Bir kamu kuruluşu tarafından Scrum, Kanban ve benzerlerinin terimlerini ve kavramlarını açıklayan 101 çevik gelişmeyle ilgili gayri resmi bir atölye çalışması yapmam istendi. Yaklaşık beş yıldır çevik ortamlarda çalıştım, ama beni bir Scrum müjdeci olarak düşünmüyorum.

Atölyeden sonra fikri sevdiler. Bununla birlikte, yaklaşımın kendileri için yazılım geliştirmeleri için harici yazılım şirketlerini görevlendirmeleri gerektiğinden muhtemelen kendileri için geçerli olmayacağını açıkladılar (sadece birkaç geliştiricinin kendileri var). Bu aktivitenin, sonucu, fiyatı ve zaman dilimini tanımlayan bir kamu ihale sürecinde yapılması gerekmektedir. Bu, bu kuruluş için bir bütçeye başvurmak için yasal bir gerekliliktir (bir kamu araştırma kurumu).

Bu kısıtlamalar çevik kalkınmanın temel ilkelerine biraz çelişkili görünmektedir, değil mi?

Scrum sadece böyle bir ortamda uyumsuz mu?

Bu kuruma ne önerirsiniz?

Scrum muhtemelen bu organizasyon için uygun değildir.

Scrum Kılavuzundan, "Scrum, karmaşık ürünleri geliştirmek, sunmak ve sürdürmek için bir çerçevedir." Ayrıca, toplam 4-11 kişi için ürün üzerinde çalışan bir Geliştirme Ekibinden oluşan 3-9 kişilik bir ekip, bir Ürün Sahibi ve bir Scrum Master (Geliştirme Ekibinde olabilir veya olmayabilir) için tasarlanmıştır.

İç gelişme ile ilgili olarak, sadece birkaç geliştiriciye sahip olduklarından söz edersiniz. Eğer bir Scrum Takımı oluşturacak kadar geniş bir takım yoksa, o zaman tüm Scrum'ı kullanmak mantıklı olmaz. Ancak, bazı Scrum uygulamaları kuruluş için yararlı olabilir.

Sözleşmeli gelişme için, dış taraflardan birinin Scrum'u kullanması mümkündür. Bu durumda, araştırma enstitüsünün Scrum uygulamaları hakkında bilgi sahibi olması, rolleri ve nasıl çalıştığını anlamaları yararlı olacaktır. Dış gelişim organizasyonunun Scrum uygulamalarını ve diğer uygulamaları nasıl kullandıklarının özelliklerini hala anlamalarına ihtiyaç duyabilirler, ancak nasıl çalıştıklarını anlamalarına yardımcı olabilir. Örneğin, Sprint İncelemelerine katılmanın veya Ürün İş Listesini sipariş ederken kuruluşla birlikte çalışmanın (muhtemelen onların Ürün Sahibi) olması gerektiğini anlama.

ABD hükümeti bünyesindeki bir dijital servis ajansı olan 18F, hükümetin çevik metodolojilerin yasalarla uyumlu bir şekilde kullanılmasına izin vermek için nasıl sözleşmeler yazabileceği ve işin nasıl yapıldığına ilişkin ayrıntılı gereklilikleri belirten genel sonuçlar belirleyen çok sayıda çalışma yaptı. yapılması gereken. Kaynaklarından bazıları şunlardır:

• Çevik bir sözleşme formatı ile hükümet sonuçlarının iyileştirilmesi
• Çevik Battaniye Alım Sözleşmesi
• Modüler Taahhüt (çevik gelişime sahip büyük projeleri daha küçük modüler projelere bölmek)
• Projeniz “agilefall” kullanıyor mu?

Çevik çalışma yöntemlerinin bir avantajı, sözleşme yapıldıktan sonra bir sorun için bir çözüm bulmaya odaklanmalarıdır, yani, Bölüm 15'teki gibi ayrıntılı çözümü belirtmek yerine, ihale sonrası uygulama sırasında. Ayrıntılı çözümler gerektiren sorunları, genellikle üst düzey sözleşme teslim alanlarını tanımlayan Ürün Gereksinim Öğeleri olarak belirtin.

Bu sorunu anlamak için, Yönetim ve Bütçe ve Federal İhale Politikası Ofisi, ajansları SOW'ları kullanmayı bırakmaya ve hizmet almak için bir Performans Çalışma Beyanı (PWS) kullanmaya yönelmeye yönlendirmiştir. Bir PWS “gereklilikleri (yöntemi) yerine genel olarak ne (sonuç) yapılması gerektiği ile ilgili gereklilikleri belirtmelidir” İyi sözleşmeli memurlar ajanslara uzman hizmetleri satın alarak en bilgili olmadığınız anlamına geldiğini söyler. "nasıl" iş yapılır. Görev sahibi olarak, “ne” nin başarılması gereken konusunda uzman sizsiniz, ancak ikisini birleştirmek görevinizi tehlikeye atar ve sözleşmenin değer vermesini zorlaştırır.

Temel olarak, yaklaşım daha ayrıntılı teknik özelliklerin sayfalarını önceden listelemek yerine, bir çözüm tasarlamak için sizinle birlikte çalışmak üzere bir servis sağlayıcı kiralamak gibidir. Kurum, yeni bir bina tasarlamak için bir mimar kiralamaz "tasarım dört katlı olmalı, 37º çatı perdesine sahip olmalıydı. Üçüncü kat, hareketle kontrol edilen dört floresan armatür içeren 237 metrekarelik bir mutfağa sahip olmalı. tavana duyarlı ışık şalteri. " Aksine, mimarın müşteriyle istişare içinde tasarım hizmetleri sağlama konusunda bir sözleşmeleri olacak ve sonuçta elde edilebilecekleri üretmek için alanında uzman olan satıcılarına güveneceklerdir.

Detaylar kuruma ve geçerli olan satın alma politikalarına ve yasalarına bağlı olsa da, büyük devlet BT projelerinin tüm başarısızlıklarının ortasında, kamu ihalelerini yazılım geliştirmeye yönelik daha modern çevik metodolojilere taşımak için çalışan gruplar olduğunu göstermektedir. Yeterli siyasi irade ve güvenilir kalkınma ortakları verildi. Bu tür projelerin nasıl tasarlandığına ve yönetildiğine (süreç boyunca kullanıcı geri bildirimi sağlamak için uzun zamandır da dahil olmak üzere), kuruluşun takip etmekte herhangi bir ilgisi olup olmayacağı konusunda büyük bir kayma var.

Tipik geliyor. İhale yazıldıktan sonra teklifler hazır olur ve yarışmacılardan biri sözleşme yapılır ... kamu kuruluşunun temsilcileri söz konusu olduğunda, proje yapılır.

Bu yüzden bu projelerin çoğu başarısız oldu. Bütçeyi aştıktan sonra.

Eksik oldukları (ya da en azından endişelendikleri hissetmedikleri), toplantılara ve gösterilere katılmaları gereken paydaşları olmalarıdır.

Bu yüzden hiçbir şekilde Çevik veya Scrum ile bir çatışma yoktur. İnsanlar rollerini almıyorlar. Hükümetin buna neden olan şeklidir.

"Bu sisteme sahip olmak istiyoruz ve bunun için biraz çaba sarf etmeye ve ne kadar dayanabileceğimize bakmaya istekliyiz" gibi değil.

Hayır. "Demokrasimiz o zamana kadar bu sisteme sahip olacağımıza karar verdi" gibi. Bir yandan% 100 başarı, diğer yandan% 100 başarısızlık arasında yer bırakmaz. Baştan mahkum.

Aynı zamanda gülünç oranları istemek için piyasaya bir davet. Projeyi yapmamak çok pahalı olduğu için bir seçenek değil, ihale yapılmadan önce kararını çoktan verilmiş.

Yeterince adil, paydaşlar rollerini ele alsalar bile, tamamen güçsüz olacaklardı. Hiçbiri aynı sebepten dolayı bu demolara götürecek güvenilir bir sopaya sahip olamaz.

Hayır, SCRUM kamu ihaleleriyle uyumlu değildir. Bir kamu ihalesinde ne aldığınızı açıkça belirtmeniz gerekir.

"Alıcı, 5 geliştirici ve sertifikalı bir SCRUM ustası (alıcı Paydaş rolünü dolduracak) içeren deneyimli bir SCRUM ekibinden 10 adet 2 haftalık geliştirme sprinti satın almak istiyor. ihalenin başlangıcı. Elbette gerekli takım becerilerini listelemeniz ve üzerinde çalışacakları proje hakkında bir fikir vermeniz gerekecek, ancak bir takım kiralamak için bir ihale sahibi olmak kesinlikle kabul edilebilir.

Tabii ki, burada "sabit kapsam" dan vazgeçiyorsunuz. Sonuçta, bu SCRUM için tipiktir. İhaleye biraz daha fazla açıklama ekleyerek (ancak burada yasal bölgeye giriyoruz) küçük bir kapsam genişletmesine, yani az sayıda ek sprint olmasına izin verebilirsiniz. Ancak ilk 10 sprintten sonra 10 sprint daha almaya karar verirseniz, muhtemelen yeniden ihale yapmanız gerekecektir.

Zor.

Belli ki çalışmayı açık uçlu bir bütçeyle ihale edemezsiniz. Öyleyse, yapılması gerekenlere ve bunun için ne kadar çaba gerektiğine bakmalısınız.

Artık pek çok yazılım projesinin başarısız olmasının nedeni, sabitleme, zaman, çaba ve kapsamın ön plana çıkmasının çok eğilimli olmasından kaynaklanıyor. Örneğin, bir ihalede verilen bir şartname neredeyse her zaman bir belirsizliğe sahip olacaktır.

Dolayısıyla, sadece çevik değil, aynı zamanda yazılım geliştirme için açık ihale kavramıyla ilgili temel bir sorun var. Birinin girip, tam olarak ne istediğinizi yaratma şansı, sizin belirttiğiniz zamanda düşüktür.

Biraz esnekliğe izin verirseniz, bunu iyileştirebilirsiniz.

Kamu ihalesine iş verme süreci esnek değildir gibi geliyor. Ancak, sözleşme kazanıldıktan sonra, kırma odası olduğunu görebilirsiniz. Örneğin, çevik çalışmaya izin verebilirsiniz, ancak bunun kapsamı etkileyebileceğini kabul etmeniz (ve yasal izin almanız) gerekir.

Şimdi bunun daha iyi bir ürünle sonuçlanacağına inanıyorum, çünkü erken olanları göreceksiniz ve ürün içine pişirilmeden önce değişiklikler yapacaksınız. Sıkı geri bildirim döngüleri ve yinelemeli geliştirme, gerçek gereksinimlere daha iyi uyan ürünleri yapabilir (ihaleye konulan veya olmayabilir).

Bu bağlıdır, ama muhtemelen evet.

BT ile ilgili herhangi bir projede herhangi bir hükümetle birlikte çalışan herkesin pratikte, ihalede açıklanan 'zor sınırların' asla karşılanmadığını bileceği konusunda para koymak istiyorum. İşler bütçeyi aşma, gecikme ve / veya kapsam değişikliği eğilimindedir. Genellikle bunlardan birkaçı. Hükümetler bunun gerçek olduğunu kabul etmeye istekliyse ve onlara oldukları gibi ilkeler gibi davranmaya istekli olursa, scrum gerçekten işe yarayabilir.

Kişisel deneyimimden (hem kendi hem de profesyonel ağımdaki) hükümet projelerinin çoğunda gereksinimlerin sık sık değiştiğini biliyorum. Sorumlu komiteler ayrıca proje sonunda yer aldıklarında çok fazla geri bildirim alma eğilimindedir. Bunlar Scrum'un çok uygun olduğu problemlerdir.

Bununla birlikte, bu, hükümetler ve kurumları için zihniyette köklü bir değişiklik gerektirecektir. Çoğu ülkede, öyle çok bu değişim hiç gerçekleşecek olası. O zamana kadar, kamu ihaleleri Scrum'la çalışmayla uyumsuz olmaya devam edecek. (Bu konuda, kişisel görüşüme göre, kamu ihaleleri sürdürülebilir herhangi bir yazılım geliştirme uygulamasıyla uyumsuz olmaya devam edecek , ancak bu başka bir zaman için başka bir sorun ...)

Bu kuruma ne önerirsiniz?

Bu noktada hiçbir şey.

Burada eksik olan, şu anki süreçlerinin kendilerine neden olduğu sorunların hikayesidir. Scrum, kör olarak önerecek bir şey değildir. Bir noktası var. Herkese uyan tek beden değil.

Onlara şu anki süreçlerinin neden olduğu sorunları sorun. Dinleyin. Sadece gerçek problemlerini çözen yöntemler önerin. Mevcut süreçlerine karşı önyargılı olacaklar. Tinders, bir gelişim sürecini dikte ediyorlar gibi görünebilir, ancak yapmazlar. Bir teslimat süreci dikte ediyorlar. Fakat bu takımın daha önce yapmak zorunda olmadığı bir ayrım.

Çeviklik, gereksinimler proje ömrü boyunca% 3'ten fazla değiştiğinde en iyi şekilde çalışır. Aksi halde şelale hala çok etkilidir. Günümüzde hala birçok yerde kullanılmaktadır. Ve elbette birçok başarılı geliştirici, süreçlerini hiçbir zaman biçimselleştirmez. Gayriresmi insanlar hakkında değil, zor problemler teknik olduğunda iyi çalışır.

Öyleyse onlara mevcut süreçleri ve yaşadıkları problemler hakkında konuşun. Onlara bu yöntemlerin neye yardım ettiğini anlatın. Ama kırılmadıysa tamir etmeyin.