Chúng tôi hiện đang sử dụng JIRA để theo dõi công việc phát triển của mình. Quản lý của tôi muốn định dạng và phân loại mọi thứ là "Câu chuyện của người dùng", bao gồm các tác vụ không liên quan đến phát triển phần mềm. Ví dụ:

"Là người quản lý kiểm tra, tôi có thể thực hiện kiểm tra ứng dụng chỉ bằng các kiểm tra tự động và không kiểm tra thủ công để tôi có thể kiểm tra ứng dụng hiệu quả nhất có thể không?

Tiêu chí chấp nhận: 1. Chuyển đổi 50 bài kiểm tra thủ công hiện có sang bài kiểm tra hoàn toàn tự động 2. Bài kiểm tra phải thực hiện trong vòng chưa đầy 1 giờ "

Tôi muốn có ý thức từ cộng đồng nếu sử dụng "câu chuyện người dùng" cho công việc hỗ trợ quá trình phát triển phần mềm, không được lập trình viên thực hiện và không trực tiếp dẫn đến mã có thể phân phối. Hoặc điều này nên được xử lý / phân loại khác nhau (ví dụ, trong JIRA)?

Cập nhật ngày 6/7/2011 - Câu hỏi được nhắc lại để tập trung vào thuật ngữ "câu chuyện của người dùng".

Đúng

bất kỳ bên liên quan, bất kỳ tính năng cải thiện hệ thống

[hãy để những người theo chủ nghĩa thuần túy bắt đầu!]

"Quản lý của tôi muốn sử dụng Agile cho mọi thứ, kể cả các nhiệm vụ không liên quan đến phát triển phần mềm."

Điều này không có nghĩa là viết câu chuyện của người dùng cho mọi tính năng.

Nếu bạn muốn viết câu chuyện của người dùng cho mọi tính năng, bạn không nhất thiết phải là Agile. Bạn chỉ đang viết câu chuyện của người dùng cho mọi tính năng.

Câu chuyện của người dùng! = Nhanh nhẹn.

Câu chuyện của người dùng là một cách để thu thập và hiểu các yêu cầu. Chúng có thể được sử dụng một cách hoàn hảo, nếu bạn muốn. Một số người làm điều này.

Agile là một cách để quản lý dự án. Bạn có thể sử dụng Câu chuyện người dùng, hoặc không, trong một dự án Agile.

Câu chuyện của người dùng để quản lý nợ kỹ thuật và các nhiệm vụ nội bộ - một lần nữa - không liên quan gì đến việc Agile.

Nhiều người hoàn toàn hài lòng khi thêm các tính năng "kỹ thuật" hoặc "hỗ trợ" vào giai đoạn nước rút mà không lãng phí thời gian để viết một "câu chuyện người dùng" giả cho người dùng hoàn toàn nội bộ, giới hạn giá trị gia tăng, không liên quan.

Nếu QA không hiểu câu chuyện của họ, thì có bao nhiêu mất mát kinh doanh thực sự?

Nếu các bên liên quan thực sự không có được câu chuyện của họ, doanh nghiệp thực sự bị ảnh hưởng.

Điều này không có ý nghĩa với tôi. Về bản chất, 'Câu chuyện người dùng' chỉ là câu chuyện người dùng, không phải câu chuyện của Người quản lý dự án, không phải Câu chuyện của nhà phát triển, không phải câu chuyện về Kỹ sư đảm bảo chất lượng.

Trên lưu ý đó, phần mềm là:

1. Có thể xác định
2. Có thể kiểm tra

Cải tiến quy trình là kết thúc mở, và thường chủ quan.

Tiêu chí chấp nhận: 1. Cải thiện để kiểm tra 1 (theo x / y)

Làm thế nào để bạn đo lường Cải thiện để thử nghiệm? Không có hợp đồng chắc chắn cho điều đó.

Và trên một lưu ý không liên quan, tôi TỰ TIN rằng ví dụ của bạn đã nêu ở trên,

Là người quản lý kiểm tra, tôi có thể thực hiện kiểm tra ứng dụng chỉ bằng các kiểm tra tự động và không kiểm tra thủ công để tôi có thể kiểm tra ứng dụng hiệu quả nhất có thể không?

... chỉ là một ví dụ, bởi vì có quá nhiều điều sai trái mà tôi thậm chí không thể bắt đầu mô tả.

Nợ kỹ thuật có thể được xử lý theo cách tương tự như câu chuyện của người dùng nhưng đôi khi điều này có thể trở nên khá xấu xí. Ví dụ: để có một câu chuyện như: "Là nhà phát triển, tôi muốn có các thử nghiệm đơn vị làm việc để tôi có thể tin tưởng vào các thử nghiệm để xác thực nếu các thay đổi khác phá vỡ điều gì đó", không có nhiều giá trị cho chủ sở hữu sản phẩm nhưng cũng có thể là một ý tưởng tốt cho nhóm để thực hiện như là một phần của tái cấu trúc của chính nó, đó là một phần của công việc trong một lần chạy nước rút.

Tôi thích ý tưởng có các tác vụ tách biệt với các câu chuyện của người dùng vì các tác vụ sẽ không phải là thứ mà bạn sẽ hiển thị cho người dùng cuối của hệ thống nhưng có thể là thứ giúp cải thiện bảo trì và thời gian có thể phát triển một số tính năng mới. Tùy thuộc vào số lượng nhiệm vụ, xét về tổng số điểm vì một số nhiệm vụ có thể là 2 phút và các nhiệm vụ khác có thể là 2 tuần, đã xây dựng nên đây có thể là yếu tố quyết định nếu nhóm thực hiện chạy nước rút và không đưa vào các tính năng mới nhưng hoạt động về các nhiệm vụ để dọn dẹp những thứ mà tôi đã thấy một vài lần khi tôi làm việc.

