Birden fazla scrum takımı tek bir biriktirme listesine geçiyor

Şu anda, geçen yıl kendi ürün birikimlerini işleyen 5 scrum ekibimiz var. Her takım kendi özel sistemi üzerinde çalışır, ancak altta yatan teknoloji aynıdır.

Tek bir biriktirme listesi üzerinde çalışan özellik tabanlı ekiplere geçme konusunda çok fazla tartışma var. Bunun nedeni, ana sistemlerimizden birinin önemli miktarda çalışmasının olması ve bunların yıl boyunca tüm işleri teslim etmek için yeterli kapasite olmamasıdır. İnanıyorum ki önemli olan diğer bir nedeni de portföydeki değişikliklere hızla uyum sağlamak için daha fazla esneklik sağlaması.

İki takımı tek bir biriktirme listesi üzerinde çalışacak şekilde değiştirme kararı alındı ​​ancak geliştiricilerin diğer sistemlerde deneyimi yok. Yaptığımız bir şey, bir deneyim sistemi geliştiricisini takıma taşıyarak çapraz beceri kazanmak.

Sorum şu: İki veya daha fazla farklı sistem için tek bir biriktirme listesine geçmeyi deneyimlediniz mi? Zorluklarınız nelerdi? Çalışması için ne yapmanız gerekiyordu?

Tek bir biriktirme listesi kullanarak yaklaşık yarım düzine proje yönetiyoruz. "Hakkında" diyorum çünkü projeleri nasıl farklılaştırmak istediğinize bağlı.

Gevşek olarak, bazıları birden fazla ürüne sahip olan beş veya altı ürün sahibimiz var. Yedi geliştirici ile oldukça küçük bir ekibimiz ve zamanı olduğunda kod yazan bir takım liderimiz var. Fikirleri boru hattına taşımak için süreç halkımızla birlikte çalışan birkaç evangelizörümüz var. Tabii ki, birkaç halk şeyleri çamurlayan birkaç şapka takıyor ama cevabım için bunu görmezden geleceğim. İlginç bir şekilde, resmi bir scrum master'ımız yok.

İş birikintilerini bir araya getirmek zorunda değildik, ancak yanınızda basit bir görev gibi görünüyor.

Bir şeyleri organize tutmak gerçek bir acı olabilir, bu yüzden düşünmek isteyeceğiniz bazı noktalar.

• Yönetişim anahtardır. Pasta bir idari parmağı var herkes gerekir önemli değişiklikler yapmadan önce başkaları ile iletişim kurar. Ve / veya değişiklik yapanların bunu yapma yetkileri ile rahat olmaları (ve kötü bir değişiklik için ısıyı almaya hazır olmaları) gerekir. Değişiklik yapanlar, güçlü yönetici desteğine sahiptir ve alanlar oldukça net bir şekilde çizilmiştir. Ancak bir şüphe olduğunda, değişmeden önce soruyoruz.

• İş yükü tımarlama, önceliklendirme ve başlama için daha fazla yük olabilir. Bir ritüel olarak önceliklendirme en çok acı çeker, çünkü tüm sahiplerini düzenli olarak bir araya getirmek zordur. Önceliği müzakere etmek ve / veya öncelikli kesintiyi yapmamaya ilişkin kötü haberleri sunmak için birkaç go-betweens kullanıyoruz.

• Çalışmalarımızın çoğu dış bağlılıktan kaynaklanmaktadır. Bu, bazı özerkliği kararlarımızdan uzaklaştırıyor, ama bu işin gerçekliği. Geliştiricilerin bu değişimin farkında olması gerekiyor. Algılanan bir kontrol kaybı varsa tüyler karıştırılabilir. Yine de fazla taahhütte bulunmamaya çalışıyoruz ve sprint haline getirmenin zirvesinde oturan bazı ürün sahiplerine "hayır" demek zorunda kaldık.

• Bir ürün biriktirme listesi öğesinin ait olduğu ürünü etiketlemek için genellikle iki yöntem kullanırız. Her ikisini de basitçe kullanıyoruz çünkü bakım ve diğer görevleri kolaylaştırıyor.

  1. PBI başlığını ürün adı veya stenografi sürümü ile önceden yazacağız.
  2. Toplam ürünü gösteren ve doldurulması gereken ayrı bir alanımız var.

• Çapraz eğitime bilinçli bir çaba harcamalıyız ve herkesin çeşitli alanlarda bir el sahibi olmasını sağlamak zorundayız. Geliştirme ekibimizle ilgili çok geniş bir kod tabanımız var. Yaptığımız kodlardan bazıları da çok özel. Ekip liderimiz bu konuda harika ve çapraz eğitimden kaynaklanan verimsizlikleri karşılayabilmemiz için bağlılık seviyemizi bir çentik aşağı itecek. Bu konuda güçlü bir takım liderliğine sahip olmak çok önemlidir.

• Sprint zaman çerçevelerimizi korumak için elimizden geleni yapıyoruz. Daha yeni ekip üyeleriyle yapılan karmaşık projeler, taahhütlerle nadir olmayan bir kanamaya dönüşür. Dallanma süreciniz burada gerçekten yardımcı olacaktır. Tüm çalışmalarımız, daha sonra bir gövde serbest bırakma ile birleştirilen bir şubeye karşı yapılır. Ayrıca, geçici tetikleyicilere ek olarak her gece çalışan bir yapı sunucumuz var. Yapıyı bozan geliştiriciler sorunu 24 saat içinde bilir ve çözer. Dönemi. 24 saat içinde çözülmemesi, taahhüdünüzün geri alındığı ve kıdemli geliştiricilerin onlara keder verdiği anlamına gelir. Üst düzey geliştiriciler, yapıyı korumak söz konusu olduğunda kendi başlarına en zor olanlardır.

• Kod gözden geçirmeleri ve incelemeler daha da kritik hale gelir. Çeşitli alanlarda nelerin değiştiğini herkesin güncel tutmasına yardımcı olur.

• Benzer şekilde, günlük destek tüm geliştiricileri ve kullanıcı arayüzümüzü içerir. Çok sayıda insanın faydalı işbirliğine dayalı iletişim ve verimsizliğinin hemen yanındayız. Ancak biz stand-up'ı 15 dakikadan daha az tutuyoruz ve yan tartışmalardan hızla geçeceğiz. Genellikle 5 ila 10 dakika içinde işimiz bitti.

• Hız veya genel taahhüt ve burndown oranları gibi metrikler üzerindeki etkileri hakkında konuşamam. Bu yönler, bizim yakından takip etmemiz için yeterince önemli değildi. YMMV, bunu dikkate alın. Bu aynı zamanda her takımın hikaye noktası için oldukça benzer bir tanımlamaya sahip olduğunu varsayar. Değilse, bu birleştirme işleminden sonra ilk tahminleri berbat edecektir. Daha önce olduğu gibi aynı ölçü birimini kullanmadığınız için geçmiş karşılaştırmalar için de bazı sorunlar yaratacaktır. Kolay çıkış, bunu metrikler için "yeni bir ekip" olarak ilan etmek ve birleştirme işleminden sonra veri toplamaya başlamaktır.

• Bu yaklaşımdan önemli faydalar gördük. Tüm ellerin bir alana odaklandığı bazı sprintlerimiz vardı ve kısa sürede çok fazla değişiklik yapabiliriz. Belirli bir projeye normal sayıda geliştiriciyi hızlı bir şekilde uygulayabilmenin getirdiği değeri küçümsememelisiniz. Ama çapraz eğitimi önceden koymanız gerekiyor. Ayrıca, test döngüleri veya tımarlama ya da her neyse, hiçbir zaman "yapacak bir şey" bulunmayan geliştiricilerimiz olmadığı anlamına gelir. Her zaman üstesinden gelmek için bir birikimimiz var.

• Ar-Ge projeleri için zaman ayırın. Aksi takdirde, çatlaklardan geçmeleri çok kolaydır ve bu bölgelere yatırım yapma fırsatını kaybedersiniz.

• Gerçekten ego içermeyen kodlama üzerinde çalışın ve bir alanda uzmanınız olsa da, bir kod alanının sahiplerine sahip olmadığınız anlamına gelir. Bir bölgeye farklı stiller eklendiğinde morarmış ego fırsatını önlemek önemlidir. Yeni kod ekip standartlarını karşıladığı ve işlevsel olduğu sürece, iyi olmalıdır. Sadece bilirkişinin böyle yapmaması önemli değil.

• İlgili ekiplerin aynı kodlama kurallarını ve stilini kullandığından emin olun. Entegrasyon girişimlerinize zarar vermek için burada tutarsızlık gibi bir şey yok.

• Retrospektiflerinizi tutmaya devam edin ve grup olarak tutun. Neyin işe yarayıp neyin işe yaramadığına ve neyin farklı denenmesi gerektiğine dair herkesin geri bildirimlerini almak önemlidir. Bu, ekip içinde bir arkadaşlık duygusu yaratmaya yardımcı olur ve geliştirme süreci etrafında bir sahiplik hissi verir.

Scrum'ın doğru cevabı "Takımlara sorun". Bu, işi hızlı bir şekilde yapmak için kendilerini yeniden yapılandırabilmeleri gereken kendi kendini örgütleme ilkesidir. Takımlardaki birçok insanın yabancıdan daha fazla bağlam bilgisine sahip olduğunu ve neyin en iyi olduğunu bildiklerini görüyorsunuz. Buna Ürün Sahibi de dahildir.

