Có phải là một ý tưởng tốt để viết các yêu cầu kỹ thuật theo câu chuyện?

Hiện tại chúng tôi đang sử dụng các phương thức nhanh trong dự án hiện tại của mình và chúng tôi có rất nhiều câu chuyện như sau:

• Là một trợ lý, tôi muốn hoàn lại tiền cho khách hàng để họ có thể nhận được một số tiền khi họ yêu cầu.

• Là một khách hàng, tôi muốn trả tiền mua hàng để tôi có thể nhận được hàng của mình.

Làm thế nào chúng ta đã làm điều đó cho đến nay là chọn những câu chuyện quan trọng nhất mỗi lần chạy nước rút và xây dựng nó thành một số thông số kỹ thuật yêu cầu chính thức (chúng tôi nhóm một số câu chuyện tương tự với nhau trong cùng một thông số). Tùy thuộc vào câu chuyện, nó có thể chỉ là một nút trên màn hình hoặc toàn bộ quy trình làm việc.

Vấn đề bây giờ là bởi vì có quá nhiều câu chuyện, không rõ ràng ngay lập tức, đối với bất kỳ phần nào của hệ thống mà câu chuyện liên quan đến nó.

Nó hoạt động vào thời điểm của các nhà phát triển, mỗi lần chạy nước rút các nhà phát triển chỉ cần có một thông số cụ thể về những gì họ cần làm và những thay đổi họ cần thực hiện. Nhưng về mặt duy trì danh sách câu chuyện này và để thử nghiệm, nó bắt đầu gặp lỗi rất khó theo dõi và nói chung chỉ duy trì thông số kỹ thuật, bởi vì một phần chức năng trong màn hình có thể đã được ghi nhận ở một số nơi khác nhau do nó bị chia theo câu chuyện.

Là viết thông số kỹ thuật dựa trên câu chuyện là một ý tưởng tốt? Chúng ta đã viết những câu chuyện sai cách?

Điều này có thể gây tranh cãi nhưng ở đây nó đi!

Chúng tôi đã làm việc trên một hệ thống thời gian thực, nơi một trong những ông chủ trong quá khứ của tôi đề nghị chúng ta hãy thực hiện! Thật dễ dàng để giành được quản lý trên đó thực sự; tuy nhiên, nói thì dễ hơn làm.

Khái niệm về câu chuyện là tốt - nhưng để rất thẳng thắn, nó khá mơ hồ. Một câu chuyện, thực sự là gì? Vấn đề thực sự là việc sử dụng các câu chuyện alone(và cũng giống như các trường hợp sử dụng) cũng có một số vấn đề - như sau:

1. Yêu cầu không thể nằm ngoài ngữ cảnh (trừ khi bạn thực hiện nhiều lần lặp lại quá nhiều lần). Có những giả định, kiến ​​thức nền tảng và các yêu cầu khác được liên kết quá một yêu cầu nhất định; chúng có ý nghĩa chỉ trong một bối cảnh và chỉ theo một trật tự cụ thể. Việc thực hiện quan trọng nhất trước tiên có ý nghĩa kinh doanh nhưng khi bạn nộp chúng ít nhất - hãy giữ một tham chiếu đầy đủ ngay từ đầu khi bạn thu thập chúng. Bản thân từ yêu cầu rất phức tạp và không thực sự giới hạn trong Ca sử dụng / Câu chuyện. Thực tế câu chuyện là hành động, nhưng sau đó có những yêu cầu có thể không thể hành động, chẳng hạn như hiệu suất, các ràng buộc phải được đáp ứng, quy tắc kinh doanh, vv

2. Yêu cầu cần phải phù hợp về kích thước và theo cách định lượng khác, bạn không bao giờ có thể cần nhiều hơn 1 câu chuyện lớn! Những gì hình thành chính xác 1 câu chuyện?

   • nó có phải là một kịch bản chi tiết đầy đủ không? (ví dụ: một câu chuyện khi ATM từ chối giao dịch)
   • nó có phải là một bộ hành động mà người dùng thực hiện không? (ví dụ: toàn bộ câu chuyện về rút tiền)
   • hoặc là một màn hình trong giao diện người dùng? (ví dụ màn hình rút tiền như một câu chuyện đầy đủ).
   • Làm thế nào để thực sự định lượng các quy tắc kinh doanh rất sắc nét với các câu chuyện? Thành thật mà nói, nó có thể là bất kỳ ở trên. Vấn đề là bạn đi bao nhiêu hạn chế và chi tiết là một phong cách cá nhân. Nếu nó hoạt động - nó là tốt;

3. Kiến thức tên miền là thực sự cần thiết! Một ví dụ đơn giản, của một Kiến trúc sư biết nhiều tính chất của Thủy tinh, Thép và Gỗ. kiến thức này không phải là một phần của tài liệu yêu cầu cho tòa nhà mỗi lần nói! Tương tự, nếu bạn đang viết một phần mềm ngân hàng - có cả đống khái niệm về ngân hàng. Nói rõ chúng, vìchính Yêu cầu làm cho nó không thể chuyển đổi được vì nó không cho bạn biết phần mềm nên làm gì trái ngược với cách thế giới hoạt động . Có câu chuyện bao gồm những phức tạp tên miền như vậy? hoặc nó loại trừ điều này?

