Çoğu yöneticiye "psikolojik güvenlik" veya "vizyon" hakkında soru sorarsanız (devamını oku: Psikolojik güvenlik) çevik yazılım geliştirme ekiplerinin yöneticileri, bunların önemli olduğu konusunda hemfikirdirler, ancak... Müşteri aciliyet sinyali verdiğinde veya son teslim tarihi yaklaştığında, tüm bu "daha yumuşak" değişkenler genellikle arka plana atılır. Yöneticiler öncelikle çevik ekiplerinin öngörülebilir bir şekilde işleyen çevik teslimat akışıyla ilgilenirler.

Eğer Echometer blogumuza bir göz atarsanız (blogumuza), içeriğimizin ekiplerin ve kuruluşların sosyal becerilerini geliştirmeye odaklanma eğiliminde olduğunu biliyorsunuz. Bunlar genellikle karar vericiler tarafından hafife alınır. Ancak Scrum Masters ve Agile koçları tarafından değil.

Yine Scrum Ustaları ve Agile koçlarının hafife aldığını düşündüğüm şey, – temelde yöneticilerin istediği teslimat akışını iyileştirmeye odaklanmaktır. Bugünkü yazımda, tekrar tekrar zamanında ve bütçeye uygun teslimat yapma olasılığını önemli ölçüde artıracak basit bir teknik anlatıyorum.

Agile Teslimat Akışınızla ilgili ilk adım

Görevlerinizin Agile teslimat akışını izlemekten bahsediyorum. Sadece birkaç şeyi doğru yaparsanız, çok daha öngörülebilir sonuçlar elde edebilirsiniz. Döngü süresi dağılım grafikleriniz veya proje tahminlerini hesaplamak için kullandığınız Monte Carlo simülasyonunuz bile sonunda tamamen yanlış olmak yerine geçerli tahminlere işaret edebilir (daha fazlasını okuyun: 9 Agile Karar vericiler için metrikler).

Mücadele edilmesi gereken ilk belirti, "Planlandı "dan "Tamamlandı "ya sadece birkaç gün süren görevler ve bir aydan fazla süren görevler olmasıdır. Bunu önlemek için, bir görevin her zaman istenen özelliğin mümkün olan en küçük teslim edilebilir sürümünü içerdiğinden emin olmalısınız. Müşterinin temel talebi için gerekli olmayan ziller ve ıslıklar olmadan. Temel olarak bir MVT, Minimum Uygulanabilir Görev. Bu, her görevi küçük yapacağı anlamına gelmez. Ancak görevlerin aylar yerine en fazla birkaç hafta sürdüğü bir aşamaya ulaşmanıza yardımcı olmalıdır.

Agile Teslimat Akışınızla ilgili ikinci adım: Hız yerine WIP

Birçok Scrum Ustası veya Kanban koçu, hızın vb. geçerli bir ölçümünün, tüm iş öğelerinin yaklaşık olarak aynı boyuta sahip olduğu görevlerin veya iş öğelerinin "doğru boyutlandırılmasına" bağlı olduğuna inanmaktadır. Ancak o zaman (hızı ölçmek için gerekli olan) hikaye noktaları, karşılaştırılabilir bir zaman birimi gibi göründükleri için hızı ölçmek için yararlı olurlar. 

Ancak bu yanlıştır: görevlerin benzer boyutta olması bile gerekmez. Bunu varsaymamalısınız, çünkü Story Point tahminlerini kontrol etmek çok zordur. Kontrol edebileceğiniz tek şey kaç tane yeni görev başlattığınızdır.

Öngörülebilir olmak için aşağıdakileri yapın: "Tamamlanan görevler" oranına kıyasla "başlatılan yeni görevler" oranını izleyin. Bu ikisi dengede olmalıdır. Başka bir deyişle, görevlerin "giriş" ve "çıkış" oranları mümkün olduğunca yakın, hatta ideal olarak aynı olmalıdır.

