Kendi Metodolojinizi Belirleyin
“Kurumsalsan Waterfall şart abi. Değilsen Agile’dan yürüyeceksin.”,
“Biz Agile yapıyoruz ya.”,
“Biz Kanban’a geçelim diyoruz.”,
“Scrum’ı da Kanban’ı da boş ver, en iyisi Scrumban.”
“Şimdi boş verin retrospektifi, bu işlerin yetişmesi lazım. Hafta sonu kalıyor muyuz?“
Bunlar ve benzeri cümleleri çevrenizde/şirketinizde çok sık duyuyorsanız yazılım geliştirme metodolojinize ilişkin yanlış giden bir şeyler olabilir.
Bu yazıda son projemizde yaşadıklarımız üzerinden bir projede metodolojiye nasıl karar verilmesi gerektiğinden bahsedeceğim.
Projenin başında konuştuk tartıştık ve Scrum’la ilerlemeye karar verdik. Başlangıçta her şey olması gerektiği gibiydi. Ortaya çıkarmamız gereken bir ürün, her daim yeni talepleri olan ve mutlu etmemiz gereken müşterilerimiz vardı.
Tam bir yıl Scrum’la ilerledik. Scrum’ın reçetesinde yazan tüm kuralları harfiyen uyguladık (planlama toplantıları, tahminler, günlük toplantılar vs vs). Sürenin sonuna yaklaştığımızda müşterinin değişen taleplerini karşılayabilmiştik ancak hedefimiz olan ürüne ulaşamamıştık. Başlarda ekip olarak bizi birbirimize ve projeye ısıtan kurallar artık yorucu gelmeye başlamıştı.
Bize farklı bir şey gerekiyordu. Daha hızlı ilerleyebileceğimiz, daha amaca yönelik bir şey.
To-Do/Doing/Done!
Aslında o anda ihtiyacımız olan her şey bu üç statünün çevresinde dönüyordu. Sadece bu üç statüyü kullanarak tüm sürecimizi görselleştirmeyi denedik. Basitçe anlatmak gerekirse iki şey yaptık;
1. Yazılım geliştirme döngüsündeki her adım için bir To-Do/Doing/Done tanımladık. Örneğin; Geliştirme, Bugfix ve Test adımlarının ayrı ayrı To-Do/Doing/Done’ı var. Geliştirmenin ve Bugfix’ten çıkan işler Test adımına To-Do olarak gider.
2. Her iş tipinde kullanacağımız kartlar için birer renk belirledik. Geliştirme yeşil, Bug kırmızı gibi.
Tüm işleri fiziksel bir karalama tahtasına yansıttığımızda, adımlar, hangi iş tipinde yoğunluk olduğu, nerelerde birikme olduğunu açık bir şekilde gördük.
Zamanla işlerin detaylarını anlatmak için bir ortama ihtiyacımız olduğunu fark ettik. Bu da bizi basit bir sanal karalama tahtası (board) kullanımına götürdü. Yazılım ekibi Github bir alternatifi olan Gitlab’i kullanıyordu. Board’u ekip kullanacağı için Gitlab üzerinde basit bir board yaratmaya karar verdik.
Farklı metodolojilerdeki kavramları amacınıza göre kullanın!
Kendimize yeni bir metodoloji belirleyip, her konuda ona sığınmadık.
İşin yapılması/geliştirmesi kısmını Kanban’da olduğu gibi bir board üzerinden WIP (Work in progress limit)‘ler tanımlayarak ilerlettik. Analizi ve planlanması kısmını daha Scrum’da karşımıza çıkan iteratif yaklaşımla yapmaya devam ettik. Uzun süredir Scrum’la ilerlediğimiz için bu konuda iyiydik ve büyük işleri planlarken iteratif düşünmek işimizi çok kolaylaştırıyordu.
Scrum’da her sprint öncesinde Sprint Planlama toplantıları yapıp önümüzdeki sprint yapılacak işlere hep birlikte kafa yoruyorduk. Projemiz için son derece faydalı olduğunu düşündüğümüzden bu toplantıları sürdürme kararı aldık. Scrum’da olduğu gibi bu toplantılarda herhangi bir tahminde bulunmadık. Ancak backlog’ta yer alan işleri sıraları geldikçe ekip olarak detaylandırdık.
Böylece işlerin analiz aşamasına ekibin de katılmasını ve planlamayı daha iyi takip edebilmelerini sağladık.
İhtiyacınız yoksa yapmayın veya azaltın!
Asla ihmal etmediğimiz retrospektif toplantılarımız vardı. Scrum’da her sprint sonunda planlanması tavsiye ediliyor. Kanban’da herhangi bir dayatma yok. Bu toplantıları çok sık yaptığımızda bir konuda herhangi bir ilerleme kaydedemeden başka bir toplantıya giriyorduk. Bu nedenle azaltmaya karar verdik. Performansımızda ve ekibin motivasyonunda artış gördük.
Sonuç: Geliştirme sürecinizi ekibe ve ihtiyaçlarınıza göre şekillendirin!
Ürünümüz canlıya çıktı. Her geçişte olduğu gibi bizim canlıya çıkışımız da kusursuz değildi. Ama kusurları düzeltmek için herhangi bir metodolojiye bağlı kalmadık.
Başardık. Projenin başındaki deneyimlerimiz üzerinden ihtiyacımızı çıkardık ve bunun üzerinden bir süreç belirledik.
