Belgeye göre çevik geliştirme yöntemleri. Çevik geliştirme metodolojisi. Bir tanım yerine. Farklı departmanlardan farklı insanlar bir araya geldiğinde Agile hakkında ne söylenir?

Sakın kaybetme. Abone olun ve e-postanızdaki makaleye bir bağlantı alın.

Hiç projeler üzerinde çalıştınız mı veya en azından proje çalışmalarında yer aldınız mı? Eğer öyleyse, muhtemelen bir ekibin çalışmasını sağlamanın oldukça zor olabileceğini fark etmişsinizdir. Ve bu sağlansa bile, tüm çabaların boşa gitme riski vardır, çünkü istenen sonuca yönelik gereksinimler sıklıkla değişir.

Bununla birlikte, sistemi kullanarak proje üzerindeki çalışmayı önemli ölçüde basitleştirebilir ve onu nasıl yöneteceğinizi öğrenebilir, böylece ekibin verimliliğini artırabilirsiniz. esnek yönetimÇevik (“Çevik” veya “Çevik”) adı verilen projeler. Genel olarak (dördüncü dersimizde) bundan kısaca bahsetmiştik, ancak şimdi bu konu hakkında daha ayrıntılı olarak konuşacağız.

Çevik Yöntem: Tanımı ve Kısa Tarihçesi

Kulağa ne kadar sıradışı gelse de, ciddi yazılım geliştirme ve proje yönetimi geçen yüzyılın 70'lerinde başladı. 1970 yılında Amerikalı bilgisayar bilimcisi Winston Royce, “Büyük Yazılım Sistemlerinin Geliştirilmesinin Yönetilmesi” adlı bir belgeyi derledi. İçinde sıralı gelişmeyi eleştirdi ve gelişmenin şu olduğuna dikkat çekti: yazılım bir montaj hattının çalışmasına benzememelidir (örneğin, otomotiv üretimi), birbirini izleyen aşamalarda sırayla yeni parçaların eklendiği yer.

Royce, her aşamanın (aşama) tek tek tamamlanmasını beklemek yerine, aşama yaklaşımının kullanılmasını önerdi. Özü, proje için gerekli tüm gereksinimlerin başlangıçta toplanması, ardından tüm mimarinin tamamlanması, tasarımın oluşturulması, kodun yazılması vb.

Buna dayanarak 90'lı yıllarda karmaşık ve zaman alıcı yöntemlerin yerini alabilecek bir dizi esnek yazılım geliştirme yöntemi oluşturmak mümkün oldu. Şöyle oldu:

1991 yılında RAD hızlı uygulama geliştirme yöntemi tanıtıldı.
1994 yılında dinamik sistemlerin geliştirilmesine yönelik DSDM yöntemi ortaya çıktı.
1995 yılında esnek gelişim için Scrum platformu (çerçeve) ortaya çıktı.
1996 yılında çevik geliştirme metodolojisi Crystal Clear ve XP Extreme Programming ortaya çıktı
1997 yılında yinelemeli yazılım geliştirme metodolojisi FDD ortaya çıktı

Bu yöntemler birlikte esnek yazılım geliştirme yöntemleri genel adı altında birleştirilmiştir.

