Sor-Dinle Dinle-Sor

İş analizi yapan kişide olması gereken iki önemli özellik. Belki herşeyden önemlisi. 

1. Dinlemek : Böylece öğrenirsin.
2. Doğru soruyu sormak: Nasıl yerine neden sorusunu sorarsan ihtiyacı özümsersin. 


When you talk, you are only repeating what you know.
But if you listen, you may learn something new.
– Dalai Lama

 The big question of our time is not Can it be built? but Should it be built?
– Eric Ries

Value Proposition Canvas

Business model canvas içerisindeki 9 temel iş modeli elementlerinden Customer ve Value kısmına odaklanarak müşteri açısından değeri karşılayan unsurlar ile Ürün/Hizmetin ürettiği değerin müşterinin ihtiyaçlarına verdiği cevapları eşleştirir.

Bir ürün veya hizmetin en temel özelliği ihtiyaçları karşılamasıdır.
Müşteri Segmentinde ürün/hizmete duyulan ihtiyaca neden olan 3 unsur vardır.
Ürün/servis de bu 3 unsuru karşılamak zorundadır. Value Proposition Canvas (Türkçesine Müşteri Eksenli Katma Değer Modeli dersek anlamlı olur herhalde) ise ihtiyaç ve bu ihtiyacı karşılama şekillerini ilişkilendirir. (*) Bu unsurlar müşteri açısından şöyle ifade edilr

Kazanım (Gains): Müşterinin bir ürün veya servisten kazanımı ne olacak?
Acı (Pains) : Bu ürün veya hizmet müşterinin muzdarip olduğu hangi konuları ortadan kaldıracak.
Lüzum (Customer Jobs): Ürün veya Müşterinin ihtiyaç duyduğu bir işini görecek mi?

Ürün ihtiyacı doğuran bu unsurlara ne kadar çok karşılık verir ise o kadar çok değer önermiş demektir.

Müşteri Eksenli Katma Değer Modeli

(*) : https://strategyzer.com/

Karmaşık diyagramlarla çalış(ama)mak

OKUMA SÜRESİ: 2dk 30 sn

Talep edilen yapının parçaları arasındaki etkileşimleri, iletişimleri görsel olarak ifade etmek iş analizinin daha hızlı ve sağlıklı ilerlemesini sağlar. Ne de olsa birçok insan görselliği yazıya tercih eder. Haliyle, tümevarım veya tümdenvarım yöntemi farketmeksizin analiz çalışmasını daha baştan çeşitli diyagramlarla görselleştirmeye çalışmak doğru bir yaklaşımdır. Bu konuda herkesin en çok kullandığı diyagramlardan biri şüphesiz iş akış diyagramıdır.

Fakat bazen bu diyagramlar o kadar karmaşıklaşır ki, 3-4 cümleyle anlatılmak istenen bir süreç veya ilişki olur sana 40 kutucuklu bir muamma.

İş Akış Diyagramı

Ya da bir ilişki diyagramı kurayım derken örümcek ağına dönen entity relationship diyagramları ile karşılaşırız.

Entity Relationship Örneği

Etki-Neden diyagramı için kullandığımız balık kılçığında ise kılçıklar o kadar çoğalır ki yenmesi pek zor bir alabalığa döner.

Balık Kılçığı Diyagramı

Sequence diyagramına gelince; bunu pek kullanmayız o yüzden pek karmaşık olanını görmedim. Bundan sonra kullanmaya başlasak iyi olacak, akış diyagramına göre daha faydalı (https://www.websequencediagrams.com sitesi bu konuda güzel)

Sequence Diyagramı

Bu tür diyagramlar armaşıklıktan öte hazırlanışına harcanan kayıp zamanlara da neden olmaktadır.

Karmaşık diyagramlar iş analizinin kalitesini veya derinliğini göstermez. Bu tür diyagramlardan (karşı taraftan talep edilmedikçe ) mümkün olduğunca kaçınılmalıdır. 

Gelin birazcık empati kuralım. Eğer bu denli karmaşık diyagramlar izaha ihtiyaç duyacak hale gelmeye başlamışsa bu diyagramları basitleştirelim. Gerekirse parçalara ayıralım. Bir diyagram değil 2-3 ayrı diyagram oluşturalım. Kutucuklar yerine ev, araba, insan şekli, figürler vs koyalım. 20 kutucuktan fazlasının dikkat dağıttığını düşünerek gerekirse çok detaylı süreçleri sözel ifade edelim veya birkaç noktayı tek yerde toplayarak daha detaylı açıklamaları yazıya dökelim.

İş yapıyorum diye ne kendi ne de başkalarının vaktini harcamakla meşgul olmayalım

Diyagramları 4 ana kısma bölelim. Üst yönetim ile, İş birimi ile, müşteriler ile ve yazılımcılar ile paylaşılacaklar.

Üst Yönetim ile yaplaşılacak diyagramların en temel özelliği kesinlikle detay içermememesi ve kolay anlaşılabilir olmasıdır. Bu anlamda, use case, iş akış diyagramından kaçınmak gerek. Üst yönetim için şekillerden ziyade 5-10 cümlelik bir özet daha sağlıklı olacaktır.

Yazılıma verilecek en güzel diyagram interaktif ekran görüntüleridir. Interaktif toollar yoksa story boarding şeklinde ekran görüntüleri sıralanarak bir akış çıkarılabilir.Ekran görüntüleri illa bir tool üzerinde çizilmek zorunda değil, kalemle kağıda çizilip fotoğrafları da çekilebilir. Yazılım bitinceye kadar ömrü olan diyagramlara çok vakit harcamamak gerek.

İş birimine orta düzey detay seviyeyi gösterecek use case veya iş akış diyagramları hazırlanabilir. Kutu sayısı 20’yi geçmemeli. Çok küçük yazılar olmamalı. Gerekirse kutucuklar yerine daha göresel figürler kullanılabilir. Balık Kılçığı, Sequence diyagramı ile Use Case diyagramları kullanılabilir.

Son kullanıcıya (müşteriye) verilecek en güzel akışlar, daha çok video tarzı görsel ve sözlü anlatımlı diyagramlardır. 3 slaytı bir araya getirerek bile ses ekleyebilir veya ses eklemeden de  arkasına müzik ekleyerek zenginleştirebilirsiniz. Bu amaç için internette hızlı toollar bulabilirsiniz.

Yukarıda verilen diyagram örnekleri daha da genişletilebilir veya müşteri, yazılımcı ve işbirimi dikkat ve detaycılığına göre farklıştırılabilir.

Temel hedef şu, KISS: Keep it simple and stupid. Eğer sisteminiz basit değilse diyagramları basitleştirmeye çalışın. Eğer sistemleriniz basitse o zaman da diyagramlarınızı içinden çıkılmaz bir karmaşıklığa sürüklemeyin.

Her yerde göstereceğiniz diyagramlarınız varsa tüm yapıyı özetle anlatacak kadarıını yapın ama bakan  kişiler bulmaca çözmeye çalışmasın. Belediyelerin imar haritasına dönmesin akışlar

Kalın sağlıcakla.

KARTAL: İŞ ANALİZİNDE İLHAM KAYNAĞI

OKUMA SÜRESİ: 1 dk

Bazı hayvanlar efsanedir. Onların ayırdedici özelliklerini bilmesek de hemen çıkıverir ağzımızdan bir muhabbet esnasında. Aslan, kaplan, kurt, şahin, at gibi. Bunlardan biri de kuşkusuz kartal.

Peki kartalın ayırdedici hangi özellikleri var dersiniz?

1. Güçlü ayakları ve gövdesi:  öyle ki koca bir geyik bile avlayabiliyor.
2. Keskin gözleri: Bilinen en yüksek uçan kuş olmasına rağmen onca yüksekten avını kestirip yakalayabiliyor.
3. Karizması: Bu da bizden olsun :)

Bu blogda ne işi var kartalın o zaman. Sizce hangi özelliği ile blogumuza misafir olmuştur? Araya karizmatik bir kartal fotoğrafı eklendi ki yazının kalan kısmının etkisi olmasın cevabınızda :)

Kartal Analist. 

Gelelim analizimize:

1. özellik olan güç son vuruş ki buna release anı diyelim. Bizcesi en sondaki iletişim ve koordinasyon gücü.

3. özellik ise 1 ve 2 olmayınca havası çabuk sönen çocuklara aldığımız helyum gazlı pepee balonu gibidir. Varlığının tadı kısa süre de olsa tadılır yine de.(çocukların her görüşünde istediği ve 24 saat içerisinde söneceğini bile bile anne ve babaların aldığı yeni nesil balonlar. )

Bizim aradığımız özellik 2'de saklı. İş analisti rolünü üstlenen herkes büyük resmi en yüksek seviyeden görüp tüm detayları taramalı. Gücüne göre hedeflerini seçmeli ve en optimum çözümü müşteriye sunmalı. Detaylarda boğulmadan önce yükseklerden uçmalı. 

Gayet açık olduğundan fazla yazmaya da gerek kalmıyor. 

Kartal ruhlu analistlere sevgiler.

İŞ ANALİSTİNİN GEREKSİZ TEKNİK ADAMLIK HAZZI

OKUMA SÜRESİ: 1dk 30 sn

Bugün uzun zaman aradan sonra third party bir entegratörün sunduğu bir API servisinde ilgili parametreleri girerek test amaçlı birkaç HTTP Request yaptım. 2-3 tool yükledim. Bir iki request, error derken zamanın nasıl geçtiğini anlamadan JSON, Header, key, error code, request ve responseler vs havada uçuştu. Ne bileyim bir hoş oldum aslında. Sanki zaman zaman damarlarımı baskılayan teknik ruh kendini dışarı salıvermiş pervasızca teknolojik hazzın tadını çıkarmaya çalışıyordu.

Hayli saat harcadıktan sonra, API servisinden error olmadan response aldım. Yazılımcılara koşup, "arkadaşlar bu third party ile çalışacağız, siz rahat olun servisleri de gayet güzel çalışıyor, bizzat test ettim, story'leri de çabucak çıkrırım" dedim. 

Ve tabii o deriiiiin! teknolojik bilgimin farkına varmalarını da sağlamış oldum. 

Fakaaat!!! 

Uzun yıllardır iş analistlerinin aslında ne kadar önemli bir yerde durduğunu ıspatlamaya çalışan biri olarak, hemen bu anlamsız hazdan kendime bir ders çıkardım. Kimse bizi, entegrasyonu test etmemiz, SQL yazmamız, kodu debug edip yazılımcının tepesine binmemiz veyahut ta iş birimine sisteme ne kadar hakim olduğumuz göstermemiz için işe almıyor. (Alıyorsa da almasın bundan sonra, bu işleri yapacak hayli yazılımcı, testçi işe alınıyor zaten)

Burada "amaaan be sen de, kod bilmemizin ve ne olup bittiğini anlamamızın ne zararı var. kendin bilmiyon diye bizi de yanlış yola götürme" dediğinizi duyar gibi oldum. 

Bunu demekte haksız değilsiniz. Bazen çok arafta bırakılıyoruz. Bizi işe alanlar bile nereye konumlandıracağını karıştırabiliyor. Fakat şurda hemfikirsek, kodu ancak hobi için yapmamız gerektiğinde de uzlaşırız.

İş analistleri veya product owner olarak biz,

Kaynaklarımızın, stretajilerimizin ve teknolojik kısıt ve varlıklarımızın farkında olarak, sınırsız teknolojik talepleri en çok değer üretebilecek noktaya taşımayla görevlendirildik.

Yani bizim adımıza herşeyin başladığı yer burası. Sonrası ise malumumuz. 

Sonuçta, beynimiz de bir kaynak. Doğru yere odaklanalım. Kendi işimiz için değer üretelim.

Vesselam. 

İŞ ANALİSTİNİN 8 TEMEL DOĞRUSU

Siz bir iş analistisiniz. Sizinle güzel bir sohbete yapan bir arkadaşınız bir ara tam olarak ne yaptığınızı merak ediyor.

-  Senin görevin neydi kurumda?

-  İş analistiyim.

-  Ne yapıyorsun tam olarak?

İşte kritik soru geldi. Cevabı ise muhtemelen geçiştirmelik veririz, yoksa bu hamur çok su götürür.

Zira yaptığımız işi tanımlamak o kadar da kolay değildir. Doğrudur! Kolay tanımlanamayanı yapmak da kolay değildir. Hele bunun en doğrusuna ulaşmak gerçek bir sanattır.

İşte bu soruya arkadaşımızın da merakını kolayca gidermek için kalıplaşmış aspirin bir cevap verir ve böylece konuyu değiştiririz.

-  Kurumumuzda yazılımsal bir değişiklik talep eden birimler ile yazılımcılar arasında köprü görevi görüyorum

-  Hmmmm! Gayet güzel.

Bu cevabın doğruluğunu ve arkadaşınızın anlamış gibi gözüken yüz ifadesini bir kenara bırakalım.

Şimdi, gelelim, biz iş analistleri olarak kendimizi nasıl tanımlamalıyız ve nereye konumlandırmalıyız sorusunun cevabına. Az sonra ifade edilecek olan maddeler agile, waterfall, lean tekniklerinden bağımsız olarak iş analisti şapkasını takan product owner, çözüm mimarı, sistem analisti gibi tüm roller için genellemelerdir.

