Not Defterim: Agile Proje Yönetimi

Photo by Patrick Perkins on Unsplash

Çok uzak değil belki son çeyrek asırdır proje denildiğinde tanım olarak , baştan sona planlanan ve bu planlara sıkı sıkıya bağlı kalınan bir dizi süreç aklımıza gelirdi. Yazımızın konusu bu değil tabii ki ama karşılaştırma amacıyla Waterfall (Şelale Döngüsü) modelinden de sık sık bahsedeceğiz. Dijital hayatın hızlanması ve rekabet gibi bileşenler hepimiz gibi proje yönetim şekillerini de etkiledi. Çoğumuz değişimin bir parçası olmak için kolları sıvadık. Bu yazımda değişime ayak uyduran veya uydurmaya çalışan hemen hemen bütün ekiplerin kullandığı bir yöntem olan Agile(Çevik) metodolojiler hakkında toparladığım notlarımı paylaşacağım.Şimdiden faydası olması dileklerimle 😊

Peki bu yazıda nelerden bahsedeceğiz?

Bu yazıda özetle Agile süreçlerde en çok duyduğumuz veya duyacağımız konu başlıklarına değineceğiz. Teorik bilgileri pratik örneklerle destekleyip Agile’yı doğru kullanıyor muyuz noktasında kendimizi sorgulayacak ve bilgilerimizi pekiştireceğiz.

Kısaca Agile’dan bahsedelim ve Waterfall’a gönderme yapalım 😊

Baştan her şeyin planlandığı şelale(Waterfall) modelinde hangi zaman diliminde hangi adımın atılacağı ve dolayısıyla neyin ne zaman olacağı net olarak belirtilir. Fazlar ona göre en baştan planlanır ve bu işleyiş dışına pek çıkılmaz. Waterfall işe yarayan bir yöntemdir. Senelerce de çoğu firmadaki ekiplere rehber olmuştur. Fakat teknolojinin çok hızlı değişmesi, internetin hayatımıza girmesi, uzaktan çalışan ekipler, projelerin ömür döngülerindeki belirsizlikler gibi etkenlerden dolayı, ürün ya da hizmeti baştan sona kadar net tanımlayamadığımız noktalar oluşmaya başladı. Çoğu noktada keskin kararlar alınamadığı durumlar olabilir ve ekip üyeleri proje geliştirilirken başlangıçta kullanmaya başladıkları yöntemleri, projenin ilerleyen safhalarında değiştirme ihtiyacı duyulabilir. Bu durumlarda Waterfall ile ilerlemek pek mümkün değildir. Waterfall yöntemde demin de söylediğimiz gibi yapılan iş baştan planlanır. Ürün veya hizmet çıktısı ise en sonda ortaya konur.

Agile ise ;

“Tabloyu en azından kara kalem de olsa duvara asayım, geri kalan renklendirme işlemlerini sonradan yaparım.”

şeklinde bir yaklaşım sunar. Müşteriye değeri aşamalı olarak sunabilmek önemli bir noktadır.

Agile Manifestosu’ndan bahsedelim ! 😊

Manifestonun çıkışı 2001 yılında yazılım ağırlıklı meşhur topluluktan çıkmıştır. Örneklendirme bir yazılım projesi üzerinden gerçekleştirmiştir. Yazılım projelerinde projeyi en baştan planlayıp sonuna kadar bu plandan sapmadan ilerlesek bile sonuçta başta tasarlanan amaçtan farklı bir noktaya ulaşmış olabilir. En kötüsü de bu sorunu son ana kadar fark edememe halidir. Projeyi geliştiren kişiler kendi yöntemleriyle aralarda teslim ederek, değer koyarak ilerlemelidir. Bu strateji takıma hız kazandırır ve motive eder. Agile Manifesto da tam olarak bu ihtiyaçtan ortaya çıkmıştır. Scrum’ın kurucularından Jeff Sutherland de bu manifestonun imzalayıcıları arasındadır. (Jeff Sutherland’in “Scrum iki katı işi yarı zamanda yapma sanatı” kitabını da tavsiye ederim. :))

Scrum’dan bahsetmesek olmaz ! 😊

