İşlevsel gereksinimlerin eksikliği çevik midir?

Bugünlerde herkes çevik olmak istiyor. Çalıştığım her takımda, çeviklik şekli farklıydı. Günlük dikmeler veya planlama gibi bazı şeyler yaygındır, ancak diğer bölümler önemli ölçüde farklılık gösterir.

Şu anki takımımda rahatsız edici bulduğum bir detay var. İşlevsel gereksinimlerin eksikliği. Sadece yazılı bir beklenti biçimi değil, aynı zamanda görevlerde ne yapılması gerektiği oldukça belirsiz bir şekilde tanımlanmıştır.

Projenin amacı eski sistemleri yeni teknolojiler kullanarak yeniden yazmaktır. Eski sistemin de makul bir belgesi yoktur. Elbette güncel biri yok. İşletme sahiplerinin gereksinimleri açıklaması - hadi bunu yeni uygulamada eskisi gibi yapalım. Makul gibi görünüyor ama değil. Eski sistem bir çeşit spagetti kodudur ve iş gereksinimlerini buradan ayıklamak pahalıdır. Durumun planlamayı olumsuz yönde etkilediği görülmektedir. Elbette yeni uygulamadaki hatalara ve hatalara eğilimlidir (bazı ayrıntıları atlar).

Bu yüzden düşünüyorum - eski sistemi yeniden yazmak durumunda hiçbir iş gereksinimi olması gerçekten çevik mi?

İşlevsel gereksinimlerden bağımsız olsun ya da olmasın, afet için bir reçetedir. Sistemin nasıl çalıştığını bilmediğinizde sistemi yeniden oluşturamazsınız.

İşletme sahibine eski sistemin nasıl çalıştığı hakkında hiçbir fikriniz olmadığını söylemelisiniz.

En iyi seçeneğiniz, oyundaki iş süreçlerini anlamak ve kendi kabul testlerinizi geliştirmek için işletme sahibinizle veya birkaç deneyimli kullanıcıyla çalışmaktır. Bazı son kullanıcılarla çalışabiliyorsanız, eski sistemin nasıl çalıştığı hakkında daha fazla geri bildirim alabilirsiniz.

Bunu başaramazsanız, kendi gereksinimlerinizi karşılamak için üretim dışı bir ortamda bazı keşif testleri yapmanız gerekir. Çoğu zaman bir işletme sahibi "eskisi gibi çalışmasını sağla" derken, zaman kısıtlaması vardır ve bir işletme sahibinin gerektiği gibi size yardımcı olamamaktadır. Eski sistemin nasıl çalıştığını anlamak için bazı deneyimli kullanıcıların uzmanlığına veya sizin tarafınızdan bir çok manuel teste ihtiyacınız var.

İşletme sahibine, eski sistemin gerekliliklerinin ve anlayışının, onu yeniden inşa etmek için gereken süreyi büyük ölçüde artıracağını - üç kat veya daha fazla bir süre boyunca - artıracağını bildirin. Artan zaman çizelgesi ve maliyetle karşı karşıya kalan işletme sahibi, gereksinimleri daha hızlı toplamak için gereken uzmanlığı size verecektir veya yeniden yazmanın şu anda ekonomik olarak mümkün olmadığına karar verecektir.

Aşağıdakilerden birini alırsınız:

• Uygun gereksinimler ve daha hızlı bir geliştirme döngüsü
• Gereksinimleri toplama ve yazılımı yeniden oluşturma zamanı
• Kariyerinizde kara leke olmayacak yeni bir proje

Çevik, işlevsel gereksinimlere olan ihtiyacı değiştirmez, ancak genellikle bunları toplama şeklinizi değiştirir . Çevik olmayan yol, birinin uzun bir süreçten geçmesi için size sistem için tüm gereksinimleri içeren bir tür belge vermesidir.

