Làm thế nào để áp dụng phương pháp nhanh để phát triển phần mềm / hệ thống nhúng-phần mềm?

Tôi đã luôn tự hỏi làm thế nào để áp dụng các phương thức nhanh thực sự có trong phần mềm hệ thống nhúng phức tạp lớn (hơn 100 kỹ sư). Phát triển phần sụn có một số đặc điểm độc đáo gây khó khăn khi thực hiện nhanh (ví dụ: Phần cứng không khả dụng cho đến cuối chu kỳ phát triển; Một khi sản phẩm được phát hành, không thể dễ dàng cập nhật phần sụn; v.v ...)

Các tiêu chuẩn trong loại phát triển này là tài liệu dày và đánh giá ngang hàng. Bạn không thể sửa lỗi mã đơn giản như đổi tên một biến mà không có 2-3 chữ ký. (Tôi phóng đại một chút nhưng điều này là điển hình. Ngoài ra, rất nhiều người thực hiện các phím tắt và Người quản lý dự án thậm chí chấp thuận chúng đặc biệt khi đối mặt với thời hạn thị trường khó khăn.)

Tôi muốn nghe bất kỳ lời khuyên hoặc hướng dẫn về cách áp dụng phương pháp nhanh cho các dự án phát triển phần sụn.

Tôi nghĩ rằng hai kỹ thuật là chính:

• Phát triển một trình giả lập hoặc môi trường thử nghiệm hoàn chỉnh cho phần cứng, để bạn có thể phát triển phần mềm như thể bạn có phần cứng thực sự. Đừng bỏ qua hoặc sử dụng các phím tắt ở đây: phát triển một trình giả lập tốt sẽ được đền đáp.

• Viết nhiều bài kiểm tra đơn vị chống lại trình giả lập.

Khi bạn đã thực hiện được những điều này và mọi người tin tưởng rằng các thử nghiệm mô phỏng và đơn vị sẽ đưa ra ý tưởng chính xác về cách mọi thứ sẽ hoạt động với phần cứng, sẽ dễ dàng hơn để áp dụng các kỹ thuật nhanh nhẹn khác (lặp lại ngắn, tái cấu trúc không ngừng, v.v.) .

Tác động của Agile đối với quá trình phát triển liên quan đến nhiều nhà cung cấp có thể được so sánh với những gì xảy ra khi một công ty đi JIT.

Để cung cấp JIT, mỗi nhà cung cấp của công ty phải cung cấp JIT.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

Tương tự như vậy, nếu bạn muốn một sản phẩm phức tạp được phát triển theo phương pháp Agile, mọi nhóm con trong chuỗi sẽ có thể hoạt động theo cách đó.

Về mặt phát triển 'gia tăng' (còn gọi là Tracer Bullets của 15 năm trước), điều này có nghĩa là 'lõi' sẽ sớm được phát hành cho anh chàng lái xe và trình điều khiển cơ bản có sẵn cho nhà tích hợp và GUI sẽ được phát triển, cùng lúc với một nút duy nhất và hộp chỉnh sửa.

Phần khó là thuyết phục các nhà thiết kế phần cứng, đến từ một chuyên ngành kỹ thuật tư duy vững chắc, tham gia vào xã hội tinkerer của chúng tôi.

Phần khó thứ hai là tìm cách cho phép phát triển gia tăng trong một thế giới nơi một bản in phần cứng sẽ được đặt hàng trước 3 tuần. Tôi đang nghĩ về trình giả lập, fpga đang ở đây. Tôi không phải là một người phần cứng mặc dù.

Nếu bạn sẵn sàng thả vào phát triển phần cứng gia tăng, bạn có thể, giống như trên các đường viền của chuỗi JIT, thấy trước một cơ chế đệm cho phép các nhóm Agile tiến lên.

Chúng ta đừng mù quáng: Agile cũng phải đối phó với các quá trình nặng nề! Đừng yêu cầu nhóm Agile bây giờ 'tái cấu trúc' cơ sở mã Java của họ thành Python trong lần chạy nước rút tiếp theo. Chỉ vì một số phần thực sự ổn định mà chúng ta có thể nhảy những bước nhảy Agile của mình trên đầu chúng.

