Là viết phần mềm trong trường hợp không có yêu cầu là một kỹ năng để sở hữu hoặc một tình huống tôi nên tránh?

Tôi thấy rằng một số nhà phát triển phần mềm rất thành thạo về điều này và thường được khen ngợi về khả năng đưa ra một khái niệm làm việc với các yêu cầu trừu tượng. Thành thật mà nói, điều này làm tôi phát điên, và tôi không thích "làm cho nó lên" khi tôi đi. Tôi đã từng nghĩ rằng điều này có vấn đề, nhưng tôi đã bắt đầu cảm nhận được sự thay đổi và tôi tự hỏi liệu tôi có cần điều chỉnh quá trình suy nghĩ (và lập trình) của mình khi được đưa ra rất ít hướng. Tôi có nên bắt đầu có được khả năng này như một kỹ năng, hay bám sát ý tưởng rằng quy tắc kinh doanh và thu thập yêu cầu là ưu tiên hàng đầu?

Kỹ năng không phải là viết phần mềm mà không có yêu cầu. Thay vào đó, để gợi ra các yêu cầu từ chủ dự án bất kể có tài liệu yêu cầu chính thức hay không.

Thu thập các yêu cầu chắc chắn là ưu tiên hàng đầu của bạn, nhưng bạn không nhất thiết phải ghi nhận tất cả các nhu cầu của khách hàng. Rủi ro tất nhiên là bạn có thể bỏ lỡ một số thông tin quan trọng làm cho kiến ​​trúc hệ thống của bạn trở nên vô dụng nếu bạn không quản lý để có loại cuộc trò chuyện phù hợp với khách hàng của mình, tuy nhiên việc xác định sản phẩm và thậm chí nhận được là không bình thường. phần lớn sự phát triển ngoài lề, trong khi trì hoãn các quyết định kiến ​​trúc hệ thống chính cho đến thời điểm cuối cùng có thể. Đây là một cách tiếp cận phát triển tinh gọn nhằm đảm bảo rằng bạn không cam kết với một kiến ​​trúc không tương thích tiềm năng quá sớm trong quá trình phát triển sản phẩm của bạn cho đến khi bạn có nhiều thông tin vững chắc hơn. Trong các tình huống mà OP đã mô tả trong câu hỏi của anh ấy,

Vâng, đôi khi bạn cần phải nhìn chằm chằm vào quả cầu pha lê một chút để hiểu được khách hàng thực sự đang yêu cầu điều gì, đó là nơi mà việc tạo mẫu tăng đột biến và chậm - và đôi khi rất đau đớn - đòi hỏi phải gia tăng các yêu cầu rằng bạn thực sự phát triển các kỹ năng quan hệ khách hàng tốt và cũng là sự kiên nhẫn để nhận ra rằng với bất kỳ ý tưởng phần mềm phức tạp nào, ban đầu, khách hàng thường không biết nhiều hơn bạn về những gì phần mềm thực sự cần làm. Thông thường, khách hàng gọi cho bạn sớm để phụ thuộc vào chuyên môn của bạn để xác định các yêu cầu của họ vì khách hàng không phải lúc nào cũng có chuyên môn hoặc kiến ​​thức cần thiết về quy trình phát triển phần mềm.

Điều này rất mơ hồ

Hai điều tôi có thể nói:

1. Có rất nhiều người kỹ thuật rất có năng khiếu mà sự nghiệp của họ bị dừng lại vì họ chờ đợi những yêu cầu hoàn hảo. Hoặc họ chơi, "Xin lỗi, không thể làm điều đó, không nằm trong yêu cầu." Thực tế là yêu cầu viết rất khó khăn. Độ chính xác cần thiết cho các yêu cầu tốt không giống như bất cứ điều gì mà hầu hết những người kinh doanh đã từng tạo ra. Có một cầu nối giữa công nghệ và doanh nghiệp, và những người khiến những người khác đến 100% để gặp họ thường thua cuộc.

