Agile Pratikler - Information Radiators

Agile Pratikler yazı serisinin bir önceki yazısında Eşli Programlama'ya değinmiştik. Bu sefer ki yazımızda Information Radiators konusuna değineceğiz. "Information Radiators" pratiği için tam anlamı yansıttığını düşündüğüm Türkçe karşılık bulamadım. Bu nedenle yazıda orjinal tanımı kullanacağım. Ancak güzel bir karşılık biliyorsanız ve paylaşırsanız memnun olurum.
 
Information Radiator, bir takımın proje ile önemli gördüğü bilgileri içeren grafikleri herkes tarafından görünür bir yere asması pratiği için kullanılan genel bir terimdir. İlk kullanılmaya başlandığı zamanlarda "Big Visible Charts" ismiyle de bilinen Information Radiator'lar, el yazısı, çizim, çıktı veya elektronik ekran şeklinde olabilir. 1980'lerde Toyota Üretim Sistemi'ndeki "Görsel Kontrol" tanımı ilk çıkış noktası olarak bilinir. İlk defa "Big Visible Charts" terimi olarak 1999 yılında Kent Beck tarafından "Extreme Programming Explained" kitabında tanımı yapılmıştır. En temel özelliği, bir bakışta mevcut durumla ilgili son bilginin görülmesini sağlamasıdır.
 
 
Information Radiator'ların kullanımı, kendi sağladıkları bilgilerin haricinde iki temel mesaj iletmektedir:
  • Takım olarak, ziyaretçilerimizden (müşteri, diğer paydaşlar vb.) hiçbir şey saklamayız.
  • Takım olarak, kendimizden hiçbir şey saklamayız. Problemlerimizi kabullenir ve onlarla yüzleşiriz.
Information Radiator'ların sağladığı en temel fayda, sorumluluk duygusunun takım içerisinde yayılmasını sağlamaktır. Ekip haricinde kişilerin ziyaretleri sırasında, beyin fırtınası yapılmasını sağlaması da faydaları arasında sayılabilir.
 
Bir çok takım, sadece Hız Grafikleri'ni, Information Radiator olarak bilir ve sadece bu grafiği kullanır. Bu durum genellikle yanlış bilinen bir olgudur, aksine ürün geliştirme süreci için bir çok bilgi değerli olabilir. Hangi bilginin değerli olduğuna takım kendisi karar vermelidir. Aşağıdaki bilgileri görünür kılmak için Information Radiators pratiğini kullanabilirsiniz:
  • Otomatikleştirilmiş test sayısı
  • Başarısız ve geçmiş test sayısı
  • Mevcut Hata Raporu ve Çözülmüş Hata Raporu Sayısı
  • Süreç ile ilgili grafikler (Eşli Programlama için harcanan süre, yapılan entegrasyon sayısı vb.)
  • Patronunuzun takıma en son ne zaman pizza ısmarladığı :)
 
Bunlara ek olarak kullanmanızı önerdiğim Engeller Tahtası'nı (Impediment Board) da Information Radiator olarak değerlendirebiliriz. Bu pratikte önemli görülen engeller, pusulacıklara yazılarak herkesin görebileceği bir yere asılmalıdır. Engeller Tahtası, özellikle Scrum Master'ların takımın önündeki engelleri fark etmesi ve bu engelleri ortadan kaldırmak için aksiyon almasının sağlanması açısından faydalıdır.
 
Bir sonraki yazıda görüşmek üzere.
* Bu yazıda kullanılan görseller Atlassian web sitesinden alıntıdır.

Agile Pratikler - Pair Programming (Eşli Programlama)

Agil Pratikler serisinin ilk yazısında Hazır Kriteri konusunda bilgiler paylaşmaya çalışmıştım. Serinin bu yazısında Eşli Programlama (Pair Programming) konusunda bilgiler aktarmaya çalışacağım.
 
