Etiket arşivi: Product Backlog

Waterfallda Karşımıza Çıkan Problemler

Waterfallda Karşımıza Çıkan Problemler

Bu yazımda son 40 yıldır yazılım geliştiren herkesin en az bir defa karşısına çıkan Waterfall’dan bahsedeceğim. İster küçük bir yazılım evinde ürün geliştiriyor olun ister kurumsal bir organizasyonda görev alın Waterfall size dokunmuştur. İster bir veri ambarı projesi yapın, ister bir B2B projesi geliştirin herkesin desteklediği ama bilgisinin olmadığı ve üzerine düşünmediği bir konudur, geleneksel yazılım geliştirme süreci.

40 yıldır bu yaklaşımla proje geliştiren kişilerin bu yaklaşımı savunmasını anlıyorum, anlayamadığım konu çalışmaya sadece birkaç yıl önce başlamış kişilerin adeta fanatik bir şekilde bu yaklaşımı savunmalarıdır. İlk önce analizi bitirmeliyiz analiz bittikten sonra geliştirmeye başlanabilir geliştirmeyi bitirdikten sonrada testçi arkadaşlar test etmeye başlayacak diye seslerini yükseltmelerini şaşkınlık içinde izlediğim çok olmuştur. Bu sahneleri izleyince Uğur MUMCU’nun şu sözü gelir aklıma “Bilgi sahibi olmadan fikir sahibi olunmaz!”. Gerçekten bilgi sahibi olmadan fikir sahibi olan bu arkadaşların fanatik yapısı neden kaynaklanmaktadır. İnsanoğlu neden öğrendiği ilk şeyin hep doğru olduğunu düşünür? İlk öğrendiğini benimser ve sahiplenir? Çünkü ego -psikoloji biliminde kullanılan anlamıyla- değişimin kötü olduğunu düşünür ve insan içgüdüsel olarak kendini koruması gerektiğini varsayar. Bu içgüdüsel yaklaşım bir savunma mekanizmasını tetikler ve değişime karşı yumruklar sıkılır.
Konuyu daha fazla ilginçleştirmeden ve dağıtmadan Waterfall ile geliştirilen ürünlerin geliştirme sürecinde karşıma çıkan problemleri anlatacağım. Sizinde karşınıza çıkan gözlemlediğiniz, yaşadığınız ve ilginç olduğunu düşündüğünüz problemleri duymayı çok isterim. Waterfallda Karşımıza Çıkan Problemler yazısına devam et

Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü…

Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü…

 

Sprint Planlama Toplantısı’nın ikinci bölümü olan NASIL kısmında Geliştirme Takımı işin nasıl yapılacağına dair analiz ve tasarım yaptı mı?

Çevik Koçluk yaptığım Scrum Takımlar’ında üyelerin en çok sıkıntı yaşadığı yer Sprint Planlama Toplantısı’nın NASIL bölümüdür. Bu bölümünde gerçekleştirilmesi gereken analiz ve tasarım aktiviteleridir. NASIL bölümde yapılan analiz ve tasarım aktivitesi Geliştirme Takımı üyeleri tarafından gereksiz olarak görülmektedir. Bunun nedeni ise Geliştirme Takımı üyelerinin bunu daha önce denememiş olmalarıdır. Böyle takımlarla karşılaştığımda ilk önerim bebek adımlarıyla ilerlemeliridir. Bebek adımlarından anlaşılması gereken ise Sprint’e aldıkları İş Listesi Maddeleri’nin sadece yarısı ya da üçte biri için bu aktiviteyi gerçekleştirmeye çalışmalarıdır.

 

Toplantının bu bölümü yeni başlayan Scrum Takımları için gerçekten sıkıcı olabilir. 7 Geliştirme Takımı üyesinin 1 Scrum Master ve 1 Ürün Sahibi’nin bulunduğu toplantıda 9 kişinin basit bir İş Listesi Maddesinin nasıl gerçekleştirileceğine dair konuşması sıkıcı ve zaman kaybı olarak görülebilir. Halbuki burada erişilmek istenen nokta konuşulan maddeler hakkında bilgi paylaşımı, yapılan planlamanın herkes tarafından bilinmesi  ve mümkün olduğunca kusursuza yakın bir planlama yapmaktır. İnsanlara bunu göstermenin en iyi yoluysa fazla sıkılmalarını engelleyerek birkaç tane maddenin analiz ve tasarımını yapıp Sprint içinde bu işlerin nasıl ilerlediğini görmelerini sağlamaktır. Seçilen maddelerle ile ilgili gözlemlerin bir sonraki Sprint Retrospektif Toplantsı’nda konuşulması, analiz ve tasarımı yapılan maddeler ile yapılmayan maddelerin geliştirilmesi arasındaki farkların ortaya çıkarılması insanların daha kolay ikna olmasını sağlayacaktır.

Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü… yazısına devam et

Sprint Planlama Toplantısı Nasıl Yapılır? NE Bölümü…

Sprint Planlama Toplantısı Nasıl Yapılır? NE Bölümü…

Sprint Planlama Toplantısı’nın ilk bölümü olan NE bölümünü 1 saat ya da altında bir sürede tamamlayabildiniz mi?

