Scrum MIT'leri

05 Ocak 2017 4403 0 AGILE GELİŞTİRME Hakan Aksungar

  • Product Owner’ın, ürün ilişkili detayları bilmemesi, nihai karar yetkisini üstlenmemiş olması, Scrum geliştirme takımının sorularına yeterince zaman ayırmaması, 
  • Scrum Takım üyelerinin belirlenmesinde ve atanmasında yaşanan sorunlar.
  • Geliştirme ile Operasyon süreçlerinin aynı çalışanlar-takım üyeleri tarafından yapılıyor olması; Scrum Takım üyeleri şirket içinde çıkan pürüzleri çözmek için ara ara başka görevleri üstlenmeleri,
  • Kaynak planlamanın yeterince iyi yapılamadığı durumlarda; eş zamanlı yürütülen projeler arasında kaynakların paylaştırılamaması, 
  • İlerleyen aşamalarda ihtiyaç duyulacak geliştirme, test ve diğer altyapı ihtiyaçlarının   düşünülmemesi.
  • Koçluk hizmeti alınmaması, ön görülemeyen sorunlar için planlama yapılmaması.

  • Ürün Vizyonunun çıkartmamış olması,
  • Ürün vizyonunun net olmadığı durumlarda çözüm mimarisinin hazırlanmasında yaşanan zorluklar.  Geliştirme hayat döngüsü süresince, çözüm mimarisinin değişebileceğinin göz ardı edilmesi. Ürün geliştirilirken, ilerlemelere göre sürekli gelişime açık bir mimarinin oluşturulmasına yönelik pürüzler.
  • Çözüm mimarisi hazırlama sürecinde, mimari ekipler tarafından Geliştirme Takımının yeterince desteklenmemesi. Rol ve sorumlulukların tanımlanmamış olması.  
  • Ürün vizyonunun net olmadığı durumlarda sürüm planının yapılamaması.
  • Ürünün tüm özelliklerinin aynı anda release-üretim ortamına alınmak istenmesi nedeniyle sürüm planına ihtiyaç duyulmaması. (Big Bang vs. Iterative)
  • Scrum Takımının, ürün vizyonundan ve yol haritasından büyük resimden uzaklaşması.  
  • Product Owner tarafından öncelik verilmiş, artarak ve sürekli geliştirmeye verecek bir backlog oluşturulmaması.  Geliştirme takımının büyük resmi görmemesi.
  • Takım, tahmin yaparken, göreceli büyüklük belirleme yerine, saat bazında efora odaklanması, 
  • Açık ve Net olmayan ürün özellikleri için kullanması gereken analiz yetkinliklerine sahip olmaması, 
  • Scrum Master ve Product Owner müzakere etmeden, yeterli olgunluğa ulaşmadan varsayımlarla yola devam etmeleri (Scrum varsayımlara yer vermez, her şey net ve açık olarak bilinmeli)
  • Product Owner’ ın sprint çalışmalarına dahil olmaması. Scrum Master’in yetersiz kalması.

  • Sprint Planlama Toplantı süresine uyulmaması, sprint sürelerinin aşılması. 
  • Sprint içinde %5-%10 zamanın takım tarafından ayrılmayıp Product Backlog Grooming (diğer bir değişle Product Backlog Refinement) Toplantısının düzenli olarak yapılmaması nedeniyle Sprint Planlama toplantısında öncelik belirleme ve Product Backlog maddelerinin analiz edilerek küçük parçalara ayırmak zorunda kalınması ve toplantı zamanın aşılması. Product Backlog analizinin önceden yapılmadığı için, büyüklüğü belirlenmemiş Product Backlog maddeleri ve aşağıdaki diğer sorunlar
    • Definition of Ready standartlarına uygun olmayan Backlog ile sprint planlama toplantısına başlanması.  
    • Product Backlog maddelerinin listelenmemesi ve öncelik verilmemesi, dolayısıyla en öncelikli konuların bir sonraki sprintte gerçekleştirilmesi için backloga dahil edilmesinin atlanması.
    • Product Owner tarafından iş değeri baz alınarak öncelikleri belirlenmemiş olması, Scrum Master tarafından iş değerinin sorgulanmaması.
    • Product Backlog Planlama Toplantılarının süresinin kısa tutulması. (Acceptance) Kabul kriterlerinin analiz edilmeden, mutabakat sağlanmadan Sprint Backlog’ a alınması.
    • Geliştirme Takımının Sprint kapasitesinin-gücünün net olarak hesaplanmaması.
    • Büyüklük belirlemedeki eksik öngörüler nedeniyle ekibin fazla iş alma eğilimi.
    • Sprint Backlog maddeleri için genel görevler yazılması, yeterince analize zaman ayrılmaması,   
    • Sprint hedefinin tanımlanamaması.  

 

  • DoD-(Definition of Done) tanımının eksik yapılması nedeniyle, test, dokümantasyon gibi görev lerin atlanması.
  • Sprintte tamamlanmamış maddelerin bir sonraki sprinte nasıl taşınacağına dair belirsizlikler.
  • İlerleme konusunda çevik takımın ön hazırlık yapmaması.
  • Sprint e alınan işlerin release edilebilecek şekilde tamamlanmasında yaşanan sıkıntılar.
  • Continous Integration, Continous Delivery, TDD, DevOps gibi mükemmellik yolunda motivasyonun düşmesi,
  • COS ve kabul kriterleri doğrultusunda bir test planının olmaması ve kodun sürekli şekilde sınanmaması. Testlerin, sprint sonuna hatta sprint sonrasına bırakılması. UAT (User Acceptance Test)’inin sprint içinde yapılmaması.
  • Yapılacak Geliştirmelerin erken geri bildirim alınacak şekilde planlanmasında yaşanan sıkıntılar. Prototyping yapmaktan kaçınılması, Prototyping planının, çözüm mimarisi çalışmaları sırasında dikkate alınmaması, 
  • Product Owner’ ın sprint çalışmalarına dahil olmaması. Scrum Master’ in bu konuda etkisiz ve kalması.
  • Sprint değerlendirme ve planlama toplantılarının birleştirilmesi nedeniyle, değerlendirme toplantısının gerekleri yerine getirilmeden planlamaya geçme eğilimi.

  • Daily scrum toplantısının Scrum Task Board olmadan yapılması.
  • Daily Scrum Toplantısında Sprint Burndown Chart’ ın düzenli olarak güncellenmemesi.
  • Daily Scrum’ın yapılamaması durumunda
    • Takım olamamaktan dolayı, sprint te yaşanan olumsuzluklar.  Görev paylaşımı ve yardımlaşma sorunları.
    • Takımın Sprint haricindeki işlerden ve müdahalelerden soyutlanamaması.
    • Sprint çalışmalarının yeterince görselleştirilmemesi.
    • Impediment’ ler (engeller) müzakere edilmediği için düzeltici veya önleyici aksiyon fırsatlarının kaçırılması ve çevikliğin azalması

Retrospektif toplantısı için tüm Takım üyelerinin katılımcı olmasını sağlayacak teknik yöntemleri bilmemeleri, üyeler birbirlerinin davranışlarını açıkça konuşacak olgunluğu sahip olmayabilirler ve toplantının zaman kaybı olduğunu düşünebilirler ve Retrospektif toplantısını yapmaktan kaçınabilirler.

  • Sprint sürecinde, Takım üyeleri gözlemledikleri hatalı yaklaşımları müzakere etmedikleri için düzeltme fırsatını kaçırır, mükemmelleşme yolculuğunda daha iyi sonuç alacak çözümler bulmak yerine sonraki Sprint’ te aynı hataları tekrar ederler. 
  • Retrospektif Toplantısı, kurumsal öğrenme ve kurumsal gelişim fırsatı yaratır.  Üyeler, iyi sonuç aldıkları yaklaşım ve davranışları değerlendirip adapte ederler.  İstenmeyen sonuçların alındığı durumlarda, daha iyi sonuçlar almak için neler yapmalarını gerektiğini değerlendirip birlikte karar verirler. Kendi kendini idare eden takımlara dönüşerek, Kurumsal Öğrenmeyi ve Gelişimi birlikte hayata geçirirler. Verdikleri kararlar, takım üyelerini bağlar. Takım dışından kimseden emir almazlar. İnisiyatifi kendileri alarak motivasyonlarını yüksek tutarlar.       

Üst Yönetimin Vizyonu ve Desteği, geliştirme takımları ve deneyimli çevik danışmanlar ile bir araya geldiğinde bu engelleri aşmak çok kolaylaşacaktır.  Scrum’ dan beklenen yararları sağlamak, Scrum’ı ve Çevik Prensipleri doğru uygulamakla sağlanabilir.

İLK YORUMU SİZ YAPIN!

YORUM YAP

YORUM YAPABİLMEK İÇİN ÜYE GİRİŞİ YAPMANIZ GEREKMEKTEDİR.

REFERANSLARIMIZDAN BAZILARI

Akçansa
Türk Telekom
Türk Hava Yolları
Maliye Bakanlığı

BLOGUMUZDAN YAZILAR

Yukarı Çık
BİZ SİZİ ARAYALIM