Waterfall,Scrum, Kanban ya da Hiçbiri!

Sanki bir sabah herkes uyandı ve “Hadi Agile Dönüşüm yapalım” dedi!

Yazılım geliştirme ekipleri uzun yıllardır geleneksel yöntem olarak adlandırdığımız waterfall modeliyle yazılımlarını geliştirmekte.Bu yöntemde projenin erken safhalarında gereksinimler toplanır,nihai hale gelir ve tasarım,geliştirme süreçleri tamamlanmış gereksinimler üzerinden yapılır. Ancak internetin yaygınlaşması,tüketim hızının aşırı artması neticesinde firmaların time-to-market dediğimiz pazara çıkış hızlarını artırması gerekti.

Bu da özellikle proje ekiplerini geleneksel yöntemden uzaklaşarak Agile yani Çevik-Atik yöntemlere yöneltti.

İşte bu noktada On yedi yazılım gurusu 2001 yılında Amerika’nın Utah eyaletinde bir araya gelip yazılım geliştirme ile alakalı 2 günlük bir beyin fırtınası yaptılar. Toplantının amacı yazılım geliştirme üretkenliğini arttırmak, bu doğrultuda da farklı tecrübe ve yaklaşımları değerlendirmekti. Toplantı sonucunda fikir birliğine varılan ve toplantının bir çıktısı sayılabilecek 4 maddelik bir değerler topluluğunu Agile-Çevik Yazılım Geliştirme Manifestosu ismi ile yayınladılar.Bu manifesto’da şunu dediler;

• “Süreçler ve araçlardan ziyade bireyler ve aralarındaki etkileşimlere

• Kapsamlı dökümantasyondan ziyade çalışan yazılıma

• Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine

• Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye değer vermeye kanaat getirdik.

Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız. “

Peki bu 4 maddelik önerge daha da iyileştirilemez mi? Mesela şöyle;

• Bireyler ve aralarındaki ilişkiden ziyade takım işi çıkar

• Çalışan yazılımdan ziyade değer üret

• Müşteri ile işbirliğinden ziyade ortaklık geliştir

• Değişime karşılık vermekten ziyade onu içselleştir

İşte bu manifesto üzerine 17 kişilik bu vizyoner ekibin içerisinde yer alan Ken Schwaber ve Jeff Sutherland yazılım geliştirme dünyamıza güneş gibi doğan Scrum yöntemini geliştirdiler.

Kimi ekipler Scrum’a aşık olurken kimileri de Kanban olmadan asla olmaz der hale geldi. Kimileri Scrumban,XP başka yöntemler üzerinden ilerledi.

Peki acaba hangi yöntem sizin için doğru? Bir yönteme sıkı sıkıya bağlanmak mı yoksa hepsinin iyi yönlerinden faydalanıp kendinize özgü yöntemi mi geliştirmek mi doğru? Veya yöntemsizlik mi doğru? Öncelikle şu videoya bakalım (1) ;

İşler yağmaya başladığında bir metodunuz olmazsa…

Şimdi kısaca Scrum nedir, ne katkı sağlar buna bakalım;

SCRUM

Scrum simple(2)

Özetle Scrum;

• Organizasyonunuzu, küçük, çapraz fonksiyonel ve kendi kendini yöneten takımlara bölün

• İşlerinizi, küçük ve somut teslimlerden oluşan maddelere bölün.

• Zamanınızı, kısa, sabit uzunlukta-genellikle 1–4 hafta arasında- döngülere bölün. Döngüler sonrasında geliştirdiğiniz ve müşterinize gösterdiğiniz özellikleri teslim edin.

• Teslim Planını en iyi hale getirin. Müşterinizle işbirliği yaparak önceliklerinizi sürekli güncel tutun. Bunu yaparken her döngü sonrası yaptığınız teslimlerden kazandığınız tecrübeden yararlanın. Teslimlerinizi gözlemleyin ve bir sonraki tesliminizde bu gözlemlerden yararlanın.

• Yani büyük bir grup halinde çok uzun süre harcayarak büyük bir şey –proje, ürün- geliştirmek yerine küçük bir takım halinde kısa süre harcayarak küçük bir şey-proje, ürün- geliştirin.

• Fakat düzenli olarak önceki geliştirdiklerinizle entegre etmeyi unutmayın! (3)

Scrum’ın 3 önemli sacayağı vardır. Bunlar;

• Şeffaflık

• Gözetleme

• Adaptasyon

Bunları sağlamak için çeşitli roller,etkinlikler ve araçlar vardır. Çok kısa değinecek olursak;

Roller;

Product Owner;

