Agile Retrospective - Tại sao nó lại cần thiết và một số cách để thực hiện

Phát triển phần mềm linh hoạt ( Agile Software Development) là một tập hợp các phương pháp và thực hành dựa trên tuyên ngôn Agile. Phương pháp Agile chú trọng đến việc liên kết trong team và việc delivery thường xuyên của một sản phẩm.

Một trong 12 nguyên tắc trong bản tuyên ngôn Alige là:

“Sau một khoảng thời gian nhất định, team sẽ suy nghĩ làm thế nào để hiểu quả hơn, từ đó đưa ra những điều chỉnh phù hợp”

Nguyên tắc này được kết hợp chặt chẽ trong Agile team dưới hình thức họp cải tiến dự án (Agile Retrospective meeting).

Trong bài viết này, chúng ta sẽ nói nhiều hơn về Agile Retrospective meetings, mục đích của Alige và các cách làm thế nào để thực hiện.

Định nghĩa và mục đích của buổi họp cải tiến này.

Theo định nghĩa, Cải tiến (Retrospective) có nghĩa là "Nhìn lại hoặc giải quyết các sự kiện hoặc tình huống trong quá khứ ".

Nhưng ý nghĩa thực sự của retrospective meeting là: phản ánh các sprint, project, milestone gần đây nhất và xác định các khía cạnh cần được cải tiến và tuyên dương team chiến thắng.

Điều này liên hệ chặt chẽ với khái niệm cải tiến liên tục, team cần cùng nhau thảo luận các khía cạnh mà team thực hiện chưa tốt, các khía cạnh mà team cần thực hiện cùng nhau để cải tiến trong các sprint, project và milestone tiếp theo.

Tiến hành Retrospective Meetings

Buổi họp cải tiến có thể được diễn ra ở các giai đoạn khác trong dự án

• Retrospective meetings có thể được tổ chức vào ngày cuối cùng của 1 sprint và trước khi sprint tiếp theo bắt đầu để suy nghĩ về sprint gần đây nhất.

• Để xem lại các vấn đề cụ thể

• Tại mỗi một mốc quan trọng (Milestone) có thể phản ảnh trạng thái về sau.

Các bước trong Agile Retrospective

Bất kì một buổi họp cải tiến nào cũng sẽ liên quan đến các bước sau:

• Thiết lập từng giai đoạn _ Set Stage- Tổ chức các cuộc họp - Liên quan đến việc thiết lập các cuộc họp của các hỗ trợ và gửi thông báo mời họp đến tất cả các thành viên trong nhóm được yêu cầu và các bên liên quan (PM, scrum master, vv.).
• Thu thập dữ liệu - Một khi cuộc họp bắt đầu, thu thập tất cả những ý tưởng, ý kiến, mối quan tâm mà các thành viên trong nhóm có thể có. Điều này có thể được thực hiện thông qua nhiều hoạt động hồi nhanh nhẹn như Start, Stop, và Tiếp tục, Sơn nhớ hình ảnh, vv
• Tạo ra sự thấu hiểu - Sau khi dữ liệu được thu thập, phân tích ý nghĩa phải được xác định và các mẫu phải được tạo ra. Ý tưởng là để xác định xu hướng và giải quyết chúng. Ví dụ: nếu các thành viên trong nhóm không hài lòng về dài hàng ngày stand-up thì chúng ta phải tìm ra những gì đang gây ra điều này. Nó có thể là các cuộc thảo luận liên quan, những chậm trễ của các thành viên trong nhóm, thời gian thực tế thiết lập mà không chứa các số cập nhật, vv
• Tạo Actions - Một khi các vấn đề cơ bản được xác định, tạo ra các điểm hành động để giải quyết chúng. Điểm hành động nên được giao cho một người có trách nhiệm, người sẽ chịu trách nhiệm giải quyết trong một khoảng thời gian nhất định .
• Wrap Up - Cảm ơn nhóm cho thời gian của họ và cho họ tham gia. Hãy chắc chắn rằng các điểm thảo luận cuộc họp và hành động được ghi chép lại và chuyển tới các thành viên trong nhóm để dễ tham khảo.

Formats, ý tưởng và hoạt động trong buổi họp Cải tiến

#1) Đã làm tốt những gì, phải cải thiện những gì, những gì cần phải hành động.

Các thành viên trong nhóm gặp gỡ và thảo luận về những cái nhóm đã làm tốt, cái mà team cần phải cải thiện, những bài học cần được rút ra và các hành động tương ứng với lĩnh vực cần cải thiện.

Những hành động này được giao cho một thành viên trong nhóm có trách nhiệm. Thảo luận này được ghi chép và lưu chuyển cho tất cả các thành viên sau khi cuộc họp hoặc có thể được lưu và chia sẻ trên mạng nội bộ để dễ dàng truy cập.

JIRA có kèm một mẫu Retrospective Sprint cho cuộc họp cải tiến dựa trên format dưới đây.

