Điều nào nên được thực hiện đầu tiên: trường hợp sử dụng hoặc câu chuyện người dùng?

Tôi đã nghe cả về các trường hợp sử dụng (tôi đang nói về mô tả, không phải sơ đồ) và các câu chuyện của người dùng đang được sử dụng để thu thập các yêu cầu và sắp xếp chúng tốt hơn.

Tôi làm việc một mình, vì vậy tôi chỉ cố gắng tìm cách tốt nhất để tổ chức các yêu cầu, để hiểu những gì phải làm trong quá trình phát triển. Tôi không có, cũng không cần bất kỳ phương pháp chính thức nào với các tài liệu khổng lồ, v.v.

Câu chuyện của người dùng Tôi dường như đã được sử dụng để xây dựng các sản phẩm tồn đọng, trong đó có mọi thứ cần được thực hiện trong quá trình phát triển.

Các trường hợp sử dụng, mặt khác, cung cấp một mô tả về cách mọi thứ được thực hiện trong hệ thống, luồng tương tác giữa các tác nhân bên ngoài và hệ thống.

Dường như với tôi, trong một trường hợp sử dụng, có một vài câu chuyện của người dùng.

Điều này dẫn tôi đến câu hỏi sau: khi phát hiện ra yêu cầu, tôi nên làm gì trước tiên? Tìm và viết câu chuyện của người dùng hoặc tìm và viết các trường hợp sử dụng? Hoặc họ nên được thực hiện "cùng một lúc" bằng cách nào đó?

Tôi thực sự khá bối rối. Liên quan đến các trường hợp sử dụng và câu chuyện người dùng, đối với một nhà phát triển làm việc một mình, quy trình làm việc tốt là gì, sử dụng các phương pháp này một cách chính xác để có sự phát triển tốt hơn?

Các trường hợp sử dụng và câu chuyện của người dùng là cả hai công cụ để thu thập và thể hiện các yêu cầu.
Như bạn đã tìm thấy, một trường hợp sử dụng duy nhất thường có phạm vi rộng hơn một câu chuyện người dùng vì nó cố gắng mô tả hoàn toàn một tương tác người dùng bao gồm các lỗi và sai lệch so với đường dẫn thông thường. Một câu chuyện người dùng có thể được so sánh gần như với một luồng thông qua một trường hợp sử dụng.

Như với tất cả các công cụ, tùy thuộc vào bạn để sử dụng các công cụ mà bạn nghĩ là cần thiết trong một tình huống cụ thể. Điều này có nghĩa là bạn chỉ có thể sử dụng các trường hợp sử dụng, chỉ các câu chuyện của người dùng hoặc kết hợp các trường hợp sử dụng và các câu chuyện của người dùng khi bạn thấy phù hợp.

Việc sử dụng các câu chuyện của người dùng ngày càng trở nên phổ biến là đơn vị công việc của những gì có thể được phát triển và phân phối trong một lần lặp / chạy nước rút.
Với ý nghĩ đó, tôi sẽ không tập trung quá nhiều vào việc thu thập các yêu cầu như các trường hợp sử dụng, trừ khi các trường hợp sử dụng diễn ra tự nhiên khi nói chuyện với các bên liên quan.

Trong trường hợp của tôi, tôi luôn thấy rằng mức độ chi tiết cần thiết cho các trường hợp sử dụng đầy đủ xuất hiện bằng cách suy nghĩ thông qua các câu chuyện người dùng của tôi trước tiên. Câu hỏi đầu tiên tôi hỏi là "mọi người cần gì để có thể làm gì?". Khi tôi có các kịch bản, việc bắt đầu trải qua tất cả các trường hợp sử dụng và các biến thể của dòng chảy cho hệ thống sẽ dễ dàng hơn.

Điều đó đang được nói, đối với một nhà phát triển duy nhất làm việc một mình, bạn không thực sự cần quan tâm đến việc đó là trường hợp sử dụng hay câu chuyện người dùng hoặc dính trên tường có nội dung "đừng quên 'x'". Những gì bạn cần là bất kỳ quy trình nào khiến bạn suy nghĩ về những gì người dùng của bạn đang cố gắng đạt được và giúp bạn theo dõi những điều khác nhau mà họ cần để có thể làm. Mọi thứ khác tùy thuộc vào mức độ chi tiết bạn cần viết ra để lập kế hoạch phát triển.

