Başarısız sprintler ve son tarihlerle başa çıkmak


80

Birçok Scrum kitabı ve makalesi başarısız bir sprintin (takım Sprint İş Listesi'ndeki bazı özellikleri tamamlayamadığında) kötü bir şey olmadığını, zaman zaman bunun gerçekleştiğini ve takımın hatalarından ders çıkarması gerçekten yararlı olabileceğini söylüyor. ve aşağıdaki sprintlerde bir şeyi geliştirir. Ve takım, taahhüt ettiği işi tamamlamadığı için cezalandırılmamalıdır.

Bu, geliştiricinin bakış açısından harika görünüyor, ancak ciddi müşteriler için (" Money-Bags Corporation ") bir şeyler geliştiren bir yazılım şirketimiz " Scrum-Addicts LLC " olduğunu varsayalım :

  1. Scrum-Addicts yöneticileri Money-Bags için bir yazılım hazırlamayı öneriyor
  2. Bir özellikler listesi üzerinde anlaşıyorlar ve Money-Bags bir teslimat tarihi belirtmek istiyor
  3. Scrum-Addicts yöneticileri, scrum takımlarına danışıyor ve takım, tüm özellikleri tamamlamak için 3 hafta sürecek sprint süreceğini söylüyor.
  4. Scrum-Addicts yöneticisi güvende olmak için 1 hafta ekler, yazılımı 1 ay içerisinde göndermeyi taahhüt eder ve Money-Bags ile sözleşme imzalar
  5. 4 sprintin ardından (nakliye için son tarih) Scrum ekibi özelliklerin sadece% 80'ini sağlayabilir (yeni sistemdeki deneyimsizlik, üretim ortamındaki önceki özelliklerdeki kritik hataları çözme ihtiyacı ...
  6. Scrum'ın önerdiği gibi, bu noktada, ürün potansiyel olarak sevk edilebilir, ancak Money-Bags, sözleşmede belirtildiği gibi özelliklerin% 100'üne ihtiyaç duyuyor. Yani sözleşmeyi çiğniyorlar ve hiçbir şey ödemiyorlar.
  7. Scrum-Addicts, iflasın eşiğinde, çünkü Money-Bags'ten para alamadılar ve yatırımcılar sonuçlardan hayal kırıklığına uğradılar ve şirkete daha fazla yardımcı olmak istemiyorlardı.

Açıkçası, hiçbir yazılım şirketi Scrum-Addicts'in yerinde olmak istemiyor. Çevik ve Scrum hakkında anlamadığım şey ise, ekiplerin yukarıda açıklanan durumdan kaçınmak için planlama ve son tarihlerle başa çıkmaları gerektiğini nasıl önerdikleridir. Özetlemek gerekirse 2 sorum var:

Kimi suçluyor?

  1. Yöneticiler, çünkü doğru planlama yapmak onların işidir.
  2. Takım, çünkü ellerinden daha fazla iş yapmaya karar verdiler.
  3. Başkası

Ne Yapmalı?

  1. Yöneticiler, son tarihi asıl takımın tahmininden 2x (veya 3x) kez daha geçmelidir.
  2. Ekip üyelerinin, ne olursa olsun (taahhüt edilen sprintler için cezalar vererek), taahhüt ettikleri tüm işleri yapmaya teşvik edilmesi gerekir.
  3. Ekip Scrum'u bırakmalı çünkü şirketin son tarih politikasına uymuyor
  4. Hepimiz yazılım geliştirmeyi bırakmalı ve bir manastıra katılmalıyız.
  5. ???

31
"Yapılacak" bölümünün 3'ünü, Scrum'u kullanmamanın, özelliklerin yalnızca% 80'inin bir ay içinde hazır olmasıyla ilgili herhangi bir şeyi değiştireceğini varsayarsınız. Bu çok saçma.
Doktor Brown

7
@DocBrown, saçma olduğu konusunda aynı fikirdeyim. Retrospektif ve gösteri toplantıları gibi bazı Scrum faaliyetlerini bırakmak, gelişmeyi hızlandırabilir. Ve sağlam bir kontrat olması durumunda, bu nihai amacın gerçekleştirilmesine yardımcı olabilir: son teslim tarihinin sonunda sabit miktarda özellik sunun.
Andre Borges

26
@AndreBorges Retrospektifleri ve gösterileri bırakma konusundaki öneriniz, bir arabadan frenleri çıkarmayı önermekle aynıdır. Elbette, frenler sadece sizi yavaşlatır. Ama bu gerçekten hızlı gitmenizi sağlayan şeydir.
Mutlu,

13
Aynı problem herhangi bir sistemde kalmaya devam eder - bu tür scrum'u hemen hemen eşdeğer bir şelale ile değiştirebileceğinizi unutmayın ve şirket yine de büstür
jk.

6
Belki bu Scrum-Addicts yöneticileri, bu sinir bozucu "retrospektif" toplantılar sırasında daha fazla dikkat etmiş olsalardı, projenin uçurumdan aşağıya doğru ilerlemesini izlemek yerine, 1. veya 2. haftada frene basma ve gaz pedalına çarpma şansına sahip olacaklardı. .
Dorus,

Yanıtlar:


134

Örneğinizde birkaç temel yönetim sorunu görüyorum:

  • Eğer bir Scrum-Addicts yöneticisi "son başvuru tarihi" bir sözleşme imzalarsa, ancak "yeni bir sistemin dahil olduğu" bir durumda sadece% 33'lük bir güvenlik payı eklerse, bu oldukça umursamaz.

  • bir ay sonra özelliklerin en az% x'inin sunulması durumu, müşterilerin en azından kısmen son ödeme tarihinin özelliklerinin sadece% 80'ini aldığında para ödediği bir sözleşmeyi müzakere etmek için kullanılabilir. Ya hep ya hiç ya da hiçbir sözleşme, ne yazılım satıcısının ne de müşterinin faydalanabileceği bir şey değildir - bu, satıcı için sadece 0 para değil, aynı zamanda müşteri için de 0 özellik anlamına gelir. Ve "Şelale" gibi bir ya hep ya hiç geliştirme metodolojisi yalnızca bu tür sözleşmeleri yazmanıza izin verecektir, çevik bir yaklaşım ek olanaklar sunar.

  • İlk bir veya iki sprintin sonuçlarına bakmak, yöneticinin takımın son teslim tarihini karşılayamayacağını açıkça belirtmelidir. Bu yüzden daha erken eylemlerde bulunmalı, kalan görev ve özelliklere yeniden öncelik vermeli ya da müşteriyle daha önce yeniden pazarlık etmeye çalışmalıydı. Örneğin, yönetici kalan özelliklerden bazılarının kapsamını küçültmeye çalışmış olabilir, böylece takım sözleşmede belirtilen tüm özellikleri sunmuş olabilir, ancak her biri azaltılmış kapsamda.

Eğer bir görev düşündüğünüzden daha uzun sürerse, hiçbir geliştirme metodolojisi sizi bundan kurtaramaz. Fakat Scrum gibi çevik bir yaklaşım, yönetime bu durumda olanları kontrol etmek için daha fazla fırsat verir. Eğer bu fırsatları kullanmazlarsa, takımın değil, "Scrum" ın değil, müşterinin suçu olmadığı açıktır, çünkü "çevikliği kabul etmez".


47
"Ya hep ya hiç ya hiç bir sözleşme, yazılım satıcısının ya da müşterinin faydalanacağı bir şey değildir" için +1 . Çevik sözleşmeyle ilgili en önemli şey budur.
guillaume31

5
Ve kesinlikle% 80 projenin bazı türlü iyi değil Bu durumda (sonuçta bu kadar mümkün görülmekle birlikte, bu çevik çok bu projeler için hazırlık yapmak üzere sınırlıyor). Bu nedenle, örneğin başlattığınızda uydunuz için özelliklerin% 80'ine sahip olmanın bir faydası yoktur, bu yüzden bu projelerdeki beklenmedik durumlarla uğraşmazsınız. Eğer teslim edemezseniz, müşterinizin misyonu başarısız olur (veya ertelenir), sözleşmede bunu değiştirmek için yapabileceğiniz hiçbir şey yoktur.
Steve Jessop

6
@SteveJessop: Bir uydu için yazılım gibi karmaşık bir şey inşa ederken bile, farklı özellikler için farklı öncelikler olduğundan ve kapsamın belirli bir dereceye kadar değişebileceği birçok özellik olacağından eminim. Elbette böyle bir durum için son tarih belirlenebilir, çünkü roketi gelecek yıl aralık ayına kadar uzaya götüremediğinizde, ikinci bir şansınız olmayabilir.
Doktor Brown

6
Ama bu özel örnek için ... tabi ki kimse kamera sabitleyicisini bitirmeyi başaramazsa yeni ufuklar göndermezdi. Fakat bu ölçekte projeler için bile, tahmin edeceğim şey, hayal ettikleri her özellik ile uzaya girmeyeceğinden bahsediyorum.
Zaibis

6
belki dönüm noktası veya işlevsellik başına ödeme de bir seçenek olabilir.
Bram,

68

" Çevik Yazılım Geliştirme Manifestosu " nun değer açıklamalarından biri:

Sözleşme müzakere konusunda müşteri işbirliği

Aslında Scrum-Bağımlıları LLC yerine bir müşteri ile işbirliği kurma sözleşme müzakere beni kendi çeviklik soru yapar.

Bir şey açık: Çeviklik HERKES tarafından kabul edilmeli. Çeviklik sadece geliştiriciler için değildir. Yöneticilerin ve müşterilerin de Çevik Manifesto'nun değerlerini kabul etmesi gerekir. Müşteriler çevikliği kabul etmiyorsa ve hala katı sözleşmelere ve asgari işbirliğine ihtiyaç duyuyorsa, ya çevik kullanmayın ya da daha iyi müşteriler bulamayın.

Müşterilerin suçu, son tarih odaklı gelişmeleri ile sözleşme balonlarına kilitlenmeleridir.


9
@RubberDuck Henüz özelliklerin önceden belirlenmesine, son tarihin belirlenmesine izin veren ve çok pahalı olmayan bir yazılım proje yönetimi metodolojisi olmamıştır. Kapsam, Zaman, Para; İkisini seç.
Euphoric

8
@RubberDuck: Proje zaten çevik değil çünkü gereklilikler taştan yapılmıştır. Ve tahmin sadece üç haftadır. Şelalenin büyüsüz kötü bir tarafı yoktur, onu her zaman geç yapar, belli belirsiz gereksinimler ve değişim ile baş edemez. Evet, bu durumda "şelale" kullanırdım, ya da daha doğrusu "hadi ne yapmamız gerektiğine karar verelim".
RemcoGerlich

3
@RemcoGerlich ironik bir şekilde, "ne yapılması gerektiğine ve ne yapması gerektiğine karar verelim" - son derece çeviktir :-)
gbjbaanb