Eşli Programlama, iki programcının bir bilgisayarı paylaşarak yazılım geliştirme aktivitesini yerine getirmesidir. Burada yazılım geliştirmeyi yapan kişiye sürücü, aktif olarak aktiviteye katılan diğer kişiye yönlendirici ismi verilir. Bu iki kişinin bu rolleri sürekli değiştirerek aktiviteyi gerçekleştirmesi beklenir.
 
İki kişi birden bir aktivite üzerinde çalışıldığında, aynı iş için harcanan eforun iki katına çıkacağı düşünülür. Ancak bu yanlış bilinen bir olgudur. Yapılan deneyimsel araştırmalarda sadece %15'lik bir artış gözlenmiştir. Bu artışın, kod kalitesinin iyileşmesi nedeniyle ilerleyen dönemlerde sağlanacak olan kazançla karşılanabileceği düşünülmektedir.
 
Eşli Programlama, Sesli Programlama olarakta adlandırılmaktadır. Bu aktivite sırasında iki kişinin konuşmuyor olması, aktivitenin tam anlamıyla yapılmıyor olmasına işarettir. Burada yönlendirici, sürücüyü uyarmalı ve aktiviteyi ilerletmelidir.
 
Eşli Programlama aktivitesinin kişisel problemleri olan kişiler arasında yapılması zorlanmamalıdır. Bu tür durumlarda öncelikli olarak bu problemler ortadan kaldırılmalı, sonrasında bu aktivite gerçekleştirilmelidir.
 
 
Bu aktivitenin gerçekleştirilmesi için bulunulan fiziki şartların uygun olması gerekmektedir. Geniş odalarda yapılan aktivitelerin genellikle başarısız olduğunu belirtmemiz gerekir. Sesli bir aktivite olmasından dolayı, ortamdaki gürültü seviyesinin kontrol edilmesi gerekmektedir.

Eşli Programlama aktivitesinin sağladığı avantajları şu şekilde sıralayabiliriz:
  • Kod kalitesindeki artış, ve buna bağlı olarak hata oranında azalma sağlanması
  • Ekip içerisinde teknik bilgi birikiminin artması (mentörlük ve öğrenme)
  • Koordinasyon ihtiyacında azalma (Örnek: 10 kişilik bir ekipte, sadece 5 çiftin koordinasyonunun sağlanması gerekir)
  • Ekip arasındaki kişisel ilişkilerin gelişmesi ve buna bağlı olarak takım olgusunun oluşmasındaki olumlu etki.
Eşli programlama aktivitesi, tanım olarak iki programcı ile yapılmalıdır. Birlikte çalıştığımız bir takımda, bu tanıma uymayan, ancak başarılı sonuçlar elde ettiğimiz farklı bir eşli programlama aktivitesinden bahsetmek istiyorum. Gerçekleştirdiğimiz bu çalışmada, bir analist ile bir yazılımcıyı eşleştirdik. Burada roller hep sabit olarak tutuldu. Yazılımcı her zaman sürücü, analist ise her zaman yönlendirici rolündeydi. Analist, geliştirilen kodun yapısal kısımlarından daha çok fonksiyonel kısımlarına odaklandı. Bu çalışma sayesinde sağlamış olduğumuz kazanımlarımızı şu şekilde sıralayabilirim:
  • Yazılımcılar ve analistler birbirlerini daha iyi anlamaya başladılar. Yaptıkları işlerin zorluklarını görme fırsatı buldular. Bu sayede takım olgusunun gelişmesi sağlandı.
  • Özellikle analistlerin tahminleme aktivitesi sırasında kullanabilecekleri farklı bir bakış açısı kazanmları sağlandı.
  • Geliştirilen yazılım parçası üzerinde ilk defa çalışan bir yazılımcının, analist eşi sayesinde, daha önceden geliştirilmiş olan kodu anlaması kolaylaştı.
  • Yazılımcının, kullanıcı hikayesi ile ilgili sorusu olduğu durumda, beklemeden çözüme ulaşabilir olması sağlandı. Böylece kesintiler önlendi.