TANIYIN: Çalıştığınız kurumun kültürünü, kısa-orta-uzun vadeli hedeflerini, hedefe taşıyan stratejilerini, kar getiren ürünlerinin ne olduğunu, gider merkezlerini, rakiplerini, kurumda güç merkezlerineki kişi ve birimlerin kim/nerede olduğunu ve karar verme sürecinin nasıl işlediğini öğrenin. Analiz yaparken bu bilgileri üst çatı olarak referans alın. Küçük işler için büyük hedefleri kurban etmeyin.

UNUTMAYIN: Yazılımcı, test mühendisi, database uzmanı veya donanımcı olmadığınızı unutmayın. Onların ne iş yaptığını ve nerede konumlandıklarını çok iyi bilin ama onların işini çok iyi bilmeniz değil sizin işinizi bilmeniz gerektiğini unutmayın. Onlar adına konuşmayın. Onlardan danışmanlık alın. C#, Java, Mongo, test otomasyonu konularını bilmiyorum dediğinizde sizden bir şey eksilmez unutmayın. ,Bu araç ve yöntemleri ana hatlarıyla bilmeniz yeterlidir.

ANLAYIN: Kapınızı analiz için çalan herkesi önce anlayın. Büyük-küçük iştir demeden dinleyin, sorun, içselleştirin, teyit edin. Bu döngüyü doğru olanı tam anlayıncaya alana kadar tekrarlayın.

DEĞER KATIN : İhtiyacı anladıysanız , hemen analiz yapmaya çalışmayın, birlikte beyin jimnastiği yapın, değer katmaya çalışın (kaynak kısıtını unutmadan). Talep içinize sinmediyse karşı tarafı düşündürün. Gerekirse daha sonra tekrar bir araya gelmek üzere akıllara soru işaretleri atıp biraz ara verin.

ÖNERİN: İşin ihtiyaç olduğu kesinleşip başlama aşamasına gelince, ihtiyacı karşılayabilecek çözüm önerileri sunun. Her zaman, combobox, checkbox, ekran, menü diye kısıtlamayın kendinizi. Ufkunuzu geniş tutun. Manuel bir çözüm bile olabilir. Yeter ki değer katın. Değer katmak RoI maksimizasyonudur. Açık kaynak ürünler, mobil veya bulut bilişim gibi güncel teknolojiler konusunda daha fazla çözüm önerileri geliştirin. Öneri yaparken her önerinin, fayda/maliyet kriterlerini sunmayı ihmal etmeyin. Böylece güvenilir bir danışman özelliğiniz oluşacaktır.

TAKİP EDİN: İş, analiz edilip yazılım sürecine girdikten sonra, işin tüm aşamalarından haberdar olun, takip edin, kontrol edin. Yazılım ve proje takım üyeleri ile sık sık konuşup hangi aşamada olduklarını, işi doğru anlayıp anlamadıklarını ve ilk çıktılarını kontrol edin. (Agile bu konuda Desk Check önerir)

DOĞUM SONRASI :) İşimizin en güzel yeri. Ürün doğdu. Ama o da ne? Doğum sonrası adaptasyon problemleri, hastalıklar, ihtiyaçlar... Her ortaya çıkan ürünün, yeni ürün ihtiyacı doğuracağı kesindir. Bu yüzden, yeni ihtiyaçlar eklenmesine müsait modeller geliştirmeye özen gösterin. Esnek çözümler üretin. Bu konuda gerekirse yazılım ekiplerini de ikna edin. Hatta kurumun hedefleri arasında teknolojiyi satmak varsa oldukça esnek ve satılabilir bir ürün hedefleyin. Ürün ortaya çıktıktan sonra ürünün performans verilerini sürekli takip edin.

GÜNCEL KALIN: Bu kısım sadece bizim rolümüzün bir parçası değil fakat iş analizi pratiklerle hem kendi doğrularını hem de kendi yanlışlarını büyütebilir. Bu yüzden yaptığımız yanlışları daha fazla beslememek adına, konferanslar, bloglar, kitaplar ve eğitimler ile kendimizi yenilemeliyiz. Bunların yanında yönetici, yazılım ve iş birimlerinden her zaman geri bildirim alın. Vermezlerse zorlayın.

Bu açıklamalardan sonra yapılacak en güzel tanım ne olabilir siz karar verin.

Köprü olmadığı açık. Varsa bir öneriniz yorumlarınızı bekliyoruz.

İş Analizi için uçtan uca tool önerisi

Siz de takdir edersiniz ki böyle sihirli bir tool yok gerçek dünyada.

Fakat daha ötesi var aslında.

Nasıl ki yazılım iyi business için iyi bir araçtır, aynı şekilde aklınıza gelen bütün analiz toolları da daha iyi analiz yapmak için birer araçtır. Ortada iyi bir analiz yoksa iyi toollar de işe yaramayacakır.

Diyelim iyi analiz yaptık. Hangi toollar bize daha çok yardımcı olur?

Yıllardan bu yana yaptığım gerek küçük, gerekse büyük proje analizlerinden öğrendiğim şu oldu. Hangi toolu en iyi kullanıyorsanız ve kendinizi rahat hissediyorsanız sizin için en iyi analiz toolu da odur. Excel, Word, Visio, Outlook, Html, Jira, TFS ve hatta dijital ortama aktarabiliyorsanız el yazısı, hiç farketmez. Çünkü artık birçok tool kendini oldukça geliştirdi. bir image capturing programı olan Snagit üzerinden bile akış çizebilir, user story detaylarını yazabilir ve mockup oluşturabilirsiniz. Tüm fonksiyonları çözüp analizi oluşturduysanız, kimse kullandığınığz toola bakmaz. Amacınız varsa tüm rüzgarları lehinize kullanabilirsiniz.

Burada kurumun önümüze koyduğu kurumsal süreç toolları olabilir ama bunlar genelde nihai analiz sonuçlarını kaydettiğimiz ortamlardır. Fakat analizi uzun bir yolculuğa benzetecek olursak kurumsal doküman yönetimi bu yolculuğun duraklarıdır. Yolculuk boyunca kimse analizi nasıl yaptığınıza bakmaz. 

Esas olan analiz aşamalarını kendimiz ve muhataplar açısından anlaşılır hale getirmekse en iyi oynadığımız oyuncağı kullanmalıyız. Zihnimizde her iş için bir tool matrisi oluşturmaya hiç gerek yok.Bir iki tool gayet yeterlidir. Odaklanmamız gereken şey şu olmalı. Analizin tüm aşamalarını gerçekleştirdim mi? İhtiyacı net anladım mı? İhtiyaca en optimum çözümü üretebildim mi? Çözümü yeterince detaylandırdım mı? Ve analiz sonuçlarını trace ettim mi? Shakespeare'nin dediği gibi "olmak ya da olmamak işte bütün mesele bu" diyoruz. İyi bir analiz kurgusu var mı yok mu? Bütün mesele bu...

