İşi geliştiriciler arasında paylaştırmanın en iyi yolu nedir?

Ekibim ve ben on yıl önce geliştirdiğimiz bir siteyi yeniden inşa ediyoruz ve bunu Çevik'te yapmak istiyoruz.

Bu yüzden okumaya çok zaman harcadıktan sonra (muhtemelen yeterli değil) geliştiriciler arasında çalışmanın nasıl bölüneceği sorusu ile sorun yaşıyorum.

Daha spesifik olacağım ve sitenin birbiriyle fazla entegrasyona sahip olmayan ayrı modüllere bölündüğünü söyleyeceğim.

İşi geliştiriciler arasında paylaştırmanın en iyi / en kabul edilen yolu nedir?

• Her kişiye üzerinde çalışacak farklı bir modül verilmesi.
• Tüm geliştiricileri aynı modüle atayın ve işi modülün farklı bölümlerine ayırın (UnitTesting, DAL ve Mapping, Logics, UI)
• Tüm geliştiricileri aynı modüle atayın ve işi farklı mantıklara bölün (Örneğin, her geliştirici belirli bir mantıktan sorumludur (muhtemelen BL'de bir yöntemdir) ve It's UnitTesting, DAL ve Mapping and UI ...

Ya da belki tamamen farklı bir şey?

Ekibim şimdi birkaç sürüm için "çevik" olmaya çalışıyor, ancak büyük bir şirketin parçası olmak tam olarak kolay olmamıştı. Cevabı benmişim gibi davranmayacağım, ama bazı gözlemlerimi paylaşabilirim.

• Modül başına geliştiricileri bölme:

  • Dikkatli olmalısınız, çünkü insanlar çok fazla tecrit halinde çalışıyorlarsa, ekibiniz beceri ve bilgilerin karşılıklı paylaşımından faydalanamaz.
  • Toplantılar ve günlük stantlar planlama, eğer insanlar kendi modüllerine çok fazla odaklanırlarsa ve daha büyük bir resim görmezlerse herkes için inanılmaz derecede sıkıcı olabilir. İnsanlar sıkıldığında, kontrol etmeye başlarlar ve çevikliğin getirdiği faydaların çoğunu kaybedersiniz
  • Gerçekten iyi yazılmış bazı bileşenlerle ve diğer bileşenlerle de sonuçlanır ... pek de değil. İnsanlar tecritte çalışıyorsa, kıdemli çocuklarınız küçükleri eğitemez.

• Herkes aynı modülde aynı anda çalışıyor

  • Bir sürüm için, yönetim tüm takıma çevik davranmaya karar verdiğinde ve tamamen kendi yolunda olacaklarını denedik. Mutlak bir tren kazası olarak. Genellikle 1 geliştirici tarafından yapılabilecekleri bir yılda 9 geliştiriciden oluşan bir ekibimiz vardı. (Burada abartıyor olabilirim ama fazla değil).
  • Kimse nefes alma odası gibi hissetmedi. Yazılımı umursamayanlar, kendilerini evlerinde hissediyorlardı çünkü daha büyük bir paketin parçası olarak, sadece grup içinde seyreltiliyorlar. Yazılım tutkusu olan bizler, 9 kişinin üzerinde anlaştığı sınırların dışına çıkma ya da dışarı çıkma özgürlüğü olmadığı için kesinlikle kendimizi boğdu.
  • Tüm toplantılar sonsuza dek kendime ateş etmek istediğim bir noktaya gitti. Aynı odada görüşü olan çok sayıda insan aynı ucube DLL üzerinde çalışmak zorunda kaldı. Korku.
• Son sürümde, farklı bir şey denemeye karar verdik
  • Birincisi ve en önemlisi, geliştirme grubunu 3-4 geliştiriciden oluşan küçük ekiplere ayırın. Her takım birbirinden göreceli bir izolasyonla çalıştı ancak ekip içinde insanlar çok daha uyumlu çalıştı
  • Bu yaklaşımla, stand up'lar hızlıdır ve planlama toplantıları katı 4 saate kıyasla 1-2 saat sürer.
  • Herkes kendini meşgul hissediyor çünkü her takım sadece o takımdaki geliştiricilerin neyle ilgilendiğini tartışıyor.
  • Her bir takımdan gelen teknik lider, genel projenin yolunda olduğundan emin olmak için periyodik olarak diğer teknik liderlerle görüşür.
  • İnsanları belirli bir modülün "sahibi" yapmak yerine, insanlara uzmanlık alanları tahsis ettik, bu yüzden projeye ilk başladığımızda insanların kendi modüllerine sahip olduğunu hissettik, ancak birkaç ay sonra geliştiriciler birbirlerinin kodlarına bakmaya başlayacaktı. alanlar üst üste binmeye başladı.
  • Kod incelemeleri esastır. Bu, sıkı kod inceleme politikamızın olduğu ve ekipteki herkesin onları sevdiği ikinci sürümdü. Birisi bu kodu değiştirdiğinde, belirli bir alanın uzmanı her zaman bir kod incelemesinde bulunur.
  • Kod incelemeleri ile bir ton bilgi paylaşımımız var ve ekiplerimizin kod kalitesinin genel gelişimini görebilirsiniz. Ayrıca, kod çok sık gözden geçirildiğinden, insanlar başkalarının uzmanlık alanına girdiklerinde, daha önce kodu en az birkaç kez görmüş olma ihtimalleri var.
  • Her ekibin daha büyük bir kısmı tasarım inceleme toplantılarına girmiştir, bu nedenle kodu hiç görmemiş olsalar bile, herkes kendi ekibinin sorumlu olduğu tüm modüllerin genel akışına aşinadır.
  • Bunu yaklaşık 10 ay boyunca yaptık ve izole modül yaklaşımıyla başladığımız ve herkesin her şey üzerinde çalıştığı anlaşıldı. Fakat aynı zamanda, kimse kendilerini sıkışık veya sınırlı gibi hissetmez. Çocukların hala bir otorite anlayışı içinde olduklarından emin olmak için, şu anda çoğunlukla bir formalite olmasına rağmen, onları alan uzmanları olarak bıraktık.

Bu son şeyi yapıyoruz ve iyileştirmeler için bir ton oda olmasına rağmen, genel olarak tüm ekibimiz çok mutlu oldu ve dev bir şirketin bir parçası olduğumuzda çok şey söylüyor.

“Çevik” olduğumuz ilk 3 kez yanlış yaptığımız önemli bir şey, her birine insanlara nasıl çalışacakları ve ne üzerinde çalışacakları söylendiğidir. Bu, ekibinizin projeye tamamen ilgisini kaybetmesinin bir numaralı yolu ve sonra başınız gerçekten belada.

Bunun yerine, tam tersini deneyin. Takıma söyleyin, ne isterlerse yapabilirler ve bir yönetici / lider olarak (eğer sizseniz, eğer yöneticinizin bu kelimeleri tekrar etmesini sağlamıyorsanız) işiniz mümkün olduğunca üretken ve mutlu olmalarını sağlamaktır. Süreç kötü bir şey değildir, ancak süreç diğerine değil bir kişiye ihtiyaç duyduğunda takımınıza yardım etmek için orada olmalıdır.

Ekip üyelerinizden bazıları yalıtılmış bir şekilde çalışmayı tercih ederse, onları (bir dereceye kadar) bırakın. Çiftler halinde çalışmayı tercih ediyorlarsa, bırak gitsinler. Çalışanlarınızın mümkün olduğunca kendi işlerini seçmelerine izin verdiğinizden emin olun.

Son olarak, ve bu çok önemlidir ve her zaman göz ardı edilir. BU SAĞ ALMAYIN (Süpermen veya en azından batman olmadıkça). Düzenli retrospektif toplantılar yapılması son derece önemlidir. Retrospektifleri sunduğumuzda, onlar kitap tarafından yapıldı ve içinde oturmanız gereken başka bir işlem gibi geldi. Bunun için retrospektif bunun için değil. Ekibinizi dinlemek, en fazla acıya neden olan alanları belirlemek ve bunları düzeltmek, böylece herkes işlerine devam edebilmek için. Genelde yazılım mühendisleri genel olarak ürün ve özellikler sunmak ve geçmişe dönük toplantıların iletişim kurması gereken en önemli mesaj gibi, bunun yalnızca kendi yararı için olduğu yönünde. En büyüklerinden başlayarak (veya en kolay olanı orada) engelleri belirlemek ve çözmek istiyorsunuz.

Ekip ile bir toplantı yapın, yapılacaklar listesini gösterin ve kimin ne yapmak istediğini sorun.

Modüllerde düşünmeyin. İşlevsellik öğelerinde düşünün. Bu işlevsellik öğelerini kullanıcı hikayeleriyle (veya başka bir yolla) tanımlayın ve kabul kriterlerini tanımlamayı unutmayın (muhtemelen mevcut uygulamanız tarafından tanımlanır ve işletmenin beklediği değişiklikleri değiştirir). İşlevsel öğelerinizi birikim listesine alın. O zaman, hangi işlevselliğin ilk önce teslim edilmesi gerektiğine öncelik vermesine izin verin (aşamalı ve yinelemeli olarak çalışacaksınız ve öncelik size ilk olarak neyin uygulanması gerektiğini söyleyecektir).

Bunu yaptığınızda, asıl uygulamanızın bir parçası için, geliştirme için hazırsınız demektir. Sonra ne olacağı, seçtiğiniz çevik metodolojiye bağlıdır. Önemli olan kısım, her bir işlevin genellikle birden fazla göreve bölünebileceği ve ekip üyelerinin hangi işleri yapmak istediklerini seçecekleri - buna öz organizasyon denir. Çevik bir işe başladığınızda, kendini organize etme, birinin popüler olmayan ve popüler görevlerin ekip tarafından eşit olarak paylaşıldığından emin olacağı bir yerde yardıma ihtiyaç duyabilir. Takım daha olgunlaştığında, geliştiriciler mevcut kişisel organizasyonla olan anlaşmazlıklarını konuşmaktan çekinmeyecek ve bu takım içinde otomatik olarak ele alınacaktır.

Modüllerde baştan düşünmek iyi bir yol olmak zorunda değildir. Uygulamayı bir nedenden dolayı yeniden yazıyorsunuz ve belki de yanlış modül ayrımına dayanan mevcut uygulama mimarisi, görünen sorunların arkasındaki gizli nedenlerden biridir. Ayrıca, mevcut modüllerden gelen bazı işlevlerin tamamen yeniden tanımlanacağını ve başka bir yere taşınacağını görebilirsiniz.

David'in cevabını kabul etmeme rağmen, bazı detaylardan yararlanabileceğini hissettim:

• Çevik, bu kararları almamanız ve onları takıma itmeniz anlamına geliyor. Böyle bir proje yöneticisi / lideri yok. Sadece takım.
• En iyisini bilenler, işi nasıl bölecekleri ekip üyeleridir.
• Biriktirme işleminizi tartışın ve bir sonraki yinelemede / sprintte neler yapmak istediğinizi öğrenin.
• Ne kadar ikiye bölüneceğinize dair bir fikir edinmek için planlama pokerini veya benzeri yöntemleri kullanın ve sadece gerçek iş paketlerini birlikte bölmeye başlayın .

Temel olarak, sonuç şu: SE'de kimse bu soruyu sizin için cevaplayamaz, ne de bir önemi yoktur, çünkü takım olarak bir cevap bulursanız çok daha iyi olur.

En basit yaklaşım genellikle en iyisidir.

Bunu yapmak için çok iyi ve net sebepler tanımlayamazsanız, görevleri test / log / UI / etc gibi gruplara bölmekten kaçınırdım. Neden, programcıların kendi uzmanlık alanlarının dışında çalışmasına izin verdiğinizde, onlar için işleri daha ilginç ve zorlu tutabiliyor ve kendi alanlarında gelişmelerini ve büyümelerini sağlıyor. Zaman kısıtlamalarının işi uzmanlığa göre bölmenizi gerektirdiğini düşünüyorsanız, en azından her geliştiricinin kendi birim testini yapması gerektiğine emin olun ve sorunları tespit etmek için kod inceleme ve kabul testini kullanın. Kendi testlerinizi yazmak çok çeviktir ve test ediciler için zamanın hazır olmasını beklemek çok israf edici olabilir.

Bu aynı ikilemle karşı karşıya kaldığımda, aşağıdaki yaklaşımı kullandım:

• Projenin kapsamı. Kendinizi ne elde edeceğiniz hakkında bir fikir verin ve projeyi bir dizi işe ayırarak bir özellikler listesi geliştirin.

• Özelliklere Öncelik Verin. Hangi özelliklerin erken yapılması gerektiğine ve hangilerinin müşterilerinize anında değer sağlayacağına karar verin. Geliştiricileriniz aynı modüller üzerinde çalışmaya başlarsa endişelenmeyin, ancak kod birleştirme işlemlerini yönetmek için iyi bir işlem ve araçlara sahip olduğunuzdan emin olun.

• Ekibinizin katılımını sağlayın ve geliştiricilerinizden, özellikleri daha kolay yönetilen görevler listesine bölmede size yardımcı olmalarını isteyin. Grup olarak inceleyin ve görevleri daha kolay tahmin edilebilecekleri şekilde gerektiği şekilde ayarlayın.

• Her geliştiriciden, geliştiricinin üzerinde çalışmak istediği öncelik sırasının en üstünden yinelemelerinizin nasıl yürütüleceğine bağlı olarak uygulanacak bir görev veya bir grup görev seçmesini isteyin.

• Her geliştiricinin, bir sonraki öğeyi öncelik sırasının en üstünden seçmeye geçmeden önce tamamlanıncaya kadar yalnızca bir şey üzerinde çalışmasını sağlayın. Çalışanlarınızın zaman zaman görevleri değiştirmesini sağlamak için cazip olabilirsiniz, ancak bu, geliştiricinin zamanı açısından israfa neden olur. Kendinizi bağımlılık darboğazlarıyla bulursanız, görev önceliklerini ayarlamanız ve israfı en aza indirmeniz gerekecektir.

• Geliştiricilerin üst üste gelen yinelemelerle çalışmasından ve sürümlerinizi buna göre yönetmekten korkmayın. Bu, görevlerin tamamlanmasını bekleyen sürümler arasında boşa harcanan zamanı en aza indirmeye yardımcı olacaktır.

Sonuç olarak, Çevik olmak ekibiniz, şirketiniz ve müşterileriniz için iyi sonuç veren bir çözüm bulmaktır. Sizin için en işe yarayacak uygulamaların dengesini bularak sürecinizi ayarlamak size kalmıştır. Görevlerinizi nasıl böleceğiniz çok daha büyük bir sürecin çok önemli bir parçası olacak, ancak istekli katılımı teşvik etmeyi ve daha sonra ortaya çıkan süreçle ilgili sorunları çözmeyi zorlaştırmamak için yapabileceğiniz kadar basit tutulmalıdır.

Hiçbir geliştirici ekibi organizasyonel tartışması, Dr. Fred Brooks'un Cerrahi Takımından bahsetmeden tamamlanamaz .

Temel formül: Çalışma Birimi başına bir Cerrahi Ekip

Cerrahi Ekip Tanımlama

Cerrahi ekip kavramı iki temel düşünceye dayanmaktadır:

1. Daha az sayıda geliştirici iş birimi başına daha iyidir, çünkü karşılıklı konuşma üretkenliği öldürür.
2. Yüksek üretim geliştiricileri, düşük üretim geliştiricileri (ve Brooks'a göre, orta üretim geliştirici diye bir şey yoktur), bu yüzden yapmaları gereken en iyi işi yapmaları ve dikkat dağıtıcılarını sınırlandırmaları iyi oldu.

Bir cerrahi ekip, 3-10 geliştiriciden oluşur:

1. Baş programcı. Gerçek programlamanın çoğunu yapan, yüksek verimli bir geliştirici.
2. Bir yardımcı pilot. Bazı programlama yapan, ancak aynı zamanda toplantılara katılmak ve gereksinimleri toplamak gibi bazı idari görevleri de yapan bir diğer yüksek verimli geliştirici.
3. 1 - 8 asistan. Brooks, bunları dokümantasyon, kod temizleme, araştırma, yazma araçları / algoritmaları, test etme, vb. Gibi şeylerden sorumlu geliştiriciler olarak tanımlamaktadır. muhtemelen projenizin ihtiyaçlarına göre atanmalıdır.

Bir İş Birimi Tanımlama

Şimdi bir takımı bir araya getirebileceğimize göre, onlara ne atayalım?

• Proje çok küçükse , bu kolaydır. Tüm projeye bir cerrahi ekip atarsınız.
• Aksi takdirde, tüm projenin mimarisinden sorumlu bir kişi veya ekiple başlamanız gerekir . Çalışmayı ek alt takımlar arasında paylaştırmak için yazılımı uygun şekilde modüle etmek onların işi olacak. Mimar ekibi, geliştiricilerin çok ince yayılmaması için başka işler de yapabilir.

Üç temel, kabul edilebilir model ortaya çıktığını görmelisiniz:

1. Her katman için tam olarak 1 alt takım (UI, DAL, vb.)
2. Her modül için tam olarak 1 alt ekip (Ana Sayfa, Destek Sitesi, Mağaza)
3. İkisinden oluşan bir karışım (düşük seviyeli bir çerçeve ekibi ve her modül için bir kullanıcı arabirimi odaklı ekip)

Geliştiricilere ve modüllere (ve zaman çizelgelerine) bağlı olarak, geliştiricilerime genellikle bir ilginç modül (onlar için) ve bir zorlu modül (tercihen yapmadıkları bir şey) ve sonra kalanları beceri seviyesine göre bölüyorum. zaman kısıtlayıcıları. Bunun geliştiricilere çalışmak istedikleri bir şeyi ve onları zorlayacak bir şey verdiğini biliyorum.

Tabii ki bu her zaman işe yaramaz ...

İşte ne yapardım:

Tüm modüllerin küçük olması durumunda, üzerinde çalışacak bir modül verebilirsiniz. Aksi takdirde, şunu yapın:

1. Her modül boyutunu, karmaşıklığını ve bunu yapmak için gereken becerileri tanımlayın.
2. Her takım üyesi becerisini tanımlayın.
3. Hangi insanların birlikte iyi çalıştığını ve hangilerinin başkalarıyla iyi çalışmadığını tanımlayın.
4. Modül beceri gereklilikleri ve takım becerilerine göre birlikte çalışan insan ekiplerine büyük modüller atayın.
5. Kalan modülleri, modül becerileri gereklilikleri ve takım becerilerine dayanarak diğer insanlarla iyi çalışamayan kişilere atayın.

Başkalarıyla çalışmak istemeyen insanlar en yetkin kişilerse ve bu durum ortak bir durumsa, yukarıdakiler işe yaramayacaktır, bu nedenle 4 ve 5’e istisna yapın.