· Ürünün özelliklerini,gereksinimlerini tanımlar

· Çıkan ürünün ne zaman devreye alınacağına karar verir

· İşleri önceliklendirir

· Çıkan ürünü kabul eder ya da reddeder

Scrum Master;

· Scrum değerlerinin gözetilmesinden sorumludur

· Takımın karşısına çıkan engelleri yok eder

· Takımın tümüyle üretken olduğundan emin olur

· Takımı dış etkilerden korur

Takım;

· Cross-functional;Yazılım,test,analiz uzmanları

· Üyeler full dedike olmalı

· Kimsenin birbirine üstünlüğü yok

· Sprint bitmeden takımdan kimse ayrılamaz

· Max 9 kişi

Özetle roller;

Etkinlikler;

· Sprint;

· Bir ay veya daha az

· Önceki Sprint biter bitmez yeni Sprint başlar.

· ““Bitti” durumunda, kullanılabilir ve potansiyel olarak yayınlanabilir bir Ürün Parçasının oluşturulur.

· Sprintler; Sprint Planlama, Günlük Scrumlar, geliştirme işi, Sprint Değerlendirme ve Sprint Retrospektifinden oluşur.

· Sprint Planlama Toplantısı;

· Her sprint öncesi max 8 saat

· Tüm Scrum Takımı katılır

· Sprint Planlama şu sorulara cevap verir: Başlayan Sprintte Ürün Parçası olarak ne teslim edilebilir? Ürün Parçasını teslim etmek için gerekli olan iş nasıl başarılacak?

· Çıktıları;Sprint Hedefi ve Sprint Planıdır

· Günlük Scrum;

· Her Gün

· 15 dakika

· Ayakta

· Problem çözüm yeri değil

· Geliştirme takımı toplantının sahibi

· Başka toplantılar yapılmasını engeller

· 3 soruya yanıt aranır;Dün ne yaptın? Bugün ne yapacaksın? Herşey yolunda mı?

· Sprint Review;

· Takım sprintte ne geliştirdiğini müşteriye sunar.

· Herkes davetlidir.

· Aylık sprint için 4 saat ile sınırlıdır. Daha azı için daha az sürelidir.

· Ürün Sahibi, Ürün İş Listesi kalemlerinden hangilerinin “Bitti” olup olmadığını açıklar

· Geliştirme Takımı Sprint boyunca neyin iyi gittiğini, hangi sorunlarla karşılaştığını ve bu sorunları nasıl çözdüğünü tartışır.

· Çıktısı güncellenmiş Product Backlogdur.

· Sprint Retrospective;

· Takımın kendi kendini sorgulayacağı toplantıdır.

· Aylık sprint için 3 saat ile sınırlıdır.

· Her sprintin sonunda yapılmalıdır.

· Tüm takım katılır.

· Müşteri katılamaz.

Araçlar;

· Product Backlog;

· Ürünün tüm gereksinimlerini içerir

· PO tarafından önceliklendirmesi yapılır

· Her sprintin başında tekrar öncelilendirme yapılır

· PO sahibidir

· Sprint Backlog;

· Product backlogun sprint için seçilmiş parçasıdır

· Sprintin başarıyla teslimi için plan içerir

· Geliştirme takımı sahibidir

· Ürün Parçası-Increment;

· Bir Sprint boyunca tamamlanan Ürün İş Listesi kalemlerinin ve tüm geçmiş Sprintlerin Ürün Parçalarının değerlerinin toplamıdır

· Sprintin sonunda, yeni Ürün Parçası “Bitti” olmalıdır yani kullanılabilir durumda olmalı ve Scrum Takımının “Bitti” tanımına uymalıdır.

Bu yukarıda verdiğim bilgiler hemen hemen her yerde ulaşabileceğiniz bilgiler. Peki bu bilgiler ışığında Scrum bizim için doğru yöntem mi? Bunun için Henrik Kniberg & Mattias Skarin’in Kanban and Scrum making the most of both kitabından çok sevdiğim bir diyaloğu aşağıda paylaşıyorum(4);

Jim: “Sonunda hepimiz Scrum yapıyoruz!”

Fred: “Eee nasıl gidiyor?”

Jim: “Yani daha önce yaptığımızdan daha iyi…”

Fred: “…ama?”

Jim: “…ama biz bir destek ve bakım takımıyız.”

Fred: “Evet ve?”

Jim: “Pekâlâ, Ürün İş Listesi’nde öncelikleri belirlemeyi, kendi kendini yöneten takımları, Günlük Scrum’ları ve retrospektifleri vb. sevdik.”

Fred: “Eee ne güzel, problem nerede?”

