Trong Scrum / Agile, làm thế nào để cung cấp công cụ xác thực / quy tắc tăng dần?

Giả sử bạn có một công cụ xác thực cần bao gồm 100 quy tắc để có ích.

Chúng ta cũng giả sử nhóm chỉ có thể cung cấp khoảng 10 quy tắc cho mỗi lần lặp.

Làm thế nào bạn có thể thực hiện một "gia tăng sản phẩm có khả năng đáng tin cậy" vào cuối lần lặp đầu tiên, khi công cụ quy tắc vẫn còn thiếu 90 quy tắc cốt lõi?

Ví dụ, bạn có thêm một lỗi / cảnh báo tạm thời luôn kích hoạt dựa trên thực tế là không phải tất cả các quy tắc đã được thực hiện không?

Chỉnh sửa cho ngữ cảnh: Tôi đang phát triển phần mềm trung gian cho một quy trình kinh doanh phức tạp với nhiều trường hợp sử dụng cũ, nhằm tái tạo và thay thế một khối nguyên khối lớn. Thật khó khăn để phát trực tiếp mà không có bảo hiểm 100%, vì chúng tôi có khả năng hạn chế hoặc quyết định hạn chế những trường hợp sử dụng khó khăn nào sẽ xuất hiện trong sản xuất yêu cầu được bảo trì.

Làm thế nào bạn có thể thực hiện một "gia tăng sản phẩm có khả năng đáng tin cậy" vào cuối lần lặp đầu tiên, khi công cụ quy tắc vẫn còn thiếu 90 quy tắc cốt lõi?

Bạn phát hành mười đầu tiên trong lần chạy nước rút đầu tiên. Chỉ vì nó "có khả năng giải phóng" không có nghĩa là nó phải được sử dụng bởi khách hàng. Điều đó chỉ có nghĩa là chức năng nào đã được thử nghiệm và hoạt động như được thiết kế và không gây ra bất kỳ hồi quy nào trong sản phẩm.

Hãy nghĩ về "có khả năng đáng tin cậy" là "chúng tôi không còn phải làm gì cho tính năng này. Mã đã được thực hiện và nó đã được kiểm tra và ghi lại đúng cách".

Ví dụ, bạn có thêm một lỗi / cảnh báo tạm thời luôn kích hoạt dựa trên thực tế là không phải tất cả các quy tắc đã được thực hiện không?

Đó chắc chắn là điều bạn có thể muốn xem xét, nếu bạn muốn khách hàng thực sự thử nghiệm tính năng này.

Từ Hướng dẫn Scrum, định nghĩa của Phần tăng cho biết :

Khi kết thúc một Sprint, Phần tăng mới phải là Xong, Xỏ có nghĩa là nó phải ở trong tình trạng có thể sử dụng được và đáp ứng định nghĩa của Nhóm Scrum về Xong. Nó phải ở trong tình trạng có thể sử dụng được bất kể Chủ sở hữu sản phẩm có quyết định phát hành nó hay không.

Nếu bạn không hoàn thành đủ các quy tắc, có thể Chủ sở hữu sản phẩm sẽ chọn không phát hành nó. Tuy nhiên, phần Tăng thêm phải là "Xong". Bất kỳ quy tắc nào bạn đã triển khai phải được hoàn thành theo Định nghĩa Hoàn thành của nhóm của bạn.

Các quyết định mà bạn đưa ra phụ thuộc vào những gì sẽ được thực hiện với Phần tăng thêm. Trong câu hỏi của bạn, bạn đề cập đến việc ném ngoại lệ cho các quy tắc chưa được thực hiện. Điều này có thể hoạt động, nhưng nếu ai đó sẽ tích hợp với công cụ quy tắc của bạn, nó có thể tạo ra chi phí cho họ để xử lý trường hợp lỗi này, đặc biệt là nếu nó không tồn tại trong một sản phẩm hoàn chỉnh. Hoặc có thể đó là những gì sẽ làm cho cuộc sống của họ dễ dàng hơn. Xem xét mục đích của Tăng là gì, ai có thể sử dụng nó và đi từ đó.

Bạn đã xác định một tình huống không có lối thoát.

Tôi chắc chắn có những tình huống thực tế trong cuộc sống mà bạn có một khối chức năng phức tạp không thể tách rời. Nhưng trường hợp thông thường là bạn có thể chia một yêu cầu thành các yêu cầu phụ có lợi cho bản thân.

Ví dụ, yêu cầu của tôi là xác thực các địa chỉ thanh toán thẻ tín dụng của Vương quốc Anh. Điều này khá phức tạp, chúng tôi muốn đảm bảo tốt nhất có thể rằng địa chỉ là địa chỉ cư trú của người có tên trên thẻ để nếu họ mặc định thanh toán, chúng tôi có thể đuổi theo họ.

Có khả năng hàng trăm xác nhận và kiểm tra mà chúng tôi có thể làm để cải thiện độ tin cậy của séc, nhưng mỗi cá nhân đều có thể kiểm tra được và giảm rủi ro gian lận thực sự.

• địa chỉ có số nhà và mã bưu điện
• mã bưu điện là định dạng hợp lệ
• tra cứu mã bưu điện với api bên ngoài thành công
• mã bưu điện là mã bưu điện địa lý
• địa chỉ được xác nhận với nhà cung cấp thẻ tín dụng, vv

Nếu thúc đẩy, khách hàng sẽ có thể kiếm tiền chỉ với một tập hợp các quy tắc được thực hiện. Rủi ro thêm có thể được chấp nhận hoặc xung quanh công việc thủ công có thể được thêm vào quy trình làm việc để giảm thiểu tình huống.

Phương pháp Scrum và nhanh nhẹn được thiết kế với ý tưởng này. Họ cố gắng tránh thất bại của toàn bộ dự án bằng cách đảm bảo rằng một số yêu cầu còn thiếu không làm cho toàn bộ giải pháp trở nên vô giá trị.

Nhưng họ không thể thay đổi thực tế, nếu bạn có một tên lửa không gian chắc chắn cần X, Y và Z để bay. Sau đó, bạn cần cả ba!

Bí quyết là nhận ra rằng nhìn chung trong các ứng dụng kinh doanh, đây không phải là trường hợp, mặc dù khách hàng có thể nói gì.