Agile Retrospectives - Nhìn lại và cải tiến hiệu quả công việc dự án

Retrospectives cung cấp giá trị tức thì cho dự án hiện tại, thay vì chỉ ghi lại những lời khuyên với “hy vọng” rằng dự án sẽ tốt lên và động lực của team cũng tăng lên.

Việc các nhóm Agile xem xét và đánh giá lại những gì đã làm tốt và những vấn đề nào gặp phải cần giải quyết, xử lý trong quá trình hoàn thành mục tiêu dự án là công đoạn vô cùng quan trọng. Chúng ta cần có những buổi họp đặc biệt, để cùng nhau thảo luận về những gì đã xảy ra trong quá trình phát triển và phát hành phần mềm/sản phẩm, với mục tiêu cải thiện cách chúng ta thực hiện dự án trong tương lai dựa trên những bài học kinh nghiệm. Vậy cuộc họp này là gì? Lợi ích của quá trình này mang lại những gì và ứng dụng ra sao? Chúng ta sẽ cùng tìm hiểu trong bài viết bên dưới!

Retrospectives là gì?

Một cuộc họp retrospectives là một cuộc họp nội bộ, hay một cuộc họp chuyên biệt có thể được tổ chức sau mỗi lần release sản phẩm, hoặc thậm chí toàn bộ dự án. Tuy nhiên, thuật ngữ này thường đề cập đến cuộc họp được tổ chức vào cuối mỗi lần lặp, sau khi đã demo phần mềm/sản phẩm của lần lặp đó xong. Tại cuộc họp này, bất kể phần nào của dự án cũng có thể được đánh giá lại, đây luôn là cơ hội để các thành viên của development team kiểm tra và cải thiện phương pháp thực hiện dự án cũng như kết nối tinh thần đồng đội của nhóm. Retrospectives cũng có thể được lên lịch thường xuyên (cuối mỗi lần lặp), hoặc bất cứ khi nào được yêu cầu (đối với các dự án Lean và Kanban có thể không áp dụng các giai đoạn lặp lại). Trong quá trình retrospectives, chúng ta sẽ trả lời cho các câu hỏi sau:

  • Điều gì đang diễn ra tốt?
  • Có thể áp dụng những cải tiến vào phần nào của dự án?
  • Chúng ta nên làm gì khác đi?

Khi các vấn đề được xác định, chúng ta cùng nhau tìm ra các giải pháp, sau đó cam kết áp dụng các giải pháp đã chọn trong một hoặc hai lần lặp, trước khi gặp lại nhau để thảo luận (trong một cuộc họp retrospectives khác) xem tình hình có được cải thiện hay không. Nếu những thay đổi là hữu ích thì quá tuyệt vời! Chúng ta sẽ áp dụng những cải tiến này vào quy trình dự án. Nhưng ngược lại, nếu chúng không giúp ích trong quá trình phát triển dự án, chúng ta có thể coi sự nỗ lực này là một cơ hội để học tập và quyết định nên thử phương án khác hay quay lại quy trình trước đó mà chúng ta đã từng làm.

Lợi ích của quy trình retrospectives

Vì retrospectives diễn ra trong quá trình triển khai dự án, nên các bài học kinh nghiệm và cải tiến có được sau mỗi buổi họp đem lại tính ứng dụng cao và phù hợp với các công việc sắp tới. Nói cách khác, retrospectives cung cấp giá trị tức thì cho dự án hiện tại, thay vì chỉ ghi lại những lời khuyên với “hy vọng” rằng dự án sẽ tốt lên và động lực của team cũng tăng lên.

Một số project manager khi bắt đầu sự nghiệp của mình thường sử dụng các phương pháp quản lý dự án truyền thống. Họ đọc các tài liệu về những bài học kinh nghiệm từ các project manager khác, giúp ngăn ngừa được những rủi ro và vấn đề sẽ gặp phải, từ đó những vấn đề đó không thể xảy ra trong các dự án. Kết quả là họ không tự mình gặp phải những vấn đề nghiêm trọng nào đó và tự mình thu thập được những bài học kinh nghiệm đáng giá. Tuy nhiên, vì các dự án Agile có tính thay đổi rất cao nên luôn xuất hiện những vấn đề mới, khi nhóm agile xác định được các vấn đề và các vấn đề này mới thực sự là của dự án của chúng ta. Từ đó có thể cùng nhóm đưa ra các giải pháp và giải quyết các vấn đề bởi chính-chúng-ta. Việc cần làm là phải xem xét lại các bài học thu được trong suốt quá trình triển khai dự án, sẽ giúp cho nhóm ngày càng phát triển và ứng phó tốt với các vấn đề.

Retrospectives thường mang lại một số lợi ích cho các nhóm, bao gồm các loại cải thiện sau:

  • Cải thiện năng suất: Bằng cách áp dụng các bài học kinh nghiệm và giảm thiểu rework, nhóm có thể hoàn thành công việc hiệu quả hơn.
  • Cải thiện khả năng: Retrospectives đem đến cơ hội để truyền đạt những kiến thức/kỹ năng khó, ít người có và khi số lượng người có kiến thức/kỹ năng này tăng lên, thì số người có thể thực hiện các nhiệm vụ liên quan đến kiến thức/kỹ năng này cũng sẽ tăng lên.
  • Cải thiện chất lượng: Chúng ta có thể cải thiện chất lượng cho các dự án của mình bằng cách tìm ra nguyên nhân dẫn đến các sai lầm và loại bỏ các nguyên nhân đó.
  • Nâng cao năng lực: Tập trung vào việc tìm kiếm các cải tiến về quy trình hiệu quả, có thể nâng cao năng lực thực hiện công việc của nhóm.

Quá trình thực hiện retrospectives

Vậy chúng ta phải làm gì để đạt được những lợi ích này? Theo Esther Derby và Diana Larsen, một cuộc họp retrospectives bao gồm 5 bước: Bước mở đầu, bước kết thúc và ba bước ở giữa thể hiện quá trình giải quyết vấn đề, được minh họa trong hình bên dưới:

Derby và Larsen nói rằng trong 2 giờ retrospectives điển hình, 5 bước trên sẽ có timeboxed như hình bên dưới:

 

Các bước trong quá trình retrospectives là một phần của chu kỳ liên tục, trong đó các buổi retrospectives sẽ luân phiên với các lần lặp (iteration):

Chu kỳ bắt đầu với các hoạt động được thực hiện trong một lần lặp của dự án (ở bên trái) - sau đó chúng ta sẽ hoàn thành các bước retrospective cho lần lặp đó (ở bên phải). Kết quả đầu ra từ cuộc họp này (các cải tiến và thử nghiệm đã thống nhất trong quá trình retrospective) sẽ được lập kế hoạch và tích hợp cho các hoạt động trong lần lặp tiếp theo. Trong lần lặp tiếp theo, chúng ta xây dựng và bàn giao các phần gia tăng cho phần mềm/sản phẩm, tạo tiền đề cho việc đánh giá lại ở cuối lần lặp - từ đó chu kỳ tiếp tục lặp lại.

Chúng ta sẽ xem xét kỹ hơn 5 bước trong quá trình retrospective ở phần bên dưới đây:

Bước 1: Chuẩn bị - Set the Stage

Khi bắt đầu buổi họp retrospectives, chúng ta cần tạo tiền đề để giúp mọi người tập trung vào nhiệm vụ phản ánh những gì đã diễn ra trong giai đoạn cần đánh giá. Trong quá trình chuẩn bị, chúng ta cần tạo ra một bầu không khí thoải mái để các thành viên có thể trình bày một cách rõ ràng, chi tiết nhất về những vấn đề đã/đang gặp phải.

Việc các thành viên giữ im lặng trong buổi retrospective là không chấp nhận được. Để quá trình này được thực hiện thành công đòi hỏi các thành viên phải cùng nhau đưa ra ý kiến, trình bày về mọi thứ đã diễn ra như thế nào, kết quả đạt được ra sao và họ muốn làm gì tiếp theo trong tương lai. Kỹ thuật mà chúng ta có thể sử dụng để khuyến khích sự tham gia của tất cả các thành viên là tạo ra một không gian có thể thu hút mọi người, yêu cầu họ giới thiệu về bản thân trong buổi retrospective đầu tiên, hoặc yêu cầu những người tham gia phác thảo những gì họ hy vọng nhận được từ cuộc họp retrospective, cũng có thể là nói một hoặc hai từ mô tả cảm nhận của họ về lần lặp vừa rồi và sự tiến bộ của nhóm. Mục tiêu là giúp các thành viên làm quen với việc phát biểu và khuyến khích họ tiếp tục đóng góp trong suốt cuộc họp.

Phần tiếp theo của giai đoạn chuẩn bị là xây dựng cách tiếp cận của buổi retrospective và chủ đề để thảo luận. Việc cung cấp một dàn ý như vậy giúp thiết lập một mục đích và chương trình làm việc rõ ràng và ngăn mọi người coi đây là “một cuộc họp không có mục đích”. Chúng ta cũng cần thiết lập các thỏa thuận về cách vận hành buổi retrospectives - còn được gọi là “thiết lập quy tắc”. Với các quy tắc hoặc thỏa thuận này, nhóm sẽ biết nên chú trọng vào những việc gì (ví dụ: nói về các vấn đề đang gặp phải trong quá trình triển khai công việc) và việc gì không nên làm (ví dụ: chỉ trích cá nhân hoặc khiếu nại không có cơ sở) trong quá trình retrospectives.

Yếu tố cuối cùng của giai đoạn chuẩn bị là khiến mọi người có tâm trạng thoải mái để đóng góp thông tin và ý tưởng. Những người tham gia có thể cảm thấy không thoải mái khi đưa ra các vấn đề, vì họ sợ xung đột. Họ có thể cảm thấy rằng những lời trích về quá trình làm việc có thể phản ánh không tốt về họ. Tuy nhiên, mục tiêu thực sự của buổi retrospectives chỉ đơn giản là tìm ra cách giải quyết và cải thiện các vấn đề. Thực tế là ai trong chúng ta đều cũng đã từng mắc sai lầm, và điều đó không có gì là đáng trách cả, nếu chúng ta có thể tiếp tục và không mắc phải những sai lầm đó nữa. Chúng ta cần đánh giá mức độ sẵn sàng chia sẻ của những người tham gia buổi retrospectives và cố gắng tăng mức độ thoải mái của họ.