Doğruyu yapacağım derken stratejileri unutmayalım

Vilfredo Pareto:

İtalya'nın önemli ekonomistlerinden.

Kendisi iş hayatında da birçok konuyu izah etmemize yarayacak teoriyi ortaya atmış. Aslında teori oluşturmamış ama "İtalya arazilerinin %80'i nüfusun en zengin %20'sine ait olsun/olmalı" deyince ardından gelenler bu teorinin iş dünyasında da doğru olduğunu varsayarak adına şu meşhur  Pareto kuramını oluşturmuşlar. Bizler de onların sayesinde biraz rahata kavuştuk ve bu oranlar kesin doğru olmasa da yaklaşık olarak birçok alanda kabul ettik. Kendisini anmayı boyun borcu bildik de başladık. Ruhu şad olsun.

Bu kısa hatırlatmadan geçelim bizim mevzuya. Özelde iş analizinde genelde de birçok IT rolünde hatırımızda daim taze tutmamız gereken bir bilgi olmalı. Pareto ile ilgilisi de var ki Vilfredo'yu da yad ettik. Zira, kurumların stratejilerini ve genel hedeflerini şirketin seçkin bir grubu oluşturur. Ve bu stratejilere göre kalan ahali çalışıp çabalayarak bu hedefe ulaşmaya çalışır. Yani %20 %80'nin nereye koşması gerektiğini belirler. Pareto muhtemelen burda biraz sapabilir. %20 biraz fazla gözüküyor. Az da olsa kurumun stratejileri biraz değişebilir ama unutmamak lazımki birçok kurum daha baştan stratejik hedeflerini belirler ve bu hedefleri üst düzey anlaşmalarda pazarlarlar. Örneğin, 10 milyon ciro hedefi olan bir e-ticaret şirketi bu hedefine göre bankalar, kargo şirketleri, firmalarla anlaşmalar yaparlar. Bu stratejiyi ancak olumlu yönde revize etmeyi önerebilirsiniz. Aksi halde başarısızlık önerilmiş olur ve bu hedefe götürmeyen her iş abesle iştigalden başka birşey değildir. 

Biz çalışanlar da, kendi alanlarımızda üniversitelerde dirsek çürütüp, işe başlayınca da birçok eğitimler ve iş deneyimleri elde ederek uzmanlaşmaya gayret ederiz. Yani profesyonel oluruz. Profesyoneller arasında da küçük farklılıklar olsa da genelde çözümler birbirine yakındır. Tek bir farkla ki kurum stratejileri dikkate alındığında insanlar aynı işte çok farklı tarz hareket edebilirler.

Kurum stratejilerini göz önüne alarak çalışanlar yaptıkları işlerin önüne stratejik hedefleri koyunca bazen kesin bildiği doğrudan ya sapar ya da vazgeçebilir. Diğer yandan büyük resmi görmeden hareket eden arkadaşlar ise mesleki doğruya göre hareket ederek küçük gerçeğin önündeki büyük gerçeğe aykırı davranırlar. Ve böyle davrandıklarını da belki de bilmediklerinden de memnuniyetsiz olurlar. Özellikle IT sektöründe oldukça yaygın bir kaos nedenidir.

Bazen kurumun çok açık ifade etmedikleri stratejileri de olabilir. Eğer kişiler bu stratejileri bir şekilde öğrenerek kendi payına düşen işi yapmaya başlamışsa işin gerçeklerinden öte stratejik gerçekleri referans almalıdır. Tabi stratejilerin etik olması önkoşulu her zaman geçerlidir.

Bu bağlamda iş analizinde ENTERPRISE ANALYSIS konusunu ayrıca ele alacağım.

Hepimize iyi eğlenceler:)

İş Analizde erken söylenen zararlı "Tamam"lar

İş analizi septik bir filozofun bolca soru sorması ve meseleyi irdelemesine benzetilebilir.

Öyle ki bir analiz tekniği olan 5 Why yöntemi ya da diğer adıyla kök-neden analizinde her bir ihtiyacın 5. kırılımına kadar nedeni inceleniyor.

Aslında iş analizinde esas olan ihtiyaçların nedenini en derin noktaya kadar sorgulamaktır.

Analiz yaparken ihtiyaç sahibinin isteklerini nasıl yaparım son amaçtır.

Peki iş analizi yaparken nedir öncelikli amacımız: Ne isteniyor? Niçin isteniyor?

Bunu da ancak sorgulayarak, soru sorarak ve dinleyerek yapabiliriz.

Anlamak için, öğrenmek için, empati kurabilmek için, mantıklı sebepleri yakalamak için bolca dinlemeli, kök nedenler iyice anlaşılmalı. 

Bazen zaman kısıtından, bazen etkilerini tahmin edemeyip talep basit görüldüğünden ya da en tehlikelisi olan soru sormak bir kalitesizlik göstergesi olarak görüldüğünden erkenden TAMAM, OLUR, YAPALIM, ŞURAYA BİR EKRAN KOYARIZ ile projelere ilk darbeler vurulmuş oluyor. Bu da zayıf analize neden olur ki yazılım projelerinde bu tür eksik analizler %60'a kadar ek maliyete neden olmaktadır. *

Bunun yerine, İNCELEYELİM, ARAŞTIRALIM, DEĞERLENDİRELİM ifadeleri daha ufuk açıcı ifadeler olup hem analiz yapan hem de ihtiyaç sahibi paydaşın zihin jimnastiği yapmasına yardımcı olur. 

İş analizi yapmış herkesin "Basit gibi gözüküyordu ama hiç düşünmediğimiz yerleri etkiledi" şeklinde bir analiz hikayesi vardır. 

Bu hikayeleri mümkün olduğunca az yaşamak için, projenin büyüklüğü veya küçüklüğüne bakmaksızın her ihtiyacın nedeni, diğer sistemlere olası etkileri, gerekliliği iyice değerlendirildikten sonra TAMAM denilmelidir.

* : Source: Business Analysis Benchmark, IAG Consulting

CBAP Sertifikası almalı mı?

Öncelikle şu konuda hepimiz aynı şeyleri düşünüyoruz ki haklılık payımız oldukça yüksek.

Sertifika para tuzağıdır. CBAP'a girmek için 450 USD sınav parası vermek zorundasınız.

Bir de 21 saat eğitim almış olmanız gerekiyor ki, bireysel çabalarla eğitim almaya kalktığınızda 1000 USD'den aşağı eğitim bulmak zor.

Eğer şanslıysanız kurumunuza ödetebilirsiniz ama eğer kurumunuzun böyle bir sorumluluk alması pek olası değilse CBAP'a sahip olmak için ödeyeceğiniz para en iyi ihtimalle 1450 USD (~4500 TL)'dir. İlk sınavdan geçemeyip 2.-3. sınavlara kalırsanız biraz daha ödemeye mahkum olursunuz.

Evet bu eleştirimizi yapalım.Ama yankı bulana kadar da serttifika mertifika almam diye düşünüyorsanız orada bir durup değerlendirelim.

Bugün Türkiye'de net olarak kaç iş analisti var bilemiyoruz. Bununla ilgili bir çalışma yok. fakat banka-telekom-finans-e-ticaret-teknoloji firmalarının sayısını hesaba katınca bu sayı 2000'den fazla olduğunu düşünüyorum. Peki kaç sertifikalı analist var? 20'yi geçmez. Yani yüzde 1.

Sertifikasız analistler kötü sertifikalılar iyi mi? Elbette hayır.

Fakat sertifikası olan analistler en kötü ihtimalle iş analizinin esaslarını belirleyen IIBA kuruluşunun yayınladığı BABOK'u yalayıp yutmamışsa da okumuş, internette geçen iş analizi ile ilgili birçok dokümandan haberdar olmuş, iş analizi ile ilgili blogları gözden geçirmiş, sınav sorularına çalışmış ve yaptığı işin hangi adımlardan oluştuğunu biliyordur. Yani bu işin bilimsel olarak nasıl yapıldığını bildiğini tescillemiştir.

Sertifika almamış analistler ise kendilerince iyi düşündükleri bir teknik üzerinde bir yol izleyerek ve kurumunun SDLC sürecine adapte olarak bir metod uyguluyordur illaki. Fakat kendine ve yaptığı işe değer katabileceği birçok bilgiden mahrum olabilir ve bundan dolayı da sağladığı katma değeri olması gerekenden düşük olabilir. (Genelde ihtimal yüklemleri kullandık ama bu ihtimal yüzde yüze çok yakındır. :) ) Gerçi genel olarak Türk kültüründe bilimsellikten ziyade bireysel fikir yürütmeye dayalı iş yapma yöntemi yaygın olduğundan, analistler için de aynı durumun olması olağan. Fakat bireysel yaklaşımları esas almak yerine uluslararası kabul görmüş esaslara dayanmak kesinlikle daha faydalı sonuç verecektir.

Nasıl ki bir hastanın tanısının konulması hastanın kendi hikayesini iyi anlatmasına ve doktorun da bu hikayeden doğru bir çıkarım yapmasına bağlıdır, aynen öyle de iyi bir ürünün ortaya çıkması, ihtiyaç sahibinin derdini iyi anlatıp analistin iyi yorumlamasına bağlıdır.

Bu durumda tıp eğitimi almış doktorun üzerine uzmanlık eğitimini ne kadar gerekliyse, iş analistinin de aldığı eğitimin üzerine iyi bir sertifika eklemesi o kadar gereklidir.

Bu arada; bu yazıyı yazarken sertifikamın olmadığını fakat sertifikaya hazırlık sürecinde olduğumu belirteyim :)

İŞ ANALİZİNİN 6 TEMEL KAVRAMI (BACCM)

İş analizi yapılırken birçok kavram ile çalışabiliriz. Fakat BABOK V3'te çok güzel bir model ile analistlere temel ama unutulmaması gereken bir model üretmiş. Adına da BACCM demiş ve patentini de almış. Yani, Business Analysis Core Consept Model. Bu modelde geçen 6 kavram ise analiz yaparken bizi çepeçevre sarmalayan ve içi oldukça dolu kavramlar. 

Stakeholder - Paydaş

Value - Katma Değer

Context (Condition) - Şartlar

Change - Değişim

Need - İhtiyaç

Solution - Çözüm

SıVaCı CaNSu olarak kodlayınca bende gayet akılda kalıcı oldu. Cansu ismindeki arkadaşlarımız umarım kızmaz. Çünkü bir erkek mesleğini kendilerine yakıştırdık :) Kusur ettiysek affola.

Ya da hikaye edecek olursak şöyle diyebiliriz. Paydaşlardan birisi Değer üretmek için Şartların Değişmesini istemiş. İhtiyaç kalmayınca farklı bir Çözüm bulmuş. 

Bu model İş analizinin input ve outputlarını veriyor bir anlamda. Ve bu modeldeki tüm kavramlar birbiriyle sıkı sıkıya ilişkili. Inputlar, Paydaşlar, Şartlar, Değişim,İhtiyaç olarak belirlenebilir. Bu durumda Katma Değer ve Çözüm birer Output olacaktır. 

Bu iş setinden biri hatalı olursa tüm analiz hatalı olur. Zincirleme kaza desek yanlış olmaz.Örneğin, Paydaşların analizi doğru yapılmazsa İhtiyaç tam anlaşılmaz ya da Çözüm yerine oturmaz. 

Analitik düşünce denilen o sihirli yaklaşım bu olsa gerek. Bir İhtiyaç sözkonsu. Bu ihtiyaç, bir problemin çözümü, yeni bir gereksinimin modellenmesi, yeni bir ürünün implementasyonu olabilir. Analist bu ihtiyaca katma değer sağlayacak çözüm üretmek için ihtiyacın etrafındaki Paydaşları, Şartları, Değişimleri ve İstekleri tüm detaylarına kadar irdeler. Ve sonuçta optimum çözümü önerir.

Keşke kavramlar kodlandığı kadar kolay ve hızlı şekilde de analiz edilebilse. O da olacak. Yeter ki her bir kavramı bir canlı olarak düşünüp bu canlılarla empati kurulabilsin. 

Talep Sahibi Analizi-Requester Analysis

Hani bir söz vardır, Önce, Söze bakarım söz mü diye, adama bakarım adam mı diye....

Bizim önümüze analiz edilecek bir talep gelince biz ne yapıyoruz.

Hoppaaaaa analize dalmadan önce önce talebe bakarım talep mi, talep sahibine bakarım yetkin mi diye.

Hasılı, Yazılımlar insanlar içindir.

Yazılımları talep edenler insanlardır. 

Bu açıdan bakıldığında, projeler analiz edilirken projeyi talep eden ile projenin hizmet vereceği insanların analizi de önemli bir proje aşaması olarak karşımıza çıkmaktadır. 

Bu yazıda talep sahibini niçin ve nasıl analiz edeceğimizi konuşalım. 

Yazılımlar talep edilirken birçok amaç hedeflenebilir. 

