Agile - Định nghĩa câu chuyện của người dùng

Question

Tôi đang viết một ứng dụng nhỏ cho doanh nghiệp của bạn tôi, và nghĩ tôi sẽ tận dụng cơ hội để tập trung vào một số khóa đào tạo Quản lý dự án Agile mà tôi đã làm vào đầu năm.

tôi (và tôi nghĩ, tổ chức hiện tại của tôi!) Đã luôn luôn phải vật lộn với yêu cầu thu thập dưới hình thức Câu chuyện dùng, mà mang hình thức:

Là một [User Type] Tôi muốn [Tính năng] để [một số lợi ích]

Tôi là luôn luôn bị cám dỗ bỏ lỡ đầu và cuối, và chỉ để lại tính năng - nhưng điều này sau đó chỉ trở thành yêu cầu thu thập theo cách cũ!

Nhưng tôi không muốn chỉ làm cho nó phù hợp, để tôi có thể nói 'Tôi đang làm Agile' .... ví dụ, nếu tôi biết rằng người dùng sẽ được trình bày với một danh sách các mục thì lý do là hiển nhiên, phải không?

ví dụ:

Là một [Quản lý cửa hàng] tôi muốn [xem danh sách các hạng mục cổ phiếu] sao cho ...?

Thực tiễn bình thường có bỏ qua mệnh đề [để] không?

Answer 1

Chúng tôi cũng thường bỏ lỡ nó. Và bằng cách bỏ nó ra, chúng tôi đã bỏ lỡ rất nhiều. Để hiểu tính năng đúng cách và không chỉ làm điều đúng mà còn làm điều đó là chìa khóa để biết TẠI SAO tính năng này, và điều quan trọng tiếp theo là WHO (vai trò) Trong các điều khoản DDD, các bên liên quan. Các bên liên quan có thể khác nhau, mọi người quan tâm. Từ lập trình viên và quản trị viên db cho tất cả các loại người dùng.Vì vậy, đầu tiên hiểu, ai là bên liên quan, sau đó bạn biết 50% TẠI SAO ông quan tâm, sau đó là lợi ích, và sau đó nó đã gần như rõ ràng GÌ để thực hiện.

Cố gắng không chỉ viết "làm người dùng". Chỉ định. "là người quản lý cửa hàng", hoặc thậm chí "là người dẫn đầu sự thay đổi chịu trách nhiệm đóng cửa ngày", tôi cần .... để ....

Có thể bạn có thể thực hiện điều gì đó khác biệt sẽ cung cấp cho cùng một bên liên quan lợi ích tốt hơn !!!

Answer 2

Tôi nghĩ bạn nên thực sự cố gắng để có được một lý do được xác định, ngay cả khi nó có vẻ hiển nhiên. Nếu bạn không thể đưa ra lý do thì tại sao lại xây dựng tính năng này ngay từ đầu? Ngoài ra, lý do có thể chỉ ra những thiếu sót khác trong thiết kế có thể kích hoạt cải tiến ở các khu vực khác.

Answer 3

Tôi thường phân loại câu chuyện của mình theo người dùng/persona mà nó chủ yếu liên quan đến, do đó tôi không đặt nhận dạng của người dùng trong tiêu đề câu chuyện. Câu chuyện của tôi cũng lớn hơn một số phương pháp luận nhanh nhẹn đề xuất. Thông thường, tôi bắt đầu với một tiêu đề. Tôi sử dụng nó cho mục đích lập kế hoạch. Khi tôi gần gũi với việc thực sự làm việc về câu chuyện đó, tôi xác định một số chi tiết - ý tưởng cơ bản, ràng buộc, giả định, những câu chuyện liên quan - để tôi nắm bắt được nhiều thông tin mà tôi biết về nó. Tôi cũng giữ câu chuyện của tôi trong một wiki, không phải trên thẻ ghi chú. Tôi hiểu sự cân bằng - nghĩa là, tôi có thể dành quá nhiều thời gian vào chi tiết trước khi tôi cần chúng, nhưng tôi có thể nắm bắt và chia sẻ nó với, thường là các khách hàng bên ngoài một cách dễ dàng.

