Proje Yönetimi Planı Bölüm 2: Şelale, DAD, SAFe, LeSS ve Scrum@Scale'in Kapsamlı Bir Karşılaştırması

genel bakış

Proje Yönetimi Planının 1. Kısmında Yalın Yazılım Geliştirme, Çevik, Scrum ve Kanban yazılım geliştirme metodolojilerini ve hepsinin köklerini Yalın Üretime kadar nasıl takip ettiklerini ele aldık. Bu metodolojiler genellikle tek bir ekip düzeyinde dağıtılır. Bununla birlikte, projeler ve proje ekipleri büyüdükçe karmaşıklık artar ve ölçekte çevik olmak için yeni yaklaşımlar gerekir.

Bölüm 2'de ilk olarak, geleneksel şirketlerde yazılım geliştirme için en yaygın çerçeve olan şelale metodolojisini proje yöneticilerinin nasıl kullandığına dalacağız. Buna paralel olarak, çevik ilkeleri ölçekte birleştirmeye çalışan en popüler çerçeveleri ele alacağız: Disiplinli Çevik Teslimat (DAD), Ölçekli Çevik Çerçeve (SAFe), Büyük Ölçekli Scrum (LeSS) ve Scrum@Scale.

Şelale

Şelale metodolojisi (yazılım geliştirme yaşam döngüsü modeli (SDLC) olarak da bilinir), yazılım geliştirmenin bir şelale gibi bir aşamadan diğerine geçtiği daha geleneksel bir metodolojidir. Fazlar örtüşmez ve bir fazdan diğerine geçmek için belirli giriş ve çıkış kriterlerine sahiptir.

Orijinal şelale modelinin altı yaşam döngüsü aşaması şunlardır:

1. Gereksinimler: Bu aşamada, projenin beklentileri ve hedefleri tanımlanır ve gereksinimler, genellikle bir iş analisti tarafından kapsamlı bir şekilde analiz edilir ve belgelenir. Bu aşamadan çıkmadan önce gereksinimler gözden geçirilir ve onaylanır.
2. Tasarım: Gereksinimler onaylandıktan sonra, ürünün onaylanan gereksinimleri karşılayacak şekilde mimari ve tasarım çalışmalarına başlanır. Fiziksel mimari, bileşen mimarisi, veritabanı tasarımı, ayrıntılı bileşen, modül tasarımı ve tasarımın diğer yönleri, bir yazılım mimarı veya tasarımcısı tarafından belgelenir. Daha sonra uygulamaya başlamadan önce gözden geçirilir ve onaylanır.
3. Uygulama: Tasarım onaylandıktan sonra, yazılım geliştiriciler tarafından gereksinimlere ve tasarımlara göre yazılımın uygulanması veya kodlanması yapılır.
4. Doğrulama: Uygulama tamamlandıktan sonra, gereksinimlerin ve tasarımın karşılandığından ve istenen kalite seviyesine ulaşıldığından emin olmak için yazılım test veya QA ekibi tarafından test edilir. Kusurlar bulunur, günlüğe kaydedilir, triyaj yapılır ve çoğu durumda düzeltilir.
5. Yayın ve bakım: Test ve hata giderme tamamlandıktan sonra ürün, istemciye bırakılır ve kurulur. Çoğu zaman, kurulumun başarılı olduğundan emin olmak için bir dizi test yapılır. Ürün teslim edildikten sonra, ürünün tasarlandığı gibi çalışmaya devam etmesini sağlamak için sürekli bakım ve destek gerçekleştirilir.

Şelalenin Avantajları

Şelalenin bazı avantajları vardır ve belirli proje türleri için uygundur, ancak bazı ciddi dezavantajları da vardır. Şelale, gereksinimlerin, teknolojinin iyi anlaşıldığı ve önemli bir şekilde değişmesinin muhtemel olmadığı daha kısa projeler için en uygunudur.

Doğru proje tipine uygulanırsa şelale modelinin bazı avantajları:

• Basitlik: Kapsamın önceden belirlenmesi ve katı fazlar ve bir aşamadan diğerine net bir geçiş nedeniyle şelalenin uygulanması kolaydır.
• Görünürlük: İşin tüm kapsamı önceden bilindiği ve proje bir aşamadan diğerine geçtiği için ilerleme daha kolay ölçülür ve paydaşlar tarafından görülür.
• Belgeleme: Kapsam, gereksinimler ve planlar baştan sona düşünülüp iyi belgelenebilir, bu da daha az deneyimli ekiplerin proje üzerinde çalışmasını kolaylaştırır.
• Aşamalı çalışma: Katı roller ve aşamalar arasındaki geçiş nedeniyle, proje kaynaklarının birincil aşamaları devam etmediğinde başka projeler üzerinde çalışması mümkündür.

Şelalenin Dezavantajları

