Bagaimana cara mengadopsi metodologi gesit untuk mengembangkan firmware / embedded-system-software?


17

Saya selalu bertanya-tanya bagaimana cara menerapkan metode lincah benar-benar dalam perangkat lunak sistem tertanam besar yang kompleks (100 + insinyur). Pengembangan firmware memiliki beberapa karakteristik unik yang membuatnya sulit dilakukan dengan gesit (mis. Perangkat keras tidak tersedia hingga akhir siklus dev; Setelah produk dirilis, tidak dapat dengan mudah memperbarui firmware; dll ...)

Norma dalam pengembangan semacam ini adalah dokumentasi yang tebal dan ulasan sejawat yang melelahkan. Anda tidak bisa mendapatkan perbaikan kode sederhana seperti mengganti nama variabel tanpa 2-3 tanda tangan. (Saya sedikit melebih-lebihkan tetapi ini tipikal. Selain itu, banyak orang yang mengambil jalan pintas dan Manajer Proyek bahkan menyetujui mereka terutama dalam menghadapi tenggat waktu pasar yang keras.)

Saya ingin mendengar kiat atau pedoman tentang cara mengadopsi metodologi lincah untuk proyek pengembangan firmware.


Saya mengerti bahwa perangkat keras yang diselesaikan tidak tersedia hingga akhir siklus dev, tetapi tidakkah Anda memiliki perangkat keras prototipe atau debug, papan dev, atau setidaknya simulator vendor untuk diuji? Atau kita mulai dari awal di sini?
Kevin Vermeer

3
Saya sedang berbicara dengan pengembang lincah tentang pekerjaan tertanam saya. "Rilis setiap 6-8 minggu!?!?" dia berkata. "Itu waktu yang sangat lama". "Tidak, kamu salah dengar," kataku, "Ini 6-8 bulan "
AShelly


2
Saya agak penasaran jenis produk apa yang memiliki 100+ insinyur yang disematkan?
Pemdas

@reemrevnivek - biasanya ada papan eval dari proyek sebelumnya yang dapat digunakan. Terkadang, mereka cukup mirip dengan produk baru. Meski begitu, meskipun semua tes Anda lulus pada papan eval ketika Anda benar-benar menjalankan firmware pada perangkat akhir, lebih sering daripada tidak, tes akan pecah karena ada beberapa hal baru yang orang-orang perangkat keras memutuskan untuk menambahkan pada menit terakhir atau mungkin tidak menyebutkan kepada kami pada awalnya ....
hopia

Jawaban:


10

Saya pikir dua teknik adalah kuncinya:

  • Kembangkan simulator lengkap atau lingkungan uji untuk perangkat keras, sehingga Anda dapat mengembangkan perangkat lunak seolah-olah Anda memiliki perangkat keras nyata. Jangan berhemat atau mengambil jalan pintas di sini: mengembangkan simulator yang baik akan membuahkan hasil.

  • Tulis banyak unit test melawan simulator.

Setelah Anda menyelesaikan semua ini, dan orang-orang yakin bahwa simulator dan unit test akan memberikan gagasan yang akurat tentang bagaimana hal-hal akan bekerja dengan perangkat keras, akan lebih mudah untuk mengadopsi teknik gesit lainnya (iterasi pendek, refactoring tanpa henti, dll.) .


Juga, buat produsen chip menyediakan bagian yang relevan dari kode simulator.
rwong

pada saat Anda memiliki barang-barang ini seorang pesaing telah dikirim
Bill

Jika Anda memiliki 100+ insinyur, Anda tentu dapat membuat simulator yang dapat digunakan dalam waktu kurang dari yang dikirimkan pesaing Anda. Itu terutama benar jika pesaing Anda tidak memiliki cara untuk menguji perangkat lunak mereka sampai mereka menerima perangkat keras.
Kristopher Johnson

Ya, saya setuju simulator adalah kuncinya. Jadi merancang seluruh sistem dari awal berdasarkan seberapa efisien Anda dapat memecah sistem menjadi komponen yang dapat diuji. Sekarang, bagaimana meyakinkan semua orang untuk menjadi gesit adalah pertanyaan lain ........
hopia

@ bill Itu sangat mungkin. Namun, itu mungkin berarti mereka mengirim produk inferior yang belum diuji, dan produk OP akan mengeluarkan mereka dari air. Yah, setidaknya begitulah seharusnya.
Julio

2

Dampak Agile pada proses pengembangan yang melibatkan banyak pemasok dapat dibandingkan dengan apa yang terjadi ketika perusahaan menggunakan JIT.

Untuk memberikan JIT, masing-masing pemasok perusahaan harus mengirimkan JIT.

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

Demikian juga, jika Anda ingin produk kompleks dikembangkan menurut metodologi Agile, setiap subkelompok dalam rantai harus dapat bekerja dengan cara itu.

