Câu hỏi:
Làm sản phẩm nó nên áp dụng Scrum không?

Vấn đề gặp phải:

Tình hình là công ty mình đang chuyển đổi sang mô hình scrum cho việc phát triển sản phẩm. Nó khá là khó khăn khi mà các tính năng phải chia nhỏ hết mức để có thể hoàn thành Sprint Goal. Nhưng chính vì chia nhỏ ra như vậy mà End User không được có trải nghiệm tốt nhất khi tính năng không hoàn thiện 100% (vì chia nhỏ cho từng sprint). 2 tuần để làm 1 số tính năng mà còn phải fix production bug cũ + thêm không đánh giá được hết ảnh hưởng nền chuyện không hoàn thành Sprint Goal là chuyện thường xảy ra. Có cách nào khắc phục được không.

2 nữa là bản thân mình thấy nếu không tính năng không hoàn thiện mà đã đưa tới khách hàng thì tỷ lệ khách không lựa chọn sử dụng là cao với trải nghiệm lần đầu mà team không để tý tới điều đó thì mà chỉ nghĩ tới có sản phẩm để sale với KH thôi thì cũng không ổn mà 1 designer không đủ tiếng nói. Vậy có cách nào để có lý do thuyết phục hơn không hay mình suy nghĩ vậy là chưa đúng.

Trả lời:

Dù bạn làm gì, Agile (hay Scrum) sẽ giúp được bạn.

Agile giúp tổ chức hay đội nhóm của bạn linh hoạt và chủ động hơn trong việc tiếp cận và giải quyết vấn đề. Mọi đội nhóm với tinh thần và cách làm việc như trên, bạn sẽ đồng ý với tôi nó sẽ “tốt” hơn phiên bản hiện tại của đội nhóm bạn đang có đúng không?

Vậy tại sao lại không Agile (hay Scrum)?

Trở lại vấn đề của bạn.

1. Tính năng chia nhỏ và End user không có sản phẩm hoàn thiện để sử dụng sau mỗi sprint.
2. Sprint Goal thường không đạt được, và thường xuyên xảy ra.
3. Đưa sản phẩm chưa hoàn thiện tới khách hàng.

Hãy luôn nhớ rằng, releaseable (hay phần tăng trưởng được) không nhất thiết phải release ngay lập tức. Nó có thể đợi tới sprint sau, khi tích hợp đủ mới thực hiện release. Việc release không giới hạn (bắt buộc) khi bạn kết thúc sprint (tất nhiên team bạn có thể làm điều này nếu tính năng đó thực sự hay ho và “đủ” hoàn thiện để release).

Vấn đề thứ 2 là câu hỏi sẽ nhiều nhóm mới tiếp cận Scrum sẽ quan tâm. Sprint Goal không hoàn thành sẽ do nhiều nguyên nhân, dựa trên follow của Scrum, mình xin note một vài ý kiến:

• Sprint Goal chưa thực tế. Nó quá nhiều US, có lẽ vậy.
• Nhóm đang chưa thực sự tập trung vào Goal.
• Có nhiều issue chen ngang trong sprint (PO có một chút điều chỉnh – SM chưa follow được, team chỉ quan tâm tới task mà bỏ quên sprint goal).
• Plan chưa thực sự hợp lý: dựa trên các sprint trước, việc lập kế hoạch cho sprint sau là quan trọng, nếu team bạn liên tục fail sprint goal, hãy hỏi SM sao lại thế. Nếu bạn là SM hãy tự hỏi bản thân và xem lại các số liệu để nhìn nhận vấn đề.

Vấn đề tiếp theo, hãy follow PO để cùng thảo luận. Dù đề cao việc tổ chức đội nhóm, nhưng Scrum đề xuất 3 vai trò, trong đó PO là “chủ” thực sự của sản phẩm. Chỉ anh ấy mới biết tính năng release phục vụ việc gì. Và tại sao cần release một tính năng chưa thực sự hoàn hảo. Mọi thành viên trong development team nên quan tâm tới sprint goal nhiều hơn việc release khi nào và release cái gì. Tất nhiên bạn có trách nhiệm quan tâm tới đứa con tinh thần của mình, nhưng bằng cách hãy trao đổi nếu thấy điều đó có vấn đề. PO sẽ vui vẻ lắng nghe góp ý của bạn, vì dù sao, bạn cũng là người tạo ra sản phẩm – và biết đâu đấy là một khách hàng khó tính muốn góp ý cho sự phát triển của doanh nghiệp?

