Sürekli olarak Scrum sprintleri yaparken tükenmişlik olabilir mi? [kapalı]

Oldukça küçük bir başlangıçtanım ve bir Scrum / Agile geliştirme döngüsü biçimi kullanmaya başladık.

Birçok yönden Scrum'dan zevk alıyorum. Nispeten kısa sprintlerimiz var (2 hafta) ve takımın ilerlemesini izlemek için Burn Down Chart'ı seviyorum. Ayrıca Feature Board'u seviyorum, bu yüzden her zaman ne yapmam gerektiğini biliyorum. Tahtadan bir özelliğin kartını çıkarmak, tamamlamak ve sonra yanmış yığına koymak iyi hissettiriyor.

Ancak, şimdi 18. Sprint sürüm döngümüze giriyoruz ve biraz tükenmiş hissetmeye başlıyorum. İşi veya iş arkadaşlarımı sevmediğimden değil, sadece bu sprintler ... eh, sprintler . Baştan sona geliştirme hızımızı korumak için zamana karşı yarışıyormuşum gibi hissediyorum. Sprint ile işimiz bittiğinde bir gün bir sonraki sprintin özellik setini ve tahminlerini planlamak için harcıyoruz ve sonra tekrar yola çıkıyoruz.

Olgun bir Çevik / Scrum geliştirme sürecinde çalışan insanlar için bu normal mi? Yoksa bir şey mi kaçırıyoruz? Normalde bir Scrum ortamında bazı küçük şeyler yapmak ve kafanızı boşaltmak için atanmamış / izlenmemiş zaman var mı?

Bu nispeten normaldir ve bazen projeler uzun bir süre devam ederse ekip üyelerimizin şikayeti olabilir.

Burada bahsettiğimiz şeyin anahtarı sürdürülebilir hızdır . Siz ve ekibiniz uzun vadede hızınızı koruyabiliyorsanız, bu mükemmel - tüm Scrum takımlarının çabaladığı hiper üretkenliğe ulaşmış olursunuz.

Alternatif olarak, bir günde gerçekten ne kadar iş yapabileceğinizi abarttığınızı fark ediyorsanız, geriye dönük olarak bunu yeniden değerlendirmeniz gerekebilir. Bir takımın bir sprint için kapasite planlamasını yaparken farkına varmayı seçtiği bir gün içindeki verimli zaman miktarı odak faktörü olarak adlandırılır .

Henrik Kniberg şunu söylüyor:

Yeni takımlar için kullandığım "varsayılan" odak faktörü genellikle% 70'tir, çünkü bu, diğer takımlarımızın çoğunun zaman içinde sona erdiği yerdir.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Bununla birlikte, konuştuğunuz gibi görünen şey, sadece bir gün içindeki üretkenliğiniz değil, sprintten sonraki kesintisiz sprint ivmesidir. İşte bununla başa çıkmaya çalıştığımız şeylerle ilgili bazı öneriler:

• Sprinti bir Cuma sabahı bitirin. Sprintinizi sabah gözden geçirin ve geriye dönük olarak değerlendirin ve ekibin günün geri kalanında kafalarını boşaltması için başka bir şey üzerinde çalışmasına izin verin. Pazartesi günü Sprint planlama ile başlayın.
• "Laboratuvar günleri" kavramını ortaya koyduk. Bunlar, ekibin projeden uzaklaştırıldığı ve günlerini birbirleriyle araştırma yaparak ve belirli teknik konularda işbirliği yaparak kendi teknik becerilerini geliştirmek için harcadıkları günler. Çoğu zaman belirli bir projeyle hiçbir ilgisi yoktur ve ekip üyelerinin daha hafif konular hakkında düşünmelerine izin verir.

Wikipedia'dan tükenmişlik üzerine: "Tükenmişlik, büyük ölçüde uzun saatler, kısa çalışmama süreleri ve sürekli akran, müşteri ve üstün gözetimden kaynaklanan örgütsel bir sorundur"

Tükenmişlik tanımının yanında Scrum'ın bir simge görüntüsüne de sahip olabilirler.

