Scrum ortamında hızdaki büyük artış gerçekçi midir?

Yöneticim son zamanlarda hızı hedef olarak ve verimliliğin ölçüsü olarak kullanmak için bastırıyor. Şu anda ortalama 50 hikaye hızında çalışıyoruz. Menajerim bunu% 40 arttırıp 70 hikaye puanı arttırmamızı istiyor (ekip üyelerinde artış yok). Bu artışı başaramazsak, nedenini açıklayan tam bir ara vermemizi istiyor.

Takım performansını hız ile ölçme ve bunu hedef olarak kullanma fikri bana yanlış geliyor, ama nedenini açıklamakta zorlanıyorum. Herhangi bir yardım? Bu neden verimliliği ölçmek ve teşvik etmek için doğru bir yol değil?

Hızı% 40 arttırmak son derece kolaydır - tüm tahminlerinize sadece% 40 daha fazla puan ekleyin ve aynı miktarda iş yapın.

Bunun böyle olduğu göz önüne alındığında, hızı hedef olarak yanlış kullanmak neden açıkça anlaşılmalıdır, sadece şişirilmiş tahminleri teşvik eder.

Daha az glib bir cevap, tahmininizin her şeyi doğru yaparken mümkün olduğu kadar hızlı gittiğinizi varsaydığıdır. Verimliliği% 40 oranında artırmanın tek yolu, fazla mesai yapmak veya her şeyi doğru yapmamaktır. Bunların her ikisi de kısa vadede işleri hızlandırmakta, ancak uzun vadede işleri yavaşlatmaktadır. Ve bu durumda uzun vadede dışarıda bir ay, çok uzun değil. Optimal uzun vadeli strateji asla sürdürülebilir hızınızdan daha hızlı ilerlememek.

Peopleware , programcıları daha yüksek üretkenliğe zorlama çabaları ile ilgili olarak konuşur ve sıkça bahsedilen bir klasiktir. Ancak genel olarak, sizin olduğunuz yolda ilerleyen bir yöneticinin fikrini değiştirmek kolay olmayacaktır. Projenizin başı belada olabilir - bu kesinlikle kırmızı bir bayrak.

Yorumlar belirtildiği gibi, istek açıkça belirtildiği gibi yanlıştır. Ancak, verimliliği sürekli olarak artırmak istemediği için yanlış değil. Kural olarak, yöneticilerin bunun için çaba gösterdiği (ve değerlendirildiği) budur.

Bununla birlikte yöneticiler her zaman performansı iyileştirmek istiyor ve Scrum ve Çevik tamamen uyarlanabilir olmakla ilgili. Hız mevcut sürdürülebilir hızınızın bir ölçüsü olsa da, defne üzerine oturmamanız gerekir. Scrum, sürecinizde neyin işe yarayıp yaramadığını değerlendirmek ve değiştirmek için bir yere sahiptir: geriye dönük. Bundan faydalanır ve sürecinizi ayarlarsanız, verimlilik (ve muhtemelen hız) yükselmelidir.

Öyleyse, bir ekip olarak daha üretken olma yollarını mı arıyorsunuz (retrospektiflerinizde)? Sprintlerinizde düzenli olarak orantısız bir çaba harcayan herhangi bir şey var mı? Ele alınabilir mi? Muhtemelen size% 40 artış sağlamaz, ancak% 5-10 bir başlangıçtır, değil mi? Her sprint darboğaz aramak ve onları ele almalısınız. Sonunda, sizin için koyduğu hedefe yaklaşabilirsiniz.

TL; DR

Hız, programları tahmin etmek veya planlama değerleri oluşturmak için çok kullanışlıdır ve aynı zamanda süreç darboğazlarını veya takım kapasitesindeki değişiklikleri değerlendirmek için anlamlı bir dedektif kontrol olabilir . Bununla birlikte, geçerli bir verimlilik ölçütü değildir.

Hız, Yönetim Hedefleriyle karıştırıldığında

