Kategori arşivi: Agile-Çevik

Proje Yönetiminde Taslaklar

Wireframes | Everything you need to know and how to explain it to customers

Proje doğru başlamak, başlangıçta erken geri bildirim almak önemlidir. İlgili paydaşlardan erken ve zamanında geri bildirim alınmadan, ihtiyaç ve beklentilerini karşılayan tatmin edici çözümler üretmek zordur. Paydaşları yorum yapmaya teşvik etmenin en iyi yollarından biri anlatmak yerine göstermektir. Çoğu kişinin yüzlerce sayfalık yazıları okumasını beklememek gerekir. Bunun yerine, onlara görsel olarak nihai hedefi sunmak gerekir.

Taslaklar, özellikle yazılım projelerinde kullanıcı arayüzündeki öğelerin yerleşimini, çözümün amaçlanan düzenini ve işlevselliğini gösteren basit diyagramlardır. Aşağıdaki soruları yanıtlamaya çalışırlar:

  • Kullanıcı arayüzünde hangi öğeler görüntülenecek?
  • Öğeler nasıl organize edilecek?
  • Arayüz nasıl çalışacak?
  • Kullanıcı uygulama / web sitesi ile nasıl etkileşime girecek?

Taslaklar, imalat için hazırlanan maketlerdeki gibi ayrıntılar içermezler. Taslaklar ele alınması gereken kavramsal sorulara odaklanılmasına yardımcı olurlar.

Kimler Kullanır?

  • Müşteriler – Neyin geliştirileceğini daha iyi anlar ve çözümün ihtiyaçlarını yeterince karşılayıp karşılamadığını değerlendirebilirler. Bir şeylerin eksik olup olmadığını, hangi eylemlerin mevcut olduğunu ve nasıl bir araya getirildiğini görebilirler. Taslaklar, daha önce dikkate alınmayan önemli hususları gündeme getirebilirler.
  • Proje Yöneticisi – Tüm paydaşların aynı sayfada olmasını ve neyin oluşturulacağı konusunda hemfikir olmasını sağlayabilirler. Proje ilerledikçe, ilerlemeyi takip etmek ve önemli her şeyin düşünüldüğünü ve uygulandığını doğrulamak için taslakları kontrol listesi olarak kullanabilirler.
  • Ekip Üyeleri – Çözümün işlevselliğini ve teknik gereksinimlerini daha iyi anlarlar.

Taslaklar, kağıda kaba eskizler çizerek hazırlanabilirler.

Avantajları

  • Mevcut taslaklar yeniden düzenlemeyi ve üzerlerinde yinelemeli çalışmayı hızlı ve acısız hale getirirler.
  • Düğmeler, tablolar, açılır menüler vb. öğeler için şablonlar sağlarlar.
  • İşbirliğini ve ekip genelinde tutarlılığı korumak için kolayca paylaşılabilir.

Çevik Projelerde Taslaklar

  • Taslaklar, Çevik zihniyetle mükemmel uyum sağlarlar;
  • Farklı disiplinlerdeki ekip üyeleri arasında aktif olarak iletişim kurmaya ve birlikte çalışmaya teşvik ederler.
  • Ayrıntılı, kapsamlı belgeler yerine hafif, sindirimi kolay çizimlerdir.
  • Kullanıcılardan ve müşterilerden erken ve sürekli geri bildirim almayı teşvik eder.
  • Nihai tasarıma dönüşen kaba eskizlerle başlayan yinelemeli yaklaşıma izin verir.

Başlangıç Sprintinde vizyonu ve bu vizyona giden yolun ana hatları çizilerek başlanabilir. Ekip temel ayrıntı düzeyinde ilk taslaklarını oluşturur ve kullanıcılarla ele alabilir. Buradaki amaç, tüm ürünü baştan tasarlamak değil, proje hedeflerinin anlaşılmasını ve tüm paydaşların katılımını sağlamaktır. Büyük resim daha sonra kademeli olarak detaylandırılır ve sonraki yinelemelerde uygulanabilir.

Wireframing: 10 Best Practices and Guidelines | WebTek Blog

Dikkat Edilmesi Gerekenler

  • Taslakları güzelleştirmekle vakit kaybetmeyin.
  • Erken ve sık geri bildirim almak için ayrıntıdan uzak basit hazırlayın.
  • Temel fikri içeren kaba eskizlerle başlayın, geri bildirimlerle detaylandırın.
  • Temel amaç tartışmayı teşvik etmek ve yeni fikirler üretmektir, başka konulara dalmayın.
  • Kullanıcının bakış açısını, hedef kitlenizi odağınıza alın.
  • Taslaklar üzerinden hemen denemeler yapın, hata yapmaktan çekinmeyin.
  • Taslakları açıklayıcı notlar ekleyin.
  • Taslakları, pano formatında kullanarak geri bildirimi kolaylaştırın.
  • Amacını açıklamadan taslağı paylaşmayın.

What is a Wireframe and How to Create Wireframes

Taslaklar, projeyi başlatmak ve projenin neyi başaracağı konusunda fikir birliğine varmak için kullanılırlar. İnsanların fikirlerini zihinlerinden alıp ekip arasında tartışılabilecek, gerekirse gözden geçirilebilecek veya atılabilecek somut bir forma sokmaya yararlar. Taslakların oluşturulması ve değiştirilmesi yalnızca hızlı ve kolay olmakla kalmaz, yapı ve işlevsellik ile ilgili “büyük resme” odaklanmaya yardımcı olur.

Türkçe eğitimler

İngilizce eğitimler

Geleneksel ve Çevik Proje Yönetimi Yaklaşımlarında Proje Başlatma Belgesi

Write A Project Charter: How-To Guide, Examples & Template | by Digital  Project Manager | The Digital Project Manager | Medium

Hem Çevik hem de Geleneksel yöntemlerde resmi bir başlangıç süreci ve başlatma belgesi vardır.

Geleneksel yaklaşımda, projeye başlamak, proje yöneticisini yetkilendirmek için proje başlatma belgesi gereklidir. Başlatma belgesi iş gerekçesine dayalı bilgileri, başarının ve hedeflerin tanımını, kilometre taşlarını, üst seviye riskleri, zaman ve bütçeyi içerir.Geleneksel proje yaklaşımında Proje Başlatma Belgesi yayınlanmadan proje başlamaz.

Proje Başlatma Belgesi henüz detaylı planlama olmasada en azından sonucun ne olması gerektiğini görmeyi sağlar. Planlama sürecinde gereksinimler toplandıktan sonra, proje yöneticisi proje kapsam bildirimi hazırlar, kapsam içinde ve dışında olan işleri netleştirir. Bu yaklaşım kapsamı kesinleştirmeye yöneliktir.

Çevik projelerde kapsam net olmadığı için Başlama belgesi basit, esnek ve gerektiğinde güncellenebilirdir. Projenin sonucuna ilişkin zemini sunar. Ekibin kapsam değişene kadar aynı sayfada kalması içindir. Geleneksel projelerde Proje Başlatma Belgesine aykırı bir değişiklik kabul edilmez veya kabul edilirse mevcut proje kapatılır, yeni bir proje başlatılır.

Geleneksel ve Çevik başlatma belgelerinin ortak noktası, projeye sponsor olan kuruluşun mali kararı vermek için kullandığı proje seçim teknikleridir.

Projenin başında ve proje süresince paydaş katılımının sağlanması için her iki yaklaşımda da Başlatma Belgesi gereklidir.

Her iki yaklaşımda da, mevcut ve kilit paydaşları süreçlere dahil etmek ve kim, ne, nerede, ne zaman, neden ve nasıl hakkında genel bir anlayış ve anlaşma oluşturmak için resmi bir başlangıç noktası olmalıdır. Böylece, projenin çok erken aşamalarında açık ve şeffaf iletişim ve fikir birliği oluşturmanın önünü açılabilir.

Geleneksel ve Çevik Proje Başlatma Belgeleri

Geleneksel Proje Başlatma Belgesi

  • Proje Adı:
  • Yönetici Özeti: Proje genel bakış açısını ve yapılacakları özetleyen bölümdür. Projenin neden gerekli olduğunu özetleyerek, gerekçelendirir.
  • Proje Açıklaması – Projeye ilişkin genel bir açıklamadır.
  • Hedefler ve Başarı Kriterleri: Bu, kar vb. finansallardan, ürün/hizmet/sonucun ne olacağına veya ne için kullanılacağına kadar her şey olabilir.
  • Organizasyonel Etkiler – Piyasaya ilk giren olmak, sözleşme yükümlülüklerini yerine getirmek veya yasal düzenlemeyi karşılamak vb. olabilir.
  • Teslimatlar – Proje çıktısı ürün veya hizmetin tanımı, fiili belgeler veya diğer çıktılar olabilir.
  • Üst Seviye Maliyetler ve Süreler – Maliyetler, iş gerekçesi veya fizibilite çalışmalarından, süreler genellikle müşteriden veya kilometre taşlarından gelebilir. Her iki tahmin de iyimser olma eğilimindedir.
  • Varsayımlar ve Kısıtlar – Risklerin belirlenmesine yardımcı olmak ve ayrıca sponsorun/kuruluşun/müşterinin projede ne olacağını varsaydığının bilinmesini sağlamak içindir. Kısıtlar, proje çalışmasını bitirmek için yeterli kaynak olmaması, yasalar veya mutlak tarihler gibi projeyi sınırlayan konulardır..
  • Üst Seviye Proje Riskleri – Öngörülen ve çoğunlukla deneyime dayalı risklerdir.
  • Proje Yaklaşımı – İhtiyaç duyulan aşamalar veya süreçler hakkında genel ifadedir. Ayrıca resmi değişiklik kontrol yaklaşımını içerebilir.
  • Proje Yöneticisi ve Yetki Düzeyi – Proje Yöneticisine proje çalışmasına başlaması için verilen resmi yetkidir.
  • İmzalar – Sponsor ve diğer kilit paydaşların imzalarıdır.

