Etkili Geliştirme Maddesi Açmanın Yöntemleri ve Sonuçları: SMALL & INVEST
Ürün yöneticisi olarak, 1 yıl içinde 3–4 çok büyük proje, 8–10 büyük ürün özelliği (epic) ve onlarca bağımsız geliştirme ve iyileştirme yapıyoruz, bulgu bildiriyoruz. Yüzlerce geliştirme maddesi oluşturuyoruz.
Geliştirme maddesi oluşturmak, bir ürün yöneticisinin, iş analistinin veya ürün sahibinin uzmanlaşması gereken bir beceridir. Bu beceri, ürün özelliklerinin zamanında yayına alınmasında kritik bir öneme sahiptir: Bir ürün yöneticisinin işinin en büyük kısmını oluşturan (bence 90%) stratejilerin hayata geçirilmesinde kullanılır. Bu nedenle, geliştirme ekibine belirsizlik içermeyen yönlendirmeler yapmak hayati öneme sahiptir.
Abartıyorsun!
Hayır abartmıyorum. Eksik veya özensiz açılan geliştirme maddeleri, tekrar eden ve günlük iş düzenimizi bozan aşağıdaki kronik problemlere yol açar.
- Ürün özelliğinin teslim tarihlerinde gecikmeler
- Ürün ve geliştirme ekiplerinde stres ve gerginlik
- Verimli ve yerinde kullanılamayan kaynaklar
- Test, UAT, otomasyon, yayına alma gibi süreçlerin planlamalarında uyuşmazlıklar
- Hatalı veya eksik yapılan geliştirmeler
- Geliştirmenin yakın ve uzak etki alanlarında öngörülmeyen hatalar
- Yanlış varsayımlar üzerine yapılan geliştirmeler
- Sprint planı içinde söz verilen kapsamın (Sprint Commitment) yapılamaması
- İş ve yaşam dengesinin bozulması
- Motivasyon kaybı
Bu sorunlarla sıkça karşılaştığımızda, durumu olağan iş akışının bir parçası olarak kabul eder ve her gün aynı sorunları çözmeye çalışırız. Ancak bu durum kocaman bir zaman ve bütçe kaybına neden olur.
Bu problemlerin olduğu bir ortamda, pek çoğumuz, muhtelif örneklerde, eminim şu diyalog içinde kalmıştır:
Y.: Bu bahsettiğin konu madde içine nerde yazıyor, ben bunun geliştirileceğini
anlamamıştım.
Ü.Y.: Madde içinde yazmıyor ama zaten böyle olması gerekiyordu.
Y.: ...Yazılımcı, madde kapsamını anlamakla yükümlüdür.
Araya parantez açarak hemen eklemem gerekiyor ki, geliştirme maddesini üstlenmiş yazılımcı, maddeden beklenen çıktıyı, bu çıktıyı hangi kısıtlar ve çerçeve içinde geliştirmesi gerektiğini anlamakla yükümlüdür. Bunun için vakit ayırmalıdır. Aksi halde yukarıdaki sorunlar yine kaçınılmazdır.
Pek çoğumuz, yine eminim ki şu diyalog içinde kalmıştır:
Ü.Y.: Burayı geliştirirken xxxx gibi bir kısıtımız olduğundan bahsetmiştim,
hatta geliştirme maddesi içinde de yazıyordu.
Y.: Hımm… Öyle miydi, nerede? .... Tamam, orayı da yapayım o zaman.Bir yazılımcı olarak, geliştirme maddesinin nasıl ele alınması gerektiğini yeniden değerlendirmek isterseniz buraya bakabilirsiniz: The first thing to do in any Software Engineering task: Write a checklist.
Önemli Not
‘Multitasking’ adı altında, pek çoğumuz muhteşem çocuk olarak görülürken, bu eşsiz yeteneğin yan etkilerinden bir tanesi tabi ki dikkat dağınıklığı. Hem ürün yöneticisi, iş analisti, ürün sahibi geliştirme maddesini açarken bu nedenle eksik açmış olabilir, hem de yazılımcı, bir nedenden ötürü, maddeyi eksik geliştirmiş olabilir. Arada sırada yaşanan sorunların gündelik iş akışının doğal sonuçları olduğunu hepimiz kabul etmeliyiz.
Geliştirilebilir Atomik Parçalar: “Task”
Geliştirme maddesine, günlük yaşamımızda “task” adı veriyoruz. Task açacağım.. Task’ı güncelledim.. gibi ifadeleri sayısız kez kullanıyoruz.
“Task” kavramı, Agile metodolojisi içinde bir tanımlamaya sahiptir: Bir kullanıcı hikayesinin, özelliğin veya hata düzeltmesinin geliştirilebilir en küçük parçasıdır.
Bir task, doğrudan bir kullanıcı hikayesine karşılık gelebilir veya birden fazla task tamamlandığında bir kullanıcı hikayesi veya özellik ortaya çıkabilir. Task bir duvardaki tuğla gibidir; bir tanesinin yanlış yerleştirilmesi tüm duvarı bozabilir. Bu nedenle, yanlış bir task tanımlaması, tüm geliştirme sürecini baştan yapmanıza neden olabilir. Eksiksiz ve doğru task tanımlamak bu yüzden önemlidir.
Neden Eksik Task Açarız?
Task açarken yapılan tüm hataların altında “varsaymak” yatar:
- Yazılımcının bizim kullandığımız terimleri anladığını varsayarız.
- Yazılımcının süreç akışını bildiğini veya süreci tek bir defa anlatmamız ile kavradığını varsayarız.
- Yazılımcının zaten konuya hâkim olduğunu varsayarız.
- Yazılımcının bizim için aşikâr olan o kuralı zaten oraya koyacağını varsayarız.
İyi Bir Task Açmanın Yöntemleri
Farklı tipteki tasklar (yeni özellik, web servis, ön yüz geliştirmesi, entegrasyon, hata, iyileştirme, bulgu vb.) için hangi detayların eklenmesi gerektiğini yaşayarak, gözlemleyerek ve geri bildirim alarak öğrenmek uzun bir süreçtir. Ancak, bu süreçte kendimize yol haritası olarak kullanabileceğimiz etkili metotlar mevcuttur. Bu metotlar, taskların doğru ve eksiksiz tanımlanmasını sağlayarak, geliştirme sürecinde karşılaşılan zorlukları minimize eder ve geliştirme sürecinin daha verimli ilerlemesine katkı sağlar.
SMART Metodu
SMART metodu, proje yönetiminde hedef ve amaç belirlemek için kullanılan bir yaklaşımdır. Temel olarak, hedeflerin nasıl oluşturulması, geliştirilmesi ve gerçekleştirilmesi gerektiği hakkında bilgi verdiğinden, task oluşturma sürecinde de yol gösterici olarak kullanılabilir.
Spesific — Spesifik / Belirli: Geliştirme maddesi olabildiğince açık olmalıdır. Okuyan herkes aynı sonuca varmalıdır. Ne yapılması gerektiği detaylandırılmalı, genelleme yapılmamalıdır.
Measurable — Ölçülebilir / Anlamlı: Geliştirme maddesinin tamamlandığını gösteren bir ölçüt veya sonuç olmalıdır. SMART metodunun kitap tanımlamasında, bu kriterden sayısal ölçüt olarak bahsedilmektedir. Örneğin, “5sn içinde sms göndermelidir” gibi. Ancak her geliştirme maddesinde bu tür bir sayısal ölçek belirlemek mümkün olmayabilir. Bu nedenle anlamlı bir çıktı (test edilebilir, sonucu görülebilir) oluşmalı şeklinde de yorumlayabiliriz.
Achievable — Ulaşılabilir: Geliştirme maddesinden elde edilmek istenen sonuç gerçekçi ve ulaşılabilir olmalıdır. “Task” kavramının Agile metodolojisindeki “en küçük geliştirilebilir birim” tanımı, bu kriterle örtüşür. Bir task, sprint planlaması içinde tamamlanabilecek kadar küçük olmalıdır.
Relevant — Uygun / İlgili: Yapılacak geliştirme, amaca uygun ve değerli olmalıdır. Uzun soluklu geliştirmeleri mikro geliştirme maddeleri ile yaparken, hedef üzerindeki kontrolü devam ettirmek zor olabilir. Hangi maddelerin hedef için önemli (Must have) ve hangilerinin ötelenebilir (Should have / Could have) olduğunu değerlendirmeye devam etmemiz gerekir. (MoSCoW için bakınız.) Bunun için şu iki soruyu da aklımızda tutabiliriz:
- Bu madde diğer maddelere göre ne kadar önemli?
- Bu madde için doğru zaman mı?
Time-Bound — Zaman Sınırlı: Geliştirme maddesi için bir tarih belirlemek, o hedefe odaklanmak için önemlidir. Belirlediğimiz bu tarih ile günlük görevlerimizi önümüzdeki (1, 2… sprintlik geliştirmeler, çeyrek bazlı projeler vb.) planlara göre önceliklendirebiliriz.
INVEST Metodu
Invest metodu kullanıcı hikayesi yazmak konusunda Agile ile uyumlu çalışan bir metottur. Her bir kullanıcı hikayesinin iyi tanımlanması için bir pratik sunar.
Bir kullanıcı hikayesi son kullanıcı gözünden yazılmış, kullanıcının beklentisini ifade eden metindir. Dolayısıyla bir kullanıcı hikayesi tek bir geliştirme maddesine karşılık gelebileceği gibi, birden fazla geliştirme maddesinin birleşimiyle de oluşabilir.
Kullanıcı hikayesine bir örnek:
Kullanıcının talebi: Geçmiş siparişlerimi görüyorum ama tekrar aynı siparişi
veremiyorum. Yeniden mağazayı seç, ürünü bul, sipariş detaylarını girmek
zor geliyor. Geçmiş siparişimi tekrar verebilmek istiyorum.
Bunun kullanıcı hikayesine dönüşmüş hali:
Bir AA kullanıcısı olarak, geçmiş siparişlerimin içinden bir siparişi seçerek
tekrar aynı siparişi verebilmek istiyorum.Independent — Bağımsız: Her kullanıcı hikayesi birbirinden bağımsız ve ilişkisiz olmalıdır. İlişkili hikayeleri yönetmek, öncelikleri yönetmekte zorluk çıkaracağından, kullanıcı hikayelerinin bağımsız olması beklenir.
Negotiable — Tartışılabilir: Kullanıcı hikayesi üzerinde tartışılabilir bir süreç tanımı yapar, kati ve değişmez değildir. Geliştirme aşamasına gelmeden önce veya geliştirme planlaması sırasında tartışılabilir ve değiştirilebilir. Bu sayede en iyi deneyim, en iyi süreç veya en iyi yöntem ile geliştirme yapma fırsatı elde edilir. Örneğin, ‘Tek tıkla şifre sıfırlayabilmek istiyorum.’ diyen bir kullanıcı için, bu işlemin SMS mi yoksa e-posta ile mi yapılacağı tartışılabilir.
Valuable — Değerli: Bu kriter, hikâyenin son kullanıcı için bir anlamı olmasını ifade eder. Kullanıcıya somut bir değer veya fayda sunmayan hikayeler, kullanıcı için öncelikli olmayabilir veya kullanıcının ihtiyacı olmayabilir.
Estimable — Tahmin edilebilir: Kullanıcı hikayesinin karmaşıklığı, etki noktaları, teknik gereksinimleri ve riskleri tahmin edilebilir olmalıdır. Eğer bu başlıklarda öngörülmezlik varsa, kullanıcı hikayesi küçük parçalara bölünebilir veya sprint planlamasına bir inceleme taskı (Spike) alınarak açık noktalar hakkında araştırma yapılabilir. (Spike için bakınız.)
Small — Küçük: Kullanıcı hikayesi sprint içinde tamamlanacak kadar küçük olmalıdır. Ancak bazen kullanıcı hikayeleri bu kadar basit olmaz. Kullanıcı hikayesi karmaşıksa, sprint içinde geliştirilebilecek daha küçük parçalara bölünmeli ve bu parçalar üzerinden planlama yapılmalıdır.
Testable — Test Edilebilir: Kullanıcı hikayeleri mutlaka test edilebilir çıktılar üretmelidir. Aslında her bir geliştirme maddesi test edilebilir olmalıdır. Test edilemeyen veya bağımlılık nedeniyle test edilemeyen maddeler, zamanlama ve planlama sorunlarına yol açar. Bu nedenle, kullanıcı hikayeleri oluşturulurken veya planlanabilecek kadar küçük parçalara bölünürken bu unsur göz önünde bulundurulmalıdır.
Bir hikâyenin veya taskın test edilebilirliğine en büyük katkıyı kabul kriterleri (Acceptance Criteria) verir. Kabul kriterleri, geliştirmenin sonucunda elde edilmek istenenlerin listesidir ve çıktıyı net bir şekilde ifade eder. Kabul kriteri deyince, task içine yazdığımız detaylardan çok farklı, bambaşka şeyler gözümüzde canlanmamalı. Bazen, geliştirme maddesinin içine yazdığımız açıklamanın kendisi bile kabul kriteri olabilir.
Örnek
Amaç: AA raporuna, raporda bulunan B kolonunda arama yapan yeni
filtre eklenecektir.
Madde detayı: (kabul kriterleri)
- Yeni filtrenin ismi X olmalıdır.
- X filtresi, ekranın üstünde Y filtresinin sağ tarafına tasarımdaki gibi
yerleştirilmelidir.
- X filtresi sayısal değer araması yapılan alandır. Metin araması yapılamaz.
- Alanda en az 1 karekter girilerek arama yapılabilir.
- ....Neredeyse her günümüzün odağında bulunan geliştirme maddelerini, doğru, eksiksiz ve anlaşılır açmak, günlük iş hayatımızı daha verimli, üretken, planlı ve stressiz geçirmemizin önünü açar.
Yukarıdaki metotlar genel ifadeler içerse de temellerinde yatan aşağıdaki 5 kriteri her tipteki geliştirme maddesi için uygulayabiliriz:
- Spesific (Belirli) & Estimable (Tahmin Edilebilir)
- Independent (Bağımsız)
- Measurable (Ölçülebilir / Anlamlı) & Testable (Test Edilebilir)
- Achievable (Ulaşılabilir) & Small (Küçük) & Time Bound (Zaman Sınırlı)
- Relevant (Uygun/ilgili) & Valuable (Değerli)
Bu kriterleri kullanarak geliştirme maddelerini oluşturmak, ekiplerin daha etkili çalışmasına ve projelerin daha başarılı bir şekilde tamamlanmasına olanak tanır. Her bir maddenin açık, ölçülebilir ve test edilebilir olması, potansiyel sorunları önceden tespit etmeyi ve çözümler üretmeyi kolaylaştırır. Bağımsız ve ulaşılabilir hedefler belirlemek, ekiplerin iş yükünü dengeleyerek verimliliği artırır. Sonuç olarak, bu prensipler hem günlük iş akışını iyileştirir hem de uzun vadeli projelerde daha sürdürülebilir bir başarı sağlar. Bu yöntemleri benimseyerek, geliştirme süreçlerinizi daha planlı, düzenli ve stressiz hale getirebilir, böylece hem ekiplerin hem de projelerin performansını optimize edebilirsiniz.
Geliştirme maddesinin açık, anlaşılır, net beklentiler içermesi ile varsayımlardan arınmış şekilde hazırlanmasının, geliştirme çıktısının kalitesini etkilediği açıkça görülmektedir. Sözlü iletişim kadar, yazılı iletişim becerilerinin kuvvetli olması hem geliştirme hem ürün ekiplerinin daha verimli ve üretken çalışmasının önünü açtığı görülmektedir.
Geliştirme maddesi açarken yaşadığınız zorluklar ve iyileşme önerinizi yorumlarda benimle paylaşın!