Benzer faydaları sağlayabileceğinizi ve yararlı bir aktivite olduğunu düşünüyorum. Denemenizi tavsiye ederim.
 
Keyifli bir Agile yolculuğu diliyorum.

Agile Pratikler - Hazır Kriteri

Bu yazıyla birlikte, Agile Pratiklerle ilgili bilgiler paylaşacağım bir yazı serisi başlatıyorum. Bu yazı serisinde Agile metodolojilerin kural kitaplarında tanımlanmış veya tecrübe sonucu ortaya çıkmış ve yakın bir zamanda kural kitaplarına gireceğini düşündüğüm pratiklere yer vermeye çalışacağım. Bu serinin ilk yazısında "Definition of Ready - (Hazır Kriteri)" pratiğini tartışacağız.
 
Hazır Kriteri, Scrum çerçevesini kullananların çok iyi bildiği "Definition of Done - (Tamamlandı Kriteri)"ne benzeyen bir pratiktir. Birlikte çalıştığım bir çok takım bu pratiği kullanmıyor. Ve bu nedenle aşağıda listelemeye çalıştığım problemleri sıklıkla yaşıyorlar:
  • Sprint hedefinin net bir şekilde ortaya konulamıyor olması
  • Uzun Sprint Planlama Toplantıları ve bunun bir sonucu olarak bu toplantılardan nefret edilmesi
  • Kullanıcı hikayelerinin gerekli detayda yazılmamış olmasından dolayı yaşanan motivasyon kaybı
Bu problemlerin en temel kaynağı, Ürün Sahip'lerinin takımlara, Sprint için açık bir hedef veremiyor olmasıdır. Hazır Kriteri, Scrum takımlarına bu konuda yardımcı olan bir pratiktir. Peki nedir bu Hazır Kriteri?
 
Hazır Kriteri, takım tarafından açık ve görünür bir şekilde belirlenmiş, bir kullanıcı hikayesinin gelecek Sprint'e kabul edilmesi için gerekli kuralları belirleyen bir listedir. Tamamlandı Kriterinin tam karşıtıdır. Tamamlandı Kriteri, bir kullanıcı hikayesinin tamamlanması ile ilgili kriterleri belirlerken; Hazır Kriteri, bir kullanıcı hikayesinin Sprint'e kabul edilmesi ile ilgili kuralları belirler. Hazır Kriteri için, Geliştirme Takımı müşteri, Ürün Sahibi şirkettir.

 
Kendiliğinden organize bir takım için açık bir hedef belirlemek çok önemlidir, çünkü kendiliğinden organizasyonun, organize edilecek bir şey olmadığı zaman varlığından söz edemeyiz. Hazır Kriteri pratiği burada devreye girerek, Sprint için kabul edilecek kullanıcı hikayelerinin kalitesini arttırır ve takımlara açık bir hedef belirlenmesi konusunda yardımcı olur. Hazır Kriteri, sağlıklı bir Sprint yapılması için ön koşulların hazırlanmasını sağlar. Böylece daha etkin Sprint Planlama toplantıları yapabilir, takımlarınızın motivasyonunu arttırabilirsiniz.
 
Hazır Kriteri'ni bir liste olarak düşünebilirsiniz. Sizlere başlangıç için yardımcı olması açısından bir örnek paylaşıyorum:
  • Takım tarafından validasyonu yapılmış
  • Kabul Kriterleri hazır
  • Tahminlemesi yapılmış
  • Son Kullanıcı tarafından gözden geçirilmiş
Hazır Kriteri'ni, Sprint Retrospective toplantılarında gözden geçirerek, ihtiyaçlarınıza göre düzenleyebilirsiniz. Jeff Sutherland'in CSM (Certified Scrum Master) eğitimlerinde de anlattığı bu pratik, defacto bir standart olma yolunda ilerliyor. Yakın bir zamanda Scrum Kılavuzu'nda da yerini alacaktır.
 
Keyifli Scrum'lar...