Çevik müşteri katılımı olmadan başarılabilir mi?

Çevik hakkında bir kitap yazamam. Kendilerine Çevik diyen birçok mağazada çalıştım. Çevik gelişimin ana noktalarından biri düzenli müşteri katılımıdır. Bir sprint sonrası, çalışma geri bildirimlerini almak için müşteriye demonte edilebilir. Durulayın ve tekrarlayın.

Karşılaştığım sorun, birçok müşterinin dahil olmak istememesi. Şelale yaklaşımını tercih ederlerdi. Gereksinimleri önceden toplayın, sonra işiniz bittiğinde geri gelin. Benim tecrübeme göre, şelale çalışmıyor. Müşteriler görene kadar ne istediklerini bilmiyorlar. Şelale ikilemi, tüm gereksinimleri ön plana çıkarmak isteyen geniş bir geliştirici topluluğu tarafından daha da yayılmaktadır. Bu şekilde ne inşa ettiklerini biliyorlar, buna göre mimarlık yapıyorlar ve müşteri söz konusu gereklilikleri "imzaladı "ları için suçluyor.

Yanlış mıyım? Çevik müşteri katılımı olmadan çalışabilir mi? Öyleyse, tartıştığım sorunları nasıl ve nasıl aşarsınız?

Nasıl olabilir? Tekniğin doğası, müşteri ile geliştirici arasında bir tür geri bildirim döngüsü gerektirir.

Bununla birlikte, ekibinizin bazı kısımları "vekil" müşteriler ("kendi köpek yemeğinizi yemeye benzer bir işlem" gibi) davranabilir, böylece gerçek müşteri elde etmek kadar tatmin edici olmamasına rağmen, çevik gibi davranma "gibi davranabilirsiniz" geri bildirim.

Beğenin ya da beğenmeyin, müşteri tasarım sürecine dahil olacak; bu sadece yeniden çalışmanın maliyetini ne kadar istedikleriyle ilgilidir (ne kadar uzun gecikirse, o kadar pahalı olur).

Müşteri "Büyük Tasarım Ön Cephesi" istediğinden, tasarımı ilk kez doğru yapmaları için daha fazla zaman ve çaba harcayacaklarını anlamalarına yardımcı olur.

Sorunuza kısa cevap 'hayır'. İşte sorunuzun bazı bölümleriyle ilgili yorumlar. Doğru olmak için cevapların çoğu kişisel deneyimime ve gözlemime dayanıyor.

Benim tecrübeme göre, şelale çalışmıyor.

Şelale, değişken karmaşıklıktaki sistemleri sağlamak için sağlam bir metodolojidir. Bunun iyi bir şekilde sunulmaması veya anlaşılmaması talihsiz bir durumdur. Bunun bir nedeni de, günümüzde ortaya çıkan metodolojiyle rekabet edebilecek kadar para kazanmamasıdır. Bankacılık, sigorta ve üretim sistemlerinin çoğunun yalnızca Waterfall yaklaşımı kullanılarak oluşturulduğunu ve birçoğunun bugün hala üretimde olduğunu bilmek sizi şaşırtabilir. Yazılım endüstrisinin bilimden çok yutturmacaya dayanması üzücü.

Müşteriler görene kadar ne istediklerini bilmiyorlar.

Bu bir efsanedir. Çok büyük bir tane. Bu, web sayfası tasarımında / düzeninde olabilir, ancak iş verilerinin işlenmesi için çoğu kullanıcı çalışan bir şey ister. Bu kullanıcıların bazıları hala AS / 400 ekranları ve RGB'li 3270 CICS monitörlerini kullanıyor ve işlerini bu araçlarla yapabiliyorlar. Ayrıca, aynı kullanıcılar, arabirimin tasarımında (ve işlevsellikte bazen) herhangi bir şey söylemeden SAP ve ORACLE ERP sistemlerini kabul eder. Çoğu işletme kullanıcısı, sistem doğru işlevi üretiyorsa çalışma alışkanlıklarını ve akışlarını bile adapte eder. Buradaki stres açık değildir, fonksiyon görünmez. İş adamları işlerini nasıl iyi yaptıklarını anlıyorlar% 90.

Şelale ikilemi, tüm gereksinimleri ön plana çıkarmak isteyen geniş bir geliştirici topluluğu tarafından daha da yayılmaktadır. Bu şekilde ne inşa ettiklerini biliyorlar, buna göre mimarlık yapıyorlar ve müşteri söz konusu gereklilikleri "imzaladı "ları için suçluyor.