Resimlerde gördüğümüz takımlar Amerikan Futbolu ve Curling takımlarıydı. Görüldüğü üzere bu iki sporda da takımlar, oyuncuların birlik olup değer katmasıyla başarıya ulaşabilir. Açıkçası Amerikan Futbolu ve Curling ile çok ilgilenmiyor ve takip etmiyorum. En sevdiğim spor basketbol ve ondan örnek verebilirim. Üçlük sayı atışı dediğimizde aklımıza gelenler elbette ki yakın tarihte Golden State Warriors’un yıldız oyuncusu Stephen Curry. Biraz daha geçmişe gidersek Ray Allen ve Reggie Miller’ı da tabii ki göz ardı edemeyiz. Basketbolla yakından ilgilendiğim zamanlarda üçlük sayı atışını hep bir şekilde yeteneğe bağlardım ancak izlediğim bir belgeselde oyuncuların üçlük sayı isabet yüzdelerini arttırabilmek için disiplinli ve planlı bir şekilde çalıştıklarının farkına vardım. Aslına bakarsanız eski zamanlarda üçlük sayı atışı o kadar da kıymetli değilmiş, daha doğrusu üçlük sayı atışı kavramı bulunmuyormuş. Sonraları birçok oyuncu potaya hayli uzaktan kaydettikleri sayılarla maçları çevirmeye başlayınca üçlük sayı atışı kavramı basketbol terimlerine dahil olmuş,yaygınlaşmış ve yaygınlaştıkça da oyuncular bunun üzerine çalışmalar yapmaya yoğunlaşmışlardır. Buradan Agile’a nasıl geçeceğimi merak ediyorsunuz tabii.

Her şey de olduğu gibi Agile ekiplerde de başarının kilit noktası doğru ve planlı çalışmaktır. Konuya Agile açısından yaklaşmak için Golden State Warriors oyuncularının durumunu bir inceleyelim derim. Golden State Warriors takımında herkes yapması gereken görevi, üzerine düşen sorumluluğu biliyor. Örneğin; çoğunlukla üç sayılık atışları ile anılan Stephen Curry, sayı isabeti düşük olmasına rağmen her maçta sürekli üçlük deneseydi ne olurdu? Peki takımın başarılı forveti olan Draymond Green, savunma yapmak yerine sürekli dışarıdan sayı kaydetmeyi deneseydi bu durum takımı etkiler miydi? Bu sorulara çoğumuzun verebileceği cevapları bir kelimede toparlayabilseydik eğer herhalde bu kelime, “Başarısızlık” olacaktır çünkü basketbol bir takım oyunudur. Basketbolda da tıpkı Agile ekiplerde olduğu gibi herkesin bir görev tanımı vardır ve oyuncular arasındaki görev dağılımı maç öncesinde gerçekleştirilir. Agile, takımların kendilerine verilen görevlere istinaden doğru ve planlı bir şekilde çalışmasını hedefler. Tabii ki Agile ekiplerde de,tıpkı basketbol maçlarında olduğu gibi, takım üyelerinin sahip olduğu görev tanımları dışında diğer arkadaşlarına destek olması gereken durumlar olabilir ama unutmayın ki bu da oyunun bir parçasıdır. 🙂

Scrum da grupların bir takım halinde topu istenilen hedefe götürürken birlikte çabaladıklarını gösterir. Amerikan futbolunda amaç, topun karşı tarafa geçmesini engellemektir ve o sırada takımdan kimse bireysel egosunu düşünmez. Topa sahip olan arkadaşın hedefe ulaşması için onu korur ve etrafında dururlar. Agile’da da belli bir hizmeti müşteri veya son kullanıcıya ekip olarak sürekli paslaşarak teslim etmek hedef alınır. Scrum kavramı da 19. yüzyılın ilk yarısında İngiltere’de kurulan birebir temasa dayalı bir takım oyunu olan Rugby’den gelmektedir. Agile kavramında da ,çoğu takım oyununda olduğu gibi, hedefe ulaşana kadar sürekli yeniden yön verme ve senkron olarak çalışma amaçlanır. Agile’ın normal proje yönetiminden farklılaştığı ilk nokta burasıdır. Agile kısa döngülerle değeri ortaya koymak üzerine oluşturulan bir felsefedir. Günümüzde bu felsefeyi uygulayıp Scrum’ı benimseyen birçok kurum ve kuruluş vardır. Bunlara örnek olarak Google,Apple,Facebook,Yahoo,Spotify,Adobe,AirBnB örnek olarak verilebilir.

