Kaynak Kısıtı ve Bekleme Süresi Teorisi

#ProjeYönetimi‘nde kaynak kısıtlarına dair #Agile olmak için bilmeniz gereken bir teori:Bekleme süresi, kaynağın meşgul olduğu sürenin, boşta olduğu süreye bölünmesiyle elde edilir.Kaynak %50 dolu ise bekleme süresi 1 Birim/Saattir. Kaynak doldukça bekleme süresi katlanarak artar

 

Reklam

Agile Scrum Hakkında Notlarım

​Bir yazılım geliştirme projesi yaklaşımı olarak Agile Savunucularının mevcutta uygulanan sistemler hakkındaki görüşleri:
​İstenildiği ve planlandığı gibi yürümeyen ve geç biten projelere bir çözüm olarak düşünülüyor.
​Asıl sorunu bulmaya çalışırken mevcut sistemlerin gecikmeler ve aksaklıklara yol açtığını ve proje yöneticilerinin arada kalan taraf olduğunu tesbit ediyorlar.
​İş biriminin bt’yi suçlaması ve sıkıştırması ve yine iş biriminin pyo’yu yeterli bulmaması çıkarımının yanı sıra yine bt’nin de pyo’nun baskı uyguladığını söylediği şuan yaşanan sistemlerin sonucu olduğu vurgulanıyor.
​Bu sıkıntıların yaşandığı sistemlerde proje yönetim ofisinin hep arada kaldığı ve yıprandığı agile savunucuları tarafından dile getiriliyor.
​Agile SCRUM:
​Scrum, Agile yöntemlerinden biri ve kompleks problemleri çözümleyerek üretken ve yaratıcı bir şekilde olası en yüksek değerde ürünler üretilmesini sağlayan bir altyapı olarak tanımlanıyor.
​Scrum, yönetimsel bir alt yapı olarak tanıtılıyor ve bütünü itibariyle sürecin kapsamında proje yönetim tekniği dışında öğretiler olduğu vurgulanıyor.
​Scrum Master, scrum değer,pratik ve kurallarının uygulanmasını sağlayarak scrum takımının üretkenliğine destek olmaktan sorumlu olan kişi olarak tanımlanıyor.Bu pozisyon ilk bakışta proje yöneticisine denk geliyor gibi görünse de proje yöneticsinin donanımlı görev tanımından uzak bir görev tanımıyla yönlendirici, çözüm üretici olarak ekibi yönlendiriyor.
​Dönüşüm Hakkında:
​Agile scrum uygulamak için organizasyonların dedike personelin çalışacağı, süresinin ve paydaşlarının uygun olduğu pilot projelerle değişim aksiyon planlarının uygulanması gerektiği belirtiliyor.
​Bu değişim aksiyon planında dikkat edilecek en önemli noktanın bt’nin potansiyel görüşleri olduğu belirtiliyor. Bt’nin agile konusunu dokümansız ve kuralsız bir proje yönetim tekniği olarak algılaması ve proje yöneticisine yer olmadığı için pyo gibi birimlerin bu dönüşümü istemeyeceğini düşünüyor olması muhtemel görünüyor.
​Buna paralel bt’nin scrum masterları kendi içinden çıkararak geliştirme süreçlerini kendi içinde yürütmek agile’ın şeffaflık ilkesinden dolayı riskli görülüyor.
​Bu görüşler doğrultusunda organizasyonun agile altyapı sistemini kurabilmesi için proje yönetim ofisi gibi güçlü bağlantıları olan bir birimin desteğinin olması çok önemli görülmektedir.
​Scrum Süreci:
​Scrum takımının önemli üyelerinden Product Owner, üretilecek olan ürünün değerini optimize etmekten sorumlu kişi olarak görülüyor ve bu diğer yaşayan sistemlerdeki müşteri kavramına benzer şekilde ürünün gereksinimleri ve işleyişi hakkında bilgi vermesi gereken kişi olarak görünüyor fakat burda farklı olan aradaki bilgi alışverişinin çoğunun sözlü ve yüzyüze olması gereltiği ve yapılacak işin bitti kapsamı denen kabul kriterleriyle tarif edilmesi bekleniyor.
​Product Owner’dan specleri alan scrum geliştirme takımının çalışır durumdaki yazılım parçacığını geliştirmek için çalıştığı süre  Sprint olarak tanımlanıyor. Bu yapı yaşayan diğer sistemlerdeki aktiviteler bütününe denk geliyor olsa da farklı olan kısmı çalışan takımda geliştirici, analyst ve tester birlikte çalışıyor ve kullanıcıya gösterilen kısım tamamlanmış çalışır bir parça oluyor.
​Yaşayan diğer sistemlerde olduğu gibi scrum süreci de bir kick off toplantısıyla hazırlıklar yapılarak başlanıyor.
​Süreç başlangıcında takımın product backlog denen ürünün şekillenmesini sağlayacak her türlü isteğin üretilecek değeri optimize edecek şekilde önceliklendirilmiş olarak belirtildiği listenin çıkarılması ve bu listedeki öncelikli işlere sprint süresi tanımlanmasıyla başlıyor.
​Bu planlama çalışmasına sprint planlama toplantısı deniyor ve sprint sonlarında sprint review toplantısıyla ortaya çıkan yazılım değerlendiriliyor. Sprint sonlarında kaizen çalışma prensibi amacıyla retrospective toplantısı yapılarak sprint dahilindeki işlerin değerlendirilmesi ve iyileştirmeye yönelik adımlar konuşulabiliyor.
​Günlük kısa scrum toplantılarıyla, scrum geliştirme takımının bir araya gelerek senkronize olması ve sprint hedefine doğru ilerleyişin değerlendirilmesi isteniyor.
​Agile’ın yapılmasını istediği toplantılar mevcut sistemlerdeki durum değerlendirme toplantılarına benzetilebilir fakat mevcut sistemlerdeki diğer yönetim gereksinimleri ve dokümanları (risk, kalite, performans, tedarik yönetimi) üzerinde uzun konuşulacak ve zaman harcanacak çalışmalar olarak görülmüyor.
​Buradaki kapsamın çerçevesinin yazılım geliştirme projesi olduğu düşünüldüğünde  bu klasik dokümanlar ve çalışmalar gerekli görülmeyebilir fakat yaşanılan tecrübelere göre bu tür sorunlara scrum masterın çözüm bulması bekleniyor. Scrum master’ın zaten başarılı bir şekilde ekibi yönetebilmesi için geliştirici takımını tamamen bu işe ayrılmış kaynaklardan oluşturması gerektiği söyleniyor.
​Yine detaylardan bir diğeri de müşteri ve paydaş tarafının sürece aktif olarak dahil edilmesi gerektiği ve product owner denen kişinin bu sürece yeterince zaman ayırarak geliştirmelere bilgi sağlaması gerektiği. Scrum sürecinde yapılan her toplantının tüm katılımcılarının bir takım olma bilinciyle çalışmayı öğrenmesi gerektiği ve yaşanılan sorunlara takımın birlikte çözüm bulmayı öğrenmesi gerektiği vurgulanıyor.
​
​Bu sistemdeki diğer kavramlar ve işleyişlerde şu şekilde;

