Kodlamadan önce işlevselliği bilmek ne kadar önemlidir?

Geliştirme çalışmasının bize açıklandığı bir yazılım geliştirme şirketinde çalışıyorum. Kıyıdaki ekip destekle ilgilenir ve doğrudan müşterilerle konuşur. Müşterilerle asla doğrudan konuşmayız, sadece kıyıdaki ekipten, doğrudan müşterilerle konuşan insanlarla konuşuyoruz.

Gereksinimler geldiğinde, kıyıdaki ekip müşterilerle konuşur ve gereksinim belgeleri hazırlar ve bizi bilgilendirir. İhtiyaçları inceledikten sonra tasarım belgeleri hazırlıyoruz (geleneksel şelale modelini takip ediyoruz).

Ancak tüm süreçte bir sorun var: kıyıdan ya da kıyıdan ekipte hiç kimse uygulamanın işlevselliğini tamamen anlamıyor. Biz sadece onun karmaşık sipariş işleme, katalog yönetimi, kampanya yönetimi ve diğer faaliyetleri işleme büyük bir karmaşık web uygulaması biliyorum. Gereksinimler net olmayacağı için tasarım belgesiyle mücadele ediyoruz. Daha sonra kıyı ekibi, kıyı ekibi ve müşteriler arasında bir dizi soru / cevap alır. Sıklıkla işlevselliği koddan anlamamız söylenir. Ancak, kod tabanı çok büyük olduğundan ve hatta basit bir menü öğesini anlamak haftalar olmasa bile günler sürdüğü için genellikle uygun değildir. Müşterilere bize bilgi transferi yapmalarını söylemeye çalıştıkuygulama hakkında ama boşuna. Yöneticimiz bize tasarım belgesi tam olmasa veya gereksinimler net olmasa bile kodlamaya başlamamızı söylerdi. Açık görünen gereksinimlerin bir kısmını kodlayarak başlayacağız ve geri kalanını bekleyin.

Bu genellikle konuşlandırmayı bir ay geciktirir. Aşırı durumlarda, geliştirme ve üretimde çok düşük hatalarımız olurdu, ancak müşteriler sordukları şey bu değildir. Bu bir suçlama oyunu ve bir dizi değişiklik isteği başlatacak ve sonuçta çok farklı bir şey geliştireceğiz.

Benim sorum, uygulamanın işlevselliğini tam olarak bilmiyorsanız geliştirme işini nasıl yapardınız?

GÜNCELLEME

Geliştirme metodolojisi gerçekten benim seçimim değil ve ben ekibimin lideri değilim. Bu şekilde başladı. İnsanlara çevikliğin avantajlarını anlatmaya çalıştım ama boşuna. Ayrıca ekibimin çevik bir ortamda çalışmak için gerekli zihniyete sahip olduğunu düşünmüyorum.

Kısa versiyon:

Ne yapacağınızı bilmek customer müşterinizi tanımak.

Şunu hayal edin: gayrimenkul geliştirme ile ilgili bir şirketsiniz. Eşinizden büyük bir kompleks inşa etmesini istersiniz. Ortak, ona verdiğiniz tüm belgelere rağmen, aynı zamanda bu kompleksteki daireleri satın alacak kişilerle doğrudan konuşması gerektiğini söylüyor. Ciddi anlamda?

Uzun versiyon:

Belirli bir uygulamanın nasıl kullanılacağını bilmek her zaman iyidir, çünkü bir şeyler öğrenmek eğlencelidir, ancak büyük projelerde her zaman mümkün değildir.

Bazı alanlar çok karmaşık. İseniz sadece bir geliştirici ve birden fazla alanda birden fazla uygulama üzerinde çalışıyoruz, sadece her zaman son kullanıcı ne yaptığını anlayamıyorum o muhasebe öğrenmeye beş yıl harcamak gerekecektir çünkü, tıp fakültesinde on yıl, hukuk fakültesinde altı yıl vb.

Öte yandan, belirli bir etki alanını anlamadan yapılan bir yazılım ürünü en iyi, iyi, biraz kullanılamaz olacaktır .

Bu nedenle işlevsel ve işlevsel olmayan gereksinimler, etki alanını tam olarak anlayan kişiler tarafından yazılmalıdır. Genel olarak, gereksinimlerin toplanması aynı zamanda şunları içerir:

1. Teknisyenler (örneğin, belirli bir özelliğin imkansız olduğunu söyleyecek geliştiriciler, bu şekilde yapılırsa diğerinin daha iyi olabileceğini ve çok daha ucuz bir alternatif varken binlerce dolara mal olacağını söyleyen geliştiriciler),

