Çevik Proje Yönetimine Nihai Giriş

Özet

Şirketinizin “Widgets International”ın çehresini sonsuza dek değiştirecek en yeni ve en büyük girişimini sunmaktan sorumlusunuz. Müşterilerinizin ilgisini çekecek ve onları büyüleyecek, iş arkadaşlarınızın hayatını kolaylaştıracak ve şirkete milyonlar kazandıracak bir yazılım projesidir. Büyük bir beklenti, şevk, heyecan ve beklenti var. İşletmenizin avantajlardan yararlanmaya başlayabilmesi için mümkün olduğunca çabuk halletmeniz gerekir. Şirketin gelecekteki başarısı size bağlıdır. Bütün gözler senin üzerinde. Başarısız olamazsın.

İlk başta kendi kendinize “Harika, meydan okumaya hazırım. Şu işi bitirelim!” Bir an duraksıyorsunuz, geri çekiliyorsunuz ve kendinize “Tamam, peki bunu nasıl yapacağız?” Diye düşünüyorsunuz. Meslektaşlarınız ve akranlarınızla konuşmaya başlarsınız. En iyi uygulama yazılım geliştirme ve proje yönetimi tekniklerini aramak için zaman harcıyorsunuz, ancak seçenekler ve yaklaşımlar sayısız. Çok sayıda kısaltma ve metodoloji var. Önemli olanlar zirveye çıkıyor. İçine şüphe giriyor. Hangisini kullanmalıyız? Başarıyı nasıl garanti edebilirim? Ya yanlış kararlar verirsem?

Yazılım projelerini yönetmeye gelince, sayısız fikirle desteklenen çok çeşitli seçenekler vardır. Odanın köşelerinden gelen sesler fısıldıyor, “Bunu böyle yapmayı dene”; diğerleri, “Bunu yapmanın tek yolu bu” diye bağırır; ve geri kalanlar sadece "Hiç idare etme, sadece devam et" diye sızlanır. Gerçekte, tüm bu sesler bazı doğruları söylüyor. Ancak önemli olan ihtiyaçlarınız, ekibiniz, işiniz ve müşterileriniz için doğru olanı bulmaktır.

Sahneyi Ayarlamak

Yazılım proje yönetiminin üç kamptan birinde tam anlamıyla oturduğu bir zaman vardı. Kontrol ve yönetimi sürdürmek için bir yapı sunarken, nasıl yürüteceğiniz ve teslim edeceğiniz konusunda kararlar almanıza izin veren ağır çerçeveler vardı. Sizi uzun projeler planlamaya, tüm gereksinimlerinizi anlamaya ve taahhüt etmeye, karmaşık sistemler tasarlamaya ve imzalamaya, çok sayıda kod yazmaya ve ardından test etmeye (müşteriniz ilk kez görmeden önce) zorlayan şelale gibi kuralcı ardışık metodolojiler vardı. zaman). Ve son olarak, hızlı prototiplemeyi veya daha büyük sistemlerin artımlı adımlarla tasarlanmasını, inşa edilmesini ve teslim edilmesini teşvik eden daha az kuralcı ancak yinelemeli yazılım geliştirme yaşam döngüleri (SDLC).

Çevik yazılım geliştirme ve Çevik proje yönetimi, şelalenin yetersizliklerinden ve yazılım tesliminde yinelemeli yaklaşımların faydalarından doğmuştur. Köklerini 1950'lere, düşünce liderliğini 70'lere, olgunluğu 90'lara ve benimsemeyi 2000'lere kadar takip edebilirler. 2001 yılında, bir grup uygulayıcı ve uzman, Çevik yazılım geliştirme ruhunu somutlaştırmayı ve evrimini teşvik etmeyi amaçlayan 4 değer ve 12 yol gösterici ilkeyi tanımlamayı amaçlayan Çevik Manifesto'yu oluşturdu. Ve kesinlikle gelişti.

Şimdi, bir şeyi sadece Çevik olarak adlandırmak özellikle yardımcı olmuyor. Kelime, yazılım bağlamında bile, farklı kişi veya kuruluşlar için farklı anlamlara gelir. Birçok yönü, tanımı, uygulaması ve yorumu vardır. Çevikliği benimseyen her beden, ona kendi tanımını vermeye çalışma eğilimindedir.

Çevik yazılım geliştirme ve proje yönetiminin, doğru çalışan yazılımın mümkün olan en erken ve sıklıkta sunulmasını temel olarak destekleyen ilgili davranışlar, çerçeveler, teknikler ve kavramlar grubu olduğunu söylemek yeterlidir.

Yazılım geliştirme veya proje yönetimine uygulandığında Agile'ın farklı şeyler olabileceğinden daha önce bahsetmiştim. Özetle, Çevik yazılım geliştirme, her zamanki gibi bir işte (BAU) veya proje bağlamında harika yazılımlar geliştirmeye özen gösterir. Çevik proje yönetimi ise, yazılım dahil ancak bunlarla sınırlı olmamak üzere karmaşık projeleri teslim etmek için gereken yönetişim ve kontrolle ilgilenir.

Scrum, Kanban, XP ve Yalın Yazılım Geliştirme gibi birçok Çevik yazılım geliştirme yöntemi mevcuttur. Ancak ragbi oyununun hücumdan daha fazlası olduğu gibi, Agile de öyle. Tek başına, bu Çevik paradigmalar, yönetişim, kaynak sağlama, finansal, açık risk yönetimi ve diğer birçok önemli proje yönetimi kavramı gibi karmaşık projelerde gerekli olan proje yönetiminin tüm yaşam döngüsünü ele almaz. Bunlar için PMI Agile veya PRINCE2 Agile'ı düşünmek isteyebilirsiniz - bunu “Governed Agility” olarak düşünün.

Neden Çevik Olmalıyız?

Uzun zaman önce, hayatta kalmak için yiyecek ve barınak toplamak için topraklarda dolaştık. Bunlar basit ihtiyaçlardı ama oldukça çevikti. Bir süre sonra, Sanayi Devrimi'nin ardından ülkeler ve ekonomiler büyüdü ve zenginleşti. Bu, yönetim ve kontrolün doğuşu ve çevikliğin kaybıydı. Artık işletmelerin bilgi işçileri istihdam ettiği Bilgi Çağı veya Devrimi'ndeyiz. Bilgi işçileri, müşteri, iş, sosyal, ekonomik ve dünya sorunlarına harika çözümler yaratmaya çalışan siz, ortaklarınız ve meslektaşlarınız ve meslektaşlarınızdır. Bilgi çalışanları, genellikle gevşek bir şekilde tanımlanmış ve değişen ihtiyaçlara analiz, bilgi, akıl yürütme, anlayış, uzmanlık ve beceriler uygular. Bu işletmeler ve işçiler, eski Sanayi Çağı süreç ve prosedürleriyle karşılanamayan yöntem ve tekniklere ihtiyaç duyarlar. Çevik etkileşimleri destekler.

Neredeyse hiçbir yazılım projesi, başlangıçta kendinden emin bir şekilde yola çıkamaz ve değerli çalışan yazılımları değişmeden teslim etmek için ihtiyaç duyduğu her şeyi bilemez. Değişim, bir projenin başarısı için hem fırsatlar hem de riskler sunar. Yönetilmeyen fırsatlar, harika bir şirket ile harika bir şirket arasındaki fark anlamına gelebilir. Yönetilmeyen risk felaket ve yıkım demektir. Çevik, değişimi yönetir.