Şelale, gereksinimlerin iyi anlaşılmadığı ve/veya değişmesi muhtemel ve/veya önemli teknik risk bulunan daha uzun projeler için uygun değildir. Pazar koşullarının sürekli değiştiği ve pazara sunma süresinin kritik olduğu günümüz çağında bu, çoğu yazılım projesi için geçerlidir.

Çoğunlukla değişime uyum sağlayamamasına odaklanan şelale modelinin dezavantajları şunlardır:

• Monolitik kapsam: Paydaşları, projenin kapsamını tanımlarken HER ŞEYİ düşünmelerini ödüllendirerek monolitik bir kapsam sağlar.
• Geç müşteri geribildirimi: Paydaşlar ve özellikle müşteriler için bir projenin tüm detaylı kapsamını hayal etmek zordur. Şelale, müşterileri proje sonuçlarına çoğunlukla projenin son aşamalarında maruz bıraktığından, kaçınılmaz olarak müşteri geri bildirimlerini projeye dahil etmek zorlaşır.
• Gereksinimler değişir: Daha uzun projelerde piyasa koşulları ve dolayısıyla proje hedefleri ve gereksinimleri, proje sırasında çok yüksek değişme riski altındadır.
• Sonunda yaratılan değer: Şelale, çok fazla çalışma gerektirir, bu da değerin projenin sonlarına kadar üretilmediği anlamına gelir.
• Aşamalar arası bağımlılık: Değişikliklerin dahil edilmesi, genellikle, projenin diğer alanlarını etkileyebilecek gereksinimler ve/veya tasarım yeniden çalışmaları ile sonuçlanır. Sonraki aşamaların önceki aşamalara bağımlılığı, projede orantısız bir şekilde zorlayıcı küçük değişiklikler yapabilir.

Disiplinli Çevik Teslimat (DAD)

Disiplinli çevik teslimat (DAD), IBM ve Mark Lines'ta Scott Ambler tarafından resmileştirildi ve bir organizasyonun çevik olmayan bölümlerinin genellikle bir yazılım projesinin sunulmasında bir miktar kapasiteye dahil olduğunu kabul ederek çevik ve scrum çerçevelerini genişletiyor. Bu çerçeve, BT operasyonlarından, kurumsal mimariden, portföy yönetiminden, finanstan ve tedarikten tam teslimat yaşam döngüsüne kadar olan faaliyetleri açıkça içerir. DAD, genel iş çevikliğini pragmatik bir şekilde artırmayı amaçlar.

Ana İlkeler ve Bileşenler

Roller

DAD, scrum'dan çok daha fazla role sahiptir ve iki takım rolü kategorisine ayrılır. Birincil roller, proje ile sürekli olarak çalışan kişiler tarafından doldurulur. İkincil roller, genellikle ekibe ölçeklendirme veya diğer sorunlarda yardımcı olmak için geçici olarak tanıtılır. DAD, tüm çözüm sağlama yaşam döngüsünü ele aldığı ve gerçek dünyada bulunan çeşitli ihtiyaç duyulan geçici ve destekleyici rol türlerini tanıdığı için bu ek rollere sahiptir.

Birincil roller:

1. Paydaş: Projeyi bitiren ekibinize bağlı olan biri: müşteri, son kullanıcı veya dahili iş arkadaşı.
2. Ekip üyesi: Planlanan işi gerçekten yapan ekip içindeki kişiler: geliştiriciler, tasarımcılar, testçiler vb.
3. Takım lideri: Scrum ustasına benzer şekilde, takım lideri, engelleri kaldırarak, takım uyumunu kolaylaştırarak ve çevik değerleri yayarak takım için hizmetkar-lider olarak çalışır.
4. Ürün sahibi: Bazen “müşterinin sesi” olarak anılır. Ürün sahibi paydaşları temsil eder ve yapılması gereken işlerin öncelikli listesini tutar.
5. Mimari sahibi: Büyük ölçekte mimari riskini azaltmaktan sorumludur. Bu rol, derin bir teknik altyapı ve sağlam iş alanı bilgisi gerektirdiğinden, genellikle ekip içindeki kıdemli bir geliştirici tarafından doldurulur.

İkincil roller:

1. Uzman: Özel bir rolde yardımcı olmak için ekibe geçici olarak katılan kişiler. Örneğin, bir veri analisti, bir projenin erken aşamalarında araştırma yetenekleri sağlamak için katılabilir.
2. Alan uzmanı: Vergi danışmanları, hukuk danışmanları ve alan uzmanlığına sahip olan ve ilgili zorluklarda ekibe yardımcı olan diğer kişiler.
3. Teknik uzman: Veritabanı yöneticisi, güvenlik uzmanı yapı ustası vb. Bu kişiler, yaşam döngüsünün önemli noktalarında daha genelleştirilmiş ekip üyelerine yardımcı olur.
4. Bağımsız test uzmanı: Test uzmanları genellikle ana ekibin bir parçası olsa da, bazı durumlarda yaşam düzenleyici gereksinimleri veya çok karmaşık sistemlerde bağımsız test uzmanları, teslim edilen işi doğrulamak için paralel olarak çalışır.
5. Entegratör: Ölçekte, farklı ekipler tüm sistemin farklı bölümlerinde çalışıyor. Entegratör, ekibin kendi parçalarını tüm sistemle entegre etmesine yardımcı olur ve bağımlılıkları yönetir.

