Ekibiniz bir çalışma metodolojisi (scrum gibi) takip etmeden iyi çalışıyor mu?

Son 9 yıl içinde küçük takımlarda çalıştım. Her biri kısa toplantılar, revizyon kontrolü, sürekli entegrasyon yazılımı, sorun izleme gibi bariz iyi uygulamalara sahipti.

Bu 9 yıl içinde, geliştirme metodolojileri hakkında hiçbir şey duymadım; örneğin, hiçbir zaman "scrum yapıyoruz" veya "çevik yapalım" ya da geçen bir referanstan başka bir şey olmadı. Tüm takımlar iyi işlemiş gibi görünüyordu, fazla bir süreç izlemeden, sadece serbest akışlıydık ve doğal olarak iyi çalıştık.

Scrum / çevik / vb. İle karşılaşmadan başkası uzun süre ilerledi mi?

Bunlara maruz kaldığım tek şey bunun gibi sitelerden geçiyor. Sprint Meetings - Ne hakkında konuşmalıyım ... gibi tüm soruları okudum ve tüm konuşmalar, bir metodoloji sonlu durum makinesini takip eden insanlar gibi neredeyse robotik gibi görünüyor. Gerçekten (abartılı olsa da) böyle mi? Merak ediyorum internette yayın yapan insanlar, "en iyi uygulama" nın yüksek sesle destekçileri, benzer ders kitabı görünümleriyle, insanların nasıl çalıştığını gerçekten yansıtmıyor mu ... Ya da süreçlerini doğal olarak oluşturan bazı takımlarla karşılaştım.

Dahası (ben İngiltere'liyim, bu konuyla alakalı olabilir) ... Sanırım üzerinde çalışacağım takımlardan herhangi birine bir metodoloji getirilmiş olsaydı, bunu aptalca ve gereksiz olarak reddederlerdi ... sonra taşıyın üzerinde. Katılıyorum, süreçleri takip etmek biraz doğal görünmüyor. Bu tipik mi yoksa yaygın mı?

Burada 20 yılı aşkın bir süredir geliştirme deneyimi var ve hiçbir zaman resmi bir metodoloji kullanmadım. Onlara hiç ihtiyaç duymadım ve gelecekte bir tane kullanmayı planlamıyorum. Metodolojiler bazı insanlar için iyi olabilir, ancak iyi, test edilmiş kod yazan yetenekli programcıların yerini tutmazlar.

Şahsen, günün en sıcak yeni metodolojisini takip etmek ve kod kalitesine daha fazla odaklanmak için daha fazla önem vermek birçok insanın olacağını düşünüyorum.

Dürüst olmak gerekirse, küçük ekibiniz süreç düşünmeden tüm bu yıllar boyunca büyük olaylar olmadan iyi çalışıyorsa, muhtemelen bir çeşit çeviklik yapıyordunuz. Tüm çevik bir süreç, yinelemeli, hikaye tahtaları, vb. Hakkında söyleyecek şaşırtıcı bir şey olmayan "Çevik Manifesto" http://agilemanifesto.org/ ile uyumlu olduğu anlamına gelir. Çevikliğin ilk kiracısı, "Bireyler ve msgstr "süreçler ve araçlar üzerindeki etkileşimler". Birlikte iyi çalışan herhangi bir takımın süreç hakkında çok fazla düşünmesi gerekmez.

Birbirleriyle çalışmaya alışkın olmayan yepyeni bir ekibiniz varsa, farklı çevik markalar (Scrum vb.) Çok kullanışlıdır. Uyumlu bir ekibin nasıl inşa edileceğine dair bir çerçeve oluşturdular ve bu da uyumlu bir ürün oluşturacak.

Yaptığınız şey çalışıyorsa, yapmaya devam edin. Teslim edilebilir ürünlere sürekli geç kalıyorsanız, fazla mesaiyi rutin olarak çekmeniz veya bir şeyi dağıttıktan sonra büyük hataları düzeltmeniz gerekiyorsa - bir şeyler yanlıştır. İşte o zaman sorunları çözmek için bir dizi küçük değişiklik yaparsınız.

Eğer her şey yolundaysa ve her zaman yolundaysa sorun yoktur - bu yüzden yeni (takımlarınız bir tür metodolojiyi izleyecektir - resmi veya başka bir şekilde) metodoloji gerçekten zaman kaybı olacaktır.

Metodolojilerin gerçekten yardımcı olduğu durumlarda, takımın sorunlarla dış kaynaklardan karşılaştığı veya bunlarla ilgili sorunları olduğu zaman - bir metodoloji sadece iyi uygulamaları tanıtmakla kalmaz, onları korumanıza yardımcı olur . İyi uygulamaları bilinçli bir şekilde yaparken stres altında tutmak çok daha kolaydır, aksi takdirde hızla sıkışabilirler.

Resmi bir metodolojiye ihtiyacınız olduğunu düşünmüyorum - ancak her takımın etkili bir IMHO olması için çalışmalarına bir çeşit örüntüye (mutlaka tekrarlanması değil, olaya bağlı olabilir) ihtiyacı var.

Çözmek için sorun yoksa, şanslıyım.

Tanımlanmış bir metodoloji olmadan iyi çalışan birçok takım (özellikle çok küçük şirketlerde) gördüm.

Eğlenceli olduğu için ya da internetteki blog gönderisini okuduğunuz için bir metodoloji (veya teknik) uygulamak çok tehlikelidir.

Eğer iyiyseniz, hiçbir şeyi değiştirmeyin. Yapabildiğinizde bazı optimizasyonları deneyin.

Bazıları oldukça mantıklı, bazıları çılgınca sınırlanan geniş bir dizi metodoloji vardır. Hepsi sağduyu kodluyor , onlara komik bir isim veriyor, sonra çok fazla kitap / seminer / vb satıyorlar.

Şimdi yönetiminiz ya da gerçekten ekibiniz sağduyundan yoksundur ve organik olarak kendi mantıklı metodolojilerine sahip değilse (bilinçli ya da sözlü değil), o zaman çalışmaya değer olabilirler ve daha sonra metodolojinin bölümlerini üstlenirler. bu ekibin deneyimleriyle alakalı .

En son <insert-buzzword-here>çalışma uygulamalarının battaniyeye yerleştirilmesi, çözmeyi amaçladığından daha fazla karışıklığa neden olmakla yükümlüdür. Ancak, genellikle kodlama yapmayan bir satır yöneticisinin coşkuyla işaretleyebileceği birçok onay kutusu metriği sağlayabilir.

Belki çevik ya da scrum demediniz ama bu, hiçbir işleminiz olmadığı ve kullanmadığınız anlamına gelmez.

Tıpkı yazılım geliştirmenin kendisi gibi. Açıkça isimleriyle düşünmemenize rağmen, muhtemelen birkaç tasarım deseni kullanacaksınız.