Quản lí dự án Agile
Phần lớn đào tạo về quản lí dự án đều hội tụ vào dự án lớn tạp trung theo cách tiếp cận “vòng đời thác đổ”. Khi nhiều công ti dùng phương pháp agile, người quản lí dự án phải được đào tạo lại để bắt kịp với thay đổi công nghệ và phương pháp để cho họ có thể hiệu quả hơn. Sau đây là một số gợi ý:
Vì phần lớn các dự án agile đều nhỏ (3 tới 9 người), điều quan trọng là giữ cho các nhiệm vụ dự án nhỏ (8 tới 20 giờ) để cho các thành viên tổ có thể hoàn thành nhiệm vụ của họ nhanh hơn. Về mặt truyền thống, người quản lí dự án được đào tạo để chia các yêu cầu thành các nhiệm vụ từ một tới bốn tuần; điều này sẽ KHÔNG có tác dụng tốt với phương pháp agile. Qui tắc của tôi là “nhiệm vụ dự án lớn hơn được ước lượng trong một tuần, nhiệm vụ dự án nhỏ hơn (Agile) nên được ước lượng theo giờ.”
Bởi vì bạn có kích cỡ nhiệm vụ nhỏ hơn, bạn phải lập kế hoạch để thực hiện cột mốc nào đó chỉ trong một tuần mỗi lúc. Người quản lí dự án phải theo dõi tất cả các công việc bên trong chiều dài một tuần để cho họ biết điều họ đã làm được trong một tuần. Nếu họ không làm tiến bộ tốt, đây là dấu hiệu cảnh báo rằng dự án có thể KHÔNG được hoàn thành đúng thời gian. Thành viên tổ phải theo dõi tiến bộ của mình, nơi họ bắt đầu từ đầu tuần và nơi họ tới lúc cuối. Về căn bản từng người phải có nhiều nhiệm vụ được hoàn thành trong một tuần, nếu họ kết thúc họ phải đánh giá lại công việc của mình hay ước lượng của mình.
Bất kì nhiệm vụ nào cũng phải có một định nghĩa về “làm xong”. Nhiều người phần mềm vẫn còn tranh cãi về “làm xong” là gì. Qui tắc của tôi là “Làm xong là đã sẵn sàng được được ra cho người dùng.” Điều đó nghĩa là việc viết mã phải được thực hiện bao gồm mọi kiểm thử mà không còn lỗi. Khi bạn hoàn thành cái gì đó nó phải được hoàn thành, nó KHÔNG THỂ được hoàn thành bộ phận. Vì nó sẵn sàng để đưa ra, nó phải được kiểm thử đầy đủ để cho người dùng có thể dùng ngay được nó. Tất nhiên, đôi khi, một thành viên tổ KHÔNG thể kiểm thử được công việc của họ chừng nào những người khác còn chưa làm xong phần của họ. Nhưng thành viên tổ nên làm công việc của mình được thực hiện xong nhiều nhất có thể được.
Về truyền thống, người quản lí dự án phân công nhiệm vụ cho các thành viên tổ và theo dõi họ tương ứng. Phương pháp Agile hội tụ nhiều hơn vào công việc tổ cho nên người quản lí dự án phải làm việc với tổ để xác định cái gì cần được thực hiện để hoàn thành nhiệm vụ trong một tuần hay để sang cột mốc khác. Để dự án agile thành công, các thành viên tổ phải có đủ kinh nghiệm để cho họ có thể đóng góp cho công việc toàn thể. Thảo luận tổ về cái gì có thể được thực hiện, nhiệm vụ nào nên được thực hiện và cái gì có thể được hoàn thành để tiến sang cột mốc tiếp nên được động viên. Càng nhiều thảo luận, các thành viên tổ các tham gia vào trong dự án, càng có tự tin rằng dự án sẽ hoàn thành đúng lịch biểu.
Bởi vì các dự án agile là nhỏ, điều quan trọng là hội tụ nhiều vào chức năng hơn vào kiến trúc. Về truyền thống trong các dự án lớn, người quản lí dự án tổ chức công việc bằng kiến trúc và nhiều nhiệm vụ hội tụ vào tầng kiến trúc. Với phương pháp agile, bạn nên chia các nhiệm vụ xuyên qua kiến trúc để cho bạn có thể hoàn thành một tính năng hay chức năng vào mỗi lúc, cho dù bạn không hoàn thành tầng kiến trúc. Cách tiếp cận này dường như phản trực giác với lí thuyết phần mềm, nhưng tôi thấy nó nhanh hơn và cho phép bạn kết thúc sản phẩm sớm hơn.
Thay vì tạo ra lịch biểu đầy đủ trước thời gian, tôi thích dùng cách tiếp cận lặp bằng viế thiết lập lịch biểu một tuần vào mỗi lúc, nơi các thành viên tổ đều tham gia để cho tôi biết họ có thể hoàn thành được cái gì vào tuần đó. Một khi họ đã đạt tới một cột mốc, đó là lúc ước lượng và lập kế hoạch sang cột mốc tiếp. Việc cả tổ tham gia vào ước lượng lịch biểu là tốt hơn nhiều so với ước lượng riêng của các cá nhân. Tôi đòi hỏi từng thành viên tổ phải đưa ra ước lượng riêng của họ và dùng cách tiếp cận “Delphi băng rộng” hay cách tiếp cận trung bình để đi tới lịch biểu toàn thể. Khi bạn cho phép mọi người tạo ra ước lượng riêng của họ, họ có xu hướng theo dõi mình, đi theo mình, và cố gắng làm cho nó được hoàn thành thành công bởi vì ước lượng của họ là một phần công việc của họ.
Bởi vì các dự án agile đều nhỏ, bạn phải tích hợp các công việc liên tục, không thành vấn đề bạn đang làm cái gì (mã, kiểm thử, tài liệu, kế hoạch). Bạn phải có người làm quản lí cấu hình phần mềm để giúp thiết lập cấu hình và phiên bản đúng cho phần mềm của bạn vì công việc thường xuyên thay đổi. Khi phiên bản cuối cùng được kiểm đưa vào, và tôi biết trạng thái nó tới trong nó và tôi không phải nghĩ về nó.
Ai đó hỏi tôi, nếu agile là hoạt động toàn tổ, có thực sự cần người quản lí dự án không? Câu trả lời của tôi là dứt khoát “Có”. Tuy nhiên, vai trò của người quản lí dự án trong phương pháp agile mang nhiều tính người lãnh đạo và thầy kèm chứ KHÔNG kiểm soát như được dạy trong hầu hết các giáo trình quản lí dự án. Bạn càng cung cấp nhiều hướng dẫn và hỗ trợ cho tổ, họ sẽ càng có kết quả hơn. Bạn càng thực hành cách tiếp cận cộng tác này, bạn càng linh hoạt hơn như một người quản lí dự án, điều làm cho bạn thành người quản lí giỏi hơn. Bạn KHÔNG ra lệnh cho họ, bạn KHÔNG chỉ đạo họ, bạn KHÔNG chỉ huy họ, bạn KHÔNG đe doạ họ mà bạn là người hướng dẫn họ, ai đó mà họ tin cậy và ai đó giúp cho họ làm công việc của họ. Về căn bản, bạn là người lãnh đạo của họ và người lãnh đạo KHÔNG phải là ai đó có thẩm quyền trên họ mà là ai đó họ sẵn lòng đi theo.
Dự án agile thành công có hai yếu tố then chốt: Người lãnh đạo là người quản lí dự án và tổ có kinh nghiệm và có kỉ luật. Không có hai yếu tố này, nó sẽ là khó. Câu hỏi của tôi là “Là người quản lí dự án, bạn có sẵn lòng thay đổi để trở thành người lãnh đạo giỏi hơn không?” và “Là thành viên tổ, bạn có đủ kinh nghiệm và kỉ luật để áp dụng phương pháp agile vào công việc của bạn không?”
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
