Scrum takımı YAGNI ilkesine uymuyor

SCRUM toplantısında ürün ekibi, mobil uygulama tarafından tüketilecek bir API'daki bir özellik hakkında tartışıyordu. Ekranın nasıl görünmesi gerektiğini ve hangi temel öğeleri içermesi gerektiğini gösteren bir modelimiz vardı ("düzen").

Buna ve ürün sahibiyle yaptığım tartışmaya dayanarak bir API yanıtı (HAL + JSON) için bir prototip oluşturdum. Çok basit, HAL uyumlu JSON, maketlerdeki şeyleri temsil etmekten başka bir şey yapmadı. Fikirlerini sık sık değiştirme eğilimi gösterdikleri için iş adamları tarafından öngörülen gelecekteki fikirlerden etkilenmedim ve minimalist yaklaşımı benimsemeye karar verdim. Teklifim ekip tarafından reddedildi ve 7'den 1'e reddedildim.

Ekip, yerleşimin düzenlenmesinde daha fazla esneklik sağlayan daha karmaşık, anlamsız soyut json yapısını kullanmaya karar verdi. Bu yaklaşımın dezavantajı, tasarım gereği boş ve boş özelliklere sahip olabilecek bir dizi tek tip nesne ile sonuçlanmış olmamızdır. Ayrıca A / B testini mümkün kılmanın iyi olacağını düşünüyorlardı, ancak sadece böyle bir gereksinimimiz olmadığından tahminlerine dayanıyordu.

Çoğu zaman süratin bir parçası olmayan ya da maketlerde bahsi geçen şeyler hakkında tartışıyorduk. Açıklanan sorunlar "ya gelecekte pazarlama yapacaksa ...", "ya iş yapmamızı isteseydi ..." idi.

Ben ve ürün sahibi deneyimli programcıyız ve geçmişte bu tür sorunları gördük. YAGNI ve KISS ilkelerini takip etmeye çalışıyoruz . Ekibin geri kalanı biraz daha az deneyimlidir ve bu ilkeleri bilmelerine rağmen, onları anlamıyor gibi görünmektedir.

Bir bütün olarak ekip bizim için daha önemli olduğu için onların çözümü üzerinde anlaştık ve o kadar da önemli olmayan bir şeyle savaşmak istemedik. Ama korkuyorum ki böyle bir şey yeni çıkan, daha karmaşık tartışmalar için bir emsal olabilir mi? Böyle bir davranışla nasıl başa çıkılır? Takım lideri olarak daha iyisini yapabileceğim bir şey var mı?

Ürünün erken aşamada bir MVP olduğunu belirtmek gerekir.

Acını hissediyorum, orada bulundum. IMHO, bu tür sorunlara, her zaman en iyi stratejik kararları vermenize izin veremeyecek kadar büyük olan 8 kişilik bir ekibiniz olması nedeniyledir.

8 veya daha fazla şansa sahip bir ekipte vasat programcıların sayısı deneyimli olanlardan daha fazladır. Bu genellikle daha iyi kararların vasat kararlar tarafından aşıldığı durumlara yol açacaktır. Bu, özellikle daha deneyimli adamlardan biri olduğunuzda (veya olduğunuzu düşünüyorsanız) tatmin edici görünmüyor, ancak en azından aynı şey gerçekten kötü kararlar için genellikle doğrudur.

Gerçek şu ki, takım değişmediği sürece , en azından işler demokratik kalacaksa, bu konuda yapabileceğiniz çok şey yoktur.

• Onunla yaşamayı öğren
• bir veya iki yıl boyunca ekiple birlikte çalışın, kendi uzmanlığınızı paylaşın ve zaman içinde YAGNI ve KISS'in değerini öğrendiklerini umuyoruz
• ekibe tasarım veya stratejik kararları "satma" becerileriniz üzerinde çalışın
• kendi uzmanlık seviyenizin tüm ekibin ortalamasına yakın olduğu farklı (belki daha küçük) bir takıma geçmeye çalışın

Minimalist bir yaklaşımın gerçek değerini öğrenmenin ve anlamanın tek yolunun ve YAGNI'nın bazı deneyimleri birinci elden yapmak olduğunu düşünüyorum. Örneğin, bir çok yanlış "ne olursa olsun" tahminleri olan eski bir sistemin bakımına dahil olarak, "her ihtimale karşı" argümanları tarafından motive edilen yanlış tasarım kararları veya aslında hiçbir zaman ihtiyaç duyulmayan aşırı genelleştirilmiş çerçeve kodu içeren. Ancak bu, iki gün içinde ekip üyelerinize öğretebileceğiniz hiçbir şey değildir; insanların kendi başlarına yapmaları gereken bazı deneyimler.

İleri uyumluluk meşru bir sorundur

Sizi geride bırakan yedi geliştiriciden biri mimarsa , NFR'leri gerektiği gibi tanıtmak onun hakkıdır ve bu NFR'lerden biri, özellikle daha seyrek olabilen bir uzak sistem bileşenini desteklediğinizde "ileri uyumluluk" olabilir. çıkış programı. İleriyi düşünmediğiniz için kullanıcıların bir uygulamanın yeni bir sürümünü yüklemesini istemezsiniz.

Diğer şartlar gibi, kabul kriterlerine de ihtiyacınız var

Bununla birlikte, herhangi bir UFR, gereklilik olarak belgelenmeli ve tanımlanmış kabul kriterlerine sahip olmalıdır . Ayrıca, bunları test etmek için bir araç bulmalısınız . Bu yüzden YAGNI önemlidir - test edilemeyen kod yazmak istemezsiniz ve kodun tek amacı kimsenin kullanmadığı bir özelliği desteklemekse, test etmek zordur.