Ví dụ, khi tôi làm việc trong một dự án phụ, các nhiệm vụ công việc của tôi trông giống như thế này:

1. Đăng nhập
2. Xem danh sách 'foo'
3. Lưu các lựa chọn từ danh sách
4. Tìm kiếm

Thành thật mà nói, mỗi người trong số họ sẽ không có gì nhiều về nó hơn là ước tính. Tại sao? Bởi vì tôi chỉ sử dụng chúng như một lời nhắc nhở về những gì tôi cần để người dùng có thể làm và tôi sẽ tìm ra các chi tiết khi tôi tiếp cận phần đó. Với một nhóm gồm một người, mọi thứ đều có thể nằm trong đầu bạn và điều đó không sao, bởi vì bạn không phải truyền đạt nó cho bất kỳ ai khác.

Bây giờ, có những cảnh báo ...

Nhà phát triển duy nhất làm việc với các chuyên gia khác

Bạn có cần báo cáo về tiến trình cho một nhóm khác? Bạn có người kiểm tra cần xác nhận công việc của bạn? Bạn có quản lý muốn biết những gì bạn đã làm? Bạn có một người quản lý dự án cần dự đoán một dòng thời gian? Bạn có chủ sở hữu sản phẩm đang xác định các tính năng được yêu cầu không?

Nếu những người này là một phần của dự án của bạn thì bạn cần đảm bảo rằng các nhiệm vụ công việc của bạn có đủ thông tin về họ để cho phép họ thực hiện công việc của họ. Thủ tướng có lẽ cần một cách để nhìn thấy kích thước tương đối của sự vật và tiến bộ thông qua công việc đó. Người kiểm tra của bạn sẽ cần chi tiết về cách mọi thứ được dự kiến ​​sẽ chảy (trường hợp sử dụng) và thậm chí bạn có thể yêu cầu họ giúp bạn viết chúng. Quản lý có thể muốn biết bạn đang làm việc trên cái gì, vì vậy bạn sẽ cần đủ mô tả doanh nghiệp để họ có thể hiểu các tính năng bạn sẽ cung cấp.

Nếu bạn trả lời 'có' cho tất cả những câu hỏi đó, có lẽ bạn cần phải có một hồ sơ tồn đọng được ghi chép chặt chẽ hơn vì bạn sẽ sử dụng nó để liên lạc với các thành viên khác trong nhóm của bạn.

• Bạn có thể sẽ cần phải có khái niệm 'Epics' hoặc 'Tính năng' sẽ là chức năng cấp cao mà bạn có thể sử dụng để báo cáo cho quản lý hoặc chủ sở hữu sản phẩm của mình.
• Bạn sẽ lồng Câu chuyện người dùng lồng nhau bên trong các Epics / Tính năng sẽ xác định các khối chức năng nhỏ hơn sẽ được sử dụng để truyền đạt tiến trình với người quản lý dự án của bạn, xác định các nhiệm vụ công việc của bạn trong giai đoạn nước rút và sẽ được sử dụng để truyền đạt mục tiêu kinh doanh tới đội kiểm tra.
• Bạn sẽ có các trường hợp sử dụng hoặc trường hợp thử nghiệm được xác định cho các câu chuyện để nắm bắt các quyết định lưu lượng cấp thấp khác nhau được yêu cầu để đảm bảo rằng bạn, doanh nghiệp và nhóm thử nghiệm được căn chỉnh và biết điều gì sẽ được chấp nhận là 'chính xác'.

Tất cả những điều trên chỉ có thể được bỏ qua nếu bạn là người xác định công việc, quản lý tiến độ, kiểm tra phần mềm và quyết định xem có gì đó là 'chính xác' hay không. Cắt bỏ nỗ lực thêm và đảm bảo bạn đang làm điều quan trọng: xây dựng phần mềm làm việc!

