Kategori arşivi: AGILE

AGILE Devrimi

AGILE, Dünya üzerinde kabul görmüş bir yaklaşımdır. Birçok şirket bünyesinde bu yaklaşımı hayata geçirmeyi sürdürüyor. AGILE’ı bu kadar cazibeli yapan parametreler Çeviklik ve şeffaflık üzerinde yoğunlaşıyor.

CIO Update Dergisi 2019 Aralık sayısında bu yazım “AGILE Devrimi” yayınlanmıştır.

AGILE’ı bir metodoloji olarak ele alırsak eğer, bu metodoloji’nin ortaya çıkmasında rol oynayan sebepleri incelemek gerekir. 1980’li yıllarda bir ekip ile iş geliştirmek çok zordu. Ekip üyelerinin sayılarının artması ve müşteriden gelen taleplerin yığılması stresi de beraberinde getirmekteydi. Bir yazılım tasarımı ortaya çıkarabilmenin maliyeti çok yüksekti bunun sebebi ise gereksiz çok zaman harcanmasıydı. Memnuniyetsizlik, başarısız sonuçlar, kestirilemeyen problemler gibi birçok sebepten dolayı İş Geliştirme Yöntemi önemli bir konu haline geldi. Firmalar Zaman/Maliyet hesaplamalarını Gantt şeması üzerinden planlıyor ve  WaterFall yöntemi ile iş akışlarını belirleyip projeye start veriyordu. Bende meslek hayatımın ilk yıllarında birkaç kez Gantt şemasını kullanan firmalarda görev almıştım fakat başarıyı tam yakalama gibi bir durum söz konusu olmadı.

Talep edilen bir geliştirmenin birkaç ay gibi bir süre sonunda müşteriye henüz gösterilmemiş olması hem müşterinin hem de proje ekibinin motivasyon kaybına sebep olabilir. Müşterinin talep ettiği geliştirmeleri bir yöntem uygulamadan geliştirme sürecine dahil etmek de yığılma sorunları ve hata çözümleme süreçlerinin iflas etmesine sebep olabilir.

AGILE tamda bu noktada devreye giriyor. AGILE Yaklaşımı projenin başarılı bir şekilde tamamlanması veya yürütülmesi için yöntemler sunuyor. Taleplerin hızlı bir şekilde çözümlenmesi ve müşteriye sunulması AGILE’ın en önemli çıktısıdır.

AGILE’ı  diğer tüm yaklaşımlardan ayıran özellik Iteration’dır. Iteration bir görevi defalarca kez bir yöntem üzerinden uygulamayı gösterir. Projenin ufak parçalara bölünmesi ve her bir parçayı development sürecine dahil ederek Planlama, Tasarım, Test ve Onay gibi adımlardan geçip bir başka Iteration’un tamamlanmasını beklemek, parçaların çevik bir şekilde tamamlanmasını sağlamaktadır.

Scrum Yaklaşımı

Scrum, AGILE’ın bir framework’üdür.  AGILE temelde benzer yapılara sahip olduğu alt kollara sahiptir. Scrum’da bu kollardan biridir. Scrum Süreç olarak 3 temel prensip üzerine kuruludur. Bunlar;

  • Şeffaf Olmak
  • Kontrol Etmek
  • Değişime Açıklık

Proje sürecinin, problemlerin, geliştirmelerin açık ve net olarak herkes tarafından görülebilir olması gerekir. Scrum’ın en belirgin çıktısı şeffaf olarak yürütülen süreç içerisinde oluşan aksaklıkların net bir şekilde açığa çıkmasıdır. Bir problem var ise anında o noktaya çözüm uygulanıp sürecin kesintiye uğramasına engel olur ve süreci sürekli olarak iyileştirme yönünde takımın motivesini sağlar.

Proje, geliştirme süresince sürekli bir değişim talebi alabilir. Projenin sonunda dahi değişiklik talebi kabul edilebilir olmaktadır. Bir bütün olarak çözüme gidilmediği için küçük parçalar halinde çevik bir şekilde çözüm sağlanmaktadır. Alınan talepler küçük parçalara bölünerek bir sıralama mekanizmasına eklenir ve burada planlama aşamasını bekler.