Jim: “Sprint’lerde başarısız olmaya devam ediyoruz.”

Fred: “Neden?”

Jim: “Çünkü 2 haftalık planlara taahhüt vermemiz zor. İterasyonlar bizim için çok bir şey ifade etmiyor. Bugün en acil konu neyse biz ona çalışıyoruz. Acaba 1 haftalık iterasyonlar mı yapmalıyız?”

Fred: “1 haftalık işlere taahhüt verebilir misiniz? Huzur içinde 1 hafta odaklanmanıza ve çalışmanıza izin verecekler mi?”

Jim: “Pek sanmıyorum. Her gün farklı bir konu ortaya çıkıyor. Belki de 1 günlük Sprint’ler yapmalıyız…”

Fred: “Problemleriniz 1 günden daha kısa zamanda çözülüyor mu?”

Jim: “Hayır, bazen günlerce sürenler oluyor.”

Fred: “Yani 1 günlük Sprint’ler de sizin için uygun değil. Hiç Sprint koşmamayı düşündünüz mü?”

Jim: “Açıkçası evet, bu hoşumuza giderdi. Fakat Scrum buna karşı değil mi?”

Fred: “Scrum sadece bir araç, ne zaman ve nasıl kullanacağını sen belirlersin. Scrum’ın kölesi olmaya gerek yok!”

Jim: “Ne yapmalıyız?”

Fred: “Kanban’ı duydun mu?”

Jim:…..

Hadi gelin o zaman biraz da Kanban’a kulak kabartalım.

KANBAN

( Japon dilinde pano, tabela ya da işaret veren tahta anlamına gelen kelime)

Kanban, tam zamanında Üretim ortamında malzeme hareketlerinin kontrolü amacıyla kullanılan bir çizelgeleme yaklaşımıdır. Toyota’nın üretim verimliliğini artırmak amacıyla aynı zamanda Lean Production (Yalım Üretim)’un da mucidi olan Taiichi Ohno tarafından geliştirilmiştir. Yöntem 1953'ten bu yana kullanılmaktadır.(5)

Kanban, 2000’li yılların başlarında ilk kez David J. Anderson tarafından uygulanan, karakteristik özelliklerini Yalın Üretim (Lean Production) ilkerinden (özellikle Taiichi Ohno’nun 1953 yılında Toyota’da uygulamaya başladığı yalın üretim metodu kanbandan) alan ve Kısıtlar Teorisi (Theory of Constraints) yanında Sistemsel Düşünme (Systems Thinking) gibi sistemik optimize yaklaşımlarını barındıran evrimsel bir metodolojidir.(6)

Peki bu metodu projelerimizde nasıl uygulayabiliriz?

Aşağıdaki 4 madde Kanban için kritik öneme sahiptir;

· İş akışınızı görselleştirin; İşi küçük parçalara bölün, her küçük parçayı bir karta yazın ve bu kartları bir duvara yapıştırın.Kendinize özgü kolonlar yapın ve işlerinizi bu kolonlara taşıyın

· WIP(Work In Progress) Limiti koyun;Aynı anda kaç iş alıp işleyebileceğinizi belirleyin ve bu sınırın dışına çıkmayın. Bu iş bitmeden başka iş almayın.WIP belirleme Kanban metodunda çok önemli yere sahiptir.Ancak olgunluğa erişene kadar sürekli değişerek geliştirilmelidir.

· Lead Time (Teslim Süresi Ölçümü);Bir parça işin ne kadar sürede teslim edilebileceğini tahminleyin.Bu sürenin ölçümü deneyseldir.Sürekli iyileştirilebilir.Ve bu süreye göre WIP limitinizi de iyileştirmiş olacaksınız.

· Sürekli İyileştirme;Özünü KAIZEN(kai:değişim,zen:daha iyi)’den alan bu yöntem ile üretim ve geliştirme hattınızdaki tıkanıklık yaratan noktaları ortaya çıkararak sürekli iyileştirmeye gidin.

Peki bu maddeleri yazılım geliştirme projelerimizde nasıl uygularız? İşte bunun için ;

Kanban ile bir gün nasıl geçer ?(7)

Görüldüğü gibi 8 kalem iş var ve WIP limiti olarak 2(Kodlama) verilmiş

Product Backlog içerisinden refine edilmiş 2 adet iş seçiliyor ve kuyruğa alınıyor

Geliştiriciler önceliklendirilmiş 2 adet işi kuyruktan çekiyor ve geliştirmeye başlıyor.Bu sırada Product Owner(Kanban’da böyle bir rol yoktur ancak kullanabilirsiniz) sıradaki iki işi kuyruğa alıyor.

