Agile Metodolojilerden Kanban ve Scrum Arasındaki Farklar

Yazılım Geliştirme süreçleri ve SDLC (Software Development Lifecycle) yaşam döngüsünü daha verimli hale getirmek için Agile metodolojiler son zamanlar da fazlasıyla tercih edilmeye başlandı. Özellikle Türkiye’deki birçok Kurumsal ve Start-Up kurumlar Waterfall model yerine Agile modelleri olan Scrum ve Kanban’a geçiş yapıyor.

Türkiye’de en çok Scrum üzerine çalışmalar ve araştırmalar yapılmaktadır. Kanban metodu biraz daha az kullanılır. Kanban, işlerin görünürlüğünü biraz daha ön planda tutmaktadır. Work in Progress (WIP) sürelerini hızlandırmak ve verimliliği maksimum seviyeye çıkarmayı hedefler.

Scrum'da Sprint Burndown Chart ve TFS'de Kullanımı

Sprint Burndown Chart, Sprint içinde takımın gidişatını ve kalan iş saatini gösteren bir donedir Takımın başarısını değil gidişatını gösterir. Alınan iş, kalan iş süresi, Emerged PBI alımı, ideal çizgi ile orantı gibi birçok veriyi Burndown Chart üzerinde görebilirsiniz.

Sprint Burndown Chart genelde Scrum Board'a yakın veya yanında olur. Her gün güncellenmesi gerekir. Kalan iş saatin en iyi Burndown Chart üzerinden görebilirsiniz. Daily Scrum’lar da kalan iş veya kalan saat bilgisine odaklanmak önemli. Scrum, ne kadar iş yaptığınıza değil kalan iş ne kadar onunla ilgilenir. Genelde grafiği olumsuz etkileyen durumlar Impediment ve Emerged PBI'lar dır. Sprint içinde eğer grafik yukarı doğru çıkmışsa buradan durumu anlayabilirsiniz.

Agile & Scrum Çalışma Metodolojisi ile Team Foundation Server Üzerinden Test ve BUG Yönetimi

Agile & Scrum çalışma metodolojisi için en iyi araçlardan biri olan Microsoft Team Foundation Server üzerinde Test işlemleri ve BUG yönetimini anlatacağım. Özellikle Bug yönetiminin kolaylığı sayesinde hem Test işlemleri daha da hızlanıyor hemde Developer-Tester arasındaki Fix süreci daha da verimli olabiliyor.

Anlatımı www.visualstudio.com/tfs üzerinden yaptım. Sizde ekip olarak Scrum ile çalışıyorsanız ücretsiz Microsoft üyeliği alarak link üzerinden Online Board yönetiminizi yapabilirsiniz.

İş Analisti Nedir? Scrum'da Analiz Süreçleri Ne Şekilde Gerçekleştirilir?

İş Analisti, kurumun iş yapısını, iş kurallarını, iş süreçlerini çözümlemek, sorunlar ve fırsatlar için çözümler üretmek, çözümleri oluştururken çeşitli fonksiyonel birimler ile çalışarak, gerektiğinde bütünleştirici görev ve teknikler bütünüdür.

Temelde müşterinin iş ihtiyacını anlayıp, yazılımcı ve son kullanıcı arasındaki köprü olup işi yazılımcının anlayabileceği şekilde dokümantasyonunu yapmaktadır. Telekomünikasyon, Bankacılık gibi birçok büyük kurumda iş analisti vardır.

Bankacılık sektöründe özellikle Business Unit veya Stratejik İş Birimi olarak geçen son kullanıcı ile BT arasında köprü görevi gören analist Scrum sürecinde Sprint'ler içerisinde yazılımcıya tüm analiz dokümanını paylaşmak yerine o Sprint için yapacağı kararlı bir Solution Document (Çözüm Parçacığı veya Çözüm Dokümanı) yazılımcıya vererek uzun uzun yazılan analiz dokümanları yerine kısa, net ve öz yazılan bu doküman daha çok tercih edilmektedir.

Scrum Üzerine Kısa Bilgiler (Agile & Scrum Glossary)

Agile süreçlerin en iyi uygulamalarından biri olan Scrum'ın birçok terimlerini ve kısa ama yararlı bilgilerini bu başlık altında toplamaya çalışacağım.

Scrum'da Bir Takımın Kalitesi Nasıl Ölçülür?

Çevik(Agile) yazılımın en iyi uygulamalarından biri olan Scrum'ı tam anlamıyla yönetmek ve işletmek başlı başına bir disiplin sürecinden geçmektedir. Bütün çarklar birbirine bağlı olup tek bir yerdeki aksaklık Scrum sürecini ve kaliteyi düşürür.

Öncelikle şunu söylemeliyim ki her takımın Scrum metodolojisini uygulaması mümkün değildir. Takım kurma sürecinden itibaren başlayan Scrum serüveni hakkında size bazı yaşanmışlıklardan bahsedeceğim. İlk olarak takım kurarken mutlaka ekip Cross Functional olmalıdır. Developer tüm süreçleri analizden teste kadar bilirken, bir testçi analist kadar konuya hakim, bir analist ise detaylı test yapacak kadar kaliteden ödün vermemesi gerekir. Eğer ekip kurarken başlangıçta bu problemler varsa aşağıdaki saydıklarım birçok Scrum Team'in başına gelecektir.

Scrum Team(Takımı) ve Product Owner

Scrum Team, kendini yöneten takımlara denir. Scrum Takımı; Product Owner, Scrum Master ve Development Team'den oluşur. Takım dışındaki kişilerden komut almak yerine, işlerin nasıl yapılacağına kendi karar veren bir yapıdır. Scrum takımları Self-Organized yapıda olup kendi kendilerini yönetirler. Takım Cross-Functional özelliğine sahip olup, takım dışında kişilere bağlı kalmadan istenilen ürünü üretebilecek beceri yetkisine sahiptir.

Cross-Functional özelliği takım kurulurken çok önemlidir. Gerekli mimari yapı ve yetkinlik yeterli değilse, takım kaliteli ve zamanında ürün çıkarma hızına ulaşamayacaktır. Bu problem her Sprint sonunda gözle görülür şekilde yansıyacaktır. Scrum'da takım modeli; esneklik, yaratıcılık ve üretkenliği en iyi şekilde kullanmak üzerine tasarlanmıştır.

Scrum'da Definition of Done (DoD) Nedir? ve DoD Kriterlerindeki TEST Süreçleri

Definition of Done veya kısa adı ile DoD bir PBI'ın Production ortamına verilmesi hazırmış gibi kabul edilen, PBI'ın bitmesi için oluşturulan kabul kriterlerine ve adımlarına denir. DoD kriterleri bir PBI'ın kalitesini ölçmekte en önemli etkendir. Siz DoD kriterlerini esnetir veya bazı adımlarını geçiştirir seniz günün sonunda kalitesiz ürün ile karşılaşırsınız.

Kaliteli ürün ve kaliteli şekilde Done olmuş bir PBI, takımın Velocity değerini de yükseltecektir. Velocity bilgisi PBI bazında olup, DoD kriterlerine sadık kalan takımlar Done yaptıkları PBI'lar ile kendi kalitesini Scrum sürecinden göreceklerdir. Ayrıca PBI almadan önce Definition of Ready(DoR) çalışması yapılabilir.

Aşağıda örnek bir Definition of Done listesi oluşturdum. Bu kriterlerde hangi adımları kimler beraber yaparsa kaliteli ürünün çıkmasına ve çevik yaklaşımın gelişmesine yardımcı olmalıdan bahsettim.

Product Backlog Item (PBI) Nedir? Kaizen Action ve Task'lar Nasıl Belirlenir

Scrum'da yapılan işin temel parçacıkları olan Product Backlog Item (PBI) veya Türkçe adı ile Ürün Gereksinim Maddesi; büyük bir proje veya işi ufak parçalara bölerek işin tümünün bitmesini kolaylaştıracak iş parçacıklarına denir.

Product Owner Proje ve Epics olan büyük işleri PBI olarak görünebilir parçalara bölüp Product Backlog'a ekler. Burada en önemli nokta PBI'ların bir Sprint bazında yapılabilirliği mümkün olması ve işin iyi parçalara bölünmüş PBI'lar dan oluşmasıdır. Gereğinden fazla büyük PBI'lar Sprint Planlamada takıma zorluk çıkartabilir ve işlerin yetişmesini engelleyebilir.

Bir PBI'ın Size değeri yani büyüklüğünü ise Development Team belirler. Takım ilk kurulduğunda PBI Size verme işlemi biraz uzun sürebilir ve Scrum Team, Sprint içinde Product Backlog Refinement yaparak PBI bazlı Size verme ve iş planlaması yaparak bir sonraki Sprint'ler için planlama işlerini kolaylaştırır. Product Backlog Refinement toplantısında öncelik PBI belirlemektir. Estimate başta verilmez fakat takım zaman kazanmak ve Size büyüklüğü verme becerisini geliştirmek için Estimate verme işlemini toplantının kalan kısmında verebilir. Product Backlog Refinement toplantısına genelde Product Owner ihtiyaç duyar. Amacı takımın önünü görmek ve ilerleyen Sprint'ler de işleri daha iyi planlamak içindir.

Scrum'da Sprint Retrospective Toplantısı

Scrum'da bir Sprint bittiğinde o Sprint üzerinde takımı daha da iyileştirmek ve aksiyonlar çıkarmak için toplanılan etkinliğe Sprint Retrospective toplantısı denir. Scrum Team'in kendini gözlemlemesi ve iyileştirmeler çıkarması için Sprint Retrospective toplantısı iyi bir fırsattır.

Sprint Retrospective toplantısı Sprint Review'dan sonra ve Sprint Planning'den önce yapılır. Toplantıyı Scrum Master organize eder. İki haftalık Sprint Retrospective toplantısının Time-Boxed süresi 1.5 saat bir aylık Sprint için 3 saattir.

Sprint Review (Sprint Değerlendirme) Toplantısı ve Püf Noktaları

Sprint Review, her Sprint sonunda çıkarılan Increment'ın sunulduğu yerdir. Scrum Team ve Paydaşlar(Stakeholders) Sprint'te yapılan işi görürler. Katılımcılar değeri en üst seviyeye çıkarmak adına ne yapabileceklerini belirlemek için işbirliği yaparlar.

Sprint Review gayri resmi bir toplantıdır ve Sprint durum tespit toplantısı değildir. Increment sunulmasının amacı Feedback(geri bildirim) almak ve işbirliğini artırmaktır. 2 haftalık Sprint için Sprint Review toplantısının Time-Box süresi 2 saattir, 1 aylık toplantının ise 4 saat ile sınırlıdır. Scrum Master herkese zaman sınır içerisinde kalmasını öğretir.

Professional Scrum Master I (PSM I) Sertifikası ve Sınav Hakkındaki Detaylar

Yazılım geliştirme metodolojisi Agile & Scrum'ın son zamanlarda popülerliği gittikçe artıyor. Bu artış ile birlikte Scrum'ın sertifikalarına ilgide hem Türkiye hemde dünyada oldukça artıyor. Scrum'ın en popüler sertifikalarından biri olan PSM I sertifikası nedir? nasıl alınır? ve sınav detayları hakkında birçok bilgiyi bu başlıkta yazmaya çalışacağım.

Professional Scrum Master I kısa adıyla PSM I sertifikası uluslar arası bir sertifika olup scrum.org üzerinden alınmaktadır. Sınav çoktan seçmeli 80 sorudan oluşmaktadır. Soruların bir kısmı Scrum Open Assessment'dan çekilip diğerleri Scrum soru havuzundan seçilmektedir. Sınavda aynı soruda birden fazla seçenek seçmenizi isteyebilir ve ne kadar seçeceğinizi soruda söylüyor. True/False ve tek şıklı sorularda gelmektedir. Sınav süresi 60 dakikadır ve Scrum.org'dan satın aldığınız şifreyi girdiğiniz an sınav başlamaktadır.

Sınav olurken tereddüt ettiğiniz sorular için Bookmark this question diyerek sınav sonunda bu sorulara tekrar dönebiliyorsunuz. Sınav ücreti 150 dolar olup Get Certified kısmından Online sınav şifresi alabilirsiniz. Aldığınız şifre hiçbir zaman Expire olmuyor, tek kullanımlık şifre olup sınava gireceğiniz zaman kullanabiliyorsunuz. Sınava hazır olduğunuzda Start Assessment kısmından şifrenizi girerek sınava başlayabilirsiniz.

Sprint Nedir? ve Bir Sprint'in İptal Edilmesi

Sprint 1 ay veya 2 haftalık süreli Time-Box'ı olan, içerisinde Definition of Done kriterlerini geçip Done olan ve potansiyel olarak yayınlanabilir bir Increment'in oluştuğu sürecin adına denir. Sprint'lerin süresi sabittir ve önceki Sprint biter bitmez bir sonraki başlar.

Burada ek olarak şunu diyebilirim. 2 haftalık Sprint koşmak bazen yorucu olabiliyor. Özellikle 2. haftanın sonu benim için daha yorgun bir gün olabiliyor. Her Sprint'in başlangıcı ve sonu yeni bir tempo, yeni bir plan ve yeniden başlangıç gibidir. Buna ayak uydurmanız ve bu kültüre adapte olmanız biraz zaman alabilir. Fakat işleri planlamak ve ufak parçalara bölerek görünür halde iş çıkarmak Scrum'ın en iyi durumlarından biridir.

Scrum Etkinlikleri Nelerdir? Scrum Events

Scrum çalışma metedolojisi içerisinde birçok uyguladığımız Scrum etkinlikleri vardır. Bu etkinlikler Scrum'da olmayan toplantı ihtiyacını asgari seviyeye düşürmek için kullanılır. Bu etkinlikler verimli zaman aralıklarını Development Team için oluşturup daha kaliteli çalışmasını sağlar. Etkinliklerin en önemli kriterlerinden biri Time-Boxed süreleridir.

Sprint başladığı zaman süresi 1 haftadır ve Sprint Review zamanı geldiğinde artık Sprint bitmiştir. Bundan dolayı Sprint süresi uzatılamaz, 2 veya 4 hafta şeklinde planlanıp koşulur. Aynı şekilde Daily Scrum'a da 15 dakika zaman ayrılmıştır. Scrum'daki etkinlikler şeffaflığı ve gözlemi mümkün kılmak için özel olarak tasarlanmıştır. Bu etkinlikleri aksatmak veya birini bile kullanmamak şeffaflığı azaltır. Scrum etkinliklerinden kısaca bahsetmek gerekirse;

Scrum'da Sprint Hedefinin Belirlenmesi: Sprint Goal

Scrum'da Sprint Planning yaparken Sprint hedefinin belirlenmesi en önemli kriterlerden biridir. Bu hedef bizim Sprint amacımızın temelini oluşturur ve adı Sprint Goal'dür. Sprint Goal bir veya birkaç PBI'dan oluşabilir ve Increment'e dönüştürülmesiyle ulaşılabilmektedir. Eğer Sprint Goal 2 veya 3 PBI'dan oluşuyorsa ve Sprint sonu tek bir PBI DoD kriterlerine göre Done olduysa Sprint Goal başarısız olmuştur.

Sprint hedefine ulaşma ve takımı tek bir Goal noktasına dedike etmek, Development Team'i farklı girişimlerde bulunmak yerine birlikte çalışmaya teşvik eder. Sprint Goal'ün durumu her gün Daily Scrum'da değerlendirilir ve takım üyeleri hedefe ulaşmak için ne yaptıklarını ve ne yapacaklarını konuşurlar. Takım çalışırken de Sprint Goal'ü aklından çıkarmaz.

Scrum'ın Günlük Planlama Toplantısı: Daily Scrum

Daily Scrum, Development Team üyelerinin her sabah 15 dakika toplanıp günü planladığı aktivitedir. Takım üyeleri dün ve gün içinde yapacağı işler hakkında birbirlerine bilgiler verir. Günlük Scrum toplantısında karmaşıklığı ve zaman kaybını azaltmak hatta minimuma indirmek için her gün aynı yer ve saatte Scrum Board önünde takım toplanır.

Toplantıda bir önceki gün yapılan işler gözlemlenir ve bir sonraki güne kadar yapılacak işler planlanır. Development Team üyeleri toplantıda şu soruları cevaplar;

* Takımın Sprint hedefine(Sprint Goal) ulaşması için dün ne yaptım?
* Takımın Sprint hedefine(Sprint Goal) ulaşması için bugün ne yapacağım?
* Benim veya Takımın Sprint hedefine(Sprint Goal) ulaşması için bir Impediment var mı?

Development Team, Sprint hedefini gerçekleştirmek ve Sprint boyunca nasıl gittiklerini görmek için Daily Scrum yapar. Sprint hedefine ulaşmak ve beklenen Increment'ı Sprint sonunda çıkarmak için birlikte Self-organize bir takım olarak nasıl çalışması gerektiğini anlamalıdır.

Scrum'da Efektif Sprint Planlama(Sprint Planning) Toplantısı Nasıl Yapılır?

Scrum'ın en önemli ve yönetilmesi zor etkinliği olan Sprint Planlama(Sprint Planning) toplantısı, Sprint içinde yapılacak işlerin planlandığı etkinliktir. Sprint planlama Scrum Team ile birlikte yapılır. Planlama toplantısının birinci kısmına Product Owner katılır, ikinci kısmına ise katılmak zorunda değildir ancak ulaşılabilir olmalıdır. Çünkü takım kapasite ve iş önceliğine göre alacağı PBI'lar da danışmak ve bilgi almak isteyebilir.

Sprint Planning, 4 haftalık Sprint için 8 saat, 2 haftalık Sprint için 4 saat ile sınırlıdır. Scrum Master, toplantının yapılmasını ve Development Team'in etkinliğin amacını anlamasını sağlar. Planlama toplantısı Time-Box süresini aşmamalıdır. Eğer takım bu süreyi aşıyorsa eski adıyla Grooming yeni adıyla Refinement(detaylandırma) toplantısı yapabilir. Bu sayede takım planlamada zaman kazanmış olur. Normalde Scrum'ın özünde bu etkinlik yoktur. Fakat takım tahminleme özelliğini daha da iyileştirmek için bu etkinliği yapar.

Planlamanın ilk kısmında PBI'lar Product Backlog'dan öncelik sırasına göre seçildikten sonra sonra Sprint Goal belirlenir ve çıkarılacak Increment netleşir. Planlamanın ikini kısmında ise PBI'lara Task verme ve işi detaylandırma aşamasına geçilebilir.

Scrum'da Development Team Büyüklüğü ve Başarılı Bir Takımın Genel Özellikleri

Scrum'da Development Team, Sprint sonunda istenilen ürünü Definition of Done (DoD) çerçevesinde Done yapan ve üretime geçebilecek seviyedeki o ürünü teslim etmekten sorumlu olan kişilerden oluşur.

Increment'ler(İş parçacığı) sadece Development Team tarafından geliştirilir. Development Team, kendi işlerini planlamak ve yönetmek için kurulmuş yapılardır. Ortaya çıkan sinerji, geliştirme takımının verimliliğini ve etkinliğini artırmaktadır.

Başarılı bir Development Team'in Özelliklerinden bahsedecek olursak;

PBI Kapasitesi Belirlemek ve Scrum Poker Kullanımı

Scrum çalışmasında rakamsal olarak değerlendirilmesi en zor olan nitel değerlerden biride PBI Size(Kapasite) belirleme işlemidir. Birçok takım tarafından birkaç Sprint sonrası ancak oturmaktadır.
PBI Size belirlemede en önemli kriterler ise o işin riskleri ve kompleksliği olup bu iki olasılık bizim kapasitemizi belirlememizi zorlaştırabilir ve işin büyüklüğü konusunda kesin bir şey söylememizi engeller.

Takımlar bir PBI'ın kapasitesini rakamsal olarak vermek istediklerinde referans alacağı noktalar şu şekildedir;

Kimdir Bu Scrum Master

Agile yazılım geliştirme metodolojisi için uygulanan Scrum yönteminde önemli role sahip olan Scrum Master kimdir ve görevleri nelerdir bunlardan bahsedeceğim. Scrum Master veya Türkçe adı ile Scrum Ustası, Scrum yönteminin anlaşılmasını ve takım içinde uygulamasını sağlamakla sorumlu kişidir. Bu sorumlulukları Scrum takımının Scrum kurallarını pratikte ve satrançta olduğu gibi kurallarına uyulmasını sağlayarak yerine getirir.

Satrançta kurallar bellidir. Scrum'da da öyledir. Siz bir kuralı çıkartamazsınız sadece var olan kurallara ek iyileştirmeler koyabilirsiniz. Scrum Master, takımın hizmetkar yöneticisidir. Buradaki yönetim kavramı hiyerarşi şeklinde olan bir yönetim algısı değildir. Scrum Master kişileri değil işi yönetir. Scrum Master, takımı ile olan ilişkisinin faydalı olup olmadığını anlamları için Scrum takımı dışındaki kişilere de yardım eder.