08/07/2013 – Blogs of Prof. John Vu, Carnegie Mellon University
– This article is translated into Vietnamese by Ngo Trung Viet with the English
originals followed.
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?”
______________________________________
Giáo sư John Vu, một người Mỹ gốc Việt, là một nhà khoa học nổi
tiếng nước Mỹ thuộc trong Top 10 những người sáng tạo nhất thế giới. Ông từng
là Phó Chủ tịch của Boeing. Sau khi rời Boeing, GS John Vu hiện là viện trưởng
Viện Công Nghệ Sinh Học ÐH Carnegie Mellon. Ông là dịch giả/tác giả bộ sách
Hành Trình về Phương Ðông, Ðường Mây Qua Xứ Tuyết, Ngọc Sáng Hoa Sen, Trên Ðỉnh
Tuyết Sơn,… và cuốn mới nhất 2016 là Khởi Hành.
______________________________________
—-English version—-
Managing an Agile Project
Most project management trainings are focusing on larger project
focusing on the “Waterfall life cycle” approach. As more companies are using
agile method, project managers should be retrained to keep up with changing
technology and method so they can be more effective. Following are some
suggestions:
Since most agile projects are small (3 to 9 people), it is
important to keep project tasks small (8 to 20 hours) so team members can
complete their tasks faster. Traditionally, project managers are trained to
breakdown requirements into one to four week tasks; this will NOT work well
with agile method. My rule is “larger project task is estimated in week,
smaller project task (Agile) should be estimated in hour”.
Because you have smaller task sizes, you should plan to
accomplish certain milestone in just one week at a time. Project managers
should track all works within that one week long so they know what they get
done in a week. If they are not making good progress, this is a warning signs
that the project may NOT be completed on time. Team member must track their
progress, where they are at the beginning of the week and where they are at the
end. Typically each should have several tasks to be completed within a week, if
they did not finish they should reevaluate their works or their estimates.
Any given task should have a definition of “Done”. Many software
people still argue about what is “done”. My rule is “Done is ready to be
released to users.” That means the code have to be done including all tests
with no defect. When you finish something it must be completed, it CAN NOT be
partially completed. Since it is ready to release, it must be fully tested so
users can use it immediately. Of course, sometimes, a team member can NOT test
their work until other people have done their parts. But team member should
make their works done as much as they can.
Traditionally, project managers assign tasks to team members and
track them accordingly. Agile method focuses more on teamwork so project
managers should work with the team to determine what should be done to complete
a one week task or to the next milestone. For agile project to be successful,
team members must be experienced enough so they can contribute to the overall.
A team discussion on what can be done, what tasks should be done and what can
be accomplished to get to the next milestone should be encouraged. The more
discussion, the more team members participate in the project, the more
confidence that the project will be complete on schedule.
Because agile projects are small, it is important to focus more on
functionality than on the architecture. Traditionally in larger projects,
project manager is organizing the work by architecture and many tasks are
focusing on the architecture layer. For agile method, you should breakdown
tasks across the architecture so you can finish a feature or a function at a
time, even if you don’t finish the architectural layer. This approach may seem
counter-intuitive to software theories, but I found it is faster and allows you
to finish your product earlier.
Instead of create a fully schedule ahead of time, I like to use
an iterative approach by set up one week schedule at a time where team members
participate to let me know what they can accomplish on that week. Once they’ve
reached one milestone, it’s time to estimate and plan to get to the next one. A
team participating on estimates the schedule is much better than an
individual’s. I ask each team member to come up with their own estimate and use
a “Wideband Delphi” approach or an average approach to come up with the overall
schedule. When you allow people to create their own estimates, they tend to
track them, follow them, and try to make it complete successfully because their
estimate is part of their works.
Because agile projects are small, you must integrate works
continuously, no matter what you are doing (code, tests, documentation, plans).
You must have software configuration management people to help set up proper
configuration and version for your software as works are constantly changing.
When the latest version is checked in, and I know the state that it has in it
and I do not have to think about it.
Some people ask me, if agile is a teamwork activity do you
really need a project manager? My answer is definitely “Yes”. However, the role
for project managers in agile method is more of a leader and mentor and NOT
control as taught in most project management courses. The more you provide
guidance and supporting the team, the more they will produce. The more you
practice this collaboration approach, the more flexible you are as a project
manager, which makes you a better manager. You do NOT order them, you do NOT
direct them, you do NOT command them, you do NOT threaten them but you are
their guidance, someone that they trust and someone that helping them to do
their works. Basically, you are their leader and leader is NOT someone who has
authority over them but someone that they are willing to follow.
A successful agile project has two key factors: A leader as
project manager and an experienced and disciplined team. Without these two
factors, it would be difficult. My question is “As project manager, are you
willing to change to become a better leader?” and “As a team member, do you
have enough experienced and disciplines to apply the agile method into your
work?”
________________________________________
ĐỌC THÊM
Giới thiệu
Vietnam Carenet TẠI ĐÂY
Tủ Sách
Vietnam Carenet TẠI ĐÂY
Các bài
viết về Khởi Nghiệp TẠI ĐÂY
Các bài
viết về Lập Kế Hoạch TẠI ĐÂY
Các bài
viết về Lập Dự Án TẠI ĐÂY
Các bài
viết về Quản lý Dự Án TẠI ĐÂY
Các bài
viết về Kỷ Nguyên 4.0 TẠI ĐÂY
Các bài
viết về Agile & Scrum TẠI ĐÂY