Gereksinimlerin yokluğunda yazılım yazmak sahip olmak için bir yetenek mi, yoksa kaçınmam gereken bir durum mu?

Bazı yazılım geliştiricilerin bu konuda çok usta olduklarını ve çoğu zaman soyut bir gereksinimle çalışan bir konsept sunma kabiliyetleri nedeniyle övüldüğünü buluyorum. Açıkçası, bu beni deli ediyor, ve ilerlediğimde "telafi etmekten" hoşlanmıyorum. Bunun sorunlu olduğunu düşünürdüm, ancak bir kayma hissetmeye başladım ve çok az bir yön verildiğinde düşünce (ve programlama) sürecimi ayarlamam gerekip gerekmediğini merak ediyorum. Bu yeteneği bir beceri olarak edinmeye başlamalı mıyım yoksa gereksinimin toplanması ve iş kurallarının birinci öncelik olduğu fikrine bağlı mıyım?

Beceri, gereksinim duymadan yazılım yazmak değildir. Bunun yerine resmi bir gereklilik belgelendirmesi olup olmadığına bakılmaksızın proje sahibinden gereksinimler ortaya çıkarılmalıdır.

İhtiyaçların toplanması kesinlikle birinci önceliğinizdir, ancak tüm müşterinin ihtiyaçlarını önceden belirtmeniz gerekmez. Tabii ki risk, eğer müşterinizle doğru şekilde konuşmayı başaramadıysanız, sistem mimarinizi işe yaramaz hale getiren bazı önemli bilgileri kaçırmanız olabilir, ancak bir ürünü tanımlamak ve hatta almak sıra dışı büyük sistem mimarisi kararlarını mümkün olan en son ana kadar ertelerken, çoğu gelişmenin dışında kalmaktadır. Bu, daha sağlam bir bilgiye sahip oluncaya kadar, ürün geliştirmenizde çok erken bir potansiyel olarak uyumsuz mimariye bağlı kalmamanızı sağlamak için yapılan yalın bir geliştirme yaklaşımıdır. OP'nin sorusunda tanımladığı durumlarda,

Evet, bazen müşterinin gerçekte istediği şeyin kalbine ulaşmak için biraz kristal toplara bakmanız gerekir; bu, prototiplemenin yükseldiği ve yavaş - ve bazen de bazen acı veren - gereksinimlerin ortaya çıkmasını gerektiren gerçekten iyi müşteri ilişkileri becerilerini ve ayrıca karmaşık yazılım fikirleriyle, başlangıçta müşterinin yazılımın gerçekte ne yapması gerektiğinden daha fazla şey bilmediğini fark etme sabrını geliştiriyor olmanız. Çoğu zaman, müşteri, yazılım geliştirme süreci hakkında her zaman gerekli uzmanlığa veya bilgiye sahip olmadığından, gereksinimlerini tanımlamak için uzmanlığınıza bağlı olarak sizi erken arar.

Bu çok belirsiz…

Söyleyebileceğim iki şey:

1. Mükemmel gereksinimleri bekledikleri için kariyeri kesilmiş çok yetenekli teknik insanlar var. Ya da "Üzgünüz, yapamam, şartlarda yoktu" diye oynuyorlar. Gerçek şu ki, şartların yazılması çok zor. İyi gereksinimler için gereken hassasiyet, çoğu iş insanının yarattığı hiçbir şeye benzemez. Teknoloji ile işletme arasında bir köprü var ve diğerlerini karşılayan insanlar, onlarla tanışmanın% 100'ünü genellikle kaybediyorlar.

2. Etki alanlarını müşterilerinden daha iyi veya daha iyi öğrenen yazılım adamları var. Bu insanlar% 100 en iyi geliştiriciler olmasa bile, altınlarına değer veriyorlar. Ülkedeki en iyi marka yöneticilerinin nicel pazarlama ihtiyaçlarını tahmin eden yazılım adamları gördüm. Tüm çözümleri kodlamada en iyisi onlar değildi, ancak kahramanlardı çünkü köprüden geçebiliyorlardı.

Hayat siyahla ilgili değil ama beyazlar da. Etrafınıza dar bir kutu çizerseniz, kendinizi sınırlarsınız. Kapak tarafında, teknoloji yaratmak için neyin gerekli olduğunu reddeden bir organizasyon da sınırlıdır. Gri renkte nerede olmayı tercih ettiğini görmek zorundasın.

Gereksinimler yolculuktaki adımlardır, vizyon yöndür

Pek çok uygulama için, oldukça ayrıntılı bir teknik şartname hemen hemen ön plandadır; Bunun yerine, bir vizyonla başlayın. Herkes genel resmi anlarsa, şartlar tartışmalar boyunca yerine getirilebilir.

