Nhà phát triển có thể mong đợi bao nhiêu chi tiết về câu chuyện người dùng?

Hạn chế lớn nhất của sự phát triển nhanh mà tôi đã trải qua là những người không tham gia phát triển tập trung vào câu thần chú rằng câu chuyện của người dùng (3-10 ngày người lý tưởng) không nên chứa nhiều hơn 1-3 câu như:

Là một khách hàng, tôi có thể sử dụng tìm kiếm văn bản miễn phí để tôi có thể tìm thấy các sản phẩm tôi đang tìm kiếm.

Đưa ra câu này, các nhà quản lý dự án mong muốn tôi là một nhà phát triển cam kết ước tính và phát triển câu chuyện. Họ cho rằng phát triển nhanh có nghĩa là những câu như thế này là tất cả những gì họ phải cung cấp cho các nhà phát triển.

Tôi sẽ không trách họ vì tài liệu nổi tiếng về phát triển nhanh tạo ra ấn tượng rằng điều này sẽ thực sự hoạt động. Tôi đã đọc thứ gì đó như 2 trang bằng ngôn ngữ tự nhiên cho mỗi câu chuyện trong "Lập kế hoạch XP", nhưng đó là nó. Bởi vì "phần mềm làm việc" được ưa chuộng hơn "tài liệu toàn diện", chủ đề này dường như thường được tránh.

Tất nhiên, thực tế là nếu nhà phát triển có cơ hội làm điều đó, một cuộc phỏng vấn với khách hàng sẽ đưa ra một danh sách dài các yêu cầu mà khách hàng có về câu chuyện:

• Chúng ta cần các toán tử boolean như AND và OR.
• Chúng tôi cần tìm kiếm mờ tất cả các điều khoản.
• Chúng ta cần tìm kiếm theo từng từ cũng như theo cụm từ.
• Chúng tôi không muốn tìm các sản phẩm đáp ứng các tiêu chí X, Y và Z.
• Chúng tôi muốn sắp xếp kết quả. Ồ, và nhân tiện, người dùng có thể chọn tiêu chí sắp xếp trong hộp tổ hợp với các tùy chọn a, b và c.

Vì vậy, bạn thấy rằng tôi không nói về chi tiết kỹ thuật hoặc thiết kế phần mềm hoặc thậm chí chi tiết triển khai. Đó là yêu cầu thuần túy. Càng nói lâu, khách hàng càng nhận ra rằng thực sự có khá nhiều điều để nói về những gì họ muốn.

Nhưng thường thì tôi thấy mình trong tình huống những thông tin đó không được cung cấp hoặc theo kiểu rất kém chất lượng. Tôi cũng không thể thực hiện cuộc phỏng vấn, cũng như người không ở vị trí thực hiện cuộc phỏng vấn sẽ cung cấp cho tôi kết quả của nó.

Đôi khi, các nhà quản lý thậm chí còn đưa ra các chi tiết kỹ thuật như "chúng tôi muốn tìm kiếm Lucene" nhưng họ không muốn nghĩ về việc họ chỉ muốn tìm tên sản phẩm hay mô tả sản phẩm. Đôi khi tôi nghĩ rằng họ chỉ lười biếng;)

Đối với tôi, đây là vấn đề hàng đầu trong các dự án tôi làm việc (ứng dụng web kinh doanh điện tử, 500-2000 ngày mỗi người cho mỗi dự án). Tôi đã giải quyết vấn đề này thường xuyên đủ và các nhà quản lý nhận thức được rằng hầu hết các nhà phát triển có vấn đề với tình huống này. Nhưng họ tin rằng các nhà phát triển chỉ là quá nhiều "người cầu toàn". Họ có vẻ khó chịu khi các nhà phát triển "luôn muốn có mọi thứ được chỉ định".

Do thiếu các con số được thừa nhận chung, thật khó để tranh luận. Mọi người đều biết một lần lặp nên kéo dài bao lâu. Nhưng không ai có thể nói cần bao nhiêu yêu cầu để ước tính và phát triển một câu chuyện.