Proje yöneticisinin ve kilit paydaşların, Gelenek Proje Başlatma Belgesinin oluşturulmasına katkıda bulunurlar, sponsor yayınlar.

Çevik Proje Başlatma Belgesi

  • Kim – Kilit paydaşlar, ekip ve müşteri vb. şu anda kimlerin olduğudur.
  • Ne – Bugün başarının neye benzediğinin üst düzey bir tanımıdır. Projenin hedefleri ve vizyonu, değişebileceği varsayımıyla açıklanır.
  • Nasıl – Projenin nasıl yürütüleceğidir. Scrum, XP vb. olabilir. Müşteri ve kilit paydaşların iş akışının arkasındaki “nasıl”ı anlamalarını sağlamak içindir.
  • İmzalar ve Tarih – Çevik proje başlangıcı için gerekli olan resmi yetkiye sahip kişilerin imzalarıdır.

Çevik proje başlatma belgesinde ayrıntılara daha az odaklanılır, bugün bilinenlerin kısa açıklamalarına daha fazla odaklanılır. Daha az kapsam, daha esnek ve daha az bilgilendiricidir. Çevik proje yönetimi şeffaf ve etkileşimli iletişime odaklandığından, amaç bilgiyi erkenden ve sıklıkla bilindiği gibi paylaşmaya teşvik etmektir. Ekip, başlangıçta bulabilecekleri soruları yanıtlayacak ve ihtiyaç duydukları açıklamalar için kendi sorularını soracaklardır.

Türkçe eğitimler

İngilizce eğitimler

PMP Hazırlık – Çevik Yöntemler – Uyarlanabilir Yazılım Geliştirme (UYG)

Premium Vector | Adaptive software development and programming programmers  testing and developing cross platform

Jim Highsmith, Uyarlanabilir Yazılım Geliştirme: Karmaşık Sistemleri Yönetmede İşbirliğine Dayalı Yaklaşım adlı kitabında, etkili ekip çalışması, planlama ve değişen koşullara hızlı uyum sağlama yeteneği ile ilgili olarak dağ tırmanışı benzetmesini kullanır. Uyarlanabilir yazılım geliştirme, Deming/Shewhart’ın Planla-Uygula-Kontrol Et-Uygula döngüsü yerine tekrarlayan yinelemeleri, işbirliğini ve öğrenmeyi önerir. PMBOK ® Kılavuzunda bulunan planlama, yürütme, izleme ve kontrol ve kapanış süreç gruplarınının sürekli iyileştirme ve uyarlama ihtiyacını yansıtttığını söylemektedir.

UYG yaşam döngüsünün özellikleri, görev odaklı, özellik tabanlı, yinelemeli, zaman sınırlamalı, risk odaklı ve değişime toleranslı olarak ifade edilir.

Uyarlanabilir Yazılım Geliştirme Döngüsü

Hızla değişen koşullar, uyarlanabilir ve esnek olma ihtiyacını zorunlu kılmaktadır. Uyarlanabilir yazılım geliştirme döngüsü, yazılım geliştirmedeki sürekli uyarlamayı çok basit bir şekilde ele alır.

Adaptive software development (ASD) phases, adapted from Pressman (2001) |  Download High-Quality Scientific Diagram

Yazılım geliştirilir, ilerledikçe, görüşmeler ve işbirliği yaparak, öğrenerek uyum sağlanır. Döngü biraz belirsiz görünse de, çevik yaklaşımlarda çalışan herkesin sürekli kendinizi kontrol etmesi, işbirliği yapması, iletişim kurması, hem başarılardan hem de hatalardan öğrenmesi gerektiğini vurgulayan etkili ve uyarlanabilir bir yoldur.

  1. Tahmin Etme: Proje başlatılır ve ilk bilgilerle uyarlanabilir döngü planlaması yapılır. Örneğin müşteri, ne beklediğini açıklar. Zaman, maliyet, kapsam ve kalite gibi tipik proje kısıtlamaları gözden geçirilir. Temel gereksinimler, proje için gerekli olacak sürümleri veya yazılım artışlarını tanımlamak için belgelenir. Müşterilerin her zaman fikirlerini değiştirebilirler. Yapılacak görüşmeler (spekülasyon) bir yönün seçilmesine ve değişikliklerin olacağını bilerek ve onları kabullenerek ilerlemeye izin verir.
  2. İşbirliği yapmak: Belirsizliğe uyum sağlamak gibi, her çevik projede işbirliği çok önemlidir. Teknoloji, gereksinimler, kapsam değişiklikleri, riskler, paydaşlar ve satıcılar/tedarikçilerle açık diyalog gereklidir.
  3. Öğrenme: Hata yapmak ve hatalardan öğrenme yeteneğidir. Statükoya ve hatta gerekirse paydaşlara meydan okunur. Hızlı tasarım, yapı ve test yinelemelerle çalışılır. Yinelemeler sırasında, yanlış varsayımlara dayalı hatalar yapıldığında, düzelterek bilgi toplanır. Bu yaklaşım, sorunun bulunduğu alanda daha iyi bir deneyim ve değerlendirmeye, nihai ustalığa yol açar.

Aşağıda UYG ile ilkeler yer almaktadır;

  • UYG, planlamaya daha az, sürece daha fazla odaklanır.
  • Sürecin ve işin sürekli uyarlanması temel prensiptir.
  • UYG, geleneksel yaklaşımı tekrar eden bir dizi görüşme(spekülasyon), işbirliği ve öğrenme döngüsüyle değiştirir.

Türkçe eğitimler

İngilizce eğitimler

PMP Hazırlık – Çevik Yöntemler – Kristal Metodlar

Crystal Agile Methodology: Your guide to the Crystal framework in Agile

Kristal metodlar, 1990’ların ortalarında Alistair Cockburn tarafından geliştirilmiştir. Cockburn tarafından yıllarca süren çalışma ve ekiplerle yapılan röportajlardan ortaya çıkmıştır. Cockburn, projeleri başarılı kılan konuları bir araya getirmiştir. Kristal metodlar “hafif metodolojiler” olarak kabul edilir ve tanımlanır.

PMP sınavında kristal yöntemlere özgü herhangi bir soru çıkmaz ancak metodolojinin daha kritik projeler için daha detaylı bir süreci uyarlamaya odaklanmasını yansıtan sorular çıkabilir. Proje ve ekip ne kadar büyükse, uygulanacak metodoloji ağırlaşır, kritiklik seviyesi artar. Kristal metodlar, projenin ihtiyaçlarına bağlı olarak kritiklik seviyesinde değişiklik gösterir. Ozmotik iletişim (kulak kabartmak) felsefesinin kaynağı bu metodlardır.

Kristal Ailesi Renk Kodları

Kristal metodlar, ekip boyutuna ve projenin kritikliğine göre özelleştirilmiş “renk kodlu” metodolojiler ailesidir. Proje değerlendirildikten sonra ilgili ölçeğe göre yöntem seçilir. Renk kodları, devletlerin alarm sistemine benzer yani terör uyarısında kodun kırmızı olması herkesin yüksek alarmda olması gerektiğini gösterir.

Çok kritik ihtiyaçları olan bir proje varsa, o zaman modelin sonuç için etkili bir şekilde çalışabilecek bir detay seviyesinde ölçeklendirmem gerekir. Proje ne kadar kritikse, süreci detaylandırma ihtiyacı da o kadar fazla olur. Proje ne kadar az kritikse, ölçeği küçültme ihtiyacı o kadar büyük olur. Kristal esnek bir model olup neyin kullanılacağına karar vermek, projenin kritikliğine ve işi uygun şekilde tamamlamak için hangi ölçekte ele alınmasının gerekli olduğuna bağlıdır. Kristal ailesi Net Kristal ile başlar ve Kristal Safir ile biter;

  1. Net Kristal – Daha küçük projeler
  2. Kristal Sarı
  3. Kristal Portakal
  4. Kristal Turuncu
  5. Kristal Kırmızı
  6. Kristal Bordo
  7. Kristal Elmas
  8. Kristal Safir: Kritik Görev

What is Crystal Method in Agile and How it is different?

Kişisel web sitesi vb. küçük, kritik olmayan projede Kristal Net, Mars’a giden bir araç projesinde Kristal Safir tercih edilir.

Kristal, proje yaşam döngüsü, gerekli/isteğe bağlı bütçe vb. kategorilere dayalı bir puan sistemi kullanarak hangi projenin hangi renkte olduğunu belirlemek için düşükten yükseğe “kritiklik” değerlemesini kullanır. Puana göre, projenin ne kadar kritik olduğuna karar verilir. Ardından ilgili seviyeye uygun en iyi uygulamalarından yararlanılır. Kristal gibi ölçeklenebilir bir model, Çevik yaklaşımlardaki en iyi uygulamalar için kullanılabilecek en rahat ve uyarlanabilir metodolojidir.

Crystal Methods - Wikiversity

Renk kodunu belirlemenin dışındaki en büyük odak, ekip çalışması, iletişim ve basitliktir. Geri bildirimler, süreci ayarlamak ve iyileştirmek için sıklıkla kullanılır.

Kristal, çalışan yazılımın erken ve sık teslimini, yüksek kullanıcı katılımını, uyarlanabilirliği ve bürokrasinin veya dikkat dağıtıcı unsurların ortadan kaldırılmasını destekler.

Diğer Çevik yöntemlerdeki geri bildirim, iletişim, erken ve sık teslimat, değişikliklere uyum sağlama ve işleri basit tutma üzerine odaklanır.

