Phá vỡ một câu chuyện phức tạp khi bắt đầu dự án

Tôi đang cố gắng nắm bắt với quản lý dự án nhanh nhẹn (với Pivotal Tracker) nhưng cứ thấy mình chạy vào tường khi cố gắng xác định một vài câu chuyện đầu tiên của dự án. Lấy ví dụ câu chuyện rất đơn giản này:

"Người dùng có thể gắn thẻ sản phẩm"

Giả sử tôi đã định nghĩa "sản phẩm" ở nơi khác, câu chuyện này có thể liên quan đến việc viết một hệ thống gắn thẻ đa hình dưới mui xe, khi hoàn thành id hệ thống đó cuối cùng cũng có thể thêm khả năng gắn thẻ sản phẩm.

Vấn đề của tôi là với số lượng công việc ẩn trong câu chuyện này. Tôi có thể xác định các nhiệm vụ để hoàn thành câu chuyện nhưng toàn bộ câu chuyện được cho là 1-2 ngày làm việc? Tôi không cảm thấy đúng về câu chuyện chỉ tiết lộ phần nổi của tảng băng trôi nhưng đó là phần duy nhất liên quan đến Người dùng.

Làm thế nào để bạn vượt qua loại điều này? Các thực hành tốt nhất là gì?

CẬP NHẬT 25/08 Cảm ơn mọi người đã hướng dẫn, tôi đã thực hiện mọi lời khuyên trên tàu về cách xác định câu chuyện. Bây giờ tôi đang chuyển sang Jira Grasshopper, nơi hỗ trợ tốt hơn cho các nhiệm vụ trong các câu chuyện (phân công, ước tính, v.v.) và theo dõi các nhiệm vụ phát triển sau khi chạy nước rút đã bắt đầu.

Nếu bạn cần các câu chuyện của mình là 1 đến 2 ngày cho mỗi nhà phát triển làm việc, có lẽ bạn nên chia mỗi câu chuyện thành các tác vụ người dùng cụ thể là 1 đến 2 ngày làm việc của nhà phát triển.

Hãy xem xét "câu chuyện người dùng:" sau đây

Người dùng sẽ có thể nhận được hóa đơn từ một sản phẩm đã mua.

Hãy suy nghĩ về những gì liên quan đến thiết kế cơ sở dữ liệu, trong việc cung cấp cho người dùng khả năng này. Bạn cần một bảng khách hàng, bảng tiêu đề hóa đơn và bảng chi tiết đơn hàng hóa đơn và chúng tôi thậm chí chưa nói về việc chấp nhận thanh toán.

Trong thực tế, câu chuyện của người dùng không đơn giản. Toàn bộ câu chuyện của người dùng bao gồm hướng dẫn các bước người dùng liên quan:

• Người dùng đặt sản phẩm vào giỏ hàng
• Người dùng chỉ định số lượng
• Người dùng chỉ định loại vận chuyển

và như thế. Nói tóm lại, bạn cần chia nhỏ các câu chuyện của người dùng thành chi tiết tốt hơn.

Câu chuyện không phải là, "1-2 ngày làm việc". Trong các câu chuyện Scrum thường được ước tính bằng Story Points, một hệ thống kích thước tương đối. Nếu bạn sử dụng lập kế hoạch các câu chuyện poker được đưa ra một giá trị điểm - thời gian mà câu chuyện cần thực hiện tùy thuộc vào vận tốc mà nhóm của bạn đã thiết lập.

Nếu bạn cảm thấy những câu chuyện được giấu phức tạp (bạn có thể gọi nó là một Epic câu chuyện), bạn nên chia nó ra thành những câu chuyện nhỏ. Hãy chắc chắn rằng những câu chuyện mới tuân theo các tiêu chí ĐẦU TƯ .

Nhưng bạn có thể áp đảo điều này; nguyên tắc XP của YAGNI áp dụng ở đây. Để rõ ràng, bạn không nên thực hiện một "hệ thống gắn thẻ đa hình dưới mui xe", trừ khi bạn thực sự cần nó. Ngay cả sau đó, nó nên được thiết kế bằng cách cải thiện hệ thống hiện có, mà bạn đã phát triển với một bộ thử nghiệm tốt.

