Metodolojimiz

EMS-ERP 1C: Enterprise 8.3 kullanarak Çevik Manifesto ve Scrum Metodolojisi ile geliştirilmiştir, açık kaynak kodlu 1TC Ticaret Yönetimi paketi üzerine geliştirilmiştir. İleri seviyede deneyime sahip olmayan uzmanlar tarafından geliştirilebilir.

“Scrum ile Yazılım Geliştirme Süreçleri Yönetimi” Derken Ne Kastediyoruz?

Genel bir söylem vardır, Geliştir-Test Et-Yayınla!  Aslına bakarsanız bütün metodolojilerin amacı bu üç kavram üzerinde yoğunlaşır. En büyük amaç ortaya bir ürün çıkarmaktır. Sadece aşamaların izlendiği yol farklıdır. İşte biz “Scrum” ile kendimize bir standart getirmiş oluyoruz. Kısacası “Yazılım fikrinin doğmasından, projenin bitirilmesine kadar bütün geliştirme aşamalarını, Scrum mimarisini kullanarak standartlaştırıyoruz.Verimli bir kaynak yönetimi avantajı sağlarsınız. Örneğin yazılım geliştirmenin en önemli kaynağı olan, “yazılımcıyı” ele alalım. Projeye tümden bakıldığında kaç  kişi gerektiğini kestirmek çok zordur. Çoğunlukla sonradan eleman takviyeleri yapılır. Halbuki her “sprint” için eleman sayısını kestirmek çok daha kolay olur.

 

Scrum ile özet ve ek olarak aşağıdaki avantajları sağlıyoruz;

  • Proje parçalarının başlangıç ve bitiş sürelerini zamanla çok daha hızlı saptarsınız.
  • Takım ruhu oluşur. Proje(Sprint) başarısız olursa tüm takım “başarısız”, başarılı olursa tüm takım “başarılı” sayılır.
  • Planlama sadece başta değil her aşamada olur. Böylece bütünün planını değil parçaların planını yapma avantajı sağlarsınız.
  • Projeye adapte olmak kolaylaşır. Sonradan dahil edilen elemanlar büyük bir okyanusta boğulmazlar. Çünkü dökümantasyon anlamlı, sıralı ve doğru oluşturulmuştur. Halbuki normalde hiç birimiz bir projeye sonradan dahil olmayı sevmeyiz.
  • Müşteri memnuniyeti ön plandadır. Çünkü "Değişim", korkulan değil desteklenen durumdur. Bu da müşteriyi fazlasıyla memnun eder.

Neden Scrum? 

Yazılımların ve yazılımcıların bazı konularda müşteriler tarafından  nasıl algılandığını düşündüğümüzde, olumsuz konuları konuşacak olursak, herhalde ilk sıraya zamanlama problemlerini koymak zorunda kalırız. Gerçekten çevremizdeki yazılım projelerini düşündüğümüzde çok azı zamanında biter. Bunun nedeni nedir diye düşündüğümüzde neler sayabiliriz? 
Hatalı planlama, hatalı tahminleme, takım olgusunun oluşmaması, dökümantasyon eksikliği gibi bir çok madde takımın yaşadığı yoğunluğa göre sıralanabilir. Scrum bunların hepsine bakış açısının değiştirilerek yeniden ele alınmasını önerir. Bu bakış açıları Agile dediğimiz süreçlerin yorumlanmasıyla gerçekleşir. Scrum’ın yazılımdaki bazı temel sorunlarla nasıl ilgilendiğini inceleyelim.

Planlama(Planning) : 

Waterfall gibi klasik süreçlerde planlama büyük ölçüde başta yapılır. Yani bir yıllık bir projenin ilk aylarında analiz ve tasarım çalışmalarınin bitmesi hedeflenir.  Fakat yazılımın doğası buna aykırıdır. Değişim, yazılımın doğasında en temel olgudur. Bu yüzden bir yıllık projeyi sürekli değişime uğrayacağı için baştan planlamak çok zordur veya imkansızdır. Bu amaçla scrum, planlama süreçlerini daha kısa zaman dilimlerinde tekrarlar. Iteratif bir yapı söz konusudur. Küçük olanı planlamak daha kolay, doğru ve efektif olacaktır.

Takım Olgusu:

Bana göre scrum’ın mükemmel getirilerinden biridir. Scrum’da takım ruhu en üst seviyeye çıkıyor. Takımın aynı senaryolarda benzer düşünmesi sağlanıyor. Yapılan toplantılar sürekli takımı seviyelendirmeyi hedeflemektedir. Waterfall gibi süreçlerde genelde bir müddet sonra takım olgusu kaybolup, modüler yazılım geliştirme süreçleri başlar. Demem odur ki, takım içinde bireysellik hakim olmaya başlar. Her ne kadar takım aynı yazılımı geliştiriyor olsa da, her modülü yazan farklı bir-iki kişi vardır. Yazılımın doğası takımı bu şekilde yapılanmaya yönlendirmiştir. Takımdan biri ayrıldığında,  projenizin büyük bir sıkıntıya gireceğini düşünüyorsanız yeterince çevik değilsinizdir. Çevik örgütlerde, yazılımı kişi değil, takım geliştirir.

Dökümantasyon: 

Scrum’da dökümantasyon için ayrıca vakit ayrılmaz. Dökümantasyon kendiliğinden oluşur. Çünkü hepimiz biliyoruz ki neredeyse hiçbir yazılımda dökümantasyon yapılmaz veya prosedürlere uymak amacıyla son bir iki ayda eksik, baştan savma yapılır. Scrum’da iş elemanlarının(work items) oluşturulma standartları ve takibi ortaya başarılı bir dökümantasyon çıkarır. Standartlara göre oluşturulan iş elemanları hem takımı çevikleştirdiği için motivasyonu arttırır hem de ortaya dökümantasyon çakarır.

Liste ve Sprint

Scrum’da projenin ana gereksinimleri önem sırasına göre bir liste (Product Backlog)  olarak toplanır. Bu listedeki her bir eleman küçük yapılara dağıtılarak(sprint), daha küçük alt projeler oluşturulur.  Artık küçük birimler olduğundan değişimin üstesinden gelmek çok daha kolay olur. Her sprint veya planlamaya göre birkaç sprint ortaya muhtemel bir ürün çıkarır. Bu ürün, müşteri ile kabul kriterleri konusunda sonradan yaşanması muhtemel problemleri erken farketmemizi sağlayacaktır. Kısacası waterfall sürecinde bir kere tekrarlanan döngü, scrum’da defalarca tekrarlanır.

Tahminleme(Estimation) : 

Scrum’ın iteratif bir yapıya sahip olması doğal olarak küçük parçaların bütünselliğini sağlıyor. Aynen planlamada olduğu gibi küçük iterasyonları tahminlemek daha kolay olmaktadır.

Scrum Toplantıları

Scrum Toplantıları 15 dakika ile sınırlı, aynı yer ve aynı zamanda gerçekleşen toplantılardır.

3 soruya cevap ararlar:

1-     Bir önceki toplantıdan bu yana ne yaptım?

2-     Bir sonraki toplantıya kadar ne yapacağım?

3-     Yolumuzdaki engeller nelerdir?

Scrum Guide (Türkçe 2011)’e baktığımızda bir ve ikinci sorunun aşağıdaki şekilde Türkçeye çevrildiği gözüküyor

1-     Bir önceki toplantıdan sonra hangi işler tamamlandı?

2-     Bir sonraki toplantıya kadar hangi işler yapılacak?

Ekip üyeleri bazen iki toplantı arasında üzerilerine aldıkları bir işi tamamlayamıyabiliyorlar, bu durumda üzerinde çalıştıkları işi aktarmalarında fayda olduğunu düşünüyorum.

Şu ana kadar karşılaştığım klasik hataları aşağıdaki şekilde listeleyebilirim:

·        Toplantıya tüm ekibin katılmaması: İlgili toplantı ekip içi bilgi aktarım ve paylaşımını sağlamak için yapılırken ekip içerisinde katılmayan kişilerin hem bilgilendirilmesi, hem de değerli geri beslemelerinin alınamamasına neden olabilmektedir. İlgili toplantı aynı zamanda bilginin tüm ekip içerisinde yayılmasına imkan sağladığı için katılımın gerçekleşmemesini bir hata olarak görüyorum.

