Yazılım Geliştiren Küçük Ölçekli Bir Organizasyon İçin Scrumban Yaklaşımı ve Oyunlaştırma Uygulaması

Transkript

1 Yazılım Geliştiren Küçük Ölçekli Bir Organizasyon İçin Scrumban Yaklaşımı ve Oyunlaştırma Uygulaması Murat Yilmaz 1,3 and Rory V. O Connor 2,3 1 Çankaya Üniversitesi, Ankara, Türkiye myilmaz@cankaya.edu.tr 2 Dublin Şehir Üniversitesi, İrlanda 3 Lero, İrlanda Yazılım Mühendisliği Araştırmaları Merkezi, İrlanda roconnor@computing.dcu.ie Özet Çevik metotların yazılım projelerindeki genel dinamik ve sağlanması hedeflenen amaçlar doğrultusunda melezlenmesi son yıllarda yazılım sektöründe sıkça uygulanmaya başlayan rutin bir pratik halini almaktadır. Böyle yaklaşım yardımı ile çevik süreçler arasında sistematik bir özelleştirme sağlanarak, takım ve süreç üretkenliklerini açısından oluşabilecek problemlerin kontrol altına alınması hedeflenmektedir. Bu makalede, küçük ölçekli bir yazılım geliştiren organizasyon için Scrum yönteminden, Scrumban yöntemine geçiş süreci ve oyunlaştırma teknikleri kullanılarak sağlanan süreç iyileştirme uygulaması anlatılmıştır. Uygulama sırasında duruma özel olarak kurgulanan odak grup çalışması, anket çalışması ve yarı yapılandırılmış görüşmeler doğrultusunda kurgulanan araştırma yöntemi açıklanmıştır. Sonuç olarak, bu çalışmadan elde edilen gözlemler göstermektedir ki böyle yaklaşım sayesinde gerek örgütsel, ve gerekse yöntemsel bağlamda bazı iyileştirmeler sağlanabilmektedir. 1 Giriş Yazılım geliştirme, yazılımın üretim süreçleri sırasında gerçekleşen karmaşık teknik ve sosyal aktivitelerin bütününe verilen isimdir. Bu aktivitelerin planlanma şekilleri projenin durumuna, türüne veya yazılım geliştiren organizasyonlarda yerleşmiş kültüre göre farklılıklar gösterdiğinden kullanılan metodolojilerin genelleştirilmesi oldukça zordur. Yazılım geliştirme süreçleri geçen yirmi yıl içerisinde müşteri gereksinimlerinin dinamik olarak değişmesi nedeniyle önemli değişikliklere uğramıştır. Bu değişikliklerin en önemlisi daha önce üst yönetimde olan teknik bir çok sorumluluk ve karar mekanizmalarının yazılım geliştiren ekiplere terk edilmesidir. Yazılım endüstrisindeki tanımı ile çeviklik, ürün geliştirme sırasında kullanılan sürecin müşteri ihtiyaçlarına hızlı karşılık verebilme yeteneğidir [1]. Sektörün getirdiği yeni yapılanma ile birlikte, şirketler giderek klasik tarz yaklaşımlara alternatif bir felsefe getiren çevik yazılım geliştirme yöntemlerini tercih etmeye başlamışlardır. Bu yaklaşımların en popülerlerinden iki tanesi Scrum ve Kanban dır. Scrum, artırımlı üretim yapısını endüstride kabul edilmiş süreç mühendisliği ve

