Geliştirme döneminde spesifikasyonun neden değiştirilmemesi gerektiğini açıklamak istiyorum

Yeni planlama departmanı çalışanına şartnamenin geliştirme döneminde neden değiştirilmemesi gerektiğini açıklamak istiyorum.

Bir şartname, en basit projelerden herhangi biri için geliştirme sırasında neredeyse her zaman değişir.

Nedenleri:

• Projenin geliştirilmesi veya daha olası entegrasyon testi, orijinal spesifikasyon yapıldığında fark edilmeyen şeyleri ortaya çıkarır - uç durumlardan büyük yönlere. Örneğin, geliştirici, sipariş dışı mesaj onaylarının gelebileceğini fark eder.

• Spesifikasyonu belirleyen gerçek dünya koşulu donmaz. Örneğin, doğrudan işleme spesifikasyonuna eklenmesi gereken yeni bir finansal ürün yaratılır.

• Son tarih baskıları, budamalara neden olur.

• Projenin ek paydaşları keşfedildi (örneğin, proje boyunca farklı bir alanda benzer bir proje keşfedildi ve ortak alt sistemlerin merkezileştirilmesi / paylaşılması gerekiyor - bu bana 2 yıllık proje boyunca ortada büyük bir yeniden sonuç verdi. architeching).