Các hoạt động chúng ta có thể sử dụng để tạo tiền đề cho buổi họp retrospectives bao gồm:

  • Check-in: Người tham gia trả lời một loạt các câu hỏi check-in với một hoặc hai từ hoặc một cụm từ ngắn.
  • Focus on / Focus off: Các thành viên trong nhóm thảo luận về các cách tham gia hiệu quả và không hiệu quả, sau đó ghi những cách làm đã đạt đồng thuận vào cột “Focus on”.
  • ESVP: Những người tham gia xác định thái độ của họ một cách ẩn danh đối với việc tham dự cuộc họp retrospective là thuộc tuýp người nào (Explorer - người khám phá, Shopper - người mua hàng, Vacationer - người đi nghỉ mát hay Prisoner - tù nhân).
  • Working Agreements - Thỏa thuận làm việc: Nhóm nghiên cứu và sau đó xác định các thỏa thuận làm việc mà họ muốn đưa ra cho quá trình retrospective.

 

Hãy cùng xem xét kỹ hơn từng hoạt động trong số bốn hoạt động này.

  • Check-in: Chúng ta có thể sử dụng hoạt động này để giúp mọi người gạt các mối quan tâm khác của họ sang một bên và tập trung vào cuộc họp retrospectives. Thực hiện xoay vòng từng người một, chúng ta sẽ yêu cầu mọi người tóm tắt trong một hoặc hai từ những gì mà họ mong muốn có được từ buổi retrospectives, những gì hoặc cách họ đang cảm thấy về cuộc họp retrospectives.
  • Focus on / Focus off: Chúng ta có thể sử dụng hoạt động này để thiết lập tư duy giao tiếp một cách hiệu quả trong buổi retrospectives. Đối với hoạt động này, chúng ta sử dụng sơ đồ hiển thị bên dưới, tóm tắt những điểm nhấn hiệu quả nhất cần làm trong một buổi retrospectives.

Trong hoạt động này, chúng ta yêu cầu các thành viên thảo luận về ý nghĩa của từng cặp từ này đối với họ, mời họ cung cấp các ví dụ. Sau đó, chúng ta sẽ hỏi mọi người xem họ có sẵn sàng thực hiện những ý tưởng ở cột “Focus On” bên trái hay không. Nếu có sự bất đồng, có thể yêu cầu mọi người thảo luận về tác động của những hành vi ở cột “Focus Off”, và cố gắng giúp cho mọi người đạt được đồng thuận.

  • ESVP: Trong hoạt động này, những người tham gia sẽ xác định thái độ của họ đối với quá trình retrospective thuộc một trong những vai trò nào bên dưới đây (một cách ẩn danh), ghi lại sự lựa chọn của họ vào một tờ giấy:
    • Explorer - Người khám phá: Người khám phá háo hức khám phá những ý tưởng và kiến thức mới, họ luôn muốn tìm hiểu mọi thứ.
    • Shopper - Người mua hàng: Người mua hàng sẽ xem qua tất cả thông tin đang có và sẽ vui vẻ ra về với một ý tưởng hữu ích với họ.
    • Vacationer - Người đi nghỉ mát: Những người này không quan tâm đến công việc của buổi retrospective, nhưng khi tham gia retrospective họ cảm thấy thoải mái vì không phải làm công việc bình thường của họ.
    • Prisoner - Tù nhân: Những người tự phân loại mình là tù nhân cảm thấy giống như họ đang bị buộc phải tham dự cuộc họp retrospective.

Các kết quả ẩn danh được thu thập và đếm số lượng để nhóm xem xét (như được hiển thị bên dưới), để đánh giá mức độ năng lượng và cam kết của những người tham gia.

Sau khi kết quả được kiểm tra, điều phối viên của cuộc họp nên xé và loại bỏ các phiếu trả lời một cách kỹ càng để không ai phải lo lắng về việc câu trả lời của họ bị truy lại. Sau đó, điều phối viên sẽ hỏi những người tham gia cảm nhận của họ về những điểm số đó như thế nào và giải thích ý nghĩa của điểm số đối với quá trình retrospective.

  • Working Agreements - Thỏa thuận làm việc: Đối với hoạt động này, những người tham gia được phân bổ thành các nhóm nhỏ và được yêu cầu xây dựng các thỏa thuận làm việc. Toàn bộ nhóm xem xét các đề xuất và chọn 3 đến 7 chủ đề để phát triển thêm. Sau đó mỗi nhóm nhỏ được giao cho một chủ đề để xây dựng tiếp. Cuối cùng, mọi người tập trung lại, dành thời gian để làm rõ và tinh chỉnh các ý tưởng mà mọi người đã tạo ra, xây dựng một danh sách các thỏa thuận tổng thể và duy nhất để tuân thủ theo.

Bước 2: Thu thập dữ liệu - Gather Data

Trong giai đoạn thu thập dữ liệu, chúng ta phải cố gắng tạo ra một bức tranh toàn cảnh về những gì đã xảy ra trong iteration vừa rồi. Nếu không có một cái nhìn chung về những gì đã xảy ra, chúng ta sẽ chỉ đơn giản là đoán xem những thay đổi hoặc cải tiến nào cần được thực hiện - dẫn đến những thay đổi, cải tiến đó không thực sự hiệu quả cho những vấn đề chúng ta đang có. Vì vậy, trong bước này, chúng ta bắt đầu quá trình giải quyết vấn đề bằng cách thu thập các mảnh ghép mà chúng ta đang đã và đang có. Kết quả là cả nhóm sẽ có một cái nhìn chung về một tập các vấn đề, phát hiện, sự kiện trong iteration.