Bir geliştirici olarak, bu tartışmaları gereksinimler arasında dolaşmak için kullanmayı öğrenmelisiniz . Bu, müşterilere bugün kararlarının genel vizyona nasıl uyduğunu düşünmelerini sağlayan sorular yöneltmesi anlamına gelir. Bu daha ayrıntılı tartışmalar ne kadar erken olursa, genel vizyon tutarlı bir tasarıma katılabilecektir.

Bu tartışmaların sonuçlarını bir tür sorun izleyicide izlemelisiniz, böylece diğerleri orijinal tartışmayı kaçırırlarsa onlar hakkında yorum yapabilirler. Ve sizin veya ekibinizin diğer üyelerinin kaydına sahip olmanız için, açıklığa ihtiyacınız olursa tekrar başvurabilirsiniz.

Bu nedenle, vizyona karşı kodlamayı öğrenin, ancak zamanı geldiğinde bu gereksinimler için trol etmeye hazır olun.

Steve Jobs, müşterilerin gelecekteki ürünlerin neye benzemesini istediklerini tam olarak tanımlayamadıklarına inanıyor, bu yüzden bunları sunmak sizin işiniz. Bu nedenle, her zaman özel yazılım sağlamadığınız sürece, resmi özellikleri unutun ve prototipler oluşturarak ve müşterilerin onlarla oynamasına ve ne düşündüklerini size söylemesine izin vererek başlayın. Prototipleme yapan doğru kişiyi koymak zorundasın ve onların yardımına ihtiyaçları var. Bunu deneyimlerden söylüyorum - Ben sezgisel arayüzler oluşturmayı seven prototip maymuyum ve müşterilerin ne istediğini anlayan ve kâğıt üzerinde veya Excel kullanarak bir şeyler açıklayabilen üründe birisiyle birlikte çalıştım.

İkimiz de dahi değiliz, ama biz de aynı şekilde düşünüyoruz - neredeyse kimyaya sahip olduğumuzu ve hangi şeylerin nasıl yapıldığına büyük bir etkisi olduğunu söyleyebilirsiniz. Şimdi, yalnızca orta ila büyük bir ekip, yalnızca ürün geliştiren bir prototip ve kodlayıcı olmayan bir kişiye sahip olabilir, ancak buna değer. Prototipleme, yazılım geliştirmenin en ucuz aşamasıdır, bu nedenle yalnızca kullanıcı arayüzü ve görünen davranışı doğru yapmak mantıklıdır. Code Complete'i okumamıştım ama sanırım o kitapta yazılı gibi bir şey var.

Özellikleri güzel, ama asla mükemmel değiller. Bununla ilgili bir teorem var. Spesifikasyonun tamamlandığını ve aletin herhangi bir arızası olmadığını veya durduğunu kanıtlayamazsınız. :)

Yine de, yazılım şirketleri bu süreçteki kusurlara rağmen yazılımı her zaman gönderiyorlar. Spec asla mükemmel olmayacak. Spec da doğal ve modası geçmiş. Bir prototipin bir spesifikasyonu logaritma tablosu gibidir, tek bir grafiktir - bir teknik özellik aslında bir araç / grafik ile etkileşime girebildiğiniz için basılması gereken sıkıcı bir broşürdür. İlham almak için http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html adresini ziyaret edin .

Şimdi, kıçını kapatmak için bir sözleşmeniz olması gerektiğinde, teknik özellik iyidir. Fakat bir teknik daha önce değil, prototipten sonra gelmelidir. Prototiplerin nasıl ucuz hale getirileceğini bulmak sizin işiniz.

Sık sık bazı durumlarda ben iş şu anda insanlar nasıl tam olarak nasıl çalıştığını keşfetmek, iş analisti olarak görev gerektiğini bulduk düşünüyorum o (genellikle çok farklı şeyler) çalışır ve onlar nasıl gibi işe onu.

Yazılımı oluşturmak için vermeye zorlandığım kararlar konusunda her zaman net olarak başarı buldum. Akıl yürütmemi açıklar, keşfettiğim şeylerle ilgili belgeler yazarım, grafikler hazırlarım ve herkese dağıtırım, vb.

Tüm gereklilikler yerine getirilinceye kadar herhangi bir iş yapmayı reddederek muhtemelen çok iyi bir izlenim bırakmazsınız. Ancak, iyi kalite gereksinimlerini kendiniz toplayarak (gerçeğe dikkat çekmeden), aynı kalite yazılımı hedefine ulaşırsınız.

