Sản xuất và Phát triển phần mềm [đã đóng]

Người ta thường nói rằng ngành công nghiệp phần mềm là chưa trưởng thành so với sản xuất. Cụ thể liên quan đến việc được thúc đẩy quá trình.

Câu hỏi : Chúng ta có thể là nhà phát triển học hỏi từ các quy trình của ngành sản xuất không? Có thể áp dụng các quy trình của họ làm tăng tỷ lệ phát triển phần mềm thành công?

Tôi thực hiện : Trong sản xuất, việc tạo ra một sản phẩm được thúc đẩy bởi quá trình. Bạn có thể có một nhà máy nơi mỗi người có một bộ nhiệm vụ cụ thể mà họ tuân theo. Một công nhân (hoặc robot) có thể siết ốc vít cả ngày. Sau đó, nhiệm vụ tiếp theo trong quy trình được thực hiện bởi các chuyên gia tiếp theo. Các công nhân (và robot) không ngăn cản quá trình hoặc tạo ra một cái gì đó "trên đường bay". Các bộ phận chuyển qua quy trình, và đầu ra là một sản phẩm hoàn chỉnh. Nó hoạt động tốt và các công ty đạt được 99.99966% sản phẩm miễn phí. Các công ty giải quyết sự thiếu hiệu quả theo thời gian. Điều này là ấn tượng và rất tốt có thể là dấu hiệu của một ngành công nghiệp trưởng thành.

Trong sản xuất một quy trình xác định theo nghĩa đen có thể tạo ra thành phẩm. Tôi không nghĩ đây là trường hợp trong phần mềm. Chúng tôi có thể có các quy trình để kiểm soát nguồn, xem xét mã, kiểm tra trang tính, thu thập yêu cầu, SDLC, v.v. Nhưng việc thực hiện các quy trình đó không tự tạo ra một sản phẩm hoàn chỉnh. Các quy trình này có thể có lợi, nhưng trực giao với việc tạo thực tế.

Giả sử công ty của bạn được ký hợp đồng tạo ra phần mềm sẽ tìm kiếm hàng triệu hình ảnh để tìm ra khuôn mặt của một tên tội phạm. Mặc dù môi trường quá trình nặng nề, nhà phát triển phải tham gia vào việc tạo ra những thứ "đang hoạt động". Làm mọi thứ trên bay là trái với tinh thần sản xuất. Một quy trình sản xuất tốt có thể được thực hiện mà không cần suy nghĩ của robot.

Đối với việc tạo ra các thuật toán phức tạp chưa được hiểu rõ trong tâm trí của một con người, điều cần thiết là phải tạo ra mọi thứ một cách nhanh chóng. Phát triển phần mềm không phải là quy trình sau đây, mà là việc tạo ra một quy trình sẽ được máy tính thực hiện. Đó là một sự khác biệt cơ bản. Cho dù có bao nhiêu quá trình trực giao mà chúng ta đưa ra xung quanh sự phát triển, chúng ta sẽ luôn dùng đến việc thực hiện nó "một cách nhanh chóng" khi nói đến sáng tạo.

Mọi người tôi nói chuyện dường như đồng ý với tư duy sản xuất. Có phải tôi đơn độc trong suy nghĩ của tôi?

Sự khác biệt cơ bản giữa phát triển và sản xuất phần mềm là đối với phần mềm, giai đoạn thiết kế thực tế là toàn bộ. Sản xuất thực tế (phần dây chuyền lắp ráp trong sản xuất truyền thống) là vấn đề sao chép một vài tệp xung quanh. Trong phần mềm, thiết kế sản phẩm là sản phẩm.

Vì vậy, có, chúng ta có thể học hỏi từ các quy trình sản xuất, nhưng chỉ khi chúng ta nhớ rằng chúng ta phải xem xét giai đoạn thiết kế chứ không phải giai đoạn sản xuất và nhiều quy trình sản xuất được xây dựng để đối phó với những hạn chế cụ thể của chuỗi sản xuất đắt tiền , đơn giản là không áp dụng cho phần mềm.

Một ví dụ về mô hình quy trình hoạt động rất tốt trong phần mềm, nhưng thường thất bại khủng khiếp trong thiết kế sản phẩm, là thiết kế lặp - bạn bắt đầu với một nguyên mẫu tối thiểu và thêm các tính năng với mỗi lần lặp. Xây dựng một chiếc xe nguyên mẫu để xem thiết kế núm cửa sổ phía sau mới trông như thế nào là vô lý, nhưng trong phần mềm, nó có ý nghĩa (chỉ cần nhấn F5 và chờ vài giây - voilà, sẵn sàng lái thử).

