Trong bài học này, chúng ta sẽ tìm hiểu về các chiến lược và kỹ thuật lập kế hoạch dự án phát triển phần mềm theo nguyên lý Agile.
Điều quan trọng bạn nên nhớ là dự án phải xử lý linh hoạt khi có các thay đổi.
Giới thiệu
Lập kế hoạch cho toàn bộ dự án là một việc khó nhưng sẽ dễ dàng hơn nhiều khi khối lượng công việc được chia thành các việc nhỏ để dễ quản lý.
Việc lập kế hoạch nói chung bao gồm xác định và sắp xếp các đầu việc, gán thời gian và ước tính các đầu việc.
Việc phát hành sản phẩm có 2 mức độ:
- Kế hoạch phát hành (Release plan): được sử dụng để lập kế hoạch cho toàn bộ dự án.
- Kế hoạch vòng lặp (Iteration plan): kế hoạch chia thành các phần nhỏ hơn của dự án, gọi là 1 sprint.
Các kỹ năng trong việc lên kế hoạch:
Work breakdown structure (Cấu trúc phân chia công việc, viết tắt là WBS) là một kỹ thuật thể hiện dự án theo một dạng có thể dễ dàng quan sát. Kỹ thuật này chia công việc ra thành các đầu việc nhỏ hơn.
Các đầu việc sẽ được chia nhỏ đến mức thực sự rõ ràng và có thể gán cho một người thực hiện.
WBS thường được thể hiện dưới dạng danh sách hoặc biểu đồ:
Mục đích sử dụng WBS:
- Xác định các đầu việc cho dự án
- Đánh giá thời gian team dev có thể hoàn thành dự án
- Xác định các rủi ro tiềm năng của dự án
- Bàn luận về các chức năng với khách hàng.
Phần lớn việc lập kế hoạch dự án là giải quyết thời gian và nỗ lực cần thiết để thực hiện.
Chúng ta sẽ sử dụng các thuật ngữ sau:
Estimate: là ước tính về thời gian mà team dev cần để hoàn thành một đầu việc. Ước tính được thể hiện theo một khoảng như là 1-2 giờ, 0.5-1 ngày.
Estimate không thể thương lượng, không nên bao gồm thời gian dư thừa hoặc thêm thời gian ngẫu nhiên, hoặc bị ảnh hưởng bởi các stakeholder khác.
Target: là một điểm cụ thể trong lịch trình dự án cần phải đáp ứng, nó tương tự như hạn chót của công việc. Mốc này thường vào cuối một sprint hoặc ngày phát hành sản phẩm.
Commitment: thời gian đội dev đồng cam kết phát hành sản phẩm, có thể được thương lượng dựa trên estimate và target.
Cách tốt nhất để có cam kết đúng là thảo luận với team dev trước, để có con số chính xác. Sau đó, tiếp tục thảo luận với khách hàng để xác định ngày mục tiêu, từ đó có thể xác định cam kết.
Các kỹ thuật hữu ích để estimate ở cấp độ dự án:
Time box là tạo ra một khung thời gian có giới hạn để xây dựng hoặc để hoàn thành một số đầu việc nhất định. Đây là một kỹ thuật quan trọng khi làm Scrum.
Trong Scrum, Timebox là một Sprint, thường kéo dài 2-4 tuần. Mỗi Sprint bao gồm một lượng nhỏ công việc được giới hạn trong thời gian phát triển ngắn.
Story Point:
Story point thay thế cho estimate.
Story point là một giá trị để xác định mất bao lâu để hoàn thành một phần công việc so với các công việc khác. Story point đo tương đối và không có đơn vị cụ thể, không giống như ước tính thời gian.
Story point sử dụng user story và backlog:
Để sử dụng story point trong một dự án:
- Gán một con số cơ sở lên một user story. Bạn nên chọn một user story dễ để dùng làm con số cơ sở.
- Lấy đó làm cơ sở, gán story point cho các user story còn lại. Nếu một US lớn gấp đôi US đầu tiên thì nên tăng gấp đôi giá trị.
- Sau khi hoàn tất, ta sẽ có một danh sách US có ước tính công việc đều liên quan đến nhau.
Tổng số Story point của một dự án là các story point lẻ được cộng lại.
Điều cực kỳ quan trọng là phải nhớ không coi story point như thời gian. Việc đó sẽ không mang lại lợi ích gì.
Một cách hay để đảm bảo các story point cố định và tương đối là sử dụng dãy Fibonacci – bất kỳ số riêng lẻ nào cũng là tổng của hai số đứng trước nó: 1, 1, 2, 3, 5, 8, 13, 21, v.v.
Kế hoạch phát – Release plan:
Kế hoạch này quyết định những User story nào từ dự án sẽ được hoàn thành và phát hành trong mỗi Sprint. Nó được thực hiện trước khi bất kỳ Sprint nào bắt đầu và ưu tiên các nhiệm vụ dựa trên mức độ quan trọng: Must do > Should do > Could do.
Kỹ thuật lập kế hoạch ở cấp độ đầu việc và lập kế hoạch vòng lặp:
Có nhiều cách để tạo estimate cho các task. Tất cả đều dựa trên dữ liệu trước đó.
Tuy nhiên hãy nhớ rằng ước tính là những con số không thể thương lượng được.
- Dựa vào kinh nghiệm trước đó với dự án tướng tự để estimate.
- Dùng nhiều estimate từ các dev có kinh nghiệm để có được estimate chuẩn nhất.
- Chia nhỏ thành phần công việc rồi estimate từng phần nhỏ.
PM nên để ý về các quan hệ phụ thuộc của các đầu việc khi lên kế hoạch dự án:
- Start-Start: Task 1 phải bắt đầu trước Task 2 nhưng có thể kết thúc bất cứ lúc nào.
- Start-Finish: Task 1 phải bắt đầu trước khi Task 2 kết thúc
- Finish-Start: Task 1 phải kết thúc trước khi Task 2 bắt đầu (phổ biến nhất)
- Finish-Finish: Task 1 phải kết thúc trước khi task 2 kết thúc.
Kế hoạch vòng lặp (Interation Planning):
Ta có thể hiểu giống như lên kê hoạch cho một Sprint, tập trung chi tiết vào quản lý các đầu việc hơn.
Kế hoạch này được lập trong các buổi họp Sprint Planning và sẽ quyết định cho team dev sẽ làm gì trong một Sprint, xác định được Sprint Goal là mục tiêu của 1 và báo cáo lại sô thời gian sử dụng/story point trong sprint trước đó .
Các rủi ro cần chú ý trong phát triển phần mềm:
Patterns trong Tiếng Anh được hiểu là các việc lặp lại, hoặc một quy trình làm gì đó được lặp lại nhiều lần.
Đối với các rủi ro thất bại trong dự án cũng thường xuất hiện nhiều lần nên được gọi là anti-pattern.
Các PM cần nhận thức được các anti-pattern thường xảy ra trong dự án để tránh các hậu quả nghiêm trong dẫn đến sự thất bại của dự án.
Sau đây là một số anti-pattern theo nhóm:
- Tư duy tập thể (Groupthink): mọi người trong team thường theo một ý kiến chung chứ không cân nhắc ý kiến riêng của mình.
Để tránh hiện tượng này, ta cần phải sắp xếp môi trường bàn luận được mở mang, ủng hộ các ý kiến mang tính chất xây dựng, hoặc chia nhỏ team ra thành các nhóm nhỏ rồi lấy ý kiến theo từng nhóm. - Làm phức tạp hóa vấn đề: (Overengineering): khi sản phẩm trở nên phức tạp hơn cần thiết, bao gồm các chức năng không sử dụng đến khiến cho người dùng cảm thấy khó hiểu trong khi sử dụng.
Với vấn đề này, team dev phải hiểu rõ ràng nhu cầu của sản phẩm thay vì những chức năng khách hàng muốn có trong sản phẩm. - Con Trâu đi trước cái cày (Cart Before the Horse): anti pattern chỉ hiện tượng tập trung vào phần mà nên làm sau trong dự án thay vì nhưng phần nền xử lý trước. Ví dụ như khi lập trình viên tự gán mình làm các đầu việc không ảnh hưởng trực tiếp đến các tính năng hiện tại để chuẩn bị trước cho các công việc sau này.
Team cần rõ ràng về mức độ ưu tiên của các công việc trong dự án để tránh được antipattern này.
Anti pattern theo cá nhân trong quản lý:
- Quản lý vi mô (micromanagement): Khi một người quản lý cực đoan trong việc kiểm soát liên tục team của mình, họ muốn tham gia từng chi tiết của dự án dù nhỏ đến đâu.
- Nóng tính (Loose cannon): anti pattern này xảy ra khi một người thường đưa ra những quyết định quan trọng về dự án mà không hỏi ý kiến những người còn lại trong team, điều này rất bất cẩn và có thể tạo thêm công việc không cần thiết cho người khác.
Các rủi ro khác :
- Liên quan đến scope
- Liên quan đến công nghệ:
- Liên quan đến khách hàng hoặc các bên liên quan
- Liên quan đến từng cá nhân
- Liên quan đến pháp lý, bảo vệ, mất tài sản ….
Bài tiếp theo: Bài 5: Giới thiệu về kỹ thuật đánh giá và số liệu thống kê để cải thiện phần mềm