Çevik Tasarım Temel Bilgiler

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

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

İ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ı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

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

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

• 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 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/