Scrum - Các thành viên trong nhóm bận rộn với việc chạy nước rút là gì

Vì vậy, chạy nước rút scrum là một khoảng thời gian cố định trong đó một bộ tính năng cụ thể sẽ được triển khai. Và một nhóm scrum bao gồm tất cả những người cam kết cung cấp các tính năng đó, phần lớn trong số họ thường là nhà phát triển và người thử nghiệm.

Khi thiết lập các quy tắc này, người ta có thể tự hỏi làm thế nào để giữ cho tất cả những người này bận rộn trong suốt quá trình nước rút. Khi bắt đầu chạy nước rút, không có gì để kiểm tra, và ở cuối giai đoạn nước rút, thường không còn gì hoặc rất ít để phát triển / sửa chữa.

Tôi đã thấy 2 cách tiếp cận để xử lý vấn đề này, nhưng cả hai cách này dường như không giải quyết được vấn đề.

1) Hãy để các thành viên trong nhóm quyết định phải làm gì mỗi khi hết nhiệm vụ.

Nhược điểm:

• Nếu những gì họ làm không được lên kế hoạch kỹ lưỡng (nghĩa là tái cấu trúc chính, chuyển sang khung thử nghiệm mới), công việc của họ có thể trở nên vô dụng hoặc bị kẹt giữa chừng
• Mặt khác, việc lập kế hoạch cho công việc như vậy có thể mất nhiều thời gian và khách hàng có thể thất vọng khi thấy nhóm lãng phí thời gian vào thứ gì đó không mang lại giá trị ngay lập tức
• Những nhiệm vụ như vậy thường không thể được ước tính kỹ lưỡng, do đó, thật dễ dàng cho những người lao động không có kinh nghiệm dành thời gian xem mèo YouTube mà không bị phản ánh trên bảng scrum hoặc bất cứ nơi nào khác

2) Chỉ dành chỗ cho lần chạy nước rút để phát triển và bắt đầu thử nghiệm sau khi chạy nước rút kết thúc (khi nhà phát triển bắt đầu làm việc với các tính năng từ lần chạy nước rút tiếp theo)

Nhược điểm:

• Trong khi phát triển các tính năng cho lần chạy nước rút hiện tại, các nhà phát triển bị phân tâm khi sửa các lỗi từ lần trước và họ có thể không thực hiện được số lượng công việc được ước tính sẽ được thực hiện trong giai đoạn nước rút hiện tại
• Cần có hai bảng scrum: một cho các tính năng chạy nước rút hiện tại và một cho các lỗi chạy nước rút trước đó

Vì vậy, câu hỏi của tôi là: làm thế nào để phân phối công việc đúng cách trong giai đoạn nước rút giữa nhà phát triển và người thử nghiệm để không ai bị quá tải với công việc hoặc kết thúc mà không có nhiệm vụ tại bất kỳ điểm nào? Có cách nào để cải thiện các phương pháp được mô tả ở trên? Hoặc có cách tiếp cận nào tốt hơn?

Khi bắt đầu nước rút, không có gì để kiểm tra

Có thật không? Bạn không có yêu cầu để xác nhận? Không có thảo luận để có với khách hàng của bạn? Không có khung dây để đánh giá? Không có kế hoạch kiểm tra để suy nghĩ về?

ở cuối giai đoạn nước rút thường không còn gì hoặc rất ít để phát triển / sửa chữa

Tôi chưa bao giờ ở nơi đó trong một dự án. Không còn việc để làm? Luôn luôn có một cái gì đó. Có phải tất cả các bài kiểm tra của bạn hoàn toàn tự động? CI của bạn trông như thế nào? Lớp truy cập cơ sở dữ liệu có thể được cấu trúc lại để đơn giản hơn không? Và tôi chưa bao giờ làm việc trên bất cứ thứ gì có danh sách lỗi và tồn đọng. Các nhà phát triển của bạn đã từng làm gì trong giai đoạn thử nghiệm thác nước?

Tôi biết một số người rất tôn giáo về những gì không phải là 'SCRUM'. Tôi không thể quan tâm đến điều đó. Nhưng tôi nghĩ bạn có hai vấn đề ở đây:

1. Bộ phận QA 'truyền thống' kiểm tra mã một khi nó được 'hoàn thành' bởi các nhà phát triển thay vì làm việc với khách hàng và nhà phát triển để đảm bảo bạn đang xây dựng đúng thứ cũng như xây dựng đúng. Hãy xem các góc phần tư thử nghiệm nhanh của Lisa Crispin. Những người kiểm thử tốt nhất tham gia vào mọi giai đoạn của vòng đời phát triển phần mềm và những người phát triển tốt nhất viết những bài kiểm tra của riêng họ.