Nếu chúng ta nhìn vào các quy trình thiết kế sản phẩm, các ngành công nghiệp tốt nhất để xem xét rơi vào hai loại:

• những nơi mà sản xuất có thể được thực hiện ở mức giá hàng hóa; ví dụ: ngành công nghiệp thu âm (1% hoặc ít hơn giá cho một đĩa CD là nướng và in), phương tiện đồ họa, v.v.
• những nơi có số lượng thấp đến mức giai đoạn thiết kế là yếu tố chi phí nổi bật nhất (các mặt hàng xa xỉ, các sản phẩm tùy biến cao, thị trường ngách ...)

Đó là một lỗi cơ bản để thử và áp dụng các quy trình từ sản xuất vật lý đến phát triển phần mềm: phát triển phần mềm không lặp lại (nếu đó là công việc của bạn, hãy tìm một công việc khác), nó chỉ có thể dự đoán được một phần, chỉ có rất ít hạn chế về thể chất ( tốc độ phần cứng là một), và cả cách tiếp cận được thực hiện và kết quả có thể mang tính cá nhân cao. Áp dụng các triết lý dây chuyền lắp ráp vào những gì về cơ bản là vấn đề phân tích và tư duy sáng tạo có thể (và thường không) có tác dụng tàn phá.

Nếu bạn muốn viết cùng một phần mềm chính xác (thay vì chỉ sao chép nó), bạn có thể làm điều đó rất hiệu quả thông qua một dây chuyền lắp ráp.

Nhưng tạo phần mềm không phải là một nhiệm vụ lặp đi lặp lại, mỗi mô-đun là uniqe. Đó là lý do tại sao việc so sánh với sản xuất là không hợp lệ.

Tôi nghĩ rằng câu trả lời bạn đang tìm kiếm là có thể áp dụng hoặc thực tế ở đây. Những gì tôi cảm thấy như bạn muốn biết là làm thế nào chúng ta có thể thiết lập các quy trình của mình giống với ngành công nghiệp sản xuất. Thay vào đó tôi nghĩ câu hỏi thực sự trở thành "Biết sản xuất và các ngành công nghiệp khác làm gì để xây dựng sản phẩm chất lượng, chúng ta có thể học được gì?" hoặc "Công nghiệp phần mềm có thể làm gì để cải thiện chất lượng?"

Thật không may, câu trả lời cho điều này là không rõ ràng vì bản thân ngành công nghiệp phần mềm vẫn chưa biết câu trả lời. Để có thể trả lời điều này, ngành công nghiệp phần mềm cần nghiên cứu về những gì hoạt động và tại sao? Ví dụ, đã có những nghiên cứu chỉ ra rằng Thiết kế ổ đĩa thử nghiệm (TDD) dẫn đến sự cải thiện về chất lượng. Mặc dù câu hỏi về năng suất dường như vẫn chưa được trả lời hoặc ít nhất là chưa hoàn toàn hiểu rõ. Theo như những gì các bằng chứng cho thấy cho đến nay:

• Đánh giá mã là tuyệt vời và được hiển thị để tìm ra nhiều lỗi nhất, nhưng hiệu quả của đánh giá giảm khá mạnh sau giờ đánh giá đầu tiên. Cho rằng một người bình thường chỉ có thể đọc vài trăm dòng mã một giờ, điều đó cho thấy các nhà phát triển nên chia nhỏ các thay đổi thành các phần nhỏ hơn.
• Càng mất nhiều thời gian để tìm ra một lỗi thì càng tốn kém (thời gian và tiền bạc) để sửa nó. Vì vậy, nếu một nhà phát triển tìm thấy nó trong khi viết mã, chúng tôi nói chi phí là 1. Nếu một người không tin tưởng tìm thấy nó sau đó thì chi phí là 10, nếu EVT tìm thấy nó thì chi phí là 100 và cứ thế.
• Có một số bằng chứng cho thấy các yêu cầu càng phức tạp thì giải pháp càng phức tạp và giải pháp càng phức tạp thì càng có nhiều lỗi.

Có một người đàn ông tên Greg Wilson đã nói chuyện tuyệt vời về một số điều này một vài năm trước đây. Dưới đây là một liên kết đến nói chuyện: Greg Wilson Talk

