Çevik geliştirme

"Merhaba, Amigo!"

"Merhaba, Bilaabo!"

"Bugün size programların genellikle nasıl geliştirildiğini anlatacağım."

"20. yüzyılda, modern BT emekleme dönemindeyken, herkes programlamanın inşaat veya imalat gibi olduğunu düşünüyor gibiydi."

"İşler genellikle şöyle bir şeydi:"

" Müşteri, ihtiyaç duyduğu programın türünü, ne yapması gerektiğini ve nasıl yapması gerektiğini açıklayacaktır."

" İş analistleri onu dinler ve söylediklerine göre program gereksinimlerinin tam bir listesini çıkarırdı."

"Daha sonra proje yöneticileri bu gereksinimleri görevlere ayıracak ve ayrıca hangi programcının hangi görevi ve hangi sırayla yapacağını belirleyecekti."

"Ardından programcılar işe başlardı. Bazen birkaç yıl çalışırlardı(!)."

"Bittiklerinde, program testçilere verildi."

" Testçiler, uygulandıklarını ve programın olması gerektiği gibi çalıştığını doğrulamak için programın gereksinimlerinin her birini gözden geçireceklerdi."

"Bir şeyler ters giderse, testçiler hataları kaydeder ve programcılara gönderir."

"Ardından programcılar hataları düzeltir ve düzeltilen programı test edicilere geri gönderir. Ve döngü tekrar ederdi."

"Ana hatalar giderilince program müşteriye verildi."

"İşler gerçekten böyle mi gitti?"

"Tabii ki pek çok şeyi basitleştirdim ama bu, işlerin yapıldığı şekle oldukça yakın."

"Ve bir projenin tamamlanması gerçekten bir buçuk ila iki yıl sürebilir, öyle mi?"

"Bazen bir projenin gelişimi gerçekten uzunsa, onu ayrı sürümlere bölerlerdi. Her 3-6 ayda bir, geliştiricilerin programın işlevselliğinin belirli bir bölümünü oluşturması, test etmesi, tüm hatalarını düzeltmesi ve bunu geliştiricilere göstermesi gerekiyordu. müşteri."

"Birincisi, izlenimlerini paylaşabilmesi için. İkincisi ve daha da önemlisi, programın geliştirilmesi için ödeme yapmaya devam etmesi için."

"Ödemeye devam mı?"

"O zamanlar geliştirme genellikle planlanandan 2-3 kat daha uzun sürüyordu. Programcılara genellikle saatlik ödeme yapıldığı için program 2-3 kat daha pahalı hale geliyordu. Üstelik avantajlar da azalmıştı. Ne de olsa bugün müşterinin istediği şey 100.000$'a 3 yıl sonra ihtiyaç kalmayabilir - özellikle de üç katı fiyata."

"Müşteriler genellikle ödemeyi reddediyor muydu?"

"Evet. Daha sonra sözleşmeye cezalar eklemeye başladılar, ancak bu durumu iyileştirmedi. Yazılım geliştirme uzayıp gitti. Ve kimse istese de bu konuda bir şey yapamazdı."

"Ama neden?"

"Öncelikle, planlama aşamasında çok az şey biliniyor. Çoğu zaman, başlangıçta programcıların karşılaşacağı sorunları kimse tahmin edemezdi."

"Ama deneyimli programcılar her şeyi önceden görebilmeliydi, değil mi?"

"Programcılığın eşsiz bir meslek olduğunu görebiliyor musun?"

"Sıradan bir işçi sıklıkla aynı işi tekrar tekrar yapıyor. Saatçiler saat yapıyor, aşçılar yemek yapıyor, öğretmenler öğretiyor, doktorlar tedavi ediyor vs."

"Bu profesyonellerin her biri temelde her gün aynı şeyi yapıyor. Sonuç olarak, işlerinde gittikçe daha iyi olmaya başlıyorlar."

"Programlamada yaklaşım farklıdır. Bir programcı her gün aynı görevle karşılaştığında, bunu gerçekleştirmek için bir işlev, modül veya program yazar ve bir daha asla geri dönmez."

"Her programcı genellikle her görevi yaşamı boyunca bir kez çözer."

"Bir şeyler icat eden bilim adamları veya tasarım mühendisleri gibi bir şey."

"Ah. Pekala, bir projedeki en önemli rol nedir?"

"Hmm, buna nasıl cevap vereyim. Hangisinin en önemli olduğunu söylemek kolay ama en az önemli olanı belirlemek zor."

" Bir test uzmanının ( Kalite Güvencesi  , QA ) birincil işi,  bir programın durumunu izlemek ve hataları derhal bildirmektir. Bir test uzmanı hataları ne kadar çok ve erken bulursa, o kadar çok düzeltilebilir.  İyi bir test uzmanı, ürün kalitesini şundan daha fazla etkiler : iyi bir programcı yapar ."