2 kontrol sistemlerinden almıştır. Sürekli geri bildirim, kısa metrajlı planlar, ve gereksinimler önem sırası ile uygulamaya geçirildiği için hedefe küçük ama emin adımlarla yaklaşılmasını mümkün kılar. Diğer taraftan, endüstriyel alanda sıkça kullanılan Kanban yaklaşımı çevik yaklaşımların zaman kutulu süreçleri yerine süreklilik içeren akış tabanlı alternatifini önermektedir. Kanban, yazılım geliştirme süreçlerinde bulunan iş akışlarını genellikle bir pano vasıtası ile görselleştirmek ve dolayısı ile işlevselleştirmek için düşünülmüş bir yöntemdir. Yaklaşım, işin görsel sunumu ile birlikte yapılacak işlerin belirlenmesi, önceliklendirilmesi, miktarının sınırlandırılması, minimal pazarlanabilir özelliklerin belirlenmesi ve süreçlerin bir havuzdan çekilmeye başlanması esaslarına dayanır. Takım üretkenliğini arttırmak için düşünülmüş bir araç olan Kanban panosu sayesinde, bir yandan bitmiş ve süren işler net olarak gözlenebilirken, diğer yandan tüm sürece ait ölçüm ve geri beslemeyi kolaylaştırır. Son on yılda yapılan bir çok araştırma göstermektedir ki, bir çok yazılım geliştiren organizasyon çevik yaklaşımları kendi ihtiyaçlarına göre düzenleme ihtiyacı duymuşlardır [2]. Scrumban yaklaşımı, Scrum ve Kanban çevik süreçlerinin melezlenmesi ile oluşturulmuş; aşırı değişken kullanıcı veya müşteri hikayeleri ve kodlama hataları ile baş etmek için kurgulanmıştır [8]. Bu melez yaklaşım, Scrum sürecinin özünde bulunan zaman kutusu tabanlı koşu (sprint) özelliğinin uygulama sırasında işlevselliğin azaldığı, fakat bu yaklaşımın içerdiği günlük Scrum toplantıları ve diğer bazı pratiklerinin kullanılabilir olduğu durumlar için düşünülmüştür. Bu yaklaşım kullanılarak bir yazılım takımının iş akışı, her kullanıcı hikayesi için asgari en çabuk tamamlanma zamanına yönlendirilirken ekibin elemanlarının hiç birisinin görevsiz kalmamasının sağlaması hedeflenir. Son zamanlarda, yazılım geliştiren bir organizasyonda çalışan bireylerin motivasyonlarını arttırmak için yeni ve popüler iş süreç iyileştirme yöntemlerinden biri olarak kabul edilen, oyunlaştırma kullanılmaktadır. Oyunlaştırma; oyun geliştirme süreçlerinde kullanılan öğelerin (örn: puanlama sistemi, lider tablosu, bröveler) oyun geliştirme dışındaki alanlarda kullanılması olarak tanımlanmaktadır [14]. Genellikle, iş geliştirme süreçlerinde fayda sağlamak için kullanılmaktadır. Oyunlaştırma kullanılarak bireylerin motive edilmesi ve kişilere sıkıcı gelebilecek rutin iş süreçlerinin eğlenceli ve etkileşimli hale getirilmesi planlanmaktadır. Oyunlaştırma uygulamaları ile bireylerin üretkenlik artırımının sağlanması ve dolayısıyla şirketlerin ve kurumların verimlilikleri ve örgütsel kalitesinin yükseltilmesi hedeflenmektedir. Bu makalenin devamı şu şekilde oluşturulmuştur. Bir sonraki bölümde, Kanban ve Scrum arasındaki ilişki ve Scrumban melez yöntemi açıklanacaktır. Üçüncü bölümde, oyunlaştırma kavramı açıklanacak ve oyunsal öğelerin yazılım mühendisliğinde yapılmış uygulamalarından bahsedilecektir. Dördüncü kısımda, araştırmada kullanılan süreç modeli sunulacaktır. Son olarak, beşinci bölümde ise çalışma sırasında elde ettiğimiz bazı öncül sonuçlar sunularak, ileride yapılması planlanan uygulamalar ile ilgili genel bilgi verilecektir.

3 2 Çevik Yazılım Geliştirme, Scrum ve Scrumban İki binli yılların başlarında, klasik yazılım geliştirme metodolojileri değişen gereksinimlerle yeterince iyi bir şekilde baş edemeyince çevik yazılım metotları gündeme gelmeye başlamıştır. Kolektif olarak çevik metotlar sistem tasarımının yazılım projesinin ilk zamanlarında detaylandırılmasındansa en hızlı şekilde ürün oluşturmayı hedeflemiştir. Çevik perspektif ürünün çalışan bir kısmının en erken şekilde paydaşlarla paylaşılmasını ve sorun giderme süreçlerinin en kısa zamanda başlamasını ön görür [6]. Bu vizyon Humprey nin gereksinim belirsizliği ilkesi ile desteklenmektedir: Bir yazılım sistemi kullanıcıları tarafından test edilmeden önce tüm gereksinimleri belirlenemez [7]. Boehm bu tür yaklaşımları hafif sıklet metotlar olarak kabul nitelendirmiştir [1]. Çevik yazılım süreçleri bir yandan yinelenen yazılım geliştirme metodunun temel kabul ederken diğer taraftan Cukburn un belirttiği hafiflik ve sadelik temelleri ile yazılım projelerinin yönetilebileceği kabulüne dayalıdır. Çevik yaklaşımlar insan tabanlı olup, sözlü iletişimin ve örtük bilginin takım ilişkilerindeki önemini vurgular [6]. Scrum kelimesi rugby oyunundan gelen oyuna özel bir kilitlenme durumundan türetilmiştir [11]. Bu yaklaşım iyi kurgulanmış yazılım takımlarından beklentiler doğrultusunda elde edilebilecek çalkantılı ortamlarda yüksek verimlilik almak için düşünülmüştür. Scrum yazılım geliştiren organizasyonu küçük, çapraz fonksiyonlu, farklı görevlerde çalışabilen ve kendi kendini organize edebilen takımlara dönüştürürken, yapılacak işi de küçük ve net çıktılar üzerinden planlanmış teslimatlar olarak tanımlar [10]. Bu bilgiler doğrultusunda örgüt ve öncelik sırasında konulan işler sıralanarak işlerin sürecekleri zaman kestirilmeye çalışılır. Klasik yaklaşımların tersine, Scrum zaman tabanlı, koşu adı verilen, sistematik yinelemeler doğrultusunda ürün veya çalışan dağıtılabilir bir yazılım parçası üretimini hedeflemektedir. Müşteri ile beraber öncelikler ve genellikle bir ila dört hafta arası süren koşu sonucunda da teslimat zamanları belirlenir [6]. Scrum ve Kanban, çevik yöntemler arasında küçük ve orta ölçekli yazılım firmaları tarafından en çok kullanılan metotlarıdır. Bu iki yaklaşımın ortak özelliği bilgi tabanlı bir çalışma ortamında bireyler ve takımlar arası iş birliğine dayalı uygulamaları desteklemeleridir. Scum yinelemeli ve artırımlı yapısı ile her koşu sonucunda çalışan bir parça yazılım üretimini hedeflemektedir. Bu yöntem yazılım geliştirme süreçlerini önceden tanımlanmış grup toplantıları, kişilere atanmış net roller ve üretilen yapay süreç olguları yardımı ile yönetmeyi hedeflemektedir. Uygulamaları sırasında yinelemenin otuz gün içinde tamamlanması ve günlük toplantıların on beş dakikayı geçmemesi hedeflenir. Diğer taraftan Kanban metodu son yıllarda yazılım şirketleri tarafından daha fazla tercih edilen bir yöntem olmaya başlamıştır [10]. Bu metot, Yalın (Lean) yazılım geliştirme ilkeleri üzerine kurulmuştur. Yazılım ürününün pazarlanabilir fonksiyonlarının öncelikli olarak kodlanması, iş akışının görselleştirilmesi ve yapılan işin sınırlandırılması yardımı ile verim artırımı amaçlanır. Scrumban, belirli Scrum pratiklerinin Kanban ilkeleri ile melezlenmesine verilen isim olarak adlandırılabilir [8].