Tükenmişliği gidermek için birisini kısa bir saptırma için başka bir şeye gönderebileceğinizi düşünüyorsanız, açıkça düşünmemişsinizdir. Hiç tükendikten sonra tatile git ve düşünerek işe geri dön, Vay canına! Şimdi tazelendim ve sonunda tekrar ara verene kadar bu işkenceye 6 ay daha hazırım. Hayır, ne olduğunu anladın, Vay canına! İşim berbat. Şimdi aptal yöneticimin mikro yönetim, geliştirme sürecinin nasıl benden daha azına daha fazlasını elde etmenin başka bir yolu olduğunu ve hayat bunun için çok kısa olduğunu gerçekten görebiliyorum ... Yapacak başka bir şey bulmalıyım veya işleri daha az stresli bir şeye dönüştürmeliyim .

IMHO, kısa 2 hafta Scrum, art arda 4-8'den fazla olmamak üzere küçük dozlar dışında yasaklanmalıdır. Sürekli olarak değil, istisnai veya kritik şeyler için bir araç olarak kullanın. Sağduyu kullanın.

36 haftalık sıkı çalışmanın ardından yıpranıyorsun; bu Scrum değil, bu insan doğası! Scrum, daha çok çalışmanızı sağlamak için orada değildir, daha tutarlı ve daha yüksek öngörülebilirlikle çalışmanıza yardımcı olmak için vardır. İnsanların, çevik metodolojilerin semptomları olarak algıladıklarıyla normal proje yönetiminin semptomlarını karıştırdığını sık sık görüyorum (yani, "müşteri gereksinimleri değiştirmeye devam ediyor - bu Scrum'ın hatası olmalı!"). Yine de önemli bir ayrım çünkü nedeni belirlemeden semptomları tedavi edemezsiniz. Kişisel olarak, stres yönetimi teknikleri gibi tükenmişliği azaltmanın yollarını arıyor olurdum. Stresli bir ortamda nasıl başarılı olunacağına dair bir sürü bilgi var.

Şu anda üzerinde çalıştığım ekip bu sorunu gerçekten güzel bir şekilde çözüyor. Üç sprintten sonra, her geliştiricinin istediği şey üzerinde çalışabileceği bir haftamız var. Bu yan projeler iş değeriyle bağlantılı olmalıdır, ancak bunu yapmak için herhangi bir baskı yoktur. Bu, geliştiricilerin yeni teknolojileri keşfetmemize olanak tanıyan bir ölçüdür, ancak aynı zamanda bize bir hafta daha rahat ve eğlenceli bir çalışma sağlar.

Bu kesinlikle yanmamama yardımcı oluyor.

Hangi geliştirme sürecini kullanıyor olursanız olun, takım tükeniyorsa bir şeyler yanlıştır. Bu, insanların ihtiyaç duydukları tatile gitmemeleri kadar basit olabilir veya bu, dalgınlıklarınızı nasıl ele aldığınızın ayrıntılarında olabilir. Takımlar uzun vadede etkilidir çünkü herkes ihtiyaç duyduğu dinlenmeyi yol boyunca alır.

Bir Sprint, 100 yardlık bir atış değildir; maratondaki bir (rastgele) mil, yani sonsuza kadar sürdürebileceğiniz bir hız.

Ekibiniz her Sprint'in sonunda geriye dönük çalışmalar yapıyor mu? Bu, Takımın süreçlerini "inceleme ve uyarlama" fırsatı mıdır? Bir ScrumMaster olarak, Takımdan düzenli olarak Takımın bir varlık olarak Takımın nasıl 'hissettiğini' ve eğlendiklerini değerlendirmesini istiyorum. Nedenini veya neden olmadığını keşfediyor ve ayarlamalar ve alternatiflerle deney yapıyoruz.

Deneyimlerime göre, Takım üyeleri Sprint zaman kutusunun kısıtladığı 'baskının' tadını çıkarırlar (bir sınıra kadar). Anahtar, o bölgeye yaklaşmak ama onu aşmamaktır. Gerektiği gibi, bu bölgeyi kalibre etmek, geçmişe dönük olarak birincil kontrol noktasıdır.