2. Có những người phần mềm học các lĩnh vực tốt hoặc tốt hơn khách hàng của họ. Những người này đáng giá vàng của họ, ngay cả khi họ không phải là nhà phát triển tốt nhất 100%. Tôi đã thấy mọi người phần mềm dự đoán nhu cầu tiếp thị định lượng của các nhà quản lý thương hiệu tốt nhất trong nước. Họ không giỏi nhất trong việc mã hóa tất cả các giải pháp, nhưng họ là anh hùng vì họ có thể qua cầu.

Cuộc sống không phải là về màu đen và người da trắng mặc dù. Nếu bạn vẽ một hộp hẹp xung quanh mình, bạn sẽ tự giới hạn mình. Mặt khác, một tổ chức loại bỏ những gì cần thiết để tạo ra công nghệ cũng bị hạn chế. Bạn sẽ phải xem nơi nào bạn thích màu xám hơn.

Yêu cầu là những bước trong hành trình, tầm nhìn là hướng đi

Đối với nhiều ứng dụng, một đặc tả kỹ thuật rất chi tiết chỉ là quá nhiều vì một cuộc thảo luận nhanh có thể khiến tài liệu sắp chữ cẩn thận của họ trở nên vô dụng. Thay vào đó, hãy bắt đầu với một tầm nhìn. Nếu mọi người hiểu bức tranh tổng thể thì các yêu cầu có thể được điền vào trong suốt quá trình thảo luận.

Là một nhà phát triển, bạn phải học cách sử dụng các cuộc thảo luận này để truy tìm các yêu cầu . Điều này có nghĩa là đặt câu hỏi hàng đầu cho khách hàng khiến họ suy nghĩ về quyết định của họ ngày nay phù hợp với tầm nhìn tổng thể. Càng sớm những cuộc thảo luận chi tiết này diễn ra thì tầm nhìn tổng thể sẽ càng nhanh chóng trở thành một thiết kế mạch lạc.

Bạn nên theo dõi kết quả của các cuộc thảo luận này trong một số loại theo dõi vấn đề để những người khác có thể nhận xét về họ nếu họ bỏ lỡ cuộc thảo luận ban đầu. Và để bạn có một bản ghi bạn, hoặc các thành viên khác trong nhóm của bạn, có thể tham khảo lại nếu bạn cần làm rõ.

Vì vậy, học cách viết mã chống lại tầm nhìn, nhưng hãy sẵn sàng để truy tìm những yêu cầu đó khi đến lúc.

Steve Jobs tin rằng khách hàng không thể mô tả chính xác những gì họ muốn các sản phẩm trong tương lai trông như thế nào, vì vậy công việc của bạn là cung cấp chúng. Vì vậy, trừ khi bạn cung cấp phần mềm tùy chỉnh mọi lúc, hãy quên thông số kỹ thuật chính thức và bắt đầu bằng cách tạo nguyên mẫu và để khách hàng chơi với họ và cho bạn biết họ nghĩ gì. Bạn phải đặt đúng người làm nguyên mẫu, và họ cần có sự giúp đỡ. Tôi nói điều này từ kinh nghiệm - Tôi là con khỉ nguyên mẫu, người thích tạo giao diện trực quan và tôi đã hợp tác với ai đó trong sản phẩm, người hiểu những gì khách hàng muốn và có thể giải thích mọi thứ trên giấy hoặc sử dụng Excel.

Cả hai chúng tôi đều không phải là thiên tài, nhưng chúng tôi nghĩ giống nhau - bạn gần như có thể nói rằng chúng tôi có hóa học và có tác động rất lớn đến việc mọi thứ đang được xây dựng và làm thế nào. Bây giờ, chỉ có một nhóm từ trung bình đến lớn có thể đủ khả năng để có một nguyên mẫu và một người không phải là lập trình viên, người phát triển sản phẩm độc quyền, nhưng nó rất xứng đáng. Prototyping là giai đoạn rẻ nhất trong phát triển phần mềm, vì vậy nó chỉ có ý nghĩa để có được giao diện người dùng và hành vi rõ ràng. Tôi chưa đọc Code Complete nhưng tôi nghĩ có một cái gì đó giống như được viết trong cuốn sách đó.