Dört yıl sonra, 2001'de on yedi yazılım geliştiricisi Utah'taki (ABD) Snowbird tatil beldesinde bir araya geldi. Geliştirme yöntemlerinin tartışılması sonucunda “Çevik Yazılım Geliştirme için Çevik Manifesto” yayımlandı (çev. İngilizce kavramı"Çevik", "çevik", "çevik" veya "hızlı" anlamına gelir, ancak çoğu durumda "esnek" olarak çevrilir. Yazılım oluşturma konusundaki tüm ileri çalışmaların hızını belirledi.

Çevik Manifesto

Programcılar tarafından oluşturulan manifesto 4 temel fikir ve 12 ilkeyi içeriyor Etkili yönetim projeler. Çevik tabanlı proje yönetim sistemlerinden herhangi biri (sistemler hakkında daha sonra konuşacağız), bunları farklı varyasyonlarda kullansa da, tam olarak bu fikir ve ilkelere dayanmaktadır.

İnsanlar ve onların etkileşimleri süreçlerden ve araçlardan daha önemlidir
Çalışan yazılım dokümantasyondan daha önemlidir
Müşteriler ve onlarla işbirliği, bir sözleşmeden ve şartların müzakere edilmesinden daha önemlidir
Değişiklik yapma isteği orijinal plandan daha önemlidir

Çevik ilkeler:

Yazılımı erken ve tutarlı bir şekilde teslim ederek müşterileri memnun edin (müşteriler, çalışan yazılımın düzenli aralıklarla gelmesinden memnun olur)
Nihai ürüne ilişkin gereksinimleri geliştirme döngüsü boyunca değiştirin
Çalışan yazılımı mümkün olduğunca sık teslim edin (haftada bir, iki haftada bir, ayda bir vb.)
Geliştirme döngüsü boyunca geliştiriciler ve müşteriler arasındaki işbirliğini destekleyin
Projeye katılan herkesi destekleyin ve motive edin (eğer görevleriyle, üyeleri çalışma koşullarından memnun olmayan bir ekipten çok daha iyi başa çıkıyorsa)
Geliştiriciler arasında doğrudan etkileşim sağlayın (doğrudan iletişim olasılığı daha başarılı iletişime katkıda bulunur)
İlerlemeyi yalnızca çalışan yazılım aracılığıyla ölçün (istemciler yalnızca işlevsel ve çalışan yazılım almalıdır)
Sürekli bir çalışma temposunu koruyun (ekip optimum ve sürdürülebilir bir çalışma hızı geliştirmelidir)
Tasarım ve teknik detaylara dikkat edin (etkili beceriler ve iyi tasarım sayesinde proje ekibi ürünü sürekli olarak geliştirebilir ve geliştirmek için çalışabilir)
İş akışını olabildiğince basit, yazılımı ise basit ve anlaşılır hale getirmeye çalışın
Ekip üyelerine izin verin (geliştiriciler kendi kararlarını verebilir, kendilerini organize edebilir ve diğer ekip üyeleriyle iletişim kurabilir, onlarla fikir alışverişinde bulunabilirse kaliteli bir ürün yaratma olasılığı önemli ölçüde artar)
Değişen çevreye sürekli uyum sağlayın (bundan dolayı bitmiş ürün daha rekabetçi olacaktır)

Agile'ı öğrenirken, fikirlere ve kurallara genel bir bakışın yanı sıra, bir uzmanın katıldığı bu kısa videoyu mutlaka izleyin. proje Yönetimi, danışman ve işletme koçu Alexey Tachenkov sistemin temellerini anlatıyor.

Yukarıdaki fikirleri ve ilkeleri gerçekten uygulamaya koymak için çeşitli kurallara uymanız gerekir. Ancak o zaman Çevik proje yönetimi etkili olabilir.

Çevik kullanımında önemli noktalar

Çevik metodoloji öncelikle görsel kontrole dayanmaktadır. Çoğu zaman, proje katılımcıları sonuçlara ulaşmak için çalışırken özel renkli kartlar kullanırlar. Bir renk, nihai ürünün bazı unsurları için planlamanın tamamlandığını, diğeri geliştirmenin tamamlandığını, üçüncüsü ise hazır olunduğunu vb. gösterir. Görsel kontrol, ekibin sürecin mevcut durumu hakkında net bir resme sahip olmasını sağlar ve tüm ekip üyelerinin proje için aynı vizyona sahip olmasını sağlar.

Çoğu durumda ekip üyeleri ve müşteri birlikte ve yan yana çalışır. Bu sayede proje katılımcılarının bilgilendirilmesi ile ilgili birçok iş süreci önemli ölçüde hızlandırılmaktadır. Ayrıca, işbirliği Verimli ve etkili işbirliği için sağlıklı bir atmosferin yaratılmasına ve sonuçların hızla alınmasına katkıda bulunur.

Proje yöneticisi, ekip ve müşteri birlikte çalıştığında hedeflerin yanlış anlaşılması ve bilgi kaybı riski ortadan kalkar. Tüm iş süreçleri mümkün olduğunca şeffaf hale gelir; bu da ortaya çıkan sorunların neredeyse anında çözülebileceği ve çözüm bulunabileceği anlamına gelir. en iyi seçenekler onların kararları.

Proje yöneticisine özellikle dikkat edilmelidir. Sağa sola talimat veren biri denilemez. Buradaki yönetici daha çok yönü belirleyen, işbirliğinin ve çalışmanın kurallarını belirleyen bir lider gibi hareket eder. Başka bir deyişle Çevik yönetim uyarlanabilir.

Bir tane daha önemli noktaÇevik metodoloji, tüm proje kapsamının birkaç küçük parçaya bölünmesidir bileşenler. Bu yaklaşım, geliştirme sürecini büyük ölçüde basitleştirir ve ayrı gruplar ekiplerin her biri kendi özel görevine odaklanabilir.

Proje katılımcıları tek döngü üzerinde çalışarak yeni becerilerde ustalaşır, yeni bilgiler kazanır ve aynı zamanda süreçte yapılan hataları analiz ederler. Bütün bunlar gelecekte (sonraki döngülerde ve diğer projelerde) benzer hataların yapılma olasılığını neredeyse sıfıra indirir.

Ve son olarak yaklaşımın son önemli unsuru sprintler ve günlük toplantılardır. Sprintler, bir takımın belirli görevleri tamamlamayı başardığı, belirli son tarihlerle sınırlı zaman dilimleridir. Takım, sprintler sayesinde eylemlerinin sonuçlarını görebilir.

Proje için ayrılan tüm zamanı birkaç sprint'e bölersek, belirli sayıda sprint elde ederiz; 15 tane olsun. Her sprint örneğin iki hafta sürer. Bu iki hafta boyunca (sprint için ayrılan süre) katılımcılar her gün süreci ve ilerlemeyi tartışmak için buluşurlar.

Günlük toplantılar 15 dakikayı geçmemelidir. Her ekip üyesinin kendisine üç sorunun cevabını vereceği şekilde düzenlenirler:

Dün ne yaptım?
Bugün ne yapacağım?
Beni çalışmaktan alıkoyan ne?

Bu soruları yanıtlamak, süreci kontrol altında tutmanıza, her ekip üyesinin hangi aşamada olduğunu anlamanıza ve hedefe giden yolda olası sorunları ortadan kaldırmanıza olanak tanır. Özetlemek gerekirse, Çevik metodolojinin uygulanması birkaç koşulun karşılanması durumunda mümkündür:

Projenin önemi açıkça belirtildi
Müşteri uygulama sürecine aktif olarak katılır
İşin toplam kapsamı adım adım gerçekleştirilir
Belirli bir sonuca odaklanmalısınız
Bir çalışma grubu sayısı: 7'den 9'a kadar

Şu anda Çevik destekli proje yönetimi çoğunlukla BT alanında yaygındır, ancak iş alanı da bunu benimsemeye başlıyor. Bu sistem eğitim, pazarlama ve iş alanlarında kullanılmaktadır. Çevik proje yönetimi birçok şirket ve devlet kurumu tarafından benimsenmektedir.

Örnekler: Yeni Zelanda hükümeti, Nijerya hükümeti, Norveç Emeklilik Fonu, Return Path şirketi (yazılım), Oreo şirketi (çerez üretimi), Aviasales şirketi (en büyük uçak bileti arama motoru), Hewlett-Packard şirketi (Amerika'nın en büyük BT şirketi), Sberbank " (muhtemelen bunun ne olduğunu biliyorsunuzdur).

Bunlar ve diğer birçok kuruluş en çok farklı yöntemlerÇevik tabanlı proje yönetimi. Ve bu yöntemler hakkında konuşmak, metodolojinin kendisi hakkında konuşmaktan daha az önemli değildir.

Popüler Proje Yönetimi Yöntemleri

Farklı kuruluşlar tarafından kullanılan birçok proje yönetimi yöntemi vardır. modern şirketler. Ancak Scrum ve Kanban haklı olarak aralarında en ünlü ve en çok talep görenler olarak kabul ediliyor.

Scrum yöntemi

Çevik sistemin tüm yöntemleri arasında Scrum, iş sürecinin kalite kontrolüne asıl vurguyu yapmasıyla farklılık gösterir. Bunu ilk kez tanımlayan Japon uzmanlar stratejik Yönetim Hirotaka Takuechi ve bilim ve teknoloji profesörü Ikujiro Nonaka, bu yöntemi Scrum'ın "top için savaştığı" "ragbi yaklaşımı" olarak adlandırıyor.

Yöntem, proje geliştirmenin sprintlere bölünmesi ve bunun sonunda müşterinin geliştirilmiş yazılımı almasıdır. Sprint'lerin zamanları kesinlikle sabittir ve 2 ila 4 hafta kadar sürebilir. Bir sprintteki iş akışı birkaç aşamadan oluşur:

İşin kapsamı belirlendi
Ekip üyelerinin çalışmalarını ayarlayabilmeleri ve ara sonuçları özetleyebilmeleri için her gün 15 dakikalık toplantılar yapılır.
Elde edilen sonuçlar kanıtlanmıştır
İyi ve kötü kararları ve eylemleri bulmak için sprintler tartışılır

Çoğu durumda Scrum, karmaşık yazılımlarla çalışırken ve artımlı ve artımlı yazılımlar kullanarak ürün geliştirmede kullanılır. yinelemeli yöntemler. Bu sayede ekip verimliliği önemli ölçüde artar ve işe harcanan süre azalır.

Scrum sonuçları iyileştirir, projenin değişime uyum sağlamasına yardımcı olur, daha az analiz çabasıyla daha doğru tahminler sağlar ve çalışma aşamalarını ve proje senaryosunu daha etkin bir şekilde kontrol etmenize olanak tanır. Bütün bunlar iş hedefleriyle mükemmel bir şekilde eşleşiyor.

Kanban yöntemi

Kanban, ekip çalışmasını daha etkili ve verimli hale getiren bir diğer yöntemdir. Bunun anlamı, geliştirme sürecine maksimum şeffaflık kazandırmak ve üniforma dağıtımı Proje katılımcıları arasındaki iş yükü. Kanban'ın bir diğer önemli özelliği de insanları sürekli işbirliği yapmaya, gelişmeye ve öğrenmeye motive etmesidir.

Kanban yöntemini kullanarak çalışmak çeşitli prensiplere dayanmaktadır. Öncelikle projeyle ilgili tüm bilgilerin görselleştirilmesi gerekir, bu da örtüşmeleri, hataları ve eksiklikleri görmenize ve bunları aktif olarak ortadan kaldırmanıza olanak tanır. İkincisi, bir görev üzerinde çalışma tüm ekip tarafından aynı anda gerçekleştirilmelidir - bu, elde edilen çabaların ve sonuçların dengelenmesine yardımcı olur ve yükün eşit olmayan dağılımını ortadan kaldırır. Üçüncüsü, tüm görevleri tamamlamak için gereken süre sıkı bir şekilde kontrol edilir, böylece süreç optimize edilir ve zamandan tasarruf sağlanır.

Scrum'dan farklı olarak Kanban çok daha sonra popülerlik kazandı, ancak bu hiçbir şekilde onun değerini azaltmaz veya onu daha az etkili kılmaz. Yöntem hem BT alanında hem de iş alanında faydalıdır.

Bunlar sadece temel Çevik proje yönetimi uygulamalarının örnekleridir. Ancak PRINCE2, Yalın, Altı Sigma, XP, CCPM, ECM, Şelale ve diğerleri gibi diğer yöntemleri de ihmal etmemelisiniz. Ayrıca Agile'ın avantajlarının yanı sıra bazı dezavantajları da vardır.

Agile'ın artıları ve eksileri

Agile öğrenirken bu metodolojinin hem olumlu hem de olumsuz yönlerini bilmek önemlidir. Olumlu yönleriyle başlayalım.

Öncelikle Agile yönetiminin oldukça esnek olduğunu belirtmekte fayda var. Örneğin, geleneksel metodoloji işin belirli aşamalarını gösteriyorsa Agile, nihai ürünün kullanıcısına ve müşterinin gereksinimlerine kolayca uyum sağlar.

Aslında nihai üründeki kusurların sayısı en aza indirilir çünkü bu, her sprint aşamasının sonunda gerçekleştirilen kapsamlı bir kalite kontrolünün sonucudur.

Ayrıca Agile'ın başlatılması hızlıdır, değişikliklere kolayca yanıt verilir ve geliştirme ekibinin ve müşterilerin gerçek zamanlı olarak sürekli iletişimi sürdürmesine olanak tanır. Avantajları belli ama gelelim dezavantajlarına.

Metodolojinin dezavantajları, öncelikle sürekli Geri bildirim proje teslim tarihinin sürekli ertelenmesine neden olabilir, bu da işin sonsuza kadar devam etmesi tehdidi yaratabilir. Örneğin müşteri yalnızca sonuçları görüyor ancak bunlara ulaşmak için gereken çaba hakkında hiçbir fikri yoksa, sürekli iyileştirme talep edecektir.

İkinci dezavantaj ise değişen proje koşullarına uyum sağlama ihtiyacıdır. Proje belgeleri. Değişiklikler veya ek özellikler hakkında ekibe uygun şekilde iletişim kurulmazsa, işlevsel gereksinimler veya mimari belgeler ekiple ilgili olmayabilir. şu an zaman.

Agile'ın üçüncü önemli dezavantajı sık toplantılara ihtiyaç duymasıdır. Bunlar elbette iş verimliliğini artırmaya yardımcı olur, ancak yine de ekip üyelerinin sürekli dikkatlerinin dağılması süreç üzerinde olumsuz bir etki yaratabilir çünkü insanların dikkati sistematik olarak eldeki görevlerden uzaklaşır.

Bu aynı zamanda müşterinin sürekli varlığı ihtiyacı, uzun vadeli planlar yapamama ve motivasyonu yüksek, yüksek nitelikli uzmanlara duyulan ihtiyaç gibi şeyleri de içerir. Bu arada, ikincisi büyük ölçüde Çevik yönetimin kuruluşun faaliyetlerinde uygulanmasıyla ilgilidir. Agile'ı kavrarken aynı zamanda uygulama konusunu da tanımanız gerekir.

Çevik Uygulama

Agile'ı şirketlerin çalışmalarına dahil etmenin pek çok örneği var. Ve neredeyse hepsi bunun bir dizi önemli önlem gerektirdiğini söylüyor.

Başlamak için proje koşullarına bağlı olarak belirli bir yöntem seçilir. Daha sonra görevler ve hedefler, ana son teslim tarihi ve sprint tarihleri, ekibin büyüklüğü ve projenin diğer bileşenleri belirlenir. Maksimum sayıda gereksinimi karşılayan bir yöntem seçmek önemlidir.

Söylediğimiz gibi Agile'ı uygulamak profesyonellerden oluşan bir ekip gerektirir. Tüm üyelerin metodolojinin temel fikir ve ilkelerini bilmesi ve bunları uygulayabilmesi gerekir. Eğer şirkette bu tür kişiler yoksa çalışanların eğitilmesi gerekmektedir. Agile kullanmaya karar veren bir şirketin yönetimi aynı zamanda kurumun değişikliklere hazır olup olmadığını, sistemin projelerine uygulanıp uygulanamayacağını vs. açıkça anlamalıdır. Çoğu zaman bu soruları yanıtlamak için Agile uzmanlarına başvurmanız gerekir.

Bir sonraki aşamada sistemle çalışma tecrübesi olan bir kişi davet edilir. Bunu gösteriyor, sprintlerin ve eylemlerin özünü, gelecekteki takım üyelerinin işlevlerini, aralarındaki etkileşimin özelliklerini ve diğer konuları açıklıyor. Ve ancak bundan sonra oluşur yeni takım, roller, görevler ve sorumluluklar dağıtılır, analiz, raporlama vb. araçlar seçilir.

Son aşama Agile ile ilk deneyim olacak, yani. onu kullanan ilk proje. Hataların, eksikliklerin, tutarsızlıkların ve gecikmelerin kaçınılmaz olduğunu anlamalısınız. Bazı araçlardan vazgeçip bunları başkalarıyla değiştirmeniz ve belki de ekipteki kişiler arasındaki rolleri değiştirmeniz gerekecek. İlk deneyim bir adaptasyon sürecidir ve adaptasyon iki yönlüdür: Firma metodolojiye alışır, metodoloji de firmaya uyum sağlar.

Çözüm

Bu incelemeyi özetlemek gerekirse, teori ve pratiğin iki farklı şey olduğunu hatırlayalım. Yeni yöntemler ve teknolojiler ile bunların uygulanması ekip için benzersiz bir zorluktur ve daha fazla verimliliğin nasıl elde edileceği her zaman bireysel bir konudur. Çevik her derde deva veya başarı garantisi değildir, ancak doğru rotayı belirlemenize ve yol boyunca yönergeler bulmanıza olanak tanır.

Herhangi bir projeyi uygulamak için kesinlikle bir şeyi değiştirmeniz, yeni çözümler aramanız gerekecek. Ancak sürekli değişen çalışma koşullarına ve müşteri gereksinimlerine uyum sağlayarak doğru hareket etme yollarını bulabiliriz. Ve esnek proje yönetimi metodolojisi Agile bu konuda sadık bir yardımcı olabilir.

Size temel metodolojinin ne olduğunu anlatıyor, temel kavramları ortaya koyuyor, çevik bir ekibin nasıl yapılandırıldığını ve etkinliğinin nasıl değerlendirildiğini açıklıyoruz.

Agile, esnek proje yönetimi metodolojilerinden oluşan bir ailedir. Buradaki yönetim kavramının tamamen doğru olmadığı ortaya çıkması ilginçtir. “Çevik, ortaklaşa ürün yaratmanıza olanak tanıyan bir ekip etkileşimi yoludur” formülünü kullanmak daha doğru olacaktır. Ancak dikey, hiyerarşik bağlantıların gücüne fazlasıyla alışkınız, dolayısıyla burada da “yönetim” kelimesinin kullanımı istikrarlı hale geldi.

Uygunsuz sorular

Bir departmanın çalışmasındaki gecikmenin geri kalanını durdurmayacağından nasıl emin olabiliriz?
Bir proje planının geliştirilmesinin, tüm uygulama süresinin %30'unu almaması nasıl sağlanır?
Sonuçta bu planların takip edilmesini nasıl sağlayabiliriz?

Alt düzey yöneticilerden kurumsal direktörlere ve hükümet yetkililerine kadar her seviyedeki yöneticiler onlarca yıldır bu sorunla boğuşuyor. Ancak az çok kontrollü ürün yaratmanın ve proje geliştirmenin bilinen tek yolu adım adım, birbiri ardına kaldığı sürece bu zorluklarla hiçbir şey yapılamaz.

Niteliksel olarak yeni bir seviyeye geçmek için proje çalışması temel bir paradigma değişikliğine ihtiyaç vardı.

Bu acı verici soruların çoğuna cevap aramaya gerek olmadığı ortaya çıktı. Bunların ortadan kaldırılması ve mümkünse bunlara yol açan kavramların ortadan kaldırılması gerekiyor. Böylece aşamalı şelale geliştirmenin yerine esnek metodolojiler ortaya çıktı.

Hemen yapın!

Esnek metodolojide benimsenen etkililiğin ana ölçüsü üründür. Diğerleri sadece dokümantasyon hazırlarken, çevik ekipler çalışan bir prototip sunmaya çalışır. Bu, ünlü motive edici formüle benziyor: "Yapılmış, mükemmelden daha iyidir." İlk işlevi uygulayın ve test etmeye başlayın, bir sonrakini oluşturun ve tekrar tekrar bu şekilde devam edin - bu ana kuraldır.

Agile'daki geliştirme aşamasına, yani bu "zaman zaman" olayına yineleme denir. Yinelemeler proje boyunca aynı süreye sahiptir ve ortalama iki haftadır. Tek bir yinelemede, ana özelliği çözümünün ürünü yeni bir sürüme güncellemesi veya verimliliğini artırması olan belirli bir görev gerçekleştirilir. Bu tür görevler bu temelde seçilir.

Yinelemeli bir yaklaşım nasıl esneklik sağlar? Bireysel süreçlerin paralel ve birbirinden bağımsız olarak çalışabilmesi nedeniyle. Evet, bunun bir fikirden tamamen bitmiş bir ürüne kadar olan nihai geliştirme süresini artırabileceğini kabul etmeliyiz. Ancak gerçek şu ki, Agile'da halihazırda rakipleri karşılayabilecek ve kullanıcıları memnun edebilecek, çalışan, işlevsel bir ürün çok daha erken yaratılmıştır ve döngüsel iyileştirmeler, bu tür işlev ve yeteneklerin çok daha iyi geliştirilmesini sağlamamıza olanak tanır. planlı çalışma Ben buna asla alışamazdım.

Yatay organizasyon

Çevik bir ekip, kendi kendini organize etme ve tüm katılımcıların göreceli eşitliği ilkeleri üzerine kuruludur. Pek çok kişinin projenin başkanı, yani ürün sahibi olarak hayal ettiği kişi bile aslında ürünün gereksinimlerinin kişileşmiş halidir. Ne beklendiğine dair bilgi taşıyıcısı olarak hareket eder son sonuç, ancak hiçbir şekilde standart anlamda bir yönetici değildir. Hiyerarşi alışkanlığının ortadan kaldırılması zor olduğundan, birçok ekipte ne yazık ki ürün sahibi denetim işlevlerini üstlenmek zorunda kalıyor. Ancak çevik gelişimin ideali, ekip üyelerinin birbirlerine karşı kolektif sorumluluğudur.

Çevik ekipler oluşturmanın ilkeleri bağlı olarak değişir. özel proje. Örneğin Spotify müzik hizmetinde bunlar şu şekilde oluşturulmuştur:

Çevik ekiplerin bir diğer önemli değeri de bilgi paylaşımıdır. Bir ekip üyesi kendi dar alanıyla sınırlı kalmamalı, disiplinlerarasılık için çaba göstermelidir. Bu, bir programcının aynı zamanda bir satış elemanı olması gerektiği ve bir tasarımcının da bir pazarlamacı olması gerektiği anlamına gelmez.

Ancak çevik geliştirmede ilgili uzmanlıklar hakkında temel bilgiye sahip olmak gerekir.

Başlangıçta bunun sadece iş verimliliğini ve ekip içindeki karşılıklı anlayış düzeyini artıracağı varsayılıyordu, ancak bugün sinir biliminin gelişmesiyle birlikte bu yaklaşımın aynı zamanda beynin iyi durumda kalmasını ve beynin iyi durumda tutulmasını da sağladığı ortaya çıktı. yeni sinir bağlantılarının dinamik yaratılması. Agile'da bilginin bu çapraz tozlaşmasına t şekli denir. Aşağıdaki çizim bunun neden herhangi bir kelimeden daha iyi olduğunu açıklayacaktır.

Çevik nasıl uygulanır?

Birçok kuruluşta hâlâ yaygın olan şelale geliştirmeden projeler üzerinde çevik çalışma yöntemlerine geçiş oldukça sancılı olabilir.

İlk önce, hiyerarşiyi ortadan kaldırmalı ve aynı zamanda süreçlerdeki tüm katılımcıların sonucun sorumluluğunu eşit şekilde paylaşabilmesini sağlamalısınız.

İkincisi, Yinelemeli geliştirmeye geçiş, sizi her aşamanın ürüne yeni bir şey getireceğinin garantilendiğinden emin olmaya odaklanmaya zorlayacaktır. Bu kolay değil, planlı gelişimin ataleti ilk birkaç ay sizi rahatsız edecek.

12 prensipten oluşur. Elbette Çevik yaklaşımın bazı hükümleri bundan önce de ortaya çıktı, ancak yalnızca bu belge bunları sistematize etti ve yeterli ölçüde kullanıma sundu. Her yıl yeni şirketler, BT uzmanları ve proje yöneticileri manifestoya kaydoluyor. Çevik geliştirme sisteminin yeni yöntemleri ve modifikasyonları ortaya çıkıyor.

Çevik Metodoloji Nedir?

Çevik, kodun geliştirme döngüsünün sonunda teslim edildiği şelale modellerinin aksine, yazılımın bir projenin başlangıcından itibaren artımlı olarak oluşturulduğu yinelemeli bir geliştirme modelidir.

Çevik metodolojinin temeli, projeleri kullanıcı hikayeleri adı verilen küçük uygulanabilir parçalara ayırmaktır. Önceliğe göre görevler iki haftalık kısa döngüler (yinelemeler) içerisinde çözülür.

Çevik Metodolojiyi oluşturan 12 ilke 4 ana fikre ayrılabilir:

Araçlar ve süreçler yerine insanlara ve iletişime öncelik vermek;
Çalışan bir ürünün eksiksiz dokümantasyona göre önceliği;
Müşterilerle işbirliğinin sözleşme onayına göre önceliği;
Başlangıçta oluşturulan planı takip etmek yerine değişime istekli olmanın önceliği.

Agile'da mevcut yöntemler:

"Scrum" terimi rugby'den gelir ve bu kelime, her rakibin üç sıra oluşturduğu ve topu yakalamaya çalıştığı bir takım oyunu yöntemini ifade eder. Başarılı bir müdahale için, yalnızca iyi bir fiziksel hazırlığa değil, aynı zamanda mücadeledeki her katılımcının koordinasyonuna ve hedefin net bir şekilde anlaşılmasına da ihtiyacınız var.

Yöntem Microsoft, Yahoo, Siemens Healthcare gibi şirketler tarafından başarıyla kullanılıyor ve hatta Amazon'daki bir proje yöneticisi tarafından kazanılan deneyime dayanarak tanımlandı.

Scrum bir geliştirme çerçevesi olduğundan, sonraki her örnekte bir öncekinden önemli ölçüde farklı olabilir.

Jeff Sutherland, yazar tekniği kullanmak için 8 adım belirledi:

Seçme ürün sahibi— projenin amacını ve beklenen sonucu biliyor.
TOPLAMAK takım— uygulanabilir bir ürün yaratmak için gerekli becerilere sahip en fazla 10 kişi.
Bulmak Saldırı ustası— projenin ilerleyişini izler, proje ekibinin zorluklarla başa çıkmasına yardımcı olur.
Oluştur ürün birikimi— Agile panosunda her ürün gereksinimine öncelik verin. Ürün sahibi, birikim ekibi tarafından değerlendirilmek üzere ürün taleplerini toplayarak bunda büyük bir rol oynar.
Takvim sürat koşuları(yinelemeler) - belirli bir dizi görevi tamamlamak için gereken süreler.
Düzenlemek günlük on beş dakikalık “buluşmalar”— Ekibin her üyesine 3 soru sorun: Dün ne yaptınız, bugün ne olacak, görevi tamamlamanıza ne engel oluyor?
Yapmak ürünün çalışma parçalarının gözden geçirilmesi— Paydaşların görüntüleme ve tartışmaya dahil edilmesi.
Yönetmek geriye dönük— her sprintten sonra sorunun tartışılması ve bir çözüm bulunması. Ortaya çıkan değişim planını bir sonraki sprint'te uygularsınız.

Agile'da Retrospektif

Scrum'ın 4 temel unsuru vardır:

Ürün İş Listesi- proje gereksinimlerinin listesi
Sprint İş Listesi— bir sonraki sprintte tamamlanması gereken gereksinimlerin listesi
Sprint Hedefi- sürat hedefi
Sprint İş Bitim Tablosu- Görevler tamamlandıkça güncellenen bir grafik. Ekibin projedeki dinamiklerini ve ilerleme düzeyini anlamayı kolaylaştırır.

(XP)

Tekniğin geliştiricisi Kent Beck, amacı bir yazılım ürününün sürekli değişen gereksinimleriyle başa çıkmak ve geliştirme kalitesini artırmak olan Extreme Programming yöntemini yarattı.

Yalnızca yazılım geliştirme alanında uygulanabilir ve 4 süreç etrafında oluşturulmuştur:

kodlama— ekip içindeki tek tip tasarım standartlarına göre;
test yapmak— testler, test edilecek kod yazılmadan önce programcıların kendileri tarafından yazılır;
planlama- hem son yapı hem de bireysel yinelemeler. İkincisi ortalama iki haftada bir gerçekleşir.
işitme— belirsizliklerin ortadan kalktığı ve gereksinimlerin ve değerlerin belirlendiği hem geliştiriciler hem de müşteri.

Metodolojiler

"Çevik Yazılım Geliştirme Manifestosu"nun yazarlarından biri olan Alistair Cockburn tarafından geliştirilen, proje yönetiminin yerel alanında az bilinen bir metodoloji ailesi. Cockburn, takımdaki kişi sayısına göre renge göre sınıflandırmayı öneriyor: 2'den (Kristal Berrak) 100'e (Kristal Kırmızı). Daha büyük projeler için Bordo, Mavi ve Mor renkleri tahsis edilmiştir.

Kristal projelerin 3 ana göstergeyi karşılaması gerekir:

çalışma kodunun hızlı teslimatı- yinelemeli bir Çevik geliştirme modeli fikrinin geliştirilmesi.
yansıma yoluyla mükemmellik — yeni bir versiyon Yazılım öncekinden elde edilen verilere dayanarak geliştirildi.
"ozmotik" etkileşim- Alistair'in yeniliği, aynı odadaki yazılım geliştiricileri arasındaki iletişim ve bilgi alışverişinin bir metaforu.

Dinamik Yazılım Geliştirme Yöntemi (DSDM)

DSDM'nin geliştirilmesi tek bir kişinin, hatta bir ekibin işi değil, 17 İngiliz şirketinden oluşan bir konsorsiyumun eseriydi. Extreme Programming gibi DSDM de öncelikle yazılım oluşturmak için kullanılır.

Son tüketicinin (kullanıcının) geliştirme sürecine katılımına özel bir rol verilmektedir. Bu prensibe ek olarak temel olanlar şunlardır:

ürünün çalışma sürümlerinin sık sık yayınlanması
Karar verme konusunda geliştiricilerin özerkliği
tüm çalışma döngüsü boyunca test etme.

DSDM, teknoloji geliştikçe ve yazılım geliştirme için yeni gereksinimler ortaya çıktıkça güncellenen versiyonlara bölünmüştür. Bugün için en son olanı, 2007'de piyasaya sürülen DSDM Atern'dir, ancak bir önceki (2003) hala hizmettedir.

Ekip başlangıçta uygulama geliştirmenin gerçekliğini ve uygulamanın kapsamını inceliyor. Daha sonra iş birbirine bağlı üç döngüye bölünür:

fonksiyonel model döngüsü- analitik dokümantasyonun ve prototiplerin oluşturulması.
tasarım ve inşaat döngüsü- Sistemi çalışır duruma getirmek.
uygulama döngüsü— sistem konuşlandırması.

Özellik Odaklı Geliştirme (FDD)

Çevik Yazılım Geliştirme Manifestosu'ndan bile önce gelen bir metodoloji.

FDD aynı zamanda yinelemeli bir geliştirme modeli kullansa da Agile'dan aşağıdaki yönlerden farklılık gösterir:

ön modellemeye daha fazla vurgu
Raporlama ve grafik oluşturmanın (Çevik ile karşılaştırıldığında) önemi arttı
kurumsal gelişimi hedefliyoruz.

Özellik Odaklı Geliştirme aşağıdaki döngüsel aşamalardan oluşur:

Genel Bir Model Oluşturmak- Ön verilere dayalı olarak projenin vizyonu.
Emlak Listesi Geliştirme— Scrum metodolojisindeki ürün birikiminin bir benzeri.
Özelliklere göre planlama- her ekip üyesi tarafından özelliklerin karmaşıklığının değerlendirilmesi.
Her mülk için- teknik tasarım ve uygulama - sonunda özelliğin ürüne girdiği ve döngünün tekrarlandığı son aşama.

Yazılım geliştirme

Yalın Yazılım Geliştirme bir metodolojiden ziyade bir dizi prensiptir yalın üretim geliştirme sürecinin verimliliğini artırmayı ve maliyetleri en aza indirmeyi amaçlamaktadır.

Set aşağıdaki 7 prensibi içermektedir:

kayıplardan kurtulmak- Son tüketici için ürüne değer katmayan her şey.
sürekli antrenman— Ekibin sürekli gelişimi, görevleri etkili bir şekilde tamamlama yeteneğini artırır.
mümkün olduğunca geç karar vermek— kendiliğinden kararlara öncelik verilmez, edinilen bilgi temelinde geliştirilen düşünceli kararlara öncelik verilir.
Hızlı sevkiyat- esas olarak yinelemeli modelin temeli.
ekibi güçlendirmek- “Manifesto…” ilkelerinden biri, insanların ve etkileşimin süreç ve araçlardan daha önemli olduğunu belirtir. Proje ekibi, görevlerin başarıyla tamamlanmasının temelini oluşturur.
bütünlük ve kalite— daha fazla test yapmak ve hatalardan kurtulmak için zaman ve kaynak israf etmemek için başlangıçta yüksek kaliteli bir ürün yapmanız gerekir.
resmin tamamını görmek— Geliştirilmekte olan yazılımın mevcut geliştirme durumu, hedefleri, konsepti ve stratejisi anlaşılmadan bir projeyi ayrı parçalara ayırmak imkansızdır.

Çevik geliştirme metodolojilerinin türleri

Çevik Modelleme (AM)

Çevik Modelleme, yazılım modellemeye yönelik bir dizi değer, prensip ve uygulamadır.

AM, tam teşekküllü bir yazılım geliştirme metodolojisinin bir bileşeni olarak kullanılır - örneğin, aşırı programlama veya Hızlı Uygulama Geliştirme.

Çevik Modellemenin ilkeleri şunlardır:

proje paydaşları arasında etkili etkileşim
tüm gereksinimlere uyacak mümkün olan en basit çözümü geliştirme arzusu
sürekli geri bildirim alınması
Karar verme ve kararlardan sorumlu olma cesareti
kesinlikle her şeyi bilmediğinizi anlamak.

Çevik Birleşik Süreç (AUP)

AUP, başka bir yazılım geliştirme metodolojisinin basitleştirilmiş bir versiyonudur - Rational Unified Process (RUP). 2012'den bu yana yerini Disiplinli Çevik Teslimat (DAD) aldı, ancak AUP hala bazı yerlerde bulunuyor.

Metodolojinin yazarı Scott Ambler, Çevik Birleşik Sürecin aşağıdaki kilit konumlarını belirledi:

Ekibiniz ne yaptığını biliyor;
Sadelik her şeyden önemlidir.
Esnek geliştirme metodolojisi ilkelerine uygunluk.
Proje için değerli olan faaliyetlere odaklanın.
Araç seçiminde bağımsızlık.
Belirli bir projenin ihtiyaçları için AUP'nin bireysel konfigürasyonu.

Çevik Veri Yöntemi (ADM)

ADM, bireysel ekiplerin işbirliği yoluyla proje gereksinimleri ve çözümleri üretmeyi vurgulayan bir dizi yinelemeli çevik yazılım geliştirme tekniğidir. AUP gibi tek başına bir teknik değildir.

Çevik Veri Yönteminin özü altı hükümle belirlenmektedir:

Veri- herhangi bir uygulama oluşturmanın temeli.
Projeyle ilgili sorunlar— yalnızca projenin amacı ve konseptinin net bir şekilde anlaşılmasıyla keşfedilebilirler.
Çalışma grupları— Doğrudan geliştirme ekibine ek olarak diğer çalışma gruplarını destekleyen işletme grupları da vardır.
benzersizlik— ideal bir metodoloji yoktur; her proje için farklı metodolojilere ait araçları birleştirmeniz gerekir.
Takım çalışması— Birlikte çalışmak yalnız çalışmaktan çok daha etkilidir.
"Zayıf nokta"— aşırılıklardan kaçınarak soruna en uygun çözümü aramak (“etkili nokta”).

Temel Birleşik Süreç (EssUP)

İsveçli bilim adamı Ivar Jacobson'un, Rational Unified Process'i geliştirmek için yarattığı bir gelişme.

EssUP, aşağıdakileri içeren uygulama konseptiyle çalışır:

kullanım senaryosu - sistem davranışının açıklaması.
yinelemeli geliştirme - birkaç haftalık kısa döngülerde çalışan kod parçaları oluşturma.
takım uygulamaları – takımı birleştirmeyi ve etkinliğini arttırmayı amaçlamaktadır.
prosedürel uygulamalar - örneğin, "Büyük düşün, küçük başla" veya "Paydaşları iş süreçlerine dahil edin."

Şu veya bu şekildeki tüm uygulamalar RUP, CMMI ve esnek geliştirme metodolojilerinde bulunur.

Gerçeğe Dönüşmek (GR)

Küçük projelerin ve şirketlerin özelliklerinin maksimum kullanımını sunan, yeni başlayanlar ve acemi ekipler için etkili bir metodoloji: hareketlilik, esneklik, yeni çözüm arayışı, katı, kafa karıştırıcı hiyerarşinin olmaması vb. 37signals'ın (şimdi Basecamp) kurucuları Jason Fried ve David Hansson, Getting Real'i gerçek sorunları çözmeye yönelik bir sistem olarak tanımladılar: mümkün olduğunca basit, anlaşılır ve işlevsel.

GR, aşağıdakileri en aza indirmek için kullanılan bir düzine çevik geliştirme aracından oluşan bir karmakarışıktır:

fırsatlar
seçenekler ve ayarlar
şirket yapıları
toplantılar
vaat ediyor.

Bazı unsurlar başka teknikler kullansa da, alışılmadık kavram yaygın olarak kullanılmamaktadır.

OpenUP (OUP)

Aşağıdaki uygulamaları içeren, katı bir yapıya sahip olmayan, araçtan bağımsız bir yazılım geliştirme metodolojisi:

takım hızının ölçülmesi;
Yinelemelerin tamamlanmasının ardından günlük toplantılar ve retrospektif toplantılar düzenlemek;
mikro adımlar kavramı ve kontrol listeleri kullanılarak yapılan erken testler;
Çevik Modelleme Metodolojisi (AMDD).

Uygulamalar dört esasa göre yürütülür:

Çevik ölçümler

Agile'daki araçların, uygulamaların, yöntemlerin ve metodolojilerin çeşitliliği göz önüne alındığında, bunların her birinin etkinliğini belirlemenize yardımcı olacak bir araç seçmeniz gerekir. Metrikler böyle bir araçtır.

Çoğu proje için 4 ölçüm alanı yeterlidir:

Verim— buna Hız ve Devam Eden Çalışma dahildir. İlki tüm projeler için uygun değildir, çünkü yineleme başına tamamlanan görevlerin sayısı ölçülür, ancak bunlar eşit değildir. Devam Eden Çalışma metriği görev sınırını farklı aşamalarda belirler: ne kadar yüksekse o kadar kötüdür;
Tahmin— kapasite ölçüsü: bir sonraki sprintte mevcut olan ideal saat sayısının belirlenmesi. Buna göre çalışmak için ne kadar zamanınız kaldığını, görevlerin ne kadar verimli tamamlandığını ve sprint'in nasıl tamamlanacağını anlayabilir;
Kalite- örneğin, aşağıdaki formül kullanılarak hesaplanan gereksinim kararlılık endeksi = ( Toplam Orijinal iş gereksinimleri + Bu zamana kadar değişen gereksinimlerin sayısı + Eklenen gereksinimlerin sayısı + Kaldırılan gereksinimlerin sayısı) / (orijinal gereksinimlerin toplam sayısı). Metrik, görevleri yeniden yapmak için harcanan süreyi belirlemek için kullanılır;
Değerler— her durumda proje formatına bağlı olarak ayrı ayrı hesaplanır. Örneğin, startup AirBnb, kullanıcılar için ürünün nihai değerini belirleyen bir ölçüm olarak yüklenen yüksek kaliteli fotoğraf sayısını seçti. Onların artmasıyla birlikte tüketici sayısı da aynı oranda arttı.

Diğer Çevik araçlarla aynı kurallar metrikler için de geçerlidir.

Projeniz için tek bir doğru veya gerekli ölçüm yoktur.

Sürekli olarak gözden geçirilmeleri, güncel olmayanların atılması ve gerektiğinde yenilerinin eklenmesi gerekir. Tüm ekip için anlaşılır ve erişilebilir olmalı ve kendi başına bir amaç haline gelmemelidir. Metrik uğruna metrikler kötü bir çözümdür.

Efsane Avcıları: Çevik

Esnek geliştirme metodolojisi ailesinin popülaritesi bu konuda acımasız bir şaka yaptı ve hatta özel portallarda Agile'ın şu veya bu yönü hakkında efsaneler var. Anlayacağız!

Efsane #1: Agile tüm projeler için uygundur.

En kalıcı yanılgı. Hiçbir Çevik yöntem tek başına bir ürüne değer katmaz veya bir ekibi motive etmez.

Efsane #2: Çevik ve Dokümantasyon.

Çevik geliştirme dokümantasyona karşı değildir, başlı başına bir amaç olan dokümantasyona karşıdır. Ancak iletişim aracı olarak dokümantasyonu seçerken Agile gerçekten canlı iletişime öncelik veriyor.

Efsane #3: Çeviklik ve planlama birbirine karışmaz.

Bu efsanenin çürütülmesi, 10 dakikalık stand-up'larla günlük planlama, iki haftada bir yinelenen planlama, sprint toplantıları vb.'dir.

Efsane #4: Çeviklik çok fazla yeniden çalışmayı gerektirir.

Çevik yazılım geliştirmede yeniden tasarım iki biçimde gelir: gereksinimlerin yeniden tasarlanması (kullanıcılar gerçekten neye ihtiyaç duyduklarını anlar) ve yazılımın yeniden tasarlanması (geliştirme ekipleri uygulamayı yazmanın ve tasarlamanın daha iyi yollarını bulur). Ancak bununla başka yöntemlerle de uğraşmanız gerekir! Üstelik yeniden çalışmanın olumsuz etkisini azaltmak için Agile'ın bir özelliği olan yinelemeli bir modele ihtiyaç vardır.

Çevik kullanmanın artıları ve eksileri

Artıları:

Paydaş katılımı— ekibin müşterinin isteklerini anlamak için daha fazla fırsatı var. Yazılımın erken ve sık teslimi, paydaşların proje ekibine olan güvenini artırır ve onları projenin daha da derinlerine çeker.
erken ve öngörülebilir teslimat— yinelemeler yoluyla geliştirme modeli (1 ila 6 hafta arası kısa aralıklarla) esneklik sağlar ve ürünün piyasaya sürülmesini hızlandırır.
iş değerine odaklanmak— müşteriyle işbirliği, ekibin ürünü tüketici için nasıl mümkün olduğunca değerli hale getireceğini anlamasını sağlar.
sürekli kalite iyileştirme— her yineleme sırasında test yapmak, son yapıyı ayrı çalışma kodu parçalarına bölmek, nihai ürün yayınlanmadan önce yazılım hatalarını iyileştirmemize ve bunlarla başa çıkmamıza olanak tanır.

Eksileri:

Ekip ve müşterilerden artan talepler— Proje ekibi ile kullanıcılar arasında yakın etkileşim olmadan, yüksek değere sahip, yüksek kaliteli bir ürün elde etmek imkansızdır. Agile'daki araç ve yöntemlerin bolluğu, uygulama için deneyimli bir ekip gerektirir.
dış kaynak kullanımına uygun değil ve katılımcıların yalnızca çevrimiçi olarak birbirleriyle etkileşime girdiği projeler.
Yazılımın son sürümünün asla yayınlanmama riski- garip bir şekilde bu eksi, ürünün yinelemeli geliştirilmesinden ve sürekli iyileştirilmesinden kaynaklanıyor - Çevik'in avantajları.
projenin iş hedeflerine ilişkin net bir vizyon olmadan çalışmaz— Agile ekibi paydaşlara odaklandığından, hedefler ve ürün konsepti geliştirmeden gelişim mümkün değildir.

Uygulamalar

Projeleri yönetmek için Proje yönetimine yönelik tüm hizmetler veya programlar Agile için uygun değildir çünkü her birinin kendine has özellikleri vardır.

Eğer işinizpazarlama ve reklamcılık, tasarım, SEO veya dijital ajanslar , ardından saas hizmeti tüm takıma uygulanabilir. Biz tavsiye ediliriz .

İşte Agile'ı kurmak için birkaç tüyo

etiketleri ve durumları yapılandırmaŞirketinizin işleyişi için gerekli olan.
Durumlar şu şekilde olabilir: devam ediyor, kontrol ediliyor, tamamlandı, iyileştirme gerektiriyor, kritik, özellik, ödeme.
Etiketler genellikle şuna benzer: düzen, test, üretim, konsept, kod.
proje biriktirme listesi oluştur Ve proje baharı.
görevler oluştur ve ön kontrol listeleri, taslaklar vb. birikimde.
buluşmalarda tanımlayın bahar görevleri Ve onları birikimden taşı sprint'e.
kullanmak misafir istemci erişimi Proje hakkında her zaman tutarlı ve güncel yorumlara sahip olmak için görevlere.
kutlamak görevlerden sorumlu böylece her bir meslektaş kendi sorumluluk alanını bilir ve sprint sonucuna dahil olduğunu hisseder.

Karar

Çevik yazılım geliştirmeyle küçük proje ekipleri maksimum verimliliğe ulaşır. Çevik diğer esnek yöntemlerle uygulanır: Scrum, XP, Yalın vb.

Aceleyle, tecrübesiz bir ekip tarafından, kısa sürede hayata geçirilemez. ancak Agile'ın uygulanması, BT ile iş dünyası arasındaki etkileşimi geliştirecek, ürünün pazara çıkış süresini hızlandıracak ve ürünün son kullanıcı için değerini artıracaktır.

İÇİNDE modern yönetim“Esnek” yönetim modeli, Agile'ın ne olduğunu tanımlayan (her biri kendi yolunda) üç farklı bağlamda ele alınır.

Agile'ın üç ciltlik anlamı

İlk, daha dar anlamda, bu terim yazılım geliştirme alanında 2000'li yılların başında, Amerika'nın Utah eyaletinde, bir dağ beldesinde endüstri uzmanlarının yazılım geliştirme yöntem ve uygulamalarını tartışmak üzere bir araya gelmesiyle kullanılmaya başlandı. yazılım ürünleri, aranılan son tüketici. Bu toplantının sonucu, öncelikle yazarların faaliyetlerinin dar kapsamıyla ilgili olan ancak potansiyel olarak diğer bazı iş projelerine de genişletilebilecek 12 ilkeden oluşan, yazılım ürünlerinin geliştirilmesine yönelik Çevik Manifesto oldu.

Terimin ikinci, daha geniş anlamında, Çevik ilkeler hemen hemen her işletmenin yürütülmesine uygulanır ve örneğin “yalın girişim” (Yalın Başlangıç) konseptinde bileşenler olarak kullanılır. Bu anlamda Çevik Modelin, proje geliştirme için birkaç adımda karakteristik bir şema izleyen esnek bir metodolojiyi takip ettiği anlaşılmaktadır.

Proje üzerindeki çalışmalar yinelemeler - kısa döngüler (sprintler) halinde gerçekleştirilir. (Yazılım geliştirme durumunda bu döngülerin süresi 1 hafta ile 1 ay arasında değişmektedir).
Her döngünün sonunda halihazırda iş dünyasında kullanılabilecek bir ürün ortaya çıkar. Yazılım için böyle bir ürün bir uygulama veya onun yalnızca bir parçası olabilir, ancak "ham" yazılım bile çalışırken denenebilir ve denenmelidir.
Ürün, geliştiricilerle sürekli geri bildirimde bulunan müşteri veya kullanıcılar tarafından test edilir. Tüm proje boyunca (tüm yinelemeler) müşteri odaklı bir yaklaşım uygulanır.
Her türlü yorum hızlı bir şekilde revizyona dahil edilir ve ürün gelişimini anında düzeltmemize olanak tanıyan değişiklikler memnuniyetle karşılanır, çünkü bu birikmemize izin vermez genel hatalar sistemler.

Üçüncü ve daha geniş anlamda ise Agile, Toyota fabrikalarında kullanılan yönetim modelinin bir parçasıdır ve artık hemen hemen her başarılı üretimin yönetiminin temel bileşenlerinden biridir. Bu bağlamda Agile'ın temelleri, diğer bağlamlarda teknolojiyi anlamanın temellerine benzer.

Toyota fabrikalarında son üretim formatının ayarlanmasında hızlı geri bildirim, konveyörü durdurmayı başlatan ve ek ayarlar için ayarlamaların yazarı olabilecek her çalışan tarafından sağlandı. üretim döngüsü. Üretim boyunca Çevik dönüşüm, yeniden takım yenilemeyi gerektirebilir üretim faaliyetleri genel olarak, ürün müşterinin mevcut ihtiyaçlarına canlı bir yanıtın sonucu haline gelirse. Yani, eğer bir fabrika plastik leğen üretiyorsa ve müşteri geri bildirimleri kovalara ihtiyaç duyulduğunu gösteriyorsa o zaman hızlı adaptasyon Nüansların (sap şekli, boyutu, rengi) paralel olarak ayarlanmasıyla tam olarak Çevik yönetim tarzında olacaktır (eğer diğer ilkelere uyulursa).

Çevik Yönetimin İlkeleri

Bir iş süreci yönetimi modeli olarak çevik proje yönetimi dünya çapında binlerce ekip tarafından kullanılmaktadır ve aşağıdakiler her yerde mevcuttur: ayırt edici özellikleri bu yaklaşım:

Tüketici ve sonucun yaratılmasına katılım derecesi, ürünü kişiselleştirmede kritik öneme sahiptir.
Karar vermek için ekiplerin son derece etkili ve uyumlu olması gerekir.
Adım adım ve döngüsel çalışma sürecin temelini oluşturur. Proje, bir bütün olarak projenin tamamlanmasından belirli bir tarihe kadar tamamlanan küçük parçalara bölünür.
Performans değerlendirmesinin odak noktası, ara proje durumlarının sık sık sunulmasıdır.
Ekip, çalışmalarında, çabaların %20'sinin %80 verimlilik sağladığını öngören Pareto yasasına güveniyor ve bu yasa, sonucu tüketiciye sunmadan önce her bir döngünün mükemmelliğe getirilmemesini mümkün kılıyor. Ürün her yeni yinelemede doğal olarak gelişir.
Bir sonraki aşamaya geçmeden önce bir aşamanın tamamlanması beklenmektedir.

“Çevik” yaklaşım, birbirinden farklı olan ancak Agile fikirlerini içeren bir dizi metodolojik uygulamanın temeli haline gelmiştir: Scrum, Kanban, Lean, Crystal, vb. Scrum metodolojisi, örneğin, neredeyse her zaman Agile ile birlikte tek sistem yazılım geliştirme proje yönetimi.

Scrum yöntemi, "çevik yaklaşımın" belirli operasyonlarda pratikte nasıl uygulanabileceğini gösterir. Örneğin, proje gereksinimleriyle çalışmak dört "yapı" kullanılarak gerçekleştirilir:

Ürün biriktirme listesi, tek bir şablona (Kullanıcı Hikayesi) göre oluşturulan ve önceliğe göre sıralanmış bir gereksinimler listesi oluşturmayı içerir. Herhangi bir gereksinim yoksa proje sonlandırılır.
Sprint biriktirme listesi, en yakın sprintin (etap) gereksinimleridir ve sprint sırasında yeni gereksinimler ekleme olanağı olmaksızın görevlere bölünmüştür. Çevik yönetim tipine sahip bir ekip tarafından alınan bir sonraki aşamaya yönelik taahhütler tahtaya (Kanban denir) yazılır.
Sprint Hedefi - sprint'in genel hedefi - alternatif kararlar almak için bir kılavuz.
Sprint Burndown Chart - “burndown diyagramı”. Takımın etapta ne kadar ilerlediğini gösterir.

Çevik proje yönetimi formatı herkes için uygun değildir ve her zaman uygun değildir. Faaliyetleri değişmeyen mevzuata dayanan ve hedefleri ve uygulamalarında muhafazakar olan hükümet yapılarının bu tür bir optimizasyona ihtiyacı yoktur.

Agile uygulamasındaki tipik hatalar ve yaklaşımın dezavantajları

Bazı durumlarda dikkate alınan aynı faktör sağlam nokta bazılarında ise sorunlara yol açabilmektedir. Dolayısıyla "esneklik" çoğu zaman odağın bulanıklaşmasının nedeni haline gelir. Yoklukla metodolojik temel Yer işaretlerinin kaybı ve birincilin ikincil ile değiştirilmesi söz konusudur. Bu tür "çarpıtmaları" önlemek için, projenin uygulanması sırasında operasyonların içeriğini ve sırasını daha sıkı düzenleyen hazır metodolojiler veya kendi geliştirmelerini kullanıyorlar. Ancak bu durumda Çevik yönetimde hatalar yapılması mümkündür.

Yaygın uygulama hataları aşağıdakileri içerir:

Esnek bir yaklaşımı uygulamanın tüm zorluklarına rağmen, müşteri odaklı yeni bir ürünü hızlı bir şekilde yaratma söz konusu olduğunda genel olarak geleneksel "yavaş" üretimden daha etkilidir. Geleneksel üretim bürokratik gecikmelere takılıp kalırken Çevik yaklaşım, projenin lansmanından hemen sonra doğal hareket sağlar.

18 Ekim 2017

Eğer gerçeğine bakarsanız Rus şirketi 30 yaş üstü ve binden fazla çalışanı olan ve Agile kelimesini kullananların tepkisi en azından temkinli olacaktır. Oradaki insanlar zaten "Büyükannene nasıl söylenir" veya "Büyükbabana nasıl söylenir" gibi hikayeler duymuş ve Gref'in tüm konuşmalarını izlemiş, bir hafta içinde esnekliği getirmek için bir düzine teklif almış, hatta çalışanların bazıları Scrum ile çalışmış. bir yıl, ama geriye bir soru kalıyor:

“Bununla ne yapmalıyız? Sadece programlamadan bir web sitemiz var mı?”

Sonuç olarak, şirketlerin yaklaşık %100'ü için Agile şarlatanlık gibi görünüyor.

Ancak burada bir paradoks var; dünyada projelerinde Agile kullanan şirketlerin %77'si* yazılım geliştirmeyle hiç ilgilenmiyor.

*VersionOne şirketlerinin katıldığı yıllık büyük bir anketten

Bir tanım yerine. Farklı departmanlardan farklı insanlar bir araya geldiğinde Agile hakkında ne söylenir?

Çevik bir yazılım geliştirme yöntemi değildir. Geliştirici değilseniz Vikipedi tanımlarını anlamak zordur.
Bunlar organizasyon ilkeleridir. proje aktiviteleri ve her alanda uygulanabilir. Pratikte insanlar için en hassas farklılık, hiyerarşiden uzaklaşma ve kesin olarak tanımlanmış görevleri üreten tek merkezin ortadan kalkmasıdır. Bu takım çalışması roller, genel sonucun sorumluluğu ve düz bir etkileşim yapısı.

Oyundaki takım "Ne? Nerede? Ne Zaman?" Çevik ilkelere göre var olur. Etkileşimler önemli bir rol oynamaktadır. Kaptan, ürünün müşterisi rolünü oynar (doğru cevap), 2-3 bilim insanı bilgi dizilerini sıralar, birisi zamanı takip eder, analiz eden, soru soran ve iletişimi teşvik eden bir kişi vardır, herkes açıkça konuşabilir ve bir sonuca varmak veya her şeyi başarısızlığa uğratmak, oyunların ötesinde bir bilgilendirme (geriye dönük) yapın.

Agile'ın karşı ağırlığı, katı bir hiyerarşiye ve SMART'a mümkün olduğunca yakın ayarlanmış hassas görevlere sahip bir konveyör (kademeli) yöntemidir. Bu ilkelere göre "Ne? Nerede? Ne Zaman?" Kaptanın kime, hangi yönde düşüneceği ve yanıt olarak bunları bir araya getirmeye çalışacağı konusunda kesin görevler vermesi gerekecekti. Her katılımcının edepli davranması ve sırası geldiğinde açıkça konuşması gerekir. Başarısızlık durumunda birinin motivasyonunun düşürülmesi veya kovulması gerekecekti ve bu kararı kaptan verecekti.

Agile'ın ortaya çıkmasının ve gelişmesinin temel nedeni, her şeyin daha fazla proje sonunda ne olması gerektiği konusunda %100 anlayışa sahip değilsiniz. Kesin görevleri tanımlamak kesinlikle imkansızdır. Ve serbest etkileşimlerin talimatlardan daha önemli olduğuna ve değişime hazır olmanın planlardan daha önemli olduğuna karar verdiler.

Çevik metodolojiler belirsizliğe bir yanıttır; ne yapılması gerektiği ve sonucunun ne olması gerektiği tam olarak bilinmiyor. Görünüşe göre, örneğin bir web sitesi geliştirmenin, bir ev inşa etmenin veya McDonald's'ta hamburger hazırlamanın nesi anlaşılmaz? Bu projeler yayında, belirsizlik nerede?

Ancak. Bir web stüdyosu olsanız ve bu sizin bininci siteniz olsa bile, müşteri için bu ilk defa oluyor. Ve arzuları sonuna kadar belirsiz kalacaktır. Birçok stüdyo, ana sayfanın 3-4 versiyonunu hazırlıyor ve öngörülemeyen iyileştirmeler için bir hafta ayırıyor. Tanıdığım herkes tekrarlar halinde çalışıyor, bunu bir gösteri ve tartışma takip ediyor. Müşteriyle iletişim, imzalanan sözleşmeden daha önemlidir.

Bir evin yapımında bir proje planı, malzeme hesaplaması ve işçilik maliyetleri vardır. Ancak bazı nedenlerden dolayı son teslim tarihleri her zaman uzar. Temelin yüzdüğü, şapın kuruduğu, bir şeyin çatlamaya başladığı, kerestenin nemli olduğu, tuğlanın çok gözenekli olduğu, yanlış marka çimentonun teslim edildiği veya müşterinin fikrini değiştirip şimdi karar verdiği olur. hamam olacak. Ustabaşı bir insan orkestrasıdır, ortaya çıkan her şeye karar verir, sonuç uğruna sürekli plandan sapar. Normal bir ev, bir açıklamadan çok daha önemlidir.

Tamam, McDonald's hamburgeri yapma konusunda hiçbir belirsizlik yok. Süreç 70 yılı aşkın süredir geliştirildi ve 125 ülkede tekrarlandı. Evet, bu esnekliğe müdahale etmemenin daha iyi olduğu bir taşıma bandıdır. Çevik, yıllar içinde iyi bir şekilde oluşturulmuş süreçlere uygulanamaz. Doğru, çok hassas bir franchise altında yeni bir restoran açmak her zaman benzersiz bir projedir. Yinelemeli bir yaklaşımın olacağı, yinelemelerin azaltılması, rollerin dağıtılması, açık etkileşim, projenin Agile panosunda görselleştirilmesi, geriye dönük, günlük planlama toplantıları.

Agile'ın toplam anahtar değerleri (manifesto):

bir takımda serbest etkileşim
proje etkinliği (harika ürün)
müşteri ile ortaklık iletişimi
değişime hazır olma

Rolleri olan takımlar nelerdir?

Tipik bir takımda iki rol vardır: Şef ve Ast, biri akıllı, diğeri aptal. Agile'da üçü temel olarak önemlidir: Ürün Müşterisi, Metodolog, Ekip Üyesi.

Basitleştirilmiş biçimde:
Müşteri- Hangi ürüne ihtiyaç duyulduğunu, neden ihtiyaç duyulduğunu söyler, pazardan gelen talepler etrafında tartışmalar düzenler, öncelikler konusunda kararlar alır.
Metodist- Müşterinin patrona dönüşmemesini sağlar. Ayrıca, örneğin tüm görevlerin derecelendirilmesi veya böyle bir anlaşma varsa görev tahminlerinin mevcut sürenin %80'ini aşmaması için başka uygulamaların da uygulanması.
Takım- Görevleri değerlendirir, dağıtır ve uygular. Her zaman ayrı ayrı tamamlanmış parçaları değil, ürünün bir versiyonunu gösterir.

Basitçe söylemek gerekirse Agile, ekibin ihtiyaç duyulan ürün hakkında farklı açılardan maksimum miktarda bilgiyi tüm detaylarıyla almasını sağlayan ve kabul eden bir kişiye ihtiyaç duyar. Aktif katılım nasıl uygulanacağı tartışılıyor. Görevi yukarıdan bir direktif olarak değil, ürün geliştirilirken kullanıcı için ne yapılması gerektiğine dair bir açıklama ve anlayış olarak aldım.

Dışarıdan bakıldığında çevik bir ekibi geleneksel ekipten ayıran şey, sözde anlatı işbirliğinin varlığı veya yokluğudur. “Ürün nasıl uygulanır?” sorusuyla ilgili bir tartışma varsa her seviyede, bu da ekibin esnek olduğu anlamına gelir. Belirli görevlerin bir listesini tamamlamadığı için kimin suçlanacağını arıyorlarsa, her şey her zamanki gibidir.

Ana soru: "Her şey bu kadar esnekken kaynaklar nasıl yönetilir?"

Sorumlu ekipler ve yöntemin ortaya çıkış tarihi hakkındaki tüm bu hikayeler, soruların cevabı yoksa tam bir çöp olarak algılanıyor:
“Kaynakları nasıl daha doğru yönetebiliriz?”, “Bir projeyi tamamlamak için yeterli kaynağın olmadığını nasıl daha erken anlayabiliriz?”, “Her zaman görevleri sanatçılar arasında belirleyip dağıttık ve sonucu tahmin edebiliyorduk, peki şimdi ne olacak? ” Agile hakkında konuşmak için sadece bu soruya cevap verebilirsiniz.

Genel olarak Agile'ın tamamının özellikle kaynak sorununu çözmek için tasarlandığını belirtmek gerekir: "Öngörülemeyen bir projede kaynaklar nasıl etkin bir şekilde yönetilir?" Asıl amaç rahatlık ve özgürlük olsaydı metodoloji doğmazdı. takımdaki insanlar.

Özellikle kaynak tahminini açıkça hedefleyen birkaç önemli ilke ve yöntem vardır:

1. Gerekli kaynakların görünürlüğü.Çevik kurullar metodolojiyle ayrılmaz bir şekilde bağlantılıdır. Bu, görevlerin sütunlara dağıtıldığı ve sütunların, içerdikleri görevlerin aşamasını belirlediği zamandır. Bu, projenin durumunu görselleştirmek için en görsel araçtır. İdeal olarak, dışarıdan herhangi biri için projenin hangi aşamada olduğu ve sonuna ne kadar zaman kaldığı açık olmalıdır. Birdenbire yeterli kaynağın olmadığı veya önceliklerin değiştirilmesi gerektiği herkes tarafından açıkça anlaşılırsa, bu kendiliğinden olacaktır.
Sonuçların öngörülebilirliği ve önceliklerin yönetimine ilişkin sorunlar, tam olarak görünürlük yoluyla çözümlenir.

2. Öncelikler ve birikim. Planlama yaparken, tüm görevlerin ayrılan sürede tamamlanamayacağı dikkate alınır. Her zaman ne yapılması gerektiğinin ve ne yapmanın güzel olacağının bir listesi vardır (bu birikmiş iş listesidir). Öncelikler, ekip tarafından ürünün iç müşterisi ile görüşülerek belirlenir. Zaman kalırsa, ikinci derece önem taşıyan görevler çözülür; Zorunlu (Kritik) olarak işaretlenen görevleri bile kapatmak için zamanları yoksa ekip daha da zorlanır.

3. Kısa yinelemeler(sprintler). Bu yaklaşım, başka hiçbir şeye benzemeyen, şirketlerin Agile'dan bir şeyler denemesine olanak tanır. Yönetim, müdahil olmadan ve herkese görev vermeden birkaç hafta içinde bir ara sonuç üzerinde anlaşmaya varır. Altı ay boyunca böyle bir çalışma programını kabul etmek imkansız olurdu.
Bir sprint (yineleme) birkaç haftalık bir zaman dilimidir. Bizim için çoğu zaman 2 haftadır. Bir sprintte en önemli şey hangi ara sonucun elde edilmesi gerektiğinin belirlenmesidir. Bu sonucu yineleme olarak adlandırmak iyidir; örneğin, "Panoları haklarıyla birlikte yayınlayın" veya "Siteyi test için yayınlayın". Çalışma zaman dilimleri halinde ilerliyorsa ancak her bölüm belirli bir sonuca yol açmıyorsa bu artık tekrarlanan bir yaklaşım değildir.

4. Tişört bedenlerindeki sorunların tahmini.İnsanlar görevlerle ilgili kesin tahminler vermekten pek hoşlanmazlar, ancak kabaca büyük, orta, küçük ölçekte tahmin yapmak çoğu kişi için normaldir. Aşağıda, yüksek doğruluk olmadan sorunları tahmin etmek için dünyanın en popüler yöntemleri bulunmaktadır. Kullanım sıklığına göre yüzdelerle.

Üçüncüyü kullanıyoruz, ancak derecelendirmeler yalnızca 1 saat, 2 saat, 4 saat, 8 saattir.

Yaklaşımın amacı, birisinin işi hakkında yanlış değerlendirmeler yapmasını yakalamaya çalışmaktan kaçınmaktır. Zaten en başından beri örnek teşkil ediyorlar. Odak noktası, sprint sırasında herkesin yaklaşık olarak zamanla bağlantılı olan maksimum puanı almaya çalışmasıdır.

5. Burndown grafiği(yanma programı)
Çok basit bir şey iki çizgiden oluşan bir grafiktir; birincisi ne kadar zaman yakıldığı ve bu her zaman düz bir çizgi, ikincisi ise kaynaklar açısından kaç görevin kapatıldığı ve burada dalgalanmaların mümkün olduğu. Aslında bu, takımın doğru yolda mı yoksa programın gerisinde mi olduğu sorusunun grafiksel bir cevabıdır.

Burada ayrıntı verilmeden yalnızca genel yaklaşımlar sunulmaktadır; belki de kaynak yönetiminin ayrıntılarını içeren ayrı bir materyal yazmaya değer. Ama burada iki satırda özetlersek şu ortaya çıkar:

En yaygın hata tahminleri çok doğru tutturmaya çalışmaktır, ekip sonuç üzerinde çalışmayı bırakır
En başarılı yaklaşım, bir zaman rezervi oluşturmak ve kaynakların %80'ini planlamaktır

Rusya'nın en büyük, en eski ve en ünlü SEO stüdyosundan içeriden bilgi- Kaynakları iki kez ayırırlar; ilki müşteriyle görüşme sırasında, ikincisi ise iç planlama sırasında.

Herkesin anlayabileceği en popüler 5 Agile uygulaması

Agile'ın temel düzeydeki uygulamasının basit olduğunu bir kez daha vurgulamak isterim. Öğrenilmesi uzun zaman alan süper karmaşık teknikler yoktur. Aşağıda örnek olarak en popüler 5 uygulama verilmiştir (VersionOne'un aynı anketine göre)

Hepsi her alandaki projelere uygulanabilir ve anında kullanılabilecek kadar basittir. Hepsi yinelemeli bir yaklaşımın ortak fikrinde birleşiyor.

1. Yinelemeli planlama- sprintler (takımların %90'ı kullanıyor)
Küçük serilerde orta düzey sonuçlarla çalışmak iyi bir uygulamadır. Bir sprint birkaç haftadır. Çok kısa veya çok uzun bölümler kötüdür. Tüm durumlar için aynı aralık da uygun değildir. Sprint'in en kesin hedefi olmalı ve süre buna göre belirlenmelidir.
En sık hata ekiplerin görevleri iki haftada bir basitçe planlamaya alışması ve ara hedefleri belirleme ve sonunda özetleme süreçlerinin kaybolmasıdır. İş, sprint başına bir kez güncellenen olağan görev akışına giriyor. Sorunun metodolog tarafından çözülmesi gerekir.

2. Günlük planlama toplantıları(Takımların %88'i kullanıyor)
Ekibin amacı, her gün tüm katılımcıların aynı yönde hareket ettiğini doğrulamaktır. Klasik açıklamaya göre ekipteki herkes üç soruyu yanıtlıyor:

Sprintten bugüne kadar neler başarıldı?
Bugün için ne planlanıyor?
Hangi sorunlar ortaya çıktı veya sizi durduran ne?

Bizim uygulamamızda ekipler bundan çabuk sıkılıyor ve rutin ya da resmi bir raporlama haline geliyor. Ne yardımcı olur:
Planlama toplantı süresini değiştirin - 6 ay. sabah, 6 ay Akşam.
Planlama toplantısının liderini her seferinde değiştirin; rapor verecekleri kimse olmamalıdır. Liderin kurayla çekilmesi durumunda mükemmel bir seçenek. Ürün müşterisi, planlama toplantısının başında müşteri hikayelerini paylaşın. Tartışmak ortak konular ve ancak bundan sonra sorulara geçin. Ekip üyeleri dışında hiç kimsenin planlama toplantılarına katılmasına izin vermeyin.

3. Retrospektifler(Takımların %83'ü kullanıyor)
Yinelemenin sonunda toplantı. Neyin işe yarayıp neyin yaramadığının tartışılması. En önemli amaç nasıl değişileceğine dair sonuçlar çıkarmaktır.
Ürünün müşterisi - kullanıcı beklentilerini en iyi şekilde nasıl gösterebileceği, metodoloji uzmanı - diyaloğun nasıl teşvik edileceği ve seçilen yaklaşımların anlaşmalarının nasıl yerine getirileceği, ekip - değerlendirme yaparken yeni ortaya çıkan faktörlerin nasıl dikkate alınacağı hakkında. Kural olarak, retrospektifler eğlencelidir; yineleme bitti, nefes alıp sonuçları tartışabilirsiniz. İyi pratik Bu süreçteki molalarda bir şeyler içip yiyin.

4. Yinelemeli gösteriler(Takımların %81'i kullanıyor)
Bu, projenin sonuçlarının birkaç yinelemede bir, genellikle bir konuşma şeklinde, ekibin yaptığı bir gösteridir. Asıl mesele bir “oturum” düzenlemektir ve eğer yönetime rapor vermek gibi bir hal alırsa sorun olmaz. Asıl zorluk, ekipten başka birinin bir araya gelmesini sağlamak ve hatta olup bitenlerin anlamını anlamaktır. Uygulamamızda ancak çok güçlü bir liderlikle kök salıyor.

5. Kısa yinelemeler(Takımların %71'i kullanıyor)
Önemli olan, küçük ara sonuçlar elde etme döngüsünü sürekli olarak kısaltmaya çalışmanız gerektiğidir. Bu yapılmazsa, ara hedeflere bakılmaksızın döngüler doğal olarak büyüyecek veya sabit kalacaktır. Döngü ne kadar kısa olursa yinelemeli planlama sırasında o kadar az hata olur. Bu, metodolojistin görevidir; bunu en az altı ayda bir hatırlamakta fayda var.

Bir projenin Agile metodolojisi kullanılarak yürütülüp yürütülmediği nasıl anlaşılır?

Kaç şirketin Agile'ı kendilerine uyacak şekilde değiştirdiğini gösteren bir diyagram şuna benzer:

Yaklaşımın esnekliği yaklaşımın kendisine kadar uzanır. Bir ekibin daha esnek olmak istiyorsa öğrenmesi gereken ilk şey budur. Tüm gereklilikleri takip ederek %100 Çevik olamazsınız. Hiç kimse kurallara sıkı sıkıya uymuyor saf formu, pratikte her şirketin kendi modifikasyonları vardır.

En popüler Çevik yöntemlerin uygulanması kolaydır, sonuç üretir ve şirketi alt üst etmez. Bu nedenle Agile'dan bir şey kullananların %98'i yaklaşımların başarılı olduğunu söylüyor.

Örneğin sabah planlama toplantılarıyla başlarsanız ekipte kötü bir şey olmaz, ancak proje içindeki kişiler arasındaki basit günlük diyalog süreci daha esnek hale getirir.

Esneklik ve katılığın birleşimi her zaman bireyseldir ve birçok faktöre bağlıdır: yönetici, projenin karmaşıklığı, ekip büyüklüğü, bütçe vb. Ancak en az bir yaklaşım anlamlı bir şekilde uygulanmışsa, bu şirket Agile metodolojisine göre çalışıyor demektir ve bunu ekip içinde gururla duyurmak yanlış olmaz.