1. Tư duy và nguyên tắc Agile

Bản tuyên ngôn Agile - Lịch sử hình thành Agile

12 nguyên tắc của Agile

2. Agile Methodologies - Phương pháp luận Agile

Agile có hơn 50 phương pháp quản lý dự án, một vài phương pháp có thể kể đến: Scrum, Extreme Programming (XP), Lean product development, Kanban, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal, Scrum of Scrum,… 

Các phương pháp phổ biến trong bài thi PMI-ACP® có thể kể đến:

• Scrum
• Extreme Programming (XP)
• Kanban
• Scrum of Scrum

3. Value-Driven Delivery - Phân phối theo định hướng giá trị

• Deliver “highest-value" càng sớm càng tốt là ưu tiên hàng đầu của Agile Team. Khi gặp các tình huống liên quan đến xác định độ ưu tiên yêu cầu/công việc,… thì nên xem xét vào các đáp án có mang lại “value" cao. 
• “Risk" trong phạm vi PMI-ACP® chỉ đề cập đến rủi ro mang lại “Negative impact” (hay Threats), nên Risk = Anti-value. r
• Product Owner sẽ là người “accountable" cho việc “Maximize/Optimize value of product" nên các ngữ cảnh liên quan đến Product (yêu cầu, độ ưu tiên, thay đổi về yêu cầu,…) thì cách làm là mình sẽ “refer" đến Product Owner, hoặc nhờ hỗ trợ từ Product Owner để xử lý. 

4. Đánh giá giá trị trong dự án Agile

 Xác định dự án tiềm năng

Để xác định các dự án tiềm năng trong dự án Agile, thông thường mình sẽ sử dụng các công thức:

• ROI
• PV
• NPV
• IRR

→ Các chỉ số này, chỉ số nào càng cao thì dự án đó mang lại giá trị càng cao. Trong phạm vi bài thi PMI-ACP®, các câu hỏi tính toán hầu như là không có, nên mình có thể tìm hiểu thêm chứ không cần tập trung quá nhiều vào các câu hỏi tính toán. 

 Earned Value Management trong dự án Agile

- Thông thường, Earned Value Management sẽ dùng cho các cột mốc “release" thay vì “iteration". Mục tiêu của Earned Value Management: 

• EVM là một bộ công thức để thể hiện hiệu suất.
• Thể hiện giá trị thu được của hiệu suất thực tế so với hiệu suất dự kiến.

- Cách sử dụng Earned Value Management trong Agile:

• Quy đổi các yêu cầu/User Story thành tiền.
• Sử dụng Story Points.

Tương tự, trong phạm vi bài thi PMI-ACP®, các câu hỏi tính toán về Earned Value Management hầu như là không có, nên mình có thể tìm hiểu thêm chứ không cần đặt nặng quá các câu hỏi về tính toán. 

Tham khảo các công thức về Earned Value Management tại đây

 Các công cụ phổ biến dùng để đo lường hiệu suất (performance) trong Agile 

- Burn-down chart: Các keywords để nhận diện Burn-down chart: “remaining” work, “how much work is left”, “how close they are to achieve their sprint goals”, “how the project is progressing”,...

- Burn-up chart: Các keywords để nhận diện Burn-up chart: “scope line”, “capture scope changes”, “total number of points burned up”, “completed work”,...

Thông thường cả 02 công cụ này có thể sử dụng trong Iterations/Sprints và trong Releases.

- Velocity: Đây là một phương pháp cực kỳ đơn giản để đo lường chính xác tốc độ mà Development Team hoàn thành công việc một cách nhất quán. Velocity là cơ sở cho thấy lượng Product Backlog trung bình được chuyển thành phần gia tăng tính năng sản phẩm trong Sprint, được Development team theo dõi để sử dụng. Do đó, để tính toán velocity của nhóm, chúng ta chỉ cần cộng các ước lượng của các tính năng, user stories, yêu cầu hoặc backlog items được hoàn thành trong một lần lặp hay Sprint. 

Một vài lưu ý của Velocity:

