Bắt đầu từ câu chuyện của người dùng sang mã trong khi sử dụng TDD (scrum)

Tôi đang tham gia vào scrum và TDD và tôi nghĩ rằng tôi có một số nhầm lẫn mà tôi muốn nhận phản hồi của bạn. Giả sử tôi có một câu chuyện người dùng trong hồ sơ tồn đọng của mình, để tôi bắt đầu phát triển nó như một phần của TDD, tôi cần phải có yêu cầu, cho đến nay?

Có đúng không khi nói rằng người quản lý sản phẩm và QA phải chịu trách nhiệm đưa câu chuyện của người dùng và chia nhỏ nó để kiểm tra chấp nhận?

Tôi nghĩ những điều trên là đúng vì các thử nghiệm chấp nhận cần phải chính thức, vì vậy chúng có thể được sử dụng làm thử nghiệm, nhưng cũng có thể đọc được để con người có thể phê duyệt chúng là những yêu cầu, phải không?

Có phải cũng đúng là sau này tôi thực hiện các thử nghiệm chấp nhận này và sử dụng chúng làm yêu cầu của mình, tức là chúng là một tập hợp các trường hợp sử dụng mà tôi thực hiện (thông qua TDD)? Tôi hy vọng tôi không tạo ra quá nhiều sự lộn xộn nhưng đó là dòng chảy hiện tại tôi có trong tâm trí.

Cập nhật
Tôi nghĩ ý định ban đầu của tôi không rõ ràng nên tôi sẽ cố gắng viết lại. Tôi muốn biết thêm chi tiết về luồng scrum khi biến câu chuyện người dùng thành mã trong khi sử dụng TDD.
Điểm khởi đầu là rõ ràng, người dùng sẽ đưa ra một nhu cầu (hoặc đại diện của người dùng là sản phẩm), đó là một mô tả 1-2 dòng ngắn theo định dạng đã biết và được thêm vào hồ sơ tồn đọng của sản phẩm.
Khi có một cuộc họp lập kế hoạch mùa xuân, câu chuyện của người dùng được lấy từ hồ sơ tồn đọng và được chỉ định cho các nhà phát triển.
Để một nhà phát triển viết mã, họ cần các yêu cầu (đặc biệt là trong TDD vì các yêu cầu là những gì các bài kiểm tra được lấy từ đó).
Khi nào, bởi ai và định dạng nào là các yêu cầu được biên soạn?
Điều tôi có trong đầu là sản phẩm và QA xác định các yêu cầu thông qua các bài kiểm tra chấp nhận (Tôi đang nghĩ đến việc tự động sử dụng FitNesse hoặc loại nhưng đó không phải là cốt lõi tôi nghĩ) giúp phục vụ 2 mục đích cùng một lúc:

1. Họ định nghĩa "Xong" đúng cách.
2. Họ cung cấp cho một nhà phát triển một cái gì đó để rút ra các bài kiểm tra.

Tôi không chắc chắn khi nào chúng được viết (trước khi nước rút chúng được chọn thì đó có thể là một sự lãng phí vì thông tin bổ sung sẽ đến hoặc câu chuyện sẽ không được chọn, trong quá trình lặp lại thì nhà phát triển có thể bị kẹt chờ chúng. ..)

Có đúng không khi nói rằng người quản lý sản phẩm và QA phải chịu trách nhiệm đưa câu chuyện của người dùng và chia nhỏ nó để kiểm tra chấp nhận?

Hầu hết. Họ có thể không thực sự viết bài kiểm tra chấp nhận thực tế. Họ có thể phê duyệt một cái gì đó bạn đã viết. Nhưng họ chấp thuận các bài kiểm tra chấp nhận. Đúng.

các thử nghiệm chấp nhận cần phải chính thức, để chúng có thể được sử dụng làm thử nghiệm, nhưng cũng có thể đọc được để con người có thể phê duyệt chúng là những yêu cầu, phải không?

Không liên quan. Họ có thể được chính thức hóa như các bài kiểm tra tự động. Hoặc chúng có thể không chính thức và đó có thể là công việc của bạn để tạo các bài kiểm tra tự động từ các tiêu chí kiểm tra chấp nhận không chính thức.

Cũng thế. "Yêu cầu" là câu chuyện của người dùng. Không có nhu cầu thực sự để tạo ra một phiên bản khác của câu chuyện gọi là "yêu cầu". Một số người thích xây dựng câu chuyện trước khi họ viết mã. Bạn có thể gọi các yêu cầu này, nhưng "thiết kế" là một từ tốt hơn. "Xây dựng" là từ tốt nhất.

Có phải cũng đúng là sau này tôi thực hiện các thử nghiệm chấp nhận này và sử dụng chúng làm yêu cầu của mình, tức là chúng là một tập hợp các trường hợp sử dụng mà tôi thực hiện (thông qua TDD)?

Đúng. Câu chuyện dẫn đến các bài kiểm tra chấp nhận. Câu chuyện là hành vi bắt buộc (nghĩa là "yêu cầu"). Câu chuyện dẫn đến các bài kiểm tra thúc đẩy thiết kế và phát triển phần mềm.

đó là dòng chảy hiện tại tôi có trong tâm trí.

Thực sự không có nhiều "dòng chảy" này.