"Hız", bir takımın tarihsel bir süre boyunca ortalama kapasitesini ifade eden bir aralıktır. Geçmiş performansın istatistiksel bir analizi olup, gelecekteki iş yükü kapasitesi veya döngü sürelerinin olasılık tahminlerini tahmin etmek için kullanılabilir. Bu, planlama amacıyla bir zaman çizelgesi veya hedef belirleyen bir yönetimsel amaç olan "zamanlama hedefi" nin tam tersidir.

Deneyimli çevik proje yöneticileri, hızın doğru kullanımının, bir ekibin yönetimle tanımlı planlama hedeflerine ulaşmak için sürdürülebilir kapasiteye sahip olup olmadığını belirlemek olduğunu bilmektedir. Bazen cevap evet ve herkes mutlu. Bazen cevap hayır, bu noktada demir üçgen iş, kapsam, maliyet, zaman ve kalite konusundaki kararları zorlar.

Politik Seçeneklerinizi Değerlendirin

Ortalama 50 hikaye puanımız var ... Benden% 40 arttırmam istendi (ekip üyelerinde artış olmadan).

Kestirim uygulamalarınızın sağlam olduğunu ve hızınızın makul bir şekilde sabit olduğunu varsayarak, yöneticiniz kestirim ölçeğini ayarlamaktan veya geçmiş performansa dayalı olmayan yönetim hedefleri belirlemekten zevk alamaz. Doğru bir şekilde işaret ettiğiniz gibi, bu temelde bir kapasite sorunudur.

Kapasite sınırı, ekibinizdeki kişi sayısıyla ilgili olabilir veya organizasyon süreçlerinizin bir kısıtlaması olabilir. Tabii ki, daha fazla insan eklemek her zaman gerçek proje kapasitesini de eklemez; bkz Brooks'un Kanunu bu Sanıldığının devamı için.

Sorun sen yüz siyasidir. Görevinizin tonundan, yöneticinizin ekibin temel kapasitesinde herhangi bir değişiklik yapmadan üretkenlikte bir artış görmek istediği anlaşılıyor. Bu nedenle çözümler aynı zamanda politiktir ve büyük ölçüde doğada eğitimdir.

Eğer bir Scrum mağazasıysanız, Scrum Master'ınızdan bu konuyu uygun çerçeve kanalları üzerinden ele almasını isteyin. Backlog Tımar ve Sprint Retrospektifleri genellikle bu konu için ideal inceleme ve uyarlama olanaklarıdır.

Eğer bir Scrum mağazası değilseniz, endişelerinizi gidermek için doğru yolun kuruluşunuzda ne olduğuna karar vermelisiniz. Yöneticinizle iyi durumdaysanız, öğlen yemeğinde görüşmeniz için Çevik Tahmin ve Planlama'nın bir kopyasını bile ödünç alabilirsiniz .

Eğer herkes başarısız olursa, özgeçmişinizi tazeleyerek ve proje tamamlanana kadar profesyonelinizi en iyi şekilde yaparak ölüm yürüyüşüne hazırlanın . BT projelerinin% 68'i başarısız ; Yönetim hedefleri örgütsel kapasitede sağlam bir şekilde desteklenmediği sürece, sizinki muhtemelen bunlardan biri olacaktır.

Müdürünüzün Scrum ekibinde rolü nedir anlamıyorum? Koç mu? Ürün sahibi mi?

Eğer takımın içinde bir koç veya benzeri bir durumda (gelişim görevinde çalışıyorsa), neden kendi verimliliğini düşürdüğünü sorabilirsiniz, çünkü diğer takım üyeleri için durum böyle değildi. Her yinelemede 30 hikaye puanı daha fazla alabildiğine inanıyorsa, göstermesine izin verin.

Daha muhtemel: o takımın dışında, belki ürün sahibi? Eğer öyleyse, böyle aptalca bir istek yapmayı anlaması gerekiyorsa, çevikliği durdurdu.

Temel bir kural, ekip bir yinelemede neler yapılabileceğini belirlerken ürün sahibinin hedefi belirlemektir. Bunu yapmamak, klasik ve iyi bilinen demir çembere yol açar: kaynaklar, hız, özellikler. İkisini seç! Aynı anda üçünü seçemezsiniz (ve unutmayın: kalite bir ayar değişkeni değildir, köşeleri düşük kaliteyle kesmeye çalışmak işleri daha da kötüleştirir).