Agile'ı benimsemek, değişen veya yeni gereksinimlere duyarlı olmanızı sağlar. Geliştirme ekiplerine uzman olmaları ve ilgili, güvenilir ve bilgili bir işletme tarafından desteklenen kararlar almaları için yetki verir. Müşterilere gerçekten istediklerini sunmanızı sağlar. Sonuç olarak, size ve kuruluşunuza, müşteri ihtiyaç ve beklentilerini karşılayan yüksek kaliteli, değerli yazılımlar sağlamanın kontrolünü sağlarken, yatırımınızın karşılığını mümkün olan en kısa sürede elde eder. Çevik değer yaratır.

Agile'ı benimsemenin bir maliyeti vardır. Bedava gelmiyor. Yazılım teslimi için Çevik bir yaklaşıma dönüşmek, izlenmesi zor bir yol olabilir. Ancak, Çevik felsefeyi içselleştirirseniz, dikkatli davranırsanız, doğru ekiple doğru tutumla etkileşime geçerseniz, işleri bozarsanız, başarılabilir ve gerçekçi hale getirirseniz ve geri bildirimlere yanıt verirseniz, ödüller alırsınız. Çevik işbirliğini vurgular.

Aşağıda bekleyebileceğiniz bazı avantajlar listelenmiştir:

• Pazara çıkış hızı
• Daha erken gelir elde etme
• Gerçek değerin düzenli teslimatı
• Yatırımınız için koruma
• Veri, veri, veri
• Daha iyi ürün kalitesi
• Yönetilebilir beklentiler
• Daha fazla müşteri memnuniyeti
• Daha yüksek performans gösteren ekipler
• İlerleme konusunda iyileştirilmiş görünürlük
• Öngörülebilirlik, şeffaflık ve güven
• yönetilebilir risk

Başarı nihai değildir, başarısızlık ölümcül değildir: önemli olan devam etme cesaretidir.

Winston Churchill bunu asla söylememiş olabilir, ama bence bu Çevik'in oldukça iyi bir özeti. Çoğu proje için en iyi adımın Agile olduğunu biliyoruz. Başarı için çabalamanızı teşvik eder, ancak biz her zaman yineler ve bunun üzerine inşa etmeye devam ederiz. Agile sizi başarısız olmaya teşvik eder, ancak erken başarısız olur ve devam eder. Ödülü getiren şey, devam etme ve müşterinizin bilgilendirdiği içgörüye dayalı doğru çözümü oluşturma cesaretine sahip olmaktır.

Akılda tutulması gereken şey, Agile'ı ihtiyaçlarınıza göre uyarlayabilmenizdir. İşletmeniz için doğru olan yöntemi ve yönetimi kullanın. Nereden başlarsanız başlayın, kullandığınız yöntemin içeriğine, bağlamına ve ruhuna sadık kalın - basit olsun. Yeni başlıyorsanız öğrenin . Bir süredir yapıyorsanız, anlayın . Harika oluyorsanız, başvurun . Son olarak, işiniz ve projeleriniz karmaşık ve birbirine bağlıysa, yönetin . Zamanla, siz ve ekipleriniz işiniz için en iyisinin ne olduğunu anlayacaksınız.

Fizibilite

Şimdi, “Tamam, anladım. Nasıl başlarım? Nereden başlayayım?” Pekala, tüm güzel şeylerle, en baştan başlıyoruz. Ve Agile ile kendinize “Hangi iş değerini sunmak istiyorum?” sorusunu sorabilirsiniz. Sonuçta, işte bu yüzden iş değeri yaratmak için projeler üstleniyoruz. Projenin iş değerini elde etmeye değer olup olmadığını belirlemek için, bunun uygulanabilir olup olmadığını anlamanız gerekir.

Görüş

Projenizin geliri artırması, yeni bir pazara girmesi, daha fazla müşteri kazanması, müşteri algısını iyileştirmesi veya belirlediğiniz belirli bir sorun için hayatı kolaylaştırması öngörülüyor mu? Bunu akılda tutarak, “vizyonunuzu” belirtebilirsiniz.

• Vizyonunuz farklı kaynaklardan gelebilir - ortak bir sorunu çözmek için kendi cesur girişiminiz, iş yönetimi stratejisi, CEO'nuzun evcil hayvan projesi, belirli bir ürün ekibi ve hatta müşterinizin ihtiyaçları.
• Kendi ayakkabılarınızdan bir adım geri atmaya çalışın ve müşterilerinizin elinde yeni ürününüz veya hizmetinizle geleceğin nasıl göründüğünü “görmeye” çalışın.
• Paydaşlarınızla (CEO, ürün sorumlusu ve müşteriler) etkileşim kurun. Atölye çalışması yapın, bunu tek başına denemeyin. Varsayımlara meydan okuyun ve argümanları doğrulayın.
• Yazın, kısa tutun. İş değerine odaklanın.
• Vizyonun herkeste yankı bulduğunu ve nereye gittiğinizi belirten ortak bir yorumla buluştuğunu kabul edene kadar bunu hassaslaştırın.
• Vizyonunuz, eğer geçerliyse, nadiren değişir. Oraya nasıl varacağınız kesinlikle olacaktır.

İnsanlar ne yaptığınızı veya nasıl yaptığınızı satın almazlar. “Neden” yaptığınızı satın alıyorlar. İşletmeniz ve müşterileriniz arasındaki duygusal bağı oluşturan şey budur. Vizyon bunu göstermeye yardımcı olacaktır.

Mümkün mü?

Fizibilite en az birkaç tonda gelir. Tipik olarak, işletmeniz ve müşterileriniz için daha parlak bir gelecek vizyonunuzun hem teknik olarak mümkün olup olmadığını hem de işletmenizin bunu gerçekleştirmesinin mümkün olup olmadığını anlamak isteyeceksiniz.

• Vizyonunuz bir saatten daha kısa bir sürede dünyanın herhangi bir yerine seyahat etmekse, teknik fizibilite ile ilgili bir sorununuz olabilir. Bilim, fizik ve teknoloji henüz bu rüyayı tam olarak yakalayamadığı için, teknik çözümünüz teori dışında hiçbir şeyde geçerli olmayabilir. Ek olarak, çözümünüz yeni olsaydı, bu, minimum uygulanabilir ürün (MVP) fikrinin çok ötesine geçerdi.

• Ürününüzün teknik fizibilitesini test etmek için, onu bir Discovery prototip projesinde daha fazla araştırmayı veya projenin ilk aşamalarında bir ani artış gerçekleştirerek düşünün. Aklınızdaki çözümün ölçeğini veya karmaşıklığını düşünerek hangi yöntemi kullanacağınızı bileceksiniz.

  "Ekiplerimin teknik fizibiliteyi anlama konusunda edindiği en iyi bilgilerden bazıları, bir ani yükseliş gerçekleştirerek elde edildi. Ve çoğu zaman, kazanan en basit çözümdür!”

