it-swarm.asia

Agile yeni mikro yönetim mi?

Bu soru bir süredir kafamda yemek pişiriyor, bu yüzden geliştirme ortamlarında çevik/scrum uygulamalarını takip edenlere sormak istedim.

Şirketim nihayetinde çevik uygulamaları hayata geçirmeye çalıştı ve deneme temelinde çevik bir grupta 4 geliştiriciden oluşan bir ekiple işe başladı. 3 yineleme ile 4 ay oldu ve geri kalanımız için tamamen çevik olmadan yapmaya devam ediyorlar. Bunun nedeni, yönetimin, iş gereksinimlerini karşılamak için duyduğu güvenin, yukarıdakilerden biraz fazla ad hoc tipi talep ile olmasıdır.

Son zamanlarda, bu girişimin parçası olan geliştiricilerle konuştum; bana bunun eğlenceli olmadığını söylüyorlar. Scrum ustası tarafından diğer geliştiricilerle konuşmalarına izin verilmez ve çalışma alanında herhangi bir telefon görüşmesi yapmasına izin verilmez (bu da bir dereceye kadar iyi olabilir). Örneğin, çevik takımdaki vuruşlar için arkadaşımla konuşmak istersem, Scrum ustasının onayı olmadan izin verilmez; çevik ekibin hemen yanında oturuyor.

Tüm bunların veya çevikliğin fikri, çevik geliştiriciler için herhangi bir kesintiden tam bir vakum sağlamak ve onları 6 saatten fazla üretken saatlere koymaktır. Eh, çocuklar, çevik bir guru değilim ama Yahoo çevik sunum belgesini ve diğer kuruluşlar için benzerleri okuduğum şey, bana çevikliğin ucuz olmadığı hissi veriyor. Ekiplere çeviklik aşılamak için kaynak ve bütçe gerektirir ve onları tekrar yoluna sokmak için geldiklerinde sorunu düzeltir.

Yeni başlayanlar için, geliştiriciler için eğitim ve yöneticiler vb. İçin koçluk gerektirir ... Şu anki Scrum ustası, yönetim tarafından ödenen birkaç günlük çevik eğitim dersi alan bir yöneticiydi, şimdi bu çevik ekibe liderlik ediyor. Toplantıda ayrıca çevik manifesto'nun çevikliğin taşlara yerleştirilmediğini ve her şirket için farklı şekilde özelleştirildiğini dikte etmediğini duydum. Her şey kulağa iyi ve mantıklı geliyor.

Sonuç olarak, her zaman çevikliğin geliştirme ekiplerine uyum sağlaması gerektiğini düşündüm, bu da mutlu geliştiricilerle sonuçlanır. Ancak, çevik takımdaki geliştiricilerle konuşurken çok zıt bir his alıyorum. Çalışmaktan başka bir şey konuşamayacaklarından mutsuzlar, tüm gün sessizce oturup sadece çalışıyorlar ve yönetimin daha fazla çalışmasını sağlamanın başka bir yolu olduğunu düşünüyorlar.

Söylesene lütfen, eğer bu daha fazla dolar için bencil avantaj amacıyla kullanılan iyi uygulama örneklerinden biri ise? Ya da belki de sadece benim gibi geliştiriciler biziz ve bu çevik ekip sadece iş soludukları için nefes aldıkları bir ortamda çalışmaktan hoşlanmadıklarını düşünüyor.


ABD'de ofisleri olan sağlık alanında bir şirkettir. Kesinlikle bir kovboy tarzı çevik gibi geliyor, bu da beni gerçekten çevik gitmek istemiyor, esp benim şirket.

Her şey tamamen ucuz olmak yönetimi ile ilgili. Daha ucuz versiyon için pahalı kahveyi kesmek, tasarruflara vurgu yapmak ve mümkün olduğunca zayıf kalırken üretken olmak.

