Đặc trưng mô hình Scrum, những sai lầm thường mắc phải khi tiến hành một buổi Daily Stand-up Meeting và một số hướng khắc phục

** I: Scrum và những đặc trưng cơ bản: **

Trong những thập niên gần đây, mô hình phát triển phần mềm đang rất được ưu chuộng là Agile và Scrum đã trở thành một trong những qui trình Agile có những giá trị và nguyên lý như mô tả trong Tuyên ngôn Agile.

Sau đây tôi xin mô tả chi tiết hơn về Scrum:

• SCRUM là một phương thức phát triển phần mềm chỉ ra cách để Team làm việc một cách hiệu quả để tạo ra sản phẩm phần mềm.  Với nguyên tắc là chia nhỏ phần mềm ra thành các phần nhỏ để phát triển.

Với các tính chất đặc trưng là:

• Tập trung vào sản phẩm, sản phẩm mới là đích cuối cùng chứ không phải qui trình.

• Thích ứng nhanh với thay đổi requirement.

• Nhấn mạnh vai trò của Team, Team là người đưa ra giải pháp và thực hiện.

• Tạo nên sự tương tác cao giữa khách hàng, nhóm phát triển sản phẩm để đảm bảo sản phẩm đầu ra đúng với yêu cầu của khách hàng.

  Daily Scrum Meeting là cuộc họp hàng ngày và được đề nghị không quá 15 phút và họp đứng để đảm bảo thời gian họp không bị kéo dài vào đầu mỗi ngày, mỗi thành viên chỉ trả lời 3 câu hỏi:

  • Công việc đã làm hôm qua.
  • Có vấn đề phát sinh hay ko?
  • Plan cho hôm nay là gì?

Team member tham gia họp Scrum hằng ngày để đánh giá tiến độ công việc hướng tới Mục tiêu Sprint và đánh giá xu hướng tiến triển của công việc trong Sprint Backlog.

Hằng ngày, Nhóm Phát triển có thể giải thích cho Product Owner và Scrum Master biết họ định làm gì với tư cách là một nhóm tự quản để hoàn thành mục tiêu và tạo ra các phần tăng trưởng cần thiết trong Sprint.

Scrum Master đảm bảo cho Nhóm Phát triển tham gia họp, nhưng chính Nhóm Phát triển mới có trách nhiệm chính trong cuộc họp Scrum Hằng ngày. Scrum Master phải hướng dẫn cho Nhóm Phát triển biết cách giữ cuộc họp ngắn gọn trong phạm vi khung thời gian 15 phút.

Scrum Master đảm bảo cuộc họp này được thực hiện đúng qui định.

Họp Scrum Hằng ngày sẽ cải tiến quá trình giao tiếp, lược bỏ các buổi họp hành không cần thiết, nhận biết và loại bỏ các trở lực trong quá trình phát triển vầ giúp đưa ra quyết định nhanh chóng và nâng cao mức độ hiểu biết của Nhóm Phát triển về dự án.

**II: Những sai lầm thường mắc phải khi tiến hành Daily Stand-up Meeting **

Nghe thì có vẻ đơn giản và dễ thực hiện. Thế nhưng, có phải bất kỳ đội dự án nào cũng tuân thủ một cách nghiêm túc theo các chuẩn mực mà một Daily Stand-up Meeting yêu cầu.

Sau đây, tôi xin đưa ra một số sai lầm căn bản mà các Scrum team này thường gặp phải trong những buổi Daily Stand-up Meeting như sau:

1. Daily Stand-up Meeting không diễn ra đúng thời gian quy định.

Ví dụ 1: Một đội Scrum với lịch meeting hàng ngày diễn ra lúc 09:00 AM. Nhưng trên thực tế thì meeting diễn ra lúc 09:04 AM.

Sau đó vào lúc 09:09 AM, bất ngờ có một thành viên khác mới đến họp. Vậy team này có nhiều hơn 9 thành viên? Thành viên tham gia muộn này có tham gia báo cáo tiến độ cuối cùng?

===> Cậu ấy là thành viên của đội phát triển? Cậu ấy đóng vai trò gì trong buổi meeting?.

Tính kỷ luật để duy trì meeting giữa các thành viên trong team được trao đổi như thế nào?

Với các dự án Agile, tính kỷ luật là một điều rất quan trọng. Nếu thời gian bắt đầu không được các thành viên tuân thủ thì làm sao họ giữ được timebox cho các sự kiện khác, chưa đề cập đến việc họ có xu hướng không giữ được cam kết của bản thân với dự án mà họ đảm nhận, bao gồm cả cam kết chung của team cho sprint.

