Çevik geliştirme metodolojisi. Atik. Bu Yöntem Nasıl ve Ne Zaman Uygulanmalı Çevik Bir Organizasyonun Temel Yapı Taşları

"NASA'nın aya bir adam gönderirken karşılaştığı tüm zorluklar arasında, kontrol muhtemelen en zor görevdi."

- Roger Launis, NASA Tarihçisi

Tarih boyunca insanlık, başarıyla uygulanan karmaşık projelerin etkileyici bir listesini biriktirdi. Giza'daki Piramitlerin inşasından aya bir adam göndermeye kadar, en cüretkar insan çabaları binlerce insanın koordineli çalışmasını gerektiriyordu. Bu da karmaşık bir proje yönetim sistemi anlamına gelir.

Ve sadece birkaçımız bu büyüklükteki görevlerle karşı karşıya kalacak olsa da, bu blogun okuyucularının çoğu şu ya da bu şekilde proje yönetimi ile karşı karşıya. PMI, 2020 yılına kadar olacağını tahmin ediyor - ve diğer birçok profesyonel genellikle en azından kişisel düzeyde mini projeleri yönetmek zorunda kalıyor.

Basit bir ifadeyle, Proje Yönetimi, bir hedefe ulaşmak için ihtiyacınız olan her şeyi yönetmek ve organize etmekle ilgilidir - tabii ki zamanında ve bütçe dahilinde. Yeni bir tane geliştirmeye hazır olun yazılım, bir pazarlama kampanyası yürütmek veya bir adamı Mars'a indirmek - proje yönetimi başarılı olmanızı sağlar.

Tüm projeler farklıdır. Her proje türü için mükemmel bir proje yönetim sistemi yoktur. Ayrıca her lidere uygun ve tüm ekip üyelerine uygun bir sistem de yoktur. Ancak proje yönetiminin varlığı sırasında benimsenebilecek birçok etkin yaklaşım, yöntem ve standart oluşturulmuştur. Bugün bunların en popülerlerinden bahsedeceğiz.

Geliştirilen yaklaşımlar birbirinden çok farklıdır. Kapsam, ayrıntı, kendi kendine yeterlilik ve resmileştirme açısından farklılık gösterirler. Başlıkta kolaylık olması açısından bunlara “yöntemler” adını verdik, ancak aslında bu makale proje yönetiminde kullanılan standartları, kavramları, yöntemleri ve çerçeveleri tanıtıyor. Bu makalenin amacı, proje yönetimine yönelik mevcut yaklaşımlara en geniş genel bakışı sağlamaktır.

Bu yazıda şunlara bakacağız:

• Klasik proje yönetimi
• Atik
• Scrum
• Eğilmek
• kanban
• AltıSigma
• PRENS2

Ve belirli yöntemlere bakmadan önce, bariz soruyu cevaplayalım - "Neden proje yönetim sistemlerine ve yöntemlerine ihtiyacımız var?"- tabii ki, proje yönetiminin tarihini kısaca düşünün ve proje yönetiminin temel terimlerini tanımlayın.

Neden "proje yönetimi"?

Neil Armstrong ve Buzz Aldrin'in isimleri, insanlığın en büyük başarılarından birinin - insanın aya inişinin - sembolleri olarak sonsuza dek tarihe geçecektir. Ancak, bu etkinliğe en çok katkıda bulunanlar 400.000 NASA çalışanı ve Apollo görevinde birlikte çalışan 20.000 şirket ve üniversiteydi.

1961'de John F. Kennedy, bir adamı bir Dünya uydusuna indirme ve onu geri döndürme görevini üstlendi - o sırada NASA'nın bir adamı sadece 15 dakikalığına uzaya göndermesine rağmen. Böyle iddialı bir hedef, inanılmaz miktarda kaynak, işbirliği, yenilik ve planlama gerektiriyordu.

NASA'nın Ay Programını Yönetmek adlı kitabının belirttiği gibi, asıl sorun şu değildi: “ ne yapalım?", ama bunda, " Bu kadar kısa sürede nasıl bu kadar çok şey yapılır?" Lyndon Johnson Uzay Merkezi'nde mühendislik başkanı olan Dr. Max Faget'e göre (Lyndon B. Johnson Uzay Merkezi, JSC), o zaman NASA'nın gerekli tüm eylemleri 10 yıl içinde nasıl koyacağı hakkında hiçbir fikri yoktu. Bu nedenle ilk adım "projeyi yönetilebilir aşamalara bölmek" oldu.

O zaman her aşamayı hızlandırmak ve her aşamada çalışan ekiplerin ve şirketlerin birbirleriyle etkili bir şekilde iletişim kurmasını ve zamanında sonuç vermesini sağlamak önemliydi. Bu görev, Apollo projesinin Beyaz Saray'dan en küçük parçanın tedarikçisine kadar her bölümünü yöneten Dr. George E. Muller'e verildi. Projeyi kontrol etmeyi kolaylaştırmak için projeyi 5 alana ayırmaya karar verdi: Program Kontrolü, Sistem Mühendisliği, Test, Güvenilirlik ve Kalite ve Uçuş Operasyonu. Apollo program kontrol şeması şurada sunulmaktadır: Şekil 1.

Dr. Müller'in baş harflerinden sonra "GEM Aşamaları" olarak adlandırılan bu 5 aşamalı sistem, Mueller'in kendisinin belirttiği gibi "test edilmek amacıyla ürün testi ve ürün geliştirmeye odaklanmak için" tasarlandı. Program Kontrolü, yapılması gerekenleri belirledi, bütçeyi ve gereksinimleri yönetti ve program öğelerinin ilişkisini yönetti. "Sistem Mühendisliği" alanı, yeni cihaz ve düzeneklerin geliştirilmesinden, bu yeni öğelerin çalıştığından "Test", "Güvenilirlik ve Kalite", geliştirilen öğelerin gereksinimlere ve standartlara uygunluğunun kontrol edilmesinden ve "Uçuş Operasyonu"ndan sorumluydu. Bu düğümlerin uçuş sırasında çalışacağı gerçeğinden sorumluydu.

Birçoğu başlangıçta Müller tarafından önerilen yönteme şüpheyle tepki gösterdi, ancak sonunda programın üyelerini bu algoritmayı takip etmeye ikna etmeyi başardı. Bu sistem etkinliğini göstermiştir - proje başarıyla tamamlandı ve hatta ilan edilen son teslim tarihlerinden önce muzaffer bir şekilde söylenebilir. Bu, ancak büyük ölçekli bir projenin, birçok ayrı şirketin ve uzmanın tek bir ritimde çalışmasına izin veren yönetilebilir, tekrarlanabilir aşamalara bölünmesi sayesinde mümkün oldu. Proje yönetimi Uzay Yarışı'nda etkinliğini bu şekilde kanıtladı.

Proje yönetiminin kısa bir tarihi

Proje yönetimi NASA ve Dr. Mueller tarafından icat edilmedi. Mısır piramitleri ve Çin Seddi, tarih öncesi çağlardan kalma proje yönetiminin ürünleridir. Ne yazık ki, bu projelerin nasıl uygulandığına ve yönetildiğine dair hiçbir belgesel kanıt yoktur ve mevcut proje yönetimi geçmiş yüzyılların bilgisinden kopmuştur.

Bir projeyi uygulamanın en belirgin yolu, onu aşamalara veya ayrı görevlere ayırmaktır. Bir yemek tarifi gibi - malzemeleri satın alın, doğru şekilde karıştırın, pişirin ve servis yapın. En basit proje yönetimi aracı, bir hedefe ulaşmak için yapılması gereken eylemlerin bir kontrol listesidir. Basit ve etkili.

Ancak, bir şefseniz ve birden fazla yemek pişiriyorsanız, ancak örneğin bir salata (hazırlanması 3 aşamadan oluşan) ve bir tatlı (sadece servis edilmesi gereken) gibi birkaç yemek pişiriyorsanız, o zaman bir araca ihtiyacınız olacaktır. öğelerin her birine harcanan zamanı ve hazır olmaları gereken zamanı izlemenize olanak tanır. Ve burada ilk modern proje yönetimi araçlarından biri kurtarmaya geliyor: Gantt şeması, şekil 2.

K tarafından bağımsız olarak icat edildi Ö Korol Adamecki ve Genry L. Gantt'ın 20. yüzyılın başlarındaki rolü, bir Gantt şeması, görev tamamlama ve tamamlama tarihlerine dayalı bir proje çizelgesini gösterir. Görevler, süreleri ve ilişkileri buna girilir ve daha sonra kritik yol hesaplanır - projenin süresini belirleyen birbiriyle ilişkili en uzun görevler zinciri. Farklı görevleri başlatmak ve bitirmek arasındaki ilişki çok önemlidir - misafirlerinize çorbayı pişirene kadar servis edemezsiniz, değil mi?

Bu nedenle, tipik bir proje, bir akşam yemeği hazırlama ve servis etme projesine çok benzer, yalnızca daha fazla görevi, ilişkisi, son teslim tarihi ve kaynak türü vardır. Sınırlı teslim tarihlerine sahip projeler için Gantt şeması, uygulama süresini kısaltmak için belirli görevlerin ne zaman başlatılacağına karar vermenize yardımcı olur. Güçlü kaynak kısıtlamaları olan projeler için Gantt şeması, kaynak planlaması için olaya dayalı bir süreç zinciri oluşturma yeteneği sağlar.

Farklı projeler gerekiyor farklı seviye kontrol. Örneğin, bir dizi makale yayınlıyorsanız, sıkı son tarihler o kadar önemli değildir. Çok daha önemli olan, her makaleyi yapılandırmanın, her makaleyi çizmenin, geri bildirim almanın, düzenlemeler yapmanın, makaleyi bitirmenin, düzeltme okumanın ve yayınlamanın mümkün olduğu açık bir süreçtir. Zamanı ve kaynakları yönetmek yerine süreci kontrol edersiniz.

Çevik proje yönetimi teknikleri ve Lean, Kanban ve diğerleri gibi ilgili yaklaşımlar bu tür projeler için daha uygundur. Hem iş akışını hem de zamanı ve kaynakları yönetmenize izin veren yöntemler de vardır - 6 Sigma ve Scrum.

Popüler proje yönetim sistemleri

Proje yönetiminin tarihi boyunca hemen her ihtiyaca yönelik birçok farklı proje yönetimi yöntemi oluşturulmuştur. Ay'a bir insan göndermeyecek ve aynı miktarda kaynağa sahip olmasanız bile, yine de kendinize uygun bir araç bulacaksınız. Anahtar, projeniz için neyin en önemli olduğunu - son tarihler, kaynaklar, sürece bağlılık veya aynı anda birkaç faktör - anlamak ve ardından bu göstergeyi elde etmeye odaklanan bir proje yönetimi yöntemi seçmektir.

En popüler yöntemlere bakmaya başlamadan önce, bazı anahtar terimleri tanımlayalım.

Proje yönetiminin temel terimleri

Atik:Çeşitli profillerden uzmanlardan oluşan kendi kendini organize eden çalışma grupları içinde sürekli etkileşimin bir sonucu olarak gereksinimlerin dinamik oluşumuna ve bunların uygulanmasını sağlamaya odaklanan proje ve ürün yönetimine esnek yinelemeli-artımlı bir yaklaşım. En popülerleri Scrum ve Kanban olan Çevik fikirlere dayalı birçok yöntem vardır.

Kritik yol: Tamamlanması en uzun süreyi alan olayın başından sonuna kadar sürekli bir etkinlik ve olaylar dizisi.

Olay zinciri süreçleri (EPC diyagramı): kaynakların kullanılabilirliğine ve kullanımına dayalı olarak projelerin uygulanma sırasını gösteren bir diyagram

Zaman rezervi: Projenin genel süresini etkilemeden işin başlamasının ertelenebileceği süre. Böylece kritik yol üzerindeki işler için rezerv sıfıra eşit olacaktır.

Kilometre taşı (kontrol noktası,dönüm noktası):Örneğin, bir aşamanın sonunu işaret eden önemli bir olay. Gantt şemasında belirtilen, süresi sıfır olan bir görevdir.

Proje yöneticisi (proje yöneticisi,projeyönetici,ÖĞLEDEN SONRA ): Proje yönetiminden (projenin planlanması, uygulanması ve kapatılması) sorumlu proje takım lideri.

Kaynaklar: Projenin uygulanması için gerekli unsurlar. Kaynaklar zaman, ekipman, malzemeler, çalışanlar vb.

sürat koşusu (Sürat koşusu): Scrum'da bir haftadan bir aya kadar süren, bir ürünün çalışan bir versiyonunun veya müşteri için değer unsurunun yaratıldığı bir yineleme (çalışma döngüsü).

"Klasik" veya "geleneksel" proje yönetimi: En yaygın olarak kullanılan proje yönetimi yöntemi, görevin bir akışa benzeyen aşamalarda sırayla aktarıldığı "şelale" veya kademeli döngüye dayanmaktadır.

Klasik proje yönetimi

Projenizi daha yönetilebilir hale getirmenin en belirgin yolu, yürütme sürecini ardışık adımlara bölmektir. Geleneksel proje yönetiminin temeli bu doğrusal yapı üzerinedir. Bu anlamda bir bilgisayar oyununa benziyor - bir öncekini tamamlamadan bir sonraki seviyeye geçemezsiniz. İş akışı şeması şurada gösterilir: Figür 3.

Bu yaklaşım, görev sırası üzerinde katı kısıtlamaların olduğu projelere odaklanır. Örneğin, bir ev inşa etmek - temelsiz duvarlar inşa edemezsiniz.

Klasik proje yönetiminin genellikle 5 aşaması vardır, ancak proje gerektiriyorsa ek aşamalar eklenebilir.

Geleneksel yönetimin 5 aşaması:

Aşama 1. Başlatma. Proje yöneticisi ve ekip, proje için gereksinimleri tanımlar. Bu aşamada, genellikle projenin ürününün ne olması gerektiğine karar verilen toplantılar ve "beyin fırtınası" oturumları yapılır.

Aşama 2. Planlama. Bu aşamada ekip, bir önceki aşamada belirlenen hedefe nasıl ulaşacağına karar verir. Bu aşamada ekip, projenin amaçlarını ve sonuçlarını ve proje üzerindeki çalışmanın kapsamını netleştirir ve detaylandırır. Ekip, bu bilgilere dayanarak bir program ve bütçe oluşturur, riskleri değerlendirir ve paydaşları belirler.

Aşama 3. Geliştirme. Bu aşama tüm projeler için uygulanmaz - kural olarak planlama aşamasının bir parçasıdır. Teknolojik projeler için tipik olan geliştirme aşamasında, gelecekteki proje ve/veya ürünün konfigürasyonu ve bunu gerçekleştirmenin teknik yolları belirlenir. Örneğin IT projelerinde bu aşamada bir programlama dili seçilir. ( Ev içi uygulamada, bu aşama genellikle vurgulanmaz ve "kalkınma" terimi kullanılmaz - yakl. başına.)