Agile olmak için;

  • Agile doğru önceliklendirmelerle alınmış işlerin doğru şekilde parçalanarak işlenmesini ve iterasyon sonunda müşteri için değer olarak çıktı haline getirilmesini önemser.
  • Sürekli iyileştirmeye önem verilmelidir.
  • Paydaşların dikkate alınması önemlidir.
  • Metodolojinin amaçlarından birisi takımın eksiklerini görüp kendisini iyileştirme imkanı yaratması ve buna bağlı olarak verimini arttırmaya çalışmasıdır.
  • Adapte edilebilir planlama nasıl yapılmalı ? sorusuna cevap verilebilmelidir çünkü Agile yeniden yön vermeyi esas alır. Baştan sona kadar belirlenen bir yol yoktur. Yolun çizilmesinde müşterinin iterasyon bazlı istekleri de önem taşır. O nedenle ekipteki kişiler değişimlere kolayca ayak uydurmalıdır.
  • 2001 yılında hazırlanan Agile Mindset; Projelerde süreçler ve araçlar önemli ama daha önemlisi kişiler ve kişiler arası etkileşimdir. Süreçler ve araçlara uyum sağlamak önemli tabii ki ama daha önemlisi değildir.” düşüncesini savunur.
  • Agile yaklaşım dokümantasyona daha az önem verir. Çünkü müşteri için işe yarar/çalışır çıktılar üretmek aslolandır. Tabii bu hiç dokümantasyon yapılmadığı anlamına gelmemelidir. En ufak User Story’den Test Case’ine kadar düzenli ve iyi yazılması gereken bir sürü içerik de mevcuttur.
  • Bir işte sözleşmeye göre hareket edilmeli ve ürünü çıkarma noktasında engel teşkil edecek maddeler varsa geçici veya kalıcı olarak planlardan çıkarılmalıdır. Burada önemli olan müşteri ile iletişimde senkron kalmak ve işe yarar ürün parçaları hedefinden şaşmamaktır.

NOT: Agile sadece yazılım projeleri için kullanılmamaktadır. Ulaştırmadan uzay çalışmalarına, sanayiden akademik organizasyonlara, eğitimden sağlığa kadar pek çok sektörde kullanılmaktadır.

Agile Manifesto’dan bahsetmiştik. Şimdi biraz da prensipleri üzerine konuşalım! 😊

  • Sürekli Teslimat: Müşteri veya kullanıcıya ürünü parça parça sunmak Agile prensiplerinin en önemli unsurlarındadır.
  • Araçlar : Agile ekiplerin mümkün oldukça aynı ortamda olması gerekir ancak son zamanlarda pandemiden dolayı Agile ekipler de uzaktan çalışmaya alıştılar. Uzaktan çalışma ile bir arada bulunamayan takımlar yüz yüze görüşememenin sebep olabileceği sıkıntılara istinaden bazı uygulamalar kullanmaya başlamıştır. Online Boardlar için Miro,Vsts,Trello,Jenkins vs gibi alternatifler kullanılırken; toplantılar için Zoom, Webex, Teams, Skype vb alternatiflerden yararlanılmaktadır.
  • Definition of done: Sprint sonunda teslim etmeyi taahhüt ettiğimiz beş maddelik bir işimiz olduğunu ama sadece üç puanlık bir kısmını bitirebildiğimi düşünelim. Müşteri ile el sıkıştığımda tamamlanma kriteri beş puan üzerinden değerlendirilir. Dolayısıyla iş tamamlanmamış sayılır. Bu her ne kadar kötü görünse de, işe yarar çıktıların oluşturulması ve bir ürün değerinin ortaya konması açısından anlamlıdır. İşlerin bu şekilde eksik kalmaması ve istekleri tam olarak karşılanması için planlama toplantılarında üzerinde karar kılınan maddelerin takım tarafından iyice anlaşılır ve yapılabilir parçalara bölünmüş olması önemlidir.
  • İletişim: Kimse ekipte birbirini bir işin yapılması için uyarmamalıdır. Zaten planlamanın başında alınan işler bellidir ve takım bu işleri bitireceğine dair birbirine söz vermiştir. Bu sözün tutulması için de herkes elinden geleni yapmalıdır. O nedenle döngünün içerisinde takımdakilerin birbirlerini “Bu talebi bitirdin mi? Bitirecek misin?” şeklinde uyarması etik değildir. Eğer bir yavaşlık söz konusu ise veya belli başlı nedenler ile alınan talepler bitirilmediyse retrospective toplantısında tartışılmalıdır.
  • Toplantılar: Agile yaklaşımın iterasyonlar bazında vazgeçilmez toplantı ritüelleri vardır. Daily Meeting, Sprint Planning, Review, Retrospective vb. Bunları yazının ilerleyen kısımlarında ele alacağız.
  • Yalınlık : Agile süreçlerinde sadelik önemlidir.