Nếu bạn chắc chắn rằng bạn cần hệ thống gắn thẻ phức tạp này, bạn nên gọi ra sự phức tạp trong các câu chuyện riêng biệt. Mike Cohn mô tả cách tiếp cận để thiết kế như là " Cố ý, nhưng chưa xuất hiện "

Có vẻ như bạn đang bối rối những câu chuyện và nhiệm vụ.

Câu chuyện người dùng

Câu chuyện của người dùng là một "tính năng" hoàn chỉnh, một thứ mà khi được thêm vào sản phẩm, sẽ cung cấp nhiều giá trị hơn cho sản phẩm.

Một câu chuyện người dùng không nên lớn hơn nó có thể được thực hiện trong một lần chạy nước rút . Trong phần đầu tiên của kế hoạch chạy nước rút, bạn quyết định những câu chuyện người dùng nào bạn muốn làm việc trong giai đoạn nước rút. Mục tiêu của lần chạy nước rút là hoàn thành những câu chuyện của người dùng này, do đó tăng thêm giá trị cho sản phẩm.

Bài tập

Trong phần thứ hai của giai đoạn lập kế hoạch chạy nước rút, các nhà phát triển chia câu chuyện thành các nhiệm vụ . Các nhiệm vụ là nhiệm vụ phát triển. Chúng có thể là những thứ như "Thêm cột vào cơ sở dữ liệu", "Mở rộng dịch vụ x", v.v. Một nhiệm vụ không được lớn hơn nó có thể được hoàn thành trong một ngày.

Trong scrum hàng ngày, bạn đánh giá tiến trình của các nhiệm vụ này. Nếu một nhiệm vụ đã được tiến hành trong hơn một scrum hàng ngày, thì nó sẽ mất quá nhiều thời gian và bạn, với tư cách là một nhóm, có trách nhiệm giải quyết tình huống đó.

Hãy nhớ rằng, câu chuyện của người dùng đại diện cho giá trị kinh doanh cho các cổ đông. Những người nắm giữ cổ phần nên quan tâm đến việc hoàn thành các câu chuyện của người dùng, chứ không phải các nhiệm vụ.

Bộ phận nhiệm vụ là một công cụ để nhóm phát triển quản lý chạy nước rút, theo dõi tiến trình của các câu chuyện của người dùng trong giai đoạn nước rút và để hình dung các vấn đề tiềm ẩn.

Các cổ đông không nên quan tâm đến mình với các nhiệm vụ phát triển này. Thật không may, đó là kinh nghiệm của tôi mà họ thường làm, đặc biệt là đối với các tổ chức mới phát triển nhanh. Đối phó với tình huống này là một vấn đề khác.

Sử thi

Nếu một câu chuyện người dùng lớn hơn bạn nghĩ bạn có thể hoàn thành nó trong một lần chạy nước rút, thì nó được gọi là một bản anh hùng ca. Nó cần được chia thành nhiều câu chuyện người dùng nhỏ hơn trước khi bạn có thể bắt đầu làm việc với nó.

Hãy nhớ rằng một câu chuyện người dùng làm tăng giá trị cho người dùng cuối, vì vậy việc chia một bản anh hùng ca thành một "front-end" và một câu chuyện "back-end" không phải là cách đúng đắn. Việc thêm back-end cho một tính năng mới tự nó không cung cấp giá trị cho người dùng cuối.

Việc chia một bản anh hùng ca thành những câu chuyện của người dùng có thể quản lý được trong khung thời gian của một lần chạy nước rút không phải lúc nào cũng dễ dàng khi bạn không có kinh nghiệm làm việc đó.

Sử dụng Trình theo dõi Pivotal