​Scrum Studio:İçerisinde sadece scrum uygulayan kişi ve ekiplerin bulunduğu, şirket organizasyonundan bağımsız, özerk bir yazılım geliştirme birimi.
​
​Grooming toplantısı:Scrum takımı tarafından product backlogun güncel bir şekilde varlığını sürdürmesi amacıyla yapılan çeki düzen toplantısı.
​
​Scrum Tahtası:Sprint ile ilgili yapılması gereken işlerin bulunduğu yer.
​
​Timebox:Bir işin yapılması için tanımlanmış belirli uzunluktaki maksimum zaman periyodu.(Klasik yöntemlerde aktivite süresi diyebiliriz fakat buradaki iş paketleri aktiviteler bütünü olabilir ve ayrıca proje planı olmadan projeler son tarihe kadar sürekli değişen belirsiz bir zaman planlamasıyla yürütülür.)
​
​Sprint Burn Down Chart: Sprint ile ilgili yapılması gereken kalan işlerin büyüklüğünün zamanla değişimini gösteren grafik.
​
​Agile altyapı sistemleri ve kullanımı ile ilgili araştırılabilecek ve detayları öğrenilmesi gereken konu başlıkları:
​
-​Agile portföy yönetim altyapısı nasıl çalışır?
-​Proje yönetim süreci olarak risk, tedarik , maliyet yönetimi nasıl yapılabilir?
-​Sdlc ile ilişkisi düşünüldüğünde analiz,tasarım,geliştirme ve geçiş sürecinin cobit gibi düzenlemelere uyumu nasıl yönetilebilir?
-​Özellikle dış kaynak ağırlıklı çalışılan projelerde agile yaklaşımı kendi içinde farklılaşabilir mi?
-​Dedike olmayan kaynaklarla agile süreç nasıl planlanır, nasıl yönetilir?