Aşağıda Kristal yöntemlere ilişkin ilkeler Görülebilir;

  • Kristal, en hafif ve uyarlanabilir Çevik metodolojidir.
  • Seçimler, ekip büyüklüğü, sistemin kritikliği ve proje öncelikleri gibi çeşitli faktörler tarafından yönlendirilir.
  • Kristal temel ilkeleri ekip çalışması, iletişim ve basitliği içerir.
  • Geri bildirim, süreci ayarlamak ve iyileştirmek için sıklıkla kullanılır.
  • Kristal, çalışan yazılımın erken ve sık teslimatını teşvik eder: yüksek kullanıcı katılımı, uyarlanabilirlik ve bürokrasinin veya dikkat dağıtıcı unsurların ortadan kaldırılması.
  • Ozmotik iletişim, Kristal’de, özellikle daha yüksek kritiklik veya daha büyük ekiplerle yüksek oranda kullanılır.

Türkçe eğitimler

İngilizce eğitimler

 

PMP Hazırlık – Çevik Yöntemler – Özellik Odaklı Geliştirme (ÖOG)

What is Feature Driven Development (FDD)? - Agile Methodologies

ÖOG, Jeff De Luca tarafından büyük ekiplerin çevik yaklaşımları uygulamaları ve süreçlerini iyileştirmelerine yardımcı olmak için oluşturuldu.

Büyük ekipler, küçük ekiplerden daha fazla iletişim kurmak zorundadırlar ve daha çok zorluklarla karşılaşırlar.

ÖOG’nin Beş Süreci

FDD Full Form - GeeksforGeeks

  1. Genel Bir Model Geliştirme: İlk sprintte (Iteration Zero) veya yinelemede ilk adım görevler için bir model geliştirmek, uygulamada kalite kontrollerinin nasıl gerçekleşeceğini ve çözülmesi gereken sorunları belirlemektir.
  2. Özellikler Listesi Oluşturma: Özellik, geliştirilmesi gereken müşteriye değer katan işlevdir. Yazılma şekli < eylem> <sonuç> <nesne>dir. Ekibin tam olarak neyi gerçekleştireceğine odaklanmasına ve değer sağlayan ana özellikler üzerinde fikir birliğine varmasına olanak tanır.
  3. Özelliğe Göre Planlama: Planlamanın veya ilk yinelemenin son adımıdır. Başlangıç zaman çizelgeleri ve atamalar belirlenir. Planlama ekibi, mevcut iş değerine göre özellikleri sıralar ve nasıl gerçekleştirileceğini belirler.
  4. Özelliğe Göre Tasarlama: Her bir özellik için tasarım yapılır. Baş yazılımcı, iki hafta içinde geliştirilecek küçük bir özellik grubu seçer, ancak inceleme için biraz zaman ve alan bırakır.
  5. Özelliğe Göre Oluşturma: Değerli işlev (özellik) gerçekleştirilir.

Proje yönetiminde uyarlama yapmak özellikle ilk yinelemenin tekrarlanması büyük ekiplerde yanlış konularda çok fazla zaman ve para harcamamayı önce stratejiyi belirleme ve proje boyunca yolda kalmayı sağlar.

ÖOG’de En İyi Uygulamalar

  1. Etki alanı nesne modellemesi
  2. Özelliğe göre geliştirme
  3. Bireysel sınıf (Kod) sahipliği
  4. Özellik ekipleri
  5. Denetimler
  6. Yapılandırma yönetimi
  7. Düzenli yapılar
  8. İlerleme ve sonuçların görünürlüğü

1.Etki Alanı Nesne Modellemesi: Çözülecek problemlerin etki alanını araştırmak ve açıklamak, genel bir çerçeve ve yaklaşım sağlar. PMBOK®’taki Başlatma sürecine benzer.

2.Özelliğe Göre Geliştirme: İki hafta içinde uygulanamayacak kadar karmaşık olan işlevler, daha küçük işlevlere ayrıştırılır. Daha büyük bir çıktıyı aktivite düzeyine ayrıştırmak anlamında iş kırılım yapısına benzer

3.Bireysel Sınıf (Kod) Sahipliği: Yazılımcı/geliştirici, diğer metodolojilerde bulunan toplu kod sahipliğinin aksine, kodun tutarlılığından, performansından ve kavramsal bütünlüğünden bireysel olarak sorumludur.

4.Özellik Ekipleri: Aktiviteyi gerçekleştiren ve bir özellik üzerinde çalışan, küçük, dinamik ekiplerdir. Birlikte çalışan büyük bir ekip yerine, çapraz işlevli ekip üyelerinin aynı sonuç üzerinde birlikte çalışmasıdır.

5.Denetimler: Kusurları tespit ederek mükemmel kalite, tasarım ve kod sağlamaktır.

6.Konfigürasyon Yönetimi: Bugüne kadar tamamlanan özelliklerin belirlenmesi ve değişiklik geçmişinin tutulmasıdır. Konfigürasyon yönetimi, birçok Çevik proje türünde görülmeyen ürün değişikliklerine özgü bir tür resmi değişiklik kontrol sistemidir.

7.Düzenli Yapılar: Güncel çalışmalar müşteriye sunularak entegrasyon hatalarının erkenden fark edilmesini sağlar. Kurulan yapı ne kadar düzenli olursa, o kadar fazla geri bildirim alınabilir.

8.İlerleme ve Sonuçların Görünürlüğü: Sık ilerleme raporları, projeye doğru şekilde odaklanılmasına yardımcı olur. İlerlemenin ve sonuçların şeffaf bir şekilde sunulması, herkesin yolda kalmasını ve hedefe odaklanmasını sağlar.

Aşağıdakiler, ÖOG ile ilgili yol gösterici ilkelerdir;

  • ÖOG, artırımlı teslimata yönelik üst düzey planlama içerir.
  • Her artış bir tasarım ve uygulama aşamasına sahiptir.
  • Her artışın kapsamı tek bir özelliktir.
  • ÖOG başlangıçta genel kapsamı tanımlar, ayrıntıları tanımlamaz.
  • ÖOG, özellik geliştirme yinelemesini yürütmeden önce süreci oluşturmak ve onaylamak için bir Başlangıç Yinelemesi içerebilir.

Türkçe eğitimler

İngilizce eğitimler

 

PMP Hazırlık – Çevik Yöntemler – Yalın Ürün_Yazılım Geliştirme

Lean Project Management For Remote Team Productivity

Mary ve Tom Poppendieck tarafından yazılan Yalın Yazılım Geliştirme: Çevik Araç Kiti (Addison-Wesley Professional, 2003), orijinal Yalın ilkelerini, araçları ve teknikleri diğer Çevik yöntemlerle karşılaştırır.

Yalın, tümü olmasa da çoğu Çevik yöntemde kolayca uyarlanır ve kullanılır.

Yalın’ın Yedi İlkesi

  1. İsrafı Ortadan Kaldırmak: Değeri en üst düzeye çıkarın.
  2. Öğrenmeyi Güçlendirmek: Sık İletişim ve Geri Bildirim Yoluyla
  3. Olabildiğince Geç Karar Vermek: Erken Planlama, Geç Karar Verme
  4. Olabildiğince Hızlı Teslim Etmek: Yatırımın Getirisini En Üst Düzeye Çıkarın.
  5. Ekibi Güçlendirmek: Kendi Kendini Yöneten ve Güvenilir Ekipler kurmak.
  6. Kaliteyi İnşa Etmek: Kalite Kontrolden Çok Kalite Güvencesine odaklanmak
  7. Bütünü Görmek: Bir sistemin parçalarını değil, sistemi görün.

Yalın Çevikliği Nasıl Tamamlar?

Yalın, Çevik’i dört farklı şekilde tamamlar ve tüm değer akışı boyunca akış verimliliğini optimize etmek için çalışır;

  • Doğru ve değerli olanı yapın: Müşterilerin elde edeceği değeri anlayın ve sunun.
  • Hızlı yapın: Müşteri ihtiyacından teslim edilen çözüme kadar geçen süreyi azaltın.
  • Doğru yapın: Otomatik test, entegrasyon vb. ile kalite ve hızı garanti altına alın.
  • Geri bildirim yoluyla öğrenin: Ürün tasarımını erken ve sık uçtan uca geri bildirime dayalı olarak geliştirin.

Yalın, özellikle çerçeveyi hafif ve esnek tutmaya çalışan birçok Çevik yöntemi etkilemiştir. Yalın, belirli bir Çevik metodolojiden ziyade Kanban metodolojisinin ve çekme sisteminin bir varyasyonudur.

Yalın Üretimde Yedi İsraf

