Câu chuyện của người dùng ở mức quá cao và mang tính khái niệm, ban quản lý hy vọng các nhà phát triển sẽ điền vào chỗ trống

Tôi đang làm việc trong một công ty rất xuất sắc với ý định thực sự là làm XP. Giao tiếp là tốt và quản lý mở cho thảo luận mang tính xây dựng nhưng do hạn chế về thời gian, một số điều nhất định được coi là quá RUP để được thảo luận.

Hiện tại tôi có một chút rắc rối với khối lượng thay đổi trở nên cần thiết trong khi thực hiện các câu chuyện. Tôi tin rằng nhiều trong số những khám phá này (tất nhiên mất thời gian và công sức) là trách nhiệm của người viết truyện (khách hàng, người dùng cuối và chủ sở hữu sản phẩm) chứ không phải nhà phát triển. Nói ngắn gọn, câu chuyện của người dùng quá khái niệm và chỉ truyền đạt ý định tiềm ẩn nhưng thiếu đủ chi tiết (điều kiện trước và điều kiện đặc biệt, liên quan đến các câu chuyện khác, phụ thuộc và tương tự). Nhà phát triển dự kiến ​​sẽ điền vào chỗ trống theo ý của mình bởi đức tính của các nhà phát triển XP là nhà thiết kế và phân tích cùng một lúc. Vấn đề là nhiều khoảng trống trong số này được phát hiện sau khi một số giả định sai đã được đưa vào thời gian đánh giá và mã kể từ khi nhận thấy sự phức tạp thêm xuất hiện so với dự đoán ban đầu. Ngay cả sau đó, việc tìm ra thứ phù hợp để điền vào cần có thời gian - ở nhiều mức độ khác nhau - được coi là sai lệch so với ước tính ban đầu.

Tôi đang tìm kiếm một cách xây dựng để truyền đạt những tác động này đến ban quản lý theo cách không khiến tôi trở thành một người đang cố gắng làm phức tạp mọi thứ một cách không cần thiết. Tôi là người mới và tôi chưa tạo được nhiều uy tín.

Bạn hiểu biết sâu sắc nhất được chào đón.

Liên quan chặt chẽ và bằng cách nào đó đưa ra câu trả lời: Nhà phát triển có thể mong đợi bao nhiêu chi tiết về câu chuyện của người dùng?

Bí quyết là không để tránh có khoảng trống. Bí quyết là điền vào những khoảng trống đó càng sớm càng tốt trong quá trình phát triển.

Bạn đúng rằng, nếu các nhà phát triển đưa ra các giả định, họ sẽ luôn luôn sai và điều đó sẽ tốn thời gian để phát triển lại phần mềm sau này. Nhưng, cũng như vậy, nếu những người kinh doanh dự kiến ​​sẽ thực hiện một thiết kế hoàn chỉnh trước khi họ không thực sự biết những gì họ muốn, điều tương tự sẽ xảy ra.

Đó là một phần lớn trong công việc của nhà phát triển để tìm ra những gì khách hàng muốn, khi họ thường không thực sự biết.

Đầu tiên, đặt câu hỏi. Trường hợp câu trả lời bạn nhận được có vẻ không thỏa đáng, hãy tạo một nguyên mẫu. Cho khách hàng thấy những gì họ yêu cầu và để họ nói với bạn rằng đó không phải là điều họ thực sự muốn. Bắt đầu với một nguyên mẫu giấy, sau đó chuyển sang một nguyên mẫu dựa trên HTML, không có mã phía sau nó. Sau đó, thực hiện số lượng phát triển nhỏ nhất bạn cần để sản xuất một sản phẩm gần như hoạt động và cho họ thấy điều đó. Để lại các bit khó khăn trong quá trình muộn nhất có thể.

Điều này nghe có vẻ tốn thời gian của chính nó, nhưng khi so sánh với việc phát triển lại một sản phẩm được cho là đã hoàn thành thì không.

Ngoài ra, hãy giữ những câu chuyện nhỏ nhất có thể. Lúc nào cũng vậy, những gì doanh nghiệp muốn là một bản anh hùng ca, một thứ có thể được chia thành nhiều sản phẩm. Điều này tốt hơn bởi vì bạn sẽ không phát triển quá nhiều khi họ nhìn vào ứng cử viên phát hành cuối cùng và hét lên "Ồ không, đó thực sự không phải là những gì chúng tôi đang tìm kiếm."

Ngay cả sau đó, việc tìm ra thứ phù hợp để điền vào cần có thời gian - ở nhiều mức độ khác nhau - được coi là sai lệch so với ước tính ban đầu.

Điều đó không có vẻ rất "XP" đối với tôi.

Tôi không phải là một chuyên gia XP, nhưng ý tưởng của AFAIK là điều chỉnh thông số kỹ thuật và ước tính của bạn liên tục bất cứ khi nào bạn nhận được phản hồi từ quy trình. Và quy trình là "phân tích một chút - thiết kế một chút - viết mã một chút - kiểm tra một chút - và sau đó nhận phản hồi của người dùng để sửa các giả định sai của bạn càng sớm càng tốt. Ví dụ, bạn cũng có thể thử nhận phản hồi của người dùng sớm hơn , sau khi thiết kế một số phần của phần mềm của bạn (như UI), trên một tờ giấy hoặc bảng trắng và thảo luận với người dùng hoặc khách hàng . Tôi không nghĩ rằng "cách XP" cấm cách tiếp cận như vậy chỉ vì " câu chuyện của người dùng ".

Đây là một bài viết hay về cách nhận phản hồi sớm hơn bằng cách sử dụng thông số kỹ thuật. Tôi nghĩ kiểu suy nghĩ này là "phương pháp luận" phụ thuộc và các lập luận được trình bày ở đó sẽ giúp bạn tranh luận với ban quản lý.

Để tóm tắt bạn đang ở trong tình huống sau:

1. Bạn là người mới
2. Dự án (tôi giả sử bạn đang nói về một dự án đang chạy) có những hạn chế về thời gian.
3. Nhà phát triển dự kiến ​​sẽ điền vào chỗ trống theo ý của mình.
4. Công ty bạn đang làm việc đang có ý định thực hành XP. Tuy nhiên, các câu chuyện của người dùng dường như không được áp dụng theo cách phù hợp với phương pháp XP. Mặt khác " Nhà phát triển dự kiến ​​sẽ điền vào chỗ trống theo ý của mình ".

Hãy suy nghĩ về điểm 4: Ý kiến ​​của tôi là các thực hành nhanh nhẹn nên được điều chỉnh phù hợp với nhu cầu và văn hóa của một công ty / nhóm (không phải theo cách khác). Xác định nơi công ty bám sát phương pháp XP và nơi công ty đi chệch hướng. Đây là nền tảng cho một cách tiếp cận mang tính xây dựng cho mối quan tâm của bạn.

Do 1 và 2, bạn hiện không ở vị trí tốt để đặt câu hỏi nếu công ty áp dụng XP một cách hợp lý. Bắt đầu một cuộc thảo luận với ban quản lý rất có thể sẽ coi bạn là người " làm phức tạp mọi thứ ". Tuy nhiên, bạn có thể bắt đầu thảo luận về mối quan tâm của mình với các nhà phát triển đồng nghiệp. Có thể bạn sẽ tìm thấy một số nhà phát triển nghĩ theo cách bạn làm. Có thể có một nhà phát triển cấp cao, người sau đó sẽ truyền đạt mối quan tâm của bạn đến ban quản lý. Nhưng đừng hy vọng rằng mọi thứ sẽ thay đổi nhanh chóng, đặc biệt là trong dự án hiện tại. Tuy nhiên, dự án sẽ cung cấp cho bạn một cơ hội tốt để thu thập nhiều dữ liệu hơn, bổ sung thêm chất vào cách tiếp cận mang tính xây dựng.