Bir karar çağrısı olmamalı

Ekibin, görünüşte kaçırdığınız ve bunu yazdığınız söz edilmeyen gereksinimi kabul etmesini öneririm. Test etme yöntemlerini tanımladıktan sonra, uygulamanız en az bir testten geçmemelidir ve bu nedenle bir oylama konusu olmamalıdır.

Görünüşe göre ürün ekibinin sahip olmak istediği hızlı deneme denemelerini sağlayan bir çerçeve oluşturarak geliştirme ekibiniz ürün ekibini kolaylaştırmaya çalışıyor gibi görünüyor. Yaklaşımınız "tam olarak onlara ne istediklerini verin ve onlar için düşünmeyin" gibidir.

Eğer ürün sahibi olsaydım ilk yaklaşımı benimseyen bir geliştirme ekibinden çok daha mutlu olurdum.

Benim düşüncem demokrasinin düzgün çalışmadığıdır - ne siyasal sistemde ne de çoğu programcının genç veya vasat olduğu bir ekipte.

Takım lideri olarak ve bir takımdaki en deneyimli kişilerden biri olan sözünüz, ekibin geri kalanından daha yüksek etkiye sahip olmalıdır. YAGNI sizin için önemliyse, o zaman bir sunum yapmalısınız. Bunun hakkında tartışın ve onlara neden iyi olduğunu gösterin.

Sonuçta, sorumluluğunuz diğer insanlardan daha yüksektir. Sadece kod yazmak değil, aynı zamanda insanlara da rehberlik etmek.

YAGNI hakkında biraz karışıklık olduğunu düşünüyorum.

Geliştiriciler genellikle sistemi "değişiklik için kapalı ve uzamaya açık" tutacak soyutlamaları göz ardı ettiklerinde YAGNI'yı takip ettiklerini düşünürler.

Sistemi "açıkça" talep edilmeyen bir işlevle "genişletmediğiniz" sürece YAGNI ile ilgilenmezsiniz. Uzatmanın meydana gelebileceği soyutlamalara giriş, daha önce bahsedilen "ileri uyumluluk" dur.

Benim kişisel görüşüm, alan hakkında sadece derin bir bilginin soyutlama ve nerede bulunacağı konusunda kararlar almaya yardımcı olacağıdır.

YAGNI VE KISS ile ilgili sorun tamamen öznel ve belirsiz olmalarıdır.

json ?? YAGNI! sadece bir csv dizesi gönderin!

nesneleri ?? KISSTUPID !!! sadece gotos kullanın !!

'Takım Lideri' rolü iyi tanımlanmamıştır, ancak takımınızın teknik tercihleri ​​hakkında öznel görüşlerinizi ifade etmekten uzaklaşmanızı öneririm. Yanlış hissetmiş olsanız bile. İyi tanımlanmış gereksinimlerin kısa bir listesine sadık kalın.

• kod için birim testleri
• apis için entegrasyon testleri
• son ürün için otomatik kullanıcı arayüzü testleri
• performans ve ölçeklendirme gereksinimleri

ekip, tüm iş gereksinimleri ve ölçekli teknik gereksinimlerdeki temel performans için başarılı testler gerçekleştirebilirse, çalışan bir ürününüz vardır.

Bundan sonra sadece aynı şeyi yapmak için bastırıyor

Takımda herkes gerekir katılıyorum yapmaktan tanımı . Bu olmadan, büyük miktarda kapsam sürünmesine, bakış açılarına ve temel gereksinimlerin piç haline getirilmesine eğilimlisiniz.

Bunun üzerinde ve üzerinde yapılan her şey, kendisinin de kendi tanımına sahip olacak biriktirme listesinde olmalıdır.

Önceliklere gelince, MoSCoW yöntemi bize her zaman iyi hizmet etti - YMMV.

Bununla ilgili ilk düşüncem ... Takım neden değişikliklerle ilgileniyor? Gelecekteki geliştirmeleri daha kolay hale getirmek için ilk yapılandırmayı biraz daha yapılandırılabilir hale getirmek için ihtiyaç duyduklarını hissettiren Ürün Sahibi hakkında tarihi bir anlayışları var mı? Çözümünüz 2 gün sürecek ve 5 gün sürecekse, evet, iki kat daha uzun. Ancak, planınızın değiştirilmesi her seferinde 2 gün sürecek, ancak planlarında bir iyileştirme 1 gün sürecekse, planları uzun mesafe boyunca daha verimli görünüyor. Bu soruda DOĞRU veya YANLIŞ bir karar olduğunu düşünmüyorum. Diğer faktörlere bağlıdır, IMHO. Bununla birlikte, diğer çözümlerde bunu yapmak için herhangi bir doğrudan rehberlik olmadan LOE'yi iki katına çıkarırlarsa, bu zihniyet hakkında DOĞRUDUR (ölçeklenebilirlik, sağlamlık vb. İçin ek karmaşıklığın gerekli olduğuna dair bazı kanıtlar). Benim önerim, ürün sahibini bu görüşmelere dahil etmek olacaktır, çünkü önceliklendirmeye yardımcı olmaları gerekir. Çözümünüz 5 puan ise ve şimdi ihtiyacı karşılayacaksa, ancak yapmak istedikleri şey 50 puan ve iki sprint veya daha fazla gerektirirse, PO "bekle, planlanan bu MVP'nin yüksek öncelikli bir sürümüne sahibiz ve yol haritası üzerinde olmayan işlevselliği geliştirmek için 2 hafta harcayamam! "