Üretimdeki amaç, her şeyi yalın tutmaktır. İsraf, değerin tersidir. Yalın üretimde yedi israf Shigeo Shingo’nun A Study of the Toyota Production System adlı çalışmasında (Productivity Press, 1989) tanımlanmıştır;

  1. Aşırı üretim
  2. Ekstra işleme
  3. Taşıma
  4. Bekleme
  5. Hareket
  6. Kusurlar
  7. Envanter
  8. Aşırı Üretim: Talepten fazlasını üretmek, organizasyonlara her yıl sadece para olarak değil, aynı zamanda işçilik, parça ve artan stoklar açısından maliyet yaratır. Değişken bir pazarda ne kadar üretilmesi gerektiğini tahmin etmek önemlidir. Aşırı üretim yapmamak için daha iyi tahmin yöntemleri gereklidir ve Kanban çekme sistemi yaklaşımı bu ortamda iyi çalışır.
  9. Ekstra işleme: Süreçte gerçekten ihtiyaç duyulmayan ek adımlardır. XP’nin yazılım geliştirmesindeki sürekli entegrasyon uygulaması gibidir. İşler karmaşıklaşıyor veya süreç adımlarında çok fazla zaman harcıyorsanız, süreci iyileştirmek ve değer akışını basitleştirmek gerekir. Değer akışı, konseptten teslimata kadar olan süreci ifade eder. Müşteriye değer ürettiğimiz akıştır. Süreçte gereksiz adımlar varsa değer akışı doğru şekilde akmayacaktır. Değer akışı haritalama, mevcut sisteme bakmanın ve daha sonra daha etkili bir sistemi tasarlamanın yalın bir yoludur.
  10. Taşıma: Ürün parçasının bir yerden diğerine nakliyesidir. Birçok kuruluş, bir ürünün bir parçasını üretir ve daha sonra onu farklı bir yere taşır. Bu süreçte aktarmaları azaltmak gerekir.
  11. Bekleme: Süreç adımları arasındaki gecikmedir. Kendi işinize başlamadan önce başka birinin işini bitirmesini beklemek zorundaysanız ve sonra kendi işinizi yapmak için sınırlı bir zamanınız varsa, sıkıntı var demektir. Beklemek zaman kaybıdır.
  12. Hareket: Süreç içinde ilerlemektir. İki nokta arasındaki en kısa mesafe düz çizgidir. Çok fazla hareket veya fazladan adım, kusurlara ve zaman kaybına neden olur. Şelale vb. Yöntemlerde fazla uygulama ve belge olabilir. Uzun vadeli, kapsamı belirli projelerde en iyi uygulamalardır, ancak Çevik projelerde etkili olmayı olumsuz etkiler.
  13. Kusurlar: Ürünlerin özelliklerini/işlevlerini etkileyen kusurlardır. Kusur onarımı pahalıdır. Kuruluşlar, sürecin kalite güvencesi ve kalite kontrol prosedürleri yoluyla kaliteli çıktılar ürettiğinden emin olmak için önceden para harcarlar. Arızalı parça, ekipman ve ürünlerde de kusurları düzeltmek için harcama yapmak zorunda kalırlar.
  14. Envanter: Bitmemiş mallar envanterde kalır ve satılmaz. Kullanılmayacak veya bitmeyecek öğeleri elde tutmak, başka şeyler için kullanılabilecek değerli öğelerin israfına yol açar.

Yalın Yazılım Geliştirmede Yedi İsraf

Lean software development – parent or child of the Agile movement?

Yalın yazılım geliştirmenin amacı, süreçteki ve üründeki zaman kaybını, ekstra adımları veya genel sorunların sebebine yönelik sorulara sürekli olarak cevap vermektir.

  1. Kısmen yapılan iş
  2. Ekstra özellikler
  3. Yeniden Öğrenme
  4. Aktarmalar
  5. Gecikmeler/bekleme
  6. Görev değiştirme/hareket
  7. Kusurlar

Yazılım geliştirme sisteminden atıkları kaldırmak ve sürekli iyileştirmeye odaklanmak gerekir.

1.Kısmen yapılan iş – Bitti tanımını karşılamayan ürünler, piyasaya sürülemez veya kullanılamaz. Bunun nedeni, plandan önce teknolojinin ne kadar karmaşık olduğunu fark etmeyip zaman ve kaynak israf etmektir.

  1. Ekstra Özellikler: Herhangi bir projede altın kaplama büyük hatadır. Altın kaplama, müşteriye talep etmedikleri ekstra özellikler veya ilave işlevsellik kazandırmaktır. Vizyonu, hedefi, son kullanıcıyı anlamadığınızı ve/veya değeri yanlış bir şekilde önceliklendirdiğinizi, yanlış spesifikasyona göre ürettiğinizi gösterir. Altın kaplama, kalite ve kapsam kayması ile sonuçlanacak, zaman veya para kaybı olacaktır. Altın kaplamadan kaçınmak gerekir.
  2. Yeniden öğrenme: Öğrenme değer sağlar ve mümkün olduğunca çok şey öğrenmek önemlidir. Ancak zaten bildiğin bir şeyi yeniden öğrenmek zaman kaybıdır. Belge eksikliği, kötü kodlama uygulamaları ve ekip üyeleri arasında görev geçişleri vb. Bilinen şeyi yeniden öğrenmeye zorlar ve kaos yaratır.
  3. Aktarmalar: Kuruluşta, hiyerarşik süreçler dizisi, çok fazla dağınık ekip üyesi varsa ve bilgiler iyi bir şekilde dağıtılmıyor veya görünür değilse, kaos vardır. Çevik projeler çapraz fonksiyonel ekipler kullanılarak etkin bir şekilde yönetilebilir. Ekibin tüm işlevlerde etkili olması için ihtiyaç duyduğu tüm bilgilere sahip olduğu anlamına gelir. PMP sınavında dağınık ekiplerle ilgili sorular görebilirsiniz. Ekip üyelerinizi birden fazla lokasyondaysa, devirleri en aza indirmek için her bir lokasyonda çapraz işlevli çalışanlardan oluşan bir ekibe sahip olmanın en iyi uygulama olduğunu unutmamak önemlidir.
  4. Gecikmeler: Gecikmeler işi yapacak yeterli sayıda insan olmamasından veya bir yinelemede başarılabilecekten çok daha fazla iş seçmekten kaynaklanır. Dış bağımlılıklar kaynaklı gecikmeler deneyimi eksikliğinden veya sadece genel tahmin yapmaktan kaynaklanır.
  5. Görev Değiştirme: Çoklu görev, aslında oldukça zor olduğu halde süper üretken olduğu düşünülür. Görev değiştirme, birden fazla proje hakkında vizyon sahibi olmanız beklenirken ortak bir vizyona sahip olmanızı imkansız hale getirir. Görev değiştirme israf yaratır. Devam eden çok fazla proje, yetersiz tahmine, kötü analize ve ortak vizyon eksikliğine yol açar.
  6. Kusurlar: Hiçbir şey, kusurlardan daha fazla israf yaratmaz. Ortak bir vizyona sahip olmak ve müşterinin ne istediğine dair gerçek bir anlayışa sahip olmak gerekir. Kalite güvence sürecini takip ederek, sürecin çalışıp çalışmadığını sürekli olarak denetlemek ve kusurları kalıcı olarak çözerek sürekli iyileşme sağlanabilir. Yeniden düzenleme, kodun çalışma şeklini değiştirmeden kodu değiştirmektir. Sürekli entegrasyonla ve kodun mümkün olduğunca basit olmasını sağlamakla ilgilidir. Bu sayede gözden geçirme, test etme ve değiştirme kolaylaşır.

Sürekli İyileştirme

Kanban, Lean veya diğer çevik yaklaşımlarda sürekli iyileştirme yöntemleri bulunur. Amaç, süreçte ve sonuçlarda israfa veya iyileştirme eksikliğine neyin neden olduğunu bulmaktır. Yalın’da, çoğu zaman süreçte, envanterde, ekipte ve üründe israf olabilir. Bundan kaçınmak için bazı felsefelere bakılabilir;

  1. Kısıtlar Teorisi (TOC): Süreç akışındaki darboğazların ve kısıtlamaların belirlenerek yeniden yapılandırılmasıdır. Teori, süreç akışında, israf yaratan ve sürecin kendisinin uygulanmasını engelleyen darboğazları nasıl keşfedebileceğinizi açıklar. Kısıtlamaların ne olduğunu öğrendikten sonra, süreç akışınızı iyileştirmek, savurgan veya gereksiz adımları ortadan kaldırmak ve daha kaliteli artımlar üretmek için çalışabilirsiniz.
  2. Derin Bilgi Sistemi: W. Edwards Deming’in varyasyon ve süreçleri nasıl etkilediği üzerine yaptığı bir çalışmanın başlığıdır. Deming, kalite yönetiminde en iyi uygulamaların sürekli iyileştirilmesi için Shewhart’ın Planla-Uygula-Kontrol Et-Uygulama döngüsünün uyarlanmasından yararlanmıştır. Döngü aynı zamanda geleneksel planlama, yürütme, izleme ve kontrol yaklaşımını takip edecek şekilde çevrilebilir. Derin Bilgi Sistemi, büyük resmi görmek için dört mercek kullanır:
  3. Kullanılan süreçleri anlayarak bir sistemi anlamak.
  4. Varyasyonu, kusurların neden oluştuğunu anlamak. Örneğin seri üretimde istatistiksel örnekleme, popülasyonun bir bölümünü temsil edecek bir sonucun gözden geçirilmesine izin verir. İncelemek ve tolerans seviyelerini karşılayan bir aralık olup olmadığına bakmak gerekir.
  5. İnsan davranış psikolojisini ve teorilerini anlamak. İşi yapan kişilerin anlaşılmasını sağlar.
  6. Bilgi ve inanç sistemlerine felsefi bir yaklaşım olan Bilgi Teorisini (Epistemoloji) anlamak.
  7. Yalın Ekonomik Model: Bu model “atık” kavramlarına dayanır.
  8. Muda veya Atık: Kanban’ın çözmeye yardımcı olduğu Yalın’ın yedi israfı.
  9. Muri veya Aşırı Yük: Aşırı çalışan çalışanlar veya yetersiz çalışan makineler aşırı yük yaratır. Süreç akışından aşırı yükün kaldırılması gerekir.
  10. Mura veya Eşitsizlik: Süreçteki farklılıklar atık(muda) ve aşırı yüklenmiş çalışanlar (muri) yaratabilir. Mura, uygun şekilde yönetilmezse kısır döngü ortaya çıkar.

Kuruluşlar, süreç akışındaki israfı fark ettikçe, ürünlerinde çok fazla kusur buldukça, hatalı süreçlerini fark ettikçe düzen ihtiyacı ortaya çıkar. Yalın ve Kanban felsefeleri hem endüstriyel hem de bilgi yönetimi çalışmaları için geçerlidir ve birçok endüstride çalıştıkları kanıtlanmıştır. Diğer çerçevelerle birleşecek kadar esnektirler.

