Çevik yeni mikro yönetim mi?

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

Şirketim nihayet çevik uygulamaları birleştirmeye teşebbüs etti ve deneme temelinde çevik bir gruptaki 4 geliştiriciden oluşan bir ekiple çalışmaya başladı. 3 tekrar ile 4 ay oldu ve geri kalanımız için tamamen çevik olmadan yapmayı sürdürüyorlar. Bunun nedeni, yönetimin, iş gereksinimlerini yukarıdan gelen bir miktar özel tip taleple yerine getirme konusundaki güvenidir.

Son zamanlarda, bu girişimin bir parçası olan geliştiricilerle konuştum; bana eğlenceli olmadığını söylüyorlar. Scrum ustaları tarafından diğer geliştiricilerle konuşmalarına izin verilmez ve çalışma alanında herhangi bir telefon görüşmesi yapmaları yasaktır (ki bu bir ölçüde iyi olabilir). Örneğin, arkadaşım ile çevik takımda olan tekmeler için konuşmak istersem, Scrum ustasının onayı olmadan izin verilmez; kim çevik ekibin yanında oturuyor.

Tüm bunların veya çevikliğin düşüncesi, herhangi bir kesinti nedeniyle çevik geliştiriciler için tam bir boşluk sağlamak ve onları 6'dan fazla verimli saatlere çıkarmaktır. Beyler, ben çevik guru değilim ama Yahoo çevik dağıtım belgesini okuduklarım ve diğer kuruluşlar için benzerleri, bana çevikliğin ucuz olmadığı hissini veriyor. Ekiplere çevik hale getirmek ve onları yeniden izlemek için geldiklerinde sorunu düzeltmek için kaynak ve bütçe gerekmektedir.

Yeni başlayanlar için, geliştiriciler için eğitmenler ve koçluklar vb. İçin koçluk gerektirir. Şu anki Scrum ustası, yönetim tarafından ödenen çevik bir eğitim sınıfının birkaç gün süren bir yöneticiydi. Ayrıca toplantıda, çevik manifesto'nun çevikliğin taş koymadığını ve her şirket için farklı şekilde özelleştirildiğini belirlemediğini de duydum. Her şey kulağa hoş geliyor ve sebep.

Sonuç olarak, çevikliğin her zaman mutlu geliştiricilerle sonuçlanan geliştirme ekiplerine uyum sağlaması gerektiğini düşündüm. Ancak çevik ekipteki geliştiricilerle konuşurken çok zıt bir his alıyorum. Çalışmaktan başka bir şey konuşamadıkları için mutsuzlar, bütün gün sessizce oturmak, sadece çalışmak ve yönetimin daha fazla çalışmasını sağlamak için başka bir yol olduğunu düşünüyorlar.

Söyleyin lütfen, bu bence dolar için bencil avantaj sağlamak için kullanılan iyi uygulamaların örneklerinden biriyse? Ya da belki, bizler gibi biz sadece biz geliştiricileriz ve bu çevik ekip iş başında oldukları için yalnızca işi soludukları bir ortamda çalışmaktan hoşlanmadıklarını hissediyor.

ABD’de ofisleri bulunan sağlık hizmetleri alanında bir şirkettir. Kesinlikle şu andaki şirketimde, özellikle hiç çevik olmak istemememi sağlayan bir kovboy tarzı çeviklik gibi geliyor.

Bütün bunların yönetimin tamamen ucuz olması ile ilgisi var. Daha ucuz versiyon için pahalı kahvelerin kesilmesi, tasarrufun vurgulanması ve mümkün olduğunca yalın kalırken üretken olması.

Benim fikrim, kapının ardındaki yönetimde birisinin bu fikri atması, çevikliğin sizi daha fazla üretmesini sağlamaktır, böylece patronlarımıza aynı kişi ile daha fazla ürettiğimizi gösterebiliriz. Ya da belki, durum buysa, çalışan sayısını azaltmamıza izin verir.

Günlük 5 dakikalık toplantı yapıyorlar. Ancak, ekibinin dışındaki biriyle sohbet etmesine veya konuşmasına izin verilmez. Tüm odak iş üzerinde.

Yönetim diktatörlüğünü tanımlıyorsunuz, çevik değil. Çevik, değişen gereksinimler alanında artan bir gelişimdir, insanlara bireysel olarak işlerini yapmalarına nasıl devam edeceklerini dikte etmekle ilgili değildir.

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

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

