Tôi biết rằng chủ sở hữu sản phẩm nên viết một câu chuyện người dùng bằng scrum.

Một câu chuyện người dùng đang mô tả một tính năng cho người dùng cuối.

Nhưng ai mô tả những gì cần được phát triển về mặt kỹ thuật và cách nó cần được thực hiện

và thông tin đó được lưu trữ liên quan đến scrum ở đâu?

Điều đó thực sự sẽ khiến tôi quan tâm!

Tôi thấy thiếu kiến ​​thức lớn trong công ty của chúng tôi khi nhà phát triển bắt đầu triển khai câu chuyện nhưng họ không biết CÁCH thực hiện nó!

Ví dụ, họ phải đối phó với API COM kế thừa và không biết làm thế nào để xử lý nó hoặc họ không có kỹ thuật với WPF / WEB hoặc bất cứ điều gì.

Scrum giúp mọi người bắt đầu với câu chuyện của người dùng như thế nào?

Không nhanh nhẹn ghét ở đây. Tìm hiểu chi tiết về việc thực hiện và xác định các nhiệm vụ cần thực hiện xảy ra trong cuộc họp lập kế hoạch nước rút, điều này sẽ biến câu chuyện của người dùng thành các nhiệm vụ / yêu cầu thực tế cho lần chạy nước rút. Thất bại của nhiều quy trình nhanh là cuộc họp lập kế hoạch nước rút thực sự được cho là do các nhà phát triển thực hiện ... nếu đó chỉ là chủ sở hữu sản phẩm, họ sẽ quyết định lấy mặt trăng. Đây là nơi bạn nghĩ ra một câu chuyện người dùng (khá mơ hồ) như:

As a non-technical user, I need to have a simpler interface with the API

Trong khi chủ sở hữu sản phẩm xác định câu chuyện người dùng nào là ưu tiên cao nhất, thì các lập trình viên sẽ lấy những ưu tiên đó và biến chúng thành một danh sách các nhiệm vụ (được gọi là tồn đọng nước rút). Đây là nơi bạn có được ý tưởng về cách bạn sẽ thực hiện mọi thứ ... tồn đọng nước rút có thể là kỹ thuật như bạn muốn. Đây cũng là nơi bạn sẽ tìm ra "để đạt được API đơn giản hơn, chúng ta sẽ phải cấu trúc lại API COM điên rồ đó. Có ai biết cách sử dụng API đó không?". Khi câu trả lời là "Địa ngục không", bạn sẽ bắt đầu thấy rằng phạm vi câu chuyện của người dùng đó có thể lớn hơn dường như. Do đó, bạn có thể chia câu chuyện của người dùng thành các tác vụ:

• Tài liệu và hiểu API hiện tại
• Thiết kế API mới
• Triển khai API mới
• Bất cứ điều gì...

Vì điều này, bạn có thể đàm phán các câu chuyện của người dùng để chia chúng thành các thay đổi nhỏ hơn. Phương pháp nhanh nhẹn có nghĩa là bạn muốn tiếp cận những gì người đó muốn trong các bước tăng dần. Vì vậy, bạn có thể nói "Này này. Chúng ta không thể đại tu API chỉ bằng một lần lặp. Hãy chia nó thành 'Là một khách hàng không có kỹ thuật, tôi cần một API được ghi chép tốt".

Câu trả lời ngắn

Nhóm Dev viết những điều kỹ thuật. Scrum giúp bạn một chút nhưng không nhiều với sự cố kỹ thuật. bắt đầu với Câu chuyện người dùng. Scrum gần như là gì-World -only. Sự cố kỹ thuật là How-World .

Bảng phân tích do Scrum cung cấp là:

• Câu chuyện của người dùng -> Tiêu chí chấp nhận

Sự cố mọi người thường sử dụng trên đầu trang này là:

• Sử thi -> Câu chuyện người dùng
• Câu chuyện của người dùng -> Nhiệm vụ
• Tiêu chí chấp nhận -> Kiểm tra chấp nhận

Ngoài ra, nhóm có thể viết Nhiệm vụ kỹ thuật cho những việc họ biết cần phải hoàn thành (nghĩa là cài đặt IntelliJ IDEA cho mọi người khi bắt đầu dự án) nhưng không có Giá trị kinh doanh.

Để được hướng dẫn thêm về cách phân tích công việc, hãy tìm XP (Lập trình cực đoan), Mã sạch , Lập trình thực dụng , Kỹ thuật phần mềm , Thẻ CRC , OOP / OOA / OOD , Mẫu thiết kế , Tái cấu trúc , Làm việc hiệu quả với Mã kế thừa , TDD ( Phát triển dựa trên thử nghiệm), BDD (Phát triển dựa trên hành vi), ATDD (Phát triển dựa trên thử nghiệm chấp nhận).

Câu trả lời dài

Scrum nghĩ như thế nào

Thế giới và thế giới như thế nào

