“Ana” özellik birikimine paralel olarak “ısırık boyutunda” görevlerin bir biriktirme listesi mi?


16

Son derece sessiz, "yalnız kurt" geliştirme departmanı yapısında iki yıldan fazla çalıştıktan sonra Agile SCRUM'u benimsiyoruz. Harika. Çevik'i severim; bir geliştirici olarak, dün yaptıkları beklentisiyle boğazınızı projelendirdikten sonra sayısız paydaşınızın projeyi shoving etmesine odaklanmadan, yoğun ve üretken olmanızı sağlar.

Bununla birlikte, şu anki “modelimiz” e karşı SCRUM'a geçmenin bir yönü var, bence Geliştirme dışındaki insanlar en ufak bir şekilde sevmeyecekler. Bu onların şu andaki yeteneklerini "siz beklerken" küçük değişiklikler yapmamızı sağlıyor. Gelişimimizin büyük bir kısmı sadece şirket içi tüketim içindir ve hepimiz aynı binadayız. Bu nedenle, başka bir yerde bir bölüm lideri veya yöneticisinin belirli bir uygulamanın "kod temeli sahibine" gelmesi ve küçük şeyler istemesi (bazen o kadar küçük değil, ama üçünü almama konusunda oldukça iyiyiz). bu "sürüş" e dayalı haftalık projeler). Patronumuz bile bazen kendisine getirilen şeyleri bu şekilde aktarır. Çok sık, o sırada söz konusu kod tabanında çalışıyorsak, kaynak dosyayı açabiliriz,

Temel bir Çevik SCRUM metodolojisi ile, bu ince ayarlar ya kusur (daha önce tüketilen bir hikayede belirtilen bir gereksinimi karşılamadık) ya da yeni küçük hikayeler (belirtilen tüm gereksinimleri karşıladık, ancak bu gereksinimler eksik, belirsiz veya yanlış olarak kaydedildi) veya kullanıcılar yeni özellikleri gördükten sonra teslimattan sonra değiştiler). Her iki durumda da, büyük çoğunluk sıfır olmasa bile en fazla bir puanlık olacaktır ve nispeten düşük önceliğe sahiptir (sistem mevcut durumunda kullanılabilir, ancak eğer çok daha soğuk olurdu). biriktirme listesi yukarıdan aşağıya çalışırken sprint haline getirildi.

Bu olasılık, diğer departmanlar tarafından Çevik sürecimize aktif bir muhalefet kaynağı olarak geliştirildi ve bu talep üzerine küçük değişiklikler yapma yeteneğimizden daha az "çevik" olarak görüldü. Bu geçerli bir endişedir IMO; PO'nun arkasındaki paydaşlar her zaman en önemli olan şey üzerinde hemfikir değildir, çünkü hepsinin aynı bakış açısı yoktur, ancak genellikle sadece nihai kararı veren yöneticilerdir ve bu nedenle önyargıları ürün biriktirme listesinde gösterir.

Daha sonra geçici olarak "şeker kavanozu" olarak adlandırılan bir çözüm önerildi (atılan bir başka terim "sos teknesi" idi). Çeşitli departmanlarda "küçük adamlar" tarafından talep edilen, mevcut bir hikayede kusur olmayan, ekip içindeki fikir birliği veya ünlem ile bir geliştirici günün yarısından daha azını alacak şekilde tahmin edilen ve son kullanıcının görüşüne göre kullanıcı deneyimi üzerinde anında, önemli ve olumlu bir etki, birincil biriktirme listesine paralel bir listeye yerleştirilir. Bunlar "öyküler" olarak tanımlanır, ancak önceliklendirmeye tabi olan "büyük" öykülerin birincil birikiminden ayrı tutulmalıdır. Bir süratin normal ilerlemesi sırasında herhangi bir zamanda, sistemin bu ince ayarlardan birinin yapılabileceği bir alanda çalışıyor olursak, tweak önemsiz hale getirerek, tweak'i sprint'e getirebilir ve daha büyük hikayenin yanında kodlayabiliriz. Bunu yapmakolmamalıdır büyük hikaye veya başka bir taahhüt çalışmalarının tamamlandığını tehlikeye. PO da bu listeye erişebilirdi ve eğer tweak içeren temel özelliğe dokunarak yaklaşan bir kullanıcı hikayesi üzerinde çalışıyorlarsa, bunu bir gereklilik olarak hikayeye katlayabilirlerdi ve sonra herhangi bir gereksinimimizi yerine getirebilirdik diğer. Bunun, tweaks üzerinde daha erken çalışılması olasılığını artıracağı düşünülüyordu.