En başta, hangi amaca yönelik bir çalışma yapılacağını ve bu çalışmadan beklenen faydaları talep sahibi belirler. 

Örneğin, Bir çiftçi, depolarındaki ürünlerin maliyetini hesaplayacağı bir sistem oluşturmak istiyor olsun. Sistem üzerinden sattığı ve elinde bulundurduğu tüm ürünlere ne kadar yatırım yaptığı, her ürünün maliyetinin ne olduğu ve nihayetinde satıştan ne kadar kâr ettiğini hedeflemektedir. Böylece satış fiyatını daha doğru verecek ve kâr optimizasyonu yapabilecektir. Çiftçi, kâr optimizasyonunu bu şekilde yapabileceğini komşusunun bilgisayar mühendisi oğlundan aldığı fikirle netleştirmiştir.

Bu projeden yola çıkacak olursak en temelde aşağıdaki 4 ana sorunun cevabını bulmamız gerekir. 

Çiftçinin amacı : Ürün takip ve yönetim sistemi oluşturmak

Çiftçinin beklentileri: Her ürünün maliyetini bularak istediği kâr oranını ekleyerek satış fiyatını belirlemek.

İhtiyacın nedeni: Satış fiyatı belirlemede yaşanan zorluklar

İhtiyaç Nasıl Ortaya Çıktı: Öneri

Görüldüğü üzere Analiz yapılacağı ilk anda çiftçinin aklındaki temel hedefleri ve bu işin çıkış noktasını tespit etmek gereklidir. Bu adım birçok analist veya Proje yöneticisi tarafından zaten yapılmaktadır. 

Buradan hareketle ilk etapta Talep sahibinin çalışma üzerindeki etkisi hemen göze çarpmaktadır. Görüldüğü üzere amaç ve beklentilere yön veren talep sahibidir. Böyle olunca da tüm analizler bu amaç ve beklentiler üzerinden yapılacağı için tüm yazılım sürecini doğrudan etkileyecektir. 

Bu büyük etkiden dolayı talep sahibinin amaç ve beklentilerini hangi parametrelere göre belirlediği önemli bir konudur.Talep Sahibi amaç ve hedefleri belirlerken nelerden etkilenmiş ise ona göre kararlar ortaya koyar. Ortaya konulan amaç ve hedefler çok detaylı bir araştırma ve gözlem sonucu ortaya konulabildiği gibi, dışarıdan yapılan bir öneri, popüler yaklaşıma dayalı bir fikir veya karşılaştırma yöntemi ile oluşmuş olabilir. Bu parametreler Talep sahibinin amaç ve beklentilerindeki netliği göstermektedir.

Netice; Baktınız talep telep değil, gerekli tüm mercileri uyarın ve gerekirse talebin içeriğini sorgulayın. Baktınız talep eden yetkin değil, o topa hiç girmeyin ;)

Agile Business Analyst Roles

Agile Business Analist Roles and Responsibility diagram

Agile İş Analistinin Rol ve Sorumlulukları şeması

Bu roller aynı zamanda waterfall süreçlerde analiz yapanlar için de geçerlidir ama agile süreçlerde bazı fazlalıklar vardır. Umarım faydalı olur. 

Business Analyst Roles

Acceptance Criteria-Senaryo

-----------------------------

Analistlerin en büyük problemlerinden biri de aynı dil üzerinde henüz bilimsel bir uzlaşının tam olarak yerleşmemiş olmasıdır. Bu anlamda yazılım ilke ve prensiplerine yetişmemiz ve ortak dil konusunda aynı şeyleri konuşuyor olmamız gereklidir.

-----------------------------
Bu bağlamda en sık karıştırılan, karışıtılmadıında da doğru tanımlanmayan iki kavram vardır. Acceptance Criteria  ve Scenario (Senaryo).

-----------------------------

Burada ortak dil adına uluslararası kabul görmüş isimleri kullanmakta da fayda vardır. Böylece literatür tarama ve karşılıklı iletişimde de aynı dil üzerinden gidilir. Bu yüzden Acceptance Criteria kavramını türkçeleştirmedim. Yoksa bugün ingilizce bir kavramı çeviremeyecek kadar ingilizce bilmeyen analist olduğunu pek sanmıyorum. Bir kavramı çevirmek için ingilizcenin akıcı olması gerekmez.

-----------------------------

Önce kavramları kısaca tanımlayalım. Özetle formülize edecek olursak şöyle tanımlarız.

Acceptance Criteria "should be" der. Emreder. Requirement'in bir parçasıdır. Bir ihtiyacı karşılamak için en küçük kural parçasıdır. Adından da anlaşılacağı üzere bir ihtiyacı karşılamak için kabul kriterimizdir. AC tam olursa kabul edilir. AC tam olmazsa kabul edilmez ve testten kalır.
Senaryo Acceptance criteria'yı dinler ve emrin yerine gelip gelmediğini test eder. Test için birkaç farklı yol kullanabilir. Senaryo genellikle aşağıdaki şekilde tanımlanır.

Given: Senaryonun ön şartı
When: Senaryonun aksiyonu
Then: Senrayonun sonucu


Örnek verelim. Acceptance Criteria'yı AC olarak yazalım bundan sonra.

AC = Log out butonuna basıldığında kullanıcı sistemden çıkmalıdır.

AC gayet açık. buna 2 senaryo yazalım.

Senaryo1 = Müşteri login et. (given) Log out butonuna bas. (when) Müşteri hesaplarım menüsünü görmemelidir. (then)

Senaryo2 =  Ekrandaki linki kopyala (given), müşteriyi logout et (given). Linki browser adress bara yapıştır (when). Müşteri login ekranı çıkmalıdır. (Then)

Bu örneği incelediğimizde bir AC için birden fazla senaryo ihtiyacı olabileceğini görüyoruz. Bu da şöyle bir basit kural karşımıza çıkarır. Senaryolar AC'den türer ve her zaman senaryo sayısı AC'den büyük ya da eşittir.

Örnekteki diğer bir özellik ise bir senaryo içerisinde given, when ve then kalıbı her zaman kullanılabilir. Ve her biri birden fazla sayıda olabilir. Senaryo2'de 1 given 2 when ve 1 then vardır. Bu sayılar da ihtiyaca göre farklılık gösterir.

Rol ve Sorumluluk açısından da iki işin sahibi farklıdır. AC'ler Story'nin parçalarıdır. AC'ler Analist veya Product Owner tarafından belirlenir. Senaryo ise Test Uzmanı (QA) tarafından belirlenir ve her test adımında kullanılabilir. (Fonksiyonel Test, UAT veya Sign-off gibi testler kastediliyor)