Có một số kỹ thuật hỗ trợ mà nhóm có thể sử dụng để thu thập dữ liệu, bao gồm:

  • Timeline (Dòng thời gian): Các thành viên trong nhóm tạo một dòng thời gian để theo dõi tiến trình của iteration - từ đầu đến cuối.
  • Triple Nickels: Nhóm được chia thành những nhóm nhỏ 5 người, dành 5 phút để tập hợp và xây dựng dựa trên 5 ý tưởng, lặp lại 5 lần.
  • Color Code Dots: Các thành viên trong nhóm xác định mức năng lượng của họ đạt cao/thấp tại thời điểm nào trong iteration.
  • Mad (điên), Sad (buồn), Glad (vui): Những người tham gia xác định phản ứng và cảm xúc của họ trong suốt iteration với 3 trạng thái Mad (điên), Sad (buồn), Glad (vui).
  • Locate Strengths (Xác định điểm mạnh): Nhóm xác định những gì đã diễn ra suôn sẻ (tốt) trong suốt dự án.
  • Satisfaction Histogram (Biểu đồ sự hài lòng): Các thành viên trong nhóm tạo một biểu đồ thể việc mức độ hài lòng của họ về một lĩnh vực hoặc một vấn đề cụ thể.
  • Team Radar: Nhóm đánh giá họ đã thực hiện như thế nào so với các mục tiêu cải tiến quy trình trước đó của họ.
  • Like to Like: Nhóm so sánh phản ứng của họ với các sự kiện xảy ra trong quá trình lặp lại.


Tiếp theo, chúng ta sẽ xem xét kỹ hơn hai kỹ thuật đầu tiên (Timeline và Triple Nickels).

  • Timeline:
    • Nhóm có thể sử dụng kỹ thuật Timeline để chẩn đoán nguồn gốc và sự tiến triển của một hoặc một số vấn đề. Để bắt đầu, điều phối viên vẽ một timeline cho giai đoạn cần xem xét - có thể là của iteration hoặc timeline của 1 vấn đề. Sau đó, điều phối viên yêu cầu các thành viên trong nhóm nhớ lại các sự kiện diễn ra tốt, hay các sự kiện gặp vấn đề và các sự kiện quan trọng đã xảy ra.
    • Ban đầu, các thành viên trong nhóm làm việc riêng lẻ, viết các sự kiện lên các sticky note có màu (màu sắc của sticky note giúp phân loại các sự kiện tốt hơn). Khi mọi người có cho mình những sticky notes, sẽ gắn chúng lên timeline và xem lại người khác đã đăng những gì.
    • Bằng cách ghi lại timeline như vậy, các thành viên trong nhóm có được cái nhìn sâu sắc hơn về các sự kiện và điều gì đã góp phần gây ra các vấn đề, từ đó giúp họ có thêm các dữ kiện để tránh các vấn đề tương tự trong tương lai. Cả nhóm có thể nhớ lại các chi tiết bổ sung thông qua sự thể hiện trực quan của timeline và những giải thích về các sự kiện tương tự của các thành viên trong nhóm.
    • Sau khi notes được gắn lên timeline, nhóm thảo luận về timeline từ trái sang phải và thêm notes mới theo yêu cầu. Bên dưới timeline, các thành viên sẽ ghi lại biểu hiện cảm xúc của mình đối với các sự kiện và vẽ đường xu hướng để phản ánh những cảm xúc đó.

 

  • Triple Nickels:
    • Triple Nickels là một quá trình thu thập dữ liệu trong đó người tham gia dành 5 phút để thu thập dữ liệu về ít nhất 5 ý tưởng liên quan đến một chủ đề cụ thể. (Kỹ thuật này lấy tên từ một cuộc thi bắn súng, bắn hạ các mục tiêu từ 5 yard trong 5 giây). Nhóm được chia thành các nhóm nhỏ riêng lẻ (hoặc nếu toàn bộ nhóm có từ 7 người trở lại thì chúng ta sẽ gộp thành 1 nhóm) và các nhóm tiến hành 5 vòng mở rộng.
    • Quá trình này yêu cầu mỗi cá nhân tự làm việc riêng lẻ trước và suy nghĩ về ít nhất 5 vấn đề xảy ra trong iteration. Sau đó, mọi người ghi lại các vấn đề trên sticky notes. Sau khi 5 phút đầu tiên kết thúc, mọi người chuyển notes của mình cho người kế bên phải. Sau đó, mỗi người dành 5 phút để xây dựng ý tưởng trên notes mà họ đã nhận được. Thời gian của quá trình này sẽ lặp lại liên tục để mọi người có thể đóng góp ý kiến ​​của riêng mình và có cơ hội để suy nghĩ, cũng như bổ sung vào ý tưởng của các thành viên khác trong nhóm.
    • Mục tiêu của kỹ thuật này là tạo ra một môi trường giúp mọi người có thời gian để thực hiện cả việc suy ngẫm cá nhân và mở rộng ý tưởng của những người khác.

 Bước 3: Tạo thông tin chi tiết - Generate Insights

