Değişen gereksinimlerle nasıl başa çıkıyorsunuz? [kapalı]

Şu anki işimde çok fazla gereksinim değişikliği varmış gibi geliyor. Biz "Çevik" bir dükkanız, bu yüzden ayarlamamız gerekiyordu ve ne olmasın, ama bazen değişiklik büyük ve önemsiz bir şey değil.

Sorum şu: Değişimin maliyetini etkili bir şekilde nasıl iletiyorsunuz? Çevik olduğu için, bir değişiklik yeterince büyükse, mevcut süratten bir şey düşecektir, ancak genellikle bir dahaki sefere eklenir. Modelimiz SaaS olduğundan, son müşteri etkin bir şekilde şirketin kendisi ve n hafta sonra kesim özelliğini alacaklarını biliyorlar .

Sanırım almaya çalıştığım şey, bir özelliğin kaldırılması, yalnızca n hafta kadar geciktiği için iletişim için kullanılacak bir şey değil . İşletmenin bir değişikliğin maliyetini anlamasını sağlamak için başka hangi yollara sahipsiniz?

@Joe "Biz" Çevik "bir dükkanız, bu yüzden ayarlamamız gerekiyor ve ne olmasın, ama bazen değişim büyük ve önemsiz bir şey değil."

İşleminiz gereksinimlerdeki değişim oranını kontrol etmenize izin vermiyorsa, işleminiz çevik değil, gelişigüzeldir. Çevik "benim yoluma gelen herhangi bir şeyi almak" anlamına gelmez.

Gereksinim değişikliğini / sürünmeyi kontrol etmek için - işleminizde - bir gereksinimin değişmediği fikrini kabul edebilirsiniz (Scrum'ın kalbindeki bir kavramdır). Bir gereksinim değişikliğini eski bir gereksinimi yenisiyle değiştirerek ele alın. Gereksinimlerin bir birikimine sahip olmanız ve kullanıcının hangilerini uygulamak istediğini seçmesi gerekir.

İki haftada X ve Y'yi istedin, ama aniden Z'yi istiyorsun. Peki, o zaman sana her üçünü de 4 haftada teslim edebilirim. Veya iki hafta içinde bir çift (X ve Z) veya (X ve Y) veya (Y ve Z) verebilirim ve kalanını daha sonra teslim edebilirim. Seç.

Müşterilerle bu şekilde pazarlık edersiniz. Gereksinim değişikliği maliyetini bu şekilde iletirsiniz. Grubunuzun bu gücü yoksa, çevik bir dükkanda değilsiniz ve bu konuda yapabileceğiniz hiçbir şey yoktur. Berbat, ama doğru.

Pazarlık yapabileceğiniz durumlarda, gereksinimleri ve gereksinim değişikliklerini uygulamak için gereken süreyi (hassas bir şekilde) izlemeniz gerekir. Yani, geçmiş ve şimdiki projelerden bu verileri toplamalısınız.

Orijinal zaman tahminini ve gerçek tamamlanma süresini (geliştirici sayısı gibi kaynaklara ek olarak) istek başına (veya N isteklerinden etkilenen modül) toplarsınız. Daha da iyisi, istek / istek değişikliğinin boyutunu tahmin edin (geçmiş projeler ve taleplerdeki kod satırları veya işlev noktaları açısından).

Kullanıcıyla konuşabileceğiniz bir metriğiniz olduğunu varsayalım. Yeni bir isteğin, örneğin, 1K kod satırı veya her biri ortalama 5 giriş alanına sahip 10 web sayfası (50 işlev noktası) alacağını biliyorsunuz.

Daha sonra geçmiş projelerinize özgü geçmiş verilere bakarak (bazıları kod satırlarına göre, bazıları web sayfalarına, bazıları gerçek işlev noktalarına göre) ve bu maliyetlerin her birinin mutlak tamamlanma süresi açısından nasıl olduğunu tahmin edebilirsiniz. Yeterli veriye sahip olanlar için, gerçek bir geliştirici kafa sayısını izleyen gereksinimleri de belirleyebilirsiniz.

Sonra bunu kullanırsınız ve müşterinize geçmiş verilere dayalı olduğunu söylersiniz; proje başarısızlıklarının üstel bir dağıtım takibi yapma eğiliminde olduğunu; ve sonra müşteriniz için aşağıdaki argümanla silahlanıyorsunuz:

Geçmiş ve şimdiki projelerimizden ve mevcut kaynaklarımızdan elde edilen verilere dayanarak, sorduğunuz gereksinim

1. X'in% 25 hata olasılığıyla tamamlanması için geçen süre (veya başarının% 75'i)

