Her bir yazılım şirketi yöneticisi yazılım projesinin çok hızlı geliştirilmesini ister. Çünkü yazılım şirketi için en değerli ve pahalı kaynak zamandır. Zamanı; kodların tekrar yazımı, güncellenmesi, toplantılar, fiziki etkinlikler için harcamak istemezsiniz. Değil mi? Ama harcanır...
Bir çok şirket büyür, yavaşlar ve ölür. Hayatta kalmak için iyi bir gelişme hızı gereklidir. Başka insanlara nazaran, kanıtlanmış ileri görüşe sahip olduğunuzu düşünün. Geliştirdiğiniz yazılımın altın vuruşa sahip bir ürün olacağından eminsiniz (Tamam, gerçek hayatta bu nadiren olur ancak hayal gücümüzü ateşlemek için böyle düşünelim). O halde tek ihtiyacınız ürünü tamamlamaktır.
Düzinelerce yetenekli ve tecrübeli geliştiriciden oluşan bir ekibiniz var, iki yıl içinde bir şeyler eziyor ve gönderiyorsunuz. Takım bezgin. Elinize vizyonunuzun %10'unu gerçekleştirmiş bir ürün var. Herkes inanılmaz bir potansiyel olduğunu söylüyor fakat pazara hakim olmak için %10 yeterli değil! Bir kaç ay daha mücadele ediyorsunuz, vaziyeti idare ediyorsunuz, satışlar vasat, paranız yok ve sonunda şirketin ömrü sona ermiş.
Büyük hayal küçük adımlarla tüketilmiş.
Kim suçlanacak?
Belkide problem çok zordu ve iki yıl ana çerçeveyi oluşturmak için makul bir süre idi. Ekip belki de konuya hakim olmadan aceleci davrandı, arada güzel ön sürümler çıkardı ve sonundan teknik karmaşa içinde boğuldu. Yazılım geliştirmede hız son derece karmaşık bir varoluştur. Çoğu zaman şaşırtıcı bir şekilde birçok şeyden etkilenir. Bu yazıda hızla ilgili düşüncelerimi paylaşmaya çalışacağım.
"Hızın iki türü"
Bir çok insan hızı tek başına bir varlık olarak düşünür ancak değildir! İki hız türü vardır: kısa süreli ani (sprint) ve uzun vadeli hız (maraton). Burada sprint ve maraton mükemmel kıyastır. Yazılım geliştirmede (koşu yarışında da) her ikisini de aynı anda yapamazsınız. Puan gibi soyut bir çaba birimi oluşturalım. Tüm ay nefes almadan sprinter çalışmanın karşılığı 100 puan olsun. İlk itirazım şudur:
Uzun süreli yazılım geliştirmede sprinter hızınızı asla sürdüremezsiniz! En fazla 6 ay 100 puan alabilirsiniz ancak bir yıl bu hızı sürdürmek mümkün olmaz.
Üstelik yüksek hızlı geliştirme ile geri tepme önemli derecede artar. Hatta bazı günler yaptığınız her işten pişmanlık duyarsınız.
Hatta bir müddet sonra yazılımcıların bir kısmı puana lanet eder noktaya ulaşır (kırmızı nokta) ve büyük düşüş yaşarlar. Amacınız ekibinizi kabul edilebilir hızda uzun mesafeli çalıştırabilmektir. Maratonun anlamı budur. Sabır ve huzura ihtiyaç duyarsınız. Zamanı değerli kullanarak nasıl yazılım geliştirebilirsiniz? Bu bir milyon dolar değerinde bir sorudur. Cevap her şirket için benzersizdir ancak yine de yararlı olabilecek makul bir taslak model oluşturabiliriz.
Sprint, Maraton ve ... mesafeler!
İlk bakışta sadece üç seçenek mevcut.
1. Seçenek : Sprint
Ekibini enerji içecekleri, şekerli besinler, kafein ile günde 12-14 saat çalıştırabilirsin. Yemek, uyku, yıkanma, spor gibi faaliyetlere çok az zaman ayırırsınız. En erken bir en çokta üç ay sonra çalışan herkes kendisini çok kötü hissedecektir. Bu hızlı tükenmişliktir.
'Kenar notu: Bu hızda çalışan birisini tanıyorum! Çok şey öğrendi ve müthiş beceriler kazandı ancak bedeli büyük oldu. Büyük olasılıkla şuan yaşadığı sağlık sorunları aşırı hızlı çalışma nedeniyledir. Aşırı deneyim sahibi olmak için sağlığını hiçe saymak iyi bir fikir midir? Bence değildir.'
2. Seçenek : Ilımlı sprint
Verimliliğin her damlasını biriktirerek günde 8-10 saat çalışabilirsiniz. İş yerinde kısa sohbetler yok, spor faaliyetleri yapılamaz, bu hiç eğlenceli değil! Bazı şirketler işi ilginç, ilgi çekici, eğlenceli hale getirecek hiç bir şey yapmazlar. Herkes baskı altındadır ve işler sürekli gecikir. Bu maalesef çok uzun süre böyle devam edebilir. İnsanlar bu durumu özümseyebilir ve ne kadar berbat durumda olduklarını fark etmezler. Bu durumun verdiği zararı hobileri veya aile bireyleriyle telafi etmeye çalışırlar. Bu ciddi bir tehlikedir. Bir kaç ay sonra iş verimliliği düşer ve kimse farkına varmaz. Durumunuz hakkında kapsamlı analiz ve fikir sahibi olmanız bir kaç yılınızı alabilir.
3. Seçenek : Maraton
Bu yöntem çok iyi görünüyor. Günde en fazla 6-8 saat çalışma ve rahatlamak için egzersiz yapmak. Her saniye çözmek zorunda olduğunuz problem hakkında düşünme lüksüne sahip değilsiniz. Sorunları kapı dışarı etmek için aceleci olmayın. Kulağa hoş geliyor. Ancak bir çok yönetici maraton hızından memnun olmaz. İşlerin hemen bitmesini arzu eder. Bu maraton seçeneğinin nadir uygulandığına inanıyorum.
Bir çok şirket yöneticisi aptalca yol olan "bizler kahramanız" övgüsüyle çalışanlara iş yükler ve işlerin hızlanacağını zanneder.
Bunlardan başka bir şey yok gibi görünüyor. Gerçeği söylemek gerekirse daha önce duyulmadık bir yöntem.
4. Seçenek : Aralıklı çalışma
Tekrarlamalı geliştirmeden bahsetmiyorum. Aslında dengeli olarak sprint ve maraton çalışma yöntemlerinin uygulanmasını kast ediyorum. Yani karışık yöntemle çalışmak. Kısa süreli sprint ardından maraton koşusu.
Bana göre bu yöntemin tarifi şöyle olabilir;
1 ay sprint
3 ay maraton
1 ay sprint
...
Sprint yani yüksek hızda çalışma yöntemini açıklayalım. Bu yöntemde takım (veya tüm şirket) esas iş haricindeki tüm işleri bir kenara bırakır. Geleceğe yönelik toplantılar, eğitimler, İK faaliyetleri ve benzeri. Tüm ekip enerjisini değer üretmeye harcar: kod yazma, test, belgelendirme ve müşteriye ulaştırma. Yüksek hızda çalışma, rahatlama haftasına geçilerek tamamlanır. Rahatlama haftasında yapılan işler gözden geçirilir. Geleceğe yönelik fikir alışverişi yapılır.
Bu yöntemin faydası açıktır. Ortalama hız maratondan daha verimlidir. Bir sonraki sprint hoşgörülü maraton döneminden sonra daha makul atlatılacaktır. Ayrıca ekip geçen hızlı dönemde yaptıkları hataları düzeltmede daha verimli çalışacaktır. Ekibe hata bildirdiğinizde içiniz daha rahat olacaktır. Bu uyuşturucu etkisi yapar. Belki de bu yüzden insanlar bir süre aşırı hızda çalışabilirler.
"Yazılım geliştirme hız modeli"
Haydi genel görünümden başlayalım. Sizi biraz korkutacağım. Resim kesinlikle korkunç görünüyor fakat benimle kalın her birini açıklayacağım. Açıklama sonunda benzer sorunları analiz etmek için elinizde güçlü bir aracınız olacak.
Şema yazılım geliştirme hızını düşüren etki ve faaliyetleri gösteriyor. Yeşil geliştirme hızının arttığına işaret ediyor, ne kadar çoksa o kadar iyi. Sarılar ise daha iyilerinin yapılması gerektiğine işaret eder. Örneğin hızı artırmak için teknik borç (*) biriktirebilirsiniz ancak ilerde bu borçları ödemeniz gerektiğinde çok daha fazla yavaşlarsınız. Kırmızılar ise geliştirmeyi yavaşlatan etkileri gösterir, ne kadar az ise o kadar iyidir. Yeşil oklar ise hızlandırıcı etkileri gösterir. Örneğin tüm dikkati bir noktada toplayarak yazılım geliştirmek.
devamı https://www.targetprocess.com/articles/speed-in-software-development/
'(*) Teknik borç, kısa vadede uygulanması kolay kodun en iyi genel çözümü uygulamak yerine kullanıldığı durumlarda ortaya çıkan ekstra geliştirme çalışmalarını yansıtan programlamadaki bir kavramdır.'