Geliştiriciler A işinin geliştirmesini yapıyor.Ancak bu işi deploy ekibine teslim edene kadar hala iş Kodlama sütununda kalıyor.Bu arada Product Backlog’a yeni işler geliyor.

A işi Deploy adımına geçtiği için geliştiriciler kuyruktan 1 adet daha iş aldılar.

Geliştiriciler B işini de tamamladılar. Bu arada A işinin deployunda bir problem çıktı.

Geliştiriciler B işini bitirdi ancak A işi deploy edilemediği için B içi deploy adımına geçirilemiyor.Yani sıkışma yaşandı. Bu durumda geliştiriciler yeni bir iş kalemini alamazlar ta ki B işi Deploy adımına geçirilene kadar.

Geliştirme ekibi tıkanan üretim hattını açmak üzere Deploy ekibinin yardımına koşuyor.Bu arada Product owner Kuyruğa yeni iş alıyor.

Hem B hem de C işi bitti ancak deploy adımına geçirilemiyor.Product Owner Pazar baskısıyla yeni iş kalemlerinin geliştirilmeye başlamasını bekliyor ancak ekip A işini deploy edemeden yeni iş alamıyor.

Tüm geliştirme ekibi yeni iş alamadığı için mevcut sorunun giderilmesi için Deploy ekibine yardım etmek istiyor.Bu aşamada Deploy ekibi Sürekli İyileştirme prensibi gereği önemli bir geri bildirim vererek böyle hataların tekrarlanmaması için Birim Testlerinin yazılması gerektiğini söylüyor.Bu arada Product Owner başta belirledikleri WIP limitinin kendisini zorladığının farkına varıyor.

Teknik adamlar teknik olmayan adamların işlerine karışmalarını pek sevmez ;)

Ekip 2 olan WIP limitini 3’e çıkardı.Bu şekilde akış devam edebilir.

Yukarıda yaşanan örnekte ekip bir kanban board oluşturdu,WIP limiti belirledi ve işleri yapmaya başladı. Üretim sırasında yaşanan sorunlardan ders alarak Birim Testleri yazmaya başladı ve WIP limitinde değişikliğe gitti.

Bu şekilde sürekli iyileştirme yapılmış oldu.

Scrum güzel,Kanban güzel! Peki bu iki metodun birbirinden farkı nedir?

Roller;

· Scrum’da belirli roller vardır.Kanban’da yoktur.

· Ancak olmaması olmayacağı anlamına gelmez. İstenirse Kanban’da da roller kullanılabilir.

· Rol eklerken dikkatli olmalısınız, yeni eklenen rolün gerçekten değer katacağından emin olmalısınız

İterasyon;

· Scrum’da Döngülerin Süresi Sabittir.

· Kanban’da süresi sınırlı döngüler zorunlu değildir. Planlamayı, süreç geliştirmeyi ve teslimi ne zaman yapmanız gerektiğini kendiniz seçebilirsiniz.

· Kanban’da bu aktiviteleri tekrar eden bir şekilde yapmayı da seçebilirsiniz. Örneğin her Pazartesi teslim yapabilirsiniz ya da bir ürün parçacığı tamamlandığında hemen teslim edebilirsiniz.

Sınırlandırma;

· Kanban, Çalışılan İşleri İş Akışındaki Adımlara Göre, Scrum, Çalışılan İşleri Döngü Bazında Sınırlandırır

Deneysellik;

· Scrum der ki; çapraz fonksiyonel takımlarınız olmalıdır.

-Kim, hangi takımda olmalı? Bunu söylemez, deney yapmalısınız.

· Scrum der ki; Takım bir Sprint’e alınacak işlerin miktarını belirler.

- Takım bir Sprint’e ne kadar iş almalı? Bunu söylemez, deney yapmalısınız.

· Kanban der ki; Çalışılan İşleri sınırlamalısınız.

- Limit ne olmalı? Bunu söylemez, deney yapmalısınız.

Geri Bildirim;

· Her ikisi de geribildirim esasına dayanır

Geri bildirim safhaları. En iç halkada yer alan pair programming ile sorunlar en erken aşamada bulunur.İçten dışa doğru sorunu bulma zamanı artar

Değişiklik Yönetimi;

· Scrum, Sprint İçindeki Değişikliklere Karşıdır

Diyelim ki yukarıdaki gibi bir Scrum Duvarımız var ve biri E maddesini eklemek isterse ne olur? Scrum Takımı şöyle bir şey söyler;“Kusura bakmayın. Bu Sprint’te A+B+C+D maddelerini taahhüt ettik. E’yi Ürün İş Listesi’ne ekleyebilirsiniz. Eğer Ürün Sahibi bunun öncelikli bir madde olduğunu düşünür ve önceliğini artırırsa önümüzdeki Sprint içeri alabiliriz”.