4 3 Oyunlaştırma Oyun tasarımı ve geliştirme süreçlerinde kullanılan temel öğe ve kavramların oyun üretimi dışındaki alanlarda kullanılmasına oyunlaştırma denmektedir [4]. Oyunlaştırma yaklaşımı özellikle iş süreç geliştirme ve modelleme alanlarında sıkça kullanılmaya başlanmıştır. Oyunlaştırma bireylere sıkıcı gelebilecek iş süreçlerinin daha eğlenceli hale gelmesine yardımcı olabilmektedir. Ayrıca, bu tür bir yaklaşım sayesinde bireylerden alınacak geribildirim de ivmelenebilecektir. Oyun tasarım elementlerinin sahip oldukları en temel özellikler; (i) tanımlı amaçları ve kuralları, (ii) zorlayıcı öyküsü, ve (ii) kısa vadeli çabuk başarılabilir görevler üretebilmeleridir. Oyunlaştırma yönteminde amaç, bu tür yaklaşımların iş süreçlerine uygulanması ile süreç kalitesinin ve insan etkileşiminin iyileştirilmesidir [14]. İnsan doğası itibarı ile oyun oynamaya yatkın (sosyal) bir yapıdadır [9]. Bazıları yarışmaktan, bazıları başarı ve prestij kazanmaktan, bazıları da keşif etmekten veya sosyalleşmekten hoşlandığı için oyun oynamayı tercih etmektedir. Oyunlaştırma çıkarımların sonuçları etkilediği prensibi üzerine kurulu bir motivasyon çatısı olarak da kabul edilebilir [3]. Bu yaklaşım, sistematik olarak bireylerin motivasyonun artırılması; küçük ve ölçülebilir hedeflerin düzenli ve anlık geribildirim ile desteklenerek insanların durum ve olaylarla en çabuk şekilde etkileşime geçmesini sağlamak için düşünülmüştür [14]. Oyunlaştırma çalışmaları insan-insan veya insan-bilgisayar etkileşimini en üst düzeye çıkartılmasını hedefler. Bu bağlamda öncelikle neyin ödüllendirilebileceği, bireylerden hangi tür davranışlar beklenildiği ve en önemlisi bireylere ne tür (anlamlı) seçenekler sunarak bireyler ve sistem arasındaki bağlantının sağlıklı olarak sürdürülebilmesi hedeflenir. Yapılan bazı vaka çalışmaları göstermiştir ki insan beyni sürpriz ödüllendirmelerden hoşlanmaktadır. Davranışsal oyunlaştırma tasarımı sırasında bireylere durum tabanlı olarak dört farkı çeşit ödül vererek güdüleme sağlanabilmektedir. Bu ödül tipleri, (i) her koşulda alınabilen ödül, (ii) etkileşim karşılığı alınabilen ödül, (iii) bir şeyi tamamlama sonucu alınabilen ödül, ve son olarak da (iv) performans tabanlı olarak alınılabilen ödül olarak sıralanabilir [13]. Bu ödüller, üç farklı şekilde, (i) sürekli ödüllendirme, (ii) sabit oranlı ödüllendirme, ve değişken şekillerde ödüllendirme olarak kişilere sunulur. Oyunlaştırma tasarımlarında önemli yer tutan geribildirim döngüleri yardımı ile bireyler istenilen davranış şekillerine doğru yönlendirilirler. Bunun yanı sıra oyunlaştırma uygulamalarında yararlı olabilecek bir başka yaklaşım olan cognitivism, bireylerin davranışlarına neyin sebep olduğunu araştıran bir yol haritası izler. Bu yaklaşım yardımı ile içe ve dışa yönelik motivasyon türlerinin oluşması için öne çıkan içsel ve dışsal ödül gibi kavramlar ve oyunlaştırma sistemlerindeki kullanılabilirlikleri incelenebilir. Dışsal motivasyon ödül kazanma güdüsü veya ceza korkusu ile sağlanan bir motivasyon şekliyken, içsel motivasyon bireylerin içinden gelen bir arzu yardımı ile güdülenmesi esasına dayanır. Werbach ve Hunter a göre [13] oyunlaştırma, bir tasarım süreci olarak, altı basamakta uygulanmalıdır (bkz: Figüre 1).

