Çevik yazılım geliştirme, bir sözleşme ile tanımlanan projelerde kullanılabilir mi?

14

Kısa bir süre önce Agile Software Development hakkında bir geliştirici ile görüştüm. İlkeyi anlasam da, sürekli değişen gereksinimler projenin sonsuza dek sürmesi için potansiyel yaratmaktadır. Ama en azından çalıştığım yerde projelerin tamamlanması gerekiyor çünkü bu bir sözleşme.

Yani, ilk yineleme aylar alabilir, çünkü bazı projeler için müşteri eksik bir uygulamayı kullanamaz. Bazı projeler için, önce bitmiş olarak tanımlamanız gerektiğini düşünüyorum, daha sonra onu yinelemelere bölebilir ve her yinelemeden sonra tanımınızı hassaslaştırabilirsiniz. Ama her zaman bu tanıma sahip olmalısınız .

Çevik Yazılım Geliştirme değişen gereksinimleri benimserse, nerede bittiğini nasıl anlarsınız? Sonuç her zaman değiştiğinde bir proje için nasıl bütçe oluşturabilirsiniz?

Çevik Yazılım Geliştirme, çevik bir üründen ziyade çevik bir süreç hakkında mı?

agile

— Verax
kaynak

etrafında dolaşmak yerine, gerçekten işe yarayan bir şey teslim etmeniz gerektiğinde sona erer. Bu noktada, yapıyı, planlamayı, gereksinimleri ve son tarihleri belirlemeye ve etrafta dolanmak yerine çalışmaya başlamalısınız.

— jwenting

Her çevik yineleme, müşterinin kullanabileceği ve daha fazla bilgi edinebileceği çalışan, teslim edilebilir bir ürünle sonuçlanır. Bu, genellikle başlangıçta planlanandan daha erken olan tatmin olana kadar devam eder. Bu, ürünün her zaman çalışmasını garanti eder ve yazılımın asla bitmediğini, aksine sonsuza kadar evrildiğini veya öldüğünü dikkate alır. Sadece ürünün yeterince iyi olduğunu düşündüğünüz bir zaman seçin ve orada durun (şimdilik).

— Martin Wickman

@Martin Wickman: Bunu anlıyorum, ama "müşterinin kullanabileceği teslim edilebilir bir ürün" buradaki sorun. Bu durumda, ilk yineleme aylar alabilir, çünkü bazı projeler için müşteri eksik bir uygulamayı kullanamaz. Bazı projeler için, önce bitmiş olarak tanımlamanız gerektiğini düşünüyorum, daha sonra onu yinelemelere bölebilir ve her yinelemeden sonra tanımınızı hassaslaştırabilirsiniz. Ama HER ZAMAN bu tanıma sahip olmalısınız.

— Verax

@Verax: Çevik manifesto, değişiklikleri yönetmek için oluşturuldu. Projenizde değişiklik yoksa, çevik sizin için değildir. Hikayenin sonu.

— Martin Wickman

2

@Verax: Sorunuzu netleştirmeli ve daha fazla bağlam eklemelisiniz. Yorumlarınız soruda daha fazlası olduğunu gösteriyor. Bu aynı zamanda cevaba verilen oy sayısında ve kabul edilen cevabın asıl soru metniyle ilgisiz olduğu açıktır (ve hatta "OP yorumlarından ..." der).

— Martin Wickman

7

OP'nin Yorumlarından, benim gibi müşterilerimize geliştirme hizmetleri sunduğumuz bir Danışmanlık mağazasında çalıştığı anlaşılıyor ... Bence çünkü kafa karışıklığına neden olan bu zihin çerçevesinde ... iyi bilinen ama asla ifade edilmeyen bir gerçeği ifade eder.

Agile, bir sözleşme ile tanımlanan yazılım geliştirme ile uyumsuzdur.

Sözleşmeler Zor Olmalı, X Yapıyoruz Y Yapıyoruz. X + M İsterseniz Bize Ödeyin Y + (M * N)
Sözleşmeler tatmin edilebilir OLMALIDIR, (IE açık uçlu değildir) aksi takdirde yasal temas değildir. (Bir kişi söz konusu olduğunda, katı bir değişiklik kontrol sürecine girmelisiniz.)