· Kanban değişikliklere açıktır.

Peki, bu soruya Kanban Takımı ne cevap verirdi?;”E maddesini “Yapılacak” işler kolonuna ekleyebilirsin. Fakat bu kolonun limiti 2 bu nedenle C veya D’yi bu kolondan çıkarman gerekiyor. Şuan A ve B maddeleri üzerinde çalışıyoruz. Bunlardan biri biter bitmez “Yapılacak” işler kolonunun en üstündeki maddeyi çekeceğiz.”

Board;

Scrum Duvarı her Sprint de Yeniden Oluşturulur

Kanban’da ise duvar kalıcıdır.

Teslim;

Scrum’da İş Maddeleri Bir Sprint’e Sığmak Zorundadır.

Kanban’da değildir.

Bu kadar bilgi iyi güzel de neyi seçmeli? Hangi yöntem ile ilerlemeli? Yoksa eski tas eski hamam devam mı etmeli?

İşte bu sorunun cevabı sizde. İş yapış şeklinizi masaya yatırmanız lazım. Sprintler uygulayıp sprint dışında iş almayayım diyebilecek misiniz? Günlük gelen rutin bakım tasklarınızı sprintler ile ele alabilecek misiniz? Tamamen yeni projeler mi geliştiriyorsunuz yoksa bakım tasklarına mı boğuldunuz yoksa ikisi de mi geliyor?

Kendi uyguladığım yöntemden örnek vermek gerekirse;

Şimdiye kadar çalıştığım yerlerde geliştirme ekipleri bir yandan yeni projeler geliştirirken bir yandan da günlük bakım taskları ile ilgilenmeleri gerekiyordu.Bunun için yukarıda bahsettiğim iki yöntemin de nimetlerinden faydalanmak adına yazılım geliştirme ekibini ikiye bölmenin ve bir ekibiniz ile Scrum diğer ekibiniz ile Kanban uygulamanın daha uygun olduğunu düşündüm.

Örneğin 15 kişilik bir yazılım geliştirme ekibiniz var. Bu ekibinizi bakım tasklarına veya belirsiz projeleri mi yoksa daha belirli,sprinte alabileceğiniz geliştirmelere ayırdığınız süre ye göre bölümlendirebilirsiniz. 8 kişilik ekibinizi Scrum ekibi olarak konumlandırıp 7 kişilik ekibinizi de Kanban ekibi olarak ayırabilirsiniz.

Her iki ekibin de mevcut metodoljiyi düzenli ve verimli olarak uyguladığını denetlemek adına bir kişiyi Scrum Master ve Kanban Master olarak belirleyebilirsiniz. Yine aynı şekilde tek Product Owner ile iş önceliklerinizi takip edebilirsiniz.

Burada önemli olan kullandığınız Board’ın ayrı olması. Çünkü Scrum’da sprint esaslı iş takip edecek, Kanban’da ise WIP limiti ile akışınızı takip edeceksiniz.

Bu esneklik sayesinde Scrum uygularken acil olarak gelen bir geliştirme kalemini Kanban ekibine havale ederek time to market’i yakalamış , müşteri tatminini üst düzeyde tutmuş olursunuz.

Özetle;Ekibinizin, şirketinizin, müşterinizin, sektörünüzün gereksinimlerini tam olarak kavramadan “Hadi Scrum uygulayalım!” Veya “Hadi Kanban uygulayalım!” demeniz hem çalışan,hem de müşteri memnuniyetsizliğine yol açarken üretimde verimsizlik,aksaklık gibi olumsuz sonuçlara gebe olacaktır.

İyisi mi siz de bir sabah uyanıp “Hadi Agile Dönüşüm Yapalım!” diyecek olursanız uykunuzu hiç bölmeyin. Organizasyonunuz için böylesi daha iyi olur. 😉

Kaynakça;

1-https://www.youtube.com/watch?v=Jm1VEO9C4VQ

2-https://www.scruminc.com/the-3-5-3-of-scrum/

3-www.mountaingoatsoftware.com/scrum

4-http://www.agileinnovation.eu/wordpress/wp-content/uploads/2010/09/KanbanAndScrum_MakingTheMostOfBoth.pdf

5-https://tr.wikipedia.org/wiki/Kanban

6-https://www.acmagile.com/kanban-nedir/

7-https://agilekanban.istanbul/tr/2017/11/02/kanban-ile-bir-gun-nasil-gecer/