5 Şekil 1. Oyunlaştırma Tasarım Süreci [13] İş amaçlarının tanımlanması: Oyunlaştırma kurgusunun iyi çalışması için tasarımcının sistemin amaçlarını çok iyi kavramış olması gereklidir. Sistemin kuruluş amaçları sıralanmalı ve ikinci aşama olarak kurulum amaçları önem sıralarına göre derecelendirilmelidir. En sıkça karşılaşılan uygulama hatalarından birisi oyun öğelerinin amaçlar belirlenmeden ve daha önemlisi bu amaçlar gerekçelendirilmeden, hızlı bir şekilde uygulanmaya çalışılmasıdır. Bu liste tasarım sırasında sıkça ziyaret edilmeli öncelikler yinelemeli bir şekilde gözden geçirilmelidir. Hedef davranışlar tasarlanması: Birinci basamakta neden oyunlaştırdığımızı açıkladıktan sonra; bu basamakta katılımcıların nasıl davranmasını hedeflendiği açıklanmalıdır. Bu basamakta sistem için düşünülen ölçekler de belirlenebilir. Hedef davranışlar somut, duruma özgü ve birinci basamakta tanımlı iş amaçları doğrultusunda oluşturulmuş olmalıdır (örn: kullanıcıların haftada üç gün egzersiz yapılının sağlanması, kişilerin Twitter hesaplarında bir şey paylaşmalarının sağlanması, vb.). Tüm tanımlı davranışlar ölçeklendirilmelidir. Bu ölçeklendirmeye örnek olarak bir puan veya ün sistemi gösterilebilir. Ayrıca günlük aylık kullanıcı sayısı ve kullanılma zamanlarındaki farklar da başarı ölçümü aracı olarak kullanılabilir. Oyuncuların tanımlanması ve modellenmesi: Sistemi kimlerin kullanacağı ve kullanıcıların nasıl motive edilecekleri ve birbirileriyle olan ilişkileri incelenmelidir. Bu bireylerin içsel ve dışsal motivasyon kaynakları incelenerek kişiler gruplandırılmalıdır. Segmentasyon sayesinde Bartle in oyuncu tipleri (başaran, kaşif, sosyaleşici, öldürücü) belirlenerek tasarım sürecine olan etkileri incelenmelidir [14]. İyi şekilde tasarlanmış bir sistem farklı oranlarda da olsa bu dört oyuncu türünden içerdiği kabul edilebilir.

6 Aktivite döngülerinin tertiplenmesi: Oyunlaştırılmış bir sistemin oyun benzeri olan yapısı doğrultusunda akış döngülerinin lineer olarak tanımlanmış olmaması gereklidir. Bu döngüler iki ana aktiviteden oluşur: Angajman düğümleri oyuncuların mikro düzeyde yaptıkları davranışları yönlendirir ve geribildirim gibi en önemli güdüleyiciyi oluşturur. İkinci olarak, ardışık ilerleme basamakları oyuncunun oyundaki ilerleme hızını ve amaçları yönlendirir. Örneğin böyle bir sistemde en klasik yaklaşım, birinci seviye ikinci seviyeye göre daha kısa ve kullanıcıyı bir şeyler başarmış şekilde motive eden bir kurgudur. Oyunsalın zorluğu ve oyuncunun sistemdeki gücü bu döngüler yardımı ile dengelenir Eğlencenin tasarlanması: Bu basamakta oyuncuların sisteme gelmeye ve sistemde kalmaya ne kadar güdülenebildikleri incelenerek, sistemin daha ne kadar eğlenceli hale getirilebileceği araştırılır. Lazaro oyunlarda gözlenebilecek dört çeşit eğlence türü tanımlamıştır; (i) kolay eğlence: basit eğlenceli ve hafif aktiviteler, (ii) zor eğlence: karışık üzerinde uğraşılması gerekilen zorlayıcı kurgular, (iii) insan eğlence: sosyalleşme ve başkaları etkileşme esasına dayalı aktiviteler, (iv) ciddi eğlence: oyuncuların yaptıkları şeyin anlamlı olduğuna inanarak eğlenmesi. İş için gerekli araçların kullanılır hale getirilmesi: Bu aşamada diğer basamaklarda derlenen bilgilerin ışığında bir yol haritası kurgulanarak gerekli tasarımsal kararlar alınır. 4 Yöntem Bu çalışmada kullanılan yöntem iki aşamadan oluşmaktadır. Birinci aşama; Scrum yaklaşımı kullanılarak ürün geliştiren, küçük ölçekli bir yazılım şirketinin yazılım geliştirme metodolojisinin Scrum yaklaşımından Scrumban a taşınmasıdır. İkinci aşama ise oyunlaştırma çatısı ve teknikleri kullanılarak yazılım geliştirme sürecinin iyileştirilmesinin sağlanmasıdır. Bu dönüşüm sayesinde bireyler arasındaki etkileşimin arttırılması ve kişilerin motivasyonlarının modellenmesi hedeflenmektedir. Bu çalışma, ciddi oyunlar ve interaktif yazılımlar geliştiren orta ölçekli bir firmada gerçekleştirilmiştir. Çalışmanın başlangıcında firmadaki tüm bireylerle birlikte yapılan bir odak grup çalışması ile çeviklik-disiplin ilişkisini etkileyen faktörler belirlenmiş, yazılım geliştiren bireyler önce Scrumban konusunda bilgilendirilmiş, daha sonra bir anket yardımı ile durum tesbiti yapılmıştır. İkinci aşama olarak, yazılım geliştirme süreci Scrumban a taşınımış ve altı aylık bir süre sonrasında aynı anket tekrarlanmıştır. Bulgular ışığında, aynı kişilerle oyunlaştırmanın iş süreç modeline nasıl uygulanacağı tartışılmıştır. Araştırmanın bitiminde aynı anket çalışması tekrarlanarak şirket personeline iyileştirme ve tasarlanan süreçler ile ilgili görüşleri sorulmuş, bu bilgiler ışığında öncelikle iyileştirme süreci incelenmiştir. Bu araştırmada kullanılan araştırma metodu eylem araştırması yaklaşımıdır. Bu yöntem, uzman araştırmacı ile birlikte bir grup katılımcının bir problemi tanımlaması, problemi çözmek için bir şeyler çaba sarfettikten sonra öncül bulgulardan ders çıkararak sürecin hepsini veya bir kısmını yeniden uygulaması esasına

7 Şekil 2. Çalışma Sırasında İzlenen Süreç Değişimi dayanan çözüm yönelimli bir araştırmadır [12]. Bu yaklaşımın genel amacı bir uygulama hatasını gidermektir. Dolayısı ile kuramsal bilgi üretmeyi direkt olarak hedeflemez. Fakat en önemlisi eylem araştırması konu üzerinde uzmanlaşmış bir uygulama yetkisi olan bir kişinin tüm sürece doğrudan katılımı sağlanarak ilk elden gözlemleme ve elde edilen çıktıların hızlı bir şekilde uygulanabilirliği sağlamaktadır [5]. 4.1 Durum Analizi Birinci aşama firma yetkililerinin araştırmacı ile temas kurup Scrum yöntemi ile ilgili uygulama sorunları olduğunu bildirmeleri ile başlamıştır. Şirket ve uzman araştırmacılar belirlenen sorun üzerinde şirketle beraber çalışarak sorunun derinlerine inmeye hedeflemiştir. Bu kapsamda öncelikli olarak sorun tespiti için bir odak grup çalışması yapılmıştır. Bu çalışma araştırmacılardan birisi tarafından yürütülmüştür. Çalışmaya şu sorularla başlanmıştır: İletişim şablonundaki sorun sürecin hangi noktasından kaynaklanmaktadır?, Takım içi bilgilendirme eksiklikleri ne sebeple olmaktadır?, Tasarım grubu ile yazılım grubu arasında ne tür kopukluklar yaşanmaktadır?, Kullanıcı hikayelerinden doğan sorunlar nelerdir?, Koşunun bitmesine rağmen neden bazen geliştirme sürecinden çıkılamamaktadır?. Bu soruların ışığında ürün sorumlusu ile yazılım takımları arasında iletişim kopukluğu tespit edilmiştir. Bu kopukluğun ayrıca oluşturulan alt ekipleri etkilediği, özellikle tasarımcı-yazılımcı gruplarında daha akut bir şekilde seyrettiği

8 belirlenmiştir. Yazılım test grubunun yinelemeli çalışma şeklinde bazı uzun iterasyonlar sırasında iş sürekliliklerini kaybettikleri rapor edilmiş. Test ekibinin geri bildirimleri kısa ve aralıklı sürelerle gecikme göstermiştir. Scrum yönteminde yaşanan bir başka sorun da tüm paydaşların koşu sürecinin bitimi ile ilgili mutabakat sağlayamaması olmuştur. Bu durumda performans testlerinin geciktiği ve dokümantasyon süreçlerinin yavaşladığı rapor edilmiştir. Yapılan araştırma sırasında ortaya çıkan bir başka sorun ise kısa vadeli sorun çözümlerinin uzun vadeli çözümlere olan kötü etkisi olmuş, bir kaç projede bulunan stratejik hedeflere ulaşılamamıştır. Bir koşunun amaçlarına hizmet etmek için bazı yazılım geliştiricilerin kod kalitesinden ödün verdiği fikri ortaya atılmıştır. Scrum planlama görevlerinde sorunsuz görünürken, özellikle programlama görevlerinde bazı sorunlara sebep olabilmektedir. Bunda örnek olarak, bir koşu durumunda işini bitirip zaman arttıran yazılım grupları, kod birleştirme işlemlerini koşunun sonunda kadar yeni işler beklemek zorunda kalmıştır. Tablo 1 de şirketin Scrum kullanırken yapılmış anket sonuçları görülebilemktedir. Tablo 1 de yapılan çalışmada sorulan sorular sunulmaktadır. Sorular, sorularda 5 li Likert tipi ölçeğe göre verilen cevaplar doğrultusunda analiz edilmiştir. Bu ölçekteki değerlerin anlamı; Kesinlikle Katılmıyorum (1), Katılmıyorum (2), Kararsızım (3), Katılıyorum (4), Kesinlikle Katılıyorum (5) arasında değişmektedir. Sorular (n=30, toplam: 38.4, ortalama=3.2) Q1:Görevlerim net olarak tanımlı 3.9 Q2:Değişen gereksinimler işinizi etkilemiyor 3.8 Q3:Ürün sahibi isteklerini bana net olarak ulaştırabiliyor 3.5 Q4:Takımınızın planları benim için yeterince açık 3.7 Q5:Grup toplantında verim alınıyor 3.2 Q6:Yazılım geliştirme sürecinden memnunum 3.2 Q7:Süreç, yaratıcılığıma olumlu katkı sağlıyor 2.9 Q8:Kendimi geliştirebildiğime inanıyorum 3.4 Q9:Sürec takım etkileşimi arttırıyor 3.6 Q10:Süreçteki sosyal etkileşim verimi iyileştiriyor 2.8 Q11:Başarılarım için yeterince ödüllendiriliyorum 2.1 Q12:Takımınızdaki sosyal bağlar yeteri kadar güçlü 2.3 Tablo 1. Süreç Değişim Anketi Soruları: Birinci Durum Scrum X 4.2 Scrum dan Scrumban a Süreç Değişimi Yapılan çalışmanın ardından alınan ortak karar doğrultusunda yazılım geliştirme süreci Scrum dan Scrumban a değiştirilmiştir. Uzman araştırmacı firma tarafından değişim yürütücüsü olarak atanmıştır. Değişim süreci altı ay sürmüş, değişimin sonuçları yönetim uzman araştırmacı tarafından yapılan bir anket yardımı ile incelenerek süreç değişiminin etkisi ampirik olarak gözlenmiştir. Yazılım geliştiren organizasyon üzerinde yapılan süreç değişim anketlerinin sonuçları, eşleştirilmiş ikili grup testi (paired-samples t test) kullanılarak incelenmiştir. Bu test ile kişilerin iki metot için yaptıkları değerlendirmeler arasın-

9 Sorular X Q1 4.1 Q2 4.3 Q3 4.3 Q4 4.5 Q5 3.5 Q6 3.8 Q7 3.9 Q8 3.8 Q9 3.8 Q Q Q Tablo 2. İkinci Durum Scrumban (n=30, toplam=44.4, ortalama=3.7) daki farkın istatistiksel olarak anlamlı olup olmadığı araştırılmıştır. Birinci süreç değişim anketi (Scrum) için 12 sorunun tüm şirket bazında değerlendirilmesi sonucunda; Likert ölçeği ortalaması 3.2, ikinci süreç değişim anketi (Scrumban) için Likert ölçeği ortalaması 3.7 olarak hesaplanmıştır (bkz Tablo 3). Burada araştırdığımız bu artışın anlamlı olup olmadığıdır. ortalama soru sayısı standart sapma Scrum (S) Scrumban (SB) Tablo 3. Eşleştirişmiş Örneklem İstatistikleri Tablo 4 de görüldüğü üzere, iki süreç arasındaki ortalamaların farkı 0.5 olarak bulunmuştur. Hesaplanan t değeri (6.12) kritik tablo değerinden (1.79) büyük olduğu için Scrumban sürecinin şirket üzerindeki etkisinin olumlu olduğu sonucuna varılmıştır. ortalama standart sapma t serbestlik derecesi SB ortalaması - S ortalaması Tablo 4. Eşleştirilmiş örneklem testi 4.3 Scrumban Getirileri Süreç değişimi sırasında yapılan çeşitli entegrasyon çalışmaları şu şekilde özetlenebilir. İlk olarak, daha önce Scrum sürecinde kullanılan iletişim tahtası Scrumban tahtasına değiştirilmiştir. Bu değişim eski süreçte, takımların hız (üretkenlik) ölçümü kaç tane kullanıcı hikayesinin gerçeklediği esasına dayanarak zaman tabanlı olarak kısıtlanırken, yeni yaklaşımda sürecinde yapılan iş, iş-akış durumuna göre sınırlandırılır. Bu durumda daha önce Scrum için kullanılan panodaki