• Velocity chỉ là phương pháp để đo lường tốc độ hoàn thành công việc trong một team, không dùng so sánh giữa team này với team khác. 
• Velocity mong đợi sẽ “stable", “consistent" vì việc ổn định, thống nhất sẽ thể hiện việc các ước lượng công việc của team là chính xác, và cũng như giữ được cho team sự ổn định. 

 Sơ lược về quản lý rủi ro trong dự án Agile

• “Risk" trong phạm vi PMI-ACP® chỉ đề cập đến rủi ro mang lại “Negative impact” (hay Threats), nên Risk = Anti-value. 
• Các yêu cầu/tính năng có mức độ rủi ro cao ưu tiên được giải quyết sớm theo mindset “Fail fast" của Agile.

5. Prioritizing Value - Ưu tiên giá trị trong Agile

- Khách hàng chính là người quyết định rằng sản phẩm/dự án của mình có thành công hay không.

- Product Owner sẽ là người “accountable" cho việc “Maximize/Optimize value of product" nên các ngữ cảnh liên quan đến Product (yêu cầu, độ ưu tiên, thay đổi về yêu cầu,…) thì cách làm là mình sẽ “refer" đến Product Owner, hoặc nhờ hỗ trợ từ Product Owner để xử lý. 

- Các yêu cầu/thay đổi cần phải dựa vào “value", yêu cầu/thay đổi nào có “value" cao thì cần được ưu tiên cao.

- Các công cụ ưu tiên phổ biến:

• MoScoW
• Monopoly Money
• 100-Point Method
• Dot Voting or Multi-Voting
• Kano Analysis

 Delivering Incrementally

- Deliver từng phần là một trong các cách Agile Team có thể tối ưu việc phân phối giá trị. 
- Agile Team thông thường sẽ deploy “working increments" của Product trong xuyên suốt khoảng thời gian dự án để:

Ở môi trường kiểm thử (chưa release ra khách hàng):

• Business Team, cũng như Agile Team sẽ có cái nhìn khách quan về tiến độ sản phẩm của mình 
• Kiểm thử sản phẩm
• Hạn chế các lỗi sai không đáng có, hoặc 
• Tạo điều kiện phát hiện ra lỗi và xử lý lỗi càng sớm càng tốt

Ở môi trường đã release ra cho khách hàng:

• Tăng cơ hội thu thập các phản hồi của khách hàng về sản phẩm
• Tăng cơ hội thấy được giá trị của sản phẩm 
• Tăng cơ hội có được lợi nhuận từ khoản đầu tư cho sản phẩm,… 

Khi nói đến việc cần deliver sản phẩm nhanh nhất có thể ra thị trường, các phương án có các keywords “incrementally", “MVP", “working products",… thông thường là các phương án đúng. 

 MVP - Minimum Viable Product

MVP hay “sản phẩm khả dụng tối thiểu" là phiên bản đầu tiên của sản phẩm mới mà Agile Team cho ra mắt thị trường, với các tính năng tối thiểu nhất, để Agile Team có thể nhanh chóng tiếp cận những khách hàng đầu tiên và nhận phản hồi nhiều nhất từ khách hàng, với ít nỗ lực nhất. 

Lưu ý: MVP bao gồm hai yếu tố “tối thiểu" và “khả dụng” (có thể sử dụng được). 

Từ đó, Agile Team sẽ:

• đánh giá được nhu cầu của thị trường
• dần cải tiến sản phẩm dựa trên phản hồi của khách hàng
• hướng đến việc xây dựng sản phẩm hoàn chỉnh trong tương lai, … 

 Verifying & Validating Value 

- Sự khác biệt giữa Verifying & Validating

- Một vài cách phổ biến của Agile Team để liên tục verifying và validating sản phẩm:

• Luôn tương tác, kết nối với các bên liên quan để hình thành, có cách hiểu chung về Acceptance Criteria và Definition of Done.
• Thiết kế, trình bày prototyping cho các bên liên quan để nắm yêu cầu, mong đợi một cách rõ nét. 
• Liên tục kết nối, tương tác với các bên liên quan để "demo" sản phẩm.