Birçok Danışman dükkan Agile'a yalan söylüyor. Sadece diyorlar çünkü Agile Buzz kelime statüsünü elde etti.

Agile, programcıların tam zamanlı olduğu ve bütçelerden çok az sözedildiği iç gelişim için en iyi sonucu verir. Sadece Zaman Çerçeveleri ve Özellikleri.

— Salaklar
kaynak

Bununla ilgili daha fazla bilgi edindikçe aynı sonuca geliyorum. Son cümleniz kesinlikle doğru gibi görünüyor. Eskiden hükümet için çalışıyordum ve müşterim çalıştığım ajanstı ve programları kullanan çalışanlar olduğu sürece yıllarca ve yıllarca sürdürülüyordu. Orada çalışırken çevik görebilirsiniz. Şimdi gömülü sistemler geliştiriyorum. Proje, makine çalıştığında (ya hep ya hiç) sona erer. Makine kısmen çalışıyorsa, satılamaz - proje başarısız oldu.

— Verax

2

Aslında birkaç yıl önce çalıştığım bir danışmanlık dükkanında, çevik bir yapışkan tarafından yazılmış ve çevikliğin sabit bir fiyat hizmeti modeline nasıl takılabileceğini anlatan bir makalesi vardı.

— mcottle

2

Bu cevaba katılmıyorum. Bunun nedeni, açık uçlu olmayan bir sözleşmeniz varsa, kapsam sürünmesini (neredeyse her zaman olur) yönetmek istemediğiniz anlamına gelir. Görmek için kullandığım sözleşmeler şöyle başlıyor: X ödüyorsunuz, Y yapıyoruz. Daha sonra herhangi bir kapsam değişikliğinin ekstra bir fiyatla geldiğini belirten bir maddeye sahipler. Notifyng kapsam sürünmesi hakkında çok erken olduğunuz sürece (ekstra kaynaklar ve zaman gerektirir), önceki müşteriler değişikliklere tepki verebilir (üst yönetimden onaylar ve bütçe almak vb.). Sonra yönetim sürecinin kendisi çevik hale gelir.

— Spoike

Sözleşme, ürünün (bitmiş yazılım) aksine hizmet (kod yazımı) içinse, bu uyumsuzdur. Agile, hangi bütçenin altında ne yapılacağını tahmin etmeyi sağlar, eğer bir gereksinim değişirse, bütçe de değişmelidir. Başka bir özellik ister misin? 500 adam-saat daha sözleşme yapmalısınız. Özellik sürünme aynı zamanda fiyat sürünme, geliştiriciler için tamamen tatmin edici ve müşteri ödemeye istekliyse, bunu kim sorgulayacağız?

— SF.

2

Orada çevik sözleşmeler çok açıktır ki bu cevap tanımı gereği yanlıştır.

— Martin Wickman

20

İlk olarak en önemli şeyleri yapmaya (inandığınız şey) odaklanıyorsanız, proje şu durumlarda biter:

Bütçettiğin parayı harcadın.
Bütçelediğiniz süreyi geçtiniz.
Artık hiçbir şey eklemek veya değiştirmek istemiyorsunuz.
En yüksek öncelikli değişikliklerinizin bir sonraki partisi, maliyete değmeyecektir.

— Dale Emery
kaynak

5

1. Artık para yok - Müşteri tüm paralarını eksik yararsız bir ürüne harcadı. 2. Daha fazla zaman yok - Müşteri hala eksik bir işe yaramaz ürüne sahip. 3. Eklenecek bir şey yok - Evet doğru! 4. Buna değmez - Müşteri sadece projeden vazgeçti. --- Neyi kaçırıyorum? Bu benim için bir anlam ifade etmiyor.

— Verax

7

1 ve 2 için: Önce en önemli şeyleri yaparsanız, o zaman paranız bittiğinde, para için alabileceğiniz en önemli şeylere sahip olursunuz. Zaman için benzer. Kabul ediyorum 3 nadirdir. 4 için: Durmak mutlaka müşterinin vazgeçtiği anlamına gelmez. Bundan istedikleri en önemli şeylere sahip oldukları anlamına gelebilir ve şimdi paralarıyla başka şeyler yapmayı tercih ederler. Diğer projeleri ne zaman bitireceğinize nasıl karar veriyorsunuz? Şu anda kullandığınız ölçütler çevik projelerde hala mevcuttur.