Çevik metodolojilerin büyük bir motivasyonu, geliştiriciler arasındaki iletişimi arttırıyor . Geliştirici <-> geliştirici iletişimini kısıtlamak, Çevik uygulamalardan ayrı bir konudur. Bunun olmadığını söylüyorum - açıkçası öyle ve kuruluşunuzdaki "çevik" sıranın bir parçası olarak etiketleniyor, ancak bu gerçekten çevik (ve çevik gelişim ruhuna karşı) IMO).

Bu, oldukça çevik bir çevik uygulama gibi geliyor. Çevik, eğer bir şey varsa, mikro yönetimi azaltmak zorunda değil, arttırmalıdır. Ekip bir taahhütte bulunur ve sürecin bir parçası, yönetimin ekibin başaracağına güvenmesidir. Günlük aldatmaca, geliştiricilerin birbirleriyle iletişim kurmaları ve ne yaptıklarını, zamanlarını nasıl harcadıklarını (birkaç yerde gördüğüm bir hatadır) bildirmenin bir yoludur. Tahmin süreci bile, tahminlerden uzak durma zamanını ortadan kaldırmalıdır, çünkü göreceli karmaşıklığı tahmin etmeniz gerekir, çünkü bir hikayenin ne kadar süreceğini değil (başka bir yaygın hata). Geliştiriciler tarafından harcanan zamanı kontrol etmek mikro yönetimin bir özelliğidir ve işlemden zamanın alınması çevikliğin temel ilkelerinden biridir.

Tanımladığınız çevre bahçe çeşitliliği sözde-Çevik saçmalık gibi geliyor .

Çevik olmadan önce Çevik ile ilişkim oldu. 2000 dolaylarında kodlama üzerine yazıyordum, Extreme Programming'i duydum, denedim ve beğendim. Bir yazılımcı olarak 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 başka bir yerde ayrıntılı olarak açıkladığım sorun, bugünlerde "Çevik" evlat edinen insanların çoğunun, eğer onları rahatsız ediyorsa, herhangi bir şeyi geliştirmekle ilgilenmemeleridir. Yani onlar için, "Çevik" sadece geliştiricileri aynı eski şekilde yenmek için yeni bir çubuktur. Söylendiği gibi, kalkınmayı yavaşlatan tüm saçmalıkları ortadan kaldırarak üretkenliği radikal bir şekilde artırmanın bir yolu.

Şimdi. Bir şirket kuruyorum ve çok fazla XP kullanacağım ve çevik dünyaya yaslandığım bir sürü numara daha kullanacağım. Ama tam da seninki gibi hikayeler yüzünden, bugünlerde Çevik bir evlat edinme hakkında bir şeyler duyduğumda yanıp sönüyorum.

Bu nedenle sorunuzu doğrudan cevaplamak için: Çevik yeni mikro yönetim olmamalıdır. Bu işi yapan insanlara, işlerini yapmalarını sağlamakla ilgili olmalı. Ama senin durumunda, Agile en son yalan gibi geliyor, kendi kötü içgüdülerini şımartırken sana söylüyorlar. Bunun için gerçekten üzgünüm.

Bu çevik değil.