6. Agile Contracting 

Các loại Contract phổ biến trong Agile có thể kể đến: 

• Multi-tiered structure
• Emphasize value delivered
• Not-to-exceed time and materials
• Dynamic scope option
• Team augmentation
• Favor full-service suppliers
• Fixed-price increments.
• DSDM Contract
• Money for Nothing and Change for Free
• Graduated Fixed-Price Contract
• Fixed-Price Work Packages
• Customized Contracts

Tuy nhiên các câu hỏi về hợp đồng trong Agile hầu như rất ít, thậm chí là không có. Như value thứ 03 của Agile có trình bày “Customer collaboration over Contract negotiation", hợp đồng trong dự án Agile thường có những đặc điểm sau:

• Là sự đàm phán lành mạnh, phối hợp giữa hai bên để lựa chọn loại hợp đồng phù hợp nhất với dự án của mình.
• Collaboration vẫn là yếu tố quan trọng nhất giữa sự hợp tác hai bên.
• Đề xuất có những thông tin trong hợp đồng về sự linh hoạt về phạm vi, hoặc chia sẻ lợi nhuận và rủi ro giữa các bên để từ đó có thể thúc đẩy sự hợp tác giữa các bên để đạt được mục đích chung trong dự án. 

7. Stakeholder Engagement - Tương tác với các bên liên quan 

Nếu không liên tục tương tác với các bên liên quan, dự án có thể rơi vào tình trạng “Gulf of evaluation":

• Team phát triển hiểu sai về yêu cầu của sản phẩm 
• Khách hàng không mô tả đúng như những gì họ thực sự mong đợi 

 Củng cố tầm nhìn chung, cách hiểu chung về dự án 

Agile Project Charter

• Ít chi tiết hơn Traditional Project Charter
• Trả lời cho W5H (Who, What, Where, When, Why, and How)

03 đặc điểm cần ghi nhớ khi nói về Documentation/Plan trong Agile:

• Just in time: Các tài liệu chỉ cần có đúng thời điểm cần
• Just enough (barely sufficient): Các tài liệu chỉ cần có vừa đủ để thực hiện các công việc
• Progressive elaboration: Các tài liệu, kế hoạch sẽ được phát triển dần dần và tinh chỉnh liên tục

 Definion of Done

- Được tạo ra bởi Scrum Team trước khi dự án bắt đầu Sprint đầu tiên. Team sẽ:

• Tham khảo Definition of Done (DoD) của tổ chức  
• “Tailor" để phù hợp với ngữ cảnh của dự án nhưng vẫn đảm bảo được các tiêu chuẩn của tổ chức 

- DoD sẽ có thể được điều chỉnh thông qua duy nhất “Retrospective" event. 

- Agile Team nào có DoD càng chi tiết thì độ trưởng thành của team đó càng cao. 

- Trường hợp team ứng dụng Scrum of Scrum, thì DoD có thể khác nhau, tuy nhiên DoD riêng không được xung đột với DoD chung. 

- Definition of Done là bắt buộc sử dụng trong Agile/Scrum Team. Hiện tại, DoD thông thường sẽ sử dụng để chỉ đến các tiêu chí về chất lượng và ứng dụng phổ biến nhất là với User Story. Tuy nhiên, chúng ta vẫn có thể ứng dụng DoD cho các mục tiêu khác: Release, Meeting,… 

 Giao tiếp với các bên liên quan

Cách giao tiếp được đề xuất và nên được ưu tiên cao nhất là face to face communication. Nếu ngữ cảnh đề bài không đề cập đến việc Agile Team có bất cập gì trong việc “co-location" hay “face to face communication", thì nên tạo mọi điều kiện để team có thể “co-location" và “face to face communication". 

- Co-location: Liên quan đến việc đặt nhiều hoặc tất cả các thành viên nhóm dự án vào cùng một vị trí địa lý để tăng cường khả năng thực hiện dự án như một nhóm. Colocation có thể là tạm thời, chẳng hạn như colocation tại những thời điểm quan trọng chiến lược trong dự án, hoặc có thể colocation liên tục cho toàn bộ dự án. Trong phạm vi bài thi, đề bài có thể sử dụng các từ đồng nghĩa khác cho co-location:

• physically located
• everyone is in the same place
• Co-location # Distributed team (remote, virtual team,…) 

- “Close or osmotic communication” - Giao tiếp thẩm thấu: nghĩa là thông tin hữu ích chảy giữa các thành viên trong nhóm khi họ làm việc gần nhau và họ tình cờ nghe được các cuộc trò chuyện của nhau. Nhóm phải ở trong cùng một phòng để thông tin được truyền đi nhanh chóng trong nhóm.

→ Tips: 

• Các đáp án có từ “co-location", “osmotic communication” hay “face-to-face" communication đa phần là phương án đúng, cân nhắc ngữ cảnh lựa chọn. 
• Trong trường hợp team đang là "virtual" team, các phương án có keyword “video conferencing", “video call" thông thường là các phương án đúng khi mình đang lựa chọn hình thức giao tiếp nào phù hợp. 

 Giải quyết xung đột

Cách giải quyết xung đột trong phạm vi bài thi PMI-ACP® có thể đi qua các bước như sau:

• Bước 1: Tạo điều kiện để các bên đang xung đột có thể tự giải quyết xung đột với nhau, thể hiện tính “self-organization", “self-direct", … một trong những đặc điểm của Agile Team. 
• Bước 2: Nếu cả hai bên đã cố gắng nhưng vẫn không giải quyết được xung đột, PM hay Scrum Master sẽ đóng vai trò là Servant Leadership để “coach" team cách giải quyết xung đột hoặc có thể đóng vai trò là “facilitator" để team có thể biết cách xử lý. 

→ Tips: Các đáp án có từ “Coach" đa phần là phương án đúng, cân nhắc ngữ cảnh lựa chọn.

• Bước 3: Nếu PM hoặc Scrum Master đã cố gắng hết sức nhưng xung đột hiện tại đã đi quá xa và không giải quyết được, team members lại có những động thái tiêu cực quá độ và không chuyên nghiệp trong môi trường làm việc,… PM và Scrum Master có thể thực hiện các biện pháp escalation đến các cấp cao hơn hoặc HR. 

 → Tips: Thông thường rất hiếm các tình huống đi tới bước 3 này, đa phần là các tình huống dừng lại ở Bước 1 & 2. 

Có thể tham khảo thêm bài viết về Quản lý xung đột của Atoha. 

8. Adaptive Planning - Lên kế hoạch linh hoạt 

 Progressive Elaboration

Phát triển tăng dần (Progressive elaboration): Đây là quá trình lặp đi lặp lại để tăng mức độ chi tiết trong kế hoạch quản lý dự án khi lượng thông tin đang dần chi tiết hơn và các ước tính chính xác hơn. Progressive elaboration có thể áp dụng cho các mục sau đây:

• Lên kế hoạch
• Ước lượng
• Đánh giá rủi ro
• Định nghĩa về yêu cầu
• Cấu trúc hệ thống/sản phẩm
• Tiêu chí chấp thuận (Acceptance Criteria)
• Kịch bản kiểm thử (Test scenarios)

Hình ví dụ trên là ví dụ cho Rolling Wave Planning - một dạng của Progressive Elaboration dùng cho việc lên kế hoạch 

 Time-boxing - Khung thời gian 

- Phân bổ khoảng thời gian cố định, tối đa cho mỗi hoạt động được lên kế hoạch gọi là khung thời gian. Một vài time-boxing phổ biến trong các events của Agile:

• Iteration/Sprint: 04 tuần 
• Sprint Planning: 08 tiếng cho một Sprint có độ dài 01 tháng (04 tuần). 
• Daily Scrum/Daily Meeting: 15 phút
• Sprint Review: 04 tiếng
• Sprint Retrospective: 03 tiếng 

 Các dạng Iteration