• Göz önünde bulundurulması gereken ikinci fizibilite gölgesi, sizin, ekibinizin veya işletmenizin onu çalıştıracak beceri ve motivasyona sahip olup olmadığıdır. Bir örnek verecek olursak, çocuklarınızın doğum günü için evde kek pişirmede harikaysanız, bu çok tatlı. Ancak bunu, dünyaya en iyi pastaları satan bir işletmeye dönüştürmek istiyorsanız, bunu ölçeklendirip gerçekleştiremeyeceğinizi, işi olduğu kadar üretimi de idare edip edemeyeceğinizi, dağıtım ve sipariş karşılamayı yönetip yönetemeyeceğinizi ve müşteri hizmetleriyle ilgilenip ilgilenemeyeceğinizi anlamanız gerekir.
• Bu tür bir vizyon uzun vadede ulaşılabilir olabilir. Ama şimdilik, muhtemelen değil. Bu yüzden ölçeği küçültün, küçük düşünün, gerçekçi görünen küçük bir parça alın ve yapabileceğiniz en iyi küçük özlemi sunmaya odaklanın. Bu, müşterilerinizin ilgisini çekmeyi ve onları memnun etmeyi başarırsa, daha fazlası için geri gelmelerini ve arkadaşlarına söylemelerini sağlayın, ardından müşteri geri bildiriminizi rehberiniz ve pusulanız olarak kullanarak oradan büyütün.
• Ayrıca, projenizin bütçe ve zaman çerçevesi açısından uygulanabilir olup olmadığını da bilmeniz gerekir. İşletmeniz bu projeyi gerçekleştirmeyi karşılayabilir mi? Zaman çerçevesi ulaşılabilir mi? Zaman ve para, bir Çevik projede sabit olan üç kısıtlamadan ikisidir. Belirli bir sabit zaman içinde ve belirli bir sabit bütçe dahilinde teslim etmeyi amaçlıyoruz.
• Bir ürünün kalitesi, müşterilerinizin kullandığı son ürünü ve ekibinizin harika, sağlam ve güvenilir yazılımlar sunmak için kullandığı mühendislik uygulamalarını ifade eder. Kalite aynı zamanda değiştirmediğimiz bir şeydir. Kalite kriterleri ise değişebilir. Bir Ferrari inşa etmek için yola çıkmıyorsanız, ürün yüksek kalite algısına sahip olmayabilir. Uzay roketleri yapmıyorsanız, üretim açısından elde edilen toleranslar çok daha yüksek olabilir. Uygun tonu ve beklentiyi erkenden belirleyin.

Artık hayalinizin çikolata fantezisinden daha fazlası olduğunu onayladınız, varsayımlarınızı test etmeye ve insanlara bu çabanın yatırım yapmaya değer olduğunu kanıtlamaya başladınız.

Meşrulaştırma

Şimdi, koşullarınıza bağlı olarak, gerekçelendirme farklı şekillerde gelecektir. Ancak esasen, bu projenin müşteri başarı kriterlerini karşılayacağını, başarı şansı olduğunu, değer katacağını ve uygun maliyetli olduğunu kanıtlamak istiyorsunuz.

• Varsayımlarınızı müşterinizin ihtiyacına göre belirtin, ardından bunları doğrulayın. Lean Startup, ürününüze müşterileriniz tarafından ihtiyaç duyulduğunu ve değer yaratacağını belirleme ve kanıtlama konusunda harika bir rehberlik sağlar.

• İş planınızı yazın, test edin ve doğrulayın. Şimdi bu, bankanızın veya işletme ve finans bölümünüzün üretmenizi söylediklerine hiç benzemiyor. Bunları kullanmayın—mürekkep kurumadan eskirler. Bunun yerine, İş Modeli Kanvası'na göz atın. Bu, esasen, değer teklifinize, müşterilerinize, gelirinize ve maliyetlerinize odaklanmanızı sağlayan kısa biçimli bir iş planıdır. İşe yarayacak bir işiniz olup olmadığını doğrulamak için kullanın.

  “Bu tavsiyeyi bir kez görmezden geldim ve uzun bir 50 sayfalık geleneksel bir iş planı yazmak için uzun zaman harcadım. Beni hiçbir yere götürmedi. Yaptığım tüm varsayımlar asılsızdı ve yaptığım tüm tahminler doğrulanamadı. Bana bir daha asla yapmamayı öğreten acı verici ve pahalı bir deneyimdi.”

• Karmaşık bir ortamda teslim edilen proje portföyleriyle olgun bir iş yapıyorsanız, finansal modelleme gerekli olabilir. Gerekirse, bunu ancak yukarıdakileri kanıtladıktan sonra yapın.
• MVP'nizi oluşturduktan sonra, daha geleneksel bir iş planı oluşturmak için bir durum olabilir - örneğin, şirketinizin rakip proje ve kaynaklardan oluşan portföyünde finansman veya seçim yapmanız gerekiyorsa. Ancak bu, yukarıda kullanılan araçlara dayalı ve onlar tarafından bilgilendirilen bir iş planı olacaktır. Hem daha hafif olacak.
• Her durumda, bu araçları yaşayan, nefes alan eserler olarak kullanın. Onları rehberiniz ve haberciniz olarak kullanın. Asla statik değildirler. Onlara bakın ve projeniz veya işiniz geliştikçe gözden geçirin.

Gerekçenizi aldıktan ve tüm paydaşlarınız gemide olduğunda, yanacaksınız.

Fizibilite aşaması genellikle projenizin ömrü boyunca bir kez gerçekleştirilir. Özellikle verileriniz, müşterileriniz, pazarınız veya işiniz bunu gösteriyorsa, projenin vizyonunu ve fizibilitesini tekrar gözden geçirdiğinizi görebilirsiniz. En azından, yol boyunca yol gösterici ışıklarınız olacaklar.

başlatma

Mükemmel. Karar verildi, projeye yeşil ışık yandı ve artık inşaata hazırsınız. Neredeyse. Düşündüğünü biliyorum, “Hadi, gerçekten mi? Bunu şimdi yapmazsak, asla yapmayacağız. Hadi bu şovu yola çıkaralım!” Ancak şunu göz önünde bulundurun: Çevik, müşterilerinizi bu süreçte memnun ederken erken ve sıklıkla değer sunmakla ilgili değilse hiçbir şey değildir. Projenizi teslim etmenin en iyi yolunu bulmak için biraz zaman ayırmak, başarı için en iyi temeldir.

Takım

Sporda, en sevdiğiniz takım oyununu düşünerek, takımın olduğu gibi oynamasını sağlayan kilit rolleri tanıyabileceksiniz. Geleneksel olarak, bir menajer, bir kaptan ve ekibin geri kalanını bulacaksınız. Bunun dışında antrenörler, fizikçiler, beslenme uzmanları ve çeşitli yardımcı personel bulacaksınız. Ancak ragbi oyununa bakarsak, takım içinde bir takım vardır: hücumu oluşturan oyuncular. Bu paket, işi topu geri kazanmak ve oyuna devam etmek olan belirlenmiş oyunculardan oluşur. Bir saldırı oyundayken, her iki taraftaki oyuncular, lider olmadan, tek bir birim olarak, mümkün olduğunca işbirliğine dayalı, iletişimsel ve verimli bir şekilde, topu geri almak için çalışırlar. Jeff Sutherland'a yazılım geliştirme metodolojisine "Scrum" adını vermesi için ilham veren şey, ragbi oyunudur.

