Một câu chuyện người dùng nên được chia sẻ giữa các nhà phát triển? [đóng cửa]

Tôi thường thấy những câu chuyện có sự phát triển back-end và front-end. Ví dụ, hãy xem xét một hộp thoại lớn với một vài bảng và một số điều khiển động. Chúng tôi sẽ tạo một vài câu chuyện (có thể một câu chuyện cho mỗi bảng và một câu chuyện khác cho hệ thống điều khiển động).

Nhóm dev sau đó sẽ chia tay với một người ở mặt sau và một người khác ở mặt trước. Điều này giúp người back-end dễ dàng lo lắng về cấu trúc của lớp SQL trong khi người front-end tập trung vào những thứ như bố cục. Sau khi giao diện ban đầu giữa back-end và front-end được thỏa thuận, hai nhà phát triển có thể tập trung sự chú ý của họ để hoàn thành phần của họ vào cuối giai đoạn nước rút.

Rồi đến sự hỗn loạn. Ai "sở hữu" câu chuyện nào? "Trong tiến trình" có nghĩa là gì hoặc "thực hiện" là gì? Chúng ta có nên làm hai câu chuyện riêng biệt cho back-end và front-end? Nếu vậy, điều đó không phá vỡ ý tưởng về câu chuyện của người dùng dựa trên tính năng? Hệ thống của chúng tôi có một khái niệm về "nhiệm vụ phụ", giúp giảm bớt một số vấn đề này. Nhưng các nhiệm vụ phụ thêm một sự phức tạp thêm. Có cách nào tốt hơn? Đây có phải là cách "xấu" để sử dụng Scrum không?

Tôi đã sử dụng một số hình thức Agile trong vài năm qua tại một vài nơi. Tôi chưa được đào tạo chính thức, vì vậy xin vui lòng tha thứ cho bất kỳ thuật ngữ hoặc ý thức hệ sai. Tôi chỉ đang cố gắng học những cách thiết thực để cải thiện quy trình của chúng tôi.

Một "câu chuyện" được đặt tên như vậy bởi vì nó đại diện cho một câu chuyện hoàn chỉnh, tốt , từ quan điểm của khách hàng. Không có mặt trước hoặc mặt sau, không có đường dẫn trường hợp sử dụng để khách hàng thực thi.

Trong trường hợp của bạn, tôi nghĩ cả front-end và back-end nên là một câu chuyện duy nhất. Chia nó thành các nhiệm vụ. Các nhà phát triển sở hữu các nhiệm vụ khác nhau của họ. Các tác vụ này có thể được theo dõi riêng lẻ thông qua các giai đoạn của chúng - Đang thực hiện, Mã hóa xong, Thử nghiệm mô-đun đã hoàn thành, v.v.

Đảm bảo bạn bao gồm các nhiệm vụ được gán QA trong cùng một câu chuyện - mà không xác thực một câu chuyện là vô ích. QA sẽ kiểm tra câu chuyện tích hợp từ đầu đến cuối mà khách hàng sẽ thấy. Chỉ sau đó, câu chuyện tổng thể mới được đánh dấu là Xong. Trong một môi trường Agile lý tưởng, một khách hàng thực sự hoặc một proxy khách hàng cũng thử câu chuyện trong một ứng dụng đang chạy và đánh dấu câu chuyện Được chấp nhận nếu nó đáp ứng các yêu cầu đã thỏa thuận.

Nếu bạn muốn các vòng phản hồi nhanh hơn, hãy thử chia trường hợp sử dụng thành các tính năng đầu cuối nhỏ hơn. Ví dụ: thay vì trường hợp sử dụng như "Khách hàng có thể mua đồ bằng cách sử dụng giỏ hàng", hãy chia thành "Khách hàng có thể thêm sản phẩm vào giỏ hàng", v.v. Sau đó, hãy hoàn thành từng trường hợp sử dụng nhỏ hơn kết thúc để kết thúc như mô tả ở trên.