The Lean- Agile ve Kanban kavramlarına değinmeden geçemeyiz ! 😊

  • Lean Türkçe’ye yalın olarak çevrilir. Lean; yalın, israftan arındırılmış değer üretimi için hareket etmek demektir.Lean’de temel fikir müşteriye sunulan değeri arttırırken israfı (waste) azaltmaktır. Bir başka ifadeyle, daha az kaynak ile daha çok değer üretmektir.Lean bir maliyet azaltma programı ya da tekniği değil, tüm organizasyon için israfı azaltmaya, müşteri için değer üretmeye ve sürekli gelişmeye odaklanan bir yaklaşım biçimidir.
  • Tam zamanında üretim için stok bulundurma işi yapıldığını hayal edelim. Bu işin aşamalarında; müşteri veya işi yapan kişi ilerleyen safhalarda geri dönüp nelerin tamamlandığını, nelerin tamamlanmadığını veya nelerin eksik kaldığını bilmek isteyebilir. Her şey ortaya koyulur ve geliştiren kişi oradan çekip işlemeye çalışır şeklinde değil, çalışan kişi ihtiyaç duyduğunda işi üzerine çeker ve işler mantığında ilerleniyorsa bu, Kanban’ın çalışma mantığını tanımlar.
  • Lean, Lean Manifacturing veya Lean production dediğimiz şey aslında bir düşünce biçimidir ve bir takımın başarılı olabilmesi için, bu takımın şekillenmiş bir kafa yapısına sahip olması gerektiğini belirtir. Scrum, Kanban, XP (Extreme Programming) gibi Agile süreçleri, bu düşünce tarzının başarılı olması için kendine has özellikleriyle yardımcı olmaktadır. Nasıl ki Lean’ e yardımcı olan agile süreçlerinin kendine özgü belli değerleri var ise Lean’ in de kendine özgü bazı temel prensipleri veya değerleri mevcuttur diyebiliriz. Lean 1900’lü yılların başında, TPS (Toyota production sistem)’ den türemiştir. Daha sonra TPS, Lean olarak insanlar arasında yayılmaya başlamıştır ve Toyotanın bütçesine katkı sağlamayı hedeflemiştir.
Kanban Board örneği

Size bir yerlerden tanıdık gelebilir! Agile rolleri ve ekip özelliklerinden bahsedelim ! 😊

Agile ekipleri Cross functional olmalıdır. Cross Functional ekip, ortak bir amaç için çalışan farklı işlevsel uzmanlığa sahip bir grup insandır. Agile metodoloji ile çalışan takımlardaki ekip üyelerinin cross functional olarak ifade edilen yetkinliklere sahip olması tercih edilir. Bu hem aynı ekipteki her geliştiricinin bir başkasının işini yapabilmesi farklı domainlerde çalışılabilmesi açısından önemli bir yetkinliktir

Agile Practitioner

Projedeki ürüne göre uzmanlıklar değişebilir. Agile’da Proje Yöneticisi kavramına rastlanmamaktadır. Bunun yerine Agile Practitioner kullanılır. Agile Koç, Scrum Master veya Scrum Coach olarak da adlandırılabilir. Agile Practitioner ekiple birlikte işi yapan kişi değildir. Ekipte işle ilgili dönüp danışılacak kişidir. Ekibin önündeki engelleri açan kişidir ancak ekibin yerine iş yapmaz. Kurumsal anlamda sorunları çözmeye çalışır.

