Ağır siklet geliştirme metodolojilerinde kişisel uygulama nasıl kazanılır?

Projenin katı kalite standartlarını karşılaması, yoğun bir şekilde belgelenmesi, ayrıntılı olarak yönetilmesi, UML diyagramları ve geçmiş iş deneyimimin çoğunun bulunduğu "kovboy kodlaması" nın tersi olan tüm bu işleri yapıyorum . Büyük ölçekli havacılık veya tıbbi cihaz yazılımının nasıl geliştirildiğini düşünün.

Kovboy kodlamasının kaosunu bıraktığım için memnunum ve ağır mühendislik yöntemlerinin ne kadar iyi gittiğini merak ediyorum. Peki ağır yöntemlerle nasıl hızlı bir şekilde deneyim kazanılabilir?

Sadece birkaç ay / yıl boyunca işte olmanın yanı sıra.

Sadece bir dil veya yeni bir API ile, bir oyuncak test programını hackleyebilir, okuyabilir, ne olduğunu görmek için kasıtlı olarak hatalar yapabilir, vb. Bisiklete binmede veya bir müzik aleti çalmada iyi olmak gibi, uygulama önemlidir. Bir flüt almak ve her gün yarım saat geçirmek kolaydır; orkestraya katılmanıza ya da tam zamanlı flüt danışmanı olmanıza gerek yok. Ancak, büyük, karmaşık, ekipleri içeren ve çoğu iletişim ve planlama ile yanlış iletişimden kaçınmak ve program ve bütçe sınırlarını aşmakla ilgili olan yazılım mühendisliği faaliyetlerini nasıl uygulayabilirim?

Yalnız yapmak mümkün görünmüyor. Az sayıda insanın kısa sürede (bir gün) küçük bir ölçekte tüm büyük bir projeyi simüle etmesinin bir yolu var mı?

Az sayıda insanın kısa sürede (bir gün) küçük bir ölçekte bütün bir projeyi simüle etmesinin bir yolu var mı?

Evet, bu bir dereceye kadar mümkündür. Yaklaşık 10 yıl önce, Münih'teki OOP konferansında, 16 kişiye küçük işletme yazılımları için kaba analiz ve tasarım yapma görevinin verildiği bir çalıştayda yer aldım. Günün ilk yarısı esas olarak 16 kişiyle görevi çözmek için bir ekip yapısı bulmaktı ve günün ikinci yarısı ise bu ekiple görevi çözmeye odaklandı.

İlk bölümde 16 kişiyi dörtlü gruplara ayırmamız gerekti. Her dört kişi-ekip takım yapısı (zaman baskısı altında) için öneriler üzerinde çalışmak zorunda kalmıştır, daha sonra hangi takım yapısının en iyi olabileceğine ve çalıştayın ikinci kısmı için kullanılması gerektiğine karar vermek için bir atış işlemi uygulanmıştır. .

Ne yazık ki, ilk bölümde, 16 kişiden her birine amaçlanan ekip yapısı içinde bir iş vermeye çalışmak için hata yaptık. Bu hata ikinci yarıda kaosa yol açar - çünkü 16 kişi böyle bir görevi çözmek için çok fazladır. Çalışan bir çözüm, 16 kişiyi daha küçük takımlara ayırmak veya ana işi yapmak için 3 veya 4 kişiyi seçmek olabilir, ancak anın sıcağında bunu görmeyi kaçırdık.

Hala o gün daha büyük proje organizasyonlarında karşılaşılabilecek tipik sorunlar hakkında çok şey öğrendiğim izlenimindeyim. Size yakın bir yerde bu tür bir atölyeyi nerede ziyaret edebileceğinizi bilmiyorum ya da bugünlerde böyle bir şey kimin teklif ettiğini bilmiyorum, ancak bir şansınız varsa, katılmanızı şiddetle tavsiye ederim.

Bir kontrol listesiyle başlayın . (Bunun ilk adım olduğunu biliyordunuz, değil mi?)
Kontrol listesinin mevcut projenizle ilgili tüm standart belgeleri listelediğinden emin olun. yani. UML Şeması, fonksiyonel özellikler, yüksek seviye ve düşük seviye tasarımlar, vb ... İçimdeki sistem mühendisi bir RTVM (gereksinimler izlenebilirlik doğrulama matrisi) kullanmanızı önerecektir.

Üzerinde çalışmak için örnek bir program seçin. Bir tane bulamazsanız, google "kod katas" veya Google'ın zorluklarla ilgili codejam arşivine göz atın. Veya sadece bir hesap makinesi oluşturun. :-)

Örnek programınız için fonksiyonel özellikleri oluşturun. Daha sonra üst düzey tasarıma, UML diyagramına vb. Geçin. Dene. Spesifikasyonunuzda (mevcut çalışma uygulamalarınızla tanımlandığı gibi) önemli bir kusur bulduğunuzda, SDLC'nin o aşamasına geri dönmeniz ve tekrar ilerlemeden önce revize etmeniz gerekir.

İlk turunuz için devam edin ve küçük tutun. Süreç boyunca bisiklet sürmek, belirli bir aşamada aşırı kilodan daha önemlidir. Sonraki turlar için, bıraktığınız özellikleri ekleyin. İzleme, günlük kaydı, performans analizi, test-iskelesi, vb. Eklemek isteyeceğiniz şey işvereninizin gerçek işiniz için ne beklediğine bağlı olacaktır.

Tasarım / derleme / test / tekrarlama döngüsünü birkaç kez yineledikten sonra, sizi endişelendiren "ağır siklet" bileşenlerde beceri ve deneyim kazanacaksınız. Yinelemeler ayrıca çeşitli aşamalar ve oluşturulan belgeler arasındaki bağlantıyı da gösterecektir. Değerli ders, 5 dakikalık bir kod değişikliğinin, belge güncellemeleri ve test gereksinimleri nedeniyle başka bir yerde nasıl çok saatlik dalgalanma etkisine sahip olabileceğini gösteriyor.

"Ağır" uygulamalarla ilgili deneyim yalnızca gerçek olanı yapmaktan gelir. Etkili bir şekilde tek başına pratik yapmanın bir yolu yoktur. Bununla birlikte, çalışabilirsiniz. İnceleyebileceğiniz ve düşünebileceğiniz birçok vaka çalışması ve kaynak vardır.

Ancak gördüğünüz veya çalıştığınız tüm uygulamalar mutlaka olumlu değildir. Yazılım geliştirme akışkan bir şeydir ve bugün sert ve katı görünen şey yarın saçma ve gereksiz görünebilir. Bu, hem yeni araçlar hem de başlangıçlardan daha muhafazakar organizasyonlara kadar uzanan deneysel deneyimlerle olur.

Temel olarak, değişim ve risk yönetimi her kuruluş için benzersiz bir şekle sahip gibi görünmektedir. En iyi seçeneğiniz açık fikirli olmaktır, ancak takımdan takıma çok fazla varsayım taşımayın.