Birden fazla projeniz varken Scrum nasıl çalışır? [kapalı]


91

Scrum'ın faydalarını ve süreçlerini oldukça iyi okuyorum. İş yığını, tükenme çizelgeleri, yinelemeler, kullanıcı öykülerini kullanarak ve Scrum "çerçevesinin" diğer çeşitli kavramları hakkında fikirler edinirim.

Bununla birlikte ... Aynı anda birden fazla projeyi yöneten ve "üretim ekibini" oluşturan altı ekip üyesiyle bir web geliştirme firmasında çalışıyorum.

Scrum, birden fazla projeye sahip olmakla nasıl çalışır? Hala tek bir proje için belirli bir süre içinde bir yineleme planlıyor musunuz ve tüm ekip onun üzerinde çalışıyor ve ardından bu yineleme tamamlandığında yeni bir yinelemeyle bir sonraki projeye geçiyor musunuz? Yoksa aynı anda yalnızca bir ekiple birden çok projeyi kendi yinelemeleri ile yönetmenin "çevik" bir yolu var mı?


9
Keşke bilseydim, 3+ projede yer alsam ve günde 3+ SCRUMS yapmam gerekiyor. : cry:
Chad Grant

Bu soru konu dışıdır çünkü burada hangi konular hakkında soru sorabilirim? Bölümünde tanımlandığı gibi bu sitenin kapsamında değildir. Ayrıca bkz: Ne tür sorular sormaktan kaçınmalıyım? Başka bir Stack Exchange sitesinde , örneğin Proje Yönetimi veya Yazılım Mühendisliği'nde soru sorabilirsiniz . Soru göndermeyi düşündüğünüz tüm siteler için yardım merkezindeki konuya ilişkin sayfayı okuduğunuzdan emin olun.
Makyen

3
@Makyen Burada dikkate alınması gereken bir şey, bu sorunun başarılı bir şekilde 8.5 yaşında olduğu ve alt Yığın Değişimlerinin çoğundan çok önce geldiğidir. Bu yüzden konu artık en iyi Proje Yönetimi Yığın Değişimi gibi bir şey tarafından sunulabilirken, o zamanlar Scrum'ın uygulamaları hakkındaki bir soru, geliştiriciler ve işin en iyi şekilde nasıl yapılacağı konusundaki metodolojileri ile inanılmaz derecede ilgiliydi.
Tim Knight

Katılıyorum, sorulduğu anda mantıklıydı. Soru olarak soruda yanlış bir şey yok. Şu anda SO için konu üzerine değil. SO için konu başlıkları zamanla değişti. Bu soru programcıların ilgisini çekse de, esasen programlama ile ilgili değil. Spesifik olarak programlama değil, projeleri yönetmek için bir yöntem olan Scrum süreciyle ilgilidir. Bu, çok çeşitli proje türleri olabilecek "birden fazla projeyi ... tek bir ekiple ..." yönetmekle ilgilidir. Bu nedenle kapatılması uygundur. Burada yararlı bilgiler olduğu için onu silmek için oy kullanmam.
Makyen

2
Bu soruyu konu dışı olarak kapatmak için oy kullanıyorum çünkü konu programlama değil, organizasyonel uygulamalarla ilgili.
Kristján

Yanıtlar:


61

Scrum, tek bir bağımsız ürün üzerinde çalışmanız gerektiğini gerçekten dikte etmez. Basitçe, yapılması gereken bir sürü şey olduğunu (ürün biriktirme listesi), bir sonraki yinelemede belirli bir miktarda geliştirme süresi olduğunu (proje hızından hesaplandı) ve müşteri tarafından seçilen öğeler olduğunu belirtir. / business, bir sonraki yinelemede (sprint iş yığını) yapılacak bu sorun / görev havuzundan en fazla önceliğe sahip olarak.

Ürün birikiminin ve sprint birikiminin tek bir projeden olması için hiçbir neden yoktur - tek bir projede bile ayrı projeler gibi ayrı iş birimleri olacaktır - UI, iş katmanı, veritabanı şeması vb. Özellikle kurumsal yazılım geliştirme, hepsinin ilerlemesi gereken bir dizi kod tabanına sahip olduğunuzda böyledir. Scrum süreci - toplantılar, sorular, yanma çizelgesi vb. - ister tek ister birden çok proje olsun, hepsi çalışır.

Bununla birlikte, pratikte her bir yinelemenin ana bir temaya sahip olmasının - "raporlama modülünü yapın" veya "XYZ sisteminin API'si ile arayüz" olmasının genellikle iyi olduğunu ve böylece birçok sorunun tek bir proje veya alandan ve yinelemenin sonunda büyük bir çalışma gövdesine işaret edebilir ve ona bir onay işareti koyabilirsiniz.


4
+1: Scrum'ın özü, etkinliği koordine etmek için günlük stand-up toplantısıdır. Tekli veya çoklu projelerde çalışır.
S.Lott

4
S.Lott'a katılmıyorum, bence esas olan sprint ve stand-up toplantısı sprint'i yönetmek için bir araçtır. Proje başına 6 sprint veya 1 koşardım.
kenny

@Kenny: Gerekli değilse, her ayrı proje için günlük bir stand-up'tan vazgeçer miydiniz? Öyleyse, her projenin sprintini yolunda tutmak için ne yaparsınız?
S. Lot

1
@ S.Lott, toplantı sorunların oluşması içindir. Tüm takım için bir tane ayağa kalkarım. Bilgiyi korumaktan zarar gelmez ve farklı / yeni bakış açıları çoğu zaman değerli olabilir.
kenny

Peki ya 3 proje, her biri orada geliştiren 3 ekip üyesi farklı ürün sahipleri için kendi kod tabanına ne dersiniz? Bu durumda 3 takım var mı?
jolySoft

25

Cevabın " biriktirme listesi maddelerine kimin öncelik vereceğine " bağlı olduğunu düşünüyorum (yani, önce ne yapılması gerektiğine karar verin). Bu tek bir kişiyse, bu kişi projelerinizin Ürün Sahibi'dir ve tek bir birikiminiz olabilir, tüm projeler için tüm öğeler - veya proje başına bir biriktirme listesi - ve planladığınızda tüm projelerdeki birikim öğelerini seçersiniz. bir Sprint. Bu durumda, Scrum iyi "çalışır".

Her projenin kendi sorumluluğu varsa, o zaman her bir sorumlunun - az ya da çok bilinçli olarak - projesini / projelerini desteklemeye çalışacağı bazı sorunlarla karşılaşmanız muhtemeldir. IMHO, yalnızca öncelikleri tahkim yoluyla belirleme yetkisine sahip bir Ürün Sahibi'ne sahip olmanız gerekir.

Böyle bir bağlamda uyulması gereken kurallardan biri , Sprint sırasında Sprint içeriğini asla değiştirmemektir . Gerekirse, mevcut Sprint'e acil bir öğe eklemek zorunda kalma riskini azaltmak için yinelemeyi iki veya üç haftaya kısaltabilirsiniz.


16

Katılmam gerekiyor. Bence bir takımın bir sprint sırasında tek bir projeye odaklanması sürecin anahtarıdır. Tüm geliştirme sürecine katkıda bulunamayacak bazı uzmanlarınız varsa (içerik yazarları, grafik uzmanları, iş süreci analistleri vb.), Artık katkıda bulunamayacakları zaman onları ekipten uzaklaştırırım. Ya da daha iyisi, onları bazı farklı görevler konusunda eğitin, böylece test etme gibi şeylere katkıda bulunabilirler.

