21 Temmuz 2013 Pazar

Scrum'da Hayat Kurtaran İpuçları-2: Gözden Geçirme Toplantıları

Scrum uygulayan takımların içine düştüğü karmaşalardan biri de sprint sonunda verilen ve takımın emeğinin değerlendirildiği "başarılı/başarısız" ya da "geçti/kaldı" kararıyla ile ilgilidir.

Teorik olarak Sprint sonunda ne olacağı aslında bellidir. Ürün sahibi takımın yaptıklarını "gözden geçirme (review)" toplantısında inceler ve her bir hikayenin %100 bitmiş (Done) olup olmadığına bakar. Eğer hikayelerden biri ya da birkaçı tam anlamıyla bitmemiş ise, tüm sprint başarısız olmuş demektir.

Teoride çok basit gibi görülen bu kuralı pratiğe dökmek aslında hiç de kolay değil. "Review" toplantılarında insanların ve algıların çatıştığı bir dizi tartışma farkına varılmadan tetiklenebilir. Karmaşaya örnek olabilecek birkaç örnek vermem gerekirse, kısaca şöyle listeleyebilirim.

  • Ürün sahibi yapılması gerektiğini düşündüğü bir işin yapılmadığını düşünür, "hikaye tam olarak bitmemiş" der ve takım da "bizce bitmiş", "yapılmamış denilen işten haberimiz yoktu" ya da "yapılmamış olmasının hikaye üzerinde önemli bir etkisi yok" diye düşünürse, ürün sahibiyle amansız bir pazarlık başlayabilir. Takım bahsedilen işin bitmiş olduğunu ispat etmeye çalışabilir.
  • Yapılan işin kalitesiz olması da işin bitmemiş olduğunu gösterir. Ürün sahibi bu nedenle hikayeyi sınıfta bırakırsa, takım kalite kriterlerinin belirsizliğini öne sürerek tersini iddia edebilir ve pazarlık başlayabilir.
  • Bir geliştirmenin, yoğun uğraşlar verilmiş olsa bile %99'unun bitmiş olması, hala eksik olduğu anlamına gelir. Hikayeleri bu nedenle "başarısız/kaldı" olarak değerlendirilmesi normaldir. Ancak bazen takım ürün sahibini tam anlamıyla bitmemiş bir işi kabul ettirmeye zorlayabilir.
  • Ürün sahibinin takım için "her an ulaşılabilir" olmadığı durumlarda, takım sprint içerisinde karşılaştığı sorunların ve soruların tümünü kendisiyle paylaşamaz. Paylaşamadığı sorunlardan bazıları nedeniyle hikaye başarısız olursa, takım ürün sahibini "takım için her an erişebilir" olmamakla suçlayabilir. Takım başarısızlığın nedeninin kendileri olmadığını, kendilerinin yapılabilecek herşeyi yaptığını ve bu nedenle hikayenin geçmesi gerektiğini söyleyebilirler. Takım haksızlığa uğramış hissiyatına kapılabilir.

Bu ve benzeri tartışmalar nedeniyle takım ve ürün sahibini karşı karşıya getirebilecek zararlı bir durum oluşabilir. Benzeri durumları sizler de zaman zaman yaşamış olabilirsiniz. "Yaşanmaması için neler yapılmalı" sorusunu cevaplamadan önce, öncelikle şu değerleri tüm Scrum takımı tafından bilinmesi ve altında yatan nedenlerin iyice anlaşılması gerekir.

  • Ürün sahibinin takımın açıklarını yakalamak ve sprinti başarısız ilan etmek gibi bir amacı yoktur. 
  • Tam anlamıyla bitmemiş bir iş ya teknik borca neden olur ya da bitmesi için ekstra zaman gerektiğinden gelecek sprintlerden zaman çalar. 
  • Ürün sahibi Scrum takımının bir üyesidir. Mutlaka takıma yakın, takımın ihtiyacı anında cevap verebilecek durumda olmalıdır.
  • Ürün sahibi sprint içerisinde yapılacak hikayeleri tüm netliği ile bilmelidir. Belirsizlikler eğer sprint içinde devam ediyorsa, takım işleri yetiştirmekte zorlanır. 
  • Ürün sahibi daima tutarlı olmalı ve duruma göre bitmemiş bir işi bitmiş kabul ederek takım üzerindeki bitti algısını zedelememelidir.
  • Takım yapılan işlerde dürüst olmalı ve hatalı, eskik ya da gereksiz gördüğü tüm durumları ürün sahibi ve takım ile paylaşmalıdır.
  • Takım başarılı olmak için beraber çalışmalıdır. Yetişmemiş işlerden bireyler değil takım sorumludur. Takım işin bitebilmesi için ne gerekiyorsa yapmalı, birkaç kişiye görevi yığıp sorumluluktan kaçmamalıdır.
  • Başarı bireylerin değil tüm Scrum takımınındır. Tüm bireylerinin -geliştirme takımı, scrum master ve ürün sahibinin- yardımlaşmasıyla ulaşılabilir.
  • "Review" toplantısından çıkan başarısızlık, ne kahrolacak kadar kötü, ne de gözardı edecek kadar önemsiz bir sonuçtur. Başarısızlıktan üzülmek doğaldır ve iyileştirecek noktalar bulunduğu ve sorunlar su yüzüne çıktığı için önemlidir. Gelecekte aynı nedenlerin oluşmaması için üzerine düşünülmesi gereklidir.
  • Scrum master, takımın ürün sahibiyle pazarlık yapan temsilcisi gibi davranmamalıdır. Normal şartlarda başarı ve başarısızlık kriterleri net olmalı, üzerine pazarlık yapılabilecek konu kalmamalıdır.
