Çevik - Neyi yanlış yapıyoruz?

Çevik bir ekipte geliştiriciyim ve Scrum'u kullanmaya çalışıyoruz.

Bu yüzden, durumu açıklamak için varsayımsal bir problem ortaya koyacağım.

Bazı dağınık ve kötü bakım JQuery kodunu kullanarak, çok eski bir uygulama var. Ayrıca React'i kullanarak uygulamanın bazı bölümlerine sahibiz ve bu bölümlerin güncellenmesi / bakımı çok daha kolaydır. Bunun yanı sıra, şirketin amacı, React'te müşteriye tek sayfalık bir uygulama yapmak, böylece JQuery kullanmak sizi bundan daha da uzaklaştıracak.

Planlamayı yaptığımızda, geliştirme zamanı açısından her zaman kolay bir çözüme gideriz, bu nedenle, örneğin yeni bir diyalog veya başka bir şey yapıyorsak, eski JQuery'yi kullanırız, çünkü daha hızlıdır ve geri döndüğümüzü söyleriz. daha sonra toparlayıp React'e dönüşecek, ancak bu nadiren gerçekleşecek.

Kullanıcı hikayelerinden ne yapmak zorunda olduğumuzun gerekliliklerini karşılıyoruz (ki bunlar IMO'yu iyi yapıyorlar, zayıflar ama ne yaptığımızı ve neden yaptığımızı açıklıyorlar).

Bazen, yeni özelliklerin gereksinimleri çok incedir, bu nedenle, örneğin bir gereksinim "tonlarca içerik yükleyen bir iletişim kutusu oluştur" diyor ancak bir yükleme özelliği uygulama demiyorsa, çoğu durumda bunu uygulamaz , hepimiz bunun müşteriler için daha iyi olacağını bilmemize rağmen, bunun sprint hedefimizi tehlikeye atabilmesi nedeniyle (şahsen buna inanmayacağımı bile olsa).

Sonuç, kod tabanımızın çok kötü bakım yapılabilirliğe sahip büyük bir karmaşa olduğudur ve yeni özellikler bazen çok küçüktür ve temel olarak bu gelişme nedeniyle (tek bir günde iyi bir kod tabanında elde edilebilecek bir şey) yapmak için tam bir sürat harcıyor. Strateji, sadece hızlı gitmek, en az düzeyde.

Bu durumda ne yapıyoruz? Çözümleri daha eksiksiz bir şekilde ele almalı mıyız, bu yüzden geçen hafta yazdığımız kötü kodları ve yeniden kodları yazmıyoruz değil mi? Yoksa tüm bu kodun tekrar yazıldığından emin olarak bunu yapmaya devam mı edelim? Bu soruna iyi bir çevik yaklaşım ne olabilir?

Bunun Çevik veya Scrum ile ilgisi yok.

"Koli bantı şimdi ve sonra düzelteceğiz" ile ilgili sorun, daha sonra asla gelmeyeceği ve bu arada çok fazla teknik borç biriktirdiğinizdir .

İyileşmenin ilk adımı sorunu tanımak ve daha da kötüleşmeyi bırakmaktır.

Her yeni kullanıcı hikayesi için ekip, "bunu kodlamanın en hızlı yolu nedir?" Değil, "bunu kodlamanın doğru yolu nedir?" Diye düşünmelidir. ve sprintleri buna göre planlayın.

Mevcut sorunu temizlemek için 200K satırlık spagetti kodunu miras aldığımın mükemmel cevaplarına bakın - şimdi ne olacak?

Elinde ne var Martin Fowler'ın “gevşek frum” dediği şey.

Çevik Manifesto'nun arkasındaki 12 İlkenin tümünü doğru okuduysanız , çoğu zaman başarısız olduğunuzu göreceksiniz.

Çalışma yazılımını, daha kısa zaman çizelgesini tercih ederek birkaç haftadan birkaç aya kadar sık ​​sık gönderin.

Gerçekten çalışan bir yazılım teslim ettiğinizi söyleyebilir misiniz? Ya da sadece zar zor çalışan bir yazılım mı?

Çevik süreçler sürdürülebilir kalkınmayı teşvik eder. Sponsorlar, geliştiriciler ve kullanıcılar, süresiz olarak sabit bir hızda kalabilmelidir.

Sürecin sürdürülebilir olduğunu söyleyebilir misiniz? Sürdürülebilirlikle ilgili kararlar alıyor musunuz? Yoksa uzun vadeli etkileri hesaba katmadan mevcut sorunu çözen çözümler mi seçiyorsunuz?

Teknik mükemmellik ve iyi tasarıma sürekli ilgi, çevikliği arttırır.

Gerçekten büyük ilke. Bunun, sayfadaki BÜYÜK KIRMIZI MEKTUPLAR'a konulması gerektiğine inanıyorum. En çok başarısız olduğun yer burası.

Düzenli aralıklarla, ekip nasıl daha etkili olacağına karar verir, sonra davranışını buna göre ayarlar ve ayarlar.

Ve en açıkçası. Davranışınızın istenen sonuçlara yol açmadığını öğrenirseniz, onu değiştirmelisiniz. Ekibiniz problem yaşadığını göremiyorsa, düzeltmeye başlayamaz.

Yorumunuzdan

Çevik bu nasıl önlenir?

İlk olarak, çevikliğin gerçekte ne olduğunu öğrenerek. Scrum çevik değildir. Bazıları, Scrum'un çevreniz çerçevelerin en kötüsü olduğunu söyleyebilir, tam durumunuza ulaşmak çok kolay. Diğer çevik çerçeveler hakkında bilgi edinmelisin. Tavsiye ederim Ekstrem Programlama. Bu açıkça problemlerinizi çözer. Çözümler basit değildir (güçlü otomatik testler, çift programlama ve sürekli teslimat yoluyla teknik mükemmelliğe odaklanın), ancak oldukça etkilidir. DevOps Devlet raporunda bildirildiği gibi .

Tanımladığınız şey - en azından benim tecrübeme göre - "Çevik" olmaya çalışan ekiplerin oldukça yaygın bir ortaya çıkması. Bu aslında Çevik'in bir parçası mı yoksa ortak bir yanlış uygulaması mı, çevik tezahür / ilkelere ya da onun doğal bir sonucuna karşı olup olmadığını tartışmaya açıktır. Sadece ampirik bir bakış açısıyla ve sadece kendi küçük örneklem deneyimimden (ve konuştuğum kişilerden) yola çıkarak, eğer bir takım çevikse, bu kalıba girme şansının ortalamadan daha yüksek olduğu görülüyor. Sadece bunu bırakalım ve somut örneğinize odaklanalım.

Tanımladığınız şeyin iki ayrı yönü vardır :

• Ortak anlayış / vizyonun eksik olması ve bu nedenle etkin olmamak
• Başarı / ilerleme ve toplam maliyet nasıl ölçülür?

Yanlış yolda ilerlemek veya dairelerde koşmak

Tecrübelerime göre, bunun gerçekleşmesinin ana nedeni, hızlı bir şekilde kod üretme girişiminde, ekiplerin aktif olarak zaten bildikleri veya kolayca öğrenebilecekleri kullanım durumlarını veya gereksinimlerini bir kenara itmeleridir . Bunu böyle düşünün: 10-20 yıl önce, insanlar devasa özellikler yazmaya ve her şeyi önceden düşünmeye çalıştı ve çoğu zaman başarısız oldu. Ya çok uzun sürdüler ya da bir şeyi gözden kaçırdılar. Geçmişin öğrendiklerinden biri, yazılım geliştirmede bilemeyeceğiniz şeyler olduğu ve her şeyin çok değiştiği, dolayısıyla hızlı bir şekilde yineleme ve hızlıca mantıklı bir çıktı üretme düşüncesidir. Bu çok iyi bir ilkedir. Ama bugün, diğer uç noktadayız: "Bunu bir sonraki süvarinin parçası olduğu için umursamıyorum" veya "O böceği dosyalamıyorum, tekrar ortaya çıktığında başa çıkıyorum".

1. Bulabileceğiniz tüm üst düzey kullanım durumlarını , gereksinimleri, bağımlılıkları ve kısıtlamaları toplayın . Bunu bir wiki'ye koyun böylece tüm paydaşlar ve dev'ler onları görebilir. Yeni bir şey çıktığında onlara ekleyin. Ortaklarınız ve kullanıcılarınızla konuşun. Bunu, nihai ürüne katkıda bulunmayan veya bir sorunu çözen, ancak üç yenisine neden olan geçici çözümler / kesitler olan şeylerin uygulanmasını önlemek için geliştirirken kontrol listesi olarak kullanın .
2. Üst düzey bir konsept formüle edin . Arayüzler veya sınıflar tasarlamaktan bahsetmiyorum, bunun yerine problem alanını kabaca çiziyorum. Son çözümde ana unsurlar, mekanizma ve etkileşimler nelerdir? Sizin durumunuzda, jquery-geçici çözümünü kullanırken bir ara adım olarak kullanıldığında ve yalnızca ek çalışmaya neden olduğu zaman açıkça anlaşılmalıdır.
3. Topladığınız listeyi kullanarak konseptinizi doğrulayın . Herhangi bir belirgin problem var mı? Mantıklı geliyor? Uzun zamandır teknoloji borcuna neden olmadan aynı kullanıcı değerini elde etmenin daha etkili yolları var mı?

Fazla abartma. Sadece bir şeye ihtiyacın var, takımdaki herkes (dev olmayanlar da dahil), MVP'nize en iyi yolun ne olduğu konusunda ortak bir anlayışa sahip. Herkes göze çarpan bir gözetim olmadığı ve gerçekte işe yarayabileceği konusunda hemfikir olmalıdır. Bu, genel olarak, çıkmazların aşağı inmesini önlemeye veya aynı şeyi birden çok kez yinelemeye yardımcı olur. Çevik, beklenmedik durumlarla daha iyi başa çıkmanıza yardımcı olabilir, bilinenleri görmezden gelmek tartışılmaz.

Düşük maliyetli yanlışlığın farkında olun : Bir mimari veya veri tabanı türüyle başlarsanız, çoğu insan proje ortasında değiştirmekte tereddüt eder. Bu yüzden, bazı şeyleri uygulamaya başlamadan önce "eğitimli en iyi tahminde bulunmak" için biraz zaman harcamak iyi bir fikirdir. Devs, hızlı bir şekilde kod yazmak isteme eğilimindedir. Ancak çoğu zaman birkaç sahtekarlık, canlı prototip, ekran görüntüsü, tel kafes vb. Olması kod yazmadan daha hızlı yinelemeye izin verir. Sadece yazılı her kod satırının ve hatta birim testlerinin genel konseptinizi tekrar değiştirmeyi zorlaştırdığının farkında olun.

Başarı Ölçümü

Tamamen ayrı bir özellik, ilerlemeyi nasıl ölçtüğünüzdür. Diyelim ki projenizin amacı etrafta yatan şeyleri kullanarak 1 metre yüksekliğinde bir kule inşa etmektir. Bir kart evi inşa etmek, örneğin pazara çıkış zamanı istikrardan daha önemliyse, tamamen geçerli bir çözüm olabilir. Amacınız süren bir şey inşa etmek ise, Lego'yu kullanmak daha iyi olurdu. Mesele şudur: Ne hack olarak kabul edilir ve ne zarif bir çözüm, tamamen projenin başarısının ölçülmesine bağlıdır .

"Yükleme" örneğiniz oldukça iyi. Geçmişte herkesin (satışlar, PO, kullanıcılar dahil) can sıkıcı olduğu konusunda hemfikir olduğu böyle şeyler vardı. Ancak ürünün başarısı üzerinde hiçbir etkisi olmadı ve uzun vadeli borçlanmalara neden olmadı. Bu yüzden düşürdük, çünkü dev kaynaklarla yapacak daha değerli şeyler vardı.

Buradaki tavsiyem:

1. Her şeyi, küçük böcekleri bile, bilet sisteminizde bilet olarak saklayın . Proje kapsamında neyin olup olmadığına dair aktif bir karar verin. Kilometre taşları oluşturun veya aksi halde birikiminizi filtreleyin, böylece her zaman hala yapılması gereken her şeyin "eksiksiz" bir listesine sahip olursunuz.
2. Projenin başarılı sayılabileceği kesin bir önem sırasına ve kesin kesinliğe sahip olun. Nihai ürünün gerçekte hangi seviyede istikrar / kod kalitesi / dokümantasyonu ihtiyacı var? Her gün çalışmayı en baştan seçerek mümkün olan en iyi şekilde geçirmeye çalışın. Bir bilet üzerinde çalışırken, yeni biletler sunmadan tamamen çözmeye çalışın (düşük öncelik nedeniyle işleri ertelemek mantıklı değilse). Her söz sizi yanlara veya geriye doğru değil, son hedefinize doğru ilerletmelidir. Ancak tekrar vurgulamak için: bazen daha sonra ek iş üreten bir kesmek yine de proje için net bir pozitif olabilir!
3. Kullanıcı değerini bulmak için PO'yu / kullanıcılarını kullan, ama aynı zamanda cihazlarının maliyetini hesapla . Dev-dev olmayanlar tipik olarak gerçek uzun vadeli maliyetin (sadece uygulama maliyeti değil) ne olduğunu yargılayamazlar, o yüzden onlara yardım et. Kaynayan kurbağa sorununun farkında olun: Çok az sayıda küçük, alakasız sorun zaman içinde bir takımı beklemeye götürebilir. Takımınızın ne kadar verimli çalışabileceğini ölçmeye çalışın.
4. Genel hedef / maliyetlere göz atın. Sprint'ten sprint'e düşünmek yerine , "bir ekip olarak projenin sonuna kadar ihtiyaç duyduğumuz her şeyi yapabilir miyiz" düşüncesini bir zihniyette tutun . Sprintler, işleri yıkmanın ve kontrol noktalarına sahip olmanın bir yoludur.
5. Erken bir şey göstermek istemek yerine, rotanızı , kullanıcıya verilebilecek asgari uygulanabilir bir ürüne giden en hızlı yolda çizin . Yine de, genel stratejiniz aradaki doğrulanabilir sonuçlara izin vermelidir.

Bu yüzden, birisi nihai uygulama hedefinize uymayan bir şey yaptığında, ideal olarak yapılan hikayeyi göz önünde bulundurmayın. Hikayeyi kapatmanın yararı varsa (örneğin, müşterilerden geri bildirim almak için), kısa zamanda cevap vermek için derhal yeni bir hikaye / hata açın. Kısayolları almanın maliyetleri düşürmediğini, sadece gizlediğini veya geciktirdiğini şeffaf hale getirin!

Buradaki hüner, projenin toplam maliyeti ile tartışmaktır: örneğin eğer bir PO bir son tarih vermek için kısayollar almaya zorlarsa, projeyi değerlendirmek için daha sonra yapılması gereken iş miktarını ölçün!

Ayrıca kritere dayalı optimizasyondan sakının : ekibiniz bir sprint incelemesinde gösterebilecekleri hikaye sayısıyla ölçülürse, iyi bir "puan" elde etmenin en iyi yolu, her hikayeyi on küçük parçaya bölmektir. Yazılan birim test sayısı ile ölçülürse, pek çok gereksiz testler yazma eğiliminde olacaktır. Hikayeleri saymayın, ihtiyaç duyulan kullanıcı işlevselliğinin ne kadarının çalıştığını, proje kapsamındaki teknik borcun maliyetinin ne kadar büyük olduğunu ölçün.

özet

Kaynatmak için: Hızlı ve minimal olmak iyi bir yaklaşımdır. T o sorun "hızlı" yorumlama ve "minimal" içindedir. Kişi her zaman uzun vadeli maliyeti göz önünde bulundurmalıdır (bunun alakasız olduğu bir projeniz yoksa). Sadece 1 gün süren, ancak teslimat tarihinden 1 ay sonra teknik borç üreten bir kısayol kullanmak şirketinize 1 hafta süren bir çözümden daha pahalıya mal olur. Derhal yazmaya başlayın testleri hızlı görünüyor, ancak kavramınız hatalıysa ve yanlış bir yaklaşıma neden oluyorsa.

Ve sizin durumunuzda "uzun süreli" nin ne anlama geldiğini aklınızda bulundurun: Büyük kod yazmaya çalışarak büsten birden fazla şirket biliyorum ve bu nedenle çok geç sevk edildi. İyi bir mimari veya temiz kod - şirket açısından - ancak bunu başarmanın maliyeti, sahip olmamanın maliyetinden azsa değerlidir.

Umarım yardımcı olur!

Ne yanlış yapıyoruz olduğu gibi Kesin bir saldırı açısından, bu çalışma değiliz sesler ile istemci. Onların ne bir anlayış gelmek için müşteri ile birlikte çalışması gerekir ihtiyaç onlar sadece ne olup istiyorum . Bir dizi hızlı düzeltmeye mi ihtiyaç duyuyorlar ya da uzun vadede onlara hizmet edecek istikrarlı, bakımı yapılabilir bir sisteme mi ihtiyaç duyuyorlar? Bunu belirlemek zor olabilir, ancak kalite, arka plan rengi veya performans kıyaslaması kadar bir zorunluluktur. Müşterinin kararlılık ve bakımın ücretsiz olmadığını ve üründe tasarlanması gerektiğini bilmesi gerekir.

Eski olduğunu söylerlerse, yanlış bir şey yapmıyorsunuzdur - sprint incelemelerinde onlara, hedeflerine ulaşmak için mühendislik köşelerini kestiğinizi açıkladığınızı varsayarsak.

İkincisi olduğunu söylerlerse, o zaman yanlış yaptığınız şey, onlara istediklerini vermemenizdir.

Scrum'un temel taşlarından biri şeffaflıktır. Scrum yapıyorsanız, müşteriyle sprint incelemeleri yapıyor olmalısınız. Bu incelemelerde, müşteriye yazılımı daha hızlı teslim edebilmek için köşeleri kestiğinizi mi söylüyorsunuz? Olmazsa, olmalısın. Müşterilerinizle birlikte tasarım tercihlerinizin sonuçları hakkında% 100 açık olmanız, yazılımınızı uygun kalitede bir kalite ile teslim edip etmediğiniz konusunda bilinçli bir karar vermelerine olanak tanımanız gerekir.

Ewan haklı. Yönetimin azarlamaktan hoşlanmasının nedeni staccato tarzında özellik talep etmeleri ve hızlıca sonuç almalarıdır. Ortaya çıkan karmaşaya kadar biri başkası problemi olana kadar.

Şimdi dikkatini çektim, lütfen açıklamama izin ver. Öyle Scrum değil. Bu, güçlü bir ürün yöneticisinin ve makul ve gerçekçi tahminler veremeyen zayıf bir geliştirme ekibinin tipik ortamıdır çünkü baskıyı hissediyorlar. Bu yüzden iyimser tahminler yapmak için çok fazla çaba harcadılar ve zaman içinde köşeleri kesmek için kendilerini daha derde soktular.

Scrum olarak (bir geliştirici olarak) kendi planlamanızı yaparsınız. Kimse size bir özelliği x gün içinde iletmemenizi söylemiyor. Birisi size x gün içinde teslim etmenizi söylüyorsa, Scrum yapmazsınız.

Sorun ne olursa olsun bunun düzeltilmesi gerekiyor, vaktinizi alın. İlk önce bir şeyi elden geçirmek için zamana ihtiyacın olduğunu düşünüyor musun? Tahmininize dahil edin. Bunu yapmayı göze alabilir misin?

Şimdi ne yaptığınızı inceleyelim, bir an için Çevik.

Planlamayı yaptığımızda, geliştirme zamanı açısından kolay bir çözüme gidiyoruz, yani yeni bir diyalog veya başka bir şey yapıyorsak, eski jquery'yi kullanırız çünkü daha hızlı olur ve daha sonra geri döneceğimizi söyleriz. toparlanır ve reaksiyona dönüşür, ancak bu nadiren olur.

Buna "Teknik Borç Alma" denir. Martin Fowler, "Teknik Borç Çeyreği" ni iki eksen boyunca yazdığı bir blogda şöyle tanımladı : "Dikkatsiz ve İhtiyatlı" ve "Kasıtlı - Yanlışlıkla".

Sizi , açık hedeflerinizden bir tanesinden (yani tek sayfalık bir uygulama) uzaklaştıracak bilinen eski teknoloji jquery'yi kullanmaya karar verdiniz . Bunu "hızlıca" sunmak için yapıyorsun. Bu Kasıtlı.

Bu "hızlı" hesaplamanın içermediği, işlevselliği sonradan tepki olarak uygulamanız için gereken zamandır. Hızın esas olduğuna dair bir değerlendirmeye dayanarak doğru olanı ( bildiğiniz tepkiyi uygulamak için zaman harcayarak) olduğunuzu bildiğiniz alternatife göre olumsuz olan bir alternatif seçersiniz . Bu Pervasız.

Martin Fowler, bu tür borçları “Tasarım için zamanımız yok” altında toplamaktadır. Bu, kodu korumayı beklemiyorsanız, hatta birkaç günden fazla bir süredir kod beklemiyorsanız uygun bir seçimdir. Ancak projeniz, müşterileriniz için açıkça bakım gerektiren uzun süredir devam eden bir projedir.

Yaptıkların çok temel düzeyde yanlış . O var kötü mühendisliği !

Teknik borcu aldınız, bu borcun geri ödenmesi ve faiz ödemesi gerektiğini göz ardı ederek . Ve borcunuzun faiz oranı, sprintinizdeki mevcut işlerinizi kapatmaya başlayana kadar bunu yapmaya devam ettiniz.

Yapmanız gereken şey borç seviyesini düşürmektir . Patronunla konuş, müşterinle konuş. Dün sürdürülebilirlik üzerinde çalışıyor olmalısın.

Sadece Çevik'i kullanmayı bırak ...

Veya daha doğrusu, kesin bir şekilde bir şeyler yapmaya çalışmayı bırakın, çünkü çevik (ya da scrum vs ...) istediği şey budur. Bu terimlerden birinin (yanlış) yorumunu yanlış aşamadaki bir projeye uygulamaya çalışmak çabucak en kötü harekete dönüşebilir. Bunun yerine nedenini kullanın.

Projenizin ve dünyadaki hemen hemen tüm diğer projelerin nedeni bir karışıklık ve farklı yaklaşımlardan kaynaklanıyor olmasının nedeni, merkezi, her şeyi bilen mimari tasarımın olmamasından kaynaklanıyor (orada dedim).

Bunun eksik olmasının sebepleri:

• Mimarın uzmanlığı yok (İlk on hobi projeniz gibi)
• Mimarın zamanı yok
• Mimarın gücü yok (Yönetici hayır diyor ya da evet ama sadece bazı parçalar için)
• Ekip, onları kurtaracak bazı voodoo metodolojisine güveniyor.

Basit çözüm, tüm bu sihirli kelimeleri bırakmak ve durumun gerçeğine bakmaktır; bunlar şöyle özetlenebilir:

1. Kodun durumu, ekibin zamanında ve hatasız teslim edilmesini engelliyor.
2. Ne kadar çok özellik eklersek o kadar kötüleşecek.
3. Bu nedenle, parçaları duraklatmak, yeniden değerlendirmek ve (belki de şiddetli bir şekilde) yeniden tasarlamak gerçekten mantıklı geliyor.

Doğal olarak, neden bu duruma, ilk etapta, suçlama parmağıyla yuvarlak ve yuvarlak bir şekilde parmakla geldiğini sormaya geleceksiniz. Cevap, bunun kaçınılmaz olduğudur: tasarımınız olgunlaştıkça, farklı bir şekilde yapmalıydınız, ancak önceden göremezdiniz. Ayrıca, bu proje başına bir kez gerçekleşmez, birkaç kez olur ve bunun için plan yapmanız gerekir.

Bunu söyledikten sonra, yöneticilerin işleri daha da kötüleştirmek için yapabilecekleri çok şey var:

1. Devlerinle son teslim tarihlerine ölüm.
2. Bu cihazların, "düşünme, konsolidasyon ve kalite yeniden düzenleme" için biletler olmadan ve bunlara cömert bir zaman ödeneği olmadan biletlere karşı sadece zaman ayıracağını belirtmek.
3. Herhangi bir kişiye, mimarlığı ele geçirme yetkisi vermeyecek
4. O kişinin gerekli olduğunu düşündüğü değişiklikleri yapmasına izin vermemek

Bu şekilde baktığımızda, çevik ve aldatıcı yorumların sizi bu rotada nasıl daha hızlı yürüttüğünü görmek kolaydır!

Bir yaklaşım, her yeniden düzenleme bitinin biletlerini oluşturmaktır. Sorun şu ki daha küçük bir bilet üzerinde çalışmaya başlayana kadar büyük bir refaktöre ihtiyacınız olduğunu fark etmiyorsunuz, bu süre son başvuru tarihlerini geri çekiyor ve bilet geçtikten sonra onay döngülerinden geçiyor, her şeyi yavaşlatıyor.

Diğer bir yaklaşım, takımınızın kapasitesinin yalnızca% 25-50'sini kullanacak sprintleri planlamaktır. Devs daha sonra gerçek biletlere giriş yapar (yeniden düzenleme yapılmadan geçirilmesi gereken zamanı kaydetme) ve yeniden düzenleme zamanını (hafta için büyük bir bilet, onay döngüsü yoktur, sadece devs arasında tartışma). Yeniden düzenleme yapılmazsa, gelecek haftaki sürat biletlerini alabilirsiniz. Projenin temel kodu düzeldikçe, gelecek haftalara göre yüzde kaydırıcısını ayarlarsınız.

Bu yüzden "Neyi yanlış yapıyoruz" cevabını vermek için sağduyulu bir metodolojiye güvendiğinizi söyleyebilirim. Hatta "bu soruna çevik bir yaklaşım" bile istiyorsunuz . Kelimeleri bırakıp asıl problemi düşünelim derdim. Daha sonra, nihai sağduyu yaklaşımınızın gerçekten de “çevik” veya “aldatmaca” kisvesi altına girip girmediğini deşifre etmeye çalışan çeşitli manifestoları gerçekten ayırmak istiyorsanız, elbette bunun için gidin :-)

Yanlış bir şey yapmıyorsun. Bu tür bir metodoloji, özelliklere olabildiğince hızlı ve hızlı bir şekilde ulaşmak için tasarlanmıştır.

Çalıştığınız ikincil hedefleriniz varsa, bunları 'işlevsel olmayan gereksinimler' veya 'yapılanma' olarak tanımlamak en iyisidir.

örneğin, işlevsel olmayan bir gereksiniminiz olabilir:

"Tüm yeni özellikler React'te yazılmalıdır"

ve

"Tüm eşzamansız çağrılar yükleme döndürücü ve hata işleme uygulamalıdır"

Bunların, geliştiricilerin beğendikleri için gizlice değil, yapmaya değer şeyler olduğunu kabul etmesi için Ürün Sahibinize (veya eşdeğerine) sahip olmanız yeterlidir.