Yalın yazılım geliştirme ile ilgili ilkeler aşağıdadır;

  • Gecikmeleri ortadan kaldırmak ve kesintileri azaltmak için çalışmayı sınırlandırmak.
  • Yapılması gereken en değerli işi belirlemek.
  • Gereksiz olanı yapmaktan kaçınmak.
  • İş akışının doğru sırada olmasını sağlamak.
  • Atıkları sistemden çıkarmak.

Türkçe eğitimler

İngilizce eğitimler

PMP Hazırlık – Çevik Yaklaşımlar – Kanban

Kanban nedir?

1940’ların sonlarında Toyota, ABD süpermarketlerini incelemeye başladı. Müşterilerin genellikle o anda ihtiyaç duyduklarını (ne fazla ne az) aldıklarını fark ettiler. Müşteriler ertesi gün geri gelip ihtiyaç duyduklarını tekrar alabileceklerini biliyorlardı.Toyota’nın gözlemleri, envanteri algılamanın yeni bir yolunu ateşledi. Artık bilgisayar sistemleri ve envanter yazılımlarının kullanımı ile bir sistemin yalın ve tam zamanında olması daha kolaydı. Toyota bu yaklaşımı fabrikaya taşıyarak Kanban sistemini yarattı.

Kanban, üretim sistemi, süreçler veya faaliyetlerin sırasını ve gerekli talimatları gösteren bir model yarattı. Böylece herkes süreci nasıl yöneteceğini ve yönetmek için talimatların ne olduğunu görebiliyordu.

Kanban yöntemi, bireylerin faaliyetlerinden ziyade müşteriye ve onların ihtiyaçlarına hizmet eden işe odaklanmayı vurgular. Ayrıca, Kanban’ın ilkeleri, değişiklik yönetimi ve hizmet sunumu ilkelerinden başlayarak oldukça basittir. Değişim yönetimi ilkesi, tamamen mevcut süreçleri anlamak, rollere, sorumluluklara ve iş ünvanlarına saygı duymakla ilgilidir. Sürekli olarak iyileştirmeleri takip etmeye ve değişim yoluyla gelişmeye ve organizasyondaki rolleri ne olursa olsun her seviyede liderliği uygulamaya teşvik etmeye odaklanılır. Kanban uyarlanabilir liderliği yansıtır.

Hizmet sunumu tarafında önemli olan müşteriyi gerçekten anlamak, ihtiyaç duyduğu ve beklediği şeye odaklanmaktır. Bunu yapmak için, hem müşteri hem de işletme için sonuçları iyileştirmek için politikalarınızı kurumsal olarak sürekli olarak geliştirmeniz gerekir. Bunu yapabilmek için, işi yönetmek ve ekibin kendi kendine organize olmasına izin vermek gerekir. Böylece kendi kendini organize olan ve yöneten çapraz işlevli ekipler ortaya çıkar.

Kanban’da iki araç vardır: Kanban kartı ve Kanban panosu. Kanban kartları, üretim tesisi içindeki malzemeleri taşıma veya tedarikçiden üretim tesisine malzeme alma ihtiyacını işaret eder.

Kanban system: how does it work in logistics? - Mecalux.com

Çevik metodolojide en çok kullanılan Kanban panosudur. Kanban Panoları, birikmiş iş yığınından devam eden işe (Work-in-progress-WIP) yapılan veya dağıtılan işi temsil eden yüzme havuzundaki kulvarlara benzeyen şeritlere sahip beyaz tahtalardır. İş öğelerini veya Kanban kartlarını temsil etmek için Post-it’ler kullanılır. Kanban Panosu fiziksel veya sanal olabilir.

Kanban board - Wikipedia

Kanban panosu yalnızca yapılması gereken, yapılmakta olan işin görsel bir temsili olmayıp birden fazla paydaşla bilgi paylaşmanın en popüler yollarından biridir.

Kanban, bir çekme sistemini temsil eder. Diğer iş tamamlandığında iş yapılmak için çekilir. Çevik yaklaşımlarda ürün-iş biriktirme listelerinin, müşteri ihtiyaç ve isteklerinin dinamik ve sürekli değiştiğini biliyoruz. Ürün sahibi, çekme sistemini kullanarak, bir öğe tamamlandıktan sonra hangi iş biriktirme listesi öğelerinin yapılması gerektiğini belirleyebilmektedir. Ekip, sprint veya yinelemede başarabilecekleri işi seçer. İş tamamlandığında kabul aşamasına geçer ve diğer işler yapılmak için çekilir. İş tamamlanmış kabul edildiğinde, diğer işe başlanır.

Scrum Panosu, Kanban panosuna çok benzer, ancak ikisi arasında bazı belirgin farklılıklar vardır. Scrum panosu aynı çekme sistemini kullanır, ancak sürekli olarak yeni işlerin çekilmesi yerine, bir sprint sırasında ekibin o sprint sırasında üzerinde çalışmayı seçtikleri dışında hiçbir ek öğe eklenemez.

What is Scrum Board? | Online Agile Scrum Board - Zoho Sprints

Scrum Panosu, sprint boyunca soldan sağa hareket eden iş akışının mükemmel bir görsel temsilidir ve herkesi işin üstünde tutar. Hem okunması hem de kullanımı kolay olduğunda bilgi radyatörü (bilgi yayma aracı) olarak kullanılır. Tüm iş ve sprint bittiğinde, bir sonraki sprint sırasında yapılacak yeni iş seçildiğinde Scrum tahtası sıfırlanır. İkisi arasındaki diğer fark, Scrum panoları sprintte gerçekleştirilebilecek iş miktarını temsil etmek için destanları, kullanıcı hikayelerini ve hikaye puanı atanmış görevleri kullanır. Hikaye puanları işin boyutunu temsil eder. Kanban panoları gibi, Scrum panoları da düzenli olarak güncellenirler.

Kanban’ın Altı İlkesi

  1. İş akışını görselleştirmek
  2. Devam eden işi sınırlamak
  3. Akışı yönetmek
  4. Politikaları açık hale getirmek
  5. Geri bildirim döngülerini uygulamak
  6. İşbirliği içinde ve denemeler yaparak geliştirmek

Kanban’ın altı ilkesi, iş akışını anlamayı sağlar, iş ilerledikçe tutarlı geri bildirim ve iyileştirmeye izin verir.

  1. İş Akışını Görselleştirmek: İş akışının şu anda nasıl olduğunu ve yürütüleceğini belirleyen işi ve ilkeleri görmek gerekir. Süreci yinelemeli olarak iyileştirir, gerekli değişiklikleri benimsemeye yardımcı olur ve etkisiz değişikliklerden öğrenmeyi sağlar. Kanban panoları iş akışını önde ve merkezde tutarlar ve nereden başladığınız ve nerede bittiğinizin haritasını gösterirler. İş akışı anlaşıldıktan sonra, daha iyi ve optimize edilmiş iş akışı için değişiklik yapılabilir. Kanban panosu her zaman görüş alanı içindedir ve yapılması gereken iş veya hangi işin tamamlandığı konusunda soru işareti bırakmaz. Beyin görsel sunumları metni işlemekten 60.000 kat daha hızlı işler ve Kanban/Scrum panoları hızlı tempolu çevik ortamlarda oldukça değerlidir.
  2. Devam Eden Çalışmayı Sınırlamak: Devam eden çalışmayı sınırlamak Kanban’ın can alıcı noktasıdır. Hiç kimse çok fazla veya çok az iş üstlenmez. Devam Eden Çalışma, çekme sistemi aracılığıyla sınırlandırılırsa ve iş akışının bir kısmına veya tamamına uygulanırsa, iş akışındaki her adım sınırlandırılır. Yeni iş, yalnızca mevcut kapasite yeterli olduğunda bir sonraki adıma “çekilir”. Devam Eden Çalışmayı sınırlamak, birçok çevik metodoloji ve çerçevenin ortak noktasıdır.
  3. Akışı Yönetmek: Süreç veya ürünleri iyileştirmek için değişiklik gerekli olsa da, bazen çok fazla değişiklik süreç akışına zarar verebilir. Akışı etkili bir şekilde yönetmek, yalnızca değişiklik anlaşıldıktan sonra süreçte değişiklikler yaratmaktan geçer. Değişikliğin sonuçlarının projenin diğer alanları üzerindeki tüm etkileri değerlendirilmelidir. Akışı yönetmek ve yalnızca gerçekten gerekli olan değişiklikleri uygulamak, işlerin verimli bir şekilde ilerlemesini sağlar ve süreçteki israfı ortadan kaldırır.
  4. Politikaları Açık Hale Getirmek: Herkes tarafından iyi bilinen kural ve politikalara sahip olmak gerekir. Herkes politika ve prosedürleri veya yapılanın tanımını anlarsa, gerektiğinde süreçteki rasyonel değişikliklerin daha iyi uygulanması veya daha etkili olması mümkündür.
  5. Geri Bildirim Döngülerini Uygulamak: Geri bildirim yoluyla durumu daha iyi anlamak, süreci ve sonucu iyileştirir. Devam eden etkili iletişim tüm çevik yaklaşımlarda ortak noktadır. Görsel iş akışı, kendi kendini yöneten ve kendi kendine organize olan ekiplerin tümü, etkili geri bildirim için çok önemlidir. Ozmotik iletişim PMP sınavında karşınıza çıkabilir. Kişilerin bilmek istedikleri veya bilmeleri gereken konulardaki konuşmalara kulak misafiri olmaları anlamına gelir. Ozmotik iletişim, etkili bir bilgi aktarımı yoludur.
  6. İşbirliği İçinde ve Denemeler Yaparak Geliştirmek: Sürekli iyileştirme anlamına gelen Japonca Kai ve Zen kelimelerinin birleşiminden oluşan Kaizen kelimesi projelerde işbirliğinin ve denemeler yaparak sürekli iyileştirmenin altını çizer.

