Ekibimin Kanban'daki kalite özelliklerini nasıl takip edebilirim?

Ekibim, günlük ilerlemeyi izlemek için bir Kanban sistemi kullanıyor ve özelliklerdeki (kullanıcı hikayeleri olarak kaydedilen) ilerlemeyi anlamak için gerçekten iyi çalıştı. Yakın zamana kadar iyi çalışan özellikler geliştirirken sistem tasarımımızın ortaya çıkmasına büyük ölçüde izin verdik. Son iki haftada, özellikle performans ve değiştirilebilirlik kalite özellikleriyle ilgili mimari ödünleşmeler hakkında birkaç tartışma yaptık.

Bence olan şey, özellikleri uygularken ve sistemi tasarlarken, dolaylı olarak mimarlık hakkında kararlar veriyoruz, ancak bu kararları bilinen kalite özellik gereksinimlerimiz açısından dikkate almıyoruz. Bu önemli tasarım kararlarının nasıl alındığını izleyebilmem / yakalayabilmem / görsel olarak tasvir edebilmem gerçekten harika olurdu, böylece ekip üyeleri uygulanmakta olan sistemin mimarisinde ek gerginlik yaratmama şansı daha yüksek. Ve elbette, işleri daha da karmaşıklaştırmak için, kartımızdaki özellikler sadece işlevsel değildir ve bazen mimari karmaşıklığı gizler!

Ekibimin kanbanında kalite özellikleri (veya mimari olarak ilgili diğer kararlar) konusundaki ilerlemeyi görsel olarak nasıl izleyebilirim?

mimarlıkla ilgili dolaylı olarak kararlar veriyoruz, ancak bu kararları bilinen kalite özellik şartlarımız açısından dikkate almıyoruz.

Bunu iş akışınızda bir "mimari inceleme" adımı oluşturarak görselleştirebileceğinizi düşünüyorum. Adım, kendi Devam Eden Çalışma sınırına sahip bir Kanbad panosu sütunu ile temsil edilir. Devam Eden Çalışma sınırı, bu incelemelere kaç mimar / tasarımcı katmanız gerektiğine bağlı olacaktır.

Geliştirme ekibi, kullanıcı öykülerinin yatay, soldan sağa akışından sorumludur. Mimar (lar) çoğu durumda öykülere yalnızca mimari / teknik inceleme sütunundayken dokunacaktır. Kolonun yatay bir yüzücü ile kesişimi, geliştiricilerin ve mimarların buluşmasını görselleştirir.

Çalıştığım ekiplerden birinin, baş veri mimarı ile bir veritabanı şeması incelemesi yaptıkları benzer bir adım var. Kanban kullanmıyorlar, ama eğer yaparlarsa, tahtalarında bu sütuna sahip olmaları çok olasıdır.

Bilinen kalite özellikleri daha sonra şu şekilde temsil edilebilir:

• mimari gözden geçirme adımı için yapılan tanım.
• işlevsel olmayan gereksinimleri temsil eden önceden yapılmış kullanıcı hikayeleri etrafında kabul testleri. Daha sonra yeni bir kullanıcı hikayesi için yapılanın tanımı, bu testleri kırmamayı içerir.

EKLENDİ : "Mimari inceleme" iş akışı adımı , müştereklerin trajedisi olarak adlandırılan bir sorundan şüphelenilebilir . İşte Kanban görselleştirmesinin onunla ve olası çözümlerle nasıl başa çıkabileceği hakkında harika bir blog yazısı .

Bu sorunun gerçekten iki kısmı var. Bir kısmı: Mimarinin ne zaman değiştiğini nasıl biliyoruz. İkinci bölüm: Mimarinin hala iyi olduğunu nereden biliyoruz?

Bu ilk bölüm için: Mimarinin ne zaman değiştiğini nasıl anlarsınız?

Buradaki amaç, örtük olarak yapılan bir şeyi alıp açık hale getirmektir.

• Alexei'nin önerisi bir seçenektir. Mimari inceleme için tahtada bir sütun oluşturun. Ardından, mimari kararlar gerektiriyorsa bir kartı oraya taşıyın
• Başka bir seçenek, bunun nasıl ele alınacağına dair açık bir politika oluşturmaktır: "Mimariyi değiştirmemiz gerekiyorsa, başka biriyle eşleştirmeliyiz" böyle bir politika örneğidir. Bir projede, belirli uzman modüllerde kod değişikliklerinin belirli kişilerle eşleştirilmesi gerektiğine dair bir politikamız vardı. Birisi orada kodu değiştirmek istediğinde, bir çift çağırır ve ekip kurar. İşin geri kalanı yalnız yapıldı. Mimariyle benzer bir şey yapabilirsiniz.

