12/08/2018, 17:42

Quick Guide cho Retrospective Meeting: Pattern WHAT-WHY-HOW

Trong thế giới phát triển phần mềm, chúng ta luôn có thể quay lại và sửa chữa sản phẩm. Agile retrospective cho phép chúng ta tạo mẫu nhanh hơn, cung cấp các bản cập nhật mới thường xuyên hơn và hoàn toàn kiểm soát được sự đảm bảo chất lượng của chúng ta. Đó là sức mạnh của Agile. Và tất cả những ...

Trong thế giới phát triển phần mềm, chúng ta luôn có thể quay lại và sửa chữa sản phẩm. Agile retrospective cho phép chúng ta tạo mẫu nhanh hơn, cung cấp các bản cập nhật mới thường xuyên hơn và hoàn toàn kiểm soát được sự đảm bảo chất lượng của chúng ta.

Đó là sức mạnh của Agile. Và tất cả những gì nó cần là một cách tiếp cận có hệ thống nghiêm túc đối với các cuộc họp Retro.

Trong Agile, retrospective ("retro" nghĩa là ngắn) là một loại cuộc họp hậu sản xuất, thường là một giờ dài, mà một team nắm giữ sau mỗi Sprint. Trong quá trình Retro, các developer thảo luận về những thành công và thất bại mà họ phải đối mặt trong giai đoạn này.

Mục đích của Agile retrospectives là xác định nguyên nhân gốc rễ của mọi vấn đề và tìm cách tránh chúng trong tương lai.

Đúng là cải tiến liên tục nên được thực hiện trong quá trình sản xuất giống như sau khi sản xuất. Tuy nhiên, khi mọi người đang bận rộn làm việc thì khó có thể bắt đầu bất kỳ sáng kiến mới nào.

Ngược lại, mặt khác, tạo ra không gian cho ý tưởng và thời gian để tập hợp lại trước giai đoạn tiếp theo. Team của bạn có thể thư giãn và tập trung vào việc cải thiện sự cộng tác và hiệu quả.

Sau Retro, đó là một danh sách được liệt kê các điểm phác thảo các lĩnh vực và ý tưởng cải tiến. Mỗi lần Retro, team quay trở lại danh sách trước đó và điều chỉnh danh sách mới cho phù hợp. Cuộc họp thường xuyên diễn ra là chìa khóa ở đây.

Các quy trình hàng ngày thích cải tiến liên tục nhưng chúng ta không có thời gian cho việc thực sự thực hiện nó.

Ngoài ra, khi các member của team làm việc trên các cải tiến riêng biệt, việc xảy ra sub-optimization là điều hiển nhiên. Cá nhân hoạt động tốt hơn, nhưng dự án tổng thể vẫn có thể thất bại.

Agile retrospective cho phép chúng ta đưa mọi thứ vào từng phần. Theo nguyên tắc cuối cùng của tuyên ngôn Agile: "Thường xuyên, team nghiên cứu phản ánh về cách trở nên hiệu quả hơn, sau đó lên dây cót và điều chỉnh hành vi của nó cho phù hợp."

Đó là không thể thiếu được kết nối với một nguyên tắc Agile khác: "Liên tục chú ý đến kỹ thuật xuất sắc và thiết kế tốt giúp tăng cường sự nhanh nhẹn."

Những người có thể dựa vào nhau và cùng nhau theo đuổi sự xuất sắc kỹ thuật tạo ra những team có hiệu suất tốt nhất. Họ tiết kiệm rất nhiều thời gian và nguồn lực cho cả bản thân và công ty.

Các team thực hành các cuộc họp Retro loại bỏ các vấn đề định kỳ, cải thiện quy trình làm việc của họ và cung cấp các sản phẩm tốt hơn nhanh hơn. Họ cũng đặt tốc độ cho phần còn lại của công ty, thúc đẩy các team khác cải thiện.

Một số benefit khác

Nuôi dưỡng văn hóa cải tiến liên tục

Tìm kiếm những cách hiệu quả nhất để phân phối giá trị cùng nhau tạo ra môi trường chất xúc tác cho những thay đổi.

