Nhiệm vụ phát triển được chia sẻ cho câu chuyện người dùng nhanh nhẹn


8

Nhóm của tôi sẽ sử dụng Visual Studio Team Services cho một dự án sắp tới. Các công cụ Agile cho phép tôi sắp xếp các Câu chuyện và Nhiệm vụ của Người dùng theo thứ bậc như thế này:

Sử thi> Tính năng> Câu chuyện người dùng> Nhiệm vụ / Lỗi

Hãy nói rằng tôi đang thiết kế một hệ thống quản lý Học sinh (câu lạc bộ) cho học sinh trung học và cố vấn. Sinh viên và cố vấn có thể tham gia các câu lạc bộ, làm sĩ quan, tổ chức các sự kiện, gửi thông báo, v.v.

Hãy lấy tính năng Thông báo làm ví dụ:

Câu chuyện của người dùng:

  • Là một sinh viên, tôi muốn đọc Thông báo cho các câu lạc bộ mà tôi là một phần để tôi nhận thức được sự thay đổi lịch trình.
  • Là một cố vấn, tôi muốn đọc Thông báo cho các câu lạc bộ mà tôi là một phần để tôi nhận thức được sự thay đổi lịch trình.
  • Là một cố vấn, tôi muốn gửi Thông báo cho các câu lạc bộ mà tôi là một phần để Học sinh của tôi nhận thức được sự thay đổi lịch trình
  • Là Quản trị viên, tôi muốn gửi Thông báo tới TẤT CẢ các câu lạc bộ của trường để tôi có thể khiến họ biết về xung đột lịch trình.
  • Vân vân

Nếu chúng tôi cho rằng đây là những Câu chuyện Người dùng được viết tốt (có thể không có), tôi sẽ bối rối khi nhóm phát triển của mình và tôi ngồi xuống để phân chia các mục này thành Nhiệm vụ phát triển. Chúng tôi có thể bao gồm các phần của một số Câu chuyện người dùng với các Nhiệm vụ phát triển duy nhất. Ví dụ: chúng tôi có một công cụ tạo các hành động CRUD cho tất cả các lớp từ UI đến DB chỉ bằng cách xác định các thuộc tính của Thông báo. Vì vậy, các phần của một số Câu chuyện người dùng "gửi" và "đọc" được hoàn thành trong một bước phát triển duy nhất.

Từ những gì tôi đã đọc, mỗi Câu chuyện của người dùng nên độc lập với những câu chuyện khác và điều đó có ý nghĩa. Nhưng mỗi Câu chuyện người dùng của chúng tôi chia sẻ Nhiệm vụ "Tạo giao diện người dùng và DB" bởi vì đây là cách chúng tôi tạo giao diện người dùng cấp cơ sở (trước khi chúng tôi tùy chỉnh nó). Tôi không nên viết Tác vụ "Tạo UI và DB" cho mỗi Câu chuyện của người dùng. Đó là quá nhiều dư thừa. Nhưng tôi không biết cách viết tác vụ "Tạo UI và DB" phải được hoàn thành trước khi có thể bắt đầu bất kỳ Câu chuyện người dùng nào.

Tôi có sự nhầm lẫn tương tự với hệ thống cho phép của chúng tôi. Chúng tôi có các loại tài khoản khác nhau như Sinh viên, Cố vấn và Quản trị viên đều có quyền truy cập vào trang Thông báo, nhưng có chức năng khác nhau trong trang (Tôi đã nắm bắt ý tưởng này với Câu chuyện của người dùng ở trên). Chúng ta có thể viết hệ thống cấp phép thành mô-đun để có thể sử dụng nó cho các Tính năng khác, nhưng tôi không biết phải viết Tác vụ ở đâu để tạo "hệ thống cấp phép mô-đun".

Tôi đoán toàn bộ câu chuyện Người dùng này làm tôi bối rối. Vâng, thật tuyệt vời khi nắm bắt chức năng của một hệ thống, nhưng khi suy nghĩ về các Nhiệm vụ phát triển, tôi dường như không thể quấn đầu xung quanh nó. Bất cứ lời khuyên nào cũng tuyệt vời cả.


