Hangi programlama metodolojisi bizim için uygun olur?

Ne yazık ki, birisi üst yönetimimize "Agile" kelimesini öğretti ve şimdi ona doğru ilerlememizi istiyorlar. Çevresel bir çeviklik anlayışım var (prensip olarak) ama bunu pratikte hiç kullanmadım. Bildiğim kadarıyla, organizasyonumuz için uygun olmayacak. Şu anda, işler oldukça aşınmış. İşte böyle;

Çok küçük bir ekibiz - iki geliştirici, bir DBA, bir tasarımcı. Çalıştığım şirket, büyüklüğüne göre orantısız olarak büyük miktarda para kazanıyor ve bunun yaklaşık% 95'i saf çevrimiçi satışlar.

Geliştirme perspektifinden baktığımızda, tipik bir gün boyunca birçok masa istilasına maruz kalıyoruz (teknik destek ve geliştiriciyiz), bir satış ekibi üyesi birine bir şey vaat ederse iş düzenli olarak bir anda gökyüzünden düşebilir . Biz de daha büyük projeler üstleniyoruz ve bunlar sürekli kesintilerle bir kabus. Bazılarımız saçlarımızı yırtmaya başlıyor! Proje planları, teknik olmayan yöneticiler tarafından excel elektronik tablolarında hazırlanır ve burada görevi anlayabilecekleri ve her birinin yanına bir tarih koyabilecekleri ısırık büyüklüğünde cümleler haline getirmeye çalışırlar. Bu tarihler her zaman korkunç bir şekilde gerçekçi değildir ve çoğu zaman kaçırılır ve toplantılarımız (haftalık olarak yaptığımız) düzenli olarak "neden henüz yapılmadı" diye soran insanlarla garip anlarla doludur.

Eminim ki Agile bizim için değil. Şimdi, (ve denedim) bu şirketin yollarını değiştirmeyeceğini ve sadece dev ekibinin değişmeye istekli olduğu göz önüne alındığında, benimsediğimiz, sadece akıl sağlığımızdan kurtulmak için iyi bir seçim metodolojisi var mı?

Çevik aslında yaşadığınız sorunların çoğunu ele almak için tasarlanmıştır. Yönetim gerçekten satın alınmışsa ve süreci saptırmazsa, büyük bir gelişme görebilirsiniz. Sorunlarınıza noktadan noktaya değinmeme izin verin. Deneyimim scrum ile, bu yüzden bu açıdan konuşacağım, ancak diğer uygulamaların benzer faydaları olduğundan eminim.

• Gökyüzünden düşen işler Bu hikayeler, ürün sahibi ve ekibi yukarı taşımaya karar vermek için bir araya gelinceye kadar biriktirmenin alt kısmına konur. Önceliği ekibinizin diğer tüm taahhütlerine göre belirlenir ve bu öncelik bakmak isteyen her paydaş tarafından görülebilir. Bir sprint'in ortasına yeni bir özellik eklemek son derece nadir olmalıdır ve sadece en yüksek öncelikli hataların bir sprint'i kesmesine izin verilmelidir. Düzenli bir beklenti yapılan gelecek haftanın sonuna kadar kaç "acil" bekleyebileceği şaşırtıcı.
• büyük projeler üstlenmek Kısa vadeli önceliklerin uzun vadeli projelerinizi nasıl etkilediğini göstermek için görünürlüğe sahip olacaksınız. İnsanlar sürekli olarak kullanıcı hikayelerini uzun vadeli projelerinizin önünde taşıyorsa, ancak bu kararı vermek için herkes uzun vadeli projenin programındaki etkisini bilecektir.
• Proje planları olmayan teknik yöneticiler tarafından çizilir Kullanıcı hikayeleri vardır sözde bakış olmayan bir teknik açıdan yazılacak, ancak saldırı takım tahminler yapmak ve uygulama ayrıntılarını belirlemek yetkisi olmalıdır.
• tarihler aşırı gerçekçi değil Ekibiniz tüm tahminleri ele alıyor, çünkü ne yaptığınızı bilen sizsiniz. Bu tahminler işletme tarafından kabul edilebilir değilse, özelliklerin nasıl önceliklendirileceğine karar vermeleri gerekir. İşleyebileceğinizden daha fazla çalışmaya ihtiyaç duyarlarsa, daha fazla insanı işe alma ihtiyacı açıkça görülebilir.
• tarihler çoğu zaman gözden kaçırılır İlk olarak, tahminleriniz daha gerçekçi olacaktır, bu da yardımcı olacaktır. Ayrıca, daha küçük parçaları ısırıyor ve onları bitiriyorsunuz , bu da tam özellik olmasa bile işin yararlı bir şey üretmiş gibi hissetmesine yardımcı oluyor.
• garip anlarla dolu toplantılar Agile daha fazla görünürlük ve çok daha hızlı bir geri bildirim döngüsüne sahiptir ve ürün sahibi yoğun bir şekilde dahil olur. Engelleme sorunlarınız ve gecikme nedenleriniz sürpriz olmamalıdır.
• Ayrıca teknik destek yapıyor Çevik inanışın aksine, çevik bölünmüş bir programla uyumlu değildir. Kesintilerinizdeki faktörleri ekibinizin hızına sürükleyin. Normalde zamanınızın yarısını teknik destek için harcarsanız, hızın yarısına sahip olursunuz.