EDIT: Tôi muốn sao lưu các điểm trên với một số nguồn. Các đặc điểm của một câu chuyện người dùng tốt được thể hiện chính xác bằng một từ viết tắt gọi là " ĐẦU TƯ ". Nó được tạo ra bởi Bill Wake và phổ biến bởi phong trào Scrum. Đặc biệt lưu ý các mục về câu chuyện là Độc lập và Dọc.

Một số thông tin ở đây và ở đây .

Ai "sở hữu" câu chuyện nào?

Bất cứ ai nắm bắt câu chuyện. Họ quan trọng từ quan điểm tổ chức là một người chịu trách nhiệm về công việc. Một khi bạn có được hai người, thật dễ dàng để vượt qua vòng lao lý.

Chúng ta có nên làm hai câu chuyện riêng biệt cho back-end và front-end? Nếu vậy, điều đó không phá vỡ ý tưởng về câu chuyện của người dùng dựa trên tính năng?

Nó phụ thuộc. Tôi đã thấy cả hai cách làm việc. Nếu câu chuyện đủ lớn để có hai nhà phát triển làm việc toàn thời gian cho nó, thì có lẽ nó nên được chia ra. Nếu hai nhà phát triển là một phần của hai nhóm khác nhau, thì có lẽ nên chia tách. Nếu hai nhà phát triển sẽ làm việc với nó trong các lần chạy nước rút khác nhau, thì có lẽ nó nên được tách ra.

Đây có phải là cách "xấu" để sử dụng Scrum không?

Chìa khóa cần nhớ là quá trình đó là để phục vụ bạn chứ không phải ngược lại. Câu chuyện của người dùng là một cách để những người kỹ thuật và những người không có kỹ thuật tạo điều kiện giao tiếp. Họ đánh vần những gì họ muốn, mọi người đàm phán và sau đó bạn cung cấp phản hồi trong câu chuyện về tiến trình của nó.

Miễn là quá trình làm việc cho bạn, nó không thể tệ đến thế.

Khi chúng tôi đã triển khai các mô hình Scrum, hoàn toàn mong đợi rằng nhiều nhà phát triển có thể tham gia vào một câu chuyện người dùng. Có thể có công việc cho lớp dữ liệu, tích hợp, CSS front-end, cơ sở hạ tầng, v.v. Nhóm có thể kết hợp với nhau trên các tác vụ phụ khác nhau cho một câu chuyện để hoàn thành nó.

Điều đó đang được nói, một người sở hữu câu chuyện và chịu trách nhiệm cập nhật về tiến trình của nó và đảm bảo mọi người đã hoàn thành tác phẩm của mình và nó đang hoạt động cùng nhau. Đây là người cho chúng tôi báo cáo rằng một câu chuyện đã được "thực hiện".

Giống như những người khác đã đề xuất, nhóm của tôi cũng chia câu chuyện người dùng của chúng tôi thành các nhiệm vụ. Điều này thường dễ thực hiện nếu bạn đang quản lý các câu chuyện người dùng của mình thông qua phần mềm (chẳng hạn như JIRA hoặc Rally). Sau đó, thật dễ dàng để nói những phần của câu chuyện đang di chuyển cùng.

Nhưng một sự thay thế cho các nhiệm vụ sẽ là chỉ định lại quyền sở hữu khi mỗi người hoàn thành phần của mình. Vì vậy, câu chuyện được thông qua - có thể nhà phát triển 1 bắt đầu nó với công việc phụ trợ, sau đó chuyển cho nhà phát triển 2 để thực hiện UI. Sau đó, nó được chuyển cho người kiểm tra QA của bạn để xác minh. Phương pháp này sẽ hoạt động tốt trong môi trường bạn đang sử dụng thẻ thực tế trên tường hoặc nếu phần mềm của bạn không theo dõi các tác vụ.

