Geleneksel proje başlangıcından sonra çevik gelişimi tanıtmak

Yaklaşık bir buçuk yıl önce, Agile geliştirme yaptığını iddia eden bir işyerine girdim. Ne öğrendim burası birkaç çevik uygulamalar (günlük standups, sprint planlamaları ve sprint değerlendirmeleri gibi) benimsedi ama ilkelerin hiçbiri (sadece zamanında / sadece yeterince iyi zihniyet, başarısızlık erken ortaya çıkarmak, zengin iletişim) oldu.

Şimdi ekibi daha çevik yapmakla görevlendirildim ve geliştiricilerden ve iş ekibinden tam olarak satın aldığımdan emin oldum. Bir pilot program olarak, bana sadece 15 aylık gereksinimlerin toplanmasını tamamlayan, 110 sayfalık Analiz ve Tasarım belgesine ("taş yazılmış" olarak kabul edilecek) sahip olan ve sonuna kadar erişemediğim bir proje verdiler kullanıcıları (yalnızca ürünü gerçekten kullanmayacak olan kullanıcı yöneticilerinden oluşan komiteye).

Küçük başladım, onlara ilk 5 sprint için beklenen çıktıların bir listesini (gelecekteki sprint'leri tanımsız bırakarak), ilk sprint için hedeflerin bir listesini verdim ve ilk sprint'in hedeflerine ulaşmak için yeterli kullanıcı hikayeleri elde etmek için A&D belgesini inceledim .

O zamandan beri, neden tüm sprintler için tüm gereksinimlere sahip olmadığımızı, neden üçüncü sprint için şeyler üzerinde çalışmaya başlamadığımı sordular (daha önemli olduğunu düşünüyorlar ancak ilkinin çıktılarını temel alıyorlar) 2 sprint) ve tüm BT ekibimin yoğun çalıştığımız veya bizimle alakasız olduğunu düşündüğü daha fazla dokümantasyon için baskı yapıyoruz (kullanım kılavuzunu ön tarafa yazmak, tüm sprint'lerden tüm veri alanlarını dokümante etmek ve daha fazlası gibi) "ön" çalışma).

Bu, yeni bir proje yöneticisi olarak benim için oldukça zor oldu, ancak hikaye yönetimi için scrumban, çift programlama ve işin bize müşteri kabul testleri vermesini (gereksinimler belgelerinin bir parçası olarak) etkin bir şekilde uyguladığım iyileştirmeler var. .

Yani sorularım:

1. Dayanıklı bir işletmeye değişimi daha etkin bir şekilde tanıtmak için ne yapabilirim?
2. İşletmeye çevik avantajları göstermek için BT tarafında uygulayabileceğim başka uygulamalar var mı?
3. Dokümantasyon yükü bizi boğuyor - işletme bunu bir risk yerine bir risk yönetimi stratejisi olarak görüyor. Dokümantasyon kaygılarını ve taleplerini hafifletmek için ne yapabiliriz (özellikle dokümantasyon miktarı ve bunların hepsine olan ihtiyacı).
4. Biz işimizden ayrı bir binadayız, yaklaşık 3 blok ötede ve bu projede çalışanlarının bu ortak projeye sahip olmalarını reddediyorlar. bina." Bizden her zaman oraya gitmemizi ve sorularımızı bir araya getirmemizi bekleriz, böylece hepsine bir kerede sorabilir ve o kişinin zamanını "sürekli kesintilerle" boşa harcamayız. Onlardan daha zengin iletişim kurmak için ne yapabiliriz?

Herhangi bir ek tavsiye de takdir edilecektir.

Teşekkürler!

Ben devs ve iş ekibi tam buy-in olduğundan emin oldum [...] Son kullanıcılara erişim yok [...]

Oldukça açık bir şey, sözlü olarak "buy-in yaptığınız" ve diğer yandan çalışmanıza sponsor olan kimsenin gerçek bağlılığı arasındaki farktır.

Size en iyi tavsiyem "Agile" etiketini bir kenara bırakmak. Sözcüğü mümkün olduğunca konuşmadan yasaklayın. Bunun yerine, aşağıdakilere odaklanın:

• Hangi sonuçları sunmanız istenir (siz özellikle ekip değil)
• Ne başarı kriteri görev için olan (yine yerine takımın daha size ait)
• Ne araçlarının (neyse insanlar, insanlara erişimi, zaman, bilgi, eğitim bütçesi dahil) emrinde var

"Ekibi daha çevik hale getirmek" eyleme geçirilebilir bir hedef değildir. Yeterince spesifik değil, ölçülebilir değil, son şartı yok. İhtiyacınız olan şey belirli bir şeydir: Z tarihine göre yüzde X daha az kusur veya özellik teslim tarihlerinizin yüzde Y değeri olarak ifade edilen bir hedef.

Bu hedeflere ulaşmak için değişiklikler yapmanız gerekebilir. Şimdi birkaç kural geçerlidir. Her gelişme bir değişikliktir, ancak her değişiklik bir gelişme değildir. Genellikle insanlar değişime direnirler, ama aslında insanlar resist söylenir değiştirilmesini ve değişim bir gelişme olup olmayacağını bilmeden.

Kolay kazançlar, düşük asılı meyveler olacağını düşündüğünüz uygulamalara odaklanın. Sadece değişimi uygulamak için değil , değişimin etkilerini değerlendirmek ve insanlara gerilemeden ziyade iyileşme ile sonuçlandıklarını güvence altına almak için bir çerçeve oluşturan uygulamalara odaklanın . "Bilgi radyatörleri" ve geriye dönük olarak iyidir.

Bu değişikliklerin bazıları, temel bilgilere sahip insanlara daha fazla erişime sahip olmak gibi, hem gerekli hem de tehdit edici olarak algılanabilir. Bunlardan ödün vermeyin: "içeri girmek", siyasi katliamlara kuzu gibi götürülmemek üzere, size gerçekten istendiğiniz şeyi sunma şansınız olduğu bir müzakere süreci anlamına gelir.

Bir şeyler kurmaya çalışın, böylece işler doğru gitmezse suçu size kaydırmak zorlaşır (ve muhtemelen yanlış gidecektir). Bunun olabileceğinin farkında olun ve eğer gerçekleşirse hazırlıklı olun: çıkış stratejinizi öğrenin.

Yeni bir şeyi sorunsuz bir şekilde tanıtmak için, insanların bunu bir tehdit ve kalıcı olarak görmeyeceğinden emin olmanız gerekir .

Birçoğumuz doğal olarak her türlü yeni şeyden kaçınmak için kablolanmış durumdayız. Biyolojik. Genellikle yenilik arayan insanlar size asla sorun çıkarmaz. Daha endişeli insanların önerinizi mevcut konforları için bir tehdit olarak görmeyeceğinden emin olmalısınız.

Bir ekibin bir uygulamayı veya fikri benimsemesinin ideal yolu, fikrin onlardan geldiğinden emin olmaktır ve yönetim veya daha da kötüsü bazı rastgele danışmanlar gibi dış kişilerden değil. Bunun gerçekleşmesi için, tüm ekiple sadece tek bir konu hakkında beyin fırtınası toplantıları oluşturun. Konu sorun olmalı. Toplantıda, fikirleri dikkatlice getirmeniz ve argümanlar ve gerçeklerle gelmeniz gerekecek.

Kalıcı şeyler hakkında karar vermek istemiyoruz. Potansiyel bir değişikliğin etkisiyle zaten endişeliyiz. Bu davranış evcil hayvan dükkanları tarafından iyi bilinir. Bir köpek satın almak çok büyük bir karardır ve muhtemelen hayatınızı kökten değiştirecektir. Mağazada olduğunuzda, satıcı genellikle onu eve götürmenizi ve fikrinizi değiştirirseniz iade etmenizi önerir. Tahmin edebileceğiniz gibi, çok az geri dönüş var. Teklifin tek bir amacı var: insanların karar almasını engelleyen kaygıyı azaltmak. Takım çalışmanıza, etkisini değerlendireceğiniz şeyden sonra sabit bir süre denemenizi öneririz.

İkinci sorunuzla ilgili olarak, her seferinde bir şey getirmenizi şiddetle tavsiye ederim.

Belgeleme probleminiz P.SE'de kendi gönderisini hak ediyor ve her ikisi de düzenli olarak buluşmaya istekli iseniz iki farklı binada olduğunuzla ilgili herhangi bir sorun görmüyorum. Taraflardan birinin hiç görüşmek istemediği bir durum var;)

Çevik herkes için değil, işiniz sadece çevik demekten hoşlanıyor gibi geliyor, çünkü en ateşli kelime. Her şeyden önce, işlemlerini gerçek çevik metodolojiler gibi yapmaya başlamak için yepyeni bir proje veya daha küçük bakım projelerini zorlamak iyi bir fikir olurdu. Halihazırda devam etmekte olan bir projeyi kullanarak bir metodolojiyi yeniden tasarlamaya çalışmak, 8 şeritli bir otoyolun ortasında bir lastiği değiştirmeye çalışmak gibidir. İş çevikliğinizin işe yarayabileceğini göstermenin bir yoluna ihtiyacınız var, ancak çalışma şansına sahip olduğu bir ortama ihtiyacınız var, ancak çeviklerin söylediklerine dayanarak yerleşik kültürleriyle iyi çalışma olasılığı düşük.

Dokümantasyon için ne istediklerine bağlı olarak, bunun kullandığınız bir araçtan otomatik olarak oluşturulduğunu veya yedeklendiğini ve B belgesinin A'nın gösterilmesi istenen bilgi belgesine sahip olduğunu gösterebilirsiniz. Ayrıca, dokümantasyon için planlarınızı ayarlamanız, tahminlerinizin neden değiştiğini bildirmeniz ve istenen dokümantasyon miktarını azaltmalarını veya dokümanları oluşturmak için bir iş analisti gibi kaynakları ayırmalarını istemeniz gerekir.

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

Bu senin sorunun. Anlamıyorlar. Birisi sizden daha çevik olmanızı isteyemez ve sürüşe devam etmek istemez. Yanlış beklentileri var. İşe başlamadan önce işler bozuldu. Beklentileri düzeltin yoksa başarısız olursunuz. Sanki 150 MPH kullanmanı istiyor ve sana bunu yapman için bir Chevette veriyorum.

İstedikleri belgelerin zamanını / kaynağını / maliyetini oluşturun ve programı ne kadar uzağa ittiğini görmelerini sağlayın.

Bu, onlara proje ekibine ne kadar iş yüklediklerini ve bunu yapmadılarsa bunun nasıl azaltılabileceğini göstermeye yardımcı olabilir.