Neden ve hangi sebeplerle geliştiriciler “günlük hata” dan hoşlanmayabilir? [kapalı]

Gibi günlük scrum tutmak avantajları vardır:

1. Takım birbiriyle koordine olsun
2. Herkes ne kadar iş yapıldığını biliyor
3. Burndown grafiği gittikçe daha fazla tamamlanıyor
4. Görev panosu güncellendi
5. O kadar uzun sürmez, 15 dakika kimseyi öldürmez

Ancak, son zamanlarda (6 ay boyunca scrum kullanıp kullandıktan sonra), geliştiricilerimizin artık her gün scrumdan hoşlanmadığını hissediyorum. İnsanlar görev panosunu sadece yeterince açıklama yapmadan yeniliyorlar ve ondan sıkılıyor gibiler. Görüyorum ki, herhangi bir nedenden ötürü, tutmadığımız zaman, fazlasıyla mutlu oluyorlar.

Sadece bunun ne yanlış olabileceğini bilmiyorum. Herhangi bir yerde, “günlük işkence” nin bir takım için sahip olabileceği dezavantajlardan herhangi bir sebep var mı? Geliştiricilerin günlük hatalardan yorulmasının sebepleri neler olabilir?

Birkaç işveren ile bir "SCRUM" ekibine katılma konusunda deneyimim oldu. Bana göre yöneticiler, SCRUM'un ana noktası olarak "günlük iş bulma toplantısı" nı gerçekleştirdiler ve hedef olarak belirlediler; bunun yerine ne olduğu için: daha etkili bir gelişim döngüsü elde etmek için bir araç .