Aşağıdakiler, Kanban bakış açısına yönelik kilit noktalardır;

  • Kanban, işi kolayca yönetmenin ve devam eden işi sınırlı tutmanın bir yoludur.
  • Devam eden iş ve iş akışı Kanban panosunda sunulur.
  • Kanban kartı, yapılan iş tamamlandıkça Devam Eden Çalışmanın çeşitli aşamalarından geçecektir.
  • Kanban’a genellikle çekme sistemi denir.
  • Kanban, belirli bir çerçeveden ziyade sürekli iyileştirmeler modelidir.
  • Kanban, Scrum ve XP gibi birçok Çevik metodolojiye dahil edilebilir.

 

PMP Hazırlık – Çevik Yaklaşımlar – Ekstrem Programlama(XP)

What Is Extreme Programming?. A complete overview of XP | by Pratyaksh Jain  | Inheaden | Medium

XP’nin temel değeri önce basitliktir. XP ekipleri ek ve gereksiz özelliklerden kurtulmak, israftan kaçınmak, işleri basit tutmak ve müşteri gereksinimlerini karşılamak için işe yarayabilecek en basit çözümü bulmaya odaklanırlar. Scrum gibi, XP de proje boyunca değişiklikler bekler ve XP ekibi değişikliği memnuniyetle karşılar.

XP’de son teslim tarihlerine sahip projeler, teslimatı oluşturmak için gereken süre konusunda gerçekçi değildir ve proje ekibine ek stres yaratır. Son teslim tarihi, XP ekibinin gereğinden fazla çalışmasına, baskı altında kalmasına ve yenilik yapmaktan korkmasına neden olabilir.

XP, zaman sınırlamalı yaklaşımında haftalık döngüler ve üç aylık sürüm döngüleri tercih edilir. Scrum’daki sprint gibi haftalık döngü yinelemeli gerçekleştirilir. Her haftanın ilk gününde ekip, neler başarıldığını tartışmak, hafta boyunca gerçekleştirilecek öncelikli kullanıcı hikayelerini seçmek ve seçilen kullanıcı hikayelerini nasıl oluşturacağına karar vermek için toplanır. Bu yaklaşım, sprint planlamasına benzer, ancak tipik sprint’ten daha kısadır. Üç aylık döngü sürümdür ve müşterinin gereksinimleri önceliklendirmesine göre haftalık döngülerde planlanır ve güncellenir. Temel olarak, her haftanın başarıları, her çeyrekte neyin piyasaya sürüleceğini belirlemeye yardımcı olur.

XP’de Slack kavramı, süre yetmezse haftalık döngüden çıkarılabilecek bazı düşük seviyeli gereksinimleri listeye ekleyerek oluşturulur. İşler sorunsuz gidiyorsa, proje ekibi için yük oluşturmayacak düşük seviyeli gereksinimler haftalık döngüye eklenebilirler.

XP’de On Dakikalık Yapı kavramı, yazılan kodun derleme ve test etmek için on dakikalık bir zaman diliminde tamamlanabileceği anlamına gelir. On dakikalık süre, ekibi otomatikleştirilmiş derleme yaklaşımı oluşturmaya, sık sık test etmeye ve sürekli entegrasyonu izlemeye teşvik eder. Sürekli entegrasyon, kod geliştirildiğinde veya değiştirildiğinde gerçekleşir. Ardından entegrasyon hatalarını bulmak ve düzeltmek için kod hemen test edilir.

XP, önce test planlama yaklaşımını izler. Önce test planlandığında, programcılar gerekli testi geçmek için kodun nasıl yazılması gerektiğini bilirler.

eXtreme Programming (XP) – An Agile Framework – StillGeek

XP, yaşam döngüsü boyunca planlama ve geri bildirim döngülerini içerir;

XP Projesini Planlamak

  • Kullanıcı hikayeleri yazılır.
  • Sürüm planı oluşturulur.
  • Sık, küçük sürümler için planlar geliştirilir.
  • Proje yinelemelere bölünür.
  • Her yineleme, bir yineleme planlama oturumu ile başlar.

XP Projesini Yönetme

  • Bir arada bulunan ekipler uygun çalışma ortamında çalışır.
  • Sürdürülebilir bir çalışma hızı oluşturulur.
  • Gün, 15 dakikalık ayaküstü toplantı ile başlar.
  • Proje ekibinin hızı düzenli ölçülür.
  • Ekip üyeleri diğer rollerde bilgi sahibi olacak şekilde eğitilir.
  • Retrospektifler, XP’deki sorunların çözülmesine yardımcı olur.

Tasarım

  • İşler basit tutulur.
  • Projenin hızlı ve kolay anlaşılması için sistem metaforu oluşturulur.
  • Yapılacak işler, sorumluluklar ve işbirliği kartları hazırlanarak, sistem tasarlanır.
  • Spike(mümkün olan en basit çözüm) yinelemeleri, riskleri ele almak için kullanılır.
  • İstenene kadar özellik ve işlev eklenmez.
  • Kodun temizlenmesi anlamına gelen refactor, proje boyunca gerçekleşir.

Kodlama

  • Müşteri rolüne ihtiyaç vardır.
  • Tüm kodlama için standartlar oluşturulur.
  • Önce birim testleri yazılır.
  • Programcılar eşli programlama (aynı işi bilen iki kişi) yapar.
  • Kod sık sık entegre edilir.
  • Tüm kodlar ekibe aittir, herhangi bir programcı kodu gözden geçirebilir veya düzenleyebilir.

Test yapmak

  • Tüm kodlar için birim testleri yapılır.
  • Tüm kodlar yayınlanmadan önce birim testini geçmelidirler.
  • Koddaki hatalar, yeni testlerin oluşturulmasını gerektirebilir.
  • Kabul testi gereklidir, sonuçlar izlenir ve paylaşılır.

XP’nin en önemli unsuru iletişimdir. XP, Scrum gibi, yüz yüze iletişime önem verir. Etkili iletişim erken ve sık geri bildirim almayı sağlar. Bu sayede erken ve hızlı başarısız olma avantajı yakalanır. Ekip hızlı ve erken başarısız olduğunda, neyin işe yarayıp yaramadığına dair geri bildirim alırlar, ayarlamalar yapabilir ve projede ilerleyebilirler. XP, çalışanların deneyip başarısız olmaları için güvenli bir ortam gerektirir. Olumsuz bir geri bildirim yoktur. Eğer yapılan işe yaramadıysa, ekip neyin işe yaramadığını bilir ve ceza korkusu olmadan devam edebilirler.

XP’de basit, kolay anlamına gelmez. Basit, aşırı mühendislik yapmamak, karmaşık kod oluşturmamak, doğrudan ve uygulaması kolay bir çözüm tasarlamak anlamına gelir. XP’de, müşteri gereksinimlerini karşılamak için işe yarayacak en basit şey hedeflenir.

Scrum’da, ekipler bir sonraki sprintte gelişme ve daha iyi çalışma fırsatı için sprint retrospektif yaparlar. XP, anında geri bildirim yoluyla benzer bir konsepte sahiptir. Geri bildirim yargılayıcı değil yapıcı olmalı ve ekibe daha iyi kararlar verme konusunda rehberlik etmelidir. Geri bildirim verirken ekip üyeleri saygılı, dürüst olmalı ve neyin işe yarayıp neyin yaramadığına odaklanmalıdır. Geri bildirimler, suçlamak için fırsat değil, projede ilerlemek için fırsattırlar.

Erken, hızlı ve sık sık başarısız olmak için cesarete ihtiyaç vardır. Geliştiriciler deneme yaptıklarında ekipteki herkes tarafından görülebilir. Ekip, kodu açıkça paylaşır, birbirlerinin kodunu düzeltme yetkisine sahiptirler. Eşli Programlamada bir kişi geliştirici olarak çalışır ve yanında kodu geliştirmesini izleyen bir kişi vardır. İkinci programcı hataları yakalamaya yardımcı olur, iyileştirmeler sunar ve programcıya ihtiyaç duyduğunda yardımcı olur. Programlayan kişiye sürücü, yardım eden kişiye yönlendirici denir. Sürücü ve yönlendirici her 1,5 ila 3 saatte bir rol değiştirir.

Etkili iletişim kurmak, eşli programlamayla birlikte çalışmak ve yeni yaklaşımlar denemek için ekip üyeleri birbirlerine saygı duymalıdırlar. XP, projenin başarısı veya başarısızlığından herhangi bir kişinin değil herkesin sorumlu olduğu kavramını benimser. Herkes farklı çalışır, ancak ekiple birlikte çalışmak gerekir.

What Is Extreme Programming (XP)? - Values, Principles, And Practices

XP Rolleri ve Sorumlulukları

