Làm thế nào để bạn phát triển phần mềm mà không có tiêu chí chấp nhận?

Làm thế nào để bạn hợp tác phát triển phần mềm trong một nhóm 4-5 nhà phát triển mà không có tiêu chí chấp nhận, mà không biết người kiểm tra sẽ thử nghiệm cái gì và với nhiều (2-3) người đóng vai trò là chủ sở hữu sản phẩm.

Tất cả những gì chúng ta có là một 'thông số kỹ thuật' sơ sài với một số ảnh chụp màn hình và một vài gạch đầu dòng.

Chúng tôi đã nói rằng nó sẽ dễ dàng vì vậy những điều này là không bắt buộc.

Tôi không biết làm thế nào để tiến hành.

Thông tin bổ sung

Chúng tôi đã được đưa ra một thời hạn khó khăn.

Về mặt lý thuyết, khách hàng là khách hàng, chúng tôi có chủ sở hữu sản phẩm nhưng ít nhất 3 người kiểm tra phần mềm có thể thất bại một mục công việc đơn giản vì nó không hoạt động như thế nào họ nghĩ rằng nó nên hoạt động và không có gì minh bạch về những gì họ mong đợi hoặc những gì họ đang thực sự thử nghiệm cho đến khi nó thất bại.

chủ sở hữu sản phẩm không sẵn sàng trả lời các câu hỏi hoặc đưa ra phản hồi. Không có cuộc họp hoặc cuộc gọi theo lịch trình thường xuyên với họ và phản hồi có thể mất nhiều ngày.

Tôi có thể hiểu rằng chúng ta không thể có một thông số hoàn hảo nhưng tôi nghĩ sẽ là 'bình thường' khi có tiêu chí chấp nhận cho những thứ chúng ta thực sự đang làm trong mỗi lần chạy nước rút.

Một quá trình lặp đi lặp lại sẽ đạt được điều này độc đáo, không có thông số kỹ thuật chi tiết.

Đơn giản chỉ cần tạo một nguyên mẫu sơ sài, yêu cầu phản hồi từ khách hàng, thay đổi dựa trên phản hồi và lặp lại quy trình này cho đến khi ứng dụng được hoàn thành.

Liệu khách hàng có đủ kiên nhẫn để làm theo cách này hay không là một câu hỏi khác. Một số khách hàng và nhà phát triển thực sự thích quá trình này; vì khách hàng luôn luôn thực hành, cuối cùng anh ta sẽ có được chính xác những gì anh ta muốn.

Nó sẽ đi mà không nói rằng bạn sẽ không làm việc một hợp đồng thời gian cố định hoặc chi phí cố định theo cách này.

Nếu những gì bạn nói là đúng và thông số kỹ thuật không đủ tốt để bạn bắt đầu (và bạn trung thực trong đánh giá này), tôi khuyên bạn nên sử dụng lời khuyên này:

1. Đọc các bản phác thảo và thông số kỹ thuật "sơ sài" mà bạn đã được cung cấp.
2. Viết thông số kỹ thuật của riêng bạn đến một mức vừa đủ để bạn có thể viết mã. Bạn có thể phải thực hiện một tấn đoán.
3. Hiển thị thông số kỹ thuật của bạn cho khách hàng để xem xét. Lưu ý những phần mà họ thích và nhận thêm thông tin về những phần mà họ nghĩ rằng bạn đã hiểu sai.
4. Lặp lại bước 2 và 3 cho đến khi bạn và khách hàng đồng bộ.
5. Bây giờ bạn có một thông số đầy đủ.

Nếu khách hàng của bạn đã đúng khi họ nói "nó sẽ dễ dàng", thì bài tập này sẽ là một miếng bánh.

Nếu khách hàng của bạn sai và trên thực tế có tất cả các loại yêu cầu và lỗ hổng trong yêu cầu, đặc điểm kỹ thuật dự thảo của bạn sẽ nhanh chóng minh họa vấn đề và thông báo cho họ rằng họ đã sai (mà bạn không cần phải chỉ tay hoặc tranh luận) vì nó sẽ ở ngay trước mặt họ và hiển nhiên Ngoài ra, thông số kỹ thuật của bạn sẽ phục vụ như một công cụ thảo luận tuyệt vời để giải quyết những sự mơ hồ đó và sẽ đóng vai trò là bản ghi các quyết định chính khi bạn sửa đổi nó với phản hồi của họ.

