Scrum'da Proje Kapanışları

Tipik bir yazılım geliştirme ortamında, proje kapanışları bir projenin sonunu gösterir.

1. Proje kayıtları tamamlanır ve arşivlenir,
2. serbest bırakılan kaynaklar,
3. sorunlar ve dersler belgelenir ve
4. kutlama için düzenlenen resmi bir akşam yemeği / parti.

Son adım isteğe bağlıdır, ancak katılımcılar için çok motive edicidir. :-)

Bunu Scrum ile karşılaştırın. Scrum'ın biriken işlerdeki hikayeler üzerinde çalıştığını biliyorum . Yani, teknik olarak, her yineleme belirli hikayeleri kapatır. Burada iki soru var.

1. Birden fazla eşzamanlı projede çalışan bir grup için proje kapanışları nasıl uyum sağlar?
2. Birden fazla grup içeren bir proje için bu kavram nasıl uygulanır?

Veya proje kapatma terimi T&M projeleri için hiç geçerli değil mi?

Birden fazla eşzamanlı projede çalışan bir grup için proje kapanışları nasıl uyum sağlar?

İlk olarak, "çoklu eşzamanlı projeler" gerçekten kötü bir fikir olarak kabul edilir. Scrum noktası sprint ve yapılmasıdır. Projeleri başka bir sprint başlatmak için değiştirmek rahatsız edici. Aynı anda iki proje yapmak bir sprint değildir. Bu bir karmaşa.

Ancak Scrum, çevik olmayan (şelale) bir yöntemden farklı değildir. Biriktirme listesi yaklaşık sıfıra düşürüldüğünde, işleminiz tamamlanmıştır. Tıpkı çevik bir yaklaşım yerine bir şelale yaklaşımınız varmış gibi yapılır.

Bazen biriktirme listesi sıfır değildir, ancak müşteri memnun olur ve artık istemez. Yani aynen bitirdiniz. Genellikle bir şelaleden daha erken ve daha ucuz yapılır (her şeyi inşa etmek zorundadır, hatta işe yaramaz olduğu ortaya çıkan fikirler bile).

Birden fazla grup içeren bir proje için bu kavram nasıl uygulanır?

Birden fazla grup içeren scrum olmayan bir proje ile aynı. İnsanlar hakkında hiçbir şey değişmez. Hala iyi bir partiyi seviyorlar.

Veya proje kapatma terimi T&M projeleri için hiç geçerli değil mi?

Faturalandırma neden işin niteliği veya sonunda yapılan törenle ilgili bir şey değiştirsin?

Genellikle daha yapılandırılmış bir proje yönetimi çerçevesinde scrum uygulamaları gibi çevik yöntemler görürüm. Bu hiç de bir çelişki değil. Agile teslimat için çalışır, amacı doğru yazılımı daha hızlı sunmaktır. Geliştiriciler ve paydaşlar arasındaki etkileşimlere yardımcı olur. Belirli bir süre programının parçası olarak veya açık uçlu geliştirmeler için kullanılabilir.

Bu nedenle, proje yönetiminin geri kalanının geleneksel bir şekilde yönetilememesinin bir nedeni yoktur; bir PM, zaman çizelgesini, maliyetleri ve diğer bağımlılıkları yönetir. Tamamlandığında her zamanki gibi kapanış etkinlikleriniz olur.

Finansta çalışıyorum, bazen yeni düzenlemeler oluyor, ya da yeni bir borsa ortaya çıkıyor ve taşa ayarlanmış olan için canlı bir tarihimiz var. Teslimat için hala Çevik bir yöntem kullanıyoruz, ancak daha geleneksel bir proje yönetim çerçevesi içinde, zamanında teslim edilmesini sağlıyoruz.

Çalışma birimlerinin tahmini ve mevcut zaman diliminde ulaşılabilir bir çözüm seçilmesi bizi iyi geliştiriciler yapan şeydir (Söylemem gereken şeylerden biri).

Scrum'da, tüm Çevik tekniklerde olduğu gibi, projeler bir araya gelip giderken projeler gelip giden küçük şeylerdir. Yani böyle bir "proje-clojure" ritüeli yoktur. Daha ziyade başka bir cilalanırken proje azalır. Biriktirme listesi öğelerinin akışı yavaş yavaş birinden diğerine geçer. Takım farkı neredeyse hiç bilmiyor.

Gerçekten de ekip aynı anda iki veya üç farklı proje üzerinde çalışıyor olabilir. Yine, farkı zar zor biliyorlar. Birikmiş işler öğeleri her sprint başında takıma gelir ve ekip bunları uygular. Hepsi bir projeye ait olabilir veya birkaç proje arasında eşit olarak bölünebilir. Takım umurunda değil. Ekip, kendilerine verilen birikmiş işler kalemlerini uygular.

İşletmenin projelerin önceliğini değiştirmesi gerekiyorsa, birikmiş işler öğelerinin ekiplere akışını basitçe değiştirirler.

Burada tartıştığınız bazı şeyler, çevik süreçlerin çoğuna maruz kalacak, bazı harici tetikleyicileri beklemek yerine, elbette sıklıkla ortaya çıkan dokümantasyon ve sürümler gibi şeyler olacaktır. Tabii ki, ne tür müşterileriniz olduğuna ve ne tür bir işletmenizde bulunduğunuza bağlı olarak her zaman böyle olmayacaktır. Örneğin, harici bir kuruluşun sahip olduğu daha büyük bir sistemin tek bir parçasını oluşturuyorsanız, genellikle süreci yönlendiren bir tarih vardır ve bu tarih ek temizlik ve elbette parti yapmak için uygun bir zaman olacaktır. Diğer zamanlarda, müşteri dahili olsa bile, işletme yine de proje defter tutma / parti işleminizin sona erdirilmesi için çağrıda bulunan bir işletme kilometre taşının / büyük bir teslimat kaleminin / diğerinin tamamlandığını fark edebilir. Şirketiniz sürüm planlamasıyla uğraşıyorsa, bu size doğal kırılma noktaları verecektir, ancak yapmasanız bile, iş odaklı başarı ölçülerine sahip olmak mükemmel bir şekilde uygundur. Yani, projeler artık mühendislik sürecinizin bir özelliği olmayabilir, ancak kesinlikle işinizin bir parçası olabilir ve onlarla kutlama / uğraşma, şirketinizin kültürünün bir parçası olabilir ve yine de olmalıdır.