Quản lý rủi ro trong dự án Agile (Scrum) là câu hỏi nhiều người gặp phải trong quá trình tìm hiểu về Agile và Scrum. Ở bài viết này mình sẽ chia sẻ về nội dung này để mọi người có thêm góc nhìn.

1. Đặc điểm quản lý rủi ro trong dự án Agile/Scrum.
2. Thực hành quản lý rủi ro trong Agile.
3. Có thể sử dụng 2 phương pháp quản lý rủi ro cùng nhau không.
4. Tổng kết.

Phần 1: Đặc điểm của quản lý rủi ro trong dự án áp dụng Agile và Scrum

Đầu tiên, xin quay lại với tuyên ngôn Agile:

Cá nhân và tương tác hơn là quy trình và công cụ.
Phần mềm chạy tốt hơn là tài liệu đầy đủ.
Cộng tác với khách hàng hơn là đàm phán hợp đồng.
Phản hồi với thay đổi hơn là tuân theo kế hoạch.
Mặc dù những điều ở bên phải vẫn còn giá trị, nhưng chúng tôi đề cao những điều ở bên trái.

Tuyên ngôn Agile giúp tập trung vào con người và đội nhóm, sản phẩm, việc tương tác với khách hàng, và sự “linh hoạt” khi thích nghi nhanh chóng với các thay đổi. Mang trong mình triết lý Agile, Scrum framework thể hiện việc giảm thiểu rủi ro dự án thông qua các đặc điểm:

1. Tính minh bạch về thông tin: Scrum có tôn chỉ minh bạch về mọi thông tin, các công việc đang làm, các vấn đề của đội nhóm, các vấn đề kĩ thuật…để chúng ta có thể sớm thấy rủi ro.

2. Tương tác đội nhóm: Thông qua các sự kiện, Scrum giúp nhóm tương tác tích cực dần theo thời gian, từ đó khai thác kiến thức của tập thể và giúp sớm phát hiện nhiều rủi ro hơn.

3. Hợp tác với khách hàng: Suốt vòng đời của sản phẩm, sau mỗi sprint từ 1-4 tuần, khách hàng cùng tham gia với đội nhóm để theo dõi tiến trình của sản phẩm. Điều này giúp dự án giảm thiểu rủi ro từ phía khách hàng.

Phần 2: Quản lý rủi ro trong dự án Agile/Scrum diễn ra như thế nào?

Tiếp cận dự án theo phương pháp Agile giúp nhóm phát triển và khách hàng đồng bộ với nhau về nhu cầu của sản phẩm. Nhóm hiểu rõ, và hiểu đúng những gì mà khách hàng mong muốn, điều này giúp hạn chế rủi ro giao nhầm sản phẩm (release những thứ nhóm cho là đúng nhưng khách hàng không cần). Ngoài ra việc thấu hiểu giá trị sản phẩm với khách hàng cũng giúp nhóm có thêm nhiều trách nhiệm và hỗ trợ cho sản phẩm.

Scrum cho phép nhóm thực hành lập kế hoạch dựa trên lịch sử, điều này giúp giảm thiểu rủi ro ước tính (thay cho cách làm thông thường, sau khi estimate, nhóm sẽ buffer thêm 20-40% thời gian làm). Thay vì vậy Scrum khuyến khích nhóm nhìn lại quá trình làm việc trong các sprint và đưa ra ước tính dựa trên kinh nghiệm và năng lực thực sự của nhóm. Từ đó các bên liên quan có trách nhiệm sẽ minh bạch được thông tin và đưa ra các quyết định kịp thời. Ngoài ra khi lập kế hoạch, nhóm phát triển luôn có cơ hội lập kế hoạch công việc ở cấp độ tính năng, điều này khiến nhóm có góc nhìn rộng hơn để đánh giá các rủi ro tiềm ẩn khi tích hợp vào sản phẩm.

Nhiều nhóm không làm Scrum hay Agile nhưng vẫn thực hiện Daily Meeting, với cá nhân mình thì không có đúng hoặc sai, chỉ là nó có phù hợp cho nhóm – hay tổ chức của bạn không mà thôi. Câu hỏi là nếu Daily Meeting không có bất kì lợi ích nào, vì sao mọi người lại áp dụng nó, và dường như nó còn đang trở thành phong trào trong các công ty làm phần mềm? Bàn luận thêm về Daily Meeting, các bạn có thể xem bài viết khác của mình. Còn ở khía cạnh quản lý rủi ro, Daily Meeting giúp bạn phát hiện sớm rủi ro sau mỗi 24h! Thật lợi ích đúng không?