Yönetimin ve satışların fark etmesi gereken şey, çevikliğin geliştirme ekibi üzerinde daha sıkı kontrol kullanmanın bir yolu olmadığı, takıma iş ataırken işe tüm önceliklerini gerçekçi bir şekilde değerlendirmesine yardımcı olurken, iyi olduklarını yapma konusunda takıma daha fazla özerklik kazandırmasıdır . takım.

Yönetim kaprislerinden yararlanın diyebilirim! Sana bir iyilik yapıyor ve çalışma yöntemlerini geliştirmek için biraz kaldıraç gibi geliyor.

Onlara Tamam deyin, biz diğer şeyler arasında gerektirir çevik gidecek: -

• kalkınma ve destek ayrımı
• resmi bir gereklilik toplama süreci - BT ekibinin kontrolü altında. "Hikayeler" vb. Çok belirsiz görünüyor - ama aslında gayri resmi görünmek için giyinmiş bir "resmi" yöntem.
• zamanlama BT ekibinin kontrolü altındadır.

Eğer bunu kabul etmezlerse onlara çevik gidemeyeceğini söyle.

Agile bir programlama metodolojisi değil, Agile bir proje yönetimi metodolojisidir. Üst yönetim gerçekten buldukları bu yeni kelimeyi denemenizi istiyorsa, Agile yönteminin üstten başladığını ve yönetimin her adımında yönetimi içerdiğini anlamaları gerekir. Onlara zor bir gerçeklik dozu vermeniz gerekiyorsa, belki de biraz eğitim vermek için Agile hakkında 30 dakikalık bir Powerpoint sunumu düzenleyin. Yöneticiler Powerpoint'i sever.

Ancak, dediğiniz gibi, dev ekibi değiştirmek isteyen tek kişi ise, hiçbir geliştirme yöntemi size yardımcı olamaz. Diğer görevlerinizin hafifletilmemesi durumunda, kesintiler olmaya devam edecek ve karşılayamayacağınız son teslim tarihlerini karşılamanız istenecektir.

Bu senaryodaki tavsiyem, ön cephelerde gerçekte nasıl olduğuna ilişkin olarak berat değil, yönetimi eğitmektir.

Satış personelinin günlük programı dikte ettiği bir organizasyonda hiçbir yazılım geliştirme ve proje yönetimi metodolojisi yardımcı olamaz. Böyle kaotik ve dikkat dağıtıcı bir çalışma haftasında bir projeyi nasıl yönetmeniz gerekiyor?

Pek çok üst yönetici Agile'ın değerini görür ve faydalarını ister, ancak hareketin başarılı olduğundan emin olmak için gerekli iç değişiklikleri neredeyse hiçbir zaman yapamazlar. Tanıdığım tek başarılı Agile mağazası bu şekilde başlamıştı. Bir yönetilen satış veya şelale yazılım geliştirme mağazası deneyimimi tek bir örneği hatırlayamıyorum çünkü kültürde köklü bir değişiklik gerektiriyor.

Kültürde bu değişiklik mümkün müdür? Evet, ama senin durumunda neredeyse kesinlikle değil.

Kültürde bir değişiklik, genellikle bir yeniden örgütü haklı çıkarmak için şirketin varlığını tehdit eden bir yarışçı veya bir marka ya da kırılma durumu ya da benzer şekilde ilgili başka bir durum gerektirir. Sizin durumunuzda, şirketiniz şu anda paranın kolay olduğu ve herkesin şişmanladığı spektrumun diğer ucunda.

Şirketler ASLA paranın kolay olduğu zaman içinden değişmezler. Neden geliştirmeliler ki, yazılım geliştirme başarısızlıklarına rağmen, yazılım geliştirme başarıları nedeniyle değil, başarılıdırlar.

Son tavsiyem, ben olsaydım daha iyi bir şey arayacağım. Buradaki insanların büyük tavsiyeleri var ama daha önce bu şarkıyı ve dansı görmüştüm ve durumunuzda işe yaramıyor.

bakmak extremeprogramming.org - XP almak ve a la cart seçebilir kolay anlaşılır yönleriyle Çevik şeklidir; başlamak için çok iyi bir yer

bir entegrasyon sırasında zihinlerini değiştirmeme konusundaki müşteri taahhüdü , sesinden ortamınız için iyi bir başlangıç ​​noktası olacaktır ;-)

Eğer kişi hem geleneksel hem de çağdaş metodolojilerin manzarasını düşünürse, "Çevik" in bir metodolojiden ziyade "anti-metodoloji" olduğunu fark ederdi. Desenler, "en iyi durum" çözümünü belirli bir bağlamda belirli bir bağlamda göstermeyi amaçlamaktadır. Böyle bir çözümü veya modeli doğrudan ihlal etme girişimlerine genellikle "anti-desen" veya daha kötü durum uygulamaları denir. Benzer şekilde, gerçek yazılım geliştirme metodolojileri çözüm geliştirmede en iyi uygulamaları uygulamaya çalışırken, "Agile" (Scrum, XP, vb.) Gelişigüzel, kaotik bir lehine yazılım geliştirme sürecindeki her türlü yapıyı doğrudan ihlal etmeye çalışır. yaklaşım (geç), aynı zamanda (naif) izleyicilerden alkış talep ediyor gibi görünüyor.

Bununla birlikte, Çevik felsefenin ortaya çıktığı bağlamı akılda tutmak uygundur. O sırada sofistike yinelemeli metodolojiler (örn. Birleşik Süreç) mevcut olmasına rağmen, birincil metodoloji hala eski şelale yaklaşımıydı, bu da tam gereksinim analizinin "en iyi uygulaması", ardından tasarımı tamamladı, sonra çözümü geliştirdi / kodladı, sonra uyguladı çözüm. Açıkçası, yazılım geliştirmeye yönelik bu mühendislik yaklaşımı kötü tavsiye edilmiştir - ve yürütülebilir bir çözüm görmeden önce (ve bazen hiç olmadan) çok sayıda evrak işi ile sonuçlanmıştır.

Bununla birlikte, Agile'nin konjüratörlerinde olduğu gibi bebeğin banyo suyuyla atılmasını hala garanti etmemektedir. Agile yaklaşımı, belki de çözümün gerçek kodlaması dışında, ondan önce kullanılan her şeyin doğrudan bir şekilde reddedilmesini zorunlu kılar. Açıkçası, bu, yaratıcılarının parçası hakkında sınırlı bir içgörü göstergesidir veya belki de basitçe "görmek istemeyenler kadar kör biri yoktur" örneğidir.

Bununla birlikte, çevikliğin değeri, aerodinamik süreçleri teşvik etmesi ve yürütülebilir koda odaklanmasıdır - bu kaçınılmaz olarak nihai çıktınızdır.

ŞİMDİ, sorunuzu daha doğrudan cevaplamak için:

Ortamınıza genel bakışınız göz önüne alındığında, öncelikle bir Çevik uygulama (yani Scrum, XP, vb.) Seçmenizi öneririm. Ardından, ekibinizin nasıl çalışacağına ilişkin açık bir süreci belirleyerek ortamınıza uygun yaklaşımı özelleştirin, örneğin:

• Kullanıcı (lar) dan istek alma;

• Kullanıcı isteklerine öncelik verin;

• Geliştirmenin mevcut sistem üzerindeki etkisi (belki günlük / haftalık stand-up toplantılarınız sırasında);

• Her geliştirmenin geliştirme süresini tahmin edin ve bunları çeşitli talep eden kullanıcılara iletin;

• Mevcut sistemde gerçek iyileştirme (ler) i gerçekleştirin (örn. Kodlama).

• Kullanıcı testi yapın ve kullanıcılardan istenen değişikliklerin başarıyla uygulandığını taahhüt edin (örn. E-posta yoluyla).

Bu, bir çevik yaklaşımın bazı benzerliğini korurken, aynı zamanda bir yapı (ve düzen) sağlamalıdır.

Yukarıdakilerle birlikte, eski İngilizce konuşma figürü olan “Bir maymun gibi Çevik” in akılsızca üretilmediğini unutmayın!

Ben Çevik ise gibi bir metodoloji gerek söyleyebilirim temel Ekibiniz için. Şirketiniz çok dağınık olduğundan kendi geliştirme ekibinizde daha organize olmanız gerekir. Ancak teknik olmayan yöneticilerinizin bununla bir ilgisi olması gerektiğini düşünmüyorum.

Satış elemanlarınızı geri çekecek ve gerçekçi son tarihler talep edecekseniz, bunu organize planlarla gerekçelendirmeniz gerekir.

Ayrıca, teknik bir danışmadan tahminlerle size gelirlerse, ayrı bir notta, sadece boş noktayı reddedin.