Aşama 4. Uygulama ve test etme. Bu aşamada, projedeki asıl ana çalışma gerçekleşir - kod yazma, bir bina inşa etme ve benzerleri. Geliştirilen planların ardından önceden belirlenen proje içeriği oluşturulmaya başlanır, seçilen metriklere göre kontrol yapılır. Bu aşamanın ikinci bölümünde ürün test edilir, Müşteri ve ilgili tarafların gereksinimlerine uygunluğu kontrol edilir. Test açısından ürün eksiklikleri tespit edilir ve düzeltilir.

Aşama 5. Projenin izlenmesi ve tamamlanması. Projeye bağlı olarak, bu aşama proje sonuçlarının Müşteriye basit bir şekilde aktarılmasından veya projeyi iyileştirmek ve memnuniyetlerini artırmak ve proje sonuçlarını desteklemek için müşterilerle uzun bir etkileşim sürecinden oluşabilir. İkincisi, müşteri hizmetleri ve yazılım alanındaki projeler için geçerlidir.

Yukarıda açıklananlar, çeşitli proje yönetimi yöntemlerinin üzerine inşa edildiği temeldir. Farklı projeler, farklı uygulama aşamalarına ihtiyaç duyar - bazıları için yeterlidir ve üç aşama, diğerleri çok daha fazla. Bazen, her aşamanın bir alt proje olduğu ve görevlerin sabit yinelemelerde uygulandığı "yinelemeli şelale" adı verilir. Ancak öz aynı kalır - proje, kesin olarak tanımlanmış bir sırayla yürütülen aşamalara ayrılır.

Klasik proje yönetiminin, kural olarak, planlama aşamasında önceden belirlenen görevlerin yürütme süresine sıkı sıkıya bağlı olması nedeniyle, çizelgeleme ve ağ planlama araçları, projeleri bu yaklaşım içinde uygulamak için mükemmeldir. En yaygın zamanlama aracı, daha önce bahsedilen Gantt şemasıdır. Excel ve Smartsheet gibi basit elektronik tablolardan Microsoft Project ve Primavera gibi profesyonel yazılım paketlerine kadar onu oluşturmak için birçok araç vardır.

Güçlü klasik proje yönetimi

Günümüzde klasik şelale yaklaşımının modasının geçtiği sıklıkla söylense de konumlarından vazgeçmeyi bile düşünmüyor. Bu yaklaşımın en büyük artısı, daha projenin ilk aşamasında Müşterinin ve şirket yönetiminin ne almak istediklerini belirlemesini gerektirmesidir. Erken katılım, projeye belirli bir düzeyde istikrar getirir ve planlama, projenin uygulanmasını kolaylaştırmaya yardımcı olur. Ek olarak, bu yaklaşım, çeşitli boyutlardaki gerçek projeler için kesinlikle gerekli olan performans izleme ve test etme anlamına gelir.

Potansiyel olarak klasik yaklaşım, herhangi bir komplikasyon durumunda ve risklerin gerçekleşmesi durumunda her aşamada boş zamanın bulunması nedeniyle stresten kaçınmanıza izin verir. Ayrıca, doğru planlama aşamasıyla proje yöneticisi hangi kaynaklara sahip olduğunu her zaman bilir. Bu tahmin her zaman doğru olmasa bile.

Klasik proje yönetiminin zayıf yönleri

Klasik proje yönetiminin temel zayıflığı, değişime karşı tahammülsüzlüğüdür. Yalın ve Kanban gibi sistemler oluşturmakla ünlü Toyota yöneticileri, şirketleri için yazılım geliştirmeye yönelik klasik yaklaşımı benimsedikleri ve tam olarak esneklik eksikliği nedeniyle sıklıkla eleştiriliyor.

Klasik yaklaşımın temel dayanağı, proje içeriğinin tüm proje boyunca pratikte değişmeden kaldığı inşaat ve mühendislik projeleridir. Ancak, projenizdeki temel kısıtlamalar kaynaklar ve zaman değilse ve projenin içeriği değişebilirse, diğer proje yönetim sistemlerine bakmanız gerekebilir.

Atik

Daha önce de belirtildiği gibi, tüm projeler klasik proje yaklaşımına göre uygulanacak şekilde yapılandırılamaz. Şefle verdiğimiz örneğe dönersek: bir yemeğin hazırlanması ideal olarak "şelale" yaklaşımına uygundur, ancak her seferinde sonuna kadar beklemek zorunda kalırsanız, dört çeşit bir akşam yemeğini zamanında hazırlamak ve sunmak neredeyse imkansız olacaktır. başka bir yemek pişirmeye başlamak için bir yemek.

İşte tam bu noktada Agile devreye giriyor - projeleri ve ürünleri yönetmek için esnek, yinelemeli-artımlı yöntemler ailesi. Bu yaklaşıma göre, proje ardışık aşamalara değil, küçük alt projelere bölünür ve bunlar daha sonra bitmiş bir ürüne “birleştirilir”. Çalışma şeması üzerinde gösterilir Şekil 5.

Böylece, tüm proje için başlatma ve üst düzey planlama yapılır ve sonraki aşamalar: geliştirme, test ve diğerleri her mini proje için ayrı ayrı gerçekleştirilir. Bu, sözde artışlar olarak adlandırılan bu mini projelerin sonuçlarını daha hızlı aktarmanıza ve yeni bir alt proje başlatmanıza (yineleme) izin verir, yüksek maliyetler olmadan ve projenin geri kalanı üzerinde etki yaratmadan değişiklikler yapabilirsiniz.

Çevik'in nispeten yakın zamanda moda olmasına rağmen, yinelemeli geliştirme fikri yeni değil. (görünüş tarihi hakkındaÇevik okunabilir - yaklaşık Tercüme). Agile ailesi, 2001 yılında ekip çalışmasına ve adaptasyona, hatta değişim "sevgisine" dayalı, çevik yazılım geliştirmenin temel değerlerini ve ilkelerini barındıran Çevik Manifesto'nun yayınlanmasıyla bugünkü adını almıştır.

Agile'ın kendisi bir proje yönetimi yöntemi değildir. Daha ziyade, projelerin nasıl uygulanması gerektiğine ilişkin bir dizi fikir ve ilkedir. Zaten bu ilkeler ve en iyi uygulamalar temelinde, ayrı esnek yöntemler veya bazen adlandırıldığı gibi çerçeveler (çerçeveler) geliştirildi: Scrum, Kanban, Crystal ve diğerleri. Bu yöntemler birbirinden oldukça farklı olabilir, ancak aynı ilkeleri takip ederler.

GüçlüAtik

Agile'ın en önemli avantajı esnekliği ve uyarlanabilirliğidir. Hemen hemen her organizasyonun ortamına ve süreçlerine uyum sağlayabilir. Mevcut popülaritesini ve temelinde çeşitli alanlar için kaç sistem oluşturulduğunu belirleyen şey budur.

Çevik ilkelerinden biri: "Değişime yanıt vermek, planı takip etmekten daha önemlidir." Değişime verilen bu hızlı ve nispeten acısız tepkinin nedeni, birçok büyük şirketler süreçlerini daha esnek hale getirmeye çalışır. Ayrıca Agile, bir hizmet veya blog başlatma gibi açık uçlu projeler için harikadır.

Agile'ın alanı, yeni, yenilikçi ürünlerin geliştirilmesidir. Bu tür ürünlerin geliştirilmesine yönelik projelerde yüksek derecede belirsizlik vardır ve proje ilerledikçe ürünle ilgili bilgiler ifşa edilir. Bu gibi durumlarda, "şelale" projesini uygulamak imkansız hale gelir - planlama için bilgi yoktur.

Zayıf taraflarAtik

PRINCE2 ve PMBOK'tan farklı olarak Agile, ne bir metodoloji ne de bir standarttır. Çevik, bir dizi ilke ve değerdir. Zayıf nokta, her takımın Agile ilkeleri tarafından yönlendirilen kendi yönetim sistemini bağımsız olarak oluşturmak zorunda kalacak olmasıdır. Bu, prosedürlerden temel değerlere kadar tüm organizasyonda değişiklikler gerektirecek, zor ve zaman alıcı bir süreçtir. Bu zorlu bir yoldur ve tüm kuruluşlar bunu yapamaz.

Bu yol, liderin yalnızca bilgi ve azmini değil, aynı zamanda ciddi idari kaynakları ve maliyetleri de değiştirmesini gerektirecektir. Neyse ki, bir organizasyonun Çevik dönüşümünü kolaylaştıran kullanıma hazır uygulama kitleri var. Bu setler, Scrum çerçevesini, Kanban yöntemini ve diğer birçok - Crystal, LeSS, SAFe, Nexus'u içerir.

Scrum

1986'da oluşturulan çevik çerçeve, Çevik ailesinin en yapılandırılmış olarak kabul edilir. 1986'da oluşturuldu, klasik sürecin unsurlarını ve çevik bir proje yönetimi yaklaşımının fikirlerini birleştiriyor. Sonuç, esneklik ve yapının çok dengeli bir birleşimidir.

Agile'ın ilkelerini takip eden Scrum, projeyi, ürün biriktirme listesi adı verilen değer elde etmek için Müşteri tarafından hemen kullanılabilecek bölümlere ayırır. Ve “ürün temelinin” oldukça doğru bir çeviri olmasına ve profesyonel literatürde kullanılmasına rağmen, Rus pratiğinde çoğu zaman sadece “birikim” kullanılır. Daha sonra bu parçalara, Ürün Sahibi - Müşteri'nin ekipteki temsilcisi tarafından öncelik verilir. En önemli "parçalar" ilk olarak Sprint'te uygulanmak üzere seçilir - bunlar Scrum'da 2 ila 4 hafta süren yinelemelerdir. Sprint'in sonunda, Müşteriye, halihazırda kullanılabilecek çok önemli "parçalar" olan, ürünün çalışan bir parçası sunulur. Örneğin, işlevselliğin bir kısmına sahip bir site veya kısmen de olsa halihazırda çalışmakta olan bir program. Bundan sonra proje ekibi bir sonraki Sprint'e geçer. Sprint'in süresi sabittir, ancak ekip, projeye ve kendi üretkenliğine bağlı olarak projenin başında bağımsız olarak seçer.

Her Sprint başlamadan önce projenin Müşteri'nin zamanla değişme eğiliminde olan gereksinimlerini karşıladığından emin olmak için henüz tamamlanmamış proje içeriği yeniden değerlendirilir ve üzerinde değişiklikler yapılır. Herkes bu sürece katılır - proje ekibi, Scrum Master (Scrum Master, proje ekibi lideri) ve Ürün Sahibi. Ve bu sürecin sorumluluğu herkese aittir.

Daha önce de belirtildiği gibi, Ürün Sahibi projede Müşterinin temsilcisidir veya Müşteri yoksa gelecekteki projenin tüm müşterilerini kişileştirir. Bunu yapmak için, ürünü ve üretim teknolojisini anlamanın yanı sıra ihtiyaçlarını ve düşünme biçimlerini tam olarak bilmesi gerekir. Scrum Master, proje katılımcılarının Scrum uygulamasının değerlerini, ilkelerini ve normlarını daha iyi anlamalarına ve kabul etmelerine yardımcı olmak için tasarlanmıştır. Dış dünya ile ekip arasında lider ve arabulucudur. Görevi, atanan görevler üzerinde kimsenin bağımsız ve rahat bir şekilde takıma müdahale etmemesini sağlamaktır. Takım, sprint sonunda gerekli tüm görevlerin tamamlanmasını ve teslimatların tamamlanmasını sağlamaktan sorumludur.

Scrum süreçlerinin temel yapısı 5 ana toplantı etrafında döner: biriktirme listesi siparişi, Sprint planlaması, günlük geçişler, Sprint bilgilendirme ve Sprint retrospektifi.

Birçokları için Scrum'ı uygulamak zor olabilir - yeni bir süreç, yeni roller, çok sayıda delegasyon ve tamamen yeni bir organizasyon yapısı. Ancak, Çevik'in belirsiz ve genel ilkelerinin aksine, proje teslimine yönelik esnek ancak yapılandırılmış bir yaklaşım, işin yanlış yöne gitmesini önleyecektir.

GüçlüScrum

Scrum, değişim toleransı ile birlikte hızlı kazanımlar gerektiren projeler için tasarlanmıştır. Ayrıca, bu çerçeve, projenin uygulandığı alanda tüm ekip üyelerinin yeterli deneyime sahip olmadığı durumlar için uygundur - ekip üyeleri arasındaki sürekli iletişim, meslektaşların bilgi ve yardımları nedeniyle bazı çalışanların deneyim veya nitelik eksikliğine yol açar. .

Çevrimiçi TV kanalı Netflix, sonuçların hızlı teslimine harika bir örnektir. Kaynağın sitesi, yalnızca yüksek hızda çalışmanıza izin vermekle kalmayan, aynı zamanda kullanıcı deneyimi biriktiren ve müşteriler için en önemli şeyleri tanımlamayı mümkün kılan Scrum sayesinde iki haftada bir güncellenir.

Her yineleme sırasında, geliştiriciler sitenin yeni özelliklerini ekler ve test eder ve istemciler tarafından kullanılmayanları kaldırır. Netflix ekibine göre Scrum'ın ana yararı, "hızlı bir şekilde yanlış anlamanıza" izin vermesidir. Büyük bir yayın hazırlamak için uzun ve pahalı bir zaman almak yerine, iki haftada bir Scrum gönderileri küçüktür. İzlemeleri kolaydır ve bir şeyler ters giderse hızlı bir şekilde düzeltilebilirler.

Zayıf taraflarScrum

Scrum proje ekibi konusunda çok seçicidir. Küçük (5-9 kişi) ve çapraz işlevli olmalıdır - yani, ekip üyelerinin projeyi uygulamak için birden fazla yeterliliğe sahip olması gerekir. Örneğin, bir yazılım geliştiricinin test etme ve iş zekası konusunda bilgi sahibi olması gerekir. Bu, ekibin bir kısmının projenin farklı aşamalarında “beklememesi” ve çalışanların birbirlerine yardım edebilmeleri ve birbirlerini değiştirebilmeleri için yapılır.

Ayrıca ekip üyeleri “takım oyuncusu” olmalı, aktif olarak sorumluluk almalı ve kendilerini organize edebilmelidir. Böyle olgun bir ekip bulmak çok zor!

Scrum, tüm ekipler ve organizasyonlar için uygun değildir, ayrıca önerilen süreç belirli bir ürünün geliştirilmesi için uygun olmayabilir - örneğin, endüstriyel bir makine aleti veya bir bina inşa etmek.

Eğilmek

