Agile Teslimat Akışı: 3 adımda her zaman zamanında teslimat

Çoğu yöneticiye çevik yazılım geliştirme ekiplerinin “psikolojik güvenliği” veya “vizyonu” sorulduğunda (daha fazlası için: Psikolojik güvenlik ) çevik yazılım geliştirme ekiplerinin “psikolojik güvenliği” veya “vizyonu” sorulduğunda, bu şeylerin önemli olduğu konusunda hemfikirler, ancak… Müşteri aciliyet sinyali verdiğinde veya son teslim tarihi yaklaştığında, bu “daha yumuşak” değişkenlerin tümü tipik olarak geri plana atılır. Yöneticiler öncelikle çevik ekiplerinin öngörülebilir şekilde işleyen çevik teslimat akışıyla ilgilenirler.

Eğer Echometer blogumuza bir göz atarsanız ( blogumuza ) göz attıysanız, içeriğimizin daha çok ekiplerin ve kuruluşların “sosyal becerilerini” geliştirmeye odaklandığını bilirsiniz. Bunlar genellikle karar vericiler tarafından hafife alınır. Ancak Scrum Master’ları ve Agile Koçları tarafından değil.

Bana göre Scrum Master’ları ve Agile Koçları’nın hafife aldığı şey ise, teslimat akışını iyileştirmeye odaklanmak - temelde yöneticilerin istediği şey. Bugünkü yazımda, tekrar tekrar zamanında ve bütçeye uygun teslimat yapma olasılığını önemli ölçüde artırmak için basit bir teknik açıklayacağım.

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 Master veya Kanban Koçu, Velocity vb.‘nin geçerli bir şekilde ölçülmesi için, tüm iş kalemlerinin yaklaşık olarak aynı boyutta olduğu görevlerin veya iş kalemlerinin “doğru boyutlandırılması”nın önemli olduğuna inanır. Sadece o zaman Hikaye Puanları (Velocity’yi ölçmek için gereken) Velocity’yi ölçmek için kullanılabilir, çünkü daha çok karşılaştırılabilir bir zaman birimi gibi görünürler. 

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.

Bu nedenle, öngörülebilir olmak için şunları yapın: “Yeni başlanan görevler” oranını “tamamlanan görevler” oranıyla karşılaştırarak izleyin. Bu ikisi dengede olmalıdır. Başka bir deyişle, görevlerin “giriş” ve “çıkış oranı” mümkün olduğunca birbirine yakın olmalı, ideal olarak hatta 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şlanan her görev için tamamlanan bir görev olduğundan emin olursanız, Daily’de odaklanılan birkaç görevin engelini kaldırmak daha iyi olacaktır. Performansınız genel olarak daha hesaplanabilir hale gelecektir - ve amiriniz ve müşterileriniz daha memnun olduğu için ekip daha mutlu olacaktır.

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

Teoride ne yapmanız gerektiğini biliyorsunuz. Peki pratikte başlamanın en iyi yolu nedir? Ekipte farkındalık ve “değişime açıklık” yaratarak. En iyi durumda öz-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 retrospektif şablonumuzdur (daha fazlası için: Çevik retrospektifler için 26 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:

Agile Teslimat Geçmişe Dönük

Health Check Öğeleri

Çalışma şeklimiz ne zaman optimal olmayan bir iş akışına yol açtı? (örn. net olmayan, uygunsuz veya takip edilmeyen kılavuzlar)

Tahmin edebileceğiniz gibi, Sağlık Kontrolü’nün son noktası (nedeni kontrol etme) zaten potansiyel bir önlemi, size yardımcı olup olmadığını görmek için bir veya iki çevik sprint için deneyebileceğiniz bir şeyi ima ediyor: “Devam Eden İş” durumundaki görevlerin sayısını sınırlamak.

Temelin atılması: Ekip çalışması için anlaşmalar yapın

Ekibinizin bu tür bir yansımaya henüz hazır olmadığını mı düşünüyorsunuz? Bu durumda, öncelikle genel olarak “iyi iş” hakkında düşünmeli ve ardından bazı temel kurallar, yani Çalışma Anlaşmaları belirlemelisiniz. Aşağıdaki atölye şablonu size bu konuda yardımcı olabilir. Bunu bir projenin başında özel bir retrospektif biçimi olarak veya ek bir atölye olarak gerçekleştirebilirsiniz.

Öncelikle ekibinizin örtük olarak ne kadar hemfikir olduğunu anlamalısınız - bunun için Sağlık Kontrolü Öğesine bakın. Ardından, bunu birkaç açık uçlu soruyla pratik olarak kontrol etmelisiniz. Her ekip üyesi cümleyi (diğer sorulara bakın) aklına gelen mümkün olduğunca çok cevapla bitirmelidir:

Takım Taahhütleri Geçmişe Dönük

Health Check Öğeleri

Çatışmalarla başa çıkma: ‘Ekibimizde bir çatışmanın ortaya çıktığını fark edersem, o zaman …’

Cevapları topladıktan sonra, elbette kalıpları bulmaya çalışmalı ve gelecekte nasıl birlikte çalışmak istediğinize dair somut anlaşmalar üzerinde anlaşmalısınız - en azından geçici olarak bir deney olarak.

İlginç, yaratıcı bir alternatif

Bu retrospektif yöntemleri size “çok kuru” geliyorsa, ekibinizin çıktısının kalitesini yansıtmaya odaklanan başka bir retrospektif yöntemi daha var ( Eğlenceli 54 Geriye Dönük Yöntemlere buradan ulaşabilirsiniz ): ‘Üç Küçük Domuz’ Retrospektifi. Farklı malzemelerden evler inşa eden üç küçük domuzun masalına dayanan, performansınızı yansıtmaya ve geliştirmeye başlamak için basit bir alternatiftir.

Sonuç - Çevik Teslimat Akışı

Nasıl başlarsanız başlayın, en önemli şey ilk etapta başlamaktır. Agile teslimat akışını aktif bir şekilde takip eden ekipler daha iyi ekiplerdir.

Bu arada, burada bulacağınız fikirlerin çoğu, şiddetle tavsiye edebileceğim “Agile Bites” podcast’inde de iyi bir şekilde özetlenmiştir (Podcast’e git: Agile Isırıkları). 

Ekibinizi geliştirirken iyi eğlenceler!