— Dale Emery

1

Dale, düşüncelerin için teşekkürler. Bunun yalnızca müşteri her yinelemeyi ayrı ayrı ödüyor ve her yinelemeye bir ürün olarak değer veriyorsa işe yaradığını düşünüyorum. Bunun sabit maliyetli ürünler veya tümü veya hiçbir şey gerektiren ürünler için nasıl iyi çalışabileceğini görmüyorum.

— Verax

5

@Verax: "Ya hep ya hiç" gerektiren bir ürün diye bir şey yoktur. Her zaman sadece "sahip olmak güzel" özellikler ve işlevsel olmaktan ziyade kozmetik olan hatalar vardır. Sabit maliyetli bir proje, para bittiğinde kalan tek şeyse başarılı olur. Çevik yöntemler bunun olasılığını en üst düzeye çıkarmaya çalışır.

— Michael Borgwardt

1

Tabii ki gereksinimleri değiştirmek için bir maliyet var. Bir yinelemede bir şey oluşturursanız, bir sonraki öğede bu şeylerin gereksinimlerini değiştirin, bunun bir maliyeti vardır. Çevik maliyeti azaltır. Bunu ortadan kaldırmaz. Bütçeniz varsa, yeni bir özellik eklemeye veya mevcut bir özelliği değiştirmeye karar verirken her zaman bir başkasıyla işlem yaptığınızı bilerek bütçeyi göz önünde bulundurursunuz. Öncelik vermeyi ve yeniden öncelik vermeyi ve sonuçlarını öğrenirsiniz.

— Dale Emery

14

İş, artık tekrarlama yapmak istemediklerine karar verdiğinde durursunuz. Bunun, önemli miktarda değer teslim edildikten sonra, ancak azalan getiriler alanına girmeden önce olduğunu umarsınız.

Durumunuz ne anlama gelirse gelsin her zaman "iş" tarafından yönlendirilmelidir. Bir yazılım geliştirme mağazasının üst yönetimi veya şirket içi bir geliştirme ortamında gerçek iş sponsorları olabilir. Bir sonraki yinelemenin maliyetinin, bir sonraki yinelemede sunulacak özelliklerden ne zaman daha ağır basacağına karar verecekler.

— mcottle
kaynak

5

Asla, ve bu onun güzelliği.

Proje asla bitmedi . Başka bir sürüme, başka bir dönüm noktasına ulaştınız, ancak para aktığı sürece, her zaman eklemek için bir özellik daha, daha iyi yapmak için bir parça daha, düzeltmek için bir hata daha var. Proje artık ihtiyaç duyulmadığında ölecek, ama asla bitmeyecek. Gereksinim-> proje-> ürün-> sonlu Şelale modelinin aksine, bu, ödediğiniz sürece sonsuza kadar dönebilen bir döngüdür.

Bu teknolojinin sıkça bahsedilen bir ticari özelliği değil, değil mi?

— SF.
kaynak

2

Şelale projeleri de tamamen tamamlanmadı, sadece önemli özellikleri eksik olan al ya da bırak gibi teslim edilmesi daha yeni ve pahalı bir projeyi gerekli kılıyor.

— Michael Borgwardt

4

Burada bir yanlış anlama var: Agile projenin gereksinimlerini değiştirmeye teşvik etmiyor. Bunun yerine, işi boşa harcamadan veya önemli gelişim alanlarından ödün vermeden değişime izin verir.

Herhangi bir mühendislik projesinde dört temel kısıtlama vardır; kapsam, maliyet, zaman ve kalite. Şelale, bunların statik olacağını varsayar. Bu yanlış bir varsayımdır; bu HER ZAMAN biri veya daha fazlası değişir. Kapsam sürünmesi, kesik bütçeler ve diğer "bilinmeyen bilinmeyenler" DAİMA bir projeye müdahale ederek kısıtlamaları değiştirir. Şelale bunu öngörmez, bu nedenle proje istenmeyen şekillerde değişir; henüz eklenmemiş önemli özellikler ortadan kaybolur veya hızlı bir şekilde yapılır, ya da sürüm geri itilmelidir, ya da PM gelip yeni şeylerin doğru yapılmasına yardımcı olmak için yeni geliştiricilere para atarken balonları maliyetlendirmelidir.