Çok kısa bir sürede 15 dakikalık toplantılar 45 dakikalık toplantılar oldu, güncellemeler etkisizdi çünkü insanlar esneme ve başkalarını dinlemek yerine "ne zaman gidebiliriz" diye düşünmekle meşgul olacak ve insanların rutinlerini bozacaktı (örneğin, ben ... bir baykuş ve her gün bu aptal toplantı için sabah 9'da çalışmaya başlamam işimden ayrılmam için yeterince iyi bir nedendir).

Yöneticiler doğru uygulanırsa iyi olabilecek bir fikir edindiğinde ve bunu en uç noktaya getirdiğinde - bekledikleri sonuçların tam tersi olur. Ben şahsen ben yapıyorum az iş - başka toplantı ı katılmak düşünüyorum. Takvimimde haftada 2 düzenli toplantı var ve genellikle bunlardan birini atlıyorum. Toplantılar yöneticiler içindir, geliştiricileri işlerini yapmak için bırakın.

Eminim "Ama çok güzel" diyecek bir sürü SCRUM meraklısı olacak - peki, sakla, hepsini duydum.

Günlük ayağa kalkar sıkıcı ve yararsız bulurdum; Günlük standup'un faydasını azaltabilecek birkaç şey var.

• Paylaşılan bilgiler hiçbir zaman beni hiçbir zaman tutmaz veya etkilemez.
• Ekip sahipliğinin olmaması ve herkes daima kendi projeleri üzerinde çalışıyor.
• Stand-out dışında takım iletişiminin olmaması.
• Görülebilir veya iletilmiş ilerleme eksikliği.
• Paylaşılacak bilgilerin olmaması.

Bunlar sadece kafamın üstünde, ama her zaman daha olası sebepler var.

Belki de geliştiricilere niçin ilgilenmiyor gibi görünmediklerini sormalısınız? Daha fazla / daha iyi iletişim istiyorsanız, sizinle başlamalıdır.

Günlük SCRUM toplantılarında karşılaşılan sorunlardan bazıları:

• çok uzun süren olanlar. Her gün yöneticilerden birini istemiyorsun çünkü bu tür sorunların sebebi onlar. Genelde sandalyeyi kullananların nasıl olacağını görün (evet, bunun için ayağa kalkmak zorunda olmak, insanları hızlı olmaya ikna etmek demektir)
• daha sonra başkaları ile tartışmak üzere başka bir gerçek toplantı planlamaya karar vermek yerine, uzun süreli problemini tanımlayan birini (veya 2 veya 3 dev) duymak zorunda kalmak
• Aptal saatler. Bu toplantıların sabah olması gerekmez: dün yaptığınız şeyden bahsetmiyorsunuz ve bugün ne yapacağınıza karar vermiyorsunuz; Son gün ile bunun arasında ne yaptığın hakkında konuşuyorsun ve bir sonrakine kadar ne yapacağına karar veriyor.
• devs için uygulamanın mülkiyet eksikliği. SCRUM, devs kod maymunu olarak değerlendirilmezse işe yarar. Sürecin yanlış gittiğinin ilk işareti, devlerin bir şeyin ne kadar zaman alacağını değerlendirenlerin olmadığı zamandır.
• Yine aptal saatler. Takımın bir kısmı bazı şeyler üzerinde çalışmaya başladıysa ve günlük gerçekleştiğinde “bölgede” ise, can sıkıcı hale gelir. Günlük olanlar için iyi bir zaman, hiç kimsenin çalışmaması gerektiği zamandır (örneğin, öğle yemeğinden sonra veya öğle yemeğinde bazı tartışmalara başlamadan hemen önce).

Zamanlama birçok insanın katilidir. Programcılar geç kodlamayı, geç uyumayı ve sabah koşusundan sonra gelmeyi severler. Sabit bir zamanda ofiste olmak zorunda - onlar için çok erken. Ve daha erken gelip daha şimdiden çalışmaya başlayanlar için çok geç.

Akış başka bir konudur. Bazı özelliklere sahip olan bir programcı gece geç saatlere kadar çalışacak, eve dönecek ve tekrar şarj olmuş ve devam etmeye hazır olacak. En çok ilgisiz konuların olduğu bir toplantıya katılmak zorunda kalmak onu rahatsız edebilir.

Benim gözlemim çok sık, bu toplantılar yöneticilerin ekip ve proje için yararlı olmaktan ziyade bir şey yapıyormuş gibi görünüp kendilerini hissetmelerini sağlıyor.

Örneğin, farklı projelerde bir dizi kısa hata düzeltmesi yapmak için bir ekip görevlendirilir. Gerçekten takım olarak değil, birey olarak çalışıyorlar. Ancak, şirket / departman politikası bunu zorunlu kıldığından, takım lideri / yöneticisi yine de günlük bir toplantı düzenler. Bütün bunlar, işe yaramaz bir toplantı için 15+ dakika sürüyor ve toplantıdan önce ve sonra 15-30 dakikalık dikkat dağıtıcı ve verimsizliğin üstesinden geliyor.

Şimdi, sıkı tarihlere sahip ve çeşitli parçalar üzerinde çalışan insanlar arasında çok fazla koordinasyon gerektiren bir projede iyi iş çıkardığını gördüm. Bu bağlamda harika bir sistemdi. Ancak, “Bir toplantı yapıyoruz çünkü biz bir dolandırıcılık / çevik mağazayız ve yapmamız gereken şey bu” bağlamında gerçekten emilebilir.

Kimsenin toplantıya tekel getirmediğinden emin olun.

Geliştiricilerin 4'ü spiellerini 5 dakika içinde ortadan kaldırırsa ve sonraki 10 dakika , çoğu ne muhteşem, ne de harika olmayan, yaptıkları şaşırtıcı , harika yeni gelişmeleri detaylandıran ekip liderini dinleyerek geçirilir. Onların düşündükleri gibi, insanlar çok çabuk sıkılacaklar.

Biraz bekleyin ve ekibinizi düşünün:

• Etkili çalışıyorlar mı?
• Görevler zamanında tamamlandı mı?
• Kod sağlam ve iyi yazılmış mı?
• Takım çatlaklardan hiçbir şeyin düşmemesini sağlıyor mu?
• Ekip, işlerini kopyalamamaları veya birbirlerinin ayak parmaklarına basmamaları için kendini koordine ediyor mu?

Bunların hepsine cevabınız "Evet" ise, belki de günlük toplantılar, yazma çizelgeleri ve görev kurulları gibi yoğun işleri neden zorlamak istediğinizi düşünmelisiniz. Hangi değeri ekler? Bürokratik verileri yalnızca kendi keyfinize göre mi oluşturmak istiyorsunuz yoksa ekibi daha üretken kılmaya mı çalışıyorsunuz?

Günlük israflar durduğundan beri verimde bir düşüş var mı, yoksa her şey eskisi gibi mi geçiyor? Hiçbir şey değişmediyse, toplantılara neden devam edilsin?

15 dakika. Bu 15 dakika (artı hazırlık zamanı) ekip üyeleri arasında gelecek gün takımların üretkenliğini 15 dakikadan fazla arttırmak için yeterince yeni ve faydalı bilgi veriyor mu? Her gün bu kadar yararlı scrum içeriği yoksa, ekip üyeleri, bu en kısa sürede bu toplantıdan çıkıp işe geri dönmeleri halinde hedeflere doğru daha fazla ilerleme kaydettiklerini düşünüyorlar.

Tahtayı ve grafiği sık sık güncellemek istiyorsanız, taslak kopyaları bir wiki'ye koyun.

"Neyin iyi gittiğini" ve "Neyin iyi gitmediğini" görmek için Retrospektif toplantısını yapıp yapmadığınızı ve geliştiricilerin günlük Stand-up toplantısının kendisini zaman kaybı olarak listeleyip listelemediğini öneriyorum. O zaman onu biraz tekrar organize etmen gerekir.

Kişisel deneyimim:

• Amaç bugün ne yaptığımızı ve dün nerede olduğumuzu bilmek. Gündeme bağlı kalmak yerine, 2 kişi ile diğer 15 kişi arasındaki engelleyici teknik tartışmalara giriyor. Sorunu tanımla ama dışarıda tartış
• İnsanlar toplantı odasına zamanında giremiyorlar ve bu bazı bilerek yapılan bir döngü haline geliyor. Bu yüzden, Scrum Master'ın, toplantıya başlamaları ve zamanında bitmelerini sağlamak için onlarla sessiz bir tartışma yapması gerekiyor.
• Günlük çizelgenin asıl amacı bu değil, Scrum toplantısı dışındaki güncelleme tablolarını zaten güncelledik.

Direnç şu durumlarda gelir: 1) İnsanları sabah 9'da acele etmeye zorlamak için kullanılırlar. Tren geciktiğinde fazladan stres olur. 2) Zayıf scrum liderliği. Lider, insanlara kendilerini etkilemeyecek bir şeyi dinlemeye devam etmekten ziyade, insanların bir şeyleri kapalı hale getirmelerini söylüyor olmalı. 3) Değersiz içerik. Bu yine bir scrum liderlik konusudur. Darboğazları, yörünge sorunlarını ve potansiyel işbirliklerini ele almak için bir forum olması gerekiyordu. Gerçekte olan şey şu ki, herkes o gün çalışmayı umduğunu söylüyor, kimsenin yararı veya yararı olmayan. 4) Ayakta. Ayakta durmayacağım. Durmanın ardındaki mantık insanları kısa olmaya teşvik etmesiydi. İnsanlar aslında ne olursa olsun, sadece çıngıraklı.