Mevcut hedefi değiştirmek istemiyorsa, takım için daha fazla insanı işe alarak üretkenlikte% 40'lık bir artışa ulaşılabilir mi? Belki bazı ekip üyeleri için biraz önceden eğitime yatırım yapmak? Ekipler ayrıca sürekli iyileştirme ile zaman içinde hız kazanabilir, ancak kesinlikle keyfi kararla değil.

Bir takımın hızını değiştirmeye çalışmak bir odanın büyüklüğünü değiştirmeye çalışmak gibidir. Yapılabilir, ancak temelde odayı değiştirmeniz gerekir.

Bunu ona açıklayabilecek Scrum Usta ya da Scrum hakkında temel bilgileri olan başka insanlar yok mu?

Bu durumda menajer takımdan dürüst ve sadık bir tahminde bulunduktan sonra yanlış yöne döndü. Yöneticinin paydaşa yönelmesi ve gereksinimlerinin istenen zamanda tamamlanamayacağını bildirmesi gerekir. Yönetici / analist daha sonra hangi özelliklerin dahil edilmesini ve diğerlerinin bekleyebileceğini (sadece birkaç hafta olsa bile) önceliklendirmelidir. Eğer paydaş mantıksız ise, daha yüksek yöneticilerin katılımı gerektirebilir, bu da genellikle zorlayıcı olabilir ve diğer bütün tartışmalara ihtiyaç duyabilir.

Ben senin yerinde olsaydım proje neden olarak ayrıntılı bir durumda ile geleceğini IS sürece tahmin edilmiştir olarak alacak. Ayrıca düşük getirili öğeleri tanımlamaya çalışın. Çok fazla değer katmayan ve önemli programlama çalışmaları gerektiren öğeleri bulun ve bunları sprint'ten çıkarmak için bir durum açın. Ayrıca, "Y" tarihinde "X" sağlayan ve uygun olduğundan emin olduktan sonra yinelemeli bir yaklaşımla ortaya çıktıktan sonra kalan öğeleri alabilen bir takip yinelemesi ile gel.

Temel olarak, birisinin paydaşa son teslim tarihine kadar ne alabileceklerini ve ihtiyaçlarının çoğunu içerdiğini söylemesi gerekir. ve aşağıdaki sürümde geri kalan öğelere sahip olacaklardır. Müşteri bu kadar makul değilse, üst yönetimin katılması gerekir, yönetici bunu gerçekleştirebilmelidir.

Bununla birlikte, müşteri fazla söz verildiyse ve şimdiye kadar hiç kimse konuşmadıysa, bu bir yokuş yukarı savaş olacak. Bu maalesef nadir bir durum değil.

İki meseleyle yüzleşiyor gibisin.

Ölçme hızının sizi rahatsız eden kısmı muhtemelen ölçümün maliyet olmasıdır . Gerçekten geliştirmek istediğiniz şey değerdir . Ne yazık ki, yazılımın değerini ölçmek meşhur zor ve özneldir. Yine de, kusurlu ve öznel bir metrik bile yararlı olabilir. Asıl mesele, ekibinizin daha fazla kod yazması gerektiği değil, hikayelerin daha değerli olması gerektiği olabilir.

Diğer bir konu da, hesabınıza dayanarak yöneticinizin üretkenlikte% 40 artış beklemesidir. Sorunuzda bu isteğin içeriği belirtilmedi. Ekibinizin gelişmesini arzulayan arzularınız varsa iyi huylu olabilirler. Ya da yöneticinizin ekibinizin düşük performans gösterdiğine inandığına dair belirsiz bir gösterge olabilir.

düzenleme: Yorumunuza göre, durum kötü görünüyor. Şirketiniz sizi ve ekibinizi kovmak için temel atıyor gibi görünüyor (belki de menajeriniz). Başka bir iş aramanı öneririm.