Ve evet, diğer yorumcuların söylediği gibi, her zaman değişeceğini varsayarak yazılımı oluşturun. Değişim, güvenebileceğiniz bir sabittir. Yazılımınızı daima yeterince esnek ve modüler bir hale getirin, böylece bazı yeni gereksinimler aniden göründüğünde güncellenmesi acı verici olmaz.

Eğer başlangıçta bir yazılım geliştiricisi olarak çalışmak istiyorsanız, sahip olmak bir beceridir.

Bir danışmanlık firmasında çalışmak istiyorsanız, ne pahasına olursa olsun kaçınılması gereken bir durumdur. Bunun nedeni, firmanızın spesifikasyon / gereksinimleri ne kadar iyi uyguladığınıza ve müşterinin problemini ne kadar iyi çözemediğinize göre ödenmesidir.

Boş zamanlarınızda eğlenceyi kodluyorsanız, bu sizin aramanız. Boş zaman projelerinizi aramak için nitelikli hissetmiyorsanız, her iki şekilde bir kaç deneyin ve neyin işe yaradığını görün. Ayrıca tek bedene uyan her şeye gerek yok, bazı projelerden biri ya da başka bir yaklaşıma ihtiyaç duyuyor. Genellikle bu projelerden birinde yanlış olanı seçerseniz, oldukça hızlı bir şekilde çözersiniz.

İkisindende biraz. Müşterilerinizi tatmin etmeniz gerekir, bu ne istediklerini bilmeniz gerektiği anlamına gelir. Öte yandan, müşteriler gerçekten ne istediklerini iletmekte çok kötüler.

Böylece, müşterilerin ne istediğini bilmediğiniz senaryolardan kaçınmak istersiniz, ancak kaçınılmaz olarak, gereksinimlerin en iyi şekilde "aldatıcı" ve en kötü şekilde aldatıcı olduğu bir senaryoya girersiniz. İyi bir gerçek dünya programcısı uyarlanabilirlik gerektirir.

Gereksinim olmadan program yazmak mümkün değildir. 'Merhaba Dünya' bile bile: çıktı üretmek. Yani, UML benzeri bir şey büyük bir yığın şeklinde, resmi gereksinimler hakkında soruyor düşünüyorum. Ve bunlarla ilgili olarak, 2 tür insanla tanıştım:

1) Resmi gereksinimlere ihtiyaç duyan insanlar. Tam olarak ne yapacaklarını ve en iyi şekilde nasıl yapacaklarını söylemeleri gerekir. Onlar gibi cümleler seviyorum argüman B irade çıktı C'yi alarak prosedür A ve söz konusu nefret: Program bizim Bölümün işi daha etkin yapmalıdır . Bunlar genellikle şirket hayvanlarıdır.

2) 1'e göre olan insanlar 1. Ne yapacakları ve nasıl yapacakları söylenmekten nefret ederler, ne yapılması gerektiği söylenmeye bayılırlar. Müşteriyle konuşmayı, söylediklerini analiz etmeyi ve sonra kendi çözümlerini geliştirmeyi seviyorlar. Genellikle serbest çalışanlardır ve şirkete uygun değildir.

Hangisinin daha iyi olduğunu söyleyemem. Her ikisinin de artıları ve kontraları var. Diğer koşullar için yeterli basit.

Sen edebilirsiniz DEĞİL geliştirmek operasyonel Gereksinimleri bilmeden yazılımı; ancak, deneyiminizin size Gereksinimlerin muhtemel olduğunu söylediklerini geliştirmede çok iyi bir bıçak olabilir.olmak. Çevik geliştirme, 80:20 Kuralı ve prototip kullanarak Gereksinimlerin 'keşfi' dahil olmak üzere 'sezgisel' tekniklerin bir kombinasyonunu kullanır. Başka bir deyişle, deneyimli bir geliştirme ekibi neye ihtiyaç duyulduğunu en iyi şekilde tahmin eder ve yazılımın bir prototipini oluşturur. 80:20 Kuralı,% 80 doğru olacaklarını söylüyor. Proje paydaşları daha sonra somut prototipi gözden geçirir. Onların geri bildirimleri, Gereksinimleri anlamadaki% 20'lik boşluğu doldurmaya başlar. Bu yüzden, aslında, Agile herhangi bir gereksinim duymadan yazılım yazmakla ilgili değil, daha önce "böyle bir şey mi istiyorsun?" Bu, vakaların% 80'inde, ileriye doğru atlamanıza ve gerçekten gerekli olan şeyleri geleneksel Gereksinimler süreçleri ile yapılan yağmalamadan daha hızlı bir şekilde onaylamanıza izin verecektir.

Agile, ihtiyaçların olmadığı durumlarda kod yazdığını söyledi? Manifesto'nun bu şekilde bazı insanlar tarafından yorumlandığını biliyorum ... ama bu doğru değil.