2. 1.5 * X'in% 5'lik bir başarısızlıkla (veya% 95'lik başarıyla) tamamlanması için geçen süre

3. % 95 başarısızlık (veya başarının% 5'i) ile 0,5 * X tamamlama süresi

Zaman kaynaklarının bir fonksiyonu olarak başarısızlık olasılığı tipik olarak% 95,% 25 ve% 5'tir (üstel bir dağıtıma benzemektedir). Belli bir temel miktarın biraz iyi bir başarı şansı verdiğini (ancak gerçek risklerle) ). Bunların 1.5'i minimum riskle neredeyse belirli bir başarı şansı verebilir, ancak bundan çok daha az olabilir (orijinalin 0,5'i neredeyse kesin başarısızlığı garanti eder.)

Bunu sindirmelerine izin verdin. Eğer riskli öneri için devam ederse ( dün yapılır! ) En azından yazılı olarak söylediniz. Grubunuzun sadece çevik değil mühendislik gibi olma umudu varsa, o zaman müşteri sayılarınıza ciddi önem verebilir ve bu ve gelecekteki talepleri buna göre planlayabilir.

Mühendis olarak, istek değişiklikleri ücretsiz bir yemek değildir, doğrulanabilir ve açık terimlerle açıklamak bir mühendis olarak sizin görevinizdir.

Açıkladığınızdan, bir sorununuz yok. Onlar bir değişiklik istiyorlar ve ya yapılabilir ya da başka bir özelliği ertelemeye kadar söyleyene kadar beklemeye istekli. Zaman, kaynaklar ve gereksinimler arasında bir denge gibi görünüyor.

Yeni bir ekleme / değişiklik için minimum yaş belirlemeyi deneyebilirsiniz (hata düzeltmeleri için geçerli değildir). Örneğin, 3 haftalık olana kadar hiçbir yeni değişiklik üzerinde çalışılamaz.

Bir görevin asgari yaşına sahip olmak güzeldir, çünkü başlangıçta her görev son derece önemli gibi görünür, ancak bir süre beklerseniz önemi genellikle önemli ölçüde düşer. Zaman aralığınıza bağlı olarak, üzerinde çalıştığınız görevlerde en az bu miktarda kararlılık süresi sağlar.

Yaşı izlemek için görevlerin bir listeye eklenmesine izin verirsiniz, ancak bu süre sona erene kadar üzerinde çalışmak için görev olarak kabul edilmezler.

Bir proje teknik şartlarda ne kadar hızlı ilerlese de bu çok yaygın bir sorundur, müşterinin projeyi çok daha yavaş olarak algıladığını ve geliştiricilerin çok fazla bir şey yapmaması gerektiğini düşünmeyi istedikleri için gereksinimleri değiştirmekte özgür olduğunu hisseder.

Bu kusurlu algı, zaman tüketen ve müşteriler tarafından asla uygun şekilde hesaplanmayacak üç önemli geliştirme görevinden gelir:

1. Kod incelemeleri / temizleme: Eski kod şişirilir ve berbat olur ve düzenli incelemelere ve temizliğe ihtiyaç duyar, bu çok zaman alır ve müşteri asla inanmaz.
2. Güvenlik denetimi ve düzeltmeleri: Özellikle genç ekip üyeleriniz varsa, kodla ilgili birçok güvenlik sorununuz olacak ve düzenli olarak yazılmış tüm yeni kodları gözden geçirmek ve bir güvenlikten iyi görünmeyen şeyleri yeniden yazmak isteyeceksiniz perspektif, müşteri asla bu kez bilecek veya hesap.
3. Mimariyle ilgili değişiklikler: Büyüyen bir kod tabanı birden fazla noktada yapısal yeniden düşünmeyi ve yeniden düzenlemeyi gerektirebilir (aşağıdakileri içerebilir): A - Performansla ilgili değişiklikler / optimizasyonlar (Algoritma değişiklikleri, kütüphane değiştirme, önbellek motorları, vb.) veya: B - Verimlilikle ilgili değişiklikler / optimizasyonlar (okunabilirlik, kodun tekrar kullanılabilirliği, kolay anlaşılırlık, yeni kodlama kuralları, yeni bir çerçeve, vb.).

Yukarıdakilerin hiçbiri son müşteriler tarafından anlaşılmayacak ve uygun şekilde açıklanmayacaktır.

Temel olarak "görünüm" (GUI öğeleri) ne olursa olsun yapılmamıştır.

Buna projenix teoremi diyelim, haha ​​şaka yapmıyorum: D