SCRUM'u tanıtırken neyin yanlış gittiğini gördünüz?

Şirketiniz mevcut süreçleri SCRUM ile değiştirmeye karar verdiğinde karşılaşılan tek hata noktası neydi?

Bir şirket SCRUM'u tanıtmaya çalıştığında bana gerçekten yanlış giden şeylerden bazı örnekler verebilir misiniz? Anekdotlarınızı, kendinizi deneyimlediğiniz bir şeyi, geldiğini gördüğünüz ancak engelleyemediğiniz büyük başarısızlığı duymak istiyorum .

Uygulama ayrıntılarıyla ilgili kararlar ve hikaye boyutları ve hikayelerin ayrıntı düzeyi hakkında eksik dokümantasyon konusunda çok endişe duyuyorum .

En büyük sorun yanlış anlamadır. Sık karşılaşılan hatalar:

• Sadece bir takım Scrum yapıyor ancak şirketin geri kalanı (satış, yönetim, İK dahil) hala eski şekilde düşünüyor. Örnekler:

  Müşteri ve müşterinin katılımı ile sürekli etkileşim çok önemlidir.

  İK, ekip performansının bireylerin performansından daha önemli olduğunu anlamalıdır. KPI buna göre değişmelidir.

  Özellik tanımı sürekli bir süreçtir. Proje tanımı geliştirme sırasında müşteri geri bildirimleri ile gelişecektir. Bu proje son tarihi nedeniyle, gerekli bütçe veya sonuç özellik seti değişebilir (paydaş tarafından onaylandıktan sonra).

  Değişim sürecin bir parçasıdır.

  Tahmin, projenin başında 5 ay içinde tüm özelliklerle (birçoğu başlangıçta bilinmeyen) yapılacağını söyleyemeyeceğiniz sürekli bir süreçtir.

  Takım karar verme yetkisine sahiptir. Takım, bir sonraki sprint sırasında sunulan özelliklerin miktarını taahhüt eder. Bu talep edilemez veya komuta edilemez.

  Sprint, takım için güvenli bir bölgedir. Ekip, tanımlanmış bazı kullanıcı öykülerini taahhüt ettiğinde, taahhüt ekip dışında değiştirilemez.

  Eski organizasyon yapısının bir kısmı Scrum'a taşınırken mantıklı değil. Scrum üç rol tanımlar: Scrum ustası, Ürün sahibi, ekip. Başka roller var, ancak bu üçü genellikle uygulamayı sağlamak için yeterlidir. Yaygın olmayan, Scrum ustası, Takım lideri, ürün sahibi ve bir veya daha fazla Proje yöneticisine sahip olmaktır. Proje yöneticisi ve takım lideri Scrum'da gereksiz roller.

• Scrum master rolü atanan adam Scrum master yapmıyor. Scrum master engelleri çözer. Ekibi rahatsız eden her şey en kısa sürede çözülmesi gereken bir engeldir. En yaygın başarısızlık, bu rolü daha önce Scrum ile deneyimi olmayan geliştiriciye atamaktır. Bu rol kısmen ortak proje yöneticisinin yerini alır, ancak Scrum master'ın ekip üzerinde gücü yoktur ve Scrum master hiçbir özelliğin uygulanmasını talep etmez. Scrum master, takımı gerçekleştirilemeyen gereksinimlerle Ürün sahibine karşı korur.

• Atanan Ürün sahibi rolü Ürün sahibi yapmıyor. Ürün sahibinin ürün için finansal sorumluluğu vardır. Başarı için çok spesifik ve önemli bir rol. Rolün analitik, proje yöneticisi ve ürün yöneticisi ile ortak bir yanı vardır. Ürün sahibi gereksinimleri toplar ve korur (genellikle kullanıcı öyküleri biçiminde). Sorumluluğu ekibe bilgi sağlamak ve kullanıcı hikayelerinin önceliğini tanımlamaktır. Ekiple birlikte yerinde olmalıdır çünkü PO ile ekip arasındaki işbirliği süreklidir.
• İşlem adını Scrum olarak değiştirmek, ancak işlemin çoğunu eskisi gibi bırakmak. En yaygın senaryo şelaleden Scrum'a geçmeniz ve en önemli değişiklik artık analiz ve dokümantasyon yapmamanız ve Scrum olduğunuzu söylemenizdir.
• Gereksinimler / kullanıcı öyküleri tamamlanmış tanımı eksik - çok yaygın. Tamamlanmış (kabul kriterleri) tanımınız yoksa, sprint planlama sırasında kullanıcı hikayesinin karmaşıklığı hakkında herhangi bir varsayımda bulunamazsınız. Sprint sırasında bunlara sahip değilseniz, kullanıcı öyküsünü tamamlandı olarak işaretleyemezsiniz, çünkü doğrulayamazsınız.
• Kalite isteğe bağlı olarak kabul edilir. Scrum'da kalite birinci sınıf vatandaştır. Her kabul kriterinin otomatik uçtan uca test ile kapsanması gerektiğini söyleyebiliriz. Kaliteyi düşürmeye ve test edilmemiş özellikler eklemeye başladıktan sonra, ürün üzerinde kontrolü kaybediyorsunuz çünkü yapılan kabul edilen özellikler regresyon nedeniyle her zaman çalışmayı durdurabilir.
• Sprint sonucu ürüne sevk edilebilir artış (= çalışma ve test edilmiş) olmalıdır.

Düzenle:

Önemli not ekliyorum. Çevik yaklaşımı kullanırken ana nokta, müşteriye mümkün olan en yüksek miktarda iş değeri sunmaktır. Ancak müşteri (Ürün Sahibi tarafından temsil edilir) işletme değerinin ne olduğunu açıklar. Bu nedenle Scrum'ı kullanırken analiz veya belgeleriniz olmadığı genellikle doğru değildir. Müşteri analiz veya dokümantasyon talep edip işletme değeri olarak işaretlerse (örneğin, önümüzdeki birkaç yıl içinde iyileştirilmesi gereken büyük ölçekli veya uzun vadeli proje nedeniyle) bunu da oluşturacaksınız. En temel yaklaşım, kullanıcı öyküleri için kabul kriterlerinde analiz ve dokümantasyon içerir. Bu durumda analiz, ürün sahibiyle standart bir şekilde iletişim halinde belgelenir.

10 yıldan fazla bir süredir xp ve scrum'da fark ettiğim en büyük sorun, henüz oldukça çevik olmayan "takımların" çevik hakkında esnek olmaya "karar vermeleri ve özelleştirmeye başlaması, belirli parçaları düşürmeleri vb. her bir parçanın ne yaptığını ve neden orada olduğunu net bir şekilde anlar.

Takımların ilk başta kitapla bir şeyler yaptıkları zaman scrum konusunda henüz "elde etmedikleri" şeyi değiştirmeyen takımlardan daha başarılı olduklarını gördüm.

İşte o zaman "ilk sprint, tüm gereksinimleri yapacağız. İkinci sprint tüm tasarım, vb, son sprint tüm test". Şelale olarak da bilinir. Ya da "yine de oturalım, bu standup işinde ne var?" Gibi basit şeyler.

Shuhari ile ilgili bir şey ( http://c2.com/cgi/wiki?ShuHaRi ).

En büyük sorun her zaman buy-in. Herhangi bir takım veya kilit kişiler satın almadıysa (proje yönetimi, KG, geliştirme, vb.) Başarısızlık neredeyse kesin olarak sağlanır.

Başka bir ilgili sorun aslında dahil herkes scrum gerçek nedir ve değil ne farkında olmaktır.

Proje yönetiminin bunu değişimle doğrudan geliştiricilere gelmek için bir bilet olarak gördüğü ve yarın tamamlanmasını beklediğimiz ortamları gördüm, çünkü büyük yeni süreci kullanıyoruz. Bu durumda olan ya da Scrum'ı uygulamada başarısız olan ve ağızlarında acı bir tadı olan herkes. Bu insanlar bazen projeyi de raydan çıkarmaya çalışırlar.

Gördüğüm bir diğer sorun da ayağa kalkma toplantıları. Her zaman bir stand toplantısında oturmak isteyen adamı alacaksın .... "Kötü bir sırtım var" ya da her neyse. Her zaman hedefin arkasında yatan hedefin ne olduğu hakkında hiçbir fikri olmayan ve siyaset ya da o hafta sonu ne yaptığını bilmeyen aynı adam gibi görünüyor. Etkili iletişim için anahtar toplantılar buldum. Bu toplantıları kimsenin zehirlemesine izin vermemek önemlidir.

Geliştirdiğimiz kodun tüm analizlerini aynı sprint'te yapmaya çalışırken , aslında kodladığımız kodu.

Biz biraz önce scrum taşındı ve açıkçası çalışan yönetimi her scrum 2 haftalık bir şelale süreci olarak tedavi. Scrum kurallarına öyle bir bağlılık vardı ki bu kendi içinde bir süreç haline geldi!

Bulduğum sorun bu, tüm çevik metodolojiler sizin için etkili bir şekilde çalışma esnekliği ile ilgili olmalıdır. Süreçler tarafından yasaklanan şekilde değil. Örneğin, 2 haftalık scrum'larımız vardı ve bir ekip 2 haftanın iyi iş yapmak için yeterli olmadığını düşündüklerini söyledi (scrum demo ve ilk gereksinimlerin gözden geçirilmesinin neden olduğu kesinti süresiyle değil), bu yüzden 3 hafta. Şok dehşeti! Scrum başına 2 hafta ideal olduğuna karar verdikleri ve şimdi kalite prosedürlerinde belgelendiği için yönetim reddetti.

Scrum, çevik yöntemlerin en az çevikidir, bu yüzden belki de bu kadar popüler olmuştur - eski muhafızlara satmak daha kolaydır. sevmediğiniz şeyleri kaldırmanız gerekiyor, ama bunun olacağını sanmıyorum. Benim tavsiyem daha esnek, daha az kural tabanlı bir kuralla gidip ihtiyacınız olan kuralları eklemektir. Bu yüzden Crystal'ı tercih ederim .

Nihayetinde, sadece yarım kollu çevik manifestoyu hatırlayın .

En büyük sorun da müşterinizin SCRUM sürecini kabul etmesi ve çevik olması gerektiğidir. Müşterilerin çoğu bunu projenin başında duymak ister:

• Maliyeti ne kadar
• Nasıl görünecek
• Ne zaman yapılacak

Kulağa makul geliyor, ama kesinlikle çevikle uyumsuz. Müşterinize şelale yerine neden onun için çevik olduğunu açıklamanız gerekir.

SCRUM'a ilk gitmemde iki büyük sorunumuz vardı:

1) Gerçekten bir ürün sahibimiz yoktu. Patronumuz bu rolü oynamak zorundaydı çünkü ürün sahibi olması gereken hiç kimse bunu kabul etmeyecekti. Bu tür şeylere bir kıvrım koydu çünkü cevapları her zaman bilmiyordu.

2) Dış bileşenleri hesaba katmakta kötüydük. İlk birkaç sprintimiz tam otomatik testlerin başlatılmasını ve çalıştırılmasını içeriyordu ve kullandığımız simülatörleri otomatik olarak tekrar tekrar sorunla karşılaştık. Her nasılsa, bunun olacağını bilecek kadar iyi olamadık.

Projemde karşılaştığım en büyük sorun, bir sonraki sprint için tahmin edildikten sonra gereksinim toplamanın gerçekleşmesi. Kabul kriterlerine göre tahmin ediyoruz. Gereksinim toplama sırasında, ince ayarlı AC'nin çok daha büyük olduğunu görüyoruz, bu yüzden 8 saat boyunca başlangıçta tahmin edilen görev şimdi gerçekten 24 saat! Sprint birikimimi değiştirebilir ve hikayelerimi azaltacak tahminleri gözden geçirebilir miyim? Hayır efendim! Sprint biriktirme listesini değiştiremeyeceğiniz çevik gereksinimler! TL'm böyle diyor. Bu yüzden, zamanı 8 saat olarak tahmin ettiğim orijinal kabul kriterlerine göre kodlamamalıyım! Tanrı! Yok hayır! Bunu yapamazsın! Bu Çevik olmaz, değil mi!