Belki de artımlı / yinelemeli yönlere odaklanmak, hem ekibinizin hem de gökyüzünün düştüğü paydaşların düzenli ve tutarlı bir şekilde teslim edebilmeleri gereken şeydir. Zamanla, satış ekibi ve yönetim yeni bir özellik talebi sunduklarında ekibinizin uygun bir zaman diliminde teslim edeceğinden emin olabilirler.

Tabii ki, henüz orada değilseniz, oraya ulaşmak için birim / sistem / regresyon testine, otomatik yapılara, test sürümlerine vb. Yatırım yapmanız gerekir.

İlk önce bazı veri toplamayı öneririm. Sessiz bir zamanda oturun ve statükonun gerçekte ne olduğunu anlayın - işlerin nasıl yapıldığını. Eğer yönetim çevik diyebilecekleri bir şeyi uygulama konusunda ciddiyse, ekibiniz için işe yarayacak bir şey bul, bir belge hazırla, adına "Agile" tokatla ve gitmekte fayda var. Çevik hakkında gerçekten bildikleri tek şeyin kelime olduğunu ve İngilizce'deki olağan tanımı için çabukluk ile bazı belirsiz ilişkilerin olduğunu unutmayın. Yani benim savunduğum şey, ekibinizin konunun önüne geçmesi, sizin için çalışan bir lezzet bulması ve daha sonra bunu Agile (tm) yolu olarak yönetiminize sunmasıdır. Aksi takdirde, bazı PHB bir kitap alacak ve kare pimi yuvarlak deliğe yerleştirmeye çalışacak ve kimse mutlu olmayacak.

Eğer "saf" bir çevik form ile giderseniz, ekibinizin destek rolünü yerine getirmesi zor olabilir. Kabul edelim, patronunuz yardım masası taleplerine cevap veren ekibinizin üyelerini "bir biriktirme listesi oluşturmama izin verin, (sprint'in sonuna kadar) haftalarda alacağım" diyerek zor olabilir.

En büyük engel paradır. Her şey yeşil et suyu ise, bir şeyin yanlış olduğunu ve değişmesi gerektiğini söylemek çok daha zordur.

İyi şanslar.

Aksine, bana cevapsız teslim tarihleri, gerçekçi olmayan beklentiler ve kötü planlanmış projelerle başa çıkmak için tam olarak ihtiyacınız olan Çevik bir yöntem gibi geliyor.

Yönetiminiz bu yeni Buzz kelimesiyle ilgilendiklerini belirtti. Büyük olasılıkla, ürünlerinizin pazarlamasını hızlandırmak için kullanmak isteyeceklerdir. bu mutlaka kötü bir şey değildir, ancak bir Agile yönteminin sizin için çalışmasını istiyorsanız çok dikkatli bir şekilde yönetilmesi gerekecektir .

Savaşın yarısı yönetimden katılım sağlıyor. Onları Agile fikrine alıştırmak savaşın çoğudur. Gerisi, çevik olmanızı istemeye devam etmeleri için beklentilerinin yönetildiğinden emin olmak ve yöneticilerinizin proje yönetimi üzerindeki kontrolleri büyük ölçüde parmaklarının arasından kayıyormuş gibi hissettiklerinde ve hayal kırıklığına uğramamaktan kaçınmaktır.

Şirketiniz herhangi bir şeye karar vermeden önce, yarım günlük bir seminer ve atölye çalışması için bir Agile koçuna girmenizi tavsiye ederim. Hepinizin bir takım olarak düşünmesini sağlayın - hem yöneticiler hem de geliştiriciler - Agile'ın sizin için çalışacağını ve hissetmeyeceğiniz şeyin ne olduğunu düşünün. Öte yandan yönetim kararınıza güveniyorsa, bir dizi Çevik uygulama ve Yönteme aşina olmanız ve bir seminer ya da kendi seminerinizi oluşturmanız gerekir. Şahsen, çok fazla zaman kaybetmemek ve momentumu korumak için deneyimli bir koç almaya yönelirim. Bu arada, birkaç iyi Agile kitabının bir kopyasını referans olarak alın, iyice okuyun, ancak yönetiminizin görebileceği masanızın etrafında asılı bırakın. Bilinçaltı psikolojisi, tanımladığınız gibi bir durumda harikalar yaratabilir.

En azından aşağıdakileri okumak için tavsiye ederim:

• Yalın Yazılım Geliştirme - Mary & Tom Poppendieck
• Çevik Yazılım Geliştirme - Robert C. Martin

ve ekstra kredi için (çünkü bahsettiğim diğer kitaplar için harika bir arkadaş olduğunu düşünüyorum):

• Temizlik Kodu - Robert C. Martin