XP projesinde PMP sınavı için bilmeniz gereken sekiz rol vardır. Bunları derinlemesine bilmeniz gerekmez, ancak sorumluluklarını bilmeli ve projede her rolün ne yaptığını anlayabilmelisiniz;

  • Müşteri veya ürün sahibi – Bu rol, scrum’daki ürün sahibi gibi, iş değerlerini temsil etmekten, kullanıcı hikayeleri yazmaktan, gereksinimleri önceliklendirmekten ve programcıların kullanıcı hikayelerinin değerini anlamalarına yardımcı olmaktan sorumludur. Bu rol müşteri gibi hareket eder. Müşterinin neye değer verdiğine ve projeden ne beklendiğine dair iyi bir içgörüye ihtiyaçları vardır.
  • Koç – XP koçu, ekip üyelerine XP yaklaşımı konusunda koçluk yapar, işlerin ilerlemesini sağlar, projenin çalışmasını denetler ve ekip geri bildirimlerine dayalı olarak süreç iyileştirmelerinin uygulanmasına yardımcı olur. Koç, proje yöneticisi ile aynı şey değildir, ancak proje faaliyetlerinin koordine edilmesine yardımcı olur, herkesin kurallara uymasını ve katkıda bulunmasını sağlar.
  • Programcı – Kodu müşterinin gereksinimlerini karşılayacak şekilde yazandır. Kullanıcı hikayelerini tamamlamak için gereken görevleri belirlerler ve birim testleri yaparlar.
  • Testçi – Programcıların oluşturduğu kod üzerinde işlevsel testler gerçekleştirirler. Fonksiyonel testler, entegrasyon testleri olarak da adlandırılır ve programcıların yaptığı birim testlerinden farklıdır. Testçi, test sonuçlarını belgeler.
  • İzleyici – Bu rolün bazı proje yönetimi görevleri vardır, çünkü kişi projede işlerin “yolda” olduğunu doğrulamak için iş atamalarını izleyecektir. İşler beklendiği gibi gitmezse, kişi belirli görevleri yapmak için plan yapacaktır. İzleyici ayrıca proje ilerlemesini raporlamak için programcılar, koç ve müşteri ile bir araya gelir.
  • Risk İzleyici – Projelerdeki, riskleri, kötü sonuçları ve projeyle ilgili sorunları izler. Projenin başarısını tehdit edebilecek durumlar hakkında sık sık iletişim kurar. Rolün amacı, projenin sağlığı konusunda dürüstlüğü ve şeffaflığı sağlamaktır.
  • Yönetici – Projeyi söz verildiği gibi teslim etmekten sorumludur. Yönetici, proje müşterisine durumu iletmekten, sürüm planlaması için toplantıları planlamaktan ve genellikle kontrol etmekten sorumludur.
  • Sponsor – Projeye kaynak sağlayandır.

XP ekipleri yüz yüze iletişim ve ozmotik iletişim (konuşulanlara kulak kabartmak) kurarlar. XP rollerine bazen genelleme uzmanları denebilir. Bir rolün yalnızca bir şey yapmaktan ziyade birden fazla şey yapabileceği anlamına gelir.

PMP sınavında dikkat edilmesi gereken sürdürülebilir tempodur. Ekip, ürün iş biriktirme listesini incelerken, en üstteki en önemli öğelerle başlayacak ve ekip, tamamlama sürecinde(döngüde) kaç hikaye noktası tamamlayabileceklerini belirleyecektir. Yeni döngülerde, daha fazla iş yapmaya teşvik edilmezler. Bu fazla mesaiye ve uzun çalışma saatlerine yol açar ve sürdürülebilir değildir. Hız bir ekibin yinelemede ne kadar iş yapabileceğidir, bu yüzden tek tip ve sürdürülebilir olmalıdır.

PMP Sınavında, senaryo bazlı sorular proje çalışmasını tanımlayabilir, projenin tamamladığı işin türüne göre çevik veya öngörücü olduğuna dair bilgiler verecektir.

PMP sınavında dikkat etmeniz gereken tüm çevik proje yönetimi kavramlarının benzerlikleri vardır:

  • İletişim şeffaf ve dürüst olmalıdır.
  • Değişim memnuniyetle karşılanır ve beklenir.
  • Proje gereksinimlerine değerine göre öncelik verilir.
  • Ekip ve paydaşlar işbirliği yapar.
  • Asgari düzeyde yeterli belge olmalıdır.

Türkçe eğitimler

İngilizce eğitimler

PMP Hazırlık – Çevik Yaklaşımlar – Scrum

Scrum Images | Free Vectors, Stock Photos & PSD

En yaygın çevik yaklaşımdır. Sadece süreçler veya proje yönetimi için bir çerçeve olmayıp ürün yönetiminin bir özelliğidir. Projeyi, “Bitti Tanımı”na doğru ilerletmek için yinelemeli yaklaşımı tercih eden çevik bir yaklaşımdır. Proje, paydaşların en önemliden en az önemliye doğru gereksinimlerini sprint adı verilen yinelemelerle gerçekleştirmeye dayanır.

Çevik için birçok farklı yaklaşım olsada, tüm çevik yaklaşımlar sprintler, yinelemeler veya artışlarla çalışır. Artış, her sprintte geliştirilen kullanılabilir ürün veya ürünlerdir. Artış, nihai ürünün potansiyel olarak kullanılabilir bir parçasıdır. Her artış, önceki artışlara eklenir. Bir tren düşünün; her artış, trene eklenen başka bir yük vagonudur.

Yinelemeler aynı zamanda sprintlerdir ve geçmişte tamamlanmış olanların üzerine inşa edilirler, ürünü bir bütün olarak iyileştirir ve/veya geliştirirler. Örneğin, bir resmin taslağını çizdiğinizi ve ardından taslağı iyileştirdiğinizi, taslağın üzerini boyadığınızı, taslağı yeniden boyadığınızı ve resim mükemmelleşene kadar devam ettiğinizi hayal edebilirsiniz. Yinelemelerin arkasındaki fikir: tamamladığınız şeyi yinelersiniz. Diğer bir örnek web sitesi oluşturup, ekip ve ürün sahibi gördükten sonra ek özellikler eklemek vb.

Süreç

1 – Vizyon beyanı yapılır. Vizyon ifadesi, hedefleri ve projenin neden var olduğunu açıklar. Projenin amacını ve projenin getirdiği değeri ön planda tutan basit bir belgedir. Vizyon ifadesinin, iyi olarak kabul edilmesi için beş unsuru içermesi gerekir;

  • Projenin açık tanımı
  • Açık ve basit bir dil
  • Kuruluşun beklediği değer ile uyum
  • Proje ile ilgili gerçekçi beklentiler
  • Kısa ve net

2 – Ürün Yol Haritası hazırlanır. Ürün sahibi, Scrum Master ve Scrum ekibi ile birlikte ürün yol haritası geliştirmek için birlikte çalışır. Ürün yol haritası, paydaşlara baştan sona projedeki teslimatların nasıl teslim edileceğini gösterir. Aynı zamanda Scrum ekibi için yol göstericidir. Ürün sahibinin onaylaması için hangi koşulların yerine getirilmesi gerektiğini, bileşenlerin neler olduğunu ve projenin sonucunu açıklar.

3 – Ürün Sahibi, Ürün iş biriktirme listesini hazırlar. Ürün sahibi, iş değerine ve beklenen değere göre ürün biriktirme listesini öncelik sırasına koyar. Değişiklik istendiğinde, ürün sahibi değişikliği değerlendirir, onaylarsa ürün iş biriktirme listesine ekler ve yeniden önceliklendirir. Böylelikle Sürüm Planı hazırlanmış olur.

4- Önceliklendirilmiş ürün iş biriktirme listesindeki öğeler Kullanıcı Hikayelerine dönüştürülürler. Kullanıcı Hikayeleri rol bazlı olarak istenilen fonksiyon veya işlevi açıklayan kısa notlardır. Kullanıcının, istenen özelliği nasıl kullanacakları ve kullandıklarında elde edecekleri değer hakkında kısa bir açıklamadır. Örneğin bir satış elemanı olarak daha fazla satış yapabilmek için uygulama üzerinden sipariş girmek istiyorum. Kullanıcı hikayeleri bir rol, işlev ve değer formülünü takip eder. Örneğin, “Bir <rol> olarak, <işlev> istiyorum, böylece <değeri> gerçekleştirebilirim”. Kullanıcı hikayeleri yapışkan notlara veya dizin kartlarına yazılır ve hikaye kartları olarak adlandırılır.

Kullanıcı hikayeleri, ekipteki herkes tarafından kolay anlaşılmalıdır. Kullanıcı hikayeleri ürün sahibi tarafından oluşturulur ve ürün iş biriktirme listesine girerler. Kullanıcı hikayelerinin önceliklendirilmesinden ürün sahibi sorumludur. Her kullanıcı hikayesi değer yaratmalıdır.

Kullanıcı hikayeleri aşağıdaki özellikleri içermelidir;

  • Bağımsız – Ürün iş biriktirme listesinde herhangi bir sırada önceliklendirilebilir.
  • Pazarlık edilebilir – Ekip ve ürün sahibi, maliyet ve işlev konusunda ödün verebilir.
  • Değer Kullanıcı hikayesi eyleminin değeri açıktır.
  • Tahmin edilebilir – Gerçekleştirmek için gereken çaba tahmin edilebilir.
  • Küçük – Bir yinelemede tamamlanabilmelidir.
  • Test edilebilir – Sonuçlar, tamamlanma ve doğruluk açısından test edilebilir.

5 – Scrum’da, teslimatlar, sprintlerde ortaya çıkarılır. Sprintler iki ila dört hafta sürebilir. Her sprintin başlangıcında, ürün sahibi, scrum master ve scrum ekibi, sprintte gerçekleştirilecek çalışmaları planlamak üzere bir araya gelirler. Sprint planlama toplantısı, ürün iş listesine ve scrum ekibinin ne kadar iş başarabileceklerine odaklıdır. Scrum ekibi, kullanıcı hikayeleri gözden geçirirler. En değerli kullanıcı hikayelerini belirler, sprint sırasında kaç kullanıcı hikayesini tamamlayabileceklerini belirlemeye çalışırlar. Sprint planlama toplantısının amacı ekibin başarabileceklerini düşündükleri iş parçası üzerinde hemfikir olmalarını sağlamaktır.

Scrum ekibi, ürün iş biriktirme listesindeki kullanıcı hikayelerine bakıp, kullanıcı hikayelerinin ne kadar büyük veya küçük olduğunu belirlemeleri ve kullanıcı hikayesinin boyutuna göre hikayelere puan atamaları gerekir. Hikaye ne kadar büyükse, o kadar fazla hikaye puanı alır. Hikaye puanı veya hikaye noktası, gerçekleştirilecek hikayeleri büyükten küçüğe boyutlandırmaya yarar.

