Scrum Takımında Şüpheci

Şirketim yakın zamanda Çevik bir çalışma şekline geçti ve bunun bir parçası olarak SCRUM'u kullanmaya başladık. Bununla çok rahatım ve bu yolun geleneksel olandan daha üstün olduğunu hissediyorum, ancak takım arkadaşlarımın bazıları aynı görüşü paylaşmıyor. Aslında "tüm bu çevik şeyler" konusunda çok şüpheci ve ciddiye almıyorlar. Örnek olarak, takım arkadaşlarından biri toplantılara her zaman geç kalır ve gerçekten umursamaz. Yönetim IMO bunu fark etmemeye çalışır (belki de yeni olduğu için ve insanların buna alışması zaman alır).

Benim sorum, takım içinde bir çatışmaya yol açmazken bu sorunu nasıl çözeceğim?

Aşırı şüpheyle karşılaştığımda birkaç şey deniyorum:

1.) Böyle TDD olarak teknikleri göstermek, Kullanıcılarınızla Sürekli Dağıtım, Çifti Programlama, Gereksinimler Buluşması, vb ben kısa yineleme yok Çevik Manifesto (I Yazılım El Sanatları isimli hakkında üzerinde harp yapmak konusunda üzerinde bu teknikler Çevik veya harp diyoruz - ama bu farklı; p). Ekip üyelerine hayatlarını kolaylaştıran faydalı araçlar ve teknikler gösteriyorum. Günlük faydaları gördüklerinde Agile bandwagonuna atlama eğilimindedirler.

2.) Tam üflemeli bir SCRUM (veya başka) metodolojisine derhal takas etmem. Bir seferde Agile'ın küçük yönlerini tanıtmak her zaman en iyisidir.

3.) Şüphecilere katılıyorum (bir noktaya kadar). Çevik gümüş kurşun değildir ve SCRUM, Kanban, Lean vb. Gümüş kurşun değildir. Bunun yerine, hangi yönlerin hemen faydalanabileceğini görmek için onlarla birlikte çalışıyorum (CI sunucusu genellikle bir beyinsizdir) ve daha sonra geri kalanı denedim "Stand-up'lara bir hafta boyunca izin verin ve sonra gözden geçirin".

Herhangi bir metodoloji gibi, SCRUM ve diğerlerinin de onları yabancılaştırmak değil, ekip ve organizasyonla çalışması gerekir.

Doğrudan sorunuza ulaşmak için. Ekiple birlikte kaldırın:

"Stand-up'lar hakkında da biraz şüpheliyim, ama bir takım olarak 1 hafta boyunca (mazeret yok!) Doğru bir yol vermeli ve sonra bunun bizim için işe yarayıp yaramadığını görmek için gözden geçirmeliyiz. düşünüyorsun?"

Tipik olarak yanlış uygulanan Scrum örneği .

Scrum takıma empoze edildi. (Bütün) takım bunu seçmedi.

Uygulamak istediğinizde, hem ekibi hem de yönetimi tam olarak desteklemelisiniz, yoksa hiç işe yaramayacaktır.

Değişime karşı direnç burada düşmanınızdır.

Başlamanızı ve Scrum'ı takıma sunmanızı ve soru sormalarını öneriyorum .

Fikri satamazsanız, istemedikleri bir metodoloji kullanarak onları zorlamaya çalışmayın. Sabote etmek için her şeyi yapacaklar. Günlük ayaklanmalarda geç kalmak, alacağınız davranışlardan biridir.

Scrum'ın şirketiniz için tavsiye edilmeyebileceğini lütfen unutmayın . Bu soruya cevap verebilecek tek kişi üssünde çalışan kişilerdir. Takım .

Günlük toplantılar kavramı bir kişinin yaptıklarına çok iyi uymuyor olabilir. Bu toplantılar ücretsiz değildir.

Yaptığınız şey, ağır matematik gibi uzun vadeli bir konsantrasyon gerektiriyorsa, toplantılar sizi raydan çıkarabilir ve sinir bozucu olabilir. Haftalık olarak buluşmayı tercih eden böyle biriyle çalışıyorum, ki bu oldukça makul.

Aslında, eğer programlama ekibinizde olsaydım dürüst olmak gerekirse, muhtemelen bu kuşkucu olurdum! İşlerde devrim yaratacak ve projeleri zamanında, bütçe dahilinde ve hatasız hale getirecek uzun bir metodoloji hattı gördüm. Bu sadece sonuncusu. Yılan yağına neden inanmalıyım? 10 yıl önce aynı insanlar başka bir şeyi kırıyorlardı, birkaç yıl içinde yeni bir şey ortaya çıkacak. Beni yanlış anlamayın, bazı yeni metodolojilerin bazı yararlı fikirler getirdiğini düşünüyorum. Ne yazık ki bir sürü dogma ve aptalca fikir de getiriyorlar.

Gemiye binmemesi gerçekten önemli mi? Ona bazı programlama görevleri atayın ve istediği gibi yapmasına izin verin. Eğer işi tatmin ediciyse bırakın. İşi tatmin edici değilse, değiştirin. İnsanlar scrum'u takip etmek neden bu kadar önemli?

Yıllar boyunca, yöneticilerinin yeni metodolojiler sunmaya devam etmeleri nedeniyle birçok iyi programcının istifa ettiğini veya rahatsız olduğunu gördüm. Sadece kodlamak ve işi halletmek istiyorlar. Güven bana birkaç yıl sonra lanet scrum olacak ve son fad ne olursa olsun atlamak.

