Çevik Nedir? Uygulama Yoluyla Gelişen Bir Felsefe

Başlangıçta yazılım geliştirme ekipleri için tasarlanan Agile, şimdi tüm dünyadaki endüstriler ve şirketler için önde gelen proje yönetimi yaklaşımıdır. Çekiciliği, sadeliği ve esnekliğinde yatmaktadır: Agile'ın kuralcı uygulamalardan yoksun olması, onu son derece kabul edilebilir kılmaktadır. Yine de, birkaç şirkette Çevik dönüşümlere rehberlik ederken, bu esnekliğin Çevik olmanın ne anlama geldiğine dair yanlış anlamalara yol açtığını gördüm. Birçok şirket, felsefenin kendisini anlamak yerine Çevik kaynaklı çerçevelere bağlı kalmaya öncelik verir.

Bunun yerine, Çevik ekipleri bir araya getiren ve yönlendiren proje yöneticileri ve koçlar, onları Çevik bir zihniyet benimseme konusunda eğiterek, esasen felsefenin temel değerlerini ve ilkelerini içselleştirerek başlamalıdır. Ancak o zaman, proje gereksinimlerine en iyi hizmet eden şeye dayalı olarak Çevik çerçevelerdeki uygulamaları birleştirmeli, özelleştirmeli veya ihmal etmelidirler.

Bu makale, Agile'ın tarihsel gelişimini takip ederek ve kuruluş ilkelerini şirketlerin ve ekiplerin özel ihtiyaçlarına bağlayarak, proje yöneticilerinin Çevik dönüşümler için optimal bir gelecek yaratmasına yardımcı olabilir. Aşağıdaki vakaların gösterdiği gibi, Agile katı bir şekilde bir proje yönetimi yaklaşımı olarak değil, pratikte sürekli gelişen bir ürün geliştirme felsefesi olarak düşünülmelidir.

Çevik Öncüller

İlk olarak 2001'de derlenen, dört temel değer ve 12 ilkeden oluşan kısa ve öz bir derleme olan “Çevik Yazılım Geliştirme Manifestosu”, kurallar ve yığınla dokümantasyonla dolu doğrusal, süreç ağırlıklı yaklaşımlara radikal bir yanıttı. Ancak Agile'ın tarihi, endüstriyel üretimi kolaylaştıran bir yöntemle onlarca yıl önce ortaya çıktı.

Yinelemeli iyileştirmeye odaklanma felsefesinin bir öncülü olan Planla-Yap-Çalıştır-Act modeli 1930'larda Bell Labs fizikçisi ve istatistikçi Walter Shewhart tarafından geliştirildi. İkinci Dünya Savaşı'ndan sonra, himayesi altındaki W. Edwards Deming, Toyota'daki yönetici yetiştirmek için bunu uyguladı. Yöntem, verimli yap-ölç-öğren döngüsüyle Yalın düşüncenin ana kaynağı olan Toyota Üretim Sisteminin geliştirilmesinin ayrılmaz bir parçasıydı.

1970'lerde, Barry Boehm, yazılım geliştirmek için gereken emek ve zamanı doğru ve nesnel olarak tahmin etmek için yinelemeli bir süreç kullanarak Geniş Bant Delphi tekniğini önerdiğinde kavram daha da geliştirildi.

1980'lerin ortalarında kişisel bilgisayarların yaygınlaşmasıyla birlikte, bir ürün ve hizmet olarak yazılımın insanların iş yapma biçiminin temel taşı haline geleceği anlaşıldı. Profesyoneller yazılım mühendisliğine yönelik artımlı, yinelemeli yaklaşımlara ciddi önem vermeye başladıkça, Agile, üstün geliştirme ve yönetim yaklaşımı olarak Şelale süreçlerini geride bıraktı.

Araştırmacılar, rakiplerinden daha hızlı yenilik yapan üreticilerin, bir ürünü yaşam döngüsü boyunca taşımak için çok disiplinli, ekip odaklı bir yöntem kullandıklarını buldu. Bu, Jeff Sutherland'ın 1993'te Scrum çerçevesini icat etmesi için ilham kaynağı olarak kabul edilir ve bu, ona görünüşte imkansız projeleri programa ve bütçeye uygun olarak minimum hata ile tamamlamasını sağlar.