Thông số kỹ thuật là tốt đẹp để có, nhưng chúng không bao giờ hoàn hảo. Có tồn tại một định lý về điều đó. Bạn không thể chứng minh rằng thông số kỹ thuật đã hoàn tất và bạn không thể chứng minh rằng công cụ không có lỗi hoặc nó sẽ dừng lại :)

Tuy nhiên, các công ty phần mềm luôn luôn vận chuyển phần mềm bất chấp những khiếm khuyết này trong quy trình. Thông số kỹ thuật sẽ không bao giờ hoàn hảo. Thông số kỹ thuật cũng KHÔNG HẤP DẪN và lỗi thời. Một thông số kỹ thuật cho một nguyên mẫu giống như bảng logarit là một biểu đồ duy nhất - thông số kỹ thuật về cơ bản là một tập tài liệu nhàm chán được in trong khi bạn có thể tương tác với một công cụ / biểu đồ thay thế. Hãy xem http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html để tìm cảm hứng.

Bây giờ, spec là tốt nếu bạn phải có một hợp đồng để trang trải mông của bạn. Nhưng một thông số kỹ thuật vẫn nên đến sau một nguyên mẫu, không phải trước đó. Công việc của bạn là tìm ra cách làm cho các nguyên mẫu rẻ tiền.

Tôi thường thấy rằng trong một số trường hợp tôi cần phải đóng vai trò như một nhà phân tích kinh doanh, phát hiện chính xác cách thức các doanh nghiệp hiện đang hoạt động, cách mọi người nghĩ rằng nó hoạt động (thường được những điều rất khác nhau), và làm thế nào họ sẽ thích nó để làm việc.

Tôi đã tìm thấy thành công bằng cách luôn rõ ràng về các quyết định mà tôi buộc phải đưa ra để xây dựng phần mềm. Tôi giải thích lý do của mình, viết tài liệu về những gì tôi đã khám phá, tạo biểu đồ và phân phối chúng cho mọi người, v.v.

Bạn có thể sẽ không tạo ấn tượng tốt bằng cách từ chối thực hiện bất kỳ công việc nào cho đến khi hoàn thành các yêu cầu. Nhưng bằng cách tự mình thu thập các yêu cầu chất lượng tốt (mà không nhất thiết phải chú ý đến thực tế), bạn sẽ đạt được cùng một mục tiêu là phần mềm chất lượng.

Và vâng, như những người bình luận khác đã nói, luôn xây dựng phần mềm giả định rằng nó sẽ thay đổi. Thay đổi là một hằng số bạn có thể dựa vào. Luôn xây dựng phần mềm của bạn đủ linh hoạt và mô đun để không cập nhật phần mềm khi một số yêu cầu mới đột nhiên xuất hiện.

Nếu bạn muốn làm việc như một nhà phát triển phần mềm khi mới khởi nghiệp, đó là một kỹ năng cần có.

Nếu bạn muốn làm việc tại một công ty tư vấn thì đó là một tình huống cần tránh bằng mọi giá. Điều này là do công ty của bạn được trả tiền theo mức độ bạn thực hiện thông số kỹ thuật / yêu cầu chứ không phải bạn giải quyết vấn đề của khách hàng tốt như thế nào.