Bạn có một số tài liệu tham khảo?

Bạn đang thiếu điểm nhanh nhẹn một chút. Những gì bạn đang gọi là một câu chuyện người dùng, tôi thấy có ít nhất sáu: một tìm kiếm đơn giản và một cho mỗi điểm đạn của bạn. Bằng mọi cách, hãy lập đủ kế hoạch để tránh vẽ mình vào một góc sẽ tốn kém để thoát ra, nhưng toàn bộ ý tưởng là bạn cung cấp tối thiểu cần thiết để cung cấp một số giá trị và thực hiện đủ nhanh để nhận được phản hồi nhanh chóng.

Khi bạn chia một câu chuyện như vậy, nó không chỉ giúp bạn ước tính dễ dàng hơn, nó cho phép chủ sở hữu sản phẩm ưu tiên theo cách chi tiết hơn. Chắc chắn họ thích khả năng sắp xếp kết quả tìm kiếm, nhưng có lẽ nó không quan trọng bằng một mục khác trong hồ sơ tồn đọng hoàn toàn không liên quan đến tìm kiếm.

Ngoài ra, trên ý tưởng lập trình viên cần mọi thứ được chỉ định, hãy thử nhìn nó từ quan điểm của khách hàng. Rất nhiều lần, nó giống như bạn đang đi mua một chiếc xe hơi, và nhân viên bán hàng đang hỏi bạn muốn màu gì cho núm gạt nước kính chắn gió. Rất nhiều chi tiết chúng tôi có thể thấy quan trọng là hoàn toàn không liên quan từ quan điểm của khách hàng. Tôi đã làm việc ở những nơi yêu cầu quá cao, và tin tôi đi, nó không vui lắm. Loại vĩ độ bạn đang phàn nàn, rất nhiều lập trình viên rất thích có.

Âm thanh giống như vấn đề đầu tiên là bạn không cần phải áp dụng ước tính thời gian cho câu chuyện của người dùng. Bạn phải lấy một câu chuyện và áp dụng "điểm câu chuyện", đó là ước tính chung về độ phức tạp từ 1 đến INFINITY. Điểm câu chuyện thường được chạy một số thứ như 1,2,3,5,8,13,20 ... (Mỗi tổ chức đều có quy tắc riêng.) Họ thường áp dụng một cái gì đó như:

1 - Bạn có thể làm điều đó trong giấc ngủ của bạn và nó hầu như không đáng để thực hiện. 2 - Bạn hiểu điều này và có thể hoàn thành nó nhanh chóng với ít rủi ro bị tràn ngập. 3 - Bạn hiểu điều này, nhưng có thể có một hoặc hai điều bất ngờ. 5 - Đây là một nghiên cứu nhỏ và có một số rủi ro nhỏ. 8 - Đây là một nhiệm vụ lớn, cần nhiều nghiên cứu và có thể không phù hợp với nước rút. 13 - Điều này là rất lớn, và chắc chắn sẽ không phù hợp với nước rút. Có rủi ro lớn. Vân vân.

Nói chung, bất kỳ câu chuyện người dùng nào từ 8 trở lên cần được chia thành các câu chuyện nhỏ hơn.

Nếu bạn không có thông tin để làm điều này, bạn chắc chắn nên gửi lại cho người quản lý dự án và nói rằng bạn cần thêm thông tin.

Bạn thực sự chỉ nên ước tính thời gian một khi bạn đã chấp nhận câu chuyện vào giai đoạn nước rút, nhưng ngay cả khi đó, có ít sự nhấn mạnh về điều này. Ý tưởng là một khi nhóm của bạn đã quen với quy trình trỏ, bạn có thể đo sản lượng thô của nó trên mỗi lần chạy nước rút trong các điểm câu chuyện và lên kế hoạch theo cách đó. Bạn không muốn lập kế hoạch cho một khoảng thời gian ngắn hơn so với nước rút. Ý tưởng ở đây là nếu bạn chia nhỏ các nhiệm vụ một cách chính xác để nhiều câu chuyện phù hợp với một lần chạy nước rút và nằm trong phạm vi điểm 1-5, điều đó có nghĩa là chúng được xác định rõ.