Teoride - bu öncüllerden ortaya çıkan - çevik değerler, yinelemeli geliştirme, işbirlikçi ekip çalışması ve doğru tahmin üzerinde durularak, pratikte Çevik kullanımımda doğrulandı.

Teoride Çevik Nedir?

Şirketler, Çevik çalışma yöntemlerini benimsemeye devam ettikçe, bunu felsefenin kurucularının şimdiye kadar amaçladığından daha kuralcı hale getirme riskiyle karşı karşıyadır. Tecrübelerime göre, Çevik'i benimsemek isteyen liderler, değerler ve ilkeler üzerinde yeterince değil, çerçevelere veya belirli uygulama kümelerine ve bunlarla ilişkili terminolojiye çok fazla odaklanırlar.

Çevik ilkeleri uygulama konusunda ileri düzeyde olan uygulayıcıların iyi bildiği gibi, Çevik bir dönüşümden geçmek isteyen her kuruluş kendilerine uygun yaklaşımları bulmalı ve uyarlamalıdır. Takımlara manifestonun değerlerini ve ilkelerini nasıl izleyeceklerini göstererek ve ardından bunları pratikte uygulamak için Scrum, Kanban ve Extreme Programming (XP) gibi çerçevelerden ilham alarak bu öğrenme sürecini kolaylaştırıyorum.

Manifestonun ilkeleri artık Çevik proje yöneticilerinin ikinci doğasıdır:

1. Süreçler ve araçlar üzerinden bireyler ve etkileşimler
2. Kapsamlı belgeler üzerinde çalışan ürünler
3. Sözleşme müzakeresi üzerinden müşteri işbirliği
4. Bir planı takip ederek değişime yanıt verme

Ancak manifestoda bu ilkeleri izleyen uyarı genellikle gözden kaçıyor: “Yani, sağdaki öğelerde değer varken, soldaki öğelere daha fazla değer veriyoruz.” Birçok Agile uygulayıcısı sonunda sağdaki değerleri göz ardı eder ve sadece soldakine odaklanır. Sonuç? Süreç ağırlıklı çerçeveleri körü körüne takip etmenin tersi: eşit derecede sorunlu olan hiç süreç yok.

Sağ ve soldaki öğeler arasında uygun dengeyi kurmak, Çevik dönüşümlere nasıl rehberlik ettiğimin anahtarı haline geldi. Apple, Google, Amazon, Facebook ve Netflix'in hiçbiri tekil bir Çevik çerçeveye abone olmayan yönetim yaklaşımlarıyla da örneklendirilmiştir. Onlar, kendileri için en iyi olanı temel alarak farklı çerçevelerin parçalarını takip ederken veya değiştirirken, her şeyden önce manifestonun ilkelerini somutlaştırdılar; sonuç olarak, pazar değişikliklerine uyum sağladılar ve yeni ürünleri hızlı bir şekilde sunabiliyorlar.

Pratikte Çevik Nedir?

Aşağıdaki genel bakışta, manifesto değerlerinin orijinal ifadesini değiştirdim. Anlambilimdeki değişiklikler, Çevik değerleri pratikte nasıl uyguladığımı netleştirmeye yardımcı olur.

İlk değerde, “bireyler” terimini “insanlar” ile değiştiriyorum çünkü çevik olmak takım odaklı olmak demektir. İkincisine gelince, yazılımın “çalışır” olması gerektiği aşikardır, bu nedenle odak noktası artık başarılı ve zamanında “teslimat” üzerindedir. Üçüncü değer, birlikte çalışan iş arkadaşları ve müşterilerle çalışan ekipler için eşit derecede geçerli olduğu için basitçe “işbirliği”dir. Son olarak, "çerçeveler", "bir planı takip etme"nin yerini alır, çünkü bu, planlamanın tamamen terk edilmesi gerektiği şeklindeki yanlış anlaşılmayı önler.

Süreçler Üzerindeki İnsanlar

Çevik dönüşümler zordur, çünkü çoğu işletme süreçleri sıkı bir şekilde takip etmeye çok alışkındır. Yenilikçi bir ürün geliştirmek yerine belirli bir takım araçlarla belirli sayıda adımı tamamlamak nihai hedef haline geliyor.