Ve önemli bir NOT: Test uzmanının olmadığı yerde Analist Test uzmanı görevini yapar. Yapmalı mı? Elbette ki hayır. Senaryo çıkarmak ve test için gerekli sabır ve çok yönlülük apayrı bir yetkinlik gerektirir ki 1 analist ve 3 yazılımcının olduğu her yerde 1 Test uzmanına ihtiyaç vardır.

İHTİYAÇLARIN ÖNCELİKLENDİRİLMESİ: LEGO TIME

İHTİYAÇLARIN ÖNCELİKLENDİRİLMESİ: LEGO TIME

Kapsamlı projelerde hangi ihtiyaçların önce yapılacağı çok önemlidir. Şöyle düşünebiliriz. 300 parçalık bir lego setimiz var ve bu setten bir ev yapmak istiyorsanız sivri parçaları çatı yapmak için sona bırakırsınız. Pencere ve kapı şeklindeki parçaları en başta kullanırsanız evin ortalarına geldiğinizde yerleştirecek kapı bulamazsınız.  Bu yüzden bu parçaları evin  temelini oluşturduktan sonra kullanırsınız.  Bir projenin kapsamı da belli olduktan sonra ihtiyaç listesi (requirements) üzerinden bir önceliklendirme yapılmalı ve bu öneliklendirmeye göre projeye start verilmelidir. Projeye başlandığında özellikle en yüksek öncelikli ihtiyaçların hangileri olduğu belli olmalıdır.

Peki, nasıl önceliklendiririz?  Agile ve Sürekli teslim (Continious Delivery) metodolojileri uygulanan yerlerde bu soru daha da önemlidir. Çünkü belirli dönemlerde ürünün biten kısımları live ortama alınabildiğinden müşteri için öncelikli olan fonksiyonlar belirlenmelidir. Diğer metodlarda da teknik mimarinin doğru kurulması ve sonraki ihtiyaçların daha hızlı deliver edilmesi açısından doğru önceliklendirme yapılmalıdır. Önceliklendirme için birçok teknik olmakla beraber bana göre en efektif yöntemler aşağıdakilerdir.

MoSCoW: Bu yöntemde herbir requirement önemine göre Must, Should, Could, Would modalları ile belirlenir. Buradaki önem, işi isteyen kişinin verdiği önem derecesidir. Teknik ve mimari öncelikler ikinci plandadır. Must olandan başlanır. Should olanlar ardından bitirilir. Could olanlar kaynak ve zaman sorunu yoksa en sonda tamamlanır. Would olanlar yapılmaz fakat bu fonksiyonların ileride olacağı varsayılarak projenin teknik ve iş mimarisi kurgulanır. 

Must Have	Kritik task. Workaroundu olmayan ve proje için kritik task. Yapılmadığında proje tamamlanmış sayılmaz.
Should Have	Yapılması oldukça önemli olan konu. Yapılmadığında proje başarılı sayılmaz.
Could Have	Yapılması istenen fakat kritik olmayan tasklar. Yapılmadığında müşteri memnuniyeti düşebilir. Proje tamamlanmış ve başarılı sayılır.
Would Have (Won’t)	Yapılması planlanan fakat bu aşamada projenin dışına atılan tasklar. Bir anlamda bu faz dışındaki maddeler

HI/LO Etki-Zorluk Düzlemi: Buna Affinity Chart da diyenler vardır. Bu yöntem XY düzleminde Etki ve Zorluk düzeyine göre tüm ihtiyaçların gruplanması esasına dayanır.  Etki iş biriminin önceliği iken, Zorluk ise yazılım sürecinin zorluk derecesini ifade eder. Projelerin kritik parçalarının müşteriye gösterilmesi gereken projelerde oldukça etkin bir yöntemdir.  Düzlemde Yeşil bölge en başta Kırmızı bölge en sonda yapılır. Diğerleri ise tamamen müşterinin isteğine göre önceliklendirilir.

HLO Düzleminde Önceliklendirme

Bu iki yöntem sonunda ortaya aşağıdaki gayet basit bir sıralama listesi ortaya çıkacaktır. Önemli olan bu listenin her an müşteriye göre yeniden düzenlenmesidir. Bir projede belki de en güncel tutulması gereken bilgi “ÖNCELİK” bilgisidir.

Öyle projeler olacaktır ki, müşteri en başta gördüğü ihtiyaçlara göre tüm projeyi şekillendirecektir.

Sonuç olarak; 

ÖNCELİKLENDİRME EN ÖNEMLİ ÖNCELİĞİMİZ ARASINDA OLMALIDIR   

İş Analisti rolü hakkındaki en temel yanılgı

İş analizinin anayasa kitabı olan BABOK’ta analist tanımlanırken REQUIREMENT sözcüğünden bahsedilmez. SOLUTION geçer. O zaman birçok analistin kendini tarif ederken veya işverenler tarafından iş analisti ararken düştüğü en temel yanlışlardan veya eksikliklerden biri de “Analist ihtiyaç analizi yapar” tanımıdır. BABOK der ki “Analyst recommends solutions”. Solution nedir diye devam eder tarifine: “Solution enables organization’s needs, solves a problem and takes an advantage of oppurtinities”. Buraya kadar Requirement tanımlamalarda yoktur. Sonrasında şunu der ama. “Requirements help to solve problem and achieve an objective”. Demek ki ihtiyaçlar çözüm üretmek için yardımcı elemanlardır. Yardımcı elemanlar bir işin en temel tarifinde yer teşkil etmemeli.

Buradan çıkacak sonuç şudur. Analist ihtiyaçları analiz eder ama bundan çok daha öncesinde organizasyonun mevcut durumunu anlayıp (ki bu ifade de BABOK’ta vardır) bu duruma uygun çözümleri tavsiye eder. Sonrasında oluşan fikir birliği ile (ki bu fikir birliği analistin önerdiği çözümlerin dışında bir öneri de olabilir) oluşan çözüm önerisine yardımcı olabilecek ihtiyaçlar belirlenir.

Yazıyı uzatmayıp her analistin bu konuyu sıkılmadan tekrar düşünebilmesini amaçladım. Çok önemli bir konu. Çünkü yanlış başlanan her iş yanlış biter. 

Agile Sistemlerde Analist ve Product Owner?

Kurumların Bilişim politikalarına göre istihdam ettikleri 2 tür analist vardır.

Bir grup ağırlıklı olarak yazılımı iyi bilen yazılım ekibiyle teknik konuşabilen ve gerektiğinde yazılım ve diğer mimari konularda yorum yapabilen Sistem Analisti vasıflı kişileri tercih ederler.

Diğer grup işkolunun tüm ihtiyaçlarını sonuna kadar detaylandırabilecek ve bunu yazılıma olduğu gibi aktaracak, mimari ve yazılım konularında suya sabuna dokunması arzu edilmeyen İş Analistlerinden yana tercihlerini kullanırlar.