Tôi nghĩ Pivotal Tracker là một công cụ tuyệt vời để theo dõi các câu chuyện của người dùng. Nhưng nó không phải là một công cụ scrum như vậy, và cách mà scrum dạy để phân chia các câu chuyện thành các nhiệm vụ không dễ dàng được xử lý bởi trình theo dõi quan trọng. Bạn có thể kích hoạt khả năng thêm tác vụ vào câu chuyện của người dùng. Nhưng nếu bạn đang chạy một dự án bằng scrum, tôi sẽ đề nghị sử dụng bảng trắng và ghi chú dán để theo dõi tiến trình của các nhiệm vụ trong giai đoạn nước rút.

Có một mục tiêu thiết kế để thực hiện một hệ thống gắn thẻ đa hình là tốt, nhưng bạn vẫn nên tập trung vào việc thực hiện các tính năng khách hàng muốn. Điều này có thể có nghĩa là, Câu chuyện người dùng chi tiết bằng Câu chuyện người dùng chi tiết, hệ thống của bạn phát triển thành một hệ thống gắn thẻ đa hình theo thời gian. Tuy nhiên, tại bất kỳ thời điểm nào trên hành trình đó, bạn nên có hệ thống gồm rất nhiều tính năng nhỏ và có thể kiểm tra được, được mô tả bởi một bộ Câu chuyện người dùng bạn đã triển khai.

Trong trường hợp này, có vẻ như "Sản phẩm gắn thẻ" trong hệ thống của bạn có thể là một Epic, tức là một cái gì đó lớn hơn nhiều so với một Câu chuyện người dùng và có thể được chia thành nhiều câu chuyện nhỏ hơn với một chút nỗ lực. Lấy một số lượng lớn giấy phép nghệ thuật, tôi có thể nghĩ đến Câu chuyện người dùng sau đây có thể áp dụng gần đúng cho các yêu cầu của bạn:

• Là quản trị viên hệ thống, tôi muốn chọn hệ thống bằng một số thẻ hợp lệ để người dùng có một số giá trị để chọn khi lần đầu tiên sử dụng tính năng gắn thẻ.
• Là người dùng của hệ thống, tôi muốn có thể tìm kiếm một sản phẩm theo tên để tôi có thể gắn thẻ nó sau này.
• Là người dùng của hệ thống, tôi muốn có thể đọc mô tả của sản phẩm để tôi có thể quyết định những thẻ nào cần có.
• Là người dùng hệ thống, tôi muốn có thể nhìn thấy hình ảnh của sản phẩm để tôi có thể quyết định những thẻ nào cần có.
• Là người dùng của hệ thống, tôi muốn có thể đính kèm một thẻ vào một sản phẩm.
• Là người dùng của hệ thống, tôi muốn có thể xóa một thẻ khỏi một sản phẩm.
• Là người dùng của hệ thống, tôi muốn có thể đính kèm một thẻ vào nhiều sản phẩm.
• Là người dùng của hệ thống, tôi muốn có thể đính kèm nhiều thẻ vào một sản phẩm.
• Là một quản trị viên hệ thống, tôi muốn xem một danh sách các thẻ được sử dụng trong hệ thống để tôi có thể quyết định xem có bất kỳ thẻ nào trong số chúng là trùng lặp hay không.
• Là một quản trị viên hệ thống, tôi muốn hợp nhất các thẻ trùng lặp.

... Và tôi có thể tiếp tục.

Tôi nghi ngờ bất kỳ thứ nào trong số này sẽ giống như thật đến mức bạn sẽ sử dụng chúng, nhưng hy vọng chúng minh họa loại chi tiết bạn có thể đi với Câu chuyện người dùng của mình.

Nếu Câu chuyện người dùng thực sự không thể được chia thành bất kỳ câu chuyện nhỏ nào và bạn vẫn cho rằng nó quá lớn để cố gắng thực hiện trong một lần, thì bạn có thể chia nó thành các lát dọc. Đây là một kỹ thuật có nghĩa là chỉ cung cấp một phần tính năng trong mỗi Câu chuyện của người dùng, nhưng mỗi phần là một lát cắt có thể kiểm tra thông qua tất cả các lớp công nghệ có liên quan, ví dụ: đối với một trang web, điều này có thể có nghĩa là thay đổi cơ sở dữ liệu, ứng dụng và lớp UI. Tránh có một Câu chuyện người dùng cho cơ sở dữ liệu hoạt động, một câu chuyện khác cho ứng dụng và một câu chuyện khác cho UI, vì những điều này sẽ không thể kiểm tra riêng lẻ.