Điểm mấu chốt đối với tôi là Agile là một triết lý, chứ không phải là một đặc điểm kỹ thuật. Có những triển khai cụ thể có thể (mạnh mẽ) đề nghị bạn làm mọi thứ theo một cách nhất định và có thể không thương lượng được đối với một số mặt hàng. Ví dụ, thật khó để nói rằng bạn đang làm XP nếu bạn không ghép nối chương trình. Nói chung, mặc dù, tôi sẽ nói rằng hầu hết các nhà agilists sẽ nói rằng bạn nên làm những điều đó làm việc cho bạn, theo cách họ làm việc cho bạn - miễn là chúng phù hợp với các nguyên tắc chung, bạn vẫn có thể gọi bản thân bạn nhanh nhẹn. Các nguyên tắc chung sẽ bao gồm những thứ như phát hành sớm/phát hành thường xuyên, kiểm tra đơn vị, lặp lại ngắn, xác nhận rằng thay đổi sẽ xảy ra, trì hoãn lập kế hoạch chi tiết cho đến khi bạn sẵn sàng thực hiện, ...

Tóm lại cho tôi: nếu câu chuyện làm việc cho bạn mà không có người dùng và lý do - miễn là bạn hiểu người dùng là ai và tại sao họ muốn một cái gì đó - hãy làm điều đó theo cách bạn muốn. Chỉ cần không yêu cầu một đặc điểm kỹ thuật đầy đủ trước khi bạn bắt đầu thực hiện.

Answer 4

Câu chuyện của người dùng là một cách khác để nói rằng bạn cần phỏng vấn người dùng của mình để tìm hiểu xem họ muốn gì và họ đang cố giải quyết những vấn đề gì. Đó là trái tim của việc này trong sự phát triển nhanh nhẹn. Nếu biểu mẫu không hoạt động cho bạn thì hãy lùi lại một bước và thử một cách tiếp cận khác mà cảm thấy tự nhiên hơn cho bạn hoặc phù hợp hơn với khả năng của bạn với tư cách là một nhà văn.

Tóm lại không có cảm giác như bạn phải mặc áo khoác thẳng. Điều quan trọng là bạn theo tinh thần của phương pháp luận.

Trong trường hợp cụ thể này, bạn muốn nhận danh sách những vấn đề mà người dùng gặp phải, tại sao chúng là vấn đề và những gì họ nghĩ sẽ giúp họ.

Answer 5

Không, thực sự không rõ ràng - có rất nhiều lý do để muốn xem danh sách, rất nhiều thứ bạn có thể muốn - quét tìm một số thông tin, xem tổng quan, in, sao chép và dán nó vào một tài liệu từ vv Và chính xác nó sẽ cho bạn những gợi ý có giá trị về chi tiết thực hiện hợp lý - định dạng danh sách, nội dung chính xác; hoặc thậm chí gợi ý rằng một tính năng khác có thể là một ý tưởng tốt hơn để thỏa mãn nhu cầu đó. Đừng ngạc nhiên khi biết rằng lý do thực sự là "để tôi có thể đếm số lượng mục nhập" ...

Tất nhiên, điều này có thể không áp dụng cho bạn. Điểm thực tế của tôi trên thực tế là có nhiều lý do khiến mọi người nghĩ ra mẫu này - và cũng có nhiều lý do khiến nhiều người có kinh nghiệm không thực sự sử dụng nó. Và khi bạn mới tập luyện, bạn không ở trong một vị trí tốt để đánh giá tất cả những ưu và khuyết điểm của việc thực hành sau, vì vậy tôi khuyên bạn nên cố gắng làm theo nó một cách chặt chẽ trong một thời gian. Bạn có thể ngạc nhiên bởi tính hữu ích của nó - hay không, trong trường hợp đó bạn vẫn học được điều gì đó và có thể thả nó với một súc tích rõ ràng ... :)

Answer 6

Hãy thử, để đạt được [Giá trị kinh doanh] Là [người dùng] tôi cần [Tính năng].

Mục đích là tập trung vào giá trị mà đối tượng cung cấp. Nó giúp bạn suy nghĩ trong các lát thẳng đứng, làm giảm "nhiệm vụ kỹ thuật" thuần túy mà không nhìn thấy được. Nó không phải là một quá trình chuyển đổi dễ dàng, nhưng khi bạn bắt đầu suy nghĩ theo chiều dọc, bạn bắt đầu thực sự có khả năng giảm lãng phí trong quá trình của bạn.

Một cách khác là suy nghĩ về các thử nghiệm chấp nhận mà khách hàng của bạn có thể viết để đảm bảo tính năng sẽ hoạt động. Đó là một bước nhảy ngắn để sau đó sử dụng một cái gì đó như FitNesse để tự động kiểm tra.