Chủ sở hữu sản phẩm đã trao cho bạn một nguyên mẫu; đưa anh ta trở lại những người tốt hơn (cho đến khi bạn hoàn thành)

Có vẻ như bạn đã được cung cấp một nguyên mẫu giấy để bắt đầu dự án. Đó không phải là một khởi đầu khủng khiếp. Tôi đề nghị bạn nên liên lạc lại với chủ doanh nghiệp bằng cùng một ngôn ngữ , bằng cách cung cấp các nguyên mẫu có khả năng tiến bộ.

Các nguyên mẫu của bạn nên bắt đầu bằng giấy, chuyển sang các mockup kỹ thuật số và sau đó được xây dựng với các công nghệ thực tế.

Treehouse có một hướng dẫn tuyệt vời cho việc này, kết luận:

Điều tuyệt vời về tạo mẫu với khung là nguyên mẫu thường chỉ trở thành trang web thực sự vì cấu trúc và kiểu dáng đã được đặt sẵn. Không cần phải tạo lại trang web từ đầu nếu nó sẽ sử dụng cùng một khung.

Bạn cũng có thể muốn cung cấp một đặc điểm kỹ thuật chính thức, đặc biệt nếu bạn vẫn lo lắng về việc bị đổ lỗi cho một kết quả xấu. Nhưng bạn có thể sẽ nhận được nhiều phản hồi hơn từ các nguyên mẫu.

Đáp ứng thời hạn của bạn

Lưu ý rằng tất cả những nỗ lực sau này của bạn sẽ không phải là "nguyên mẫu" cổ điển, vì chúng sẽ không dùng một lần (hoặc một phần của chúng sẽ không). Lần lặp cuối cùng, có khả năng nhất, bạn hoàn thành trước thời hạn sẽ trở thành việc giao hàng của bạn.

Hạn chót của bạn là yêu cầu được xác định rõ nhất mà bạn có. Có một cái gì đó đầy đủ và mạch lạc mà bạn có thể cung cấp đúng thời gian.

Phối hợp với người thử nghiệm của bạn

Nếu quy trình lỏng lẻo này là một điều mới cho công ty của bạn, những người thử nghiệm của bạn có thể thậm chí còn thua lỗ nhiều hơn bạn và có thể tìm đến bạn để được hướng dẫn. Bạn đã có được một số thời gian của họ sớm trong quá trình. Hãy cho sếp của họ biết bạn đang cố gắng giúp họ cung cấp một bài kiểm tra có ý nghĩa mà không nhận được tiêu chí chấp nhận chính thức.

Tìm hiểu xem những người thử nghiệm có bất cứ thứ gì công ty họ cần cung cấp, như tài liệu thử nghiệm bằng chứng, mà bạn có thể chuyển lại thành.

Thử nghiệm thiết kế đầu tiên

Vì bạn không có yêu cầu chính thức, nên việc phát triển các trường hợp thử nghiệm sẽ cung cấp một số cấu trúc.

Làm quen với thiết kế thử nghiệm đầu tiên và / hoặc phát triển theo hướng thử nghiệm và cung cấp hướng dẫn cho người thử nghiệm của bạn về quy trình khi cần thiết. Đối với một dự án nhanh như thế này, bạn không cần phải trở thành chuyên gia trong quá trình này. Nhưng sử dụng một phương pháp đã được chứng minh sẽ phản ánh tốt về bạn và người thử nghiệm của bạn.

Bám sát các tiêu chuẩn, đặc biệt là cho UI

Bạn không có yêu cầu về giao diện, nhưng bạn có thời hạn. Sử dụng công việc thiết kế của người khác để giảm thiểu công việc bạn cần làm để tạo ra một tạo tác chuyên nghiệp.

Chọn một giao diện người dùng chuẩn cho trang web của bạn và không tùy chỉnh nó trừ khi / cho đến khi được hướng dẫn. Tôi không biết bạn đang phát triển nền tảng nào, nhưng Bootstrap hoặc Google Material Design là hai ví dụ.