Ngoài ra, có vẻ như các PM tại công ty của bạn không hiểu "câu chuyện" là gì. Một phần quan trọng của "câu chuyện người dùng" là tiêu chí thoát. Tiêu chí thoát là một hoặc hai câu ngắn mô tả rõ ràng làm thế nào có thể chỉ ra rằng bộ lưu trữ này được hoàn thành. Lý tưởng nhất, đây phải là điều mà các QA của bạn đã nói "vâng, chúng tôi có thể kiểm tra điều đó". Điều quan trọng là các PM phải hiểu rằng câu chuyện của người dùng đã hoàn tất khi phần mềm đáp ứng "tiêu chí thoát". "Nhưng chúng tôi không muốn điều đó" không cắt nó. Nếu họ không muốn những gì được giao, nhưng nó phù hợp với tiêu chí thoát ra, họ phải bước vào một câu chuyện mới.

Chắc chắn có một yếu tố "đào tạo Thủ tướng" ở đây. Họ phải học được rằng những câu chuyện mơ hồ dẫn đến những điểm câu chuyện lớn, và nếu họ định nghĩa câu chuyện một cách mơ hồ để có được những gì họ muốn, họ phải làm lại.

Rõ ràng nếu các bên liên quan không thu thập đủ thông tin, thì bạn phải làm, và nếu bạn phải làm, thì đó là công việc nhiều hơn, phải không? Rất lâu trước những ngày nhanh nhẹn của tôi, tôi đã thành công bằng cách đưa ra các ước tính rất lớn và nói rõ ràng rằng các ước tính đó quá lớn để cho phép rủi ro do thiếu thông tin. Tôi đã phải giả sử trường hợp xấu nhất cho tất cả các câu hỏi, và ước tính dựa trên trường hợp xấu nhất này. Tôi thấy rằng các nhà quản lý sẵn sàng cung cấp thêm chi tiết khi họ thấy nó dẫn đến ước tính đi xuống.

Đây không phải là chơi game hệ thống ... điều này là hoàn toàn hợp lệ. Nếu bạn không biết đó là "A" hay "B", bạn ước tính dựa vào đó đưa ra ước tính lớn nhất để che mông của bạn.

Theo kinh nghiệm của tôi, nhiều thay đổi hoặc dự án tôi đang thực hiện để giải quyết vấn đề này. Custom X muốn một cái gì đó và họ có ý tưởng về những gì họ muốn, nhưng họ chỉ cung cấp cho bạn một email yêu cầu nhỏ. Điều đó chủ yếu là vì khách hàng không "chính xác" biết họ muốn gì. Đó là lý do tại sao hầu hết công việc của bộ phận dịch vụ khách hàng của chúng tôi đang giải quyết những nhu cầu của khách hàng đó và lọc thông tin cần thiết đồng thời dự đoán những gì khách hàng THỰC SỰ sẽ muốn, hoặc những gì họ thực sự cần.

Giả sử một khách hàng (đối với tôi) muốn một phần trong ứng dụng web của chúng tôi trả lại cho họ danh sách tất cả các số điện thoại. Họ không bao giờ chỉ định nếu họ có nghĩa là những người vật lý, những người logic, những người được chỉ định cho một người hoặc một vị trí, ect. Họ chỉ đơn giản muốn tất cả các số điện thoại. Là một nhà phát triển, tôi có thể ngồi đó và nghĩ ra hàng tá câu hỏi mà tôi cần hỏi khách hàng, giống như bạn có. Nhưng, như bạn nói, điều đó là không thể. Đó là lý do tại sao có một bộ phận dịch vụ khách hàng tốt biết sản phẩm và khách hàng là vô giá.

