Firmware / gömülü sistemler-yazılım geliştirmek için çevik bir metodoloji nasıl benimsenir?

Her zaman çevik yöntemlerin nasıl uygulanacağını merak ettim, gerçekten büyük karmaşık gömülü sistem yazılımında (100+ mühendis). Ürün yazılımı geliştirme, çevik yapmayı zorlaştıran bazı benzersiz özelliklere sahiptir (yani, donanım geliştirme döngüsünün sonuna kadar donanım kullanılamaz; Ürün piyasaya sürüldüğünde, ürün yazılımını kolayca güncelleyemez; vb.)

Bu tür bir gelişimdeki norm, kalın dokümantasyon ve yorucu akran incelemeleridir. 2-3 imza olmadan bir değişkeni yeniden adlandırmak gibi basit bir kod düzeltmesi alamazsınız. (Biraz abartıyorum ama bu tipik. Ek olarak, birçok insan kısayol kullanıyor ve Proje Yöneticileri bunları özellikle zor piyasa süreleri karşısında onaylıyor.)

Ürün yazılımı geliştirme projeleri için çevik metodolojinin nasıl benimseneceğine dair ipuçlarını veya yönergeleri duymak isterim.

İki tekniğin anahtar olduğunu düşünüyorum:

• Yazılımı gerçek bir donanıma sahip gibi geliştirebilmeniz için donanım için eksiksiz bir simülatör veya test ortamı geliştirin. Burada eksik ya da kısayol kullanmayın: iyi bir simülatör geliştirmek işe yarayacaktır .

• Simülatöre karşı çok sayıda birim testi yazın .

Bu şeyleri sürdürdüğünüzde ve insanlar simülatör ve birim testlerinin, donanımla nasıl çalışacağına dair doğru bir fikir vereceğinden emin olduklarında, diğer çevik teknikleri (kısa iterasyonlar, amansız yeniden düzenleme vb.) Benimsemek daha kolay olacaktır. .

Agile'ın birden fazla tedarikçiyi içeren bir geliştirme süreci üzerindeki etkisi, bir şirket JIT'e gittiğinde olanlarla karşılaştırılabilir.

JIT'i teslim etmek için şirketin her tedarikçisinin JIT'i teslim etmesi gerekir.

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

Benzer şekilde, Agile metodolojilerine göre karmaşık bir ürünün geliştirilmesini istiyorsanız, zincirdeki her alt grup bu şekilde çalışabilmelidir.

'Artan' gelişme ( 15 yıl önceki Tracer Bullets olarak da bilinir ) açısından, bu 'çekirdek' sürücünün çok yakında serbest bırakılacağı ve temel sürücünün entegratör tarafından kullanılabileceği ve GUI'nin aynı anda tek bir düğme ve bir düzenleme kutusu ile geliştirilebilir.

Zor olan, sağlam bir düşünceli mühendislik disiplinden gelen donanım tasarımcılarını tamircilik topluluğumuza katılmaya ikna etmektir.

İkinci en zor kısım, donanım baskısının 3 hafta önceden sipariş edileceği bir dünyada artımlı gelişimin sağlanmasının bir yolunu bulmaktır. Ben öykünücüler düşünüyorum, fpga burada. Yine de donanımcı değilim.

Artımlı donanım geliştirmeye düşmek istiyorsanız, tıpkı bir JIT zincirinin sınırlarında olduğu gibi, Agile takımlarının ilerlemesine izin veren bir tamponlama mekanizması öngörebilirsiniz.

Kör olmayalım: Agile'ın ağır süreçlerle de uğraşması gerekiyor! Agile ekibinden bir sonraki sprint'te artık Java kod tabanlarını Python'a 'yeniden düzenlemelerini' istemeyin. Sadece bazı kısımları gerçekten kararlı olduğu için Agile hareketlerimizi onların üstünde dans edebiliriz.

Çevik Manifesto: http://agilemanifesto.org/

"Bireyler ve süreçler ve araçlar üzerindeki etkileşimler"

• Daha fazla tanışın. Kağıdı daha az itin.

"Kapsamlı belgeler üzerinde çalışan yazılım"

• Prototip ve yapım teknolojisi erken ve sık sık yükselir.

• Bir spesifikasyona sıkı sıkıya bağlı kalmaya devam etmek yerine kullanıcının gerçek problemini çözün . Bu evrimsel çözümler demektir . Onu doğru şekilde inşa etmemiz gerektiği fikri, bir daha asla inşa edemeyeceğimiz yanlıştır. Yinelemeyi planlayın. Pazarlama ve dağıtım stratejisinin bir parçası haline getirin.

"Sözleşme görüşmesi üzerinden müşteri işbirliği"

• Hiper-kompleks değişim-kontrol süreçleri sadece müşteriye "hayır" demenin yollarından biridir.

• Tüm gereksinimleri önceden kilitlemek ve daha sonra değişiklik kontrolü uygulamak "hayır" demenin başka bir yoludur.

• Zaten birden fazla sürüm planlıyorsanız, gereksinimleri daha sonraki bir sürüme daha kolay erteleyebilirsiniz. Müşteri cihaza gömülü yazılımla sahip olduktan sonra, bir sonraki sürüm önceliklerinde değişecektir.

"Bir planın ardından değişime cevap vermek"

• Karmaşık entegrasyon karmaşık bir plan gerektirse de, genel "program" (veya proje dizisi) çok erken somut olarak kullanılamaz.

Tamamen Çevik bir metodoloji (yani scrum) gömülü bir sistem için anlamlı olmayabilir.

Bununla birlikte, Agile manifestosu, basit bir kaosa izin vermeden değişimin mümkün kılınması için yollar sağlar.

Gömülü sistemlerde scrum ile ilgili sorunum, özellikle erken aşamalarda, gösterilemeyen birçok görev var. Bir dev kartı, işletim sistemi, ekran, seri haberleşme vb. İle başladık. 6 sprint için ekranımız yoktu.

İlk 4 sprint vardı: RTOS'u kurma ve çalıştırma Görev oluşturma Ağ ve seri sürücüleri yazma Düğmeler, iletişim bilgileri vb. İçin kesme rutinleri yazma Birincil veritabanı sınıfları ve yöntemleri yazma Seri hata ayıklama menüsü yazma

Bu görevlerin çoğu kullanıcı hikayeleri için uygun değildir. Aslında, tüm sisteme tek arayüz, sprint 3'te yerleşik olan seri hata ayıklama menüsüdür, bu yüzden sprintlerin sonunda gösterilecek hiçbir şey yoktu. Seri menü bile son kullanıcı için değil dahili kullanım içindir.

Elbette, yazdığımız her sınıfın ilişkili birim testleri vardır ve tüm testlerin yürütülmesini otomatikleştirmek için bir birim test çerçevesi kullanırız.

"Bir geliştirici olarak ..." gibi "kullanıcı öyküleri" ifadeleri yazarak sonuçlandırmadık, ancak Hedef Süreci'ni (www.targetprocess.com) kullanırken, bir biriktirme öğesi kavramı yok. bir görev veya angarya.

Başkalarının bu durumları nasıl ele aldığını duymak isterim.