Nếu bạn đang viết mã để giải trí trong thời gian rảnh rỗi thì đó là cuộc gọi của bạn. Nếu bạn không cảm thấy đủ điều kiện để thực hiện cuộc gọi cho các dự án thời gian rảnh rỗi của mình thì hãy thử một vài cách và xem những gì hoạt động. Ngoài ra, không cần thiết một điều phù hợp với một kích thước, một số dự án yêu cầu một hoặc một kiểu tiếp cận khác. Thông thường nếu bạn chọn sai một trong những dự án này, bạn sẽ tìm ra nó khá nhanh.

Một chút của cả hai. Bạn cần làm hài lòng khách hàng, điều đó có nghĩa là bạn cần biết họ muốn gì. Mặt khác, khách hàng nổi tiếng là xấu trong việc truyền đạt những gì họ thực sự muốn.

Vì vậy, bạn muốn tránh các tình huống mà bạn không biết khách hàng muốn gì, nhưng chắc chắn bạn sẽ gặp phải một kịch bản trong đó các yêu cầu là 'yếu đuối' nhất, và tồi tệ nhất. Một lập trình viên thế giới thực tốt đòi hỏi khả năng thích ứng.

Không thể viết một chương trình mà không có yêu cầu. Ngay cả 'Hello World' cũng có yêu cầu: tạo ra đầu ra. Vì vậy, tôi nghĩ rằng bạn đang hỏi về các yêu cầu chính thức, dưới dạng một số lượng lớn thứ gì đó giống như UML. Và về những điều đó, tôi đã gặp 2 loại người:

1) Những người cần yêu cầu chính thức. Họ cần được nói chính xác những gì cần làm, và tốt nhất là làm thế nào để làm điều đó. Họ yêu thích các câu như Quy trình A lấy đối số B sẽ xuất ra C và họ ghét những câu đó: Chương trình sẽ làm cho công việc của chúng tôi hiệu quả hơn . Chúng thường là động vật của công ty.

2) Những người đối diện với 1. Họ ghét được nói phải làm gì và làm như thế nào, họ thích được nói những gì nên đạt được. Họ thích nói chuyện với khách hàng, phân tích những gì họ nói và sau đó phát triển giải pháp của riêng họ. Họ thường là những người làm việc tự do và không phù hợp với tập đoàn.

Tôi sẽ không nói cái nào tốt hơn. Cả hai đều có ưu và nhược điểm của họ. Họ là đơn giản đầy đủ cho các điều kiện khác.

Bạn KHÔNG thể phát triển phần mềm hoạt động mà không biết các Yêu cầu; nhưng, bạn có thể có một cú hích tốt trong việc phát triển những gì kinh nghiệm của bạn cho bạn biết các Yêu cầu có khả năngđược. Phát triển Agile sử dụng kết hợp các kỹ thuật 'trực quan', bao gồm Quy tắc 80:20 và 'khám phá' các Yêu cầu bằng cách tạo mẫu. Nói cách khác, một nhóm phát triển có kinh nghiệm đưa ra dự đoán tốt nhất về những gì cần thiết và tạo ra một nguyên mẫu của phần mềm. Quy tắc 80:20 nói rằng họ sẽ đúng 80%. Các bên liên quan của dự án sau đó xem xét các nguyên mẫu hữu hình. Phản hồi của họ bắt đầu lấp đầy khoảng trống 20% ​​theo cách hiểu của chúng tôi về Yêu cầu. Vì vậy, về mặt hiệu quả, Agile không phải là về việc viết phần mềm mà không có bất kỳ yêu cầu nào, thay vào đó, đó là về việc sử dụng kinh nghiệm trước đây của bạn để nói, "bạn có muốn một cái gì đó như thế này không?" Trong 80% các trường hợp, sẽ cho phép bạn vượt lên và xác nhận những gì thực sự cần thiết nhanh hơn là thực hiện các quy trình Yêu cầu truyền thống.

Ai nói Agile đã viết mã khi không có yêu cầu? Tôi biết Tuyên ngôn đã được giải thích theo cách này bởi một số ... nhưng điều đó không làm cho nó đúng.