Bu, ScrumMaster'ın "uh-uh" eğitimi ile aramızdaki reaksiyonu tetikledi. Orada bir birikim. İki biriktirme listesi, hangi # 1 öğesinin gerçekten en önemli olduğu, hangi listenin öğelerinin gerçek hızı belirlediği ve bir hikayenin gerçekte ait olduğu iki birikimden hangisinin ait olduğu sorusunu sunar (boyut / karmaşıklığın herhangi bir sınırının göreceli olarak düşen bazı vakaları olacaktır keyfi olarak bir tarafa veya diğer tarafa). "Süreci işleyelim" dedik; değişiklik son kullanıcılar için gerçekten önemliyse, bölüm başkanlarının zaman / para kararları almasını sağlamak için yeterli gürültü yapacaklar ve geliştirici ekibinin birikmiş işlerin üst kısmındaki bilincine girecekler.

Soruyu zemine oturtacağımı düşündüm: Sizce, "ısırık büyüklüğünde" hikayelerin paralel bir listesi küçük, yararlı ama sonuçta düşük öncelikli değişikliklerin daha hızlı yapılmasında değer yaratır mı yoksa genel olarak daha iyi bir karar mıdır? onları ana biriktirme listesi haline getirmek ve temel sürecin bir sprint'e dahil edilmesini yönetmesine izin vermek için?


5
Mevcut kafeterya geliştirme tarzı ne kadar iyi çalışıyor? Herkes bundan memnunsa ve sürekli hareket eden son tarihlerin belirsizliği ile yaşayabiliyorsa, neden scrum kabul edilmeli? Bu sadece retorik bir soru değildir; Scrum'ı benimsemenin ana nedeni, mevcut geliştirme tarzınızın paydaşlarınızın değer verdiği kaliteyi tam olarak ortadan kaldırmaktır. Scrum'ı düşünüyor olmalısın çünkü scrum'un çözeceği bir problem algılarsın; bu sorun yeterli ve ikna edici bir şekilde paydaşlara iletildi mi?
Robert Harvey

Mevcut sistemle ilgili birkaç problemimiz var; birincisi, çeşitli kurum içi uygulamaların kod tabanlarına "sahip" kişiler ek özellikler talep eden "araçlara" gömülür. Devam etmek ve başka bir şeye odaklanmak zor veya imkansız. Bu da temel olarak her geliştiricinin, her uygulamanın en az biraz aşina olduğu bir takım çabası olması yerine, yazdığı kod için "guru" olmasını sağlar. Herhangi bir kod sahipliğinin kötü olduğunu söylememekle birlikte, güçlü kod sahipliği, evet bunu durdurmak istiyoruz.
KeithS

Bu sistem ayrıca iletişimi büyük ölçüde önler; hepimiz hala etrafımızda olan ve onlarla çalışmış olan uygulamaları destekliyoruz ve diğer insanların ne yaptığını öğrenmek için zamanımız yok. Bu, kodlayıcının en çok bildiklerine bağlı olarak farklı çerçevelerin benimsenmesiyle sonuçlandı, kod tabanları arasında birlikte çalışma bir kabus oldu (ve sistem entegrasyonu becerimiz konusunda bir şirket olarak yaşıyor ve ölüyoruz).
KeithS

