Çevik Manifesto Açıklaması ve Nasıl Uygulanır?

Çevik Manifesto Nedir?

Çevik Manifesto, yazılım geliştirme içindeki çalışma biçimlerini iyileştirmeyi amaçlayan dört değer ve 12 ilkeyi içeren yazılı bir bildiridir.

Buyurucu olmaktan çok felsefi bir nitelik taşıyan Manifesto, çeşitli ekip büyüklüklerine, hedeflere ve koşullara uyarlanabilecek şekilde hazırlanmıştır.

Çevik Manifesto'nun 4 Değeri

Resmî Çevik Manifesto şu 4 değerden oluşur:

1. Süreçler ve araçlar yerine bireyler ve etkileşimler
2. Kapsamlı dokümantasyon yerine çalışan yazılım
3. Sözleşme müzakeresi yerine müşteriyle iş birliği
4. Bir planı takip etmek yerine değişime yanıt verme

Yazarların, değerlerin ardından şu açıklayıcı ifadeyi eklemiş olması dikkat çekicidir: "Yani sağdaki maddelerde değer olsa da soldaki maddelere daha fazla değer veriyoruz."

Bu, Çevik Manifesto'nun belirli bir süreci takip etmek veya belirli bir çevik araç kullanmakla ilgili olmadığı fikrini pekiştirir. Önemli olan belirli bir zihniyet benimsemektir.

Çevik Manifesto'nun 12 İlkesi

Çevik Manifesto, dört değere ek olarak bu değerlerin çevik projelerde nasıl yorumlanacağını ve uygulanacağını açıklayan 12 destekleyici ilkeyi de listeler.

1. Müşteriyi önceliklendirin

En yüksek öncelik, değerli yazılımları erken ve sürekli teslim ederek müşteriyi memnun etmektir.

2. Değişimi memnuniyetle karşılayın

Geliştirmenin ilerleyen aşamalarında bile değişen gereksinimleri memnuniyetle karşılayın. Çevik süreçler, değişimi müşterinin rekabet avantajı için kullanır.

3. Sık sık teslim edin

Çalışan yazılımı birkaç haftadan birkaç aya kadar değişen aralıklarla sık sık teslim edin; daha kısa zaman aralıklarını tercih edin.

4. Ekipler arasında iş birliği yapın

İş birimleri ve geliştiriciler proje boyunca her gün birlikte çalışmalıdır.

5. Yeteneği geliştirin

Projeleri motive olmuş bireylerin etrafında şekillendirin. Onlara ihtiyaç duydukları ortamı ve desteği sağlayın ve işi tamamlayacaklarına güvenin.

6. Konuşun

Bilgiyi bir geliştirme ekibine ve ekip içinde aktarmanın en verimli ve etkili yöntemi yüz yüze konuşmadır.

7. Önemli olanı ölçün

Çalışan yazılım, ilerlemenin temel ölçütüdür.

8. Tükenmişliği önlemek için çalışma temposunu ayarlayın

Çevik süreçler sürdürülebilir geliştirmeyi teşvik eder. Sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak istikrarlı bir tempoyu sürdürebilmelidir.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

9. Kaliteye odaklanın, işler daha hızlı ilerlesin

Teknik mükemmelliğe ve iyi tasarıma sürekli dikkat edilmesi çevikliği artırır.

10. Sadelik ilkesini benimseyin

Sadelik–yapılmayan iş miktarını en üst düzeye çıkarma sanatı–hayati önem taşır.

11. Mikro yönetim yapmayın

En iyi mimariler, gereksinimler ve tasarımlar kendi kendini organize eden ekiplerden ortaya çıkar.

12. Değerlendirin ve uyarlayın

Ekip, düzenli aralıklarla nasıl daha etkili olabileceğini değerlendirir, ardından davranışlarını buna göre düzenler ve uyarlar.

Çevik Manifesto'nun tarihi, yazarları ve ortaya çıkış öyküsü

Teknoloji dünyasında Çevik Manifesto, zaman içinde aktarılagelmiş herhangi bir kutsal metinle aynı saygı ve alaycılıkla ele alınır.

Şubat 2001'de kendilerine “The Agile Alliance” adını veren 17 yazılım uzmanı, “Çevik Yazılım Geliştirme Manifestosu” adını verdikleri belgeyi geliştirmek üzere ABD'nin Utah eyaletinde bir araya geldi. Dört değeri ve 12 ilkesi vurgulayan bu belge, günümüzde Çevik Manifesto olarak bilinir.

