Kullanıcı hikayeleri ve gereksinimleri çok farklı canavarlardır.
Gereksinimler
Gereksinimler, uygulamanın tasarımının önceden yapıldığını ve geliştirmenin bu tasarımın uygulanması olduğunu varsayar. Gereksinimler bu nedenle bir işlevin nasıl uygulanacağına odaklanır .
Gereksinim örneği:
- Aşağıdaki alanlardan oluşan bir kullanıcı iletişim formu oluşturun: ad, soyad, e-posta, serbest metin ve gönder düğmesi. Gönder düğmesine basıldığında, destek ekibimize bir e-posta gönderilir.
Kullanıcı hikayeleri
Kullanıcı hikayeleri neyin başarılacağına odaklanır ve ürünün tasarımının son dakikada yapılmasında ve bir ürün insanı ile bir geliştirici insan arasında bir işbirliği olduğu konusunda ısrar eder. Ayrıntılara uygulama sırasında fırsata dayalı karar verilir.
Bir hikaye örneği:
- Jimmy olarak kullanıcı siteyi gerektiği gibi kullanamadığımda destek ekibinizle bağlantı kurmak istiyorum böylece bana yardımcı olabilirler.
Fark ne?
Görebildiğiniz gibi, verilen ayrıntıların miktarında kesinlikle bir fark var, ancak aynı zamanda yalnızca bu hikayede elde etmeye çalıştığımızın amacı olan hikayede mevcut olan birçok bilgi var .
Amaç nispeten önemsiz gibi görünse de, çevik gelişimde bu yanlış bir varsayımdır. Amacın bilinmesinin çok önemli olduğu tipik olarak iki durum vardır: fırsat maliyetini azaltmak ve çevikliği sağlamak.
Fırsat maliyeti
Gereksinimlerde gizli varsayımlar varsa, elde edilmesi çok zor olabilir. Örneğin: bir posta sunucusu var mı? Aksi takdirde, gereksinimin geliştirilmesi daha uzun sürebilir. Diğer bazı durumlarda, tasarım nedeniyle aynı hedefe ulaşmanın daha basit bir yolu kaçırılabilir.
Buna karşılık, kullanıcı hikayesi destek departmanımızla iletişim kuran bir kullanıcı hakkındadır. Bir posta göndermek mümkün değilse veya çok pahalıysa, yerinde farklı bir çözüm önerebiliriz: örneğin bir veritabanına yazın, ya da Google docs yoluyla bir form kullanın ya da sadece form yerine bir e-posta adresi koyun. Bu bir gereksinimle kolayca yapılamaz, ancak kolayca bir hikaye ve hazır bulunan bir ürün ile yapılır.
Çeviklik
Bu sebeple, gerekliliklerle, genellikle önceden bu gizli varsayımları düşünmeye meyilliyiz ve aksama olmadığından emin oluruz. Bu nedenle, bu durumda elden önce planlanmış ve bir posta sunucusunun var olduğundan emin olan farklı bir gereksinim olabilir.
Bu bizi hiyerarşi olan hikayeler ve gereksinimler arasında başka bir büyük farklılığa götürür . Yukarıda örneklendirdiğim gibi, gereksinimler, kendi doğası gereği, bazı doğal hiyerarşilerde, böylece bağımlılıkların karşılanması için sipariş edilmelidir. Öte yandan, hikayeler bilerek odaklanır ve bu tür kısıtlamaları yoktur.
Bu, tasarım gereği, çevik olduğu gibi, projenin yürütülmesi sırasında ihtiyaç duyulan hikayeleri eklemek, kaldırmak, yeniden planlamak ve değiştirmek için çok önemlidir. Gereksinimler genellikle eklenebilir, bazen değiştirilebilir veya kaldırılabilir, ancak tüm bağımlılıklar nedeniyle onları hareket ettirmek çok acı vericidir. Sadece çok sık yapılmaz. Gereksinimlerle çalışıyorsanız çevik uygulamanız, değişimi benimsemek anlamında acı çekecek veya muhtemelen hiç çevik olmayacaktır.