Kov onu. Yani, başının üzerinden geçip ekibine olan tüm güvenini kaybettiğini ve iş için bir değeri olmadığını açıklamaktır. Bu yetersizlik seviyesine sahip yöneticilerin değiştirilmelerinin aşağıdaki takımdan daha kolay olduğunu açıklayın.

Böyle bir yöneticiye katlanmak için iyi bir neden yoktur, ancak bu, geliştiricilerin istifa etmesi gerektiği anlamına gelmez. İşle ilgili yanlış bir şeyler olması gerekmez, sadece bu şahısla. Bu sorunu düzelt.

Ve üst yönetimden susturmanın önüne geçmek için, bunun affedilebilir bir hata olmadığını açıkça belirtin. Bu mesul müdür sahip olduğunu işaret hayır o yönetiyor takımın anlayış. Bu, kendisini tamir etmeye borç vermez ve mevcut işgücü piyasasında buna ihtiyaç yoktur. Yöneticiler, tıpkı spor antrenörleri gibi kesinlikle değiştirilebilirler. Sahipleri takımları ateşlemez.

Şimdi, bu geri tepebilecek bir stratejiye benzeyebilir. Ancak şunları göz önünde bulundurun: üst yönetim ne olursa olsun yöneticinizle görüşüyorsa, zaten zaten kaybedilmiş bir durumda olursunuz. Öyleyse, sadece zaten o kaybetme konumunda olmadığınız durumları göz önünde bulundurursanız, sonuç muhtemelen daha olumlu olacaktır. Asıl risk, üst yönetimin, müdür de dahil olmak üzere bütün takımı kovmasıdır. Sadece bu riski tahmin edebilirsiniz. Anlaşılan çıktınız aranıyor, aksi halde daha fazlasını istemeyecekler, fakat hangi fiyattan?

Tecrübelerime göre, takımın, sorun alanının veya teknoloji yığınının değişmemesi durumunda, bir takımın gerçek hızını arttırmanın çok, çok zor olduğu yönünde .

Artışları başarabildiğimde, meselesi şu:

• teknik borcun temizlenmesi; Her şeyin doğru (en son değil! sürüm) çalıştırıldığından, kodun iyi bir şekilde yönlendirildiğinden ve sistemde artıklık bulunmadığından emin olun (kopyalanan kod, kullanılmayan kod vb.)

• iyileştirici uygulamalar; mümkün olduğunda eşleştirme (evet, hızı arttırdığını buldum), refaktöre agresif bir şekilde zaman ayırmak (aynen!) ve kapsam ve odaklanma konusunda acımasız olmak

• iş için en iyi araçları bulmak ve / veya satın almak (örneğin, ReSharper for .NET, altın, Airbrake ve Ruby gelişimi için Splunk gibi ağırlığına değer.)

Yöneticinizin, hızda keyfi bir artış istediğini belirten bir bayrak olduğunu söyleyen diğerleriyle aynı fikirdeyim. Öncelikli olarak başka bir iş arıyor olurdum.

Yöneticiniz ekibinize ekstra saatler çalışmasını söylüyor (veya söylüyor). Darboğazları ortadan kaldırmak ve verim kazanmak, hızınızı bir miktar artırabilirken, bu artışı elde etmenin tek yolu (% 40) daha uzun saatler çalışarak, o zaman diliminde daha fazla iş birimine girmeniz gerekebileceğindendir.

Bir senaryo alalım.

İki haftalık bir etkileşim için 10 gün söyleyelim. Ütopya günde 8 saat olacak ve hikaye noktası bir iş gününe çekilecek. Bu yüzden, en baştan, hızınız 8 olacaktır. Ancak, dinsel olarak insanlar muhtemelen e-posta, toplantılar, banyo molaları, vb. İle günde 6 saat içinde geliyorlar. Yani şimdi geliştirici başına 6'da. Demek ki temeliniz 6'dır. Diyelim ki, insanlar fazla mesai yapmak istiyorlar, şimdi günde 10 saat orada. Yani, bu geliştirici başına 10 hız noktası olacaktır.

Hızınız her zaman dalgalanacaktır, belki düşüktü, çünkü bu yineleme sırasında birçok hatayla uğraşmak zorunda kaldınız, belki gereksinimler eksik, belki birileri birkaç gün hastalandı. Belki de yüksekti, çünkü iş fazla büyütülmüş ya da ekibiniz fazladan saatler sürüyordu.