TL; DR: Một số chương trình tôi thực hiện cho một Câu chuyện người dùng có thể được sử dụng ở nơi khác trong dự án của chúng tôi cho các Câu chuyện người dùng khác (hệ thống cấp phép, v.v.). Làm cách nào để tôi viết / sắp xếp Nhiệm vụ cho Câu chuyện của Người dùng để minh họa khả năng này?

Câu trả lời:


11

Tôi không nên viết Tác vụ "Tạo UI và DB" cho mỗi Câu chuyện của người dùng. Đó là quá nhiều dư thừa. Nhưng tôi không biết cách viết tác vụ "Tạo UI và DB" phải được hoàn thành trước khi có thể bắt đầu bất kỳ Câu chuyện người dùng nào.

Bạn không .

Bạn viết câu chuyện người dùng của mình theo nhu cầu của người dùng cấp cao - bạn đã đạt được điều đó.

Sau đó, bạn chọn câu chuyện người dùng (tính năng) mà bạn sẽ giải quyết trước tiên. Tại thời điểm này - với trạng thái hiện tại của sản phẩm - bạn quyết định cách tốt nhất để thực hiện tính năng này. Sau đó, bạn làm công việc kỹ thuật tối thiểu cần thiết để thực hiện tính năng. Sau đó, bạn chuyển sang câu chuyện người dùng tiếp theo.

Điều này có thể diễn ra như sau:

  • Chúng tôi ngồi xuống để làm câu chuyện người dùng 1 và xác định rằng nó yêu cầu một cơ sở dữ liệu. Vì vậy, chúng tôi thực hiện cơ sở dữ liệu và sau đó các tính năng.
  • Chúng tôi ngồi xuống để làm câu chuyện người dùng 2 và xác định rằng - hey - chúng tôi đã có cơ sở dữ liệu nên bây giờ chúng tôi chỉ cần mở rộng giao diện người dùng.

Hoặc trong ví dụ của bạn, nó thậm chí có thể hoạt động như sau:

  • Chúng tôi ngồi xuống để thực hiện gửi một thông báo. Chúng tôi xây dựng giao diện người dùng với hộp văn bản và nút gửi để tạo một bài đăng mẫu. Back-end, không có gì xảy ra. Mát mẻ. Câu chuyện người dùng hoàn thành.
  • Bây giờ chúng tôi ngồi xuống để thực hiện nhận thông báo ... đoán đã đến lúc bắt đầu làm gì đó với chúng khi chúng được gửi.

Toàn bộ mục đích của quá trình này là ngăn bạn cố gắng thiết kế toàn bộ mọi thứ và cho phép bạn đưa ra quyết định sáng suốt về cách triển khai điều tiếp theo với tình trạng hiện tại của phần mềm. Điều đó không tương thích trực tiếp với việc cố gắng chia tất cả các câu chuyện thành các nhiệm vụ kỹ thuật trước khi bắt đầu bất kỳ câu chuyện nào.

Vì vậy, bạn chỉ thiết kế giải pháp một khi bạn chọn câu chuyện và bạn phát triển thiết kế của mình một tính năng tại một thời điểm. Làm thế nào (và thậm chí liệu) bạn có tài liệu thiết kế kỹ thuật của bạn sau khi bạn bắt đầu làm việc với một câu chuyện là tùy thuộc vào bạn.

Nếu hai nhà phát triển nhận hai câu chuyện cùng một lúc và cả hai đều có chung các yêu cầu kỹ thuật, điều đó cho bạn biết rằng bạn không thể thực hiện song song các công việc đó, vì vậy hãy chọn một và các nhà phát triển khác làm việc khác.

Mục đích ở đây là để thực hiện các giải pháp đơn giản và sửa đổi thiết kế của bạn khi các yêu cầu mới xuất hiện.

Và, quan trọng nhất, hãy nhớ rằng: đây không phải là một khoa học .


+1 cho "công cụ cơ sở dữ liệu tồn tại, hãy mở rộng giao diện người dùng." Đội ngũ của chúng tôi đã làm điều này chính xác vào sáng sớm hôm nay, thực sự. Nó chỉ có nghĩa là câu chuyện với những thứ phổ biến là một câu chuyện lớn hơn. Nhiều khả năng nó sẽ là nhiều điểm câu chuyện hơn các câu chuyện tiếp theo, trừ khi nỗ lực thử nghiệm lớn hơn. Chúng tôi đã có 1 câu chuyện "công cụ chung" kết thúc với 13 điểm. Câu chuyện tiếp theo về cơ bản là thực hiện một công cụ cơ sở dữ liệu và mở rộng giao diện người dùng. Đó cũng là 13 điểm. Ít phát triển hơn, nhưng chúng tôi đã xác định nhiều trường hợp thử nghiệm hơn. Câu chuyện cuối cùng ít hơn nhiều so với 3 câu chuyện còn lại, vì ít trường hợp thử nghiệm hơn.
Greg Burghardt