Çevik, yönetilebilir küçük iş paketlerine ayrılmamızı söyler, ancak bu paketin geliştirilmesinin nasıl yönetileceği hakkında hiçbir şey söylemez. Scrum bize süreçlerini ve prosedürlerini sunar. Yalın ise, her yinelemenin eşit derecede iyi gerçekleştirilmesi için Çevik ilkelerine bir iş akışı ekler.

Yalın'da, tıpkı Scrum'da olduğu gibi, iş ayrı ve bağımsız olarak uygulanan küçük teslimat paketlerine bölünür. Ancak Yalın'da, Apollo projesi için oluşturulanlara benzer aşamalarla her teslimat paketinin geliştirilmesi için bir iş akışı vardır. Klasik proje yönetiminde olduğu gibi, bunlar planlama, geliştirme, üretim, test etme ve teslim aşamaları veya projelerin yüksek kalitede uygulanması için gerekli olan diğer aşamalar olabilir.

Yalın aşamalar ve esneklikleri, projenin her bölümünün olması gerektiği gibi yapılmasını sağlar. Yalın, Scrum'da olduğu gibi aşamalar için net sınırlar içermez, Sprint'ler sınırlıdır. Ayrıca, klasik proje yönetiminden farklı olarak Yalın, farklı aşamalarda aynı anda birkaç görevi gerçekleştirmenize olanak tanır, bu da esnekliği artırır ve proje yürütme hızını artırır.

Çevik gibi, Yalın da taşa yerleştirilmiş bir şeyden ziyade bir kavram, bir düşünme biçimidir. Yalın fikirleri kullanarak proje yönetimi gereksinimlerinizi karşılayan bağımsız bir sistem oluşturabilirsiniz.

GüçlüEğilmek

Çevik fikirleri seviyorsanız, ancak proje çok tutarlı kalite ve hassas uygulama gerektiriyorsa, Yalın bu gereksinimleri karşılamak için bir dizi araç sağlar. Yalın, Scrum gibi esneklik ve yapıyı birleştirir, ancak biraz farklı bir şekilde.

Zayıf taraflarEğilmek

Bir projenin her parçası aynı detaylı ve titiz çalışma ve dikkati gerektirmez. Ancak Yalın, her görev ve aşamada tam olarak bu yaklaşımı benimser. Bu, büyük ve heterojen projeler için Yalın kullanmanın ana dezavantajıdır.

Ayrıca, Scrum'dan farklı olarak Yalın, projenin "parçalarının" uygulanması için net bir iş akışı sağlamaz, bu da proje teslim tarihinin uzamasına katkıda bulunur. Bu sorun, etkili liderlik ve açık iletişim ile çözülebilir - bunu akılda tutmak için en önemli şey.

kanban

Yalın kendi başına biraz soyut görünüyor, ancak Kanban ile birleştirildiğinde kendi proje yönetim sisteminizi oluşturmak için kullanmak çok daha kolay hale geliyor. 1953 yılında Toyota mühendisi Taiichi Ono tarafından yaratılan Kanban, endüstriyel üretim planına çok benzer. Bu işlemin girişinde bir metal parçası girer ve çıkışta bitmiş bir parça elde edilir. Ayrıca Kanban'da ürün artışı aşama aşama iletilir ve sonunda ürün teslimata hazır hale gelir.

Buna ek olarak, Kanban'ın yaratıcısı, süpermarketlerden ilham aldı, yani "sadece müşterinin ihtiyaç duyduğu şeyi raflarda tut" ilkesi. Bu nedenle, Kanban'da, önceliği değişmişse ve başka acil görevler varsa, aşamalardan birinde tamamlanmamış bir görev bırakılmasına izin verilir. Düzenlenmemiş bir blog gönderisi, gönderi tarihi olmadan asılı veya ürüne dahil edilmemiş olabilecek bir özellik kodu parçası Kanban çalışması için uygundur.

Kanban, Scrum'dan çok daha az katıdır - sprint sürelerini sınırlamaz, ürün sahibinden başka bir rol yoktur. Kanban, bir ekip üyesinin aynı anda birden fazla görevi yürütmesine bile izin verir, ancak Scrum bunu yapmaz. Ayrıca, projenin durumuyla ilgili toplantılar hiçbir şekilde düzenlenmemiştir - istediğiniz gibi yapabilirsiniz veya hiç yapamazsınız.

Kanban ile çalışmak için iş akışı aşamalarını tanımlamanız gerekir. Kanban'da sütunlar olarak temsil edilirler ve görevler özel kartlarla temsil edilir. Kart, bir fabrikadaki makineden makineye giden bir parça gibi aşamalardan geçer ve her aşamada daha yüksek bir tamamlanma yüzdesi ile hareket eder. Sonuç olarak, müşteriye teslime hazır bir ürün elemanı alıyoruz. Sütunları ve kartları olan bir pano gerçek veya elektronik olabilir - burada bile Kanban, kullanıcılara herhangi bir kısıtlama getirmez.

Kendi Kanban sisteminiz olmasını istediğiniz kadar esnek olabilir - birçok yönden Kanban, Çevik bir fikrin görselleştirilmesidir. Ancak Kanban'ın tüm sistemi destekleyen 4 ayağı vardır:

1. Kartlar: Her görev için, görevle ilgili tüm gerekli bilgilerin girildiği ayrı bir kart oluşturulur. Böylece, görevle ilgili tüm gerekli bilgiler her zaman elinizin altında.
2. Bir aşamadaki görev sayısını sınırlayın: Bir aşamadaki kart sayısı kesinlikle düzenlenir. Bu, iş akışında hızlı bir şekilde çözülen bir "tıkanıklık" oluştuğunda bunu hemen gösterir.
3. Sürekli akış: Biriktirme listesindeki görevler, öncelik sırasına göre akışa girer. Böylece iş hiç durmaz.
4. Sürekli iyileştirme ("kaizen" (kaizen)): Sürekli iyileştirme kavramı, 20. yüzyılın sonunda Japonya'da ortaya çıktı. Özü, üretim sürecinin sürekli analizi ve verimliliği artırmanın yollarını aramaktır.

Güçlükanban

Scrum gibi, Kanban da iyi iletişime sahip oldukça sıkı bir ekip için iyi çalışır. Ancak Scrum'dan farklı olarak Kanban'ın kesin teslim tarihleri ​​yoktur, bu da motive ve deneyimli ekipler için harikadır.

Kanban, uygun şekilde yapılandırıldığında ve yönetildiğinde proje ekibine büyük fayda sağlayabilir. Ekip üzerindeki iş yükünün doğru hesaplanması, kısıtlamaların doğru yerleştirilmesi ve sürekli iyileştirmeye odaklanma - tüm bunlar Kanban'ın kaynakları ciddi şekilde korumasını ve son teslim tarihlerine ve bütçeye uymasını sağlar. Ve tüm bunlar esneklikle birleşiyor.

Zayıf taraflarkanban

Scrum'dan farklı olarak Kanban'da hemen hemen her takımla çalışabileceğinizi sık sık duyabilirsiniz. Ama öyle değil. Kanban, üyelerinin becerileri birbiriyle örtüşen ekipler için en iyisidir. Bu şekilde, sorunları çözmedeki zorlukların üstesinden gelmelerine birbirlerine yardımcı olabilirler. Onsuz, Kanban olabileceği kadar etkili olmayacaktır. Ayrıca, daha önce de belirtildiği gibi, Kanban, sıkı teslim tarihlerinin olmadığı durumlar için daha uygundur. Sıkı teslim tarihleri ​​için klasik yaklaşım veya Scrum daha iyidir.

6 sigma (Altı Sigma)

Motorola, Toyota ile birlikte küresel proje yönetiminin geliştirilmesine de katkıda bulunmuştur. Bu şirkette bir mühendis olan Bill Smith, 1986'da 6 Sigma konseptini yarattı. Bu, Yalın'ın Kanban'dan daha yapılandırılmış bir sürümüdür ve kaynakları korumak, kaliteyi artırmak ve ayrıca hurda ve sorunları azaltmak için daha fazla planlama ekler.

Projenin nihai hedefi, göstergelerin kapsamlı bir analizine dayalı olarak projenin tüm yönlerinin sürekli bir iyileştirme süreciyle elde edilebilecek ürün kalitesiyle müşteri memnuniyetidir. 6 Sigma, ortaya çıkan sorunları gidermeye odaklanır.

Bunun için DMEDI olarak bilinen 5 aşamalı bir süreç önerilmiştir:

• Tanım (Tanımlamak):İlk aşama, diğer proje yönetim sistemlerinin ilk aşamalarına çok benzer. Projenin içeriğini belirler, projenin ön koşulları hakkında bilgi toplar, hedefler belirler.
• Ölçüm (Ölçüm): 6 Sigma, nicel proje verilerini toplamaya ve analiz etmeye odaklanmıştır. Bu aşamada, projenin başarısını hangi göstergelerin belirleyeceği ve hangi verilerin toplanıp analiz edilmesi gerektiği belirlenir.
• Ders çalışma (Keşfetmek): Araştırma aşamasında, proje yöneticisi ekibin hedeflere nasıl ulaşacağına ve tüm gereksinimleri zamanında ve bütçe dahilinde nasıl yerine getireceğine karar verir. Bu aşamada, ortaya çıkan sorunları çözerken proje yöneticisinin kalıpların dışında düşünmesi çok önemlidir.
• Gelişim (Geliştirmek): Bu aşamada, önceki aşamalarda alınan planlar ve kararlar uygulanmaktadır. Bu aşamada gerekli olduğunu anlamak önemlidir. detaylı plan, hedeflere ulaşmak için gerekli tüm eylemleri açıklar. Ayrıca bu aşamada projenin ilerleyişi ölçülür.
• Kontrol (Kontrol): 6 Sigma metodolojisinde önemli bir kilometre taşı. Ana görevi, proje uygulama süreçlerinin uzun vadeli iyileştirilmesidir. Bu aşama, alınan derslerin dikkatli bir şekilde belgelenmesini, toplanan verilerin analizini ve kazanılan bilgilerin hem projelerde hem de bir bütün olarak şirket genelinde uygulanmasını gerektirir.

6 Sigma, Kanban'a çok benzer, yalnızca belirlenmiş kilometre taşlarıyla - planlama, hedef belirleme ve test kalitesi. Büyük olasılıkla, 6 Sigma ile Kanban'a göre önemli ölçüde daha fazla ekip toplantısı olacaktır, ancak proje uygulama süreci daha yapılandırılmıştır ve ekibin yoldan çıkması daha zordur. Ve Kanban gibi, 6 Sigma da belirli bir şirketin veya ekibin ihtiyaçlarına göre nispeten kolayca uyarlanabilir. Kesin bir gereklilik, uygulama aşamalarında proje göstergelerinin yalnızca dikkatli bir şekilde ölçülmesi ve kontrol edilmesidir - bu olmadan, proje uygulama süreçlerinin sürekli uzun vadeli iyileştirilmesi mümkün değildir.

6 Sigma'nın Güçlü Yönleri

6 Sigma, projelerin uygulanması ve süreçlerin sürekli iyileştirilmesi için net bir çerçeve sağlar. Hedefleri tanımlayarak, ardından bunları dikkatlice analiz ederek ve revize ederek, projeyi daha derinden anlamak ve daha iyi karar vermek için nicel veriler elde edersiniz. Verilerin toplanması, analiz edilmesi ve derslerin çıkarılması biraz zaman alabilirken, proje uygulama süreçlerini iyileştirecek ve optimize edecek ve böylece gelecekte kaynak tasarrufu sağlayacaktır.

6 Sigma, birçok yeni ve karmaşık operasyon içeren zorlu projeler için uygundur. Bu yaklaşım, proje öğelerini uygulamanıza, hatalardan ders çıkarmanıza ve gelecekte kaliteyi artırmanıza olanak tanır.

6 Sigma'nın Zayıf Yönleri

6 Sigma ile ilgili sorun, beyan edilen ana hedefin maliyetleri azaltmak ve verimliliği artırmak olmasına rağmen, müşteri memnuniyetinin genellikle ön planda tutulmasıdır. Bir projenin farklı aşamalarında hedeflerdeki bazı farklılıklar göz önüne alındığında, ekipler genellikle öncelikler konusunda kafa karışıklığına sahiptir ve bundan kaçınmak kolay değildir.

Ayrıca 6 Sigma'nın ana teması: “Her zaman daha iyi hale getirebilirsiniz”. Bu, yaptıkları işten memnun olmayan çalışanları motive edebilir. Ayrıca proje bir defaya mahsus ise ve şirket gelecekte benzer projeleri hayata geçirmeyi planlamıyorsa, tüm analiz ve derslerden öğrenme maliyetleri boşuna olabilir.

PRENS2

NASA, proje yönetiminin geliştirilmesine katkıda bulunan tek devlet kurumu değildir. İngiliz hükümeti proje yönetiminin etkinliğini uzun zamandır takdir ediyor ve 1989'da İngiliz PRINCE2 metodolojisi oluşturuldu. Adı kısaltmadan geliyor " halkla ilişkiler nesneler İÇİNDE C kontrol edilen E ortam sürümü 2 ", "Kontrollü bir ortamda projeler sürüm 2" olarak tercüme edilir. Çevik yöntemlerden farklı olarak, PRINCE2 projeye yinelemeli bir yaklaşım getirmez. Diğer ürünlerle karşılaştırıldığında, PRINCE2, klasik proje yönetimi yaklaşımının bir melezi ve 6 Sigma'dan gelen kaliteye odaklanıyor.

PRINCE2 metodolojisi, örneğin PMBOK bilgi gövdesinden farklı olarak şunları içermez:

• Sektöre özgü gibi proje yönetiminin özel yönleri;
• Gantt şeması, WBS vb. gibi belirli proje yönetimi uygulamaları ve araçları.

PRINCE2, 7 ilke, 7 süreç ve 7 proje temasıyla ifade edilen projenin yönetim yönlerine odaklanır.

• 7 ilke tanımlar Genel kurallar PRINCE2'ye göre proje yönetimi, metodolojinin temelini tanımlar;
• 7 süreç, proje döngüsünü hareket ettirmek için adımları tanımlar;
• 7 konu - projenin başarısına ulaşmak için kontrolün gerçekleştirildiği yönler.

Projenin başında PRINCE2 bizi projenin 3 ana yönünü tanımlamaya davet ediyor:

• İş yönü (Bu proje fayda sağlayacak mı?)
• Tüketici yönü (Hangi ürüne ihtiyaç var, ne yapacağız?)
• Kaynak yönü (Hedefe ulaşmak için her şeye yeterince sahip miyiz?)

PRINCE2, çoğu proje yönetimi yaklaşımından daha net tanımlanmış bir proje ekibi yapısına sahiptir. Bunun nedeni, PRINCE2'nin büyük ölçekli hükümet projelerine odaklanması ve büyük organizasyonlar.

PRINCE2'ye göre, her ekip üyesinin 7 sürecin her birinde ayrı bir rolü vardır:

• Proje başlangıcı (BaşlangıçNS yukarıa proje): Bu süreçte bir proje yöneticisi atanır ve Genel Gereksinimlerürünün özelliklerine göre. Birincil sorumluluğu ayrıntılara dikkat etmek olan Proje Yöneticisi, genel proje yönetiminden sorumlu olan Proje Yönlendirme Komitesine rapor verir. Projenin yoldan çıkmamasını sağlayan Yönlendirme Komitesi'dir ve projenin başarısından da tamamen sorumludur.
• Projenin başlatılmasıa proje): Bu süreçte proje yöneticisi, proje planını aşama aşama içeren Proje Başlangıç ​​Belgelerini hazırlar. Aşamalar farklı süreler boyunca sürebilir, ancak klasik yaklaşımda olduğu gibi, birbiri ardına kesinlikle takip ederler.
• Proje yönetimi (Yönng a proje): Bu süreç, proje yöneticisinin yetki alanına giren ayrıntılara girmeden, Yönlendirme Komitesinin projenin başarısı için genel sorumluluğa sahip olması için bir fırsat sağlar.
• Sahne kontrolü (Kontrolling a sahne): Projenin uygulanması sırasında ideal koşullarda dahi bazı değişiklikler yapılacaktır. Aşama Kontrolü süreci, PRINCE2 ilkelerinden birini - istisnalarla kontrol ilkesini - uygular. Proje yöneticisinin sorumluluğu, aşamanın uygulanması sırasında projenin planlanan parametrelerinden zaman, içerik, bütçe vb. durumdan çıkış yolları açısından sapmaları izlemektir.
• Ürün oluşturma yönetimi (yönetme Ürün Teslimat):Ürün Oluşturma Yönetimi süreci, proje ürünlerinden birini oluşturmak için proje yöneticisi ve ekip yöneticisi arasındaki etkileşimdir. Proje yöneticisinin bu süreçteki sorumlulukları arasında ekip yöneticisine ürün oluşturma yetkisinin devredilmesi ve oluşturulan ürünün kabul edilmesi yer alır.
• Aşama Sınır Yönetimi (YönetmeNS a sahne sınır): Bu süreçte proje yöneticisi, geçilen aşamanın ilerlemesini değerlendirmek ve bir sonraki aşamaya geçişe karar vermek için ihtiyaç duyduğu tüm bilgileri Yönlendirme Komitesine sağlar.
• projeyi kapatmaka proje): PRINCE2 arasındaki farklardan biri, bir projeyi tamamlama sürecinin klasik yaklaşımda olduğu gibi ayrı bir aşamaya veya aşamaya ayrılmaması, ancak bir ürün yaratmanın son aşamasının bir parçası olarak gerçekleştirilmesidir. Sürecin amacı, proje ürününün kabul edildiğini veya projenin artık değerli bir şey sağlayamayacağını teyit etmektir.

PRINCE2, her büyüklükteki ve her konu alanındaki projelere uyarlanabilir. Metodoloji, projenin ihtiyaçlarına göre proje yaşam döngüsünü, rol modelini ve gerekli dokümanları değiştirmek için özel öneriler sunar.

PRINCE2'nin Güçlü Yönleri

• Kuruluşun özelliklerine uyarlanabilirlik;
• Rol ve sorumlulukların net bir tanımına sahip olmak;
• Projenin ürünlerine vurgu;
• Belirli yönetim seviyeleri;
• Ekonomik canlılığa odaklanmak;
• Tasarım çalışmasının sırası;
• Deneyimi yakalamaya ve sürekli iyileştirmeye vurgu.

PRINCE2'nin zayıf yönleri

• Endüstri uygulamalarının eksikliği;
• Proje üzerinde çalışmak için özel araçların eksikliği.

En iyi proje yönetim sistemi... sizin için!

Proje yönetimi bir bilimdir, ancak bilim en doğru olanı değildir. Bu alanda sarsılmaz temeller ve evrensel çözümler yoktur. Projeniz için mükemmel bir şekilde çalışan bir yöntem bulabilirseniz, kendinizi şanslı sayın, çünkü daha az şanslı liderlerin çoğu kendi proje yönetim sistemlerini oluşturmak ve özelleştirmek için çaba sarf etmek zorundadır. Bu sistemler, mevcut sistemlerin unsurlarından oluşabileceği gibi, Apollo görevinde olduğu gibi tamamen sıfırdan da oluşturulabilir. Ana şey, size en azından bir yapı kazandıracak ve projeniz için neyin önemli olduğunu unutmayacak bir şey kullanmaktır.

Agile'da uluslararası sertifika nasıl alınır?

Çevik hakkında sistematik bir anlayış kazanmak, projelere ve ürünlere çevik bir yaklaşımın avantaj ve dezavantajlarını anlamak, Çevik'in en iyi kullanım alanlarını bulmak ve uluslararası bir ICAgile Sertifikalı Profesyonel elde etmek isteyenler için - eğitimimiz

Bir felsefe örneği Atik herhangi bir astının konveyörü durdurabileceği ve ayarlamalar yapabileceği ünlü Toyota fabrikasının çalışma prensibidir. ()

Birçoğu, bu proje uygulama yöntemini tek doğru yöntem olarak görüyor. Böyle bir beyanın temeli, her bir katılımcının genel sürece katılımıdır. Proje ekibinin bir üyesi herhangi bir zamanda bir teklifte bulunma veya projede değişiklik yapma hakkına sahiptir.

Çoğu zaman, bir ürün yaratırken, projenin belirli aşamalarından sorumlu kişiler birbirleriyle çatışır. Bir sorun bulunursa, geliştiriciler diğer ekip üyelerini suçlar.

Yenilikçi bir Çevik metodoloji, her zamanki sorumluluklarını sürdürürken dahil olan herkesin katılımını sağlar. Yaklaşım, herkesi müşteriyi memnun eden bir ürün şeklinde bir sonuca ulaşmaya odaklar.

Bu metodoloji, tüm şirketin iş kültürünü değiştirme, ekibi bir araya getirme ve daha sonra piyasada etkili hale gelme yeteneğine sahiptir.

Çevik'in karakteristik özellikleri arasında olası risklerin farklılaşması, bağımsız organizasyon, öngörülebilirlik, dönüşümlere hızlı yanıtlar ve istikrarlı etkileşim (geri bildirim) yer alır.

Bugün, bir müşteri ile çalışma ilişkisi kurmak için oldukça yaygın olarak kullanılan iki yöntem vardır - sabit fiyatlı sözleşmeler ve zaman ve malzemeler. Sabit bir fiyat anlaşması, sorumluluğu şu şekilde değiştirir: olası riskler karşı tarafta, ikincisi, gerçekleştirilen hizmetler için müşteri tarafından nihai sonucu olumsuz yönde etkileyebilecek ödeme yapılmasını sağlar.

Öngörülebilirlik geçersiz kılar Uzun vadeli planlama, net teslim tarihleri ​​ve belirlenmiş bir nihai fiyat. Çevik yöntem, görevlerin belirli bir miktarda kara kutu biçiminde tanımlanmasını gerektirir. giriş bilgisi ve elde edilen sonucun gösterilmesi için ayrılan süre. Sürecin başında katılımcılar ödevi değerlendirir ve sonucun sorumluluğunu alır.

Geri bildirim, müşterinin görevi doğru formüle edememesiyle ilgili büyük bir soruna sahiptir. İyi belgelenmiş bir plan bile aylarca süren geliştirmelerden sonra alakasız hale gelebilir. İlk konseptin yeniden yapılandırılması, muhtemelen uzun revizyonları ve sonuçların yeniden işlenmesini gerektirecektir.

Metodoloji, plana göre çalışmanın ilk aşamasından sonra bile, ürünün, projenin başlangıç ​​çizgisinden başlayarak müşterinin yorum yapmasına ve ayarlamalar yapmasına izin verecek beyan edilen işlevselliğe sahip olmayacağını belirtir. Geliştirmenin iki aşamasından geçtikten sonra, geri bildirim almak için ürünün test sürümünü başlatabilirsiniz. Buradaki ek bir özellik, işlevsel değişikliklere neredeyse anında yanıt verilmesidir.

Kendi kendine organizasyon, gereksiz yönetim yapısını ortadan kaldırmaya yardımcı olur, her biri belirli bir sorumluluk alan ekip üyelerini kontrol etme ihtiyacının olmaması. Bu, performans garantisi ve yüksek kaliteli bir ürün olacaktır. Ancak, çoğu hata yapar.

çevik tarih

1970 yılında, Dr. Winston Royce "büyük yazılım sistemlerinin gelişimini yönetmek" için metodolojiyi tanıttı. O zamandan beri Çevik kavramı ortaya çıktı. Proje yönetiminin oluşumunun tam tarihi şurada açıklanmıştır:

Scrum yöntemiyle ilgili bir şey

Çevik Geliştirmenin Faydaları

• Sonuçların kalitesini iyileştirmek
• Değişime uyum sağlamak
• Çok hızlı ve verimli
• Daha kontrollü bir proje programı

Temel Çevik İlkeler

1. Kullanıcı katılımı kritik öneme sahiptir;
2. Karar vermek için ekipler son derece etkili olmalıdır;
3. Temel olarak aşamalar ve döngüler;
4. Ara proje sonuçlarının sık sık sunulmasına odaklanır;
5. 80/20 çalışma kuralı geçerlidir;
6. Planı uygulamak için işbirlikçi bir yaklaşım kullanmak;
7. Bir sonrakine geçmek için ayrı bir aşamanın tamamlanması.

Ayrıca Agile metodolojisinin 12 temel ilkesini ayrı bir infografikte ortaya çıkardık. Görebilirsin

Yöntem özellikleri:

• yinelemeli
• modüler
• Artan
• uyarlanabilir
• Çevik proje yönetiminin uygulanmasındaki hatalar makalede açıklanmıştır.

Neden Çevik Kullanılır?

• Nakit akışında artış
• Risk kontrolü
• Azaltılmış zaman ve ek yük
• Hesap Verebilirliği Artırın Geliştirme için Agile'ın nasıl kullanılacağına ilişkin makaleyi okuyun.

Hangi proje yönetimi metodolojisi size uygun?

Çoğu zaman, bir projenin başarısının sırrı, doğru proje yönetimi metodolojisinde yatar.

Kalite uygulaması için etkili bir yönetim sistemi seçmek, herhangi bir proje için kritik öneme sahiptir.

Ancak şelale ve Çevik planlama yöntemleri arasında bir seçeneğiniz olduğunda, projeniz ve ekibiniz için hangisinin en iyi olduğunu nasıl bileceksiniz.

Karar vermenize yardımcı olmak için, her yöntem için bir artı ve eksiler listesi derledik.

Şelale proje yönetimi metodolojisi

Bir şelale metodolojisi, bir projenin başlangıcında ayrıntılı planlama gerektirir

Tüm aşamalar bilinir ve aralarında mantıksal bağımlılıklar kurulur ve bir sonraki adıma ancak bir öncekini tamamladıktan sonra geçersiniz.

Şelale proje yönetimi yönteminin faydaları

• Fiziksel nesnelerle ilgilenen projeler için en iyisi - inşaat projelerinden ekipman kurulum projelerine
• Gereksinimler projenin başında açıklanmıştır
• Belirli bir sırayla tamamlanması gereken iyi tanımlanmış görevler ve kilometre taşları olan projeler için en iyisi (örneğin, bir binanın birinci katını ikinci katına inşa etmek)
• Geliştirme sürecinde müşteri katılımı gerekmez
• Proje programları gelecekte aynı veya benzer projeler için kullanılabilir
• Gereksinimlerin tam kapsamı önceden bilinir
• TK'de tanımlanan sonuçlar, kusur olasılığını azaltır

Klasik proje yönetimi metodolojisinin dezavantajları

• Çalışmaya başlamadan önce yüksek kaliteli proje planlaması ve çizelgeleme için önemli işçilik maliyetleri gerektirir
• Müşteri, çalışmanın sonuçlarını yalnızca projenin sonunda görür ve memnun kalmayabilir.
• Proje kapsamı değişiklikleri uzun olabilir ve resmi değişiklik yönetimi gerektirebilir
• Müşteri, projenin vizyonuyla en başında sorunlar yaşayabilir.
• Geç TOR değişiklikleri bütçe aşımlarına neden olur
• Şartnamede yapılan geç değişiklikler proje uygulama zaman çizelgesini uzatır
• Yöntem, hizmet sektöründeki projeler, yazılım, tasarım ve fiziksel nesneleri olmayan diğer projeler için daha az etkilidir.

Çevik - proje yönetimi metodolojisi

Çevik, işbirliği, uyarlanabilirlik ve sürekli iyileştirme ilkelerine dayalı proje yönetimine hızlı ve esnek bir yaklaşımdır.

Şelale planlama yönteminin sıralanmasının aksine, Çevik ilkeler hızlı, yinelemeli ürün serbest bırakma döngülerinde uygulanma eğilimindedir.

Çevik Proje Yönetim Metodolojisinin Faydaları

• Kodlama, metin yazarlığı veya tasarım gibi hizmet odaklı ve fiziksel olmayan çıktılarla ilgilenen projeler için en iyi metodoloji
• Proje, her aşamada müşteri için şeffaf ve anlaşılırdır.
• Hızlı bir başlangıç ​​için harika
• Paydaş geri bildirimlerine dayalı hızlı kurs ayarlamaları sağlar
• Öncelikler müşteri yararına odaklanır
• Proje, ekibe yaratıcı ve etkili bir şekilde çalışma özgürlüğü verir.
• Müşterinin projeye dahil olması, geliştirmenin odağını verir.
• Proje ekibinin tüm üyeleriyle etkileşim ve işbirliğini içerir

Çevik Proje Yönetimi Metodolojisinin Dezavantajları

• Ekip her zaman projeye dahil olur
• Açıkça tanımlanmış gereksinimleri ve hacimleri olan projeler için uygun değildir
• İşin kapsamı ve zamanlamasındaki belirsizlik, müşterileri ve yönetimi tedirgin edebilir (başlangıçta)
• Müşterinin projeye dahil olmak için zamanı olmayabilir
• Ekip görevlerini yönetmek için işin sürekli izlenmesini ve belgelerin bakımını gerektirir
• Müşteri işin kapsamını revize edebilir
• Hızlı başlatma, eksik görevlere neden olabilir

Seçeceğiniz proje yönetimi yöntemi projeye, ekibe ve hedeflere göre değişiklik gösterecektir. Bir yönetim stili seçtikten sonra, sizin ve ekibinizin projeyi istediğiniz şekilde özelleştirmenize olanak tanıyan proje yönetimi yazılımını kullandığınızdan emin olun.

Projelerinizde iyi şanslar!

Çevik ve Akış Metodolojisini Birleştirme

Proje uygulamasının başarısı, büyük ölçüde seçilen metodolojiye ve proje yöneticisinin eğitim düzeyine bağlıdır. Yazılım geliştirmeye metodik bir yaklaşım, süreçteki karışıklığı azaltır ve bu nedenle sonuçta daha kısa geliştirme süreleri sağlar ve en iyi kalite.