Bu zihniyetin karlı bir “Çevik endüstri” ortaya çıkardığını görmek beni dehşete düşürdü. Çevik kurucuları Ward Cunningham ve Jon Kern'in açıkladığı gibi, birçok işletme, şirketlerin "Çevik olmalarına" yardımcı olacağını iddia ettikleri yazılımlar satıyor. Ancak Çevik olmak, bir felsefe benimsemek, yazılım kullanmamak ve onun öngördüğü programı takip etmek demektir.

Doğru dengeye ulaşmak, prosedürleri ortadan kaldırmak değil, her takımın gelişim hedeflerini en iyi destekleyenleri bulmakla ilgilidir. Büyük bir kurumsal teknoloji kuruluşu olan müşterilerimden biri için IBM'de geliştirilen bir yaklaşım olan Disiplinli Çevik'i uyguladım. Scrum ve Kanban dahil olmak üzere birden çok çerçeveden birçok uygulamayı birleştirir. Yinelemeli geliştirmeyi kullanır, ancak özellikle başlangıç ​​aşamasında geleneksel Çevik'ten biraz daha ağırdır, çünkü Scrum tarafından bırakılan boşlukları doldurmayı amaçlar. Disiplinli Çevik bu müşteri için çalıştı çünkü organizasyon çok süreç odaklıydı. Takımlarla yarı yolda buluşmama, katılımlarını almama ve onları bir Scrum iş akışını benimsemeye ikna etmeme izin verdi.

Ekip içi ve ekipler arası işbirliğini kolaylaştırmak için biriktirme listesi iyileştirme toplantıları, gözden geçirme toplantıları ve günlük scrum'ları dahil ettim. İş listesi iyileştirme, Scrum Kılavuzunun bir parçasıdır, ancak iyileştirme toplantıları değildir. Bunları, Agile acemiler için yararlı olan gelecek sprintlerde belirli özellikleri uygulamayı neden planladığımız hakkında sağlıklı bir sohbet sağlamak için ekledim. Ayrıca, Waterfall proje yönetiminde kullanılan bir terim olan "kilometre taşları" terminolojisini de müşteriye daha tanıdık geldiği için seçtim. İncelemeler ve günlük scrum etkileşimleri, Scrum Kılavuzundaki geleneksel öğelerdir, ancak ben onları program, süre ve akış açısından daha yapılandırılmış hale getirdim.

Ek olarak, Scrum'a sıkı sıkıya bağlı kalmak her kişinin Scrum Kılavuzunda listelenen rollerden birine tamamen adanmasını sağlarken, müşterimin takımlarında beceri setleri tek bir role tam olarak uymayan insanlar vardı. Disiplinli Çevik yöntemini kullanmak, bu pozisyonların sorumluluklarını birden fazla ekip üyesi arasında bölmeme ve ilgili kişilerin güçlü yanlarına dayanan bir süreç oluşturmama izin verdi.

Belgeler Üzerinden Yazılım Teslimi

Herhangi bir çerçeveye sıkı sıkıya uymak yerine özelleştirilmiş Scrum veya Kanban iş akışlarını tercih etmemin bir başka nedeni de, bana bir amaç olarak plana minimum uygulanabilir ürünü (MVP) ekleme fırsatı vermeleridir. Yalın'dan türetilen bir MVP oluşturma uygulaması, yinelemeli geliştirme ile tutarlıdır ve Çevik uygulayıcılar arasında popüler bir teknik haline gelmiştir. Bir ekibin yüksek kaliteli yazılımları ve diğer ürünleri kullanıcılara verimli bir şekilde sunmasına ve ardından geri bildirime dayalı olarak iyileştirmesine olanak tanır. Bunu büyük ölçüde Scrum veya Kanban'a dayalı hibrit bir yaklaşımın parçası olarak uygulamak, ekiplerimin müşterilerin ihtiyaçlarını karşılayan ürünler yaratma yeteneklerini geliştirdi.

Şu anda ABD merkezli bir girişimle çalışıyorum ve bu yöntemi NFT'ler için bir kripto para birimi piyasası oluşturmak için kullanıyorum. MVP'yi oluşturmaya odaklanıyoruz, bu nedenle şimdilik yalnızca gereken minimum belgeleri yazıyoruz. Bu yaklaşım geniş bir ürün yelpazesi için etkili olsa da, özellikle hızla değişen yeni, deneysel bir kategoride yer alan kripto para birimi ve NFT'ler için kullanışlıdır. Tüm teknik özellikleri ve özellikleri taslak haline getirmek ve piyasaya sürülmeden önce bunları tekrar tekrar değiştirmek zorunda kalmak yerine, bu zamanı pazar geliştirmemizi geliştirmek için kullanıcı geri bildirimlerini dahil etmeye ayırabiliriz.