Çevik, aksine, kısıtlamaların değişmesine izin verir ve aslında bunu bekler. Bunu, sahibinin önceliklerine göre küçük, kullanışlı parçalar halinde yaparak yapar ve bu nedenle parçalar proje sahibi için hemen faydalıdır. Böylece bilinmeyenlerin büyük olduğu bir zaman diliminde büyük planlar yapmayarak bilinmeyene maruz kalmayı azaltır. Zaman çizelgesi değişirse, ekipler eklenebilir veya daha az önemli özellikler "kapsamı kaldırılabilir" ve ekibin oluşturduğu sistem bundan etkilenmez.

Ayrıca, verilen kapsamı istenilen kalitede üretmek için gereken zaman ve maliyetin daha iyi tahmin edilmesini sağlar. İnsanlar büyük işleri tahmin etmede kötü bir şekilde kötüdür; düzgün yapmak için çok deneyim ve çok daha açık bir hesaplama gerektirir. Aksine, insanlar genellikle bir gün ya da bir iki hafta içinde neler yapılabileceklerinin iyi yargıçlarıdır. Bu, hızlı bir şekilde kararlı bir hal üretir; burada tarihi temponuza dayanarak yapılacak işin zamanını ve maliyetini adil bir doğrulukla tahmin edebilirsiniz.

Bitiş noktalarını tanımlamak için haklısınız; Çevik bir proje sonsuza dek devam edebilir. Ancak, geleneksel SLDC de öyle; müşteri genellikle daha fazla para ve yükseltme istek listesi ile geri gelir. Aradaki fark, projeye bir bütün olarak bakıldığında "analiz", "tasarım", "geliştirme" ve "bakım" arasında net bir çizgi olmamasıdır; her şey tuğla tuğla, sürat koşusu olur. Herhangi bir noktada proje sahibi "tamamlandı" olarak adlandırmak isterse yapabilirler ve sağlam bir "duvar" içinde ödemiş oldukları toplam "tuğla" toplamına sahip olurlar; başlangıçta planladıkları kadar yüksek veya geniş olmayabilir, ancak sıkıca yerinde, işi yapar ve daha sonraki bir tarihte minimum yırtılma ile eklenebilir.

— Keiths
kaynak

Özür dilerim ama "Bunun yerine iş israfı olmadan değişime izin verir", yönetimi ne kadar büyük olduğuna ikna etmek için kullanılan alçakgönüllü bir yanlıştır. Beklenmedik değişiklikleri karşılamak için sistemi yeniden düzenleme ve / veya yeniden tasarlama işi boşa harcamıyor mu? Şelale kampında, görünüşe göre çevik kampta değil. Ayrıca, müşteri sadece tamamlanması için 2 hafta süren bir iş isterse, hangi yöntemin kullanıldığı önemli değildir, insanlar iyi tahminler verebilir. Müşterinin gerçekten istediği şey, tam ürüne ne kadar süre kalmadan önce, çevikliğin diğer tahmin yöntemlerinden daha iyi olmadığıdır.

— Dunk

1

Ayrıca, sahibinin herhangi bir noktada çağırabileceği iyi bir şey gibi geliyor ve bitirdiğiniz şey ne elde ettiği. IME, genellikle müşteri X dolarlarının nakit parayı düşürmeden önce belirli bir dizi özellik sağlayacağını bilmek ister. Müşterinin bir yığın para harcadığını ve bekledikleri özelliklerin sadece yarısını aldığını bir fayda olarak görmüyorum. Çalışmak istedikleri bir şeyi teslim etseler bile gelişmekte olan şirketler kısmında başarısızlık olarak görüyorum ....

— Dunk

2

Bir müşteri bir ev için sözleşmeli olsa da, çatı döşenmeden önce para bittiğinde ne olur? Çevik kamp buna yine başarı derdi. Başka hiç kimse yapmaz; özellikle müşteri.

— Dunk

1