• Projenin ek sponsorlarının yeni spesifikasyon gereksinimleri var (en ünlü örneklerden biri Bradley Fighting Vehicle'in gelişim tarihidir).

Spesifikasyon değişikliklerinin neden olumsuz bir etkiye sahip olduğuna gelince ("olmamalı" diyemezsiniz çünkü görebildiğiniz gibi birçok neden var, neredeyse tüm kontrolünüz dışında ve birçoğu iyi bir nedenden dolayı) -

• Spesifik değişiklikler, kod değişikliklerine neden olarak, henüz yazılmayan proje bölümlerini tamamlamanızı engeller (hepimizin bildiği ve Joel Spolsky tarafından evangelize edildiği için odak değişiklikleri geliştiriciler için çok kötüdür)

• Bazı spesifikasyon değişiklikleri (bazen görünüşte ÇOK önemsiz gibi görünüyor) , spesifikasyondan alınan bir varsayım temelinde 2 mimarlık arasında bir seçim yapıldığından sistemin tamamen yeniden yapılandırılması / yeniden yapılandırılması gereği ortaya çıkabilir .

• TDD durumunda, testlere tabi tutulan büyük bir iş geçersiz olabilir.

• Spesifikasyon değişiklikleri yukarıda belirtildiği gibi ek paydaşlardan geliyorsa, mevcut spesifikasyonla çelişkili olabilir ve bu da ürün kalitesinde önemli bir düşüşe neden olabilir (bkz. Fighting Vehicle, Bradley).

• Spesifikasyon değişikliği, değiştiricinin / talep edenin farkında olamayacağı veya ilgilenemeyeceği bazı mevcut işletme gereksinimlerini ihlal edebilir (bu gerçekten son kurşun noktasıyla aynıdır).

Tüm bunların ne olacağı elbette projenin teslim tarihini uzatır (bazen önemli ölçüde) ve potansiyel olarak arızalı olma olasılığını arttırır.

Spesifikasyondaki küçük bir değişikliğin nasıl aşırı problemler yaratabileceğine dair en iyi örnek için, sizin için 3 harfim var:

Y2K .

Yaptıkları tek şey, " 2000 yılından sonra çalışmalı " dediklerini değiştirmekti .

Ayrıca, bazı durumlarda şartnamenin değişmemesi ZORUNLUDUR ("iyi bir sebep olmadan değişmemelidir" yerine):

• Spesifikasyonun bir kısmı, arayüzler olması gereken harici bir sistemin spesifikasyonudur (veya bağımlıdır).

• Spesifikasyonun bir kısmı, sistemin uygulandığı bir donanımdır (veya ona bağımlıdır).

• Bir müşteri ile yapılan sözleşme gereklilikleri (sınırlama, sadece değişiklik gerçeğinin aksine, önce müşteri ile yapılan değişiklikler üzerinde çalışmadan ve sözleşmeyi değiştirmeden spesifikasyonu değiştirmekten bahsediyor olsa da)

• Bir sistemin, müşteri tercihine bakılmaksızın belirli yasal veya düzenleyici gereksinimleri karşılaması gerekebilir. Örnekler: kredi kartı şifrelemesi, vergi verilerinin korunması.

Geliştirme sırasında spesifikasyonda değişiklik yapılmasını yasaklamak programcı için idealdir, ancak gerçek dünya ortamında gerçekçi değildir. İnsanlar, her şey kapıdan çıksa bile, her zaman değişiklik yapmak isteyeceklerdir. Asla durmaz. Ve bu insanların bazıları maaş çekini imzalıyor olabilir. Ne kadar çok önem verirlerse, o kadar çok düşünürler ve bu nedenle tasarımı daha sık revize etmek isterler. Başlamadan önce bile, tasarımın tamamlanmadan önce değiştirilmesini tolere edebilmelisiniz.

Önemli olan, değişikliklerin sonuçlarını net bir şekilde iletmektir, böylece herkes tasarım sürecinden gerçekçi beklentilere sahiptir.

Değişikliklerin uygun şekilde tartışılması gerekir ve söz konusu şeyin sorumlusu değişikliklerin teslimat tarihinde ne gibi bir etkisi olacağını net bir şekilde anlamalıdır. Bunu elde etmek için geliştiriciyle konuşmak zorunda. Bununla birlikte, sürekli bir tartışma tartışması geliştiriciyi su altında tutacağından ve herhangi bir gerçek çalışmanın gerçekleşmesini engelleyeceğinden, değişikliklerin sıralı ve seyrek aralıklarla sıraya alınması ve tartışılması gerekir. Umarım budur.

İdeal olarak, insanlara yapmak istedikleri değişiklikleri not etmelerini ve haftalık / iki haftada bir / aylık / her türlü koordinasyon toplantısında getirmelerini istemeniz talimatını verirsiniz. Toplantı sırasında, talep edilen özelliğin uygulanması için yapılması gereken temel değişikliklerin ve dolayısıyla tamamlanma tarihi üzerindeki etkinin tartışılması da dahil olmak üzere her değişiklik talebi tartışılır. Değişikliğin "maliyeti" belirlendikten sonra, bunu dahil edip etmeyeceğini belirleyebilirler.

Bu sürecin getirdiği önemli şey, her değişikliğin ilişkili bir maliyetinin olduğu ve proje boyunca ilerledikçe maliyetin genellikle daha yüksek olduğu fikridir, çünkü daha fazla çalışma çoğaltılmalıdır. Gelişimde çalışmayan insanlar genellikle bir değişikliğin ne kadara mal olacağı konusunda hiçbir fikre sahip değildir; anlatmanın tek yolu onu önermek ve tepkinizi ölçmektir. İyi tanımlanmış bir değişiklik inceleme süreci oluşturmak hem onlara hem de size yardımcı olacaktır.

Programcıların ya bir değişikliğin ne kadar kolay olduğu konusunda son derece iyimser ya da ne kadar imkansız olacağı konusunda son derece kötümser olduklarını unutmayın. Orijinal tahminlerinizi sonuçlarla karşılaştırarak ne olduğunuzu anlamaya çalışın ve buna göre ayarlayın.

Belki de spesifikasyonun geçerli bir değişiklik talebi ve süreci olmadan değişmemesi gerektiğini söylemek daha iyi olur. Bir spesifikasyon değişikliği talep etmenin program ve maliyet üzerinde etkileri vardır, bu nedenle bunların onaylanması gerekir.

Uygun bir değişiklik yönetimi süreci olduğu göz önüne alındığında, teknik özelliklerin değiştirilmesi hakkında "yanlış" bir şey yoktur, ancak çok pahalı olması muhtemeldir, bu nedenle müşterileriniz çok mutlu olmayabilir. Bazı iyi gereksinimleri ve özellikleri öne çıkarmaya çalışarak onları kendilerinden koruyabilirsiniz, böylece daha az değişiklik gerekir.

Sahip olduğum en iyi benzetme onu bir ev inşa etmekle karşılaştırmak. Mimar planları hazırlar ve sonra bir tahmin yaparsa, müşteri daha sonra planı kabul eder (veya etmez). Müşteri ilave bir banyo koymak isterse iş durur, planların değişmesi gerekir, yeni bir tahmin yapılır ve müşteri kabul eder (ya da etmez).

Yazma yazılımı farklı değil. anlaşma yapıldıktan sonra (tasarım ve tahminden sonra) herhangi bir değişiklik yapılması gerekiyorsa, yeni plan yapabilmek için çalışmanın durdurulması, yeni tahminin onaylanması (veya onaylanmaması) ve daha sonra çalışma devam edecektir.

Söylediğim ya da söylemediğim her yerde proje yeni değişiklikler olmadan devam ediyor demektir. Tabii ki her zaman yeni planlar ve tahminde bulunmanın zamanı ve materyalleri vardır.