2. Proje yönetimi konusunda uzmanlaşmış kişiler,

3. Müşterinin alanında uzmanlaşmış, bu alan adını tam olarak bilen ve müşterinin kesin ihtiyaçlarını karşılayan kişiler. Tabii ki, bu müşterinin kendisi olabilir.

Bir işlevsel ve işlevsel olmayan gereksinim yazılır ve yeterince hassastır, işi bu gereksinimleri koda çevirmek olan bir kişi olarak başka bir şeye ihtiyacınız yoktur.

Özel durumunuza gelince, sorunun nedenini kendiniz açıklıyorsunuz:

Gereksinimler net olmayacağı için tasarım belgesiyle mücadele ediyoruz.

Tüm soruna neden olan müşteri hakkında bilgi eksikliği değil , gereksinimlerin düşük kalitesi. Doğru yönetilen bir projede, işlevsel ve işlevsel olmayan gereksinimler tamamen net ve açık olmalıdır. Gereksinimler belgesi net değilse veya size "ürünün görsel tasarımının çekici olması gerektiğini" veya bunun gibi diğer aptallıkları söylerse, bunun nasıl yazılacağını bilmeyen insanlar tarafından yazıldığı için.

Bunu bilerek, farklı davranmanız gerekir:

• Gereksinimleri toplayan ekibin çaresiz olduğunu ve kendi ekibinizin gereksinimleri toplamak için insanları becerikli hale getirdiğini biliyorsanız , durumu amirinize açıklayın ve diğer ekibin , örneğin sizinkiler gibi yetkili biriyle değiştirilmesi gerektiğini söyleyin .

• Aksi takdirde (yani umutsuzlarsa), bu düşük gereksinimlerin iç nedenlerini belirlemeye çalışın ve işlerini doğru yapmanın sadece projenin toplam maliyetini azaltacağı konusunda ikna edin . Maliyeti (ne kadar?) Artırarak kötü yazılmış projelerin projeyi ne kadar etkilediğine ilişkin istatistikleri göstermek ve son tarihe hazır olmama riski burada iyi bir fikirdir.

Muhtemelen gereksinimler belgesi henüz tamamlanmamıştır. Bunu her zaman görüyorum: deneyimsiz proje yöneticileri sadece bir sayfalık belgenin yeterli olduğuna ikna oldular ve neden bir yerine üç ila dört yüz sayfa yazacaklarını anlamıyorlar. Şirketinizde durum buysa, gereksinimlere daha fazla zaman harcamanın maliyetleri düşüreceğini gösterin.

Karşılaştığınız sorunlar için tam olarak yanlış geliştirme metodolojisi kullanıyorsunuz.

Şelale kullanarak şunları taahhüt edersiniz:

1. Doğru gereksinimleri ön plana çıkarmak - bu kesinlikle çalışmıyor
2. Gereksinimleri müşteriden uzakta kodlama - Gereksinimleri geliştirmeyi taahhüt ettiğinizde müşteri ile olan sorunları etkili bir şekilde kontrol edemezsiniz
3. Müşterinin işlevlerini görmesinin ilk şansı test sırasındadır - yaşadığınız sorunlar göz önüne alındığında bu çok geç

Mümkünse, projeyi yönetmenin farklı bir yolunu kullanmayı düşünün. Çevik Yazılım Geliştirme , karşılaştığınız sorunları çözmek için tasarlanmış çeşitli özelliklere sahiptir.

Waterfall vs Agile ile iyi bir karşılaştırma bir süre önce yazılmıştır, sorunlarınızı vurgulayan birkaç alıntı yapalım:

İşareti Eksik:

Şelale yönteminde bir aşama tamamlandığında, geri dönüş yoktur, çünkü şelale yöntemi altında tasarlanan ve uygulanan çoğu yazılımın zamana ve kullanıcı ihtiyaçlarına göre değiştirilmesi zordur. Sorun ancak geri dönüp tamamen yeni bir sistem, çok maliyetli ve verimsiz bir yöntem tasarlanarak düzeltilebilir.

Bağlı ...

Çevik yöntemler, son kullanıcının gereksinimlerine göre şartname değişikliklerine izin vererek müşteri memnuniyetini sağlar. Daha önce de belirtildiği gibi, şelale yöntemi kullanıldığında bu mümkün değildir, çünkü yapılacak herhangi bir değişiklik, projenin yeniden başlatılması gerektiği anlamına gelir.

... ve Hareket Edilemiyor