Çevik Manifesto'nun yazarlarından çoğunlukla Agile Alliance olarak söz edilir ve aralarında ekstrem programlama, Scrum ve Crystal'ın da bulunduğu çeşitli geliştirme süreçlerinin temsilcileri yer alır. 

Manifestonun resmî web sitesine hızlıca göz atmak, yazarları gizli bir topluluğu veya kurucu babaların buluşmasını andırabilecek bir ortamda gösterir. Niyetlerinin sektör üzerinde kalıcı bir etki bırakacak bir şey yaratmak olduğu açıktı. Nitekim öyle de oldu.

Utah'ta buluşan kişiler, genel olarak çevik ilkelerin öncüleri olmasalar da yazılım geliştirme dünyasında bir süredir arka planda şekillenmekte olan değerleri sağlamlaştırdılar.

Günümüzde çevik metodoloji neredeyse her sektöre nüfuz etmiş durumdadır.

Yazarlar şunlardı:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

Çevik Manifesto neden (hâlâ) önemli?

Çevik Manifesto, insan odaklı çalışma biçimlerine ve esnekliğe izin vermeye odaklandığı için hâlâ geçerliliğini korumaktadır.

Hızlı teknolojik değişimler çoğu zaman değişen proje gereksinimlerini de beraberinde getirir. Çevik Manifesto, aynı anda iş teslim edebilen, yenilik yapabilen ve gerektiğinde yön değiştirebilen duyarlı ve dayanıklı bir proje ortamı oluşturarak proje yöneticilerinin uyarlanabilirliğe ve iş birliğine öncelik vermesini sağlar.

Ayrıca kapsamlı belgeler yerine çalışan çözümlere değer vererek müşteri odaklı bir zihniyeti teşvik eder. Bu, proje yöneticilerinin erken aşamada geri bildirim toplamasına ve çalışmalarını sürekli olarak geliştirmesine olanak tanır; böylece projenin kullanıcı ihtiyaçlarıyla yakından örtüşmesi sağlanır. Bu yinelemeli ve müşteri odaklı yaklaşım, proje başarı oranlarını ve memnuniyeti artırır.

Çevik Manifesto nasıl uygulanır?

Çevik manifestonun dört değerinin her birini biraz daha ayrıntılı inceleyelim. Temel değerleri gözden geçirirken, her birine karşılık gelen 12 ilkeyi de ele alacağız.

Değer #1: Süreçler ve araçlar yerine bireyler ve etkileşimler

Çevikliğin temelinde insanlar vardır. Çevik yaklaşım, bir ekibin birlikte çalışmasını, yakın iş birliği yapmasını ve kararları bağımsız olarak almasını vurgular. Çeviklik, bir ekibe ne yapacağını veya ne geliştireceğini söylemekle ilgili değildir. 

Çevik projelerde iletişim tanımlanmış ve planlanmış değil, serbest akışlı ve sürekli olmalıdır. Çeviklik, birbirinden kopuk silolar içinde çalışmak değildir.

Ekip iletişimini değerlendirin

Kendinize şunu sorun: Siz ve ekibiniz yüz yüze görüşmeler yapıyor musunuz? Yoksa e-postalara, belgelere ve çok sevilen bazı mesajlaşma araçlarına mı güveniyorsunuz (burada isim vermeyeceğim)? 

Uzaktan çalışıyor olsanız bile yüz yüze bir görüşme, işlerin daha hızlı ilerlemesini sağlayabilir. Özellikle bir ekip yeni oluşturuluyorsa eş zamanlı iletişim güveni ve açıklığı teşvik eder, ayrıca ilişkilerin kurulmasına yardımcı olur.

Kontrol manyaklığını bırakın

Zaman zaman hepimiz bu konuda suçluyuz. Ancak güven, çevikliğin ayrılmaz bir parçasıdır. Hemen uygulayabileceğiniz bir şey mi arıyorsunuz? MİKRO YÖNETİM YAPMAYIN (evet, bunu özellikle büyük harflerle yazdım).

Görevleri ayrıntılı bir şekilde tanımlayıp ekibe dağıtmak ve ardından belirlenen teslim tarihine uyana (ya da uymayana) kadar bunları takip etmek, böylece her şey üzerinde kontrol sahibi olmak cazip gelebilir. Ancak ekibinizi gerçekten güçlendirmek için biraz geri çekilmeli ve çalışmalarının sorumluluğunu üstlenmelerine izin vermelisiniz!