Birçok kez başarabildim ve takımlarımın bir parçası oldum. Geliştiricilerin aldatmacadan hoşlanmamalarının ana nedeni:

• Çok zayıf bir scrum ustası tarafından çalıştırıldıkları için, 45 dakikaya dönerse, scrum ustanızın scrum'u kontrol etmede iyileştirmesi gerekir.
• En büyüğü ve bugüne kadar Hoşlanmamalarının en dürüst nedeni, kötü bir iş ahlakında saklanmanın çok zor olması, yani daha açık bir şekilde tembel insanları ortaya çıkarmasıdır. Çalıştığım bazı devler şok edici, 30 dakikalık bir iş yapması gereken işleri yaparak günlerini alıyorlar. İyi bir PM, devs için engelleri kaldırmalı, bu da bir sprint içinde görevlerini sürdürebilmeleri gerektiği anlamına geliyor. Devs bundan hoşlanmadı çünkü her gün ayağa kalkmaları ve kaydettiği ilerlemeleri göstermeleri gerekiyor. Ne sebeple olursa olsun ilerleme gösteremediklerinde endişe yaratır. Geçerli bir sorun yüzünden, iyi bir scrum ustası bu sorunu en kısa sürede çözmelidir.

Sorun, scrum ustalarının engelleme sorunlarını çözme yetkisine, becerisine veya kabiliyetine sahip olmaması durumunda ortaya çıkar. Aslında, onların gideceklerini umarak bazı gömülü sorunları gördüm. Bu felakettir.

Açıkçası, gittim günlük scrum toplantılarının% 99'unda, hemen hemen tüm tartışma / soru / cevaplar birkaç e-posta ile çözülebilirdi.

Gerçekten toplantı yapmamak için daha geçerli nedenler göstermemiz gerektiğini düşünüyorum. Herkesi şahsen bir odaya sokmanın zamanı geldiğinde, zamanın verimliliğini en üst düzeye çıkarmak için daha iyi bir neden olduğu ve organize olduğu ortamlar oluşturun.

