Müşterilerin gereksinimleri hiç değişmediğinde Agile kullanmak yanlış mıdır?

12

Son zamanlarda Agile'ın kullanılmasının en önemli nedenlerinden birinin müşterilerin genellikle gereksinimleri değiştirdiğini söyleyen birçok gönderi gördüm.

Ancak, müşterilerin gereksinimleri sık sık değiştirmediğini varsayalım . Aslında, müşterilerin biraz belirsiz (ama makul olmayan bir şekilde belirsiz bir şey) olsa da sağlam gereksinimleri var, ama yine de Agile kullanıyorum.

Çevik'i çalıştırmamın nedeni, yazılımın, gerçekte onlarla karşılaşana kadar tanıyamayacağım ayrıntılar, sorunlar olacak kadar karmaşık olmasıdır. Şelale gibi tam ölçekli bir ağır planlama yaklaşımı yapabilirdim, ancak daha sonra tüm üst düzey tasarım ve düşük seviye kodlama imzalarını tamamlamak birkaç ay sürecekti. Yine de sistem için çok özel, sabit bir mimari tasarım var.

Sorum şu: Bu kötü, kovboy kodlama, anti-desen vb. Agile'da bu 'hadi yapalım' zihninin yerine gereksinimler kararlı olduğunda kodlamaya başlamadan önce şelale kullanmalı ve mümkün olduğunca ayrıntılı bir şekilde planlamalıyız ?

EDIT: Buradaki en önemli nokta şudur: Değişen gereksinimler için müşterileri suçlayamayız. Müşterilerin bizi çok somut bir soruna işaret ettiğini, bize çok makul detaylarda bir dilek listesi verdiğini ve bizi yalnız bıraktıklarını varsayalım (yani müşterilerin yapacakları kendi üretken şeyleri var, onları daha fazla rahatsız etmeyin. minimum çalışma prototipiniz olduğunda sonlandırın). Bu senaryoda Agile kullanmak yanlış olur mu?

agile development-process

— InformedA
kaynak

2

@randomA: aslında, IMHO asla sadece bir haftadan fazla çaba gerektiren çalışan bir ürün oluşturmak istiyorsanız saf şelale denememelisiniz.

— Doc Brown

10

Lütfen bana müşterilerinizi verin

— Razethestray

7

Müşterileriniz için @razethestray'den 2 kat daha fazla vereceğim

— Euphoric

2

Müşteriniz "günlük rahatsız olmak" istemiyorsa, onunla nasıl etkili iletişim kuracağınızı öğrenin. Örneğin, belirsiz noktalar hakkında (muhtemelen yanlış) varsayımlar yapmak yerine, bir listede soruları toplayın ve müşterinizi listeyi düzenli aralıklarla gönderin. Daha da iyisi: noktaları tartışmak için bir toplantı düzenleyin. Gereksinimler o kadar açıksa liste boş kalır: toplantı yok (ama sanırım olmayacak). Yazılımınıza yanlış varsayımlar uygulamaya başlarsanız, bunu daha sonra değiştirmek için çok fazla çaba harcayacaksınız.

— Doc Brown

3

@randomA: hiçbir şey sormadan müşterinizi bir süre mutlu tutabilirsiniz ve daha sonra, son şeyi teslim ettiğinizde, onu çok mutsuz hale getirin, çünkü programınızı atıp başlatabileceğiniz gereksinimleri kaçırdınız. (müşterinin ödemeye istekli olmayacağı). Ya da ona doğru programı oluşturmak için yeterince zaman isteyerek onu biraz ama mutsuz yaparsınız, ancak programın gerçekten istediği şeyi yapacağından ve ödediği şeyi aldığında sonunda çok mutlu olursunuz. Seçiminizi yapın.

— Doc Brown

16

Bu kötü, kovboy kodlama, anti-desen olarak kabul edilir mi?

Kısa cevap: hayır. "Çevik" i doğru yapmak "planlama yok" anlamına gelmez, bir şeyleri aşırı değerlendirmemek anlamına gelir.

Agile'ın kullanılmasının en önemli nedenlerinden biri, müşterilerin genellikle gereksinimleri değiştirmesidir.

Bu çok basit bir ifade. "Değişen gereksinimler" aynı zamanda ekibin gereksinimler hakkındaki anlayışının nasıl değiştiği ile ilgilidir. Ve müşterinin yazılımın birkaç sürümünü gördüğünde gereksinimle ilgili önceliklerinin nasıl değiştiği ile ilgilidir.

Aslında, "çevik" en iyi tanımladığınız durumda IMHO çalışır - müşteri genel gereksinimleri hakkında iyi bir bilgiye sahip, ondan genel bir plan yazabilir, biriktirme işinizi birçok "kullanıcı hikayesi" ile doldurabilir ve zaten doğru sistem mimarisini seçmek için yeterli bilgi. Çevik bir geliştirme stratejisinin kısa iterasyonları, hala doğru yöne gidiyorsanız çok fazla geri bildirim ile "belirsiz gereksinimleri" daha kesin hale getirmeye yardımcı olacaktır. Ayrıca, gerçek çaba ve maliyetler hakkında erken geri bildirim verecektir (bu, her gereksinimi ayrıntılı olarak bilseniz bile, bir şelale yaklaşımında hala başarısız olabileceğiniz bir şeydir).

— Doc Brown
kaynak

3

"Şelale" yi doğru yapmak "her şeyi planla" anlamına gelmez, şeyleri azarlamak anlamına gelmez.

— Giorgio

1

@Giorgio: "şelale" yi doğru yapmak, gereksinimler "biraz belirsiz" ve "yazılım, ayrıntılarla, gerçekte yüzleşene kadar tanıyamayacağım sorunlar olduğu kadar karmaşık olduğunda" uygulanmaması anlamına gelir ( orijinal soru).

— Doc Brown

6

Bu durumda çevik kullanımı hala çok iyi bir fikirdir. Çevikliğin birçok faydası vardır, bunlardan sadece bir tanesi müşteriden düzenli geri bildirim ve bahsettiğiniz gibi değişen gereksinimlere cevap verme yeteneğidir.

Şelale projelerinin başarısızlık için kötü şöhretli olmasının ana nedenlerinden biri, 'neredeyse bitti' problemidir - sonunda üretilen hata yığınlarını test ederek, dayanılmaz bir ürün bırakarak ve olağanüstü hataları düzeltmek için iki gün veya iki yıl daha gerekip gerekmediğine dair bir fikir yoktur. Agile bu riski tamamen ortadan kaldırır. Çevik bir proje aşırı çalışıyorsa, hala çalışan bir sürüm sunabilirsiniz:

A) Demo ("Tüm bu hikayeler yapılır, isterseniz son birkaçını yapabiliriz") ile neredeyse orada olduğunuzu müşteriye kanıtlar ve biraz daha tam olarak istediklerini elde eder.

B) Zaten mutlu olmaları ve salıverilmeleri için potansiyel olarak yeterince iyidir.

Bana göre, bu tamamen başarısızlık riskini kaldırmak, bir işletmenin çevik bir geliştirme sürecine geçmesi için tek başına yeterli bir sebeptir, başlangıçta planlanandan daha iyi yazılım oluşturma yeteneği kek üzerine krema yapmaktır. Diğer cevaplarda belirtildiği gibi, bu 'somut' gereklilikler hala şaşırtıcı bir şekilde biçimlendirilebilir.

— SpoonerNZ
kaynak

A) cevabınızın başlangıcında bahsettiğiniz sorunu hangi şekilde çözdüğünü anlamıyorum: son birkaç öykünün birkaç gün veya iki yıl alıp almayacağını nasıl anlarsınız? Sadece onları gerçekten ne zaman yaptığını gerçekten biliyorsun, değil mi?

— Giorgio

1

Haklısınız, ancak fark şu ki, serbest bırakılamayan% 90'lık bir hatalı yazılım parçası yerine mevcut durumunda serbest bırakılabilir bir ürününüz var. Ayrıca, serbest bırakılabilir özellikleri sunmanın ne kadar sürdüğüne ve yaptığınız herhangi bir şeyin gerçekten işe yaradığına dair hiçbir kanıt bulunmadığına dair daha fazla güven sağlama olasılığı olan kalan çalışma tahminlerinize ilişkin ampirik kanıtlara da sahipsiniz.

— SpoonerNZ

Şunlara bağlıdır: planlanan tüm özellikler gerekliyse,% 90 özelliklere sahip bir ürün kullanılamaz / serbest bırakılamaz: sadece zaten orada olanın bir demosunu vermek için kullanılabilir. Deneyimlerime göre çeviklik her durumda tercih edilmez: çevikliğin daha uygun olduğu projeler (değişen gereksinimler, küçük, müstakil ve bağımsız özellikler) ve olmayan projeler (istikrarlı gereksinimler, karmaşık ve / veya kritik görevler) özellikleri).

— Giorgio

Kabul ediyorum - yetersiz dağıtım her iki durumda da iyi değil, ancak bir paydaş olarak, her şeyin çalıştığı ancak bazı özelliklerin eksik olduğu yerde oynamak için yazılımınızın tamamen çalışan bir sürümünü üreten takıma veya size bir bug teorik olarak tüm özelliklere sahip ama çok çöküyor ve beklenmedik davranış çok kaynak kodu yığını riddled? Hangisine daha fazla güveneceğimi biliyorum.

— SpoonerNZ

Tabii ki ilk takıma güvenirim, ancak çevik olmayan bir yöntem kullanarak her zaman "teorik olarak tüm özelliklerinize sahip olan ancak çok fazla çöken ve beklenmeyen davranışlara sahip olan bir hata kod kaynağı yığını" ile sonuçlandığınızı kabul etmiyorum. . En azından şu ana kadarki deneyimim olmadı.

— Giorgio

3

İstemci ile sık sık geri bildirim döngüsüne ihtiyacınız varsa Agile idealdir. Bunun nedeni, gereksinimlerin sık sık değişmesi olabilir, ancak başka nedenlerle de olabilir.

Öte yandan, gereksinimler tamamen kararlıysa ve müşteri yalnızca tek bir büyük patlama teslimatı beklerse, Agile eşit derecede iyi çalışabilir, ancak müşterinin, projesi. Bu, Ürün Sahibi rolünün kendi kuruluşunuzdan doldurulması gerektiği ve söz konusu kişinin karar almak için müşteriden yeterli yetkiye sahip olması gerektiği anlamına gelir .

— Bart van Ingen Schenau
kaynak

1

Çok fazla yer almak istemeyen müşterilerin gerçek bir iş ihtiyacına sahip olup olmadığını merak ediyorum. Mevcut bir uygulamanın yeni bir teknolojiye 'çevrildiği' projelerde bunu sık sık gördüm. Size söyledikleri sorularınız varsa kodu kontrol edebilirsiniz. Kimse yeniden yapmayı beklemiyor.

— user99561

@ user99561: haklısınız, ancak bu gibi durumlarda gereksinimler çoğunlukla belirsiz değildir, kristal berraklığındadır - yeni program tam olarak eskisi gibi davranacağı sürece . Böyle bir durumda "çevik" bir yaklaşım gerçekten gerekli değildir. Yinelemeli, mil-taş tabanlı bir yaklaşım (fazla müşteri etkileşimi olmadan) gerçekten yeterli olacaktır.

— Doc Brown

Kristal berraklığı? Tam davranışın ne olduğunu ve istisnaların ne olduğunu bulmak için iyi şanslar. Çoğu zaman iş adamları bile uygulamada ne olduğunu anlamıyorlar. Benim tavsiyem: Bu projelerden olabildiğince hızlı kaç. Çünkü projenin ne zaman başladığını biliyorsunuz ancak son farklı hatanın ne zaman yayınlanacağını bilmiyorsunuz çünkü uygulamalar farklı davranıyor.

— user99561

0

Büyük sürümü her zaman daha küçük sürümlere (sprintlere) bölebilir ve müşterinizden geri bildirim isteyebilirsiniz. Bu şekilde doğru şeyi yaptığınızdan emin olabilirsiniz ve müşteri ilerlemenizi takip edebilir.

Yanlış bir şey varsa, müşterinize sizi daha erken düzeltme şansı sunabilirsiniz, bu da çok iyidir. Hatalarınızı en kısa zamanda düzeltmek, sonunda ona bir saçmalık göstermek ve nereden başlayacağınızı bile bilmediğinizde düzeltmeye çalışmak daha iyidir.

— Silviu Burcea
kaynak

Açıklığa kavuşturmak için bir düzenleme ekledim. Müşteriler, yeterli ayrıntılar ve açık bir istek listesi ile ilgili bir sorun gösterdi ve daha fazla sorun yaşamamak istiyorlar. Öyleyse, çalışan bir prototipi demoya sokabileceğiniz zamana kadar müşteri geri bildirimi olmadığını varsayalım.

— InformedA