Gereksinimleri toplamanın çevik yolu, sistemin küçük bir artışının gereksinimlerini belirlemek, birlikte oluşturmak, daha sonra geri bildirim almak ve bir sonraki artışı yapmak için birlikte çalışmaktır. İşletme sahiplerinin süreci başlatmasını sağlamada sorun yaşıyorsanız, belki yarım gün geçirerek eski sistemin bir sonraki üzerinde çalışmak istediğiniz bölümünü keşfederek ve gereksinimlerle ilgili bir soru listesi oluşturarak başlayabilirim.

Ardından işletme sahiplerinize oturup sorularınızı sorun. Bazı soruları cevaplamaları kolay olacak, bazıları koda bakarak cevaplamanız daha kolay ve bazılarının her iki şekilde de cevaplanması zor. Cevaplanabilecek bir şeye ulaşıncaya kadar zor soruları daha küçük ve daha küçük parçalara bölün.

Amaç, bir şeyler oluşturmak, geri bildirim almak ve süreci yeniden başlatmak için sorularınızın yeterince yanıtlanmasını sağlamaktır. Unutmayın, değişiklikleriniz ne kadar küçük ve geri bildirim döngüsü ne kadar kısa olursa, yanlış bir şey oluşturursanız o kadar az şey olur.

Gereksinimleri yakalamak, herhangi bir (başarılı) yazılım projesinin önemli bir parçasıdır. Ancak bir gereksinim belirtimi yazmak değil.

• Belgelere dayalı bir yaklaşım bir Çin Fısıltı oyunu gibi sonuçlanabilir: bir konu uzmanı bir gereksinimi dile getirir, bir analist bunu yazar, bir geliştirici analistin açıklamasını karşılayan bir şey yazmaya çalışır, yazılım kullanıcı tarafından onların problemini çözmez.

  Çevik teknikler, geliştiricilerin genellikle son kullanıcı olmak üzere doğrudan konu uzmanlarından gereksinimleri toplaması gerektiğini önermektedir. Bunu yapmak için çeşitli teknikler vardır, örneğin KOBİ ile örnek bir senaryodan bahsederek. Geliştiriciler, uç durumları tespit etmekte ve KOBİ'den yazılımın bu uç durumda nasıl davranması gerektiğini açıklamasını istemektedir.

• Çevik ekipler büyük olasılıkla küçük bir gereksinimle başlayacak, bir prototip oluşturacak ve bunu bir sonraki yineleme için geri bildirim toplamak için kullanacaklar.

• İhtiyaçların anlaşılması zaman içinde değiştikçe, statik bir şartname spesifikasyonu güncelliğini yitirecektir. Bu nasıl önlenebilir?

  Gereksinimleri çalıştırılabilir testler olarak ifade ederek. “Okunabilir şartname” ve “çalıştırılabilir testler” in münhasır kavramlar olmadığı, ancak bir ve aynı belge olabileceği ortaya çıkıyor. Örneğin Salatalık ve BDD alanı dışındaki diğer fikirler burada çok yardımcı olabilir.

Eski bir sistemi yeniden yazıyorsanız, orijinal sistem büyük bir gereksinim kaynağı olabilir. Fakat hangi yönler önemlidir? Niş özellikleri kullanılıyor mu? Uyumluluk için hangi hataların yeniden uygulanması gerekir? Genellikle son kullanıcılarla konuşmak için bir çözüm yoktur.

Etrafta yatan bir çalışma sistemine sahip olmak, yeni yazılımı test etmek için de çok yararlı olabilir, ancak bu çeviklikle ilgili herhangi bir endişeyle ilgisizdir.

Son teslim tarihleri ​​olan sabit kapsamlı, sabit zamanlı projelerin çevik antitez olduğunu unutmayın. Normal çevik yaklaşım, bir işlev şeridi seçmek ve önce bunu sunmak, daha sonra tekrarlamaktır. En önemli şeyler önce yapılır, daha az önemli şeyler sonra yapılır (ya da asla). Her şey önemliyse ve ASAP yapılması GEREKİRSE, o zaman hiçbir şey önemli değildir ve projenin herhangi bir şey teslim etmesi olası değildir.