Phần này của buổi retrospectives cho phép cả nhóm cùng hợp tác với nhau, đánh giá dữ liệu mà chúng ta đã thu thập được ở bước trước và thu được những thông tin chi tiết có ý nghĩa. Những hoạt động này giúp chúng ta giải thích và hiểu được ý nghĩa của các vấn đề mà chúng ta đang phải đối mặt, trước khi chúng ta chuyển sang giai đoạn giải quyết vấn đề.

Có một số hoạt động dựa trên việc thảo luận nhóm mà chúng ta có thể sử dụng để tạo ra thông tin chi tiết, bao gồm:

  • Brainstorming: Nhóm tập trung vào việc tạo ra một lượng lớn các ý tưởng và sẽ được sàng lọc sau đó. Các cách tiếp cận phổ biến bao gồm Free-for-AlI, Round-Robin và Quiet Writing.
  • Five Whys: Những người tham gia phân tích nguyên nhân cơ bản của vấn đề bằng cách đặt câu hỏi “Tại sao?” năm lần để xác định nguyên nhân gốc rễ thực sự của vấn đề.
  • Fishbone Analysis (Phân tích biểu đồ xương cá): Nhóm sử dụng công cụ lập biểu đồ xương cá - kết hợp với Five Whys - để sơ đồ hóa việc phân tích nguyên nhân gốc rễ của một vấn đề.
  • Prioritize with Dots: Để xác định mức độ ưu tiên, các thành viên trong nhóm sử dụng kỹ thuật bỏ phiếu bằng việc phân bổ các dấu chấm cho những sự lựa chọn.

 

Hãy cùng tìm hiểu ba kỹ thuật đầu tiên (Brainstorming, Five Whys và Fishbone Analysis) một cách chi tiết hơn.

  • Brainstorming:
    • Brainstorming nhằm mục đích tạo ra một số lượng lớn các ý tưởng, sau đó được thống kê thành một danh sách chọn lọc các ý tưởng và sẽ được sử dụng trong giai đoạn này. Khối lượng lớn ý tưởng được tạo ra, giúp nhóm sẽ loại bỏ được suy nghĩ rằng những ý tưởng hay nhất thường hiếm khi xuất hiện trước. Có nhiều cách brainstorming tiếp cận khác nhau, bao gồm ba phương pháp - Quiet Writing (các thành viên trong nhóm viết ra các ý tưởng và chuyển chúng cho điều phối viên, thường là trong một khoảng thời gian được xác định trước. Những ý tưởng này được nhóm đánh giá sau đó), Round-Robin (các thành viên trong nhóm truyền một thẻ bài cho nhau, yêu cầu người sở hữu thẻ bài chia sẻ một ý tưởng, nhóm sẽ thảo luận và sau đó chuyển thẻ bài cho thành viên tiếp theo) và Free-for-All (các thành viên trong nhóm tự do phát biểu ý tưởng và sau đó được điều phối viên ghi lại để phát triển các ý tưởng giải quyết vấn đề).
    • Nhóm sẽ đưa ra những tiêu chí để lựa chọn các ý tưởng đã được tạo ra. Sau khi có được các tiêu chí, chúng ta quyết định xem nên chọn những ý tưởng nào để thực hiện bước tiếp theo trong buổi retrospectives - "Quyết định việc cần làm".
  • Five Whys:
    • Mục đích của việc thực hiện Five Whys là khám phá các mối quan hệ nguyên nhân và kết quả liên quan đến một vấn đề cụ thể và tìm ra nguyên nhân gốc rễ của vấn đề. Kỹ thuật này có nguồn gốc từ Toyota và thường được sử dụng trong phương pháp Lean (sẽ cùng tìm hiểu ở những bài viết khác).
    • Khi nhóm thực hiện quá trình này, mọi người nên làm việc theo cặp hoặc nhóm nhỏ. Trong các cặp hoặc nhóm này, họ hỏi "Tại sao?" năm lần để hạn chế những câu trả lời theo thói quen và cố gắng tìm ra nguyên nhân gốc rễ của vấn đề. Dưới đây là một ví dụ:

Câu hỏi 1: Tại sao chúng ta lại gặp sự cố hệ thống bị treo khi đang demo?

Trả lời 1: Hệ thống bị treo do chúng ta cố gắng truy xuất dữ liệu các đơn bán hàng, nhưng không có đơn hàng nào cả.

Câu hỏi 2: Tại sao không có đơn hàng nào lại gây ra lỗi?

Trả lời 2: Quá trình truy xuất dữ liệu trả về dữ liệu rỗng.

Câu hỏi 3: Tại sao chúng ta không kiểm tra trường hợp dữ liệu rỗng và hiển thị thông báo lỗi có ý nghĩa hơn?

Trả lời 3: Chúng ta đã chặn lỗi ở những phần mà chúng ta biết, nhưng đây là lần đầu tiên thấy lỗi xuất hiện ở hệ thống đơn hàng.

Câu hỏi 4: Tại sao tất cả những đoạn mã truy vấn không xử lý trường hợp dữ liệu rỗng?

Trả lời 4: Tôi không biết; nó chưa bao giờ được ưu tiên.