2. Cố gắng bám sát vào thời gian biểu của SCRUM trong 1 tuần / 2 tuần nước rút mà không có một hồ sơ tồn đọng ưu tiên và có kích thước được chia thành các nhiệm vụ đủ dễ dàng để hoàn thành trong một khoảng thời gian ngắn trong một lần chạy nước rút. Nếu bạn có điều này thì sẽ luôn có nhiều việc để làm. Có thể tính năng cuối cùng bạn làm trong lần chạy nước rút này không có trong bản phát hành của lần chạy nước rút này, nhưng nó luôn có thể đi vào phần tiếp theo.

Qua một bên. Nếu bạn có một nhóm gắn kết nhỏ thì vai trò ít quan trọng hơn. Thay vì có ai đó với người kiểm thử nhãn không được phép viết mã sản xuất hoặc ai đó gắn nhãn nhà phát triển nghĩ rằng họ đang thử nghiệm ở trên, mọi người nên làm bất cứ điều gì cần thiết để nhóm thành công, bao gồm các nhiệm vụ quản lý dự án đáng sợ khi chúng là cần thiết, đây được gọi là một nhóm chức năng chéo.

Thêm một điểm nữa được đưa ra bởi @Cort Ammon trong các bình luận. Bản tuyên ngôn nhanh nhẹn nói về sự hợp tác của khách hàng trong quá trình đàm phán hợp đồng. Bạn nói thế:

khách hàng có thể thất vọng khi thấy nhóm lãng phí thời gian vào thứ gì đó không mang lại giá trị ngay lập tức

Có thể khó giải thích và tôi hiểu khách hàng đôi khi có thể rất khó khăn nhưng đây sẽ là một lá cờ đỏ lớn đối với tôi. Họ đang tin tưởng bạn với mã nguồn / mối quan hệ khách hàng / doanh nghiệp / bất cứ điều gì bạn đang phát triển cho họ. Nếu họ không thể tin tưởng bạn hành động chuyên nghiệp vì lợi ích tốt nhất của họ thì bạn có vấn đề hoặc họ làm.

Tôi đã viết một bài đăng nói về các nhà phát triển phần mềm không được coi là chuyên gia. Một bác sĩ chuyên nghiệp, luật sư, kỹ sư dân sự phải đối mặt với một khách hàng đã thay đổi các yêu cầu trên chúng một phần thông qua sẽ không chỉ làm giảm chất lượng và than vãn về nó. Họ sẽ nói với khách hàng của họ rằng đó sẽ là một vấn đề. Nếu khách hàng thúc đẩy thì một chuyên gia sẽ không chỉ mù quáng làm điều đó đến một tiêu chuẩn thấp kém nguy hiểm bởi vì họ sẽ phải chịu trách nhiệm. Chúng tôi không làm bài kiểm tra đầu vào chuyên nghiệp và vì vậy không chịu trách nhiệm. Điều đó không có nghĩa là chúng ta không nên cố gắng trở nên tốt hơn.

Tóm lại, tôi sẽ không lo lắng quá nhiều về việc cố gắng làm cho mọi người trở nên hiệu quả hơn vào lúc bắt đầu và kết thúc cuộc chạy nước rút mà chỉ xem đó là một triệu chứng của một vấn đề rộng lớn hơn trong nhóm. Bạn đã nghe nói về lập trình eXtreme (XP) . Tôi muốn nói rằng các nguyên tắc từ XP để áp dụng ở đây là giao tiếp và tôn trọng:

• Tôn trọng nhóm của bạn để làm những gì họ nghĩ là tốt nhất. Tôi sẽ lập luận rằng nếu có nhiều người xem video về mèo thì bạn có nhà phát triển kém hoặc bạn đang đối xử với họ không tốt.
• Giao tiếp. Nếu các nhà phát triển của bạn đang nói chuyện với nhau, với người kiểm tra, quản lý, với khách hàng, thì mọi người có lẽ nên có cảm giác tốt về những gì tiếp theo và nếu họ không thì họ chỉ có thể hỏi.

Điểm đầu tiên là Scrum là tất cả về tối ưu hóa nhóm , không phải mỗi cá nhân. Nếu nhóm làm việc hiệu quả và hiệu quả, sẽ không có vấn đề gì nếu ai đó nhàn rỗi khi bắt đầu hoặc kết thúc nhiệm vụ.

Tuy nhiên, trên mỗi đội tôi đã tham gia, luôn có rất nhiều công việc. Hãy để tôi giải quyết một vài mối quan tâm cụ thể của bạn:

Khi bắt đầu nước rút, không có gì để kiểm tra cả,

Mặc dù điều đó có thể đúng theo nghĩa đen, nhưng nó ngụ ý rằng bạn nghĩ công việc duy nhất cho người thử nghiệm là "kiểm tra". Có rất nhiều điều có thể được thực hiện trước khi họ bắt đầu thử nghiệm. Đối với một, họ có thể gặp chủ sở hữu sản phẩm và nhà phát triển để hiểu đầy đủ các yêu cầu. Họ có thể bận rộn làm việc trên một kế hoạch kiểm tra, thu thập dữ liệu kiểm tra, v.v. Nếu họ có sự sang trọng của một khuôn khổ tốt, họ có thể bắt đầu viết các bài kiểm tra tự động trước thời hạn.