Yaşam Döngüsü Desteği

DAD, yalnızca çevik/scrum kapsamındaki programlama ve sürüm bölümünü değil, aynı zamanda proje vizyonunun tanımlandığı ve onaylandığı başlangıç ​​aşamasını ve sürümden sonraki destek ve emeklilik aşamalarını da içeren tam bir teslimat yaşam döngüsünü destekler. Şu anda DAD 6 farklı yaşam döngüsünü desteklemektedir:

• Çevik Yaşam Döngüsü: Scrum Tabanlı Bir Proje Yaşam Döngüsü
• Yalın Yaşam Döngüsü: Kanban Tabanlı Bir Proje Yaşam Döngüsü
• Sürekli Teslimat: Çevik Yaşam Döngüsü
• Sürekli Teslimat: Yalın Yaşam Döngüsü
• Keşif (Yalın Başlangıç) Yaşam Döngüsü
• Ekiplerden Oluşan Bir Ekip için Program Yaşam Döngüsü

Bu yaşam döngüleri, farklı çalışma tarzlarını, şirket çeviklik düzeylerini ve ekiplerin kendilerini içinde bulabilecekleri diğer durumları açıklar. Ana nokta, bu yaşam döngülerinin öneri işlevi görmesidir. DAD, her durum benzersiz olduğundan ve disiplinli çevik uygulayıcıların çevik süreci ihtiyaçlarına göre benimsemeleri gerektiğinden, pragmatizmi saflıktan daha fazla teşvik eder.

Süreç Hedefleri

DAD, çevik süreçler oluşturmak ve uyarlamak için hedef odaklı bir yaklaşım kullanır. Bu metodolojinin yazarları, çoğu ekibin yaşam döngüleri boyunca karşılaşacağı en önemli ve yaygın 21 süreci özetlemektedir.

Tüm bu süreçler, ekibin bu süreci nasıl yapılandıracağına karar vermesini gerektirecek belgelenmiş karar noktalarına sahiptir. Her karar noktası, kararı uygulamak için kullanılabilecek önerilen teknikler veya uygulamalar sağlar. Aşağıdaki resimde bunun bir örneğini görebilirsiniz. “Ortak Vizyon Geliştirme” süreci, alınması gereken 6 karardan oluşur. Bu kararların her biri 2 ila 5 önerilen uygulamaya sahiptir. Oklar, DAD yazarlarının bu listedeki en üstteki öğenin en iyi uygulama ve alttaki öğenin en kötü uygulama olduğu listeyi sıraladığını gösterir. _ Kalın italik_ metin, DAD ile yeni başlayan yeni takımlar için iyi başlangıç ​​noktalarını belirtir.

DAD'nin ölçeklendirilmesi

Disiplinli Çevik Teslimat, ölçeklendirmeye iki farklı açıdan yaklaşır:

• Ölçekte taktik çeviklik

• Geniş ölçekte stratejik çeviklik

Taktik çeviklik, süreç hedeflerinin durumsal uygulaması ve önerilen uygulamaları aracılığıyla büyüklük, coğrafi dağılım, proje karmaşıklığı vb. gibi bireysel ekip ölçeklendirme faktörlerini ele almaya çalışır.

Stratejik çeviklik, çerçeveyi kuruluşun farklı alanlarını ele alacak şekilde genişleterek çevik ve yalın stratejilerin tüm kuruluş genelinde uygulanması yoluyla ölçeklendirmeyi ele almaya çalışır:

• Disiplinli DevOps: Bir kuruluşa daha etkili sonuçlar sağlamak için DevOps kullanımını kapsar.

• Disiplinli Çevik BT (DAIT): Çevik ve yalın stratejilerin BT'nin tüm yönlerine nasıl uygulanacağını kapsar.

• Disiplinli Çevik Kurumsal:. yalın ve çevikliğin bir işletme genelinde nasıl uygulanacağını kapsar.

Güvenli

Ölçekli Çevik Çerçeve (SAFe), şu anda en popüler ve en karmaşık ve kapsamlı ölçeklendirilmiş Çevik çerçevedir. Yıllık Çevik Durum Raporuna katılanların %29'u bu çerçeveyi kuruluşlarında kullandıklarını iddia ediyor. Buna karşılık, piyasada birçok SAFe proje yöneticisi var.