Kendi kendini organize eden bir ekibi teşvik edin

Konu yönetmek değil; liderlik etmek ve kolaylaştırmaktır. Kendi kendini organize eden bir ekip, çalışmalarını en iyi nasıl tamamlayacağına kendi karar veren ekip demektir. İş listesini yayımlanabilir koda nasıl dönüştüreceklerine kendileri karar vermelidir. Ancak işi diğer uca götürüp hiçbir yardım veya yönlendirme sağlamayın; ekibin hâlâ bir vizyona, motivasyona ve engelleri aşmak için yardıma ihtiyacı vardır.

Bu durumda, görevleri dağıtmayı bırakıp çalışmayı nasıl kolaylaştırabileceğinizi nasıl belirleyebilirsiniz?

Süreç veya araç konusunda stres yapmayın

Biliyorum, biliyorum—proje yönetimi araçları ve çevik proje yönetimi yazılımı hakkında konuşmalar çevik PM dünyasında sürekli karşımıza çıkıyor.

Ama mesele şu: Müşteriniz kendi çevik iş akışı sürecinizle ilgilenmez. Zaten ilgilenmemelidir.

Çeviklik, müşteriyi merkeze alan bir yaklaşım benimsemek ve ekibinizin daha iyi ve daha değerli işler sunmasını sağlamaktır. Müşteriyi merkeze alan yaklaşım hakkında daha fazla bilgi ileride!

Yalıtılmış çalışma alanlarını ortadan kaldırın

Yalıtılmış çalışma alanları iş birliğini engeller ve bu nedenle çevik değerlerden uzaklaştırır. 

Yalıtılmış çalışma alanlarından uzaklaşmak için şu ipuçlarını değerlendirin:

• Ekibi aynı yerde konumlandırın: Evet, bunu yine söylüyoruz. Tasarımcılarınızın birbirlerine yakın oturup tasarım hakkında konuşabilmeleri harika, ancak bu harika ürünü geliştirme konusunda geliştiricilerle konuşmaları daha iyi olmaz mı? Bunu daha büyük bir kuruluşta veya uzaktan çalışma ortamlarında uygulamanın zor olabileceğini biliyorum, ancak ortak bir Slack kanalında bir araya gelmek ya da insanların aynı anda ve uzaktan derinlemesine çalışabilecekleri planlı ortak çalışma oturumları düzenlemek bile ekibinizin daha bağlantılı kalmasını sağlayabilir.
• Bölümler arasındaki iş aktarımlarını caydırın: Her bölümün aşamalar hâlinde çalıştığı (UX, ardından tasarım, sonra geliştirme ve son olarak QA) daha katı, şelale benzeri yaklaşım genellikle iletişim kopukluklarına neden olabilir ve bir projedeki israfı artırabilir. Ekibinizin işleri bir zincir boyunca aktarmak yerine özellikler üzerinde birlikte çalışmasını sağlayın. Öncesinde bir tasarım sprinti olmak üzere sprintlerle çalışsanız bile geliştiricilerinizi tasarım sprintine dâhil edin—sonuçta bunu onlar geliştirecek!

Değer #2: Kapsamlı Belgeler Yerine Çalışan Yazılım

Manifestonun belgeleri ortadan kaldırmayı önermediğini unutmayın; yalnızca soldaki öğelere sağdakilerden daha fazla değer verir. Bu, belgelerin hâlâ var olduğu anlamına gelir. Örneğin Scrum, geliştiriciye geliştirmeye nasıl başlayacağını bildiren kullanıcı hikâyelerine sahiptir.

Peki yoğun ve zaman kaybettiren belgelerden uzaklaşıp hızla somut bir ürüne geçmek için ne yapabilirsiniz?

Kullandığınız belgeleri yalınlaştırın

Sürecinizdeki sorunlu noktaları veya engelleri belirleyin. Belgelendirmeye fazla mı ağırlık veriyorsunuz? Kusursuz gereksinim belgesini hazırlamak, işlevsel kapsam üzerinde uzun süre çalışmak ve ardından ürünü geliştirmek için zaman bulamamak gibi bir durum yaşıyor musunuz? Gereksiz belgeleri şu yollarla azaltın:

• Sonuçta kullanılmayacak yazılı bir belge yerine doğrudan ürünün kendisine katkı sağlayacak tasarım ve geliştirme görevlerine odaklanın
• Uzun belgeler yazmak yerine gereksinimleri ve sonraki adımları önceden tanımlamak için atölye çalışmaları düzenleyin. Sonuçları fotoğraflar ve kısa notlarla belgeleyip paylaşın.