Projeler genellikle çevik ve şelale ürün geliştirme yaşam döngüsü modelleri, küçük kilometre taşları geliştirmek için çevik metodoloji ve tüm proje için akıcı metodolojinin bir kombinasyonunu kullanır.

Hizmet teslim süreci

1. Problemi tanımlama
geliştirici şirket müşterinin çözmeye çalıştığı sorunu olabildiğince doğru bir şekilde anlamalı ve tanımlamalıdır. Büyük ölçüde, sorunu doğru tanımlamak çözümün yarısıdır.

2. Çözümün belirlenmesi
Birkaç olası çözüm üzerinde düşünmek ve müşteriye önermek gerekir. İş sorunlarını en iyi çözen ve maksimum fayda sağlayan bir teklife karar verin.

3. Piyasa kontrolü
Önerilen çözümün rekabetçi ortam tanımı, endüstri trendleri ve hedef müşteriler gibi pazarlama araçlarını kullanarak doğrulaması gerekmektedir. Bu, müşteriye önerilen çözümü makul bir şekilde doğrulamak ve güçlendirmek için yapılır.

Bu isteğe bağlı bir adımdır, üçüncü taraf pazarlama araştırması şirketlerini dahil edebilir, müşterinin orijinal uzman verilerini (varsa) kullanabilir veya kavramı kanıtlamak için yeterli açık verileri izleyebilirsiniz. Sürekli bir proje akışıyla kendi analist departmanınızı oluşturabilir ve bunu ayrı bir hizmet olarak sunabilirsiniz.

4. Çözüm geliştirme
Geliştirme ekibi çözüm üzerinde çalışmaya başlar.

Çevik geliştirme metodolojisi (çevik yapı)

Karmaşık yazılım geliştirme projelerinin yönetimi şunları içerir: verimli kullanım kaynaklar, görevlerin önceliklendirilmesi, doğru zamanlama ve risk yönetimi. Çevik metodoloji, riskleri azaltmak ve müşteri faydasını artırmak için kullanılır.

Çevik metodolojiyi kullanarak, ekibin faaliyetlerinin çeşitli yönleri birbiriyle birleştirilir, bu, tüm konseptin doğru tanımlanmış hedeflere dayanmasını ve yaklaşımların ve çalışma yöntemlerinin sürekli olarak iyileştirilmesini sağlar. Metodoloji, tüm geliştirme sürecini, geliştirilen tüm bileşenlerin sürekli entegrasyonu ile küçük adımlara ve yinelemelere böler. Özellikler, sıralı tasarım ve periyodik gözden geçirme döngüsü, gereksinimlerin açıklığa kavuşturulması ve nihai ürünün geliştirilmesini içerir. Çevik ayrıca, yaşam döngüsünün sonraki aşamalarında herhangi bir sürprizden kaçınmak için müşteri geri bildirimi alırken sürekli iyileştirme sağlar.

Birleşik metodolojinin benzersizliği:

Çevik metodolojinin her adımda kullanılması, hem müşteri hem de yüklenici için fon ve kaynaklarda tasarruf sağlar.

Büyük bir proje için şelale modelinin kullanılması, genel sonuçlar üzerinde kontrole yol açar.

Müşteri ve geliştirme ekibi arasında hızlı geri bildirim sağlamak.

Hızlı ve sık prototipleme.

Müşteri odaklı yaklaşım - toplam sahip olma maliyetini (TCO) en aza indirmeye ve yatırım getirisini (ROI) en üst düzeye çıkarmaya odaklanın.

"Şelale" hakkında, sıradaki Çevik: birçok programcı ekibinin çalışmalarını düzenlediği bu şema ile tanışalım.

Şubat 2001'de, on yedi kişi - büyük BT uzmanları ve geliştiricileri - Utah'taki bir dağ beldesinde toplandı. Biraz dinlendik, konuştuk ve küçük bir belge hazırladık - Çevik manifesto.

Yazılımın geliştirilmesine öncülük etti ve programlamaya yönelik bir dizi pratik yaklaşımın temelini attı. Klasik metodoloji "Şelale" yer açmak zorunda kaldı.

Her şeyde esneklik

Çevik, İngilizce'den "çevik, hızlı, çevik" olarak çevrilir. Ancak Rusça BT sözlüğünde bu metodoloji grubu “esnek” olarak tanımlanır. Çevik yaklaşım, projeyi sürekli olarak yeni koşullara ve gereksinimlere uyarlayarak programlamayı dinamik olarak düzenler.

Detaylara girmeden, Şelale metodolojisine göre geliştirmenin nasıl çalıştığını hatırlayalım:

1. Yazılım gereksinimleri ortaya kondu, teknik bir atama (TOR) geliştiriliyor.
2. Atanan görevler kodda somutlaştırılmıştır.
3. Test devam ediyor.
4. Bitmiş yazılım uygulanıyor.

Teorik olarak, Şelale'de önceki aşamalara dönmek mümkündür - örneğin, belirli bir görevin teknik nedenlerle tamamlanamayacağı ortaya çıkarsa. Bu durumda, TK revize ediliyor, ancak bu daha çok acil bir durum. Normalde nihai ürün, geliştirme öncesinde formüle edilen gereksinimleri, amaçları ve hedefleri ideal olarak karşılamalıdır.

Çevik metodolojide öncelik, ilk ayar değil, kullanıcının gerçek ihtiyaçlarıdır. Agile'ın geliştirmenin ortasında bile teknik özelliklerde sürekli değişiklik yapması normaldir. Çevik bir metodoloji, bir ön ana plan sağlamaz - aksine, yazılım ürünü neredeyse doğaçlama yazılır.

Geliştirme bir dizi döngüden geçer - yinelemeler. Her yineleme aslında programın bir parçasının geliştirildiği, işlevselliğin iyileştirildiği ve yeni özelliklerin eklendiği ayrı bir projedir.

Bunun nasıl çalıştığını anlamak için, bir ses çalar oluşturan geliştiricilerden oluşan bir ekip hayal edelim. Program kodunun omurgası zaten yazılmıştır: arayüz ve temel işlevsellik. Program MP3, WAV ve OGG dosyalarını çalabilir. Ancak kullanıcılar, oynatıcıyı hızlı bir şekilde kontrol etmek için CD oynatma ve kısayol tuşları eklemeyi önerir.

Yeni bir geliştirme yinelemesi başlar. Meslektaşlar-programcılar kısa bir toplantı için toplanırlar: görevleri tartışırlar, dağıtırlar ve çözümler geliştirirler. Bir geliştirici, çevrimiçi radyo oynatma eklemeyi önerir.

Bir sonraki aşama - geliştirme - birkaç günden haftalara kadar sürebilir. Program kodu oluşturulur, ürüne entegre edilir, test yapılır. Yeni işlevsellik tamamen çalışmaya hazır olduğunda, programın sonraki sürümü derlenir ve yürütülebilir dosya kullanıcılara gönderilir.

Burası yinelemenin bittiği ve yeni bir geliştirme turunun başladığı yerdir.

Fikirler ve ilkeler

Çevik, geliştirmeye yönelik birleşik bir yaklaşım değil, somut pratik çözümlerin dayandığı bir dizi fikir ve ilkedir. Bu, bir vektör oluşturan ve eylemleri öngörmeyen özel bir felsefe olarak kabul edilebilir. Bu fikirler ve ilkeler ilk olarak Çevik Manifesto'da dile getirildi.

Çevik Manifesto'nun Dört Temel Fikri

• İnsanlar ve etkileşimler, süreçlerden ve araçlardan daha önemlidir.
• Çalışan yazılım, kapsamlı dokümantasyondan daha önemlidir.
• Müşteri ile işbirliği, sözleşme şartları üzerinde anlaşmaktan daha önemlidir.
• Değişime hazır olmak, orijinal planı takip etmekten daha önemlidir.

12 Çevik İlke

1. En yüksek öncelik, müşteriye yazılım sağlayarak ihtiyaçlarını düzenli ve mümkün olan en kısa sürede karşılamaktır.
2. Gereksinimlerin geliştirmenin herhangi bir aşamasında değişebileceğini göz önünde bulundurun. Projede hızlı değişiklikler yapılırsa, müşteri rekabet avantajı elde edebilir.
3. Bitmiş programın sürümlerini mümkün olduğunca sık yayınlayın - iki haftadan iki aya kadar aralıklarla.
4. Geliştiriciler ve müşteriler için bir proje üzerinde günlük olarak birlikte çalışın.
5. İşi motive olmuş profesyonellere emanet edin. Destek ve koşullar sağlayın, onlara güvenin - ve iş yapılacaktır.
6. Doğrudan iletişim, ekip içinde ve dışında etkileşim kurmanın en etkili yoludur.
7. Çalışan bir ürünü ilerlemenin ana göstergesi olarak düşünün.
8. Sabit bir çalışma ritmini sürdürmek - hem geliştiriciler hem de müşteriler için geçerlidir.
9. Teknik mükemmelliğe ve tasarım kalitesine çok dikkat edin - bu, proje esnekliğini artırır.
10. Gereksiz işleri en aza indirin.
11. Kendi kendini organize eden bir ekip için çaba gösterin - en etkili ve kaliteli çözümler içinde doğar.
12. Tüm ekip üyeleri sürekli olarak performanslarını iyileştirmenin yollarını ararlar.

Ancak yalnızca bu fikirler ve ilkeler tarafından yönlendirilen iş süreçleri oluşturmak imkansızdır. Bu nedenle, Agile'ın bir dizi uygulamalı metodolojinin olduğu bir sınıf olduğu genel olarak kabul edilir.

Scrum

Scrum, Çevik manifesto oluşturulmadan önce ortaya çıktı. Ancak ilkeleri, çevik metodoloji kavramına çok uygundur, bu nedenle onu bu ailenin bir parçası olarak sınıflandırmak gelenekseldir.

Terim ilk olarak 1986'da duyuldu. Japon araştırmacılar Ikujiro Nonaka ve Hirotaka Takeuchi, Yeni Yeni ürün geliştirme oyunu makalesinde, yeni bir ürünün daha hızlı oluşturulmasını sağlayan ilkeleri formüle etti. Böyle bir gelişmenin koşulları arasında, kendi kendini organize eden bir uzman ekibini, yaratıcılık ve çalışmadaki tam özgürlüklerini - üst yönetimin kısıtlamaları olmaksızın - seçtiler. Yazarlar bu yaklaşımı şu şekilde tanımladılar:

“Bu, tüm çalışanları ikinci katta bırakıp merdivenleri kaldırıp ardından atla ya da ne yaparsan yap - karar senindir demeye benziyor. Aşırı koşullar yaratıcılığı doğurur!"

Yönetim ekip için bir görev belirler ve muhtemelen şartları iletir, ancak belirli talimatlar vermez - çalışma grubu bağımsız olarak bir çözüm arar.

Scrum yaklaşımı için ana şey, takımın sürekli olarak ürünü nasıl daha iyi hale getireceğini tartıştığı işin özel dinamikleridir. Yazarlar bu ritmi ragbi ile karşılaştırıyorlar: oyuncular topu birbirlerine pas veriyor, ancak takım bir bütün olarak sahada hareket ederek ortak bir hedefe ulaşıyor. "Scrum" terimi ragbiden geldi - top için bir kavga.

Nonaka ve Takeuchi tarafından önerilen teknik, BT alanında, makine mühendisliğinde, elektronikte mühendislik çözümlerinin geliştirilmesinde uygulama bulmuştur. 90'larda Scrum, bir takımın çalışmasını sıfırdan oluşturmaya yardımcı olan belirli tekniklerle büyümüş, iyi geliştirilmiş ve bütünsel bir metodoloji olarak şekillendi. Ken Schwaber ve Jeff Sutherland sayesinde Scrum BT'ye geldi ve geliştiriciler arasında popülerlik kazandı - hatta bazıları bu metodolojiyi devrim niteliğinde görüyor.

Takım ruhu

Bir Scrum takımının dahili hiyerarşisi yoktur: yönetici yok, ast yok, direktif yok. İki özel grup üyesi vardır: ürün sahibi, ürün sahibidir ve scrum yöneticisi, scrum yöneticisidir.