Kullanıcı hikayesi boyutlandırma tamamen görecelidir. Scrum ekibinin bir yinelemede ne kadar iş veya hikaye noktası tamamlayabileceklerini tahmin etmesine yardımcı olur. Her bir kullanıcı hikayesi, işi yapmak için gereken çaba, karmaşıklık ve süreye göre boyutlandırılır, ancak bu kesin bir süre tahmini olmayıp, scrum ekibinin gerçekçi bir şekilde tamamlayabilecekleri iş miktarının kaba bir tahminidir.

Kullanıcı hikayesi boyutlandırması zordur, bu nedenle iyi bir yaklaşım tercih edilmelidir. Örneğin, tişört boyutları, fibonacci serisi vb. Boyutlandırmanın doğru olduğundan ve aynı zamanda tek tip olduğundan emin olmak gerekir.

Yakınlık tahmini yapılıyorsa ürün sahibi, scrum ekibi ve scrum master bir araya gelirler. Tahminler, ürün iş biriktirme listesinin en üstünden başlayarak geçmiş projeler veya benzer çalışmalar gibi bazı kanıtlanmış referans noktaları ile başlar. İlk sprintlerde, scrum ekibinin ne kadar iş tamamlayabileceğini tahmin etmek zordur. Zamanla tahmin normalleşecektir. Hikayeler, hikaye noktaları kullanılarak boyutlandırılır. Ekip, bir sprintte kaç hikaye puanı tamamlayabileceklerini tahmin eder. Ürün iş biriktirme listesinden seçilen hikayeler, sprint iş biriktirme listesi haline gelir. Her yeni sprintte scrum ekibinin kaç puan tamamlayabileceklerini tahmin etmede yardımcı olur.

6 – Sprint için seçilen kullanıcı hikayeleri sprint iş listesi olarak tanımlanır. Sprint iş listesi oluşturulduktan sonra değişmez. Sprint iş listesi, ekibin sprint hedefi oluşturmasına yardımcı olur. Her sprint, sprint planlama sürecini tekrar eder ve bu toplantı, dört haftalık bir sprint için genellikle sekiz saat sürer.

Kullanıcı hikayeleri bir sprintte tamamlanamayacak kadar büyük olmamalıdır. Hikaye büyükse ayrıştırılması ve sprintte gerçekleştirilebilecek boyuta indirgenmesi gerekebilir.

7- Planlama sonrası projede kimin ne yapacağını ve bundan sonra neyin yapılmasının önemli olduğunu belirleyen scrum master değil ekiptir. Scrum ekipleri kendi kendine organize organize olurlar. Ne yapacaklarını söylemesi için scrum mastera bakmazlar. Scrum master’ın rolü ekibe koçluk yapmaktır. Scrum yöneticisi, ekibin kimin hangi görevi yapacağını belirlemesine, koordine olmasına ve iş üzerinde kontrol sağlamalarına yardımcı olur. Proje ilerledikçe, scrum master desteğine ihtiyaç azalır, ekip kendi kendine liderlik eder.

Uzun sprintler risklidir çünkü müşteri incelemesi ve etkileşimini geciktirir. Ürün sahibi ve müşteri sprintin sonuna kadar herhangi bir değer görmez veya alamaz. Ekibin değişmesi (istifa vb.) sprint süresini etkiler. Sprint sırasında ekip üyelerinin değiştirilmesi önerilmez ancak uzun sprintin ortasında ekipten ayrılan veya yeni katılan insanlar yeni riskler ve problemler yaratırlar. Örneğin, işi öğrenme, ekiple kaynaşma, iletişim zorlukları vb.

8 – Scrum’da her sabah ekibin sprint hedefleri ile ilgili performansını değerlendirebileceği toplantı yapılır. Günlük toplantılar, sprint boyunca her gün aynı saatte ve aynı yerde gerçekleşir. Günlük toplantıda ekip üç soruyu yanıtlar:

  • Son görüşmemizden beri ne başardın?
  • Sonraki günlük toplantımızdan önce ne başaracaksın?
  • İlerlemenin önünde engeller var mı?

9 – Sprint’in sonunda, scrum ekibinin sprintte tamamlananları gözden geçirdiği toplantı olan sprint incelemesi yapılır. Sprint incelemesinde yalnızca tamamlanan çıktılar gösterilir. Çıktı, Bitti Tanımını karşılamıyorsa, ürün iş biriktirme listesinde tekrar önceliklendirilmesi için ürün sahibine iletilir. Proje müşterisi sprint incelemesi sırasında değişiklik talep edebilir. Müşteri çıktıyı gördüğünde, nelerin mümkün olduğunu görecek ve elde etmeyi umduğu değeri iyileştirmek için yeni fikirleri olabilecektir. Bu değişiklikleri scrum ekibi memnuniyetle karşılar.

Scrum ekibinin sprintte tamamladığı hikaye noktalarının sayısına hız denir. Başlangıç için hız tahmin edilemez olabilir, ancak zamanla takımın hızı sabit hale gelecektir.

10 – Sprintin sonunda Sprint retrospektif adı verilen geçmiş sprint sırasında neyin iyi gittiğine ya da iyi gitmediğine dair öğrenilen dersler toplantısı yapılır. Toplantının amacı, ürünü ve projeyi geliştirmek için fırsatlar aramaktır. Ürün sahibi, scrum ekibi ve scrum master, projenin iletişimini, başarılarını ve başarısızlıklarını şeffaf bir şekilde incelemek ve gözden geçirmek için toplantıya katılırlar. Amaç kimseyi suçlamak değil, sprintin kazançlarını ve kayıplarını dürüstçe tartışmaktır. Retrospektif, scrum ekibinin bir sonraki sprintte yapacağı proje çalışmasını geliştirmesine yardımcı olur.

Türkçe eğitimler

İngilizce eğitimler

 

Çevik Projelerde Tedarikçi Anlaşmaları

How to draft an agreement? - A primer - iPleaders

Uyarlanabilir(çevik) projelerde sözleşme müzakerelerinden çok işbirliğine değer vermek, pazarlık yapıl(a)mayacağı anlamına gelmez. Taraflar için için neyin iyi olduğunu kazanan-kaybeden zihniyetiyle değil, kazanan-kazanan ilkesi ile müzakere etmek gerekir.

Sözleşmelerdeki çok katmanlı yapılar

Garantilerin, anlaşmazlık durumunda çözüm yöntemlerinin ve ek talep/değişiklik yönetimi vb. konuların sözleşmeye konmasına izin verilmelidir. Hizmet verme oranları ve ihtiyaç duyulan kaynaklar vb. değişebilecek öğeler sözleşmede yer almalıdır. Proje kapsamı, zaman çizelgesi ve bütçe gibi çevik bileşenler için yapılacak çalışmalar belirtilmelidir. Bu yaklaşım her iki tarafa esneklik sağlar ve proje için bazı sınırlar koyar.

  • Teslim edilen değeri vurgulamak – Sözleşmeleri, projede değişebilecek belirli kilometre taşları ve çıktılar üzerinde yapılandırmak yerine, değer odaklı öğelere odaklanılabilir.
  • Sabit fiyat artışları – Sözleşmede, kullanıcı hikayelerine değer atanarak, tamamlanan kullanıcı hikaye puanlarına göre fiyatlandırma yapılabilir. Bu sayede, müşterinin tedarik bütçesini nereye harcadığı konusunda daha fazla kontrol sahibi olmasını sağlar. Aynı zamanda satıcının değişmesi muhtemel olan sabit ücret riskinden kaçınmasını sağlar.
  • Aşılmaması gereken sınırlamalar – Bu yaklaşımla, ürün biriktirme listesinin değişebileceği, ancak satıcının önceden tanımlanmış sınırlı bir miktara kadar çalışma saatleri sattığı anlayışıyla, tedarik edilen iş gerekli bütçe ayrılabilir. Bu adil yaklaşımda her iki taraf da riski paylaşır.
  • Teşvik ve Ceza – Bu yaklaşım, satıcıya ürünü beklenenden daha erken teslim etmesi için teşvik sunarken proje beklenenden daha geç tamamlandığında, saat başına daha düşük ödeme şeklinde bir ceza sunabilir.
  • Erken iptal – Örneğin satıcı projenin yüzde 50’sini tamamladığında müşteri projenin geri kalanına ihtiyacı olmadığını belirlerse, müşteri kalan bakiyeden daha az bir kapanış ücreti ödeyebilir. Müşteri, teslim edilen işten daha fazlasını öder, satıcı yapmak zorunda olmadığı iş için gelir elde eder.
  • Dinamik kapsam – Sabit ücretli sözleşmelerde müşterinin projede önceden tanımlanmamış konularda ek talep yapmasına izin verir. Müşterinin proje kapsamını çevik bir biçimde değiştirmesine olanak tanıyın ancak ya ek iş için ek ücretlendirme ya da işin kalanında kapsamı daraltın.
  • Ekip Büyüklüğü – Basitçe satıcı, çevik proje ekibinin harcadığı emek ve zamanı satar. Sözleşmede kaynak kısıt olarak yer alırsa bu kısıta uygun süre ve bütçe belirlenir. Müşteri işi hızlandırmak vb. ek gereksinimlerle geldiğinde ekip büyütmenin bedeli ve etkilerinin yansıtılacağı sözleşmeye eklenebilir.
  • Birden Fazla Satıcı – Projenin birden fazla tedarikçisi olabilir. Bit tedarikçinin diğerleri ile olan etkileşimi ve ilgili beklentiler sözleşmeye yansıtılmalıdır.

Türkçe eğitimler

İngilizce eğitimler