Agile Leaders 5. Bölümü Gerçekleştirildi

Agile Leaders etkinliğinin 5. bölümü gerçekleştirildi. Bu bölümdeki konuğumuz Hakan Danışık'tı. Kendisine keyifli sohbeti ve katkıları için çok teşekkür ediyoruz.

 

Sizlerin geri bildirimleri bizim için çok önemli. Etkinlikle ilgili düşüncelerinizi, etkinlikte görmek istediğiniz konukları, sorularınızı vb. bize Twitter üzerinden #AgileLeadersST etiketiyle iletebilirsiniz.

Agile Leaders 6. bölümü 7 Ocak 2015 tarihinde gerçekleştirilecek. Detaylarını önümüzdeki günlerde yayınlayacağız.

Agile Leaders Etkinliği - Episode 5

Agile Leaders 5. Bölümü ile sizlerle! Etkinliğimizin bu bölümünde 17 Aralık 2014 Çarşamba günü, saat 17.00'da Comodo ArGe Direktörü Hakan Danışık bizlerle olacak. Bu bölümümüzde "Ürün Geliştirme Projelerinde Agile Yöntemler" başlıklı bir sohbet gerçekleştireceğiz. Bu keyifli sohbeti kaçırmayın!
 
 
Yayın öncesinde veya canlı yayın sırasında Hakan Danışık'a yöneltmemizi istediğiniz soruları #AgileLeadersST etiketi ile Twitter üzerinden paylaşabilirsiniz.

 
Hakan Danışık Kimdir?
 
 
1996 yılında ODTÜ Bilgisayar Mühendisliği bölümünden mezun olan Hakan Danışık, 15 yıl Siemens Türkiye ArGe grubunda çalışmıştır. 2008 yılında Siemens yazılım geliştirme süreçlerinin CMMI L3 uyumluluğu çalışmalarında aktif olarak rol almış, ve Ankara ArGe grubu olarak CMMI L3 sertifikasının alınması çalışmalarında yer almıştır.

2009 yılında Boris Gloger’dan aldığı uygulamalı eğitimler ile birlikte agile yöntemlerle tanışmış, bu yöntemleri kullanarak şirket süreçlerinin de Scrum temelinde güncellenmesi çalışmalarını yürütmüştür.

2013 Ocak ayından itibaren Comodo şirketinde ArGe Direktörü olarak çalışmaktadır. Comodo'nun yazılım geliştirme süreçlerinin tasarlanması ve yazılması işlerine öncülük etmiş, Comodo genelinde kullanılmak üzere agileComodo isimli çatı sürecin geliştirilmesine katkı sağlamıştır.

Bilişim Zirvesi'14 - Agile Approach to ERP by Pınar Ayorak

Yazarlarımızdan Pınar Ayorak, 30 Eylül - 1 Ekim tarihleri arasında Lütfi Kırdar Kongre Merkezi, İstanbul'da düzenlenen ICT Summit NOW - Bilişim Zirvesi'14 etkinliğinde konuşmacı olarak yer aldı. "Agile Approach to ERP" başlıklı sunumuyla, karmaşık olan ERP projelerinde Agile yaklaşımların kullanımına yönelik bilgiler aktardı. Bu etkinliği kaçıranlar için konuşmanın videosunu sizlerle paylaşmak istiyoruz. Keyifli seyirler.
 

Scrum Master Proje Yöneticisi Midir?

Yazarımız Sevgi Korkmaz'ın yeni yazısı sizlerle. İlk yazısına buradan ulaşabilirsiniz.

Klasik proje yönetiminden Agile’a geçiş sürecinde en çok merak edilen konulardan biri Proje Yöneticisine ne olacağıdır. Bir proje yöneticine ihtiyaç var mıdır? Üst yönetime zaman, kalite ve maliyet konusunda söz verebilecek birisi olacak mıdır? Proje süresince ve sonunda maliyet hesabını da içeren bir takım metrik ve raporları kim sağlayacaktır? Tedarik sürecini kim yönetecektir?  Scrum Master bir proje yöneticisi midir ya da product Owner ya da Takım,  Proje Yöneticisinin yerini alabilir mi? gibi sorular, organizasyonda Agile süreçlere geçişte cevaplanması gereken sorulardır.

Scrum metodolojisinde Proje Yöneticisinin sorumluluklarının bir kısmı Geliştirme Takımı, Scrum Master ve Product Owner tarafından üstlenilir. Burada bir kısım kelimesinin altının çizilmesi gerektiğini düşünüyorum çünkü bazı sorumluluklar Scrum metodolojisinin dışında kalmaktadır.


Rollere ve üstlenilen sorumluluklara kısaca bakalım.