İlk olarak, Scrum çevik değildir . Açıkçası, Scrum saçmalık. Bir Extreme Programming evinde büyüdüm (kelimenin tam anlamıyla - Kent Beck'in babamın kanepesine oturup benimle test hakkında konuşmasını sağladım) ve size Scrum'un olmadığını söyleyeyim. Scrum bir proje yönetim aracıdır - bir geliştirme projesi için tanımlanmış bir ritimdir. Ancak gelişim hakkında söylenecek hiçbir şey yok ve gereklilikler, planlama ve müşteri ile ilişki hakkında söylenecek çok az şey var. XP'nin bu konuda söyleyecek çok şeyi var; Kendini çevik olarak adlandırmak isteyen başka bir metodolojinin, konuşmaya ekleyeceği bir şey olması gerekir. Scrum savunucuları bunu bir süreç olarak değil, bir süreç için sarıcı olarak tanımladılar. Akıllı 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 atıldı!

İkincisi, herhangi bir çevik süreç için temel olduğuna inandığım XP'nin kurucu ilkesi , geliştirici üzerine odaklanmış olmasıdır . Bu, geliştiricilere yapmaları gereken bildikleri işi yapma gücü vermenin bir yolunu vermenin bir yoludur. Çevik bir ekip demokrasi veya otokrasi olarak yapılandırılabilir, ancak liderler geliştiricilerdir. Proje yöneticileri için roller vardır ve bunun gibi - hayati roller - ancak bu takım liderliğinden biri değildir. Bir yönetici - üzgünüm, 'scrum master' - orada oturan insanlara patronluk oturuyor takımın çevik olmadığına dair kesin bir işaret.

Üçüncüsü olması gerektiğini düşünüyorum. Yok.

Scrum, çevik piç çocuğu. Tüm çevik metodolojilerin en şelale tarzı ve bu nedenle yöneticiler arasında en popüler olanı.

Tüm çevik yöntemler, işe yaramayan iş kodları üretme hakkındadır. Bunu tekrar oku. Ve yeniden.

“Çevik kurallar” ne olursa olsun, bu hedefe giden herhangi bir şey kötüdür. Kurallar yerine gelirse, f * * kurallarını değiştir! Çevik bu, onu alakalı ve etkili yapan budur.

Buna en iyi örnek Alistair Cockburn (çevik manifesto'nun kökenlerinden biri) tarafından verilmiştir:

“İş istasyonları ve beyaz tahtalar olan ve kullanıcılara erişimi olan bir odaya 4-6 kişi yerleştirin. Kullanıcılara her 1-2 ayda bir çalışan, test edilmiş yazılımlar sunmalarını ve aksi halde onları yalnız bırakmalarını sağlayın. ”

Bu, sahip olduğunuz erkeklerin kalitesi için işe yararsa, ihtiyacınız olan tek şey budur. Bir scrum usta veya herhangi bir "çevik" metodolojiye ihtiyacınız yoktur. Günlük iş yerinde oturmak sizin için işe yararsa, o zaman f * * * yapın. Sizi ayağa kaldırmak, kendiniz için düşünme yeteneğinizin acıklı bir ifadesi.

Yaptığın çevikliğe bir cevap var . Onun bu. Kimsenin etrafında olmadığı zamanlarda onu yazdırın ve bir yere sabitleyin ve kendileri için keşfetmelerine izin verin.

Şu anki Scrum ustası birkaç gün süren bir yöneticiydi ve yönetim tarafından ödenen çevik eğitim sınıfının şimdi bu çevik ekibine liderlik ediyor.

Bu senin sorunun. Yönetimler biraz Çevik istiyor, gerçekte ne olduğunu bilmiyorlar ve bunu ekiplere dayatıyorlar. Bu, geliştiricilerinizin verimliliğini önemli ölçüde azaltmak istediğinizde ne yapmanız gerektiğidir;)

Yeni süreç önerisi geliştiriciden gelmelidir. Veya bir yönetimin fikriyse, en azından onlar tarafından gözden geçirilip onaylanmalıdır .

Her durumda, geliştiriciler reddederse, uygulamayın ! Yoksa tarif edeceğin felaket olur.

“Çevik” ve diğer her “yönetim metodolojisi” insanlar üzerinde mikro yönetimi zorlamak için sık sık suistimal edilir. OTOH, bazen kötü işçiliği savunmak için de kötüye kullanılıyor.

"biz Çevikiz" planlama sıkıntısı, tasarım, özellikler, kalite, sürüm döngüleri hakkında düşünme eksikliğinden duyduğum en sık karşılaşılan bahanedir. Bu genellikle geliştiricilerin ve düşük yönetimin. Bu aynı zamanda delilik, orta düzey yöneticilerden, mimarlardan, satış görevlilerinden vb. Mikro yönetim için duyduğum, en son tarih ve özellik listelerini değiştiren, fazla mesai yapan kişilere fazla mesai yaptırmayı (sürekli değişen tarihler ve özellik listeleri elbette ki bunu sağlamayı sağlar) vb. .

Elbette ikisi genellikle doğrudan çelişki içindedir ve aynı projede olabilir.

Asıl sorunuzu cevaplamak için, yeni mikro yönetim Çevik, hayır derim.

İlk olarak, okumak gitmek bu (Çevik manifesto) ve size yardımcı geliştiriciler konuşmuyor listede yok olduğunu göreceksiniz.

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

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

Günlük iş dünyası iletişim ile ilgilidir, yönetim değil. Öncelik ve yük dengeleme hakkında bazı tartışmalar yapılacak, ama scrum'da yönetilen kişi umarım scrum ustasıdır. Bir geliştirici olarak katılıyorum, ne yaptığımı, ne yapacağımı ve ihtiyaç duyduğum yardımı söylüyorum. Öyleyse scrum ustası ilerlememdeki engelleri kaldırarak eyleme geçmeli.

Çevik ekipler günlük iş gibi hissetmemelidir, işler hiyerarşik olarak yönetilir. Kararlar, hiyerarşik bir organizasyonun tepesindeki biri tarafından uzaktan verilirse, karar vermenin ademi merkeziyetinin zamanı geldi! Bazı insanlar ve bazı kuruluşlar için bu çok fazla bir köprü olabilir. Aşağıdakiler kuruluşunuz için geçerli değilse:

Çevik Manifesto'yu Yaşayın

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

"Yeni patronla tanışın, Eski patronla aynı." Çevik ekibin içinden mümkün olduğunca köken. Bazen bu, Agile kullanan bir deneme projesinde bulunmaya istekli bir koalisyon seçerek gerçekleşir. Çevik ekibinizi gönüllülerden veya iyi bir ekip çalışması için sicili olan davetli üyelerden oluşturabilirseniz, çalışabilirler. Kısa bir projede küçük bir ekip kullanın, belki bir kurum içi veya yüksek erişilebilir müşteri için.

Değişimi kucakla. Belki biraz eğitim alabilirsin, ama belki bütçen dar ve paran yok. Diğer fırsatlar da iyileşme sağlayabilir. Biraz okuma yapın, ekibin üyelerinin Çevik hakkında ne öğrenebileceklerini öğrenmelerini ve birbirlerine öğretmelerini isteyin. Çevik evlat edinme konusunda modelleme ve liderlik yapma konusunda nitelikli yeni veya mevcut personel bulabilirsiniz.

Çevik takımlar, genel olarak anlaşılan bir hedefe doğru çalışan futbol takımları gibidir. Birkaç yıldır çevik ekiplerin bir parçası oldum ve kilit nokta tüm hissedarlar arasında etkili ve verimli bir iletişim. Yöneticiler / Scrum ustaları sadece ekibin kolaylaştırıcılarıdır ve geleneksel yönetim / mikro yönetim ekibin ruhunu öldürür.

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

Sorunuza cevap vermek için: Hayır. Agile bir mikro yönetim şekli değildir. Ancak, herhangi bir araç gibi insanlar da yanlış kullanabilir. Çevik, doğru uygulandığında ve insanlar bununla tutarlı olduğunda harikadır.

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

Bunun daha önce kural olduğu bir yerde çalıştım. Bununla birlikte, kural insanlardan işleri tamamlamalarını istemekle daha fazla ilgiliydi. Örneğin, rastgele bir dev test cihazına çıkamıyorum ve onlardan birkaç saat içinde benim için bazı testler yapmalarını istemiyorum. Scrum efendisi ile konuşmam gerekiyor, böylece ekip üyeleri ile acil bir durumda (ya da gelecekteki bir sprint için backlog'a itilmesi gerekiyorsa) bu çalışmanın sprint ile nasıl uyuşacağını tartışabilirler.

Bu durumda, "birbirleriyle konuşmayan devs" kavramını anladım, çünkü gerçekten bir kontrol noktası aracılığıyla huni işlerine gerçekten çevrildi, bu yüzden belirli bir geliştirici fazla çalışmamıştı ya da acil durum görevlerini yerine getirmek için planlanamayacak kadar meşgul. iş bitti.

Aksi takdirde, devs birbirleriyle konuşmalı. Her zaman. Sorunlarla daha hızlı çalışmanıza, ekip olarak daha yakın olmanıza ve daha hızlı teslim olmanıza yardımcı olur.

Sadece başka bir bakış açısı sunmak için: İnsanların "çok fazla konuştuğunu" düşündüğü bir ortamda da bulundum. Bir oturuştan sonra, aslında "devler kendi işlerini yapacak kadar bağımsız değil. Her şey çok parçalı olduğu için devlerin küçük işleri tamamlamak için diğer üç kişiye gitmeleri gerekiyor."

Bu nedenle, yöneticiler çevikliğe geçmeye karar verdiğinde, bilginin doğru yerlere getirilmesine ve kurum içindeki parçalanmanın çoğunun durdurulmasına yardım etmeyi umdular. Bazı insanlar, Çevik uygulamadan sonra, devlerin hala birbirlerine karşı koştuğunu hayal kırıklığına uğrattı. Fakat farketmedikleri şey, gittikçe azaldığıydı. Yine de zaman aldı. Öyleyse, belki de organizasyonunuzda olan şey buysa, insanların bir gecede işleri düzeltmeyi çevik hale getirmeleri beklenebilir. İşe yaradığı gibi değil.

Orijinal Yazar Smith Janes, tecrübe etmiş olabilir. Fakat bunlar Çevik projede bulduğum tipik problemler.

1. Örgütlerin çoğunun, geliştiricilerin Çevik / Scrum'da çoklu projede çalışması gerekiyor. Sprintler bu gerçeği asla göz önünde bulundurmuyor. Scrum Master'ınız sprint sonunda öykülerinizle yapılması gerektiğini varsayar. Scrum ustanız yalnızca bir projeye adanmış olabilir, ancak geliştiricilere değil .. BU TUTMA NEDİR - sadece bir telefon görüşmesi yapmak gerekmez. veya telefon görüşmesine izin vermek.
2. Sprint'in planlandığı Çevik projeleri gördüm, Sprint'e dahil olan hikayeler, karışık olmadan… Sprintlerin yarısına veya ortasında .. çözülmeyen bağımlılıkları bulan geliştiriciler, gereklilikler veya öykü anlatılmamış ..... Bu en çevik projelerdeki Suistimallerden biridir.
3. Test Etme: TTD .. evet çok iyi .. ama Çevik projelerin çoğunun tamamen TTD'ye dayandığını gördüm ... İşlevsel veya İnsan testi için hiçbir zaman veya zamana izin yok. Fonksiyonel testlerin önemini bilmez veya anlamaz İşletmenizin ihtiyacını karşılamıyorsa, kod parçanız mükemmel çalışıyor olabilir .. işe yaramaz .. Bu iş ileride katılmadığında veya katılım var olduğunda olur ... ancak iş kararını yansıtmaz. .. Sonunda, geliştiriciler suçlanıyor, işlevsellik sunmadınız… ya da son dakika değişikliğiyle sonuçlanacak ... ekstra uzun saatler çünkü Scrum ustanız tamamlanmayan öyküyü suçlamak istemiyor.

Burada kötüye kullanım ... ya iş dünyasına katılımın düşük olması ya da tam bilgili olmayan katılımcılar ya da sprintin ortasındaki iş adamları.

1. Tüm projeler Çevik için uygun değildir ... Yöneticilerin veya aldatıcı ustaların çoğu bunu bilmez .. Bakım projeleri .. Başlangıçta kabul edilebilecek bir kusur 8 saat içinde yapılabilir, süratte kabul edilebilir. 4 saat harcadıktan sonra, bunun Java / başka bir ürün olduğunu buldum ... (Yakın zamanda Quartz Scheduler ile ilgili işlem hatasıyla karşı karşıya kaldım ... projemizin içinde) ve bu kusur ürün / paketin iyileştirilmesine yol açabilir. Bürokrasi, onay, Finansman, yeni sürüm veya yükseltme, İç Mühendislik vb. tarafından onaylanmalıdır. 5.Retroskopi: sadece birkaç Çevik proje bu adımı gerçekleştirir. Ne olursa olsun yapılır. Yönetmenlik, Scrum Master başarısız hikayelerden asla sorumluluk almaz.
2. Eşleştirme .. Birçok geliştirici eşleştirmeyi iş arkadaşlarına suistimal etme yeri olarak kabul eder .. diğer tasarımları eleştirir, kodlama uygulamalarını .. Takım çalışması gibi davrananlar, birbirlerinden öğrenirler ... Çevik / Scrum'u Kötüye Kullanmanın Başka Bir Yolu.

Çevik kesinlikle iyi bir metodolojidir. Kurumunuz tam olarak takip etmediği veya eğitilmediği sürece .... Suistimal ediliyor .... yan etkiler haftada 60+ çalışma saati, suçlama oyunu, düşük ahlaki.

Çevik kılık değiştirmiş mikromanlaşmadır. Agile'de inisiyatif ya da yaratıcılık için yer yoktur, yetersiz yöneticilerin teknik açıdan bir ipucu olmasa bile kontrolü ellerinde tutabilmeleri için eğlenceyi programlamadan kaldırmıştır.