Làm thế nào chúng ta nên xử lý các tính năng mỹ phẩm bổ sung trong nước rút Scrum?

Tôi đã đọc các tài liệu Scrum và nó nói rằng các nhiệm vụ trong Sprint phải là "có khả năng chuyển đổi được".

Tôi bối rối bởi điều này có nghĩa là gì. Giả sử trong Sprint 1 mục tiêu là "mẫu đăng ký người dùng".

Tôi cần thêm bao nhiêu chi tiết cho một cái gì đó để sẵn sàng xuất xưởng? Ví dụ:

1. Tôi có thể hiển thị biểu mẫu đơn giản với các trường mà không có kiểu dáng lạ mắt nào và đánh dấu chúng là xong
2. Tôi chỉ có thể xác thực phía máy khách là đánh dấu là xong nhưng phía máy chủ cũng là tùy chọn hoặc cả hai
3. Tôi cũng có thể thêm một số mẹo công cụ ưa thích của jQuery, di chuột qua, captcha, màu sắc, nhãn cho biểu mẫu
4. Sau đó, có rất nhiều kiểu dáng về cách hiển thị thông báo lỗi trên màn hình

Tôi có thể làm vô tận trong một chủ đề. Vì vậy, làm thế nào để chúng tôi phân chia điều đó và khi tôi có thể nghĩ rằng đó là vận chuyển đã sẵn sàng.

Hoặc tôi cần phải viết từng điều nhỏ nhất có thể như hiển thị lỗi, cửa sổ bật lên hoặc văn bản hộp sáng dưới dạng nhiệm vụ và đặt chúng dưới dạng chạy nước rút. Điều này sẽ dẫn đến 1000 nhiệm vụ cho toàn bộ dự án.

Ý tôi là một lần nữa nếu một số hoạt động cho Internet Explorer và một số cho Firefox thì tôi cũng cần phải phân chia chúng thành các nhiệm vụ. Thời gian phải dành cho họ và khi người quản lý hỏi tôi bạn đã làm gì trong thời gian đó, tôi sẽ không có bất kỳ nhiệm vụ nào để nói nhưng thực tế tất cả đều là một phần của đăng ký Người dùng

Đồng ý điều này với chủ sở hữu sản phẩm và nhóm Scrum chứ không phải internet. Điều này cần được xác định trong Định nghĩa Hoàn thành của bạn và sẽ phụ thuộc phần lớn vào cách làm việc của nhóm.

Mặc dù tính năng này phải là 'có thể chuyển đổi' (tôi ghét thuật ngữ này trong Scrum) nhưng có thể lập luận rằng chức năng này có thể chuyển đổi được nếu không có UI. Nhiều người mắc phải quan niệm sai lầm này trong Scrum - mục đích của một cuộc chạy nước rút là để có được càng nhiều câu chuyện càng tốt (lý tưởng là tất cả) 'Hoàn thành', nhưng chắc chắn không cần phải xây dựng thành thứ gì đó có thể được phát hành.

Điều quan trọng là phải giải quyết những thứ như thế này sớm, vì vậy mọi người trong nhóm đang làm việc vì một mục tiêu chung. Nguyên tắc của Scrum là giao tiếp, vì vậy hãy hỏi nhóm Scrum và rút ra kết luận hợp lý.

Bạn có thể làm việc trong một nhóm nơi UI thường được xử lý riêng, ví dụ như bởi một nhóm khác hoặc một khi các chuyên gia UI quyết định hình thức sẽ trông như thế nào, v.v. Ngoài ra, trong một dự án / nhóm nhỏ có thể dự kiến ​​rằng UI được xây dựng như bạn đi.

Miễn là tất cả các đội đều biết câu trả lời, không liên quan câu trả lời là gì.

Nếu các tính năng mỹ phẩm là một phần của tính năng, có lẽ chúng nên được thực hiện như một phần của câu chuyện. Vấn đề là, một khi bạn nói một câu chuyện đã xong, bạn không cần phải thực hiện thêm bất kỳ mã hóa nào trên một tính năng cụ thể. Mặc dù, cuối cùng điều này được quyết định bởi chủ sở hữu sản phẩm - họ có thể muốn các tính năng mỹ phẩm hoặc họ có thể không. Điều này nên được đánh vần trong các tiêu chí chấp nhận.

