- Mühendislik ekipleri sık sık "daha fazla özelliği daha hızlı yayımlama" baskısı altında kalır
- Ancak aynı anda çok fazla iş yürütmek üretkenliği tersine düşürür
- "Daha fazla yayımlamanın sırrı aslında daha az yapmaktır" -
Less is More
Temel ilkeler
- Tüm işleri görünür kılın
- İşi küçük parçalara ayırarak tanımlayın
- Devam eden işleri sınırlayın
- Kaynakları kapasiteye göre tahsis edin
- Bonus: Beklenmeyen durumlar için boşluk bırakın
# Tüm işleri görünür kılın
- İşleri görünür kılmak gerçeği net biçimde görmeyi sağlar
- Tüm işler tek bakışta görüldüğünde şu avantajlar ortaya çıkar
- Öncelikler net biçimde belirlenebilir
- Gereksiz işler durdurulabilir veya geçici olarak askıya alınabilir
- Ekip, başlattığı işleri tamamlamaya odaklanabilir
- Amaç tüm işleri sonsuza kadar izlemek değildir → durumu net anlamak ve daha iyi kararlar alabilmek içindir
# İşi küçük parçalara ayırarak tanımlayın
- İş çok büyük olduğunda ekibin enerjisi tükenir ve ilerleme net görünmez
- İş parçalarını yaklaşık 1-2 hafta ile sınırlandırın
- Geliştiriciler kısa vadeli sonuçlarla motivasyonlarını korur
- Hızlı geri bildirim alınıp düzeltme yapılabilir
- Küçük iş parçalarının avantajları
- Kod incelemesi kolaylaşır
- Doğal bilgi paylaşımı sağlanır
- Ekip üyeleri arasındaki iş birliği güçlenir
- Dağıtım riski azalır
- İş parçalarını küçültmek hızı artırır → karmaşık özellikler karşısında bunalmadan ivme korunabilir
# Devam eden işleri sınırlayın
- Birden fazla özelliği aynı anda ele almak üretkenliği düşürür
- Bağlam değiştirme maliyeti ortaya çıkar → yeni bir işe uyum sağlamak 23 dakikaya kadar sürebilir
- Devam eden iş arttıkça şu sorunlar ortaya çıkar
- Kalite düşer
- Hata sayısı artar
- Ekip morali bozulur
- Ekip düzeyinde aşırı yük sinyalleri
- Geliştirici başına 4'ten fazla iş yürütülmesi
- Tamamlama süresinin tahminden uzun sürmesi
- Tamamlanan özelliklerden daha fazla sayıda devam eden özellik bulunması
- Bireysel düzeyde aşırı yük sinyalleri
- Odak kaybı
- Kod inceleme yanıt süresinin uzaması
- Durum toplantılarında öncelikleri açıklamanın zorlaşması
# Kaynakları kapasiteye göre tahsis edin
- "Bir geliştirici bir özelliği üstlenir" yaklaşımı verimsizdir
- Ekibin kaynaklarını en önemli işlere yoğunlaştırın
- İş birliği güçlenir → sorun çözme hızı artar
- Kod kalitesi artar → gerçek zamanlı akran incelemesi teşvik edilir
- İşlerin tamamlanma hızı yükselir
- Geliştiriciler iş birliği yoluyla daha derin bir anlayış kazanabilir
- Ekip düzeyindeki çıktılar teşvik edilmelidir → bireysel performanstan çok ekip performansına odaklanın
# Boşluk bırakın
- %100 kapasiteyle çalışmak performansı tersine düşürür
- Beklenmeyen işler kaçınılmazdır → sadece ne zaman ortaya çıkacakları bilinmez
- Boşluk olmadığında ortaya çıkan sorunlar
- Ekip reaktif biçimde çalışmaya başlar
- Kalite düşer
- Yenilik azalır
- Teknik borç artar
- Boşluk olduğunda şu avantajlar elde edilir
- Beklenmeyen sorunlara esnek şekilde yanıt verilebilir
- Yaratıcı problem çözme mümkün olur
- Yüksek kalite korunur
- Sürdürülebilir çalışma temposu korunur
- Uygun boşluk oranı yaklaşık %20'dir → ekip özelliklerine göre ayarlanabilir
Temel stratejilerin özeti
- İşleri görünür kılın → durumu net görebilmek için
- İşi küçük parçalara ayırarak tanımlayın → ivmeyi koruyun
- Devam eden işleri sınırlayın → odağı artırın
- Kaynakları kapasiteye göre tahsis edin → önceliklere göre yoğunlaşın
- Boşluk bırakın → esneklik kazanın
Sonuç
- Daha fazla iş başarmak için daha az yapma stratejisine ihtiyaç vardır
- Ekip performansı, aynı anda kaç özelliğin yürütüldüğüyle değil, müşteriye ne kadar etkili biçimde değer sunulduğuyla ölçülmelidir
- Liderin rolü ekibe daha fazla iş eklemek değil, gereksiz işleri ortadan kaldırmaktır
12 yorum
GeekNews'te birkaç kez bahsi geçen <Phoenix Project> kitabında da benzer bir hikâye geçiyor. Kapasite %100'e yaklaştıkça yanıt süresinin geometrik olarak uzadığı söyleniyor.
Ah. Bu konu
Goaladlı kitapta da geçiyor!Çünkü
<The Phoenix Project>kitabının kendisi de<The Goal>un BT versiyonu olarak yazılmış bir kitap.Vay be........ teşekkürler!!
İşlerin %80’i ve %20’lik bir esneklik alanı bırakmaya çalışıyorum ama bunu hangi kritere göre yapmam gerektiği konusunda her seferinde düşünüyorum. Bunu sadece zamana göre mi belirlemeliyim diye de aklımdan geçiyor.
Bu yüzden cuma öğleden sonralarını tamamen kişisel geliştirme zamanı olarak ayırıyorum!
Bu kadar küçük görevlere bölündüğünde, büyük resmi elinde tutan lider çok fazla yetki sahibi oluyor. Birlikte çalışan mühendisler ise tam tersine motivasyon kaybı yaşıyor ve "Biz tam olarak nereye gidiyoruz?" noktasına geliyor. Sprint tabanlı agile'ın en tipik dezavantajlarından biri bu.
Bence yazı fazla liderin bakış açısından yazılmış; başlıkta dendiği gibi.
Mühendislerin momentumu, liderin bayrağı hangi yöne tuttuğundan da büyük ölçüde etkilenir. Müşteriye verilmek istenen değerin ne olduğu, her sprintteki
outputile teslim edilenoutcomeun ne olduğunun nasıl ortaya konabileceği konusunda da biraz daha düşünmek gerekiyor gibi görünüyor. Elbette bunlar zor soft skill'ler; bu yüzden gerçekten iyi yapan lider görmek de zor, bu konuda yazı da pek yok.Bu yoruma güçlü biçimde katılıyorum. Teknik konularda mikro yönetim ortaya çıkma riski vardı. Gerçekten hiç kolay değil.
Büyük resmi paylaşmak ve herkesin anladığından emin olduktan sonra işi küçük görevlere bölmek gerekmiyor mu??
1-2 haftaya bölündüğünde, doğal olarak tek bir özelliğe dair genel resmi yalnızca sınırlı sayıda kişinin bileceğini düşünüyorum. Tıpkı process ve thread arasındaki fark gibi. Yani ilgiyi sınırlayarak üretkenliği artırmak söz konusu.
Genel resim paylaşılsa bile, insanların bu resim hakkında soru işaretleri taşıyacağı varsayımı var; ama sanırım ben de doğal olarak, her sprint planlamasında biraz biraz değişen yön doğrultusunda o büyük resmin nasıl takip edildiğini yakalayamama varsayımını yapmışım.
Bu yazıda ortaya konanlara tamamen katılıyorum; aynı zamanda bahsettiğiniz soruna da katılıyorum,
hatta bu, benim de gerçekten kafa yorduğum noktalardan biri.
Squad’a göre değişiyordu ama ekip üyelerini sprint planning’e aktif biçimde dahil ettiğimizde bahsettiğiniz sorun ortaya çıkmıyordu. Projenin bağlamını paylaşıp her sprintte değişen durumu aktararak değişen işleri yeterince fark edebilir hale getirmeye çalışırken, bir yandan da işleri oldukça ayrıntılı parçalara bölmeyi talep ettim.
Dediğiniz gibi, yönetim açısından ilerleme durumu, iş hızı ölçümü, beklenmedik durumlara karşı yanıt verme, işin içeriği niyet edildiği gibi gitmediğinde ortaya çıkan fırsat maliyeti düşünüldüğünde, işleri küçük parçalara ayırmak sonuçta gerçekten daha iyi ilerlemeyi sağlıyordu.
Benzer yazılar tekrar tekrar gündeme geliyor ama insanın hırsının sonu yok, aynı hataları da durmadan tekrarlıyoruz
Bir bilgisayarın CPU yükünün %100 olması normal değil,
ama konu insanların iş yükü olunca %100'ün daha çok çalışmaları gerektiği sonucuna varılıyor..