Dalam hal pengembangan 'incremental' (alias Tracer Bullets 15 tahun yang lalu), ini akan menyiratkan bahwa 'inti' dilepaskan segera kepada pengemudi, dan bahwa driver dasar tersedia untuk integrator, dan bahwa GUI akan dikembangkan, beit dengan satu tombol dan kotak edit, pada saat yang sama.

Bagian yang sulit adalah meyakinkan para perancang perangkat keras, yang berasal dari disiplin teknik berpikir-muka yang kuat, untuk bergabung dengan masyarakat bermain-main kami.

Bagian tersulit kedua adalah menemukan cara untuk memungkinkan pengembangan tambahan di dunia di mana cetak perangkat keras akan dipesan 3 minggu sebelumnya. Saya sedang memikirkan emulator, FPGA ada di sini. Saya bukan seorang pria perangkat keras sekalipun.

Jika Anda ingin menjatuhkan pengembangan perangkat keras tambahan, Anda bisa, seperti halnya di perbatasan rantai JIT, meramalkan mekanisme penyangga yang memungkinkan tim Agile untuk maju.

Jangan buta: Agile juga harus berurusan dengan proses yang berat! Jangan meminta tim Agile untuk sekarang 'refactor' basis kode Java mereka ke Python di sprint berikutnya. Hanya karena beberapa bagian benar-benar stabil sehingga kita bisa menari gerakan Agile kita di atasnya.


+1 untuk gesit hanya dimungkinkan karena hal-hal yang mendasarinya dirancang / dilakukan secara menyeluruh.
Bill

1

Agile Manifesto: http://agilemanifesto.org/

"Individu dan interaksi atas proses dan alat"

  • Bertemu lebih banyak. Dorong kertas lebih sedikit.

"Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif"

  • Prototipe dan membangun paku teknologi awal dan sering.

  • Pecahkan masalah nyata pengguna alih-alih terus membangun kepatuhan yang rewel terhadap suatu spesifikasi. Ini berarti solusi evolusioner . Gagasan bahwa kita harus membangunnya dengan benar karena kita tidak pernah dapat membangunnya lagi adalah salah. Rencanakan iterasi. Jadikan itu bagian dari strategi pemasaran dan peluncuran.

"Kolaborasi pelanggan atas negosiasi kontrak"

  • Proses kontrol perubahan yang sangat rumit hanyalah cara untuk mengatakan "tidak" kepada pelanggan.

  • Mengunci semua persyaratan di depan dan kemudian memaksakan kontrol perubahan adalah cara lain untuk mengatakan "tidak".

  • Jika Anda sudah merencanakan lebih dari satu rilis, maka Anda dapat lebih mudah menunda persyaratan untuk rilis berikutnya. Setelah pelanggan memiliki perangkat dengan perangkat lunak yang disematkan, rilis berikutnya akan berubah dalam prioritasnya.

"Menanggapi perubahan setelah mengikuti rencana"

  • Sementara integrasi yang kompleks membutuhkan rencana yang kompleks, "program" keseluruhan (atau urutan proyek) tidak dapat dibuat terlalu cepat.

Metodologi yang benar-benar gesit (yaitu scrum) mungkin tidak masuk akal untuk sistem tertanam.

Namun, manifesto Agile menyediakan cara untuk memungkinkan perubahan menjadi mungkin tanpa membiarkan kekacauan sederhana.


0

Masalah saya dengan scrum dalam embedded system adalah, ada banyak tugas yang harus dilakukan, terutama pada tahap awal, yang tidak dapat dibuktikan. Kami mulai dengan papan dev, tanpa OS, tanpa layar, tanpa komunikasi serial, dll. Kami tidak memiliki layar untuk 6 sprint.

4 sprint pertama adalah: Memulai dan menjalankan RTOS Membuat tugas Menulis driver jaringan dan serial Menulis rutin interupsi untuk tombol, comms, dll. Menulis kelas dan metode basis data primer Menulis menu debug serial

Sebagian besar tugas ini tidak cocok untuk cerita pengguna. Bahkan, satu-satunya antarmuka ke seluruh sistem adalah menu debug serial, dibangun di sprint 3 sehingga tidak ada yang menunjukkan di akhir sprint. Bahkan menu serial dimaksudkan untuk penggunaan internal dan bukan pengguna akhir.

Tentu saja, setiap kelas yang kami tulis memiliki tes unit terkait dan kami menggunakan kerangka uji unit untuk mengotomatisasi pelaksanaan semua tes.

Kami akhirnya menulis frasa "cerita pengguna" seperti, "Sebagai pengembang ...", yang tidak saya sukai tetapi dalam menggunakan Proses Target (www.targetprocess.com), tidak ada konsep item jaminan simpanan yang tugas atau tugas.

Saya ingin mendengar bagaimana orang lain menangani situasi ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.