Geleneksel proje yönetiminde, proje yönetcisi, projenin çıktılarından sorumlu kişi olarak tanımlanır. Bu tanım Scrum’da “Product Owner” için yapılmaktadır. Product Owner, projenin başarısından sorumludur. Ancak Product Owner, proje yöneticisinin yerini almıştır diyemeyiz. Başarıya ulaşmak için uygulanan yöntemler tamamen farklıdır. Klasik proje yönetiminde proje yöneticisi gerekli yöntemi belirleme, plan yapma ve planı uygulama otoritesine sahipken Product Owner’ın böyle bir otoriteye ihtiyacı dahi bulunmamaktadır. Tek yapması gereken ürünle ve paydaşların beklentileriyle ilgili vizyonu ekibe sağlamak, bu vizyona göre önceliklendirme yapmak ve işin istenen kalitede kabulunu gerçekleştirmektir.  Yani Product Owner, Müşteri Yönetiminden, Kapsam Yönetiminden ve Kalite Yönetiminden sorumludur.
 
Entegrasyon Yönetimi, Insan Kaynakları Yönetimi, Satın Alma Yönetimi Scrum Master ve ilgili departmanlar tarafından gerçekleştirilir. Scrum Master, sürecin Scrum süreçlerine göre gerçekleşmesini sağlayan ve takımın önündeki engelleri kaldıran kişi olarak takım adına proje ile ilgili bir taahhüt vermez.
 
 
Proje planındaki işlerin günlük takibi, zaman yönetimi, proje sürdürülürken ortaya çıkan konuların ele alınması, projenin doğrulama aktiviteleri, risk yönetimi, Geliştirme Takımı’nın sorumluluğundadır. Bu konularda Scrum Master takıma destek olur.

Proje yönetiminin bilgi alanları ve rolleri aşağıdaki gibi eşleştirebiliriz.

Entegrasyon Yönetimi : Scrum Master
Zaman Yönetimi : Geliştirme Takımı
Maliyet Yönetimi : Geliştirme Takımı & Scrum Master & Product Owner
Kalite Yönetimi : Product Owner & Scrum Master & Geliştirme Takımı
İnsan Kaynakları Yönetimi : Scrum Master
Müşteri ve Paydaş Yönetimi : Product Owner
Risk Yönetimi : Scrum Takımı
Satın Alma Yönetimi : Scrum Master
 
Sonuç olarak, Scrum Master, Proje Yöneticisi değildir. Scrum’da projenin tüm sorumluluğunu takım adına üstlenecek bir proje yöneticisine ihtiyaç bulunmamaktadır. Takım, Scrum Master ve Product Owner bu sorumluluğu beraber yerine getirirler. Geçiş yapan firmaların bu konuda çekincelerini aşmak için, adaptasyon sürecinde Scrum Takımından gerekli verileri alarak geneleksel yöntemlerle raporlamaları yapan bir proje ofisi üyesi ekiple beraber çalışabilir. Zaman içerisinde sonuçlar elde edilip, güvenin artması ile beraber, iş yapma ve kontrat yapma şekli de agile olabilir ve bu rol ortadan kaldırılabilir.

Çevik (Agile) Proje Yönetimi ve PMBOK Kılavuzu - II

Yazarımız Dilek Çıplak'ın yeni yazısı sizlerle.

Bir önceki yazımızda; PMBOK Kılavuzu, proje yönetimi için “en iyi pratikleri” içeren ve şelale  ya da çevik yaklaşımların tümü için uygulanabilir bir çerçeve sunan bir rehberdir demiştik.

Çevik bazlı metodların da PMBOK ile çerçevesi belirlenen proje yaşam döngüsü ve süreç gruplarını baz aldığını örneklendirmek için,  bu iki başlığı ayrı ayrı ele alalım.

Proje Yaşam Döngüsü
PMBOK ile tanımlanan proje yaşam döngüsü (Şekil-1) projeye dahil olan organizasyonların kontrol ihtiyaçları dikkate alınarak belirlenen sayıda ve isimde sıralı (sequential) proje fazlarından oluşur. Bu fazlar belirli bir teslimat ortaya çıkarmaya yönelik birbiri ile ilişkili aktivitelerin mantıksal gruplamasıdır.
Şekil-1 – Proje Yaşam Döngüsü Fazları (PMI)
Geleneksel yazılım geliştirme yaklaşımlarında, bu fazlar çoğunlukla şelale metoduna (Şekil-2) uygun olarak takip edilmiştir. Örneğin fazlardan birisi Tasarım olarak belirlenip, bu faz için teslimat olarak system tasarım dokümanı belirlenebilir. Çoğu zaman bir sonraki faza geçiş için onay ve imza (sign-off) gerekliliği vardır. Ancak tüm bu uygulamalar seçilen metodoloji ile ilgilidir, PMBOK tarafından zorlanan bir durum değildir.
 