Durumunuzda, gereksinim eksikliği çevik bir özellik değil, daha çok ortalama bir örgütsel işlev bozukluğu vakasıdır. Projenin başarılı olmasını istiyorsanız, bu işlev bozukluğunu aşmanın bir yolunu bulmanız gerekecektir. Örneğin, işletme sahibinden eksiksiz bir gereksinim belgesi yazmamalarını tavsiye edin, ancak en önemli özellik için gereksinimlerini açıkladıkları bir toplantı oluşturmaya çalışın. Ayrıntılar için eski sisteme bakabilirsiniz. Sonra bu özelliği uygulayın ve tekrarlayın.

İşte böyle yaptık. Sahiplerle konuştuk. Yöneticilerle konuştuk. İşi yapan kullanıcılarla konuştuk. Bir kullanıcının masa başında oturarak ve (ve soru soran) izlerken ne bulduğumuz inanılmaz faydalı oldu. Yöneticiler hangi kullanıcılarla oturmamız gerektiğini biliyorlardı.

Sistemin bazı bölümlerinin gerçekten çok iyi çalıştığını keşfettik ve tasarım ve kodlama ve test senaryolarını başlatmak için yeterli gereksinimleri kolayca yazabildik, ancak diğer bölümlerde yerdeki kullanıcıların kullandığı bazı kötü çözümler vardı, hangi yöneticiler ve sahipleri farkında değildi. Eski sistemin bu bölümleri için, işe geri döndük ve daha küçük görevlerin ne olması gerektiğini çivilemeden ve böylece çevik yöntemimizin istediği birimlere ayırabilmemiz için iş akışı ve süreçler hakkında biraz konuştuk.

Bu yüzden Agile sistemin bazı bölümlerini hızla başarabilirken, diğerleri başlamadan önce biraz daha düşünmek ve belgelemek zorundaydı.

Çevik bir çerçevede gereksinimleri bir araya getirmek ve hiç kimse Kullanıcı Hikayelerinden bahsetmedi mi? Bir kullanıcı hikayesi, aslında yazılımın ne yapabilmesi gerektiğinin üst düzey bir tanımıdır. Genellikle, işletmeden veya son kullanıcıdan gelen herhangi bir geri bildirim veya istek bir kullanıcı hikayesi olarak yazılabilir. ... Kabul kriterlerini bir kullanıcı hikayesini destekleyen fonksiyonel gereksinimler olarak düşünebilirsiniz.

Bu soru, çevik hareketle neyin yanlış gittiğine işaret ediyor. Soruyu soran kişinin hatası değildir; Her zaman bu tuzağa düşüyorum çünkü yıllar süren kurumsal yaşam beni eğitti.

Bahsettiğim tuzak, bir şeyler yapmak için öngörülen ve doğru bir Agile yolunun olduğunu düşünüyor. Bunun nedeni insanların Çevik olduğunu düşündükleri olabilir. Sen olamaz yapmak artık sen edebileceğinden çok daha Çevik yapmak Pragmatik.

"İşlevsel özelliklere" sahip olmamak ya da her neyse, endişe verici geliyor, ama olmayabilir. Başlamak için ne kadar ayrıntıya ihtiyacınız var? Güvenlik ve performans, önde bilinen ve baştan sona uygulanan açıktır. Aksi takdirde, Seçenekler Fiyatlandırma motoru mu yoksa saat uygulaması mı?

Sürekli sürüm, tartışma, öğrenme, geri dönme ve yazılımı değiştirme olacak mı? Eğer inşa ediyoruz yumuşak eşya veya donanım?

Bir şelale sürecinde çalışan geliştiriciler genellikle daha sonraki bir aşamaya kadar dahil olmazlar, bu bir problemdir. Onları daha önce veya en başından itibaren dahil etmek, aslında işlerinin bir kısmı "ne nedir?" inşa edeceğimiz bu şey için fonksiyonel gereksinimler? "

Plandaki delikleri tanımlamak, sadece yazılım geliştirmeyle hata bulmakla ilgili değildir.

Bu nedenle Guy'ın cevabını seviyorum.