Geliştirmeye hızla başlayın

Gereksinim belgelerini sayfalarca yazmak, işletmenin, müşterinin ve son kullanıcının ihtiyaçlarını haritalandırmanın bir yoludur. Ancak sonuçta çalışan, davranış gösteren ve tepki veren bir şey görmek çok daha faydalıdır.

Projenizi hızla ilerletmek için aşağıdaki yöntemlerden bazılarını değerlendirin:

• Ön keşif veya tanımlama sürecini daha kısa bir zaman dilimine sıkıştırın: Tanımlama ve işleri netleştirme için harcadığınız süreyi sınırlamak, tasarımcıların ve geliştiricilerin daha hızlı ele alabileceği bir noktaya ulaşmanızı sağlar. Bu keşif oturumu sorularını kullanarak süreci hızlandırabilirsiniz.
• Atölye çalışmaları düzenleyin: Ekip atölyeleri düzenlemek, paydaşları bir araya getirerek daha hızlı karar almalarını sağlar.
• Proje planınızı değiştirin: Tanımlamayı, ardından tasarımı ve sonra geliştirmeyi aşamalı hâle mi getirdiniz? Geliştirmeyi öne almayı ve tasarımcılarla geliştiricilerin daha erken bir aşamada birlikte bir şeyler üretmesini değerlendirin.

Düz tasarımlar yerine prototipleme yöntemlerini kullanın

İlerlemeyi, müşterinizin onaylaması için bir onay kutusu görevi gören bir tanım belgesi veya düz bir tasarım olarak görmek yerine, onlara tamamlanmış ürünün bir parçası hâline gelecek bir şey gösterin.

Çalışan ve kullanılabilir bir şey, daha da önemlisi müşterilerle test edebileceğiniz bir şey elde etmek için hızlı prototipleme kullanın. Bir prototip hakkında geri bildirim toplamak, son ürünün bir parçası olma avantajına sahip olmayan bir teslimata güvenmek yerine ilerlemeyi takip etmenin yararlı bir yolu hâline gelir.

Farklı ayrıntı düzeylerinde prototipler oluşturabilirsiniz:

• Düşük ayrıntı düzeyi: Tıklanabilir tasarımlar. Bu, müşterilerle test etmek üzere hızlıca bir taslak oluşturmanız gerektiğinde, görünüm ve hissiyat ile basit etkileşimleri test etmeye daha uygun bir yaklaşımdır.
• Orta ayrıntı düzeyi: Bazı hareket veya animasyonların kullanılması.
• Yüksek ayrıntı düzeyi: Çalışan HTML. Karmaşık etkileşimler için kullanılır, ancak yayımlanabilir koda dönüştürülerek ileride kullanılabilir.

Yüksek ayrıntı düzeyine sahip prototipler, diğer türlere kıyasla “çalışan yazılıma” daha yakındır ancak oluşturulmaları daha fazla zaman alabilir. Düşük veya orta ayrıntı düzeyine sahip prototipler, geliştiricilere düz tasarımlardan daha iyi rehberlik eder.

Son kullanıcıya veya müşteriye hızlıca bir şey sunun

Bu önemli bir noktadır.

Çalışan yazılımın sık aralıklarla yayımlanması sayesinde müşteri, yayımlanan yeni özelliklerle etkileşim kurabilir. Büyük patlama şeklinde bir lansman için projenin sonuna kadar beklemek yerine, müşterinize daha erken değer sunmak daha iyi bir ürün elde etmek açısından kritik öneme sahiptir.

Kuruluşunuzda daha sık teslimat yapmayı nasıl sağlayabilirsiniz?

• Proje planınızı veya proje yol haritanızı gözden geçirin: Geliştirmeyi tamamladıktan sonra projenizin sonunda lansman yapmayı mı planladınız? Bunun yerine ekibinizle birlikte çalışarak işi, süreç boyunca bağımsız olarak yayımlanabilecek özelliklere veya iş parçalarına ayırın.
• Engellere odaklanın: Sorunlar ortaya çıktığında ekibin önündeki engelleri kaldırmasına yardımcı olmak rolünüzün temel bir parçasıdır. Daha verimli teslimat yapmalarına nasıl yardımcı olabilirsiniz? Sürümleri yavaşlatan çalışma biçimleri var mı? Ekibinizle bir iterasyon geriye dönük değerlendirmesi düzenlemek, süreç iyileştirme fırsatlarını ortaya çıkarabilir.
• Otomatikleştirin: Kuruluşunuz sürümler için büyük çaba harcıyorsa, mümkün olan yerlerde süreçleri otomatikleştirin. Örneğin otomatik test ve dağıtım, manuel iş gücünden tasarruf sağlayabilir ve bir sürüm için gereken çaba düzeyini azaltabilir. Çevik geliştirme ekibinizle kullandıkları süreçler ve otomasyon fırsatları hakkında konuşun.