===> Scrum Master là người cần giúp team xây dựng ý thức tính kỷ luật. Thời điểm meeting cần bắt đầu đúng giờ như đã định trước, tất cả các thành viên cần tạm ngưng công việc để tham gia meeting.

Ví dụ 2: Giành cho những đội dự án làm việc theo phương thức Remote chẳng hạn.

Đó là khi các thành viên trong đội dự án không làm việc với nhau trong cùng một văn phòng. Khoảng cách địa lý buộc team phải sử dụng các phương tiện giao tiếp trực tuyến như Call Skype, Google Hangout... để mọi người cùng tham gia cuộc họp.

Khi cuộc họp chuẩn bị bắt đầu hoặc đang diễn ra mà văn phòng bị cúp điện, đường truyền Internet có trục trặc hoặc máy tính của một ai đó bất ngờ gặp sự cố.

Dù muốn hay không muốn, cuộc họp vẫn sẽ bị gián đoạn, phải kéo dài thời gian để khắc phục sự cố hay thậm chí là bị trì hoãn.

===> Đây có thể coi là lý do khách quan nhưng đội dự án cũng cần phải tính đến và có những biện pháp tối ưu hóa nhằm khắc phục sự cố và hạn chế tối đa sự bất tiện này.

2. Daily Stand-up Meeting không chỉ dành riêng cho Scrum Master

Trong khi các thành viên của đội dự án báo cáo tiến độ, họ vẫn duy trì giao tiếp bằng mắt với Scrum Master và Scrum Master lúc thì gật đầu, lúc thì lắc để đáp lại. Có vài thành viên còn lại thì tán gẫu với nhau, một thành viên khác liên tục bấm điện thoại, số khác thì hướng mắt về thành viên đang báo cáo, các bạn khác thì nhìn về hướng Scrum Master.

Đây là dấu hiệu của môi trường thiếu hợp tác, thụ động. Scrum Master có trách nhiệm sửa chửa chúng. Chính thái độ của Scrum Master đã làm cho tính tương tác trong team khó mà đạt hiệu quả.

Không có thành viên nào chủ động chia sẻ trở ngại của họ cho đến khí Scrum Master đặt câu hỏi và cũng không có thành viên nào chủ động đưa ra hướng giải quyết giúp thành viên đang gặp khó khăn cho đến khi được Scrum Master chỉ định.

===> Daily Stand-up Meeting là sự kiện của team, của các thành viên trong team, mọi người đều có trách nhiệm giám sát các thành viên còn lại và đưa ra sự hỗ trợ nếu bất kỳ thành viên nào gặp trở ngại.

Scrum Master chỉ là người tạo điều kiện cho team hoàn thành meeting và ghi lại các trở ngại nếu có. Đây là cơ sở giúp team xây dựng được khả năng tự quản. Đội dự án đôi khi phải tự mình đặt ra những nguyên tắc riêng cho các thành viên để họ tự mình ý thức về vài trò và trách nhiệm của mình trong từng cuộc họp. Đồng thời, giúp họ nhận ra rằng những hành động không đáng có của mình có thể ảnh hưởng tiêu cực đến những người khác và cục diện cuộc họp như thế nào.

** 3. Daily Stand-up Meeting không phải là cuộc thảo luận kỹ thuật và là nơi các thành viên ngoài team chia sẻ quan điểm của họ **

Có vài thành viên bắt đầu xác nhận yêu cầu kỹ thuật chi tiết về công việc họ đang làm và các thành viên còn lại chia sẻ quan điểm thiết kế, cách triển khai source code. Thành viên hỗ trợ kiến trúc hệ thống (thành viên không tham gia cam kết trong sprint) tư vấn hướng giải quyết. Và đây chính là nguyên nhân sâu xa của việc trượt timebox của sự kiện Daily Stand-up Meeting.

===> Daily Stand-up Meeting không phải là thời gian để thảo luận các vấn đề kỹ thuật ở mức chi tiết, mọi người có thể nêu ra các vấn đề đang gặp phải và các thành viên còn lại nhận trách nhiệm hỗ trợ, họ sẽ thảo luận chi tiết với nhau sau khi meeting kết thúc và chia sẻ kết quả xử lý cho cả team ở buổi meeting kế tiếp. Bên cạnh đó chỉ những thành viên tham gia cam kết mới được phép chia sẻ quan điểm, nhưng chỉ dừng lại ở mức ngắn gọn. Những thành viên không tham gia cam kết có thể hiện diện (kể cả quản lý) nhưng chỉ quan sát và lắng nghe mà thôi. Scrum Master có trách nhiệm tạo điều kiện và bảo vệ team để cả team có thể hoàn thành công việc quản lý của mình.