Sau mỗi 1-4 tuần, nhóm sẽ có buổi Sprint Review theo Scrum Framework. Điều này giúp nhóm liên tục tiếp xúc và đưa sản phẩm tới khách hàng, giúp giảm thiểu rủi ro xây dựng dự án theo tiêu chuẩn kĩ thuật nhưng không theo nhu cầu thực tế của khách hàng. Việc này khá thường xuyên xảy ra với các dự án phần mềm theo mô hình thác nước cũ, khi nhóm phát triển demo sản phẩm cho khách hàng vào cuối giai đoạn phát triển, tất cả các chức năng đều hoạt động tốt theo tiêu chuẩn kĩ thuật, nhưng khách hàng thì lại mong muốn có một chức năng khác mà không quan tâm tới công sức đội phát triển!

Scrum định nghĩa rủi ro khác với cách quản lý thông thường, thay vì việc quản lý rủi ro theo phần trăm tiến độ hoàn thành của công việc (lưu ý rằng có những công việc chỉ còn 1% là hoàn thành, nhưng chiếm tới 99% để phát triển) Scrum hướng tới việc quản lý dựa trên các tiêu chí hoàn thành khác nhau.

Quản lý theo phần trăm tiến độ công việc.

Quản lý theo định nghĩa hoàn thành

3. Có thể sử dụng 2 phương pháp quản lý rủi ro này cùng nhau không?

Câu trả lời là có. Thực tế khi áp dụng triển khai phát triển phần mềm theo phương pháp Agile, các phương pháp quản lý rủi ro trong phương pháp truyền thống vẫn còn nguyên giá trị. Thêm nữa, Agile hay Scrum cũng không hề đề cập tới việc quản lý rủi ro ở mặt chi phí hay con người (thực ra ở cách vận hành team cũng đã hướng tới đội nhóm và con người, nhưng dù sao một kế hoạch backup cho nhân sự cũng nên là một phương án cần đảm bảo khi thực thi dự án).

4. Tóm tắt

– Quản lý rủi ro kiểu truyền thống bằng cách hình dung trước tất cả các vấn đề, phân tích chúng và đưa ra giải pháp. Khác với phương pháp này, phát triển phần mềm theo Agile hay Scrum giảm thiểu rủi ro bằng cách thực hiện liên tục các hành động nhằm minh bạch hoá thông tin và phát lộ sớm vấn đề sau đó là hình dung và giải quyết chúng.

Một nhân viên công ty trước kia làm ở vị trí Project Manager. Bây giờ công ty chuyển đổi qua làm dự án theo Agile. Team dự án được tổ chức theo Scrum và đang đề bạt bạn PM này làm Product Owner. Bạn này thắc mắc rằng: Rủi Ro trong dự Agile phải được quản lý ra sao vì không thấy nhắc đến trong Scrum? Trên cương vị là Scrum Master, mà công ty đang làm việc từ xa, không có điều kiện gặp mặt đào tạo trực tiếp, bạn hãy viết một bài giải thích cho PM hiểu về việc quản lý rủi ro trong dự án. Cũng như hướng dẫn PM cách thức quản lý rủi ro hiệu quả.

Tôi rất thích câu hỏi về daily meeting và muốn chia sẻ nó ngày hôm nay. Một câu hỏi khá nhiều team mới bắt đầu triển khai gặp phải là: “Daily Meeting có nhất định phải thực hiện vào buổi sáng?”, hãy cùng tìm hiểu thêm về vấn đề này.

Scrum Master thường tổ chức cho team bắt đầu họp daily meeting vào đầu ngày làm việc (buổi sáng từ 8h30-9h tuỳ theo team).

Ý nghĩa của việc này là gì?
Lý do sâu xa thực sự của vấn đề này là SM muốn:
– Mọi người đi làm đúng giờ (do có áp lực cuộc họp sớm).
– Mọi người sẽ làm “đúng” việc sau cuộc họp.

…những gì thực sự diễn ra sau đó?
– Ở thời điểm ban đầu, team sẽ tuân theo, nhưng càng về sau, team càng “trì hoãn” việc họp buổi sáng vì luôn xuất hiện thành viên đi muộn. Để giải quyết bài toán này. Scrum Master thường đặt các quy tắc cho dự án. Song các rules này cũng không được tuân theo (E.g Quy tắc phổ biến mà SM hay PM trong dự án phần mềm thường đặt ra là phạt tiền và xung vào “quỹ team” dự án để liên hoan. Các bạn “tây” thì quái chiêu hơn bằng việc phạt tiền team thay vì phạt tiền thành viên đi muộn) cuối cùng là các thành viên vẫn..đi muộn.
– Daily Scrum lúc này giống như một buổi họp báo cáo, các thành viên của team dự án thực hiện buổi họp với sự “control” của SM hay PM và .. không mang lại “value” thực sự như ý nghĩa của buổi Daily Scrum.