• Scrum, Agile playbook'taki tek yazılım geliştirme yöntemi değildir. Ancak ekip olarak çalışma, bireyleri motive etme, güvene dayalı ilişkiler oluşturma, kendi kendine örgütlenme, hizmetkar liderlik, iletişim, şeffaflık ve işbirliği gibi Çevik kavram ve davranışlarını en iyi tanımlayandır.
• Ekibiniz büyük ölçüde içinde bulunduğunuz koşullar tarafından oluşturulacaktır. Kullanabileceğiniz geliştiriciler olabilir. Bazıları, hiçbiri veya hepsi, Çevik'e değişen derecelerde aşina olabilir. Üçüncü bir tarafla yeni bir ekip veya ortak kiralamak isteyebilirsiniz.
• Başka roller de gerekli olacak, ancak bunları daha sonra tartışacağız.
• Geliştirme ekibinizi oluşturuyorsanız, teknolojinizi seçtiğiniz söylenmiştir. Ekibinizi nereden bir araya getirdiğinize bağlı olarak, belirli becerilerle gelecekler. Bu nedenle, geliştirme ekibinizi nasıl oluşturacağınızı ve yolculuğunuzda bu noktaya gelmeden önce teknik bir değerlendirme yapmanız gerekip gerekmediğini dikkatlice düşünün.
• Bu bizi işlevler arası ekiplere getiriyor. Takımlar, birlikte çalıştıklarında en iyi şekilde çalışırlar, unvanları ne olursa olsun bireyler işi halletmek için adım attığında. Kendi kendine yeten ve birden fazla rolü üstlenen bireylerden oluşan bir ekip oluşturmaya çalışın.
• Bir ortam, kültür ve ilişki merkezi oluşturun - ekibin kısıtlamalar veya kısıtlamalar olmaksızın teslim edebileceği bir yer. Takıma etkili ve performanslı olmaları için araçları, insanları, kaynakları ve alanı verin.
• Ekip boyutlarını yedi veya sekizden fazla tutmayın. Daha fazla geliştiriciye ihtiyacınız varsa, ekibi birden fazla yeni ekibe bölün. Her takım daha sonra belirli bir işlevsel alandan sorumlu olabilir. Birden fazla yerde birden fazla takımınız varsa, bir Scrum of Scrum tutmayı düşünün. Bunların karmaşık ortamlarda çok sayıda olduğu durumlarda Çevik proje yönetimini kullanın.
• Ekibin, işletmenin, paydaşların ve hatta müşterilerin birbirine erişimi olduğundan emin olun. İletişim kurduklarından ve işbirliği yaptıklarından emin olun ve ilerlemenin önüne çıkan her şeyi kaldırın. Günlük iletişim, proje rahatsızlıkları için en iyi tedavidir. İnsanlar konuştuğunda işlerini hallederler.

Yazılım sunmak için bir ekibin bir araya getirilmesinin birçok yolu vardır.

Proje tanıtımı

Fizibilite adımında, projenizin "nedenini" anladınız ve ya girişiminizle ilerlemek için kendinize güveninizi oluşturdunuz ya da ilerlemek için destek aldınız. Proje özeti, “neden” ile “ne” ve “ne zaman” ve “kim”i bir araya getiren canlı belgedir. “Yaşamaktır” çünkü siz ilerledikçe bilginiz, anlayışınız ve yolunuz değişebilir. Bu belgeyi bir kez yazılı olarak bırakmak ve bir daha asla ona geri dönmemek, düşüncelerinizi zamanın bir noktasına gönderir. Çevik bir dünyada, belirli bir nokta referansınız erken dönemde haftalık veya hatta günlük olarak değişebilir, bu nedenle bunu taze tutmak önemlidir.

• Proje özetinizi özetlemek ve sürdürmek için harika bir araç, Jonathan Rasmusson'un Çevik Samuray adlı kitabında “başlangıç ​​güvertesi” dediği bir şeydir. Burada, projenizle ilgilenen, projenizden etkilenen veya projenize dahil olan herkesin aynı sayfada olmasını sağlamak için harika tavsiyeler bulacaksınız.
• Proje sunmanın en büyük düşmanı, projenin ne olduğu ve hangi "gereksinimlerin" karşılanması gerektiği konusunda belirsiz, tutarsız veya sadece farklı bir anlayışa sahip olmaktır. Önemli bir paydaş bile yaptığınız şey hakkında farklı bir anlayışa veya görüşe sahipse, sonuçları önemli olabilir.
• İyi bir proje özeti şunları bildirir:
  1. Paydaşlar ve ekip üyeleri arasında ortak ve üzerinde anlaşmaya varılmış bir beklenti.
  2. Tüm taraflarda aynı anlayışla proje anlayışı.
  3. Amaç, vizyon, amaç, kapsam ve proje bağlamı.
• Fizibiliteden elde edilen özet için birçok iyi bilgiye sahip olacaksınız. Proje özeti, arama sorularının yanıtlarını tanımlamanıza ve bulmanıza yardımcı olacaktır. Paydaşları, varlık sebebinizi , üst düzey kapsamı, riskleri, hedef çözümü, bütçeyi, zaman çizelgesini, beklentileri ve öncelikleri bir araya getirecektir.

Bir meslektaşım bir keresinde beni bir koridorda durdurdu ve proje için proje özetini nereden alabileceğini sordu. 'Bir özete ihtiyacımız yok, biz Çevikiz' diye espri yaptım. Sanki aklımı ya da otoritemi sorguluyormuş gibi kafası karışmış görünüyordu. Bunu yapmakta haklıydı.

Devam etmeden önce, herkesin aynı sayfada olduğundan emin olun, üzerinde çalışın, zor soruları sorun ve insanların durabileceği, okuyabileceği, yorumlayabileceği ve gözden geçirmesine yardımcı olabileceği bir yere çivileyin.

Kültür ve Çalışma Şekilleri

İşinizin nasıl yürüdüğünü ve kültürünü, işleri halletmeyi nasıl sevdiğini bilirsiniz. Çevik, doğası gereği, işletmenizin yıllar içinde geliştirdiği bu çalışma yollarından bazılarına meydan okuyabilir. Agile'ın uygulanmasını ve herkesin en baştan sevgiyle benimsemesini beklemeyin. Bazı insanlar bunu kafa karıştırıcı bulabilir ve sadece korku ve korku ile görebilir. Bazı insanlar açıkça buna katılmayı reddedebilir. Bunlar üstesinden gelmeniz gereken zorluklar ve algılardır. Ama ilk günlerinizde, Çevik sopayı sallayarak onu dinlemeyen birini dövmeyin. Bu, güven, benimseme veya katılım oluşturmaz.

Bir zamanlar büyük atasözü çubuklarını sallamanın hayranıydım ve bu bana çok fazla olumsuz baskı kazandırdı. Onu çevirdim, ama önce ciddi bir acı çekmeden önce.

Evlat edinme yolunuza çıkarken dikkatli, saygılı ve empatiyle ilerleyin. Gıcırdayan eski bir geleneksel işteyseniz, belki de tüm işi uyumlu hale getirmek için en iyi yaklaşım bu olmayacaktır. Küçük başlayın ve kademeli olarak saygı ve tanınma kazanın. Yalnızca ekibinizle başlayın. Daha önce hiç olmadığı kadar kaliteli ve hızlı bir yazılım sunmaya başladığınızda, insanlar bunu fark etmeye başlayacak ve gelip oyununuzu oynamak isteyeceklerdir. Bunu yaptıklarında, topu onlara verin, bir kahve içmeye çıkarın ve onları yeni dünyanıza alıştırın. Onlara yardım.