Buraya geldiğinizi ve soruyu sorduğunuzu düşünüyorum, çünkü doğru hissetmeyen bir şey var ve gizli endişeleriniz var. Bu yüzden size doğru kararı vermeniz için ekiple görüşmeniz için birkaç ipucu vereceğim.

Ürün sahibi

Bir biriktirme listesi için yalnızca bir ürün sahibi vardır ve bu bir iş kişi veya işletmeyi temsil eden kişi olmalıdır. BT yönetimi olmamalıdır. Büyük bir biriktirme listesi birçok öğeye sahiptir ve birden fazla ekiple tek bir PO'nun başa çıkması çok fazla olabilir. Bu nedenle birikmiş işleri ayrı tutmak isteyebilirsiniz.

Birden fazla PO varsa, takımların tek bir PO ve biriktirmeye adanmış olması gerektiği için kesinlikle birden fazla biriktirme listesine ihtiyacınız vardır. Bunun nedeni bir ekibin ürün sahipleri öncelikleri arasındaki çatışmaları yönetmesine gerek olmamasıdır.

Bakım ve Ürün Geliştirme

Bakım ekipleri birçok küçük geliştirme üzerinde çalışır, birkaç farklı ürün üzerinde hatalar ve muhtemelen birkaç ürün sahibi ile. Bu BAU ekipleri, birden çok ürün sahibi arasındaki çatışmaları planlamak ve yönetmek için BT yönetiminin desteğine ihtiyaç duyar.

Proje ekipleri, bağlam değişikliğini en aza indirmek ve bir seferde harika bir ürün sunmak için her seferinde bir ürüne odaklanmalıdır. Bağlamsal geçiş, bir dereceye kadar teknik borç ile birçok vasat ürünün teslim edilmesiyle sonuçlanabilir.

Bağlam Değiştirme

Birden fazla ürün veya farklı özellik üzerinde çalışmak, ekiplerin verimliliğini yavaşlatan bağlam geçişine neden olur. PO, bir sonraki adımın ne olduğunu ve hangi takımın hangi iş üzerinde çalışması gerektiğini hesaba katmalıdır. Geçiş miktarı önemsiz değildir ve sadece teorik bir konu değildir, gerçektir ve takımın bu nedenle verimlilikte% 80'e kadar düştüğüne şahit oldum.

İyi bir PO, ekiplerin daha az içerik geçişi yapmalarına yardımcı olmak için grup özelliklerini ve çalışma türlerini deneyecek ve böylece performanslarını artıracaktır.

Risk

Ne yazık ki, yönetim zaman, para, bütçe ve iş baskısı riskini takıma koyuyor; ve takımlar bunu kabul ederek kabul eder. Bir geliştirme uzmanı olarak, kararların gerçeklerini ve etkilerini açıklamalı ve işletmeyi kendi riski altına almalısınız.

Örnekler

• Saçma bir zaman için katılıyorum. Aksine, işi düzgün yapmak ve işin zaman problemini yönetmesini sağlamak için ne kadar çaba sarf edeceğini söyleyin

• Tahminler. İş dünyası, ekiplerin karmaşıklık ve belirsizlik dünyasında doğru bir şekilde tahmin etmesini bekler. Ekipler, büyük olasılıkla öngörülemeyen zorluklar nedeniyle tahminlerin aşılıp azaltılmadığını azaltmak için işletmeye ne yaptıklarını sormalıdır. Takımlar yağ faktörünü etkilemeli, bunun yerine iş dünyası etmelidir.

• Teknik borç. Takımlar, tamamen test edilmiş yüksek kaliteli kod yapmayı tahmin etmeli ve bunun üzerinde tahmin yapmalıdır, yani baskılardan kaynaklanan kusurları yazmayı durdurmalıdır. Eğer işletme daha düşük kalite istiyorsa, bu onların riskini alır ve işler yanlış gittiğinde sorunudur.

Profesyonellik

Kararlaştırılan kaliteye doğru şeyleri inşa ederek profesyonel olun. Eldeki gerçeklere dayanarak en iyi yeteneğinizi tahmin edin. Bu gerçekler değiştiğinde bunu iletin ve tahmini ayarlayın. Bir geliştirme ekibi olarak, harika ürünler oluşturun ve iş riskini üstlenmeyin. Beklentileri iletin ve yönetin.

İnceleyin ve Uyarlayın

Takımlar her zaman gelişmenin yollarını aramalı ve işleri daha iyi hale getireceğini düşünüyorlarsa denemeliler. Ardından, iyileştirmeler olup olmadığını kontrol edin. Son olarak, yeni yaklaşımlarına uyum sağlamaları ve geliştirmeleri ya da çalışmıyorsa hurdaya ayırmaları gerekir. İyileştirme arayışının ardındaki niyet her zaman orada olmalıdır.

Sonuç olarak

