Çevik Tasarım; bir yaklaşım deneyimi hikayesi
Bu, Agile yani Çevik Tasarım deneyiminin gerçekte neyle ilgili olduğunu, neden iyi uygulanmasının çok zor olduğu ve neden (biraz ruh arayışı ile) tasarımda harika işlediği ile ilgili bir yazı…
Yazan: James Archer (2014) https://crowdfavorite.com/agile-design-what-weve-learned/
Çevik Kavramının Doğuşu
Şubat 2001’de, geliştirme yöntemlerine ilgi duyan on yedi yazılım geliştiricisi, Utah’daki Rocky Dağları’ndaki bir tesiste toplandı. Konuştukları sırada tekrar eden temalar ve fikirler keşfettiler ve “Çevik Yazılım Geliştirme Manifestosu” olarak adlandırdıkları dokümanda bunları ölümsüzleştirdiler.
“Çevik Yazılım Geliştirme Manifestosu” Metni
Yazılımı geliştirerek ve başkalarının bunu yapmasına yardımcı olarak yazılım geliştirmenin daha iyi yollarını keşfediyoruz. Bu çalışma sayesinde:
- Süreçler ve araçlar yerine bireyler & etkileşimler
- Kapsamlı belgeler yerine çalışan yazılımlar
- Sözleşme müzakeresi yerine müşteriyle işbirliği
- Plan üzerinden hareket etmek yerine değişime ayak uydurmak
Özde soldaki öğelerde değer olduğunu kabul ederek, sağdaki öğelere daha fazla değer veriyoruz.
Bu kulağa muğlak geliyorsa, bunu büyük projelere daha geleneksel yaklaşım olan ve spesifikasyonlara ve proje planlarına odaklan “şelale” proje yönetiminin karşıtı olarak düşünebilirsiniz. (Çevik gelişimin daha yinelemeli veya döngüsel yaklaşımının aksine, her bir proje aşamasının bir sonraki aşamaya düşen görsel görüntüsü nedeniyle bu yaklaşıma “şelale” denir).
Çevik’in arkasındaki genel fikir, mevcut duruma çok az öngörüyle üç ay önce yazılmış bir ihtiyaç listesinin ifadelerini tartışmak yerine, projenin esnek ve geliştirilir olmasını kabul etmek ve süreçleri buna uygun şekilde yürürlüğe koymaktır.
200 civarında fazla kelimeden oluşan bu manifesto, yazılım geliştirme dünyasını sonsuza dek değiştiren bir hareketin temeli haline geldi. Manifestonun çeşitli yorumlarını sonsuz yazı ve tartışma araştırdı ve ilkelerini yapılandırmak için birçok özel çerçeve ve metodoloji (Extreme Programming, Kanban, Lean ve Scrum gibi) geliştirildi. Araçlar, eğitim, danışmanlık, sertifikasyon ve diğer ürün ve hizmetleri sunan başarılı şirketler ile bir “Agile yani Çevik Endüstri” oluştu. Bir bütün olarak Çevik hareketin arkasındaki ekonomik motor muazzamdır.
Evrimleşme Mücadelesi
Zamanla, Çevik yaklaşımının belirlenen faydaları başka endüstrilere sızdı ve şirketler bunu kendi koşullarında uyarlamaya başladı.
Çevik kesinlikle tüm projeler veya endüstriler için uygun değildir. Bazı yenilik unsurlarının olduğu durumlarda harikadır (gelişen gereksinimler, değişen öncelikler, esnek çıktılar vb.). Gereksinimlerin katı olduğu ve nihai teslimatın çelik ve betondan yapıldığı ticari inşaat gibi endüstriler için ise etkisizdir. Bununla birlikte, yazılım dünyasının ötesinde, Çevik (Agile) yaklaşımının çok doğal bir uyum sağladığı birçok endüstri vardır (UX tasarımı dahil).
Ancak, yazılım endüstrisinde bu kadar derin köklerle bağlı bir felsefeyi tamamen farklı bir endüstriye uyarlamaya çalışmak sinir bozucu ve cesaret kırıcı bir misyon olabilir. Diğer endüstrilerde uygulandığında, katılımcıları hakkında belirli varsayımlar üzerine inşa edilen ayrıntılı metodolojiler birden çözülebilir (neyin neden işe yaramadığını bulmak aylar hatta yıllar alabilir).
Bu zorluklar karşısında “Agile’ı denedik ve bizim için işe yaramadı…” demek mümkün.
Benzer şekilde, Agile’yi uygulamalarına yardımcı olmak için yazılım geliştirme ekiplerinin kullanabileceği birçok araç, genellikle yazılım dışı bağlamlarda hiçbir anlam ifade etmiyor. Bu da ekipleri kendileri hallerine bırakıyor ki; elektronik tablolar, not kartları, post-it notları veya yeni proje izleme sistemleri icat ediliyor. başka ne olursa olsun. (Bu tür zorlamalı inovasyon mutlaka kötü bir şey değil, ancak yazılım dışı bağlamlarda daha Çevik araçların bulunması hoş olur).
Bunun da ötesinde, Agile uygulamalarını uyarlama veya değiştirme girişimleri bazen daha garip ve farklı olduğu için geleneksel uygulamacıların eleştirisini alabilir. Çevik topluluklarda çoğu insan destekleyici olsa da; kitaplaştırılmış protokolleri kullanmadığımız için sadece yanlış yaptığımız fikrini aşamayan bazı insanlar var.
Bu zorluklar karşısında “Agile’ı denedik ve bizim için işe yaramadı” demek mümkün. UX tasarımı gibi endüstriler için ise şelale metodolojisi neredeyse her zaman yanlış seçimdir; ancak işler en azından rahat ve bildik şekillerde yanlış gider.
Tasarım için çevikliği benimsemek
Agile yazılım geliştirmeye ilk maruz kalmamız, Agile yaklaşımını benimseyen veya benimseyen bir dizi yazılım firması ile etkileşime girmeye başladığımız 2006 civarındaydı. Kısa bir süre sonra, Agile yazılım ekipleriyle düzenli olarak etkileşim kurduğumuz ortak bir çalışma alanına geçtik ve sıklıkla projeler üzerinde çalıştık. Bu tür bir ortamda, bazı felsefeleri kendi proje yönetimi süreçlerimize uygulamak için yollar aramaya başlamak doğaldı. 2009’un başlarında, standart proje yönetimi yaklaşımımız olarak Agile’ı resmen kabul ettik.
Kısa bir süre sonra, müşteri deneyimlerini (web sitesi, pazarlama materyalleri, vb.) Yeniden tasarlamak için Scrum topluluğunda önde gelen bir kuruluş tarafından işe alındık. Tahmin edebileceğiniz gibi, bu proje için Scrum kullanmamızı istediler ve biz de bunun için hazırdık. Zaten Agile ile deney yapıyorduk, o zaman neden kendimizi yürekten Scrum’a adayıp bir şeyler öğrenmeyi denemeyelim dedik.
Ve öğrendik. Scrum prensiplerini kendi kültürümüze ve uygulamalarımıza nasıl uygulayacağımızı anlamaya çalışırken oldukça acı çektik. Her şeyin biraz gelişigüzel ve sürekli değiştiği bir bağlamda tasarımın (planlama ve niyet anlamında) rolü hakkında önemli tartışmalar yaptık. Çalışmalarımızı web uygulamalarını oluşturan yazılım ekibi ile senkronize etmeye çalışmak bile zor bir işti, çünkü aynı anda farklı şeyler üzerinde çalışıyorduk.
Nihayetinde, bu sorunların çoğunu aştık; akışımızı bulduk ve kurum için gerçekten çok büyük bir iş ürettik. Hayal kırıklıklarımızı anlayan ve ne zaman esnek olabileceğini bilen harika insanlar olduğu için şanslıydık. İşi tamamladık ve yaptığımız işten gurur duyduk.
“Her şeyin biraz gelişigüzel ve sürekli değiştiği bir bağlamda tasarımın (planlama ve niyet anlamında) rolü hakkında önemli tartışmalar yaptık.”
Bundan sonra “Mükemmel Scrum” u takip etmememize rağmen, ilke ve protokollerinin çoğunu kendi proje yönetimi yöntemlerimize dahil ettik. Yöntemin yerleşik bir çerçevesini harfiyen takip etmiyorduk; ama Agile’nin temel ilkelerine gerçekten inanmıştık ve kendimizi Agile tasarım firması olarak gördük.
Tasarım ve çeviklik arasındaki hassas ilişki
Yüzeyde, tasarım ve Agile ahenkli bir şekilde birlikte çalışmalı gibi görünüyor; ancak konuyu tam çözmeden önce uğraşmanız gereken temel felsefi konular var.
Tasarım büyük resim düşüncesiyle ilgilidir: planlama, strateji, tüm detayları çalışma, her şeyi düşünme, mükemmel yapma, vb. (Eric Karjaluoto buna “ şaheser zihniyeti ” adını verdi ).
Diğer yandan, Çevik daha temel işlemleri yapmak ve ayrıntılarla daha sonra ilgilenmektir: yineleme, minimum uygulanabilir ürünler, “mükemmel, işin düşmanıdır”, vb.
Bu iki dünya en azından ilk başta düzgün bir şekilde harmanlanmıyor. Çevik geliştiriciler, aşırı düşünen tasarımcılar ile çalışırken hayal kırıklığına uğrayabilir; “Neden bir salıvermezler ki? Bunu daha sonra halledebiliriz.” Tasarımcıların ise Agile geliştiricilerinin düşük standartları ile cesaretleri kırılır; “Daha iyi olmasını istemiyor musunuz? Kullanıcının mutlu olmasını istemiyor musunuz? ”.
Her iki durumda da, sorun birbirlerinin bakış açılarının yanlış anlaşılmasından (çoğu problemde olduğu gibi) kaynaklanır. Tasarımcılar takıntılı değildir; sadece kullanıcı perspektifinden doğru şeyi yapmaya çalışırlar. Ve geliştiriciler de tembel değildir; sadece minimum gereksinimleri tamamlayarak ilerleyen bir süreci takip ederler. Her iki taraf da birbirinden önemli dersler çıkarabilir.
Tasarım dünyasında Çevik bir yaklaşımı benimsemek için, aslında tasarımcıların eğilimli olduğu büyük resim aplantılarından en azından bazılarını feda etmeniz ve yerine gerçek dünyadaki iş senaryolarını kabul etmeniz gerekir ki ideali bu değildir.
“Tasarımcılar takıntılı değildir; sadece kullanıcı perspektifinden doğru şeyi yapmaya çalışırlar. Ve geliştiriciler de tembel değildir; sadece minimum gereksinimleri tamamlayarak ilerleyen bir süreci takip ederler. Her iki taraf da birbirinden önemli dersler çıkarabilir.”
Tasarımcılar her zaman net bir “doğru” cevap olduğuna inanmak isterler ve müşterilerle bu doğru cevabı almak için zaman, bütçe ve alan için mücadele ederler. Doğru cevabın müşterinin o anki gerçek durumu için işleyen cevap olduğunu unutuyorlar. (Yalnızca 20 bin dolarlık bir bütçeniz varsa, kaç tane ödül kazanırsa kazansın 40 bin dolarlık bir web sitesi doğru değildir.)
İki dünya görüşü arasındaki gerginlikle mücadele ettiğinizde, aslında size farklı avantajlar ve esneklik sağlayan çok sağlıklı bir orta zemine ulaşabilirsiniz. Çevik bir tasarım yaklaşımı, bir kez anladıktan ve nefes almak için biraz yer verdiğinizde, gerçekten güzel çalışır.
Çevik Tasarım ile hata yapmak kolaydır
Çevik yaklaşım zordur. Herhangi bir büyük felsefe gibi, gerçekte onu uygulamaya çalışan kusurlu insanlar tarafından yürütüldüğünde işler birbirine karışır.
Voke’un tartışmalı bir 2012 raporu , Agile yaklaşımına aşağıdaki gibi yorumlar da dahil olmak üzere bazı sert eleştiriler getirdi:
“Agile hareketinin, istenmeyen görevlere ve programlara karşı bir yazılımcı isyanı ya da sadece sertifikasyon ve eğitim dahil Agile hizmetlerini satma fırsatı olabileceğini unutmayın.”
“Anket katılımcıları, yazılımcıların planlamadan kaçınmak ve gelecekteki bakım için gerekli belgeleri oluşturmaktan kaçınmak için Agile kisvesini kullandıklarını bildiriyor.”
“Çevik hareketin bazı üyelerinin yetkinlik, profesyonellik ve tavırları hakkında benzeri görülmemiş nitelikte korkutucu ve şok edici yorumlar aldık.”
“Anket katılımcılarının yüzde altmış dördü (% 64) Agile’a geçişi kafa karıştırıcı, zor veya yavaş buldu. Yüzde yirmi sekizi (% 28) başarı bildirdi. ”
“Ezici bir şekilde, Agile yöntem kullanan katılımcıların % 40’ı bir fayda belirlemedi.”
Voke bu özel raporda aşırı derecede hiperbolik olmasına rağmen (böylesi daha fazla satıyor), bunun gibi sonuçları duymak şaşırtıcı değil. Hemen hemen her metodoloji için, hatta iyi olanlar için bile, böyle sonuçlar beklenir. (Hiç bir değişimin % 64 tarafından kafa karıştırıcı, zor veya yavaş bulunmasına şaşırmamak gerek. Biz insanlar geçişlerde çok iyi değiliz.)
Agile’ı bir din, felsefe veya siyasi parti gibi bir inanç sistemi olarak düşünebilirsiniz. Çoğu inanç sisteminde temel prensipler gerçekten harika. Sorun, büyük insan gruplarının neye bağlandıklarını derinlemesine bilmeksizin bir felsefenin etrafında toplanmaya başlamasıyla ortaya çıkıyor. İnanç sisteminden bağımsız olarak, talihsiz olan çoğu katılımcının muhtemelen konuyu iyi anlamadığı ve bu nedenle de kötü uygulayacağı gerçeğidir.
Ekibiniz tembelse, Agile onları üretken yapmaz. Eğer takımınız özensiz ve gelişigüzelse, Agile onları organize etmez. Ekibiniz sürekli hata yapıyorsa, Agile her şeyin aniden pürüzsüz çalışmasını sağlamayacaktır.
Bununla birlikte, doğru yerlerde doğru insanlar varsa ve Agile’ın uygun olduğu projeler üzerinde çalışıyorsanız (örneğin bir gökdelen inşa etmiyorsanız), muhtemelen Agile ile daha iyisini yapabilirler.
Voke raporunun sizi çok korkutmasına izin vermeyin. Genel olarak, Çevik yaklaşım (Agile) oldukça iyi çalışıyor gibi görünüyor. Örneğin, Standish Group tarafından 2011 yılında yapılan bir araştırmada, Çevik projelerin geleneksel şelale proje yönetimi tekniklerini izleyen projelerden üç kat daha başarılı olduğu bulunmuştur.
Çevik tasarımın kalbi
Yıllar içinde, proje yönetimi yöntemlerimiz geliştikçe, kendimizi “Çevik suçluluk” yaşarken bulmaya başladık. Çünkü günlük stand-up toplantıları yapmıyorduk veya bazen bir müşterinin kaba bir proje iş akışını açıklaması için bir Gantt şeması oluşturuyorduk, ya da atanmış bir scrummaster’ımız yoktu
Çok geçmeden, aslında Agile’den vazgeçtiğimizi düşündük. Proje yönetimi yaklaşımımız son derece verimli ve etkili bir şekilde gelişti, ancak artık sıradan gözlemciye ortodoks Çevik yaklaşım gibi görünmeyebilir.
Ancak, sonunda Agile Manifesto’yu (ve ilişkili 12 ilkeyi) tekrar okumak için biraz zaman ayırdık ve sadece bu temel unsurlara hala inanıp uyguladığımızı değil, aslında onlarda gerçekten iyi olduğumuzu anladık.
Çevik tasarımın harika bir örneğini yakalamıştık ve bunun farkında değildik; çünkü yanlışlıkla Çevik’in etrafında gelişen ritüeller ve kurallar tarafından tanımlandığı fikrine takılmıştık. Ama öyle değil… Çevik aslında çok basit.
Çevik yani Agile yaklaşımı aslında her proje yöneticisinin bildiği ancak itiraf etmekte zorlandığı rahatsız edici gerçeği kabul etmekle ilgili. Proje planının yanlış olduğu gerçeği. Kapsam sünmesi. Siparişlerin değişmesi. Değişen öncelikler. Yeni yönler. Bu tür şeyler meydana geldiğinde, şimdiye kadar dikkatli bir şekilde planlanan her projemizde olsa bile dehşete düşüyoruz. Geri dönüyoruz ve müşterinin o an önemli olduğuna inandığı bir şeyi neden yapmamamız gerektiğini açıklamak için aylar önce yazılmış ve hiç kimse tarafından okunmamış belgelerin satırlarına işaret ediyoruz. Bu deneyimin projelerin % 100’ünde gerçekleştiği ve her seferinde aksi bir sonuç beklenen başka bir endüstri var mı? Bu delilik!
Agile yaklaşımı, özünde, sürekli değişen gerçek dünyayı kabul etmek, bu gerçeği benimsemek ve bu değişime asla gerçekleşmemesi gereken korkunç bir şey gibi davranmak yerine, nasıl verimli bir şekilde adapte olabileceğimizi anlamaktır.
Bunu gerçekten çok iyi yaptığımızı söylemekten gurur duyuyorum. Kapsam değişikliklerini çoğu tasarım firmasının yaptığı gibi değiştirmiyoruz. Teslim tarihleri değiştiğinde ve öncelikler değiştiğinde müşterilerimiz hakkında kötü şeyler mırıldanmıyoruz. Böyle şeylerin olabileceğini anlıyoruz, benimsiyoruz. Bununla barışık haldeyiz. Ve süreçlerimiz bu değişimlerin etkili bir şekilde gerçekleşmesine izin veriyor, çünkü başından beri yaşanacağını biliyorduk.
Hala Çevik
Forty’de çalışma şeklimiz, resmi Çevik metodolojilerin hiçbirine uymuyor ve bunda bir sorun yok. Agile’ın bizim günlük sistemimizde nasıl göründüğüne dair bazı örnekler:
Çevik prensip: “Süreçler ve araçlar yerine bireyler ve etkileşimler”
Felsefemiz, her projenin her müşteri için iyi çalışması gerektiğidir. Bu nedenle örneğin bir müşteri için Google Hangouts’u ve ardından bir sonraki toplantı için Skype’ı kullanabiliriz, çünkü bu müşterilerin tercihi budur. Ya da çoğu projede kullandığımız standart bir iş akışımız olabilir, ancak belirli bir projede bu içeriğe daha uygun başka bir şey için değiştirebiliriz. İşleri yapma şeklimizde katı değiliz; duruma uyacak şekilde bükülür ve esneriz.
Çevik prensip: “Kapsamlı belgeler yerine çalışan yazılım”
Yazılımları Çevik bir yazılım ekibinin yaptığı gibi sunmuyoruz; ama teori ve şovmenlik yerine müşterilerimiz için gerçekten işe yarayan şeyler yaratmaya odaklanıyoruz. Ne yaptığımızı açıklamaya yardımcı olan belirli bir dokümantasyonumuz var, ancak mümkün olduğunca yalın ve minimum düzeyde tutmaya, şovu kesip müşterilerimizin ihtiyaçlarını karşılayan net ve güncel çözümleri üretmeye odaklanıyoruz.
Çevik prensip: “Sözleşme müzakeresi yerine müşteriyle işbirliği”
Yıllar önce, sözleşmelerimizi çıkarıp belirli ifadelere işaret ederek “Bunu vaat ettin” ve “Bunu yapacağımızı asla söylemedik” derdik. Artık değil. Nihayet, bir müşteriye bir şeyleri “kanıtlamak” için sözleşmeyi işaret ettiğimizde onları zaten kaybettiğinizi fark ettik. Şimdi, projelerimizi uyumlu kılmak için ayrıntılı müzakerelere güvenmek yerine, net iletişim ve beklenti belirlemeye odaklanıyoruz. Katılan herkes ne olduğunu ve neden olduğunu ve bundan sonra ne olacağını anladığında, tartışmak için çok az neden kalıyor. Birbirimize güveniyoruz ve küçük detaylar hakkında birbirimizi iğnelemek yerine harika şeyler yapmak için birlikte çalışıyoruz.
Çevik prensip: “Plan üzerinden hareket etmek yerine değişime ayak uydurmak”
Bu bizim için büyük bir adım. Kapsam değişikliğini sürecin doğal (ve sağlıklı) bir parçası olarak görmeye başladık ve projelerimizi buna göre planlıyor ve fiyatlandırıyoruz. Müşterilerimizin birçoğu ile, projeyi durdurmak, yeniden müzakere etmek, yeniden bütçelemek gibi şeylere gerek duymadan düzeltme yapmamızı sağlayan basit bir aylık sistemimiz var. Daha yapılandırılmış projelerimizde bile zamanla gelişen öncelikler, bağlamlar vb değişimler için canlı bir proje planı var. Hala çok fazla planlama yapıyoruz, ancak kaçınılmaz olarak geldiğinde değişimle mücadele etmiyoruz.
Çevik Tasarım zor, ama işe yarıyor
Agile manifestosunu ve 12 Prensibi okuduğumda; aslında hepsini neredeyse kazara, titizlikle takip ettiğimizi fark etmek bir sürpriz oldu. Aslında baştan beri uyguladığımızı anlayana kadar Agile’dan vazgeçtiğimizi sanıyorduk. Tüm kuralları ve protokolleri bırakıp Agile’nin kalbine ulaştık. Diğer her şey doğal olarak oradan aktı.
Agile gerçekten işe yarıyor. Daha fazlasını yapıyoruz, müşterilerimizle daha güçlü ilişkilerimiz var ve bu temel ilkelere uyduğumuz için daha kaliteli işler yaratıyoruz. Kendimizi bir metodoloji veya başka bir yönteme bağlılıkla oyalamadık; Agile’ın bizim için ne anlama geldiğini anladık ve sonra uyguladık.
Ve Agile metodolojisi ağırlıklı olarak yazılım geliştirmeye yönelik olmasına rağmen, temel ilkeleri parametrelerin değiştiği ve geliştiği hemen hemen her proje için geçerli. Tasarım dünyasında, değişim günlük bir gerçekliktir. Bu yüzden nasıl işlediğini anladığınızda, Agile çok doğal bir seçim. Biz yıllardır uyguluyoruz ve harika sonuçlar görüyoruz.
Çevik Tasarım Seminer / Webinar modülümüzü buradan inceleyebilirsiniz.
Read More