Bu iki pozisyon da Bilişim grubun bünyesinde genellikle istihdam edilir. Ve elbetteki domain bilgisi (iş bilgisi) yeterli kişilerdir. Ve Analistler işi isteyen iş kolu (SME) adına karar veremezler. her zaman ihtiyacı iş kollarından alır ve analiz ederler.  

Agile yöntemlerdeki Product Owner rolü ise İş analisti gibi davranan ve ihtiyaçları detaylı bir şekilde yazılıma aktaran fakat işi isteyen iş biriminden birine daha yakın bir pozisyondur. Bu pozisyon hem işbirimi olarak ihtiyaçlara karar veren hem de bu ihtiyaçları detaylandıran kişidir.

Şimdi Türkiye özelinde bakacak olursak: Product Owner İş Analisti pozisyonuna daha yakındır. Fakat İş analisti iş kolu (SME)’ndan biri olmadığı ve ihtiyaçlara ilişkin karar veremediği için Agile metodolojinin etkinliği açısından yeterince kapsamlı yetkilere sahip değildir. Agile sistemlerde iş kolu (SME) ile yazılım arasındaki “Customer Collobration” döngüsünde iş analisti ve iş kolu (SME)nun farklı rollerde olması karar hızını azaltmaktadır.

Sonuç:  Agile süreçlerde Product Owner olarak tanımlı bir rol yoksa, İş analistine SME tarafından daha fazla karar alma yetkisi verilmelidir. Bir iş analistinin bu yetkiyi alabilmesi iki şeye bağlıdır. Birincisi, Analist karar alma konusunda yeterliliğe sahip olmalıdır. İkincisi ise İş analisti domain bilgisini mümkün olduğunca ileri bir seviyeye taşımalı ve SME yönetimi tarafından iş kolu kararlarını almaya yetkili hale getirilmelidir. 

Scrum vs Kanban

Agile manifestonun sitesini açtığımızda karşımıza çıkan dört manifestodan ilki şudur.

“interactions and individuals over processes and tools”

(agilemanifesto.org)

Agile manifestonun 17 fikir babası, yapılandırılmış süreçleri ve buna bağlı çeşitli araçlardansa interaktif  iletişimi tercih ettiğini belirtir. İşin sonuca ulaşması için, düzenli toplantılar, süreç toollarında günlerce uğraşılarak çizilmiş labirent gibi süreçler, katı hiyerarşiler, …. yerine takımın iletişimi ve etkileşime dayalı hızlı aksiyon alması agile manifestonun ilk kuralıdır.  

Hal böyleyken katı agile metotlarından söz etmek agile ruhuna çok da uygun düşmeyebilir. Çünkü her metot kendi içinde kurallar, süreçler ve yapılandırılmış araçlar içerir haliyle. Ne var ki agile proje geliştiriyorum deyip manifesto kurallarını ezberleyip tekrarlayarak proje geliştirilmesi de mümkün olmayacağı için bazı yöntemler esas alınabilir.  İnsan doğası işte kuralsız yaşayamaz…

Neyse. gelelim  Scrum ve Kanban ilişkisine. Burada Scrum ve Kanban’ın (özellikle de scrum’un)  tekniklerini anlatmayacağız. Esas olarak, temel prensiplerini ve temel farklarını ortaya koymaya çalışacağız.

İkisi arasında çok temel 2 fark vardır.

Birinci Fark, scrum temel olarak sprint bazlı olarak ilerler. Bu yüzden kesikli teslimat söz konusudur. Kanban ise süreklidir. Proje başlangıcından sonuna kadar sürer.

İkinci Fark, Scrumda yapılacak işlerin boyutu her sprint öncesinde development takımı tarafından belirlenir. Kanbanda ise WIP limitine göre her adımdaki limite göre sürekli doldur boşalt yapılır. Hangi işin yapılacağı development tarafından belirlenmez.

WIP (Work In Progress) Limiti: Proje başlamadan önce iş akışının en yavaş noktasına göre belirlenir. Bu yöntem ilk Toyota’da ara stokları düşürmek için kullanılmıştır. Örneğin; Yazılım üretim hattında 3 temel akış bölgesi olsun. Önyüz yazılımı, servis yazılımı ve test.  Bu akışta servis yazılımı yapacak kişi çok yoğun ve servis işleri çoksa bu kişinin hızına göre servis yazılımı akış noktasına göre bu kişiye bir seferde en fazla kaç task verilecekse WIP bu olur.

Bu iki farkı aşağıdaki şekil üzerinde izah edecek olursak ;

A, B, C gibi harfler her bir taskı ifade eder. Product Backlog SME ile üzerinde mutabakata varılan “Task-Story-Epic” listesidir.

SCRUM KANBAN AKIŞ

Kanban’da Proje başladıktan sonra Product Baclog üzerinden iş akmaya başlar. Aşağıdaki kanban boardda  herhangi bir anda todo bölümünde ilk 3 LŞT taskları olsun. Bu adımda In Progress adımına gidecek 3 task bellidir. Bu tasklardan örnğin l taskı çekildikten sonra Product Backlog’tan sorumlu kişi kendi belirlediği Q taskını Todo adımına ekler. (WIP Limit 3 olduğu için o kolonu maksimum 3 yapabilir)  Hangi taskı ekleyeceğini SME ile yaptığı önceliklendirmeye göre belirler. Aynı şekilde Todo adımındaki 3 tasktan hangisini In Progres adımına çekeceğine takım üyeleri karar verir. Bu süreç tüm product backlog bitene kadar tekrar eder.

KANBAN BOARD

Dikkat edilirse Kanban Board üzerinden hiçbir adımda WIP’ten fazla task bulunmuyor ve tasklar bitene kadar board kolonları boş kalmıyor. Boş kaldığı durumda takımda ilgili adımdan iş alacak kişiler kilitlenir ve boş kalabilir.

Scrum akışına bakarsak,  her sprint öncesinde SME önceliğine göre takım kendi yapabileceği kadar task üzerinde uzlaşır. Sprint 3 için bakacak olursak takım O,S,Z,Ş,Q,L  tasklarını bitireceğini taahhüt etmiştir. Bu durumda takım sprint sonuna kadar bu 6 taskı teslim etmek zorundadır. Sprint başında bu 6 task aşağıdaki gibi boarda eklenir. Bu board üzerinde sadece bu 6 task hareket eder.

Sprint sonunda bu 6 task bitirilir. Sonraki Sprinte geçildiğinde tüm backlog taskları bitene kadar aynı şekilde sprintler devam eder.

SCRUM BOARD