Điều đó không nhất thiết có nghĩa là nó đã sẵn sàng cho người dùng cuối sử dụng, nó chỉ có nghĩa là nó đã sẵn sàng cho một ai đó . Rằng ai đó có thể là người thử nghiệm hoặc nhóm khác, chẳng hạn như nhóm hỗ trợ.

Nếu bạn hỏi điều này với tư cách là nhà phát triển, câu trả lời sẽ là "bạn biết, bởi vì chủ sở hữu sản phẩm sẽ cho bạn biết họ có muốn các tính năng mỹ phẩm hay không".

Nếu bạn đang hỏi điều này với tư cách là chủ sở hữu sản phẩm, bạn chỉ cần quyết định xem bạn có muốn chia nhỏ tính năng thành nhiều câu chuyện hay không. Không có yêu cầu, ngoài việc nó phải làm bạn hài lòng , như một phương tiện để thỏa mãn khách hàng của bạn .

Hãy nhớ rằng: mục tiêu không tuân thủ nghiêm ngặt đối với scrum. Mục tiêu là cung cấp phần mềm chất lượng cao cho người dùng cuối. Sử dụng nó như một hướng dẫn khi đấu tranh với các câu hỏi như thế này. Việc thêm các mỹ phẩm trong cùng một câu chuyện như các bộ phận hoàn toàn chức năng sẽ giúp bạn cung cấp mã chất lượng cho khách hàng của bạn? Hoặc, sẽ phá vỡ điều đó thành hai câu chuyện giúp? Câu trả lời là rõ ràng hoặc không thành vấn đề và bạn có thể làm bất cứ điều gì hiệu quả cho nhóm của mình.

"Có khả năng shippable" có nghĩa là shipp-không nhất thiết phải là thứ mà bạn gửi. Ví dụ:

Một biểu mẫu đăng ký web trông khủng khiếp và không có xác nhận trên các lĩnh vực, có thể ổn đối với một số trường hợp, như một dự án trường học, nhưng trong một doanh nghiệp trị giá hàng triệu đô la, sẽ làm hỏng thương hiệu để hiển thị cho người dùng cuối. Mã có thể được chuyển đổi mà không phải là thứ bạn muốn gửi hoặc tiếp thị hoặc pháp lý sẽ cho phép bạn gửi.

Đó là điều mà các lập trình viên (và những người khác đang trong quá trình tại thời điểm này, ví dụ như các nhà thiết kế) sẽ vui lòng phát hành như hiện tại, ngay cả khi, vì một lý do nào đó, nó sẽ không bao giờ thực sự được phát hành như vậy (ví dụ: cần được dịch sang các ngôn ngữ khác trước khi có thể chuyển đến bất kỳ ai - Canada có các quy tắc nghiêm ngặt về việc mua phần mềm của Chính phủ để xem xét bình đẳng với tiếng Pháp cũng như tiếng Anh).

Đây là một điểm kiểm tra chất lượng, bạn nhìn vào mắt mọi người và hỏi liệu họ có vui lòng gửi nó như hiện tại không, không có việc làm thêm, không kiểm tra xem liệu họ có làm điều đó không. Tôi đã nghe điều này được gọi là điểm kiểm tra kỹ sư máy bay. Bạn nhìn vào mắt một kỹ sư và hỏi họ xem họ có sẵn sàng đi cùng bạn trên chuyến bay thử không.

Ý tưởng là càng nhanh càng tốt. Nhanh hơn bạn có thể nhận được một cái gì đó cho người dùng thực sự; cho dù đó là bản sao beta của mã để chọn cá nhân hay thử nghiệm A / B trên trang web của bạn thì càng tốt. Nếu bạn hiển thị mã người dùng quá thô, thô như được xác định bởi những kỳ vọng của họ đối với sản phẩm của bạn, thì họ sẽ cung cấp cho bạn phản hồi vô ích. Họ sẽ nói về những thứ mà bạn không tìm kiếm thông tin như: họ không thích nút đó màu vàng hoặc hộp văn bản không thẳng hàng với nhãn. Nếu nó đủ tốt thì bạn có thể nhận được phản hồi hữu ích. Nhanh hơn bạn nhận được thông tin phản hồi này tốt hơn! Bạn có thể xác nhận tính phù hợp của sản phẩm / thị trường và các giả định bạn đã thực hiện về tính năng bạn đã cố gắng xây dựng.