Tahmin etmeye gelince, ekip bir sprint'te neler yapabileceklerini tahmin eder ve bu, tüm proje için bir zaman çizelgesi oluşturmak için tahmin edilir. Yine, hem geliştiricilerin hem de müşterinin korunmasına yardımcı olur. Bir sözleşmeye "aşmamak" tutarı ve tarihi dahil olmak üzere istediğiniz her şeyi koyabilirsiniz. Pazarlık edilebilir. Çevik, kısıtlamaların uygulanabilir olup olmadığını her iki tarafa da çok hızlı bir şekilde göstererek yardımcı olur. İki hafta içinde, para için zamanında yapılacak gibi görünmüyorsa, ekipler eklenebilir, özellikler bozulabilir veya program uzatılabilir.

— KeithS

1

Ya bir şelale SLDC'de aynısını yapsaydı? Ya geliştirme durur ve müşteri ciddi işlevsellik deliklerine sahip bir kod tabanı alabilir veya para / zaman sıkıntısı öngörerek, kalan program kalan süreye sıkışır. HER ZAMAN kaliteden fedakarlık eder ve böyle bir projenin sonunda geliştirme ekibi kızartılır. Ayrıca, geleneksel bir şelale geliştirme tamamlanana kadar bir ürün üretmediği için çok fazla maliyet aşımı gerçekleşir; müşterinin "istediğim bu değil" deme yeteneğini sınırlar.

— KeithS

1

Tüm özellikler uygulandığında ve tüm hatalar giderildiğinde sona erer.

Son tarih sabitse ve şartlar da sabitse. O zaman bu bir sorun olmayacak. Ancak son tarih sabitse, ancak gereksinimler değişiyorsa, projeye başarılı bir şekilde devam etmek için yapmanız gereken bir şey vardır.

Sabit fiyat bölüm 1, bu kadar kötü olan ne?

Sabit fiyat bölüm 2, çevik ile Fix!

— CharithJ
kaynak

Tüm hataların ne zaman düzeltildiğini bilmek zor.

— Martin Wickman

Belki "düzeltmeye değer bilinen tüm hatalar düzeltildiğinde"?

— Dan Ray

@CharithJ, bağlantılarınız koptu. Hala bir yerlerde var mı? Teşekkürler.

— TwainJ

1

Çevik geliştirmenin arkasındaki büyük varsayım, hangi yöntemi kullanırsanız kullanın, gereksinimlerin her zaman değişmesidir. Şimdi, elbette bir gereksinimler belgesi oluşturabilir, üzerinde yürütmek için bir plan oluşturabilir ve sonunda teslim edebilirsiniz ve gereksinimleriniz değişmemiş gibi görünebilir. Planınızda değişmemiş olabilirler, ancak pazar değişiklikleri ve sizin ve müşterinizin ürünü daha iyi anlamasıyla, müşterinin ne istediğine ilişkin gereksinimler değişecektir. Agile devreye girer ve bu değişiklikleri sabit bir zamanlama yoluyla gizlemeyen bir süreç önerir, bunun yerine süreçteki kaçınılmaz değişikliklere yanıt verir.

İşiniz bittiğinde, sabit bir zamanlamanın tamamlanmasından, ürününüzün müşterinizin yazılımı mevcut durumunda gönderebileceği ve pazarlayabileceği yeterli iş değeri sağlayabileceğiniz bir yere geçişine geçer. Yapılmak, bir programa nasıl yapıştığınız yerine, ne kadar değer sağladığınıza bağlıdır.

— Brian Geihsler
kaynak

1

Çevik taraftarlar, şelale dünyasında geliştiricilerin bir sözleşme imzalandıktan sonra ortadan kaybolduğu ve bir ürün kapıdan çıkana kadar bir daha asla duyulmadıklarını çok yanlış varsayım yaparlar. Gerçek hayatta çalışma şekli, müşterinin istediği kadar dahil olabileceği çok sayıda kontrol noktası ve birçok inceleme olmasıdır. Yönü veya kararları beğenmedikleri takdirde değişiklik talep edebilirler. Bir ürün teslim edildiğinde, müşterinin dahil olmayı seçtiği ölçüde müşterinin istediği şey olmalıdır. Çevik pek çok proje için bunu geliştirmez.

— Smaç