Theo ý kiến ​​khiêm tốn của tôi, có, bạn có thể sử dụng các câu chuyện của người dùng cho các dự án phát triển phi phần mềm, không chỉ xử lý các nhiệm vụ cải tiến. Lấy ví dụ, 3 năm trước tôi là người đàn ông tốt nhất trong đám cưới của bạn tôi và tôi đã sử dụng phương pháp Agile và câu chuyện người dùng để lên kế hoạch cho đám cưới. Tất cả các nhiệm vụ chúng tôi phải hoàn thành được viết dưới dạng câu chuyện của người dùng với tính cách, ý định, sự biện minh và tiêu chí thành công cho mỗi câu chuyện của người dùng. Tất cả các bên liên quan đã tham gia vào scrum hàng ngày của chúng tôi để thảo luận về những gì chúng tôi đã làm ngày hôm trước và những gì chúng tôi sẽ làm ngày hôm đó. Mọi người đều bị phân tán về mặt địa lý do đó chúng tôi đã tổ chức các cuộc gọi hội nghị cho các cuộc họp scrum hàng ngày, lập kế hoạch chạy nước rút, hồi tưởng, viết truyện và các phiên ước tính .... bạn đặt tên cho nó, chúng tôi đã làm điều đó. Chúng tôi đã có 6 lần chạy nước rút trong tổng số (3 tháng) và đám cưới là một thành công đáng kinh ngạc mà không có hòn đá nào được lật lại.

Bạn có một vấn đề sâu sắc khi bạn đặt "câu chuyện người dùng" nội bộ vào hỗn hợp với câu chuyện người dùng thực tế.

Vui lòng đọc lại nhiều định nghĩa về "các bên liên quan" như bạn có thể tìm thấy.

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubled.com/2009/04/scrum-pigs-and-chickens.html

Đọc chúng rất, rất cẩn thận để bạn có thể thấy sự khác biệt giữa Gà và Lợn.

"Câu chuyện người dùng" nội bộ được viết bởi những con gà.

Câu chuyện người dùng thực tế được viết bởi lợn.

Câu chuyện người dùng "hướng gà" của bạn không quan trọng lắm. Cho dù quản lý muốn theo dõi chúng như thế nào thì chúng là những câu chuyện người dùng thực sự có giá trị thực, chúng không phải là những câu chuyện người dùng thực sự và chúng không tạo ra giá trị theo cùng một cách.

Ở cạnh mờ của đối số là vấn đề QA. QA là quan trọng và không có nó, không có gì hoạt động.

Điều đó không kỳ diệu làm cho QA đột nhiên trở thành một con lợn. Nó làm cho họ vẫn không phải là một bên liên quan. Họ cung cấp hỗ trợ, cơ sở hạ tầng và một nền tảng thiết yếu cho phần còn lại của công việc. Nhưng chúng là "câu chuyện người dùng" về cơ bản khác với câu chuyện người dùng thực sự của người dùng thực.

Nếu QA không hiển thị thử nghiệm một cải tiến trong thử nghiệm, không ai sẽ rời khỏi doanh nghiệp. Tiền không mất.

Nếu người dùng không thể tiến hành kinh doanh ngay từ đầu, bạn sẽ không hoạt động. Tiền mất rồi. Toàn bộ hoạt động là một thất bại hoàn toàn.

Không giao dịch nội bộ ("gà") và các bên liên quan thực sự ("lợn").

Các bình luận "gà và lợn" bỏ lỡ điểm. Các bên liên quan nội bộ là gà khi nói đến sản phẩm đang được phát triển (trừ khi nó được phát triển cho chúng), nhưng chúng là lợn khi nói đến quá trình phát triển.

Câu hỏi bạn đang hỏi là liệu công thức câu "Là một , Tôi muốn có thể _ , để tôi có thể __ "sẽ hữu ích cho việc xác định và cải thiện quy trình kinh doanh trong đó các cải tiến không yêu cầu viết mã phần mềm mới. Tôi đã tìm thấy chủ đề này bởi vì tôi đang nghĩ về việc làm điều tương tự và đang tìm kiếm cách thực hành tốt nhất, nhưng Trực giác mạnh mẽ của tôi là câu trả lời cho câu hỏi của bạn là "có." Mục đích của cấu trúc câu thực sự là buộc người viết phải trừu tượng hóa các giải pháp mà họ có thể có trong đầu và tập trung vào những gì người dùng - trong đó trường hợp, người dùng quy trình - muốn có thể làm được. Tôi thấy không có lý do tại sao câu chuyện người dùng sẽ không hữu ích khi áp dụng vào quy trình.

Quan điểm về tiêu chí chấp nhận là một tiêu chí tốt, nhưng không cần phải giáo điều về nó (dù sao đó là Agile). Đó là một bài tập tốt khi thiết kế bất kỳ quy trình kinh doanh nào để hỏi, "Làm thế nào tôi biết nếu thay đổi trong quy trình hoàn thành mục tiêu của tôi?" Đúng là bạn không thể luôn chạy thử nghiệm tự động để trả lời câu hỏi đó, nhưng đó không phải là lý do để loại bỏ câu chuyện của người dùng như một công cụ.