Kabul kriterleri olmadan yazılımı nasıl geliştirirsiniz?

4-5 geliştiriciden oluşan bir ekipte, kabul kriterlerine sahip olmayan, test ediciler için ne test edeceğini ve ürün sahibi olarak çalışan birden fazla (2-3) kişiyle nasıl bir yazılım geliştireceğinizi işbirliği içinde nasıl geliştirirsiniz.

Elimizdeki tek şey, bazı ekran görüntüleri ve birkaç kurşun noktası ile kabataslak bir 'spec'.

Bize bunun kolay olacağı söylendi, bu yüzden bunlar gerekli değil.

Nasıl devam edeceğimi bilemiyorum.

İlave bilgi

Zor bir tarih verildi.

Müşteri dahilidir, teorik olarak bir ürün sahibine sahibiz, ancak yazılımı test eden en az 3 kişi bir iş öğesinde başarısız olabilir çünkü sadece çalışması gerektiğini düşündüğü gibi çalışmaz ve ne beklediklerinin şeffaflığı çok az veya hiç yoktur. aslında başarısız olana kadar ne için test ettiklerini.

ürün sahibi (ler) soruları cevaplamak veya geri bildirim vermek için hazır değildir. Düzenli olarak planlanmış toplantılar veya onlarla aramalar yapılmaz ve geri bildirim günler alabilir.

Mükemmel bir özelliğe sahip olamayacağımızı anlayabiliyorum, ancak her sprintte üzerinde çalıştığımız şeyler için kabul kriterlerinin olmasının 'normal' olacağını düşündüm.

Bir tekrarlanan bir süreçtir ayrıntılı özellikler olmadan, güzel bunu başarmak olacaktır.

Basit bir taslak prototip oluşturun, müşteriden geri bildirim isteyin, geri bildirime göre değişiklikler yapın ve uygulama tamamlanana kadar bu işlemi tekrarlayın.

Müşterinin bu şekilde yapacak kadar sabırlı olup olmadığı farklı bir sorudur. Bazı müşteriler ve geliştiriciler aslında bu süreci tercih ediyor; müşteri her zaman uygulamalı olduğu için (sonunda) tam olarak istediğini elde eder.

Bu şekilde sabit maliyetli ya da sabit süreli bir sözleşme yapmayacağınızı söylemeden devam etmeli.

Söylediğiniz şey doğruysa ve özellik, başlayabilmeniz için yeterince iyi bir yerde değilse (ve bu değerlendirmede dürüst olursanız), bu yaklaşımı öneriyorum:

1. Eskizleri ve size verilen "kabataslak" özelliklerini okuyun.
2. Kendi spesifikasyonunuzu kodlayabilmeniz için yeterli bir seviyeye yazın . Bir ton tahmin yapmak zorunda kalabilirsiniz.
3. Özelliğinizi incelemesi için müşteriye gösterin. Beğendikleri bölümleri not alın ve yanlış anladığınızı düşündükleri bölümler hakkında daha fazla bilgi edinin.
4. Siz ve müşteri senkronize olana kadar 2. ve 3. adımları tekrarlayın.
5. Artık yeterli bir özelliğiniz var.

Müşteriniz "kolay olacak" dediğinde haklıysa, bu alıştırma bir parça kek olmalıdır.

Müşteriniz yanlıştıysa ve gerçekte ihtiyaçlarınızda her türlü sorun ve eksiklikler varsa, taslak belirtiminiz sorunu hızlı bir şekilde gösterecek ve onlara (bir parmağa ya da tartışmaya gerek kalmadan) yanlış olduklarını söyleyecektir. onların önünde haklı ve açık ol. Ayrıca, spekülasyonunuz bu belirsizlikleri çözmek için harika bir tartışma aracı olarak hizmet verecek ve geri bildirimleriyle gözden geçirirken temel kararların bir kaydı olarak hizmet edecektir.

Ürün sahibi size bir prototip verdi; onu daha iyi olanları geri verin (siz bitinceye kadar)

Projeyi başlatmak için size bir kağıt prototip sağlandı gibi görünüyor. Bu korkunç bir başlangıç ​​değil. İlerleme yeteneğine sahip prototipler sağlayarak , işletme sahibiyle aynı dilde iletişim kurmanızı öneririm .

Prototipleriniz kağıtla başlamalı, dijital örnekler üzerine hareket etmeli ve daha sonra “gerçek” teknolojilerle geliştirilmelidir.

Treehouse , bunun için mükemmel bir rehbere sahiptir:

Bir çerçeve ile prototipleme ile ilgili harika şey prototipin genellikle gerçek site haline gelmesidir çünkü yapı ve stil zaten yerindedir. Aynı çerçeveyi kullanacaksa, siteyi sıfırdan oluşturmanıza gerek yoktur.