Câu hỏi 5: Tại sao nó không phải là một ưu tiên, trong khi đó nó ảnh hưởng rất lớn tới tính ổn định của hệ thống?

Trả lời 5: Đồng ý. Chúng ta nên thêm nó vào danh sách kiểm tra và đảm bảo nó được thực hiện đúng và đủ. 

  • Fishbone Analysis (Phân tích biểu đồ xương cá):
    • Fishbone Analysis là một công cụ trực quan thường đi kèm với việc thực hiện Five Whys, giúp hiển thị phân tích nguyên nhân gốc rễ của các vấn đề. Sử dụng kỹ thuật này, nhóm sẽ xác định các yếu tố đang gây ra các tình huống hoặc ảnh hưởng đến các vấn đề và tìm kiếm nguyên nhân có thể xảy ra.
    • Quá trình bắt đầu bằng việc vẽ một biểu đồ xương cá và viết vấn đề gặp phải ở phần đầu “con cá”. Bước tiếp theo là xác định các hạng mục yếu tố liên quan, cũng được viết trên sơ đồ. Nhóm có thể sử dụng các danh mục có liên quan đến các câu hỏi trong Five Whys hoặc có thể sử dụng một tập hợp các danh mục thường được sử dụng, chẳng hạn như:
    • Con người, thủ tục, chính sách, địa điểm.
    • Hệ thống, nhà cung cấp, kỹ năng, môi trường xung quanh.
    • Sau đó, điều phối viên hỏi các thành viên trong nhóm, "Các yếu tố [điền vào tên loại] đóng góp vào vấn đề là gì?" Các câu trả lời sau đó được điền vào dưới dạng "xương" trên cá.

    • Sơ đồ xương cá ở trên giúp điều tra các yếu tố có thể góp phần gây ra vấn đề trượt kỳ thi PMI-ACP.

Bước 4: Quyết định việc cần làm - Decide What to Do

Bước cuối cùng trong ba bước giải quyết vấn đề sẽ liên quan đến việc quyết định phải làm gì đối với những vấn đề mà chúng ta đã xác định. Các hoạt động trong bước này là chuyển chúng ta từ suy nghĩ về iteration mà chúng ta vừa hoàn thành sang suy nghĩ về iteration tiếp theo - chúng ta sẽ thay đổi những gì và chúng ta sẽ xử lý các trường hợp khác nhau như thế nào. Quá trình này giúp nhóm tập trung vào việc xác nhận cách tiếp cận của chúng ta và tạo ra các mục tiêu có thể đo lường được để theo dõi tiến độ và giải quyết vấn đề. Chúng giúp xây dựng một loạt các hành động rõ ràng để giải quyết vấn đề, xác định mức độ ưu tiên, tạo kế hoạch chi tiết cho các thử nghiệm và đặt mục tiêu có thể đo lường để đạt được kết quả mong muốn.

Chúng ta có thể sử dụng một số kỹ thuật để giúp quyết định việc cần làm, bao gồm:

  • Short Subjects (Chủ đề ngắn gọn): Nhóm phân loại công việc bằng các đầu mục như “Giữ lại, bỏ qua, thêm” hoặc “Bắt đầu làm, ngừng làm, làm nhiều hơn, làm ít hơn” để xác định các hành động trong việc giải quyết vấn đề.
  • SMART Goals: Cả nhóm gắn mục tiêu cho danh sách các công việc cần làm bằng SMART Goals:
    • Specific: Cụ thể, rõ ràng
    • Measurable: Có thể đo lường
    • Attainable: Có thể đạt được
    • Relevant: Có liên quan
    • Timely: Thời gian rõ ràng
  • Circle of Questions (Vòng tròn câu hỏi): Mỗi người tham gia đặt một câu hỏi xoay vòng về cách cải thiện một trong những vấn đề đã được xác định, sẽ được trả lời bởi người tiếp theo trong vòng.
  • Retrospective Planning Game (Trò chơi lập kế hoạch Retrospective): Trong quá trình này, nhóm lập kế hoạch về các nhiệm vụ cần thiết phải làm để đạt được các mục tiêu cải tiến quy trình mà họ đã xác định cho iteration tiếp theo.

Hãy cùng xem xét chi tiết hơn hai kỹ thuật đầu tiên trong số các kỹ thuật này (Short Subjects và SMART Goals).

  • Short Subjects: Hoạt động này giúp nhóm thống nhất về các hành động giải quyết vấn đề cần theo đuổi. Nhóm tạo một vòng tròn trên giấy hoặc bảng và chia thành các danh mục. Ví dụ:
    • Điều gì đã làm tốt, Làm khác đi ở lần sau
    • Giữ, Bỏ, Thêm
    • Bắt đầu làm, ngưng làm, làm nhiều hơn, làm ít hơn