Bir örnek: Yazılım geliştirme ekiplerindeki tipik davranış, bir görev engellenir engellenmez yeni bir iş öğesinin başlatılmasıdır. Bu durum birçok görevin açık ancak tamamlanmamış olmasına yol açar ve bu da hepsinin engelini kaldırmayı çok daha karmaşık hale getirir. 

Bunun yerine, başladığınız her görev için tamamlanmış bir görev de olduğundan emin olursanız, Günlük'teki az sayıda odaklanmış görevin engelini daha iyi kaldırabilirsiniz. Genel performansınız daha öngörülebilir olacak ve ekibiniz daha mutlu olacak çünkü yöneticiniz ve müşterileriniz daha mutlu olacak.

Sağlıklı bir çevik Agile teslimat akışının bazı "olumlu belirtileri"

Uygulamada bu durum aşağıdaki davranışlara yol açacaktır:

• • Hâlâ devam eden birçok iş varken yeni görevlere başlamayız. 

• • Yeni şeylere başlamadan önce başladığımız işi bitirmeye odaklanıyoruz.

• • Görevlerin yaşı hiçbir zaman birkaç haftayı geçmez.

• • İyi bir neden yoksa, her zaman en eski görev üzerinde çalışırız.

WIP (devam eden iş) sınırları da bu konuda yardımcı olur, ancak genellikle yeterli değildir. Ekip, yeni görevlere başlamak yerine görevleri bitirmeye odaklanmayı öğrendiğinde, çoğu ekipten daha iyi olacaksınız.

Agile Teslimat Akışını doğru kullanırsanız

Net beklentiler yaratmak için: Bu şekilde bir görevin iki ya da üç gün sürüp sürmeyeceğini kontrol edemezsiniz. Ancak en azından ekibinizin 2-3 günlük görevlerin bir ay sürmesine neden olacak kadar çok görev üzerinde çalışmadığından emin olursunuz.

Temelde tüm teslimat yükümlülüklerinin birkaç hafta içinde yerine getirileceğini bilseydiniz ekibiniz ne kadar daha iyi olurdu? Elbette bu, yukarıda bahsedilen her şeyi uyguladığınızı varsayar: MVT'lerin belirlenmesi, katı bir WIP limiti ve başka bir görev tamamlanana kadar görevleri yeniden başlatmama taahhüdü.

Adım 3: Agile teslimat akışını iyileştirmeye başlayın

Teorik olarak ne yapacağınızı biliyorsunuz. Şimdi pratik olarak başlamanın en iyi yolu nedir? Ekipte farkındalık ve "değişime hazır olma durumu" yaratarak. En iyi durumda, kendini yansıtma yoluyla.

Bu sayılar konusunda şeffaf olmanız ve başlatılan ve tamamlanan görevler arasındaki oranın dengede olup olmadığını görmek için bunları düzenli olarak kontrol etmeniz gerekir. Biraz daha derine inmek ve son döngüde rakamların neden dengede olmadığını düşünmek retrospektifinizin bir parçası olabilir. 

Bahsettiğim davranışları çevik retrospektif aracımız Echometer ile retrospektifinizde tartışmanızı tavsiye edebilirim (daha fazlasını okuyun: 7 Karşılaştırmalı Geriye Dönük Araçlar). Hatta bu soruları düzenli olarak sorarak farkındalığı artırmak için bunu çalışma anlaşmalarınızın veya düzenli Health Check'lerinizin bir parçası haline getirebilirsiniz.

Aşağıdaki sorular "çevik teslimat" için geriye dönük şablonumuzdur (devamını okuyun: Çevik retrospektifler için 22 eğlenceli şablon). Birkaç Health Check ifadesiyle başlıyoruz ve ekibe katılma ya da katılmama eğiliminde olup olmadıklarını soruyoruz. Bundan sonra, birkaç açık soru var: