Önceki yazımda belirsizlikleri yönetmenin yöntemlerinden birisinin de projelerin başında uygulanabilecek sprint 0 tekniği olduğundan bahsetmiştik. Bugünkü yazımda da sprint 0 detaylarını aktaracağım.
Agile takımlar kurulmadan önce Product Owner’lar initial product backlog’u hazırlar, ilk sprint için de öncelikli PBI’ları refine ederler. Developer’lar da ilk sprintten itibaren de geliştirmeye başlarlar. Yalnız birkaç sprint sonrasında ise oluşabilecek bağımlılıklar, gerçekleşen risklerden ötürü takım ilerlemekte sıkıntı yaşayabilir. Bir de geliştirilen proje de kurum dışı firmalar, third party ürünler var ise çıkabilecek sürprizler sözleşmesel şartlardan ötürü çok daha büyük problemlere sebep olabilir. Problem ortaya çıktığında ise “Biz Agile çalışıyoruz, Agile’da böyle”, “Ama başta analiz yapmadık ki”, “Waterfall’da ne güzel detaylı analiz yapardık” gibi söylemler duyulmaya başlanır. Projelerin başında uygulanabilecek 2-3 haftalık sprint 0 ile bu tip sürprizlerin yaşanma ihtimali azalacaktır.
Sprint 0’daki amaç projenin hem business hem de teknik anlamda high level seviyede değerlendirilerek bağımlılıkların, risklerin, belirsizliklerin ortaya çıkarılması ve product backlog’un da olgunlaşmasına katkı sağlamaktır. Ayrıca birkaç küçük bir development’la da sürecin, ortamın test edilmesi sağlanabilir.
Sprint 0 öncesi yapılabilecek hazırlıklar;
- Değerlendirmelerde bulunulacak talep sahipler, kullanıcılar, teknik kişiler, bağımlılığı olabilecek paydaşlarla randevu ayarlanması
- Kullanılacak design thinking pratiklerinin belirlenmesi
- Belirlenen design thinking pratiğine göre hazırlık yapılması
- Özellikle cevabı aranacak soruların belirlenmesi
Sprint 0’ın ilk haftası:
İlk hafta business ağırlıklı değerlendirmelere ayrılabilir. İlk hafta boyunca talep sahipleri, kullanıcılar ile bir araya gelerek geliştirilecek üründen beklentiler, yaşanan sıkıntılar takım ve paydaşlarla beraber değerlendirilir.
İlk hafta için önerebileceğim design thinking pratikleri; persona belirleme, röportaj yapma, empathy map olabilir. Bunlar temel pratikler diyebiliriz, geliştirilecek projeye göre bu pratikleri daha da zenginleştirebiliriz. Bu pratikleri kullanarak gerçekleştirilen aktivitelerin yer aldığı 5 güne, Google “Design Sprint” olarak ifade etmektedir. 2010 yılından itibaren de aktif olarak da uygulamaktadır.
Belirlediğimiz personalarla bir araya gelerek röportaj sorularımızı soruyoruz. Burada özellikle belirtmek istediğim nokta ise analiz, yazılım, test ayrımı yapılmaksızın tüm takım üyelerinin personalarla röportaja dahil olması ve aynı soruların sorulmasıdır. Takım üyeleri kendi içinde farklı personlarla bir araya gelerek çıktıları sonradan birleştirebilirler. Her bir persona için empathy map oluşturulabilir.
Bu haftanın sonunda ise talep edilen isteklerin, ihtiyaçların sebepleri takım tarafından da anlaşılmış, değerlendirmeler sonrası sahiplenilmiş oluyor. Aynı zamanda backlog’un olgunluğu artmış oluyor.
Diğer önemli bir çıktı ise User Story Mapping’in oluşması. Bununla ilgili daha önce detaylı bir yazı yazmıştım.
Sprint 0’ın ikinci haftası:
İkinci hafta teknik ağırlıklı bir değerlendirmeye ayrılabilir. Geliştirilecek projenin genel mimarisi değerlendirilerek geliştirme sürecinde yaşanabilecek riskler, bağımlılıklar konusunda farkındalıkların artmasını ve alınabilecek aksiyonlarında da erken alınması sağlayacaktır. Third party bir ürün kullanılıyorsa da ürünün yetkinliklerinin değerlendirilmesi sağlanacağından ürünle ilgili yaşanabilecek sürpriz de azalacaktır.
Sadece mimari ekiple değil de bilgi güvenliği, devops, operasyon, data ekipleri gibi projenin ilerleyen aşamalarında bağımlı olacağını düşündüğünüz, kurum içinde uyulması gereken standartları olduğunu düşündüğünüz ekiplerle kısa kısa bir araya gelerek belirsizlikleri minimize edebilirsiniz.
Bu haftanın çıktısını da mimari altyapı, bağımlılıklar ve alınabilecek aksiyonların listesi olacaktır. Hatta kısa dönemli bir proje geliştiriyorsanız draft sprint goalleri bile çıkarabilirsiniz. Tecrübeli bir takımsanız product burndown chart’ın çıkmasını da sağlayabilirsiniz.
Sprint 0 boyunca ortamsal değişiklikler var ise onların kurulması sağlanabilir, daha önceki ekiple ilgili ufak tefek işler kalmışsa onlar temizlenebilir, ufak birkaç Development yaparak da ortamın, sürecin testini gerçekleştirebilirsiniz.
Sprint 0’ı bu şekilde uygulamanın avantajları;
- Talep sahipleri, analiz, geliştirme, test uzmanlık alanları aynı noktada olabilecektir. İhtiyaç benimsenmiş, çok daha etkili çözümlerin çıkması sağlanacaktır.
- Mimari, bilgi güvenliği, operasyon, data gibi kurum içinde merkezi ekiplerle bilgi alışverişinde bulunulmuş hem takım hem de teknik ekipler aynı noktada olacaktır.
- User story mapping ile kullanıcının deneyimi ortaya çıkarılmış, değerli, öncelikli işler daha rahat görünecektir. Yapılacak, değiştirilecek işin de etkisinin farkındalığı artmış olacaktır.
- Bağımlılıklar ve riskler ortaya çıkarılmış olacak.
Sprint 0 sonunda gerçekleştirilerek review etkinliğinde tüm paydaşlar davet edilerek bu çıktılar paylaşılabilir. Herkesin aynı noktada olduğu, farkındalıkların arttığı, benimsendiği , hep beraber çözüm arandığı bir proje de belirsizlikler minimize olacağı gibi yüksek motivasyonla geliştirilmesi sağlanacaktır.
