Shape up scrum veya scrum olmadan çalışan IT çözüm ekip çalışanları için yeni bir çalışma stilidir. Kısaca özetlemek gerekirse 6 haftalık bölümde bir proje bitirilir. Tabi bu proje öncesinde bir bölüm olur. Bu bölümde projelendirecekleri geliştirmeleri kapsamlı bir şekilde düşünüp bunları genel hatları ile 6 haftalık süreç başlamadan çıkarılır. 6 hafta içinde hiç bir şekilde geliştirici bölünemez. Buna buglar da dahil. 6 hafta sonunda istenilen proje çıkarılmazsa ya bu proje hafife alınmış ya da gerçekten iyi planlayamamışız deyip ikinci plana atılır. Projelerde uzatma verilmez.

Proje başlamadan önce küçük bir grup toplanır ve proje üzerinde tam olarak elle tutulur bir şey olmasa da fikir olarak ortak bir noktada buluştukları bir proje üretilir. Bu bölüme Shaping denmektedir.

Sonraki bölümde ise proje bazı deneyimli kişilere gösterilir ve bu defa kaba bir plan çıkarılır. Planda sayfaların neler olabileceği, içeriklerinde neler olacağı gibi yönlendirmeler bulunmaktadır. Dizayn yapacak kişiyi etkilememe adına sadece sayfaların genel hatlarında konuşulur. Herhangi bir mockup bulunmaz.Buna da pitching denmektedir. Yani atmak başlamak gibi düşünülebilir. Sonra bu hazırlanan dökümanı herkesin görebileceği bir yere post ederler ve 6 haftalık süre başlar.

Son adım ise Building olarak adlandırılmaktadır. Bu adımda genel olarak proje geliştiricilere bırakılır. Dikkat ettiyseniz şimdiye kadar herhangi bir task bulunmamaktadır. Tasklar aslında başı sonu belli ve sanki çizgilerinden çıkılamaz kurallar gibi algılanacağından dolayı bunun yerine süreç içerisinde geliştiricilerin oluşturacağı ve gerekli gördüğü eklentileri yapabileceği bir düzende ilerlenmiştir.

Burada 6 haftanın önemini tekrar vurgulamak isterim. Deadline olmayan durumlarda takım projeye ek özellikler geliştirebilir. Hatta bunda çoğu zaman haklıda olabilir. İşte 6 haftanın önemi buradan gelmekte. Mükemmeli aramak yerine proje en basit şekilde tamamlanmaya çalışılıyor. Ek bir şey mi yapılacak sonraya bırakılıyor. Sonra yine sonraya bırakıp en sonunda da çok gerekliyse yapılabilir. Doğal olarak gerekli olmayan hiç bir şey için zaman harcanmıyor. Hatta bu konuda o kadar ileri gidilmiş ki çalışanların hiç bir şekilde bölünmeyeceğine dair tüm firma garanti vermiş. Çünkü bir kişiyi böldüklerinde arabanın hızlanmasına benzer şekilde tekrar aynı noktaya gelebilmesi için zaman gerekiyor. Böylece riskleri en aza indirilmiştir. Hepimizin de bildiği gibi aslında ‘Bu yapılabilir mi?’ sorusunun cevabı çoğu zaman ‘Evet’’dir. Fakat burada soru şu şekilde evrildiğinde ‘6 haftada yapılabilir mi?’ Bunun cevabı bazen evet olacaktır.

Pitch durumundaki projede aslında çok detaylı bir makale ile başlar. Projenin kapsamı çok net ve okuyan herkes anlayabilmelidir. Konu üzerinde çok fazla tartışma olacaktır. Burada yazılacak iyi bir makale asenkron çalışmayı destekleyici olacaktır. Şimdiye kadar kendi deneyimlerimden de gördüğüm kadarıyla insanlar ne kadar senkron çalışırsa projenin gelişmesi o kadar zorlu ve zaman alıcı olmakta. Bundan dolayı aslında 6 haftalık süreç scrum’da koşulan 4 haftalık sprint’lerden daha iyi olabilir. Ayrıca kitap boyunca daily standup yapıldığından da bahsetmedi. Yani asenkron olabilmek için aslında çok uğraşıldığından bahsedebiliriz. Peki analistler veya projeye yöneticileri projenin ne kadarının bittiğini nasıl anlıyor?

Tepe grafik ile işlerin bir önceki durumunda değişiklik olup olmadığı anlaşılıyor.

Hill

Öncelikle uygulamanın bilinmezlerinin bilinir hale getirilmesi gerekmekte. Normal görev düzeninde aslında bu çoğunlukla görmezden gelinmekte. Görevlerin az olmasının nedeni daha rahat yeni görevler çıkarabilmektir. Projede yapılacaklar bilinir olduğunda artık bu tepe noktası geçilmiş ve işler bitmeye başlamış olacaktır. Buradaki bilinirlilikten kasıt sadece düşünce seviyesinde değildir. Örneğin bu bölümde x apisi şu şekilde kullanılacaktır çıkarımında bulunulabilir. Bunun testi de bilinmeyenler bölümünde yapılır. Apinin kullanılacağı düşünülse bile doğrulamadan tam olarak bilinemez. Tepenin sol tarafı yani bilinmez tarafı işin daha yoğun olacak yapılacağı ve daha korkutucu bölümdür.

Yöneticilerin her zamanki işin % kaç’ı bitti sorusuna, sizin de grafikten görebileceğiniz gibi net bir cevap verilemez. Burada takip edilebilecek olay bir önceki durumda ne kadar kalındığı ve bunun normal olup olmadığıdır. Grafik eğer hareket etmiyorsa bu durumda bir sorun var demektir.

Peki buglar ne olacak diye duyar gibiyim. Bug olmayan bir proje imkansızdır. Bunu dikkate aldığımızda aslında bu bugların 6 hafta daha bekleyebileceğini de düşünebiliriz. Buglar için üç farklı yöntem bulunur; 6 hafta sonrasını bekleme, 2 haftalık bir cool down döneminde bu bugları çözme pitching içinde buglara değinme ve önemli bugları 6 haftalık dönem için planlama. Ayrıca bugları bitirmek için 2 haftalık cool down döneminde ayrı bir session düzenlenebilir.

Bug haricinde bir diğer soru ise projenin yapısı gereği eğer 6 haftadan fazla sürecek büyüklükte ise? Bu durumda proje 6 haftalık bölümlere ayrılmalıdır. Birinci 6 hafta sonunda gerçekten de beklendiği gibi tamamlandı mı, bir sonraki 6 haftalık döneme ihtiyaç var mı sorularının cevabı aranır.

Shape-Up tekniği ile Scrum da bulunan netlikten vazgeçilerek yerine daha rahat fakat insanları daha heyecanlandırıcı bir yönteme önerilmiştir. Bu büyük bir artıdır. Fakat çalışanların bu bilinçte olunduğuna emin olunmalıdır. Süistimal edilebilecek bir yöntemdir. Ayrıca çoğu firmada yöneticinin bu kadar güvenini almak imkansızdır. 6 hafta hiç başka bir konuya bakmadan sadece kendi projesinde çalışan kişi sayısı azdır. Ayrıca bu 6 haftanın tahminleme aşamasında çok iyi tahmin edilmesi gerekmektedir. Yoksa geliştiriciler etkin bir şekilde çalışamayacaktır.

Kendi takımımda deneyemi isterdim fakat yukarıda bahsettiğim nedenlerden dolayı mümkün değil.