Search
  • Dinçer Özturan

Scrum & Time Sheet

Updated: Sep 22, 2019


Scrum uygulayan yazılım ekiplerinin zaman çizelgesi doldurmalarına gerek var mı? Scrum uygulayan ve harcanan efor üzerinden faturalama yapan yazılım şirketleri için zaman çizelgesi doldurtmaktan başka bir çıkış yolu var mı? Yoksa zaman çizelgesinden kurtuluş yok mu?


Scrum'ın yaratıcılarından Jeff Shutterland tarafından 3.8.2012 tarihinde kaleme alınan "Time Tracking is Anti-Scrum: What do you do when you need it for billing?" isimli makalenin doğrudan çevirisidir.

Bir yazılım projesinde, ekip üyelerinin hangi işe, ne kadar zaman harcadıklarını takip etmek, ekibi genel anlamda yavaşlatır ve canlı geçiş takvimi konusunda Ürün Sahibinin aklını karıştırır. 50 yıldan fazla süredir yapılan araştırmalar sonucunda, saat cinsinden yapılan süre tahminlerinin hata payı ve değişkenlik oranının nispeten yüksek olduğu, buna karşın oransal puanlama ile yapılan tahminlerin daha başarılı olduğu ortaya çıkmıştır.

Scrum uygulayan danışmanlık ve yazılım geliştirme şirketlerinin, geleneksel şelale yaklaşımını uygulayan ekiplere nazaran 5 kat daha üretken olmalarına karşın, müşterilerine halen harcadıkları saat üzerinden fatura kesmesi son derece anlamsızdır. Bu yaklaşım, söz konusu danışmanlık şirketinin sadece harcadığı saat üzerinden para kazandığını, diğer bir deyişle yarattığı katma değere karşılık gelen paranın %80’ini masada bıraktığı anlamına gelir. Bu yaklaşım çok kötü bir iş anlaşmasının göstergesidir.

Bazen danışmanlık ve hatta ürün şirketleri saat cinsinden ücretlendirme yapmak zorunda kalabilir veya yönetimi bilgilendirmek için saat bilgisine ihtiyaç duyabilir. Bu durumda, Scrum verisi üzerinden, geleneksel yöntemlere nazaran daha hassas süre ve teslimat tahmini oluşturulabilir. PatientkKeeper projesinin ilk yıllarında, hiper-üretken Scrum üzerine denemeler yapmakta ve detaylı saat tahminleri istemekteydik. Bu projede, uzun yıllar boyunca, on binlerce puan verisi topladık ve sadece puan tahmini toplayarak daha hızlı ilerlediğimizi öğrendik. Sonra da saat cinsinden tahminleme yapmayı bıraktık.

PatientKeeper bünyesinde, 2002 yılında otomasyon C Tipi Scrum çalışmaları sırasında, yazılımcıların idari konularda harcadıkları zamanı minimize etmek istiyorduk. Bunun için, yazılımcılardan alınabilecek en anlamlı verinin ne olabileceğini sorgulayan ve organizasyonu yalınlaştırmayı amaçlayan bir anket çalışması yaptık. Yazılımcıların üzerindeki idari yükü ortadan kaldırmayı amaçlayan buna benzer başka bir çalışma yapılıp yapılmadığını açıkçası bilmiyorum.

Anket sonucunda beklediğimizden farklı bir sonuç ile karşılaştık. Biz, İş Yıkım Şemasının nasıl güncellenmesi gerektiğini öğrenmek isterken, yazılımcılar görevlere ilişkin kalan işi, hergün saat cinsinden tahmin etmekle uğraşmak istemediklerini söylediler. Neden olarak şunları gösterdiler:

  • 5 adet görev için, kalan kısma yönelik süre tahmini yapmak 60 saniyeden uzun zaman alıyor.

  • Kalan kısmı saat cinsinden tahmin etmek için kendimizi zorluyoruz; "doğru olması gerekmeyen bir tahmin" yapmak zorunda olmaktan rahatsız oluyoruz.

  • Kalan iş için saat cinsinden yapılan tahmin güvenilir değil, risk seviyesi de yüksek. İnanarak verebileceğimiz sadece iki bilgi var: Bir görev için o ana kadar ne kadar efor harcadığımızı saat cinsinden söyleyebiliriz. Ek olarak, o ana kadar bitirdiğimiz kısmın yüzdesi hakkındaki hissiyatımızı belirtebiliriz. Bunlar dışındaki her türlü veri anlamsızdır.

Bu anketin uygulandığı uzmanlar üst düzey yetkinlikleri olan profesyonel mühendislerdi. Birçoğunun MIT ve benzeri kurumlarda doktorası vardı. Scrum’ı gayet iyi biliyorlardı ve motivasyonları da gayet yerindeydi. Bu bağlamda, anket sorularına verdikleri cevapların samimi olduğunu ve ciddiye alınması gerektiğini düşündük.

Gelen geribildirimler sonrasında sistemde düzenlemeler yapıldı. Her ekip üyesi, artık hergün üzerinde çalıştığı görevler ile ilgili “harcadığı toplam zamanı” ve söz konusu görevin o andaki “tamamlanma oranını” girmeye başladı. İş Yıkım Şemasının bu veriler üzerinden sistem tarafından otomatik güncellenmesini sağladık. Ekip üyesi bir görevi güncelleyerek, o güne kadar söz konusu görev için 1 gün harcadığını ve görevin %50’sinin tamamlandığını beyan ediyorsa, sistem otomatik olarak görevin kalan süresini 1 gün olarak tahmin ediyordu. Bu bağlamda görevin toplam süre tahmini yine sistem tarafından 2 gün olarak güncelleniyordu. İlk tahmin ise veri analizi için sistem tarafından arşivleniyordu. İş yıkım şeması, gün içerisinde üzerinde değişiklik yapılan her görev için yapılan yeni tahmini dikkate alarak, otomatik olarak güncelleniyordu.

Bu yaklaşımda, herkese şeffaf olarak sunulan tek bilgi Sprint’in başarılı biçimde tamamlanması için kalan efor tahminidir. Ekip Sprint sonunda “tamamlandı” noktasına ulaşmaya odaklanır ve ekibe zaman çizelgesi doldurması istenmez. Bu yaklaşım, İş Yıkım Şemasının güncellenmesinin en yalın yoludur. Bu yaklaşımın bir yan faydası, harcanan saat üzerinden faturalama yapan danışmanlık şirketlerinin, ekip üyelerine ayrıca bir zaman çizelgesi doldurtmadan, faturaları sistem üzerinden oluşturabilmesidir.

Dün, Kopenhag’da verdiğim Scrum eğitimine deneyimli proje liderleri katılmıştı. Hepsi IBM bünyesinde CMMI Seviye 5 olgunluğundaki bir ortamda çalışıyordu. Yazılımcılara zaman çizelgesi doldurtmanın, üretkenliği %10 oranında azalttığı konusunda hemfikir olduk. Yazılımcılar zaman çizelgesi doldurmaktan nefret eder. Zaman çizelgesi doldurmak tamamen israftır. Yazılım ekip üyelerinin zaman çizelgesi doldurulmasını isteyen kurumların büyük bölümünün yalın ürün geliştirme hakkında en ufak fikri yoktur.

Efor raporlamasının son derece karmaşık olduğu şirketlere danışmanlık yaptım; yazılımcılar zaman çizelgelerini süsler, bunun sonucu olarak şirket aslında müşterilerine yalan söyler, üst yönetim yanlış veri üzerine yanlış kararlar alır ve şirketin pazardaki başarısından feragat ederler. Bir kurumun üst yönetime yönelik hazırladığım son raporda, zaman çizelgesi raporlamasının, tüm geliştirme çalışmalarındaki üretkenliği %50 oranında azalttığını belirttim.

Aklı selim herhangi bir proje lideri, bir geliştirme ekibinin üretkenliğinin %10’unun veya daha fazlasının israf edilmesine asla izin vermeyecektir. Böylesi bir israftan kaçınmak ve kazanılan zamanı daha fazla özellik geliştirmek adına harcamak için ellerinden geleni yapacaklardır.

Sonuç olarak, saat cinsinden faturalama yapan yazılım kurumlarına önerim şudur:

  • Tüm efor raporlamalarını iptal edin.

  • Yukarıda, C Tipi Scrum uygulamasında anlatılan yapıyı kurun.

  • Müşteriye yapacağınız raporlamayı C Tipi Scrum yaklaşımı ile otomatik üretin. Bu bilgiyi geliştirme çalışmalarının ne kadar ilerlediğini anlamak veya göstermek için asla kullanmayın.

  • Bu yaklaşım, kullanılan her türlü zaman çizelgeleme yönteminden daha doğru veri sağlar. Bu yaklaşım sayesinde, yazılımcılar zaman çizelgesinde makyaj yapmakla uğraşmaz. Her görev için harcanan süre tam olarak ortaya çıkar. Çalışmaların ilerlemesinin en ucuz analizini size sunar. Müşterilerinize asla yalan söylememiş olursunuz; ne kadar efor harcandıysa onun ücretini ödemiş olurlar.

Saat cinsinden harcanan efor üzerinden faturalama yapmayan kurumların zaman çizelgesi doldurmaktan tamamen vaz geçmesini ve sadece oransal puan tahminleri kullanmasını öneriyoruz.

Bu yaklaşımı benimseyen ekiplerin hem tahminleri daha doğru olur, hem de üretim hızları artar.

Makalenin İngilizce orjinal versiyonuna buradan ulaşabilirsiniz.

#scrum #timesheet

0 views

Adres : CAFERAĞA MAH. NEŞET ÖMER SOK. NO:5-7/3 34710 Kadıköy İstanbul Türkiye

Eposta: info@projera.com | Telefon: +90 216 336 0667 | Fax: +90 216 336 0667

© 2019 PROJERA DANIŞMANLIK LTD.