Birçok kartın gözden geçirilmesi gerekiyorsa veya mimar ekibin bir parçası değilse ve bir devir gerekiyorsa veya inceleme izlemek istediğiniz biraz zaman alacak kadar ayrıntılı olacaksa, muhtemelen ilkiyle birlikte gidersiniz. pano. İkincisi, sadece birkaç kart mimariye dokunursa ve isteğe bağlı bir çift bulmak kolaydır.

Şimdi ikinci soruya geliyoruz: Mimarinin hala iyi olduğunu nereden biliyoruz?

Ben büyük bir görselleştirme hayranıyım. Beyaz tahtada bileşenleri ve mimariyi açıklayan post-it notları içeren bir grafik olabilir.

Kod tabanını analiz edecek ve çeşitli bileşenlerin bağımlılık grafiğine sahip bir görüntü oluşturacak statik analizörler de vardır. Çalıştırabilir, çıktı alabilir ve haftada bir duvara yapıştırabilirsiniz. Belki de en son iki çıktı duvarda olabilir, bu yüzden geçen hafta bir değişiklik olup olmadığını görebilirsiniz.

Bunların yapmanıza izin verdiği şey, mimarinizi ve tasarımınızı görünür kılmaktır. Ekip üyeleri ara sıra ona bakacak ve bir şeyin daha iyi bir şekilde değiştirilebileceği veya yeniden düzenlenebileceği veya yapılabileceği konusunda yorum yapacaklardır.

Ben de bu problemi gördüm. Örtük karar verme! Örtüklük sorunsa, sorunu olabildiğince açık hale getirmek sorunu çözer mi? Benim önerdiğim, karar verme sürecine ilerleyen örtülü düşünceleri 'açıklamaya' başlamak için mimari süreci biraz değiştirmektir. Süreçteki ek adımın amacı, ekip üyelerinin herkesin örtülü mimari kararlar almaya eğilimli olduğunu anlamalarını sağlamaktır. Bu adım, örtük kararları yoldan uzak tutacaktır.

Senaryoların her biri için kanbanın bir parçası olarak "Örtülü kararları açıklamak" yardımcı olabilir.

Önereceğim şey hantal olabilir. Ancak süreç bir dizi kanban öğesine eşlenirse ve bu her bir kemer senaryosu için tahtaya getirilirse, izlemenize yardımcı olmaz. Ayrıca bunları altı bölüm senaryo şablonuyla eşleştirmenizi ve bulguları karşılamak için kanban panosunu doğaçlama yapabilmenizi öneririm, KG'ler izlenebilir.

Vikram.

Çevik ekiplerde mimari kararları erteleme risklerinden biridir. Çevik olmanın en sorumlu yanı, mimari kararları son sorumlu ana kadar ertelemektir . Ancak, şansın erken sorumlu olabileceği (veya olması gerektiği) son sorumlu an .

Yardımcı olan bir şey, temel sürüş gereksinimlerinizi açıkça tanımlamaktır; sahip olmanız gerektiğini açıkça bildiğiniz şeyler (ancak şu anda uygulanması gerekmiyor.) Gelişen mimariniz (minimalist ve esnek olmaya çalışan) bu tür gereksinimler için mevcut veya gelecekteki desteği barındırmalıdır.

Bununla birlikte, daha da önemlisi, bu mimariler mevcut gereksinimleri çözmek için tasarlanmış olsa bile, gelişen mimariniz bu tür temel sürüş gereksinimlerini destekleme yolunda olan (veya alabilen) yapayları UYGULAMAMALIDIR. Müdahale eden artefaktlar , gerçek bir değer sağlayan (mevcut gereksinimlere bir çözüm uyguladıkları için) ancak varlığı gelecekteki bir anahtar sürüş gereksinimini uygulamayı zor / maliyetli kılan artefaktlar olarak söz edebiliriz .

Müdahale eden bir yapı uygulamanız gerektiğinde, göreviniz bir noktada kaldırılmasını planlamak olacaktır (böylece müdahale edilen anahtar sürüş gereksinimini uygulayabilirsiniz.)

Açıkçası bunların hepsi gerçek, somut bir bağlamı olmayan (gerçek bir proje gibi) ezoteriktir. Ancak az çok geliştirme süreci modeliniz ve gelişen mimariniz bu hususları dikkate almalıdır.

Örtük gereksinimler mimarilerin ölümüdür. Erken bir gereksinim uygulamanız gerekmez. Sadece hesap verebilmeniz gerekir.

PS. Gereksinim gereği, sistem düzeyinde mimari gereklilikleri kastediyorum, mimaride önemli değişiklikler yapılmaksızın uygulanabilecek geçici uygulama seviyesi gereklilikleri değil. Umarım yardımcı olur.