Điều gì xảy ra giữa các lần chạy nước rút?

Tôi đang làm việc trên một dự án lỏng lẻo theo mô hình scrum. Chúng tôi đang chạy nước rút hai tuần. Một cái gì đó tôi không rõ ràng (và không có một cuốn sách để tham khảo) chính xác là những gì sẽ xảy ra giữa các lần chạy nước rút: cần có một quá trình "bọc", trong đó sản phẩm được xây dựng và phân phối, nhưng:

• cái này thường mất bao lâu?
• toàn đội có nên tham gia không?
• nó có hoàn toàn phải hoàn thành trước khi các nhà phát triển bắt đầu làm việc với các mục chạy nước rút tiếp theo không?
• Đây có phải là khi xem xét và kiểm tra mã diễn ra?

Có ba nhà phát triển, thêm tối đa khoảng 1 FTE. Vì vậy, nước rút thực sự rất ngắn.

Tôi đang làm việc trên một dự án lỏng lẻo theo mô hình scrum.

Để làm rõ: Người quản lý của bạn có thể đã nói với bạn về Scrum nhưng những gì bạn thực hiện không phải là Scrum.

Điều này thường mất bao lâu?

Cuộc họp đánh giá Sprint + Cuộc họp hồi cứu Sprint kết thúc nước rút hiện tại. Trong những lần chạy nước rút ngắn, họ nên mất khoảng 30 phút - 1 giờ với nhau. Ngày làm việc tiếp theo bắt đầu một cuộc chạy nước rút mới bằng cách thực hiện cuộc họp lập kế hoạch Sprint 1 và 2. Dựa trên quy mô nhóm và thời gian chạy nước rút, cuộc họp này có thể mất 2 - 4 giờ.

Cả đội có nên tham gia không?

Toàn đội phải tham gia vào các cuộc họp được đề cập trong câu trả lời trước.

Nó có hoàn toàn phải hoàn thành trước khi các nhà phát triển bắt đầu làm việc với các mục chạy nước rút tiếp theo không?

Có bởi vì cho đến khi cuộc họp đánh giá được thực hiện, bạn không biết liệu khách hàng có chấp nhận kết quả của lần chạy nước rút trước đó hay không và bạn không biết những câu chuyện của người dùng sẽ được cam kết trong các cuộc họp lập kế hoạch.

Đây có phải là khi xem xét và kiểm tra mã diễn ra?

Không. Xem xét và kiểm tra mã là một phần của nước rút. Các nhà phát triển phải làm mọi thứ cần thiết để cung cấp mã làm việc thỏa mãn các yêu cầu. Điều này có thể bao gồm các đánh giá mã và nó luôn phải bao gồm một số loại kiểm tra tự động xác thực rằng mã hoạt động và thực hiện những gì nó được thực hiện nếu không câu chuyện của người dùng không thể được coi là đã hoàn thành.

Sự thay đổi tinh thần chính là với QA. Nhiều nhà phát triển nghĩ rằng QA ở đó để xác nhận mã đó hoạt động và thực hiện những gì nó phải làm. Tất nhiên là không. Đó là công việc của nhà phát triển.

QA nên tham gia phát triển sản phẩm. Trách nhiệm chính của họ trong chạy nước rút là liên lạc với chủ sở hữu sản phẩm và tạo ra các thử nghiệm chấp nhận tự động cho các tiêu chí chấp nhận (định nghĩa hoàn thành) sẽ xác thực rằng câu chuyện của người dùng đã thực sự được thực hiện và ứng dụng vượt qua tất cả các yêu cầu mới. Trong các nhóm nhỏ, điều này có thể là trách nhiệm của các nhà phát triển.

QA cũng nên thực hiện một số thử nghiệm thủ công để giữ cho sản phẩm nhất quán và phát hiện ra các tính năng bị thiếu, xác thực trải nghiệm người dùng với UI, v.v. QA không có mặt để tìm lỗi và kiểm tra hồi quy - kiểm tra hồi quy nên được tự động hóa cao.

Theo kinh nghiệm của tôi, đây là nơi mà hầu hết các công ty chuyển sang nhanh nhẹn đều thất bại.

Từ kinh nghiệm của tôi, không có thời gian giữa các lần chạy nước rút, ngoại trừ cuối tuần. Vào giữa cuộc đua nước rút, các đội mà tôi đã từng là thành viên làm việc với chủ sở hữu sản phẩm để thực hiện một số câu chuyện chải chuốt hoặc sơ bộ dựa trên các yêu cầu. Trách nhiệm của chủ sở hữu sản phẩm là giữ cho hồ sơ tồn đọng đầy đủ - những câu chuyện đó là những gì nhóm sẽ làm việc, với một số thông tin từ chủ sở hữu sản phẩm về các ưu tiên. Sau khi chạy nước rút hiện tại, lần chạy nước rút tiếp theo sẽ bắt đầu, sử dụng công việc mà chúng tôi đã đưa vào để chuẩn bị các câu chuyện và nhiệm vụ cho lần chạy nước rút tiếp theo.

Có một số chi phí chung (rất nhiều cuộc họp, hỏi đáp và đánh giá yêu cầu), nhưng nhìn chung nó vẫn hoạt động - chúng tôi đạt được tiến bộ ổn định với ít thời gian. Nước rút thường kéo dài hai hoặc ba tuần. QA thường diễn ra khi câu chuyện được hoàn thành. Tuy nhiên, nhóm QA có thể có các nhiệm vụ khác mà họ có thể làm. Về câu chuyện chải chuốt, nhiệm vụ có thể thuộc về các thành viên cao cấp của đội, hoặc toàn đội. Nó có thể thay đổi tùy thuộc vào quy mô của đội và quy trình đã được thỏa thuận. Đánh giá mã thường diễn ra trong khi QA xảy ra, hoặc vào cuối giai đoạn nước rút nếu thời gian được nén. Và nếu không có đủ thời gian để hoàn thành câu chuyện, trong thực tế, những câu chuyện này được đẩy sang giai đoạn nước rút tiếp theo. Định cỡ và ước lượng thích hợp là rất quan trọng ở đây.

... và khi nào thì ước tính? lập kế hoạch?

Câu chuyện nên thực sự dễ dàng để không có thời gian giữa các lần chạy nước rút.

Và tôi không biết bạn đang nói về loại thử nghiệm nào nhưng các nhà phát triển sẽ tạo ra thử nghiệm đơn vị và tích hợp, không có gì nữa.

Tôi đã làm việc trong một dự án với đôi khi 2 o 3 ngày giữa các lần chạy nước rút và cảm thấy đúng. Bây giờ tôi đang làm việc trên một dự án mà không có thời gian và tất cả đều mờ nhạt. Lần cuối cùng của lần chạy nước rút, chúng tôi đã triển khai sản xuất và phải mất một thời gian trong ngày chạy nước rút cuối cùng của tôi.