Benim hissim kapının arkasındaki yönetimde birisinin bu fikri ortaya atması, çevikliğin sizi daha fazla üretmesini sağlaması, böylece patronlarımıza aynı çalışan sayısıyla daha fazla ürettiğimizi gösterebilmemiz. Ya da belki de durum böyleyse personel sayısını azaltmamıza izin verir.

Onlar günlük 5 dakika toplantı yapıyorlar. Ancak ekibinin dışındaki biriyle sohbet etmesine veya konuşmasına izin verilmez. Tüm odak noktası iş üzerindedir.

81
Smith James

Çevik değil yönetimsel diktatörlüğü tarif ediyorsunuz. Çevik, değişen gereksinimler alanındaki artımlı gelişim ile ilgilidir, insanları işlerini bireysel olarak nasıl yaptıklarını dikte etmekle ilgili değildir.

89
Sami Lehtinen

Scrum ustası tarafından diğer geliştiricilerle konuşmalarına izin verilmez ve çalışma alanında herhangi bir telefon görüşmesi yapmasına izin verilmez.

Bu gerçekten Agile uygulamalarının bir parçası değil - ve ayrı bir konu.

Çevik metodolojilerin büyük bir motivasyonu, geliştiriciler arasında artan iletişim dir. Geliştirici <-> geliştirici iletişimini kısıtlamak, Çevik uygulamalardan ayrı bir konudur. Bunun gerçekleşmediğini söylemiyorum - açıkçası, ve kuruluşunuzdaki "çevik" sunumun bir parçası olarak etiketleniyor, ancak bu gerçekten çevik (ve bir şekilde çevik gelişim ruhuna karşı, IMO).

46
Reed Copsey

Bu, çevikliğin oldukça sapkın bir uygulaması gibi görünüyor. Çevik, eğer bir şey varsa, mikro yönetimi azaltmalı, arttırmamalı. Ekip bir taahhütte bulunur ve sürecin bir parçası, yönetimin ekibin bunu başaracağına güvenmesidir. Günlük scrum, geliştiricilerin birbirleriyle iletişim kurmaları için bir yol ve zamanlarını nasıl harcadıklarını değil, ne yaptıklarını bilgilendirmenin bir yoludur (bu, birkaç yerde gördüğüm bir hatadır). Tahmin süreci bile tahminlerden uzak durma zamanını kaldırmalıdır, çünkü bir hikayenin ne kadar süreceğini değil, göreceli karmaşıklığı tahmin etmelisiniz (başka bir yaygın hata). Geliştiriciler tarafından harcanan zamanı kontrol etmek mikro yönetimin ayırt edici özelliğidir ve zamanın süreçten kaldırılması çevikliğin temel ilkelerinden biridir.

31
jjb

Tanımladığınız ortam bahçe çeşitliliği sözde Agile saçmalık gibi geliyor.

Agile olmadan önce Agile ile ilgilenmiştim. Yaklaşık 2000 kodlamada yanıyordum, Extreme Programming'i duydum, denedim ve beğendim. Bir geliştirici olarak bana sağlam yazılım üretmenin en önemli şey olduğu bir bağlam verdi ve beni çıldırtan saçmalıkların çoğunu en aza indirecek araçlar verdi. Onu sevdim.

Bugün sorun, Başka bir yerde ayrıntılı olarak açıklayacağım , bugünlerde "Agile'ı benimseyen" insanların çoğunun, onları rahatsız ederse, hiçbir şeyi iyileştirmekle ilgilenmemesidir. Onlar için, "Agile" sadece geliştiricileri aynı eski şekilde yenmek için yeni bir sopa. Mesela, gelişmeyi yavaşlatan tüm saçmalığı ortadan kaldırırken üretkenliği radikal bir şekilde artırmanın bir yolu.

Şimdi. Bir şirkete başlıyorum ve çok fazla XP kullanacağım, ayrıca Agile dünyasına yasladığım bir sürü başka numara kullanacağım. Ama tam da seninki gibi hikayeler yüzünden, bugünlerde Agile'ın benimsenmesini duyduğumda kaçıyorum.