Giao tiếp, nhưng không làm phiền

Tôi sẽ đề nghị gửi một email cho chủ sở hữu sản phẩm một ngày. Chỉ gửi nhiều hơn thế nếu đó là trường hợp khẩn cấp.

Nếu bạn có câu hỏi, hãy mô tả cách bạn sẽ tiến hành nếu bạn không nhận được hướng dẫn. Ví dụ:

Người dùng của ứng dụng này có cần truy cập nó bằng thiết bị di động không? Ngay bây giờ chúng tôi đang giả định đây sẽ là một hệ thống chỉ dành cho máy tính để bàn / máy tính xách tay.

Đừng hoảng sợ

Tôi đã tham gia rất nhiều dự án cho những người không biết về yêu cầu của thuật ngữ. Hầu hết đều thành công. Chủ sở hữu sản phẩm thực hành cung cấp cho bạn vĩ độ để xây dựng các giải pháp tuyệt vời.

Lưu ý, một số chủ dự án trong các dự án này không thể làm hài lòng và ẩn đằng sau những người tôi quá bận rộn để ... xin lỗi vì sự bất tài của họ. Nhưng hầu hết là những người thích thú với những kết quả cuối cùng.

Một dự án là hành động giảm sự không chắc chắn cho đến khi đạt được sự chắc chắn :

• Luôn luôn có một số mức độ không chắc chắn khi bắt đầu. Đôi khi đó là một chút mơ hồ trong các yêu cầu. Đôi khi, nó rất sơ sài. Bạn sẽ phải làm việc như một phần của công việc.
• Bí quyết là lặp đi lặp lại làm giảm sự không chắc chắn này (kết hợp phân tích, thiết kế và triển khai), tinh chỉnh các câu chuyện của người dùng và triển khai hệ thống của bạn.
• Các trường hợp / kịch bản thử nghiệm và tiêu chí chấp nhận sẽ phải được làm rõ theo cùng một cách. Họ sẽ góp phần làm giảm sự không chắc chắn về chất lượng và tính chính xác (trong số khác).
• Cuối cùng, một sự chắc chắn đủ đạt được: khách hàng nhận được một sản phẩm được thử nghiệm phù hợp với nhu cầu của mình và có thể được sử dụng.

Đó là nguyên tắc của công phu tiến bộ: các yêu cầu, tiêu chí và kết quả sẽ được xây dựng từng bước, cũng như sự hiểu biết của khách hàng về những kỳ vọng và yêu cầu của chính mình thông qua sự tham gia của anh ấy vào quá trình phát triển.

Đây co phải vân đê ?

Càng phác thảo các yêu cầu ban đầu, độ không chắc chắn càng cao và thời gian cần thiết để thực hiện các nhiệm vụ càng cao. Vì vậy, đó chỉ là vấn đề ai sẽ làm công việc bổ sung và ai sẽ trả chi phí.

Câu trả lời của hai câu hỏi này nên có trong hợp đồng. Hoặc sẽ là đối tượng của một cuộc đàm phán. Và khách hàng phải chấp nhận sự tham gia bổ sung (đối số chính sẽ là "rác vào, rác ra", mặc dù tôi khuyên bạn nên trình bày nó theo cách ngoại giao hơn ;-))

" Không có cuộc họp định kỳ thường xuyên ". Chà, tại sao bạn không bắt đầu bằng cách lên lịch các cuộc họp thường xuyên sau đó? Thực tế là bạn có nhiều chủ sở hữu sản phẩm đảm bảo rằng dự án của bạn sẽ KHÔNG dễ dàng, vì mỗi người trong số đó S have có các yêu cầu mâu thuẫn mà PHẢI được thảo luận trực tiếp với tất cả các bên liên quan.