Değer #3: Sözleşme müzakeresi yerine müşteri iş birliği

Bir projenin başında kesin teslimatları, kapsamı, bütçeyi ve zaman çizelgelerini ayrıntılı olarak belirleyen son derece özel bir sözleşme hazırlamak yerine, çevik sözleşmenizi mümkün olduğunca üst düzey tutun. Projeniz boyunca müşterileriniz ve paydaşlarınızla yakından iş birliği yaparak kararları netleştirin.

Çevik yaklaşım, gereksinimleri önceden tanımlamak için çok fazla zaman harcamakla ilgili değildir. Bir projeye başlayıp çalışan yazılımdan elde edilen müşteri testleri ve geri bildirimlerine dayanarak süreç içinde öğrenmekle ilgilidir.

Müşteri odaklı bir yaklaşım benimseyin

Neil Killick'in makalesindeki şu alıntıyı çok seviyorum:

“Çevik düşünen biri sürekli olarak ‘Müşteriye değer sunmanın en basit/en hızlı yolu nedir?’ diye sorar. Bu soruyu her gün soruyor musunuz? Sormuyorsanız, ilk adımınız burada.”

Bunu düşünmesi gerekenler yalnızca tasarımcılar ve geliştiriciler değildir; proje yöneticileri de düşünmelidir. Bir müşteriye mümkün olan en iyi ürün veya hizmeti sunmaktan biz de sorumluyuz. Ürününüzün veya hizmetinizin kullanıcısı olan müşteriniz, yaptığınız her şeyin merkezinde olmalıdır.

Son müşteriyi planın merkezine koyun

Planınızı teslimatlar ve tahminler etrafında yapmak yerine, değerli müşteri sonuçları etrafında yapın. Müşterinin ne yapmasını istiyoruz ve neden? Bunun işe yaradığını nasıl ölçeceğiz?

Konuşmayı, kaç iş öğesi teslim ettiğimize değil, müşteri için ne kadar değer sunduğumuza odaklanacak şekilde yeniden çerçeveleyin.

Müşterinizi sürece yakından dâhil edin

Haftalık bir durum toplantısı düzenleyip belirli bir dönemin sonunda müşterinize ve paydaşlarınıza teslimat yapmak yerine, müşterinizi projeye günlük olarak dâhil etmeye çalışın.

Daha çok Scrum süreci yürütüyorsanız, müşteriyi ürün sahibi yapın. Ürün sahibi; iş, teknik ve müşteri gereksinimlerini bir araya getirmekten sorumludur. Gecikmeleri önlemek için müşterinin erken aşamada ve sık sık desteğini almak ve iş birliğini sağlamak kritik öneme sahiptir. Bu, sonuçta son müşteri için daha iyi bir ürün veya hizmet ortaya çıkarır.

Uzak bir müşteriyi sürece dahil edin

Müşterinizin projeye katkıda bulunacak zamanı yoksa veya başka bir nedenle sürece dahil olmuyorsa, ekipte bir kişinin müşteriyi temsil ettiğinden emin olun. Birinin müşteri ve iş gereksinimlerini dikkate alması kritik öneme sahiptir.

Müşteri günlük olarak sürece dahil olmasa bile onunla düzenli iletişim kurduğunuzdan ve en azından tüm çevik planlama ve önceliklendirme görüşmelerine onu dahil ettiğinizden emin olun. Katılımının faydalarını göstermek için onunla birlikte çalışın.

Ürün yol haritası oluşturun

Ürününüzün gelişim rotasını belirlemek için bir ürün yol haritası kullanmayı değerlendirin. Ürün yol haritası, ürünle ilgili planı iletir ve teslim edilmesi planlanan özellikleri görselleştirir. Bir yol haritası projenin başında sabit değildir; bunun yerine önceliklerdeki değişiklikleri yansıtacak şekilde zaman içinde gelişir.

Son kullanıcılarınızla veya müşterilerinizle konuştuğunuzdan emin olun

