Tóm Tắt
1. Sprint Planning là gì?
Một Sprint mở màn bằng buổi lập kế hoạch Sprint để xác lập tiềm năng và lên kế hoạch chi tiết cụ thể cho những việc làm cần thực thi. Buổi Sprint Planning này sẽ lần lượt vấn đáp những câu hỏi chính :
Mục tiêu của Sprint này là gì?
Sprint này team mình cần chuyển giao cái gì?
Làm sao để team mình đạt được kết quả như mong muốn?
Diễn biến một buổi làm kế hoạch Sprint thường như sau :
1. What/Why: Product Owner trình bày tầm nhìn về sản phẩm, mục tiêu Sprint. Nhóm phát triển hỏi kỹ về các hạng mục cũng như mục tiêu. Tại sao Sprint này có thể mang lại giá trị cho sản phẩm, giá trị đó là gì? Product Goal của sản phẩm là gì? Có gì thay đổi trên thị trường không? Nó có liên hệ gì tới mục tiêu của Sprint tiếp theo?
Bạn đang đọc: Sprint Planning – Lập Kế Hoạch Sprint
2. How: Nhóm phát triển thảo luận, phân tích và dùng kỹ thuật để bẻ nhỏ thành Sprint Backlog, có thể trao đổi với PO.
2. Ai tham gia Sprint Planning?
Toàn bộ nhóm bắt buộc cần tham gia phần thứ nhất (What), xác định Mục tiêu của Sprint bao gồm Product Owner, Scrum Master và Nhóm phát triển. Tuy nhiên nếu Product Owner đã phân quyền và giao cho team quyền tự chủ quyết định việc mình sẽ làm trong mục tiêu ngắn (ví dụ tháng/quý) thì team hoàn toàn chủ động làm được phần này.
Phần thứ hai (How), Product Owner có thể vắng mặt, nhưng luôn cần ở trạng thái sẵn sàng support để làm rõ cho nhóm các hạng mục quan trọng. Nếu không có thể có mặt, có thể trả lời qua online hoặc qua điện thoại, tránh để mất thời gian chờ đợi nhau.
3. Sprint Planning dài bao lâu?
Timebox là yếu tố cực kỳ quan trọng của những buổi họp. Điều quan trọng là tất cả chúng ta có tác dụng và bước tiếp theo cần phải làm gì sau mỗi cuộc họp chứ không phải muốn họp đến khi nào thì họp. Thông thường ,
- Với sprint 1 tháng, buổi kế hoạch Sprint kéo dài 8 tiếng
- Với sprint 2 tuần, buổi kế hoạch Sprint kép dài 4 tiếng
Với team sprint 1 tuần, buổi kế hoạch Sprint thường không lê dài hơn 2 tiếng. Trong đó 1 tiếng dành cho việc xác lập tiềm năng và thời hạn còn lại dành cho việc tìm / trao đổi và xác lập cách triển khai .Với những team mới làm quen với Scrum, những buổi họp tiên phong thường hoảng sợ và hoàn toàn có thể vượt quá Timebox, nên kiểm soát và điều chỉnh và nâng cấp cải tiến trong những buổi tiếp theo .
4. Product Backlog – Đầu vào của Sprint Planning
Không phải cứ đến giờ Sprint Planning, Product Owner hoặc cả team mới xác lập Sprint này làm gì. Thông thường việc tăng trưởng loại sản phẩm có roadmap khá rõ ràng với những milestone đơn cử, tiềm năng đạt được rõ ràng. Điều này được phản ánh trải qua những buổi Định hướng loại sản phẩm, Product Planning và sau đó được Product Owner san sẻ lại với team trải qua công cụ Product Backlog, và đây cũng sẽ là nguồn vào của hoạt động giải trí Sprint Planning .Product Backlog là list những tính năng mong ước của loại sản phẩm. Danh sách được sắp xếp dựa trên độ ưu tiên của từng khuôn khổ. Các khuôn khổ được ưu tiên sẽ được để ở trên, và được nhóm Phát triển ưu tiên pick chọn. Product Backlog trong team Triển khai loại sản phẩm, sẽ thường là những trách nhiệm của những Project người mua. Tùy vào mốc thời hạn đã cam kết với người mua, những trách nhiệm này sẽ được sắp xếp theo những thứ tự ưu tiên độc lạ .Product Backlog hoàn toàn có thể được quản trị trên Google Spreadsheet, trên Trello, hoặc sử dụng những công cụ quản trị source code như Github Project. Tại Haposoft, chúng mình sử dụng Trello cho hoạt động giải trí này .
5. Các bước tiến hành Sprint Planning
5.1. Xác định mục tiêu của Sprint
Product Owner sẽ trình bày mục tiêu mong muốn đạt được trong Sprint này, hoặc team sẽ chủ động nhắc lại các mục tiêu đã được thống nhất với PO từ đầu quý. Nếu cần làm rõ hơn các hạng mục trong Product Backlog, nhóm sẽ trao đổi trực tiếp với PO. Nhưng thông thường, việc làm rõ này đã được thực hiện trước qua các buổi làm mịn Backlog (hay còn gọi là Grooming) .
Thứ tiếp theo cần xem xét để lựa chọn số lượng tiềm năng cho tương thích chính là năng lượng của nhóm. Việc thống kê giám sát năng lượng của nhóm là điều rất quan trọng, vì nếu thống kê giám sát không đúng chuẩn, bạn sẽ nhận nhiều hơn sức mình có hoặc quá ít so với năng lượng của nhóm dẫn đến hiệu suất kém .
Có một lưu ý là nếu 1 ngày các bạn có 8 giờ làm việc, thì thời gian năng suất để mỗi thành viên thực sự làm việc được hiệu quả sẽ chỉ là 5 hoặc 6 giờ. Tiếp theo, hãy nhìn vào lịch cá nhân của mình xem có thành viên nào trong nhóm vướng mắc việc gì trong tuần này không, nếu có hãy chủ động chia sẻ ngay đầu buổi Planning.
5.2. Xác định cách thực hiện mục tiêu của Sprint
Làm thế nào để hoàn thành xong việc làm đã chọn ? Kết quả của phần thao tác chính là Sprint Backlog – bảng việc làm được nhóm Phát triển sử dụng trong suốt Sprint .Đối với mỗi khuôn khổ trong list đã lựa chọn, nhóm sẽ tách thành những việc làm đơn cử. Các việc làm này thường đủ nhỏ để triển khai xong trong vòng một ngày hoặc ít hơn .
Thông thường các task của team sẽ là:
- Thiết kế solution
- Viết testing
- Code
- Viết tài liệu
- Nghiên cứu kỹ thuật/công nghệ mới
- Fix bug
- Họp với team làm BA cho feature mới…
Sau khi xác lập đầu mục việc làm, nhóm sẽ cùng nhau chốt thời hạn và nỗ lực team cần để triển khai xong việc làm đó, hoàn toàn có thể theo thời hạn ( giờ ) hoặc point ( điểm ) .
Thông thường trong 1 team phát triển, chúng mình sẽ có nhiều thành phần developer, tester, BA, nên việc ước lượng cho các task có thể có sự chênh lệch. Đó là lúc chúng mình sẽ dụng Planning Poker để tìm ra con số chung của nhóm.
Sau khi thống kê giám sát khối lượng việc làm đã lựa chọn, nhóm tăng trưởng hoàn toàn có thể dữ thế chủ động nhận thêm hoặc trao đổi với PO để cắt bớt những khuôn khổ .
5.3. Kiểm soát chất lượng bằng định nghĩa hoàn thành DoD
DoD
Product Owner sẽ thường làm việc với các team theo Quý với định hướng Quý, sau đó các team chủ động làm việc trong các Sprint. Việc tham gia Sprint Review cũng không bắt buộc với PO.
Liệu có thuận tiện và bị thiếu chất lượng khi để một nhóm tự đề xuất kiến nghị việc làm dựa trên tiềm năng, rồi review với nhau và dữ thế chủ động đưa ra những phiên bản update ?Có 2 cách để bạn quản trị chất lượng :
- Một là giao nhiệm vụ, rồi kè kè bên cạnh kiểm soát và khi kết quả hoàn thành bạn sẽ check để soi lỗi.
- Cách còn lại là giao nhiệm vụ, hướng dẫn team cách tự tư duy về định nghĩa hoàn thành (thế nào là hoàn thành) một cách cực kỳ chi tiết, team sẽ tự giám sát lẫn nhau và đảm bảo cho chất lượng đầu ra của mình.
Cách thứ 2 này là cách thường được lựa chọn. Chính vì thế, định nghĩa hoàn thành xong lại trở thành một tiêu chuẩn cực kỳ quan trọng của bất kỳ trách nhiệm nào trong Sprint .
Định nghĩa hoàn thành là một danh sách các quy định những công việc cần được thực hiện xong trước khi một hạng mục được công nhận là DONE. Việc nhóm cùng nhau đưa ra định nghĩa hoàn thành cũng giúp mọi người trong nhóm hiểu chung về yêu cầu công việc, ngăn ngừa các mâu thuẫn do hiểu nhầm hoặc không hiểu rõ. Gia tăng tính minh bạch về yêu cầu cũng giúp nhóm tự tổ chức hiệu quả hơn. Chúng mình hay gọi Định nghĩa hoàn thành là DOD tức Definition of Done.
6. Bí kíp để buổi Sprint Planning đạt hiệu quả cao
6.1. Thống nhất giờ Sprint Planning phù hợp
Các team có sự lựa chọn thời hạn Sprint Planning khác nhau, có team thì làm luôn vào chiều thứ 6, có team thì sáng thứ 2 mới làm .Tuy nhiên, theo quan sát :
- Các team tiếp xúc với khách hàng hay có sự thay đổi thường xuyên và công việc cần sự tiếp nối cao thì sẽ thích làm Planning vào chiều thứ 6 để không bị quên tình huống của khách hàng sau 2 ngày cuối tuần.
- Còn các team ít sự biến động, chủ động hơn với mục tiêu công việc của mình sẽ chọn Planning vào đầu tuần.
6.2. Các thành viên trong team rà soát & chuẩn bị các task của bản thân đẩy lên trước và làm rõ
Buổi thao tác sẽ không hề hiệu suất cao nếu đến lúc đó bạn mới bê não vào phòng họp .
Ví dụ giờ planning của team là 15h30, chiều thứ 6 hàng tuần. Khoảng thời gian từ đầu giờ chiều thứ 6 đến buổi họp (2 tiếng trước buổi Planning) là lúc chúng ta sẽ cùng đẩy lên các mục tiêu của cá nhân hoặc chủ động nhìn lại các mục tiêu của team và đưa vào kế hoạch tuần.
6.3. Thực hiện Grooming (làm mịn) thường xuyên
Làm mịn là một kỹ thuật trong việc quản lý Product Backlog. Các hạng mục trong Product Backlog có kích thước khác nhau, mức độ chi tiết khác nhau và thường chúng cần được làm mịn trước khi đi vào sản xuất.
Làm mịn hoàn toàn có thể gồm có việc bẻ nhỏ những khuôn khổ có kích cỡ lớn thành những khuôn khổ nhỏ hơn, càng nhỏ, càng cụ thể thì càng rõ ràng và mịn .
Một nhóm Scrum có thể dành ra 10% thời gian Sprint để ngồi cùng nhau làm mịn Product Backlog cho các phiên tiếp theo.
Việc tư duy công việc từ trước để có sự chuẩn bị và không bị động là bí kíp để các buổi Sprint Planning được hiệu quả cao.
7. Check list kiểm tra lập kế hoạch sprint
- ✓ Buổi lập kế hoạch có diễn ra đúng giờ?
- ✓ Có thành viên nào thiếu không? Lí do vì sao?
- ✓ Product Backlog có sẵn sàng trước buổi lập kế hoạch?
- ✓ PO có sơ kết lại tình hình sản phẩm hiện tại đầu buổi lập kế hoạch?
- ✓ PO có đưa ra mong muốn mục tiêu Sprint đầu buổi lập kế hoạch?
- ✓ Khả năng của Nhóm Phát triển đã được tính?
- ✓ Có những vấn đề, sự kiện nào đặc biệt ảnh hưởng tới khả năng của nhóm không (ví dụ nghỉ hè, thành viên nào có việc riêng)?
- ✓ Nhóm Phát triển và PO có rà soát những hạng mục có thể sẽ phát triển trong Sprint?
- ✓ Những hạng mục có thể sẽ phát triển trong Sprint đã có tiêu chí chấp nhận?
- ✓ Nhóm Phát triển đã phân ra các hạng mục sẽ phát triển thành các công việc đưa vào Sprint Backlog?
- ✓ Các hạng mục trong Sprint Backlog đã được ước lượng?
- ✓ PO có hài lòng với cam kết của Nhóm Phát triển?
Chúc các bạn có hoạt động Sprint Planning hiệu quả nhé!
Tài liệu tham khảo
https://career.magestore.com/post/sprint-planning
https://www.atlassian.com/agile/scrum
https://scrumguides.org/scrum-guide.html#daily-scrum
https://www.scrum.org/resources
Source: https://final-blade.com
Category : Kiến thức Internet
