Şüphesiz, yazılımın geliştirilmesi talep ediyor. Birçok proje, aksaklıksız çalışmaz veya beklenen sonuçları almaz. Bunun nedeni genellikle sektördeki hızlı tempo ve küçük dönemden bahsedilmektedir. Çok az deneyim var. Deneyim varsa, genellikle eskidirler. Gerçekten doğru mu?
Somut bir örnek alalım: bir proje geç kaldı ve yakında bir sonuç vermek zorunda kalacak. Ne yapalım? İş birkaç omuz üzerine dağıtılabilir. Projeye daha fazla geliştirici ekleyebilirsiniz. Daha fazla geliştirici projeyi daha hızlı hale getirecek. Sonuçta, daha fazla kod yazabilirsiniz. Bu doğru karardır. Bir ressam bir duvarı ortadan kaldırırsa ve başka bir ressam ona yardımcı olursa, çok daha hızlı bitirmiş olurdu. Yazılımla neden farklı olmalı?
Ne yazık ki, yazılımın geliştirilmesi, daha fazla geliştiricinin bir projeyi hızlandırdığı uygulanmaz. Zaten 1975'te Fred Brooks, geçici bir açığı olan projelerin yeni geliştiriciler tarafından daha da ertelenen “Efsanevi Man ayı” kitabında desteklendi. Yeni ekip üyeleri dahil edilmelidir. Bu, projede uzun zamandır olan geliştiricileri bağlar. Artık projenin başarısına katkıda bulunamazsınız. Yeni geliştiriciler bile yardımcı olamaz. Dolayısıyla verimlilik azalır ve sorunlar daha ciddi hale gelir.
Bu bilgiyi 1975'ten beri, yani 40 yıldır aldık. Proje, yeni IBM ana çerçeveleri için yazılımın geliştirilmesine yol açıyor. Boyut sadece ayın inişiyle karşılaştırılabilir ve hala IBM'e rekabet avantajı sunuyor. Bu deneyime rağmen, projelere bir gecikmeye ulaşmak için hala birden fazla geliştirici sağlanmıştır, çünkü bu prosedür mantıklı görünmektedir.
Şelale modelinin ilk eleştirilerini ihmal etti
Başka bir örnek: Şelale modeli hala yazılım geliştirme için kullanılmaktadır. Farklı aşamalara ve ayrıntılı planlamaya bölünme, yazılımı etkili bir şekilde geliştirmek için makul bir yaklaşıma sahip gibi görünmektedir. Royce belgesi 1970'den beri var olmuştur. Cascade sürecini eleştiriyor ve çeşitli iyileştirmelere sahip. Bu birkaç nedenden dolayı dikkat çekicidir: sistemlerin karmaşıklığı bugünün zamanında çok daha düşüktü. Dolayısıyla projeler de daha iyi yönetilebilir ve öngörülebilir olmalıdır.
Royce'un çalışmalarının odak noktası uzay yolculuğu sistemleri idi. Bu sektörde, özellikle, kaskad modeline göre büyük bir planlama yararlı olmalıdır, çünkü gereksinim açık olmalı ve güvenlik gereksinimleri ayrıntılı planlama ve incelemeler talep etmelidir. Bir şeyleri kötüleştirmek için, belge uzun zamandır şelale modelinin kökeni olarak kabul edildi, gerçekte bir eleştiri olsa bile. Bu tür efsaneler, “yazılım geliştirmenin cömertleri” kitabında ortaya çıkıyor.
İlerlemeye ulaşmak için, “insanın efsanevi ayından” veya Royce belgesinden, sezgisel olmasalar bile uzun zamandır bilinmektedir. Ne işe yaradığına tutarlı olan, profesyonel bir yaklaşımın işaretidir. Sorun sektörümüzün hızlı temposu değil, çünkü her iki kaynak da 40 yaşın üzerindedir.
TL; Dr.
Yazılım geliştirme sorunu hızlı bir hız değildir, ancak bazı bağlantıların sadece sezgisel olmadığı ve uzun zaman sonra bile temel bilgi gözlemlenmemesidir.
()
Somut bir örnek alalım: bir proje geç kaldı ve yakında bir sonuç vermek zorunda kalacak. Ne yapalım? İş birkaç omuz üzerine dağıtılabilir. Projeye daha fazla geliştirici ekleyebilirsiniz. Daha fazla geliştirici projeyi daha hızlı hale getirecek. Sonuçta, daha fazla kod yazabilirsiniz. Bu doğru karardır. Bir ressam bir duvarı ortadan kaldırırsa ve başka bir ressam ona yardımcı olursa, çok daha hızlı bitirmiş olurdu. Yazılımla neden farklı olmalı?
Ne yazık ki, yazılımın geliştirilmesi, daha fazla geliştiricinin bir projeyi hızlandırdığı uygulanmaz. Zaten 1975'te Fred Brooks, geçici bir açığı olan projelerin yeni geliştiriciler tarafından daha da ertelenen “Efsanevi Man ayı” kitabında desteklendi. Yeni ekip üyeleri dahil edilmelidir. Bu, projede uzun zamandır olan geliştiricileri bağlar. Artık projenin başarısına katkıda bulunamazsınız. Yeni geliştiriciler bile yardımcı olamaz. Dolayısıyla verimlilik azalır ve sorunlar daha ciddi hale gelir.
Bu bilgiyi 1975'ten beri, yani 40 yıldır aldık. Proje, yeni IBM ana çerçeveleri için yazılımın geliştirilmesine yol açıyor. Boyut sadece ayın inişiyle karşılaştırılabilir ve hala IBM'e rekabet avantajı sunuyor. Bu deneyime rağmen, projelere bir gecikmeye ulaşmak için hala birden fazla geliştirici sağlanmıştır, çünkü bu prosedür mantıklı görünmektedir.
Şelale modelinin ilk eleştirilerini ihmal etti
Başka bir örnek: Şelale modeli hala yazılım geliştirme için kullanılmaktadır. Farklı aşamalara ve ayrıntılı planlamaya bölünme, yazılımı etkili bir şekilde geliştirmek için makul bir yaklaşıma sahip gibi görünmektedir. Royce belgesi 1970'den beri var olmuştur. Cascade sürecini eleştiriyor ve çeşitli iyileştirmelere sahip. Bu birkaç nedenden dolayı dikkat çekicidir: sistemlerin karmaşıklığı bugünün zamanında çok daha düşüktü. Dolayısıyla projeler de daha iyi yönetilebilir ve öngörülebilir olmalıdır.
Royce'un çalışmalarının odak noktası uzay yolculuğu sistemleri idi. Bu sektörde, özellikle, kaskad modeline göre büyük bir planlama yararlı olmalıdır, çünkü gereksinim açık olmalı ve güvenlik gereksinimleri ayrıntılı planlama ve incelemeler talep etmelidir. Bir şeyleri kötüleştirmek için, belge uzun zamandır şelale modelinin kökeni olarak kabul edildi, gerçekte bir eleştiri olsa bile. Bu tür efsaneler, “yazılım geliştirmenin cömertleri” kitabında ortaya çıkıyor.
İlerlemeye ulaşmak için, “insanın efsanevi ayından” veya Royce belgesinden, sezgisel olmasalar bile uzun zamandır bilinmektedir. Ne işe yaradığına tutarlı olan, profesyonel bir yaklaşımın işaretidir. Sorun sektörümüzün hızlı temposu değil, çünkü her iki kaynak da 40 yaşın üzerindedir.
TL; Dr.
Yazılım geliştirme sorunu hızlı bir hız değildir, ancak bazı bağlantıların sadece sezgisel olmadığı ve uzun zaman sonra bile temel bilgi gözlemlenmemesidir.
()