Ngoài ra, tôi sẽ nói rằng hãy nhìn lại công việc của chính bạn và tìm các chủ đề với các loại lỗi mà bạn giới thiệu cũng như những phần bạn đấu tranh. Tổng hợp các kết quả này và sau đó tạo một danh sách kiểm tra để chèn vào quy trình của bạn tại các vị trí khác nhau để giúp bạn thực hiện công việc tốt hơn. Cá nhân tôi đã nhìn lại những năm vừa qua trong công việc của mình và thấy rằng có một số chủ đề phổ biến cho các vấn đề tôi giới thiệu. Cụ thể tôi đã tìm thấy rằng

• Tôi thường không nhớ xây dựng tất cả các biến thể dẫn đến việc tôi phá vỡ công trình.
• Nhiều lần tôi không nghĩ về những điều sau đây cho mỗi thay đổi. Trường hợp tốt, trường hợp xấu và trường hợp ngoại lệ.
• Tất cả các kịch bản có thể xảy ra. Lưu ý rằng điều này thực sự khó khăn vì có rất nhiều trong số họ.

Vì tôi đã tìm thấy một số chủ đề cho các lỗi của mình, tôi đã tạo danh sách kiểm tra mà tôi tự động sử dụng, do chèn chúng vào tập lệnh của mình, giúp tôi khắc phục các vấn đề này. Có một cuốn sách viết về cuộc gọi này là "Bản kê khai danh sách kiểm tra", trong đó nêu chi tiết về cách sử dụng chúng. Cá nhân tôi thấy nó rất sâu sắc.

Đó không phải là về việc áp dụng các quy trình "của họ". Đó là về việc áp dụng các quy trình "một số", không có những bất lợi thông thường và được đánh giá cao khi sử dụng các quy trình dây chuyền lắp ráp cho các nỗ lực sáng tạo. Điều quan trọng nhất cần lưu ý ở đây là ý tưởng rằng chất lượng của các quy trình chuyển trực tiếp đến chất lượng của sản phẩm.

Các quy trình hay sản phẩm tốt nhất cho vấn đề đó là những quy trình phù hợp với kịch bản sử dụng dự định như một chiếc găng tay. Điều cần suy nghĩ là phần viết mã thực tế là về phần duy nhất, ít nhất là ở cấp độ vĩ mô, không lặp lại. Tất cả các khía cạnh khác, chẳng hạn như kiểm soát phiên bản, theo dõi lỗi, lập kế hoạch, ước tính, đo lường, v.v., và việc sử dụng một quy trình chuẩn, phù hợp và đã được chứng minh có thể giúp bạn ít nhất trong các lĩnh vực này.

Vì vậy, không, quy trình phát triển phần mềm không thể được ví như sản xuất dây chuyền lắp ráp và vì "quy trình của họ" không ổn, nhưng giai đoạn thiết kế sản xuất / thiết kế sản phẩm của sản phẩm trong ngành sản xuất có thể là nguồn cảm hứng.

Câu hỏi: Chúng ta có thể là nhà phát triển học hỏi từ các quy trình của ngành sản xuất không? Có thể áp dụng các quy trình của họ làm tăng tỷ lệ phát triển phần mềm thành công?

Trả lời: Có, tất nhiên. Có nhiều bài học mà các nhà phát triển phần mềm có thể học được từ sản xuất mặc dù thực tế rằng phát triển phần mềm là một quá trình sáng tạo. Phát triển phần mềm tự nó là một quá trình, và nó bao gồm nhiều quy trình khác. Bạn càng có thể xác định và kiểm soát các quy trình đó tốt hơn, bạn càng có thể kiểm soát tốt hơn quá trình phát triển phần mềm nói chung. Điều đó không có nghĩa là bạn nên kê đơn mỗi lần nhấn phím mà nhà phát triển thực hiện; điều đó chỉ có nghĩa là với tư cách là một nhà phát triển, bạn tự nhiên thực hiện các nhiệm vụ theo một thứ tự nhất định và những nhiệm vụ đó thường có thể được quản lý. Dưới đây là một số ví dụ:

• theo dõi lỗi: Khi một lỗi được quan sát hoặc báo cáo, điều gì xảy ra với nó? Bạn có viết nó ra một mẩu giấy và dán nó lên một cành 'điều tra' không? Sau này, bạn có loại bỏ những mẩu vụn đó cùng một lúc, điều tra chúng và cuối cùng di chuyển chúng đến mức tăng 'giải quyết' không? Nếu bạn làm điều đó mà không thất bại mỗi khi bạn nhận được báo cáo lỗi, bạn đã có một quy trình được xác định rõ ràng, có thể đo lường được và có lẽ bạn sẽ tốt hơn nhiều so với một người có hệ thống theo dõi lỗi khiếm khuyết, công nghệ cao rất phù hợp rằng một số thành viên trong nhóm theo dõi các lỗi khác, hoặc hoàn toàn không.