Bây giờ đến điểm 3: Tôi nghĩ rằng những câu chuyện người dùng tốt được cộng tác viết bởi khách hàng / người dùng cuối / chủ sở hữu sản phẩm và nhà phát triển. Hiển thị một số sáng kiến: Tìm kiếm một số cơ hội để trực tiếp hỏi các tác giả của câu chuyện người dùng. Nếu điều này là không thể, hãy hỏi một số nhà phát triển cấp cao hoặc ban quản lý cách xử lý các câu hỏi mở phải được trả lời bởi các tác giả của câu chuyện người dùng. Có lẽ bạn ít nhất có thể có một số thư từ bằng văn bản. Vì bạn cần điền vào chỗ trống theo ý của bạn, nên lựa chọn của bạn là chủ động liên quan đến khách hàng / người dùng cuối / chủ sở hữu sản phẩm.

Tại một số điểm, bạn đã thực hiện đủ suy nghĩ và quan sát về cách công ty của bạn áp dụng XP (hoặc thực hành nhanh nhẹn nói chung). Có lẽ một thời gian đã trôi qua và bạn không còn được coi là một nhà kính nữa. Có thể sự tham gia tích cực của bạn với khách hàng đã cho thấy một số hiệu ứng tích cực. Có lẽ dự án tiếp theo đã bắt đầu. Có lẽ bạn cũng đã có một số bản sao lưu từ những người phát ngôn khác. Có thể bạn phát hiện ra rằng cách nó hoạt động không tệ chút nào. Vấn đề là sau đó bạn sẽ có đủ ý tưởng để truyền đạt mối quan tâm của mình đến ban quản lý, dựa trên kinh nghiệm thực tế và dữ liệu trong công ty của bạn.

Thành thật mà nói, câu chuyện của người dùng không nên có nhiều chi tiết. "Tôi muốn các phần mềm để làm X, Y để đáp ứng nhu cầu kinh doanh" nên là đủ. Rốt cuộc, bạn không muốn những người kinh doanh ra lệnh làm thế nào - bạn là chuyên gia về phần mềm và thực hành tốt nhất trong đó.

Điều đó nói rằng, các nhà phát triển cũng cần phải hỏi : "bạn mong đợi nó hoạt động như thế nào?", "Điều gì xảy ra khi tương tác với tính năng Z?". Các nhà phát triển không đưa ra yêu cầu, họ thực hiện.

Nó cũng có vẻ như có quá nhiều khoảng cách giữa thực hiện và đánh giá. Các bên liên quan nên xem xét các nguyên mẫu, với mã được thực hiện một nửa mỗi vài ngày. Điều đó cho phép bạn nhận được thông tin phản hồi trước khi đi quá xa vào đám cỏ dại.

Nếu bạn được yêu cầu ước tính một câu chuyện dường như chưa hoàn chỉnh đối với bạn, hãy thông báo rằng bạn có câu hỏi về câu chuyện và bạn không thể đưa ra ước tính chính xác trước khi những câu hỏi đó được trả lời.

Sau đó, đặt câu hỏi của bạn và đảm bảo câu trả lời trở thành một phần của câu chuyện.

Nếu bạn buộc phải đưa ra ước tính ngay cả khi câu hỏi của bạn chưa được trả lời (tất cả), bạn có thể chọn từ chối đưa ra ước tính hoặc chỉ ra rõ ràng rằng bạn đang giả định kết quả tồi tệ nhất có thể cho các khoảng trống còn lại trong ước tính của bạn có thể sẽ làm cho ước tính của bạn trở thành một ngoại lệ cao).

Những gì bạn làm không phải là một cách phát triển nhanh. Thay vào đó, bạn đang làm việc với các yêu cầu chất lượng thấp. Đó là sai lầm rằng một cách phát triển nhanh là không xác định các yêu cầu.

Thay vào đó, ban đầu họ cần chỉ định càng nhiều càng tốt, và nếu cần thay đổi sau đó. Sau đó, bạn chia công việc của bạn thành các phần và thực hiện trong các lần lặp. Sau mỗi lần lặp, bạn đã hoàn thành một cái gì đó.

Sự khác biệt đối với sự phát triển của thác nước, là trong sự phát triển của thác nước, mọi thứ đều được thực hiện với những yêu cầu ban đầu và được thay đổi vào cuối.

Có vẻ như các nhà phát triển đã bị loại bỏ hoàn toàn khỏi việc tạo ra các câu chuyện của người dùng. Bạn có mong đợi chỉ có thể đọc chúng như một thông số kỹ thuật chi tiết và xây dựng nó ngay lần đầu tiên không? Nếu bạn có thể làm điều đó, bạn sẽ không cần XP hoặc bất kỳ phương pháp nhanh nào khác.