Sözleşmeler Üzerinden İşbirliği

Yukarıda bahsedilen büyük kurumsal teknoloji organizasyonu, birçok sabit maliyetli proje için büyük ölçüde sözleşmelere dayanıyordu. Sözleşmeler, işi tamamlamak için kullanacakları yöntemlerin yanı sıra her bir görevden sorumlu olacak belirli kişileri özetledi. Bir kez imzalandıktan sonra, sözleşmeler uzun bir talep süreci olmaksızın değiştirilemezdi.

Dönüşümün bir parçası olarak, bu katı anlaşmalar yerine işbirliğine öncelik verdim. Uyguladığımız plan, sözleşmeleri tek sayfalık belgelerle değiştirdi. Her biri, belirlenen başlangıç ​​ve bitiş tarihleri ​​arasında müşterilerimizle, ekip arkadaşlarımızla ve farklı ekiplerden iş arkadaşlarımızla işbirliği içinde çalışmak için Agile'ı kullanmayı kabul ettiğimizi belirtti. İşbirliğinden ne çıkarsa çıksın sonuç o olacaktı. Bitmiş ürünlerin ne olabileceğine dair ayrıntıları dahil etmedim. Müşteri geri bildirimi talep ettiğimiz ve bunu ürün geliştirmemize dahil ettiğimiz için, plan belgemizden spesifikasyonları kaldırmak, onların yanıtlarına daha açık olmamızı sağladı ve onları bizimle daha aktif çalışmaya teşvik etti.

Yönetimi dahil etmek için, geliştirme sürelerinin çok uzun olduğuna dair endişelerini dile getiren küçük bir müşteriyle çalışan küçük bir ekiple, herhangi bir gerekli değişiklik sorunu daha da karmaşık hale getirmeden önce, bir konsept kanıtı yönetmeme izin vermelerini istedim. Bu müşteriyi doğrudan ürün sahibimizle işbirliği yaparak geliştirmenin ortasında değişiklikler yapabildik ve teslimat sürelerini önemli ölçüde kısalttık.

Bu sonuçlar, yönetimi planı daha fazla ekibe sunmama izin vermeye ikna etti. Genel olarak, kolaylaştırılmış sözleşme ve Çevik iş akışımız, ürün özelliklerini geliştirmek ve pazara sunmak için gereken süreyi azalttı.

Çerçeveler Üzerinden Uyarlanabilirlik

Bir sağlık teknolojisi şirketi olan başka bir müşterim de Çevik bir değerin her iki tarafının da önemini kabul etme, yani bir planı takip ederek değişime yanıt verme açısından bir denge kuramadı. Ancak bu durumda, kurumsal teknoloji müşterimin yaptığı hatanın tam tersini yapmıştı: Bir süreci çok katı bir şekilde takip etmek yerine, süreci büyük ölçüde ihmal ederken esnekliğe aşırı endekslenmişti. Mühendisler ne üzerinde çalışmaları gerektiğini nadiren biliyorlardı çünkü herhangi bir önceliklendirme veya program yoktu. Her gün bunu anlamaya çalışırken zaman ve üretkenlik kaybettiler ve daha az önemli görevleri daha önemli olanlardan önce tamamladılar.

CEO ve CTO'ya Scrum uygulamasını önerdim ve sprintlerin mühendisleri her gün ne üzerinde çalışacaklarına karar vermek yerine disiplinli olmaya ve iki haftalık artışlarla planlamaya zorladığını açıkladım. Ayrıca, ekibin ürün sorumluluğu eksikliğini giderecek bir ürün sahibi tutmalarını tavsiye ettim. Yöneticilerden, sonuçları görmeyi beklemeden önce ekipleriyle çalışmam için bana üç veya dört ay vermelerini istedim.