Hình bên dưới cho thấy một ví dụ về Short Subjects được tổ chức cho một dự án phần mềm. Bản này sử dụng các danh mục: bắt đầu làm, ngưng làm, làm thêm và làm ít đi.

  • SMART Goals:
    • Hoạt động này giúp nhóm tạo ra các mục tiêu: Cụ thể, có thể đo lường, có thể đạt được, có liên quan và có thời hạn rõ ràng (SMART). Các mục tiêu có những đặc điểm này có nhiều khả năng đạt được hơn. Để bắt đầu quá trình xác định SMART Goals, điều phối viên liệt kê các đặc điểm của SMART trên giấy hoặc trên bảng. Sau đó, nhóm xác định sự khác biệt giữa mục tiêu không phải SMART, chẳng hạn như “Chúng ta cần thực hiện nhiều thử nghiệm hơn”, và SMART của mục tiêu đó, chẳng hạn như “Mỗi mô-đun phải vượt qua unit tests, test chức năng và test hệ thống trước khi demo cho khách hàng."
    • Khi mọi người trong nhóm hiểu rõ đặc điểm của SMART Goals, họ chia thành các nhóm nhỏ hơn để chuyển các phương án giải quyết vấn đề mà họ đã xác định thành SMART Goals. Trong một nhóm lớn, người tham gia khi xem xét từng mục tiêu - họ cần thảo luận xem mục tiêu đó có phải là SMART hay không và thực hiện các cải tiến khi cần thiết. Quá trình đảm bảo rằng các mục tiêu có các đặc điểm SMART cũng xác nhận sự hiểu biết của mọi người về những gì sẽ xảy ra và giúp họ thiết lập tinh thần về những gì sẽ được thực hiện để hoàn thành các mục tiêu và giải quyết các vấn đề.

Bước 5: Đóng retrospectives - Close the Retrospective

Bước cuối cùng là kết thúc retrospectives. Tại đây, chúng ta có cơ hội để suy ngẫm về những gì đã xảy ra trong buổi retrospectives và bày tỏ sự cảm ơn của chúng ta dành cho nhau. Các hoạt động trong bước này có thể tóm tắt những gì chúng ta đã quyết định giữ lại hoặc thay đổi. Những hoạt động này giúp hoàn thiện và củng cố giá trị của retrospectives cho dự án.

Có một số hoạt động mà nhóm có thể sử dụng để kết thúc retrospectives, bao gồm:

  • Plus / Delta: Nhóm ghi lại những gì họ muốn làm nhiều hơn (“plus”) và những gì họ muốn thay đổi (“delta”) trong hai cột.
  • Được trợ giúp (Helped), bị cản trở (Hindered), giả thuyết (Hypothesis): Các thành viên trong nhóm cung cấp phản hồi về chính buổi retrospectives đang diễn ra - điều gì đã giúp, điều gì cản trở và bất kỳ ý tưởng nào mà họ đưa ra (“giả thuyết”) để cải thiện các buổi retrospectives trong tương lai.
  • Return on Time Invested - ROTI: Cả nhóm thảo luận về lợi ích của retrospectives và sau đó chấm điểm cuộc họp theo thang điểm 5 để cho biết liệu thời gian của họ bỏ ra có đem lại nhiều lợi ích hay không.
  • Lời cảm ơn (Appreciations): Các thành viên trong nhóm có cơ hội bày tỏ sự cảm ơn của họ với nhau về những nỗ lực cụ thể trong iteration vừa qua.

Để minh họa các loại hoạt động có thể thực hiện để giúp kết thúc quá trình retrospectives, chúng ta sẽ tìm hiểu chi tiết hơn hai loại đầu tiên - “Plus / Delta” và “Helped, Hindered, Hypothesis”.

  • Plus / Delta: Với hoạt động này, chúng ta ghi lại các ý tưởng của mình về những gì chúng ta nên làm nhiều hơn (những điều đang diễn ra tốt đẹp) và những gì chúng ta nên thay đổi (những điều đang diễn ra không tốt) trên một sơ đồ chữ T lên trên giấy hoặc trên bảng, được minh họa bằng hình bên dưới:

 

  • Được trợ giúp (Helped), bị cản trở (Hindered), giả thuyết (Hypothesis)
    • Quá trình này giúp tạo ra phản hồi về chính buổi retrospectives và tạo ra hướng cải tiến mới. Để thực hiện quá trình này, trước tiên chúng ta chuẩn bị ba tờ giấy hoặc bảng và đặt cho chúng các tiêu đề “Được trợ giúp”, “Bị cản trở” và “Giả thuyết”. Chúng ta giải thích với nhóm rằng chúng ta đang tìm cách cải thiện quy trình retrospectives và muốn phản hồi về những gì họ cho là được trợ giúp, đâu là trở ngại và bất kỳ ý tưởng (giả thuyết) nào mà họ có đề xuất để cải thiện các buổi retrospectives trong tương lai. Sau đó, các thành viên trong nhóm viết ý tưởng của họ trên sticky notes và dán notes lên từng bảng thích hợp.