Có một Thế giới và Thế giới . Như bạn đã cảm nhận chính xác, Câu chuyện người dùng dành cho người dùng , tạo ra Giá trị doanh nghiệp hay còn gọi là Giá trị thứ cấp trong Thế giới . Scrum chủ yếu là chỉ thế giới. Nó nói rất ít về không có gì về Thế giới , về cơ bản không hơn gì "Thế giới là trách nhiệm của Nhóm phát triển".

Câu chuyện người dùng và nhiệm vụ

Thông thường, các mục tồn đọng dành cho Thế giới không được gọi là Câu chuyện người dùng mà là Nhiệm vụ kỹ thuật hoặc Subtask . Nhiều công cụ cho phép chia nhỏ Câu chuyện của Người dùng từ Thế giới Thế giới thành Nhiệm vụ trong Thế giới .

Scrum giúp như thế nào và nơi mà sự giúp đỡ kết thúc

Sự giúp đỡ của Scrum cho Thế giới thế giới kết thúc tại một vài điểm trong Cuộc họp Lập kế hoạch Sprint :

• [Cuộc họp Lập kế hoạch Sprint] Nhóm phát hiện ra sự hiểu lầm về câu chuyện nếu các đồng đội khác nhau đưa ra các ước tính Điểm Câu chuyện khác nhau trong Kế hoạch Poker -> Thảo luận.
• [Định nghĩa về sự sẵn sàng] Nhóm không chấp nhận Câu chuyện của người dùng quá lớn (Điểm câu chuyện quá cao). Một nguyên tắc nhỏ được tìm thấy trong nhiều Định nghĩa Sẵn sàng là Điểm Câu chuyện phải nhỏ hơn một nửa vận tốc của đội.
• [Định nghĩa về sự sẵn sàng] Nhóm không chấp nhận Câu chuyện của người dùng mà không có mô tả đầy đủ về Tiêu chí chấp nhận. Tiêu chí chấp nhận là đủ nếu nhóm có đủ tự tin về cách bắt đầu viết Bài kiểm tra chấp nhận.

Một vài lời khuyên về Cấp độ của Scrum

Tôi thấy thật hữu ích khi phân tích Câu chuyện của người dùng thành các Nhiệm vụ phụ trong các cuộc họp Tinh chỉnh tồn đọng hoặc ít nhất là phần thứ hai của Cuộc họp Lập kế hoạch Sprint (đối với một số nhóm Cuộc họp Lập kế hoạch 2 ).

Với các nhóm thiếu kinh nghiệm, tôi thấy thật hữu ích khi phấn đấu cho Câu chuyện người dùng nguyên tử trong quá trình Tinh chỉnh Backlog và Lập kế hoạch Sprint. Câu chuyện người dùng nguyên tử là Câu chuyện người dùng không thể chia nhỏ thành Câu chuyện người dùng nhỏ hơn mà không mất hoàn toàn Giá trị doanh nghiệp. Nói chung, Câu chuyện người dùng không cần phải là Nguyên tử, tôi chỉ thấy rằng nó giúp tôi với các nhóm thiếu kinh nghiệm.

Và đừng làm "(Kiến trúc | Thiết kế | Thực hiện | Thử nghiệm) của Tính năng X" như Câu chuyện của Người dùng. Tôi khuyên bạn thậm chí nên cố gắng tránh điều này như một Subtask.

Nếu tôi có Câu chuyện người dùng nguyên tử và họ dường như cần phân tích thêm ngoài Tiêu chí chấp nhận được triển khai, điều đó có nghĩa với tôi rằng một cái gì đó không hoạt động ở mức tối ưu. Kiến trúc là sai / quá phức tạp, tức là kỹ thuật thay vì định hướng kinh doanh. Hoặc đội thiếu kinh nghiệm. Hoặc cả hai. Trong mọi trường hợp, hành động sẽ được yêu cầu để cải thiện tình hình bằng cách đào tạo và truyền bá kiến ​​thức.

Ngoài Scrum

Scrum Master ngoài Scrum

Ngày nay, Scrum Master hầu hết được hiểu là Vai trò quản lý và điều đó thật nhảm nhí. Ban đầu, Scrum Master là và tôi ủng hộ điều này, Vai trò Kỹ thuật , không phải vai trò quản lý, giống như Huấn luyện viên trong XP .

Thật quá dễ dàng để dựa vào Scrum và Scrum Master và do đó rơi vào một khoảng cách lớn vì Scrum gần như không nói gì về Thế giới.

Xoay Scrum Master

Lý tưởng nhất, Scrum Master xoay quanh những nhà phát triển có kinh nghiệm, những người cũng có đủ kỹ năng quản lý và giao tiếp cho đến khi mọi người trong nhóm sống "Kiểm tra và thích nghi" sâu sắc đến mức Scrum Master trở nên dư thừa; không ai và mọi người sẽ là Scrum Master cùng một lúc.

Nhưng hãy cẩn thận, Scrum Mastery giống như nấu ăn hơn, không thích lau bàn và rửa bát. Bạn có thể muốn xoay người dọn bàn và rửa chén, vì mọi người đều có thể làm điều đó. Nhưng bạn sẽ không muốn xoay xở nấu ăn với mọi người, bởi vì có những người không thể nấu ăn hoặc không thích nấu ăn, và bạn muốn ăn thức ăn ngon.