"... bazı küçük şeyleri yapmak ve kafanızı boşaltmak için atanmamış / izlenmemiş bir Scrum ortamında zaman" konusuna gelince, Takım taahhüdünü mevcut kapasitenin% x'inde tutarak (tercihen puan, ancak saatler kullanılabilir Gerekirse; her iki durumda da% 60-70 aralığında bir şey buldum, norm gibi görünüyor) bir Sprint içinde sürdürülebilirliğin anahtarı ve ara sıra bir 'bedava kod günü' Sprintler dışında iyi çalışıyor.

Çözümlerden biri, sprint için harcanan gün içindeki saat sayısını azaltmaktır.

İş günleri sadece iki buçuk saatlik bir sprintten oluşan ve günün geri kalanı çeşitli diğer faaliyetlere odaklanan bazı insanlar tanıyorum: destek, teknik borcu hafifletme, araştırma, vb. Geliştirme hızları buna göre ayarlandı.

Bu biraz aşırı görünebilir, ancak yanılmıyorsam, yakın zamandaki yaygın ekonomik şok vurana kadar karlı bir şirketti.

18. sprint'inizdesiniz !?

Sprint başına 2 hafta olarak düşünülürse, bu aynı proje üzerinde 36 hafta kesintisiz çalışmak anlamına gelir. Ayrıca her gün yaklaşık 6 saat çalıştığını da söylüyorsunuz. Kulağa çok benziyor!

Çevik metodolojiler hakkında pek bir şey bilmiyorum (şimdiki projemizde aslında Scrum kullanıyor olsak da), ancak çalışma saatlerinizle ilgili bir prensip var (yani, bir görevi yaparken harcadığınız zaman miktarı)% 60 olmalıdır. ~% 70. Şimdi, tekrar rakamlar yapmak, eğer iş gününüz 8 saat uzunluğundaysa ve 6 saat çalışıyorsanız, gerçekten emek zamanınızın yaklaşık% 75'ini harcıyorsunuz demektir. Bu, sonunda bu duyguyu yaşamanıza neden olan küçük bir sapma olabilir.

OTOH, projenizin yapılması uzun zaman alacaksa sprintlerin 2 hafta değil bir ay daha büyük olması gerektiğine inanıyorum. Tükenmişlik çizelgenizde aşağı doğru bir eğri düşünün: Sprintinize düzenli bir görev yakma ile başlayın ve sprint sona ermeden önceki son 2 veya 3 gündeki aktivitenizi azaltın.