4. Mô hình hóa thế giới là điều kiện tiên quyết không hoàn toàn được hỗ trợ bởi.
   Đã có rất nhiều tài liệu về Mô hình hóa tập trung vào việc chỉ hiểu cách thế giới hoạt động là một kiến ​​thức nền tảng. Mô hình hóa nền tảng vững chắc mà các yêu cầu đạt được ý nghĩa rõ ràng; tuy nhiên một điều như vậy nên được trả trước. Thật không may, hầu hết các thực hành nhanh nhẹn từ chối giá trị trong mô hình trả trước vì lợi ích của việc giao hàng nhanh hơn và gọn hơn; nhưng điều đó tôi vẫn nghĩ là một điểm dừng chương trình lớn khi mọi thứ phải mở rộng. Nhiều dự án thành công không phải vì mô hình hóa không liên quan - nhưng các kỹ sư dày dạn biết họ trong đầu và không cần hướng dẫn rõ ràng.

Vì vậy, đến câu hỏi của bạn:

Là viết thông số kỹ thuật dựa trên câu chuyện là một ý tưởng tốt? Chúng ta đã viết những câu chuyện sai cách?

Tôi nghĩ rằng những câu chuyện của người dùng có giá trị như phán quyết rõ ràng được đưa ra bởi khách hàng. Nhưng nếu chúng được tổ chức kém và không đủ chi tiết (hoặc mơ hồ) thì có một vấn đề. Trừ khi bạn có một cấu trúc lớn hơn để tích lũy sự hiểu biết rộng hơn (kiến thức tên miền) và phạm vi (tổng thông số kỹ thuật). Câu chuyện của người dùng chỉ dành cho các phân khúc hoặc thành phần trong hệ thống lớn hơn như vậy.

Tái bút: Tôi có ý kiến ​​chính xác về các trường hợp sử dụng (vì chúng được mô tả trong sơ đồ hình bầu dục) trừ khi bạn đặt chúng trong bối cảnh thích hợp và ở mức độ chi tiết phù hợp, chúng không làm tốt công việc nào. (Tôi gọi chúng là những trường hợp vô dụng ). Nguồn đáng tin cậy duy nhất tôi tìm thấy để viết trường hợp sử dụng thực sự có khả năng mở rộng và có ý nghĩa là Viết trường hợp sử dụng hiệu quả bởi Cockburn

> Writing specs by stories? a good idea?

Có nếu bạn có thể quản lý sự phụ thuộc lẫn nhau và các ưu tiên của câu chuyện của bạn.

Dưới đây là một bài viết về bản đồ câu chuyện có thể giúp bạn đặt hàng và quản lý nhiều người dùng.

Khi viết câu trả lời này, tôi đã nhận ra rằng nó không phải là về thử nghiệm, mà là về tài liệu. Trước tiên bạn nên đọc bản tuyên ngôn nhanh :

[Chúng tôi đánh giá] phần mềm làm việc trên tài liệu toàn diện

Vì vậy, bạn nên làm cho các thông số kỹ thuật của bạn có thể thực thi được, tức là viết chúng dưới dạng một bộ kiểm tra hoàn toàn tự động.

Là viết thông số kỹ thuật dựa trên câu chuyện là một ý tưởng tốt?

Vâng, imho, nó là. Nó được gọi là "phát triển theo hướng hành vi" hoặc "đặc tả bằng ví dụ". Trong ruby ​​có một công cụ dưa chuột tuyệt vời giúp ích rất nhiều.

Vấn đề bây giờ là bởi vì có quá nhiều câu chuyện, không rõ ràng ngay lập tức, đối với bất kỳ phần nào của hệ thống mà câu chuyện liên quan đến nó.

Tại sao bạn muốn nó rõ ràng? Ý tôi là, bạn có thực sự cần một ma trận truy xuất nguồn gốc "test / code" không? Ưu điểm của việc viết các bài kiểm tra như một đặc điểm kỹ thuật là bạn không cần truy xuất nguồn gốc "yêu cầu / kiểm tra" riêng biệt, bởi vì các bài kiểm tra trở thành yêu cầu. Đối với mục đích kiểm tra tích hợp, bạn nên coi toàn bộ phần mềm của mình, không phải là các phần riêng biệt.

Bạn có thể cần một công cụ bảo hiểm để xem nếu có các mô-đun "chết", các phần trong hệ thống của bạn không nằm trong các thử nghiệm đặc điểm kỹ thuật của bạn. Nhưng bạn thực sự không nên quan tâm đặc điểm kỹ thuật mà mã đặc biệt này tương ứng với. Nó phải là ngược lại: từ một đặc điểm kỹ thuật cụ thể, bạn nên biết phần nào của hệ thống tương ứng với nó. Bạn không nên lo lắng về một số trùng lặp trong thông số kỹ thuật của bạn. Và nếu bạn áp dụng nguyên tắc DRY cho mã của mình, sẽ có hàng tá thông số kỹ thuật thực thi cùng mã.

