Giống như các team hoạt động trong các công ty công nghệ, team tôi cũng sử dụng Scrum. Ban đầu, Scrum chỉ cung cấp cho team những quy tắc cũng như cách thức để tổ chức các quy trình. Nhưng thông qua nhiều lần thử và sai, team tôi bắt đầu thiết lập ra những cách thức mới khiến cho các Sprint hoạt động hiệu quả hơn và “sát” hơn với nhu cầu của công ty và nguồn lực của mình. Nhờ những cách thức này mà quy trình hoạt động của chúng tôi trở nên “mượt mà” hơn, sản phẩm hoàn thành đúng hạn và rất ít thời gian bị lãng phí (điều này vẫn xảy ra nhưng đã được hạn chế). Đơn cử như vấn đề mơ hồ trong Sprint planning khiến developers bắt đầu công việc của mình nhưng tester thì “ngồi không” trong giai đoạn đầu vì chưa có gì để test, chúng tôi đã ngăn chặn được việc đó.
Tips 1: Sử dụng các công cụ hỗ trợ dự đoán khi triển khai Scrum
Đầu tiên, tôi muốn giới thiệu đến các bạn một công cụ (tool) rất quen thuộc nhưng lại hoạt động rất hiệu quả khi kết hợp với Scrum, tạo nên một bộ đôi “song sát”: JIRA!
Mô hình Scrum có rất nhiều điểm mạnh như “nhanh”, “gọn” và nếu kết hợp với Jira, nó sẽ có thể tăng thêm tính “dự đoán được” (predictability) do nền tảng Jira hỗ trợ team theo dõi toàn bộ hoạt động và cung cấp những báo cáo trực quan. Các báo cáo này giúp cho team dễ dàng “truy vết” các công việc còn tồn đọng, nắm rõ các công việc đã hoàn thành như thế nào và dự đoán được sản phẩm khi nào hoàn thiện. Nó cũng giúp team dễ kiểm soát chất lượng và cập nhật được các plan về meetings, đảm bảo các thành viên có được thông tin như nhau (Để biết thêm truyền thông trong dự án làm thế nào hiệu quả, bạn có thể xem tại đây.
Khi chúng ta sử dụng Scrum, dự án sẽ được chia nhỏ và quản lý ở từng Sprint. Điều này giúp team tập trung hơn vì Sprint có lượng thời gian ngắn và mọi người dễ dàng kiểm soát cũng như đánh giá được công việc trong khoảng thời gian ấy. Nó giống như bạn thực hiện thử thách chạy 50 km trong 10 ngày sẽ hiệu quả hơn thực hiện chạy 500 km trong 100 ngày. Thời gian càng lâu, chúng ta sẽ dễ bị trì hoãn và thiếu tập trung. Hiện tượng này cũng giống với Parkinson’s Law, khi công việc có xu hướng kéo dài theo thời hạn hoàn tất và “nước đến chân mới nhảy”, rủi ro dự án sẽ tăng cao.
Vì thế, chúng ta cần phải giữ các hoạt động chạy liên tục và có thể dự đoán được trong thời gian tương đối để không cảm thấy “ngán” và “overload”. Jira hỗ trợ việc đó bằng cách “đếm” từng công việc đã hoàn thành trong Backlog và tính toán luôn Fix versions – một dạng events nhỏ như first test version, second version, product release,…Trong backlog thì Jira có danh sách các tasks và nếu đã được ước lượng (estimated) bằng story point, Jira có thể đưa ra số sprint cần thiết cho dự án dựa trên khai báo về working speed. Vì lẽ đó, chúng ta có thể cung cấp cho khách hàng ước lượng tương đối chính xác về ngân sách cũng như deadline trong giai đoạn sơ khởi của dự án.
Tips 2: Thiết lập dòng chảy công việc liên tục
Chúng ta tiếp tục đến với vấn đề xây dựng các Sprints. Để không có khoảng “gap” giữa các Sprints nhưng vẫn không khiến mọi thứ trở nên “áp lực” hoặc “quá tải” là một vấn đề khó. Một số nơi khi công việc đã kết thúc nhưng chưa đến thời điểm kết thúc Sprint, Manager thường “đẩy” thêm task từ Backlog khiến cho định nghĩa Sprint ban đầu không còn giá trị. Tuy nhiên, không ai muốn kết thúc Sprint và có một khoảng “gap” ở giữa vì nó sẽ khiến cho team bị “mất đà”. Để thực hiện Sprint liên tục, chúng ta cần nhìn lại những tính chất của Sprint.
Đầu tiên, Sprint là một khung thời gian được xác định (fixed time-box) nhằm để team Scrum tiến hành tất cả các hoạt động cần thiết để sản xuất được một phần giao phẩm có khả năng chuyển giao được. Thường khung thời gian này hợp lý là kéo dài trong 10 ngày (2 tuần làm việc). Bởi vì đây là khoảng thời gian không quá dài để hoàn tất một phần giao phẩm (working increment) nhưng cũng vừa đủ ngắn để có thể dự đoán và kiểm soát được đối với team.
Từ ngày 01 đến ngày thứ 07 là khoảng thời gian phát triển các chức năng, khi đó backend, frontend và QA sẽ hoạt động chung với nhau trên các nhiệm vụ trong Backlog. Trong lúc đó, nếu có vấn đề nào liên quan đến quản lý hoặc các yêu cầu khẩn của khách hàng, dev team có thể hotfix.
Tuy nhiên, trong thực tế chúng ta thường gặp vấn đề khi công việc của một người bị “đứng” bởi một người khác (ví dụ QA không thể bắt đầu test nếu như engineers chưa hoàn thành xong phần của họ). Chính vì thế trong giai đoạn planning, chúng ta cần phải cân nhắc đến trường hợp này và giảm thiểu khả năng xảy ra của nó. Một cách để khắc phục tình trạng này là sử dụng các khoảng thời gian trống cho việc “grooming”. Ví dụ: frontend chỉ có thể bắt đầu làm việc khi một phần công việc của backend được hoàn thành. Nhưng trong khi chờ backend code, frontend có thể thực hiện “grooming”. Cũng như vậy sau khi backend đã hoàn thành xong phần việc của mình và đang chờ người khác, họ cũng có thể bắt đầu “grooming”.Sau đó, đến ngày cuối của sprint, team members có thể báo cáo những công việc mà họ đã “groomed”. Như vậy, team sẽ sẵn sàng cho một Sprint mới tốt hơn và không còn phải tốn cả ngày để grooming và planning.
Từ ngày 08 đến ngày thứ 09 là thời gian cho việc testing cũng như các vấn đề technical khác. Đây cũng có thể là khoảng thời gian “Black-out” hoặc “code-freeze” khi mọi vấn đề về thay đổi system được dừng lại để tập trung vào Release. Trong 02 ngày này, team dev sẽ tập trung:
1. Thực hiện các test cases của QA
2. Thực hiện automation test hoặc cải thiện code (code refactoring) nếu đủ nguồn lực hoặc đang trong giai đoạn nâng cấp giao phẩm.
Các automation test sẽ kiểm tra sản phẩm nhanh chóng hơn “manual” rất nhiều, tuy nhiên không phải test nào cũng có thể kiểm tra bằng automation. Mặc dù vậy, trong đa số trường hợp, automating test trong giai đoạn đầu phát triển sản phẩm vẫn được đề cao nhờ vào tính hữu hiệu của nó. Nếu dự án có thể automated testing sớm, thì giai đoạn testing có thể chỉ mất một ngày là ngày thứ 09. Như vậy team dev có thể thêm một ngày để phát triển sản phẩm (thay vì từ ngày 01 đến ngày 07 thì sẽ từ ngày 01 đến ngày 08). Lúc này QA sẽ bận rộn hơn nhưng các thành viên còn lại có thể “chăm sóc’ thêm những vấn đề kĩ thuật như review các file cũ, dọn sach dữ liệu, sắp xếp folder và tiến đến cải thiện workflow và structure của code (dĩ nhiên là không thay đổi code, chỉ là “tút” lại một chút).
Khi đến ngày 10, gần như mọi công việc trong Sprint đã hoàn thành. Mọi thứ đã được lên server, test chức năng, chỉnh sửa, triển khai (deployment),…Giao phẩm được demo và tập trung thêm vào những khía cạnh business với khách hàng. Ngoài ra, để tận dụng ngày 10 này một cách hữu hiệu, chúng ta có thể thực hiện hoạt động retrospective, báo cáo và planning cho Sprint tiếp theo. Có thể nói ngày 10 là “phút giây nhìn lại” cho cả team về những gì đã làm và chuẩn bị cho một Sprint mới.
Tips “nhỏ” nhưng hiệu quả “to”:
“ Nếu các thành viên đều nghỉ vào ngày Thứ 7 và Chủ nhật thì đừng để ngày 10 này rơi vào ngày thứ 6, vì nếu triển khai giải pháp nhưng không có người giám sát (supervise) tận 02 ngày tiếp theo thì vô cùng nguy hiểm. Cần có thành viên hỗ trợ giải pháp một cách tập trung khi launching.
Như vậy thì Sprint “mới” nên bắt đầu vào ngày thứ 4. Chúng ta sẽ “freeze code” vào tối thứ 5, dùng ngày thứ 6 và thứ 2 cho việc testing, xử lý các technical stuffs và demo giải pháp vào thứ 3 (thứ 2 luôn là thời điểm khó tập trung với các stakeholder) và đây cũng là khung thời gian gần như tốt nhất cho một Sprint hiệu quả.”
Ngoài ra, cách thức này còn có tác dụng thu hẹp thời gian “chết” trong dự án. Thông thường thì vấn đề thời gian “chết” trong dự án sẽ xuất hiện khi team “lớn dần”. Một khi team có hơn 10 thành viên, sẽ không thể giao task cho tất cả mọi người sao cho phù hợp với năng lực của họ. Kết quả sẽ trở nên hỗn loạn. Lúc này, việc tạo nên một dòng chảy công việc liên tục như trên là một cách thức hiệu quả để hạn chế các vấn đề xảy ra và duy trì “lửa” trong team. Bên cạnh đó, chúng ta còn phải tập trung vào 2 vấn đề:
1) Các yêu cầu về giao phẩm và khía cạnh kinh doanh cần được làm rõ và thống nhất, tránh việc team không thể cam kết được cho Sprint
2) Team cần phải chuẩn bị và hiểu rõ các cốt lõi về sản phẩm trước khi bắt đầu. Một khi đã bắt tay vào thực hiện, sẽ có rất ít thời gian để bắt đầu tìm hiểu những vấn đề liên quan.
Tips 3: Tận dụng các Scrum events và mindset về planning
Scrum được biết đến như một phương pháp quản lý dự án với các events hỗ trợ có tính tương tác cao và thường xuyên. Các events này tập trung giúp cho các thành viên “on the same page” và kịp thời hỗ trợ lẫn nhau. Việc tận dụng các events này rất quan trọng và thường là nhiệm vụ của Scrum Master/ Product owner nhưng để tăng được độ hiệu quả trong việc lên kế hoạch, đội ngũ dev cũng cần có mindset về mặt planning trong công việc.
Các developers cần hiểu được công việc của họ không chỉ có code và test, họ còn là những “kiến trúc sư” và điều quan trọng nhất vẫn là thời gian suy nghĩ để tạo nên một sản phẩm tốt chứ không phải là thời gian code.
Thông thường thì trong một ngày làm việc “8 giờ tiêu chuẩn”, một developer sẽ dành 5.5 tiếng cho việc coding, 2.5 tiếng cho các daily tasks, grooming, trao đổi với khách hàng cũng như hotfix các lỗi hoặc họp hành.
Có một sự thật là, những vấn đề nhỏ như fix bug, hoặc tìm hiểu về task kĩ lưỡng hơn thường không được coi trọng khi thực hiện planning. Bởi vì chúng xảy ra một cách ngẫu nhiên nhưng nếu bạn không ước lượng để đưa vào planning, các developer sẽ tốn rất nhiều thời gian và không thể hoàn thành công việc mà họ chỉ có 8 tiếng để hoàn thành.
Bạn có thể sử dụng các hình thức “Brainstorming” để tìm ra hướng làm việc tốt hơn cho team cũng như ước lượng được những vấn đề xảy ra khi thực hiện công việc để đưa vào planning. Ngoài ra, trong mô hình Scrum có 2 hoạt động “na ná” nhau mà bạn cần phân biệt đó là: “Grooming” và “Planning”.
Trong hoạt động Planning, thường chúng ta sẽ có “outcomes” là một danh sách các tasks cho team. Danh sách này thường không cần cho toàn bộ dự án, nhưng ít nhất cũng phải cho từ 01 đến 02 sprints.
Grooming là hoạt động sâu hơn đi vào từng task nằm trên backlog của Jira. Để sử dụng thời gian hiệu quả, từng team member sẽ “pick” tasks trong một tuần trước khi bắt đầu Sprint, để hỏi client những vấn đề quan trọng và dành ra thời gian hợp lí để có thể nhận được các câu trả lời. Sau đó, khi đến sprint planning, mọi người sẽ báo cáo những gì họ tìm ra cũng như chia sẻ ý tưởng với mọi người làm cách nào để thực hiện công việc cụ thể. Điều này sẽ giúp cho team hình dung và hiểu hơn cả về hệ thống lẫn công việc của họ. Ngay khi Sprint bắt đầu, gần như các task đều được làm rõ và team đã hiểu về nó.
Chính vì vậy, grooming rất cần thiết và hiệu quả hơn so với chỉ thực hiện planning một cách truyền thống, khi tất cả thành viên cùng ngồi lại và cố gắng lên kế hoạch cho sprint sắp tới trong khi họ thật sự thiếu thông tin và chưa hiểu rõ các tasks. Bên cạnh đó, đôi khi sẽ chỉ có ít thành viên tham gia tích cực và tìm thêm thông tin, một số khác gần như sẽ thụ động vì các vấn đề nằm ngoài phạm vi của họ. Thực hiện grooming một cách khéo léo không chỉ giúp mọi thành viên gắn kết trong quá trình planning mà còn giảm thiểu thời gian, giúp cho các Sprints gần như được thực hiện liên tục mà không có khoảng “gap” nào.
Bonus Tips: Thực hiện các công việc song song
Như đã đề cập trong phần đầu bài viết, có một vấn đề thường xảy ra trong các team công nghệ là QA thường bị “ép” phải “catch up” với team, trong khi họ chỉ có thể tập trung testing khi backend và frontend đã xong công việc. Để xử lý vấn đề này một cách hiệu quả, chúng ta cần thực hiện song song các công việc.
Khi QA bắt đầu test giao phẩm, thì developers cần hoàn thành các technical stuff khác hoặc dành thời gian để automation. Và trong khi các developers thực hiện công việc của họ vào ngày 01, QA có thể kiểm tra những technical stuff đã thực hiện trước đó hoặc grooming. Và đến giai đoạn phát triển sản phẩm tiếp theo thì mọi thứ đã sẵn sàng.
Như vậy chúng ta đã cùng nhau tìm hiểu qua những “mẹo vặt” để sắp xếp công việc và chuẩn bị cho Sprint Planning tốt hơn. Hi vọng các bạn sẽ đạt được hiệu quả trong công việc của mình.
Đấu tranh với các Sprint goal
Cải thiện phản hồi trong Sprint reviews
21 mô hình Sprint Retrospective sai lầm đang cản trở các Scrum team