İkisi arasındaki farkı özetlemek için, klasik şelale yönteminin öngörülebilirliği temsil ettiği söylenebilirken, Agile metodolojisi uyarlanabilirliği büyülüyor. Çevik yöntemler, gerekçe, gerekçe, dokümantasyon ve toplantılar gibi genel giderleri azaltmada ve mümkün olduğunca düşük tutmada iyidir. Bu yüzden Agile yöntemleri, büyük projelerden ziyade sürekli değişen gereksinimleri olan küçük ekiplere fayda sağlar.

Şu an nerede olduğun kötü; müşterinin gereksinimlerini karşılamıyorsunuz ve yazılım geliştirmenin suçlu bir parçasıysanız, verimlilik pencereden dışarı çıkacak, güvensizlik artacak ve işler daha da kötüleşecek, daha iyi değil.

Müşteri ile ilişki kritiktir ; burada, sorunlarını etkin bir şekilde toplayamayacağınız ve şu anda çalıştığınız şekilde değişen gereksinimlerine uyum sağlayamayacağınız anlaşılıyor; bu nedenle bunu değiştirmenin yollarına bakmanız gerekir.

Bu şekilde değil. Mevcut eğitimimin konularından biri analiz ve bir müşteriyle olan ilişkidir. Vurgu her zaman projeyi açıkça tanımlamak olmuştur. Şunu hayal edin:

• Bir inşaat şirketi için bir ev inşa etmesini emrediyorsunuz ama nasıl görünmesini istediğinizi bilmiyorsunuz. Sadece birinci katı özelleştirirsiniz, böylece takım birinci kata kadar bir ev inşa eder. Sonra zemin katın farklı şekilde döşenmesini istiyorsunuz. Hata ...

(Kısmen) uygulama için doğru temeller yapabileceğinizden çok emin değilseniz, sadece müşteriye, açıkça tanımlanmış hedefler ve işlevselliklerden daha yapılacak başka bir yol olmadığını söyleyebilirim. Çünkü ne olabileceğine bir bıçak takarsanız, çok fazla para atma ve boşa harcanma zamanını tehlikeye atabilirsiniz.

Sorunların üstesinden gelmeye yardımcı olacak bazı şeyler:

1. İki ekip arasındaki iletişimi geliştirin . Diğer ekipten gereksinimi 3 kelimeye sıkıştırmasını isteyin ve programcı bu kelimeleri tam olarak uygulayacaktır. Kelimelerin doğru olması gerekir. Bu kelimeler olmadan hiçbir şey uygulanmayacak. Her kelime size 2000 satırlık kod verir. Uygulama yeni bir kelime bilindiğinde başlar.
2. Bir kelime programcılarınıza hemen açık değilse, tek soru sormalarına izin verilir . Soru yine doğru olmalı. Hemen cevaplanması gerekiyor - cevap dünyanın diğer tarafından bir gidiş dönüş bekleyemez, ancak önceden bilinmesi gerekir. Uygulama cevabı aldıktan hemen sonra başlar ve cevap mektuba kadar takip edilir.
3. Uygulama sırasında belirsiz veya bulanık gereksinimler varsa, bunları çözmenin yolu önce (mevcut) 3 kelimeye bakmaktır. Hala belirsizse, programcı mümkün olan en iyi tahminde bulunur . Bu süreçte herhangi bir gecikme kesinlikle yasaktır; ve diğer takımdan yardım istemek sorunu çözmenin doğru yolu değildir - doğru 3 kelimeye karar vererek gereksinimleri değiştirme şansları zaten vardı.
4. Tüm bunlardan sonra, gereksinim hala belirsiz veya uygulanması imkansızsa, doğru işlemenin yolu , soruna neden olan bu 3 kelimeyi reddetmek ve bir sonraki kelimelere geçmektir. Reddedilen kelimeler toplanacak ve diğer ekibe aktarılacak ve kelimeleri sisteme tekrar girmeden önce değiştirmeleri gerekecektir. Kelimeleri reddetmek her zaman son tarihi taşır ve uygulamanın yeniden planlanması gerekir.
5. Takımların kaç tane reddedilmiş kelimeye göre değerlendirilmeleri gerekir. Gereksinim uygulandıktan sonra, sonsuza kadar sabitlenir ve artık değiştirilemez . Zaten uygulanmış olan özellikleri değiştirme girişimleri reddedilecektir.
6. Soru ile ilgili asıl sorun, daha fazla bilginin uygulamayı kolaylaştırdığını varsaymasıdır. Bu doğru değil. Daha çok özgürlük senin programcılar var, daha kolay uygulanması . Gereksinimlerin sıkıştırılması, programcıların yapmasına izin verilen çok fazla kısıtlama olmaksızın büyük miktarda bilgi iletişimine izin verir.