Çevik yapıyorsanız, üzerinde çalıştığınız bir iş birikimine sahip olmalısınız. İş yığınından ödevleri dağıtmak için scrum'ı kullanın.

Seçim (en iyi) ödevleri ilk olarak toplantının başında seçilir. Geç geldiğinizde ona sadece gün için kalanları verin.

Tanrı'nın programlamaya armağanı olması önemli değil, kimsenin istemediği boktan bir görev alır. Eğer başka bir görevi yerine getirmeye veya başka bir şey üzerinde çalışmaya çalışırsa, ekibin bir bütün olarak ona yaslanması ve onu sadece "seçtiği" görev üzerinde çalışmaya zorlaması gerekir. Muhtemelen seçilen iş üzerinde çalışmıyorsa, değişikliklerini reddedebilecek bir yapı ustanız olmalıdır.

Ayrıca ekip hedefler koymalı ve potansiyel olarak tazminat ödemelidir. Katılmayanları ödüllendirmemek için bir takım olarak oy kullanabilirsiniz. Bu, yönetiminizin çevik ekibinize verdiği sahiplik miktarına göre değişir. Ekibi inciten ve ekibin başarılı olmasını engelleyenlerin yönetimini hatırlatın.

Ona hatırlatırsa, sürece katılabilir.

Scrum takımlarının kendi kendini organize etmeleri gerekiyor. Scrum ayrıca her şeye aşırı şeffaflık uygulayarak çalışır.

Bu yüzden açık cevap, Scrum Master'ın bir toplantıyı çağırması, sorunu açıklaması (ancak kendiniz kandırmayın, takımdaki herkes sorunun tam olarak ne olduğunu zaten biliyor) ve sonra onlara ne olduğunu anlamaları için 1 saatlerinin olduğunu söyler. bu konuda yapacaklar. Sonra köşede oturuyor ve ağzını kapalı tutuyor.

Açıkçası, bu Scrum için yeni bir takım. Yani anahtar, Scrum Master'ın ekibin cevaplarını ne olursa olsun kabul etmesi gerektiğidir. Onları geçersiz kılarsa veya çözüme kendi fikirlerini dayatırsa, ekibin kendisiyle örgütlenmesine izin verildiği güveni yok edecektir. Takımın hiçbir şey yapmamaya karar vermesi mümkündür.

Her halükarda, bu konu Sprint Retrospective'te gözden geçirilmelidir ve ortaya çıkardıkları çözümün etkinliği tartışılabilir.

"Takım çatışması" ndan kaçınmak hiç de bir faktör olmamalı.

Takım arkadaşını kov, o zaman takım içinde tartışmalara neden olmaz.

Eski çalışmalarınıza göz atın, su düşüşü yaklaşımının geçmişte birçok kez sizi nasıl hayal kırıklığına uğrattığına dair birkaç örnek kazın. Ardından vakaları takım arkadaşınıza sunun. Sağduyu bir an ile ışığı görecektir.

Programlama hassas bir faaliyettir, bu nedenle nadir bir birey zor gerçeklere duyarsız kalacaktır. En azından teoride.

Geçiş kararı kim verdi ve neden? Bu şüpheciler nereye karar verdiyse ya da karar sadece düştü mü?

Yeni yöntemlerinizi uygulamada çok katı ve / veya hızlı mısınız? Eski yöntemlerinizi kullanarak iyi (mutlaka mükemmel olmayan) ürünler çıkardınız mı? Şüphecilere onlara nasıl fayda sağlayacağını gösterdiniz mi? Gösterebilir misin? "Işığı gören" şüphecilere onlara, takıma ve şirkete nasıl fayda sağladığını gösterdi mi?

Muhtemelen sizden her şeyi sadece inananların sözleriyle kabul etmelerini istiyorsunuz. Muhtemelen bu şüpheciler daha önce yeni metodolojiler benimsemişlerdir ve hiç farkedilmediklerinde faydaları yoktur.

Belki sadece yeni inançlarınızı kullanarak üzerinde çalışan inananlar ile bir ya da iki proje yapabilirsiniz. Gerçek ölçümler yapın ve şüphecilere gerçek faydaları gösterin. Hatta şüpheciler ve eski yolları ile müminler ve yeni yolları arasında küçük bir rekabet bile kurmuş olabilir.

Şüphesiz şüpheciler kazanırsa ne yaparsınız?

Şirketinizin neden SCRUM'a geçtiğini tartışmak ve anlamak için bir ekip toplantısı yapın ve herkesin SCRUM hakkında ne düşündüklerini belirlemesini sağlayın, mevcut çalışma moduna değer katacaktır. Bazen şirketler kemikli anahtarlar yaparlar (Kimsenin gerçekten dinlemediği ve herkesin dün yaptıkları şeyleri tıkadıkları scrum toplantılarına katıldım. Benimle "ve oraya dolan. Bu sadece zaman kaybıdır), O zaman senin için en iyisini al.

Gaziler genellikle mevcut çalışma stillerini değiştirebilecek herhangi bir şeye karşı çok dirençlidirler, Bu yüzden onların eylemsizliklerinden kurtulmaları için yeterli havuç olduğundan emin olmalısınız. Bu durumda, ya o kişi ile 1: 1 olurdu ya da onu scrum ustası yapardım :). Onlara sorumluluk verdikten sonra, onunla barış bulacaklar veya değer katmayacağı için tamamen ortadan kaldıracaklar. İkisi de kazan kazan.