Resmi bir şartname de belirtmek isteyebilirsiniz, özellikle de kötü bir sonuç için suçlanmaktan endişe duyuyorsanız. Fakat muhtemelen prototiplerden daha fazla geri bildirim alacaksınız.

Son teslim tarihinle tanış

Daha sonra yapacağınız çabaların, tek kullanımlık olmayacakları için (veya bunların bir kısmı olmayacak), klasik “prototip” olmayacağını unutmayın. Son teslim tarihinden önce tamamladığınız en son, en yetenekli yineleme, teslim edilebilir hale gelir.

Son tarihiniz sahip olduğunuz en iyi tanımlanmış gereksinimdir. Zamanında teslim edebileceğiniz eksiksiz ve tutarlı bir şey sağlayın.

Test cihazlarınızla işbirliği yapın

Bu gevşek süreç şirketiniz için yeni bir şeyse, testçileriniz muhtemelen sizden çok daha fazla kaybediyor ve size rehberlik için bakıyor olabilirler . Sürecinin bir kısmını bu süreçte erken almak zorundasınız. Patronlarına resmi kabul kriterleri almadan anlamlı bir test yapmalarına yardımcı olmaya çalıştığınızı bildirin.

Test uzmanlarının, “tekrar girebileceğiniz” test kanıtı belgeleri gibi sağlamaları gereken herhangi bir firmaya sahip olup olmadığını öğrenin.

Deneyin Testi İlk Tasarım

Resmi bir gereksiniminiz olmadığından, test senaryolarını geliştirmeniz doğru bir yapı sağlar.

Test First Design ve / veya test odaklı geliştirme konusunda kendinize bir aşina olun ve test edeceğiniz süreçte ihtiyaç duyduğunuzda rehberlik edin. Bunun gibi hızlı bir proje için süreçte uzman olmanıza gerek yok. Ancak kanıtlanmış bir metodoloji kullanmak sizi ve test edenlerinizi iyi bir şekilde yansıtacaktır.

Özellikle kullanıcı arayüzü için standartlara uyun

Bak ve hissetmenle ilgili şartların yok ama son bir tarihin var. Profesyonel görünümlü bir eser yaratmak için yapmanız gereken işi en aza indirmek için başkasının tasarım çalışmasını kullanın.

Siteniz için standart bir UI seçin ve yönlendirilinceye kadar / özelleştirmeyin. Hangi platform için geliştirdiğinizi bilmiyorum ama Bootstrap veya Google Materyal Tasarımı iki örnektir.

İletişim kurun, ama üzülmeyin

Bir gün ürün sahibine bir e-posta göndermenizi öneririm. Sadece acil bir durumdan daha fazlasını gönder.

Sorularınız varsa, rehberlik almadığınızda nasıl devam edeceğinizi açıklayın. Örneğin:

Bu uygulamanın kullanıcılarının mobil cihazlarla erişmeleri gerekecek mi? Şu anda bunun yalnızca masaüstü / dizüstü bilgisayar sistemi olacağını varsayıyoruz.

Panik yapma

“Gereklilik” terimini bilmeyen insanlar için birçok projeye katıldım. Çoğu başarılı oldu. Hands-off ürün sahipleri size harika çözümler üretme şansı veriyor.

Unutmayın, bu projelerdeki bazı proje sahiplerinin memnuniyeti imkansızdı ve yetersizlikleri için “çok meşgulüm ...” bahanesinin arkasına saklandılar. Ancak çoğu, sonuçlarla “sevindi”.

Bir proje, kesinliğe ulaşılıncaya kadar belirsizliği azaltma eylemidir :

• Her zaman başlangıçta bir miktar belirsizlik vardır. Bazen gereksinimlerde biraz belirsizlik olur. Bazen, çok kabataslak olanlar. İşin bir parçası olarak çalışmak zorunda kalacaksınız.
• İşin püf noktası bu belirsizliği yinelemeli olarak azaltmak (analiz, tasarım ve uygulamayı birleştirmek), kullanıcı hikayelerini iyileştirmek ve sisteminizi uygulamaktır.
• Test vakaları / senaryoları ve kabul kriterleri aynı şekilde açıklığa kavuşturulacaktır. Kalite ve doğruluk konusundaki belirsizliği azaltmaya katkıda bulunurlar (diğerlerinin yanı sıra).
• Sonunda, yeterli bir kesinliğe ulaşılır: müşteri, ihtiyaçlarına uygun ve kullanılabilecek test edilmiş bir ürün alır.

İlerici detaylandırma ilkesi budur: gereksinimler, kriterler ve sonuçlar, müşterinin gelişim sürecine katılımıyla kendi beklentilerini ve gereksinimlerini anlamalarını sağlayacak şekilde adım adım detaylandırılacaktır.

Bu bir sorun mu ?

Başlangıçtaki gereksinimler ne kadar ayrıntılı olursa, belirsizlik ve görevlerin yerine getirilmesi için gereken süre o kadar yüksek olur. Bu yüzden, ek işi kimin yapacağı ve masrafları kimin ödeyeceği meselesi.

Bu iki sorunun cevabı sözleşmede olmalıdır. Yoksa müzakere konusu olur. Ve müşteri ek katılımı kabul etmelidir (temel argüman "daha fazla diplomatik bir şekilde sunmanızı şiddetle tavsiye etmeme rağmen," çöp içeri, çöp dışarı "olacak) ;-)

" Düzenli olarak programlanmış toplantı yok ". O zaman neden düzenli toplantılar düzenleyerek başlamıyorsunuz ? Tek başına birden fazla ürün sahibine sahip olmanız gerçeği, projenizin kolay olmayacağını garanti eder, çünkü bu kişilerin her birinin mevcut tüm paydaşlarla birlikte tartışılması gereken Çatışma gereksinimleri olacaktır.

Ek olarak, gerçekten, gerçekten, gerçekten ayrıntılı bir karar günlüğü tutmanızı tavsiye ederim . En azından birinin karar verdiği her şeyi, karar verildiğinde hazır bulunan kişilerin tarih ve listesini içeren bir yere yazarsınız. Niye bir şey olduğuna karar verildiğine karar verebilirseniz daha da iyi. Bilgisayarınızdaki bir dosya, intranet wiki'nizdeki bir sayfa veya masanızdaki bir dizüstü bilgisayarın önemi yoktur. Kayıt defteri sizi ve projeyi korur: bir test cihazı bazı öğelerin "başarısız" olduğunu söylediğinde, bu kişilerle bu şekilde karar verildiğine işaret edebilirsiniz ve bu sizin sorununuz değil, test ediciler arasında sorun değil. Bu, özelliklerin değişmesine yol açarsa, sorun değil, ancak bu noktada akıllarında bulundukları herhangi bir son tarihi yerine getirmeyi bekleyemezler - veya kapsamı başka bir yerde kesmeleri gerekir.

Net şartlar, gevşek liderlik, hiçbir tanım (DoD) olmayan bir proje , işinizi yapmak için gereken bilgiye sahip olduğunuzdan emin olmak için hiçbir zaman sorumlu olmaya istekli olan herhangi bir kimse , son tarihlerini yerine getirme ve son başvuru tarihine uyma konusunda bir reçetedir. hatası.

Yinelemeli gelişim kötü bir öneri değildir, ancak ürün sahipleri ve geliştiriciler arasında yakın işbirliği gerektirir. "Bir soru soracağımızı biliyoruz. Bunların cevaplandığından emin olmak için düzenli olarak kim bulunabilir ki, böylece proje tesliminde gecikme olmaz?" İlerlemeyi gözden geçirmek ve engelleri kaldırmak için birisiyle düzenli zamanlar ayarlayın. Eğer göstermezler veya reddederlerse, kibar yazılı yazışmalar ve belge gecikmeleri veya cevaplamamaları ile takip edin. Ürün sahipleri uygun değilse, onlardan olabilecek bir temsilci sağlamasını isteyin.

Ayrıca, yinelemeli gelişimin bir diğer özelliği , gereksinimlerdeki bir değişikliğin zaman çizelgesinde bir değişiklik gerektirmesidir. Eğer bir zaman çizelgesi geliştiremezseniz, bir son tarih bulmaya söz veremezsiniz ve yapılması gerekenler hakkında iyi bir fikriniz yoksa bir zaman çizelgesi geliştiremezsiniz. Dogmatik olarak bir özellik istemek yerine, mevcut spesifikasyonu gözden geçirin, sizin veya ekibin nasıl çalışması gerektiği ile ilgili tüm soruları belgeleyin, tartışmak için ürün sahipleriyle zaman planlayın ve cevapları belgeleyin. İşiniz bittiğinde, kararlarını temel alan şartnamelere sahip olacaksınız; bu durumda ürün sahiplerinin de (yazılı olarak) kabul etmelerini sağlayabilirsiniz. Bir özelliğin amacı belirsizliği ortadan kaldırmak ve bir soru-cevap oturumunun tam olarak sağlayabileceği bir DoD oluşturmaktır. Eğer bir belirtime muhalefet varsa, buna bir özellik demeyin.

Kimsenin size kolay olacağını söyledi . Bazen gerçekten göründüğü kadar basit ve bu iman ederler , eğer (ve sadece eğer ben tam olduklarını söyledikleri gibi şartlar gerçekten basit olduğunu güvenmeyi yeterince iyi ürün sahipleri biliyorum) ve gözlük ı olmuştur sağlanan açıklayıcı niteliktedir (eğer değilse, bir soru-cevap oturumu düzenler ve belgelerim). Nerede çok fazla durumlarda bulunmuş kolay bir operasyon açısından ise inanılmaz derecede zorgelişme açısından, ya da tamamen bittiğinizi ve umutsuzluk sözlerini duyduğunuzu düşünüyorsunuz ("Ah, bu arada, biz unuttuk ..."). Örnek ... "Tek yapmanız gereken bu PDF dosyalarını, kabul testi sırasında ortaya çıkan" bir belge deposundan okumak. "Bunların bir kısmının tamamen tutarsız bir şekilde okuduğunu unuttuk ve Bazılarında yanlış sayfa boyutu tanımlanmış ve bazıları bu üç sayfaya eklenmiş ve hepsinin de aynı şekilde görüntülenmesi gerekiyor. Bu düzeltmesi gerçekten kolay, değil mi? "

Mesele şu ki, gerçekten kolay olabilir ve hızlı bir toplantı, tüm varsayımları belgelemenize ve bunların doğru ve doğru olduklarına dair onay almanıza izin verebilir. Beklentilerini karşılayan çalışma kodunu yazmanız gereken engelleri kaldırmak için ayağa kalkmanızı tavsiye ederim, çünkü parmak uçlarına basıp basmamaya bakılmaksızın, birileri muhtemelen sonunda mutsuz olacak. Soruların cevaplandırılması konusunda ısrarcıysanız ve birini sinirlendirirseniz, zamanında gereksinimleri karşılayan harika bir ürün teslim ettiğinizde bunu unutacaklardır. Eğer açıklığa kavuştuğunuzda ve sunmazsanız, hiç kimse size onları rahatsız etmemenizi söylediklerini hatırlamayacaktır.

Spesifikasyon olmadan, takım çalışman var. Çevik ol.

PO ile oturun ve küçük bir başlangıç ​​hikayesi ekleyin. “Biz sadece bu ekranı sunacağız, sadece 'bing!' Düğmesine basan bu düğme ile.” Bazı AC'lere razı olun. Hikayeyi yayınla. Sergilemek hikaye. Düğmelerin kırmızı olması gerektiği ortaya çıktı. Bir böcek veya yeni bir hikaye kaldırın. Nargile ve patlama giden düğmeleri teslim edin. Ve bunun gibi.

Sık sık gösterilen küçük dikey dilimleri birlikte belirleyin ve sunun.

Müşteri sizinle bu şekilde çalışmayacaksa, bir çıkış yolu arayın.

Sizin de belirttiğiniz gibi birkaç işi projeler yaparak geçirdim. PO, hangi tasarım kararlarını verdiğinizi ve neden onları vermek zorunda olduğunuzu bildiği sürece, iyi olmalısınız. Öte yandan, tasarım kararlarını anlamıyorlarsa, en azından yazılı bir kullanıcı kabul testi belgesi için bunlara basmanız gerekir.

Kod yazmaya başlamadan önce ayrıntılı ve doğrulanabilir bir özelliğe ihtiyacınız var. Bu bir gerçek ve etrafta dolaşmak yok.

Başka kimsenin bu özelliği yazmaya istekli olmaması durumunda, geliştiricilerin yazması gerekir. Böylece eksik bir özellik elde edersiniz. Bunu tam bir spesifikasyona dönüştürüyorsunuz (bu "başkası bana yapmamasını söylemediği sürece uygulayacağım şey" anlamına gelir). Bu spesifikasyonu paydaşlara veriyor ve şartnameyi değiştirmeleri için onlara bir şans veriyorsunuz. Spesifikasyonu değiştirmek için sadece bir şans - mesela "Bu şekilde sevmiyorum" diyerek söylemeye gerek yok. Bu noktada, bu sizin spesifikasyonunuzdur veya farklı bir spesifikasyon sağlayabilirler ancak spesifikasyonu kaldıramazlar.

Spesifikasyonu iyileştirebilecek meslektaşlarınızdan hızlı bir inceleme almak iyi bir fikir olabilir. Ama yine de bir özelliğin var, kodu buna göre yaz, testçiler buna göre test et. Ve sen işini yaptın: Bir özelliğin vardı ve onu uyguladın. Teknik özellik müşterinin istediği gibi değilse, ürün sahibinin veya iyi bir teknik özellik belirtme zahmetinde bulunamayan müşterinin sorumluluğundadır.