Ai đó nên đặt câu hỏi nếu câu chuyện quá mơ hồ. Không nơi Acceptance Testing xảy ra?

Câu chuyện của người dùng có nghĩa là để thay đổi. Bạn cần phải đối phó với nó.

Mặc dù một nhà phát triển có thể viết một câu chuyện / yêu cầu chi tiết nhưng tôi chưa thấy nhiều người giỏi về nó. chúng tôi rất giỏi trong việc chỉ ra các vấn đề, đề xuất các luồng tốt hơn nhưng là một đầu vào cho trường hợp đã được viết tốt.

Đã làm việc trên các sản phẩm mới và hiện có và với cả hai trường hợp trong đó các yêu cầu chỉ có 5 dòng và chúng tôi dự kiến ​​sẽ điền vào chỗ trống và tạo ra một "sự hiểu biết" hoặc tài liệu phức tạp hơn.

Các dự án chuyển tốt hơn nhiều sau đó chúng tôi có người phục vụ chuyên nghiệp của chúng tôi đã giúp đỡ việc này (hoặc trong một trường hợp một VP đã nhảy vào vì không có ai khác). Dù bằng cách nào thì nó cũng lãng phí thời gian để phát triển (trừ khi không có phản hồi nào quay trở lại và thời hạn không thay đổi). Vì vậy, đề nghị của tôi: hỏi thêm chi tiết, cung cấp thêm, yêu cầu phản hồi ràng buộc về thời gian đối với các giả định và tài liệu của bạn và nói rằng có nguy cơ sẽ phải làm lại và trì hoãn nếu bạn không nhận được thông tin này trước ngày x.

Bất kể phương pháp phát triển là gì, nếu bất cứ điều gì bạn đang sử dụng để xác định các yêu cầu đều khiến nhà phát triển đưa ra các giả định, thì nó cần phải được đưa trở lại cho phía doanh nghiệp. Tôi thường có một ý tưởng tốt về câu trả lời tôi thích vì vậy tôi sẽ trả lại những thứ như thế này:

XYZ không rõ ràng với tôi. Nó có nghĩa là ABC? Hay tôi đang thiếu một cái gì đó? (Giả sử XYZ là yêu cầu, giả sử ABC là giả định tôi muốn thực hiện với tư cách là nhà phát triển)

Sẽ mất ít thời gian hơn để làm cho mọi thứ rõ ràng trước khi bạn đưa ra các giả định xấu hơn là làm lại. Các nhà phát triển đưa ra dự đoán về các yêu cầu mà không nhận được xác nhận rằng dự đoán của họ là đúng có xu hướng trở thành các nhà phát triển tồi và họ tiêu tốn của công ty rất nhiều tiền. Nếu một người quản lý tồi sẽ không cho phép bạn đá lại, thì hãy giải thích cho anh ta về việc tốn kém về thời gian và tiền bạc để làm điều đó sai bao nhiêu. Nếu anh ấy vẫn khăng khăng, hãy làm theo những gì anh ấy nói và khi nó thất bại, lần sau khi bạn muốn đá lại, hãy nhắc anh ấy rằng đó là lúc anh ấy không cho phép bạn tốn kém như thế nào. Nếu anh ta vẫn không lắng nghe, hãy tìm một ông chủ tốt hơn.

Giá trị khác của việc đẩy lùi mọi thứ là, dần dần, doanh nghiệp sẽ học được những gì bạn cần và cung cấp cho bạn những yêu cầu tốt hơn.

Là một nhà phát triển,

Tôi cần hiểu đầy đủ các chi tiết cụ thể của một câu chuyện người dùng,

để tôi có thể tự tin ước tính và thực hiện nó.

Nói cách khác, bạn phải đặt câu hỏi cho đến khi bạn hiểu chi tiết cụ thể của câu chuyện. Điều này được thực hiện trong lập kế hoạch lặp và đóng vai trò là điểm quyết định: nếu bạn không thể ước tính nó, bạn không thể xây dựng nó.