Scrum ve Kanban Arasındaki Benzerlikler ve Farklılıklar
Çevikliği düşününce aklıma gelen ilk iki şey Scrum ve Kanban oluyor. Tabi ki çeviklik sadece bu iki yaklaşımla bitmiyor, çok daha büyük bir şeyi, bir kültürü anlatıyor. Çevik yazılım geliştirme dediğimizde aklımıza gelen bu yaklaşımları ne kadar biliyoruz? Bu soru aklıma düştüğünde cevaplamanın en iyi yolunun bu iki yaklaşımın benzerliklerinin ve farklılıklarının neler olduğu belirleyerek çok daha kolay anlayabileceğimi ve anlatabileceğimi düşündüm. İşte burada Scrum ve Kanban arasındaki benzerlikler ve farklılıklar bulunuyor. Umarım faydalı olur.
Scrum ve Kanban Arasındaki Benzerlikler
- İkisininde özünde Çeviklik ve Yalınlık bulunur.
- İşler emir komuta ile değil iş çekme prensibine dayalı tamamlanır.
- İkiside aynı anda geliştirilen işleri sınırlamayı önerir(Kanban WIP’i limitleyerek bunu direk olarak yaparken, Scrum bir Sprint’te geliştirilecek iş miktarını sınırlayarak yapar).
- İkiside sürecin iyileştirilmesi için şeffaflığı kullanır.
- İkiside deneyciliğe dayanır.
- İkiside olabildiğince erken ve sık yazılım teslimatı yapmaya çalışır.
- İkisinde de geliştirme takımları kendi kendini yönetir.
- İkisinde de büyük işlerin küçük parçalara ayrılması tavsiye edilir.
- Deneysel veriye(Scrum’da takımın ortalama hızı, Kanban’da lead time’a -bir fikrin ortaya çıkışı ve teslim tarihi arasındaki fark) göre teslim planı sürekli olarak güncellenir.
- İkisinde de özellikle bir pratiğin- TDD, Sürekli Teslim, Refactoring, Acceptance Testing, Small Releases, Simple Design, Coding Standards, Shared Metaphor, Collective Code Ownership- kullanılması belirtilmemiştir. İçinde bulunulan ortama göre bu pratiklerin benimsenmesi geliştirme takımına bırakılmıştır.
Scrum ve Kanban Arasındaki Farklılıklar
Scrum | Kanban |
| Geliştirme belirlenen zaman limiti içinde başlar ve biter. Sprint… | Geliştirme sürekli olarak devam eder. Limit belirlemek opsiyoneldir. |
| Planlama, süreç iyileştirmeleri ve teslim için farklı ritimlere sahip olabilir. Sprint Planlama, Sprint Retrospektif ve Teslim Planlaması farklı zamanlarda yapılabilir. | Yaşanılan gelişmelere göre aksiyon alınır. Önceden belirlenmiş toplantılar ya da aktiviteler bulunmamaktadır. |
| Takım bir iterasyonda belirli miktarda işi bitireceğine dair söz verir. | Söz vermek opsiyoneldir. |
| Takımın hızı planlama ve süreç iyileştirme için temel metrik olarak kullanılır. | Lead Time, planlama ve süreç iyileştirme için temel metrik olarak kullanılır. |
| Geliştirme Takımları’nın çapraz fonksiyonel olması kuraldır. | Geliştirme Takımları’nın çapraz fonksiyonel olması opsiyoneldir. Uzmanlıkların ön planda olduğu takımlar kurulabilir. |
| İş maddeleri bir Sprint içinde tamamlanacak küçük parçalara bölünmelidir. | İş maddeleri büyüklükleri farklılık gösterebilir. Belirlenen alt ya da üst bir limit yoktur. |
| Burndown grafiklerin kullanılması tavsiye edilir. | Belirli tipte bir grafiğin kullanılması zorunlu değildir. İşi yapmaya yarayacak herhangi bir grafik kullanılabilir. |
| Geliştirilen iş sayısı dolaylı olarak kısıtlanır. Bir Sprint’te Geliştirme Takımı’nın gerçekleştirebileceği iş miktarı belirlidir. | Geliştirilen iş sayısı direk olarak kısıtlanır. Bu kısıt koyulurken iş akış durumuna bakılır. |
| İşlerin büyüklükleri hakkında tahmin yapmak tavsiye edilir. | İşlerin büyüklüklerini tahmin etmek opsiyoneldir. |
| Devam eden bir Sprint’e yeni işler eklenemez. | Kapasite uygun olduğu sürece yeni işler eklenebilir. |
| Sprint İş Listesi belirli bir takım tarafından sahiplenilmiştir. | Kanban Tahtası, birçok takım ya da kişi tarafından kullanılabilir. |
| Üç rol belirlenmiştir. Ürün Sahibi, Geliştirme Takımı, Scrum Master | Herhangi bir rol belirlenmemiştir. |
| Scrum Tahtası her Sprint başında yeniden oluşturulur. | Kanban Tahtası kalıcıdır. |
| Önceliklendirilmiş bir İş Listesi zorunludur. | Önceliklendirme zorunlu değildir. |
| İş geliştirilirken kısa aralıklarla ulaşılabilecek hedefler konulur. Böylece takım hedefe her ulaşmaya çalıştığında deney yapabilir ve önceki deneylerden çıkardığı sonuçlar ile gelecekteki deneylerde daha iyi sonuçlar elde etmek için iyileştirmelerde bulunabilir. Amaç bir ritim yakalamak ve olabildiğince bu ritmi iyileştirerek ilerlemektir. | İşler bir akış mantığı içinde geliştirilir. Akışta bir dar boğaz tespit edildiğinde bu dar boğaza karşı aksiyon alınır ve tekrarlamaması için iyileştirmeler yapılır. Kısa vadelerde belirlenen hedefler yoktur. Geliştirme sürekli olarak devam eder. İş sürekli olarak akar. Amaç işin pürüzsüz bir şekilde sürekli olarak akışını sağlamaktır. |
Referans: http://www.yilmazcihan.com/kanban-ve-scrum-ikisinin-de-en-iyisini-yapmak/
Gayet güzel açıklanmış.teşekkürler
Rica ederim, ne mutlu bana 🙂
Eline Sağlık Cihan, farklılıklar ve benzerlikler çok iyi ifade edilmiş.
Teşekkürler, faydalı olduysa ne mutlu bana 🙂
Teşekkürler Cihan Bey 🙂
Rica ederim 🙂 Ne mutlu bana 🙂
Google’da bu konuyu araştırırken yazına denk gelmek mutluluk verici. Eline sağlık Cihan, teşekkürler?
Teşekkürler Cansel, faydalı olduysa ne mutlu bana 🙂
Onca site içerisinden okuduğum en güzel yazı, elinize sağlık.
Teşekkürler 🙂
Oldukça güzel açıklanmış; fakat söylemek isterim ki yazım yanlışları olmasa yazının kalitesi daha da artarmış.
Teşekkürler. Geri bildirimlerinizi her zaman beklerim, yazıların üstünden benden başka en az bir kişi daha geçiyor fakat bazen gözden kaçabiliyor. Yanlış olan yerleri söylerseniz düzeltebilirim.