Phương pháp Scrum
Một người viết cho tôi: “Em đã làm việc như người phát triển phần mềm trong ba năm và vừa mới được đề bạt làm người quản lí dự án. Gần đây công ti của em đang chấp nhận phương pháp agile (phương pháp Scrum). Có tin đồn rằng họ không cần người quản lí dự án nữa và em có thể bị sa thải. Em có thể làm gì để duy trì vị trí của em? Xin thầy lời khuyên.”
Đáp: Việc dịch chuyển từ phát triển truyền thống sang cách tiếp cận agile mất thời gian và đào tạo để làm nó cho đúng. Mọi người phải hiểu vai trò, trách nhiệm của họ và đảm nhiệm cho công việc của họ. Điều này sẽ yêu cầu thay đổi trong cách công ti vận hành từ đỉnh tới đáy nơi những người quản lí phải hiểu “tình huống lí tưởng” là thế nào và tình huống nào thì không. Dễ nói điều gì đó như chúng ta không cần người quản lí dự án nữa nhưng trong thực hành điều đó không xảy ra dễ dàng thế. Đừng mong đợi việc dịch chuyển từ phát triển truyền thống sang cách tiếp cận agile xảy ra trong vài tuần hay vài tháng, có nhiều điều công ti của bạn phải học từ việc chuyển này, và nó sẽ yêu cầu nhiều nỗ lực để làm việc cho đúng. Theo ý kiến cá nhân, tôi nghĩ Scrum là cách tiếp cận rất tốt tới phát triển phần mềm. Nó khác với cách tiếp cận thác đổ truyền thống mà yêu cầu phải là rõ ràng và được hiểu. Scrum chấp nhận rằng yêu cầu có thể không được xác định rõ từ đầu cho nên chúng có thể thay đổi và mục đích là đáp ứng theo cách tốt với những thay đổi đó bằn việc tạo ra phần mềm làm việc tăng dần cho khách hàng.
Về căn bản, có ba vai trò trong Scrum: Thầy Scrum, Người chủ sản phẩm, và Tổ tự quản. Mặc dầu không có vị trí người quản lí “chính thức” trong Scrum, điều đó không có nghĩa là bạn không có việc làm. Bạn có thể vẫn học làm việc như một Thầy Scrum để đảm bảo rằng mọi người tuân theo các qui tắc scrum; tạo điều kiện cho gặp gỡ giữa tổ và người chủ sản phẩm; và loại bỏ các chướng ngại từ dự án để cho tổ dự án có thể hội tụ vào sản phẩm mà không bị ngắt quãng. Kĩ năng mà bạn đã học như người quản lí dự án vẫn áp dụng được trong phương pháp Scrum. Chẳng hạn, bạn có thể tham gia và tạo điều kiện cho việc phát triển Tồn dư sản phẩm của những việc được ưu tiên hoá để được thực hiện. Tồn dư là tương tự như đặc tả yêu cầu của dự án truyền thống mà bạn quen thuộc với. Trong Scrum, tồn dư sản phẩm thường được phát triển cùng với Người chủ sản phẩm và Tổ phát triển nhưng trong việc chuyển dịch, họ vẫn cần ai đó để quản lí nó.
Dự án cần có Kế hoạch đưa ra để chuyển giao sản phẩm qua nhiều chặng nước rút Sprints với ưu tiên cao nhất được chuyển giao trước nhất. Kế hoạch đưa ra cũng là tương tự với Lịch biểu dự án. Nó nhận diện tính năng sản phẩm và thời gian tương ứng theo đó những tính năng nào đó sẽ được chuyển giao cho khách hàng. Trong Scrum, Kế hoạch đưa ra được phát triển chung bởi Người chủ sản phẩm và Tổ phát triển nhưng trong khi dịch chuyển, họ vẫn cần ai đó tạo điều kiện và quản lí nó.
Vậy mà, Người chủ sản phẩm và Tổ phát triển quyết định tính năng nào và nhiệm vụ có liên quan nào được thực hiện trong từng Sprint, ai đó có nhiều kinh nghiệm phải đưa ra các ước lượng như một phần của lập kế hoạch Sprint. Những rủi ro và vấn đề nào đó cũng phải được thảo luận trong Họp lập kế hoạch Sprint nơi việc phát triển, kiểm thử và đưa ra được xác định và đây là chỗ kinh nghiệm của bạn được cần tới.
Khi các nhiệm vụ được nhận diện trong Họp lập kế hoạch Sprint, chúng được làm tài liệu trong Tổn dư Sprint. Tồn dư Sprint là tương tự như Phạm vi dự án trong phát triển truyền thống bởi vì nó bao quát mọi hoạt động cần được hoàn thành bên trong Sprint.
Tồn dư Sprint được cập nhật trong cuộc họp Sprint nơi khách hàng và người dùng được mời tham dự và có thể cần ai đó như bạn, người có thể tạo điều kiện và quản lí cuộc họp.
Trong cách tiếp cận Scrum, có cuộc họp hàng ngày nơi các thành viên tổ chia sẻ mối quan tâm và hoạt động của họ giữa các tổ, thỉnh thoảng họ cần ai đó để quản lí nó cho tới khi tổ sẵn sàng tự quản và có hiệu quả.
Đến cuối của từng Sprint, tổ họp cùng nhau và thảo luận cái gì làm việc và cái gì không làm việc, cuộc họp hồi tưởng này là tương tự với “bài học rút ra” truyền thống hay kiểm điểm “hậu kì” trong dự án truyền thống. Chừng nào tổ chưa có kinh nghiệm và không hiệu quả, nó có thể cần ai đó để tạo điều kiện cho cuộc họp hồi tưởng để chắc mọi sự làm việc tốt.
Nếu bạn so sánh các vai trò của người quản lí dự án truyền thống với Thầy Scrum, bạn có thể thấy rằng có những nhiệm vụ nào đó thiếu trong Thầy Scrum vì trong tình huống lí tưởng, mọi thứ có thể được thực hiện bởi Tổ tự quản, giả định rằng tổ bao gồm những thành viên có kinh nghiệm và được đào tạo tốt. Tuy nhiên trong thực hành, điều đó có thể không xảy ra theo cách đó. Vai trò của Thầy Scrum có thể bành trướng ra để bao quát một số nhược điểm khác. Trong cách tiếp cận Scrum, qui trình được tạo điều kiện bởi Thầy Scrum người có trách nhiệm chính là hướng dẫn và loại bỏ các vấn đề ngăn cản tổ đáp ứng mục đích. Mặc dầu Thầy Scrum Master không phải là người quản lí của tổ (Tổ là tự tổ chức và tự quản) nhưng trong thực tế và trong khi dịch chuyển, Thầy có thể hành động như người tạo điều kiện cho việc giải quyết vấn đề và cho trao đổi và thỉnh thoảng phải đóng vai trò tích cực hơn trong việc bảo đảm rằng tổ tuân theo qui trình Scrum, tạo điều kiện cho cộng tác, và hành động như “thầy kèm” cho tổ.
Tất nhiên trong Scrum, bạn không hành động như người quản lí dự án, chỉ đạo mọi thứ, quản lí mọi thứ và chịu trách nhiệm về mọi thứ. Trong Scrum mọi người chia sẻ trách nhiệm về thành công của dự án. Tuy nhiên, trong thực hành ai đó phải quan tâm tới lịch biểu, chi phí và ngân sách và tôi nghĩ là người quản lí dự án, mọi người sẽ mong đợi bạn hoàn thành vai trò đó. Lời khuyên của tôi là học nhiều nhất có thể về Scrum vì với kinh nghiệm của bạn, công ti của bạn sẽ cần ai đó như bạn.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