10 süregiden işlere sınırlandırılma kuralı getirilmiştir. Bu sayede, hızlı değişen gereksinimlere adaptasyon daha kolaylaşmıştır. İkinci olarak, bu yeni yaklaşım günlük Scrum toplantılarını yeniden şekillendirmiştir. Scrumban felsefesinden yola çıkarak yeni bir süreç iletişim yöntemi ortaya atılmıştır. Böylelikle, bu toplantılar odak grup toplantılarına benzetilmiş, yeniden yarı yapılandırılmış görüşme tekniği ışığında şekillendirilmiş ve ürün sahibinin sormayı planladığı sorular doğrultusunda bir görüşme protokolü hazırlanmıştır. Böylece toplantılarda, günlük durumla ilgili sistematik ve karşılaştırılabilir bilgi edinilmesi sağlanmıştır. Görüşme sırasında elde edilen bilgiler ışığında gerekli görüldükçe Scrumban panosuna eklenmiştir. Son olarak; daha önce kullanılan (zaman kutulu) koşu tabanlı yazılım geliştirme yöntemi yerine Scrumban yaklaşımının bir özelliği olan belirli bir zaman aralığında yazılım takımlarının hangi özellikleri geliştireceğinin sınırlandırarak kontrolü yöntemine geçilmiştir. 4.4 Oyunlaştırma Süreç değişim anketi sonuçlarında çalışanlarda gözlenen ödüllendirme ve sosyal etkileşim alanındaki motivasyon düşüklüğü gibi göze çarpan bazı sosyal eksikliklerle baş etmek için uzman araştırmacı Scrumban sürecine oyun öğelerinin eklenesini önermiştir. Bu bağlamda yazılım geliştirme sürecine altı basamaklı oyunlaştırma süreci uygulanmıştır. Şirket için tanımlanmış iş hedefleri şu şekilde belirlenmiştir. Oyunlaştırma kullanılarak yazılım ekiplerinin motivasyon düşüklükleri azaltılmaya çalışılması. Scrumban tecrübesinin kullanılacak interaktif öğeler yardımı ile etkileşimin artırımı. Topluluk bilincinin geliştirilmesi ile bireylerin daha fazla görev üstlenmelerinin sağlanması. Süreç boyunca ilerleme algısı korunması. Sürecin daha eğlenceli hale getirilmesi. Hedef davranışlar tasarlanması: Daha fazla görev bitir: Oyunlarda sıkça rastlanan, bağlantılı görevler (quests) ve zorluklar tanımlanarak yazılım geliştiren bireylerin sürece olan ilgileri ve ellerindeki görevleri bitirme istekleri artırtılmıştır. Sistem geliştirme süreçlerinde göze çarpan ve çözülmesi gereken bazı problemli parçalar belirlenmiştir. Daha fazla işbirliği yap: Bağlantılı olarak geliştirilebilecek yazılım birimleri iş birliği ile çözümlenmesi için gerekli alt yapı kurulmuştur. Gereksinim analizi sırasında belirlenen kullanıcı hikayelerine göre zorluk dereceleri ve bu zorluk derecelerine göre bireylere kendi işleri dışında bu işlerle uğraşabilme şansı tanınmıştır. Daha fazla bilgi paylaş: Kendi işlerini bitiren bir kişinin takım arkadaşına destek vermesi desteklenmektedir. Bu tür faaliyetlerde bulunanlar ödüllendirilerek desteklenmektedir.

11 Oyuncuların tanımlanması ve modellenmesi: Sistem çapraz fonsyonlu takımlarda çalışan bilgisayar programcısı, grafik ve 3B lu model tasarımcısı ve testçi rollerinde çalışan yirmi kırk yaş aralığında bulunan, 23 erkek, 7 bayandan oluşan, otuz kişilik bir grup olarak tanımlanabilir. Kişilere yapılan görüşmeler doğrultusunda 5 kişi kendini başaran, 8 kişi kaşif, 7 kişi sosyalleşici, 3 kişi de öldürücü oyuncu tipi olarak tanımlamıştır. Aktivite döngülerinin tertiplenmesi: Scrumban panosuna ek olarak panoya bir puanlama sistemi eklenmiştir, günlük olarak işinin başında olan herkes puan alarak desteklenmiştir. Görev bitirmek, bilgi paylaşmak ve iş birliği yapmak ayrıca puanlandırılmıştır. Gereksinim analizi sırasında değer biçilen kullanıcı hikayeleri uygulama sırasına göre kademendirilmiş, bazı görevlere toplanılan puanlarla ulaşılması sağlanmıştır. Eğlencenin tasarlanması: Sistem içinde sağlanan başarılar bireyler tarafından ilk etapta bilinmeyen bröveler ile ödüllendirilerek hem ilerleme duygusu hem de sürpriz durumları oluşturulmuştur. Yazılım geliştiren bireylerin avatar oluşturabilmesi ve bu avatarların panoda görünümü sağlanmış, bu şekilde kimin hangi görevi yaptığı da daha kolay izlenebilir bir hal almıştır. İş için gerekli araçların kullanılır hale getirilmesi: Oyunlaştırılmış sistem uygulaması, Scrumban panosu için kurgulanmış, yapılan işlerin akışı oyun prensiplerine göre sağlanmıştır. Süreçteki ilerlemekler pano yardımı ile rahatlıkla takip edilebilmektedir. Yapılan çeşitli geri bildirimler de panoya yerleştirilmiştir. 5 Scrumban ve Oyunlaştırma Yazılım geliştirme sürecine oyunlaştırmanın da eklenmesinin ardından süreç değişim anketi bir daha uygulanmış ve daha sonra çıkan sonuçlar Scrumban süreç değişim anketinin sonuçları ile kıyaslanmıştır. Yapılan çalışmanın devamı olarak Scrumban ile Scrumban+Oyunlaştırma süreçleri karşılaştırılmıştır. Scrumban süreç değişim anketi için 12 sorunun tüm şirket bazında değerlendirilmesi sonucunda; Likert ölçeği ortalaması 3.2, Scrumban+Oyunlaştırma süreç değişim anketi için Likert ölçeği ortalaması ise 4.09 olarak hesaplanmıştır (bkz Tablo 5). Tablo 7 de görüldüğü üzere, iki süreç anketi arasındaki ortalamaların farkı 0.39 olarak hesaplanmıştır. Bulunan t değeri (6.71) kritik tablo değerinden (1.79) büyük olduğu için Scrumban+Oyunlaştırma sürecinin Scrumban a göre olumlu etkisi gözlenmiştir.