Proje geliştirme sürecinde ekip içerisinde kopukluklar en aza indirilir. Günlük Scrum Event’ı ekibin sürekli iletişim halinde kalmasını sağlar.  Scrum Event’larının süresi yapılan araştırmalar sonucunda 10-15  dakika olarak tavsiye edilmektedir. Nedeni ise ekip içi iletişimi sağlamlaştırmak isterken, bir anda tam tersi bir durumla karşılaşmamanız. Bu süre deneyleyerek belirlenebilir. Ekip içi yapılan Event’lar ile projenin takvim üzerinde nerede olduğunu, hangi noktalarda tıkanıklığın olduğunu ve çözümün daha başarılı sonuçlar ile geldiğini görebilmekteyiz.

Scrum Takımı; Geliştirme Takımı, Ürün Sahibi ve Scrum Master’dan oluşmaktadır. Yöntemsel olarak farklı ekiplerin işleyişine müdahale edilmesi mümkün olmamaktadır. Scrum Takımı işleri başarılı çözüme ulaştırmak için yöntemleri kendi aralarında kararlaştırabilirler.  Ürünün İterasyon ile parça parça tamamlanması yani “Done” olması, hali hazırda bekleyen başarılı ve onaylanmış teslim edilebilir ve feedback alınabilir hale gelmesini sağlamaktadır.

Ürün Sahibi yani Product Owner ürünün değerini yüksek tutmakla sorumludur. Geliştirme takımı da Product Owner dışında kimseden iş alamaz/talep edemez/kabul edemez. Ürün listesi Product Backlog listesinde Product Owner tarafından yönetilir.

Geliştirme Takımına ürünü teknik olarak nasıl geliştireceğini hiç kimse söyleyemez. Geliştirme takımı profesyonellerden oluşmaktadır. Ürünleri geliştirmek için gereken tüm becerilere sahiptir. Scrum, Geliştirme Takımı içerisinde geliştiriciden başka hiçbir unvanı tanımaz. Takım Lideri/Teknik Lider ancak bir geliştirici üye olarak dahil olabilir.

Sprint,  Scrum sürecinin en temel yapı taşıdır.  Tüm süreç aktiviteleri Sprint içerisinde gerçekleşir. Scrum süreci 1 ayı geçmeksizin birbirini ardı ardına takip eden Sprint’lerden oluşmaktadır.  Scrum planlama event’larında belirlenen işleri ekiplerin tamamlaması için küçük parçalar halinde ekip üyelerine aktarılır ve Sprint süresi boyunca bu işlerin takibi yapılır.

Çoğunlukla 2 haftalık Sprint’ler planlanmaktadır. Sprint öncesi, sonrası ve ortasında farklı event’lar yapılması Sprint’in başarılı bir şekilde tamamlanmasını olumlu yönde etkilemektedir.

Sprintler; Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum’dan oluşmaktadır.

Sprint boyunca, hedefi tehlikeye sokacak değişiklikler sürece dahil edilmez, değişiklikler bazı event’lar yapılarak enjekte edilebilir fakat bunun dikkatli bir çalışma ile yapılması gerekmektedir.

Scrum Master, takımına süreç boyunca destek vermelidir. Sprint’in günlük 8 saatle sınırlı planlaması yapılır ve bu sürenin aşılmaması konusunda ekip üyelerine bilgi aktarılır.

Sprint Review, Sprint tamamlandıktan sonra gerçekleşecek olan bu event’ın ana konusu; sorun var ise bunu anlamak ve çözüm için bir sonraki Sprint’e bilinçli yaklaşmak, takım içi iş birliğinin güçlendirilmesi olarak düşünülebilir.

Sprint Review’a Product Owner, Paydaşlar ve Scrum Takımı katılır. Bu ritüelin öncesinde bir Daily Scrum ile hangi noktada olunduğu görülebilir.  Done ve UnDone PBI(Product Backlog Item)’lar belirlenerek Sprint Review sunumu hazırlanır. Sprint süresine göre event’ın süresi de ortaya çıkabilmektedir. 2 haftalık bir Sprint için maksimum 2 saat tavsiye edilir.

Sprint Planning, Bir sonraki Sprint için yapılan planlar bu event içerisinde belirlenir. Sprint içerisinde çözülecek işlerin miktarını geliştirme takımı belirler ve bu işler planlamaya alındıktan sonra Sprint Backlog’ta tutulur.

Sprint Retrospective,Sprint süresince ve ya iş akışı üzerinden takım içi ilişkiler, kişiler, kısaca bir çok etken üzerinden değerlendirme yapılan, daha iyiye ulaşmak için sorunların ve çözümlerin tartışıldığı event’dır. Herşeyin iyi gitmesi ve sorunsuz bir süreç yakalamak yeterli gibi görünse de sürekli geliştir ve her zaman daha iyiye git kuralını unutmamak gerekiyor. Bu kurala Kaizen denilmektedir.

Daily Scrum, Günlük yapılan Scrum event’ları genellikle ekip içi sorulara cevap aramak/iş hakkında bilgi paylaşımı için yapılır. 15 dakika bu event için tavsiye edilen süredir.

Günlük yapılan event’lar takımın Sprint hedefini gerçekleştirme ihtimalini olumlu yönde etkiler. Çünkü her gün işler üzerinde ki pürüzler var ise tartışılır ve o pürüzleri ortadan kaldırmak üzere aksiyon alınır. Bu şekilde ilerlemenin önü kesilmemiş olur.

  • Dün ne yaptım?
  • Bugün ne yapacağım?
  • Takıldığım bir nokta var mı?

Kaizen, japoncada “Kai” ve “Zen” kelimelerini birleşmesi ile bir anlam ifade etmektedir. Değişim ve Daha İyi kelime öbeğini barındıran bu ifade “Sürekli İyileştirme” anlamına gelir. Sonuçların daha iyi olabilmesi için Takım elemanları Kaizen için süreç içerisinde çok  önemli bir noktadadır. Bu nedenle takım işleyişi çok önemlidir ve sürekli iyileştirilmesi gereken bir yapıdır.

Sorunların çözümü için farklı görevler üstlenen ekipler kurarak  temelden çözümlerin üretilmesi hedeflenmiştir.  Kaizen’in temelinde süreç odaklı iyileştirme olduğu için sonuca bakılmaksızın sürekli sürecin iyileştirilmesi başarı getirmektedir.

Sürekli iyileştirme kavramının temelinde, her gün bir önceki günden daha iyi olma hedefi yatmaktadır. Kaizen, istek ve potansiyel enerji ile başlayan projelerin motivasyon kaybı, erteleme ve vazgeçme gibi durumlara karşı gelişen bir felsefe olduğu için, ufak adımlarla geniş çaplı değişimleri hedeflemektedir. Ufak adımlar takım’ın alışkanlıklara karşı göstermiş olduğu direnci ortadan kaldırmaktadır.

KANBAN

Kanban, 1940’larda iş akışlarını daha iyi hale getirmek için geliştirilmiştir. Japonca’da Kanban kelimesi, Tahta ve tabela gibi anlamlara gelmektedir. Kanban kaynakları daha verimli ve daha yönetilebilir halde kullanabilmek için çözümler sunmaktadır. Kanban’ında Scrum gibi özünde çeviklik ve şeffaflık vardır.

Önceden planlanan ritüel’leri bulunmamakla beraber alınan aksiyonlar gelişmelere göre şekillenmektedir. Lead Time ve Cycle Time terimleri ifade edilen planlamalar yapılabilmektedir. Bir talep geldiği andan itibaren çözülüp tamamlanma sürecine kadar geçen süreye Lead Time denilmektedir. Örnek olarak, canlı ortamda bir hatanın farkına varılmasıyla başlayan sürecin o hatanın çözüldüğü zamana kadar geçen süre olarak düşünebiliriz.