• Iteration 0: Khái niệm "Sprint 0" hoặc "Iteration 0" có thể được xem là một thùng chứa tất cả các hoạt động cần được thực hiện trước Sprint đầu tiên. Thông thường, các hoạt động này sẽ bao gồm cả việc xây dựng team, thiết lập cơ sở hạ tầng, vị trí hậu cần và những thứ tương tự khác.
• Iteration H (Hardening iteration): là lần lặp cuối cùng cho công việc xử lý hậu kỳ. Ví dụ, phép lặp H được sử dụng để ổn định mã, biên dịch mã cuối cùng, tạo tài liệu sản phẩm và thực hiện thử nghiệm cuối cùng trước khi release sản phẩm. 

9. Giải quyết vấn đề theo mindset PMI-ACP®

 Project Manager, Scrum Master, hay các vị trí dẫn dắt khác trong dự án Agile thông thường có vai trò là Servant Leadership:

- Hỗ trợ team, giúp team 100% focus vào công việc. Nguồn lực trong Agile đề xuất sẽ tập trung vào một dự án (dedicated team) để team có thể hoàn thành công việc một cách nhanh nhất, cũng như đảm bảo chất lượng → Gặp các tình huống về nguồn lực xung đột, Project Manager, Scrum Master sẽ thảo luận với các bên liên quan để bảo vệ nguồn lực cũng như tạo điều kiện để team của mình có thể tập trung làm việc trong một dự án. 

- Chính vì vai trò là Servant Leadership, nên các nhiệm vụ có thể kể đến:

• “Coach" team
• Loại bỏ những rào cản có thể có trong công việc của team
• Cẩn thận các từ “command", “direct", “ask", “request", … khi xử lý các các tình huống vì đa phần các đáp án có các từ trên là PHƯƠNG ÁN SAI. 

- Luôn giữ môi trường bền vững cho đội nhóm của mình. Cẩn thận các đáp án xử lý tình huống như sau vì đa phần là PHƯƠNG ÁN SAI:

• Tăng bonus cho team, tăng incentive để team có thể làm việc ngoài giờ, cam kết cho công việc → Chưa hợp lý ở chỗ ngoài việc tăng tiền thưởng, Servant Leadership cần phải nhận diện được team member đang gặp phải tình huống cụ thể như thế nào, phân tích tình huống đấy và hỗ trợ đúng nguyên nhân.  
• Cho team làm việc overtime để chạy kịp “deadline”. 

 Đề cao sức mạnh tổng thể. Thông thường khi có tình huống xảy ra trong nội bộ team. Các phương án chủ động của Project Manager, Scrum Master có thể kể đến: 

• Tổ chức meeting (face to face càng tốt) với các bên liên quan để thảo luận vấn đề đang gặp phải. 
• Cùng team tìm nguyên nhân gốc rễ của vấn đề.
• Lựa chọn các phương án theo sự đồng thuận của team.
• Project Manager, Scrum Master, hay Product Owner sẽ không được tự ra quyết định về vấn đề công việc, kỹ thuật, mà cần phải thảo luận với các team members, và các team members/development team/developers sẽ có “final say” cho các công việc của mình bởi vì họ là những người trực tiếp thực hiện công việc đó. 

Hy vọng có thể giúp ích cho bạn đạt kết quả cao trong bài thi PMI-ACP®. Bài viết này sẽ liên tục cập nhật khi có thêm các thông tin hữu ích khác. Chúc bạn sớm đạt được mục tiêu của mình đề ra. 

Trainer Lâm Thu Nguyên 

(PfMP®, PgMP®, PMP®, PMI-ACP®, PMI-PBA®, PSPO II™, PSM II™, SPS, PAL I, PMI-ATP Instructor)

Xem thêm

PMI-ACP Guide - Hướng dẫn pass PMI-ACP on the first try

Bí kíp thi đậu PMI-ACP®

PMI AGILE CERTIFIED PRACTITIONER (PMI-ACP)® EXAMINATION CONTENT OUTLINE

Chi tiết về khoá luyện thi PMI-ACP ONLINE PRO