Điểm hay của việc xoay Scrum Master giữa các nhà phát triển chuyên gia là nhóm có nhiều khả năng tìm hiểu về nhiều phương pháp hơn.

Nhóm tự tổ chức

Từ quan điểm của Scrum, nhóm phải tự tìm ra, lý tưởng nhất là với sự giúp đỡ của Scrum Master .

Scrum cũng chỉ nói về nhóm Dev . Các vai trò như Kiến trúc sư hoặc Kỹ sư trưởng không tồn tại trong Scrum. Điều đó không có nghĩa là họ bị cấm, điều đó chỉ có nghĩa là Scrum không nói gì về họ. Scrum tuyên bố một nhóm tự tổ chức , có nghĩa là nếu nhóm tuyên bố một Kiến trúc sư, nhóm có một Kiến trúc sư. Điều đó không được xác định bởi Scrum, nhưng nó tương thích với Scrum. Tôi không công bố Kiến trúc sư chuyên dụng (Tôi đã làm Kiến trúc sư được chỉ định trong nhiều năm và mặc dù tôi thích nó, nhưng về cơ bản tôi chống lại ý tưởng của Kiến trúc sư được chỉ định), chỉ đưa ra một ví dụ.

Xét nghiệm nghiệm thu

Câu chuyện của người dùng có Tiêu chí chấp nhận . Các tiêu chí chấp nhận này được chuyển thành các thử nghiệm chấp nhận

Những thứ khác

Để biết danh sách các công cụ khác để phân tích, hãy xem Làm thế nào để chia nhỏ dự án lập trình thành các nhiệm vụ cho các nhà phát triển khác?

Hi vọng điêu nay co ich.

Bất cứ ai có trình độ tốt nhất trong nhóm cần chia nhỏ các yêu cầu từ chủ sở hữu sản phẩm thành các câu chuyện người dùng có thể hành động. Theo kinh nghiệm của tôi, chúng tôi đã sử dụng phương pháp sau:

• Nó luôn luôn là một nhà phát triển viết những câu chuyện dựa trên các cuộc thảo luận với chủ sở hữu sản phẩm.
• Những câu chuyện này sau đó được các nhà phát triển ước tính (dựa trên điểm hoặc thời gian)
• Các chủ sở hữu sản phẩm sau đó quyết định về cách mọi thứ được ưu tiên.

Nếu các nhà phát triển không biết cách triển khai một câu chuyện, thì một trong những trường hợp này có thể đúng:

• Nhiệm vụ có thể không đủ rõ ràng (thêm chi tiết / ảnh chụp màn hình / mockup)
• Nó cần được chia nhỏ hơn nữa để các nhiệm vụ cụ thể rõ ràng hơn
• Nó cần nhiều thời gian hơn để nhà phát triển có thể nghiên cứu và tìm hiểu cách thực hiện nó. (Khi ước tính tác vụ này, hãy thêm thời gian để tính đến việc này)
• Nhà phát triển không đủ trình độ để thực hiện nó và nó có thể cần được chỉ định cho người khác hoặc nhà phát triển cần được người khác giúp đỡ.

Bạn có thể tham gia khóa học này trên SCRUM tại Udemy miễn phí và tìm hiểu về các khía cạnh riêng lẻ của quy trình SCRUM - https://www.udemy.com/scrum-methodology/

Câu trả lời ngắn gọn là đây: chủ sở hữu sản phẩm chịu trách nhiệm tạo ra những câu chuyện mà nhóm phải cung cấp. Đó là nhóm quyết định làm thế nào để cung cấp các câu chuyện. Nếu một phần của việc giao hàng liên quan đến một số câu chuyện kỹ thuật, thì đó là nhóm viết những câu chuyện đó. Sau đó, nhóm làm việc với chủ sở hữu sản phẩm để quyết định ưu tiên.

Một lần nữa, PO quyết định xây dựng cái gì , nhóm sẽ quyết định cách thực hiện những câu chuyện đó.

Đây không phải là một vấn đề Agile. Vấn đề là nhóm không có đủ kiến ​​thức kỹ thuật để hoàn thành câu chuyện người dùng (nhanh nhẹn) hoặc yêu cầu (truyền thống). Agile có thể giúp gì trong tình huống này không? Không, nếu nhóm không được chọn cẩn thận và không ai trong nhóm có đủ kinh nghiệm kỹ thuật để thực hiện nhiệm vụ của họ. Có, nếu một số thành viên trong nhóm có kiến ​​thức kỹ thuật tốt, người có thể giúp các thành viên khác trong nhóm thực hiện nhiệm vụ của họ. Đối với đội đó cần phải tự tổ chức, và nên biết đó là điểm mạnh và điểm yếu.

hãy nhớ các pricipl Agile sau đây.

"Các kiến ​​trúc, yêu cầu và thiết kế tốt nhất xuất hiện từ các nhóm tự tổ chức"

Điều này xảy ra bởi vì trong môi trường Agile, lòng tin của nhóm rất cao và họ ủy thác công việc cho nhau.