Thông thường các nhóm sẽ có khả năng lên kế hoạch và kiểm soát thời gian của mình ở mức trung bình. Họ có khả năng sẽ nói những câu kiểu như “chúng tôi sẽ làm những việc này ở Sprint tiếp theo” và một cách nào đó họ có một kỳ vọng (cực kỳ hợp lý) rằng điều này sẽ xảy ra.
Những nhóm như vậy chúng tôi gặp rất nhiều trong các tư liệu về Scrum. Các nguồn tài liệu Scrum khuyên rằng chúng ta nên lập kế hoạch Sprint và thay đổi nó.
Nhưng các nhóm nên làm gì khi Sprint không cho phép có bất kỳ sự thay đổi nào?
Với chủ đề này tôi muốn tập trung vào hai nhóm làm việc khác nhau:
Việc tạo ra một ngưỡng an toàn ở mức vừa phải sẽ giúp ích rất nhiều cho các nhóm. Điều cơ bản nhất cần phải nhớ, các nhóm không nên tự cho rằng họ có thể thay đổi nhiều trong Sprint đó. Ví dụ, một nhóm sẽ muốn rời khỏi phòng trong lúc đang lập kế hoạch cho một Sprint với những lý do như sau:
Còn có rất nhiều ví dụ khác tuỳ thuộc vào môi trường làm việc của nhóm. Bạn sẽ muốn đặt một ngưỡng cao cho những việc có thể tạo ra sự gián đoạn trong một Sprint. Các nhóm phát triển làm việc rất tốt khi họ có ít khoảng thời gian bị gián đoạn.
Để làm việc theo cách đó, tất cả những gì một nhóm cần làm là để lại một chút thời gian dự phòng khi lập kế hoạch Sprint. Hãy cùng xem cách thực hiện điều này.
Tôi nghĩ một Sprint cần có 3 thành phần sau: corporate overhead (thời gian cho vận hành/hành chính), plannable time (thời gian dự tính trong kế hoạch) và unplanned time (thời gian cho những việc ngoài kế hoạch).
Corporate overhead có thể hiểu là khoảng thời gian dành cho các hoạt động thông thường của doanh nghiệp như các cuộc họp, trả lời email từ những dự án trước, tham dự khóa huấn luyện nhân sự,… Mặc dù đó là những hoạt động cần thiết của doanh nghiệp, nhưng ở nhiều tổ chức, chúng tốn rất nhiều thời gian. Tôi cũng xếp các cuộc họp Scrum (Lập kế hoạch Sprint, Scrum Hằng ngày,…) vào mục corporate overhead.
Plannable time là thời gian nằm trong dự tính của kế hoạch, cũng chính là điều thứ hai phải có trong một Sprint. Đây chính là quãng thời gian thuộc về nhóm.
Với khoảng thời gian trống còn lại của Sprint, chúng ta sẽ không muốn lấp đầy thời gian bằng thời gian dự kiến. Lúc này nhóm cần nhận thức được sự cần thiết để thêm vào đó thời gian cho những việc phát sinh (hay unplanned time).
Thường thời gian phát sinh từ các việc như:
Cách phân loại và phân chia tỷ lệ thời gian hợp lý trong mỗi sprint
Tôi thường hay được hỏi về tỉ lệ phù hợp giữa 3 thành phần thời gian vừa được nêu ở trên. Không có một đáp án chính xác cho câu hỏi này. Nhưng tôi có thể chỉ cho bạn cách để tìm ra câu trả lời.
Sau mỗi Sprint, hãy so sánh thời gian phát sinh (unplanned time) thực sự của nhóm với thời gian phát sinh (unplanned time) mà nhóm cần/dự tính cho Sprint đó. Sau đó có thể điều chỉnh tăng hoặc giảm cho Sprint tiếp theo. Chúng ta cần biết rằng không có một đáp án hoàn hảo cho việc này.
Thay vì đi tìm một tỉ lệ chính xác, đây chính là một trò chơi của những giá trị trung bình. Nhóm cần dành một khoảng thời gian phù hợp cho những nhiệm vụ ngoài dự kiến ở mức trung bình. Sẽ có trường hợp một vài Sprint sẽ có nhiều nhiệm vụ phát sinh hơn dự kiến, trường hợp còn lại sẽ có ít hơn.
Ở trường hợp sau, nhóm cần tiếp tục các công việc của mình, do đó, nhóm đã được chuẩn bị cho tình huống có nhiều nhiệm vụ phát sinh hơn xảy ra.
Những lời khuyên ở trên sẽ phù hợp nhất với phần lớn nhóm Agile nhưng thường là những nhóm có mức độ gián đoạn vừa phải. Tuy nhiên, một vài nhóm lại có xu hướng bị gián đoạn cao.
Một lần nữa, tôi muốn tránh việc đặt những con số tỷ lệ thực, nhưng tôi sẽ mô tả một tình huống khi lượng thời gian phát sinh (unplanned time) trở lên lớn hơn so với lượng thời gian đã dự tính.
Thực ra tôi muốn nói về những trường hợp mà thời gian phát sinh chiếm tỷ lệ lớn nhất so với các thành phần còn lại. Những nhóm như vậy có xu hướng bị gián đoạn cao.
Những nhóm này vẫn muốn dành không gian cho các công việc phát sinh trong các Sprint của họ. Nhưng có một vài điều cần cân nhắc nếu như bạn đang ở trong một nhóm có tỉ lệ gián đoạn cao.
Đầu tiên, bạn sẽ muốn điều chỉnh thời gian của mỗi Sprint. Lựa chọn thứ nhất là tạo ra một Sprint dài. Tăng thời lượng của Sprint có ưu điểm đó là tỉ lệ gián đoạn sẽ dễ đoán hơn bởi biến số sẽ khác đi từ Sprint này sang Sprint khác.
Để dễ hình dung, bạn có thể tưởng tượng khi chọn Sprint một năm (đừng làm như vậy!). Với những Sprint dài như vậy, sự biến động mà một nhóm gặp phải ở những Sprint ngắn hơn sẽ biến mất. Có một điều chắc chắn rằng năm đó (Sprint này) sẽ có nhiều gián đoạn hơn năm trước (Sprint trước), nhưng với một thời gian dài như vậy thì nhóm có đủ thời gian để khắc phục bất cứ sự biến động quá lớn nào xảy ra.
Lựa chọn thứ hai đó là chọn những Sprint ngắn, chẳng hạn Sprint 1-tuần và chấp nhận những rủi ro khó lường. Bạn sẽ khó xoa dịu cấp trên bằng những câu như “chúng tôi sẽ xong việc này” bằng một thời gian đã được giao, nhưng tôi thấy lựa chọn này đáng để đánh đổi.
Điều thứ hai cần lưu ý, các nhóm bị điều hướng bởi sự gián đoạn nên biến việc lập kế hoạch Sprint thành một hoạt động “không tốn công sức”.
Lập kế hoạch Sprint nên là hoạt động tốn ít công sức và trong kế hoạch phải có một vài công việc dễ dàng thực hiện mà nhóm nghĩ họ có thể thực hiện ngay vào tuần tới. 15 -30 phút là khoảng thời gian nỗ lực tối thiểu dành cho việc lập kế hoạch Sprint.
Để dễ hình dung hơn, chúng ta hãy so sánh việc lập kế hoạch Sprint với lập kế hoạch cho một buổi tiệc. Hãy vẽ ra hai đầu của một đoạn thẳng. Ở đầu bên này là các công việc mang tính “nghiêm túc”, ví dụ như chuẩn bị khu vực lễ tân của một đám cưới. Ở đầu kia của dải công việc, đó là kế hoạch “dễ nhằn” như mời bạn bè tới nhà và chơi game trên TV chẳng hạn. Để lên kế hoạch cho việc này, tôi sẽ cần kiểm tra tủ lạnh, bia và đặt một chiếc pizza. Trên đây là hai mức độ khác nhau của việc lên kế hoạch cho một bữa tiệc.
Lựa chọn thứ hai sẽ phù hợp cho việc lập kế hoạch Sprint ở những nhóm có xu hướng gián đoạn cao với các tiêu chí: Nhanh, đơn giản và vừa đủ để thành công.
Tác giả: Mike Cohn
Một số cách lập kế hoạch Sprint
Khóa học Quản trị dự án Agile (Agile Project Management) được xây dựng dựa trên khung kiến thức PMI-ACP của Project Management Institute, Scrum Framework trong quản trị dự án, cung cấp kiến thức, các phương pháp và công cụ thực hành về quản trị dự án theo Agile một cách bài bản, hệ thống, giúp các cá nhân, doanh nghiệp hiểu đúng và làm chuẩn ngay từ đầu.
Sau khóa học, bạn có thể:
Bài viết liên quan:
