Scrum sprintlerindeki ekstra kozmetik özellikleri nasıl ele almalıyız?

Scrum belgelerini okuyordum ve Sprint'teki görevlerin "potansiyel olarak sevk edilebilir" olması gerektiğini söylüyor.

Bunun anlamı ile kafam karıştı. Sprint 1'de hedefin "kullanıcı kayıt formu" olduğunu varsayalım.

Bir şeyin gönderilmeye hazır olması için ne kadar ayrıntı eklemem gerekir? Örneğin:

1. Herhangi bir süslü stil olmadan basit formu alanları ile gösterebilir ve bitti olarak işaretleyebilirim
2. Istemci tarafı doğrulama olarak işareti olarak yapabilirsiniz ama sunucu tarafı da seçenek veya her ikisi de
3. Ayrıca bazı jQuery fantezi araç ipuçları, fareyle üzerine gelme, captcha, renkler, form için etiketler ekleyebilirim
4. Sonra ekranda hata mesajlarının nasıl gösterileceği hakkında çok fazla stil var

Sonsuza dek tek bir konuda yapabilirim. Peki bunu nasıl bölebiliriz ve bunu ne zaman hazır nakliye olarak düşünebilirim.

Ya da hataları, açılır pencereyi veya ışık kutusu metnini alt görevler olarak gösterme ve bunları sprint olarak koyma gibi mümkün olan en küçük şeyleri yazmam gerekir mi? Bu, tüm proje için 1000 görev gerektirecektir.

Demek istediğim, yine Internet Explorer için ve bazıları Firefox için çalışıyorsa, bunları yine görevler olarak bölmeliyim. Onlara zaman harcanmalı ve yönetici bana o zaman ne yaptığınızı sorduğunda, anlatacağım herhangi bir görevim olmayacak, ancak gerçekte hepsi Kullanıcı kaydının bir parçası

Bunu internet değil ürün sahibi ve Scrum ekibi ile kabul edin. Bu, Bitti Tanımınızda belirlenmelidir ve büyük ölçüde ekibin nasıl çalıştığına bağlı olacaktır.