Ngoài ra, tôi thực sự, thực sự, thực sự khuyên bạn nên giữ một bản ghi quyết định chi tiết . Tối thiểu bạn viết ra tất cả những gì ai đó đã quyết định, với ngày và danh sách những người có mặt khi quyết định được đưa ra. Thậm chí tốt hơn nếu bạn có thể viết ra TẠI SAO một cái gì đó đã được quyết định theo cách đó. Sẽ không thành vấn đề nếu đó là một tệp trên PC của bạn, một trang trong wiki mạng nội bộ của bạn hoặc một sổ ghi chép trên bàn của bạn. Nhật ký bảo vệ bạn và dự án: khi người kiểm tra nói một số mục "không thành công", bạn có thể chỉ ra rằng nó đã được quyết định theo cách đó với những người này, và đó không phải là vấn đề của bạn mà là giữa họ và người kiểm tra. Nếu điều này dẫn đến thông số kỹ thuật được thay đổi thì tốt, nhưng tại thời điểm này, họ không thể mong đợi đáp ứng bất kỳ thời hạn nào họ có trong tâm trí - hoặc họ phải cắt phạm vi ở một nơi khác.

Một dự án không có yêu cầu rõ ràng, lãnh đạo lỏng lẻo, không có định nghĩa về việc thực hiện (DoD), không ai sẵn sàng chịu trách nhiệm để đảm bảo rằng bạn có thông tin bạn cần để thực hiện công việc của mình một cách kịp thời và đáp ứng thời hạn của họ là một công thức cho dự án sự thất bại.

Phát triển lặp không phải là một gợi ý tồi, nhưng nó đòi hỏi sự hợp tác chặt chẽ giữa chủ sở hữu sản phẩm và nhà phát triển. Hãy cố gắng khiến ai đó gặp khó khăn bằng cách nói, "Chúng tôi biết rằng chúng tôi sẽ có câu hỏi. Ai có thể thường xuyên có mặt để đảm bảo những người được trả lời để việc giao dự án không bị trì hoãn?" Lên lịch thời gian thường xuyên với ai đó để xem xét tiến độ và loại bỏ các trở ngại. Nếu họ không hiển thị hoặc từ chối, thì hãy theo dõi với sự tương ứng bằng văn bản và trì hoãn tài liệu hoặc không trả lời. Nếu chủ sở hữu sản phẩm không thể có sẵn, hãy yêu cầu họ cung cấp một đại diện có thể.

Ngoài ra, một dấu hiệu khác của sự phát triển lặp lại là sự thay đổi trong các yêu cầu đòi hỏi phải thay đổi dòng thời gian. Bạn không thể cam kết đáp ứng thời hạn nếu bạn không thể phát triển dòng thời gian và bạn không thể phát triển dòng thời gian nếu bạn không có ý tưởng hay về những gì cần phải làm. Thay vì hỏi một cách cụ thể về thông số kỹ thuật, hãy xem lại thông số kỹ thuật hiện tại, ghi lại bất kỳ câu hỏi nào mà bạn hoặc nhóm có liên quan đến cách thức hoạt động của nó, sắp xếp thời gian với chủ sở hữu sản phẩm để thảo luận và ghi lại câu trả lời. Khi bạn hoàn thành, bạn sẽ có thông số kỹ thuật dựa trên quyết định của họ, sau đó bạn có thể khiến chủ sở hữu sản phẩm đồng ý (bằng văn bản). Mục đích của thông số kỹ thuật là loại bỏ sự mơ hồ và tạo DoD, đó chính xác là những gì một phiên hỏi đáp có thể cung cấp. Nếu có sự phản đối với thông số kỹ thuật, đừng gọi nó là thông số kỹ thuật.

Đừng tin bất cứ ai khi họ nói với bạn điều đó sẽ dễ dàng . Đôi khi nó thực sự đơn giản như âm thanh và tôi có thể tin điều này nếu (và chỉ khi ) tôi biết rõ chủ sở hữu sản phẩm đủ tin tưởng rằng các yêu cầu thực sự đơn giản như họ nói, và thông số kỹ thuật tôi đã có được cung cấp là tự giải thích (nếu không, tôi lên lịch một phiên hỏi đáp và ghi lại nó). Tôi đã ở trong quá nhiều tình huống mà việc dễ dàng từ quan điểm hoạt động là vô cùng khó khăntừ quan điểm phát triển, hoặc bạn nghĩ rằng bạn đã hoàn thành và bạn nghe thấy những lời tuyệt vọng ("Ồ, nhân tiện, chúng tôi đã quên về ..."). Ví dụ ... "Tất cả những gì bạn phải làm là đọc các tệp PDF này ra khỏi kho lưu trữ tài liệu", trong quá trình kiểm tra chấp nhận biến thành "Ồ, chúng tôi quên rằng một số trong số này đã được đọc sang một bên theo cách hoàn toàn không nhất quán và một số có kích thước trang sai được xác định và một số cần thêm ba trang này và chúng tôi cần tất cả chúng để hiển thị giống nhau. Điều đó thực sự dễ sửa, phải không? ".