Lead Time daha çok müşteri tarafını ilgilendiren bir durum olarak karşımıza çıkmaktadır. Cycle Time ise talebin geliştirme aşamasından itibaren sürecin başlamasıdır. Geliştirme aşaması Cycle Time ile başlamaktadır.  Geliştirme tamamlandığında Lead Time ve Cycle Time tamamlanmış olur.

Kanban’ın hedeflerinden birisi ise Lead Time’ı düşürmektir. Bu şekilde daha çevik dönüşler yapılabilmektedir.

Kanban temelde prensipleri Sınırlandırmak ve Görselleştirmek üzere iki ana madde üzerinden çalışmaktadır. İşlerin görselleştirilmesi bir Board üzerinde takip edilebilir olmasıdır. Board üzerinde Taleplerin başlama adımı ile tamamlanma adımları arasında bir süreç takip edilir. Bu süreç New, ToDo, In Progress, Test, Done olarak düşünülebilir. İşler bu board üzerinde soldan sağa doğru ilerlemektedir.

Sınırlandırma ise süreç içerisinde bulunan adımların paralelde maksimum kaç iş barındırılabileceğidir. Kanban buna WIP(Work in Process) adını vermiştir.  Geliştirici sayısı ve bekleyen iş sayısı WIP sayısını belirleyebilir. WIP’in Lead Time’ın düşmesinde etkisi büyüktür. İşlerin daha kaliteli çıktılar vermesi muhtemel sonuçlardan birisi olarak görülebilir.

Scrum ile Kanban’ın bazı farklılıkları bulunmaktadır. Scrum, geliştirme için bir zaman limiti uygular, yani geliştirme Sprint içerisinde devam eder ve tamamlandığında yeni bir Sprint planlanarak yeniden başlanır. Kanban’da ise geliştirme sürekli olarak devam eder. İş geldikçe çözülüp tamamlanır. Limit belirlemek opsiyonel olarak kullanılabilir bir yöntemdir.

Kanban’da Event’lar bulunmamaktadır. Aksiyon’lar süreç içerisinde ki gelişmeler göre alınır. Scrum’da ise Sprint Planlama, Sprint Retrospective gibi Event’lar bulunmaktadır. Bu şekilde tüm süreç takip edilerek aksiyon planlamaları yapılmaktadır.

Scrum’da iş maddelerinin küçük parçalara bölünmesi kuralı bulunmaktadır. Bu sayede çeviklik sağlanır. Kanban’da ise bunun bir kısıtlaması bulunmamaktadır. Yapılacak işlerin büyüklüğü veya küçüklüğü opsiyonel bırakılmıştır.

Scrum için bazı Roller bulunmaktadır. Product Owner, Scrum Master, Geliştirme Takımı gibi, Kanban’da bu roller belirlenmemiştir.

Kanban Board müsait oldukça yeni işler eklenebilir. Geliştirme ekibi sürekli board üzerinde bekleyen iş görebilir. Geliştirme sürekli devam eder ve işlerin akışının kesilmemesi sağlanır. Scrum’da ise Sprint’e yeni bir iş eklenemez. Bunun nedeni, Scrum Takımı sürekli olarak kısa hedefler koyar. Her hedefe ulaştığında bir inceleme yapar ve daha iyi sonuçlar elde etmek için kararlar alır. Kanban’da kısa vadede konulan hedefler yoktur.

Scrum Board’ı her Sprint’te yeniden düzenlenir. Kanban Board ise kalıcı olarak sürecine devam eder. İşler sürekli akış içerisindedir.

Tabi bunun yanı sıra bazı benzerlikleride bulunmaktadır. Scrum ve Kanban’ın temelinde çeviklik vardır. Her ikisinde de bazı kısıtlamalar vardır. Scrum bunu Sprint ile yapıyor, Kanban ise WIP(Work in Process).