Mô hình phát triển phần mềm nào đã hoạt động tốt nhất cho các nhóm phần mềm có sự phụ thuộc nặng nề vào các nhóm phần cứng?

Có một số thực tiễn tốt nhất cạnh tranh để phát triển phần mềm. Từ những gì tôi đã tìm thấy, nhiều nhóm đã được hưởng lợi từ các thực hành Agile trong một số trường hợp. Tuy nhiên, trong một số trường hợp khác, sử dụng Quy trình hợp nhất đã được các công ty lớn như IBM vô địch.

Các chủ đề phổ biến mà tôi thấy dường như hoạt động tốt cho các nhóm chủ yếu phát triển phần mềm.

Tôi muốn biết những gì đã làm việc tốt nhất cho những người đã làm việc trong các cửa hàng nơi có một nhóm ở phía bên kia sản xuất phần cứng mà phần mềm của bạn đang chạy. Ví dụ, một nhóm đặt một thùng với một số phần cứng tùy chỉnh trên đó; trong khi bạn cần phát triển phần mềm chạy trên các thùng đó. Tôi không thể tìm thấy một mô hình phát triển (nhanh nhẹn, xoắn ốc ...) hoạt động tốt nhất trong trường hợp này.

Bất kỳ sự khôn ngoan là lĩnh vực này sẽ được đánh giá tốt.

Nó thực sự phụ thuộc vào cách nhóm phần cứng của bạn sẽ phân phối các tạo phẩm hữu ích mà nhóm phần mềm của bạn có thể sử dụng để phát triển và cách các nhóm được thiết lập để giao tiếp với nhau.

Thông thường, bạn sẽ thấy nhóm phần cứng sẽ xây dựng một sản phẩm, đưa nó đến giai đoạn nguyên mẫu để thử nghiệm và chỉ sau đó, nhóm phần mềm mới nhận được bất kỳ loại tài liệu yêu cầu nào từ nhóm phần cứng. Không cần phải nói điều này không phải lúc nào cũng là cách tốt nhất, vì phần mềm thường được phát triển rất muộn trong quy trình và bạn thường thấy mình có ít sự lựa chọn ngoài làm việc với phương pháp dựa trên thác nước. Theo quan điểm của nhóm phần cứng, nếu họ đột nhiên cần thay đổi thứ gì đó, nhóm phần mềm sẽ không cần sửa đổi phần mềm của họ. Vấn đề ở đây tất nhiên là anh chàng phần cứng trung bình của bạn cần phát triển sản phẩm theo cách này và hy vọng rằng bất cứ điều gì sẽ có lợi cho anh ta với sự giúp đỡ của nhóm phần mềm.

Thay vào đó, nếu nhóm phần cứng của bạn đang xây dựng một sản phẩm và cập nhật các yêu cầu phần mềm khi họ đi, và thậm chí tốt hơn, nếu họ liên quan đến nhóm phần mềm sớm vì mỗi tính năng phần cứng đang được lên kế hoạch và mô phỏng, thì bạn có cơ hội cho nhóm phần mềm làm việc theo cách nhanh nhẹn hơn nhiều. Đương nhiên, điều này có nghĩa là nhóm phần cứng là khách hàng và cung cấp cho nhóm phần mềm một danh sách các vấn đề cần được giải quyết trong phần mềm. Nhóm phần mềm có thể thảo luận với khách hàng của họ về các ưu tiên tương đối của từng yêu cầu và ngay khi nguyên mẫu phần cứng sẵn sàng, phần mềm có thể sẽ có sẵn ở dạng phát hành sớm và có thể được sử dụng để giúp kiểm tra phần cứng. Nếu các yêu cầu thay đổi, nhóm phần mềm hy vọng sẽ có sự linh hoạt để thay đổi phần mềm khi họ đi, và có thể cung cấp phản hồi sớm cho nhóm phần cứng trước khi thiết kế phần cứng được cam kết nguyên mẫu. Nhóm phần mềm cũng có quyền truy cập trực tiếp vào khách hàng từ rất sớm trong dự án, điều đó có nghĩa là họ có thể hiểu rõ hơn về những gì họ cần chế giễu - và cách thực hiện - trong khi chờ phần cứng kiểm tra.