Bunu ne kadar vurgulasam azdır—ürününüzü son kullanıcılar ve müşterilerle erken aşamada ve sık sık test etmeye çalışmalısınız. 

Test yapmanın pek çok faydası vardır:

• Ürününüzün müşteri ihtiyaçlarını karşıladığından, yani ürünün müşteri ve dolayısıyla işletme için değerli olduğundan emin olabilirsiniz. Bu, ürün-pazar uyumunu değerlendirmenize yardımcı olur.
• Müşteri geri bildirimlerini tasarım ve geliştirme sürecinize dahil edebilir, böylece daha iyi bir nihai ürün ortaya çıkarabilirsiniz.
• Gelecekteki çalışmalara yön verecek içgörüler elde edebilirsiniz.

• Müşteri testleriyle ilgili sıkça dile getirilen sorun bütçedir—bu testler pahalı olabilir. Proje bütçeniz ne olursa olsun test yapmanın bazı yolları şunlardır:

Gerilla testi: Bunu seviyorum çünkü ucuz ve kolaydır. Tasarımlarınız veya prototipiniz hakkında birkaç soruyu yanıtlamaları karşılığında insanlara gerçek (veya sanal) bir kahve ısmarlamayı teklif edin. Sorularınızı kimin yanıtlayacağını belirlemek daha zordur, ancak görünüm ve hissiyatı veya basit etkileşimleri test ederken hızlı geri bildirimler faydalı olabilir.

Anketler: Daha geniş bir insan grubundan nicel veri toplamak için tasarımı değerlendirecek veya müşteri davranışını daha derinlemesine inceleyecek bir anket oluşturabilirsiniz.

usertesting.com gibi siteler: Tasarımlarınızı bu sitelerden birine yükleyebilir ve bu siteler aracılığıyla insanları (gerekirse belirlediğiniz kriterleri kullanarak) çalışmaya dahil edebilirsiniz. Bu kişiler daha sonra tasarımlarınızda tıklayarak ilerler, düşüncelerini kaydeder ve soruları yanıtlar.

Yüz yüze test: Evet, bu daha pahalı bir seçenek olabilir; çünkü muhtemelen insanları bulmanız ve teşvik ödemeleri yapmanız gerekir. Ancak karmaşık etkileşimleri veya yüksek riskli özellikleri test ediyorsanız bu yöntem paha biçilmez olabilir.

Değer #4: Bir planı takip etmek yerine değişime yanıt vermek

Çevik ve şelale projeleri bu açıdan birbirinden daha farklı olamazdı. Geleneksel yazılım geliştirme projelerinde gereksinimleri, maliyeti ve zamanlamayı önceden belirlersiniz; çevik yaklaşım ise değişime izin verir ve değişimi benimser.

Değişim iyidir! Kötü değildir! Kaç proje planı başlangıçta oluşturduğunuz şekliyle tam olarak işe yaradı? Çok fazla olmadığını tahmin ediyorum (proje planının onlarca kez yinelendiği projelerde çalıştım.)

Planlar, belirli bir andaki en iyi tahmindir ve ilerledikçe bunları kesinleştirebilirsiniz—ancak genellikle değişime izin vermezler. Müşterinin ihtiyaçları değişirse ne olur? İşletme yön değiştirirse? Müşteriniz önceliklerini değiştirirse? Belirlenen özelliğin geliştirilmesinin düşündüğünüz kadar basit olmadığı ortaya çıkarsa?

Çevik çalışma yöntemleri, uyarlanabilir bir planlama yaklaşımını (örneğin planlama pokerini) benimseyerek belirsizliği kabul eder. Örneğin Scrum değerleri, ekibin çalışmayı sprint sprint planlamasını öngörür. Çevik ekipler, zamanla sınırlı bir çalışma dönemine başlamadan önce iş listesinden öğeler alır ve bunları geliştirme için önceliklendirir.

Bir projenin başında maliyetleri, zaman çizelgesini ve kapsamı kesinleştirmek için genellikle baskı yapılsa da karşılaştığınız belirsizlikler konusunda daha gerçekçi olmak, çoğu zaman çok daha iyi bir nihai ürün ortaya çıkarır. Sonuçta sizin, müşterinin ve paydaşlarınızın istemesi gereken şey budur. 

Projelerinizde değişime olanak tanımaya ve daha fazla esnekliği teşvik etmeye başlamanın bazı yolları şunlardır:

Paydaşları memnun etmek için “hafif” bir plan oluşturun

“Ama bir plana ihtiyacımız var!” diye bağırır paydaşlarınız. “Sürpriz, plan yok!” diyerek onları paniğe sürüklemek yerine, biraz daha az resmî olan bu yaklaşıma güven duymalarını sağlamak için hafif bir sürüm planı oluşturun.

Çevik proje yönetimi ni Scrum süreçleriyle yürütüyorsanız, iş listenizde önceliklendirilmiş ve tahmin edilmiş kullanıcı hikâyelerinden oluşan bir listeniz vardır. Bunları kabaca sürümler hâlinde gruplandırmak ve ürün yol haritanızla eşleştirmek için ürün sahibiyle birlikte çalışın.

Her şeyi planlamamaya çalışın; aksi takdirde Scrum metodolojisini kullanmanın faydalarını ortadan kaldırırsınız. İlk iki veya üç sürümde ne planladığınızı paydaşlarınıza gösterin, ardından yeniden planlamanın çevik çalışma biçiminin temel unsurlarından biri olduğunu onlara anlatın ve ilerledikçe güncellemeleri ve sonraki sürümleri paylaşacağınızı belirtin. Umarız bu, ihtiyaç duydukları güveni onlara verir!

Ekibi sprint tabanlı bir yaklaşıma alıştırın

Mike Cohn, “Bir kuruluşa çevik süreç kazandırmak” başlıklı makalesinde, örneğin bir dizi sprint türü tanımlayarak ekiplerin Scrum'a alışmasını kolaylaştırmayı öneriyor:

• Prototip oluşturma
• Gereksinimlerin toplanması
• Analiz ve tasarım
• Uygulama
• Kararlılık

Burada bunun nasıl yardımcı olabileceğini açıklıyor:

“Daha sonra ekiplerle birlikte çalışarak her sprint türünden ortaya çıkacak çıktıları tanımlarız. Sprint türlerini kullanmak, ekiplerin proje boyunca izleyecekleri yolu daha net görmelerini sağlayacak kadar biçimsel bir yapı sunar. Ekipler çevik sürecin biçimsel olmayan yapısında daha yetkin hâle geldikçe sprint türleri kavramını aşamalı olarak bırakırlar.”

Bu, sürüm planınızı şekillendirmenin başka bir yoludur. Her sprint'e bir “tür” atarsanız, paydaşlarınız planın nasıl şekillendiğini görebilir; siz de özellikleri garanti etmek zorunda kalmazsınız. Ekibiniz de üzerinde çalışacağı şeyler hakkında daha iyi bir fikir edinir.

Sabit teslim tarihlerinden uzaklaşın

Ekibinize bir son teslim tarihi vermek veya müşterinize sabit bir tarih bildirmek, başarısız olmaya mahkûm ya da en azından süreç boyunca strese yol açacak stratejilerdir. Siz ve ekibiniz ile müşteriniz veya paydaşınız arasında güven oluşturmak, son müşteriye teslimat yapacağınızı ve değer sunacağınızı kanıtlamak için çok önemlidir.

Unutmayın, birden fazla kontrol noktası ve onay ihtiyacını azaltmaya çalışıyorsunuz. Projenize son teslim tarihleri koymak bu hedefe ulaşmanıza yardımcı olmaz. Ekibinizin ensesinde boza pişirmek ve “teslim edeceklerine söz verdikleri” işler için onları sürekli takip etmek de iyi bir yaklaşım değildir.

Yukarıda belirttiğim gibi, yol haritaları ve sürüm planları sabit tarih yaklaşımından uzaklaşmak için iyi bir mekanizma olabilir. Paydaşlara yakın gelecekte nelerin yayımlanacağı hakkında fikir vermek, bir plan olduğunu bilmelerini sağlayabilir.

Zaman ve malzeme temelli kapsam kullanın

Sabit fiyatlı ve sabit çıktılardan oluşan bir kapsamınız varsa, daha çevik bir şekilde teslimat yapmak zordur. Daha iş birliğine dayalı bir ekip oluşturmak gibi daha önce ele aldığım tekniklerden bazılarını kesinlikle kullanabilirsiniz. Ancak değişime ne ölçüde yanıt verebileceğiniz ve uyum sağlayabileceğiniz, ekibin ne üzerinde çalışacağına karar vermesine izin verebileceğiniz veya daha müşteri odaklı bir yaklaşım kullanabileceğiniz sınırlı olacaktır.