Şekil-2 – Yazılım Geliştirme Şelale Yaklaşımı (Royce, 1970)
Çevik proje yaşam döngüsü ise iterasyon adı verilen sıralı proje fazlarından oluşur ve her bir fazın sonunda teslimat olarak “çalışan bir kod” ortaya çıkarılır. Şelale yaklaşımında tüm proje için sıralı olarak uygulanan aşamalar – analiz, tasarım, geliştirme, test- çevik projelerde geliştirilen kodun artımlı olarak devam ettirilmesi hedefiyle her bir faz için uygulanır.

Proje yaşam döngüsü tanımında yer alan “organizasyonların kontrol aşamalarına uygun olarak belirlenen sayıda” proje fazı ise çevik projelerde iterasyon süresi ve sayısı ile birebir aynıdır. Çevik yaklaşımlarda, iterasyon sayısı müşterinin belirli bir sürüm için kabul edeceği minimum fonksiyonalite baz alınarak belirlenir (MMF-Minimum Marketable Features). Müşterinin hangi sıklıkta ürünü kontrol etmek istediğine bağlı olarak 1 ila 4 haftalık iterasyonlar kararlaştırılabilir. Iterasyon süresinin tespitinde piyasa koşulları, ilgili sektör, risk seviyesi, ürün vizyonunun net olup olmaması gibi farklı kriterler de devrede olur.

Çevik projelerde proje yaşam döngüsünün (Şekil-3) başlangıç (Initiation Phase) fazında, ilk iterasyonun parçası olarak planlama süreci yer alır ve teslimat olarak “çalışan bir kod” ile birlikte proje için üst seviye bir proje planı sunulur. Ara (Intermediate Phases) fazlar ise “çalışan artımlı kod” şeklinde teslimatların yapıldığı sürüm ve/veya iterasyonlardan oluşur. Çevik projelerin en son fazı (Final Phase) ise tüm isterleri karşılayan ürünün üretime geçiş için yapılan son hazırlıkları, en son proje retrospektif toplantısı ve proje kapanış aktivitelerinden oluşur.
 
Şekil-3 – Çevik Proje Yaşam Döngüsünde- Faz ve Altfazlar (Agile Fractal)
Çevik projelerdeki herbir iterasyon, bir proje olarak değil projenin bir fazı veya alt fazı olarak değerlendirilebilir. Her iterasyon sonunda artımlı yaklaşım sayesinde ortaya çıkan sonucun değerlendirilmesi ve bir sonraki iterasyon öncesinde elde edilen sonuçların dikkate alınması ile daha doğru ve öğrenerek planlama yapılması mümkün olmaktadır. PMBOK ile tanımlanan “progressive elaboration-aşamalı olgunlaşma” kavramı tam da çevik projelerin “contionus improvement-sürekli iyileştirme” kavramı ile eşleşmektedir.
 
Süreç Grupları
PMBOK Rehberi’nde yer alan süreç grupları ayrı birer faz değildir. Süreç grupları, proje süresince iteratif olarak uygulanan ve gerektiğinde güncellenen bütünleşik süreçlerdir.
Şekil-4 – Plan-Do-Check-Act PMBOK Rehberi Süreç Grupları
Proje yaşam döngüsü gibi PMBOK ile tanımlı süreç grupları da çevik yaklaşımların proje, sürüm ve iterasyon seviyesinde uygulanan süreçler ile birebir örtüşmektedir.
 
Şekil-5 - Süreç Grupları ve Agile Fractal
Sonuç olarak; PMBOK Kılavuzu proje yönetiminde bilinen iyi pratikleri ve genel kabul gören standardları içermektedir.  Bu standardlar belirli bir metodolojiye özel oluşturulmamıştır. Maalesef, PMBOK ile sunulan pratikler ile yazılım geliştirme alanındaki farklı metodolojiler, özellikle şelale metodu birbiri ile ilişkilendirilmekte ve PMBOK Kılavuzunun şelale yaklaşımlara uygun pratikler sunduğu düşünülmektedir. Aslında doğru olan PMBOK Kılavuzu ile yazılım geliştirme metodolojileri karşılaştırmak değil, yazılım geliştirme metolodojilerini kendi aralarında kaşılaştırmaktır. Çevik yaklaşımlar uygulanırken de PMBOK ile sunulan genel kabul gören pratikleri ve önerileri dikkate alabiliriz.

Bir sonraki yazımızda; Çevik Proje Yönetimi ve Geleneksel Proje Yönetimi (şelale metodlara dayalı) yaklaşımları arasındaki temel farklılıkları “Agile Manifesto” ve prensiplerini dikkate alarak örneklerle açıklamaya çalışacağım.