Ekibinizle, artık projenin ne hakkında olduğunu bildiklerine ve Çevik benimseme planlarınız üzerinde anlaşmaya varıldığına göre, ekibin nasıl davranmak ve bir ekip olarak çalışmak istediklerine karar vermesine izin verin.

• Toplu ihtiyaçlarınıza uygun olduğunu düşündüğünüz Çevik kavramları, teknikleri, davranışları ve çerçeveleri belirlemeleri için ekibinize rehberlik edin.
• Ekip üyelerinizden, ellerinden gelenin en iyisini yapmalarına yardımcı olmak için hangi gereksinimlerin olması gerektiği konusunda talepler alın. Bu isteklerin bazılarını hemen çözebileceksiniz. Diğerleri, bütçe veya dışarıdan yardım almanız gerekebilir. Bunu gerçekleştirmek için elinizden geleni yapın.
• Bunlar gerçek bir hizmetkar lider olma yolundaki ilk adımlarınız.
• Ekibinizin benimsemeyi seçtiği kavram ve teknikler konusunda uygun bir eğitim düzenlemeyi düşünün. Bu, tüm ekip üyelerinizin, hatta paydaşlarınızın aynı sayfada olmasını ve aynı mesajı almasını sağlamanın en iyi yoludur. Tekliflerini ihtiyaçlarınıza göre uyarlayabilecek bir tedarikçi kuruluşla çalışın.
• İhtiyatlı ol. Çevik olmayı öğrenen bir atölyede birkaç gün geçirdikten sonra kimse Çevik ninja olmayacak. Yolun uzun olacak. “Olmak” kelimesi oldukça tanımlayıcıdır. Sadece Agile'ı gerçekten kucakladığınızda değerini anlayacaksınız. Seni heyecanlandırmalı. Seni heyecanlandırıyorsa, git başkalarını da heyecanlandır.
• Ekibiniz kavramlar ve teknikler üzerinde anlaştığına, isteklerini yerine getirdiğine ve Çevik eğitimde olduğuna göre, ekibinizin dikkatini kendilerine ve sizden, işten ve birbirlerinden ne beklediklerine çevirin.
• Ekip içinde ve ekip tarafından bazı çalışma yöntemlerini (WoW) tanımlayın; güven, ilişki ve beklentiler oluşturmaya yardımcı olur. WoW, Savaş ve Barış değil. Kısa ve öz olmalı, yedi ile on arasında sivri uçlu cümle olmalıdır. Bu cümleler, insanların nasıl davrandığını, iletişim kurduğunu, işbirliği yaptığını, desteklediğini, teslim ettiğini ve birlikte nasıl gerçekleştirdiğini açıkça belirtir. Ayrıca ekibin işletmeden ne beklediğini de belirtmelidir.

• Çevik, ilkelere ve kavramlara rehberlik ettiği kadar bir zihniyettir. Davranış, düşünme, müzakere etme, etkileşim kurma, iletişim kurma, gerçekleştirme ve iyileştirme şeklinizde gelişmenize yardımcı olur. Birlikte ortak bir amaca ulaşmak için birbirini destekleyen motive olmuş bireylere dayanır. Bir Afrika atasözü vardır:

Şimdiye kadar ekibiniz çok heyecanlı, enerjik ve motive olmalıdır. Şimdi, birikmiş kullanıcı hikayelerinizle onları daha fazla meşgul edin.

iş listesi

Projenizde bir belirsizlik olduğundan hiç şüpheniz olmasın. Müşterileriniz için doğru ürünü bu kadar erken bir zamanda oluşturmak için ne gerektiğini tam olarak bilemezsiniz. Bir kristal küreye özlemle bakıp geleceği tahmin edemezsiniz.

"Bekleme listesi" veya "ürün biriktirme listesi", gereksinimlerinizin yaşadığı yerdir. Agile, bir "gereksinimin" özünü yakalayan kısa, özlü ifadelerin yazılmasını tercih eder. Biriktirme listesi basitçe uzun bir giriş listesidir ve her giriş bir kullanıcı hikayesi olarak tek, ayrı bir "gereksinim" tanımlar. Ve bundan sonra, "gereksinim" değil, kullanıcı hikayesi kelimesini kullanacağız. Muhtemelen "neden?" diye soruyorsunuz. Bu iyi bir soru. Sonsuza dek gibi görünen bir süre boyunca, bir müşteri tarafından bir yazılım projesinde ihtiyaç duyulan özelliklerin veya yönlerin belirtilmesi her zaman bir gereklilik olarak anılmıştır. Bu kelimenin Agile'da değeri olmayan bir yorumu var. Oxford sözlüğü bunu şöyle tanımlar:

İhtiyaç duyulan veya istenen bir şey. Veya, Zorunlu olan bir şey; gerekli bir koşul.

Ve ne yazık ki çözümümüzün ne olması gerektiğini tanımlarsak, işlerin “zorunlu” olduğunu söylersek, başımız belaya girer. Tüm bu kullanıcı hikayelerinin zorunlu olduğunu söylemek çok kolay. Bu görüşü benimsersek, belirli bir kapsamın tamamını sunma girişiminde zaman çizelgesini ve bütçeyi aşma riskiyle karşı karşıya kalırız. Bu ürün için bu hikayelerin çözümün uygulanabilir olması için gerekli olduğunu söylemek sorun değil, sadece o belirli kelimenin yorumlanmasından kaçınmak istiyoruz.

• Her zaman bir kişinin bakış açısından hikayeler yazın. Bir persona, çözümün bir kullanıcısını veya paydaşını temsil eder. Bir biriktirme listesine başlamadan önce bu kişiliği geliştirmek iyi bir fikirdir.
• Bu aşamada, yalnızca, zamanı geldiğinde kullanıcı hikayesi hakkında daha derin bir konuşma yapmak için temelde bir hatırlatma öneren kısa, basit ifadeler yazın.
• Gerçek insanlar, bir hedefe ulaşmak için yapmaları gereken görevler açısından düşünürler. Hikayelerinizi kişisel bakış açısıyla ve yapılması gerekenler açısından yazın.
• Birikmiş iş listesinin tamamını yazmanıza gerek yok - sadece müşterilerinizin ürününüzün uygulanabilir olması için ihtiyaç duyacağını hayal edebileceğiniz kadar yazın.
• Kullanıcı hikayelerinin değişeceğini, az çok önemli hale geleceğini veya tamamen silinebileceğini ürünün ömrü boyunca daha sonra keşfedeceksiniz. Sık sık serbest bırakmak, geri bildirim almak ve neyin öncelikli olduğunu değerlendirmek bu davranışı bilgilendirecektir.
• Ayrı ayrı hikayeler yazmayın. Ekibinizin, paydaşlarınızın ve hatta müşterilerinizin katılımını sağlayın. Hikayeler, bir projenin ömrü boyunca herhangi bir zamanda güncellenebilir, ancak üzerlerinde geliştirme çalışmaları başladıktan sonra değiştirilmemelidir.
• Bazı hikayeleriniz “destan” olarak kabul edilebilir. Bunlar, çok şeyi kapsayan büyük hikayelerdir ve teslimat zamanına daha yakın bir zamanda daha küçük hikayelere bölüneceklerdir.
• İyi bir kullanıcı hikayesinin kalitesini doğrulamak için bir kontrol listesi olan INVEST modelini kullanmayı düşünün.
• Herkes biriktirme listesine bir hikaye ekleyebilir. En alta veya özel olarak oluşturulmuş bir “otoparka” yerleştirilmelidir. Bu eklenen hikaye, ekip ve işletme ile tartışmak için bir uyarı görevi görür. İşletme ve ekip destekliyorsa, tahmin edilebilir ve önceliklendirilebilir
• Ayrıca sistemin en riskli kısımlarını da düşünebilirsiniz. Karmaşık, yeni veya teknik olarak bilinmeyen bir kullanıcı hikayeniz veya özelliğiniz varsa, bunları biriktirme listenizin en üstüne önceliklendirin. Bu şekilde, ürününüzün zorlu ve kritik kısımlarını ilk sürümünüzden sadece haftalar önce teslim etmeye çalışmayacaksınız.