Geliştiricileri ne inşa ettiklerini bilmek istedikleri için suçlayamazsınız, çünkü bu geliştiriciler eve bir akşam yemeği pişirmek ve bir sonraki tatbikatı öğrenmek için 3 saat harcadıktan sonra başka bir tatbikat için gömleklerini bastırmak ister. Bu onların mevcut yetenek setinin yerini alacak! Suçlama oyunu kimseyi kazanan yapmaz. Her bir tarafın rollerini ve sorumluluklarını düşünün ve görüntü çok net olacaktır.

Sonuç olarak, Proje yöneticileri, Programcılar ve Web Tasarımcıları, metodolojiden bağımsız olarak son kullanıcılardan nasıl gereksinim almaları gerektiğini bilmesi gereken İş Analistlerinin yerine geçmez.

Zaman ayırmak istemiyorlar ve eğer bir seçenek verilirse ücretsiz yazılım almak istiyorlar, ama yine de onları ücretlendireceksin, değil mi? Şirketiniz için dahili olarak yazılım geliştiriyorsanız, bu bulanıklaşır. Bilgi İşlem Departmanının (maaşlı çalışanlar) satın alındığını ve ödendiğini düşünüyorlar, bu yüzden ellerinden geldiğince çok çalışabiliyorlar.

Potansiyel olarak çevik olabilirsiniz. Tüm özellikleri alın ve kodlamaya başlayın. Müşteri işi bir kenara bıraktığından, sadece bir şey düşündükleri ve değişiklikler ve düzeltmeler yapmanız gerektiğinden, biraz daha çevik oldunuz. Onayları ekibinizde de yapabilirsiniz. Ekibinizden birinin bir takım elbise giymesini sağlayın ve müşteri gibi davranın.

Önünde büyük bir zaman taahhüdü yapmak onları korkutabilir. Denemek için bir sprint yapmayı önerin. Öyleyse onlara dışarı çıkma şansı ver. Projenin geri kalanı için her zaman bir şelaleye geçebilirsiniz. Ayrıca ekibindeki farklı kişilerin incelemeyi yapabileceklerini ve zamanın kontrolü yazan kişi için bir kısıtlama olup olmadığını onaylayabileceklerini de önerin.

Bir noktada, onlara şelalenin işe yarayacağını düşünmediğini söylemelisin. Onlara bu yaklaşımdan memnun olup olmadıklarını sorun ve eğer öyleyse, neden bu projeyi yapan son erkeklere sahip değiller?

Hiçbir metodoloji müşterinin katılımı olmadan çalışamaz. İhtiyaçlara imza atmak katıldığım projelere şahit olduğum için anlamsız olabilir. Sorununuz Çevik yapmanın ötesine geçiyor, müşterinizi eğitmeniz ve katılımlarının ne kadar önemli olduğunu anladığından emin olmanız gerekiyor.

Agile'nin temel faydalarından birinin, genel olarak her özellik için daha ayrıntılı gereksinimler elde etme yeteneği olduğunu düşünüyorum. Müşteri tüm gereksinimlerini açıkca verdiğinde, her özellik tanımlanmış bir işlevsellik ile belirsiz bir fikir olma eğilimindedir. Çevik kuvvet istemci her bir özelliği tekrar ve odaklanma tam özellik büyük resmin içine sığacak ne istediklerini ve nasıl. Spesifikasyona aynı miktarda detayı (özellikleri uygulamak için yeterli detay) sahip olmak için, şelale gerçekten iki şeyden birini yapmanı gerektirir:

1. Tahmin. Belirsiz bir şeye rastlamadan önce uygulayın, sonra özelliğin en iyi nasıl uygulanacağını düşündüğünüze karar verin. Bu kesinlikle ideal değil, çünkü "Bekle, istediğim şey bu değildi!" senaryo.

2. Tasarım konusunda çok daha fazla durmaya özen gösterin. Temel olarak, müşteri yarı pişmiş özelliklerini ilk gün size attığında, bir şey uygulamadan önce her dakika detayını gözden geçirmeyi planlayın. Netleştirmek müşteri sor herşeyi size tüm proje boyunca her uygulama detay biliyorum noktaya reklam nauseum. Mükemmel olmasa da, bu seçenek 1'den daha iyidir. Yine de beklemeyeceğiniz ayrıntılarla karşılaşabilirsiniz ve hatta tepelerde çalışan müşteriyi bile gönderebilir, ancak gerçekten geliştirme ve iletişim sırasında iletişimde olmak istemiyorlarsa psişik değil, bu bir zorunluluktur. Bu temelde şelaledir ve uygun şekilde yürütülmesi son derece zor olmak da dahil olmak üzere tüm ilişkili olumsuz taraflarla birlikte gelir.