Nó hoạt động vào thời điểm của các nhà phát triển, mỗi lần chạy nước rút các nhà phát triển chỉ cần có một thông số cụ thể về những gì họ cần làm và những thay đổi họ cần thực hiện. Nhưng về mặt duy trì danh sách câu chuyện này và để thử nghiệm, nó bắt đầu gặp lỗi rất khó theo dõi và nói chung chỉ duy trì thông số kỹ thuật, bởi vì một phần chức năng trong màn hình có thể đã được ghi nhận ở một số nơi khác nhau do nó bị chia theo câu chuyện.

Không có gì lạ khi hàng trăm bài kiểm tra tích hợp bị phá vỡ bởi một thay đổi nhỏ trong một mô-đun quan trọng. Đó là nơi đơn vị thử nghiệm bước vào.

Bạn nên cấu trúc các bài kiểm tra của mình sao cho có thể biết liệu một bài kiểm tra cụ thể có đáp ứng yêu cầu cấp cao hay chỉ là một chi tiết tinh tế của nó. Nếu sau này, bạn nên tách bài kiểm tra này khỏi bộ kiểm tra tích hợp. Mục đích của kiểm tra đơn vị là để bản địa hóa lỗi. Vì vậy, nếu bạn giới thiệu một lỗi, sẽ có một và chỉ một lỗi kiểm tra.

Chúng ta đã viết những câu chuyện sai cách?

Tôi nghĩ rằng, bạn chỉ cần sắp xếp các câu chuyện của mình thành sử thi theo người dùng, ví dụ: "Khách hàng", "Trợ lý" hoặc theo tính năng / màn hình / quy trình làm việc ("Mua hàng", "Hoàn tiền").

Và một lần nữa, kiểm tra đặc điểm kỹ thuật không phải là một thay thế cho kiểm tra đơn vị. Đọc thêm

Bạn đã đề cập đến một vấn đề và cách bạn giải quyết nó nhưng bạn quên đề cập đến một số ví dụ về thông số kỹ thuật và nhóm của bạn và cách nó liên quan đến cách bạn phát triển sản phẩm của mình.

Viết thông số kỹ thuật bằng những câu chuyện? một ý tưởng tốt?

Agile không cấm nó. Trong nhanh nhẹn, bạn có thể làm bất cứ điều gì bạn cần để cung cấp giá trị kinh doanh tối đa trong tốc độ bền vững. Vì vậy, nếu viết thông số kỹ thuật là một cái gì đó bạn cần để cung cấp thêm giá trị kinh doanh thì hoàn toàn ổn để làm điều đó.

Ví dụ của bạn cho thấy hai câu chuyện của người dùng. Chúng có lẽ liên quan đến logic kinh doanh của bạn nhưng đó là tình huống rất phổ biến.

Nếu bạn cần bactrack chức năng cho các câu chuyện của người dùng, bạn có thể sử dụng lại bất cứ thứ gì phù hợp nhất với bạn bao gồm tài liệu, một số sơ đồ hoặc "thông số kỹ thuật" của bạn, nhưng bạn phải chuẩn bị rằng việc duy trì các tạo phẩm này sẽ khiến bạn tốn nhiều tiền hơn khi mức độ phức tạp của ứng dụng được phát triển tăng lên. Vì vậy, câu hỏi duy nhất bạn phải trả lời trong trường hợp này là: Nếu tôi không sử dụng thông số kỹ thuật của mình, nó có khiến chúng tôi tốn nhiều tiền hơn không? Nếu câu trả lời là có, bạn đã chọn một lựa chọn tốt hơn.

Nhanh nhẹn hoạt động tốt nhất cho các dự án vừa và nhỏ với nhóm nhỏ là toàn bộ kiến ​​trúc được tổ chức theo kiến ​​thức ngầm được chia sẻ trong nhóm. Trong quá trình lập kế hoạch lặp lại, bạn sẽ trải qua các câu chuyện đã chọn, thảo luận về tác động đối với việc triển khai hiện tại và viết một số nhiệm vụ cần thiết để hoàn thành câu chuyện. Tài liệu thực tế trong trường hợp đó sẽ là bộ kiểm tra tổ chức kiểm tra tự động và tích hợp / kiểm thử đơn vị. Khi SW hoặc nhóm của bạn phát triển, kiến ​​thức ngầm sẽ phải chuyển một phần sang một số tài liệu.

Bây giờ đây là nơi trừu tượng đóng vai trò chính. Bạn cần nhìn vào những câu chuyện với sự tôn trọng đối với quan điểm liên quan. Tập hợp các danh từ và động từ trong các câu và xác nhận chúng. Bạn không thể căn cứ vào các mô hình của mình dựa trên các giả định cá nhân . Ngoài ra, hãy chú ý đến chi tiết.

Viết thông số kỹ thuật dựa trên câu chuyện của người dùng không thể chính xác. Bạn cần phải đào thêm chi tiết và đôi khi bỏ qua chi tiết không liên quan. Thông số kỹ thuật nên được viết khi mô hình của bạn hoàn chỉnh và chính xác sau khi có xác nhận của nhà phân tích.