Zaman ve malzeme temelli bir kapsam oluşturmak için kurum içi ekibiniz ve müşteriyle birlikte çalışın; yani müşteri sabit çıktılar yerine bir ekip için ödeme yapsın. Müşteriler başlangıçta tam olarak ne elde edeceklerini bilmediklerinde endişelenebilir.

Bu endişeyi azaltmak için kapsama, lansman için değerlendirilebilecek faaliyet veya görevlerden oluşan bir iş listesi ekleyebilirsiniz. Sözleşmede, proje ilerledikçe ekibin müşterinin katkılarıyla iş listesini yeniden planlayacağını ve önceliklendireceğini belirtin (ancak her maddeyi ele almayabilirsiniz).

Değişen öncelikleri ve çıktıları yönetmeye yardımcı olmak için ekipler, iş listelerini sürekli olarak yeniden önceliklendirmek üzere çevik yönetim yazılımlarından, işlevler arası iş birliğini koordine etmek için de yazılım geliştirme iş birliği araçlarından yararlanabilir.

Bu şekilde sabit bir kapsama bağlı kalmazsınız; ancak müşteri, nihai ürünün nasıl görüneceği konusunda daha az endişe duyar.

İlerlemeyi izlemeye devam edin

Resmî bir proje planının olmaması, ilerlemenin izlenmesini ve görselleştirilmesini bir kenara bırakmanız gerektiği anlamına gelmez. İlerlemeyi ekip ve paydaşlar için görünür tutmak, olası engelleri ve darboğazları gözden kaçırmamanızı sağlamakla kalmaz, aynı zamanda paydaşları da gelişmelerden haberdar eder. 

Kanban tarzı bir WIP panosu veya çevik gösterge panoları kullanmak, çevik projeler için iyi sonuç verir. Sürecinizi görselleştirdikten sonra destekleyici görevleri ve faaliyetleri haritalamaya başlayabilirsiniz. Bu, müşteriye daha hızlı teslimat yapabilmek için ortadan kaldırabileceğiniz darboğazları fark etmenize yardımcı olur.

Çevik Manifesto'ya yönelik eleştiriler

Diğer tüm proje yönetimi metodolojileri gibi, çevik yaklaşım da kusursuz değildir. Eleştirmenler, Çevik Manifesto'nun yazarlarının, uzaktan çalışmanın faydaları veya çevik yaklaşımın yazılım geliştirme alanı dışında nasıl uygulanabileceği gibi alternatif çalışma yöntemlerini dikkate almamış olabilecek homojen bir grup olduğunu belirtir.

Aşırıya kaçıldığında çevik yaklaşım, işlerin ilerleme hızını yavaşlatan komite tarafından karar alma anlamına gelebilir. Belgelerin eksikliği, özellikle eşzamansız iletişimin kritik olduğu uzak bir çalışma ortamında, projenin teslim edilmesine zarar verebilir.

Projelerinizde çevik yaklaşımı kullanmaya karar verirseniz, çevik değer ve ilkelerine başvurduğunuzdan emin olun. Bunlar, çevik yaklaşımın en olumsuz eğilimlerini kontrol altında tutmak için yararlı bir rehberdir.

Çevik yaklaşımın bir metodoloji mi yoksa bir zihniyet mi olduğu tartışması hakkında daha fazla bilgiye buradan ulaşabilirsiniz.

Çevik Değil, Çeviklik

Son bir düşünce: retrospektifi unutmayın! Manifesto'da şöyle belirtilir:

Ekip, düzenli aralıklarla nasıl daha etkili olabileceğini değerlendirir, ardından davranışlarını buna göre düzenler ve uyarlar.

Hangi tür süreci yürütüyor olursanız olun, retrospektif, nasıl çalıştığınızı incelemek ve başarı için optimizasyon yapmak üzere etkili bir yöntemdir. Kullandığınız süreç ne olursa olsun, sürece düzenli olarak proje retrospektiflerini dahil ettiğinizden ve öğrendiklerinizi sürece dahil etmek için bir mekanizmanız olduğundan emin olun! Not: Retrospektiflerde sessiz ekip üyelerinizin de konuşmasını sağlamak önemlidir—bunu nasıl yapacağınızı buradan öğrenebilirsiniz.

Sırada Ne Var?

Çevik çalışma yöntemlerini nasıl uygulayacağınızı öğrenmek ve sektördeki en iyi proje yöneticilerinden bilgi edinmek için DPM üyelik seçeneklerimize göz atın.