Trên thực tế, bạn sẽ không tìm thấy một phương pháp lý tưởng nào phù hợp với giá sách và tôi có thể đảm bảo rằng bạn sẽ có nhiều điều chỉnh để thực hiện bất kể phương pháp nào bạn chọn áp dụng hoặc phát triển. Vấn đề thực sự là bạn muốn thử và làm cho việc đồng bộ hóa giữa các nhóm trở nên dễ quản lý và có nghĩa là bạn cần tìm cách tăng số lượng liên hệ và đầu vào giữa hai nhóm càng sớm càng tốt trong quá trình, ngay cả khi nó có vẻ "lãng phí" hoặc "phản trực giác" để làm như vậy. Đây là một vấn đề lớn trong công ty mà tôi hiện đang làm việc. "Phụ huynh" châu Âu của chúng tôi đang phải vật lộn với vấn đề chính xác này, trong khi nhóm ở Oz dường như có thể giữ mọi thứ hoạt động trơn tru hơn một chút, và nó '

Tôi có lẽ thiên vị, đã làm việc nhiều hơn về phía phần cứng của các nhóm phát triển sản phẩm phần cứng lớn. Phần cứng có thể rất tốn kém để sửa đổi nếu nó được kiến ​​trúc hoặc thiết kế sai. Thường thì một lỗi trong thiết kế phần cứng rất tốn kém, điều đó có nghĩa là hủy toàn bộ dự án. Sửa một lỗi mặt nạ chip có thể tốn nhiều tiền hơn mức lương hàng năm của hàng chục kỹ sư. Vì vậy, tôi thấy mục đích chính của nhóm phần mềm trong 50% + đầu tiên của chu kỳ phát triển là để đảm bảo nhóm phần cứng không bị lỗi. Điều này có thể có nghĩa là quên mã ứng dụng cuối cùng và lúc đầu thiết kế, và chỉ làm việc trên các mô phỏng kiến ​​trúc phần cứng và hiệu suất, các công cụ để giúp nhóm phần cứng hoàn thành và xác minh thiết kế của họ,

Hy vọng sẽ nhanh nhẹn, không chỉ về thông số kỹ thuật của khách hàng, mà còn về các lỗi / lỗi đáng ngạc nhiên khác nhau trong nền tảng phần cứng, nơi một cách giải quyết phần mềm có thể có tác động ít hơn đến lịch trình so với quay phần cứng.

Một trong những người thuê chính của Agile là "thất bại sớm". Với phần cứng, điều này không thể đúng hơn. Phần cứng sản xuất hàng loạt là vô cùng đắt đỏ. Hơn nữa, phần cứng vật lý không thể đơn giản là "vá" như phần mềm có thể. Làm trầm trọng thêm những vấn đề này, các nhóm phần cứng có xu hướng ít phải đối mặt với khách hàng hơn các nhóm phần mềm trong thực tế và có xu hướng được sử dụng cho mô hình phát triển "vụ nổ lớn".

Vì những lý do này, việc không nắm bắt được các vấn đề về phần cứng càng sớm càng tốt thường là các đơn đặt hàng có cường độ đắt hơn sau đó không nắm bắt được các sự cố phần mềm sớm. Khách hàng mong đợi yêu cầu cập nhật phần mềm, họ có thể ngừng hoàn toàn làm việc với bạn nếu họ phải xử lý thu hồi phần cứng.

Nói tóm lại, không mong đợi và chuẩn bị sớm cho các vấn đề phần cứng là thách thức lớn nhất của mô hình phát triển khi phát triển song song phần mềm và phần cứng.

Bạn hoàn toàn phải lường trước thất bại. Lấy nguyên mẫu sớm. Sử dụng nguyên mẫu để phát triển chống lại. Hy vọng nó sẽ là một thất bại. Học hỏi từ sự thất bại. Rửa sạch. Nói lại. Hãy chắc chắn rằng mọi người dự đoán rằng các nguyên mẫu phần cứng sẽ được sửa đổi / phê bình / thiết kế lại dựa trên phản hồi từ các bên liên quan.