Son olarak, ne kadar iyi olursa olsun, bir adam tarafından yapılamayan bazı şeyler var. NBT'de yazılan tüm LoC'leri almak için aylar beklemek yerine tüm ekibimizi büyük projelerde koordineli bir şekilde kullanabilmek istiyoruz. Bu, her şey için patronumuzdan geçmeden bu tür bir koordinasyona izin veren bir sistem gerektirir. Şimdiye kadar, sadece onlara gelişmeleri ve sahip olmaları için yeni bir şey vermek amacıyla yeni insanlar işe alma noktasına kadar rahatsız olmadık .
KeithS

Oh, ve son olarak; mevcut gereksinimler dağıtım sistemi öncelikle bu "sürülerek" dir. Tamamen farklı bir kod tabanında derin dirsekler olursam ve küpümü bana sormak için geldiğinde gerçekten ne istediğini hatırlamak için yeterince ayrıntılı olarak yazmıyorsam, tamamen çatlar. Daha büyük projeler için gereklilikler daha organize, ancak her zaman bir şey daha var ve şu anda bu şeyler için merkezi bir depo yok.
KeithS

Yanıtlar:


10

Umarım yolunuzu bulmanıza yardımcı olacak birkaç noktadan bahsedeceğim:

  1. " SCRUM " çevik olmakla ilgilidir. Sağduyu gereklidir. Değişiklik birkaç dakika değişiyorsa, bunun için bir biriktirme listesine ihtiyacınız olduğunu düşünmüyorum. 2 saatten fazla ise, sanırım ikinci bir düşünce vermelisiniz. "Kolay kazanılan" her şey yapılmamalıdır. SCRUM'da önceliklere göre çalışıyorsunuz. PO'nun ekleme ve elde etme çabasından ne elde ettiğiniz hakkında bilgi alması gerektiğini düşünüyorum. Ancak bundan sonra PO önemli olup olmadığına karar verebilir. SCRUM'a geçmek bazen çok fazla soru ile gelir ve geliştiriciler genellikle "ama bu sadece birkaç saat sürer" der. Ne olmuş yani? Birkaç saat zaman, kısa olan her şeyin dahil edilmesi gerekmez.
  2. Bir zamanlar "mühendislik birikimi" olan bir projede çalıştım . Bu biriktirme listesi, geliştiriciler tarafından ürünü geliştirmek için önerilen öğeleri içermektedir. Bu öğelerin açık bir kullanıcı değeri yoktu (ancak örtük bir kullanıcı değeri vardı). Örneğin: koddaki bir bileşenin yeniden düzenlenmesi. Değişikliği, çabayı ve kazancı tanımlamıştık (bu durumda, kullanıcıya hiçbir şey sunamazsınız. Ancak böyle bir yeniden düzenleme yeni yetenekleri daha hızlı geliştirmeye neden oluyorsa, bu kesinlikle kullanıcı için bir kazançtır). PO'muz, sürüm sırasında her bir sprint'in (%)% 10'unu bu tür öğelere yatırmamız gerektiğine karar verdi. Her sprintten önce, PO yaklaşmakta olan sprint'in biriktirme birikimine karar verdiğinde, enginerring birikim biriktirme öğelerinin% 10'una sahip olduğumuzdan emin oldu. Yani 2 sürüm biriktirme listesi -> 1 sprint biriktirme listesi.
  3. Tamponlar - SCRUM'da çalışmaya başlarken insanlar genellikle yazılım mühendisleri olarak belirsizlik dünyasında ayrıldığımızı unuturlar. 1 gün çalışmayı 8 yerine 6 saat saymak sorun değil. Diyelim ki 15 günlük bir sprintiniz var, yani toplantılara, çok uzun süren şeylere ekstra 30 saatiniz var ve evet - bu küçükler için de hatırlamayacak kadar küçük ama 2 günlük işimizin bir parçası olan şeyler.
  4. Odaklanın - Son olarak, SCRUM'da odaklanmış kalmak önemlidir. Bu tür görevlere yatırım yapmak için ne kadar çaba harcadığınıza ve önceliğinizin ne olduğuna karar verin ve bu zaman ve çabaya yatırım yapmayı unutmayın. Sadece küçük oldukları için "küçük şeyler" üzerinde çalışmak için sürüklenmeyin. Karar vermenize yardımcı olacak bir PO'nuz var ve sağduyunuz var.
  5. Çevik Kalın - Ve sonunda, soruna yaklaşmak için farklı yöntemleri denemeyi unutmayın, bunun gerçekten en iyi yol olup olmadığını kendinize sorun. Yolda geliştirin.

İyi şanslar :)


1
Mühendislik birikimi için +1. Bu, aksi takdirde hiçbir zaman kesim yapmayan kullanıcı istekleri için de kullanılabilir.
Bart van Ingen Schenau

3

Agile ve SCRUM gibi programlama çerçeveleri, disiplini ve yapıyı gelişime uygulamak için tasarlanmıştır. Ancak, disiplin ve yapı eğlence ve yaratıcılığın zıtlıkları gibi görünmektedir. Genellikle, disiplini kurmak ve sürdürmek için daha çok çalışmanız gerekir. Bu karşıt kavramlar arasında bir denge bulmak çok zordur. Bu nedenle, çerçeveler konuyu önleme eğilimindedir.

Son projemde, geliştiricilerin kafalarını yenilemek veya temizlemek için her gün biraz zamana ihtiyaç duyduklarını gözlemledik. İçlerine her şey yapabilecekleri bütçelenmiş zaman (.5 saat / gün veya 2.5 saat / hafta) verildi. sebep (işyerindeki bir şeye uygulanabilme olasılığı ile). İşleri disiplinli tutmak için, faaliyetlerini belgelemeleri istendi, böylece herhangi bir başarı, vb. İçin kredi alabilsinler.

Btw, bizimkine "proje serinliği" adını verdik ve bu şirketteki birçok iyi fikir ve gelişmenin kaynağı oldu.


3

Küçük hikayeleri ana iş listesinde tutmalısınız.

Scrum kullanmama rağmen tanımladığınız şeylerle benzer sorunlarla karşılaşıyorum. Önceliklendirme ve verimlilik zorluklarıyla karşılaştığınızı görüyorum .

"Eski yolunuz" altındaymış gibi görünür, herkes bir geliştiricinin ofisini ziyaret ettiyse, görevlerini mevcut "en öncelikli" yapmak için örtük olarak yetkilendirilmişti. Bunun bazı faydaları var. İstekte bulunan kişiye yanıt veriliyor gibi geliyor ve istekte bulunan ve geliştirici "hızlı bir kazanç" elde ediyor.

Dezavantajı, bu görevleri sık sık eklemenin, ürün sahibi ile üzerinde anlaşılan en öncelikli görevleri yavaşlatma veya rayından çıkarma eğiliminde olmasıdır. (Yan not, genellikle herkes bu "hızlı" düzeltmeler için gereken süreyi hafife alır.)

Deneyimlerim, düşük öncelikli bir görevde sıkıştırmaya çalışmanın, önceliklendirmenin faydalarını baltaladığı yönündedir. Bir geliştirici olarak, önceliklendirme bana ürün sahibinin üzerinde çalışmamı istediğim şey üzerinde çalıştığımı doğrular. Ürün sahibi, "olması güzel" bir istekte ekstra iş ve katlanma riski (ancak hafif) almak isteyip istemediğine karar vermelidir.

Genellikle paydaşlardan öncelik vermelerini istediğimde, "Bunu sadece sıkıştırabilir misiniz?" Zımni arzu, yeni görevi şu anki en yüksek önceliği etkilemeden sihirli bir şekilde tamamlamamdır.

Sık sık başıma gelen şey, paydaşların LargeImportantProject ve SmallLessImportantTask istemeleri. İkilem, SmallLessImportantTask, LargeImportantProject'in bitmesini (veya birlikte gösterime sahip olmasını) beklemeli mi? Farklılıklar var ve benim deneyimim ürün sahibinin karar vermesi gerektiğiydi. (Ürün sahibi karar vermezse, geliştirme ekibi tahmin etmek zorundadır.)

Scrum'ın (ve genel olarak proje yönetiminin) bir amacı, en yüksek öncelikli görevler için birlikte gösterimlerden kaçınmaktır. Daha verimli hale geldikçe, ekstra "olması güzel" işlerde sıkmak için daha az yer vardır.

Verimlilik korkutucu olabilir, ancak maliyetin iki önemli yoldan daha ağır basmasının faydalarını gördüm.

  1. Daha verimli hale geldikçe, ekibinizin değerli çalışmaları tamamlama kapasitesini arttırırsınız.
  2. Bir talep gerçekten "sahip olmak güzel" ise, talebin daha önemli iş öncelikleri karşılanana kadar beklemesi büyük olasılıkla tamamen meşru olur.

Güzel nokta. Şu ana kadar fikir birliğinin aksine, soruyu bu yüzden sordum; tüm bakış açılarını elde etmek için.
KeithS

Aaron'un söylediği her şey doğrudur ... ama hepsi "büyük şirket" dinamiklerine yol açar. Son kullanıcının istediklerini alması için çok fazla çemberin atlanması gerekiyor. Böylece, sonunda iyi bir araç almak ve sadece "crummy" aracını olduğu gibi kullanmakla sonuçlanan küçük ayarlamalar önermekle duracaklar.
13:15, Dunk

2

Bence; sorununuz, biriktirme listesinde görevlere öncelik verme yöntemidir. Örneğin, "öncelik" hem önemi hem de ne kadar hızlı tamamlanabileceğini dikkate alabilir. O kadar önemli olmayan ancak 10 dakika içinde tamamlanabilecek bir şeyin uygulanması birkaç hafta sürecek daha önemli bir şeyden daha yüksek önceliğe sahip olabilir.


1
Bu iyi bir nokta; Öncelik ayarlanırken "YG" dikkate alınmalıdır. Sizi en hızlı şekilde iyileştiren şeyi yapın. Bu biriktirme listesi oluştururken teşvik edilebilir ( Agile benimsememizde gerçekten erkendiriz).
KeithS

2

Bir süredir çevik bir şekilde çalıştım. Söyleyebileceğim tek şey bu - bir metodolojide ısrar eden ve içerdiği her şeyin kesinlikle yanlış olduğu durumlar var. ÇEVİK olmalısınız ve belirli durumlarda bir metodolojiyi değiştirmek IMO, bir zorunluluktur.

Yukarıdaki Avi gibi - "SCRUM" çevik olmakla ilgilidir. Sağduyu gereklidir. Değişiklik birkaç dakika değişiyorsa, bunun için bir biriktirme listesine ihtiyacınız olduğunu düşünmüyorum.

Değişiklik zaman alırsa, bu "zararsız" değildir ve iyi belgelenmelidir.


0

İlk sorunuza ve sonraki açıklamalarınıza dayanarak, ağrı noktalarınızın

  • Sürekli değişen gereksinimler
  • Geliştiricilerin uygulamanın diğer alanlarına odaklanamaması, yani. biz uygulamanın bir bölümünde kahramanlar ama başka herhangi bir dokunmak için istekli değil.
  • Mimariye farklı yaklaşımlar, çözümler, çerçeveler benimseniyor
  • Gereksinim toplama işlemi işe yaramıyor

Scrum, başlangıçta doğru şekilde yapıştırılırsa, bu sorunların çoğunu düzeltmeli ve daha da önemlisi, çözülmesi gereken diğer sorunları ön plana çıkarmalıdır.

- Sürekli değişen gereksinimler

Her şeyin beslendiği ve doğru bir şekilde önceliklendirildiği tek bir biriktirmeye sahip olmak, ekibin gelişimin ortasındayken değişen gereksinimleri zorlamaması gerektiği anlamına gelmelidir. Çok dinamik bir ortamsa, 1 veya 2 haftalık daha küçük sprintler, nispeten kısa sürede değişen önceliklerin hala kolaylaştırılmasını sağlamalıdır.

- Geliştiricilerin uygulamanın diğer alanlarına odaklanamaması, yani. biz uygulamanın bir bölümünde kahramanlar ama başka herhangi bir dokunmak için istekli değil.

Birlikte çalışan ve birbirini destekleyen bir scrum ekibi, ekip içinde bilgi paylaşımına yönelik özel bir itici güç ve uygulamanın diğer bölümlerinde çalışma zorluğu arayan uygulamanın bilgilerinin paylaşılmasını sağlamaya çalışacaktır. Çift programlama gibi bazı uygulamalar, insanların bu bilgileri öğrenip paylaşırken aşina olmadıkları kod üzerinde çalışma korkusunun üstesinden gelmelerine yardımcı olabilir. Bu, uygulamanın bilgisi ekipler arasında dağıtılmadan ve insanlar uygulamanın herhangi bir alanında rahat çalışmadan önce birkaç sprint alabilir. Ayrıca, insanların bir tahtanın görevlerini çekmelerine izin vermek, yani çalışmak istedikleri şeyleri kendi seçimlerini yapmalarına izin vermek bunu teşvik edebilir.

- Mimariye farklı çözümler, çözümler, çerçeveler benimseniyor

Scrum daha iyi iletişimi kolaylaştırır, ekip çalışmasını ve daha iyi karar almayı kolaylaştırır, ayrıca neler olup bittiğine daha fazla görünürlük sağlar. Bu sırayla, çerçevelerin, mimari çözümlerin vb. Kullanımı ile ilgili örgütsel kararları kolaylaştırmalı ve Scrum of Scrums mekanizmasının kullanımı, kurum genelinde aşılanmasına yardımcı olabilir.

- Gereksinim Toplama Süreci

Yine, kurallara sıkı sıkıya bağlı kalırsanız, şartın yerine getirilmesi için neyin gerekli olduğunu anlayabilmesi ve tahmin edebilmesi için bir şart belirtilmemiş ve hazır değilse, sprint'e getirilmemelidir. Yüksek öncelikli ve iyi tanımlanmış başka bir gereksinimi ele alalım ... çünkü o zaman bunu sağlayabileceğinizi biliyorsunuz! Gereksinim toplama sürecini hemen düzeltmeyebilse de, bu işlemi düzeltmek için gerekli değişikliği zorlar.

İlk sorunuzu cevaplamak için, hayır, iki ayrı birikmiş iş olmamalıdır. Herhangi bir zamanda, geliştiricilerin ve kuruluşun öncelikle en yüksek öncelikli öğeler üzerinde çalışması herkesin yararınadır. Öncelikler esas olarak iş değerine dayanmalıdır ve küçük ayarların ve taleplerin çoğunun iş değeri katması oldukça mümkündür. Bırakın ürün sahibi karar versin.

7 yılı aşkın bir süredir Scrum Master'ım ve Scrum'ın birçok farklı takım ve şirkete girmesine yardımcı oldum. Mütevazi görüşüme ve gözlemlerime göre, Scrum kuruluşunuza ilk kez tanıtılıyorsa, kitabı takip edin. Sapma. Scrum, uygulamalara ve süreçlere bağlı kalabilmek için disiplini gerektirir. Belirli koşullara uymak için istisnalar yapmak çok kolaydır ve çok erken yapılırsa beraberinde getirdiği fayda ve değerlerin aşınmasına neden olur. Temelleri yapın, gerçekten iyi yapın. Temel bilgileri yapma ve neden orada olduklarını anlama konusunda uzman olun ve ardından kuruluşunuzda daha iyi uyum sağlamak ve sürekli iyileştirme sağlamak için süreci değiştirin.

Bunun "Çevik" olduğunu söylemek için çok geçerli durumlar var, bu yüzden süreci değiştirmeye istekli olmalıyız, ancak kendi kendini yöneten, kendini organize eden bir ekip süreci anlamak ve yapılabilecek değişiklikleri tartışmak arasında önemli bir fark var. süreç, sadece Agile veya Scrum yolunda yürümeye başlayan bir takımın aksine. Taramayı bilmeden koşmaya çalışmak gibi ...

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.