Vấn đề là, nó có thể thực sự dễ dàng và một cuộc họp nhanh có thể xác nhận điều đó, cho phép bạn ghi lại tất cả các giả định và nhận được xác nhận rằng chúng là chính xác và chính xác. Tôi khuyên bạn nên đứng lên để loại bỏ những trở ngại mà bạn phải viết mã làm việc đáp ứng mong đợi của họ, bởi vì bất kể bạn có bước lên ngón chân hay không, dù sao đi nữa, ai đó có thể sẽ không vui. Nếu bạn kiên trì nhận được câu hỏi trả lời và chọc tức ai đó, họ sẽ quên nó khi bạn cung cấp một sản phẩm tuyệt vời đúng thời gian đáp ứng yêu cầu. Nếu bạn không nhận được sự làm rõ và không cung cấp, sẽ không ai nhớ rằng họ đã nói với bạn rằng đừng làm phiền họ.

Không có thông số kỹ thuật, bạn có tinh thần đồng đội. Đi nhanh nhẹn.

Ngồi xuống với PO và xác thịt ra một / vài câu chuyện bắt đầu nhỏ. "Chúng tôi sẽ chỉ cung cấp màn hình này, chỉ với nút này là" bing! "". Giải quyết một số AC. Truyền tải câu chuyện. Chứng minh câu chuyện. Hóa ra các nút nên có màu đỏ. Tăng một lỗi hoặc một câu chuyện mới. Cung cấp các nút đi bong và bang. Và như vậy.

Hợp tác chỉ định và cung cấp các lát dọc nhỏ thường được thể hiện.

Nếu khách hàng sẽ không làm việc với bạn theo cách này, hãy tìm một lối thoát.

Tôi đã dành một số công việc làm các dự án như bạn đã vạch ra. Miễn là PO biết quyết định thiết kế nào bạn đang đưa ra và tại sao bạn phải đưa ra quyết định đó, bạn sẽ ổn thôi. Mặt khác, nếu họ không hiểu các quyết định thiết kế, thì bạn cần nhấn chúng cho ít nhất một tài liệu kiểm tra chấp nhận người dùng bằng văn bản.

Bạn cần một thông số chi tiết, có thể kiểm chứng trước khi bạn có thể bắt đầu viết mã. Đó là một sự thật, và không có xung quanh nó.

Nếu không có ai khác sẵn sàng viết thông số đó, thì các nhà phát triển phải viết nó. Vì vậy, bạn nhận được một spec không đầy đủ. Bạn biến nó thành một thông số kỹ thuật hoàn chỉnh (có nghĩa là "đây là điều tôi sẽ thực hiện trừ khi có người khác bảo tôi không làm"). Bạn trao thông số kỹ thuật đó cho các bên liên quan và cho họ cơ hội sửa đổi thông số kỹ thuật. Chỉ có một cơ hội để sửa đổi thông số kỹ thuật - không nêu ra nó chẳng hạn bằng cách nói "Tôi không thích nó theo cách này". Tại thời điểm đó, đó là thông số kỹ thuật của bạn hoặc họ có thể cung cấp thông số kỹ thuật khác, nhưng không xóa thông số kỹ thuật.

Nó có thể là một ý tưởng tốt để có được một đánh giá nhanh từ các đồng nghiệp của bạn, những người có thể cải thiện thông số kỹ thuật. Nhưng dù sao, bạn có một thông số kỹ thuật, bạn viết mã cho phù hợp, người kiểm tra kiểm tra phù hợp. Và bạn đã hoàn thành công việc của mình: Bạn đã có một thông số kỹ thuật và thực hiện nó. Nếu thông số kỹ thuật không phải là những gì khách hàng muốn, đó là trách nhiệm của chủ sở hữu sản phẩm hoặc khách hàng không thể bận tâm để viết một thông số kỹ thuật tốt.