Sorunuza doğrudan cevap vermek için: Agile yeni mikro yönetim olmamalıdır. Bu, gerçek işi yapan insanlara bok yapmak için yetki vermekle ilgili olmalı. Ama sizin durumunuzda, Agile size kendi kötü içgüdülerini şımartırken söyledikleri en son yalan gibi geliyor. Bunun için gerçekten üzgünüm.

24
William Pietri

Bu çevik değil.

İlk olarak, Scrum çevik değildir. Scrum, açıkçası, saçmalıktır. Bir Aşırı Programlama evinde büyüdüm (kelimenin tam anlamıyla - Kent Beck babamın koltuğuna oturdu ve test hakkında benimle konuştum) ve Scrum'ın o olmadığını hemen söyleyebilirim. Scrum bir proje yönetim aracıdır - bir geliştirme projesi için tanımlanmış bir ritim. Ancak, gelişimin kendisi hakkında söylenecek bir şey yok ve gereksinimler, planlama ve müşteri ile ilişki hakkında söylenecek çok az şey var. XP tüm bunlar hakkında söylenecek çok şey var; kendini çevik olarak adlandırmak isteyen diğer herhangi bir metodolojinin konuşmaya eklemek için bir şeyleri olması gerekir. Scrum taraftarları bunu bir süreç olarak değil, Bilge bir adam bir zamanlar bir sargının iyi şeylere ulaşmak için çıkardığınız ve attığınız şey olduğuna işaret etti.

Tamam, scrum bitti!

İkincisi, herhangi bir çevik süreç için temel olduğuna inandığım XP'nin kurucu ilkesi geliştirici merkezli olmasıdır. Bu, geliştiricilere yapmaları gerektiğini bildikleri işi yapma gücü vermenin bir yoludur ve sık sık yapmaları durdurulur. Çevik bir takım demokrasi veya otokrasi olarak yapılandırılabilir, ancak liderler geliştiricilerdir. Proje yöneticilerinin rolleri vardır - hayati roller - ama bu takım liderliğinden biri değildir. Bir yöneticiye sahip olmak - özür dilerim, 'scrum master' - orada oturmak, insanları patronlaştırmak, takımın çevik yapmadığının kesin bir işaretidir.

Üçüncüsü olması gerektiğini hissediyorum. Yok.

23
Tom Anderson

Scrum, Agile'nin piç çocuğudur. Tüm çevik metodolojilerin en şelale tarzı ve bu yüzden yöneticiler arasında en popüler olanı.

Tüm çevik yöntemler, bok engellemeden çalışma kodu üretmekle ilgilidir. Tekrar okuyun. Ve yeniden.

"Çevik kurallar" ne bakılmaksızın, bu hedefe engel olan her şey kötüdür. Kurallar engellenirse, f * * kurallarını değiştirin! Bu çevik yol, onu alakalı ve etkili kılan şey bu.

Bunun en iyi örneği , Alistair Cockburn (çevik manifestonun yaratıcılarından biri) tarafından verilir:

“4-6 kişiyi iş istasyonları ve yazı tahtaları bulunan bir odaya koyun ve kullanıcılara erişin. Kullanıcılara bir veya iki ayda bir çalışan, test edilmiş yazılım teslim etmelerini sağlayın ve aksi halde bunları yalnız bırakın. ”

Bu sahip olduğunuz adamların kalitesi için işe yarıyorsa, ihtiyacınız olan tek şey budur. Scrum master'a veya "çevik" bir metodolojiye ihtiyacınız yok. Günlük bir scrumda oturmak sizin için işe yarıyorsa, f * * * yapın. Ayağa kalkmak, kendiniz için düşünme yeteneğinizin acınası bir şekilde kaldırılmasıdır.

Yaptığınız çevikliğe bir yanıt var. Bu kadar. Yazdırın ve başka hiç kimse yokken bir yere sabitleyin ve kendileri için keşfetmelerine izin verin.

16
gbjbaanb

