Bir web uygulaması oluşturan çevik bir ekibi ölçeklendirmenin ve bölmenin en iyi yolu nedir?

Kısa süre önce bir web uygulaması oluşturan çevik bir geliştirme projesinde scrum ustası olarak çalıştığım bir şirkete katıldım.

Takım, çevik bir takımın maksimum boyutu olacak (gelecek hafta 9 bekleniyor). Ekibi potansiyel olarak iki takıma ayırmaktan bahsettik, standup'ları kısaltmak için çok fazla değil (şu anda aşırı değil), ancak sprint planlama oturumlarında (yine aşırı uzun olmayan) insanların tamamen sıkılmasını önlemek için konuştuk.

Projede çok farklı iki katman vardır - yüksek teknik arka uç geliştiricisi (ciddi bir şekilde karmaşık gibi) ve UI tasarımı / derlemesi / entegrasyonu. Görünüşe göre arka uç adamları teknik konuşurken UI adamları bölgeyi dışarı atıyorlar. Ekibi sadece daha fazla zaman harcamak için bölmenin mantıklı bir yolu gibi görünüyor, ama gerçekten yapabileceğim tek şeyin işbirliği ve bilgi paylaşımını azaltmak olduğu için büyük bir çekincem var. İki takımın, takımın geri kalanının ne inşa ettiği hakkında gerçekten iyi bir fikri olmayacak.

Böyle bir şeyle uğraşmada herhangi bir tecrübesi olan var mı?

UI adamlar karmaşık arka uç çalışmasının ayrıntılarını umursamıyorlar. Bu daha çok retrospektif için bir tartışma konusu gibi geliyor. Ekibi disiplin boyunca bölmek, Gereksinimler milletlerinin bölgelere başlamadan ve UI adamlarının ne yaptığını umursamadan ve kendi takımlarını istemeden ne kadar zaman önce tehlikeli bir emsal oluşturacaktır.

Takımlarım için daima dikey dilimlerden yanayım. UI, işlerini kolaylaştırmak için yardımcı olabilecek çok millet oldukları için teknik millet söyleyeceklerini dinlemelidir (Ah, bu widget bunu yapmanıza neden olacak, bunun yerine bu widget'ı kullanırsak).

Şahsen, ilk önce imar eden UI adamları konusuna odaklanacağım, daha sonra bu işlev bozukluğu çözüldükten sonra, takımları en iyi şekilde nasıl ayıracağımızı tartışın. UI adamlarını kötülemeye çalışmıyorum, belki de teknik insanlar, tartışmalarını UI adamları için daha akılcı hale getirmek için daha fazlasını yapabilirdi.

Diğerlerinin söylediği gibi, ekibin yeni yapıyı belirlemek için kendi kendine örgütlenmesine izin verilmelidir. Geçmiş deneyimler bana kendi kendini örgütlemenin sadece herkesin kendi disiplini ya da çıkarlarından ziyade ekiple ilgilenmesi durumunda çalışabileceğini öğretti.

Şerefe!

Takımın bağımsız kısımlarını yeni takımlara ayırmak gerçekten iyi bir fikirdir. Daha büyük projede, geliştiricilerin tüm projeyi yakından tanımaları neredeyse imkansızdır, bu nedenle bölünme hala resmi veya gayri resmi olarak mevcuttur.

Yeni takımların her birinin, takımlarının kapsamı hakkında sağlam bir bilgiye sahip olan ve diğer takımların çalışmalarına aşina olan bir takım lideri / teknik yöneticisi olmalıdır.

Bundan sonra her takımın ayrı scrum toplantıları olabilir ve diğer takımların liderleri hazır bulunabilir. Bu şekilde "sıkılmış" insanların sayısını azaltabilirsiniz, ancak yine de takımlar başkalarının ne üzerinde çalıştıklarını bilecek ve başarılı bir şekilde işbirliği yapabilecektir.

Takımların kapsamları kesişiyorsa veya bir takım diğerine bağlıysa işbirliği daha önemli hale gelir. Fakat yine de tüm ekibin hazır bulunmasına gerek yoktur _ ekip lideri işbirliğini koordine edebilir.

Scrum'ın kilit bir yönü kendi kendini düzenlemektir .

Soruyu ekiple tartışmanızı ve çözmelerine izin vermenizi öneririm.

Endişeleriniz iyi kurulmuş, ancak Scrum Master olarak işinizin koçluk yapmak ve kolaylaştırmak olduğunu unutmayın. Bu yüzden onlara bu sorunları nasıl çözeceklerini sorun. Çözümlere sahip olacaklar ve çalışmasını sağlayacaklar .

Şunu da ekleyeceğim: genel olarak, çapraz fonksiyonel ekipler gidilecek yol.

Takımları bölerken her zaman bir ekibin müşteriye değer verebilmesi gerektiğini aklımızda tutmaya çalışıyorum. Sizin durumunuzda, ekipte hem arka uç hem de ön uç geliştiricilerinin olması gerekir.

1. Ön uç arka uçtan ne kadar uzaklıktadır? Tahmin edilebileceği gibi, bölme ancak mesafe çok uzaksa iyi bir tavsiye olabilir.

   • Arka uç veritabanı şeması hakkında konuşuyorsa, bu çok uzak değildir . Hem ön uç hem de arka uç, veritabanı şeması ile ilgili tartışmaları dinlemelidir.

   • Arka uç, parçalama, bellek önbellekleri, disk gecikmesi vb. Hakkında konuşuyorsa, bu biraz fazladır (arka uç mekanik sempati ve optimizasyona odaklanırken, ön uç insan estetiğine odaklanır).

2. Ön uç ve arka uç arasında kararlı ve net bir programlama arayüzü var mı?

   • İstikrarlı ve açık bir şekilde, bu programlama arayüzünün (ön uç geliştiriciler) kullanıcılarının değişikliklerle dolup taşmayacağı ve doğru bir şekilde nasıl kullanılacağını öğrenmek için metin duvarlarını okumasına gerek olmayacağı anlamına gelir.

   • Arka uç ekibinin iyi bir API ve sahte bir uygulama sağlaması gerekir ve ancak bundan sonra gerçek gelişimi başlatır.

   • Bu, API'nin taş olarak ayarlanması gerektiği anlamına gelmez. Bu sadece bir takımı ikiye bölmenin sonucunun hafifletilmesidir.

3. Neden bu kadar çok çevik ürün dikey dilimlere sahip olmanızı önerir? İşte bazı arka plan bilgileri:

   • Çoğu çevik makale aslında maliyet açısından bakıldığında arka uç işinden kaçınmayı önerir.

   • Ayrıca, çevik makalelerin bir kısmının başlangıç ​​şirketlerine karşı dolaylı önyargıya sahip olduğunu unutmayın.

   • Ve pazarlamanın sert gerçekliğini unutmayın - çoğu müşteri yalnızca ön uçlar için ödeme yapar.

   • Arka uç çalışması maliyetli olma eğilimindedir ve getirisi yavaştır. Bir şirket zaten uzun vadede kurulmamışsa ve iyi bir kâr elde etmiyorsa, kullanıma hazır teknolojiye ve açık kaynak kütüphanelerine bağlı kalarak arka uç "dış kaynak" sağlamak daha iyidir.

   • Çoğu çevik makale ayrıca bir arka uç anahtarından sağ çıkabilmesi için ön ucun uygulanmasını önerir. Bu öneri bir öncekiyle el ele gider: kullanıma hazır teknoloji tüm gereksinimleri karşılamıyorsa başka bir tane deneyin.

4. Bir takımı bölmenin kötü sonuçlarını hafifletebilecek uygulamalar

   • Kararlı arka uçlar
   • Kararlı API
   • Düşük hata oranı arka ucu
     • Sebep: hayal kırıklığını önlemek için
     • Nasıl: birim testi
     • Bu şu anlama gelmez: performans veya optimizasyon; sadece işlevsel olarak doğru olması gerekir.
   • Sürekli entegrasyon
   • İletişim, ilerleme ve karar vermede şeffaflık
   • İki ekip arasında gayri resmi tartışmaları teşvik etmek
   • Ekip üyelerini (bölgeden çıkmayanlar) diğer ekibin toplantılarına katılmaya teşvik edin.
   • Ara sıra ortak toplantılar ve ortak geçmişe dönükler oluşturun
   • Diğer ekip oluşturma faaliyetleri

Diğerleri gibi, kesinlikle dikey dilimlerle gitmenizi öneririm. Bunlar bazen "Özellik Takımları" olarak adlandırılır. Ölçekler Çevik Çerçeve sitesinde artılarını / eksilerini okumayı tavsiye ederim: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

İlk olarak, bölündüğünüzde, Ürün Sahibiniz ve SDF Master'ınız her iki ekip için de Sürüm İş Listesini ve her özellik ekibi için ayrı iş yüklerini işleyebilir. Bununla birlikte, büyüdükçe, daha sonra birden fazla çevik takıma bırakılan birikmiş işler bırakan bir ürün özellikleri biriktirme listesi uygulamanız gerekecektir. Bu seviyeye ölçeklendikten sonra, büyük olasılıkla özellikler biriktirmesini yöneten ve daha sonra özellikleri uygulama için ayrı ekiplere getiren ayrı bir ekibe ihtiyacınız olacaktır. Bu yapıda şöyle bir şey olabilir:

1. Çevik Takım 1: SM, PO, Çapraz fonksiyonel takım. Hikayeleri için kendi ekip birikimine sahiptir.
2. Çevik Takım 2: SM, PO, Çapraz fonksiyonel takım. Hikayeleri için kendi ekip birikimine sahiptir.
3. Program Yönetim Ekibi: Ürün Yöneticisi, Yayın Yöneticileri, Kurumsal Mimarlar. Daha yüksek seviyeli destanlar ve organize edilecek, analiz edilecek ve daha sonra ekiplere aktarılacak özelliklere sahip kendi program birikimi vardır.

Safe Web sitesi büyük takımlara düzenlemek için serin bir sürü var ve takımların-takımların daha büyük ölçeğe taşımak gibi bazı sizin için yararlı olabilir.