3. Yarı pişmiş spec alın, ancak yine de giderken açıklama isteyin. Spesifikliğin belirsiz bir bölümüne ulaşana kadar çalışın, ardından müşteriden açıklamasını isteyin. Tabii ki, müşterinin istediği şey bu değil, ancak şartname kadar bulanık bir uygulama istemiyorlarsa ve şartnameyi tanımlamayı reddediyorlarsa, kalan seçenek budur. Çevik'in tüm faydalarına sahip değildir (örneğin herkesin aynı sayfada olduğundan emin olmak için düzenli müşteri onayı gibi), ancak geliştirmeniz gereken bilgileri almanıza izin verir. Seçenek 1 muhtemelen sizi bir alt ürün ile birlikte bırakacağından, seçenek 2 boşa harcanır ve müşteriye sinir bozucudur (tamamen önden yaparsanız genel olarak tasarım ve teknik özellik toplama için en az iki kat daha fazla zaman harcamanız gerekecektir), bu gerçekten kötü bir seçenek değil. Buradaki anahtar, ortaya çıkan her değişiklikle zaman çizgilerini ve fiyatını değiştirmekte gayretli olmaktır. Doğru yaparsanız, Çevik uygulamaların çoğunluğunun, müşteri bilmese bile, bu düzenlemeyle uyumlu olduğunu görebilirsiniz. IMHO, bu gerçekten metodolojileri kendi düzeninize uyarlamanız gerektiği için Çevik'in ruhuna uyuyor.

Eğer müşteri bu üç seçenekten herhangi birinin ya da tamamen gelişmiş Çevikliğin sonuçlarıyla yaşayamazsa, bu müşterinin gerçekte ne kadar zaman alacağınızı hayal etmekte zorlanıyorum.

Bence zor ama yine de mümkün. Bence Robert’ın proxy fikri işe yarıyor ama proxy’nin client gerçek ’müşteri ile mümkün olduğu kadar fazla zaman harcaması gerekiyor. Bu şekilde, proxy hangi özelliklerin gerçekten önemli olduğunu belirleyebilir ve müşterinin beklediği / arzu ettiği kullanıcı deneyimi için bir fikir edinebilir.

Ancak bir noktada yazılımı 'gerçek' müşteriye göstermeniz gerekecek ...

Gerçek müşterilerden kaçınmak mümkündür, hatta bazen düzenleme için gerekli olabilir. Genellikle tıbbi yazılımın müşterileri dahil değildir. Bu gibi durumlarda, diğer kuruluşlar müşteri rolünün yerine geçebilir, örneğin pazarlama ekibi müşteriler olarak kabul edilebilir.

Agile, Hard - Oldukça zor olan büyük ön tasarımın yerini almak için sıkı bir döngüye ihtiyaç duyuyor, ancak aslında yapılabilir, çevik tek yöntem değil.

Agile'nin modifikasyonlarından birini bulmak isteyebilirsiniz - birçoğu ve muhtemelen bu özel sorunu ele alır, ancak eğer kendiniz telafi edemezseniz, kendiniz telafi edersiniz.

Tüm bu işlemler akıllı insanlar tarafından yapılmıştır - ve akıllı insanlar herhangi bir işlemi yapabilir. Şelalenin icat edildiğini düşünmüyorsunuz, çünkü hiç kimse için işe yaramadı, değil mi? Gelişmiştir, çünkü bazı insanlar çalışmasını sağlayabilir ve diğerleri baktı ve "bunu düzeltmek ve etkili bir şekilde üretilemeyecek gibi görünen benim takımımı beslemek zorundayım" dediler - bu noktada muhtemelen onlardan daha iyi çalıştı fakat her programcının her sorunu çözemediğini farketmezseniz, aynı işlemi kullanan iki ekibin neden farklı sonuçlar doğurabileceğinin farkında olabilirsiniz.

Sorun, birçok sürecin bunları uygulamak için yetenek gerektirmesidir - yeteneklerini konuşuyoruz - hiç spor yapan herkesin havuzundan profesyonel sporcular kadar nadir bahsediyoruz. şelale gibi berbat süreçler işe yarıyor ve bu yüzden pek çok insan başarılı olamayacağını düşünüyor - bunun işe yaradığını hiç görmediler.