SAFe'nin başlangıcı, Dean Leffingwell'in 2007'de yayınlanan “Scaling Software Agility: Best Practices for Great Enterprises” adlı kitabıydı. Leffingwell şu anda SAFe'nin baş metodoloji uzmanıdır, ancak diğer birçok kişi de bu çerçeveye katkıda bulunmaktadır. Şu anda, sürüm 4.6'da bu çerçeve, sürüm oluşturma, geriye dönük uyumluluk ve çeşitli bileşenler içeren bir yazılım ürününe benzer.

Ana İlkeler ve Bileşenler

SAFe'nin birincil amacı, birçok farklı türdeki şirketin, kısmen, sürekli olarak en kısa ve sürdürülebilir zaman diliminde değer sunmaya ihtiyaç duyan yazılım şirketleri olduğunu kabul ettiği için bir Yalın İşletmenin yaratılmasını ve büyümesini kolaylaştırmaktır.

Yalın İşletmeler için SAFe, kanıtlanmış ilkeler, yeterlilikler ve en iyi uygulamalardan oluşan bir bilgi tabanı sağlayarak bir Yalın İşletme yaratmaya çalışır.

SAFe 4.6, Yalın İşletmenin Beş Temel Yetkinliğini tanımlar. Her bir yetkinlik, birlikte kuruluşların aşağıdakileri gerçekleştirmesini sağlayan bir dizi ilgili bilgi, beceri ve davranıştır:

1. Yalın-Çevik liderlik : SAFe'nin Yalın-Çevik zihniyetini öğrenerek, öğreterek ve uygulayarak liderlerin örgütsel değişimi nasıl yönlendirdiğini ve sürdürdüğünü açıklar.

2. Ekip ve teknik çeviklik : Yüksek performanslı Çevik ekipler oluşturmak için gereken becerileri, ilkeleri ve uygulamaları tanımlar.

3. DevOps ve talep üzerine yayın : DevOps ve sürekli teslim hattının uygulanmasının kuruluşlara talebi karşılamak için gerekli herhangi bir zamanda ürün artışlarını yayınlama yeteneği sağladığını açıklar.

4. İş çözümleri ve yalın sistem mühendisliği : Yalın çevik ilkelerin ve uygulamaların, büyük, karmaşık yazılım uygulamalarının belirtimine, geliştirilmesine, dağıtımına ve evrimine nasıl uygulanacağını açıklar.

5. Yalın portföy yönetimi : Strateji ve yatırım finansmanı, çevik portföy operasyonları ve yönetişime yalın ve sistem düşüncesi yaklaşımlarını uygulayarak strateji ve yürütmeyi hizalar.

Temel yetkinliklerin her biri, tüm süreci kapsayan Yalın-Çevik Liderlik dışında, SAFe süreç diyagramında doğrudan kendi seviyeleriyle eşleşir.

Yalın-Çevik Liderlik Yetkinliği

Yalın-Çevik Liderlik Yetkinliğinin birincil amacı, organizasyonu yalın-çevik bir işletmeye dönüştürmeye yardımcı olmaktır. Bu, SAFe'nin Yalın-Çevik zihniyetini, değerlerini, ilkelerini ve uygulamalarını öğrenerek, uygulayarak ve öğreterek yapılır.

SAFe'nin Temel Değerleri, yalın kurumsal dönüşüme rehberlik eder. Her fırsatta, bir liderin davranışı, onları teşvik etmede kritik bir rol oynar. Temel değerler şunlardır:

1. Hizalama : Misyon, portföy stratejisi ve çözüm vizyonunu iletin. İlgili brifingleri yürütün ve program artış (PI) planlamasına ve biriktirme listesi bakımına katılın.

2. Şeffaflık : İlgili tüm çalışmaları görselleştirin.

3. Yerleşik kalite : Yaşam döngüsü boyunca kaliteyi sağlamak için uygulamalara katılın. Düşük kaliteli işleri kabul etmeyin. Bakım ve teknik borcun azaltılmasına yönelik yatırımları destekleyin.

4. Programın yürütülmesi : PI uygulamasına işletme sahipleri olarak katılın ve işletme değeri oluşturun. Kapsamın talep ve kapasite ile uyumlu olduğundan emin olun. Engelleri ve demotivatörleri agresif bir şekilde kaldırın.

SAFe temel değerleri, Yalın-Çevik Zihniyet benimsenerek ve SAFe İlkeleri uygulanarak desteklenir:

1. Ekonomik bir bakış atın

2. Sistem düşüncesini uygulayın

3. Değişkenliği varsayalım; seçenekleri koru

4. Hızlı, entegre öğrenme döngüleriyle aşamalı olarak oluşturun

5. Çalışma sistemlerinin objektif bir değerlendirmesine dayalı kilometre taşları

6. Devam Eden Çalışmayı görselleştirin ve sınırlayın, toplu iş boyutlarını azaltın ve kuyruk uzunluklarını yönetin