Agile Practitioner’ın ortak amacı,ekibin engellerini ortadan kaldırmak demiştik. Bu engeller; bütçe desteği, yazılımsal araç eksikliği, yönetimsel sorunlar vb. olabilir. Bu sorunlar dahilinde operasyonel olarak işe yardım etmekle yükümlü değillerdir. Örneğin, ekip bir şeyi yanlış yapıyor ise Agile Pracititonerlar onların fikirleri alınmadığı sürece hiçbir şey yapmamalıdır.

Development Team

Yazılım ekibi; işi yapmakla yükümlü olan,plan ve iterasyonlara bağlı olarak işleri tamamlamaya çalışan ve sürekli iletişim halinde kalan çok kalabalık olmayan ekiplerdir.

Product Owner

Ürünün sahibidir ve öncelikleri belirledikten sonra detayları sağlamakla yükümlüdür. Ürün veya hizmetin yol haritasını bilen, bunları biçimlendiren, ek olarak yapılacak işleri önceliklendiren kişidir. Product Owner ekipten olabileceği gibi müşteri organizasyonundan da olabilir.

Agile Ekip Özellikleri

  • Önerilen 3–9 kişi arasıdır. Hatta şöyle bir tabir vardır. “Bir öğünde üç pizza ile doyan bir ekip Agile ekip olabilir. :)”
  • Ekip kendi kendisini yönetebilmelidir. Bu şekilde problemler karşısında hızlı organize olup kolayca çözüm üretebilirler.
  • Başlanmış olan işlerin sayısı veya büyüklüğü sınırlanmalıdır.
  • Süreklilikte etkin ekip üyeleri olması avantajdır.
  • Farklı yetkinliklerden farklı bilgilere sahip olan kişiler olmasında yarar vardır. (Cross-Functional)
  • Fiziken aynı ortamda olmaları iletişimin gücü ve verimliliği açısından önemlidir. Bu nedenle şirketlerde agile takımlar genellikle çevreden izole olmuş ve bir arada yaşayabilecekleri odalarda çalışırlar. Pandemi şartlarında ise yukarıda da belirttiğimiz üzere çeşitli çevrimiçi araçlarla bu fiziki ortamı sanal dünyaya taşırlar.
  • Her bilgi ile ilgili ufak da olsa bilgisi olan ve takımı kuvvetlendiren takım arkadaşlarına T-Shaped adı da verilir. T-Shaped yaklaşımındaki takım arkadaşlarının her alanda bilgisi ufak da olsa vardır. Tek bir alanda da kendini tam anlamıyla geliştirmiştir ve derin bilgileri vardır.
  • I-Shaped ise bir konuda uzmanlığım var, başka bir şeye bakmam yaklaşımında olan çalışanlardır. Bu çalışanların bir konuda derin bilgisi ve uzmanlığı bulunmaktadır. Eğer bildikleri konu ile ilgili sorun yaşanırsa adres bellidir.
  • Üstlendiği rol itibariyle Feautereler, User Storyler ve bunların tamamlanıp tamamlanamadığı konusunun takip edilmesi Product Owner sorumluluğundadır.

Projedeki yaşam döngüleri ve Hibrit ömür döngüsü kavramlarından bahsedelim ! 😊

Bir projenin yaşam döngüsü genellikle aşağıdaki şekildeki gibi ifade edilir:

  • Konsept geliştirme
  • Fizibilete çalışması
  • Müşteri istekleri
  • Çözüm geliştirilmesi
  • Dizayn
  • Prototip
  • Yapı
  • Test
  • Geçiş
  • Devreye alma
  • Yol haritası incelemeleri
  • Dersler çıkarmak

Hibrit Ömür Döngüleri

  • Projenin başlangıç aşamasında genel olarak yapılacak işler öngörülebilir ve planlanabilir. Projenin bu kısmında daha Waterfall yani şelale döngüsünde gidilebilir. Aynı şekilde planlama evresinde de daha waterfall yani şelale döngüsü yaklaşımla gidilebilir.
  • Ancak iş ürün geliştirmeye geldiğinde Waterfall modeli ile ilerlenmesi yanlış olur. Bu aşamada çevik yaklaşım tercih edilerek ilerlenilmesi ürün gelişimi açısından hayatidir. Yine de projenin belli kısımlarında Waterfall(ürünleşme döngüleri hariç), belli kısımlarında Agile tekniklerle ilerlenebilir.
  • Hiçbir proje için kesin olarak Agile ile yürütülmeli veya Waterfall ile gidilmeli de diyemeyiz” mi desek?
  • Agile süreçlerinde kuralcılık esas değildir, diretmeler yoktur. Amaç ürünü ve projeyi ortaya koymak ve bunu yaparken takım çalışmasının gücünü almaktır.