Nhưng trong mọi trường hợp, tôi khuyên bạn không bao giờ gọi một câu chuyện là "xong" cho đến khi nhóm đồng ý rằng nó đã được thực hiện, bao gồm cả thử nghiệm. Bằng cách đó, mọi người đều có cơ hội đưa ra ý kiến ​​đóng góp của mình. Và nếu bạn kết hợp điều này với các ý tưởng về quyền sở hữu mã tập thể và đánh giá mã thì mọi câu chuyện đều thực sự được "sở hữu" bởi nhóm. Nó có thể được "giao" cho những người khác trên đường đi, nhưng nếu có ai đó ra ngoài (ốm / nghỉ / quá nhiều cuộc họp? / Khác) thì công việc vẫn có thể hoàn thành.

Nhóm của tôi thường chấp nhận các câu chuyện của người dùng như một phần của cuộc họp trực tiếp / SCRUM buổi sáng của chúng tôi. Bằng cách đó, mọi người có thể dễ dàng thừa nhận hoặc tranh chấp cho dù nó thực sự "được thực hiện". Những lần khác, chúng tôi chỉ để kỹ sư QA của mình làm điều đó - nếu cô ấy hài lòng rằng nó đã được thử nghiệm và hoạt động, và tất cả các nhiệm vụ đã hoàn thành, thì chúng tôi gọi nó là xong.

Hôm nay tôi đang gọi dự án lớn hơn này là "sử thi". Một bản anh hùng ca được tạo thành từ nhiều câu chuyện và nó có thể kéo dài nhiều lần chạy nước rút / lặp lại. Một câu chuyện, đối với chúng tôi, luôn được trao cho một nhà phát triển duy nhất và phải phù hợp với một lần chạy nước rút. Một câu chuyện sau đó được chia thành các nhiệm vụ. Mỗi nhiệm vụ được hoàn thành bởi cùng một nhà phát triển về câu chuyện đó. Các nhiệm vụ có nghĩa là cung cấp cái nhìn sâu sắc về tiến trình của câu chuyện trong quá trình chạy nước rút / lặp lại. Khi mỗi câu chuyện được hoàn thành, bởi mỗi nhà phát triển, sử thi cho thấy sự tiến bộ.

Điểm chính của sử thi là có một mục tiêu lớn hơn mà không nhất thiết phải phù hợp với một lần chạy nước rút / lặp. Theo thời gian tất cả các câu chuyện được hoàn thành và sử thi kết thúc. Sử thi được đặt vào một bản phát hành.

Rồi đến sự hỗn loạn. Ai "sở hữu" câu chuyện nào? "Trong tiến trình" có nghĩa là gì hoặc "thực hiện" là gì?

Chúng tôi giới thiệu mã mỗi hai tuần trong đó các câu chuyện cho lần chạy nước rút / lặp đó phải được hiển thị cho các bên liên quan và được phê duyệt. Trong bối cảnh này "thực hiện" cho một câu chuyện có nghĩa là tôi có thể cho bạn thấy những gì nó làm. Một nhà phát triển sở hữu câu chuyện của họ và chịu trách nhiệm hiển thị nó (phần này là một sự đơn giản hóa quá mức, nhưng đủ tốt cho câu trả lời này; chúng tôi phối hợp các bản demo của mình thông qua một người). "Xong" có nghĩa là nó có thể được trình diễn thành công. "Trong tiến trình" có nghĩa là tôi có nhiệm vụ xuất sắc và câu chuyện chưa hoàn thành. Một bản anh hùng ca đã hoàn thành khi tất cả những câu chuyện cho bản anh hùng ca đó đã được thể hiện thành công.

Bây giờ đây là tiến trình trường hợp hoàn hảo. Chúng tôi có những câu chuyện và bản demo thất bại, người dùng muốn thứ khác, v.v. Trên đây là mục tiêu và phần lớn nó hoạt động.