Çevik yazılım geliştirme: Değişen kullanıcı gereksinimlerine * finansal * nasıl tepki veriyorsunuz?

SE ve diğer sitelerdeki tüm bu "çevik gelişim" şeylerini okurken hep merak ettiğim bir şey var:

"Geleneksel" yazılım mühendisliğinde,

1. kullanıcının gereksinimlerini toplamak,
2. bu gereksinimlere dayalı bir şartname yazabilir,
3. müşteriye verin ve şimdiye kadar yapılan işler için faturalandırın,
4. uygulama maliyetini tahmin edebilmeniz için (kaba) bir teknik tasarım yapın,
5. kullanıcıya uygulama için bir fiyat teklifi verin,
6. müşterinin spesifikasyonu imzalamasını ve teklifi kabul etmesini bekleyin,
7. tasarım, uygulama, test,
8. Bill.

İşlem sırasında gereksinimler değişirse, istenen değişiklikler için bir teklif (fiyatla) gönderirseniz (veya değişiklik küçükse ücretsiz olarak yaparsanız, müşteriyi beğenirsiniz ve müşteri bunu çok sık yapmaz) .

Peki, bu, sık sık ihtiyaç duyulan değişikliklerin sürecin bir parçası olduğu çevik bir projede (finansal olarak) nasıl çalışır?

• Her tasarım değişikliği için bir teklif yazıyor musunuz? (Bu oldukça dağınık olmaz mı?)
• Yoksa sabit bir fiyat üzerinde pazarlık yapıyor ve müşterinin gereksinimleri çok sık değiştirmemesini mi umuyorsunuz ? (Riskli olabilir, bu fırsatı projenin tamamlandığını kabul etmeden önce yıllarca yeni özellikler istemek için kullanacaklarını biliyorum.)
• Yoksa yalnızca gereken toplam süre için müşteriye fatura mı veriyorsunuz? (Maliyeti önceden bilmeyen müşteri için riskli olabilir.)

İdeal bir Agile dünyasında, önceden bir fiyat ve birkaç saat kabul edersiniz, ancak kapsam değil . Müşteri, istediği üründen ziyade asgari faydalı ürünün ne olduğuna karar verir ve bu, üzerinde anlaşılan sürenin çok kısa bir süre içinde tahmin edilmelidir .

Sonra onlara yinelemeli olarak teslim edersiniz ve zihinlerini istedikleri kadar değiştirirler, ancak asla kararlaştırılan saatlerin üzerinden geçemezsiniz. Teoride ve çoğu zaman pratikte, gerçekten istedikleri üründen ziyade gerçekten ihtiyaç duydukları ürünle sonuçlanırlar.

Ve kabul edilen orijinal değerden sonra size fazladan saatlerce ödeme yapmaya devam etmek istiyorlarsa, bu da iyidir. İlerleme görünür hale getirmek için yeterince iyi bir iş çıkarırsanız, hikaye kartları, Greenhopper veya başka bir şeyle, müşteriye her yeni şey eklediklerinde hangi özellikleri kaybettiklerini (veya en azından depisitize ettiklerini) çok açık hale getirebilirsiniz. anlamsız değişikliklerin durması.

Burada kayda değer iki risk var. Birincisi, çevikliği önceden anlamadıysa, müşteri korkabilir. Tüm riski alıyor gibi görünüyor. Sadece deneyim, gerçekten olmadığını gösterir.

İkinci onlar olmasıdır gerekir tüm süreç boyunca, meşgul olmak, ya da herkes kaybedecektir. Birçok müşteri çok geç olana kadar ne kadar meşgul olmaları gerektiğini anlamıyor.

Ama eğer bir şirket olarak, bunu yeterince iyi açıklarsanız, herkes kazanır.

Bazı insanlar teşebbüs etmek vermek geçmişte sabit fiyat projelerinde Agility kullanmak çözümler. Şahsen bunun genellikle mümkün olmadığını düşünüyorum.

Scrum özellikle ürün yazılım şirketleri için uygundur ve hizmet şirketlerinde daha az kullanılır.

Projelerinizde yineleme, günlük stand-up, burndorn vb.Gibi çeviklik kullanabilirsiniz, ancak belirli bir fiyat için belirli bir miktar şey teklif ederseniz ve sözleşmedekinden daha azını teslim ederseniz, bir sorununuz olacak.

Lütfen Agility à toutes les sauces hizmet etmeyin . Belirli bir probleme uygun çözümü kullanmalıyız.

Bu gerçekten Çevik programlama veya kullandığınız herhangi bir model ile ilgili değildir. Serbest çalışan olarak Şelale ve V-modelinin bir karışımını kullanıyorum, ancak yine de aynı problemi yaşıyorum: müşteri ayrıntılı tasarım sırasında bir şeyi değiştirmek isterse ne olur? Uygulama sırasında değişiklik yaparsa ne olur?

Kullanmanız gereken yaklaşım müşteriye ve ilişkilerinize bağlıdır.

Bir kişi bu müşteri için yaptığınız her şey için bir zorunluluksa, çünkü mümkün olduğunda ödeme yapmamaya çalıştığını biliyorsunuz veya mümkün olduğunda size dava açmaya çalışacaksa, evet, her biri için bir teklif yazmalısınız gereksinimlerde küçük bir değişiklik. Bu bir karışıklık değil: iyi organize olursanız, geliştirme sırasında yeni bir gereksinimi karşılamak çok zor olmayabilir. Ama elbette, zaman ve para kaybı ve uygulamak için iki saat sürecek bir değişiklik için bir teklif imzalamak oldukça garip.

Diğer müşteriler için, iyi çalışan yaklaşım şöyledir:

• İlk teklifi imzalarken tahmini maliyeti ve maksimum maliyeti belirtin. Tahmini maliyet yasal olarak hiçbir şey ifade etmez: bu sadece bir tahmindir. Maksimum maliyetin yasal değeri vardır: Ürünün müşterinize 3.000 ABD dolarına mal olacağını ve sonunda size 3.157.24 ABD dolarına mal olacağını söylüyorsanız, müşteri yine de 3.000 ABD doları ödemek zorundadır. Uygulamada, çoğu durumda, gerçek maliyet verilen maksimum değerden daha az ve tahmininize daha yakın olacaktır.

• Müşteri bir gereksinimi değiştirmeyi istediğinde sahip olduğu maliyeti tahmin edin ve gerçek maliyet ve durumla karşılaştırın. Ürünü neredeyse bitirdiyseniz ve gerçek maliyet 2.108.36 $ ve değişikliğin maliyeti 150 $ olarak tahmin edildiyse, yapın. Öte yandan, maksimuma ulaşma riski varsa, müşterinize toplam maliyeti birlikte değerlendirmeniz gerektiğini söyleyin.

Çevik ve 'Bir teklif yaz' bir antitez gibi görünüyor :) - ikincisi üretken yazılım mühendisliği değil: D

Tamam, şimdi şaka yolumuzdan çıktı - gerçek olana geri dönelim.

" Agile'da nasıl çalışır ?" - sözleşme işleri zorlaştırıyor ama umarım açıklığa kavuşturmayı umuyorum. Agile, 'güven' ve 'birlikte çalışma' prensibine dayanır, bu da müşterinin ne olursa olsun değişmesine izin verildiği anlamına gelir ve biraz daha pahalıya mal olabileceğini veya müdahaleci değilse, belki de ekstra bir maliyet olmadan anlayabileceği anlamına gelir.

Ne anlama geliyor? Bu, sözleşmenin (müşteri) maliyetin ilk tahminini ve% 100 varyansı% 100.000 teklifle başa çıkabileceğimizi tespit ettiğimizi belirtiyor, ancak 120 bin dolara kadar çıkmaya hazırım (bu olabilir sözleşmenin bir parçası, ancak müşterinin aklında).

Şimdi, bir tasarım değişikliği geldiğinde, tahmin etme ve planlama ile çevikleşin - ekibinizi bir araya getirin ve onlara 'hikaye noktası' değişikliklerin çarpanının karmaşıklığını tahmin etmesini isteyin. Bazı hız tahminleri sayesinde, bunları çoğaltabilir ve bir program tahmini verebilirsiniz. Ekibi ve göreceli maaşlarını biliyorsanız, hikaye noktası başına maliyeti düşürmek nispeten kolay olmalıdır (lütfen HERKES'in maaşını ortalamayın, ortalamaların kusuruna boyun eğeceksiniz).

Finans ile müşteriye geri dönmeniz mi gerekiyor? HAYIR. Şart değil. Müşterinin bunlara öncelik vermesini ve biriktirme listesinde doğru yere yerleştirmesini sağlayabilirsiniz. Artık birikmiş işin büyüklüğünü (daha önce yapmadıysanız yapmalısınız) biliyorsunuz ve mali tablolara (hikaye noktası başına maliyet) göre, hangi düşük öncelikli gereksinimlerin belirtilen bütçe ile yapılamayabileceğini biliyorsunuz . $$ sözleşmesine göre yapılabilecek özelliklerin tahmini ile onları önceden belirlenmiş birikmiş işler GÖSTER. O zaman onlar / onlar oraya / zaman daha fazla almak için daha fazla ödemek isteyip istemediklerine karar verelim. Eğer ücretsiz istiyorlarsa ... bir tavır alıp onlara daha pahalıya mal olacağını söyleyin.

Bu grafiği, müşterinin görmesi için bir yere götürebilirseniz, sürekli olarak finansal geri dönmeden yardımcı olacaktır.

Bu yardımcı olur umarım!

Diğer insanların deneyimleri muhtemelen değişecektir, ancak yapıldığını gördüğüm bir yol, dikkat etmeniz gereken birkaç şeyle "geleneksel" inizle büyük ölçüde aynıdır:

1. Değişiklikler için bazı ek yükler oluşturun (örneğin,% 10)
2. Büyük değişikliklerin veya toplam maliyetin ötesinde toplu ve fatura değişikliklerinin değerlendirilmesi ve ayrı ayrı faturalandırılması (iyi, programlama olmasa da iyi bir örnek, örneğin ilk maliyetin 3 revizyon ve sonraki revizyonlar veya belki de toplam tekrarların olduğu tasarım çalışmasıdır. ekstra)

Genellikle, çevik projeler "çekirdek" bir öğe olarak başlar ve gerektiğinde modüler bir şekilde oradan dışarı çıkar (bunun biraz dahil olduğum projelerde olduğunu gördüm). Yani, temel bir ürünle başlıyorsunuz, diyelim ki bu bir harita uygulaması. İlk uygulama yalnızca bulunduğunuz konumu (müşterinin başlangıçta sipariş ettiklerini) merkez alan bir haritadır.

Müşteri daha sonra çevrenizdeki belirli turistik yerlerin pim damlalarını almak istediğine karar verir. Tamam, bu oldukça büyük bir parça (nispeten konuşma), bu yüzden yeni bir "modül" veya satın alma emri olarak faturalandırıyorsunuz. Bu pimlerin rengi veya tasarımı gibi şeylerde yapılan değişiklikler bu siparişin maliyetine dahil edilir. Yol tarifleri ve kaplamalar başka bir satınalma siparişidir, çünkü diğer satınalma siparişi devam edene kadar talep edilmemiştir ve bu böyle devam eder.