Sonuç olarak, birikmiş iş yerinin yönetimi PO'nun seçimidir. İş kuyruğunu nasıl yönetmek istediğine bağlı. Tek düşünce, TÜM ekiplere iş hattını sağlıklı ve iyi durumda tutmaları GEREKİR. Bu nedenle karar vermek PO'ya bağlıdır.

Sözleşme

Sprint planlama oturumlarında ekip, açık, net ve düzenli olan bakımlı ürün biriktirme listesi öğelerinin bir listesini beklemelidir. PO ile kısa bir tartışma yaparak ekip PO'nun tam olarak ne istediğini bilmelidir; NE . Ekip daha sonra nasıl inşa edeceklerine odaklanır.

PO iyi hazırlanmış planlama toplantısına gelirse, birikmiş işlerin nasıl yönetildiğini kimin umurunda olur. PO sprint planlama toplantısına hazırlıksız gelirse, bu SM tarafından ele alınmalı ve çok kabul edilebilir olmalıdır çünkü bu tamamen kabul edilemez ve üstlenilmesi gereken bir takım problemi değildir.

Kısa süre önce başka bir ekibin birikmiş işini devraldık. Ekibin sadece bir üyesi vardı (çok fazla bir ekip değil, biliyorum), ancak birikmiş işlerinde gerçek bir çalışma var. Biz onların çalışmalarına pek aşina değiliz ve onlar da bize aşina değiller.

Birikmiş işleriniz birleştirilse de, bu herkesin hemen her şey üzerinde çalışması gerektiği anlamına gelmez. Bunu beklemek mantıksızdır, bu yüzden herkesin her iki iş yerindeki her şeyi hemen yapabileceği konusunda çok fazla endişelenmeyin.

Bunun yerine, her iki ekibin de daha önce üzerinde çalıştıkları şey üzerinde çalışmasını sağlayın; tek fark, her şeyin aynı iş yığınında olması.

Daha sonra, her iterasyon / sprint, her takımdan bazı üyelerin diğer birikmiş işlerden hikayeler üzerinde çalışmasını sağlar. Herkesin tanıdık olmayan eşyalar üzerinde çalışmasını sağlayarak, birbirinizin sistemlerini öğrenmenin maliyetini yayarsınız . Zamanla ekibiniz birbirlerinin bilgisini yavaş yavaş emecektir.

Eğer tüm öğrenmeyi en önde yaparsanız, önemli performans cezaları olacaktır. Üst yönetimden biri kesinlikle fark edecek ve yeni ekibin kötü performansı telafi edebileceği umuduyla başka bir takımın biriktirmesini emmek zorunda kalacaksınız ... :) Şakalar bir yana, bu benim tavsiyem olurdu.

Sizin (veya yönetiminizin) iki ekip için birleştirilmiş bir biriktirme listesi oluşturmak istemesinin, sistemden biri için yalnızca biriktirme listesi öğeleri seçebilmenizi ve her iki ekibin de üzerinde çalışmasını istediğinizi varsayıyorum.

Bu durumda, aşina olmadıkları sistem üzerinde çalışmaya zorlanan ekipten çok fazla sürtünme beklenir. Ekibin daha önce üzerinde çalıştıkları sistem üzerinde çalışmaya devam etmek için her pipeti (yani "ev" sistemiyle ilgili küçük birikmiş işler) almasını bekleyin. Onları kim suçlayacak? İyi olmadığınız bir şey üzerinde çalışmak eğlenceli değildir. Ve diğer takımın iyi olmadığınız bir şey olarak iyi olması onu daha da kötüleştirir - çünkü daha da aptal görünmenizi sağlar.

Bu nedenle, bunu başarmanın tek yolu iki takımı parçalamak ve onları iki karma takım halinde oluşturmaktır. Ancak o zaman, tüm geliştiricilerin (şu anda) "önemli" sistemde hızlı bir şekilde hızlanma şansı vardır.

Bu şekilde yapmak çok iyi değil. Önceki şirketim, tek ürünlü tek takım moduna geçti çünkü büyük şirkette farklı şeyler üzerinde çalışan farklı insanlar vardı.

Projeler arasında geçiş yapmak da çaba gerektirir ve ek yük geliştirmeye yeni bir kişi varsa gerçekten büyüktür. Gelişmiş sisteme erişim hakkı, farklı depo vb.

Uzmanlaşmayı tercih ediyorum, insanlar ne yaptıklarını biliyorlar, gerekli tüm bilgilere sahipler, projenin tuzaklarını biliyorlar ve insanlar onları işe almak, her kuruşunu emmek için projeden projeye bırakmak zorunda olduğunuz hissine sahip değiller. onlar.

Projelerinde rölantide olsalar bile, projeden projeye atlamaktan çok, aşina oldukları şeylerde çok daha üretkendirler.