Fakat sabit bir 50'de, gerçekten 70'e ulaşmak için ekstra saatler gerekir.

Hızla ilgili sorun, geliştirme sürecinizin ölçülen bir çıktısı olan bağımlı bir değişken olmasıdır. Hızı% 40 artırmayı talep etmek, arabalara daha hızlı gitmelerini söyleyerek daha erken çalışmaya çalışmak gibidir. Motora daha fazla yakıt ve hava besleyerek ya da daha hızlı bir araba alarak, daha az trafikli bir rota bularak hız artar.

Daha fazla saat çalışmak, geliştirici saat başına özellik puanlarında, doğru bir şekilde ölçmeniz durumunda hızı artırmaz. Yalnızca günlük puanları ölçtüğünüzde ve ardından bir "günün" orta ölçümde ne olduğunu yeniden tanımladığınızda çalışır. Bu sadece hız illüzyonunu sağlar.

Hızdaki bir artış, dev sürecindeki bağımsız değişkenleri iyileştirmeyi gerektirir; daha hızlı bilgisayarlar ve derleyiciler, daha verimli yapı sistemi, daha iyi tasarım süreci, daha yetenekli geliştiriciler, daha iyi çalışma alanı, süper duper motivasyonu. % 40'lık bir iyileşme çok önemli değişiklikler gerektirecektir.

Yöneticinizden, ekibinizi ortak bir çalışma odasının etrafındaki kapalı ofislerde birlikte konumlandırmayı, ekibe yeni yeni donanım donanımı satın almayı veya ekibin mentorluğunu% 40 alabilmesi için birkaç üst düzey donanım satın almasını isteyip istemediğini sorun. Geliştirme sürecinize yönelik girdilerinizi iyileştirecek hiçbir kaynak yoksa, bu iyileştirme konusundaki içten ilgiyi hemen hemen dışlar. Bu, yöneticinizi, onu gerçekten neyin motive ettiğini, bir bütün 'nother işinin konusu olacak olanı bulmak için tersine mühendislikten çıkarır.

Diğer cevapların patronun isteğini ciddiye almasına biraz şaşırdım. Verimlilikte% 40 artış talep eden biri, yazılım geliştirme ile ilgili ilk şeyi bilmiyor.

Bu konuda Phil Factor'ı okumaktan hala zevk alıyorum :

BT yönetiminde iki temel yol vardır. İşlemlerinizi kan, ter ve gözyaşı ile öğrenebilir ve zor kazanılmış teknik bilgi birikiminden ve başarılı projelerden edindiğiniz güvenilirliğe dayalı olarak kademeli olarak merdivene çıkabilirsiniz. Alternatif olarak, keskin bir takım elbise giyebilir ve bağlayabilir, dil öğrenebilir ve tepeye kadar konuşabilirsiniz.

Her iki yol da eşit derecede etkili görünüyor. İkinci cinsle başa çıkmak kesinlikle bazı dehşet ve inançsızlık anlarına neden olabilir… hatta umutsuzluk… ve bazıları da bu hikayelerde belgelenmiştir.

Bununla birlikte, biri güç pozisyonlarında teknik yetersizlikle karşılaştığında üzülmek ve huzursuz olmak ve tüm yöneticileri aynı fırça ile katetmek kolaydır. Phil buna karşı önerir. Çoğu yönetici çok çalışmakta ve şirkete iyi katkıda bulunmaktadır ve yalnızca birkaç basit yönergeyi izlerseniz, kötü yöneticiler bile gerekli standartlara göre eğitilebilir. Yöneticinizin, herkesin yararına olacak şekilde çalışmasına yardımcı olmak, ekibinizin sorumluluğunun bir parçasıdır.

Sonuç olarak, eğer onları eğitemezseniz, terfi ettirirseniz veya onlardan kaçınırsanız, belki de işyerinin zengin komediine istenmeyen katkıları için onları sevmeyi öğrenebilirsiniz.