Mevcut Scrum ustası, yönetim tarafından ödenen birkaç günlük çevik eğitim dersi alan bir yöneticiydi ve şimdi bu çevik ekibe liderlik ediyor.

Bu senin sorunun. Yönetimler biraz Çevik istiyor, ne olduğunu gerçekten bilmiyorlar ve takımlara dayatıyorlar. Geliştiricilerinizin verimliliğini önemli ölçüde azaltmak istediğinizde ne yapmanız gerektiği;)

Yeni süreç teklifi geliştiricilerden gelmelidir. Veya en azından onlar tarafından incelenip onaylandı bir yönetimin fikri ise.

Her durumda, geliştiriciler reddederse, ygulamayın! Ya da tarif ettiğin felaket olacak.

11
user2567

"Çevik" ve diğer her "yönetim metodolojisi", insanlar üzerinde mikro yönetimi zorlamak için sıklıkla istismar edilmektedir. OTOH da bazen kötü işçiliği savunmak için istismar edilir.

"Biz Agile'yiz" planlama eksikliği, tasarım, özellikler, kalite, yayın döngüleri hakkında düşünememe nedeniyle duyduğum en sık bahanedir. Bu genellikle geliştiricilerden ve alt yönetimden. Aynı zamanda, orta yöneticiler, mimarlar, satış görevlileri, vb. Mikro yönetim, sürekli değişen son tarihler ve özellik listeleri, insanlar üzerinde kitlesel fazla mesaiyi zorlayan (sürekli değişen son tarihler ve özellik listeleri elbette bunu sağlar) vb. .

Tabii ki ikisi genellikle doğrudan çelişkilidir ve aynı projede olabilir.

9
jwenting

Asıl sorunuzu cevaplamak için, yeni mikro yönetim Agile, hayır diyebilirim.

İlk olarak, okuyun this (Çevik manifesto) ve ortak geliştiricilerinizle konuşmamanın listede olmadığını fark edeceksiniz.

Aslında "Bireyler ve Etkileşimler", ortak geliştiricilerinizle konuşmamanın tam tersidir.

7
Ian

Çeviklik yeni öz yönetim olmalıdır. Çeviklik doğru bir şekilde uygulanırsa, kararların çoğu, biriktirme listesine eklenen makul kapsamda bir kullanıcı hikayesi çalıştıran bir müşteri ve geliştirici tarafından verilir. görevler tanımlanır.

Günlük scrum yönetim değil iletişim ile ilgilidir. Öncelik ve yük dengeleme hakkında bazı tartışmalar olacaktır, ancak scrumda yönetilen kişi umarım scrum ustasıdır. Bir geliştirici olarak katıldım, ne yaptığımı, ne yapacağımı ve hangi yardıma ihtiyacım olduğunu söylüyorum. Sonra scrum ustası ilerlememdeki engelleri temizleyerek eyleme geçmelidir.

Çevik ekipler günlük işlerin hiyerarşik olarak yönetildiğini düşünmemelidir. Kararlar, hiyerarşik bir örgütün en üstündeki biri tarafından uzaktan verilirse, kararın merkezsizleştirilmesinin zamanı gelmiştir. yapımı! Bazı insanlar ve bazı kuruluşlar için bu çok uzak bir köprü olabilir. Kuruluşunuz için aşağıdakiler doğru değilse:

Çevik Manifesto

"Bunu yaparak ve başkalarının bunu yapmasına yardımcı olarak yazılım geliştirmenin daha iyi yollarını ortaya çıkarıyoruz."

"Yeni patronla tanışın, eski patronla aynı." Agile'ı takımın içinden mümkün olduğunca kaynaklayın. Bazen bu, Agile kullanarak bir deneme projesinde yer almak isteyen bir koalisyon seçerek olur. Agile ekibinizi iyi ekip çalışması için sicile sahip gönüllülerden veya davetli üyelerden oluşturabilirseniz, bunu çözebilirler. Kısa bir projede küçük bir ekip kullanın, belki şirket içi veya erişilebilirliği yüksek bir müşteri için.