·        Toplantının her gün aynı zamanda başlamaması: Burada temel problemlerden birinin toplantının günlük yapılamaması, diğerini ise farklı zamanlarda yapılması olarak düşünebiliriz. Toplantı saati olarak genellikle sabah işe başladıktan sonraki ilk saat içinde yapılması tercih edilmektedir. Geç gelmeler gibi durumlarda ekip bazen geç gelen üyeleri beklemeyi tercih edebilmektedir. Ancak toplantı gerçekleşene kadar geçen sürenin ekip tarafından etkin kullanılıp kullanılamadığı incelenebilir. Tecrübelerim toplantı öncesi sürelerin etkinliklerinde problem olduğunu göstermektedir.  

·        Toplantının aynı yerde yapılmaması: Toplantı, ekibin sprint hedefini ve mevcut işlerin durumlarını görebilecekleri bir ortamda yapılmalıdır. Scrum panosu önünde yapılacak bir toplantı faydalı olacaktır.

·        Toplantının ekip içi paylaşım toplantısı yerine raporlama toplantısına dönüşmesi:Yapılan hatalardan biri ekibin scrum master, product owner veya tavuk olarak nitelendirilen scrum ekibi dışında bir kişiye raporlama toplantısına dönüşmesidir. Çeşitli zamanlarda ekibin 3 soruya cevap verirken bana raporlama durumuna geçmeleri durumunda toplantının bana raporlama yapılması yerine ekip üyeleri ile paylaşmaya yönelik olduğunu diğer ekip üyelerini gösterme, yer değiştirme, bir ekip üyesinin arkasına geçme, arkamı dönme gibi davranışlarla hatırlatmaya çalışırım.

·        Toplantı öncesi hazırlık yapılmadan toplantıya gelinmesi: Ekip üyeleri tarafından cevap verilmesi gereken soruların yanıtlarının toplantı öncesi düşünülmesi gerektiğini, bazı toplantılarda aşağıdaki şekilde cevaplar gelmesi ile üzülerek farkettim.

o   Dün ne üzerinde çalışmıştık? : Hangi story üzerinde çalışıldığı hatırlanmıyor.

o   Sıradan iş alacağım: Tüm ekibin aynı cevabı verdiğini düşünebiliyor musunuz? Bugün ne üzerine çalışılacağı konusu incelenmemiş.

o   Ne engelimiz var dı? Sürekli İyileştirme üzerinde düşünülmüyor.

·         Zombi takım üyeleri: Tecrübelerimden bazı takım üyelerinin toplantılar sırasında sesi sadece yanındaki kişiler, hatta bazen sadece kendisi  tarafından duyulabilecek şekilde aşağıdakine yakın bilgi paylaştığını gördüm. Dün 123 nolu hikayesi üzerinde çalıştım. Bugün çalışmaya devam edeceğim. Problemim yok.  Bu tür bir paylaşımın ekip için hiçbir fayda sağlamadığını düşünüyorum. 123 nolu hikaye nedir? Dünkü çalışmada ekip olarak bizim de öğrenmemiz gereken bir sorun veya bir iyileştirme ile karşılaşıldı mı? Bugün üzerinde çalışıldığında işin ne kadarı bitecek, iş bitecek mi? Ekipte birisi yardımcı olabilir mi? İşe gelip, board dan task alıp, üzerinde çalıştığı ve ekibe bir şey katmayıp, paylaşmayan ekip üyelerini zombi olarak görüyorum. Bu tür üyeler ekibe enerji vermek yerine ekibin enerjisini emebilmektedir.

·        Engeller konusunda farkındalık eksikliği: Ekip üyelerinin engelleri olmalarına rağmen, toplantı sırasında bu engellerini paylaşmamaları. Tecrübelerim sırasında bu farkındalık eksikliğine neden olan bazı kök nedenler olarak ekip içerisinde sürekli iyileştirme yaklaşımın bilinmemesi – daha iyi nasıl yapılabileceğinin sorgulanmaması, problemlerin kanıksanması – engel listesine yazılmaya değer görülmemesi, bir engel listesi olmaması, güven sorunu (ekip üyelerinin kişiye özel bir bilgi eksikliği nedeniyle ortaya çıkan problem karşısında kişiye nasıl davranacaklarına güvenememe)

·        Burn down chart olmadan, güncel olmayan scrum tahtası ile gerçekleşen scrum toplantıları:   Günlük scrum toplantıları ve günlük çalışmalarımızın hedefi sprint hedefinin tamamlanmasıdır. Gerçekleştirdiğimiz toplantılarda hedefin neresinde olduğumuzu ve mevcut durumumuzu göremediğimiz toplantılarda hedefi 12’den vurmak için nasıl davranmamız gerektiğini kestiremeyiz. Bu nedenle toplantı öncesi mevcut durumumuzu görmek ve hedefe ulaşabilmek için bir sonraki adımı atmak için burn down chartımız ve scrum tahtamızı güncel tutmalıyız.

·        Toplantının teknik, gereksinim, statü vb. toplantısına dönüşmesi: Günlük scrumtoplantısı 3 soruya cevap arıyor. Bunu teknik, gereksinim veya statü toplantısına dönüştürdüğümüzde her bir takım üyesinin 15 dakika içinde bilgi paylaşımı özgürlüklerini ellerinden alınmış oluyor. Bu tür ihtiyaçlarda sadece ilgili, gerek duyalan kişilerle scrum toplantısı sonrası için yeni bir toplantı ayarlanabilir.

·        Tavukların sazı (sözü) eline alması: Günlük Scrum toplantısı takım üyelerinindir, tavuklar gelip dinleyebilir. Ancak tavuklar, sözü ele alıp ekibin bilgi paylaşımına odaklandıkları zamanını almamalıdırlar. Bu tür bir ihtiyaç varsa ayrı bir toplantı ayarlanabilir.

·        Ekip üyelerin toplantı sırasında birbirlerini dinlememeleri: Birbirine değer katılacak bir ortam olan toplantıda, birbirini dinlememek altında yatan temel nedenler bulunup ortadan kaldırılmalıdır. Ne yazık ki ekipler içinde görülebilmektedir.

·        Bilgisayar başında toplantı: Bazen scrum board elektronik ortamda tutulabilmektedir. Bu tür durumlarda projeksiyona bağlı tek bir bilgisayar ve söz sahibi olan ekip üyesinin sırayla bilgisayar başında olması; ilgiyi konuşan kişinin üzerine çekebilir. Ancak diğer ekip üyeleri de bilgisayar başında ise ilgi başka bir yere yönelebilmektedir.

·        Toplantının benimsenmemesi: Ekip üyelerinin toplantıya gerekli değeri vermemesi ve scrum master’ın zoraki daveti sonrasında toplantının başlaması.

·        Toplantının 15 dakikadan uzun sürmesi: Muhtemelen 3 soru dışında konular ve toplantının başka bir toplantıya dönüşmesi veya sazı sözü alan kişiler bulunabilir. Bunun için söz verilen kişinin 2 dakikalık söz hakkı olduğu, kronometre tutarak süre disiplinini sağlayabilirsiniz.

Siz de scrum toplantılarında  hatalı olarak gerçekleştiğini düşündüğünüz durumları yorum olarak paylaşabilirsiniz.

kaynak erdem seherler blog

Scrum Masters

Scrum Master, sadece Scrum’ın doğru bir şekilde uygulanmasından ve üretkenliğin arttırılmasından sorumlu değildir. 
Scrum Master’ın asıl ve zor görevi değişime liderlik etmektir.

Scrum, uzun soluklu bir değişim sürecidir. Beraberinde iş yapış şekillerinin ve organizasyon kültürünün değişimini gerektirir, ki bu zor, zahmetli ve disiplin isteyen bir süreçtir. Öyle ki yapılan araştırmalar ‘değişim’ projelerinin sadece %35 oranında başarılı olabildiklerini göstermektedir. Scrum gibi kimi organizasyon kültürlerinde neredeyse %180 derece bir değişim gerektiren, yani bir paradigm shift gerektiren, dönüşümlerde risk çok daha fazladır. Bu nedenle, başarıya ulaşmak için Scrum Master ve yetkinliği ciddi önem taşımaktadır.

Scrum Master, sadece Scrum’ın doğru bir şekilde uygulanmasından ve üretkenliğin arttırılmasından sorumlu değildir.Scrum Master’ın asıl ve zor görevi değişime liderlik etmektir. Bu doğrultuda Scrum Master, Scrum konusunda uzman olduğu kadar değişim ve yönetimi konusunda da yetkin ve deneyimli olmalıdır. Değişim ancak, Scrum bakış açısını benimsemiş, değişimi disiplinle ele alan ve önüne çıkan engelleri yılmadan aşmaya çalışan bir lider ile gerçekleştirilebilir.