Lấy giấy phép nghệ thuật hơn nữa, tôi có thể chia "Là người dùng hệ thống tôi muốn có thể đính kèm một thẻ vào một sản phẩm duy nhất." vào các lát dọc sau:

• Là người dùng hệ thống đang xem một sản phẩm, tôi muốn có thể tra cứu danh sách các thẻ để tôi có thể quyết định áp dụng cái nào.
• Là một người dùng của hệ thống đang xem xét một sản phẩm, đã quyết định chọn một thẻ để áp dụng cho sản phẩm đó, tôi muốn có thể áp dụng nó.
• Là người dùng hệ thống đang xem một sản phẩm, đã áp dụng thẻ cho sản phẩm đó, tôi muốn có một thông báo xác nhận trên màn hình cho tôi biết rằng nó đã được lưu thành công.

Mỗi trong số đó đều có thể kiểm chứng - nếu không đặc biệt có giá trị theo cách riêng của họ.

Có những cuốn sách được viết cho mục đích duy nhất là tìm ra cách chính xác để mô tả và phá vỡ các yêu cầu của bạn. Vì vậy, nó không phải là một nhiệm vụ dễ dàng.

Thường thì tôi thấy các nhóm phát triển phấn đấu cho các giải pháp phức tạp thay vì những giải pháp đơn giản nhất. Điều này có thể là do chính câu chuyện hoặc vì nhóm muốn tìm kiếm một giải pháp quá phức tạp không chỉ giải quyết câu chuyện này mà còn đặt nền tảng cho các câu chuyện x, y và z. Đây là ý định tốt, nhưng phạm vi phình to nơi cùng một công việc có thể được thực hiện với ít công việc hơn. Luôn luôn khó để đánh giá bao nhiêu thiết kế phải đi vào một câu chuyện để không phá hỏng những câu chuyện trong tương lai bằng cách làm hỏng thiết kế. Quyết định này là để nhóm thực hiện.

Là chủ sở hữu sản phẩm, bạn chỉ có thể tác động đến điều này bằng cách chia nhỏ các câu chuyện thành các phần nhỏ hơn. Bạn nên tự hỏi: câu chuyện có phải là giải pháp nhỏ nhất mà chúng ta có thể nghĩ ra ngay bây giờ không? Chúng ta có thể chia nó thành các bộ tính năng giảm mà một ngày nào đó sẽ trở thành "hệ thống gắn thẻ linh hoạt lớn mà tôi luôn muốn". Bạn có thể bắt đầu với một hệ thống thẻ chỉ cho một thẻ, sau đó mở rộng nó để bao gồm danh sách các thẻ được chọn trước, sau đó cho phép người dùng xác định thẻ, v.v.

Đối với nhóm nhà phát triển, chúng ta có thể tìm ra cách tiếp cận đơn giản hơn để hiện thực hóa câu chuyện, nhưng vẫn có một kiến ​​trúc vững chắc hoàn thành công việc ngày hôm nay trong khi không ảnh hưởng đến các tính năng trong tương lai.

Nếu bạn sẵn sàng chấp nhận các giải pháp trung gian và nhóm phát triển cũng cố gắng đưa ra giải pháp đơn giản nhưng tốt nhất thì có lẽ bạn sẽ tìm thấy điểm ngọt ngào trong đó kích thước của những câu chuyện bạn muốn làm là đúng (càng nhỏ càng tốt) . Điều này không có nghĩa là bạn chỉ có những câu chuyện nhỏ. Một số lớn hơn những người khác, đây chỉ là một thực tế mà bạn cần chấp nhận, hoặc nếu chúng quá lớn, sau đó chia nhỏ các câu chuyện thành các phần nhỏ hơn.