İhtiyaçlarınızı karşılayan bir biriktirme listeniz olduğunda, içindeki hikayeleri tahmin edebilir, öncelik sırasına göre sıralayabilir ve bir yayın planı oluşturabilirsiniz.

Üst Düzey Tahmin ve Önceliklendirme

Üst düzey tahmin, biriktirme listenizi boyutlandırma işlemidir. Proje ne kadar “büyük” ve hangi değeri sağlıyor? Önceliklendirme, hangi hikayelerin sizin için en önemli olduğuna, ürünün uygulanabilirliğine ve müşterilerinizin çıkarlarına karar verme sürecidir. İşe en fazla değeri katmak için en yüksek değerli ürünleri erken teslim etmek, müşteriden geri bildirim almak ve küçük şeyleri dert etmemek istiyoruz. Çıktı, öncelik sırasına göre sıralanmış ve uygun şekilde boyutlandırılmış sıralı bir biriktirme listesi olacaktır.

• En üstteki hikayeler en değerli olarak kabul edilir. En değerli eşyaları mümkün olduğunca erken teslim etmek istiyoruz.
• Boyutlandırma ve tahminde bulunmak için pek çok teknik vardır, ancak bu noktada, yalnızca bir hikayenin boyutu hakkında iyi bir gösterge niteliğinde bir fikir elde etmek istersiniz.
  • Tişört bedenlerini, göreceli bedenleri, ideal günleri veya hikaye noktalarını kullanın.
• Bu noktada da mevcut tüm bilgilere sahip olmayacaksınız ve sorun değil. Sadece onunla koş.
• İş paydaşlarınızla veya varsa ürün yöneticinizle ve işi yapacak olan ekiple etkileşim kurun.
• Çalışmayı boyutlandırmak için tasarlayacak, geliştirecek ve test edecek kişilerin olmasını istiyoruz, çünkü tahmin edilecek en iyi kişiler uzmanlardır.
• Ekip, hikayeleri daha küçük parçalara ayırmaya başlayabilir. Bu olursa, daha ayrıntılı ama ayrık hikayeler yazın.
• Ekip ayrıca, teknolojiyi veya belirli bir kullanıcı yolculuğunu desteklemek için doğal olarak bazı şeylerin diğerlerinden önce teslim edilmesi gerektiğinden, bazı hikayeleri sıralamaya başlayabilir.
• Siz ve ekip arasında, biriktirme listesinde doldurulması gereken boşluklar bulmaya da başlayabilirsiniz. Sadece bu boşlukları yeni hikayelerle doldurun ve uygun şekilde tahmin edin ve önceliklendirin.
• Önceliklendirme, MoSCoW analizi kullanılarak en kolay şekilde gerçekleştirilir. MoSCoW, ürününüzün başarılı olması için hangi hikayelerin "olmazsa olmaz" olduğuna karar vermenize yardımcı olan basit bir tekniktir.
• Tahmin başlamadan önce bir önceliklendirme geçişi yapabilirsiniz. Bununla birlikte, belirli unsurların boyutlandırılması, öncelik ve gerçek iş değeri hakkında bir karar da belirleyebilir. Bu nedenle, tahmin ve önceliklendirmeyi birbirinden ayırın, ancak bunun üzerinde tartışmayın!
• Hiçbir iki hikaye diğeri kadar önemli olamaz. 1. sıradaki hikaye 2. sıradaki hikayeden daha önemli veya değerlidir.
• Bir hikayenin önemini veya değerini göstermenin harika bir yolu, ona parasal bir değer katmaktır. Örneğin, A hikayesinin 5000$ ekstra gelir getireceği düşünülüyorsa ve B hikayesi 100$ çekebilirse, o zaman A hikayesi daha değerlidir. Aynı şekilde, eğer C hikayesi işi D hikayesinden daha fazla kurtarıyorsa, C hikayesi daha değerlidir.
• Birikmiş iş listenizi boyutlandırdıktan sonra, bir numara ile kalacaksınız. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Küçük artışlarla çalışmanın büyük bir faydası vardır. Bu, yalnızca teslimatın yakın geleceğine odaklandığınız ve yeni girdiler, geri bildirimler ve öğrenme ile kısa bir yinelemeli döngü içinde değişime yanıt verebileceğiniz anlamına gelir.
• Sürümün başlangıcında bir sprint 0 gerçekleştirin. Bu, ekibin, işletmenin ve proje sürümünüzün hazırlanmasını sağlar ve başarılı teslimat için zihniyeti belirler. Sürümün temelini destekleyecek temel teknik çerçeveyi ve mimariyi çizin. Ortamları, hesapları ve araçları ayarlayın. Zor veya bilinmeyen sorunları anlamak için ani artışlar yapın. Kullanıcı hikayelerinizi sprint 1 için hazır hale getirin. Sprint 0, hazırlanmakla ilgilidir.
• Bir sürüm sırasında, biriktirme listesini hassaslaştırmaya devam edin. Daha fazlasını anladıkça veya yeni bir şey öğrendikçe, öncelikleriniz değişebilir, yeni gereksinimler ortaya çıkabilir ve daha önce harika bir özellik olduğunu düşündüğünüz özellikler tamamen kaldırılabilir.
• Bir sprint içinde tamamlama şansı olmayan işe başlamayın. Yapamıyorsa, daha küçük parçalara ayırın. Ve daha önce başlamış olan iş tamamlanmamışken yeni bir işe başlamayın. Tamamlanmış sayılamayacak pek çok şeye başlayarak hiçbir değer yaratamazsınız. Ayrıca, bağlam değiştirmeden kaçının. Bu, bir göreve başlama, rahatsız olma, başka bir işe başlama ve en sorunlu haliyle ikisini de tamamlamama etkinliğidir.
• Ekip tarafından herhangi bir zamanda devam eden iş miktarını sınırlayın. Örneğin, üç geliştiriciniz ve bir test kullanıcınız varsa, geliştiricilere ve test cihazına bir Devam Eden Çalışma sınırı koyabilirsiniz.
• Bir sprint planlandıktan sonra asla daha fazla iş eklemeyin. Bir sprint'i asla yarı yolda bırakmayın. Bunun istisnaları şunlardır:
  • Beklenenden daha hızlı performans gösterdiyseniz, uygun şekilde hazırlandığı sürece bir sonraki hikayeyi biriktirme listesinin en üstünden almayı düşünün.
  • Sprint o kadar kötü performans gösteriyorsa, tamamlanmayacaktır. Bu genellikle yalnızca bir tür felaketin olduğu durumlarda olur.
  • Sprint hedefi, işletmenin acil değişen ihtiyaçları nedeniyle artık desteklenemiyorsa.