"Üzücü ve kederli" olmamanın tavsiye edebileceğin en iyisidir. Teknik meseleler konusunda teknik olarak beceriksiz bir patronla savaşmayın. Bunu sadece kişisel bir saldırı olarak görecek.

Yöneticiniz hız kullanımını yanlış anladı. Bu bir metrik değil ve bir hedef değil. Amacı, sprint başına ekip iş yükünün kalibrasyonudur.
Bunu düşünürseniz, hızınız her sprintten sonra yeniden ölçeceğiniz en iyi tahminden kaynaklanmaktadır. Genellikle zaman ilerledikçe biraz kararlı hale gelmesi gerekir. Ancak bu, ekibinizin gerçekte ne yaptığının bir yan ürünü olduğu gerçeğini değiştirmiyor: müşterileriniz için değer yaratmak.

Bunu bir hedef ve / veya metrik olarak kullanmanın yanlış olmasının nedeni, bunun bir makyaj ölçüsü haline gelmesidir. Kağıt üzerinde iyi dururdu, ancak ürünlerinizin müşterilerinizin ihtiyaçlarını tam olarak doldurup doldurmadığını yansıtmayacak hiçbir şey yapmazdı. Ve bu en önemli olanıdır (umarım).

Tecrübelerime gelince doğrudan konuya girme

Öncelikle, tahminde şişirme yapabilirsiniz ancak bu daha fazlasını yaptığınız anlamına gelmez.

İkincisi (öncül: şişirmeden, sadece takım hızına odaklanmak),

Takımınızın içindeki becerileri bulmaya çalışın. En iyi oldukları şey üzerinde mi çalışıyorlar? Uygulamanın ve karmaşık şeylerin inşası ile ilgili zor kararlar almak için bir sistem mimarına ihtiyacınız var mı? Takım çabalarını nasıl harcıyor? Sorunları için çözümler araştırmak, yeniden düzenlemek, iş kararları almak için zaman harcıyorlar ya da ne?

Konforlu, odaklı ve tahmini mi? Sırada ne var?

Bu "sınırlara zorlandım" değil ... ... bütün takım için bir soru gibi, "Sınırlarda mıyız?" ve "Sınırları nasıl zorlayabiliriz?" ...

Önde gelen yüksek performanslı ekiplerim var (ilk inşaat ve / veya göçler için) ... ekibin motivasyonu başarının anahtarıdır ... ve uygulamanın temelinin ne kadar önemli olacağını planlamak. Bazen ben veya bir ekip Systems Architect rolünü üstlenir ve "şeyin" nasıl ve nereye gideceğine karar veririm.

Bazen takım arkadaşlarımın verimlerinin kaybolduğunu gördüğümde, kırmaya ve onları bir bira içmeye ya da sevdikleri bir şeye çıkmaya davet ediyorum. Bu herhangi bir çatışmayı çözer ve ertesi gün tekrar odaklanırlar.

SATIŞ...

Hızı artıramadığınız nedenleri açıklamak zorsa, YG'yi kullanın.

Scrum, müşteri için neyin önemli olduğuna odaklanın. Teorik olarak en karlı işler.

Sorunlarınız geliştirme çabasını satmakla ilgiliyse, geliştirme çabalarının yatırım getirisinin ne kadarını sattığını düşünüyorsunuz, bunun yerine hikaye puanlarını doğrudan “fiyat” a dönüştürebilirsiniz. Ekibinizin yüksek bir YG ile çalıştığını ispatlayabilirseniz, sizi kim sorgulayacak? Ayrıca, takımın "eşleşme boyutu" nu bulması halinde her takımın bir sınırı vardır, her ay bir miktar artış yapmayı deneyin, eğer tüm görevleri tamamlayamazlarsa, bu sınırdır (muhtemelen).

Görevlerin tarihini, kar gelirini (varsa), kullandığınız hikaye noktasını gösterin ve VERİMLİLİĞİN TAKIM ÇALIŞMASI OLMADIĞINI gösterin ekip tarafından karmaşıklığı ve belki de bir şey alma zamanını değerlendirmek için belirlenen bir hesaplama olduğunu tamam