Scrum’ı anlayamamış Ürün Sahipleri tarafından kolayca işgal edilebilen toplantının bu bölümünde sıklıkla birkaç hata yapılır. Müşteri ile Sprint içinde yakın ilişki kurmaktan çekinen ya da bunu gerekli görmeyen Ürün Sahipleri müşterinin ihtiyaçlarını Sprint Planlama Toplantısı’nın NE bölümünde dinlemek isterler. Müşteri, toplantıya geldiğinde tüm Scrum Takımı’nın kendini dinlediğini görünce memnun olur. Halbuki ortada yaratılan çok büyük bir israf vardır. Müşteri ihtiyaçlarının Ürün Sahibi tarafından alınması, bunların değerli olup olmadığının belirlenmesi ve İş Listesindeki öncelik ve değer sıralamasının Sprint içinde yapılmış olması gerekmektedir. Ürün Sahibi bu toplantıya önceliği belirlenmiş bir liste ile gelir. Daha iyi olanı ise bu listeyi eski adıyla grooming yeni adıyla refinement aktivitelerinde Geliştirme Takımı üyelerine göstermiş olmasıdır. Elbet son gün son dakika içinde acil işler çıkmış ve listeye girmiş olabilir ve Geliştirme Takımı bunu ilk defa görüyor olabilir. Önemli olan Geliştirme Takımı, Sprint İş Listesini oluştururken onların istediği detay bilgileri doğru bir şekilde verebilmektir.

 

Burada dikkat edilmesi gereken nokta toplantının NE bölümünün amacından sapıp bir grooming aktivitesine dönüşmemesi ve NASIL bölümü için gerekli zamanın ayrılmış olmasıdır. Bunu yapabilmek içinse gerektiği kadar detaylandırma aktivitesinin yapılmış olması lazım gelir ve mümkün olan en kısa sürede NE bölümünün bitirilmesidir.

Sprint Planlama Toplantısı Nasıl Yapılır? NE Bölümü… yazısına devam et

Sprint Planlama Toplantısı Nasıl Yapılır?

Sprint Planlama Toplantısı Nasıl Yapılır?

Çevikliğin, bir kültür ve “Neden” sorusuna bir cevap olduğunu daha önceki yazılarımda anlatmıştım. Scrum ise bu kültürü oluşturmanın, uygulamanın ve yaşatmanın yollarından biridir. Ayrıca “Nasıl” sorusunun cevabıdır. Scrum’da herşey iyi bir planlamayla başlar. Çevikliği ve Scrum’ı yeni öğrenenlerle sohbet ettiğimde genelde Scrum’da plan olmadığına ve bu nedenle işlerin yolunda gitmediğine dair yakınmalarını duyarım. Aynı şekilde Çeviklik’ten yakınırkende dokümantasyon olmadığını ve bu nedenle birçok sorun yaşadıklarını anlatırlar.

 

Evet! Scrum’da plan yoktur. Daha etkili olan planlama vardır. Bir plan yaparsanız ona uymak zorunda kalırsınız, bir değişiklikle karşılaştığınızda planı değiştiremezsiniz ve değişikliği kabul etmek istemezsiniz. Şimdi sizlere Scrum’da iyi bir planlamanın nasıl yapılabileceğini ve Çevik Yazılım Geliştirme Manifestosu’nun değerlerinden biri olan “Kapsamlı dökümantasyondan ziyade çalışan yazılım” ile ne anlatılmak istendiğini açıklamaya çalışacağım.(1)

 

Scrum’da resmi olarak belirtilen dört toplantıdan biri olan Sprint Planlama Toplantısı iki bölümden oluşur. NE ve NASIL bölümlerine ayrılan toplantının ilk bölümünde ne iş yapılacağı, ikinci bölümünde ise bu işin nasıl yapılacağı konuşulur. Geliştirme Takımı, Ürün Sahibi ve Scrum Master’ın toplantıya katılımı zorunludur. Dört haftalık Sprint’ler koşan takımlarda toplantı süresi 8 saatle sınırlıdır. Doğru orantıyla iki haftalık Sprint’ler koşan takımlarda ise 4 saatle sınırlıdır.

Sprint Planlama Toplantısı Nasıl Yapılır? yazısına devam et

Sprint Sonunda Bitmeyen İşler

Sprint Sonunda Bitmeyen İşler

Bu makalede sizlere Scrum Takımlar’ının sıklıkla karşılaştığı bir problem olan “Sprint Sonunda Bitmeyen İşler’den” bahsedeceğim. Bu işler neden bitmiyor, nasıl bitirilebilirler? Bitmeyen işleri sonraki Sprint’e taşımalı mıyız? Bitmeyen işi Geliştirme Takımı’nın hızına eklemeli miyiz? Bu konuları dilimin döndüğünce anlatmaya çalışacağım. Aklınıza takılan her konuda bana yazabilirsiniz.

 

İdeal durumda Sprint’e alınan her iş BİTTİ kriterine uygun şekilde tamamlanır ve teslimatı yapılır. Ne yazık ki, Scrum Takımlar’ında, Sprint sonunda bitmeyen işler yaygındır. Birçok farklı neden dolayı ideal durum gerçekleşmeyebilir. Bu tamamlanamayan madde ile ilgili birkaç soruyu akıllara getirir:

 

  • Bir sonraki Sprint’e taşınmalı mıdır? İş Listesi’nde bu madde ile ilgili ne yapılır?
  • Daha küçük parçalara ayrılmalı mıdır?
  • Bu madde takımın toplam hızına eklenmeli midir?

Sprint Sonunda Bitmeyen İşler yazısına devam et