Onaylarını aldıktan sonra, önce Çevik değerleri ve ilkeleri tanıttım, ardından ekibe ürün biriktirme listesi ve bunları düzenlemek için destanlar ve kullanıcı hikayeleri oluşturma ve alt görevler oluşturma dahil olmak üzere farklı teknikler konusunda eğitim verdim. İş akışımıza dahil ettiğimiz teknikler ve toplantılar, Scrum Kılavuzunda görünmedikleri için geleneksel Scrum'dan sapmalardır. Bunları plana dahil ettim çünkü destanlar, hikayeler ve alt görevler eğitim sırasında ekiplerde yankı uyandırdı ve toplantılar verimli tartışmaları teşvik etti.

Ayrıca, her ürün yinelemesindeki tüm kullanıcı öyküleri için toplam efor tahminlerini ölçen XP'ye geç eklenen hız kavramını da dahil ettim. Ancak, tercih ettiğim “kapasite” terimini kullandım çünkü bu, ekip üyelerinin görevleri ne kadar hızlı tamamlayabileceklerinden ziyade ne kadar iş alabileceklerini vurguluyor.

Tahmin için, projeleri ve görevleri küçük, orta ve büyük olarak ölçen bir teknik olan T-shirt boyutlandırma ile başladım; Ekip ilerledikçe, daha geleneksel bir tahmin tekniği olan hikaye noktalarına geçtim. Hikaye puanları genellikle, onları çalışma saatlerine veya günlerine dönüştürmeye çalışan, zaman çerçevelerine aşırı derecede odaklanan ve insanları son teslim tarihlerini karşılama yeteneklerine göre yargılayan Agile'da tecrübesiz ekipler tarafından kötüye kullanılır.

Tişört bedenleri daha soyuttur, bu da ekiplerin bu tuzaktan kaçınmasını kolaylaştırır. Ancak, aynı zamanda daha az kesindir. Bu yüzden ekip, göreceli terimlerle nasıl tahmin yapılacağını anladığında, onları daha karmaşık tekniğe geçirdim.

Ekip iki sprinti tamamladığında, üst yönetim çalışanlarının daha verimli çalıştığını ve daha etkili iletişim kurduklarını görebildi. Geliştiriciler ilk kez paydaşlar ve üst yönetimle etkileşim halindeydi. Müşteri destek ekibiyle tanışmışlar ve uyguladıkları özelliklerin kullanıcıların yaşamlarını nasıl iyileştirdiğini anlamışlardı.

Bu yaklaşım, kısa sürede şirketin yazılımının kalitesinde bir artışa ve yeni özelliklerin teslim süresinin aylardan haftalara düşmesine yol açtı.

Agile'ın Geleceği Nedir?

COVID-19 salgını, ekiplerin artık bir arada bulunamayacağı yeni bir gerçeklik yarattı ve bu, tasarlandığında Çevik içinde çalışmanın tercih edilen yoluydu. Bununla birlikte, böyle kalması gerektiği fikri bir efsanedir: Uzaktan çalışma yaygınlaştıkça, video konferans yazılımı ile yakın iletişimin tamamen mümkün olduğu ortaya çıktı. Şu anda birlikte çalıştığım ekipler tamamen dağıtılmış durumda ve uzaktan eğitim veriyorum. Bazı ekipler, Notion ve Loom gibi araçların yanı sıra Standuply gibi Slack eklentilerini kullanarak eşzamansız çalışmayı bile tercih ediyor.

Dağıtılmış işbirliği modeli, merkezinde çeviklik bulunan yeni çalışma dünyasıdır. Uzak ekiplere sağlanan iş-yaşam dengesi, üretkenliği ve kaliteyi artıran moral ve zihinsel sağlık üzerinde olumlu bir etkiye sahiptir; İnsanları süreçlerin üzerine koyar ve esnek ve uyarlanabilir, bu da onu özünde Çevik hale getirir.

Çevik koçlar, Scrum ustaları ve proje yöneticileri, felsefenin köklerine dönmeli ve onu manifestoyu hazırlayanların yaptığı gibi sunmalıdır: esnek ve dinamik bir geliştirme ve teslim yönergeleri seti. Yöneticilere ve ekip liderlerine, proje yönetiminden ilham alabilseler de Çevik'te gerçekten hiçbir şeyi yönetmediklerini, ekiplere rehberlik ettiklerini ve en iyi işlerini yapmaları için onları özgürleştirdiklerini öğretmelidirler.