Hükümet projelerinde Çevik yaklaşımın önündeki zorluklar

Bir önceki Çevik tartışma burada ne belirterek iyi cevaplar vardı kritik yazılım geliştirme Çevik metodolojisi uygulayarak başarısı için. Meselelerin çoğu tipik organizasyon ve yönetim zorluklarıydı, ancak bir nokta beni endişelendiriyor ve müşterinin süreç boyunca dahil olması gerektiği endişesi var.

Müşteri, gerçekçi bir şekilde kontrol edemediğiniz bir şeydir, belki de iş modeliniz sizi, örneğin çok katı bir sözleşmenin şirketi zorla gerektirdiği devlet sözleşmeli işlerine yönlendirir:

• X özelliklerini tam olarak istenildiği gibi sağlayın

• Özellik istekleri bir duvara atılır, bizi rahatsız etme, duymak istemeyiz.

• Müşterinin zihninde bir özellik önceliği kavramı yoktur , hepsi önemlidir ya da biz istemeyiz.

• Aşırı veya son teslim tarihlerine bakılmaksızın, proje Y'den daha az olmayacaktır.

• Tüm işlerin eksiksiz teslimatı için mutlak, kesin, kesin ve pazarlık dışı son tarih.

Daha önce böyle bir müşteriyle hiç çalışmadık, ancak projedeki parayı geçemeyecek kadar iyi. Bu işe ihtiyacımız var.

Buraya geldim ve Çevik gelişime doğru ilerlemek için içerisindeki süreçleri değiştirmek için HARD çalıştı ve burada bu projenin yeni sürecimize uygun olduğu yerleri nasıl uzlaştıracağımı bilmiyorum. Daha önce hiç geliştirme ekibine liderlik etmeme ve bu yolda ilerlememe güven veren açık fikirli bir hands-off yönetiminin lüksüne sahip değildim ve şimdi buradayız dürüstçe kendime bu projenin gerçekten gerçekleştirileceğini söyleyemem. Çevik bir yol. Yönetimin bu yolu benim yönlendirmem konusunda bana güvendiğini ve onları hayal kırıklığına uğrattığımı hissediyorum çünkü şu an içinde bulunduğumuz durum açıkça Şelalesi istiyor. Şimdi geri dönersem, güvenlerini kaybedeceğimden korkuyorum.

Buradaki gibi diğer cevaplar , bu tür bir müşteriyle Çevik'in imkansız olduğunu söylüyor, katılıyor musunuz? Herhangi biriniz benzer bir durumda oldunuz ve işe yaramıştı mı? Agile'yi başarılı bir şekilde gerçekleştirmek için hangi stratejileri uyguladınız?

Sanırım ilk fark edeceğim şey çevik olmak ile çevik olmak arasında bir fark olduğu. Çevik teknikleri ve özellikleri yavaşça yaymak - işlevler arası ekipler, uyarlanabilir planlama, evrimsel / artımlı teslimat, zaman çizelgesi yinelemeler ve hatta Lean kavramlarını tanıtmak, Aşırı Programlama, Scrum veya Kristal'i tanıtmaktan çok farklıdır.

Müşteri katılımından açıkça bahsediyorsunuz. Evet, Çevik metodolojilerin birçoğu müşteri katılımını gerektirir, ancak çevik olması gerekmez. Her hükümet / savunma ile ilgili programda, her zaman müşteriyle temas noktası olan bir program veya proje yöneticisine sahiptim. Bu kişi "müşterinin sesi" olur. Telekonferans ya da e-posta ya da arama ve açıklama neticesinde yavaşlayabilir, ancak ekibinizin müşteri temsilcisi olan tek bir kişi (ya da Başbakan yardımcısı varsa bir grup) olabilir. Kuşkusuz, tamamen aynı değil. Fakat esnek olmak ve değişime cevap vermek konusunda çevik olmak değil mi?

Ayrıca birkaç anahtar kavramdan da bahsediyorsunuz: önceden tanımlanmış gereksinimler, "duvarın üstüne atılmış" özellik istekleri, "hepsi önemli" olduğu için önceliklendirme eksikliği ve sabit maliyetli ve / veya sabit zamanlamalı projeler. Bunların her biri farklı şekillerde ele alınabilir.

Tüm ihtiyaçlarınızı önceden karşıladığınızı düşünüyorsanız, şansınız yoktur. Gereksinimler değişiyor. Sadece "bitmiş ve imzalanmış" bir şartnameye sahip olmanız, onun taşa konması anlamına gelmez. İhtiyaç belgeleriniz ne olursa olsun, onları nasıl rahat hissettiğinizi ve / veya sözleşmede belirtilen şekilde yakalayın ve gereksinimleri, tasarımı ve mimariyi sağlayın. Ek olarak, bunlara canlı belgeler olup olmadığına bakın (bugün işteyken gördüğüm tasarım dökümanı Revizyon G olarak etiketlendi, yani 8. güncellemede olduğu). Herhangi bir yinelemede TBD olarak ne kadar bırakabileceğinizi ve şu anda ne kadar sıkılaştırılması gerektiğini sorun - bir şeyler alıp verebilirsiniz.

Belgelerinize çevik olun. "Ekibinizin ne istediği" ile "müşterinin ne istediği" arasındaki çabaları çoğaltmayın. Örneğin, müşteriniz geleneksel bir yazılım gereksinimi belirtimi istiyorsa ve ekibiniz kullanıcı öyküleri kullanmak istiyorsa, geleneksel bir SRS’ye uyum sağlamaya çalışın ve zaman harcamak için kullanıcı öyküleri yerine eylem öğeleri ve bir haddeleme eylemi listesi listesi kullanmaya çalışın "Sistem uygulanmalı ..." ve "Çünkü yapabilmeli" olmalı. Yine de, bu takımlar arasındaki disiplini, projeler arasındaki farklılıklara uyum sağlamak için alır. Yansımalardaki sorunları yakalayın.

Gelişmeye başladığınızda, 5 veya 6 yineleme çalıştırabilir ve ardından uygulamanızı bir alt kümesini görmek için müşterinizi tesisinize davet edebilirsiniz. Bu işlemi durulayın ve tekrarlayın. Bazı metodolojilerin talep ettiği sürekli katılım değildir, ancak yüksek görünürlük avantajına sahipsiniz. Müşteriniz hayır diyorsa, en azından denediniz. Evet derlerse, çevik olmalarını aydınlatabilirsiniz. Çalıştığım bir projede, müşteri siteyi birkaç ayda bir ziyaret etti (genellikle 3-5 ay). QA testinden geçmemizi izlerler, endişeleri mühendislerle tartışırlar ve program / proje ofisi ile iş yaparlar. Herkesin aynı sayfaya girmesi için bir fırsattı.

Test ve bakım, diğer çevik projelerde olduğu gibi gerçekleşir. Test prosedürlerinizi ve doküman kusurlarınızı uygun şekilde oluşturun, sözleşmeden doğan her yükümlülük için metrikleri izleyin ve test sonuçlarını belgeleyin. TDD'yi takip etmek istiyorsanız, devam edin. Sürekli entegrasyon başka bir iyi fikirdir. Proje durumu toplantıları sırasında proje yöneticiniz bu bilgileri “N gereklilikleri uyguladık, M testleri yaptık, X testleri geçti” diyebilir ve paralı insanlara proje sağlığı ve durumu hakkında güncelleme yapabilir.

Paradan bahsederken, sabit maliyet ve / veya sabit zamanlama problemimiz var.

Sabit bir programla başa çıkmak oldukça basittir. Gereksinimlerinize göre, kaç tane yineleme tamamlayabileceğinizi biliyorsunuz. Her yineleme için iş yükünüz, uygulama, test etme ve entegrasyon özellikleri bakımından taşa ayarlanmıştır. Zor olabilir, ancak özellikleri parçalamak ve bunları yinelemelere önceden atamak imkansız değildir. Bu, müşteriyi davet etme konusundaki noktama geri dönüyor - bir yılınız varsa ve 2 haftalık yineleme kullanıyorsanız, belki de müşteriyi üç ayda bir davet edin (ve her üç ayda bir davet edin) ve önceki çalışmanın sonuçlarını gösterin. Gereksinimleri öncelik sırasına, gelecek planlarına ve zamanlamaya nasıl gittiğini görmelerini sağla

Sabit bir bütçe ile baş etmek benzer. Proje için ne kadar zamanınız olduğunu, proje için ne kadar kaynağınız olduğunu, ne kadara mal olduklarını ve dolayısıyla her bir yineleme için kaç saat çalışabileceğini biliyorsunuz. Bu, herkesin bunu dikkatlice takip etmesini sağlama meselesi. Şirketiniz fazla mesai masraflarını yiyebiliyorsa, bunun için gidin. Aksi takdirde, herkesin uygun bir süre çalıştığından emin olun ve herkesi üretken tutmak için iyi zaman yönetimi becerilerini ve zaman boksunu kullanın. Maliyetleri düşürmek için ihtiyacınız olan daha verimli saatler, toplantı masrafları ve ek masraflar olmadan katma değeri yüksek belgeler ve yazılımlar sunar.

Sonuçta, bu mutlaka Çevik olmakla ilgili değil, Çevikliği iyi ve çevik yapan şeyleri uygulamakla ilgilidir. Gereksinimlerdeki değişikliklere cevap verebilme, müşteri istemese de sık yazılım sunabilme, yalnızca katma değer sağlayan belgeler üretme (sözleşmeyle ne şekilde yapmak zorunda olursanız olun).

Evet, çevik, böyle bir proje için uygun değildir, çünkü şartlar halihazırda yapılmış ve sabit olarak anlaşılan, muhtemelen pahalı danışmanlar, komite toplantıları ve politik uzlaşmanın yıllarca süren analizi sonucu ortaya çıkması gibi. Şelale, müşteri ne kadar disiplinli ise, tam olarak ne istediğini size yazılı olarak söyleyebilecek kadar iyi çalışıyor. Yanlış olabilirler, ama en azından yazılı olarak alıyorsunuz ve eğer teslim ederseniz ödeme alacaksınız. (Bu elbette, müşteri memnuniyeti hakkında hiçbir şey söylemedi. Şüphesiz, ihtiyaç duymadıkları bir şeyi sunma ihtimaliniz var.)

Çevik olmayan bir sorunu çözmek için yaratıldı: gereksinimlerdeki belirsizlik nedeniyle risk.

Müşterinin değişiklik talepleri isteyebileceği doğrudur, ancak iki yoldan birini takip edersiniz:

1. Para o kadar iyiydi ki, projenin çeşitli aşamalarında X miktarındaki yeni özellikleri emebiliyorsunuz ve hala gömleğinizi kaybetmeden ortaya çıkıyor
2. Müşteriye, sıkı bir fiyat için pazarlık yaptıkları için, her yeni özellik talebinin, kendileri tarafından onaylanması gereken bir fiyatla birlikte, ekli bir satınalma siparişiyle (veya değişikliğinde) bir değişiklik siparişi üreteceğini açıkça belirtirsiniz. (orijinal satınalma siparişi) bunu uygulamanız için. Değişiklik sırası, işlevsellik veya programa herhangi bir etki bırakacaktır. Son teslim tarihinin taşınamadığını söylerlerse, değişiklik sırasını değiştirmek, proje ilerledikçe üssel olarak daha pahalı hale gelir, çünkü daha sonra işleri değiştirmek daha pahalıdır.

İlişki # 1 durumu altında daha dostça hissediyor, ancak gerçek şu ki, sizi fiyatın üzerine sıkmayacak olan satın alma departmanları bulmak oldukça nadirdir, bu nedenle çoğu zaman durum sizde # 2. Bu, ilişkinin çatışmalı olduğu anlamına gelir, ancak işte hayatta kalmak istiyorsanız, ilişkinizi sürdürürken ilişkiyi yönetmede iyi olmanız gerekir. Bu, proje yöneticisinin işinin büyük bir kısmı.

Durum # 1'de olabilirsiniz, ki bu iyi bir şey. O hükümet sözleşmeleri sonuçta onlar harcadığımız değil, çünkü onlar para umurumda değil tek yer hayal onların parasını, onlar harcadığımız senin para.

... hükümet, örneğin çok katı bir sözleşmenin şirketi şunları yapmak zorunda kaldığı durumlarda, sözleşmeli işler:

İlk. Sıkı. Ama esnek değil. Sadece detaylara ve uzun, uzun bir değişim emri dizisine dikkat edilmesi gerekiyor.

Devlet kurumları aslında yavaş, verimsiz bir şekilde çeviktir. Her zaman resmi, ayrıntılı değişiklik siparişleri yazmanız (ve pazarlık etmeniz) gerekir.

X özelliklerini tam olarak istenildiği gibi sağlayın

Bir değişiklik sırasına göre değiştirilinceye kadar.

Özellik istekleri bir duvara atılır, bizi rahatsız etme, duymak istemeyiz.

İletişim kanalı değişim sırasıdır. Bütçe ve Zamanlama Etkisi.

Müşterinin zihninde bir özellik önceliği kavramı yoktur, hepsi önemlidir ya da biz istemeyiz.

Bu çalışmak zor. “İhtiyaç analizi” için çok para harcayan hükümet dışı işletmeler bile, öncelik ve tradeoff bilgilerinin eksik kaldığı büyük, düz, buğulayıcı bir gereksinim yığını olduğunu söylemek istemiyor. Tüm gereklilikleri elde etmek için iyi para ödediler . Daha fazla bilgi nasıl istersiniz?

Bu zor bir problem.

Aşırı veya son teslim tarihlerine bakılmaksızın, proje Y'den daha az olmayacaktır.

Değişim emri hariç. Bu Y ve Son Tarihi değiştirir.

Tüm işlerin eksiksiz teslimatı için mutlak, kesin, kesin ve pazarlık dışı son tarih.

"müzakere edilemez" genellikle doğru değildir. Pazarlık edilebilir. Sadece pazarlık etmek acı verici.

Devlet kurumlarıyla müzakere etmenin önemli kısmı, maliyet ve zamanlama değişiklikleriniz için "avukat düzeyinde kanıtlara" ihtiyacınız olması gerçeğidir. Güzel bir power point slaydı olan birkaç dikkatli teknik sunum "kanıt" değildir. Durumunuzu düzeltmek için çok fazla belgeye ihtiyacınız var.

Hükümet halkı, bunu mümkün olduğu kadar ucuz ve etkili kılmak için ellerinden gelen her şeyi yaptıklarına dair anlaşılmaz kanıtlar sunmalıdır. Her kararın kamuoyunda tekrarlandığını ve arka bakışta incelendiğini biliyorlar.

Yazılım geliştirmenin karmaşıklığı ve devletin çalışmalarının "pazartesi sabahı oyun kurucu" özelliğinin son hali, onları bunaltıcı deliller olmadan sözleşmede değişiklik yapma konusunda isteksiz kılmaktadır .

Düzgün bir Çevik yaklaşımı zorlaştırır.

"Bireyler ve süreçler ve araçlar üzerindeki etkileşimler" zordur. Bir bireyle çalışmıyorsunuz, ancak işi yapan devletin temsilcisi bir süreçle kısıtlanıyor.

Böyle bir projede, ellerinizi kapsam, kaynaklar ve zaman üzerine bağladılar. Yönetmen için bıraktığın tek şey kalite. Yani...

Aksi takdirde yapabileceğiniz çevik bir yaklaşımdan en fazla faydayı elde edemezsiniz, ancak kalite risklerini azaltmak ve sorunları müşteriye daha önce değil de bildirmek için elinizden geleni yapabilirsiniz.

Yani olabildiğince çevik ol:

1. Gereksinimleri gözden geçirin ve teknik risk konusunda en iyi duruma getirin. Öncelikli gereklilikleri biriktirme listeniz olarak ayarlayın.
2. Sprintlerdeki birikim üzerinde çalışın - sprint için özellikleri tasarlayın, test edin ve kodlayın. Müşteri etkileşimi eksik, bu nedenle gereksinimler belgesi bu etkinlik için müşteriyi temsil etmek zorunda.
3. Müşteriyi her sprint incelemesine davet edin - hayır diyebilirler, ancak evet diyebilirler. Ve daha sonra değil, geri bildirim alacaksınız.

Son tarihe karşı koşmaya başlarsanız, ne yaptığını gösterebileceksiniz ve belki de bu noktada müşteriye, her şeyi elde edemeyeceğini bilerek, ne istediğini size söyleyebilecek kadar önceliklerini belirleyeceksiniz. Ayrıca, en riskli işlere de sahip olmalısınız, bu da son zamandaki görevlerin, mesai saatlerinde çalışmak için en kolay iş olduğu anlamına gelir.

Bence bu tür bir müşteri norm değil. Daha önce benzer projeler isteyen bir grupla uğraşıyorsunuz, bu yüzden ne istediklerini tam olarak biliyorlar. Özelliklerinin değişeceğini asla söylemiyorsunuz.

X özelliklerini tam olarak istenildiği gibi sağlayın

X özelliğini belirttiğim gibi belirgin bir şekilde sağlarsam ve kısa bir süre sonra değiştirmeye hazır olursam şanslıyım.

Özellik istekleri bir duvara atılır, bizi rahatsız etme, duymak istemeyiz.

Ne istediklerini biliyorsan, git ve yap.

Müşterinin zihninde bir özellik önceliği kavramı yoktur, hepsi önemlidir ya da biz istemeyiz.

Bu konuda kaybedemezsin. Uygun gördüğünüz gibi onları oluşturun.

Aşırı veya son teslim tarihlerine bakılmaksızın, proje Y'den daha az olmayacaktır. Tüm işlerin eksiksiz teslimatı için mutlak, kesin, kesin ve pazarlık dışı son tarih.

Hiç bir şey için bir proje yapmadıysanız bu zor bir şey. Bazı geçmişiniz varsa, teslim edip edemeyeceğinizi belirleyebilirsiniz. Bu, iyi para vermeyecekleri anlamına gelmez (10 dolarlık bir çekiç için 50 dolar ödedikleri için dürüstler.) Veya makul olmayan beklentiler vardır. Bu şartnamelerle, ekibinizdeki birinin müşteri olarak hareket etmesi ve çalışmayı şartnameye göre onaylaması gerekir. Bir kusur bulup gereksinimlerini değiştirmeleri için yalvarsanız bile, muhtemelen yapmazlar.

Ne yazık ki tanımladığınız şey, bir yazılım projesinin nasıl ele alınması gerektiği konusunda tipik müşteri görüşüdür. Bu, müşterinin mantıksız olduğunu söylemek değildir; sonuçta - bu, başka bir şeyin inşasını nasıl yapacağı anlamına gelmez mi (örneğin bir ev?). Bu söyleniyor olsa da, aslında zaten bildiklerimizden başka bir şey önermiyorum. İstediğiniz şey şu ki ... bu durumda uygulanabilir çevik uygulamaların uygulaması mı?

Anlattığınız duruma göre pek çok açıdan benzer bir projeyi yeni bitirmiş olmanın yararına sahibim.

1. Sabit (taş, cehennem veya yüksek su gelmesi) son tarih.
2. İşlevsel Gereksinimler Belgesi ("İncil"). Şaşırtıcı derecede yetersiz.
3. Geleneksel roller: Proje Yöneticisi, İş Analisti.
4. Zayıf çalışan iş kullanıcıları ("ürün sponsoru yok" diyebilir misiniz?).

... ve elbette, ileri görüşlü geliştirme ekibi, yukarıdakilere rağmen çevik bir şekilde çalışmaya çalışıyor:

1. 2 hafta tekrarlama;
2. Stand-up;
3. retrospektifler;
4. Çiftler programı;
5. TDD;
6. Sürekli entegrasyon

Bunlardan herhangi biri uzaktan İşletme için anlamlı mı? Hayır. Son teslim tarihine iki ay kala, dikkatlice gözlemlenen yinelemeler ve planlama toplantıları başsız tavuk-itis telaşında terk edildi.

Başkalarının yukarıda vermiş olduğu cevaplar, daha büyük veya daha az ölçüde ödün vermek içindir. Benim düşünceme göre, çevik ("Çevik" veya "çevik" olsun), taviz verdiğimizde titiz bir şekilde "yapılır". Bana göre:

Uzlaşma yok ya da çevik yok.

Çevikliğin ruhu kovalamacayı kesmek, israfı kaldırmak, vahşice dürüst olmakla ilgilidir . Büyük projelerdeki yazılım tahmininin en iyi ihtimalle bir kumar olduğu artık iyi belgelenmiş ve inkar edilemez bir gerçektir. Bu konuda potansiyel müşteriler yetiştirmek yazılım uzmanları olarak bizim görevimiz değil mi? Müşteriler bizim uzman olduğumuzu kabul etmek istemiyorsa, o zaman uzaklaşmak bizim profesyonel görevimiz değil mi?

Şu an bulunduğum yerde çalışmaya başladığımda, kendinize çok sorduğunuz soruyu sorarken buldum. Devlet ihaleleri ile şelale için söylenecek bir şey var. İronik olarak, çevik artık devlet müşterileriyle (gerçekçi bir şekilde şelale şeklinde çalışan) buzzword haline geldi, şimdi temelde esnek olmayan bir müşteriyle çevik bir süreci uygulamak için daha da zorlanmaya devam ediyoruz.

"Scrummerfall" "Agilefall" veya "A karmaşa" olarak tanımlanmış bir sistemimiz var, ancak birçok bakımdan, bu (devasa) projenin yıllar içinde ilerlediği gibi daha çevik bir süreç benimsemiş olduk. . Bunu yapmamızın yollarından biri, MÜŞTERİLERİMİZ'in aksine, sistemimizin KULLANICILARI ile iletişim kanallarını geri bulmasıdır. Müşterilerimiz, çalışma hayatlarında yazılımımıza asla dokunmayacak ve bunu anlamak istemeyen atanmış yetkililer tarafından yürütülen havasız bir departmandır. Kullanıcılarımız, alanında önemli bir görevi yerine getirmeye çalışan düzenli devlet personelidir. Bizim için, bizim kadar çevik olmamızı sağlayan bir iletişim geri bildirim döngüsü oluşturmanın anahtarı UAT (Kullanıcı Kabul Testi) gerekliliğiydi.

Projemizin ilk aşamalarında, geniş çaplı devlet müşterilerimizin çeşitli ofislerinden gelen GERÇEK KULLANICI grubunun temsilci bir grubunun BURADA yerde toplanmasına karar verildi ve bir dizi işlemi yürüdüklerinde onlarla bir kaç hafta geçirdik. Yazılımımızı test etmek için komut dosyalarını test edin. Gayri resmi bir şey olarak, gereksinimler ekibi bu zamanı gerçek son kullanıcılardan geri bildirim almak için paha biçilmez bir yol haline getirdi. Bu arada, hükümetin içindeki UAT test ekibi bürokrasilerinde, değişim emirleri dahil olmak üzere sona ermeleri gereken resmi gereksinimler süreci üzerinde giderek daha fazla etkiye sahip olmak için çalıştı. Sonuç, benim gibi BA'ların, scrum ekiplerine gömülü stand-in ürün sahipleri gibi davranması ve çok çevik bir şekilde çalışmamıza izin veren gerçek müşterilerle paha biçilmez yüz zamanı elde edebilmeleridir.

Açıkçası, pek çok sorun var ve hala çok çevik değiliz, ancak aslında hükümet müteahhitlik sektöründe bu metodolojiyi kullanan büyük bir çevik projenin örneği olarak ortaya konacak kadar çevikiz.

Özetle: Deneyiminizi, müşterinize sızmak için kendi organizasyonunuzda çevik bir saldırgan olarak kullanın. Onlarla bir öğrenme sürecinden geçin, kendi taraflarındaki kilit kişilerle güvene dayalı bir ortaklık kurun ve kaçınılmaz olarak uyguladıkları resmi, onaylanmamış Gereksinimler Süreci AÇILIŞINDA çalışın. Geliştirdiğiniz şeyi kullanmak zorunda kalanlar, sizler tarafından teşekkür edilecektir!

Gereksinimlerin iyi yazıldığını ve ne demek istediklerini kastettiklerini sanıyorsunuz. Çevik sürecin ileri ve geri, istediklerinin yanı sıra ne anlama geldiklerini anlamalarına yardımcı olacaktır.