Özelliğin 'gönderilebilir' olmasına rağmen ( Scrum'da bu terimden nefret ediyorum), işlevselliğin kullanıcı arayüzü olmadan gönderilebileceği iddia edilebilir. Scrum'da birçok insan bu yanlış anlamadan muzdariptir - bir sprintin amacı mümkün olduğunca çok hikaye (ideal olarak hepsi) 'Bitti' olmaktır, ancak kesinlikle serbest bırakılabilecek bir şeye inşa edilmesi gerekmez.

Bunun gibi şeyleri erkenden ütülemek önemlidir, bu nedenle takımdaki herkes ortak bir hedef için çalışıyor. Scrum'ın ahlakı iletişimdir, bu yüzden Scrum ekibine sorun ve mantıklı bir sonuç çıkarın.

Kullanıcı arayüzünün genellikle ayrı ayrı ele alındığı bir ekipte çalışabilirsiniz, örneğin farklı bir ekip tarafından veya kullanıcı arayüzü uzmanları formun nasıl görünmesi gerektiğine karar verdikten sonra vb. Alternatif olarak, küçük bir projede / ekipte kullanıcı arayüzünün sizin gibi oluşturulması beklenebilir Git.

Takımın cevabı bildiği sürece, cevabın ne olduğu önemsizdir.

Kozmetik özellikler özelliğin bir parçasıysa, muhtemelen hikayenin bir parçası olarak yapılmalıdır. Mesele şu ki, bir hikaye bittiğini söyledikten sonra, belirli bir özellik üzerinde daha fazla kodlama yapmak zorunda kalmamanız gerekir. Bununla birlikte, sonuçta bu ürün sahibi tarafından kararlaştırılır - kozmetik özellikleri isteyebilirler veya istemeyebilirler. Bu kabul kriterlerinde belirtilmelidir.

Bu, son kullanıcının kullanımına hazır olduğu anlamına gelmez, sadece birisine hazır olduğu anlamına gelir . Birisinin bir testçi veya arka uç ekibi gibi başka bir ekip olabileceğini.

Bunu bir geliştirici olarak soruyorsanız, cevap "bilirsiniz, çünkü ürün sahibi kozmetik özellikleri isteyip istemediklerini size söyleyecektir".

Bunu bir ürün sahibi olarak soruyorsanız, özelliği birden fazla hikayeye bölmek isteyip istemediğinize karar vermeniz yeterlidir. Müşterinizi tatmin etmenin bir yolu olarak sizi tatmin etmesinin dışında bir gereklilik yoktur .

Unutmayın: Amaç kesinlikle karışmak değil. Amaç, son kullanıcıya yüksek kaliteli yazılım sunmaktır. Böyle sorularla uğraşırken bunu bir rehber olarak kullanın. Tamamen işlevsel parçalarla aynı hikayeye kozmetik eklemek, müşterinize kalite kodu sunmanıza yardımcı olur mu? Yoksa bunu iki katına ayırmak yardımcı olur mu? Ya cevap açık, ya da önemli değil ve ekibiniz için uygun olan her şeyi yapabilirsiniz.

"Potansiyel olarak gönderilebilir", sevkıyat yapabileceğiniz anlamına gelmez, göndereceğiniz bir şey değildir. Örneğin:

Bir okul projesi gibi bazı durumlar için korkunç görünen ve hiçbir doğrulaması olmayan bir web kayıt formu iyi olabilir, ancak milyonlarca dolarlık bir işte, son kullanıcılara göstermek için markaya zarar verir. Kod, göndermek istediğiniz bir şey olmadan gönderilebilir veya bu pazarlama veya yasal, göndermenize izin verir.

Programcıların (ve bu noktada süreçte olan diğer insanların, örneğin tasarımcılar), şu anda olduğu gibi serbest bırakılmasından mutluluk duyacağı bir şeydir; herhangi birine gönderilmeden önce diğer dillere çevrilmesi gerekir - Kanada, İngilizce satın aldığı kadar Fransızca'yı da dikkate alan Hükümet satın alma yazılımı hakkında katı kurallara sahiptir).

Bu bir kalite kontrol noktasıdır, herkesin gözüne bakarsınız ve şu anda olduğu gibi göndermekten mutlu olup olmadıklarını soruyorsunuz, ekstra bir iş yapmadan, son bir şey yapıp yapmadığını görmek için kontrol yok. Bunu uçak mühendisi kontrol noktası olarak duydum. Gözünüzde bir mühendis görünüyor ve test uçuşunda size eşlik etmek isteyip istemediklerini soruyorsunuz.

Fikir olabildiğince Çevik olmaktır. Daha hızlı gerçek kullanıcılara bir şeyler alabilirsiniz; Bu, bireyleri seçmek için kodun beta kopyası mı yoksa web sitenizde A / B testi mi, o kadar iyi olur. Kullanıcılara, ürününüze ilişkin beklentileriyle tanımlanan çok kaba, kaba kodlar gösterirseniz, size işe yaramaz geri bildirimde bulunurlar. Onlar hakkında bilgi aramamanız gereken şeyler hakkında konuşacaklar: düğmenin sarı olması veya metin kutusunun etiketlerle hizalanmasını sevmiyorlar. Yeterince iyi ise, yararlı geri bildirim alabilirsiniz. Bu geribildirimi ne kadar hızlı alırsanız o kadar iyi olur! Ürün / pazar uyumunu ve oluşturmaya çalıştığınız özellik hakkında yaptığınız varsayımları doğrulayabilirsiniz.

Özelliğin gönderilmesi bunun en az önemli kısmıdır. Geliştirme ekibini hareket ettirmek ve Kullanıcı Öyküleri'ni bitirmek önemlidir. Bir şeyin yapıldığını iddia edebileceğiniz noktaya gelmek harika bir motivasyon kaynağıdır.

Anladığım kadarıyla, her hikaye , son kullanıcı değil , birileri tarafından tüketilmeye hazır olduğu ölçüde "yapılabilir" ve "gönderilebilir" olmalıdır . Bu nedenle, öykünüz daha sonra ürün sahibine teslim edilebilecek ve son kullanıcılara bırakılmasını veya özellik üzerinden tekrarlanmasını seçebilecek bazı işlevler sunabilir.

Bununla birlikte, "Son kullanıcı olarak kaydolabileceğim" hikayesine stil eklemeniz engellenmedi . Ekibimizde, daha yüksek öngörülebilirliği korumak ve söz verdiğimizi sunabilmemizi daha iyi sağlamak için her hikayeyi mümkün olduğunca küçük yapmaya çalışıyoruz. Önümüzde hazır bir tasarımımız varsa ve uygulanmasının önemsiz olduğunu düşünüyorsanız, hikayeye dahil edilir. Tasarımda bazı tekrarlamalar olabileceğini düşünürsek, bu ayrı bir hikaye - muhtemelen çoklu.

Bu soruya verilen diğer harika cevapların yanı sıra, kozmetik özellikleri kapsam-kaynak-zaman üçgeninin değişken kapsam kısmı olarak da düşünebilirsiniz. Bu hikayenin temel gereksinimlerini yerine getirdiğinizden emin olun ve zamanınız varsa güzel şeyleri ekleyin.

Scrum'ın belirli özelliklerin belirli bir sürede teslim edilmesini garanti etmesi beklenmemektedir. Belirli bir zamanda mümkün olan maksimum yararlı işi vermeniz gerekiyor. "İsteğe bağlı" kozmetik özellikleri olduğu sürat sırasında halletmek yoksa, o gerektiğini onlar mümkün değildi çünkü olun.

Şartları belirleyen kişiye, "ürün sahibine" bağlıdır. Bir programcı olarak, web hizmetlerimdeki iş mantığının doğru çalıştığını kanıtlayan ve kayıt işleminin sistemdeki diğer kaynaklara karşı kimlik doğrulaması yapılmasına olanak tanıyan, stilsiz bir "kayıt formu" sayfasıyla memnun olabilirim. Aslında, "potansiyel olarak gönderilebilir", kelimenin tam anlamıyla bir müşteriye göndereceğimiz anlamına gelmediğinden, bunun özellikle teknik ekip ve tasarım ekibi ayrı biriken işler içeren ayrı kaynaklardır.

Daha olgun bir projede, özelliğin en az stil ile "geliştirici tarafından tasarlanmış" bir sürümünü bir pilot veya beta istemcisine gönderebilirsiniz, ancak aynı işlevi hem işlevsellik değişiklikleri (geri bildirime dayalı) hem de tasarım tamamlanması için tekrar ziyaret edebilirsiniz.

Agile metodolojisinin amacı, gereksinimlerinizin tersine değil, yazılım geliştirme sürecini yönlendirmesine izin vermektir. Metodolojinin bir tanımının Gerçek ve Tek Ortodoks Gereksinimi olduğunu varsaymak tuzağına düşmeyin. Elbette söylenenden daha kolay, özellikle Scrum'ın geliştirme ekibine kaos uygulamak için bir bahane olduğu büyük bir organizasyondaysanız.