Scrum nasıl bir Gönüllü ortamına uyarlanabilir?

Son zamanlarda hala kendini kurma sürecinde olan genç bir hacker alanına katıldım. Şanslıyız çünkü mekânın üzerinde çalışılması gereken birkaç dahili projesi var ve üzerinde çalışacak gönüllü sıkıntısı yok.

Bu projelerin nasıl organize edileceği konusunda bazı tartışmalar olmuştur. En son profesyonel deneyimim Scrum ile oldu, bu yüzden yazılım projelerimiz için bir Scrum yaklaşımı oluşturmayı düşünüyorum, ancak bunun iyi bir uyum sağlayacağından emin değilim.

Scrum'ın tam zamanlı küçük ekipler için iyi çalışmasına rağmen, bu organizasyonun doğası farklı:

• Üyeler gönüllü . Bazıları tam zamanlı öğrencilerdir. Diğerleri tam zamanlı olarak çalışır. Gerçek hayatlarının önceliği olduğundan kimseden sürekli bir katkı beklemiyoruz.
• Hemen hemen herkesin yazılım yazma konusunda uzun yıllara dayanan tecrübesi olmasına rağmen, pek çok üye profesyonel olarak veya takım halinde yapmamıştır.
• Orada hiçbir Ürün Sahibi . Bu projelerin gereksinimleri bir komite tarafından belirlenir. Bu komitenin üyeleri de uygulama üzerinde çalışacaklardır. Bu, tek, özel bir Ürün Sahibimiz olmayacağı anlamına gelir.
• Biz bir süre vermediğini (yumuşak veya sert). Projeler bittiğinde yapılacaktır.

Bunlar oldukça önemli farklılıklar, ama Scrum'ı uygulamak için engelleyiciler olacaklarına inanmıyorum. Sanırım bazı küçük değişiklikler bizi bu engelden kurtarabilir:

• Sprint'leri sabit bir hikaye noktası boyutuna, ancak akışkan süresine (zaman) sahip olacak şekilde değiştirirsek, gönüllü geliştiriciler üzerinde gerçekçi olmayan teslimat baskısı yapmadan yine de yinelemeli yayınlardan yararlanabiliriz.
• Suya da olabilir çizelgeleri burndown ve hız hesaplama. Doğru anlarsam, bunlar dev ekibi ile Yönetim arasında bir köprü görevi gören araçlar ve metriklerdir. İlerlemeyi hem geliştiriciler hem de paydaşlar için anlamlı bir biçimde bildirmeye hizmet ederler. Rapor edecek kimsemiz olmadığı göz önüne alındığında (Proje Yöneticisi, Ürün Sahibi ve dış paydaş yok) Bunu tamamen bırakabileceğimize inanıyorum.

Faydalanabileceğimizi düşündüğüm şeylerin düzeltilmesi gerekmeyecek:

• Koşullar toplama Toplantısı (ler). Herkesin bir masanın etrafında oturduğu ve Kullanıcı Öyküleri'ni tartıştığı, UI alaylarını çizer ve bir Ürün İş Listesi oluşturur.
• Sprint Retrospektifleri . Bu, gönüllülerden oluşan bir ekip olarak bizim için çalışan bir geliştirme sürecine yaklaşmamız için ilginç bir yol olacaktır.

Emin olmadığım şeyler:

• Günlük Stand-Up'lara nasıl davranılmalıdır? Onlar bizim ortamda hiç çok değer olurdu merak ediyorum. Stand-up ritüeli hakkındaki anlayışım, ekip boyunca doğal olarak bilgi dağıtarak iletişime yardımcı olmasıdır. Sprintlerimizin muhtemelen ortalama bir Sprint'ten çok daha az karmaşıklık sağlayacağı düşünüldüğünde, diğer tüm ekip üyelerinin ilerlemelerinden / gelişmelerinden haberdar olmak için daha az ihtiyaç olabilir.
• Sürekli Entegrasyon, Kod İncelemeleri ve TDD gibi XP şeylerini zorlamalı mıyım ? Bunun çok şey isteyeceğinden endişeliyim. İnsanlar Scrum'a daha aşina olduklarında ve ekip olarak çalıştıklarında, bu kavramları gelecekteki projelere getirmeye daha cazip geleceğim.

Sorularım:

Scrum gönüllü tabanlı bir ortama uyarlanabilir mi?
Ve planladığım yaklaşım şimdiye kadar doğru yönde mi gidiyor?

Kanban'a bak. Kısıtlamalarınız için SCRUM'dan daha uygundur.

Düzenleme: SCRUM (çok kabaca) 'devam eden' iş hacminin kontrol altında kalmasını sağlamak ve her sprint sonunda sağlam bir şey olmasını sağlamak için sprintler ve törenler ile düzenli bir biriktirme listesi. Törenleri ve sprint kadansını terk ederseniz, Kanban ile sonuçlanırsınız: düzenli bir biriktirme ve 'devam eden' işi doğrudan sınırlamaya ve 'bitmiş' olarak işaretlenmiş her şeyin bitimine istikrar kazandırmak yerine yapıldığından emin olarak güçlü bir vurgu her sürat koşusu.

Hala çevik faydalar elde edersiniz: istediğiniz zaman, esneklik, bazı öngörülebilirlik ölçütleri bırakın - SCRUM sizi bu konuda biraz daha ileriye götürebilir - ve SCRUM'un törenleri veya hiçbir taahhüdü olmayan gevşek, dağıtılmış bir takıma uymayan yönleri olmadan . Yakalayış? Törenleri atmak daha fazla disiplin gerektirir, bu yüzden testlere, kod kalitesine, devam etmekte olan çalışmaya dikkat etmeli ve birikmiş işin üst kısmının (insanlar tarafından alınmaya hazır şeyler) yeterince ayrıntılı bir şekilde hazırlanmasını sağlamalısınız.

Gönüllü bir ortamda bazı insanlar istedikleri her şey üzerinde çalışsa da, oylamaya dayalı birikmiş işler olabilir.

(Ve evet, tüm TDD, CI, incelemeler ve akran programlama fikirleri iyi fikirlerdir).

Öncelikle not ettiğiniz farkları çözmek için:

• Üyelerinizin gönüllü olması, onlardan bir taahhüt isteyemeyeceğiniz anlamına gelmez. Özellikle Scrum'daki nispeten kısa bir sprint süresi ile her üyenin önümüzdeki birkaç hafta boyunca projeye ne kadar zaman ayırabileceklerini bilmesi mümkün olmalıdır. Takım üyelerinin her bir sprint için farklı bir süre kullanılabilir olması, planlamayı biraz daha zorlaştıracaktır, çünkü kaç hikaye noktasının gerçekçi olduğunu belirlemek daha zordur, ancak Scrum'ı olanaksız hale getirmez.
• Ürün sahibi, paydaşların ürünle ilgili vizyonunu (ve gereksinimlerini) sağlamlaştırmak ve geliştirme ekibine iletmekten sorumludur. Konsolidasyon bölümü büyük olasılıkla 'yönetim' komitesi tarafından kapsanmıştır. İletişim açısından, üyelerinden birini birincil sözcüsü olarak devredebilirler. Bu durumda, tüm pratik amaçlar için ürün sahibi olacaktır.
• Harici bir son teslim tarihine sahip olmamak Scrum için bir sorun oluşturmaz. Sadece bitirmek için ürünün ekibinin gururu daha fazla gelir. Scrum'ın her sprint için doğal bir son tarihi vardır.

Önerilen uyarlamalarınızla ilgili olarak, özellikle gönüllülerle çalışırken, sabit sprint uzunluğunu korumanızı şiddetle tavsiye ederim. Bu şekilde, gönüllüler taahhütlerini hangi dönem için verdiklerini kesinlikle bilirler.

Ayrıca derhal burkulma haritalarından vazgeçmem Ayrıca, takımın kendi taahhütleri üzerinde ne yaptığını görmesi için de yararlı olabilirler. Onları tutmaya ya da atmaya karar vermeyi takıma bırakardım. Aynı şey hız hesaplamaları için de geçerlidir. özellikle her sprintteki mevcut manholardaki büyük değişiklikle, gelecekteki sprintleri tahmin etmede çok yararlı olabilirler (özellikle manho başına tamamlanan puan sayısını hesaplarsanız).

Günlük standuplarla ilgili olarak, sadece herkesin neyle ilgili veya sorun yaşadığını (ve karmaşıklıktan bağımsızdır) bilmenizi sağlamak için, ayarlarınızda hala yararlı olacaktır. Ancak günlük bir standup gerçekleştirmek daha zor olabilir, bu yüzden orada taviz vermeniz gerekebilir.

Bahsettiğiniz XP uygulamaları, Scrum kullanımından bağımsız olarak tanıtılabilir veya tanıtılamaz ve ayrıca geriye dönük olarak önerilebilir.

Kimsenin işaret etmediği beni şaşırtıyor, ancak projeniz çoğu açık kaynaklı projeye benziyor. Bazı daha popüler açık kaynaklı projelere göz atarsanız, ilham alabilirsiniz. Bence SCRUM'u unutmalı ve bunu genel çevik bakış açısından düşünmelisiniz.

Agile tamamen iletişim ve işbirliği ile ilgilidir. Agile Manifesto'da 4 üzerinden 2 puanın bunun hakkında konuşmasının nedeni var.

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

Sözleşme görüşmesi üzerinden müşteri işbirliği

Projenizi tanımladığınız şekilde, proje üzerinde çalışan herkesle yüz yüze iletişim kurmak zor olurdu, Agile ve SCRUM'un her ikisi de teşvik eder. Bu yüzden odaklanacağım ilk şey, tüm ekip (hem gönüllüler hem de ürün komitesi) için iletişim kanalları oluşturmaktır. Wiki, forumlar, video konferanslar ve uygun biriktirme listesi, görev ve hata izleme sistemi gibi şeyler, herkesin neler olduğunu ve ne yapılması gerektiğini bilmesini sağlamanın harika yoludur.

Dikkat edeceğim ikinci şey, sadece çevikliğin teknolojik kısımlarını fırçalamak değil. Birçoğu (kendim dahil), şeylerin süreç tarafı değil, çevik işler yapanların olduğuna inanıyorlar. Kod incelemesi, projeyi bilen birinin yeterince yüksek kalitenin sağlanması için gözden geçirmesini / itmesini sağlayarak önemli ve en açık kaynaklı çalışmadır. TDD pratik olarak herhangi bir çevik proje için verilir. Koddaki herhangi bir değişikliğin önceki işlevselliği bozmamasını sağlar, bu da gönüllülerin diğer insanların hatalarını ve hatalarını düzeltmek için rahatsız edilememesi durumunda daha da önemlidir. Ayrıca, kod incelemeyi kolaylaştırır, çünkü gözden geçiren testlerde hangi işlevselliğin eklendiğini görebilir ve bunları çalıştırarak işlevin gerçekte amaçlandığı gibi çalışmasını sağlar. Sürekli entegrasyon TDD ile aynıdır.

Son olarak, projede tam zamanlı çalışan en az birkaç kişinin olması gerektiğine inanıyorum. Bu insanların belirli rolleri olmalı:

• Ürün sahibi : Buna adanmış bir komiteniz olması güzel olsa da, bu komitenin kelimelerini spesifikasyona veya kullanıcı hikayelerine yorumlamaktan ve bunların doğru bir şekilde uygulanmasını sağlamaktan sorumlu bir kişi olmalıdır.
• Koordinatör ve Scrum Master : Bu kişi tüm süreçten sorumlu olmalı ve herkesin projede meydana gelen önemli şeyleri bilmesini sağlamalıdır. Ayrıca, wiki ve görev ve hata izleme araçlarını korur. Birinin proje hakkında bir sorusu varsa, bu sorması gereken ilk kişidir.
• Ana geliştirici ve mimar : Kodu en iyi bilen kişi. Kod incelemelerini yapar ve kod kalitesinin çevik gelişim için yeterince iyi olmasını sağlar.

Tanımladığınız şekilde uyarlayamazsınız ve yine de SCRUM olarak adlandıramazsınız. ama bence, Scrum'ı tarif ettiğiniz kurulum için aşağıdaki gibi kullanabilirsiniz.

1. Sabit yineleme var. Böylece ilerlemenizi ölçebilirsiniz. Bu sadece yönetim için değil, aynı zamanda ekibin nasıl performans gösterdiğini “bilmesi” için de geçerlidir.
2. Gönüllülerden yinelemenin başlangıcında kapasiteleri paylaşmalarını isteyin. Tüm takımın hangi üyelerin taahhütte bulunduğuna ihtiyacı vardır, aksi takdirde belirli bir üye daha profesyonelce yapılan iş için takımdan ayrılabilir.
3. Son teslim tarihinin olmaması iyidir. Scrum, her bir yinelemenin sonunda yaptığınız şeyin potansiyel olarak gönderilebileceğini zorlamaz. Bu, o zamana kadar (çalışmakta olan) ne yaptığınıza bağlı olarak ne yapacağınıza karar vermenizi sağlayacaktır.
4. Hiçbir ürün sahibinin olması da işe yarayabilir.
5. Gereksinim toplama Scrum'ın bir parçası değildir. İstediğiniz şekilde yapabilirsiniz. Ancak bunu yineleme kapsamının bir parçası olarak dahil etmeyin. Bunun için ayrı bir kapasiteniz var. Bir yineleme için, sadece gereksinimlerin açık olduğu işi planlayın, örneğin ekip kabul kriterlerini bilir.
6. Retrospektif iyidir. Scrum'ı bu şekilde başlatın, ancak geriye dönük olarak neyin işe yarayıp yaramadığını görün, örneğin yineleme boyutunu değiştirmeniz gerekebilir, herkesi sürükleyen bazı gönüllülerden kurtulmanız gerekebilir ..
7. Günlük durum zorunludur. Bu, takımın birbirleriyle senkronizasyon yapma fırsatı verir, yani diğer üyelerin teslim edilememesi nedeniyle hiçbir görevin gereksiz yere engellenmemesi için çabalarını hizalarlar.
8. XP iyidir. XP'ye dayalı olarak kesin bir tanım yapın, örneğin incelenmedikçe hiçbir kod girmez. Daha fazlasını yapmak için daha az şey yapın ..

Farklı bir yaklaşım önerebilirim. Gönüllülerle uğraştığınız için dikkate almanız gereken birkaç şey var. Ekibiniz muhtemelen yüksek bir ciroya sahip olacak, hayat yoluna girecek ve insanların dikkati dağılacak. Kalanlardan birkaç tanesi tutarlı ama çok fazla katkıda bulunmayacak, son olarak dişlerini projeye batırmış olan hardcore gruba sahip olacaksınız. Burada iş gücünüz hakkında birçok varsayım yapıyorum ve değerlendirmemle birlikte çalıştığınız insanları yansıtmadığını düşünüyorsanız, bunun geri kalanını görmezden gelmekten çekinmeyin.

Şimdi çok fazla iş yapmayan insanların oldukça özerk bir şekilde çalışabilmelerini sağlayacak bir stratejiye ihtiyacınız var, sadece buna ayırmak için çok zamanları var ve bunların çoğunu harcamalarını istemiyorsunuz iletişimde. Daha fazla dahil olan insanlar, bazı daha karmaşık fikirlerin entegrasyonundan ve yıkanmasından sorumlu olmalıdır.

Bu beni tel çerçeveler ve prototipler üzerine odaklanmış bir geliştirme süreci hakkında düşünmeye itiyor.

Bir çalışma öğeleri havuzunuz olabilir ve insanları bunlar için tel çerçeveler yazmaya teşvik edebilirsiniz. Fikri geliştirmek ve insanların üzerine inşa etmek için ilham vermek için bunları Tracer Bullets (Pragmatik programcıdan ödünç alınan terminoloji) olarak kullanabilirsiniz. Oradan başarılı fikirleri prototiplere dönüştürebilirsiniz, yine bunlar insanların projeler hakkında daha fazla bilgi edinmesine yardımcı olmak için tasarlanmış çok küçük projelerdir. Bundan sonra, biraz daha aktif olan ekibin bazılarına dağıtabileceğiniz ve bu fikirleri sisteminize entegre etmek için çalışabilecekleri çok sayıda insan tarafından inşa edilmiş daha küçük bir katı fikir bölümünüz var.

Kanban'ın bu duruma daha uygun olacağını düşünüyorum.

Scrum'a uymayan birkaç şey var. Zamanlama veya kapsam ölçümleri gerekli değildir ve gelişmekte olan herkes toplantılardan aynı ürün vizyonuna sahiptir. Hesap verebilirlik ve tutarlı bir kısa plan takip etmek iş hedefleridir.

Kanban, dezavantajları olmadan Scrum ile aynı avantajları sunar. Size hızlı prototipleme yapabilir. Prototipler toplantılardan önce çalıştırılabilir. Aynı zamanda değiştirilebilir kod ve regresyon testleri için TDD sağlar. Çift programlama, bilgiyi aktararak yeni gelenleri ve düzenli olmayanları kod tabanına kolaylaştırabilir.

Kanban'ın kendine özgü avantajları da var. Kullanıcıların ne yaptığının vizyonu paralel olarak geliştiriliyorsa, Kanban iyi çalışır. Bunun kanıtı küçük işletme programları için başarıdır. Ayrıca, üç kişi gibi az sayıda gönüllünün olduğu günler için Kanban hala iyi çalışırdı. Scrum, hafif olmasına rağmen çok fazla sarı bant olurdu.