Vậy Giá trị của buổi Daily Scrum là gì?
Cùng xem lại cách Scrum Guide định nghĩa về Daily Scrum trước khi làm rõ việc này.

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity. – Scrum Guide

Tạm dịch
Daily Scrum là một sự kiện được giới hạn thời gian kéo dài 15 phút dành cho đội phát triển. Trong sprint thì Daily Scrum được tổ chức hàng ngày. Đội phát triển lập kế hoạch làm việc cho 24h tiếp theo. Bằng cách thanh tra công việc từ buổi họp trước và dự đoán công việc tiếp theo, việc này giúp tối ưu sự cộng tác và năng suất của nhóm. Daily Scrum được tổ chức tại cùng 1 thời điểm và cùng 1 vị trí để làm giảm sự phức tạp.

Trong Scrum Guide, Daily Scrum là một sự kiện dành cho nhóm phát triển, vậy câu hỏi đặt ra là: “Scrum Master có cần phải sắp xếp cho cuộc họp này hay không? (Tổ chức ở đâu, khi nào?). Hay đội phát triển sẽ tự chịu trách nhiệm cho cuộc họp này?”

Xem xét cho trường hợp nếu bạn – Scrum Master làm việc cùng Scrum team bao gồm 2 đội phát triển tại 2 địa điểm khác nhau, 1 tại UK và 1 tại Việt Nam, và 2 múi giờ chênh nhau 3 tiếng. Trường hợp này, đâu là thời điểm tốt nhất để thực hiện Daily Scrum? Vào buổi sáng có được không? Tôi không nghĩ vậy.

Đọc tới đây, chắc hẳn bạn đã có câu trả lời. Đúng vậy, Khi nào – Ở đâu – Làm cách nào để thực hiện Daily Scrum được nhóm phát triển tự-tổ-chức và thực hiện. Bỏi họ biết những gì là tốt nhất cho công việc phát triển phần mềm của họ. Không ai nên là người “bảo” họ cách thực hiện. Là một Scrum Master bạn chỉ cần đảm bảo Scrum Team có tổ chức Daily Scrum và hướng dẫn họ tối ưu hoá giá trị của Scrum và thực hiện Daily Scrum trong 15 phút time-box.

Việc sử dụng Daily Scrum như là “Time Checking Tool” hoặc “Status Report” là cách làm sai (wrong mindset), điều này không mang lại lợi ích mà còn khiến mọi thứ tệ đi. Đội nhóm sẽ có xu hướng dấu các vấn đề hoặc các trở ngại, điều này làm giảm sự minh bạch và điều này làm mất cơ hội kiểm tra và điều chỉnh kế hoạch hàng ngày của nhóm phát triển. Sựcộng tác và tự tổ chức của nhóm sẽ bị ảnh hưởng.

Bài gốc Scrum Việt

Lời khuyên: Vì chúng tôi muốn đảm bảo rằng các cuộc họp này ngắn gọn, chúng tôi chỉ đứng. Mọi người thường mệt mỏi sau 15 phút đứng, thật hoàn hảo! Nếu bạn thấy đồng nghiệp đang tìm chỗ ngồi và nghỉ ngơi, thì có thể cuộc họp của bạn đã diễn ra quá lâu.

Trong tất cả các sự kiện của Scrum, đây có lẽ là sự kiện hay bị “bỏ-qua” nhất của các team, trong khi đó, Srpint Retrospective lại lại một sự kiện rất quan trọng.

Cuộc họp Sprint retrospective được tổ chức ngay sau sự kiện sprint review, nhưng trước khi bắt đầu sự kiện sprint planning cho một sprint mới. Khi kết thúc cuộc họp sprint retrospective, đội phát triển nên chỉ ra những cải tiến mà sẽ được thực hiện ở sprint tiếp theo.

Chúng ta cần biết gì về cuộc họp Retrospective?

Cuộc họp sprint retrospective để nhóm có thể nhìn lại sprint vừa qua, giúp nhóm tự thanh tra và lập kế hoạch cho những cải thiện sẽ được thực hiện ở sprint tiếp theo (hoặc tương lại).

Có một cách tốt để cuộc họp trở nên hiệu quả là trả lời những câu hỏi sau:

• Những điều đã làm tốt
• Những điều cần cải thiện
• Những điều đã không thực hiện tốt ở sprint trước đó.

• Thanh tra xem sprint vừa rồi đã diễn ra như thế nào, những vấn đề cần quan tâm về: con người, các mối quan hệ, công cụ và quy trình.
• Xem lại những điều đã làm tốt và xem những chỗ cần cải thiện.
• Xây dựng kế hoạch để thực hiện những cải tiến đối với quy trình làm việc của nhóm phát triển.

AI NÊN THAM DỰ CUỘC HỌP RETROSPECTIVE?
Scrum master và nhóm phát triển cộng tác trong cuộc họp retrospective và cố gắng tìm kiếm những cải tiến.

Product owner có thể tham dự hoặc không, các bên liên quan không cần tham dự buổi họp này.

CUỘC HỌP SPRINT RETROSPECTIVE NÊN KÉO DÀI BAO LÂU
Nhiều nhất là 3 tiếng với sprint 1 tháng. Đối với những sprint ngắn hơn, cuộc họp này có thể rút ngắn.

Các cách thực hiện buổi họp sprint retrospective hiệu quả

THỰC HIỆN CÁC BƯỚC NHỎ, NHƯNG CỤ THỂ.
Thực hiện cải tiến yêu cầu nhóm phát triển phải tạo ra những thay đổi. Và sự thay đổi bao giờ cũng gặp rất nhiều khó khăn, đặc biệt là khi nó mang tới những giá tri tốt hơn.
Tìm kiếm những cải tiến nhỏ, những thay đổi tích cực có thể được nhóm thích nghi nhanh hơn.
Ví dụ, nếu burndown chart của bạn chưa đáp ứng được kỳ vọng giống biểu đồ lý tưởng, bạn nên tìm kiếm xem tại sao vấn đề này lại xảy ra. Lý do có vẻ luôn là do các user story chưa được làm rõ một cách đúng đắn và chưa được chia nhỏ thành cách nhiệm vụ phù hợp. Điều này có thể dẫn tới những kế hoạch không chính xác, và làm bạn trở nên lo lắng.

GIỮ SỰ TÍCH CỰC
Khi thanh tra các vấn đề để cải tiến, rất dễ chúng ta sẽ bị tập trung vào các vấn đề tiêu cực, và vì vậy nên tránh nó ngay từ đầu.
Các nghiên cứu cho thấy, để đạt năng suất làm việc tốt hơn, sự tích cực đóng một vai trò rất quan trọng. Bằng việc tập trung vào những khía cạnh tích cực của sprint trước và nói rằng nó có thể tiếp tục cải thiện, bạn sẽ thiết lập một trạng thái tốt trong cuộc họp và tránh để một cuộc họp hiệu quả trở nên xấu đi.

GHI NHẬN VÀ KHUYẾN KHÍCH SỰ ĐÓNG GÓP CỦA CÁC THÀNH VIÊN.
Trong suốt cuộc họp retrospective, hãy dành vài phút để ghi nhận những đóng góp của các thành viên một cách chân thành. Điều này có thể rất tích cực khi bạn và mọi người vừa thảo luận về “những gì đã có thể làm tốt hơn ở sprint trước”, điều này cũng giúp nhóm của bạn “muốn” tiến về phía trước.

ĐẢM BẢO CUỘC HỌP KHÔNG BỊ CHI PHỐI
Cuộc họp retrospective được sử dụng để tăng sự cộng tác. Đảm bảo rằng ý kiến của mọi thành viên về những gì hoạt động tốt và có thể được cải thiện trong buổi họp đều được lắng nghe cẩn thận. Nếu cuộc thảo luận bị chi phối bởi một người, thì scrum master có thể phải tham gia và là người tạo điều kiện cho nhóm có không gian để nói lên ý kiến của mình.

PHẢN TƯ VỀ RETROSPECTIVE
Khi họp retrospective, bạn có thể nhận thấy một vài điểm mà bạn muốn cải thiện. Tuy vậy, hãy nhớ nhìn lại về các cuộc họp retrospective lần trước và xem liệu bạn có cải tiến được điều gì không? Nếu những việc cần làm để cải tiến (được rút ra từ cuộc họp trước) bạn chưa thực hiện được. Có khả năng quá trình thực hiện cải tiến của bạn chưa thực sự tốt. Hãy dành thời gian để suy nghĩ về nó trước khi đưa ra những hành động mới – mà rất có thể lại được thực hiện dở dang.

Dịch và hiệu chỉnh từ nguồn: zepel.io