Bu işin olmazsa olmazları planlama ve bünyesinde bulundurduğu kavramlar ! 😊

  • Genel planlama, release planlaması ve müşteri tarafı ile bir araya gelinmesi gibi konulardan ürün sahibi (Product Owner) sorumludur
  • Release plan aşamasına temel paydaşlar haricinde isterse ekip de dahil olabilir.
  • Takım tarafından yapılacak geliştirmelerde iterasyona dahil edilecek maddelerin önceliklendirilmesi zor ve çok mühim bir konudur. Product Owner sorumluluğunda olan bu konuya geliştirme takımı da dahil olabilir. İletişimin çift yönlü ve birlikte ilerleyecek şekilde gerçekleşmesi avantaj sağlar.

Release Planning

  • Genel olarak bir yol haritasıyla nihai olarak yapılacak işlemler planlanır. Örneğin ilk altı ayda şunları, diğer altı ayda bunlarıyapacağız, önümüzdeki bir senede o hedefe varacağız vb. olursa bu bir Release planlamadır.
  • Kaba taslak yapılan bir planlamadır. Bir başka deyişle detaylı olarak yapılan bir şey yoktur. Daha çok releaseler sonrası ortaya çıkacak şeyler belirlenir.
  • Agile de releaseler içerisinde başlayan iterasyonlarla başlar. Bu iterasyonlar değişiklik gösterebilir. İterasyon iki hafta veya bir aylık olabilir ya da kurumun yaklaşımlarına göre değişebilir. Ancak hangi gün sayısıyla başlandıysa onunla devam edilmelidir. Bir iterasyon 15 gün, diğerinde 30 gün, sonrasında tekrar 15 gün şeklinde devam edilirse sıkıntılar olabilir.
  • Her bir özelliğe göre görev dağılımı yapılır.

User Story Kavramı

  • User Story oluşturabilmek için gereksinimlerin parçalara bölünmesi gerekir.
  • Ürün ya da hizmetle olan bağlantısı önemlidir.
  • Şu roldeki kişi olarak şunun yapılmasını istiyorum, böylelikle şuna ulaşabileceğim formatında bir tanımlama yapılır.
  • Kullanıcının aslında neye ihtiyaç duyduğu kavramlarla açıklanabilir.

User Story ve Features(Özellik) ilişkisi

  • Bir User Story kendi başına özellik olabileceği gibi biren fazla Usery Story ürün için tek bir özelliği de ifade edebilir.
  • Ürünün özellikleri User Story’lerden oluşur. Bu özelliklerin toplamı da bizi Releaselere doğru götürür.
  • Product Backlog’da her biri User Story olarak tanımlanmış gereksinimler bulunur.
  • Product Backlog’un oluşturulması Product Owner tarafından gerçekleştirilir. Ancak Agile pratiklerine göre takımla birlikte oluşturulması desteklenmektedir.
  • User Storylerin tanımlı hale gelmesi ve içlerinde ne iş yapılacağının belirtilmesi de Product Owner sorumluluğundadır.
  • Iteration Backlog ise ilgili döngüye hangi User Storyleri alacağız sorusuna cevap verir. Bunların önceliklendirilmesi Product Owner tarafından yapılır.
  • Ancak bu işlemler yapılırken, daha önce de bahsettiğimiz gibi ekip “bu yapıyı bu iterasyonda yetiştiremeyeceğiz” diyebilir ve bu konuda ortak noktaya varılabilir.

User Story Tahminlemesi

  • İşin zorluğunu da belirten büyüklük kavramı Story Point(SP) olarak ifade edilir. User Story’ler mutlaka SP değerleri ile açılır.
  • Tahminleme yöntemlerinde genellikle Fibonacci Serisi kullanılır. Yani SP değerleri bu şekilde ifade edilir(1,2,3,5,8,13,21…)