ở cuối giai đoạn nước rút thường không còn gì hoặc rất ít để phát triển / sửa chữa

Tôi vẫn chưa thấy một nhóm phát triển đã hết những thứ cần khắc phục. Tuy nhiên, đó không phải là điều họ nên làm vào cuối giai đoạn nước rút. Đến cuối giai đoạn nước rút, họ nên giúp người kiểm tra kiểm tra sản phẩm. Họ có thể giúp viết bài kiểm tra tự động, họ có thể kiểm tra mã và kiểm tra / từ khóa / vv được viết bởi người kiểm tra. Họ có thể làm việc với nhóm tài liệu để giúp họ hoàn thành công việc, v.v.

Tôi đã thấy 2 cách tiếp cận để xử lý việc này ... 1) Hãy để các thành viên trong nhóm quyết định phải làm gì mỗi khi họ hết nhiệm vụ.

Lỗ hổng trong suy nghĩ của bạn là các cá nhân hết nhiệm vụ. Nhiệm vụ thuộc về toàn bộ đội. Họ không nên làm công việc khác miễn là có bất kỳ câu chuyện hoặc nhiệm vụ nào còn lại cho nhóm trong giai đoạn nước rút hiện tại.

Nhường chỗ trong nước rút chỉ để phát triển,

Cách tiếp cận này không nằm trong định nghĩa truyền thống về scrum hoặc agile. Toàn bộ điểm nhanh nhẹn là toàn bộ nhóm tham gia làm việc hướng tới một mục tiêu chung. Điều đó có nghĩa là tất cả các công việc cần thiết để hoàn thành một câu chuyện phải được thể hiện trong một lần chạy nước rút - thiết kế, phát triển, thử nghiệm, tài liệu, v.v.

Cuối cùng, đây không phải là giải pháp khả thi duy nhất khác. Bạn bỏ qua giải pháp thực sự, đó là mọi thành viên trong nhóm nên tham gia khi cần thiết để giúp hoàn thành câu chuyện trong giai đoạn nước rút.

Mục tiêu là mục tiêu của nhóm , nhưng bạn đang viết như thể mỗi cá nhân có mục tiêu riêng ("hoàn thành nhiệm vụ của tôi"). Nếu ai đó không có gì để làm, họ có thể thấy những gì hiện đang được thực hiện và đề nghị giúp đỡ. Hoặc, họ có thể thực hiện nhiệm vụ hoặc câu chuyện tiếp theo và bắt đầu thực hiện nó.

Trong tất cả các cửa hàng nhanh nhẹn mà tôi đã làm việc, những người thử nghiệm được coi là gà để họ không bị mất thời gian trong giai đoạn nước rút như các nhà phát triển. Trước khi có được phần mềm, người kiểm tra nên viết kế hoạch và đảm bảo môi trường được thiết lập đúng để nhận phần mềm. Là một phần của việc này, họ nên chú ý đến bất kỳ tài liệu thiết kế nào như chúng.

Tiếp theo, bạn nên tìm kiếm để điền vào nước rút. Không nên có bất kỳ thời gian rảnh rỗi nào ở cuối giai đoạn nước rút nếu các ước tính là tốt mặc dù ước tính tất nhiên là một nghệ thuật đen để nó hiếm khi điền chính xác .

Nếu một nhà phát triển có thời gian rảnh rỗi ở cuối giai đoạn nước rút, thì thời gian này vẫn nên được theo dõi để đảm bảo rằng nó đang tăng thêm giá trị (học một khung mới, thực hiện phân tích, thử nghiệm thêm, v.v.).

Sửa lỗi là một hoạt động hoàn toàn chấp nhận được để đưa vào chạy nước rút. Nó đóng góp cho một tính năng và do đó thêm giá trị. Điều này không nên được xem là thời gian bị đánh cắp từ lần chạy nước rút tiếp theo - hoàn thiện đúng hơn một tính năng.

Trong một thế giới lý tưởng, nhóm của bạn sẽ có nhiều chức năng . Mọi người đều có chuyên môn của mình, nhưng mọi người đều có thể làm việc như một chuyên môn khác. Nếu người kiểm tra của bạn không thể mã hóa các tác vụ đơn giản nhất, thì bạn không có nhóm chức năng chéo.

Cách SCRUM sẽ cho phép nhóm của bạn để được cross chức năng. Người kiểm tra của bạn nên có kỹ năng tự động hóa kiểm tra dù sao, đó là một bước ngắn để mã hóa một số điều ít phức tạp hơn.