Akılda tutulması gereken bir diğer nokta da, projeleri paralel olarak yürütmenin programınızı bozmasıdır. Şunu bir düşünün: basitlik adına, diyelim ki aynı ekibi kullanan ve aynı tarihte başlayan 5 projemiz var. Her projenin 3 aylık bir çabaya ihtiyacı vardır, paralel çalışan en iyi senaryoda hepsini bir kerede bitireceksiniz ve 15 ay sürecektir. Tek bir sprint'e aylık çabanın yalnızca 1 / 5'ini sığdırabileceğiniz için hızınız yükselecek. Ayrıca aynı anda 5 demo toplantısı yapacaksınız. En iyi senaryo, 5 projenizi 15 ayda teslim edersiniz ve rekabetiniz aynı işi 3'te de yapabileceklerini iddia eder. Olgunluğu tahmin eden ekipleriniz zarar görecek çünkü mevcut işgücünün yalnızca% 20'sini dikkate alabilecekler. Aslında bazı görevleri tek bir sprintte gerçekleştiremeyeceğinizi fark edebilirsiniz. Çalışılan proje sayısını 5'ten değiştirmeniz gerekirse, ekibinizin, takım verimliliğine zarar verecek olan tahmin alışkanlıklarını ayarlaması gerekecektir. Ek olarak, basit bir görev yeniden atama, işe başlamadan önce yeni bir geliştirme ortamı oluşturmayı gerektirdiğinde, ekibiniz kendi kendini organize etmeyi zor bulacaktır.

Aynı 5 projeyi seri olarak yürütecek olsaydınız, 5. projeyi aynı 15 ayda teslim edersiniz, ancak müvekkilinize ekibinizin 12 aylık bir birikiminiz olacak ve kullanabileceğiniz kadar talep gördüğü konusunda eğitim verirdiniz. o zaman proje hedeflerinizi geliştirmek için. Ya da sürekli bir birikiminiz varsa, başka bir ekibi işe alma zamanının geldiğini biliyorsunuzdur. Bununla birlikte, en iyi projeniz, aktif dönemde hızlı gelişmeler gören bir müşteriyle 3 ayda tamamlanır. Bu projeyi bir yıl önce bitirebilir ve özgeçmişinize koyabilirsiniz. Sprint hızınız bu süre boyunca sabitlenecek ve bunun bir veya iki projeden sonra adımını attığını ve belirli bir sprintte daha fazlasını başarabildiğini görebilirsiniz.

Sanırım projeleri seri olarak yürütmek, bir organizasyonun saldırı yüzlerini benimsemeye çalışan en büyük engellerden biri. Bu, proje yöneticisi rolünün yeniden yapılandırılmasıyla ilişkili büyük bir kültürel değişimdir, ancak scrum sürecinin faydaları çok büyüktür.

HERKESİN tam bir ekip üyesi olmasına gerek olmadığını unutmayın. Müşterinizi bekleme odasında tutarak geliştirme sürecine hazırlanabilirler. İş analistlerimi, ağ mimarlarımı ve grafik tasarım çalışanlarını alan uzmanları olarak tutuyorum ve onları yalnızca gerektiğinde bir ekibe bağlıyorum. Sprint 0 ile koşmalarına izin verin. Görünüm ve his ve iş akışı üzerinde çalışmanın ne kadar ilgi çekici olduğuna şaşıracaksınız. Müşterinizi, ciddi bir gelişme başladığında, katılım seviyelerinin gerçekten yükselebileceği ve ulaşılabilir olmasının onlar için önemli olduğu anlayışıyla hazırlamak da iyidir. Tatil ve tatil gibi şeylerle çok önceden ilgilenmek için bolca zamanları olsun diye programı bilmelerini sağlayın.


Bu yalnızca ekip üyelerini yeniden atayabiliyorsanız işe yarar. Gidecekleri bir yer yoksa, onları boşta bırakamazsınız.
BlueChippy

8

Ben bu kesin durumdaydım.

Projelerde tek bir ürün sahibiniz varsa, Phillipe kesinlikle haklıdır; Tek takımla yapılan bir sprint gayet iyi çalışmalıdır.

Birden fazla ürün sahibiniz varsa, ideal olarak iş tarafı, işi planlama sorumluluğu verilen tek bir 'öncelik belirleyici' seçmelidir. Bu kesinlikle en iyi çözüm.

Eğer (muhtemelen olduğu gibi) işletme bir şeylere öncelik verme şeklini değiştirmek istemiyorsa (bu çok uygun olur), takımı bölebilir ve iki eşzamanlı sprint çalıştırabilirsiniz. Ancak altı kişilik bir ekiple, onu 3'ten fazla takıma bölmezdim (hiç bölmek istemezdim, ancak 2-3 takımın işe yarayacağını düşünüyorum). Kenny'nin önerdiği gibi daha fazla bölünmek ve tek bir kişiden oluşan ekiplere sahip olmak bana biraz anlamsız geliyor, çünkü artık bir ekibiniz yok, sadece bireysel programcılar.

Ekibi bölüyorsanız, aynı kod tabanının büyük bir kısmında çalışan ayrı sprintleriniz yoksa, stand-up'ları birleştirmede pek bir değer bulamadım, ancak bu, bu takımları aşağıdaki amaçlarla birleştirmek için bir tartışma olabilir sprint.


5

Son zamanlarda okuduğum başka bir görüş var, yani Çevik bir ortamda Proje kavramı ters etki yapabilir ve ortadan kaldırılabilir. Bu düşünce tarzına göre, organizasyon bunun yerine Bültenlere odaklanmalıdır . Çünkü Projeler , bitene kadar hiçbir değer üretmeyen yapay iş kutularıdır. Agile'ın sık sık sevk edilebilir değer sunma hedefine aykırıdırlar. Bir Sürüm , Çevik ile daha uyumludur çünkü değer sunmaya yöneliktir ve kapsamı ekiplerin bir sonraki Sürümden önce neler sunabileceğine bağlı olarak azaltılabilir veya genişletilebilir .

Önceden şirketinizde Proje olarak adlandırılan şeyin artık ortak Çevik Tema veya Özelliği olarak yeniden paketlendiği potansiyel bir orta yol var . Bu yaklaşımın yararı , Ürün sahibi uygun gördüğü için Tema veya Özelliğin artık değerli parçalar halinde uygulanabilmesidir.

Hala birden fazla Ürün üzerinde çalışan bir ekibin sorusu var ve bu, alan bilgisi ve olası teknik beceriler hakkındaki meşru endişeler nedeniyle bir sorudur. Ancak Çevik ile oluşturulan Ürünler , tek bir ekip tarafından oluşturulan birden çok Ürün bile sürekli olarak Serbest Bırakılabilir değer biriktirir . Bunun aksine, Projeler bitene kadar hiçbir değeri yoktur (ve çoğu değildir).

Düşünmek için bir şey...


1
Kabul edildiğinde, henüz hayata geçirilmemiş ve birikmiş iş değeri olan 'yazılım envanterini' en aza indirmemiz gerekiyor.
AndyM

4

Bence anopres haklıydı: en iyi yol, scrum ile aynı anda birden fazla projeden kaçınmaktır. Paralel olarak çok fazla çalışmanın verimli olmadığından emin olmak için her şeyi yapın.

5 kişilik ekip için yaklaşık 3 ayda bir 5 proje varsayalım.

Yaklaşım 1: her kişi ekipte tek bir proje üzerinde çalışır

  • Proje başına 1/5 teslimat hızı, tüm projeler için 15 aylık teslimat sağlar
  • Her kişi uzman ama sadece kendi projesinde
  • Takım ruhu yok

Yaklaşım 2: Proje başına 1 sprint, projeler arasında geçiş

  • Her 6. sprint proje üzerinde çalışır
  • Proje çalışması arasında çok uzun zaman - proje için düzenli artımlı değer değil (ürün biriktirme listesi için evet), unutulması kolay, içeriği geri yüklemek için gereken çaba
  • İlk proje yaklaşık 12-13 ay sonra teslim edildi (2 haftalık sprint varsayılarak)

Yaklaşım 3: Tek sprintte 5 proje

  • Sprint'e sığması için çok fazla ayrıntılı görev ayrımı gerektirir
  • Proje başına çok az artımlı yapı
  • Yaklaşık 12-15 ay sonra ilk projenin teslimi

Yaklaşım 4: önerilen - Serileştirilmiş çalışma

  • Takım proje sonrası tek proje üzerinde çalışır
  • İlk proje başladı ve 3 ay sonra teslim edildi
  • 3. aydan sonra başlayan ikinci proje 6. aydan sonra teslim edildi
  • ...
  • 12. aydan sonra başlayan 5. proje 15. aydan sonra teslim edildi
  • Ekip, projeye, yoğun araştırmaya ve müşteri ile işbirliğine odaklanmış
  • Tüm ekip, tüm projeler hakkında genel bilgi sahibidir.
  • Bağlam değiştirmede zaman kaybı yok
  • İyi bir ekip işbirliği gerektir (çatışmalar teslimatı yavaşlatabilir)

Gördüğünüz gibi 4.Çözüm genellikle daha iyidir çünkü projeler çok daha hızlı teslim edilir, ekip birlikte çalışır ve verimli olur. Diğer yaklaşımlar arasında bağlam değiştirme, tam ekip işbirliği olmaması, tüm projelerin çok uzun toplam teslim süresi vb.

Ve birikmiş işlerin bakımı ne olacak? Ekip aynı anda tek bir proje üzerinde çalışırsa bu basittir - herkes katılacaktır. Birden fazla proje varsa, tek tek kişileri ayrı ayrı tımar seanslarına devretmemiz gerekebilir (tam ekip dahil değildir).

Müşterilere, 2. projeye 3 ay sonra başlamanın, diğer tüm projelere hemen başlamak yerine, daha hızlı teslimatla (6. aydan sonra) sonuçlanacağına inanmak önemlidir. Yöneticilerin gördüğü bir yanılsamadır - aynı anda 5 projeye başlıyoruz, çok çalışıyoruz ve yavaş yavaş teslim ediyoruz. Sonuçta bu verimli değil.

Bu yüzden scrumın paralel olarak birden fazla proje için verimli olduğuna inanmıyorum, onu çerçeveye uydurmak ve scrum kurallarına göre çalışmak çok zor. Bazen tüm insanları meşgul etmek için 2 projeye sahip olmak iyi olabilir, ancak ne kadar çok proje eklersek o kadar az verimli scrum olacaktır. Belki kanban sadece ilerlemeyi ve takım çalışmasını görmek için bir alternatiftir (Scrum takımındaki kadar güçlü değil)?

Saygılarımızla, Adam


3

@Chris'in dediği gibi, normal bir projenin içinde alt projeleri vardır. Yine de yalnızca bir birikiminiz var.

Tüm projelerinizle bir biriktirme listesi düşünün. İlk sorun: görevlere veya projelere öncelikler mi veriyorsunuz? Proje başına bir biriktirme listesi tercih ederim. En azından ürün sahibinin sahip olduğu öncelikleri netleştirmek.

Farklı ürün sahiplerine sahip olmak ve bu ürün sahiplerinin her projeye ne kadar zaman vermeleri gerektiği konusunda hemfikir olmayacaklarından dolayı. "Birisinin" projeler arası önceliklerin nasıl yönetileceğine ilişkin kararı özümsemesi gerekecektir. Not: geliştiriciler bunu yapmamalıdır.

İşte ürün sahiplerinin ihtiyaç duyduğu kaynakları ve ekibin üyelerinin verebileceği zamanı dengeleyecek olan proje "S" yöneticimiz geliyor. Ürün sahibi A bir aylık çalışma için ödeme yaptı, ancak ürün sahibi B her zaman projesini güncelliyor (ve size de iyi ödeme yapıyor). A'nın bir ayını (geliştirici zamanı) alması ve B'nin ceplerinizi doldurmasını engellememesi için takımınızı nasıl dengeleyeceğiniz bazı şeyler var.

Dahili yazılım durumunda (bir şirket, bin proje). Farklı ürün sahipleri kendilerine verilen süre konusunda anlaşmalıdır. İzole değil, sizinle aynı gemide (proje "S" yöneticisi) yaşıyorlar. Bazı görevleri ertelemek hayatınızı kolaylaştıracak, ancak aynı zamanda ihtiyaçlarını asla unutmamalısınız.

Hâlâ bunu yapmanın en iyi yolunu bulmaya çalışıyorum. Ama şu anda bastırdığımız şey bu. Umut ediyorum bu yardım eder.


3

Ekip üyeleri zamanlarını scrum projeleri arasında paylaştırabilir, ancak ekip üyelerinin kendilerini tamamen adanmış olması çok daha üretken. Takım üyeleri de bir sprintten diğerine geçebilir, ancak bu aynı zamanda takımın üretkenliğini de azaltır. Daha büyük ekiplere sahip projeler, çabalarının yakın koordinasyonu ile her biri ürün geliştirmenin farklı bir yönüne odaklanan çoklu scrumlar olarak organize edilir.


0

Her Proje için bir Sprint çalıştırmanızı ve tüm aktif Yayları / projeleri ele almak için 1 günlük standup toplantısı yapmanızı öneririm.


Kenny yani her proje için bir seferde bir sprint? Yoksa aynı anda birden fazla sprint yapmaktan ve takımı diğerleri gibi bölmekten mi bahsediyorsunuz?
Tim Knight

Tim Hey, hayal oldu değil sprint koşuları ile bölme ekipleri tarafından ekip yapısını değiştirerek, ama sadece her proje için ... vb ayrı sprintler / backlogs / çalıştırın. Her stand-up'ta, her bir kişinin neyle uğraştığı konusunda yorum yapmasını sağlayın. Benim için herkesi / her şeyi takip etmek veya farkında olmak güzel olurdu.
kenny

0

Katkıda bulunmak isterim. Ben böyle yapıyorum:

  • Takım başına bir ürün sahibi ve bir ürün biriktirme listesi vardır. Ürün sahibinin tek bir kişi olması gerekmez, ancak bu ürün sahibi "varlık", ürün birikiminden sorumludur.
  • Ürün biriktirme listesi, her projenin (buradaki tüm projeler) kullanıcı hikayelerini içerir. Her kullanıcı hikayesinin bir çaba / hikaye puanı (ekip sorumluluğu) ve bir iş değeri (ürün sahibi sorumluluğu) vardır.
  • Her sprinti karşılayan bir "ürün birikimi düzenlememiz" var. Bu toplantıdan önce, ürün sahibi hikayelerin iş değerlerini güncelledi (iş nedeni ne olursa olsun, bizim umursamadığımız ve etmememiz gereken bir değişikliğe ihtiyaçları varsa) ve bazı yeni hikayeler ekledi. Bu toplantıda yeni hikayeler anlatılır ve çabalar da güncellenir. Bu toplantı yaklaşık bir saat sürer (ilk sefer hariç, yaklaşık 4 saat).
  • Yeni bir sprint planlayacağımız zaman, ürün iş yığınını açarız, hikayeleri ROI'ye göre sıralarız (bu iş değeri / çabadır) ve zaman geçene kadar hikayeler planlarız.

Ve bu kadar. Bunun oldukça iyi çalıştığını söyleyebilirim. Bunu yapmak için birkaç Google e-tablosu (ürün biriktirme listesi ve hem çizelge hem de malzeme içeren sprint biriktirme listesi) ve her gün çevrimiçi bir organizasyon için redmine (belirli bir semantikle) kullanıyoruz: zaman, görev ilerlemesi, vb.

Bu yaklaşımla ilgili sorun, sprint iş yığını elektronik tablosundaki ve redmine'deki görevleri kopyalamamdır. Ancak bunu tamamen çevrimiçi yapmak için herhangi bir çevrimiçi araç bulamıyorum. Redmine'de bir ürün biriktirme listesi (benim için başka anlamsal çalışma yok), jira'da tek bir pano, taygada daha fazla hikaye vb. Özledim


Bir yığındaki her bir ürüne nasıl odaklanabilirsiniz? Etiketler, adlandırma kuralı vb.? Benzer bir yaklaşım uyguladım, ancak her şeyi TFS'de tutmaya çalıştım ve henüz Özellikler / Hikayelerin hem birikimine hem de ürün görünümlerine izin vermek için iyi bir çözüme ulaşmadım.
BlueChippy
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.