Bir ürünün ne olması gerektiğini en iyi ürün sahibi bilir. Bu genellikle müşteri, temsilcisi veya müşteriyle etkileşimden sorumlu bir çalışandır. Programın son kullanıcısı tarafından tam olarak neyin gerekli olduğunu açıkça anlamalıdır. Ürünün işlevselliği ve görünümü için tüm istek ve öneriler (Scrum'da bunlara hikaye denir), özel bir listeye girer - Ürün İş Listesi. Biriktirme listesi, geliştirme başlamadan önce oluşturulur ve yol boyunca sürekli olarak güncellenir. İyileştirmelerin öncelikleri de burada belirtilmiştir.

Scrum Master, ekibin uyumlu çalışmasından sorumludur. O bir takım lideri değildir, ancak gelişimin sabit bir hızda devam etmesi için elinden gelenin en iyisini yapar, her katılımcı dahil olur ve motive olur ve önemli ayrıntılar gözden kaçırılmaz.

Sarsmak! Başka bir pislik!

Genel olarak Agile'da olduğu gibi Scrum'da bir program üzerinde çalışmak yinelemelere bölünmüştür. Spor terminolojisini severler: bu gelişim bölümlerine yarışlar veya sprintler denir. Her biri, bu sprintte ürün sahibi listesinden hangi hikayeleri uygulayabileceklerini belirlemek için ekibin birlikte çalışmasıyla başlar. Seçilen fikirler ayrı bir listeye aktarılır - sprint biriktirme listesi. Hedef sabittir: sonunda takımın kullanıcıya tam olarak ne gösterebileceği. Görevler belirlenir ve yarış başlar.

Bir ragbi maçında olduğu gibi, Scrum geliştirmedeki durum hızla değişir: kullanıcı fikrini değiştirebilir veya gereksinimleri değiştirebilir ve Agile onun isteklerine karşı duyarlıdır. Bu nedenle, Scrum Master kısa günlük toplantılar toplar - Scrum. Her katılımcı başarıları ve başarısızlıkları hakkında konuşur, geri kalanı sorunları çözmek için yeni yollar sunabilir. Görevler ayarlanıyor, sprint devam ediyor.

Yarış sonunda sonuçlar ürün sahibine gösterilir. Ve hemen yeni bir sürat koşusuna başlarlar - geliştirme döngüsünün başka bir yinelemesi.

Scrum yarışının bir sonucu olarak, kullanıcının programın hazır bir sürümünü aldığını hatırlamak önemlidir: başlayabilir ve çalışabilirsiniz. Bir projenin ilk aşamalarında, bir program yalnızca "Merhaba dünya!" mesajını görüntüleyebilir. Ancak ilk sürat koşusu bile bir sonuç vermeli: program zaten orada ve başlatılıyor.

XP - Son Derece Programlanabilir!

Bu, Windows XP ile ilgili değil. Bu kısaltma, Agile sınıfından başka bir metodolojiyi gizler: eXtreme Programming - aşırı programlama. Ward Cunningham, Martin Fowler ve diğerleri tarafından geliştirilen geliştirici Kent Beck tarafından icat edildi. İşleri etkili bir şekilde yapmanıza yardımcı olan bir dizi basit ilke ve uygulamadır.

Extreme Programming, geliştiricilerden bir pirana havuzunda otururken kod yazmasını veya bir dağdan aşağı yuvarlanırken hata ayıklamasını istemez. Metodolojinin yazarları, üretkenliklerini artırmak için geleneksel programlama tekniklerini yoğunlaştırır.

Klasik bir geliştiricinin nasıl çalıştığını hatırlayalım. Dikkatlice düşünür, planlar ve ardından bir program parçası yazar - çalışan bir blok veya işlev. Test eder, hataları yakalar, düzeltir, kontrol eder ve tekrar düzeltir ... Ardından, tamamlanmış kodu test için test uzmanlarına veya diğer programcılara gönderir. Değişiklikler biriktiğinde bir araya getirilir ve programın çalışan bir versiyonunu oluştururlar.

Aşırı programlamada, tüm bu ilkeler sınırlarına kadar zorlanır. Açıklamak için zaman yok - yapmalısın! Kısa bir süre için plan yaparlar. Geliştirme yinelemeleri mümkün olduğunca kısadır. Çalışan sürüm ne kadar erken çıkarsa o kadar iyi. En basit çözüm uygulanır ve kod paralel olarak yazılır ve test edilir.

Aşırı uygulamalar

Diğer Çevik metodolojilerde olduğu gibi, XP'de yinelemeler ne kadar kısa olursa o kadar iyidir. Revizyon bir günde tamamlanabiliyorsa, o zaman yapılmalıdır. Ancak kullanıcının çalışma programının sürümünü günlük olarak güncellemek istemesi pek olası değildir. XP'deki maksimum süre bir aydır. Yani ortalama yineleme iki hafta sürer.

Her döngünün başında geliştiriciler, Genel toplantı- müşteri temsilcisi de davetlidir. Hangi işlevin uygulanacağına birlikte karar verirler. Kullanıcı hikayeleri - yani görevler ve gereksinimler - önemleri dikkate alınarak esas alınır.

XP'de önemli bir koşul, mümkün olan en basit çalışma çözümünün ve verilen koşulları karşılayan yürütmelerinin uygulanmasıdır. Gereksiz hiçbir şey yaratılmaz: daha sonra ihtiyaç duyulabilecek, ancak şu anda ihtiyaç duyulmayan "gelecek için gadget'lar" yoktur. Sonraki aşamalarda, çözümün işlevselliği genişletilebilir ve geliştirilebilir, ancak geliştirici gerektiğinde bunu düşünecektir.

Bir risk var: İlk başta iyi çalışan ilkel bir teknik çözüm, program gelişmeye başladığında ve daha gelişmiş işlevsellik gerektiğinde bir sorun haline gelebilir. Bu, teknolojinin bir dezavantajı gibi görünebilir: XP, uzun vadeli plan yapmaktan hoşlanmaz, hareket halindeyken hızlı bir şekilde yeniden inşa etmeyi tercih eder. Ancak pratikte, çalışma kodunun sıfırdan yeniden yazılması gerektiğinde durumlar nadiren ortaya çıkar. Çevik ekiplerde çalışan deneyimli profesyoneller tarafından öngörülebilirler.

Başka bir aşırı programlama uygulaması olan yeniden düzenleme de bu tür soruları çözer. Buradaki amaç, kodu düzenli olarak gözden geçirmek ve geliştirmektir ve amaç, programı daha hızlı ve daha güvenilir hale getirmektir. Geliştiriciler yinelenen kod parçalarını kaldırır, basitleştirir ve tek tip proje standartlarına yol açar.

Bir başka iyi uygulama da sürekli ekip çalışmasıdır. XP, yakın işbirliği ve karşılıklı yardım anlamına gelir. Geliştirme, aktif olarak bilgi alışverişinde bulunan on kişilik gruplar halinde gerçekleştirilir. Çift programlama uygulanır: bir geliştirici bir modül oluşturur, ikincisi gözlemler.

Eşli programlama en iyi XP uygulamalarından biridir

Yaklaşım savurgan gibi görünebilir: Aslında, programcıların sanki herkes programın kendi parçası üzerinde çalışıyormuş gibi yarısı kadar kod yazacakları ortaya çıktı. Araştırmalar, eşli programlamanın tek bir kişi tarafından yapılan benzer geliştirmelerden %15 daha yavaş ilerlediğini gösteriyor.

Ama avantajları da var. Eksiklikler en erken aşamada, hatta modül ilk kez kullanıma sunulmadan önce ortadan kaldırılır. Bir ortak, yararlı bir numara önerebilir veya sorunu çözmek için daha basit ve daha ergonomik bir yol önerebilir - yani, yeniden düzenleme, kod oluşturulduktan hemen sonra gerçekleşir. Araştırmaya göre iki kişi ile çalışıldığında hatalar %60 oranında azalmaktadır. Ve kodun sürekliliği korunur - "sadece Vasya bu işlevin nasıl çalıştığını bildiği ve tatilde olduğu" bir durum olmayacak.

Temel olarak, kod ekibin ortak özelliğidir. Hiç kimse bir program modülünü tek başına bilemez veya sahip olamaz.

Bu nedenle, tek tip bir tasarım olan kodlamayı standart hale getirmek önemlidir: değişkenleri ve sınıfları adlandırmak için kuralları izleyin, aynı programlama tekniklerini kullanın.

XP, sürekli kod entegrasyonunu, yani yazılı ve hata ayıklanmış modüllerin düzenli ve sık değişimini gerektirir. Programın bölümleri birbirine bağımlı olabilir ve dahili uyumsuzluğu ortadan kaldırmak için tüm proje katılımcılarının modüllerin en güncel sürümlerine erişimi olmalıdır.

XP fazla çalışmayı teşvik etmez: programcıların 40 saatlik çalışma haftasına sıkı sıkıya bağlı kalmasını gerektirir. "Sadece bu işlevi ekleyeceğim" yok! Geçiş yapmayı ve dinlenmeyi bilmiyorsanız, kısa sürede verimli çalışamaz hale geleceksiniz.

Aşırı kötü anlamına gelmez

Aşırı programlama uygulamaları doğru bir şekilde uygulanırsa, bu teknik tüm çalışanların etkin etkileşimini, deneyim alışverişini ve profesyonel becerilerin istikrarlı büyümesini, yüksek verimliliği sağlar.

Ayrıca tuzaklar da vardır: XP uygulamaları belirli beceriler ve sağlam bir öz disiplin gerektirir. Eşli programlamada, hem geliştiricilerin katılımı hem de karşılıklı saygı önemlidir. Kişi kendini bir usta ve bir ortak olarak görürse - yeni başlayanlar, tavsiyeleri dinlemezse ve açıklamalara tenezzül etmezse, böyle bir işbirliğinden hiçbir fayda olmayacaktır. Kodu takip etmeyen ancak kendi işine devam eden ortak, eşli programlamaya da son verir. Uygulamanın özü birlikte çalışmaktır - klavyeyi geçmek, beyin fırtınası yapmak, fikir alışverişinde bulunmak.

Aşırı programlama, belirli bir durumda nasıl davranılacağını belirtmez. Sorunun çözümü herkes için açıksa ve kodu yazmak zor değilse, eşli programlamaya gerçekten gerek yoktur. Saat 18:00 ise ve eklenecek yirmi satır kodunuz kaldıysa yarına ertelemenize gerek yok. Metodoloji sağduyunun yerini tutmaz!

Sihir yok

Çevik, herhangi bir geliştirme problemini çözmek için inanılmaz başarılar ve mucizevi özellikler ile tanınır. Ama gerçekte onlar hakkında fantastik bir şey yok. Bunlar iyi araçlardır: doğru kullanılırlarsa iş akışlarını hızlı ve verimli hale getirebilirler ve ayrıca ekip üyelerini yaratıcı olmaya ve gelişmeye motive edebilirler.

Çevik metodolojiler, uzmanların profesyonelliğine, niteliklerine ve tutumuna yüksek talepler getirir. Ekibin uyumu, karşılıklı saygı ve deneyim alışverişi önemlidir. Aşırı uygulamalar, kötü bir programcıya zekice kodlamayı öğretmez, Scrum, çatışan bir uzmanın takıma katılmasına yardımcı olmaz.

Agile hakkında hiçbir şey bilmiyor olsanız da benzer bir şekilde çalıştığınızı söyleyebilirsiniz. Bir geliştiricinin küçük parçalar halinde kod yazması, zaman zaman meslektaşlarıyla kahve makinesinde görüş ve bilgi alışverişinde bulunmak için bir araya gelmesi doğaldır. Geliştirmeyi, hataları düzeltip özellikler eklediğiniz ve sonunda yeni bir sürümü kullanıma sunduğunuz yinelemelere bölmek mantıklıdır. Çevik metodolojilerin güzelliği budur: sezgiseldirler ve her programcıya yakındırlar.

Çevik Faydaları

1. Yazılım ürünü, tam işlevselliğe sahip olmasa da, geliştirme sürecinin ilk aşamalarında kullanıma hazırdır.
2. Geliştiriciler, müşteri ve kullanıcı ile sürekli iletişim halindedir ve programdan tam olarak ne istendiğini her zaman bilirler, ürün için yeni kullanıcı ihtiyaç ve isteklerine hızlı bir şekilde cevap verebilirler.
3. Katı bir çerçeve yoktur, bu nedenle yazılım ürünü sürekli değişir ve gelişir, kullanıcı için daha verimli ve daha çekici hale gelir.

Bu şemadaki müşteri ve kullanıcı, yatırımcılardan çok ortaklar ve ideolojik ilham vericiler olarak hareket eder. Ve bu haklı - programcı, kullanıcının tam olarak ne almak istediği konusunda her zaman net bir fikre sahip değildir. Ancak geliştirmeden uzak, programın yardımıyla elde edebileceği olanaklar, hangi süreçlerin otomatikleştirilebileceği ve hangi düzeyde olduğu hakkında hiçbir fikri yok. Çabaları birleştirerek ve iletişim kurarak, kullanıcı ve geliştirici, verimlilik ve ergonomi açısından analogları aşan bir ürün yaratabilir.

Avans ve detaylı formülasyon yoktur başvuru şartları- bu, geliştiricinin sorunu yaratıcı bir şekilde çözebileceği anlamına gelir. Ancak çok fazla değil - kullanıcı gerçeklikten uzaklaşmasına ve gereksiz kod üretmesine izin vermeyecek. Programın her bir parçası birlikte tartışılacak ve üzerinde düşünülecektir.

Gücün Karanlık Yüzü: Çevikliğin Dezavantajları

Programın asla tamamlanmayacağı bir gerçek değil.

Ciddi anlamda. Her yinelemeden sonra, hem geliştirici hem de kullanıcı, ürünü nasıl daha güçlü ve kullanışlı hale getirebileceği konusunda yeni fikirlere sahip olacaktır. Geliştirme, yıllar almakla tehdit ediyor.

Ancak müşteriyle uzun vadeli bir işbirliği planlıyorsanız ve müşteri tüm geliştirme süresi için ödeme yapmaya hazırsa - neden olmasın?

Kullanıcı her şeyi aynı anda talep eder.

Kullanıcı tarafındaki proje katılımcılarının çoğu, birçok program gereksinimini erkenden formüle edebilir ve bunların hepsinin gelecek iterasyonlarda uygulanmasını bekleyebilir. Gereksinimlerin önemli bir kısmı en yüksek önceliği alacak, bu nedenle geliştiricinin şimdi hangi görevlerin tamamlanacağını ve hangilerinin erteleneceğini belirlemesi gerekecek. Ve kullanıcılar mutsuz olacaklar: her şeyi aynı anda istiyorlar.

Bir proje üzerinde çalışmak, yalnızca geliştiricinin profesyonelliğini değil, aynı zamanda kullanıcının vicdanlılığını da gerektirir. Ve programcılara yeterli ve anlayışlı kullanıcılarla sık sık karşılaşıp karşılaşmadıklarını sorun.

"Altın Kullanıcılar"

Tartışmaya birkaç müşteri (kullanıcı) katılırsa, projeye katkıları genellikle farklı ölçeklerde olur. Biri daha dikkatli ve çok öneride bulunurken, diğeri sessizce oturuyor. Forumda geniş kapsamlı bir projenin tartışması bile yapılabilir.

Aslında bu, küçük bir grup aktivistin bizzat kendileri için ilginç bir yol izleyerek gelişmeyi izlemelerine, kendileri için bir program oluşturmalarına yol açacaktır. Diğer kullanıcıların görüşleri gölgede kalacak.

Plansız inşaat

Çevik eleştirmenlerin işaret ettiği bir diğer konu ise ana plân, program kavramı, tek tip yapı. Böyle bir yazılım ürününün kodu, çizim ve iletişim planı olmadan inşa edilmiş bir gökdelene benzeyebilir. Yeniliklerle ilgili kararlar kelimenin tam anlamıyla anında alınır, uzun vadeli planlama söz konusu değildir. Sonuç olarak, halihazırda uygulanmış kod parçalarının yeni işlevselliğin ima ettiği mimariye uymadığı ortaya çıktı. Son haline getirilmeleri ve "koltuk değnekleri" eklenmeleri, hatta değiştirilmeleri gerekir.

Her yeni yinelemede, "sahne" sayısı feci bir hızla artar ve programın iç yapısını mantıksız ve etkisiz hale getirir. Ve her aşamada test, yalnızca yeni oluşturulan veya değiştirilen işlevsellik için gerçekleştirilir. Yani kodu bir yerde sabitleyerek başka bir yerde bozmayacağınızı garanti edemezsiniz.

sürekli acele

Çevik çalışma ritmi meditasyona elverişli değildir. Yenilikler anında icat edilir, ayrıca hızlı bir şekilde uygulanmaları, anında tepki vermeleri ve hemen harekete geçmeleri gerekir. Tüm yönleri düşünmek için zaman yok, artıları ve eksileri yavaşça tartın.

Bu, kodun kalitesini etkiler: program parçaları, onları daha zarif veya verimli hale getirmeye çalışmadan "ve öyle yapacak" ilkesine göre yazılır. Geliştirici, bu tür kodun yalnızca geçici bir çözüm olarak uygun olduğunu fark eder, ancak geri dönüp yeniden yazmak nadiren mümkündür. Çalışıyor - ve iyi.

Çalıştığı sürece...

Eleştirilere rağmen, yazılım ürünlerinin oluşturulmasında çevik geliştirme metodolojisi başarıyla kullanılmıştır.

Çevik kim içindir?

Çevik sınıf metodolojileri şu durumlarda işe yarar:

• Ekibiniz, birlikte çalışmayı ve birbirlerine yardım etmeyi bilen deneyimli ve kalifiye profesyonellerden oluşmaktadır.
• Müşteri, programın nasıl görünmesi gerektiği konusunda net bir fikre sahip değil ancak ürünü geliştirmek ve iyileştirmek için ortak çalışmalara katılmaya hazır.
• Ürünün kapsamı sürekli değişiyor, sıklıkla yeni ihtiyaçlar ve görevler ortaya çıkıyor.
• Ürünün tamamlanması için belirli bir son tarih ve katı bütçe kısıtlamaları yoktur.
• Mümkün olan en kısa sürede bir çalışma programı edinin.

Bu tür koşullar, örneğin bir başlangıçta çalışırken ortaya çıkabilir. Belirli bir alanda yenilik anlamına gelir ve çalışan bir ürün sunarak bir niş işgal etmek için zamana sahip olmak önemlidir. Aynı zamanda, projenin gelişeceği yön hakkında uzun vadeli tahminler de yok.

Metodolojilerin tanrısına daha fazla metodoloji!

Scrum ve XP'yi ele aldık, ancak Agile sınıfı başka metodolojileri de içeriyor. Şelale ve Çevik dışında ilginç yaklaşımlar var. Bir sonraki yazıda devam edelim.

12 prensipten oluşur. Tabii ki, Çevik yaklaşımın bazı hükümleri bundan önce ortaya çıktı, ancak yalnızca bu belge sistematikleştirdi ve kullanım için yeterli ölçüde belirledi. 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, iş döngüsünün sonunda kodun teslim edildiği şelale modellerinin aksine, yazılımın bir projenin en başından itibaren aşamalı olarak oluşturulduğu yinelemeli bir geliştirme modelidir.

Agile'ın özü, projeleri kullanıcı hikayeleri adı verilen küçük iş parçalarına bölmektir. Önceliğe göre, görevler iki haftalık kısa döngüler (yinelemeler) çerçevesinde çözülür.

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

• Araçlar ve süreçler üzerinde insan ve iletişimin önceliği;
• Çalışan ürünün tüm belgelere göre önceliği;
• Müşterilerle işbirliğinin sözleşmenin onaylanmasından önceliği;
• Orijinal plana bağlı kalmak yerine değişme isteğine öncelik vermek.

Agile'da bulunan yöntemler:

"Scrum" terimi, adını, rakiplerin her biri tarafından üç çizgi çizerek ve topu ele geçirmeye çalışmak şeklinde bir takım oyunu yöntemi anlamına gelen rugby'ye borçludur. Başarılı müdahale sadece iyi bir fiziksel uygunluk değil, aynı zamanda her bir katılımcının maçtaki tutarlılığını ve hedefin net bir şekilde anlaşılmasını gerektirir.

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

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ı özetledi:

1. Lütfen seçin ürün sahibi- Projenin amacını ve beklenen sonucu bilir.
2. Toplamak emretmek- uygulanabilir bir ürün yaratmak için gerekli becerilere sahip 10 kişiye kadar.
3. Bulmak hücum ustaları- projenin ilerlemesini izler, proje ekibinin zorluklarla başa çıkmasına yardımcı olur.
4. Makyaj yapmak ürün birikimiÇevik panodaki her ürün gereksinimine öncelik verin. Ürün sahibi, biriktirme ekibi tarafından değerlendirilmek üzere ürün isteklerini toplayarak bunda önemli bir rol oynar.
5. Plan sprintler(yinelemeler) - belirli bir dizi görevi tamamlamak için geçen süre.
6. Düzenlemek günlük on beş dakikalık "mit-up"- her takıma 3 soru sorun: dün ne yaptınız, bugün ne olacak, görevi tamamlamanızı engelleyen nedir.
7. Yapmak ürün çalışma parçaları incelemeleri- gözden geçirme ve tartışmaya paydaşların katılımıyla.
8. Harcamak geriye dönük- sorunun tartışılması ve her sprintten sonra bir çözüm aranması. Ortaya çıkan değişiklik planını bir sonraki sprintte uygulayın.

Çevik Retrospektif

Scrum'ın 4 temel unsuru vardır:

• Ürün İş Listesi- proje gereksinimlerinin listesi
• Sprint İş Listesi- bir sonraki sprintte karşılanması gereken gereksinimlerin bir listesi
• Sprint Hedefi- sürat hedefi
• Sprint İş Bitim Tablosu- görevler tamamlandıkça güncellenen bir diyagram. Ekibin projedeki dinamiklerini ve ilerleme düzeyini anlamak kolaydır.

(XP)

Metodolojinin geliştiricisi Kent Beck, amacı bir yazılım ürünü için sürekli değişen gereksinimlerle başa çıkmak ve geliştirme kalitesini iyileştirmek olan aşırı bir programlama yöntemi yarattı.

Yalnızca yazılım geliştirme alanında uygulanabilir ve 4 süreç etrafında inşa edilmiştir:

1. kodlama- takımdaki üniforma tasarım standartlarına göre;
2. test yapmak- testler, test edilecek kodu yazmadan önce programcıların kendileri tarafından yazılır;
3. planlama- hem son yapı hem de bireysel yinelemeler. İkincisi, ortalama olarak iki haftada bir gerçekleşir.
4. işitme- Belirsizliklerin ortadan kalktığı, gereksinimlerin ve değerlerin belirlendiği hem geliştirici hem de müşteri.

metodolojiler

Proje yönetiminin yerel açık alanlarında çok az bilinen bir metodoloji ailesi, Çevik Yazılım Geliştirme Manifestosu'nun yazarlarından biri olan Alistair Cockburn tarafından geliştirilmiştir. Cockburn, takımdaki kişi sayısı kriterine göre renge göre sınıflandırma yapmayı önerir: 2'den (Crystal Clear) 100'e (Kristal Kırmızısı). Daha büyük projeler için Bordo, Mavi ve Menekşe renkleri vurgulanır.

Kristal projeler 3 ana göstergeyi karşılamalıdır:

1. çalışma kodunun hızlı teslimatı- yinelemeli bir Çevik geliştirme modeli fikrinin geliştirilmesi.
2. yansıma yoluyla mükemmellik- yeni yazılım sürümü, bir öncekiyle ilgili verilere dayalı olarak geliştirildi.
3. "Ozmotik" etkileşim- Alistair'in yeniliği, bir odada yazılım geliştiriciler arasında iletişim ve bilgi alışverişi için bir metafor.

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

DSDM'nin geliştirilmesinde tek bir kişi, hatta bir ekip değil, 17 İngiliz şirketinden oluşan bir konsorsiyum çalıştı. DSDM, aşırı programlama gibi, öncelikle yazılım geliştirme için kullanılır.

Son tüketicinin (kullanıcının) geliştirme sürecine katılımına özel bir rol verilir. Bu ilkeye ek olarak, temel olanlar şunları içerir:

• ürünün çalışan sürümlerinin sık sürümleri
• karar verme açısından geliştiricilerin özerkliği
• tüm çalışma döngüsü boyunca test.

DSDM, teknoloji geliştikçe güncellenen sürümlere bölünmüştür, yazılım geliştirme için yeni gereksinimler ortaya çıkar. Bugün için sonuncusu, 2007'de piyasaya sürülen DSDM Atern'dir, ancak önceki (2003) hala hizmettedir.

Başlangıçta ekip, uygulama geliştirmenin gerçekliğini ve uygulamanın kapsamını inceler. Ayrıca, iş birbiriyle ilişkili üç döngüye bölünmüştür:

1. fonksiyonel model döngüsü- analitik dokümantasyon ve prototiplerin oluşturulması.
2. tasarım ve yapım döngüsü- sistemi çalışır duruma getirmek.
3. uygulama döngüsü- sistem dağıtımı.

Özellik Odaklı Geliştirme (FDD)

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

FDD ayrıca yinelemeli bir geliştirme modeli kullansa da, aşağıdaki açılardan Çevik'ten farklıdır:

• ön modellemeye daha fazla vurgu
• bina raporları ve çizelgelerinin artan (Çevik ile karşılaştırıldığında) önemi
• kurumsal gelişime yöneliktir.

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

1. Genel bir model oluşturma- ön verilere dayalı proje vizyonu.
2. Bir özellik listesi tasarlama- Scrum yöntemindeki ürün biriktirme listesinin bir analogu.
3. Mülklere göre planlama- ekibin her bir üyesi tarafından özelliklerin karmaşıklığının tahmini.
4. Her mülk için- teknik tasarım ve uygulama - sonunda mülkün ü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, büyük olasılıkla bir metodoloji değil, geliştirme sürecinin verimliliğini artırmayı ve maliyetleri en aza indirmeyi amaçlayan bir dizi yalın üretim ilkesidir.

Set aşağıdaki 7 ilkeyi içerir:

1. kayıplardan kurtulmak- son tüketici için ürüne değer katmayan her şey.
2. devamlı öğrenme- ekibin sürekli gelişimi, görevleri etkin bir şekilde tamamlama yeteneğini artırır.
3. mümkün olduğunca geç karar vermek- öncelik spontane kararlar değil, kazanılan bilgiler temelinde geliştirilen düşünceli kararlar.
4. hızlı teslimat- temelde yinelemeli modelin temeli.
5. takım güçlendirme- "Manifesto..."nun ilkelerinden biri, insan ve etkileşimin süreç ve araçlardan daha önemli olduğunu belirtir. Proje ekibi, görevlerin başarıyla tamamlanmasının bel kemiğidir.
6. bütünlük ve kalite- daha fazla test etmek ve hatalardan kurtulmak için zaman ve kaynak kaybetmemek için başlangıçta yüksek kaliteli bir ürün yapmanız gerekir.
7. tüm resmin vizyonu- Geliştirilmekte olan yazılımın mevcut geliştirme durumunu, hedeflerini, konseptini ve stratejisini anlamadan projeyi ayrı bölümlere ayırmak imkansızdır.

Çeşitli çevik geliştirme metodolojileri

Çevik Modelleme (AM)

Çevik Modelleme, yazılım modelleme için bir dizi değer, ilke ve uygulamadır.

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

Çevik Modelleme ilkeleri aşağıdaki gibidir:

• proje paydaşları arasında etkili etkileşim
• tüm gereksinimlere uyan mümkün olan en basit çözümü geliştirmeye çalışmak
• sürekli geri bildirim
• Karar verme ve sorumluluk alma 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 beri Disiplinli Çevik Teslimat (DAD) ile değiştirildi, ancak bazı yerlerde AUP hala bulunuyor.

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

• Ekibiniz ne yaptığını biliyor;
• Sadelik önce gelir.
• Çevik 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 olarak özelleştirilmesi.

Çevik Veri Yöntemi (ADM)

ADM, bireysel ekiplerin işbirliği yoluyla gereksinimleri ve proje kararlarını şekillendirmeye odaklanan bir dizi yinelemeli çevik yazılım geliştirme metodolojisidir. AUP gibi, kendi kendine yeterli bir teknik değildir.

Çevik Veri Yönteminin özü altı nokta ile tanımlanır:

1. Veri- herhangi bir uygulama oluşturmanın temeli.
2. Proje ile ilgili sorunlar- sadece projenin amacı ve konseptinin net bir şekilde anlaşılmasıyla bulunabilirler.
3. Çalışma grupları- Doğrudan geliştirme ekibine ek olarak, diğer çalışma gruplarını destekleyen işletme grupları da vardır.
4. benzersizlik- ideal bir metodoloji yoktur, her proje için farklı metodolojilerden araçları birleştirmeniz gerekir.
5. Takım çalışması- ekip çalışması tek başına olmaktan çok daha etkilidir.
6. "Zayıf nokta"- aşırılıklardan kaçınarak soruna en uygun çözümü ("tatlı nokta") arayın.

Temel Birleştirilmiş Süreç (EssUP)

Rational Unified Process'i geliştirmek için tasarlanan İsveçli bilim adamı Ivar Jakobson tarafından geliştirildi.

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

• kullanım durumu - sistemin davranışının bir açıklaması.
• yinelemeli geliştirme - birkaç haftalık kısa döngülerde çalışan kod parçaları oluşturma.
• ekip uygulamaları - ekibi birleştirmeyi ve etkinliğini artırmayı amaçlar.
• “Büyük düşün, küçük başla” veya “Paydaşları iş süreçlerine dahil edin” gibi prosedürel uygulamalar.

Tüm uygulamalar RUP, CMMI ve Agile geliştirme metodolojilerinde şu veya bu şekilde bulunur.

Gerçekleşmek (GR)

Küçük projelerin ve şirketlerin özelliklerinden en iyi şekilde yararlanmayı teklif eden yeni başlayanlar ve acemi ekipler için etkili bir metodoloji: hareketlilik, esneklik, yeni çözümler arama, katı bir kafa karıştırıcı hiyerarşinin olmaması, vb. 37signals'ın (şimdi Basecamp) kurucuları Jason Freed ve David Hansson, Gerçek Sorunları çözmek için 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ının önceden hazırlanmış bir karmakarışıklığıdır:

• fırsatlar
• seçenekler ve ayarlar
• şirket yapısı
• toplantılar
• vaatler.

Bazı unsurlar farklı teknikler kullanmasına rağmen, olağandışı konsept geniş çapta benimsenmedi.

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ın hızını ölçmek;
• yinelemelerin tamamlanması üzerine günlük toplantılar ve retrospektifler düzenlemek;
• mikro adımlama kavramı ve kontrol listelerini kullanarak erken test etme;
• Çevik Modelleme Tekniği (AMDD).

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

Çevik metrikler

Çevik'teki araçların, uygulamaların, tekniklerin ve metodolojilerin çeşitliliği göz önüne alındığında, her birinin etkinliğini belirlemeye yardımcı olacak bir araç seçmeniz gerekir. Metrikler böyle bir araçtır.

Çoğu proje için 4 metrik alanı yeterlidir:

1. Verim- buna Hız ve Devam Eden Çalışma dahildir. İlki, yineleme başına tamamlanan görevlerin sayısı ölçüldüğü ve eşit olmadığı için tüm projeler için uygun değildir. Devam Eden Çalışma metriği, farklı aşamalardaki görevlerin sınırını belirler: ne kadar yüksekse o kadar kötü;
2. tahmin- kapasite ölçüsü: bir sonraki sprintte mevcut ideal saat sayısının belirlenmesi. Buna göre ne kadar çalışmanız gerektiğini, görevlerin ne kadar verimli bir şekilde tamamlandığını ve bir sprintin nasıl yapıldığını anlayabilirsiniz;
3. Kalite- örneğin, formülle hesaplanan gereksinimlerin istikrar endeksi = (Orijinal iş gereksinimlerinin toplam sayısı + Bu zamana kadar değişen gereksinimlerin sayısı + Eklenen gereksinimlerin sayısı + Kaldırılan gereksinimlerin sayısı) / (toplam sayı orijinal gereksinimler). Metrik, görevlerin yeniden işlenmesi için harcanan sürenin miktarını belirlemek için kullanılır;
4. değerler- her durumda, projenin formatına bağlı olarak ayrı ayrı hesaplanır. Örneğin, AirBnb girişimi, bir ürünün kullanıcılar için nihai değerini belirleyen bir ölçüm olarak yüklenen yüksek kaliteli fotoğrafların sayısını seçti. Artışları ile orantılı olarak tüketici sayısı da arttı.

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

Projeniz için tek bir doğru veya gerekli metrik yoktur.

Sürekli olarak gözden geçirilmeleri, modası geçmiş atılmaları ve gerektiğinde yenilerinin eklenmesi gerekir. Tüm ekip için anlaşılabilir ve erişilebilir olmalı, kendi içinde bir amaç haline gelmemelidir. Metrik uğruna metrik kötü bir karardır.

Efsane Avcıları: Çevik

Agile ailesinin popülaritesi ona acımasız bir şaka yaptı ve özel portallarda bile Agile'ın şu veya bu yönü hakkında efsaneler var. Anlayacağız!

Efsane # 1: Çevik tüm projeler için çalışır.

En kalıcı yanılsama. 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ğil, kendi başına bir amaç olarak dokümantasyona karşıdır. Ancak bir iletişim aracı olarak dokümantasyon seçerken, Agile gerçekten canlı iletişime öncelik verir.

Efsane # 3: Çevik ve planlama uyumsuz.

10 dakikalık stand-up'larla günlük zamanlama, iki haftada bir yinelemeli zamanlama, sprint toplantıları vb. bu efsaneyi çürütüyor.

Efsane # 4: Çevik, çok fazla yeniden çalışma gerektirir.

Çevik yazılım geliştirmede yeniden işleme iki şekilde gelir: yeniden çalışma gereksinimleri (kullanıcılar gerçekten neye ihtiyaç duyduklarını anlar) ve yazılım (geliştirme ekipleri bir uygulama yazmak ve tasarlamak için daha iyi yollar bulur). Ama bununla başka yöntemlerle de uğraşmak zorundasınız! Ayrıca, azaltmak için olumsuz etki Agile'ın bir özelliği olan yeniden işleme ve yinelemeli bir modele ihtiyaç vardır.

Çevik kullanmanın artıları ve eksileri

Artıları:

1. paydaşların katılımı- ekibin müşterinin isteklerini anlamak için daha fazla fırsatı var. Ve erken ve sık yazılım teslimi, paydaşların proje ekibine olan güvenini güçlendirir ve projeye daha fazla dahil olur.
2. erken ve öngörülebilir teslimat- yinelemeler yoluyla geliştirme modeli (1 ila 6 hafta arasında kısa aralıklarla) esneklik sağlar, ürünün piyasaya sürülmesini hızlandırır.
3. iş değerine odaklanmak- Müşteri ile işbirliği, ekibe, ürünü tüketici için mümkün olduğunca değerli hale getirme anlayışını sağlar.
4. sürekli kalite iyileştirme- her yineleme sırasında test etmek, son yapıyı ayrı çalışma kodu parçalarına bölmek, nihai ürün piyasaya sürülmeden önce yazılım hatalarını iyileştirmemize ve bunlarla başa çıkmamıza olanak tanır.

eksileri:

• ekip ve müşteriler için artan gereksinimler- proje ekibi ve kullanıcılar arasında yakın etkileşim olmadan, yüksek kaliteli ve değeri yüksek bir ürün elde etmek imkansızdır. Ve Agile'daki araç ve tekniklerin 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ü asla yayınlamama riski- bu eksi, garip bir şekilde, yinelemeli geliştirme ve sürekli ürün iyileştirmesinden ortaya çıkıyor - Çevik'in artıları.
• projenin iş hedeflerine ilişkin net bir vizyon olmadan çalışmaz- Çevik ekip paydaşlara odaklandığından, hedefler ve bir ürün konsepti geliştirmeden geliştirme imkansızdır.

Uygulamalar

Projeleri yönetmek için Çevik, proje yönetimine yönelik tüm hizmetler veya programlar için uygun değildir, çünkü her birinin kendine özgü özellikleri vardır.

İşletmeniz aitsepazarlama ve reklam, tasarım, seo veya dijital ajanslar sonra saas servisi bir bütün olarak tüm ekibin çalışmalarına uygulanabilir. tavsiye ediliriz .

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

1. etiketleri ve durumları özelleştirinşirketinizin çalışması için gerekli olan
   Durumlar aşağıdaki gibi olabilir: devam ediyor, kontrol ediliyor, tamamlandı, çalışması gerekiyor, kritik, özellik, ödeme.
   Etiketler genellikle şöyle görünür: düzen, test, üretim, konsept, kod.
2. bir birikim projesi oluştur ve proje yay.
3. görevler oluştur ve ön kontrol listeleri, eskizler vb. birikmiş durumda.
4. mit-up'larda tanımla bahar görevleri ve onları biriktirme listesinden aktar sprintin içine.
5. kullanmak müşteri misafir erişimi proje hakkında her zaman tutarlı ve güncel yorumlara sahip olmak için görevlere.
6. kutlamak görevlerden sorumlu böylece her meslektaş kendi sorumluluk alanını bilir ve sprintin sonucuna dahil olduğunu hisseder.

Karar

Çevik yazılım geliştirme ile küçük proje ekipleri verimliliği en üst düzeye çıkarır. Çevik diğer çevik yöntemlerle uygulanır: Scrum, XP, Lean, vb.

Tecrübesiz bir ekip tarafından bir çırpıda kısa sürede uygulanması mümkün değildir. ancak Çevik'in uygulanması, BT ile işletme arasındaki etkileşimi iyileştirecek, pazara sunma süresini hızlandıracak ve son kullanıcı için ürünün değerini artıracaktır.

Çevik proje yönetimi yöntemleri (Çevik), hem stratejik hem de taktik olarak en popüler yönetim araçlarından biri haline geliyor. Bu notta, şirketinizin yönetiminde Çevik proje yönetiminin ne kadar esnek olduğunu anlamaya çalışacağız, cevapları yöneticinin karar vermesine izin veren birkaç soruyu göz önünde bulundurarak: Çevik metodolojiyi işletmede uygulamaya değer mi? şirketinin süreçlerinin olup olmadığı ve böyle bir ihtiyaç varsa, şirketinizde hangi özel görevleri çözmenize izin verdiği.

Çevik yönetim yöntemleri, her şeyden önce çok hızlı çözüm bulmanızı, pilot projeler başlatmanızı ve gerekirse ölçeklendirmenizi sağlayan yaklaşımlardır.

Proje yönetimi açısından Agile, aşağıdaki durumlarda şirketiniz için gerekli olacaktır:

• ürününüz, hizmetiniz veya ürün sunumunuzun sürekli ayarlanması gerekiyor.
• pazarlamanızı pazar gereksinimlerine göre ayarlamanız gerekiyorsa.
• Karları artırmak ve maliyetleri azaltmak için yenilik yapmakla ilgileniyorsanız.

Mecazi olarak konuşursak: hem strateji hem de uygulama açısından sürekli değişiklikler veya belirsizlikler karşısında hızla değişen bir pazarda çalışıyorsanız her zaman Çevik bir metodolojiye ihtiyacınız vardır.

Çevik metodoloji(çevik metodoloji), sürecin şeffaflığını ve verimliliğini, karar verme hızını, ürünün geliştirilmesini, uyarlanmasını ve ölçeklenmesini ve ayrıca yanıt verme yeteneğini sağlarken yeni bir yönetim ve liderlik türünden çevik ekipler oluşturmanıza olanak tanır. belirsizliklere, değişimlere ve krizlere

Çevik metodoloji nedir?

Agile'ın bir kriz yönetimi ve değişim yönetimi aracı olduğunu söyleyebilir miyiz? Tanımlı Evet!

Çevik metodoloji, kriz yönetimi ve değişim yönetiminde belirli, pratik sorunları çözmek için bir araçtır.

Çevik Nasıl Doğru Uygulanır?

Yönün popülaritesinden ve diğer şirketlerin olumlu deneyimlerinden yararlanarak Agile'ı uygulamak istemek oldukça yaygın bir hatadır, ancak bu kadar pervasız davranırsanız büyük bir risk vardır:

Çevik organizasyon, hem ekipte hem de liderlikte düşünce, çalışma yaklaşımı ve etkileşim ilkelerinde bir değişiklik gerektiriyor, buna hazır mısınız? Ya çalışanlarınız? Bunun genellikle birçok kişi tarafından gözden kaçırılan çok önemli bir soru olduğunu unutmayın:

Çevik metodoloji bu bir kutudaki bir ürün değil, uygulaması yeni şeyler öğrenme, görevlerinize uyum sağlama ve ancak ondan sonra ölçekleme yeteneği gerektiren bir çözümdür.

Bu nedenle, her zaman Çevik uygulama konularında birkaç iş araştırması yürütmenizi, yürütmenizi ve ancak o zaman şirketlerinize çevik yönetim metodolojileri getirme olasılığını değerlendirmenizi öneririm. Çözüm olarak, uygulamalı kursumu almanızı önerebilirim:

Çevik yöntemler işinizi mahvedebilir ve bu sizin işinize, iş süreçlerinize bağlıdır, kendinize veya çalışanlarınıza değil.

Agile ne zaman uygulanmamalıdır?

Basit bir kural var:

Çevik metodoloji sadece hatalar için ödeme yapmaya hazır olduğunuzda kullanılabilir.

Çevik metodoloji sadece sonuç vermez:

Çevik geliştirme açısından Agile, geri bildirim, birçok geri bildirim seçeneği aracılığıyla bir sonuca ulaşmak için bir süreç oluşturmayı mümkün kılar, ancak geri bildirim sadece duygular ve anketler değildir, aynı zamanda paradır: kâr ve zarar, unutmayın Bugün nasılsın.

Çevik proje yönetimini uygulamayı düşünmek istiyorsanız, şirketiniz Çevik proje yönetimi yöntemlerini iş süreçlerinize entegre etmeye hazırdır:

• kişisel ve grup koçluğu.
• meslektaşlarınız Çevik ekibin değerlerini paylaşıyor
• Agile'ı tüm gerekli iş süreçlerine dahil etmeye ve proje yönetiminde Agile'ı uygulamanın risklerini anlamaya kararlısınız.

Ve bir kez daha tekrar edeceğim: Çevik metodoloji sadece araçlar değil, düşünmektir.

Ve düşünmenin kendisi şu anlama gelir: sonuca ve iletişime karşı tutum ve ayrıca esnek proje yönetimi yöntemleri kullanmayı planlıyorsanız çok önemli olan uygun şekilde yapılandırılmış geri bildirim.

Çevik metodoloji, daha yüksek bir hedef uğruna yüksek maliyetlere hazır olma koşullarında, belirsizlik ve öngörülebilir sonuçlar koşullarında mükemmel çalışır; İş süreçleri oluşturduysanız, Çevik proje yönetimi uygulayarak hangi hedeflere ulaşmaya çalıştığınızı düşünün ve buna değer mi?

Bir şirkette Çevik uygulamak için algoritma

Çevik metodolojiyi şirketin mevcut iş süreçlerine uygulamak için proje yönetiminde Çevik'e odaklanan yaklaşık bir algoritma düşünelim:

• Hedeflerle Başlamak: Çevik yönetim uygulamalarını benimseyerek hangi hedeflere ulaşmaya çalışıyorsunuz? Ve bu hedeflerin Çevik organizasyona ne ölçüde karşılık geldiği.
• Çevik bir pilot proje uygulamak için seçtiğiniz işletmenizin veya departmanınızın problemlerini, buna ihtiyaç varsa, işinizde nasıl bir tarza bağlı olduğunuzu, nasıl fikir alışverişinde bulunduğunuzu ve sonucun başarısını nasıl takip ettiğinizi açıklıyoruz. .

Tabii ki, bir sonraki adım klasik "nasıl yapılır" ı önerir, ancak burada acele etmemelisiniz, çünkü nasıl yapacağınızı nereden biliyorsunuz? - Çevik metodoloji, düşünmeyi yeniden yapılandırır ve Agile'ı proje yönetiminde uygularken, Çevik ekibinin üyeleri arasında bir diyalog oluşturmak için etkili bir iletişim ortamı yaratmak gerekir.

Bir şirkette Çevik bir ekip oluşturmak

Çevik bir ekip oluşturmak oldukça hızlı olabilir, birkaç gün sürebilir, ancak ekip üyelerini doğru yere yerleştirmek ne kadar sürer?

Tabii ki, ekip oluşturma açısından aşamalar ayırt edilir: oluşum, çatışmalar, kuralların ve normların gelişimi ve sonunda şunu elde ederiz: belirli bir çalışma tarzı, ancak Çevik bir ekipte her şey biraz farklı olur:

• Çevik ekip çalışanları ve liderleri, Çevik Manifesto'ya bağlı kalırlar ve hızlı değişim ortamında etkili çalışma oluşturmaya ve hedeflere ulaşmaya odaklanırlar.
• bir konfor bölgesi yaratmazlar, bir ütopya yaratmazlar, kendileri değişiklikleri, yeni trendleri ararlar, bunları şirketin hedeflerinin uygulanmasında kullanma olasılığı için analiz ederler.

Çevik metodoloji:

Çevik metodoloji proje yönetimi değildir, Çevik proje yönetimi için bir araç olabilen, ancak kuruluşunuzda tamamen bağımsız olabilen esnek yönetim yöntemleridir. Elbette Çevik ekiplerin etkinliği için çalışanları klasik ekip kurma ve liderlik konusunda eğitmek ve böylece onları eskisi gibi düşünmeye zorlamak büyük bir hata olacaktır!

Çevik yönetim uygulamaları harekete geçme, yeni bir şeyler bulma, hedeflere ulaşma, gerekli hedeflere ulaşmak için dış ve iç çevrenin fırsat ve tehditlerini kullanabilme ve iş dünyasında kâr ve rekabet gücünü etkileyen belirli sorunları çözme çağrısıdır.

Bayanlar ve Baylar, Çevik metodoloji bir şirketin yönetiminde gereklidir, ancak uygulama ve yeni fikirler için esnek bir yaklaşım gerektirirken eski yöntemleri kullanmak, yeni hedeflere ulaşmanıza ve bir şirketin rekabet gücünü oluşturmanıza izin vermeyecek sonuçlara yol açacaktır. Bu nedenle, Çevik metodoloji için danışman seçerken çok dikkatli olun, modern pazarın gereksinimlerine uyum derecelerini değerlendirin, sorularınızı bekliyoruz, yorumları yazın. Teşekkürler!