Agile'nin çalışması için çok daha az yetenek gerekir, ancak müşterinin sürekli olarak ne yaptığını görmesini sağlamak, böylece hataların yayılmasını engellemek ve acımasız yeniden yapılanma gibi şeyler oluşturmak için çok özel yatırımlar gerektirir takımın birkaç ay sonra çözemediği bir teknik borç.

Müşteriyi tanımla.

Başka bir şirket mi? Başka bir birey mi?

Şirketinizde başka bir ekip var mı?

Şirketinizde bir ürün şampiyonu mu?

O sen misin?

Yukarıdakilerin hepsi mümkün ve şartlara bağlı olarak oldukça makul. Tünelden Çevik'in ne olduğu hakkında tek bir bakış atmak istemezsiniz, bu yüzden kesin bir NO demek yanlış olur. Öte yandan, EVET biraz yanal düşünmeyi gerektirir.

Bir an için Agile kelimesini düşünün . Bu terimi oluşturan çok zeki insanlar grubu, tarif etmeye çalıştıkları kavram için daha iyi bir metafor bulamazlardı. Çeviklik derken aklınıza ne geliyor? Ayak filosu olmak? Belki de hızlı tepki veriyor musun? Uyum sağlamak için hızlı?

Şimdi oraya yaygın olarak kabul edilen Çevik uygulamalarının tüm düşün ve onlar gerçekten olarak kabul edilir yazılım geliştirme yöntemlerine getirmek kendinize sorun Çevik .

Kişisel projelerim için tüm amaç ve amaçların müşterisiyim. Müşteri rolümde belirgin bir zihinsel değişiklik yapmak istediğimde bazen gerçek bir şapka bile takarım . Bu, beni işteyken olduğumdan daha az çevik yapmıyor. Tek umursadığım gibi, kedim müdür olabilir. Arada bir dinlenmeye ara vermemi sağlıyor ve herhangi bir tek göreve takıntılı olmaktan kaçınmamı hatırlatıyor. Fantezi "Pomadoro Tekniği" ni kullanmayı tercih edebilirsin ama ben "Rascal" Zamanlayıcı'yı tercih ediyorum !! Mesele şu ki, kendim için kod yazdığımda kesinlikle Çevik bir süreçte çalışıyorum. Ben sonsuz gelişme sivri ve hiçbir şey yapmadan bir hayat yaşayan hacker-gel-kovboy türü değilim. Yazılımımı oluşturmayı, iş hayatım ve kişisel yaşamımla ilgili gelişimi planlamayı ve gerçek bir müşteri için çalışıyor olsaydım, beklediğim şekilde tamamlamayı seviyorum. İşler programımı kesintiye uğrattığında, proje çalışmamı buna göre değiştirir ve önceliklendiririm. Solo uygulayabildiğim tüm standart Agile uygulama ve tekniklerini kullanıyorum ve “sunuyorum” çalışma kodunu kendime (veya test etmek için bir arkadaşıma veya meslektaşıma) mümkün olduğunca sık. Bütün bunlar Çevik değilse, size ne olduğunu soruyorum?

Yani cevabım Evet , Çevik Yazılım Geliştirici olabilirsiniz ve Çevik bir metodoloji uygulayabilirsiniz ve mutlaka müşteriye, hatta yöneticiye ihtiyaç duymazsınız. Tek başına bir proje üzerinde çalışabilir ve birden fazla şapka takabilirsiniz. Bununla birlikte, bu amaçlara ulaşmak için başkalarıyla işbirliği yapmak çok yararlı olduğu için, bu diğer rollerle uğraşmak İdeal olmayabilir . Fikirleriniz için sağlam bir yönetim kurulu görevi görüyorlar ve kendi başınıza mantıklı bir şekilde üretmeyi zor bulmanızın gereklerini yerine getiriyorlar. Müşteri ve yöneticinin tatmin edici diğer önemli rolü, hiç durmadan özellikler eklemeden ve kodunuzu kesinlikle gerekli olabileceklerin ötesinde rafine etmeden, hedeflerinize odaklanmanızı sağlamaktır.

Yine de, disiplinli bir şekilde çalışıyorsanız, tercih ettiğiniz metodolojiye sıkı sıkıya bağlı kalıyorsanız ve Çevik uygulamalar uygularsanız ve yandan takip edildiğinde veya fikrinizi değiştirirseniz (müşteri şapkasını takarken) ve ürün tasarımınızı veya yönünüzü değiştirirseniz zamanlamanızı uyarlayabilir ve önceliklerinizi tıpkı müşterinizin sizden bekleyeceğini düşündüğünüz gibi ayarlayabiliyorsanız, o zaman çevik olursunuz.