Khi loại cuộc gọi đó đến với đại diện khách hàng của chúng tôi, họ có thể giải thích nó với khách hàng, biết họ cần gì để yêu cầu họ trả lời đúng câu hỏi. Họ cũng có khả năng biết trước những gì khách hàng đã yêu cầu trong quá khứ và họ biết đủ về các hệ thống mà chúng tôi phát triển để họ có thể nói có hoặc không với điều gì đó mà không cần hỏi khách hàng.

Chắc chắn, bạn sẽ có rất nhiều trường hợp khách hàng vẫn sẽ cần một thứ khác mà cả bạn và dịch vụ khách hàng đều bỏ lỡ, nhưng điều đó luôn xảy ra. Mục tiêu của bạn và mục tiêu của các dịch vụ khách hàng, nên giảm thiểu thời gian trễ giữa bạn phát triển một cái gì đó và bạn lấy lại từ khách hàng với những thay đổi cần phải thực hiện. Và điều này chỉ liên quan đến giao tiếp và đào tạo với các dịch vụ khách hàng của bạn.

Có thể điều đó không khả thi đối với bạn như tôi đang ở đây, nhưng có một đường dây liên lạc và tin tưởng tốt với đại diện khách hàng của bạn sẽ hầu như luôn giúp bạn bằng cấp, và nó sẽ làm giảm sự thất vọng của bạn và tăng sự hài lòng của khách hàng. Ngoài ra, bạn có thể dễ dàng đưa ra khung thời gian cho các dự án của mình hơn là nhún vai và nói "Tôi không biết phạm vi đầy đủ của dự án, vì vậy tôi không biết sẽ mất bao lâu". Chúng ta đang có cùng một vấn đề ở đây, và giao tiếp và đào tạo tốt hơn là những gì giúp chúng ta tạo ra thời hạn hợp lý và đạt được chúng một cách nhất quán.

khách hàng

Tôi muốn tìm kiếm sản phẩm

Quản lý sản phẩm Tôi đã phân tích câu chuyện của khách hàng và đưa ra các yêu cầu sau. Mỗi yêu cầu đã được ghi lại như một câu chuyện người dùng riêng biệt.

• tìm kiếm sản phẩm
• Sắp xếp kết quả
• Lọc kết quả tìm kiếm

Nhà phát triển Tôi đã nhận được câu chuyện của người dùng từ người quản lý sản phẩm. Tôi đã phân tích từng câu chuyện của người dùng và đưa ra một danh sách các nhiệm vụ cho từng câu chuyện của người dùng.

• tìm kiếm sản phẩm
  1. Nhiệm vụ 1: Thay đổi cơ sở dữ liệu
  2. Nhiệm vụ 2: Thay đổi phía máy chủ
  3. Nhiệm vụ 3: Thay đổi giao diện người dùng

Khách hàng, quản lý sản phẩm và nhà phát triển đều là những người nắm giữ cổ phần trong quy trình này. Tất cả họ cần đóng góp cho quá trình phân tích trước khi công việc có thể bắt đầu. Xin lưu ý rằng đây là ví dụ rất đơn giản.

Câu chuyện người dùng của chúng tôi được phân tích và tinh chỉnh theo thứ tự sau (với một số biến thể của khóa học):

Bộ phận Trợ giúp -> Chủ sở hữu sản phẩm -> Quản lý sản phẩm -> Bộ phận dẫn (nhà phát triển cao cấp, khách hàng tiềm năng, v.v.) -> Nhà phát triển

Khi tất cả các bên liên quan đã đóng góp cho quá trình phân tích, chúng tôi có thể ước tính chúng tôi sẽ mất bao lâu để đưa ra câu chuyện. Quá trình ước tính mà chúng tôi tuân theo dựa trên vận tốc và chuyên môn của từng nhà phát triển.

Tôi không nói rằng đây là một cách làm đúng, nhưng nó hoạt động thực sự tốt trong tổ chức của chúng tôi.