Bahsedilen tüm değerler takım tarafından bilinmesine rağmen hala aynı problemlerle öyle ya da böyle karşılaşabilirsiniz. Biz de benzer sorunlarla karşılaştık ve bu sorunları yaşamamak için birçok yöntem denedik. Önerilerimi sizlele paylaşmaktan mutluluk duyacağım.

"Bitti'nin Tanımı"na Önem Verin

Yapılacak işlerin hangi şartlar altında "bitti" olarak adlandırılabileceğini anlatan "bittinin tanımı", takım için bir aslında çeklisttir. Testlerinin yazılmış olması eğer bittinin tanımı içerisinde varsa, testleri yazılmamış bir geliştirme henüz bitmemiş demektir. "Review" toplantılarında ürün sahibi bu çekliste uymayan işler için "başarısız" kararı verebilir. Takım günlük scrum toplantılarında biten işlerin ve hikayelerin çekliste uyup uymadığını mutlaka gözden geçirmelidir.

Yapılan işlerin kalite standartları da bittinin tanımında bulunmalıdır. "Continuous Integration"da build'lerin hepsinin geçiyor olması, "code coverage"ın belli bir değerin altında olmaması, kritik hataların bulunmaması gibi kurallar hep kalite standartları altında çekliste girebilir.

Ürün sahibi "hikaye kabul kriterleri"ne sprint başında karar vermelidir 

Sprint içerisinde geliştirilen özelliğin sprint sonunda ürün sahibi tarafından kabul edilebilmesi için UAT ortamında da test edilmiş olması gerekiyorsa, bunun planlama toplantısında belirtilmesi gerekir. Böylece "review" toplantısında, takım tarafından bilinmeyen ya da farkedilmemiş bir nedenden ötürü işler eksik kalmaz. Ürün sahibi planlama toplantısında hikayelerin bulunduğu kartların arkasına "kabul kriterleri"ni de yazar.  Takım sprint sırasında her daim bunları kontrol etme ve eksikleri önceden farketme fırsatı yakalamış olur.

Yapılan işler ürün sahibiyle sprint sırasında da gözden geçirilebilir

"Review" toplantıları sprint için nihai kararın verileceği, ürün sahibinin son sözünü söyleyeceği bir sınav değildir. Hikayeler bittikçe ürün sahibine kısa demolar yapılabilir, onun son gözden geçirme öncesi eksikleri sizlerle paylaşması sağlanabilir. Hatta biz, takımımızın hikayeler için belirlediğimiz "bittinin tanımına", "biten hikayeler önceden ürün sahibine demo yapılmalı" maddesini eklemiştik. Böylece sprintin son günü süprizlerle karşılaşma ihtimali en aza indirgenmiş olur.

 "Scrum'da hayat kurtaran ipuçları" yazı dizisinin 2. yazısını da burada tamamlamış olduk. Biz, burada bahsettiğim ipuçlarını harfiyen uymaya gayret ettik ve başarı oranımızı ve review toplantılarının verimliliğini dramatik olarak arttırdık. Burada bahsedilenler marım sizler için de faydalı olur. Serinin diğer yazılarında buluşmak üzere... 



0 yorum:

Yorum Gönder

Template developed by Confluent Forms LLC; more resources at BlogXpertise