12 Sorular X Q1 4.3 Q2 4.5 Q3 4.6 Q4 4.7 Q5 3.8 Q6 4.2 Q7 4.2 Q8 4.3 Q9 4.4 Q Q Q Tablo 5. Üçüncü Durum Scrumban+Oyunlaştırma (n=30, toplam=49.1, ortalama=4.09) ortalama soru sayısı standart sapma Scrumban (SB) Scrumban+Oyunlaştırma (SBO) Tablo 6. Eşleştirişmiş Örneklem İstatistikleri ortalama standart sapma t serbestlik derecesi SBO ortalaması - SB ortalaması Tablo 7. Eşleştirilmiş örneklem testi 6 Sonuçlar Bu çalışmanın ışığında şu sonuçlar elde edilmiştir. Birinci olarak, yazılım geliştiren bireyler Scrum yaklaşımı yerine Scrumban kullanmayı tercih etmektedirler. Yeni melez metodolojinin öngördüğü sürekli akış modelini daha çok benimsemişler, eski süreç sırasında şikayet edilen bir çok sorundan kurtulmuşlardır. İkinci olarak, scrum yaklaşımı kullanılırken oluşturulan bazı kullanıcı hikayelerindeki problemler koşu sırasında göz ardı edilebilmekte ve potansiyel sorunlar uzun zaman maskelenebilmektedir. Önerilen yeni yaklaşım sayesinde işleyişle ilgili çeşitli sorunlar daha erken tespit edilebilir hale gelmiştir. Scrum yönteminde izlenen koşu esnasında yaşanan süreç içi önceliklendirme problemi ve verimsiz üretim süreç akışı, bu yeni yaklaşımla kontrol altına alınmıştır. Oyunlaştırma çatısı sayesinde bireylerin geliştirme sürecine olan ilgileri arttırılmış, böylelikle eski süreç sırasında azaldıklarını düşündükleri sosyal üretkenlikleri ve bireysel motivasyonları daha uzun süre korunabilmiştir. Çalışma sırasında yazılım geliştiren bireylerin iş akışının görselleşmesi, tasarlanan panonun sürece göre şekillendirilmesi, anlık olarak yapılan iş miktarındaki sınırlamalar ile üretim bir çekme sürecine başarı ile dönüştürülmüştür. Oyunlaştırma ve Scrumban yaklaşımının birlikte kullanılması iş akışında sistematik bir performans iyileştirmesi gerçeklemiş ve bu iyileştirme yapılan üç aşamalı anket çalışması vasıtası ile doğrulanmıştır.

13 Kaynaklar 1. Boehm, B., Turner, R.: Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional, 1 edn. (Aug 2003) 2. Conboy, K., Fitzgerald, B.: The views of experts on the current state of agile method tailoring. In: Organizational Dynamics of Technology-Based Innovation: Diversifying the Research Agenda, pp Springer (2007) 3. Deterding, S., Dixon, D., Khaled, R., Nacke, L.: From game design elements to gamefulness: defining gamification. In: Proceedings of the 15th International Academic MindTrek Conference: Envisioning Future Media Environments. pp ACM, New York, NY, USA (2011) 4. Deterding, S., Khaled, R., Nacke, L., Dixon, D.: Gamification: Toward a definition. In: Proceedings of the 2011 Annual Conference Extended Abstracts on Human Factors in Computing Systems. ACM, New York (2011) 5. Given, L.: The Sage encyclopedia of qualitative research methods. Sage Publications (2008) 6. Highsmith, J., Cockburn, A.: Agile software development: the business of innovation. Computer 34(9), (2002) 7. Humphrey, W.S.: A Discipline for Software Engineering. Addison-Wesley Professional, 1 edn. (1995) 8. Ladas, C.: Scrumban-essays on kanban systems for lean software development. Modus Cooperandi Press (2009) 9. McGonigal, J.: Reality is broken: Why games make us better and how they can change the world. Penguin Pr (2011) 10. Schwaber, K.: Agile project management with Scrum. Microsoft Press (2009) 11. Takeuchi, H., Nonaka, I.: The new new product development game. Harvard Business Review 64(1), (1986) 12. Tomal, D.: Action research for educators. Rowman & Littlefield Pub Incorporated (2010) 13. Werbach, K., Hunter, D.: For the Win: How Game Thinking Can Revolutionize Your Business. Wharton Digital Press (2012) 14. Zichermann, G., Cunningham, C.: Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps. O Reilly Media (2011)