Çevik, "daha hızlı / daha güçlü / daha iyi / daha çok çalışın" gravürü olan bir taş değildir, daha çok beyaz bulutları olan mavi bir gökyüzü gibidir: "güzel çalış, güzel daha üretken". (daft punk + radiohead'in izniyle sonunda biraz lol).

Ne dediğini tamamen anlıyorum. "Hızınız çok hızlı" diyenler için, insanlar bu süreçten yorulduğunda hızın her zaman sorun olduğuna katılmıyorum. Tüm ilerlemenizi takip etmek iyi bir şey olsa da, kendisi de bir stres faktörü olabilir (ve takip edememek de olabilir), sadece patronunuz / PM'niz bir şeyin gitmediğini görürlerse yanınızda olacağı için değil. plana göre, ama kendiniz için. Sadece bu kayıtlı bilgiye sahip olmak, çoğu insanın normalde HER ZAMAN yapacağınızdan biraz daha fazla çalışmasını SAĞLAYACAK bir şeydir ve zaman tahminlerinize daha fazla zaman ayırmanın bunu herkes için düzelteceğinden emin değilim. Bir motive edicinin (yakma çizelgeniz gibi) her zaman olumlu olduğunu düşünmüyorum.

Bazı insanlar böyle hissetmeyecek, bazıları hissedecek. Herkese uyacak TEK bir çalışma şekli yoktur. Bence asla olmayacak.

Ayrıca, bu çevik yöntemlerin ve sprintlerin daha etkili / üretken hale gelmediğini söylerseniz, neden hiç kullanıyorsunuz? Şirketlerin neden bu yöntemleri kullanmak istediğini düşünüyorsunuz? Eğlenceli oldukları için değil ....

Bana göre, etkililik / üretkenlik her zaman bir tür bedelle gelir. Hiçbir yerden sadece sihirli yöntemleri kullanarak ortaya çıkmaz (benim fikrimi anlarsanız).

Daha etkili olmanın (iş ve baskı açısından) ve daha az iş yapmanın tek yolu işi başkasına yaptırmak veya işi otomatikleştirmektir.

Bana göre, bir kişi her zaman süreçleri gözden geçirmeli ve neyin otomatikleştirilebileceğini görmeli ve bunun yerine süreçlerinizi otomatikleştirmek için zaman harcamalı. Otomasyon, "gerçek işi" yapmak yerine fazladan iş yapma pahasına gelir, ancak otomatikleştirilmiş görev ne kadar küçük olursa olsun, uzun vadede her zaman kâr elde edersiniz. HER ZAMAN! Bir gün değilse, ikide. Bir ay değil, iki. İki yılda bir değil. Kaptın bu işi.

Bununla birlikte, kişisel projeler üzerinde çalışmak için izin alma fikrini seviyorum. Çoğu şirket buna asla izin vermez. Ama belki de işvereninizi süreçlerinizi otomatikleştirmek için bu zamanı almaya ikna edebilirsiniz ve bu çalışma, bahsettiğiniz zamanı "dinlenmek" ve yeni bir sprint için enerjiyi geri almak için "sürat kontrolünün dışında" olabilir.

Bunlar sadece benim 2 sentimdi. İnsanlar bu yöntemlerin bizi daha etkili hale getirmek ve daha çok çalışmak için burada olmadığını söyleyince biraz korkuyorum. Tabii ki öyleler! Ne yaptığınıza dair hiçbir iziniz olmadığında, vücudunuz size söylediğinde dinleneceksiniz. Yaptığınız "her şey" takip edildiğinde, kendinizi zorlayacaksınız. Ya da kendimi düzeltirim, çoğu insan bu şekilde çalışır, bazıları yine de dinlenir.

Sürdürülebilir hız, çevikliğin temel ilkelerinden biridir. Yönetim (SCRUM) uygulamalarını mühendislik (XP) uygulamalarıyla birlikte yaparken, bir takım süresiz olarak sprint sonrası sprint teslim edebilir. Ancak, çünkü biri yapmalı anlamına gelmez.

Önünüzde gördüğünüz sonsuz sprint dizisine karşı bir değişikliğe ihtiyacınız var gibi görünüyor. Bir dizi seçenek sunulabilir. Her X sayıda sprint, bir takım üyesi (veya çifti) bir takımın dışına dönebilir. Rotasyonunuz sırasında, koşu takımını destekleyebilir, ders alabilir, bir dizi zirveye odaklanabilir, tatile gidebilirsiniz vs.

Takımın 5 çifti varsa ve bir kişiyi hat dışına döndürürseniz, Bir kişi her 10. sprintte (tek bir kişi ise) veya her 5. yinelemede (çift ise) bir rotasyon dışı bırakabilir. Faaliyetleriniz için bütçe ve yatırım getirisi konularının liderliğiniz veya iş ortağınız tarafından ele alınması gerekecektir. Ama açıkça, "testereyi keskinleştirmek" için biraz zamana sahip olmak takıma ve dolayısıyla projeye fayda sağlayacaktır. Ekibi taze ve odaklanmış tutmak çok iyi bir şey. Ancak şunu unutmamalıyız, para alıyoruz ve kazandığımız dolara değer katmamız gerekiyor.

Sanırım bir şeyi kaçırıyorsun, ama tek değilsin. Jim Highsmith'in dediği gibi: "Hız, iletilen hikaye noktalarının hacmine çok fazla odaklanan bir verimlilik ölçüsü olarak giderek daha fazla kullanılıyor (olması amaçlanan kapasite kalibrasyon ölçüsü değil)."

Sanırım ekibinize olan budur. Bu Highsmith'in IMHO seminal gönderisini okumanızı tavsiye ederim: Velocity is Killing Agility!