Genel olarak toplantılardan nefret ediyorum ve verimlilik topluluğumun kalkmasına ve kesintiye uğramasına gerek kalmadan video konferansı, telefonları, e-postaları, işime girmemi veya işime devam etmemi sağlayan her şeyi kullanmayı tercih ediyorum.

Şahsen bence 8 saatlik bir süre içinde dörtten fazla toplantınız varsa, projeler iyi yönetilemez.

Toplantılardaki gerilime katkıda bulunan birçok faktör vardır. Bunları, toplantıların size değer olduklarından daha fazla maliyetli olmasının nedenlerinden bazıları olarak düşünün:

• Focus - toplantılara karşı yazılım
• Yönetim - yöneticilerin ölçüme ihtiyacı var
• Kişilik - Introverts vs Extroverts
• Zaman - kesintiler, Maker ve Manager zamanı
• Hedefler, Öncelikler

Bu faktörlerin her biri aşağıda açıklanmaktadır.

Odaklanma - Yazılım geliştirmekten hoşlanıyorum ve buna zorlukları (problemleri) düşünmeyi, çözümler oluşturmayı, yazılımı oluşturmayı ve toplantıları dahil etmeyi, yazılımı oluşturan görevlere odaklanmaktan dağıtabilirim. Bir geliştiricinin mücadeleye daldığı (problem), çözümün zihinsel bir modelini oluşturduğu ve çözümü oluşturmaya tamamen odaklandığı" Akış "adı verilen bir durum var. Bir geliştirici gece yarısına kadar çalışabilir, sadece yemek ve uyumak için ayrılabilir, ardından bıraktıkları yere yakın bir duruma geri dönebilir.

Geliştiricilerin dikkat dağıtmalarından kaçınmaları gerekir ve birçoğu gece geç saatlere kadar kodlamanın avantajları olduğunu fark eder (gürültüden, telefon görüşmelerinden, yoğun ofisten ve işlerini kesen geliştirici olmayan iş arkadaşlarından kaçınırlar). Ve 10, 11 veya 12: 00'a kadar çalıştığınızda, daha sonra işe gelmeniz mantıklı değildir (10, 11, öğlen?). Geliştiricilerin sabah 9'dan gece yarısına kadar çalışmasını beklemek mantıklı mıdır?

Scrum (ve herhangi bir) toplantıları, geliştiriciyi temel amaçlarından uzaklaştırır; bu da yazılım oluşturmadır.

Yönetim - Yöneticilerin başarılı olmak için ölçmeleri gerekir, dolayısıyla ilerlemeyi ölçmek ve raporlamak ve bağımlılıkları, gecikmeleri ve risk alanlarını ortaya çıkarmak için programlara, ürünlere, zaman çizelgelerine, önceliklere ve toplantılara duyulan gereksinime ihtiyaç duyulur. Bir Scrum ile zorluk, bir yöneticinin bu şeylere ihtiyaç duymasıdır, ancak geliştiricinin odaklanmaya ihtiyacı vardır. Toplantılar yöneticiye hizmet eder ve yöneticinin durumu ve gelişmeleri alması, ölçmesi ve izlemesi için bir yol sağlar, ancak toplantılar nadiren geliştiricilere yardımcı olur. Yöneticilerin dikkat dağıtıcı şeyleri ele aldıklarında, engelleri kaldırdıklarında ve geliştiricilerin bina yazılımı üzerine odaklanmalarını sağladıklarında daha fazla değer sağladığını düşünün.

Toplantı ihtiyacına yönelik çözümler var. Bir yönetici geliştiricilerini ziyaret edebilir, durum raporları isteyebilir, kesintilerin daha az müdahaleci olduğu durumlarda bir protokol benimseyebilir veya geliştiricinin kesildiğinde geliştiricinin kendilerine ilerlemelerini bildirmesi için bir politika benimseyebilir. Bunun neden önemli olduğu için zaman tartışmasına bakın.

Kişilik - Bazı insanların içe dönük, bazıları ise dışa dönük olduklarını düşünün. Dışa dönükler sosyal etkileşimlerden hoşlanır ve onlar tarafından yeniden şarj edilir. Yöneticiler genellikle dışa dönüktürler (dışa dönüklükler genellikle sosyal etkileşimlerle daha iyi olduğu için), ancak içe dönükler yönetici olarak başarılı olabilir. Katılımcılar sosyal etkileşimlerden zevk alabilir ve hatta mükemmelleşebilirler, ancak yalnızlıklar tarafından yeniden doldurulurlar. Geliştiriciler genellikle içe dönüktürler ve tek başlarına (veya küçük takımlarda) çalışmaktan başarılıdırlar çünkü sosyal etkileşimlere "ihtiyaç duymazlar"; problemler üzerinde tek başlarına çalışmaktan mutlu olabilirler (dışa dönüklükler de geliştiriciler olabilir). Günlük aldatmaca toplantıları sosyal toplantılar haline gelebilir, dışa dönüklere iyi gelir, fakat içe dönük olanlar için çok iyi olmaz.