Neden Man Hours(Adam Gün) kullanılmaz ?
Man Hours(Adam Gün) işin büyüklüğü anlamında yanıltıcı olabilir. Agile ekipleri bir işi birlikte yaparak ilerler. Yani zamana bağlı bir ölçümlendirme yapmak tercih edilmez.

  • İş yakınımızda ise yani bu iterasyonda çözülebilecekse, sekiz ve altındaki puanlarla tahminleyebiliriz(1,3,5,8 )
  • Süreklilik arz eden ve tek sprint içinde tamamlanamayacak işler de söz konusu olabilir. Örneğin Refactor işlemleri, üretim ortamı hataları desteği gibi. Bunlar genel büyüklüklerde bırakılır(13,20 puan gibi)
  • Parçalanması için ayrıca çalışılması gereken veya ilk bakışta kapsamı büyük olup anlaşılamayan işler 20,40,100 SP ile Epic olarak adlandırılır. Genel görünümü aşağıdaki grafikte bulabilirsiniz.

Benzetme Tahminlemesi
Benzetme tahminlemesine göre eğer bir işe 3 SP(Story Point) kadar büyüklük veriliyorsa, diğerlerine de o tahmine benzer olacak şekilde puanlar verilebilir. Bu tahminleme şekli büyüklükleri belirlerken daha hızlı aksiyon almamızı sağlar. İlk etapta baz puanı belirlemek zordur ancak alıştıktan sonra işler kolaylaşır.

Planning Poker

  • Product Owner döngü için gerekli işleri Development Team’e ilettikten sonra Development Team bu talepler ile ilgili puanlama yaparken herkesin ortak görüşünü kolayca almak için çeşitli yöntemlerden yararlanır. Planning Poker bunlardan birisidir.
  • Eğer ekipten birisi bir iş için 8 SP verirken diğeri, 1 SP veriyorsa, neden biri bu kadar yüksek diğeri bu kadar düşük verdiğine dair bir tartışma yapılır ve ekipçe ortak karara varılır.

İterasyon/Sprint

  • Yer yere iterasyon yer yer sprint olarak da adlandırılan kavram aslında takımın belirlediği koşu sürecini ifade eder.
  • Product Backlog’dan buraya işler alınarak Sprint/iterasyon Backlog oluşturulur.
  • Sprint Backlog’daki işler önceliklendirilir, büyüklükleri belirlenir ve daha küçük görevlere bölünerek takım arasında paylaşılır.

Daily Stand Up Meeting

  • Her gün yapılan rutin toplantılardır. Bu toplantılarda amaç şu üç soruya cevap vermektir.

1-) Ekip olarak dün ne yaptım ? Neleri tamamladım?

2-) Bugün kişi olarak neleri yapacağım ?

3-) Bu işleri yaparken sıkıntıyla karşılaştım mı ? Yardıma ihtiyacım var mı ?

  • 15 dakika ile sınırlıdır (Uzaktan çalışma döneminde ise bu süre 30 dakika olarak da belirlenebilir)
  • Sorun varsa bunu çözmek için Scrum Master/Scrum Coach devreye girer.
  • Bu toplantılarda PO,Agile Coach ve Development Team dışında kimse bulunamaz. Olsa da izleyici olarak katılabilir.

NOT: AGILE KOÇUN KURUM DIŞINDAN OLMASI OBJEKTIF OLUNMASI AÇISINDAN DAHA İYİ OLABİLİR

Burndown Chart

  • Günlük olarak ekibin işlerdeki durumunu gösteren grafiklerdir.
  • Lineer bir grafik değildir. Nitekim bir çizgi ile ideal yol ifade edilirken diğeri ekibin güncel durumunu gösterir.
  • Kırmızı çizgilerle günlük işin ne kadarının tamamlandığı gösterilir. Bu çizgiler gidişatta sıkıntı var mı yok mu onu belirtir.
  • Dashbord göstergelerini izlemekte kullandığımız kavram radyatör, proje ara çıktısı ise artifact olarak adlandırılır.

Deneysel Süreç Kontrolü (Empirical Process Control)

Önceki döngülerde yaşanan sorunları çözümleme sonucunu değerlendirerek yani bu deneysel sonuçlardan yola çıkarak yeni yol haritası hazırlanır. Bu, takımın iş yapma beceresini iyileştirmek ve verimliliğini artırmak için kullanılır.

  • Transparency: Ekibin kendi içerisinde bilgiyi doğru paylaşmasıdır.
  • Inspection : Kök nedenler bulmaktır.
  • Adaptation: Bu kök nedenlere göre yeni kavramlar ortaya koyulmasıdır.