7. Kadans uygulayın, alanlar arası planlama ile senkronize edin

8. Bilgi çalışanlarının içsel motivasyonunun kilidini açın

9. Karar vermeyi merkezi olmayan hale getirin

Bu ilkeler Yalın ve Çevik ilkelere benzer. Son olarak, SAFe Uygulama Yol Haritası izlenerek organizasyonun dönüştürülmesi gerçekleştirilir.

Takım ve Teknik Çeviklik Yetkinlik/Takım Seviyesi

Ekip ve Teknik Çeviklik Yetkinliği, yüksek kaliteli çözümler yaratan yüksek performanslı çevik ekipler oluşturmak için gereken becerileri, ilkeleri ve uygulamaları tanımlar. İki temel özellik kritiktir:

• Ekip çevikliği : Ekipler, güvenilir bir ritimde çalışmalarını, öğrenmelerini ve uyum sağlamalarını sağlayan Çevik uygulamaları ve ilkeleri benimser

• Teknik çeviklik : ekipler, kod ve bileşen kalitesini ve ürettikleri kodun sürdürülebilirliğini sağlayan Çevik teknik uygulamaları uygular\ Kalite, ekip ve teknik çeviklik yetkinliğinde büyük bir odak noktasıdır. Bunu başarmak için, kaliteyi ve akışı artırmak için Behavior Driven Development (BDD) ve Test-driven Development (TDD) gibi çevik mühendislik teknikleri uygulanır. Hatalar akışı ciddi şekilde etkileyebileceğinden ve yayınları geciktirebileceğinden hızlı akış, sistem genelinde bina kalitesine bağlıdır.

SAFe diyagramının Ekip Düzeyi, bireysel Çevik ekiplerin nasıl çalıştığını açıklar. Tüm ekipler, bir Ürün Parçası sunmak için çalışan Çevik Yayın Eğitiminin bir parçasıdır. Takımların çalışma sistemleri sunmak için yinelemeler halinde çalıştığı geleneksel çevik/scrum akışının çoğu geçerlidir. Scrum yöneticisi, ürün sahibi ve ekip üyesinin rolleri, çoğu scrum etkinlikleri ve yapıtlarında olduğu gibi SAFe'de kullanılır. Ekipler ayrıca Ürün Yönetimi, Sistem Mimarı ve diğer paylaşılan hizmetler gibi program düzeyindeki rollerle desteklenir. Kanban, teslimat yaşam döngüsü boyunca özelliklerin akışını ve ekipler arasındaki etkileşimleri ve aktarmaları görselleştirmeye yardımcı olmak için kullanılır.

DevOps ve İsteğe Bağlı Yetkinlik/Program Düzeyinde Sürüm

DevOps ve Talep Üzerine Yayın Yetkinliği, "DevOps ve sürekli teslimat hattının uygulanmasının, kuruluşa pazar ve müşteri talebini karşılamak için gerekli olan herhangi bir zamanda tamamen veya kısmen değeri serbest bırakma yeteneğini nasıl sağladığını" açıklar.

DevOps, iş sonuçları sağlamak için birlikte çalışmak üzere geliştirme, operasyonlar, iş ve diğer alanları uyumlu hale getirmek için çalışır. Her kuruluşun DevOps hareketinin bazı endüstri liderleri kadar sık ​​yayınlaması gerekmese de (Amazon birkaç saniyede bir yayınlar), tüm kuruluşların talep üzerine yayın yapabilmesi gerekir.

• DevOps, sürekli teslim ve talep üzerine yayın sağlayan kültür, otomasyon, yalın akış, ölçüm ve kurtarma (CALMR) yaklaşımını sağlar

