Điều này hóa ra dài hơn tôi dự định (nó đã bắt đầu như một bình luận), nhưng tôi hy vọng độ dài / chi tiết bổ sung là hữu ích và bạn thấy chúng hợp lý.
Agile không dành riêng cho ứng dụng CRUD
Hầu hết các tài liệu về agile dường như thiên về các ứng dụng kinh doanh kiểu CRUD nơi người dùng nhận thức được khá nhiều về những gì đang diễn ra đằng sau hậu trường. (Điều đó tốt bởi vì hầu hết các mã được viết có lẽ thuộc về lớp này.)
Tôi nghĩ điều này là bởi vì việc tạo ra các ví dụ dễ theo dõi kiểu này dễ dàng hơn, không thực sự vì phương pháp này nhắm vào các loại hệ thống đó. Nếu bạn tạo một ví dụ không dễ theo dõi, bạn có nguy cơ khiến người đọc bị mắc kẹt khi cố gắng hiểu ví dụ khi quan điểm của bạn được cho là dạy cho người đọc về các khái niệm nhanh.
Câu chuyện của người dùng! = Yêu cầu
Đối với loại ứng dụng này, mối quan hệ giữa các câu chuyện của người dùng (yêu cầu) và các tác vụ phát triển chủ yếu là đơn giản: Chỉ cần chia câu chuyện của người dùng thành một vài nhiệm vụ.
Một câu chuyện người dùng không giống như một yêu cầu. Đúng, có thể có một số trùng lặp tùy thuộc vào mức độ 'yêu cầu cấp cao', nhưng nhìn chung không giống nhau. Tôi có ấn tượng rằng bạn đang gặp phải một cạm bẫy rất nhiều người quản lý cũ của tôi đã rơi vào: nghĩ về những câu chuyện của người dùng chỉ đơn giản là từ đồng nghĩa với "yêu cầu", tương tự như khi người dùng SVN cố gắng chuyển sang Git, nhưng vẫn giữ suy nghĩ về SVN. (Sau đó, họ gặp vấn đề do các giả định bắt đầu tồi.)
IMHO, một điểm khác biệt chính giữa các yêu cầu và câu chuyện của người dùng là các yêu cầu chỉ định cụ thể, cách thức các thành phần hệ thống nhất định phải hành xử; chúng là các thông số kỹ thuật bao gồm đầu vào, đầu ra, giả định / điều kiện trước, các trường hợp ngoại lệ có thể xảy ra, v.v ... Chúng tập trung vào những gì hệ thống làm.
OTOH, các câu chuyện của người dùng tập trung vào kết quả mong đợi cho người dùng cuối mà không cố gắng tạo ra một đặc tả hành vi chi tiết cho các thành phần hệ thống. Họ tập trung vào trải nghiệm người dùng mong đợi .
Những gì tôi đã từng làm, và đây là một thực tế mà nhóm của tôi đã áp dụng, là chia nhỏ các câu chuyện của người dùng thành các nhiệm vụ. Nhiệm vụ của bạn có thể cụ thể hoặc mơ hồ như bạn muốn / cần chúng, nhưng chúng có nghĩa là các chỉ số tiến bộ của bạn cho công việc thực tế được thực hiện để đưa câu chuyện đến trạng thái hoàn thành.
Thí dụ
Tôi đại khái nhớ lại một nước Mỹ tôi đã làm việc cách đây nhiều năm, nơi người dùng cần tự gán các trường hợp thử nghiệm để mọi người trong nhóm nhận thức được những TC họ đang làm việc để tránh những nỗ lực trùng lặp; UI là một ứng dụng web (n nội bộ). Người dùng chỉ thấy một nút, nhưng câu chuyện được chia thành một số nhiệm vụ bao gồm một số chi tiết triển khai kỹ thuật, v.v.
Tầm nhìn của người dùng
Nhưng có một loại ứng dụng khác mà hầu hết các mã phải xử lý việc xử lý phức tạp mà người dùng không thể nhìn thấy trực tiếp.
Có thể làm cho nó hiển thị cho người dùng theo một cách nào đó?
Hãy xem xét một GPS. Khi bạn bỏ lỡ lượt của mình, bạn sẽ không thấy quy trình tính toán lại tuyến đường thực tế, nhưng người dùng sẽ nhận được một số phản hồi hữu ích (ví dụ: "Tính toán lại ...").
Trình biên dịch có thể hiển thị các cảnh báo hoặc lỗi hoặc bao gồm các cài đặt / tùy chọn mới trong GUI để người dùng thấy rằng một cái gì đó mới đã được thêm vào. Tôi nghĩ người dùng cho trình biên dịch sẽ là lập trình viên, phải không? Họ sẽ không thấy hỗ trợ cho một tiêu chuẩn mới được thêm vào chứ?
Mặc dù hỗ trợ một tiêu chuẩn mới có thể sẽ ở cấp tính năng và cần được chia thành các câu chuyện của người dùng, bạn có chắc chắn rằng, ít nhất là trong một số trường hợp, bạn không cố gắng sử dụng các câu chuyện khi bạn nên sử dụng các tính năng thay thế ?
Phân tích hình ảnh trong một chiếc xe hơi có thể được thực hiện theo cách cho phép người dùng biết rằng cơ hội kết thúc trong một vụ tai nạn xe hơi đã giảm. Ví dụ:
Là một hành khách trong một chiếc xe tự lái, tôi cần xác suất chiếc xe gây ra tai nạn bằng cách đâm vào một vật thể không được nhận dạng để càng gần 0 càng tốt, để tôi có thể đi lại an toàn hơn.
Ở Mỹ, ở cấp độ cao, những thứ bạn thường phải chỉ định bằng cách sử dụng kết hợp các yêu cầu chức năng và phi chức năng - bao gồm bảo mật, an toàn, v.v.
Tuy nhiên, một yêu cầu có thể là nhiều hơn về hệ thống; ví dụ:
Hàm abctrong thành phần Aphải giảm giá trị ngưỡng dung sai trong thuật toán so sánh ảnh để phát hiện tốt hơn các đối tượng di chuyển chậm.
Đối với tôi, đây sẽ dễ dàng là một nhiệm vụ trong câu chuyện người dùng mà tôi đã đề cập ở trên, có tiêu đề như: Giảm dung sai trong chức năngA.abc và sau đó bao gồm các chi tiết có liên quan khác trong đó.
Đối với một hệ thống mô phỏng chất lỏng, bạn thậm chí có thể có một thanh tiến trình cung cấp phản hồi về các tác vụ nền mà hệ thống đang thực hiện, nếu điều này có ý nghĩa. (Luôn có cách để thông báo cho người dùng về một cái gì đó, mặc dù bạn có thể muốn tránh bị spam.)
Tôi không biết đủ về các tên miền cụ thể mà bạn đã đề cập để đưa ra các ví dụ tốt hơn và / hoặc thực tế hơn, nhưng nếu có một sự loại bỏ ở đây là bạn có thể sử dụng các cách khác nhau để cung cấp phản hồi của người dùng về thứ gì đó ít nhìn thấy hơn hệ thống có thể đang hoạt động, tức là có thể có những cách để làm cho những thứ vô hình trở nên rõ ràng hơn một chút. (Ngay cả khi nó tập trung vào việc viết một tập các ghi chú phát hành, tài liệu cho thấy hiệu suất của hệ thống nhanh hơn bao nhiêu do nỗ lực của bạn, v.v.)
Mối quan hệ giữa Câu chuyện và Nhiệm vụ
Ở đây có thể thực sự khó khăn để liên quan đến các nhiệm vụ và câu chuyện người dùng.
Cách tiếp cận của chúng tôi là để giữ cho câu chuyện người sử dụng tập trung vào những gì được yêu cầu là, tại sao nó đã được thực hiện, và những điều cần thiết để được thực sự để xem xét Mỹ "thực hiện". Cách thức luôn được đưa ra khỏi Hoa Kỳ và để lại cho (các) nhà phát triển.
(Các) nhà phát triển sẽ chia nhỏ vấn đề được mô tả ở Hoa Kỳ thành một tập hợp các nhiệm vụ mà họ sẽ làm việc.
Tôi đang nói điều này như một người, phần lớn, đã lập trình phía máy chủ phía sau, có lẽ là "vô hình" như bạn có thể nhận được cho người dùng cuối.
Tùy thuộc vào những gì tôi cần làm, đôi khi tôi sử dụng AJAX để hiển thị hình động / gif "tải ..." đơn giản để người dùng biết rằng họ cần đợi một chút để hoàn thành một cái gì đó khác mà không gây ấn tượng sai. Đôi khi nó đơn giản như thế này. Một nhiệm vụ cho việc này sẽ là phù hợp.
Mô hình, thực hành và kinh nghiệm khác nhau
Có những kỹ thuật để khắc phục vấn đề này hay nó chỉ là thứ chúng ta phải chấp nhận và tận dụng nó một cách tốt nhất?
Ngoài việc chấp nhận thay đổi mô hình, thực hành và tích lũy kinh nghiệm, có lẽ không còn nhiều điều để nói. Tôi thường thấy mọi người cố gắng thực hiện các phím tắt trong suốt quá trình. Tôi khuyên bạn nên chống lại điều đó, đặc biệt nếu bạn đang bắt đầu. Khi bạn có thêm kinh nghiệm, bạn có thể cho phép một số linh hoạt, nhưng tránh làm suy yếu chính mình.
Theo cách diễn đạt trước đó của bạn, bạn vẫn nghĩ về những câu chuyện như thể chúng là "yêu cầu được đổi tên", mà tôi nghĩ là một giả định sai. Tôi nghĩ rằng đây là một triệu chứng của một vấn đề sâu sắc hơn về sự khác biệt cơ bản giữa các phương pháp Agile và không Agile.
Thứ hai, tôi nghĩ bạn nên chấp nhận rằng nhanh nhẹn là một sự thay đổi mô hình so với thác nước, điều đó có nghĩa là, trong khi quá trình có các mục tiêu tương tự, họ đi về nó theo những cách rất khác nhau. (Hãy nghĩ SVN vs Git, nếu điều đó có ích.)
Cố gắng cải thiện sự hiểu biết hiện tại của bạn về sự khác biệt về khái niệm giữa các yêu cầu và câu chuyện của người dùng và chấp nhận chúng không giống nhau.
Học hỏi từ Sprints của bạn - Hồi tưởng
Điều tôi không thể nhấn mạnh đủ là sự hồi tưởng giữa Scrum Master và Nhà phát triển ở cuối mỗi lần chạy nước rút. Đó là nơi họ thảo luận về những điều mà "diễn ra tốt đẹp" hoặc "không suôn sẻ" một cách trung thực / minh bạch, và những gì có thể làm được những thay đổi sẽ được thực hiện cho chạy nước rút tiếp theo để giải quyết "không suôn sẻ" điểm .
Điều đó cho phép chúng tôi thích nghi và thậm chí học hỏi kinh nghiệm của nhau, và trước khi chúng tôi biết điều đó, chúng tôi đã cải thiện đáng kể khi được đo bằng sự thống nhất chung về vận tốc của đội chúng tôi.