Zaman - Geliştiriciler toplantılarda kod yazamazlar. Toplantılar tarafından dikkatleri dağılmışken (beyin fırtınası olmadıkça) zor problemleri de düşünemezler. Geliştiricilerin, bina yazılımına odaklanmak için büyük ve kesintisiz zaman bloklarına ihtiyacı vardır. Toplantılar çabalarından uzak durulan kesintilerdir. Saatlerce bir problemi çözdüğünüz zaman, neredeyse bitirdiniz ve birileri "kırılma zamanı" diyor, kesiliyorsunuz ve "vites değiştirirken" belki de çalışma saatlerini kaybediyorsunuz. Ya da saat 11: 00'e kadar işte kalmış, iş bırakmış, eve seyahat etmiş, problemin üzerinde uyuya kalmış, uyanmış, sorunu çözmek için çalışmaya geri döndüm ve sonra bir problem üzerinde çalıştıktan bir saat sonra kesildi. "Scrum zamanı" dır.

Paul Graham , Maker Time ve Manager Time hakkında bu konuyu benden çok daha iyi açıklayan mükemmel bir makaleye sahip. Planlanan veya planlanmayan bir toplantı kesintisinin, akışı bozabileceğini ve bir geliştiriciyi Maker saatinden Yönetici saatine zorlayabileceğini söylemek yeterlidir. İnan bana, Maker'ın zamanında geliştiricileri istiyorsun.

Hedefler, Öncelikler - Geliştiricilerin ve yöneticilerin farklı hedefleri ve öncelikleri vardır. Yöneticiler, programları takip etme, maliyetleri en aza indirme, raporlarının sorumlu olmalarını ve performans göstermelerini sağlama hakkına sahiptir. Geliştiriciler, zorluklara / sorunlara yönelik yazılımı geliştirme hedefine sahiptir. Bu hedefler çatışma içinde değildir, ancak gerginliği yaratan iletişim mekanizmasıdır. Toplantılar yöneticinin ihtiyaçlarına hizmet eder ve yöneticilerin zamanını optimize eder, ancak geliştiricinin ihtiyaçları ile çelişir. Scrum toplantıları ilk toplantı kuralını atar, “gündemde bulunur” ve daha çok gezinme eğilimindedir. Toplantılar iletişimi (yönetici için) optimize etmek için kullanılır, ancak geliştirici süresine (kesintiler, akış kaybı vb.) Mal olurlar.

Amaç nedir Gereksinimlere hitap eden, hızlı ve kaliteli bir yazılım oluşturmak, kısıtlamalar ise (kalite, zaman, maliyet, süreç). Scrum ve diğer çevik metodolojiler süreç kısıtlamasını kabul eder ve bu faktörü en aza indirmeye çalışır ve başarılı olmuştur çünkü bu kısıtlamayı en aza indirirler. Ancak toplantılar eklemek zaman alır ve kesinti, geliştiriciye toplantı süresinden çok daha fazla maliyet getirir.

Toplantıyı, faydalar sağladığından emin olmak için değiştirin:

1. Bazı kolaylıklar sunan bir zamanda planlayın. Neden işe başladıktan 30 dakika sonra olamıyor ki herkes e-postaları gözden geçirip toplantıya ilişkin düşüncelerini düzenleyebilsin. Brevity planlama yapar. Hazırlıksız olan sonsuza kadar başıboş olabilir.
2. Toplantıda bir sorun iletildiyse, önlenebilecek sorunları tespit edin. Herkesin amacı nedir anlamalı.
3. Herkesin girdisini minimumda tutmak için ne gerekiyorsa yapın. Tartışılacak yer orası değil. İnsanları, tartışılması gereken bir konuya odaklanan günlük toplantı dışında toplantıları özel olarak planlamaya teşvik edin. Kural: bir seferde sadece bir kişi konuşuyor.

Tüm şikayetçilerin soruna katkıda bulunmadıklarından emin olmaları gerekir. Günlük iştahla ilgili hedeflerinizi daha az acı verici bir şekilde yapmadan başarabilirseniz, duymak isteriz.