• Bir sprinti iptal ederseniz, bunu zarif bir şekilde yapın, yeniden odaklanmak için zaman ayırın ve diğerleri gibi yeni bir sprint başlatın.
• Bir sürümün sonuna doğru, bir son sürüm sprintini düşünün. Hiçbir yeni özellik yazılmaz, bazı hatalar temizlenebilir ve ürününüzün yeni bir sürümünü müşterilerinize gerçekten sunmak için hazırlıklar yapılabilir. Bu, bu arada artımlı müşteri sürümleri yapamayacağınız anlamına gelmez - sadece bu kontrollü, ölçülü ve sürdürülebilir bir sürüm mekanizmasıdır.
• Bir sürümün sonunda, bir haftalık bir sürat koşusu düşünebilirsiniz. Bu sprintte, bazı yeni fikirleri parçalamak veya yeni teknolojiler bulmak için ekiple birlikte çalışabilirsiniz. Bunlar, işletmeye fayda sağlayan harika araçlardır ve ekibe düşünmeleri ve yaratıcı olmaları için brifing alanı sağlar. Şaka yapmak için değil ve yine de değer yaratacak. Aynı şekilde, herkesin bir molaya ihtiyacı vardır. Bu zamanda bir tatile çıkmak, yayının ortasındayken kadansınızı ve hızınızı iyi durumda tutmanıza yardımcı olur.

Tanımlama Bitti

“Yapıldı”nın gerçekten ne anlama geldiğini tanımlamak çok önemlidir. Projenizin ömrü boyunca "bitti"nin birçok versiyonu vardır - bir hikaye, yayın veya tüm proje ile "bitmiş" olmanın ne anlama geldiği. Her şey sizin, ekibinizin ve işinizin, sevkıyat hazırlığını tatmin etmek için doğru kalite düzeyinde eksiksiz olarak kabul edeceği şeye bağlıdır.

Ekibiniz için, "bitti" öyküsünün tanımı, tüm kodların eksiksiz olması, eş tarafından gözden geçirilmesi, tanımlanmış kabul kriterlerini karşılaması, birim test edilmesi, UAT'lenmesi ve kod deponuza gönderilmesi gibi bir şey olacaktır. Bir hikayenin tasarımcıdan geliştiriciye ve test edene geçmesini sağlamak için, "bitti" tanımlarının zincirdeki bir sonraki kişi tarafından kabul edilmesi gerekecektir. Ürün sahibiniz, ürün artımını müşterilerinize sunmak için bunun kendileri için ne anlama geldiğine dair beklentilere sahip olacaktır. Her halükarda, herkes “yapıldı”nın ne anlama geldiğinin farkında olmalı ve bu anlamın yerine getirilmesinde sorumlu taraf olmalıdır. “Bitti” tanımınızı tanımlayın, iletin, üzerinde anlaşın ve geliştirin. bitti.

Sürekli Ölçüm

Ölçemezseniz yönetemezsiniz. Aynı şey iyileştirmeler için de geçerli. Çevik bir projede ampirik veri toplama ihtiyacı, damarlarınızda kan akışının olması kadar hayatidir! Veri yoksa neyin yönetilmesi, düzeltilmesi veya iyileştirilmesi gerektiğini nasıl bilebilirsiniz? Basitçe söylemek gerekirse, inceleme altında oldukça hızlı bir şekilde dağılan içgüdüsel hislere ve doğrulanmamış tahminlere güveneceksiniz. Ve incelemeyi kimin yaptığına bağlı olarak, burası oldukça rahatsız edici bir yer olabilir. Bu nedenle projenizin başlangıcından itibaren, ilerlemeyi nasıl göstereceğinizi ve başkalarının başarınızı hangi ölçütlerle göreceğini bildiğinizden emin olun.

Neyse ki Agile, faydalı araçlar ve tekniklerle yüklü olarak geliyor. Yapılması gereken ilk şey, Çevik Manifesto'ya geri dönmek, aşağıdaki kelimeleri favori kelime işlemcinize yazmak, 96pt'e kadar üflemek, yazdırmak ve herkesin görmesi için duvara uygulamak:

Yazılım sağlamadaki en büyük gösterilebilir gücünüz, onu çalışan, yapması gerekeni yapan insanlara göstermektir. Bu sadece müşterilerinizi mutlu etmekle kalmayacak, aynı zamanda ekibinize büyük saygı duyacak ve işin daha fazla benimsenmesi için tekerlekleri yağlayacaktır.

İşte diğer bazı araçlar:

• Günlük stand-up: Bu törenin birkaç varyasyonu vardır, ancak esas olan tüm ekip üyelerinin birbirleriyle yüz yüze konuşmasını sağlamaktır: Kısa tutun, odaklanın ve hafif tutun. Herhangi bir şeyin uzun süre tartışılması gerekiyorsa, stand up'tan sonra ihtiyaç duyulanlar arasında daha uzun bir konuşma için park edin. Engeller ortaya çıkarsa, bunları bir hikaye gibi yazın, biriktirme listenize ekleyin ve en kısa sürede ele alın. Ekibinizi engelleyen herhangi bir şey ilerlemelerini yavaşlatır ve beklentileri karşılamayan azaltılmış hız ve yazılımda gösterilebilir.
• Hız: Tarihsel bir araçtır. Bu biraz, geçmişteki performansın gelecekteki performansın garantisi olmadığını söyleyen finansal uyarılara benziyor. Ancak Agile'ın durumunda, büyük ölçüde pürüzsüz bir ekip hızı elde etmeyi umuyoruz. Planlarımıza gelecekteki performansı ve güveni yansıtmamızı sağlayan hızdır. Kontrolünüz dışında, belirli bir sprint için hikaye puanı çıktısını azaltabilecek etkiler olabilir. Bu olursa, muhtemelen iyileşebileceksiniz. Takımınızı yenmek için hızı asla sopa olarak kullanmayın; sana hiçbir iyilik kazandırmaz. Kesin olan bir şey, hızın ilk 2-4 sprint için düzensiz olacağıdır. Yine de bu zaman diliminde bir yerde tutarlılık ve istikrar görmeye başlamalısınız. Hızınız bir uçtan diğerine dalgalanıyorsa, ekibinizle çözmeniz gereken bir sorununuz var demektir.
• İş bitim tablosu: Şimdi bu ilerleme ölçüsü çetrefilli. Bu nedenle, daha fazlasını öğrenmek için bir bağlantı vermedim - kendi araştırmanızı yapmanız ve sizin için çalışan bir ekip ve işletme olarak kabul etmeniz gerekecek. Dikenli olmasının nedeni? Dışarıdaki tek bir kaynak aynı hikayeyi anlatmıyor! Üzerinde anlaşmaya varılan bir şey, bir sürat koşusu veya bir sürüm içinde, zaman kutunuza karşı nasıl performans gösterdiğinizi göstermesidir. Günlük olarak bakımı yapılırsa, yolda olup olmadığınızı veya sapıp sapmadığınızı gösterecektir. Bazı takımlar bunu, yaratılacak ne kadar değer kaldığını göstermek için kullanır, çoğu zaman değil, diğerleri ise ne kadar işin kaldığını göstermek için kullanır. İlki başarı ve değer yaratmanın bir kutlamasıdır, ikincisi daha az ilham verici ve motive edicidir.
• İş bitirme çizelgesi: İş tamamlama oranlarını göstermeniz gerekiyorsa, bunun için iş bitim çizelgesini kullanın. Ancak tükenmişlik grafiğini kullanmak, ne kadar değer yaratıldığını ve sprint sonunda ne kadar daha fazla değer yaratmayı planladığınızı göstermenize olanak tanır. Bir ekibin hem ne yapıldığını (ya da işler o kadar iyi gitmiyorsa çok azını…) hem de gözlerinin neye dikildiğini işletmeye göstermesi için çok daha motive edici bir araç. Her durumda, ilerlemenin beklendiği gibi izlenmediği yerleri belirlemek için çizelgeleri kullanın ve kalıpları veya sapmaları arayın ve temel sorunu mümkün olan en kısa sürede düzeltmek için bunların üstesinden gelin. Bunları sprintler için günlük olarak ve sürüm sürüm çizelgeleri için bir sprint sonunda bir kez güncelleyin.
• Görev panoları: Bunlar, yaratılan değeri göstermek için harika görsel radyatörlerdir. Günlük olarak veya günün herhangi bir noktasında güncellendiğinde, ilerleme kaydedildiğini hemen gösterirler. Kanban ile birleştirildiğinde, sistemdeki akışı ve tıkanıklıkları görselleştirmek için de harika araçlardır. Pek çok geliştirmenin tamamlandığını ancak testlerin o kadar üretken olmadığını görüyorsanız, sorunun oluştuğunu görebilir ve uygun ve hızlı bir şekilde yanıt verebilirsiniz.