Tôi đã coi Câu chuyện / Nhiệm vụ của Người dùng giống như một phương pháp Thác nước "trang trọng" hơn. Tôi đã cố gắng suy nghĩ và viết ra tất cả các Nhiệm vụ cần thiết để hoàn thành mỗi Câu chuyện người dùng trước khi bắt đầu phát triển. Tôi không hiểu khái niệm cơ bản của Agile là "chọn một câu chuyện, xác định các nhiệm vụ, thực hiện, lặp lại". Agile có ý nghĩa hơn bây giờ, cảm ơn bạn!
Schmidty15

1
@ Schmidty15: Tôi cũng đã làm điều tương tự trước đây. Và chạy vào những vấn đề tương tự. Đối xử nhanh nhẹn như thác nước chỉ có nghĩa là bạn gặp phải những vấn đề tương tự xảy ra với sự phát triển của thác nước, ngoại trừ thường xuyên hơn.
Greg Burghardt

1
@ Schmidty15 nhóm (cũ) của tôi đã sử dụng VSTS giống như bạn. Chúng tôi thậm chí sẽ không sử dụng các tác vụ nếu chúng tôi không có nhu cầu tuân thủ ISO-9001. Chúng tôi đã tạo các nhiệm vụ một cách nhanh chóng trước khi thực hiện nhiệm vụ chỉ để chúng tôi có cách theo dõi từng cam kết trở lại một yêu cầu bắt đầu. Đó là một cách thuận tiện để chúng tôi tránh được việc tôi không có mục công việc cho cái bẫy tái cấu trúc này. Chỉ là thức ăn cho suy nghĩ. Bạn thậm chí có thể không cần phải theo dõi các nhiệm vụ tại cửa hàng của bạn. Bạn có thể muốn làm điều đó đúng lúc cho mục đích truy xuất nguồn gốc.
RubberDuck

1
@Frayt: bạn đã viết "Câu chuyện của người dùng nên được viết từ góc độ người dùng không có thông tin kỹ thuật." . Nói đúng ra có thể đúng, nhưng câu chuyện của người dùng không nhất thiết là loại mặt hàng duy nhất trong sản phẩm tồn đọng. Bạn có thể có các loại câu chuyện khác.
Bryan Oakley

2

Cho rằng bạn đang tham gia mỗi lần chạy nước rút với một danh sách các câu chuyện được ưu tiên và mỗi câu chuyện được chia thành các nhiệm vụ kỹ thuật riêng biệt, tất cả các nhà phát triển nên thực hiện các nhiệm vụ cho câu chuyện ưu tiên cao nhất trước khi bắt đầu làm việc với câu chuyện ưu tiên cao thứ hai. Bởi vì điều này, vào thời điểm bạn bắt đầu thực hiện câu chuyện ưu tiên thứ hai, nhiệm vụ 'Tạo UI và DB' đã được hoàn thành như một phần của câu chuyện đầu tiên. Vì vậy, nếu trong quá trình lập kế hoạch chạy nước rút, bạn thấy rằng một nhiệm vụ kỹ thuật được sao chép qua một số câu chuyện, hãy gán nhiệm vụ đó cho câu chuyện ưu tiên cao nhất để nó sẽ được hoàn thành trước.

Nếu nhóm của bạn có thói quen sắp xếp lại các ưu tiên câu chuyện sau khi chạy nước rút bắt đầu, bạn có thể thấy lợi ích trong việc bao gồm các nhiệm vụ kỹ thuật trùng lặp trên mỗi câu chuyện và ghi chú về nhiệm vụ mà các câu chuyện khác sử dụng nó.

Nó có thể giúp đi vào suy nghĩ làm việc từ một danh sách các nhiệm vụ kỹ thuật thay vì một danh sách các câu chuyện.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.