• Çevik sürüm trenleri (ART'ler), sürekli teslim hattı aracılığıyla talep üzerine değer sunmak için organize edilen çevik ekiplerden oluşan ekiplerdir.

Diyagramın Program Düzeyi, bir Çevik Yayın Treni (ART) aracılığıyla sürekli olarak teslim etmek için gereken rolleri ve faaliyetleri açıklar. Bu düzey, ekip düzeyine benzer yinelemeli bir şekilde çalışır ancak birden çok çevik ekibi bütünleştirir ve daha fazla döngü içerir. ART, geleneksel çevik rollerin yanı sıra Release Train Engineer (RTE) ve Ürün Yönetimi gibi kritik program rolleri de dahil olmak üzere 5 ila 12 ekipten (50 ila 125 kişi) oluşan bir çevik ekip ekibidir. ART, PI Planlaması yoluyla planlanan ve bir Ürün Yöneticisi tarafından yönetilen 8-12 haftalık Program Artışları (PI) halinde sunar.

PI özelliklerinin, destanların vb. ilerlemesi bir Program Kanban panosu aracılığıyla izlenir ve yönetilir. RTE, ART'de Scrum Master olarak hareket eder. Günlük senkronizasyon toplantıları, takımın Günlük Standup'larını, Scrum-of-Scrum'ları (RTE ve Scrum Master'ları), PO Sync'i (Ürün Yönetimi ve Ürün Sahipleri) ve ART Sync'i (Scrum-of-Scrums ve PO Sync'i birlikte) içerir. Her PI'nin bir Sistem Demosu ve bir Retrospektifi vardır.

İş Çözümleri ve Yalın Sistemler Mühendisliği Yetkinlik/Geniş Çözüm Düzeyi

İş Çözümleri ve Yalın Sistem Mühendisliği Yetkinliği, "Yalın-Çevik ilkelerinin ve uygulamalarının, büyük, karmaşık yazılım uygulamalarının ve siber-fiziksel sistemlerin belirtimi, geliştirilmesi, dağıtımı ve evrimine nasıl uygulanacağını" açıklar.

SAFe ilkelerine ek olarak, büyük çözümler üzerinde çalışırken aşağıdaki 8 ilkeyi uygulamak bu yetkinliğin anahtarıdır:

Büyük Çözüm Düzeyi, büyük ve karmaşık çözümler oluşturmak için gereken rolleri, yapıları ve süreçleri içerir. Birden fazla ART, Çözümler sunmak için Çözüm Trenleri üzerinde birlikte çalışıyor. Birincil hedefler şunlardır:

• Sık entegrasyonu yönetin

• Uyumluluk endişelerini sürekli olarak ele alın

• Ölçek, modülerlik, serbest bırakılabilirlik ve servis kolaylığı için mimar

Çözüm Yönetimi , bir Çözümün içeriğini kontrol eder ve Çözüm Treni Mühendisi (STE) çalışmayı yönlendirir. Çözüm Mimarı , Çözümdeki tüm ART'ler için iyi mimariyi sürdürmekten sorumludur. PI Öncesi ve Sonrası Planlama , birden fazla Program Parçası aracılığıyla sunulan Çözümleri planlamak için kullanılır. Bir Çözüm İş Listesi , Yetenekleri ve Çözüm Destanlarını içerir ve bir Çözüm Kanban panosu aracılığıyla izlenir.

Portföy Düzeyi/Yalın Portföy Yönetimi Yetkinliği

Yalın Portföy Yönetimi Yetkinliği "strateji ve yatırım finansmanı, çevik portföy operasyonları ve yönetişime Yalın ve sistem düşüncesi yaklaşımlarını uygulayarak strateji ve yürütmeyi hizalar."

Yalın Portföy Yönetimi aşağıdaki alanlara odaklanır:

1. Strateji ve yatırım finansmanı: portföyü kurumsal stratejiye bağlar, değer akışlarını finanse eder ve portföy akışını oluşturur

2. Çevik portföy operasyonları: değer akışlarını koordine eder, program yürütmeyi destekler ve operasyonel mükemmellik

3. Yalın yönetişim: bütçeleri tahmin eder, portföy performansını ölçer ve uyumluluğu sağlar

Portföy Düzeyi, bir dizi geliştirme Değer Akışını başlatmak ve yönetmek için gereken ilkeleri, uygulamaları ve rolleri içerir. Bir Portföy İş Listesi , İş Destanlarını ve Etkinleştirici Destanlarını içerir ve bir Portföy Kanban* panosu aracılığıyla izlenir. **Yalın Portföy Yönetimi (LPM) , bir portföyde hangi değer akışlarının olduğuna karar verir ve bir kuruluştaki en yüksek karar vericileri içerir. Bir Kurumsal Mimar , işe rehberlik eder ve Değer Akışları boyunca koordine eder.

Az

Büyük ölçekli scrum (LeSS) çerçevesi, finans ve telekomünikasyon sektörlerindeki deneyimlerine dayanan Craig Larman ve Bas Vodde tarafından oluşturuldu. Adından da anlaşılacağı gibi, LeSS, birçok Scrum takımının birlikte çalışması için mümkün olduğunca az süreç ve prosedüre sahip olmayı teşvik eder. Ölçeklendirme zordur çünkü insanlar bunu karmaşık hale getirir, bu nedenle buradaki amaç bunu olabildiğince basit hale getirmektir.

Ana İlkeler ve Bileşenler

“LeSS, tek bir ürün üzerinde birlikte çalışan birçok takıma uygulanan Scrum'dır”. LeSS, Yalın-Çevik ilkelerine aşina olan herkese tanıdık gelecek on ilkeye dayanmaktadır:

1. Büyük Ölçekli Scrum, Scrum'dır

2. ampirik süreç kontrolü

3. şeffaflık

4. Daha az ile daha fazla

5. Tüm ürün odaklı

6. Müşteri odaklı

7. Mükemmelliğe doğru sürekli iyileştirme

8. Sistem düşüncesi

9. Yalın düşünme

10. Kuyruk teorisi

LeSS, her ikisi de Scrum'dan ödünç alınan yalnızca iki ana role sahiptir:

1. Ürün sahibi: 2-8 ekiple çalışır.
2. Scrum master: 1-3 takımla çalışır.

Tüm takımlar 1-4 haftalık sprintlerde aynı ürün birikimi ile çalışır. Takımlar paralel olarak çalışır, yani sprintleri aynı anda başlatıp bitirirler. Sprintin sonunda takımlar toplu olarak bir ürün parçası teslim eder. Bir ürün sahibinin 8 ekiple çalışması neredeyse imkansız görünebilir. LeSS, ürün biriktirme listesi kalemi açıklama sorumluluğunun ekiplere taşınmasını teşvik eder. Buna karşılık, ekipler çapraz işlevli olmalı ve yalnızca kodlama, tasarım ve test yetkinliklerini değil, aynı zamanda iş alanı bilgisini de içermelidir. Daha da önemlisi, ekiplerin müşterilere ulaşabilmek için yetkilendirilmesi gerekiyor.

Sprint Planlama

Planlama ikiye ayrılır:

1. Sprint planlama 1: Takım temsilcilerinin ürün sahibiyle buluştuğu ve hangi iş yığınlarını üstleneceklerine karar verdiği ve sprint sırasında takımlar arasında ihtiyaç duyulabilecek olası işbirliğini tartıştığı yer.
2. Sprint planlama 2: Geleneksel scrum'da olduğu gibi, her takım birikmiş işlerin nasıl yapılacağına dair bir plan oluşturmak için ayrı ayrı toplanır.

Ürün İş Listesi İyileştirme

Ürün biriktirme listesi ayrıntılandırması (PBR), sprint planlaması için ürün biriktirme listesi öğelerini hazırlamak için sprint sırasında yapılır. LeSS, PBR'nin nasıl yapılacağına dair kurallar sunmaz ve en etkili süreçlerini kendileri bulmayı şirketlere bırakır. PBR üç temel aktiviteyi içerir:

1. Büyük öğeleri bölme.
2. Hazır olana kadar öğeleri detaylandırma.
3. Tahmin ediliyor.

Sprint'in Sonu

Her sprintin sonunda üç şey olur:

1. Sprint İncelemesi: Ekiplerin ve müşterilerin Sprint sırasında ne yapıldığını ve daha sonra ne yapılması gerektiğini keşfettiği paylaşılan bir Sprint demosu.
2. Retrospektif: Her takım, sürecini iyileştirmek için kendi retrospektifini tutar.
3. Genel geriye dönük: Ekipler, ürün sahipleri ve scrum ustaları, organizasyonel uygulamaları daha etkili olacak şekilde denetlemek ve uyarlamak için bir araya gelir.

Scrum@Ölçek

Scrum at Scale ve Scrum@Scale birbirinin yerine kullanılır. Bu metodoloji, 2014 yılında Scrum metodolojisini oluşturan ve Agile Manifesto'nun imzacılarından biri olan Jeff Sutherland tarafından tanıtıldı.

Scrum@Scale, başlangıç ​​noktası olarak Scrum'ı alır ve Scrum'ı "minimum uygulanabilir bürokrasi" ile ölçeklendirmek için basit, hafif bir çerçeve sunar. Diğer ölçeklendirilmiş çevik metodolojilere göre daha az kuralcıdır ve bir meta-çerçeve olarak kabul edilebilir. Ölçeklendirme konularını ve alanlarını vurgular ve bunların nasıl ele alınabileceğine dair zihinsel bir çerçeve sunar.

Ana İlkeler ve Bileşenler

Scrum@Scale, Scrum'ı ölçeklendirmek için Scrum kullanarak ölçeklendirmeyi kökten basitleştiren bir çerçevedir. Scrum'da “ne” (ürün sahibi) “nasıl”dan (scrum master) açıkça ayrılmıştır. Aynı strateji Scrum@Scale'de de kullanılır, böylece yetki ve sorumluluk iyi anlaşılır, israf ve çatışma ortadan kaldırılır.

Scrum@Scale, yetki alanlarını açıkça ayırmak için iki döngü içerir: Scrum Master döngüsü ve iki temas noktasına sahip Ürün Sahibi döngüsü : Takım Düzeyinde Süreç ve Ürün Yayın Geri Bildirimi.

Scrum Master Döngüsü

Scrum master döngüsü , ürün sahibi döngüsünün tanımladığı şeylerin nasıl oluşturulacağından sorumludur. Scrum@Scale'de bireysel Scrum ekipleri, geleneksel Scrum ile aynı rollere, eserlere, etkinliklere ve törenlere sahiptir.

Scrum ekipleri, ortak bir ürün parçası üretmekten müşterek olarak sorumlu olan bir Scrum of Scrums (SoS) halinde gruplanır. Ortak birikmiş iş yığını düzenleme ve önceliklendirmeye katılırlar, geçmişe yönelik incelemeler düzenlerler, birikmiş engelleri korurlar ve ekipleri koordine etmek ve engelleri kaldırmak için bir Ölçekli Günlük Scrum (SDS) (günlük saldırıya benzer biçimde) tutarlar. SDS'ye katılan ekiplerin her birinin en az bir temsilcisi (genellikle takımın scrum yöneticisi) katılır ve scrum ekipleri ve ürün sahipleri ile koordinasyondan sorumlu olan Scrum of Scrums yöneticisi (SoSM) tarafından yönetilir.

Daha fazla ölçeklendirmeye ihtiyaç duyulursa, birden fazla SoS'den oluşturulan ve aynı zamanda her gün buluşacak olan bir scrum of scrum (SoSoS) vardır ve bu böyle devam eder. Genel lider, organizasyonda Çevikliği teşvik etmekten, gerektiğinde Scrum takımlarını koordine etmekten ve engelleri kaldırmak için son durak olmaktan sorumlu olan Yönetici Eylem Takımıdır (EAT) .

Ürün Sahibi Döngüsü

Ürün Sahibi Döngüsü , hangi ürün veya hizmetin oluşturulacağından ve bunu desteklemek için gereken tüm faaliyetlerden sorumludur. Ürün Sahipleri, Scrum ekiplerine atanır ve Scrum'da tanımlandığı şekilde rollerinin tüm etkinliklerini gerçekleştirir. Ürün sahipleri, SoS ekipleriyle eşleşen Ürün Sahibi Ekipleri halinde gruplandırılır. Ürün Sahibi Ekipleri, ekipler için üst düzey bir stratejiyi tartışmak ve gerektiğinde ilgili SoSM ve diğer ürün sahipleri ve paydaşlarla koordine etmek üzere bir Meta Scrum'da günlük olarak toplanır. Meta Scrum'lar, bir Baş Ürün Sahibi (CPO) tarafından yönetilir.

Ürün Sahipleri, organizasyonun büyüklüğüne bağlı olarak scrum master döngüsüne benzer şekilde ölçeklenir ve şirket çapında öncelik ayarından sorumlu olan Executive Meta Scrum (EMT) ile sonuçlanır.

Scrum@Scale'i Uygulamak

Scrum@Scale'in uygulanması, ölçeklenebilir bir referans modeli, yani küçük ölçekte scrum kullanan küçük bir takım seti oluşturmakla başlar. Bu, çevikliği engelleyen herhangi bir kurumsal politika ve geliştirme uygulamasını çözmek için yapılır. Scrum@Scale, tüm ekiplerin organizasyon çapında bu sorunlarla karşılaşması muhtemel olduğundan ve bunun sonucunda ortaya çıkan hayal kırıklıklarının çevikliğin benimsenmesini engelleyebileceğinden, bunların erken çözülmesini önerir. Referans model daha sonra saldırıyı diğer ekiplere ve departmanlara ölçeklendirmek için bir model olarak kullanılır.

Referans modeli uygulamak için ilk olarak yönetici eylem ekibi (EAT) oluşturulmalıdır. EAT, kurumsal politika değişikliklerini uygulayabilecekleri için kuruluş içinde siyasi ve mali olarak yetkilendirilmiş kişilerden oluşur.

Çözüm

Proje yönetimi planının bu ikinci bölümünde, daha büyük projelerde veya programlarda kullanılan en popüler çerçevelerden bazılarını ele aldık. Şelale hala birçok kuruluşta yaygın olarak kullanılmaktadır ve esnek olmayan süreçleri nedeniyle birçok dezavantajı olsa da, projeler küçük olduğunda ve kapsamın iyi tanımlandığı ve değişmesi muhtemel olmadığında bu çerçeveyi kullanmak bazen mantıklıdır.

Şirketler, sürekli değişen gereksinimleri veya hedefleri olan daha büyük, daha karmaşık projelerle karşılaştıkça, daha Çevik yaklaşımlara yönelirler. Çevik başlangıçta 5-9 kişilik küçük ekipler için tasarlandığından, çeşitli Çevik uygulayıcılar, çevikliği tek ekiplerden birden çok ekiplere ve tüm işletmeye ölçeklendirmenin birçok yolunu bulmuşlardır. Bu yazıda Disiplinli Çevik Teslimat (DAD), Ölçekli Çevik Çerçeve (SAFe), Büyük Ölçekli Scrum (LeSS) ve Scrum@Scale konularını ele aldık.

Proje yönetimi planının son bölümünde, PMP (PMBOK) ve PRINCE2 gibi birkaç proje yönetimine özel çerçeveyi ele alacağız. Ayrıca “yapılması gereken işler” (JTBD) ve “tasarım odaklı düşünme” gibi bazı inovasyon süreçlerini ve çerçevelerini de gözden geçireceğiz.