"Programcılar neden kendi programlarını test edemiyorlar. Neyin işe yarayıp neyin yaramadığını testçilerden daha iyi bilmiyorlar mı?"

"İyi bir programcı, iyi bir test edici olamaz. Bir programcı, programın nasıl gerçekten iyi çalıştığını bilir, bu nedenle programı her zaman belirli bir şekilde kullanır. Programı istedikleri gibi kullanan sıradan kullanıcıların aksine. "

"Ayrıca, testçiler henüz çalışmayan şeyleri test etmezler. Testi yapan kişi, programcının zaten neredeyse kusursuz çalıştığını söylediği programın işlevselliğini veya bölümlerini test eder."

"Ve test uzmanı bu işlevsellikte tonlarca hata bulduğunda ve programcı bunları düzelttiğinde, ürün gerçekten mükemmelliğe yaklaşıyor."

" Bir programcının ( S oftware  Developer Engineer  ,  Developer ,  SDE ) birincil görevi, yeni işlevleri uygulamaktır. Veya daha basit bir ifadeyle, kendisine atanan görevleri yerine getirmektir . , onları gerçekleştirirler. Hatalar atandığında hataları düzeltirler."

"Ancak bazen daha zorlu görevler vardır, örneğin, program veya onun bölümleri için mimari oluşturmak. Önerilen mimari ne kadar iyiyse, gelecekte işleri halletmek o kadar kolay olacaktır."

"Sorun şu ki, mimarinin en baştan seçilmesi gerekiyor, ancak geliştirmenin ortasına gelene kadar doğru mimariyi seçip seçmediğiniz net değil."

"Ayrıca, eğer mimari başarılı olursa ve program harika olursa, müşteri muhtemelen onu programın yeni sürümleri için temel olarak kullanmak isteyecektir."

"İşte varmak istediğim şey."

"Hangi mimariyi seçerseniz seçin, her zaman mimarinin hesaba katmadığı bir dizi değişiklik, ekleme ve yeni özellik olacaktır."

"İşte iyi bir örnek."

"Bir müşteri sizden 5 katlı bir bina yapmanızı istiyor, siz de bir mimari tasarlıyor ve evi inşa ediyorsunuz."

"Ardından müşteri başka bir hikaye eklemek istiyor, sonra bir tane daha ve bu böyle devam ediyor."

"Ama birinci katın duvarları ve temel de bu kadar ağırlık için tasarlanmamıştı. Bu yüzden her şeyin yeniden yapılması gerekiyor."

"Ama 5 katlı bina bittikten sonra müşteri hemen 50 katlı bir bina istediğine karar verirse ne olur?"

"Mevcut yapıyı yıkmak ve her şeyi sıfırdan yeniden inşa etmek daha kolay olurdu..."

"Ama mimarlıkla ilgili sana bir tavsiyem var."

"Bir uygulamanın mimarisi her şeyden önce esnek olmalıdır, bu da uygulamanın yarısını yeniden yapmaya karar verirseniz sıfırdan başlamak zorunda kalmayacağınız anlamına gelir. Bu tür mimariye genellikle esnek ve modüler denir . "

" Proje yöneticisinin birincil işi karar vermektir. Proje yöneticisi büyük resmi gören ve bu bakış açısına göre kararlar veren kişidir."

"Geliştirme sırasında belirli bir görevin planlandığı gibi tamamlanmayacağının netleştiğini varsayalım. Proje yöneticisi daha sonra şunları yapabilir:"

" a)  görevi değiştirmek için müşteriyle görüşmeye çalışın"

" b)  göreve daha fazla zaman ayırın"

" c)  diğer projelerden daha deneyimli programcılar getirin."

"Ve başka birçok olasılık var."

"Her seçenek, bir şeyleri feda etmenizi gerektirir ve yöneticinin işi, bu fedakarlıklardan kaynaklanan toplam kayıpları en aza indirmektir. "

"Örneğin, rakiplerin lider programcıyı ona iki kat daha fazla para teklif ederek çaldığını varsayalım."

"Proje yöneticisi şunları yapabilir:"

" a)  hiçbir şey yapmayın. Programcı ayrılacak ve proje muhtemelen geride kalacak ve cezalara maruz kalacaktır."

" b)  maaşını ikiye katlayın. O zaman ekipteki herkes zam isteyecektir. Hepsine daha fazla para verirseniz, projenin maliyeti artacak ve proje kârsız hale gelebilir."

" c)  Aklınıza gelen başka bir seçenek."

"Anlıyorum."

"Kötü bir proje yöneticisi ile, iyi bir ekip genellikle bir projeyi uzatır, ancak her zaman değil."

"Ortalama programcılardan oluşan bir ekibe sahip iyi bir yönetici, bir projeyi neredeyse her zaman mükemmel programcılardan oluşan bir ekibe sahip kötü bir yöneticiden daha hızlı tamamlayacaktır."

"Anlıyorum."

"Tamam, biraz ara verelim, sonra devam ederiz."