Vận chuyển các tính năng là phần ít quan trọng nhất của điều này. Di chuyển nhóm phát triển cùng và hoàn thiện Câu chuyện người dùng là điều quan trọng. Đến điểm mà bạn có thể yêu cầu một cái gì đó được thực hiện là một động lực tuyệt vời.

Theo hiểu biết của tôi, mỗi câu chuyện nên là "có thể thực hiện được" và "có thể chuyển đổi" đến mức nó sẵn sàng để tiêu thụ bởi một ai đó , không nhất thiết là người dùng cuối . Vì vậy, câu chuyện của bạn có thể cung cấp một số chức năng mà sau đó có thể được gửi cho chủ sở hữu sản phẩm, người có thể chọn phát hành nó cho người dùng cuối hoặc lặp lại tính năng này.

Điều đó nói rằng, bạn không bị loại trừ bao gồm cả kiểu dáng trong câu chuyện "Là người dùng cuối, tôi sẽ có thể đăng ký". Trong nhóm của chúng tôi, chúng tôi cố gắng làm cho mọi câu chuyện nhỏ nhất có thể để duy trì khả năng dự đoán cao hơn và đảm bảo tốt hơn chúng tôi có thể cung cấp những gì chúng tôi hứa. Nếu chúng ta có một thiết kế sẵn sàng từ trước và nghĩ rằng nó không quan trọng để áp dụng, thì nó đã được đưa vào câu chuyện. Nếu chúng tôi nghĩ rằng có thể có một số lần lặp lại trên thiết kế, đó là một câu chuyện riêng biệt - có thể là nhiều câu chuyện.

Bên cạnh các câu trả lời tuyệt vời khác cho câu hỏi này, bạn cũng có thể nghĩ về các tính năng mỹ phẩm như là một phần phạm vi biến đổi của tam giác phạm vi tài nguyên-thời gian. Hãy chắc chắn rằng bạn đáp ứng các yêu cầu cơ bản của câu chuyện đó và thêm những thứ hay ho nếu bạn có thời gian.

Scrum không có nghĩa vụ đảm bảo cung cấp các tính năng nhất định trong một thời gian nhất định. Nó được cho là mang lại cho bạn công việc hữu ích tối đa có thể trong một thời gian nhất định. Nếu "bắt buộc" các tính năng mỹ phẩm không được thực hiện trong suốt chạy nước rút đó, nó nên được bởi vì họ đã không thể thực hiện.

Nó phụ thuộc vào người đặt ra các yêu cầu, "chủ sở hữu sản phẩm". Là một lập trình viên, tôi có thể hài lòng với trang "mẫu đăng ký" chưa được kiểm chứng, điều đó chỉ đơn giản chứng minh rằng logic nghiệp vụ trong các dịch vụ web của tôi hoạt động chính xác và việc đăng ký cho phép bạn được xác thực với các tài nguyên khác trong hệ thống. Trên thực tế, "có khả năng có thể chuyển được", vì nó không nhất thiết ngụ ý rằng chúng tôi thực sự sẽ gửi nó cho khách hàng, có thể cho phép đây là kết quả của câu chuyện người dùng đầu tiên về chủ đề này, đặc biệt là nếu nhóm kỹ thuật và nhóm thiết kế là các tài nguyên riêng biệt với tồn đọng riêng biệt.

Trong một dự án trưởng thành hơn, bạn có thể gửi phiên bản tính năng "do nhà phát triển thiết kế", với kiểu dáng tối thiểu, cho máy khách thử nghiệm hoặc máy khách beta, nhưng xem lại tính năng tương tự cho cả sửa đổi chức năng (dựa trên phản hồi) và hoàn thành thiết kế.

Mục đích của phương pháp Agile là cho phép các yêu cầu của bạn thúc đẩy quá trình phát triển phần mềm, thay vì ngược lại. Đừng rơi vào cái bẫy giả định rằng một mô tả về phương pháp luận là Yêu cầu Chính thống và Duy nhất. Dĩ nhiên, nói dễ hơn làm, đặc biệt nếu bạn ở trong một tổ chức lớn nơi Scrum đã trở thành cái cớ để áp đặt sự hỗn loạn lên nhóm phát triển.