2
@RemcoGerlich ah, bence benim açımdan yanlış anladınız: bu çevikte aslında dev yöntemlerle ilgili değil, ne demek istersen onu kullanarak işe devam etme yeteneği. Sonuçta ilerleme hakkında prosedürler değil. (örneğin, sadece
Scrum'u

2
Burada Doc Brown ile aynı fikirdeyim. Kesinlikle "ne için" demeden kesinlikle bir "zaman limiti" olabilir. Örneğin, "Son tarihimiz <bazı tarih>. Sevk Nelerin kapsamı gelmez değil taş tarihi oluşturulur anı ayarlamak gerekir. Çevik gelişim, tamamen kendileri için son tarihler olan zaman aralıklı artışlar içindeki kapsamı yönetmek ve ilerlemeyi iletmekle ilgilidir.
Eric King,

15

Kimi suçlayacaksın?

Yöneticiler, yasal borçlar, muhasebeciler - seçiminizi yapın ...

Örneğin biraz kesin olduğunu biliyorum ama şirketin% 100 memnun olmasaydı bir kuruş ödemeden uzaklaşabiliyor olması, şelalenin ve çevik düşüncenin karışması gerektiği gibi acil alarm zilleri çalmalıydı.

Müşteriler pastalarını almak ve onu yemek isterler - Z'ye kadar X $ ürününü aldıkları sürece şelale, mini şelale, çevik, la-la-land'ı kabul ettikleri için mutludurlar.

Çevik geliştirme kesinlikle geliştirme ekibinin ve müşterinin aynı yöntemde bir metodoloji bakış açısına sahip olmasını gerektirir. Kültürdeki düşünce farklılıkları sadece yıkamada ortaya çıkacak olan arzulu düşüncedir.


12

Bilişim projeleri bilinmeyenlerle ilgileniyor ; Bu bilinmeyenlerin bir kısmı bilinmeyenleri bile bilmiyor . Bu ne anlama geliyor?

Örneğin, model demiryolu için bir oyuncak köprü alın. Bildiğiniz tüm parametreler var:

  • Vadi ne kadar büyük biliyorsun

  • Dağların malzemesini, yüksekliğini, kararlılığını vb. Biliyorsunuz.

  • Ne kadar malzemeye ihtiyacın olduğunu biliyorsun

  • Daha önceki "projelerden" benzer şeyleri inşa etmenin ne kadar sürdüğünü biliyorsun.

Boş zaman ve para yatırımı hesaplamanızı etkileyen birçok değişken vardır. Ancak gelecek hafta sonu bitip bitmediğini düşünmeden söyleyebilirsiniz.

Örneği bir adım daha ileri götürün:

  • Diyelim ki kendi model demiryolunuz için köprü inşa etmeyin, bunun yerine tam bir yabancı için inşa edin: işiniz iki dağ arasında bir demiryolu köprüsü inşa etmektir.

  • Model manzarasının öncesinde hiçbir bilgiye sahip olmadığınızı varsayalım.

  • Manzara hakkında bilgi, yani, çok büyük görünmeyen iki dağ vardır

  • Dağın kıvamı kaya ve jöle arasındadır.

  • Toplam maliyet maksimum 10 $

  • İşyeri tamamen karanlık ve ışık ihtimali yok: 8 maçta sadece bir kutunuz var

  • Son teslim tarihi 3 saat

Bu bir BT projesinin analojisi olacaktır. Köprü kurma konusunda deneyime sahipsiniz ve bilinen arazide yürüyüş yapmak kolaydır. Zor yapan şey karanlık . Çok zor tahmin edebileceğiniz birçok şey var: Dağların ölçüleri sadece karanlıkta bir süre düştükten sonra bilinir. Dağların tutarlılığı da öyle. Bundan, sizi ne kadar süreceği ve ne kadar tutacağı konusunda tahminlerde bulunabilirsiniz . Burada bilinmeyenler , projenin başlangıcında somut arazi vb gibi bilmediğiniz şeylerdir. Bu şeyler biraz kaos taşıyan bilinmeyen bilinmeyenlerdir .

Her bilişim şirketi bunu bilmeli. Proje riski ile uğraşmak zorundalar.

1) (Finansal) riski en aza indirmenin birkaç yolu vardır: anlaşma, müşterinin her çalışma artışı için ödediği tutarı da içerebilir. Bu nedenle, 1'lik artış yapıldıktan sonra kısmi bir oran ödenmek zorundadır. Scrum Addicts LLC sunduğu sürece , asgari finansal risk var. Ne kadar ince taneli sprint hedefleri planlanırsa, her sprint toplam riski o kadar düşük olur. Bu, eğer Money-Bags Corporation sözleşmenin% 80'ini aldıysa, sözleşme değerinin en az% 80'ini ödemesi gerektiği anlamına gelir . Başarısız bir sprint sonrasında ödeme yapmayı reddederlerse, risk% 100 ödemeyi reddetmek kadar yüksek değildir.

2) Scrum-Addicts LLC geliştiricileriyle ilgili bir sorun var

Scrum-Addicts yöneticileri, scrum ekibine danışıyor ve ekip, Scrum-Addicts yöneticisinin tüm özelliklerini tamamlaması 3 hafta sürecek sprinti alacağını söylüyor. Para Çantaları ile

Bu, a) geliştiricilerin scrumla karşılaşmadıklarını veya b) yanlış yaptıklarını gösterir. Takımlar tahmin yaparsa ve menajer "emniyet" olarak bir "tampon" eklerse , menajer takımdan daha iyi biliyor gibi görünür , bu kötü bir işarettir . Deneyimli bir ekibiniz varsa, bir "yönetici kurucu" na gerek yoktur, takım zaten bu tahminde bulunmuştu. Fikir şu ki, takım ne kadar çok çalışırsa, takım da güçlü ve zayıf yönlerini o kadar fazla bilir ve gerçekçi tahminler yapmak için bazı ölçütlere sahiptir. Tabii ki - daha önce de belirtildiği gibi - bilinmeyen bilinmeyenler var.tahminleri zorlaştırmaya meyillidir; veya en azından kesin değil. Ancak uzun vadede, tahminler daha iyi ve daha iyi hale gelmelidir.

Kimi suçluyor?

1) Yönetim

Yukarıda belirtildiği gibi: risk yönetiminde açıkça bir arıza var. Şirket iflasın eşiğinde ise, şirket bunu hak ediyor. Böyle bir şirkette çalışıyorsanız: bırakın!

2) Takım

Yönetim tamamen aptal olsa bile, ekip böyle bir projeye karşı konuşmalıydı. İyi bir yönetici riskleri bilmeli; ancak iyi bir geliştirici risklere dikkat çekmelidir. Ve hepsinden önemlisi: Bir şey başarısız olursa, takımın erken bildirmesi gerekir.

Ne Yapmalı?

Şimdi: Para Çantalarını mahkemeye götürün

Gelecek için: Bu tür sözleşmeler yapmayın

Scrum, yönetimin başarısızlığı nedeniyle suçlanmak değildir. Scrum, başarısız olan birçok IT projesinin deneyimine dayanarak geliştirilmiştir. Başarısızlığı önleyemez, ekip ya da yönetimin yetersizliğini tedavi edemez. Temel fikir:

  • iletişim yollarını yapılandırmak (kim ne zaman kiminle konuşur)

  • geliştirici raporlama başarısızlığını erken teşvik etmek

  • Görevlerdeki ve alt görevlerdeki sorunları bölmek

  • zaman ve kapasiteleri yapılandırmak (kim ne zaman üzerinde çalışır)

  • görevleri zaman dilimleri içinde dağıtmak

  • öngörülemeyen biraz daha öngörülebilir yapmak (planlama poker)

veya genel olarak: riski en aza indirmek için.

Scrum, çekiç gibi bir araçtır. İyi bir araç olup olmadığı bilginize onu nasıl kullanacağınıza bağlıdır. Ama bazen bir tornavida daha iyi uyuyor. Sana kalmış.


1
Scrum'un bu projenin neden başarısız olduğunu anlamak için hayati derecede önemli olan bir başka yönü daha var: scrum başarısızlığı benimsiyor . Yeni bir ekibin veya projenin ilk çiftinin başarısız olması bekleniyor. Retrospektiflerin aldatıcı süreci sayesinde takım kendini geliştirecek ve uzun vadede tahminlerinde doğru olacak, ancak aynı proje üzerinde aynı ekipte çalıştıkları sürece. Bu değişikliklerden herhangi birinde, altta yatan değişkenlerin kayması nedeniyle bir kez daha bazı başarısızlıklar beklemelisiniz.
Cronax

9

Öncelikle, "Kim suçlayacak?" sorulacak yanlış soru. Suçu atamak eğlenceli ve hepsidir ve muhtemelen suçlanan kişi (ler) hariç herkesi rahatlatır (“hey, bu benim suçum değil, patron öyle dedi!” Anlamında) ama zamanınızın verimli bir kullanımı değil ve aslında üretken olabilir ve çalışanların moralinde bir düşüşe neden olabilir.

Bakmanın daha iyi bir yolu "Gecikmeye ne sebep oldu?". Teknolojideki deneyim eksikliği miydi? Test / QA'da tespit edilmeyen kritik hatalar? Test eksikliği / KG? Tahminde çok iyimser? Takımın o kadar iyimser olmayan tahminlerini dikkate almıyor musunuz? Biri otobüs çarptı mı? Sebep ne olursa olsun, bir sonraki soru "Bunun bir daha olmayacağından nasıl emin olabiliriz?" Bazı (umarım çok nadir) durumlarda, bunun cevabı "so-so" dan kurtulmak olabilir "olabilir, ancak" kimin sorumlu olduğunu cezalandırmak zorundayım "dan başlarsanız, davaların çoğunluğunu görmeniz mümkün değildir doğru çözüm olmadığı yerde.

Proje içinde zaten battın. Son teslim tarihi geldi ve geçti, en kısa sürede kaybolacağı gibi müşteriyi uyardınız (çünkü bunu yaptınız, doğru mu? Olmazsa, bu sorunun bir parçası) ve şimdi ele alınması gerekiyor, ancak hecelendi sözleşmede (aslında sözleşmede yazıldığından, değil mi?). Genel olarak konuşursak, bu, müşteriyle eksik olanı nasıl teslim edeceğinizle ilgili pazarlığı içermelidir. Bir çok kişi bir sözleşmeyi değiştirilemeyecek bir şey olarak düşünmeyi sever, fakat ya a) sözleşmeyi bırakmak ve satın aldığınız şeyi yapmamak, b) şirketi sözleşmeyi ihlal etmek ve mahkemede çok para harcamaktan dava etmek, c) Ürünlerini mümkün olan en az sıkıntıyla nasıl alabileceklerini görüşmek, çoğu şirket c.

İleriye bakacak olursak, bir müşteriye bir fiyat / son teklif vermeden önce, kaymış bir son tarih veya maliyet aşımına dahil olan riskleri analiz etmelisiniz (böyle bir şey için olası nedenler nelerdir? planlamak zorundasınız) ve bu bilgileri ne vaat edeceğinize karar vermenize yardımcı olacak şekilde kullanın. % 100 veya hiç olmadığı durumlarda, risk daha yüksek olduğu için açıkça daha yüksek fiyatlar ve daha uzun tarihler teklif edersiniz.

Tüm bu cevapta Çevik hakkında konuşmadığımı fark edeceksiniz. Bunun nedeni (müşterinin bir süredir Scrum'a katılımını unutacağım, ama çok, çok önemli olmasına rağmen) bu noktada önemli değil. Çevik, Şelale veya kullandığınız herhangi bir geliştirme sürecinde bu sorunla karşılaşacaksınız. Evet, Agile'nin daha önce gerçek sorun olup olmadığına bakmanıza izin vererek ve müşteriyi sürece dahil etmesini sağlayarak her zaman bilgilendirilebilmelerini sağlayarak riskleri daha iyi yönetmenize yardımcı olması gerekiyor, ancak bu her derde deva değil.


3
-1 Çevik nokta, risklerin çoğunun tahmin edilememesidir. Örneğin, işlerin kayması durumunda 1 hafta arabellek eklediler. İhtiyacınız olan zamanı her zaman üçe katlayabilirsiniz, ancak o zaman bunu yapmayan rekabete karşı kaybedersiniz. Çevik, “Yapıldığında yapılır” zihniyetini benimsemelidir. Açıklandığı gibi sadece sözleşmeler ve son tarihlerle uyumsuz olan.
Euphoric

3
@Euphoric Tamamen aynı fikirdeyim. Evet, Çevik nokta, pek çok riskin tahmin edilemeyeceği ve tamponun bunun için geçerli olduğu, size bunu vereceğim. Ancak bu, tüm risklerin tahmin edilemez olduğu anlamına gelmez, ne de tahmin edebileceğiniz riskleri göz önünde bulundurmadan, bir projeye göz atmanız gerektiği anlamına gelmez.
Iker

2
@Iker Biri diğerini engellemez, ancak geliştirme sürecinde gerçekten çevik olmanın amacı, hem müşteri hem de ekip için “yapıldığında yapılır” anlayışıdır. Elbette, her zaman tahmin edebileceğiniz bazı riskler vardır, ancak olası tüm riskleri hiçbir zaman başarıyla tahmin edemezsiniz ve tam olarak ilerlemeniz üzerinde ne gibi bir etkisi olacağını tahmin edemezsiniz. Geleceği bir şekilde göremezseniz. Eğer "para bitene kadar biz çalışmaya devam edeceğiz, ya taraflardan her biri, ya da tüm müşteriler ihtiyaçları karşılandığı için artık istekli veya yapabiliyor" konusunda hemfikir nerede Çevik iş, belirli sözleşme gerektirir yüzden
Cronax

Tamam, bunu suçlamanın derhal reddedilmesi için kavram olarak reddettim. Suçluluğun başarıdan uzaklaştıran, üretken olmayan bir bileşen olduğu konusunda hemfikirim. Soruyu değiştirelim. Belki "bunu nasıl halledebilirdik" yapabiliriz? “Bunu bizim için nasıl başarılı bir hale getirebiliriz?” “Her partiden hangi değişiklikler olumlu sonuç doğurabilirdi?” "suçu" nu "sorumlu" olarak değiştirmekte uygun olabilirim, ancak bir satıcı ve bir müşteriyle yapılan her proje bir ekip etkileşimi olduğundan, tüm küresel kapsamdaki 'takım' sorumlu değil mi? Kimin suçlayacağı sorusu retorik hale geliyor.
Joshua K,

4

İlk olarak, bu herhangi bir geliştirme metodolojisinde bir sorundur. En azından yinelemeli bir geliştirme sistemiyle, müşteriye son sürenin sonunda gösterecek bir şeyiniz vardır; bu, ürünü tamamlamak için bir uzatma elde etmek için yeterli olabilir (müşteri daha fazla ödeme yapmasa bile!).

Ancak, son tarihin son teslim tarihi olduğu durumlar vardır, bir oyun yazdığınızı ve Noel tatilleri için mutlaka zamanında yayınlanması gerektiğini düşünün. Yanlış anlaşılması birçok şirketi iflas ettirdi!

Belirli bir tarihe kadar belirli sayıda özelliği tamamlamak zorunda olan çevik yöntemler için, scrum kullanmak muhtemelen en iyi yöntem değildir (her zaman scrum'un devi yavaşlattığını ve ne zaman çevikliği değiştirmek için yeterli çevikliğe izin vermediğini buldum) gerekli.

İhtiyacınız olan şey, metodolojiden bağımsız olarak, ilerlemenin görünürlüğünü sağlamak için gereken özelliklerden oluşan bir birikim oluşturmaktır. Sprint bazında ilerleme yeterince iyi değil, nihai hedefe ulaşıp ulaşamayacağınızı bilemezsiniz. Bu yüzden, bir kanban tarzı metodoloji daha iyi olurdu: tüm özellikleri sola yerleştirin ve tamamlanma sürecini göstermek için sistem üzerinde çalışın.

Bu, insanların aklını Scrum'ın idare edemediği bir şekilde yapılması gerekenlere odaklar ve dev ekip dışındaki kişilerin ne kalacağını ve hedefi karşılayabilecek olup olmadığınızı görmelerini sağlar (ve böylece müşterinin beklentilerini erken yönetirsiniz) veya fazla mesai bonuslarını ihtiyaç duymadan önce düzenleyin).

Scrum, sonsuza dek süren, sürekli olarak bir şeyi tanımlayan ve inceleyen bir sistemdir. Bu tür bir gelişim için uygun değildir. Diğerleri bu sıhhati yönetebilir ve yinelemeli gelişme kavramını hala koruyabilir, Kanban da öyle, Crystal diğeri. Fakat anlamak için esas olan, Scrum'u dini olarak takip ediyorsanız çevik olmamanızdır. Herhangi bir gerçek Çevik sistem, bu belirli sorunlarla başa çıkmak için morph yapabilmelidir, bu yüzden ilk başta çevik olarak adlandırıldı, yapılması gerekenleri yapmak hakkında ve sabit bir son tarih bunun bir parçası ise, o zaman çalışma şeklinize faktoring yapın.


6
"Noel için oyun hazır" Scrum için bir posterchild olabilir. İşini bitirdiğin% 80'i gönder, kalanını DLC olarak sat. Bu, son tarihin hem zamanı hem de kapsamı sabitlediği ve kısmi teslimat için% 100 ceza aldığı burada tartışılan varsayımsal durum değildir.
MSalters

2
@ MSalters, oyunun hiç de işe yaramadığını,% 80'inin daha sonra eklenebilecek özelliklerin eksik olamayabileceğini, ancak işlevsellik veya hataların giderilmesini sağlayabileceğini varsaydığınızı kabul ediyor. Bu bir oyun olmak zorunda değil, kesin olarak gönderilmesi gereken herhangi bir yazılım olabilir ve değişmeyen bir son tarih (Apple bile Noel'i erteleyemez!)
gbjbaanb

6
Scrum'ın temel dayanağı bu! Bozuk işlevsellik sayılmaz. Bir Şelale arka planından geliyorsanız, Scrum'ın bu nedenle yeni özellikler eklemeye yönelik hata düzeltmeye öncelik verdiğini göreceksiniz. "% 80 yapıldı", eksik seviyelerin, eksik patronların vs. olduğu anlamına gelir.
MSalters

1
@gbjbaanb Bu nedenle,% 99.9 oranında bir şey yapılabilir, ancak başlangıçta hemen çöktüğü için hala çalışmayabilir.
immibis

@ immibis ama bu doğrudur. Oyunlar gibi şeyler, özellikleri sonuna kadar dışarıda bırakma eğiliminde değildir, oyunun çoğu bölümünün tümünün çalışması için uygulanması gerekir - bazı özellikleri çıkartabilirsiniz (ve bunu yapan oyunları biliyorum) artımlı özellikler. Yani kayıp bir patron kırılmış bir oyun olurdu. Oyunları sadece eğilimlerinin bir örneği olarak (özellikle internet dağıtımından önce) zorlu tarihlere örnek olarak seçtim.
gbjbaanb

4

Kalkınma paradigması sözleşme paradigması ile senkronize değildir. İdeal olarak, sözleşmelerin yazılma şekli değişecekti, ancak bunun gerçekleşmesi pek mümkün değil. Ancak, utangaç bıraksanız bile, sürprize ve son başvuru tarihlerine cevap vermediniz (ancak daha sonra olacaksınız çünkü tüm bu tasarımları öne yaptınız ve her şey yanlıştı !!).

Sözleşmelerin nasıl yazıldığına dair bir değişiklik olsun veya olmasın, çalıştığınız şeyi gönderin . Ardından, yapmadığınız özellikleri bitirmek için bir geliştirme süresi döngüsü yiyerek sözleşmeyi yerine getirin.

Söz verdiğin gün, söz verdiğin her şeyi teslim etmemen iyi oldu mu? Hayır, ancak zamanında çalışacak bir şey sunabiliyorsanız müşteriniz çok daha mutlu olacak, daha sonra geç kalıyorsanız ve bunları verecek hiçbir şeyiniz yoksa, geri kalanını hızlı bir şekilde teslim edin.


3
Evet, bazen takım en azından bir kısmı çalışma özelliği sunuyorsa müşteri daha mutlu olur, ancak bu her zaman böyle olmaz. (1) özelliklerin% 100'ü uygulanmadıkça ürünün son kullanıcılar için işe yaramaz olduğu durumlardan söz ediyorum (örneğin, yalnızca her şey bittiğinde yapılması gereken pahalı sertifikasyon gerektirir) veya (2) müşteri “Hepsi ya da hiç” yaklaşımı olan eski bir okul şirketi: ürün% 100 hazır değilse, başarısız olduğunu düşünüyoruz, sözleşmeyi çiğnedik ve herkesin sorumluluğunu üstlenin.
Andre Borges

2
Müşteri, çalışan yazılım yolunda ilerlemeyi görmekten daima daha mutlu olacaktır. Pahalı sertifikasyon, ürün memnuniyetine kadar bekleyebilir. Müşteriye bırakması, halka duyurmaları gerektiği anlamına gelmez. 2. durumda, yasal / satış ekiplerinizin daha iyi sözleşmeler yazmasını sağlamaktan başka seçenek yoktur. Dürüst olmak gerekirse, sorunlarınız şelale ile daha da kötü olmasa da aynı olurdu.
RubberDuck

2
@AndreBorges Müşterilerin özelliklerin% 80'ini görmekten daha mutlu olacağından emin olabilirsiniz? En azından bu şekilde, müşteri ürünün çoğunlukla yapıldığını bilir.
immibis

@ immibis, eğer söylerseniz, işinizde 'tuhaf' müşterilerden kaçınmanız için yeterince mutlu olduğunuz anlamına gelir. Makul olmayan sözleşme şartlarını uygulayan, hükümetin hükümeti ile ilgili devasa bazı şirketler var, ancak çok makul olmayan sözleşme koşullarını uygulayan hükümetler var, ancak bütün kaynaklarınızı kendi görevlerine yatırırsanız ve başarılı olmayı başarırsanız, küçük şirketinizi yükseklere götürebilecek ciddi para ödüyorlar. Ancak, başarısız olursanız, kendinizi yeni bir iş ararken bulabilirsiniz. Bazı insanların almak isteme riski.
Andre Borges

2
Kesinlikle! İç bürokrasisi ve deneyimli yönetim kadrosunun eksikliği nedeniyle, bazen büyük bir şirketin başarısız bir son tarihi "başarısız bir deneme" olarak kabul etmesi ve projeyi tamamen bırakması, kapsamı iletişim kurma ve yeniden müzakere etmeye çalışmak için daha fazla çaba göstermekten daha kolaydır. Üzgün, ama gerçek :(
Andre Borges

1

Birçok Scrum kitabı ve makalesi başarısız bir sprintin (takım Sprint İş Listesi'ndeki bazı özellikleri tamamlayamadığında) kötü bir şey olmadığını, zaman zaman bunun gerçekleştiğini ve takımın hatalarından ders çıkarması gerçekten yararlı olabileceğini söylüyor. ve aşağıdaki sprintlerde bir şeyi geliştirir. Ve takım, taahhüt ettiği işi tamamlamadığı için cezalandırılmamalıdır.

Bu tür bir davranışı "cezalandırma" şekliniz, bitirmeyenlerin bir sonraki adımda üstlenebilecekleri iş miktarını sınırlamaktır. Güzel şeyler üzerinde çalışma şansı kayboluyor. İyi iş yapmanın ödülü daha fazla iştir.

Bu, geliştiricinin bakış açısından harika görünüyor, ancak ciddi müşteriler için ("Money-Bags Corporation") bir şeyler geliştiren bir yazılım şirketimiz "Scrum-Addicts LLC" olduğunu varsayalım:

Scrum-Addicts yöneticileri Money-Bags için bir yazılım hazırlamayı öneriyorlar. Özellik listesi üzerinde hemfikirler ve Money-Bags nakliye tarihi vermeyi istiyor Scrum-Addicts yöneticileri kendi scrum ekibine danışıyor ve ekip 3 hafta süreceğini söylüyor Scrum-Addicts yöneticisi tüm özellikleri tamamlamak için uzun süren sprints, güvenli olması için 1 hafta ekler, yazılımı 1 ay içinde göndermeyi vaat eder ve 4 sprintten sonra (gönderim son tarihi) Scrum ekibi sadece% 80 teslim edebilir. özelliklerin (yeni sistemdeki deneyimsizlik nedeniyle, üretim ortamındaki önceki özelliklerde kritik hataların giderilmesi, vb.) Scrum’un önerdiği gibi, bu noktada, ürünün potansiyel olarak nakliyesi mümkün, ancak Money-Bags’in% 100’e ihtiyacı var Sözleşmede belirtildiği gibi özelliklerin. Yani sözleşmeyi çiğniyorlar ve hiçbir şey ödemiyorlar.

Scrum-Addicts, iflasın eşiğinde, çünkü Money-Bags'ten para alamadılar ve yatırımcılar sonuçlardan hayal kırıklığına uğradılar ve şirkete daha fazla yardımcı olmak istemiyorlardı.

Pazartesi günü perşembe günü yağmur yağacağı için 100 dolar yatırırsanız ve cumaya kadar yağmur yağmazsa paramı almaya hak kazanırsınız. Kumar oynamak için bir şans yerine, istediğin bir hava tahmini ise, Salı günü size güncellenmiş bir tahmin vermeme izin veren bir sözleşmeye ihtiyacımız var.

Açıkçası, hiçbir yazılım şirketi Scrum-Addicts'in yerinde olmak istemiyor. Çevik ve Scrum hakkında anlamadığım şey ise, ekiplerin yukarıda açıklanan durumdan kaçınmak için planlama ve son tarihlerle başa çıkmaları gerektiğini nasıl önerdikleridir.

NEDEN MB toplarını alıp eve gitmek istiyor. MB, işin başlangıçta bir ay içinde yapılmasını istemedi. SA, bir ayda kritik özelliklerin% 100'ünü vaat etti ve teslim etmedi. SA, son tarihi MB değil. SA bile keyfi bir şekilde son tarihe bir hafta ekledi. Peki bu neden son tarih?

Ara sıra iş yazılımları için rekabet eden şirketler, ayları gösterme ve vaat etme eğiliminde olurlar. Profesyoneller, ayın gerekli olup olmadığını dikkatlice belirler. MoneyBags için en kritik ihtiyaç hangisi? Bir ay içinde özelliklerin veya çalışan bir ürünün% 100'ü? Neyin kritik olduğunu bile biliyorlar mı? Zor bir tarih belirleyen yaklaşan bir etkinlik var mı?

Scrum-Addicts bu sözleşmeyi müzakere etseydim, Money-Bag iş ihtiyaçları hakkında daha fazla bilgi edinmek ve sözleşmeyi Money-Bags'in rahat olduğu kadar esneklik sağlayacak şekilde yapılandırmak isterdim. Onlara çevik sürecin nasıl çalıştığını öğretirdim, böylece bizden ne bekleyeceklerini bilirler.

Bu şekilde, her şeyin bir ay içinde aniden mükemmel bir şekilde çalışmasını beklemek yerine, 1-2 hafta içinde ilk teslim edilebilir ürünü değerlendirmeyi beklerlerdi.

Özetlemek gerekirse 2 sorum var:

Kimi suçluyor? Yöneticiler, çünkü doğru planlamayı yapmak onların işidir
Ekip, çünkü bir
başkasının yapabileceğinden daha fazla iş yapmaya karar verdiler.

Yoldan bir ay geçmeden herkes bu travestiyi durdurabilirdi.

Sahte olarak bir şelale sürecini açıkça temsil eden bir ekibi işe almak için Money-Bags Corp'u suçlamaya kadar gidebilirim. Sözleşmenin kendisi bunun çevik olmadığını açıkça ortaya koyuyor. Bir ayda yapılması planlanan şey çevik yapmıyor.

Çevik olduğu konusunda ısrar ediyorsanız, bir ay süren tek bir sprint ile çevik. Hangi, evet, tavsiye etmem çünkü bu yine şelale ile aynı şey.

Ne Yapmalı?

Çevik? Her sprint bir şey sunmak? Son başvuru tarihinden önce geri bildirim almak? Hafta boyunca sprint? Son teslim tarihinin saklanmak ve dua etmek yerine tehlikede olduğunu düşündüğünüz andan itibaren draconian sözleşmesini yeniden müzakere etmeye ne dersiniz? En azından bir lanetli projede zaman kaybetmeyi bırakabilir ve daha makul bir müşteri bulabilirsiniz.

Yöneticiler, son tarihi asıl takımın tahmininden 2x (veya 3x) kez daha geçmelidir.

Son tarih çarpanları saatinizi 15 dakika erken ayarlamak kadar faydalıdır, bu nedenle asla geç kalmazsınız. Neyin peşinde olduğunu fark etmeden önce kendini ancak çok kandırabilirsin.

Erken tahminler yanlıştır. Ne kadar yanlış olduğunu yakalamaya çalış. 5 hafta verin veya birkaç hafta alın, tamamlanma tarihinin gerçekte ne kadar belirsiz olduğunu açıklamanızı sağlayan basit bir ifadedir. Doğru tahmin etmeye çalışmak yerine, tahmininizin ne kadar vahşi olduğunu tahmin edersiniz. Bazı gerçek işler yapın ve gerçek veriler elde edin. Sonra daha dar bir aralıkta tahminler yapmaya başlayabilirsiniz. Bir ila iki hafta, bunu yapmak için bolca zaman var.

Ekip üyelerinin, ne olursa olsun (taahhüt edilen sprintler için cezalar vererek), taahhüt ettikleri tüm işleri yapmaya teşvik edilmesi gerekir.

Takım üyeleri teşvik edilmelidir. Başarısız, taahhüt veya başka türlü. Cezalar veya hatta ikramiye (havuç ve çubuk) çalışmaları gibi herhangi bir yapay sonuç oluşturmak yerine, programlama gibi yaratıcı işler yapan insanların üç şey sağlanmışsa en iyi yanıt verdiklerini göstermiştir: Özerklik, Ustalık ve Amaç.

Daniel Pink'in bununla ilgili TED konuşması var. Konuşma, çevik değil motivasyonla ilgili ancak bu noktaları çevik olarak nasıl eşleştireceğimi kolayca gördüm:

Özerklik - Kendi hayatımı idare etmek istiyorum - Biriktirmeden iş seçmeme izin ver.
Ustalık - Önemli olan bir şeyde daha iyi olmak istiyorum - Müşteri geri bildirimi.
Amaç - Kendimden daha büyük bir şeyin parçası olmak istiyorum - İşbirlikçi bir ekip.

Ekip, Scrum'u düşürmeli, çünkü şirketin son tarih politikasına uymuyor Scrum, şelaleden daha doğru bir tarihe varabilir. Bir son tarih verildiğinde bununla karşılaşabilirsin Zamana, özelliğe ve yeteneğe bağlı olarak 47 özellikten yalnızca bir tanesiyle buluşabilir, ancak bunu karşılayabilir.

Çevik bir proje öylesine son derece şık bir şekilde tasarlanabilir ki, ekip eve giderken her gece gemiye hazır olur. Gönderinin müşteriden geri bildirim almasını ve test etmesini istediğini düşünmüyorsanız bu aptalca görünüyor. Ne kadar erken olursa, o kadar çabuk ayarlamalar yapabilirsiniz. Bu her olası son tarihi vurur. Sadece her özellik değil. Ama sizi önemli özelliklere yönlendirir.

Hepimiz yazılım geliştirmeyi bırakmalı ve bir manastıra katılmalıyız.

Doğru, beni gerçek bir odadan uzakta bir odaya kilitlemek gibi, LESS kodu yazmamı sağlayacak.

Bu cevabı boyuta indirdim. Merak ediyorsanız düzenleme geçmişini okuyun.


Ben sadece sprint backlog değil demek istediğinizi varsaymak isterim - Ben tam olarak soruda yazdıklarını kastettim: sprint backlog
Andre Borges

programlama gibi yaratıcı işler yapan insanlar üç şey sağlarlarsa en iyi şekilde yanıt verirler: Özerklik, Üstatlık ve Amaç - bu kendi başına spekülasyon için çok büyük bir konu olabilir, ancak gerçek şu ki, ne yazık ki birçok programlama işi daha az yaratıcı ve daha fazla hale geliyor rutin (donuk görevler, sabit teknoloji yığını ve getirme setleri, katı sözleşmeler). Bu nedenle, birçok durumda havuç ve çubuk iyi çalışır.
Andre Borges

@AndreBorges Haklısın, ürün birikimini düşünüyordum. Son zamanlarda, sprint boşluğunu çağıran bir araçla çalıştım. Kelime dağarcığımı mülk sahibi olmaktan korumak için savaşımı kaybederken beni yakaladın.
candied_orange

@AndreBorges programlama asla zarf doldurma olmayacak. Bu kesinlikle bir mum sorunudur. Bunun nedeni, herhangi bir tekrarlayan sorunun, ilk sorunu çözen aynı kodla çözülebilmesidir. Bu yönetime rağmen, yaratıcılığın ortadan kaldırılması gereken bir sorun olduğunu düşündükleri bir zihniyet içine girebilirler. Bu dükkanların birçoğu için çalıştım ve kaçtım. İyi insanları tutmazlar. İyi yazılım üretmiyorlar. Geliştiriciler zanaatkarlardır. Onları montaj hattına sokmaya çalışmak işçilere yalnızca amacınızı incitiyor. Benim işim yumurta çevirmek değil. Yumurtaların çevrildiğinden emin olmak için.
candied_orange

0

Herkes çevik olmalı. Buna karar verdiğiniz her neyse, tüm taraflarca kimin ne yaptığını, nasıl, ne zaman, nerede ve niçin olduğunu görün. Çevik müşteriler, yönetim ve geliştiriciler.

Gelecekte çok fazla nakliye tarihi veremezsiniz. Bir tahmin ver.

Müşterinin beklentilerini yönetmek için birinin ihtiyacı vardı. Birkaç sprintin geride kalması konusunda çok fazla endişelenmemenizin nedeni, tüm projenin geride kalmasını önleyecek şekilde ayarlama yapmanızdır. Bir veya iki sprintin ardından bitirmek istemediğiniz sonuca varmak için "gönderi tarihi" ile karşılaşırsanız, müşteriye o zaman söyleyin.

Şimdi ne yapmak istersin? İhtiyacınız olmayan özelliklerden kurtulun veya tarihi taşıyın. Zamanında teslim edebilseydin, yapardın. Kötü haberi getirmek için tereddüt etmeyin.

Kim bilir, bazı projelerde daha erken yollayabilirsiniz.

Müşteri istemiyorsa çevik olamazsın.


0

Hedef

Aşağıdaki iki "ölçümün" herhangi bir işletme kararının temeli olması gerektiğine inanıyorum:

  • iş karlı mı (müşteri için)
  • mümkün olduğunca verimli çalışıyor muyuz

Bunlar oldukça evrensel. Tabii ki çok daha karmaşık bir hal alıyor, örneğin, kârlı çalışmak doğru şeyi yapan ürün, kullanıcının ürünü kullanabilmesi, doğru şekilde pazarlanması vb. İle ilgili - çok fazla " Scrum-Addicts için LLC "sorumluluk taşımamaktadır.

Konu

Sözleşme yukarıda belirtilen hedeflere odaklanmıyor. "Hepsi ya da hiçbiri" cümlesi var - her şeyi halledin ve ödenin ya da hiçbir şey yapmayın ve ücret alınmayın. Ancak, bu doğrudan yaratılan değerle doğrudan ilişkili değildir. Bunu izleyen bir diğer dezavantaj: şimdi zaman ve para harcamamız gerekiyor ve sözleşmenin takip edildiğini güvence altına alıyoruz. Neden bu parayı harcamak istiyoruz? Bu arada, gereksinimler değiştiğinde bir sözleşmenin yerine getirildiğinden emin olmak ve sipariş edilen yazılım parçasının herhangi bir değer yaratmadığını nasıl tespit ettik? Kanalizasyona giden daha fazla para var! Şimdi, elbette, bu davranışın bir nedeni var:

  • Kültürel olarak biz böyle şeyler için alış veriş yapmak için kullanılır. Bir araç için yaptığımız gibi yazılım alışverişini bekliyoruz: bir konfigürasyon seçin, bir fiyat ve son tarih verin ve bu ikisi karşılanmazsa çok mutsuz olun.
  • Risk ve hesap verebilirliği boşaltmak istiyoruz
  • İstikrar istiyoruz, planlamamıza yardımcı oluyor ve daha iyi hissetmemizi sağlıyor (ve ayrıca önemli bir yönü olan müşterimiz!)

Günün sonunda, hedeflerimizi mümkün olduğunca iyi karşılamamıza izin verecek bir uzlaşma seçmek zorunda kalacağız.

Bu nasıl çalışması gerektiğini

  • ürün yerine servis ve iş sözleşmesi yapmak
    • nispeten kısa sürede feshedilmesi gerekiyor
  • optimum verimliliği sağlamak için birlikte çalışın
  • " Scrum-Addits LLC " ve " Money-Bags Corporation " dan gerekli tüm partileri dahil edin - tüm bilgileri tünelleyen "tek bir temas noktası" burada çalışmayacak

temelde sadece "çevik ol" dedim. Şimdi burada neden:

  • Süreç ve sözleşme, Hedefe mümkün olduğunca çok para harcamak için optimize edilmiştir
  • Yükleniciye işini yapmak için güvenmek zorundasınız ve işin doğru olduğunu doğrulamak için çok fazla para harcamanıza gerek yok.
  • Beklentileriniz / sözleşmeniz yerine getirilmezse yüklenicinize dava açma kabiliyeti genellikle yardımcı olmaz, çünkü bunu yapmak sadece düşürmekten daha pahalıya mal olur. Buradaki ana kaygılardan bazıları pazara sunma süresidir. Büyük olasılıkla mahkemeye gideceğinizden çok daha fazla para / iş kaybedeceksiniz.
    • günün sonunda sadece kendinize ait bazı riskler üstlenmeniz gerekecek.
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.