Showing posts tagged with: agile design
Çevik Tasarım
03May
Çevik Tasarım; bir yaklaşım deneyimi hikayesi
AraştırmaLeave a comment

Ç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.

Çevikliğin 12 İlkesi

Ç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 Eğitim Modülü
Çevik Tasarım Eğitimi

Çevik Tasarım Seminer / Webinar modülümüzü buradan inceleyebilirsiniz.

Read More
01May
Çevik Tasarım Hakkında Bilmeniz Gereken Temel Bilgiler
AraştırmaLeave a comment

Çevik Tasarım Temel Bilgiler

Çevik Tasarım ile ilgili Seminer / Webinar ürünümüzü buradan inceleyebilirsiniz.

Çevik Tasarım Ürün Resmi
Çevik Tasarım

Çevik Nedir?

Çevik (Agile), aslen yazılım ürünleri geliştirmek için kullanılan yinelemeli (iterasyon) bir yapıdır.

Yinelemeli (iterasyon) yazılım tasarımı, tekrarlama ile hassaslaştırmak ve sürekli hedefe doğru ilerlemek anlamına gelir. Geliştirme döngüsü bir kez çalıştırılıp iyileştirmenin gerekli olduğu alanları belirlenir ve ardından geliştirmek için döngü tekrarlanır. 

Çevik, yinelemeli olduğu kadar küçük artışlarla çıktı dağıtımını destekleyen artımlı bir yaklaşımdır. Gerekli işlevselliği birden çok yinelemeye böler ve her yinelemenin sonunda çıktı müşteriye teslim edilir.

Çevik Manifesto süreçler ve araçlar yerine insan ve etkileşimleri vurgular. Uygulamada bu, hem ekipler içinde hem de müşteriyle sık iletişim kurmanın yanı sıra günlük scrum toplantıları gibi şeyler yaparak tüm ekibin birbirine bağlı kalabilmesi anlamına gelir. Bu, ekiplerin müşterilerin, beta test kullanıcılarının ve piyasanın söylediklerine göre adaptasyonuna olanak tanıyan tutarlı bir geri bildirim döngüsü yaratır. Aynı zamanda çalışmalarının sonuçta kullanılacağı ortamda işlevsel olmasını sağlamak için kontrol mekanizması sunar.

Çevik süreç, ürünler her zaman süreç içinde revize edilebileceği için mükemmellik değil, zamanında ve bütçeye uygun çıktıların üretimini vurgular. Bu çoğunlukla daha küçük, daha ulaşılabilir hedeflere bölünmüş kısa, yoğun üretim dönemlerinin yinelenmesi biçimindedir.

Çevik Yazılım Manifestosu: http://agilemanifesto.org/ 

Çevik Tasarım - Waterfall / Agile Grafik Karşılaştrma

Çevik Yaklaşım Faydaları

  • Hızlı Geri Bildirim: Küçük bir özellik sunarak, her yinelemeden sonra geri bildirim alma ve böylece bir sonraki yinelemede ürününüzü geliştirme şansına sahip olursunuz. Müşteri, uygulanmakta olan işlevsellik şeffaflığına sahiptir. Bir şeyleri kolayca gözden geçirebilir ve değişiklik önerebilir.
  • Müşteri Katılımı: Müşterinin çıktıyı görmek için uzun süre beklemesi gerekmez. Her yineleme sırasında ürünle meşgul kalır ve ürünün görünürlüğüne sahiptir.
  • Değişim Yönetimi: Küçük bir yinelemeden sonra bir şeyleri güncellemek, tam işlevsellik sağladıktan sonra ürünü güncellemeye kıyasla daha ucuz olduğundan değişiklik yönetimi kolaydır.
  • Takım Motivasyonu: Takımlar oldukça sık bir şeyler teslim ettikleri ve teslimatlarına yanıt aldıkları için daha üretken hissederler.
Çevik Tasarım - Waterfall & Agile Akış Farklılıkları Diyagramı

İteratif Tasarım Süreci Nedir?

