Çevik Yazılım Geliştirmede risk konusu üzerine birçok araştırma yaptım. Ne yazık ki paylaşabileceğim ya da bana bir şeyler katabileceğini düşündüğüm bir paylaşım bulamadım. Bu, Çevik Topluluğu için büyük bir kayıp. Özellikle geleneksel yöntemle proje geliştirenlerin savunduğu; “Çevik yaklaşımlar içinde risk yönetimi bulunmuyor; bu nedenle kullananların canı çok yanıyor!” iddialarına cevap niteliğinde birkaç yazı bulurum diye düşünüyordum.
Bu makalede Çevik Yazılım Geliştirmede adapte olabilirlik konusunu anlatmaya çalışacağım. Yine Çevik Yazılım Geliştirme Bildirisi’ndeki değerleri göz önünde bulunduralım. Çalışan yazılıma detaylı dokümantasyondan daha fazla değer verilir. Çevik Bildiri’deki ilkelerdeyse geliştirme sürecinin geç aşamalarında bile değişim hoş karşılanır denir. Her döngü sonunda çalışan yazılım teslim edilir. Çalışan yazılıma yeni özelliklerin adapte edilebilmesi kolaydır.
Geleneksel yaklaşımda ise esneklik analiz aşaması başladığı anda düşer. Değişimi hoş karşılamaz. Geriye dönük yapılmak istenen herşeye karşı çıkılır ve tekrar edilen iş olarak görülür. Halbuki ürün müşterinin istediği yönde evrilebilmelidir. Geleneksel proje yönetiminde bu evrilmeyi gerçekleştirebilmek neredeyse imkansızdır. Yeni bir ürün geliştirmeye başladığınızı düşünün, başlangıç aşamasında tam bir ürün elde etmek istediğinizi düşünüp bir yılda geliştirilebilecek bir ürün için dört aylık analiz çalışması gerçekleştirdiniz. Dördüncü ayın sonunda ise müşterilerinizin beklentisi değişti ve başka özelliklere yöneldiler. Ürününüze yeni özellikler eklemeniz ve müşterinin beklentisi yönünde evrilmeniz gerekiyor fakat siz çoktan ürünün bir yılını planlamıştınız. Yapılan bütün analiz çalışmaları boşa gider. Bu israf demektir. Sokağa atılan para demektir. Bütçenizi değer üretmeden tüketmeniz demektir. Çevik Yazılım Geliştirmede Adapte Olabilirlik yazısına devam et
Bu makalede yazılım geliştirmede görünürlük konusunu anlatmaya çalışacağım. Çevik Yazılım Geliştirme Bildirisi değerlerinde müşteri ile yakın iletişim ve ürünü geliştiren kişiler arasında işbirlikçi bir yaklaşımdan bahsedilir. İlkelerinde ise kısa döngüler halinde geliştirilen özellikleri müşteriye sunmak ve müşteriden gelen geribildirimler ile ürüne yön vermekten böylece ürünün görünürlüğünü artırmaktan bahsedilmektedir. Her döngünün sonunda gerçekte ne kadar ilerlendiği böylece rahat bir şekilde herkes tarafından görülebilir. Çevik yazılım geliştirme ile görünürlük döngü başında yüksektir, döngünün ortasına doğru görünürlük düşer ve döngünün sonunda görünürlük tekrar yükselir. Burada anahtar nokta döngünün kısa olmasıdır. Eğer müşterinin istemediği bir özellik geliştiriliyorsa kısa tutulan döngü sonunda hemen ortaya çıkar. Çevik Yazılım Geliştirmede Görünürlük yazısına devam et
Bu makalede Pair Programming Nedir konusunu anlatmaya çalışacağım. Yöneticilerin büyük çoğunluğu yazılım geliştiricileri nadir birer kaynak gibi görür. Onlar için bir parça kodu iki kişi yazmak çöp (israf) yaratır ve buna izin vermezler.
Yazılım geliştirme -eskiden beri- tek başına yapılması gereken bir iş olarak öğretildi ve insanlar hep tek başlarına kod yazdı.
Birçok deneyimli yazılım geliştirici bir başkasıyla kod yazmaya hevesli değildir. Bazı deneyimli yazılım geliştiriciler kodlarının “kişisel” -özel, başkasına kapalı olan- olduğunu ya da başkasının onları yavaşlatacağını söyler.
Bazı deneyimli yazılım geliştiriciler bir partner ile çalışmanın çalışma sürelerini uzatacağını söyler. Başka deneyimli yazılım geliştiricilerse biriyle beraber çalışmanın kodlarında problemlere neden olabileceğini söyler.
Şimdi sizlere Pair Programming’i anlatacağım. Yukarıda söylenenlerin ne kadar yanlış olduklarını ispatlamaya çalışırken aşağıdaki konulara değineceğim ve bunu elimden geldiğince kolay anlaşılabilir bir şekilde yapmaya çalışacağım.
Pair Programming Nedir? Eşli Programlama Nedir? yazısına devam et
Ç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