Những sai lầm phổ biến

  • Retrospectives nhằm mục đích trình bày các vấn đề có tác động đối với hiệu suất của nhóm và xây dựng các ý tưởng cải tiến dựa trên những quan sát. Nó sẽ không hữu ích nếu các thành viên không nghiêm túc thực hiện.
  • Mặt khác, retrospectives sẽ thật sự hiệu quả khi các thành viên tham gia cảm thấy thoải mái khi lên tiếng. Điều phối viên có trách nhiệm tạo điều kiện, kết nối các thành viên với nhau; cần lưu ý về các mối quan hệ thứ bậc, ví dụ như sự hiện diện của người quản lý có thể ngăn cản việc thảo luận về các vấn đề hiệu suất của nhóm.
  • Là một cuộc họp với tất cả thành viên, nên có chi phí đáng kể tính theo thời gian. Việc thực hiện kém, hoặc do các nguyên nhân thông thường (thiếu sự chuẩn bị, đi trễ, không chú ý) hoặc từ các nguyên nhân cụ thể đối với hình thức này (thiếu sự tin tưởng và an toàn, các chủ đề cấm kỵ), sẽ dẫn đến việc retrospectives bị mất uy tín, mặc dù phần lớn cộng đồng Agile đánh giá cao retrospectives.
  • Retrospectives hiệu quả thông thường sẽ dẫn đến việc đưa ra các quyết định, phương án ngay sau đó, quá trình này sẽ không hiệu quả khi có quá ít hoặc quá nhiều vấn đề cần giải quyết trong iteration tiếp theo. Một hoặc hai ý tưởng cải tiến cho mỗi iteration là phù hợp nhất.
  • Các vấn đề tương tự xuất hiện ở mỗi cuộc họp retrospectives, mà không có sự cải thiện theo thời gian, có thể báo hiệu rằng họp retrospectives đã trở thành một hoạt động không có giá trị.

Tổng kết

Retrospectives là một công cụ vô cùng giá trị để cải thiện động lực, quy trình và năng suất của nhóm. Retrospectives có thể là một nền tảng tuyệt vời để nhóm đưa ra những lời khen ngợi cho những việc diễn ra tốt, cũng như những lời góp ý về những việc đang bị hạn chế, có vấn đề. Điều quan trọng của nhóm là tập trung vào việc biến những phản hồi, góp ý thành hành động trong tương lai chứ không chỉ đơn giản là “đưa ra những lời than phiền” - nhóm cần ghi lại và thực hiện các cải tiến được xác định, sau đó đánh giá lại trong các buổi retrospectives trong tương lai để xem liệu chúng có tạo ra sự khác biệt hay không. Những buổi retrospectives thành công thường bao gồm việc tạo ra bầu không khí thoải mái nhất. Ban đầu, các thành viên có thể ngại trao đổi, đóng góp ý kiến, nhưng việc lặp lại quy trình này một cách thường xuyên sẽ tạo nên thói quen chia sẻ một cách trung thực của nhóm. Các nhà quản lý và nhà điều hành nên khuyến khích tính trung thực và minh bạch, củng cố khía cạnh “không gian an toàn” của buổi retrospectives.

Kiến thức tổng hợp bởi Trainer Nguyễn Hải Hà (PMP®, PMI-ATP Instructor)

References: PMI ACP Exam Prep Mike Griffiths 2nd Edition, ProductPlan.comagilealliance.org

Product Backlog là gì? Có quan hệ như thế nào với WBS

Bản tuyên ngôn Agile - lịch sử hình thành Agile

12 nguyên tắc của Agile

Trong dự án Agile, công việc ước tính có thật sự cần thiết?

Quản lý dự án với Scrum

Scrum of Scrums

User stories - Công cụ lên kế hoạch của Agile

Story points - Công cụ ước lượng của Agile

Velocity là gì - Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile

Story Map - Lập kế hoạch tổng quát trong Agile

Agile Retrospectives - Nhìn lại và cải tiến hiệu quả công việc dự án

Kanban - phương pháp giúp cải tiến quy trình làm việc của dự án

PDCA - Chu trình cải tiến liên tục

Personas - Công cụ xây dựng hình tượng khách hàng trong Agile

Lean - Tinh gọn hóa quy trình một cách hiệu quả

Hướng Dẫn Scrum 2020 - The Scrum Guide 2020

Bóng đá có 3-5-2, Scrum có 3-5-3

Bắt đầu với Scrum từ đâu đây ta?

Một số cách chạy Daily scrum hiệu quả



Cũ hơn Mới hơn


Thông tin liên hệ

Thông tin chuyển khoản
Công ty Cổ phần ATOHA. Ngân hàng Á Châu (ACB). Số tài khoản: 6868 2468, PGD Tân Sơn Nhì, TPHCM.
Đăng ký khóa học
Chọn khóa học phù hợp bằng cách điền thông tin như link bên dưới. Tư vấn viên Atoha sẽ liên hệ anh/chị ngay.
Câu hỏi thường gặp

“Có. Atoha sẽ có chứng nhận hoàn thành chương trình đào tạo dành cho học viên và cung cấp 35 giờ đào tạo bắt buộc (1 trong 3 điều kiện thi lấy chứng chỉ PMP quốc tế)."

“Cả 2. Tài liệu có thể là tiếng Anh hoặc tiếng Việt tùy vào lớp. Atoha có thể đào tạo bằng cả tiếng Anh hoặc tiếng Việt."

“Chưa bao gồm. Học viên sẽ cần đóng phí thi trực tiếp cho viện PMI nếu muốn đăng ký thi, phí thi tham khảo như sau: 389 USD/non-member và 393 USD/member (trong đó phí thành viên PMI là 99 USD, phí admin là 10 USD, phí thi PMP là 284 USD). Chi phí này dành cho một số khu vực, trong đó có Việt Nam. Tham khảo thêm tại: www.pmi.org"

Liên hệ ngay với Atoha để được tư vấn về chương trình phù hợp