Tasarım süreci birden fazla aşamadan oluşur: Anlama, Araştırma, Eskiz, Tasarım, Prototip, Test, Hassaslaştırma. Bir yinelemeli tasarım süreci ilk aşamada doğru hamle başlar. Daha sonra çıktı analiz edilir ve daha da iyileştirmek için çoklu iterasyonlar çalıştırılır. Bu süreçte amaç, hedef çıktı yaratmak değil, her bir yinelemede tasarımı geliştirmektir. Bu yaklaşımın bir dezavantajı , tasarımdaki sonraki aşama ayarlamalarının oldukça maliyetli olmasıdır.

Çevik Tasarım Süreci Nasıl Uygulanır?

Bir çevik tasarım süreci kullanmak müşteriye tasarımlarınızı iterasyon ile artımlı bir modelle sunma imkanı verir. Gerekli fonksiyonları küçük parçalara bölerek her parça sonunda geri bildirimini almak için müşteriyle paylaşabilirsiniz.

Çevik tasarım sürecinde aşamalar paralel olarak ilerler. İşlev, bağımsız olarak teslim edilebilecek küçük parçalara bölünür ve üzerinde çalışmaya başlanır. Bu da hız ve sürekli geri bildirim imkanı verir. 

Çevik Tasarım Süreci Diyagramı

Çevik Tasarımın Faydaları

  • Hızlı Geri Bildirim: Müşteri tasarımın bitmiş prototipini beklemeden geri bildirim verebilir ve ne istediğini görmesinde zaman kazandırır. 
  • Değişim Yönetimi: Tasarımdaki değişiklikler daha kolay ve daha ekonomik olur. Zaman ve para kaybı minimize edilir. 
  • Daha Hızlı Geliştirme: Küçük tasarım parçalarını saha ekiplerine teslim etmek de daha hızlı uygulamaya olanak tanır. Saha ekibi tasarımın tamamının bitmesini beklemez. 
  • Sonuç: Bugünün dünyasında, sadece yinelemeli bir süreç rekabette geride bırakabilir. Yinelemeli ve artımlı yaklaşımın bir kombinasyonuna dayanan çevik tasarım süreci üretkenliği ve doğru hedeflerini yakalamaya imkan verir. 

Çevik Tasarım (Agile) Terminoloji

Çevik Tasarım - SCRUM Süreç Akış Diyagramı
Vector scrum agile process workflow with stages from idea to product. Iterative spring methodology for programmer,developers team. Software design management concept
  • Scrum : Bu, kullanımı en kolay yöntemdir çünkü projenin planlanması ve uygulanması aynı anda gerçekleşir. 
    • Scrum, karmaşık bilgi çalışmalarını yönetmek için çevik bir süreç çerçevesidir. On veya daha az üyeli ekipler için, çalışmalarını sprint olarak adlandırılan , bir aydan fazla olmayan ve en yaygın olarak iki haftadan fazla zaman tekrarlamalı yinelemelerde tamamlanabilecek hedeflere ayıran, ilerlemeyi izleyen ve günlük scrum olarak adlandırılan 15 dakikalık günlük toplantılarla yeniden planlayan takımlara göre tasarlanmıştır. 
    • Yazılım geliştirme terimi scrum ilk olarak 1986 yılında “Yeni Yeni Ürün Geliştirme Oyunu” başlıklı makalede kullanılmıştır. Terim, rugby sporundan gelir; oyuncuların ofansif bir yerleşimidir. Scrum terimi makalenin yazarları tarafından ekip çalışmasını vurguladığı için seçilmişir. 
    • Scrum‘ın temel ilkesi, müşterilerin (genellikle gereksinim dalgalanması olarak adlandırılan) istedikleri veya ihtiyaç duydukları hakkındaki fikirlerini değiştirecekleri; öngörülemeyen zorluklar olacağını ve buna öngörücü, planlı bir yaklaşımın uygun olmadığı fikridir. 
    • Bu nedenle Scrum, kanıta dayalı ampirik bir yaklaşım benimser – sorunun tam olarak anlaşılamayacağını veya tanımlanamayacağını kabul ederek; hızlı bir şekilde iş teslim etme, ortaya çıkan gereksinimlere, gelişen teknolojilere ve piyasa koşullarındaki değişikliklere uyum sağlamaya odaklanır. 
Çevik Tasarım - SCRUM akış diyagramı
  • Sprint: Scrum’daki temel geliştirme birimidir. Sprint zamanlanmış bir çabadır; yani, uzunluk her bir sprint için önceden kararlaştırılır ve sabitlenir ve normalde bir hafta ile bir ay arasındadır, iki hafta en yaygın olanıdır.
    • Her sprint, bir sprint hedefi ve gerekli ürün biriktirme öğeleri belirleyen bir sprint planlama etkinliğiyle başlar . Ekip, hazır olduklarını kabul eder ve bunu, gerekli işin bir dökümü ve sprint hedefi için tahmini bir tahminle bir sprint birikimine dönüştürür.
    • Her sprint, paydaşlara gösterilecek ilerlemeyi gözden geçiren ve sonraki sprint’ler için dersleri ve geliştirmeleri belirleyen bir sprint incelemesi ve sprint retrospektifiyle sona erer. 
  • Kanban : Kanban (Japonca tabela veya reklam panosu) beşeri sistemlerde iş yönetmek ve iyileştirmek için kullanılan yalın bir metot. Bu yaklaşım, talepleri mevcut kapasiteyle dengeleyerek ve sistem düzeyinde darboğazların ele alınmasını geliştirerek işi yönetmeyi amaçlar.
    • İş öğeleri, katılımcılara başlangıçtan bitişe kadar genellikle bir Kanban panosu aracılığıyla ilerleme ve süreç görünümü vermek için görselleştirilir. İş, istendiğinde sürece dahil edilmek yerine kapasite izin verdiği ölçüde çekilir.
    • Veri işlerinde ve yazılım geliştirmede amaç; neyin, ne zaman ve ne kadar üretileceğine karar vermek üzere görsel bir süreç yönetimi sağlamaktır. Altta yatan Kanban yöntemi Toyota Üretim Sistemi kökenli yalın üretim metodundan esinlenmiştir. Kanban, Scrum gibi diğer yöntem ve çerçevelerle birlikte yazılım geliştirmede yaygın olarak kullanılmaktadır.
KANBAN Tablosu Örnek
  • Ekstrem : Bu metodoloji yazılım geliştirmede daha çok kullanılır, ancak proje yönetimine uyarlanabilir. Odak, nihai ürünün kullanıcının tam olarak ihtiyaç duyduğu şey olmasını sağlamak için sık sık çıktılar üzerindedir.
  • Çevik UX : Herhangi bir metodolojinin UX versiyonları genellikle proje sonucunun ne olacağına veya projenin gerekli olup olmadığına değil, proje sonucunun nasıl yapılacağına odaklanan ayrıştırılmış bir sürece dönüşür.
  • Kristal : Kristal metodolojisi, projenin temel önceliklerine ve temel özelliklerine odaklanır. Yine, ürünün veya projenin son kullanıcının ihtiyaçlarını karşıladığından emin olmak için sık sık teslimat kullanır.

Çevik Tasarım: Örnek Sprint Akışı

Sprint Akış Diyagramı

Sprint planlama 

Sprint başlangıcında, scrum ekibi aşağıdakileri yapmak için bir sprint planlama etkinliği düzenler :

  • Sprint sırasında yapılması amaçlanan işin kapsamını karşılıklı olarak tartışıp kabul etmek
  • Bir sprint’te tamamlanabilecek ürün öğelerini seçmek
  • Seçili ürün öğelerini tamamlamak için gereken işi içeren bir iş listesi hazırlamak
  • Sprint hedefi, sonunda neler sunacağına dair kısa bir açıklamayı kararlaştırmak
  • Ayrıntılı çalışma detaylandırıldığında, ekip artık gerekli işi tek bir sprint’te tamamlayabileceğine inanmazsa, bazı ürün biriktirme öğeleri bölünebilir veya ürün birikimine geri konulabilir.
  • Geliştirme ekibi sprint işlerini hazırladıktan sonra, sprint içinde hangi görevlerin verileceğini tahmin eder (genellikle oy vererek).

Günlük scrum 

