Tôi là người quản lý QA / Test trong tổ chức của mình và cho đến hôm nay tôi đã xác minh chất lượng của phần mềm (các bài kiểm tra được viết và thực thi và đã sửa lỗi). Ai sẽ xác minh điều này trong Scrum? Làm thế nào để tôi biết rằng nhóm đã viết và thực hiện tất cả các bài kiểm tra đúng? Mặt khác, tôi e rằng nếu tôi tiếp tục xác minh, nhóm sẽ không cảm thấy đủ sức mạnh. Nhưng tôi cần một số quy trình xác minh rằng "Xong" thực sự là "Xong". Bạn có đề nghị gì?
Câu trả lời:
Một ý tưởng chính trong Scrum là nhóm nên thống nhất về "định nghĩa hoàn thành". Lý tưởng nhất, đây là một cái gì đó giống như một bộ tiêu chí khách quan mà bất cứ ai cũng có thể xác minh bằng cách đi qua một danh sách kiểm tra.
Nhưng để giảm khả năng xảy ra sự cố, điều hoàn toàn hợp lý là có một quy tắc xác minh "thực hiện" hầu hết được thực hiện bởi một người khác không phải là người thực hiện một mục - hoặc một người QA được chỉ định như bạn (nhưng điều đó có nguy cơ khiến bạn một nút cổ chai).
Nếu nghi ngờ, hãy thảo luận với nhóm và Scrum Master và cùng nhau quyết định.
Tôi nghĩ rằng có một giả định ngầm trong câu hỏi. Có một sự khác biệt giữa "được chấp nhận", khi Chủ sở hữu sản phẩm tuyên bố một mục hoặc công việc tồn đọng đã làm hài lòng Chủ sở hữu sản phẩm và "thực hiện" có nghĩa là tất cả các công việc liên quan đến mục tồn đọng đã hoàn tất.
Tuy nhiên, thường có nhiều nhiệm vụ hơn Chủ sở hữu sản phẩm, thường là một người bán kỹ thuật tốt nhất, bao gồm kiểm tra, tài liệu và đánh giá (tự động và thủ công). Chủ sở hữu sản phẩm hiếm khi ở vị trí để biết các khía cạnh kỹ thuật, chứ chưa nói đến việc chúng có được hoàn thành hay không.
Do đó, cuối cùng nhóm phải xác định "thực hiện" nghĩa là gì. Tổ chức có thể có các tiêu chuẩn và các bên liên quan khác nhau sẽ có yêu cầu riêng. Chủ scrum hoặc người quản lý có liên quan thường chịu trách nhiệm đối chiếu và thi hành danh sách.
Trong ví dụ của bạn, với tư cách là người quản lý QA / Test, bạn là người cho biết các bài kiểm tra đã hoàn thành hay chưa. Tuy nhiên, bạn có thể không phải là người tốt nhất để nói liệu mã đã được xem xét, các yêu cầu bảo mật được đáp ứng, sản phẩm được quốc tế hóa, tài liệu hoàn tất hay bất cứ điều gì khác cấu thành "xong".
Khái niệm duy nhất về "thực hiện" là liệu toàn bộ câu chuyện có được hoàn thành hay không. Nhóm nên tạo ra một định nghĩa hoàn thành cho biết khi nào họ cảm thấy một câu chuyện đã kết thúc hay chưa. Điều này thường bao gồm những thứ như "mã đã được xem xét", "kiểm tra hàng đêm đã được chạy", "tất cả các tiêu chí chấp nhận đã được đáp ứng", v.v. Khi những điều này đã được hoàn thành, nhóm có thể cảm thấy tự tin rằng họ đã làm mọi thứ dự kiến họ sẽ hoàn thành một câu chuyện.
Trong giai đoạn nước rút, nếu bạn đang cố xác định xem một trong những mục trong định nghĩa hoàn thành đã được thực hiện chưa, chỉ cần hỏi. Scrum và nhanh nhẹn là tất cả về giao tiếp mở. Nếu bạn là thành viên của nhóm, hãy hỏi đồng đội của bạn nếu có ai đã viết bài kiểm tra, hoặc điều hành chúng, hoặc tạo công việc hàng đêm, v.v. Nếu bạn là một bên liên quan, hãy hỏi chủ scrum.
Nếu bạn ngồi ngoài nhóm nhưng vẫn phải xem lại các bài kiểm tra, hãy yêu cầu nhóm thêm "các bài kiểm tra phải được xem xét bởi người dùng3251930" như một phần của định nghĩa về việc thực hiện. Nếu đó là những gì nó cần cho một câu chuyện được thực hiện, hãy trung thực về nó và biến nó thành một phần của quá trình. Toàn bộ quan điểm của "định nghĩa hoàn thành" là để nhóm có thể biết chắc chắn rằng họ đã thực hiện những gì được yêu cầu để cung cấp phần mềm chất lượng. Nếu một phần trong đó là một đánh giá bên ngoài, vì vậy hãy là nó.
Cuối cùng, chính chủ sở hữu sản phẩm đã ký vào một câu chuyện cụ thể, vì vậy vào cuối ngày, người đó có quyết định cuối cùng là liệu toàn bộ câu chuyện có được thực hiện hay không.
Câu hỏi đầu tiên bạn nên tự hỏi
Bạn có phải là Scrum Master ? Nếu có.
Trong các quy trình scrum được kiểm soát và quản lý bởi Scrum Master.
Bạn làm nó như thế nào:
Trong giai đoạn yêu cầu, bạn có thể sử dụng các câu chuyện của người dùng cho mỗi câu chuyện cần được xác minh.
Trong mỗi Sprint Các mục công việc được lấy từ tồn đọng sản phẩm và được chỉ đạo bởi chủ sở hữu sản phẩm. Nghiên cứu về chúng cũng sẽ có tiêu chí xác minh.
Bây giờ trong các yêu cầu Scrum không thay đổi sau khi chạy nước rút đã bắt đầu. Khi kết thúc Sprint, bạn có thể phân tích xác minh theo các tiêu chí cho từng mục được thực hiện.
Nếu nó được thực hiện chỉ có thể được tìm thấy bởi phản ứng của chủ sở hữu sản phẩm.
Hãy nhớ trong Agile bạn "Nắm bắt sự thay đổi" thậm chí đến cuối giai đoạn phát triển
Nhóm quyết định. Tôi sử dụng một danh sách kiểm tra, cho những gì được coi là 'Xong'. 'Hoàn thành' trên mỗi câu chuyện, mỗi lần chạy nước rút, mỗi lần phát hành.
Như những người khác đã đề cập, cuối cùng quyết định thuộc về chủ sở hữu sản phẩm.
Đồng ý rằng đây là điều mà nhóm phát triển / thử nghiệm cần xác định, tùy thuộc vào thực tiễn của bạn. Một số dự án chạy nhanh đến mức họ sẵn sàng mạo hiểm phát hành lỗi vào luồng alpha của họ; một số coi bất kỳ lỗi nào nằm ngoài nhóm phát triển là một quá trình thất bại.
Dự án tôi đang thực hiện yêu cầu đánh giá ngang hàng về thay đổi mã và yêu cầu bất kỳ ai đã viết mã đều cung cấp / cập nhật kiểm tra hồi quy hoặc giải thích lý do tại sao không thể thực hiện được. (Họ và người đánh giá của họ cũng phải xác nhận rằng họ đã kiểm tra các thực hành xấu đã biết. Chúng tôi thường hạnh phúc hơn nhiều nếu họ có thể chứng minh rằng họ đã chạy bộ thử nghiệm đầy đủ và đã nhận được kết quả sạch (hoặc modulo sạch Các vấn đề mở, ít nhất) Sau đó, mã phải tồn tại đơn vị tự động chuyên sâu và thử nghiệm chức năng trên nhiều nền tảng để chứng minh rằng nó không gây ra bất kỳ hồi quy nào đối với những điều đó và nó được kiểm tra thêm cho các phản ứng phổ biến bởi hệ thống phân tích mã tự động. sau đó chúng tôi chấp nhận nó vào luồng phát triển chính và đánh dấu mục công việc hoàn thành.
Điều đó rõ ràng không đảm bảo rằng không ai tìm ra cách mới để thất bại, nhưng nó giảm rủi ro xuống mức chấp nhận được mà không cản trở đáng kể tốc độ phát triển.
DonevàUndone