Tuyên ngôn nhanh nhẹn: http://agilemanifesto.org/

"Cá nhân và tương tác qua các quy trình và công cụ"

• Gặp nhiều hơn. Đẩy giấy ít.

"Phần mềm làm việc trên tài liệu toàn diện"

• Nguyên mẫu và xây dựng công nghệ tăng đột biến sớm và thường xuyên.

• Giải quyết vấn đề thực sự của người dùng thay vì tiếp tục xây dựng sự tuân thủ chặt chẽ với một đặc điểm kỹ thuật. Điều này có nghĩa là các giải pháp tiến hóa . Ý tưởng rằng chúng ta phải xây dựng nó đúng bởi vì chúng ta không bao giờ có thể xây dựng lại nó là sai. Kế hoạch lặp đi lặp lại. Làm cho nó trở thành một phần của chiến lược tiếp thị và triển khai.

"Hợp tác khách hàng trong đàm phán hợp đồng"

• Các quy trình kiểm soát thay đổi siêu phức tạp chỉ là cách nói "không" với khách hàng.

• Khóa tất cả các yêu cầu lên phía trước và sau đó áp đặt kiểm soát thay đổi là một cách khác để nói "không".

• Nếu bạn đã lên kế hoạch cho nhiều hơn một bản phát hành, thì bạn có thể dễ dàng trì hoãn các yêu cầu hơn cho bản phát hành sau. Khi khách hàng có thiết bị có phần mềm nhúng, phiên bản tiếp theo sẽ thay đổi theo các ưu tiên của nó.

"Đáp ứng để thay đổi theo kế hoạch"

• Mặc dù tích hợp phức tạp đòi hỏi một kế hoạch phức tạp, "chương trình" tổng thể (hoặc chuỗi dự án) không thể được đúc kết quá sớm.

Một phương pháp hoàn toàn Agile (ví dụ scrum) có thể không có ý nghĩa đối với một hệ thống nhúng.

Tuy nhiên, bản tuyên ngôn Agile cung cấp các cách để cho phép thay đổi là có thể mà không cho phép sự hỗn loạn đơn giản.

Vấn đề của tôi với scrum trong các hệ thống nhúng là, có rất nhiều nhiệm vụ phải làm, đặc biệt là trong giai đoạn đầu, không thể chứng minh được. Chúng tôi bắt đầu với một bảng dev, không có hệ điều hành, không hiển thị, không có comms nối tiếp, v.v. Chúng tôi không có màn hình cho 6 lần chạy nước rút.

4 lần chạy nước rút đầu tiên là: Khởi động và chạy RTOS Tạo tác vụ Viết trình điều khiển mạng và trình điều khiển nối tiếp Viết các thói quen ngắt cho các nút, comms, v.v. Viết các lớp và phương thức cơ sở dữ liệu chính Viết menu gỡ lỗi nối tiếp

Hầu hết các tác vụ này không phù hợp với câu chuyện của người dùng. Trên thực tế, giao diện duy nhất trong toàn bộ hệ thống là menu gỡ lỗi nối tiếp, được xây dựng trong lần chạy nước rút 3 nên không có gì để chứng minh ở cuối các lần chạy nước rút. Ngay cả menu nối tiếp cũng có nghĩa là để sử dụng nội bộ và không phải là người dùng cuối.

Tất nhiên, mỗi lớp chúng tôi viết có các bài kiểm tra đơn vị liên quan và chúng tôi sử dụng khung kiểm tra đơn vị để tự động hóa việc thực hiện tất cả các bài kiểm tra.

Cuối cùng chúng tôi đã viết các cụm từ "câu chuyện người dùng" như "Là nhà phát triển ...", điều mà tôi không hài lòng nhưng khi sử dụng Target Process (www.target Process.com), không có khái niệm nào về một mục tồn đọng một nhiệm vụ hoặc việc vặt.

Tôi muốn nghe cách những người khác đã xử lý các tình huống này.