Scrum

Scrum'ı Terk Etmek

2021 yılına doğru Scrum'u kötüleyen yazılar çoğalmaya başladı. Zamanı gelince de Scrum şöyle kötü böyle işe yaramaz diye daha fazla yazı göreceğiz. Abandoning Scrum okunabilir.

Scrum Sabit Fiyat ve Takvim Projeler için Kullanılır mı ?
Kullanılabilir. Kapsam (Scope), Takvim (Schedule) ve Bütçe (Budget) ayarlandıktan sonra kullanılmaması için bir sebep yok.

ABD'de ve Türkiye'de savunma projeleri sabit fiyat/takvim ve şelale modeline göre kurgulanırlar. Tüm projenin olmasa bile geliştirme aşamasının scrum tabanlı iterative user story'leri olarak gerçekleştirilmesi mümkün.

Burada dikkat edilmesi gereken nokta Scrum'ın, Half Arsed Agile şekline dönüşmesi.

Scrum ve XP Arasındaki Farklar

Scrum ve XP çevik süreçler. XP daha çok kodlamaya yönelik faaliyetleri ön plana çıkarıyor. Örneğin XP'de önce test (test first) çok önemli, ama Scrum kodla ile ilgili bir şey söylemiyor. Dolasıyla bazı projelerde XP ve Scrum birlikte kulanılabiliyor. Aslında XP refactoring'i öne çıkardığı için belki iyi bir şey yapıyor. Refactoring bize kodu tekrar yazabilme imkanı sunuyor. Aslında bir yazılımın 5 kere baştan yazıldıktan sonra hazır olduğuna dair bir yazı var. Yazı şöyle

However, software development doesn't obey by the normal laws of nature. For instance, every time you re-engineer your software from scratch, you're destined to implement it 10x better, 10x faster, and 10x more stable - At least up to some "n number of rewrites". Hence, my proposition, is to create the same software 5 times, before you're happy with your end result, and willing to label it as "production ready". In fact, if you haven't created the same software at least 5 times, I'd argue it's probably garbage anyways.

Destekleyici bir deney şöyle

One study once asked random strangers on the street to create ceramics pottery. 50% of the people were told to spend 8 hours creating one single cup and try to create it "perfect", while the rest of the group were told to create as many cups as they could. Afterwards they had professional ceramics teachers evaluate the results, and paradoxically, the best quality was consistently found amongst those who had been told to create many cups.

Scrum ve İletişim

Scrum iletişimi defalarca vurguluyor. Çoğu başarısızlığın altında iletişim problemi de bulunuyor. Bir açıklama şöyle. Burada bireyler ve iletişim vurgulanıyor.

From the four values:

...

Individuals and interactions over processes and tools

 Bir açıklama şöyle. Burada yine iletişim ama yüz yüze iletişim vurgulanıyor. Uzaktan çalışma ortamında bunu direkt yüz yüze değil de video konferans şekilde anlamak lazım.

From the 12 principles:

...

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Scrum Başarısızlıkları
Scrum Başarısızlıkları yazısına taşıdım.

Scrum ve Critical Path
Şelale projelerde "critical path" - yani mutlaka bitmesi gereken birbirine bağımlı en uzun işlevler zinciri - önceden belirlenir. Bu öncelikli işlerin bitmesi için tedbirler alınır. Scrum'da critical path kavramı yok.

Scrumdaki Roller
Roller yazısına taşıdım.

Sprint ve Mimari
İlk sprint'lerde mimariyi oturtmaya çalışmak gerekir. Sadece eldeki story'e odaklanılırsa genel işleyiş, kural ve kararlar gözden kaçabilir. Yukarıda da yazdığım gibi bir yazılım mimarının bulunmaması Scrum'ın zayıflıklarından birisi, ancak ilk sprint'lerde bir mimarı çalışması yapmak ta zaten hemen her yazılım projesinde olan bir şey.

Sprint Planlama Toplantısı
Sprint Planlama Toplantısı yazısına taşıdım.

Günlük Toplantılar
Günlük Toplantılar yazısına taşıdım.

Retrospektif Toplantısı

Retrospektif Toplantısı yazısına taşıdım.

Backlog
Product Owner yazısına taşıdım.

Burndown Chart
Burndown Chart yazısına taşıdım.

Velocity

Hızın sabit tutulması için gerekli şeylerden birisi de kodun sürekli refactoring'e yani yeniden düzenlemeye tabi tutulmasıdır. Scrum refactoring'den açıkça bahsetmez. Bu konuyla daha çok Extreme Programming ilgileniyor. Ancak refactoring technical debt'in yani teknik borcun temizlenmesi için gereklidir. Temizlik ise proje ilerledikçe hızın düşmemesini sağlar.

Velocity Bir Müddet Sora Kendi Kendine Ayarlanır
Açıklaması şöyle.

A team brings 30 story points in to a sprint but only completes 25 story points

The rolling average of velocity for the team is reduced from 30 to 27

The team brings 27 story points in to the next sprint and manages to complete 24 story points

The velocity again falls, down to 25

Sprint Süresi
2,4,6 haftalık sprintler olabilir. Sprint süresi değiştirilebilir ve ekip tarafından belirlenir. Açıklaması şöyle

The Scrum team decides the length of the Sprint (dev team + PO + SM). They do the actual work, so they choose the duration of the time-box they feel more comfortable with in order to produce a product increment.

With that being said, there are of course all sorts of other things happening in the company that may influence what decision the Scrum team makes. You mention some of them in your question. If that happens, the team can always change the sprint duration. You don't need to keep the same length all throughout the project. You start with whatever works for you, then inspect and adapt.

Sprint tarihleri mutlaka görünür bir yerde olmalıdır. Tatilleri de dikkate almalıdır.

Sprint 14: November 18th—December 2nd (10 days)
Sprint 15: December 2nd—December 18th (11 days; december 4th: attending the conference in NYC)

Sprint süresi uzadıkça geribesleme döngüsü de uzar. Sprint içindeki geliştirme saati aşağıdaki gibi hesaplanabilir.

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

1,2,3 haftalık sprintlerde geliştirme için ne kadar saat ayrılabildiği görülüyor. CeremonyOverhead haftada 4 saat alıyor diye düşünülmüş. Örneğin sadece günlük toplantılar haftada 1-2 saat alır.

1 week: ((8 * 5) - 4) *.8 = 28.8 hours or 5.76 hours per day.
2 weeks: ((8 * 10) - 4) *.8 = 60.8 hours or 6.08 hours per day.
3 weeks: ((8 * 15) - 4) *.8 = 92.8 hours or 6.18 hours per day.

Bazı uygulamalarda 4 sprint'ten sonra 1 hafta dinlenme ve hazırlanma amacıyla boşluk bırakılıyor.

Story
Story yazısına taşıdım.

Story Point
Story Point yazısına taşıdım.

Sprint İçinde Herkesi Meşgul Tutma
İdeal bir ortamda herkesin iş yükünün eşit olması beklenir. Böylece işini erken bitiren, ne boşta kalır ne de ben ne yapacağım diye soru sorar. Ancak gerçek hayat böyle değil. Bu yüzden işini erken bitirenlerin ne yapması gerektiğine dair sorular var. Fikirler birbiri ile çelişebiliyor. Ben de hepsini listemenin daha iyi olacağını düşündüm.

• Mesai saati dışında backlog'dan önem sırasına bakmaksızın iş çekip bitiren birisi hakkında fikirler belirtilmiş. Genel eğilim bırak yapsın yönünde.
• İşini erken bitiren birisinin backlog'dan bir iş yapmasına itiraz edenler de var. 
• Boşta kalanlar bir sonraki sprint için araştırma yapabilirler diyenler de var. 

Bakım ve Hata Temizleme
Projeleri hayata geçtikten sonra bakım ve hata temizleme süreci başlar. Scrum sadece geliştirme aşamasında değil, bu aşamada da kullanılabilir. Kullanılan yöntem geliştirme süreciyle aynı. Bu sefer bug backlog oluşturuluyor Product Owner hataları önemine  göre sıralar. Kimin hangi hatayı çözmesi gerektiğine yine ekip kendi içinde karar veriyor.

Eğer geliştirme aşamasında hatalar gelmeye başlarsa, hatalar da story formatına dönüştükten sonra bir sonraki sprint'e dahil edilirler.

"If at a later date QA (or worse yet a customer) finds a bug, the report goes into a bug tracking database and also becomes a story which should be prioritized just like all other work."