Câu chuyện -> kiểm tra chấp nhận.

Câu chuyện -> công phu ("thiết kế", "yêu cầu") -> kiểm tra đơn vị -> mã.

Câu chuyện -> Người dùng có thể làm một cái gì đó có giá trị.

Câu chuyện -> Điểm câu chuyện -> tính toán vận tốc.

Lưu ý các mẫu. Câu chuyện phần lớn thúc đẩy mọi thứ.

Khi nào, bởi ai và định dạng nào là các yêu cầu được biên soạn?

Đầu tiên. Xác định "yêu cầu". Làm thế nào khác với chính câu chuyện?

Điều tôi có trong đầu là sản phẩm và QA xác định các yêu cầu thông qua các bài kiểm tra chấp nhận

Không thường xuyên.

trong quá trình lặp lại, nhà phát triển có thể bị kẹt chờ đợi họ.

Sai. Các nhà phát triển có thể (và thường không) giúp viết những điều này. Đó là điểm của "sự phát triển": xây dựng câu chuyện thành một "hoàn thành" được xác định rõ.

Lần nữa. Khi bạn có nghi ngờ hoặc câu hỏi, bạn thực sự phải đọc Tuyên ngôn Agile. Tuyên ngôn khá rõ ràng: các nhà phát triển phải nói chuyện với chủ sở hữu sản phẩm, người dùng, QA và tất cả những người khác là các bên liên quan. Sự tương tác thực sự là điều quan trọng nhất có thể xảy ra.

Tôi sẽ trả lời bạn từ góc độ của Lập trình cực đoan (XP) liên quan đến các bài kiểm tra chấp nhận.

Khi tôi lần đầu tiên tham gia (và đọc sách), tôi đã đọc rằng đó thực sự là vai trò của nhà phát triển để làm việc với khách hàng / người dùng để phát triển / ghi lại các bài kiểm tra chấp nhận. Một trong những mục tiêu của XP là tăng giao tiếp trực tiếp giữa người dùng / khách hàng và nhà phát triển. Điều này thường là lý tưởng, bởi vì nó làm giảm khả năng lỗi mã hóa do truyền thông sai các yêu cầu.

Tôi đã làm TDD được khoảng 8 năm và đã theo phương pháp trên. Tôi nghĩ rằng nó đã cải thiện tốc độ phát triển và sự hài lòng với hệ thống vì khách hàng / người dùng thấy họ đang ảnh hưởng trực tiếp đến sự phát triển của ứng dụng như thế nào.

Khó khăn chính mà tôi gặp phải (với các khách hàng nhỏ hơn), là rất khó để khiến họ tham gia vào việc chỉ định các thử nghiệm chấp nhận. (Thông thường tôi phải làm điều đó cho họ và gửi cho họ để xem xét.) Những khách hàng lớn hơn mà tôi đã làm việc cùng, thường có suy nghĩ này, vì vậy họ đã chuẩn bị để cung cấp các bài kiểm tra chấp nhận cụ thể.

Từ những gì tôi đã đọc về scrum, tôi không chắc nó xác định vai trò nào chịu trách nhiệm xác định / viết các bài kiểm tra chấp nhận. Tôi cho rằng nó có thể thay đổi từ nhóm này sang nhóm khác.

Lời khuyên của tôi là, bạn là một nhà phát triển, bạn nên tham gia càng nhiều càng tốt trong quá trình xác định thử nghiệm. Và mục tiêu là để có được kết quả chạy nước rút trước người dùng càng nhanh càng tốt, để họ có thể cho bạn biết mọi thứ họ quên nghĩ (hoặc những gì họ nói không chính xác với bạn) càng nhanh càng tốt.

Câu chuyện của người dùng không phải là "Là người dùng tôi muốn XXX sao cho YYY" ! Câu chuyện của người dùng là lời hứa cho việc liên lạc trong tương lai với PO. Điều đó giải quyết vấn đề của bạn với nhiều chi tiết hơn. Bạn phải liên lạc với PO trong khi chạy nước rút để có được bất kỳ thông tin nào bạn cần.

Câu chuyện của người dùng cũng có nhiều tính năng hơn sau đó là câu ngắn hứa hẹn cho việc giao tiếp. Phần cần thiết của câu chuyện người dùng là tiêu chí chấp nhận. Tiêu chí chấp nhận phải được biết trước khi cam kết với câu chuyện của người dùng (chúng phải được biết trước khi ước tính câu chuyện của người dùng). Tiêu chí chấp nhận là đầu vào cho các thử nghiệm chấp nhận = thử nghiệm chấp nhận nên kiểm tra các tiêu chí chấp nhận.

Vì vậy, khi bạn bắt đầu thực hiện câu chuyện người dùng với phương pháp TDD, trước tiên bạn (không phải QA) nên tạo thử nghiệm chấp nhận tự động dựa trên các tiêu chí chấp nhận để có được thử nghiệm thất bại cho nó. Bạn sẽ tiếp tục triển khai mã cần thiết bằng TDD trước khi vượt qua bài kiểm tra chấp nhận. Bạn sẽ tiếp tục với bài kiểm tra chấp nhận tiếp theo. Tôi đã viết về điều đó cũng trong một câu hỏi khác .