Nếu bạn đang làm một số loại nhanh nhẹn, câu trả lời giáo điều là, Hãy làm những gì có ích cho bạn.

Quá trình nên là một phần của quá khứ của bạn. Bạn nên nói về tắc nghẽn, dư thừa, vấn đề giao tiếp, tài liệu mà không ai từng đọc, v.v. Và, đó là cài đặt nơi các thay đổi quy trình nên được thỏa thuận và lý tưởng được đưa ra trong chuyển động.

Theo kinh nghiệm của tôi, Quản lý dự án, Nhà phân tích và "doanh nhân" được đào tạo để thực hiện quy trình "từ trong ra ngoài". Họ thu thập các yêu cầu, thường được đưa ra bằng lời nói bởi các bên liên quan ở dạng câu chuyện của người dùng. Họ đặt câu hỏi để làm rõ, vì vậy họ có thể tạo tài liệu "ca sử dụng" chi tiết, nhóm phát triển cố gắng dịch lại thành câu chuyện của người dùng mà họ có thể lặp lại trên ...

Đề xuất của tôi, dựa trên kinh nghiệm của riêng tôi: Cố gắng đưa nhóm hoặc nhà phân tích của bạn hoặc bất cứ ai đưa câu chuyện của người dùng vào phần tồn đọng, với chi tiết tối thiểu. Bao gồm thông tin ưu tiên và mô tả "vấn đề" câu chuyện nhằm giải quyết. Có thể liệt kê một số giải pháp tiềm năng ... nhưng, ngoài ra, hãy để "các trường hợp sử dụng" xuất hiện khi các nhà phát triển của bạn lặp lại với QA và / hoặc các bên liên quan trong các câu chuyện.

Ghi lại các trường hợp sử dụng mà bạn đã sử dụng trong tài liệu của mình khi câu chuyện được giải quyết, ở bất kỳ định dạng nào giúp mọi người hiểu hệ thống.

Câu chuyện của người dùng và trường hợp sử dụng không loại trừ lẫn nhau và không có "nên" .

Chúng chỉ là những công cụ có thể hoặc có thể không hữu ích để nâng cao quá trình của bạn đến một thời điểm nào đó. Có nhiều cách có thể, tôi chỉ đề xuất một trong cả hai trường hợp sử dụng và câu chuyện được sử dụng cùng nhau:

• Để tồn đọng và lập kế hoạch, hãy thử các câu chuyện của người dùng như các tính năng giữ chỗ cấp cao. (Tất nhiên các trường hợp sử dụng xuống mức mục tiêu của người dùng cũng có thể giúp ích.)
• Để ghi lại các yêu cầu đã thực hiện, các trường hợp sử dụng sẽ hoạt động tốt nhất.

Nó phụ thuộc . Nếu bạn đang làm việc một mình, hãy thử các cách tiếp cận khác nhau và chọn những gì tốt nhất cho bạn.

Disclaimer: Có rất nhiều phương pháp làm thế nào để viết chúng lên. "Câu chuyện của người dùng" có một định nghĩa rất phổ biến trong khi "Các trường hợp sử dụng" có thể có ý nghĩa rất khác nhau. Tôi đề cập đến các sơ đồ UML cổ điển, rất phổ biến.

Câu chuyện của người dùng hoặc trường hợp sử dụng

Theo kinh nghiệm của tôi, có những bộ óc khác nhau về cách nào là tốt hơn để hiểu. Vì vậy, tôi sẽ quyết định về mỗi nhóm dự án mới, làm thế nào để ghi lại các yêu cầu. Thông thường, một sự kết hợp là phổ biến, sử dụng các trường hợp sử dụng cho tổng quan và câu chuyện của người dùng để biết chi tiết.

• Các trường hợp sử dụng , đặc biệt là sơ đồ, phù hợp hơn cho những người suy nghĩ trực quan
• Câu chuyện của người dùng được ưa thích bởi những người suy nghĩ trong các cuộc thảo luận, những người rất hay nói