Trao quyền cho team

Retrospective cho phép các member của team đưa ra quyết định riêng của họ chấp nhận trách nhiệm. Kết quả là, team của bạn sẽ phát triển trong sự trưởng thành và self-motivation.

Giúp xây dựng team

Retro mang mọi người lại gần nhau và nếu được thực hiện đúng cách - hãy đào tạo họ để hiểu rõ hơn và hữu ích cho người khác.

Đập tan những thất vọng

Bất kỳ vấn đề nào tại nơi làm việc đều là vấn đề của con người hoặc ảnh hưởng đến cá nhân. Các cuộc họp Agile tạo ra một không gian thoải mái để nói về và giảm bớt những thất vọng đó.

Retro là tuyệt vời, nhưng nó cũng rất dễ dàng trở thành phiền phức.

Đây là những gì bạn nên tránh:

Phàn nàn vô ích

Đừng để cuộc họp của bạn trở thành thuốc độc. Hãy để mọi người nói ra về sự thất vọng của họ, nhưng giữ cho nó mang tính xây dựng. Tìm giải pháp cho các vấn đề quan trọng hơn là nói về chúng.

Chán nản

Bạn không phải giải trí mọi người, chỉ giúp họ tập trung. Các dự án dài đốt cháy sự nhiệt tình - điều đó là bình thường. Tạo thói quen thú vị với các ý tưởng và cách tiếp cận Retro meeting mới liên tục.

Rò rỉ thông tin

Đảm bảo mọi thành viên trong nhóm cảm thấy an toàn để chia sẻ thông tin chi tiết của họ.

Checklist của team bị overload

Cố gắng cải thiện mọi thứ cùng một lúc là nguy hiểm. Đánh độ ưu tiên và sử dụng các kế hoạch hành động ngắn, thiết thực.

Và, cuối cùng, hãy đảm bảo rằng với tư cách là người leader, bạn:

Có một kế hoạch

Các PM hoặc Scrum Master điều hành cuộc họp phải chuẩn bị trước. Bạn cũng phải lập kế hoạch các cuộc họp thường xuyên trong tương lai.

Hãy là người điều phối

Chủ động lead cuộc họp Retro, khuyến khích thảo luận và ghi chép. Hãy chắc chắn rằng mọi thành viên trong nhóm cảm thấy được hoan nghênh tham gia.

Phê bình quy trình, không phải mọi người

Tập trung vào WHAT, không phải WHO - xác định các vấn đề hành vi và giúp giải quyết chúng với sự hiểu biết.

Thực hành những gì bạn nói

Đưa ra ví dụ phù hợp là cách tốt nhất để xây dựng thẩm quyền. Chấp nhận và giữ trách nhiệm. Sở hữu các quyết định của bạn nhiều như bạn sở hữu các cuộc họp.

Phân tích luồng công việc

Là người quản lý, bạn có thể quan sát quy trình làm việc từ trên xuống dưới. Tìm kiếm các điểm trong quá trình cần cải thiện. Hãy nghĩ về những trở ngại chính trong quy trình làm việc hàng ngày và cách chúng có thể được loại bỏ.

Xây dựng team

Chúng tôi đã đề cập đến điều này trước đó và có thể thêm nhiều hơn nữa. Chỉ cần nhớ rằng "P trong PM là nhiều về" quản lý con người "vì nó là về" quản lý dự án ".

Đừng quên tóm tắt

Sau Retro meeting thì mong muốn là nhận được danh sách việc cần làm thực tế ở cuối nó. Sử dụng phương pháp Who-What-When - nó sẽ dễ dàng hơn cho bạn để quản lý các trách nhiệm về task's schedule.

Hy vọng rằng, bây giờ bạn đã hiểu đủ để tổ chức Agile Retro meeitng đầu tiên của bạn. Và nếu ma thuật không xảy ra, đừng bỏ cuộc - hãy tập trung vào cải tiến liên tục. Xét cho cùng, đó chính xác là Agile.

0