I. Introduction:
1 Traditional planning fails – Tại sao lập kế hoạch truyền thống không còn hiệu quả
Câu châm ngôn: He who fails to plan is planning to fai – Ai không lập kế hoạch thì đang lên kế hoạch cho sự thất bại
1.1 Usage of Features: Mức độ sử dụng các tính năng
- Never or Rarely Used: 64%
- Useful: 36 %
1.2 Project Success Rate: Tỉ lệ thành công của dự án
Challenged(Khó khăn): 53%
Success: 29%
Some data from Chaos report: 18%
1.3 “Planning Risks” Graph
1.4 Corollary Risk of Doing Too Much Up-Front Planning – Rủi ro đi kèm của việc lập kế hoạch quá nhiều ngay từ đầu
Corollary = Hệ quả tất yếu, điều kéo theo, hệ quả đi kèm Risk = Rủi ro Doing too much = Làm quá nhiều Up-front planning = Lập kế hoạch ngay từ đầu dự án (trước khi bắt đầu thực hiện)
Loss due to inadequate plans: Thiệt hại do kế hoạch không đầy đủ
Time and Effort Invested in Plans: Thời gian và công sức đầu tư vào các kế hoạch
Loss due to market share erosion: Thiệt hại do suy giảm thị phần
Loss = Tổn thất, thiệt hại Due to = Do, bởi vì Market share = Thị phần Erosion = Sự xói mòn, suy giảm dần, mất dần
Inadequate = Không đầy đủ, không thích hợp, chưa đáp ứng yêu cầu
Planning Sweet Spot là một khái niệm quan trọng trong Agile và Adaptive Planning, dùng để chỉ: Mức độ lập kế hoạch vừa đủ – không quá ít và cũng không quá nhiều.
2. Agile Planning Characteristics – Đặc điểm của việc lập kế hoạch trong Agile
Characteristic = Đặc điểm, đặc trưng
2.1 Adaptive Planning – Lập kế hoạch thích ứng
Adaptive Planning (Lập kế hoạch thích ứng) là phương pháp lập kế hoạch trong đó kế hoạch được điều chỉnh liên tục dựa trên thông tin mới, phản hồi của khách hàng và những thay đổi của dự án, thay vì cố định ngay từ đầu.
Đây là một nguyên tắc cốt lõi của Agile và cũng được nhấn mạnh trong PMBOK 7.
Định nghĩa đơn giản
Adaptive Planning là quá trình lập kế hoạch từng bước, học hỏi từ kết quả thực tế và liên tục điều chỉnh kế hoạch để đạt được giá trị cao nhất.
Tại sao cần Adaptive Planning?
Trong thực tế, rất nhiều yếu tố có thể thay đổi trong quá trình thực hiện dự án:
- Khách hàng thay đổi yêu cầu.
- Công nghệ phát triển.
- Đối thủ tung ra sản phẩm mới.
- Rủi ro mới xuất hiện.
- Đội dự án hiểu rõ sản phẩm hơn sau mỗi Iteration.
Nếu lập kế hoạch quá chi tiết ngay từ đầu, kế hoạch rất dễ trở nên lỗi thời.
Ví dụ:
- Tháng 1: Lập kế hoạch cho cả năm.
- Tháng 3: Khách hàng thay đổi yêu cầu.
- Tháng 4: Đối thủ ra mắt tính năng mới.
=> Kế hoạch ban đầu không còn phù hợp.
Adaptive Planning giúp giải quyết vấn đề này bằng cách điều chỉnh kế hoạch khi có thông tin mới.
Trong sách PMP
Trial and demo uncover the true requirement, which then require replan: Việc thử nghiệm (trial) và trình diễn sản phẩm (demo) giúp làm rõ các yêu cầu thực sự của khách hàng, từ đó đòi hỏi phải lập kế hoạch lại (replan).
Planning activities don’t directly add business functionality, they could be considered waste: Các hoạt động lập kế hoạch không trực tiếp tạo ra chức năng hay giá trị kinh doanh cho sản phẩm, vì vậy chúng có thể được xem là một dạng lãng phí nếu thực hiện quá mức.
Agile planning is less of an up-front effort, and is instead done throughout the project: Trong Agile, việc lập kế hoạch không tập trung chủ yếu vào giai đoạn đầu của dự án mà được thực hiện xuyên suốt trong toàn bộ vòng đời dự án
Midcourse adjustments are the norm: Việc điều chỉnh kế hoạch trong quá trình thực hiện (midcourse adjustments) là điều bình thường và được kỳ vọng sẽ xảy ra.
Adaptive planning = Plan to replan: Adaptive Planning (Lập kế hoạch thích ứng) = Lập kế hoạch với tư duy rằng kế hoạch sẽ được lập lại và điều chỉnh khi có thông tin mới.
2. “Just in Time” Planning – Lập kế hoạch đúng thời điểm
“Just in Time” Planning (Lập kế hoạch đúng thời điểm) là phương pháp chỉ lập kế hoạch chi tiết khi công việc sắp được thực hiện, thay vì lập kế hoạch chi tiết cho toàn bộ dự án ngay từ đầu.
Đây là một nguyên tắc quan trọng trong Agile và Adaptive Planning.
Định nghĩa
Just in Time Planning là việc lập kế hoạch vào thời điểm thông tin đã đủ rõ và ngay trước khi công việc được thực hiện, nhằm giảm lãng phí và tăng khả năng thích ứng với thay đổi.
Tại sao cần “Just in Time” Planning?
Trong dự án, càng lập kế hoạch cho những công việc ở tương lai xa thì càng có nhiều giả định và độ không chắc chắn.
Ví dụ:
- Hôm nay bạn lập kế hoạch chi tiết cho một Sprint sẽ diễn ra sau 6 tháng.
- Trong 6 tháng đó:
- Khách hàng thay đổi yêu cầu.
- Thị trường thay đổi.
- Công nghệ thay đổi.
- Đội dự án học được nhiều điều mới.
Kết quả là kế hoạch ban đầu có thể phải sửa gần như hoàn toàn.
Just in Time Planning giúp tránh lãng phí này bằng cách chỉ lập kế hoạch chi tiết khi sắp bắt đầu công việc.
Ví dụ
Cách lập kế hoạch truyền thống
Dự án kéo dài 12 tháng.
- Ngày đầu tiên lập kế hoạch chi tiết cho toàn bộ 12 tháng.
Sau 3 tháng:
- 40% yêu cầu thay đổi.
→ Phải viết lại kế hoạch.
Just in Time Planning
Dự án vẫn kéo dài 12 tháng.
Ban đầu chỉ xác định:
- Tầm nhìn sản phẩm (Vision).
- Roadmap.
- Các Epic.
Khi chuẩn bị bước vào Sprint 5 mới lập kế hoạch chi tiết cho Sprint 5.
→ Kế hoạch chính xác hơn vì dựa trên thông tin mới nhất.
Trong sách PMP
The project requirements are broken down “just in time” or at the “last responsible
moment” as the team gets closer to doing the work: Các yêu cầu của dự án được phân rã (chia nhỏ) theo nguyên tắc “Just in Time” (đúng thời điểm) hoặc tại “thời điểm chịu trách nhiệm cuối cùng” (Last Responsible Moment), khi nhóm dự án tiến gần đến thời điểm thực hiện công việc.
Broken down = Phân rã, chia nhỏ (ví dụ: chia Epic thành User Story, chia Story thành Task). Just in Time = Đúng thời điểm, chỉ thực hiện khi sắp cần đến. Last Responsible Moment = Thời điểm chịu trách nhiệm cuối cùng. Đây là khái niệm trong Lean/Agile,As the team gets closer to doing the work = Khi nhóm ngày càng tiến gần đến thời điểm thực hiện công việc.
3. Progressive Elaboration: Chi tiết hóa dần hoặc Hoàn thiện dần từng bước.
Progressive Elaboration là quá trình bổ sung và làm rõ chi tiết dần khi có thêm thông tin mới.
Các yêu cầu ở mức cao nhất (chẳng hạn như Epic) sẽ được tinh chỉnh và chi tiết hóa dần thành Feature, User Story, và cuối cùng là các hạng mục công việc chi tiết nhất như Task, Business Rule (quy tắc nghiệp vụ), Acceptance Test (kiểm thử chấp nhận), v.v.
4. Agile Discovery
Kế hoạch và thiết kế hình thành dần (Emergent Plans and Designs) so với kế hoạch và thiết kế dự đoán trước (Predictive Plans and Designs).
Các hoạt động lập kế hoạch ban đầu (Pre-Planning) nhằm giúp cả nhóm đạt được sự đồng thuận về phương pháp tiếp cận tốt nhất để thực hiện dự án.
Tinh chỉnh Product Backlog (Backlog Refinement/Grooming) và cách thức thực hiện hoạt động này.
Ước lượng các công việc còn nhiều bất định so với ước lượng các công việc đã rõ ràng và chắc chắn.
Đặc điểm của việc phát triển sản phẩm mới so với các dự án đã được hiểu rõ và có quy trình thực hiện lặp lại.
5. Value-Based Decomposition
Tiếp tục quá trình phân tích dựa trên giá trị (Value-Based Analysis).
Thu thập và làm rõ các yêu cầu từ các bên liên quan (Stakeholders).
Nhóm, phân rã và sắp xếp thứ tự ưu tiên các yêu cầu đó.
Đưa các yêu cầu đã được ưu tiên vào quá trình phát triển để triển khai thực hiện.
6. Timeboxing
Là một khoảng thời gian ngắn và có thời lượng cố định (Timebox), trong đó một tập hợp các hoạt động hoặc công việc đã được xác định sẽ được thực hiện.
Nếu các công việc đã lập kế hoạch cho Timebox chưa hoàn thành khi hết thời gian, nhóm sẽ dừng công việc đang thực hiện và chuyển phần công việc còn lại sang một Timebox khác.
Điều chỉnh phạm vi công việc để tạo ra sản phẩm có chất lượng cao nhất và mang lại giá trị ưu tiên cao nhất trong giới hạn chi phí và thời gian đã được cố định.
Cung cấp các điểm kiểm tra (checkpoints) thường xuyên để nhóm có thể đánh giá tiến độ, xem xét kết quả và điều chỉnh lại kế hoạch cũng như cách tiếp cận trong quá trình thực hiện.
II. High-level Planning: Product Vision
Là gì? (What?)
- Tầm nhìn (Vision) là trạng thái mong muốn đạt được trong tương lai, thường được mô tả thông qua một tập hợp các mục tiêu và kết quả mong muốn.
Tại sao? (Why?)
- Việc xác định và chia sẻ một tầm nhìn rõ ràng ngay từ khi bắt đầu dự án sẽ giúp xây dựng mối quan hệ tốt đẹp giữa các bên liên quan và tạo sự thống nhất về định hướng trong suốt quá trình thực hiện dự án.
Khi nào? (When?)
- Khi một dự án mới được khởi động, việc xác định rõ tầm nhìn về các mục tiêu cuối cùng cần đạt được là vô cùng quan trọng.
1. Elevator statement (elevator pitch)
Elevator Statement (Elevator Pitch) là một bài giới thiệu ngắn gọn, súc tích và thuyết phục về một ý tưởng, sản phẩm, dự án hoặc doanh nghiệp, có thể trình bày trong khoảng thời gian của một chuyến đi thang máy (khoảng 30–60 giây).
Mục tiêu của Elevator Statement là giúp người nghe nhanh chóng hiểu được vấn đề đang được giải quyết, giải pháp được đề xuất, giá trị mang lại và lý do tại sao họ nên quan tâm hoặc ủng hộ ý tưởng đó.
–Elevator Statement (thường được gọi là Vision Statement hoặc Elevator Pitch) là một bản mô tả ngắn gọn về sản phẩm, giúp nhóm tập trung vào các mục tiêu của sản phẩm thông qua việc hiểu rõ:
Sản phẩm là gì.
Sản phẩm không phải là gì.
Sản phẩm dành cho đối tượng nào.
Sản phẩm khác biệt như thế nào so với các đối thủ cạnh tranh.
–Product Owner là người xây dựng, quản lý và chịu trách nhiệm về Elevator Statement. Tuy nhiên, việc xây dựng tầm nhìn cho sản phẩm cần có sự đóng góp của toàn bộ nhóm để đảm bảo mọi thành viên đều hiểu và thống nhất về định hướng phát triển của sản phẩm.
2. Practice Activity: Develop a Product Vision Statement
Hoạt động thực hành: Xây dựng Tuyên bố Tầm nhìn Sản phẩm (Product Vision Statement).
AI (WHO)
Thành phần tham gia:
- Product Owner
- Nhà tài trợ dự án (Sponsor)
- Các thành viên chủ chốt của nhóm phát triển (Delivery Team)
- Các bên liên quan chính (Major Stakeholders)
CÁCH THỰC HIỆN (HOW)
- Xác định các tính năng của sản phẩm (Product Features) và các User Story, đồng thời ước lượng sơ bộ quy mô của chúng.
- Thực hiện các ước lượng ban đầu ở mức tổng quan (coarse-grained estimates) bằng cách sử dụng các kỹ thuật như:
- Affinity Estimating (Ước lượng theo nhóm tương đồng)
- T-shirt Sizing (Ước lượng theo kích cỡ áo: XS, S, M, L, XL…)
- Story Mapping (Lập bản đồ User Story)
- Product Roadmap (Lộ trình phát triển sản phẩm)
ĐẦU RA (OUTPUTS)
- Một Product Backlog được cập nhật và sắp xếp theo thứ tự ưu tiên, bao gồm:
- Các User Story.
- Các hành động ứng phó rủi ro (Risk Response Actions).
- Các ước lượng tương đối ở mức tổng quan (High-level / Coarse-grained Relative Estimates) cho từng User Story.
- Mục tiêu của bản phát hành (Release Goal), tập trung vào giá trị mang lại cho khách hàng.
- Ngày mục tiêu cho việc phát hành sản phẩm (Target Release Date).