(đây là ý kiến ​​dựa trên, không có cơ sở khoa học)

Làm gì trước?

Khi viết các yêu cầu cho một dự án, tôi sẽ bắt đầu ở một mức độ rất trừu tượng. Sử dụng các trường hợp sử dụng, bạn sẽ vẽ sơ đồ (UML-) với các mục tiêu toàn cầu của dự án. Với những câu chuyện của người dùng, hãy viết ra một vài "câu chuyện sử thi" mô tả các mục tiêu chính.

Bước thứ hai sẽ là đi vào chi tiết. Làm điều này, bạn nên cố gắng giữ một tham chiếu đến một "câu chuyện sử thi" hoặc một mục tiêu toàn cầu. Điều này giúp cấu trúc các yêu cầu rất nhiều.

Tôi sẽ nhìn nó theo cách khác: Những gì cần phải đến cuối cùng?

Bước cuối cùng là bạn (hoặc người khác) nhập các yêu cầu vào hồ sơ tồn đọng của bạn. Các yêu cầu phải sao cho bạn biết mã mà bạn viết nên hoạt động như thế nào và để người kiểm tra có thể xác minh rằng mã của bạn hoạt động theo cách nó nên làm.

Những yêu cầu này rất có thể được ghi lại dưới dạng một câu chuyện người dùng được xác định rõ. Vì vậy, câu chuyện người dùng có thể là bước cuối cùng. Các trường hợp sử dụng thường sẽ biến thành nhiều câu chuyện của người dùng, vì vậy chúng phải đến trước câu chuyện của người dùng.

Tôi đã từng nghĩ Các trường hợp sử dụng có nghĩa là cho cách tiếp cận thác nước, trong khi Câu chuyện của người dùng đi kèm với quy trình Agile. Phải mất một thời gian tôi mới nhận ra rằng chúng không độc quyền.

Vì bạn sẽ không phải chia sẻ những điều này, nên sẽ không liên quan đến giao tiếp, ngoại trừ với chính bạn. Miễn là bạn có thể hiểu ghi chú của mình một tuần hoặc lâu hơn, bạn sẽ ổn. Nếu không, thêm chi tiết khi bạn lưu ý các yêu cầu.

Bạn có cần một cách trực quan và linh hoạt để theo dõi tiến trình của mình và đặt ưu tiên không? Nếu vậy, Câu chuyện của người dùng sẽ hữu ích, cùng với bảng tiến trình bạn sẽ tìm thấy trong hầu hết các phương pháp nhanh nhẹn (việc cần làm, đã hoàn thành, chạy nước rút hiện tại).

Khi có yêu cầu thuần túy, biết cần phải giải quyết vấn đề gì và làm thế nào, tôi khuyên bạn nên bắt đầu với Câu chuyện người dùng vì chúng dễ tạo (một câu) hoặc Sơ đồ ca sử dụng chỉ liệt kê các tác nhân và hành động cấp cao.

Khi cần chi tiết, xem chi tiết Câu chuyện người dùng. Khi bạn gặp phải một quy trình phức tạp (phân nhánh, nhiều điều kiện và điều kiện tiên quyết), bạn có thể LIÊN KẾT Câu chuyện người dùng với Ca sử dụng, cho dù bạn sử dụng sơ đồ hoặc phiên bản mẫu văn bản. Và hãy nhớ rằng ngay cả những thứ đó có thể được tạo ra với các mức độ chi tiết khác nhau. Các yêu cầu phần mềm cuốn sách của Karl Wiegers & Joy Beatty khuyên bạn chỉ giữ lại mức độ chi tiết cần thiết để hiểu được. Nếu một cái gì đó hoàn toàn rõ ràng với bạn, bạn không cần phải đi sâu vào.

Trên đây là những gì cá nhân tôi không nhận được lúc đầu: Câu chuyện của người dùng là điểm bắt đầu, "tóm tắt", nhưng mỗi tài liệu có thể được bổ sung bằng các tài liệu bổ sung để xác định thêm những gì có nghĩa và cần thiết, bao gồm các trường hợp sử dụng chi tiết khi cần thiết.