Bir sprint sırasında her gün, ekip belirli kurallara sahip günlük bir scrum toplantısı düzenler: 

  • Ekibinin tüm üyeleri hazırlıklı gelmelidir. 
    • Bazı ekip üyeleri eksik olsa bile tam zamanında başlar
    • Her gün aynı saatte ve yerde yapılır
    • Genelde on beş dakika ile sınırlıdır (örnek olarak)
  • Herkese açıktır, ancak sadece ekip üyeleri katkıda bulunmalıdır.
  • Günlük scrum sırasında, her ekip üyesi genellikle üç soruya cevap verir:
    • Dün sprint hedefimize takıma katkıda bulunacak ne işi tamamladım
    • Bugün sprint hedefimize katkıda bulunmak için ne yapmayı planlıyorum
    • Benim veya ekibin sprint hedefimize ulaşmasını engelleyebilecek herhangi bir engel görüyor muyum?
  • Günlük scrumda tanımlanan herhangi bir engel scrum yöneticisi tarafından tespit edilmeli ve ekibin scrum panosunda veya paylaşılan bir risk panosunda görüntülenmelidir. 
  • Çalışma panosu tüm ekibin sorumluluğunda olsa da, scrum yöneticisi genellikle sprint bitirme tablosunu günceller.. Takımın sorunları görmediği durumlarda, nedenini bulmak scrum ustasının sorumluluğundadır.
  • Günlük scrum sırasında ayrıntılı tartışmalar yapılmamalıdır. Toplantı sona erdiğinde, bireysel üyeler sorunları ayrıntılı olarak tartışmak için bir araya gelebilir.

Sprint incelemesi 

Bir sprint sonunda takım iki etkinlik düzenler: sprint incelemesi ve sprint retrospektifi.

Sprint incelemesi:

  • Tamamlanan ve tamamlanmamış planlanan çalışmaları inceler
  • Tamamlanan çalışmayı paydaşlara sunar ( demo olarak da bilinir )
  • Bir sonraki adımda ne yapılacağı konusunda paydaşlarla işbirliği yapar
  • Eksik çalışma gösterilemez.

Sprint retrospektifi:

  • Geçmiş sprint üzerinde değerlendirme yapılır
  • Sürekli süreç iyileştirme eylemleri tanımlanır ve kabul edilir
  • Sprint retrospektifinde üç ana soru sorulur: 
    • Sprint sırasında neler iyi gitti?
    • Neler iyi gitmedi?
    • Bir sonraki sprint’te daha iyi üretkenlik için neler geliştirilebilir?

Arka Plan Detayı

Arka Plan Detayı geri plan öğelerini gözden geçirmek, sprintlere giren ekipler için açık ve yürütülebilir hale getirecek şekilde hazırlandıklarını ve sipariş edildiklerini kontrol etme sürecidir. Geri plan öğeleri birden çok küçük parçaya bölünebilir. 

Geri plan öğeleri ayrıca teknik borç (tasarım borcu veya kod borcu olarak da bilinir) içerebilir . Bu, daha uzun sürecek daha iyi bir yaklaşım kullanmak yerine, kolay bir çözüm seçmenin neden olduğu ek çalışmanın zımni maliyetini yansıtan bir ifsdedir.

Bir sprint’i iptal etme 

Ürün sahibi gerekirse bir koşuyu iptal edebilir. Ürün sahibi bunu ekipten, scrum master’dan veya yönetimden gelen girdilerle yapabilir. Örneğin, dış koşullar sprint hedefinin değerini olumsuzlarsa, yönetim ürün sahibinin bir sprint’i iptal etmesini isteyebilir. Bir sprint anormal olarak sonlandırılırsa, bir sonraki adım, fesih sebebinin gözden geçirildiği yeni bir sprint planlaması yapmaktır.

Çevik Tasarım Kaynaklar

https://designshack.net/articles/business-articles/understanding-agile-design-and-why-its-important/

https://uxdesign.cc/agile-design-process-24be92018ad2

https://study.com/academy/lesson/agile-design-methodology-process.html

https://en.wikipedia.org/wiki/Scrum_(software_development)

https://en.wikipedia.org/wiki/Kanban_(development)

https://en.wikipedia.org/wiki/Agile_software_development

https://medium.com/@thandi.guilherme/i-bet-your-agile-process-is-broken-32985716233f

https://crowdfavorite.com/agile-design-what-weve-learned/

Read More
×