Etiket arşivi: Product Owner

Gecikmenin Maliyeti

Gecikmenin Maliyeti

Üretim ortamında bulunmayan kodlardan değer üretemezsiniz. Bu kadar vurucu bir cümleyle yazıya giriş yapmam okuyanların konunun önemini anlamalarına yardımcı olmak içindir.  İşlerinizi önceliklendirirken pazara çıkış zamanıyla elde edeceğiniz kazanç, yasal zorunluluk, iş değeri gibi kavramlardan yararlanabilirsiniz. Bunların yanında dikkate almanız gereken diğer bir konuysa Gecikmenin Maliyeti’dir. Gecikmenin maliyeti, bir özelliği üretim ortamına almayı geciktirerek kaybedilecek değerdir.

Gecikmenin maliyeti işlerin önceliklendirilmesinde nasıl bir öneme sahip? Gecikmenin maliyeti nasıl hesaplanır? Farklı senaryolar üzerinden şimdi görelim. Gecikmenin Maliyeti yazısına devam et

Karar Almada Ortamın Önemi

Karar Almada Ortamın Önemi

Bu makalede karar almada ortamın önemini anlatacağım. Bugün izlediğim bir futbol maçında dikkatimi çeken bir forvet oyuncusu bulunuyordu. Bu oyuncu takımının yakaladığı fırsatları bir bir harcadı. Kale önünde, altı pas içinde topu kaleciye nişanladı, çektiği şutlar defans oyuncularına çarptı, verdiği paslar arkadaşlarına ulaşmadan rakipler tarafından kapıldı. Maçın bir bölümünde rakip takım korner kullandı. Kornerden dönen top, kornerin kullanıldığı köşeye geri dönerken bizim ünlü forvetimiz rakip takımdan birini takip ediyordu. O anda bu topun dönüp gol olacağını düşündüm. Çünkü bu adam tam bir başarısızlık abidesiydi ve ne yapsa takımına negatif bir şekilde geri dönüyordu. Eminim demek istemiyorum ama rakibi takip etmese ve rakip boş bir pozisyonda orta yapsa bence gol olmayacaktı. Bu topun gol olması rakibin şansı bizim forvetimizin şanssızlığı değildi. Buna eminim.

Bizim forvetimiz dışarıdan bakıldığından elinden geleni yapıyor, çok çalışıyor, canını dişine takmış ve her şeyini veriyor gibi görünüyor. Tek bir şey dışında bunları yaparken doğru yolu izlemiyor. Çünkü doğru kararlar veremiyor. Dahil olduğu her pozisyonda işleri daha da karmaşık hale getiriyor ve bunun sonucu da takımına olumsuz olarak geri dönüyor.

Bunları neden anlattım? Çünkü yazılım projelerinde görev alanlarda benzer yaklaşımı sergiliyor. Tabi kişinin sahip olduğu role göre yaptığı etkide ortamda farklı oranda değişikliklere neden oluyor. Örneğin bir futbolcu hata yaptığında bu çok önemli olmayabilir ve hatadan geri dönülebilir. Hatalı bir pas verip topu rakibe kaptırabilir. Biraz sonra topu rakipten geri alabilir ve bu, çok büyük bir sorun olmayabilir. Bu tıpkı bir yazılımcının test senaryoları üzerinden geçerken birini atlaması gibi. Fakat teknik direktör maçı kaybederken ve gol atması gerekirken bir forvet çıkarıp bir savunma oyuncusu alıyorsa çok ciddi sıkıntılar var demektir. Bırakın oyunu okumayı bu teknik direktör skor tabelasını bile okuyamıyor diyebiliriz. Bir projenin planlamasında ya da ilerlemesinden sorumlu kişilerin aldığı aksiyonlarda benzerdir. Bu adam ne yaptığını bilmiyor dediğiniz olmuştur. Karar Almada Ortamın Önemi yazısına devam et

Değişiklik Maliyeti

Değişiklik Maliyeti

Bu yazımda sizlere yazılım projelerinde değişiklik maliyeti konusunu anlatmaya çalışacağım. Diğer bir deyişle proje gerçekleştirilirken yapılan hatanın organizasyona olan maliyetini anlatacağım. Böylece yazılım geliştirilirken aslında her bir aktivitenin ne kadar önemli olduğunu göreceğiz. Aktiviteler kullandığımız yaklaşıma bağlı olarak değişmektedir. Örneğin geleneksel yazılım geliştirme yaklaşımında Eşli Programlama diye bir aktivite bulunmazken aslında hatalar yapılır yapılmaz yakalanma şansı kaçırılmaktadır. Halbuki Çevik yaklaşımları kullanan takımlar Eşli Programlama’yı kullanarak hatalar yapılır yapılmaz yakalamakta ve gerekli değişikliği yapabilmektedir. Projenin tamamı düşünülerek bu açıdan bakıldığında Çevik yaklaşımlar büyük bir israfın önüne geçilebileceğini göstermektedir.

Yazılım projelerinde değişikliğin maliyetini hesaplayan çalışmayı yapan kişi Barry W. Boehm’dur. Boehm, Waterfall modelini ilk defa bilimsel makalesinde anlatan Royce gibi TRW için çalışan aynı zamanda Güney Kaliforniya Üniversitesi’nde hocalık yapan bir profesordür. 1957’de Hardvard’ta lisans eğitimini tamamlamıştır. Yüksek lisans ve doktora derecelerini 1961 ve 1964 yıllarında Kaliforniya Üniversitesi’nden almıştır. 1989 – 1992 yılları arasında Amerika Savunma Bakanlığı’nda Direktör olarak çalışmıştır. 1973 – 1989 yılları arasında TRW’de Savunma Sistemleri Şefi olarak görev yapmıştır. Yazılım geliştirme süreçlerini etkileyen birçok çalışması bulunmakla birlikte en büyük etkiyi WinWin Spiral Model ve Software Engineering Economics adlı çalışmalarıyla yapmıştır.(1)

Değişiklik Maliyeti yazısına devam et

Kültür ile Çalışmak

Kültür ile Çalışmak

Aşağıdaki diyagram Çeviklik, Kanban ve Ustalık ilkelerinin farklı kültürler ile nasıl örtüştüklerini gösterir. Şekil, her biri için önceki bölümlerde yaptığımız analizlere dayanarak dominant kültürü gösterir.

Kültür ile çalışmak
Kültür ile çalışmak

Diyagram hangi yaklaşımı kullanırsanız şirketinizde gelişecek dominant kültürü belirlemenizde bir klavuz olarak kullanılabilir.

  • Kontrol Kültürüne, Kanban öncülük eder
  • Yetkinlik Kültürüne, Yazılım Ustalığı öncülük eder
  • İşbirliği ya da Usta-Çıraklık Kültürüne, organizasyon kültürü ile aynı çizgide bulunan Çevik yaklaşımlar öncülük eder. Örneğin; Usta-Çıraklık kültürü için Vizyon ve Retrospektif

Organizasyonel kültür farklı açılardan düşünülmeden bu rehberin kullanılması amaçlanmamıştır.

Elbette birçok okur, organizasyon kültürünün Kontrol’den İşbirliğine, Usta-Çırak ve Yetkinliğe  değişimin nasıl olacağıyla ilgileniyor olabilir. Bu, dönüşüm bölümünde detaylı bir şekilde anlatılmıştır. Kültür ile Çalışmak 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