(Nguồn: http://blogs.atlassian.com/)

# 2) Bắt đầu, Dừng và Tiếp tục cuộc họp

Trong cuộc họp này, các thành viên trong nhóm được yêu cầu cung cấp ý kiến về những gì nhóm nên bắt đầu làm, ngừng làm và tiếp tục làm trong sprint.

Phương pháp này là rất phổ biến và hiệu quả, đặc biệt là đối với team mới.

• Bắt đầu những item mà nhóm muốn thêm vào quá trình của họ ví dụ: Thời gian sắp tới sẽ bắt đầu cho các cuộc họp dự án.

• Dừng những item mà team không còn muốn làm nữa ví dụ: dừng việc kiểm tra trong code mà không cần phải dừng review code.

• Tiếp tục các item mà team muốn tiếp tục làm trong tương lai ví dụ: Trong tương lai vẫn tiếp tục có buổi họp hàng ngày.

Người họp có thể thiết lập thời gian tối thiểu và tối đa của một số items một thành viên trong nhóm có thể đề xuất. Ví dụ. Mỗi thành viên trong nhóm cần phải cung cấp 1 item cho mỗi Start, Stop, và Tiếp tục danh sách và có thể cung cấp tối đa là 3 mục mỗi loại.

Ngoài ra, một khi toàn bộ danh sách được lưu lại, thành viên trong nhóm có thể được yêu cầu bỏ phiếu để thu hẹp các hạng mục quan trọng nhất.

#3) 5 lý do tại sao lại cần format cuộc họp

Format cuộc họp này được dựa trên yêu cầu theo dõi câu hỏi 'Tại sao' thong qua các thành viên trong nhóm. Format cuộc họp này được sử dụng để tìm nguyên nhân cơ bản cho một kịch bản có vấn đề (triệu chứng), và nơi mà các nguyên nhân có thể không được rõ ràng. Mục tiêu không phải là để giải quyết vấn đề nhưng để hiểu được tình hình và có thể thu hẹp các nguyên nhân gốc rễ.

Mỗi thành viên trong nhóm tạo ra một chuỗi các nguyên nhân tại sao họ nghĩ rằng vấn đề đó đang xảy ra. Khi danh sách sẵn sàng, các câu trả lời có thể được hợp nhất thành một chuỗi duy nhất đại diện cho quan điểm đạt được một sự đồng thuận chung của nhóm.

Điều này làm việc tốt nhất cho các nhóm nhỏ với kích thước khoảng từ 3-5 thành viên. Ví dụ:

Vấn đề: Chất lượng sản phẩm là không tốt.

Câu hỏi: Tại sao?

Lý do 1: Bản Build đó không ổn định.

Câu hỏi: Tại sao?

Lý do: Không có quá trình thúc ép/ép buộc- Không có mã đóng băng.

Câu hỏi: Tại sao?

Lý do: Phạm vi thay đổi

Câu hỏi: Tại sao?

Lý do: Không xác định được những ảnh hưởng trong khi lập kế hoạch cho dự án.

#4) Cải tiến sprint với Glad (vui mừng), Sad (buồn), Mad (tức giận).

Trong format cuộc họp này, mỗi team member sẽ sử dụng khoảng từ 5-10 phút để ghi lại cảm xúc của mình trong sprint vừa qua.

• Những hạng mục nào mà mình cảm thấy hài lòng thì được phân loại vào mục Glad.

• Những hạng mục nào mà mình chưa cảm thấy hài lòng và có thể cải tiến được thì đưa vào mục Sad.

• Những hạng mục nào mà gây cản trở nghiêm trọng và mình mong muốn loại bỏ nó ngay thì đưa vào mục Mad.

Sau khoảng thời gian này, những ý kiến của mọi người sẽ được tập hợp lại dựa trên cảm xúc của từng cá nhân về sprint vừa qua. Từ đó những mục Sad và Mad sẽ được bỏ phiếu để ưu tiên thực hiện trong thời gian tới. Kể cả trong những hạng mục ở cột “Glad” thì cũng vẫn có thể cải tiến để nó tốt hơn.

# 5) Vẽ hình ảnh

Kỹ thuật này là một kỹ thuật không phải bằng văn bản trong cuộc họp cải tiến.

Trong format cuộc họp này, các thành viên trong nhóm được cho vài phút để thu thập những suy nghĩ của họ và thể hiện cảm xúc và ý kiến của họ.

Cuộc họp này là một định dạng tốt để tiến hành cải tiến nơi mà truyền thông bằng lời nói trong team đang không tốt, nó hoạt động như một máy phá vỡ lớp băng khoảng cách giữa các thành viên trong nhóm.

# 6) Vòng tán dương/chúc mừng

Kỹ thuật này thu hút được thông tin phản hồi bằng việc sử dụng Điểm cộng và Delta. Ví dụ: những gì làm tốt, những gì có thể là tốt hơn.

Trong đó, các thành viên trong nhóm tập hợp lại để tạo thành một vòng tròn. Một thành viên trong nhóm bắt đầu và ném một vật mềm (quả bóng bằng vải mềm, bóng stress) ném về phia bất cứ thành viên khác.

Ý tưởng là bất cứ ai có bóng sẽ trả lời 3 câu hỏi:

• Họ thích gì,

• Họ đánh giá cao cái gì và

• Làm thế nào họ sẽ sử dụng những điều đã học để cải thiện

Các đối tượng được thông qua một cách ngẫu nhiên trong vòng tròn cho đến khi tất cả mọi người đã có cơ hội để trả lời 3 câu hỏi trên.

Những quan niệm sai lầm cơ bản về Agile Retrospective

#1) Cuộc họp cái tiến thì buồn tẻ, chán ngắt

Đây là lý do đầu tiên tại sao thành viên trong nhóm không thích tiến hành hoặc là có mặt trong cuộc họp cải tiến.

Để làm cho cuộc họp càng hấp dẫn người điều hành nên suy nghĩ với niềm vui nhưng hiệu quả để thực hiện các cuộc họp này.

#2) Cuộc họp cải tiến là cơ hội của tôi để chỉ ra hiệu suất trung bình dưới đây của một thành viên trong nhóm.

Cuộc họp cải tiến không phải là ngón tay trỏ hoặc tự trút ra cuộc họp.

Cuộc họp này không được lên kế hoạch để chỉ định đích xác hoặc quát tháo thành viên trong nhóm cho điểm yếu của họ. Cuộc họp này được thiết lập trong một môi trường trung tính với mục tiêu cải thiện và phát triển. Tránh làm cho ý kiến trực tiếp nhằm vào một người duy nhất. Và, hãy nhớ rằng mục đích cuối cùng là để làm cho dự án ngày càng trở nên tốt hơn!

# 3) Chỉ gặp tổ chức dẫn đầu cuộc họp hồi cứu và thảo luận về các vấn đề

Các thành viên trong nhóm nên được khuyến khích tham gia và chia sẻ quan điểm của họ. Cuộc họp này là dành cho sự tiến bộ của đội bóng và không cho một cuộc thảo luận trên xuống quyết định bởi tổ chức gặp gỡ / facilitator.

Đồng thời, các thành viên trong nhóm nên được thoải mái để họ có thể bày tỏ quan điểm đúng của họ xem mà không sợ bị phán xét hoặc sợ phản ứng dữ dội như một kết quả của việc lên tiếng.

# 4) Quản lý cấp cao / Các bên liên quan đều không được mời vào tất cả các cuộc họp cải tiến

Điều này thay đổi từ dự án để dự án. quản lý cao hơn, chủ sở hữu sản phẩm có thể được mời tham dự cuộc họp để giải quyết bất kỳ mối quan tâm họ có thể có hoặc bất kỳ lo ngại rằng đội bóng đã liên quan đến quản trị của họ.

# 5) kết quả cuộc họp cải tiến không cần phải được ghi chép

Phương pháp Agile là dựa trên nguyên tắc "Phần mềm làm việc trên tài liệu toàn diện", tuy nhiên, điều đó không có nghĩa là nhóm nên bỏ không làm tài liệu hoàn toàn.

Tài liệu cải tiến có thể dẫn đến theo dõi hiệu quả của các điểm hành động để đóng cửa. Điều này cũng có thể được bổ sung vào kho dữ liệu lịch sử, nơi mà các nhóm có thể truy cập vào bài học kinh nghiệm như là một phần của tài sản Quy trình tổ chức.

Phần kết luận

Retrospective thực sự rất hữu ích cho việc xây dựng đội ngũ và sự gắn kết giữa các thành viên trong team với nhau..

Thành viên trong nhóm đến với nhau để ăn mừng chiến thắng và đề xuất cải tiến cũng tạo ra một môi trường nhóm minh bạch hơn và mạnh hơn. Thông qua cải tiến liên tục và thông tin phản hồi, các đội trở nên tốt hơn theo thời gian.

Các cuộc họp cải tiến nên bao gồm cả các vấn đề của con người (nhân cách, thái độ, thiếu kỹ năng, vv) và các vấn đề kỹ thuật (phạm vi, yêu cầu không phù hợp, ổn định hệ thống, vv).

Điều này được khuyến cáo rằng các cuộc họp cải tiến được tiến hành tại tất cả các cấp và không chỉ ở các nhóm phát triển.

Các cuộc họp cải tiến có thể được tiến hành vào cuối của một cột mốc quan trọng, kết thúc của một sprint, post mortem của một sự cố hoặc vấn đề, sau các sự kiện lớn, vv… Hãy chắc chắn rằng các cuộc họp cải tiến của bạn được ghi chép lại và các điểm hành động được theo dõi để kết thúc.

Cuối cùng nhưng không kém phần quan trọng, hãy làm cho các cuộc họp cải tiến là những cuộc họp vui vẻ!

Dịch từ nguồn: http://www.softwaretestinghelp.com/agile-retrospective-meetings/