• kiểm soát phiên bản: Có nhiều khả năng bạn sử dụng kiểm soát phiên bản tại nơi bạn làm việc và kiểm soát phiên bản rõ ràng hữu ích hơn rất nhiều khi mọi người sử dụng cùng một cách.

• thiết kế sản phẩm: Bạn có quyết định thực hiện các tính năng nào bằng cách ném phi tiêu vào một bức tường phủ đầy ghi chú sau đó không? Nếu vậy, bạn đã có một quá trình. Tôi không nghĩ ai sẽ tranh luận rằng đó là một quá trình tuyệt vời, nhưng ít nhất đó là điểm khởi đầu. Nếu bạn thay đổi quy trình, làm sao bạn có thể biết chắc chắn rằng thay đổi của bạn thực sự là một sự cải thiện trừ khi bạn đo lường trước và sau? Bạn không thể.

• đánh giá mã: Đánh giá mã có hữu ích không nếu quy trình đánh giá và tiêu chí mã hóa thay đổi cho mỗi đánh giá? Dĩ nhiên là không.

• vòng đời phát triển phần mềm: Toàn bộ phân tích -> thiết kế -> thực hiện -> kiểm tra -> chu trình bảo trì là một quy trình cần được xác định rõ ràng.

Trong mỗi trường hợp này, có một quy trình tại chỗ cho phép bạn đo lường đầu vào và đầu ra và xác định xem những thay đổi bạn thực hiện có hiệu quả như mong muốn hay không. Không có quy trình tại chỗ có nghĩa là bạn chỉ đoán khi bạn cố gắng cải thiện cách bạn làm việc. Đây thực sự là những gì sản xuất là tất cả, và nó chỉ có ý nghĩa khi mượn các công cụ tinh chế kế tiếp của sản xuất khi chúng phù hợp.

Có toàn bộ lĩnh vực dành cho việc xác định và cải tiến các quy trình được sử dụng để tạo và bảo trì phần mềm; nó được gọi là kỹ thuật phần mềm . Không có gì ngạc nhiên khi bạn có câu hỏi về quy trình phát triển trong khi đọc về CMMI - CMMI là sản phẩm của Viện Kỹ thuật phần mềm .

Phát triển phần mềm đã áp dụng nhiều khái niệm sản xuất:

• Thật khó để không thấy ảnh hưởng của các bộ phận hoán đổi cho nhau của Eli Whitney đối với cả phát triển dựa trên thành phần và OOP .

• Các kỹ thuật quản lý dự án được sử dụng trong phát triển phần mềm không khác lắm so với các kỹ thuật được phát triển cho sản xuất. Chỉ là hai ví dụ, thế giới phần mềm chỉ mới áp dụng khái niệm Kanban được phát triển cách đây hàng thập kỷ tại Toyota và biểu đồ Gantt đã được sử dụng trong sản xuất từ ​​lâu trước khi máy tính điện tử đầu tiên được chế tạo.

• Các phương pháp quản lý chất lượng như Six Sigma được phát triển cho sản xuất đã được điều chỉnh để phát triển phần mềm.

Mặc dù môi trường quá trình nặng nề, nhà phát triển phải tham gia vào việc tạo ra những thứ "đang hoạt động".

Bạn có nói với tôi rằng ai đó sẽ tự quyết định thêm một bản vá vào gói nhận dạng khuôn mặt và họ sẽ thêm nó vào bản dựng sản xuất mà không tạo ra sự cố trong hệ thống theo dõi, đã xem xét thiết kế, kiểm tra mã vào kiểm soát phiên bản, hoặc để mọi người kiểm tra xem nó trước? Quá trình của chúng tôi đòi hỏi những điều đó vì một số lý do rất tốt. Nếu "trên đường bay", bạn có nghĩa là "ngoài quy trình", điều đó không thể chấp nhận được.

Làm mọi thứ trên bay là trái với tinh thần sản xuất.

Một lần nữa, nếu "đang hoạt động" có nghĩa là "ngoài quy trình", bạn đã đúng. Nhưng nếu bạn nghĩ rằng sản xuất không đòi hỏi phải suy nghĩ nhanh và phát triển các giải pháp sáng tạo cho các vấn đề, thì bạn đã nhầm. Tất cả các loại vấn đề xảy ra trong quá trình sản xuất - những chiếc bánh cupcake không có đủ kem, bề mặt sơn đột nhiên ngừng vượt qua bài kiểm tra đầu của QA, 20% thành phần bị thiếu một vòng giữ quan trọng, hệ thống trộn bột đã bị hỏng phần quan trọng...