Değişimi kabul et. Belki biraz eğitim alabilirsin, ama belki bütçen sıkı ve paran orada değil. Diğer fırsatlar da gelişme sağlayabilir. Biraz okuma yapın, ekibin üyelerine Agile hakkında neler yapabileceklerini öğrenmelerini ve birbirlerine öğretmelerini sağlayın. Çevik evlat edinmeyi modellemeye ve yönlendirmeye yetkili yeni veya mevcut personel bulabilirsiniz.

2
DeveloperDon

Çevik takımlar, yaygın olarak anlaşılan bir amaç için çalışan futbol takımları gibidir. Birkaç yıldır çevik ekiplerin bir parçasıyım ve kilit nokta tüm paydaşlar arasında etkili ve verimli bir iletişim. Yöneticiler/Scrum ustaları sadece takımın kolaylaştırıcılarıdır ve geleneksel yönetim/mikro yönetim takımın ruhunu öldürecektir.

Çalıştığım ekiplerde, çalışma saatlerinden sonra üyelerdeki arkadaşlığı geliştirmek için takım oyunları oynamaya teşvik ediyoruz. Bu düşünceleri topladım burada .

1
Vinod R

Sorunuzu cevaplamak için: Hayır. Agile bir tür mikro yönetim değildir. Ancak her araç gibi insanlar da yanlış kullanabilir. Çevik, doğru bir şekilde uygulandığında ve insanlar onunla tutarlı olduğunda harikadır.

"Geliştiriciler scrum ustası dışında kimseyle konuşmuyor" konusundaki düşüncelerim:

Daha önce kural olan bir yerde çalıştım. ANCAK, kural daha çok insanlardan görevleri tamamlamalarını istemekle ilgiliydi. Örneğin, bir dev test cihazına rastgele gidip önümüzdeki birkaç saat içinde benim için biraz test yapmalarını isteyemem. Scrum ustasıyla konuşmam gerekiyor, böylece ekip üyeleriyle acil bir durumda bu çalışmanın sprint'e nasıl uyacağını tartışabilirler (veya gelecekteki bir sprint için biriktirmeye itilmesi gerekiyorsa).

Bu durumda, "devs birbirleriyle konuşmuyor" kavramını anladım, çünkü belirli bir geliştiricinin fazla çalışmaması veya acil durum görevlerini yapmakla o kadar meşgul olduğu için planlananları alamadıkları için huni görevlerine gerçekten çevrildi iş bitti.

Aksi takdirde, geliştiriciler birbirleriyle konuşmalıdır. Her zaman. Sorunları daha hızlı çözmenize, ekip olarak yaklaşmanıza ve daha hızlı sunmanıza yardımcı olur.

Sadece başka bir bakış açısı sunmak için: İnsanların geliştiricilerin "çok fazla konuştuğunu" düşündükleri bir ortamda da bulundum. Bir oturuştan sonra, aslında "geliştiricilerin kendi işlerini yapacak kadar bağımsız olmadığını" öğrendik. Her şey çok parçalanmış olduğu için, geliştiricilerin küçük görevleri tamamlamak için diğer üç kişiye gitmeleri gerekiyor.

Bu nedenle, yöneticiler çevikliğe geçmeye karar verdiğinde, bilgileri doğru yerlere getirmeye ve organizasyon içindeki parçalanmanın çoğunu durdurmaya yardımcı olmayı beklediler. Bazı insanlar Agile uygulandıktan sonra geliştiricilerin hala birbirleriyle ileri geri koştuklarından hayal kırıklığına uğradılar. Ancak, fark etmedikleri şey, bunun gittikçe daha az gerçekleştiğidir. Yine de zaman aldı. Yani, belki kuruluşunuzda olup bitenler buysa, insanlar bir gecede bir şeyleri düzeltmek için çeviklik bekleyebilirdi. Sadece bu şekilde çalışmaz.

0
JustBlossom