Yeni bir ürün geliştirecekseniz veya sadece mevcut geliştirmenizi iyileştirecekseniz, bir geliştirme yöntemi seçmeniz gerekecektir. Şelale sisteminin tarih olduğunu not edebiliriz, nedenini detaylı olarak açıklamama gerek yok. Ama ne gibi seçeneklerimiz var? En popüler olanlar Scrum ve Kanban'dır. Evet, OKR (Hedef Anahtar Sonuçlar) da kullanabilirsiniz ancak bu makale Scrum ve Kanban arasındaki farkları, avantajları ve dezavantajları açıklamayı amaçlamaktadır.
Seçim genellikle zordur çünkü her ikisi de bir görev panosu, günlük gazeteler (kısa günlük toplantılar) sunar. Scrum, sabit teslimat zaman dilimleri olarak sprintleri olan ikisinden sadece biridir. Fakat üçüncü temel özelliklerden ikisi aynı olduğunda, farklılıklar nerede yatıyor? Bu nedenle doğru olanı seçmek oldukça zor olabilir.
Ne zaman birini diğerine tercih edip ne zaman seçmeyeceğimi açıklığa kavuşturmak istiyorum.
Tablo 1, Scrum ve Kanban arasındaki belirli farklılıkları göstermektedir.
Hiç Scrum eğitimine katıldınız mı? Öyleyse, Stacey-Matrix ve Cynefin-Framework hakkında bir şeyler duydunuz, değil mi? Her ikisi de, parçanın iki Agile yönteminden birini seçmesi için doğru kararı vermenizde size rehberlik edebilir. [1] [2]
Cynefin Modeli problemlerinizi dört kategoriye ayırır:
Açık olan bir şey varsa, o zaman bu sorunu A'dan Z'ye tarayabilir ve bu nedenle bu konuda en iyi uygulamaları kullanabilirsiniz. Rutin olarak gerçekleştirilecek bir görevden fazlası olmamalıdır.
Karmaşık sorunları ancak uzman bilgisiyle anlayabiliriz ve bunları tahmin etmek daha zordur. Daha fazla analiz burada yardımcı olur.
Karmaşık bir ortamda, bundan sonra ne olacağını önceden belirlemek neredeyse imkansızdır. Müşterilerin nasıl tepki vereceği bile belirsiz olabilir. Olayların birbiriyle nasıl ilişkili olduğu ve hangi eylemin hangi sonuçları doğurduğu ancak geriye dönüp bakıldığında netleşir. Bu sadece analiz yoluyla değil, aynı zamanda deney ve öğrenme yoluyla da.
Sebep ve etkinin artık burada bir ilişkisi yok veya bizim anlayışımızı aşıyorlar. Kaotik sistemler bir tür uyarıdır. Ne deney ne de analiz için zaman olmadığından acil eylem gerektirirler.
Ancak bunun doğru geliştirme yönteminin seçimiyle ortak yönü nedir? - Sorabilirsiniz.
Scrum gibi çevik yöntemler anlamlıdır, özellikle karmaşık problemleri çözerken, ürününüz veya şirketiniz gereksinimlerin hızla değişebileceği değişken bir ortamdadır. O halde kısa vadede sürekli teslimat, Kanban yönteminin açıkça önündedir. Sık sık bir ürünün yeni bir sürümünü yayınlarken, geri bildirim garanti edilir ve bir sonraki yinelemenizi bu geri bildirime göre ayarlayabilirsiniz. [3]
Ayrıca, Kanban'ın ürününüzü serbest bırakmak ve ayarlamak için yöntemleri vardır, ancak Kanban'ın özü, yaklaşan çalışma sürecini yönetmek ve daha sonraki değişiklikler için bir temel oluşturmaktır. Deneysel olarak çözüm bulmaya odaklanmaz.
Scrum çerçevesinin kurucusu Ken Schwaber ve Jeff Sutherland, Scrum'ı ekiplere uygulamayı amaçlıyordu. Ampirik bir yaklaşıma sahipken sıkı bir şekilde entegre geri bildirim almak için hedefler belirlerler. Bu bile müşterileriniz için doğru çözümü veya en azından en iyi işlevsel ürünü geliştirmeyi mümkün kılar. Bunu bir Jump'n'run oyununda olduğu gibi, deneme yanılma, yansıtma ve yeniden ayarlamalar ile müşteri veya diğer katılımcılar, örneğin Ürün Sahibi, Scrum Master vb. İle yaparsınız.
Scrum, 4 Etkinlik aracılığıyla bir geri bildirim döngüsü ile birlikte sprintleri (genellikle 1-4 haftalık sürekli çalışma) uygular:
Sprint Planlama - Günlük Scrum - Sprint İncelemesi - Sprint Retrospektifi [4]
Hepsini sayarsak, Tablo 1'de belirtildiği gibi 5 olay elde ederiz.
Bu adım adım yaklaşım, her sprint sonunda potansiyel olarak teslim edilebilir bir yazılım parçasını hedefler. Zamanla sadece işbirliği veya kullanıcı davranışına ilişkin içgörüler büyümekle kalmaz, aynı zamanda müşteri / kullanıcı için faydalar da her sprintten sonra artacaktır.
Müşterilere bu odaklanma, Agile Yazılım Geliştirme Manifest'inin temel bir bileşenidir. En yüksek hedefler müşteri memnuniyetine, güvene ve yakın işbirliğine ve aynı zamanda temel unsurlara odaklanmaya odaklanır. Özelliklere aşırı yüklenmiş buggy yazılım parçası geliştirmek yerine, gerçekten önemli ve fayda sağlayan öğeleri geliştirerek karmaşıklığı azaltırsınız.
Bunu hızlı bir prototip oluşturmaya ve ürünün değerli olup olmadığını test etmeye benzer şekilde görebiliriz. Ancak burada, ürününüzün değerini zaten kontrol ettiniz ve hatasız / hatasız kullanılabilir bir uygulama oluşturmak için gerekli parçaları uyguladınız. Bu temel ürün müşterilerinize şimdiden değer katacak.
İşlem sırasında gereksinimler yine de değişebilir. Başlangıçta sabit ve planlı değildirler, ancak kademeli olarak ortaya çıkabilirler. Sadece bir sprint sırasında kontrollü çalışma sabitlenir. Bir sprint genellikle 1-4 hafta uzunluğundadır. Bu, ekibinizin büyüklüğüne ve ürününüze de bağlıdır. [5]
Bir Scrum takımındaki günlük çalışmanın iyi sonuç vermesini ve hiçbir yönün gözden kaçmamasını sağlamak için üç farklı rol vardır. Kurucular bu prosedür için net roller geliştirdiler. Bu nedenle, her birinin kendi özel odağı vardır ve tüm çerçeveyi kullanışlı hale getirmek için buna uymanız gerekir.
Kısaca Ürün Sahibi, geliştirilmekte olanla ilgilenir. Geliştirme ekibi, gerçekleştirilebilir bir çözümün nasıl görünebileceğiyle ilgilenir. Scrum Master, işbirliğini ve süreci optimize etmeye özen gösterir. Roller de tıpkı olaylar gibi zorunludur ve bu nedenle Scrum'ı tanıtırken baştan dikkate alınmalıdır. Çünkü Scrum oldukça sabit kuralları ve ritimleri nedeniyle takip edilmesi kolay olsa bile, çalışma şekli sabit bir kural setini takip etmekten çok daha fazlasıdır. Hem scrum kılavuzunda hem de Çevik Manifest'te, değerler ve ilkeler her şeyden önce sabitlenmiştir, scrum olmadan basitçe işe yaramaz.
Scrum'ı uygulamak için tüm miktarlarda kuralları başarıyla yerine getirin. Örneğin, Ürün Sahibi ürününe karar veremezse ve sadece amir için bir ağızlık görevi görürse veya sorunlar takımda halının altına süpürülürse, başarı tehlikeye girer ve Scrum yalnızca boş bir kabuktur. Bu, Scrum ile çalışmak isteyen herkesin en başından itibaren büyük değişikliklere hazırlanması, temel eylem ve karar alma özgürlüğü ile yeni roller vermesi ve ekibin bağımsız çalışmasına izin vermesi gerektiği anlamına gelir.
Kanban, otomobil üretim sürecinden gelen 20. yüzyılın ortalarında icat edildi. Japon Toyota şirketi, Kanban'ı merkezi olmayan süreçleri kontrol etmek ve verimliliği artırmak için bir sistem olarak geliştirdi. Sözde yalın üretimde, sadece şu anda talep edilenler üretilecektir ( çekme prensibi ). [6]
Yazılım geliştirmede Kanban'dan bahsettiğimizde, David J. Anderson'ın versiyonundan bahsediyoruz. Bu sürüm, yalın üretim fikirlerini ürün geliştirme, hizmetler ve diğer bilgi çalışması türlerine uyarlar. Bunu bir değişiklik yönetimi yöntemi olarak yeniden adlandırdı. [7]
Yazılım-Kanban, paralel olarak yapılabilecek iş miktarını sınırlayan çekme ilkesine de dayanmaktadır. Bu sözde Devam Eden Çalışma sınırları (WIP = Devam Eden Çalışma), sistemde yalnızca makul miktarda görev olmasını sağlar. Amaç, müşteriye daha hızlı bir teslimat sağlamak için boşta kalma süresi veya darboğazlar olmadan sürekli bir iş akışıdır. Ek olarak, Scrum'a benzer şekilde Kanban da müşteriye ve ihtiyaçlarına (Tablo 2'yi karşılaştırın) ve sunulan sonuçların gerçek değerine odaklanır. [7]
Kanban dönüştürücü bir yaklaşım izliyor. Geliştirici o anda bulunduğu yerden başlar (örneğin, mevcut çalışma sürecinin grafiksel bir haritasıyla). Mevcut tüm roller, iş unvanları ve sorumluluklar korunur. Gerektiğinde tek değişiklik gelecekte yapılacaktır [8]. Bu nedenle, Kanban'ı tanıtmak ve idare etmek Scrum'dan daha kolaydır: Yeni davranışlara ve süreçlere geçiş ancak kademeli olarak gerçekleşir. Takımlar ve çevreleri buna yavaş yavaş alışabilir.
Bu bağlamda, değişikliklerin Kanban'da hedeflenen iş ve sürecin ortak olarak belirlenen zorluklara göre görselleştirilmesi ile yapıldığını vurgulamak da önemlidir. Bu, daha yüksek bir kabul şansına yol açar. Ayrıca Scrum'da prensip olarak durum böyledir, ancak önce alternatif çalışma şeklini uygulamak ve prensipleri içselleştirmek başarılı olmalıdır.
Kanban'ın yedi geri bildirim döngüsünü, kadansları ve Kanban'da bilinen iki rolü uygulamaya yönelik diğer prosedür de pratikte Scrum'a göre daha az katıdır. Kanban'ın, bazen kulağa hantal gelen ritimleri ile daha fazla ek yük gerektirdiği varsayılabilir. Bununla birlikte, yedi takım süre tanımlamaya gerek yoktur, ancak devam eden süreçte veya ayrı toplantılarda - bunların ardındaki hedeflere ulaşmak için. Bunlar gerektiği gibi gerçekleşebilir ve sabit bir ritme sahip olmaları gerekmez. Kanban toplantılarıyla uğraşırken (günlük) düzenlilik kanıtlanmıştır. Bu, sürekli iletişime, derinlemesine düşünmeye ve verimli işbirliğine yol açacaktır.
Kanban teorisinde formüle edildiği gibi, bir Hizmet Talebi Yöneticisinin rolü (bir Ürün Sahibine benzer) ve bir Hizmet Sunma Yöneticisinin (iyi bir iş akışından sorumlu) rolü, açıkça gerekli değildir. Anderson, bu rollerin, müşteri beklentilerini ve uygulamada sorunsuz iş akışlarını göz önünde bulundurmak için bir mentor yaklaşımına sahip olduğunu açıklıyor. Kanban teorisi, kimin birlikte çalışması gerektiğine açılmasına izin verdi. Aksine, bir takım kümelenmesi kendiliğinden ortaya çıkar - başlangıçta gerçek durumla ve daha sonra meydana gelebilecek bir optimizasyon ihtiyacı ile.
Kanban ve Scrum arasında seçim yaparken, kurucuların bu yaklaşımları geliştirdikleri birincil amacı anlamak önemlidir. Bu amacın kendi niyet ve hedeflerinize uyup uymadığını kontrol edin. Geliştiricilerin daha hızlı çalışmasını sağlamak için Scrum'ı tanıtmak yanlış olur. Scrum'ın odak noktası, onu geliştiren kişilerin verimliliğinde değil, ürünün etkinliğindedir. Benzer şekilde, Scrum, uzun vadeli planlamanın basit olduğu ve değişikliklerin beklenmediği istikrarlı bir ortamda kullanışlı değildir. Bu durumda fayda, çabaya kıyasla çok küçük olacaktır.
Bahsetmek önemlidir, Scrum için bir karar, yaklaşımı bütünüyle uygulama göreviyle birlikte gelir. Aksi takdirde, aslında bundan yararlanamazsınız. Beş Scrum etkinliğinin yardımıyla rolleri tanıtın ve süreci tamamen oluşturun.
Sprint - Sprint Planlama - Günlük Scrum - Sprint İncelemesi - Retrospektif
Scrum takımı ve süreç doğru şekilde kurulmazsa zorluklar önde olacaktır. Dış koşullar, çok sayıda ilgili taraf ve bir zaman gecikmesiyle işlenen görevler, kötü bir şekilde uygulanmış bir Scrum sürecine neden olan yalnızca bazı örneklerdir. Bu durumda anlamlı sprint hedeflerini ve kapsamlarını belirlemek pek mümkün olmayacaktır. Böyle bir durumda Kanban daha iyi bir seçimdir.
Kanban'ı kullanmaya karar verirseniz, yalın ve benzersiz öğelerle başlayabilirsiniz. Tersine - özellikle bu yöntemlerle tecrübesi olmayan takımlarda - ne Scrum süreci iyi ve amaçlandığı gibi çalışmaz ki bu sadece çerçevenin seçilen kısımlarına dayanır, ne de Kanban sadece yedi kontrol tarihiyle başladığınız için bir başarı garantisi olmaz. ve iki Kanban rolü. Burada daha az daha çoktur.
Muhtemelen her ikisi de birleştirilebilir. Her iki yaklaşımın bir kombinasyonu da düşünülebilir. Kombinasyona Scrumban denir, ancak bu makalenin tamamına değer. Scrum takımlarında Sprintler için Devam Eden Çalışma sınırları veya bireysel süreç adımları gibi tek tek Kanban öğeleri kullanılır veya tam tersi. Örneğin, Kanban'daki görevleri netleştirmek için iyileştirmeler sunulur.
Daha sonraki bir değişiklik de mümkündür: Scrum takımları, örneğin, ürün devam eden operasyonlarda konsolide edildiğinde ve odak, güncelleme ve bakıma geçtiğinde Kanban'a geçebilir.
[1] Stacey Matrix https://www.scrum-tips.com/agile/stacey-complexity-model/
[2] Cynefin Çerçevesi http://www.everydaykanban.com/2013/09/29/understanding-the-cynefin-framework/
[3] Scrum'ın Temel Yönleri https://www.scrumalliance.org/about-scrum/overview
[4] Scrum Olayları https://www.scrumalliance.org/about-scrum/events
[5] Çevik Manifesto https://agilemanifesto.org/iso/de/manifesto.html
[6] Çekme Prensibi https://leanopedia.com/the-pull-principle/
[7] Kanban, David J. Anderson https://amzn.to/34X2PKx
[8] Jesper Boeg tarafından Kanban Hazırlanıyor https://www.infoq.com/minibooks/priming-kanban-jesper-boeg/
Nasıl harika bir menti olunacağına ve uzun süreli bir mentor ilişkisinin nasıl kurulacağına dair çok fazla bilgi var. Peki ya masanın diğer tarafında olmak istediğinizde? 2019'dan beri altı ayda bir iki kişiye mentorluk yapıyorum ve bu harika bir ödüllendirici deneyim oldu.
With Company henüz yedi yaşına bastı. Bu yaşam ve iş yolculuğunda nasıl ergenliğe girmediğimize dair tüm duyguları yaşadığımız metaforlarına derinlemesine girmekten sizi kurtaracağız.
Birkaç gün içinde kaybedilen 28 milyar dolarlık piyasa değeri ile herkes Terra Luna stablecoin çöküşünü duydu. Bu olay, yalnızca bir proje başarısızlığı olmanın ötesinde, tüm kripto para ekosistemini ön plana çıkarıyor.
Duymak istemeyeceğiniz birkaç şey var. Ama sorun değil.
Giriş Dijital bir dünyada renkler, renk modellerinden birinde koordinatlar olarak temsil edilir: RGB, HSL, HCL, vb. Bazıları makineler için yapılırken (RGB kelimenin tam anlamıyla ekranların çalışma şeklini temsil eder), diğerleri ise (HSL, HCL) olmaya çalışır. renk uzayında gezinmek için daha doğal bir yol sağlayarak daha tasarımcı dostu. Tasarımcılar için renkler görseldir.
Yeni bir proje yayınladım: Rahatsızlıklar. Bu koleksiyon Tom'un hikayesi, benim icat ettiğim bir karakter.