Hız ( Velocity Tracking)

  • Hızdan kasıt “ne kadar zamanda ne kadar iş bitiriyoruz?” sorusunun cevabıdır. Definition of Done’a göre bitiriyorsak ekip olarak hızımız budur.
  • Bitmeyen işler tamamlanmamış olarak kabul edilirler. Tamamlanmayan işlerin değeri yoktur. Bunları çoğalması bir yerlerde hata yaptığımızı gösterir. İyileştirmek için Deneysel Süreç Kontrolünü kullanırız.

Definition of Done

  • Tamamlanma şartı anlamına gelmektedir.
  • Baştan o işin yapılması ile ilgili metrik konulur. User Story açılırken o talep ile ilgili nelere ihtiyaç olduğu ve sprint sonunda hangi çıktıkların elde edileceği metrikler halinde belirtilir. Eğer bu metriklere ulaşıldıysa o zaman Definition of Done’a uygun demektir. Yani iş tamamlanmıştır.
  • Definition of Done’ı Product Owner geliştirir. İşi ekip yapacağı için bunu ekiple birlikte geliştirmesi daha faydalı olur.
  • Definition of Done projenin etkili yapılıp yapılmadığı ile ilgili bilgiler de verebilir.

Product Backlog Refinement nasıl yapılır ?

  • Bu süreci Product Owner sahiplenir ve süreç boyunca ekibin de işin içinde olması işin daha iyi anlaşılmasını sağlar. Agile genelde bunu tavsiye eder.
  • Product Owner, bir sonraki Sprint’te veya iterasyonda üzerinde çalışılması gereken Product Backlog öğelerini çıkarır ve User Story’lere böler. Böylece ekip, bir sonraki Sprint sonunda teslim edilmesi beklenen işleri bilir.
  • İşler öncelik sırasına göre alınır, büyüklükleri Development Team tarafından tahmin edilir ve story point olamayacak kadar büyük olanların türü epic olarak güncellenir. Epic olan işler daha küçük parçalara bölünmeden sprint’e alınamazlar..

Review

  • Döngünün sonunda yapılan işler ve ürün çıktıları müşteriye sunulur.
  • Bu toplantılarda müşterinin ürünle ilgili eksiklikler de ortaya çıkabilir. Müşteri nezninde bu eksiklikler sonraki sprint için birer backlog maddesi olabilir.
  • Toplantıya Product Owner, Development Team, Agile Coach ve müşteri (isteğe bağlı) katılır.

Retrospectives

  • Müşteriyle degil ekiple alakalı bir toplantıdır.
  • Ekip kendi kendini eleştirir. Neyi iyi yapıp neyi kötü yaptığını tespit etmeye çalışır.
  • Scrum Master ile birlikte sürecin nasıl iyileştirileceği tartışılır. Bu toplantılarda Scrum Master yol gösterici kimliği ile bulunduğundan etkisi büyüktür.
  • PO,Agile Coach ve ekibin tamamı katılır.

Son olarak aklımızdan çıkarmayalım ve uygulayalım! Shu Ha Ri 😊

Shu: Öğrenen
Ha: Bağımsızlaşan ( Sadece koçtan değil, birçok kişiden destek alıyor.)
Ri: Kendi yöntemlerin ortaya koyan

Shu Ha Ri mantığında çalışan kişiler ;

  • Yeterli olmadığı noktada koçtan destek alır(Shu).
  • Belli bir noktaya geldiğinde bağımsız olarak öğrendikleriyle kendi kararlarını verebilir. Bir sonraki aşamada kendi stilini geliştirir(Ri).
  • En önemlisi kendisine aktarım yapıldığı gibi yeni gelen kişilere de aynı ona yapıldığı gibi aktarım yapar, yardım eder ve o kişinin “Shu” evresinden “Ha” evresine geçmesi için elinden geleni yapar. Unutmayalım, bilgi paylaştıkça güzeldir. Bilgiyi paylaştığımızda değer kazanır.

Sevgilerle,

Bir sonraki yazıda görüşmek üzere 🙂

Kaynakça

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir