Uzun vadeli planlama ve çevik mi?

Ekibim yakın zamanda çalışmalarımız için yaklaşık bir yıllık bir plan hazırlama sürecinden geçti. Planı üç aşamaya ayırdık. Her aşamada birkaç lansman yer alacak.

Acaba, çevik bir bakış açısından, bu yanlış mı? Bence bu kötü bir fikir değil, çünkü ilk birkaç adımdan başka bir şey tasarlamak için fazla zaman harcamadık. Yön değiştirmemiz mümkün. Aynı zamanda sadece yakın görüşte hareket etmememiz güzel.

Projenin nereye gideceğine dair bir vizyona sahip olmak, Good Thing ^TM .

Bunun olacağına kesin olarak inanmak değildir.

“Savaşa hazırlanırken her zaman planların işe yaramaz olduğunu, ancak planlamanın vazgeçilmez olduğunu gördüm.”

- Dwight D. Eisenhower

Çevik metodolojilerin benimsediği yaklaşım, işleri sindirilebilir parçalara ayırmak ve her parça sindirildikten sonra vizyonu yeniden ayarlamaktır.

Bu şu andan itibaren bir yıl içinde bitiş noktanızın tam olarak şimdi düşündüğünüz şey olmayacağı anlamına geliyor. Ancak, listenizdeki tüm yüksek değerli öğeleri ele almalı ve ilerledikçe paydaşlarınızı meşgul ve mutlu etmelisiniz.

Tamam, yönetim planı ile bir efsane sunuldu. Umarım, senin uğruna, seni tutmazlar. Çünkü, görünmeyen görüş, ekibinizin bu uzun vadeli planın söylediği gibi bir şey yapamayacağı konusunda bahse girmeye hazırım. Aslında, endüstri ortalamasını vurursanız, yaklaşık 2 katını kaçıracaksınız. Çoğu kuruluşta bir tahmin, bir kez verildikten sonra, istedikleri kadar sizi yenmek için özgür oldukları kulüp haline gelir.

Muhtemelen sadece alaycı olduğumu düşünüyorsun. Sonuçta, herkesin tahmin ettiğinden çok daha yavaş veya daha hızlı olabileceğini bildiği belirtilmemiş özellikler için belirsiz zamanlar söylediniz, değil mi? Maalesef, çoğu doğru olabilir, ancak insanlar bu sayıları duyma eğilimi bu değildir. Tarihler duymuşlar ve bir kez konuşulan bir tarih, söylediğinizden daha sağlam olduğunu duyma eğilimindedir. Dahası, bir iletişim zinciri varsa, daha da sağlamlaşacaktır. Dış müşteriler, söylediklerinize dayanarak satış yoluyla bir şey vaat ettikten sonra, aniden bu rakamlarda olması gerekenden çok daha az esneklik olduğunu göreceksiniz. Ve garanti ederim ki işlerin ne kadar zaman alacağını hafife aldınız.

Bu bariz nokta ile, yazılım tahmininin gerçekten nasıl yapılması gerektiği hakkında bir şeyler öğrenmek için Yazılım Tahmini'ni okumanızı tavsiye edeceğim . Neyi yanlış yaptığınız ve bir dahaki sefere nasıl daha iyi yapacağınız hakkında çok şey öğreneceksiniz. (Bu süreçte, neden yapacağınızı fazla tahmin ettiğinizden neden bu kadar emin olduğumu öğreneceksiniz.)

Bununla birlikte, çeviklik büyük ölçüde süreci küçük bir takım için uygun olana indirgemekle ilgilidir. Süreci azaltmanın iyi bir yolu, kısa vadede daha küçük şeyleri planlamak için büyük ölçekli uzun vadeli planlamayı azaltmaya çalışmaktır. Aynı zamanda daha dürüst olma eğilimindedir - çünkü gelecekte ne olacağını bilmiyorsunuz. Bununla birlikte, bu genellikle daha büyük iş ihtiyaçlarına uymaz ve bu nedenle, kendinizi çevik olarak ilan edip etmediğinize bakılmaksızın, bazen daha uzun planlar yapmanız gerekir.

Bununla birlikte, iletişim kurduğunuz tarihler hakkında önemli bir gerçeği keşfetmenizi şiddetle tavsiye ediyorum, maalesef sizi ısırmak için son tarih olarak geri dönmesi muhtemeldir. Ve bu gerçek bu. Kullanıcılar kime, tarihe veya özellik setine önem veriyor? Bununla kastettiğim şu. Kuruluşların genellikle önemli tarihleri ​​vardır. Örneğin, bir konferans için veya tatilden önce bir şeyler yapın. Bu durumda önemli olan bir şeyi serbest bırakmaktır ve bir şeyin tamamlanıp tamamlanmadığı o kadar da değil. Diğer zamanlarda gerçekten birlikte yayınlanması gereken bir dizi özellik vardır ve tamlık tam olarak gerçekleştiğinden daha önemlidir. Hangi durumda olduğunuzu keşfederseniz, ekibiniz gelen (neredeyse) kaçınılmaz egzersizi nasıl ele alacağınızı planlamak için çok daha iyi bir konumda olacaktır.

Taş halinde yazılmış bir şey değil, devam etmekte olduğunu düşündüğünüz sürece bir planınızın olması iyi olur.

Buradaki anahtar, düzenli olarak (en az ayda bir kez) yayın yapmak , kullanıcılarınızdan gerçek geri bildirim toplamak ve planınızı bu geri bildirime göre güncellemektir .

Bu, projenin kapsamı değiştiğinde planınızın değişeceği anlamına gelir. Bu iyi bir şey , çünkü kullanıcılarınızın istedikleri hakkında daha fazla şey öğrendiği anlamına geliyor.

Tarafından varsayarsak project-managementve agilesen Scrum'ı demek, bu gitmek için kesin bir yol olmaz.

Gelen ScrumEğer bir yıllık planım var eğer bir yıl içinde aylar olduğu gibi perspektifinden, en azından birçok Sprint'ler olarak sahip olmalıdır. Bu nedenle, bir yıllık planınız iki Sprint arasında değişebildiğinden daha çevikleşiyor.

A Sprint, bir aydan daha uzun olamaz, burada durumun durumuna Teamgetirme taahhütleri .Sprint Backlog ItemsDone

Doneburada önemli bir kelimedir ve her Scrum Teambirinin yapılması gereken bir tanımı olmalıdır, yani yapılması gereken hiçbir iş kalmamıştır. Bir zaman Sprint Backlog Itemolduğu Bitti , bu araçlar analizi, mimari ve teknik dokümantasyon yazılı olduğu ve özellik iyice (birim testleri, entegrasyon testleri, fonksiyonel testler ...) test edildiğini.

Yerleştikten sonra Product Backlogve Öğeler dibe daha az önemli özelliklerle ve en önemlileri ile önceliklendirildiğinde, geliştiricilerin Ekibi (geliştiricilerin) her birinin gelişiminin Product Backlog Itemkendi deneyimlerine dayanarak ne kadar sürmesi gerektiğini belirler . Projenin tam bir yıl çalışacağını belirleyebileceğiniz yer burasıdır. SadeceProduct OwnerYatırımın geri dönüşünden sorumlu olan ya da son kullanıcı için neyin en önemli olduğunu bildiği için Maddelere öncelik verecektir. Ayrıca, Takım burada bir özelliği tamamen geliştirmek için gereken süreyi değerlendirecektir, ancak burada tekrar kullanılabilir kod parçaları olabilir ve bu özelliğin gereksinimlerine uygun, yani daha fazla karmaşıklığı önlemek ve bir Ürünün Takımın gerektireceğini söylediklerinden daha uzun. Ürün İş Listesi'nin mükemmel olması gerekmez! Sistemin geliştirilmesini düşünebileceğimiz kullanıcı hikayelerinin basit numaralandırılması sürecin bu adımında yeterlidir.

Bu sırasında Sprint Planning Meetingtakım bir sonraki için geliştirmek ne olacağı üzerinde taahhüt eder o Sprintnedenle yaratarak Sprint Backlog. Sprint BacklogDayalı bir alt oluşur Product Backlog Itemsolduğunu Teamkaydedilmesini Sprint sonunda yapılacak. Örneğin 50 Maddelik Ürün İş Listesi ve 50 Maddenin tümü için bir yıl yapılması gerekecek, o zaman Takım Ürün İş Listesinden 5 Ürün seçip bu 5 Maddeyle Sprint İş Listesi oluşturabilir. Aynı 5 Madde gerektiğinde diğer Öğelere genişletilebilir / patlatılabilir, böylece Ekibi belki de revizyondan sonra fikrini değiştirir ve Ürün İş Listesinden daha önce seçilen 5 Maddeden sadece 4 Maddesi yapmaya karar verir.

Sprint Planlama Toplantısı sona erdiğinde, tam bir ay boyunca 8 saatten fazla sürmeyecek olan Sprint, Ekibin sadece seçilen Öğeler için işi yapmayı taahhüt etmediği, aynı zamanda işi nasıl yapacağını planlıyor böylece Takımdaki herkes ne yapması gerektiğini tam olarak bilir Sprint, başlayacaktır. Takımın proje uğruna çapraz fonksiyonel olması önemlidir.

Bununla birlikte, mevcut durumda bir ay süren her Sprint'in sonunda, Teamtaahhüt edilen tüm Öğeler, Ürün İş Listesinden seçilen Öğeleri hedefleyen tamamen işlevsel özelliklerin teslim edilebilir bir parçası olacaktır. Teslim edilebilir olması gerekir, ancak buna göre bir anlam ifade etmiyorsa teslim edilmesi zorunlu değildir Product Owner.

Sırasında Öyle Sprint Review Meetingnerede Product Ownergerektiği çağrılır TeamSprint sırasında yapılanları gösterir ve bu, bütün iş o taahhüt varsa o yapmadı neden anlatmak gerekiyor nerede. Geri alınan iş daha sonra geri konur Product Backlogve bir sonraki için kullanılabilir Sprint. Tabii ki, geri alınan bu ürünler, Ürün Sahibi tarafından aksi belirtilmedikçe, hedefin değişmesi halinde bir sonraki Sprint'e dahil edilecektir. Ancak en önemlisi, bir Sprint sırasında bir sistemin hedefi değişse de, kesinlikle gerekli olmadıkça sistemi kesintiye uğratmayın. Sadece Ürün Sahibi Sprint'i kesme yetkisine sahiptir.

Sprint Review MeetingAylık Sprint için en fazla 4 saat sürmesi bittikten sonra (doğru hatırlamıyorsam) Sprint Retrospective Meeting. Bunun gerçekleşmesi Sprint Retrospectiveiçin, TeamScrum Master ve Ürün Sahibinin (isteğe bağlı) neyin yanlış gittiğini, Scrum Ekibinin performansını nasıl geliştirebileceğini vb. Varlığında tartışabilmesi ve buna göre ayarlamalar yapabilmesi için gereklidir .

Zaman çizelgesi Sprint Retrospectivesona erdiğinde, bir Sprint Planning Meetingsonrakini planlamak Sprintve yeniyi oluşturmak için yeni meydana gelecektir Sprint Backlog.

Unutmayın, her Takım Üyesinin üç soruyu cevapladığı (o sırada değil) 15 dakikalık bir stand-up toplantısı Teamyapmaktan sorumludur Daily Scrum:

1. Son Günlük Scrum'dan bu yana ne yaptın?
2. Bir sonraki Günlük Scrum'a kadar ne yapmayı planlıyorsun?
3. Son Günlük Scrum'dan bu yana karşılaştığınız sorunlar veya engeller nelerdir?

Scrum MasterDeğil yükümlü orada olmak ama Ekip Üyeleri düzgün üç soruya cevap bu Daily Scrum toplanır ve emin olmak için gereklidir.

Scrum Master, Scrum Kurallarının diğer Scrum Takım Üyeleri (Scrum Master, Ürün Sahibi ve Ekibi) tarafından saygı duyulmasından sorumludur.

Sonunda, bu basit kuralları izleyerek geliştirme ekibiniz çevik hale gelecektir. Çeviklik, Takımın olabildiğince hızlı bir şekilde, yani her Sprint'in sonunda, Ürün Sahibi tarafından Ürün İş Listesi'ne getirilen değişikliklerin farkına varabileceği herhangi bir değişikliği yakalama yeteneğidir. Tam bir felaket ve oryantasyonun tamamen değişmesi durumunda, şirketin alması gereken maksimum kayıp, bir ayda yaklaşık 20 iş günü olduğu göz önüne alındığında, oldukça ihmal edilebilir bir gelişme ayıdır.

Scrum ve Çevik Yazılım Geliştirme hakkında daha ayrıntılı bilgiye ihtiyaç duyarsanız, lütfen Scrum.org ve Scrum Kılavuzuna bakın .

Bu oldukça bir cevap! Umarım bu en azından proje yönetiminizde size yardımcı olacaktır.

DÜZENLEME # 1

Üç veya dört aşama yapmayı planlarken, siz dediğiniz gibi, Ekibinizin birincil objektif bakış açısından odağı kaybetmesi daha olasıdır. Ekibinizin ne yaptığını yalnızca ilk çeyreğin ardından gösterirseniz, yazılımınızın mimarisini yeniden düşünmeyi ve belki de 20 günden fazla iş kaybını sürdürerek, yeniden tasarlamayı ve yeniden düşünmeyi gerektiren bazı önemli değişiklikler olabilir. Çeviklik ilkesi, değişiklikleri en kısa sürede veya mümkün olan en kısa sürede, yani Scrum için bir Sprint'in zaman kutusunu yakalayabilmektir.

1. Bence olabildiğince çok lansmanınız olmalı. Yazılım geliştirmedeki ilerleme için tek gerçek geri bildirim / metrik, üretimde kullanılan koddur. Yani hangi işlemi kullanırsanız kullanın, canlı yayıldıkça daha çevik hale gelirsiniz. Yani, daha önce gerçek kullanıcılardan gerçek geri bildirim alırsınız ve daha önce adapte olabilirsiniz.

2. Büyük Tasarım Önü yapmamalısınız , ancak birikimi her ayarlamak ve yenilemek üzereyken, hem Scrum (sonraki sprint için) hem de Kanban / flow (oda olduğunda) büyük resmi düşünmek iyi olur. (Devam Eden Çalışma sınırında). Tümü (ürün, hizmet vb.) Düşünüyorsanız, hangi iş öğelerinin size daha fazla değer kazandıracağını düşünmek daha kolaydır.

3. Büyük resmin değiştiğini unutmayın. Biriktirme listesi göz önünde bulundurulduğunda, önceliklerin ayarlanması vb. Büyük resimdeki değişiklikleri de göz önünde bulundurun. Belirli müşterilerin ve hatta tüm pazarların ihtiyaçları dahil olmak üzere işler zamanla değişir. Büyük resminiz bunu yansıtmalıdır, böylece iş planını her yenilediğinizde öncelikleriniz gerçekle hizalanabilmelidir, sadece planı yaptığınızda başlangıçta değil.

Özetle, ne kadar çok incelerseniz ve uyarlarsanız o kadar çevik hale gelirsiniz.

Büyük resim planlaması bu kadar uzun sürmez ve büyük projelerin sprintlerinizi tanımlarken büyük resmi göz önünde bulundurması çok önemlidir, aksi takdirde bir sprint'te alınan kısayollar daha sonra sorun yaratabilir.

Malısın:

1. Siz ilerledikçe gelişecek bir ana planınız (tercihen son teslim tarihleri ​​olmadan) alın.

2. Bir sürat tanımladığınızda, süratin büyük resimle tutarlı olduğundan emin olursunuz. Bu her zaman sprint için ne istendiğine dair fikrinizi değiştirdiğiniz anlamına gelmez. Bazen bir sürat tanımlarken, büyük resminizin ayarlanması gerektiğini keşfedersiniz. Öyle ya da böyle büyük resim planı ve sürat koşuya giren birbiriyle tutarlı olmalıdır.

3. Master plan gittikçe ayarlanmalıdır. Çalışırken bir şeyler öğreneceksiniz. Yeni fırsatlar ortaya çıkacak, planda çatışma noktaları ortaya çıkacak. Ana planı hareket halindeyken anında ayarlayabilirsiniz. Ancak neredeyse her zaman sprintler arasında tekrar ziyaret etmelisiniz - son sprint'ten dersleri dahil etmek ve bir sonraki sprint'in büyük resim ile uyumlu olduğundan emin olmak için.

İş birikimi ve büyük proje planının ayrı yapılar olması bence en iyisidir. Büyük proje sahibi, bağlamı korumak için ana planı hiyerarşik bir anahat biçiminde tutar ve daha sonra bir sonraki sprint'i besleyecek olan biriktirme listesini beslemek için özellikler / görevler çekilebilir.

İş listesi, ana planın aksine, diğer ekip üyeleri tarafından eklenebilir. İş listesi öğelerinin ve büyük resim planının uyum içinde kalmasını sağlamak ana proje sahibine bağlıdır - bazen iş listesi öğesini ve bazen de büyük resim planını ayarlamak.

Bu yöntem, çevikliğin gücünü ve projenizin tüm öğelerini, büyük resim planlama yoluyla belirli bir zamanda mümkün olan en iyi şekilde hizalama gücünü korur.

Jim

Burada Agile karşıtı sıralamamın kısa biçimini ekleyeceğim.

Çevik, büyük projeler için, özellikle de gelecekteki gelişmenin temeli olacak kütüphaneler ve çerçeveler oluştururken çok yıkıcı olabilir. Erken aşamalarda gerçekten önemli bir endişe “tasarımım gelecek yıl sunmamız gereken özellikleri destekleyecek mi?”. Çoğu Çevik strateji bu tür ileri görüşlere izin vermez ve bu nedenle proje başarısızlık noktaları yaratılır.

Bu noktada biraz ağrım var çünkü sadece kendim tarafından yakıldım. Bazı temel kütüphanelerimizi yeniden yazıyoruz. İlk aşamalar yapıldı ve sprint'leri için özellik hedeflerini karşıladı. Her şey çok çevik. Sonra, bazı dinamik yükleme özellikleri eklemek için gemiye getirildim. Ancak, yaklaşık altı hafta boyunca durdum çünkü daha önce yazılanların asla dinamik yükleme olmayacağını varsaydı, zaten orada olanları yeniden yazmak ve etrafta çalışmak için çok zaman harcadım. En kötüsü, dinamik yükleme başlangıçta spesifikasyonlardaydı; ilk çalışmanın gelecekteki tüm gereklilikleri akılda tutması ve çevik uygulamaların kötü olduğunu düşündüğü 'büyük tasarım çalışması önünü' yapmış olsaydı, birkaç gün içinde benim özelliğimi uygulayabilirdim.

Ders, atmak istediğiniz küçük şeyler için çevik kullanın. Bazen harika olabilir. Ancak, bu Tek Gerçek Yazılım Geliştirme Yolu değildir. Yüksek riskli veya uzun ömürlü olacak temel kod yazarken büyük tasarımı yapın.