4. Daily Stand-up Meeting phải đảm bảo đủ ba câu hỏi

Tại thời điểm từng thành viên báo cáo công việc của mình, hầu hết mỗi thành viên bắt đầu báo cáo tiến độ của mình nhưng họ chỉ dừng lại với 2 câu hỏi:

Họ đã làm gì ở ngày hôm qua? Một thành viên chia sẻ rằng họ đã hoàn thành 90% công việc. Nhưng trên thực tế, task dưới là có thời gian ước lượng là 7 giờ và bắt đầu từ đầu giờ của ngày hôm qua và spent time đã là 8 giờ. Rõ ràng đây là task đã bị trượt nhưng không ai hỏi gì thêm. Họ đang làm gì ở thời điểm hiện tại? Một số thành viên khác thì chia sẻ “Hôm nay tôi sẽ làm công việc này, công việc kia…”. Họ quên mất rằng hầu hết team bắt đầu công việc từ lúc 08:00 AM, và từ “sẽ” đã nói lên rất nhiều điều bất thường.

Không một ai trong team chủ động chia sẻ về trở ngại hoặc rủi ro cho đến khi Scrum Master hỏi. Không một ai chủ động đưa ra yêu cầu cần hỗ trợ và không một ai chủ động sẵn sàng hỗ trợ. Sau khi Scrum Master truy hỏi thì mới trình bày có hai vấn đề kỷ thuật đang gặp khó khăn trong việc triển khai source code.

Khi có một task trượt so với thời gian ước lượng đồng nghĩa task đó có trở ngại – Impediment/block. Tất cả các thành viên không chủ động trả lời câu hỏi thứ 3 “Họ đang gặp những trở ngại gì?” đồng nghĩa với khả năng tự quản của team này chưa thật sự sẵn sàng để cùng hướng đến hoàn thành sprint goals.

===> Với bất kỳ đội dự án nào thì đây chính là vấn đề nghiêm trọng nhất mà họ phải đối mặt bởi sự phức tạp và diễn biến ngầm của nó. Nếu không khắc phục kịp thời, dự án sẽ bị đẩy đi và trượt dài theo chiều hướng tiêu cực. Thậm chí, nếu sự can thiệp là không kịp thời thì nguy cơ dự án bị vỡ là điều hoàn toàn có thể xảy ra. Vì mức độ nghiêm trọng của nó mà đòi hỏi độ dự án phải đề ra một số yêu cầu hết sức chặt chẽ đối với các thành viên, đòi hỏi họ phải đưa ra đầy đủ câu trả lời đảm bảo cho 3 câu hỏi:

• Tôi đã làm những gì kể từ hôm qua để giúp Nhóm Phát triển đạt được Mục tiêu Sprint?
• Tôi sẽ làm những gì hôm nay để giúp Nhóm Phát triển đạt được Mục tiêu Sprint?
• Tôi có nhìn thấy vấn đề gì cản trở Nhóm Phát triển đạt được Mục tiêu Sprint?

Nếu thật sự các vấn đề có phần phức tạp thì việc yêu cầu thành viên đội dự án cung cấp các tài liệu liên quan để miêu tả chi tiết hơn sau khi kết thúc cuộc họp cho toàn đội hoặc những người liên quan, người chịu ảnh hưởng cùng được biết, để sớm tìm ra hướng giải quyết, hạn chế tối đa rủi ro cho dự án.

Kết luận: Trên đây chỉ là một số sai lầm cơ bản chúng ta hay mắc phải trong Daily Satnd-up Meeting - hầu hết những sai lầm này đều bắt nguồn từ thái độ làm việc, khả năng, kỹ năng của từng thành viên trong dự án. Vậy tại sao chúng ta không tìm cách cải thiện nó để đạt được hiệu quả cao?

Nguồn: https://vi.wikipedia.org/wiki/Scrum_(mô_hình_phát_triển_phần_mềm)

http://www.apexglobal.com.vn/en/nhung-sai-lam-thuong-gap-o-daily-stand-up-meeting-trong-du-an-agile/