Visual Paradigm Desktop | 
Visual Paradigm Online
Việc bước vào lĩnh vực phát triển phần mềm thường giống như việc nhảy lên một chiếc tàu đang chạy. Bạn học lý thuyết trong lớp học, nhưng thực tế trên thực địa lại vận hành theo một nhịp độ khác biệt. Nhiều sinh viên tốt nghiệp với hiểu biết vững chắc về các nguyên tắc Agile trên giấy, nhưng lại gặp khó khăn khi đối mặt với buổi họp lập kế hoạch sprint đầu tiên. Khoảng cách giữa định nghĩa học thuật và thực tiễn hàng ngày có thể rất lớn.
Chúng tôi đã thu thập những câu hỏi từ sinh viên tại các trường đại học và các khóa học kỹ thuật để tìm hiểu chính xác điều gì khiến họ bối rối. Sau đó, chúng tôi đã nhờ những chuyên gia có kinh nghiệm, từng dẫn dắt đội nhóm hơn một thập kỷ, trả lời trực tiếp các câu hỏi này. Ở đây không có lời quảng bá, chỉ có những hiểu biết thực tế được rút ra từ nhiều năm phát hành mã nguồn và quản lý con người. Cẩm nang này nhằm mục đích lấp đầy khoảng cách đó, mang lại sự rõ ràng về vai trò, nghi thức và những kỹ năng mềm thực sự quan trọng.
Sinh viên thường nghe rằng buổi họp sáng hàng ngày là cuộc họp để báo cáo tiến độ cho quản lý. Đây là một hiểu lầm phổ biến. Trong ngành, buổi họp này chỉ dành riêng cho đội phát triển để đồng bộ hóa. Scrum Master hoặc Product Owner có thể tham dự, nhưng họ ở đó để lắng nghe, chứ không phải để ra lệnh.
Dưới đây là cách nó thực sự hoạt động trong thực tế:
Khi sinh viên đặt câu hỏi về điều này, họ lo lắng rằng nếu không có gì để nói sẽ trông như đang lười biếng. Thực tế trong ngành lại khác. Nếu bạn không có gì để báo cáo, bạn không cần phải nói lâu. Buổi họp này nhằm mục đích minh bạch, chứ không phải đánh giá hiệu suất.
Đây có lẽ là vai trò gây nhầm lẫn nhất trong Agile. Sinh viên thường cho rằng Product Owner (PO) là một quản lý dự án truyền thống. Mặc dù họ chia sẻ một số trách nhiệm, nhưng cấu trúc quyền lực lại khác biệt.
Product Owner đại diện cho tiếng nói của khách hàng. Họ sở hữu Product Backlog. Điều này có nghĩa là họ quyết định cái gì sẽ được xây dựng và theo thứ tự nào. Họ không chịu trách nhiệm về quy trình của đội nhóm, nhưng họ chịu trách nhiệm về giá trịcủa sản phẩm.
Ở nhiều tổ chức, vai trò PO là một công việc toàn thời gian. Ở các nhóm nhỏ hơn, vai trò này có thể do một lập trình viên hoặc nhà thiết kế đảm nhận. Yếu tố then chốt là PO phải luôn sẵn sàng cho đội để trả lời các câu hỏi ngay lập tức trong suốt một sprint.
Một trong những nỗi sợ lớn nhất đối với sinh viên mới ra trường là giai đoạn ước lượng. Họ muốn một con số chính xác 100%. Trên thực tế, việc ước lượng chính xác là không thể trong môi trường phức tạp. Xu hướng ngành đã chuyển từ giờ sang ước lượng tương đối.
Thay vì nói ‘Công việc này sẽ mất 4 giờ’, các đội sử dụng Điểm Câu Chuyện. Điều này đo lường nỗ lực, độ phức tạp và rủi ro. Đây là một con số tương đối so với các công việc khác.
Tốc độlà chỉ số được dùng để theo dõi số điểm mà một đội hoàn thành trong mỗi sprint. Đây là trung bình lịch sử, chứ không phải mục tiêu. Nếu một đội trung bình hoàn thành 20 điểm mỗi sprint, họ sẽ lên kế hoạch cho 20 điểm trong sprint tiếp theo. Nếu họ không đạt được, đó là tín hiệu để kiểm tra quy trình, chứ không phải thất bại của cá nhân.
Sinh viên thường lo lắng rằng một đội Agile sẽ thất bại nếu điều gì đó hỏng. Khung Agile được thiết kế để xử lý thất bại ngay từ đầu. Phiên tổng kếtlà không gian được dành riêng cho điều này.
Vào cuối mỗi sprint, đội sẽ họp để thảo luận những gì đã diễn ra tốt và những gì chưa tốt. Đây không phải là cuộc chơi đổ lỗi. Đây là một buổi họp cải tiến quy trình.
Các vấn đề phổ biến bao gồm nợ kỹ thuật tích tụ, mở rộng phạm vi công việc hoặc kiệt sức. Nếu một nhóm thường xuyên không đạt được mục tiêu của mình, buổi phản tư sẽ là nơi họ quyết định ngừng thêm tính năng mới và tập trung vào sự ổn định.
Sinh viên thường xuyên hỏi liệu họ có cần bằng chứng nhận Scrum Master Chứng nhận (CSM) hay Chứng nhận Scrum Master Chuyên nghiệp (PSM) để được tuyển dụng hay không. Câu trả lời chân thành phụ thuộc vào công ty.
Ưu điểm của Chứng chỉ:
Nhược điểm của Chứng chỉ:
Cách tiếp cận tốt nhất là kết hợp chứng chỉ nền tảng với kinh nghiệm thực tế. Tự nguyện dẫn dắt một dự án sinh viên bằng phương pháp Agile. Ghi chép lại quy trình. Điều này cho thấy bạn có thể áp dụng lý thuyết, chính là điều nhà tuyển dụng thực sự tìm kiếm.
Sự chuyển dịch sang làm việc từ xa đã thay đổi cách thực hiện các thực hành Agile. Bảng vật lý không còn khả dụng. Các nhóm phải dựa vào công cụ kỹ thuật số và các giao thức giao tiếp.
Một thách thức lớn là mất đi hiện tượng “nghe lén”. Trong văn phòng, bạn học được điều gì đó bằng cách đi ngang qua bàn làm việc. Trong môi trường từ xa, bạn phải lên lịch các cuộc trò chuyện không chính thức. Khuyến khích tạo kênh “bồn nước ảo” để nói chuyện phi công việc nhằm xây dựng niềm tin.
Các bên liên quan thường muốn thêm tính năng trong giữa vòng lặp. Trong mô hình waterfall truyền thống, điều này có thể được chấp nhận như một lệnh thay đổi. Trong Agile, mục tiêu vòng lặp là thiêng liêng.
Nếu một yêu cầu mới đến trong vòng lặp, quy tắc đơn giản là: Đừng thêm nó. Nếu nó cấp bách, một mục hiện có phải được loại bỏ để duy trì năng lực không đổi. Điều này đảm bảo nhóm không kiệt sức và giao được những gì đã hứa.
Những ý tưởng mới được đưa vào Danh sách Sản phẩm. Chúng được ưu tiên ở đó. Nếu có giá trị cao, chúng sẽ được đưa vào cuộc họp tiếp theo trong quá trình lập kế hoạch. Điều này bảo vệ đội khỏi sự gián đoạn trong khi đảm bảo nhu cầu kinh doanh được đáp ứng cuối cùng.tiếp theocuộc họp tiếp theo trong quá trình lập kế hoạch. Điều này bảo vệ đội khỏi sự gián đoạn trong khi đảm bảo nhu cầu kinh doanh được đáp ứng cuối cùng.
Sinh viên thường sợ nói “không” với các bên liên quan. Tuy nhiên, nói “không phải lúc này” là một ranh giới chuyên nghiệp. Điều này xây dựng niềm tin vì đội luôn hoàn thành đúng cam kết của mình.
Để giúp bạn định hướng những cuộc trò chuyện này, dưới đây là bảng các thuật ngữ bạn sẽ gặp trong ngành.
| Thuật ngữ | Định nghĩa | Sự nhầm lẫn phổ biến của sinh viên |
|---|---|---|
| Sprint | Một khoảng thời gian nhất định (thường là 2 tuần) để hoàn thành công việc. | Nghĩ rằng nó phải chính xác là 2 tuần. Thực tế có thể là 1 tuần hoặc 4 tuần. |
| Danh sách chờ | Danh sách được ưu tiên tất cả các công việc mong muốn. | Nhầm lẫn nó với danh sách việc cần làm. Nó là động và được sắp xếp. |
| Câu chuyện người dùng | Mô tả một tính năng từ góc nhìn người dùng. | Nghĩ rằng nó là một bản mô tả kỹ thuật. Thực tế nó liên quan đến giá trị. |
| Tiêu chuẩn hoàn thành | Danh sách kiểm tra các tiêu chí mà một nhiệm vụ phải đáp ứng để được coi là hoàn thành. | Nghĩ rằng “viết xong mã” là đủ. Nó phải được kiểm thử và tài liệu hóa. |
| Tốc độ | Số lượng công việc trung bình được hoàn thành mỗi sprint. | Nghĩ rằng nó là mục tiêu hiệu suất cá nhân. Thực tế nó là về năng lực của đội. |
| Chướng ngại vật | Một vấn đề cản trở công việc tiến triển. | Bỏ qua nó. Các chướng ngại vật phải được loại bỏ ngay lập tức. |
Kỹ năng kỹ thuật giúp bạn có buổi phỏng vấn. Kỹ năng mềm giữ bạn lại trong công việc. Agile về cơ bản là về con người hơn là quy trình. Một đội có giao tiếp xuất sắc sẽ vượt trội hơn so với đội có tài liệu hoàn hảo.
Học sinh thường nghe rằng Agile là con đường duy nhất. Điều đó không đúng. Waterfall vẫn được sử dụng trong các ngành có yêu cầu quy định cao, như y tế hoặc hàng không vũ trụ, nơi tài liệu và phê duyệt là yếu tố then chốt trước khi bắt đầu xây dựng.
Agile phù hợp nhất với các dự án mà yêu cầu có khả năng thay đổi. Nếu mục tiêu là cố định và công nghệ đã được hiểu rõ, một phương pháp kết hợp có thể hoạt động. Điều quan trọng là chọn phương pháp phù hợp với rủi ro của dự án, chứ không phải chạy theo trào lưu.
Trong môi trường học thuật, các vấn đề thường được giải quyết bởi cá nhân. Trong ngành công nghiệp, các trở ngại thường đến từ bên ngoài nhóm. Điều này có thể là quyền truy cập vào máy chủ, thiếu giấy phép, hoặc quy trình phê duyệt chậm trễ.
Scrum Master chịu trách nhiệm loại bỏ những trở ngại này. Tuy nhiên, nhóm cũng cần được trao quyền để yêu cầu sự giúp đỡ. Nếu một chướng ngại tồn tại quá một ngày, nó phải được báo cáo lên quản lý.
Theo dõi những trở ngại này giúp lãnh đạo nhận diện các vấn đề hệ thống. Nếu cùng một loại chướng ngại xuất hiện ở mỗi sprint, tổ chức cần khắc phục nguyên nhân gốc rễ, chứ không chỉ giải quyết nhiệm vụ cụ thể.
Một nguồn chính gây mâu thuẫn là định nghĩa về “Hoàn thành”. Trong trường học, một dự án được coi là hoàn thành khi bạn nộp bài. Trong phần mềm, “Hoàn thành” có nghĩa là mã đã được viết, kiểm thử, xem xét và triển khai.
Nếu một nhóm nói một tính năng đã hoàn thành nhưng chưa được kiểm thử, thì điều đó chưa thực sự hoàn thành. Nó chỉ là “đã viết mã”. Sự phân biệt này rất quan trọng đối với các bên liên quan. Họ cần biết rằng thứ họ thấy trong bản trình diễn thực sự là phần mềm có thể sử dụng được.
Điều này nên là một danh sách kiểm tra được cả nhóm đồng thuận. Ví dụ bao gồm:
Nếu bất kỳ mục nào trên danh sách này chưa được chọn, câu chuyện không thể đóng lại. Điều này đảm bảo chất lượng sẽ không bao giờ bị hy sinh vì tốc độ.
Các đội Agile là những máy học tập. Họ kiểm tra và thích nghi. Nếu một đội ngừng học hỏi, họ sẽ ngừng cải tiến. Điều này có nghĩa là chấp nhận thất bại như dữ liệu.
Khi một vòng sprint không đạt được mục tiêu, phản ứng cần là tò mò, chứ không phải hoảng loạn. Tại sao chúng ta thất bại? Việc ước lượng có sai không? Một phụ thuộc có bị hỏng không? Thị trường có thay đổi không?
Sinh viên nên xem công việc đầu tiên của mình như một giai đoạn học tập sâu sắc. Đặt câu hỏi. Thừa nhận khi bạn không biết điều gì đó. Điều tệ nhất bạn có thể làm là giả vờ biết và giao sản phẩm bị lỗi.
Ngành công nghiệp đang phát triển. Scrum thuần túy thường quá cứng nhắc đối với một số tổ chức. Chúng ta đang thấy sự gia tăng của các khung công tác như Kanban, tập trung vào luồng công việc thay vì các khoảng thời gian cố định. Các mô hình kết hợp đang phổ biến.
Những giá trị cốt lõi vẫn giữ nguyên: Con người và tương tác quan trọng hơn quy trình và công cụ. Phần mềm hoạt động quan trọng hơn tài liệu chi tiết. Hợp tác với khách hàng quan trọng hơn đàm phán hợp đồng. Phản ứng với thay đổi quan trọng hơn tuân theo kế hoạch.
Khi công nghệ phát triển, những nguyên tắc này sẽ định hướng cách các đội xây dựng phần mềm. Dù là tích hợp AI hay blockchain, yếu tố con người trong hợp tác vẫn luôn là trung tâm.
Để kết thúc, đây là những điểm chính từ các chuyên gia trong ngành:
Sự chuyển đổi từ sinh viên sang người thực hành là thách thức. Bạn sẽ gặp những tình huống mà câu trả lời trong sách giáo khoa không phù hợp với thực tế. Điều đó là bình thường. Hãy dùng các nguyên tắc như la bàn, chứ không phải bản đồ cứng nhắc. Lắng nghe đội nhóm, tôn trọng quy trình và luôn hướng đến việc mang lại giá trị cho người dùng.
Agile không phải là điểm đến. Đó là hành trình liên tục cải tiến. Bằng cách đặt ra những câu hỏi đúng đắn và tìm kiếm những câu trả lời chân thành, bạn sẽ đi con đường sự nghiệp này với sự tự tin và rõ ràng.