Göz önünde bulundurulması gereken diğer araçlar, Çevik kazanılan değer, döngü süresi ve kümülatif akış diyagramlarıdır (CFD'ler).

Bu önlemleri, çizelgeleri ve diğer araçları görünür, tercihen yüksek sesle ve herkesin görmesi için bir duvarda tutun. Ekip, paydaşlar ve diğer ilgili taraflar bir projenin durumunu anında görebilir. Şeffaftır ve değerli bir iletişim aracı olarak hizmet eder. Bu eserleri duvara asamıyorsanız, paylaşılabilir ve ortak çalışmaya dayalı araçlar kullanın ve erişmek isteyenlerin buna sahip olduğundan emin olun.

Devamlı gelişme

Çevik yaşamınız boyunca, iyileştirmelerin nerede yapılabileceğini belirlemeye ve öğrenmeye çalışın. Dersler bir projenin sonunda yakalanmaz ve öğrenilmez. Bu, sürüş testinizi geçmek ve ilk sürüşünüzü eğitmen olmadan geçici olarak almak gibidir. Neyin işe yaradığını ve ne yapmanız gerektiğini bileceksiniz, ancak zamanla yeni teknikler öğrenerek sürüş beceri ve yeteneklerinizi özelleştireceksiniz. Hatta kötü alışkanlıklar edineceksin. Onları arayın, anlayın ve iyileştirmenin yollarını bulun.

Neyin işe yaramadığını belirlemek ve çareleri uygulamak için birçok fırsat vardır. Agile'da buna yerleşik yaklaşım retrospektiftir. Bu, yansıtma ve ayarlama için birincil araçtır. Her sprintin sonunda, işin nasıl yapıldığını, kalitenin nasıl sağlandığını, verimliliğin nasıl en üst düzeye çıkarılabileceğini, israfın nasıl en aza indirilebileceğini ve kapasitenin nasıl artırılacağını geliştirmek için ekiple zaman ayırın. İyileştirme önlemlerini belirlediğinizde, tüm sorunlarınızı hemen çözmeye kalkışmayın. En fazla etkiye sahip olacak ve bir sonraki sprintte uygulanabilecek olanları belirleyin. Ölçün ve gözlemleyin. İstenen etkiyi yarattıysa, kilitleyin, çalışma yöntemlerinize ve yapılan tanımlarına yazın. Eğer işe yaramazsa, tekrar düşünün. Yaklaşan sprint'e dahil edilmeyen öğrenilen dersler, bir sonraki sprint'te dikkat çekmek için park edilebilir ve önceliklendirilebilir.

Süreci uyarlayın. Çalışmayan her şeyi kaldırın. Engelleri kaldırın. Çevik bir ekip olarak olgunluğunuz, izin verirseniz sınır tanımaz.

Çevik Proje Yönetiminin Ötesinde

Proje teslim edildikten sonra ne olacağını bilmek önemlidir. Destek ve bakım, proje müşterilerin eline geçtiğinde performansının devam etmesini sağlamanın anahtarıdır; müşteri geri bildirimi gelecekteki sürümlere dahil edilebilir; ve müşteri sorunları uygun şekilde ele alınır. Bir proje benzersiz, zaman kısıtlı bir çabadır. Teslim ettiği ürün, proje ekibinin dağılmasından sonra bir ömre sahiptir. Ürün kullanıma sunulduktan sonra destekleyebildiğinizden emin olun.

Çevik projeler daha geleneksel yaklaşımlarla birlikte var olur. Bütçe kontrolü ve paydaş görünürlüğü gereksinimleri ile Çevik esneklik ve yanıt verme amaçlarını dengelemek.

Bir yönetişim çerçevesi veya Çevik yönetişim modeli, Scrum gibi standart bir Çevik süreçlerle birlikte kullanılır. İki özel yolla çalışırlar:

• Geliştirme yinelemelerinin (sprintler) dışında meydana gelen süreçleri açıklayarak Çevik bir proje için bir sarmalayıcı sağlarlar. Bu, proje başlatmanın başarılı bir şekilde tamamlanması ve kararların ve planın uygun şekilde doğrulanması için net kriterler sağlamayı içerir.
• Standart Çevik sürecin belirli bölümlerinin vurgusunu değiştirirler ve yönetişime ihtiyaç duyan veya yönetişimi destekleyen belirli ilke ve teknikleri vurgularlar.

Günümüzün sürekli değişen dünyasında, kuruluşlar ve işletmeler, projeleri teslim etmek için daha esnek bir yaklaşım benimsemeye ve daha Çevik olmak istiyor. Ancak, projeler ve programlar sunan ve mevcut resmi proje yönetimi süreçlerinin halihazırda mevcut olduğu kuruluşlar için, Çevik yaklaşımların çoğunun kayıt dışılığı göz korkutucudur ve bazen çok riskli olarak algılanır. Bu proje odaklı kuruluşlar, olgun bir çevik yaklaşıma - proje teslimi kavramı içinde çeviklik - Çevik proje yönetimine ihtiyaç duyar.

Çevik'i benimsemenizle öğrenin ve büyüyün. Yalnızca ekibinizin rahat ettiği şeyi yapın, seslerinin duyulduğundan emin olun ve istekleri doğrultusunda hareket edin. Ekibinizi, zamanı geldiğinde yeni ve daha değerli teknikleri benimsemeye teşvik edin. İşletmeyle pazarlık yapın ve onları Çevik bir organizasyon olmanın ne anlama geldiğini anlamaları için teşvik edin.

Yolculuğun tadını çıkarın.