Çevik sadece küçük şelaleler değil mi?

Projelerimde şelale metodolojisini daha çok kullandım, ama şimdi ufkumu çevik metodolojilere genişletiyorum. Şimdiye kadar okuduğum kadarıyla ve belki de yanlış şeyleri okudum, çevik küçük şelaleler anlamına gelir. Bir ya da iki yıla yayılmış büyük bir şelale yerine, geçen haftalar ya da belki de en fazla birkaç ay süren küçük şelaleler var.

Anlayışım doğru mu veya bundan daha fazlası var mı? Çevik felsefeler nelerdir?

Basit bir seviyede, evet. Sadece her iki haftada bir bir Şelale yapmak sizi çevik yapmaz , ama yinelemelidir (çevikliğin yarısıdır).

Şelale modeli aşamaları tanımlar - gereksinimler, mimari, tasarım, uygulama, doğrulama (test), doğrulama (kabul testi) ve serbest bırakma. Herhangi bir yinelemeli metodolojide, bu aşamaların her birini her yinelemede geçirirsiniz. Aralarında çakışma olabilir, ancak gereksinimleri ortaya çıkarır ve yakalarsınız, uygulamaya izin vermek, yeni özellikleri geliştirmek veya hataları düzeltmek, yeni modülleri test etmek ve ardından kabul için müşteriye sunmak için sistemin mimarisini ve tasarımını benimsersiniz. test ve dağıtım.

Bununla birlikte, çevik olmak için yinelemeli ve artımlı olmaktan çok daha fazlası var. Agile kiracıları Agile Yazılım Geliştirme Manifestosunda yakalanır . Bildiride dört ana nokta vardır:

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

Bireysel insanları sık sık dahil ediyorsunuz. Birçok uygulama kendi kendini organize eden ve kendi kendini yöneten takımlar etrafında toplanmıştır. Neredeyse hepsinin müşteriyle veya müşterinin sesi olan biriyle sık sık etkileşimi vardır. İzlenecek resmi prosedürler ve kullanılacak araçlara sahip olmak yerine, proje üzerinde çalışan kişilerin, projenin mümkün olan en iyi şekilde yapılmasını sağlamak için nasıl yapıldığını yönlendirmesine izin veriyorsunuz.

Kapsamlı belgeler üzerinde çalışan yazılımlar

Bir yazılım projesinde, birincil amaç yazılımın teslim edilmesidir. Bununla birlikte, bazı projelerde, değer katmayan belgelerin savurgan üretimi vardır. Scott Ambler, Çevik / Yalın Belgeler hakkında iyi bir makale yazdı . Bu dokümantasyon üretmek değil, ekibinize, gelecekteki geliştiricilere, müşteriye veya kullanıcıya değer katan dokümanları seçmekle ilgilidir. Yazılım mühendisleriniz değer katmayan belgeler üretmek yerine, yazılım ve ilgili testler üretiyorlar.

Sözleşme görüşmesi üzerinden müşteri işbirliği

Şartlar ve zaman çizelgeleri ve maliyetleri önceden tanımlamak yerine, müşteri ile sürekli bir çaba haline gelir. Örneğin, gereksinimlerinizi kullanıcı hikayeleri biçiminde yakalayabilir ve onlara puan atayabilirsiniz. Birkaç tekrardan sonra bir hıza (puan / yineleme) karar verirsiniz ve ekibinizin bir yinelemede kaç özellik uygulayabileceğini belirleyebilirsiniz. Müşteriniz hangi özelliklerin en fazla katma değer sağladığına dair geri bildirim sağladığı için projenin ne zaman tamamlanacağına karar verebilir. Sık teslimat ve müşteri etkileşimi ile çok sayıda şey olabilir - gereksinimler karşılandı ve proje bakım ve sonunda kullanım ömrü sona erdi, müşteri, düşündükleri her şeye ihtiyaç duymadıklarını ve bu nedenle proje başarısız oluyor ve müşteri bunu erken görüyor ve iptal edebiliyor ...

Bir planın ardından değişime tepki vermek

Önünüzde büyük bir tasarım ya da nihai planınız yok ve bu tasarım ya da planın değişmesi gerektiğinde yeniden çalışma yapmak zorundasınız. Sahip olduğunuz bilgilere dayanarak tahminleri sürekli olarak tahmin edip revize edersiniz. Metriklerinizi, projenin sağlığı ve ne zaman şirket içi değişiklikler yapılacağı konusunda fikir vermek için dikkatlice seçersiniz. Sık sık müşteri ile gereksinimleri ekler, kaldırır ve önceliklendirirsiniz. Sonuçta, değişimin tek sabit olduğunu anlıyorsunuz.

Çevik olmak, yüksek kaliteli, katma değerli yazılımları hızlı bir şekilde sunarak insanlara odaklanmak ve ihtiyaçlarını karşılamak anlamına gelir. Müşterinin ihtiyaçları değiştikçe, değer katmaya odaklanmak için bu ihtiyaçlara uyum sağlarsınız. Çevik metodolojilerin belirli uygulamaları vardır, ancak hepsi insanlara, çalışma yazılımının zamanında teslimine ve hızla değişen bir ortama uyum sağlamaya odaklanmıştır.

Evet ve hayır - asıl süreç bir dizi küçük şelale olarak görülebilir, ancak fark, sürecin tüm ekibin (dev, qa, iş vb.) Girişinden geriye dönük olarak gelişmesi ve geliştirilmesidir. sorunlara tepki verebilen ve doğru bir şekilde planlayıp teslim edebilen çok daha sıkı bir üniteye. Burada aşırı derecede basitleştiriyorum, çok daha fazlası var, ama bunun kötü bir başlangıç ​​noktası olduğunu düşünmüyorum.

Bunu söylemenin basit bir yolu olduğunu söyleyebilirim. Evet, aşağı indiğinizde küçük su akışları var, ancak arkasında çok daha fazlası var. Projelere yaklaşımınızı değiştiren tüm bir metodoloji ... Bunun için gereken zihniyetten bahsetmiyoruz bile.

Agile konusunda ciddiyseniz, ilginizi çekebilecek iyi (ve uzun) bir dizi web yayını:

http://autumnofagile.net/

Çevik bir anı unutun, "şelale" ile ne kastedildiğini düşünün.

Herkesin, nihai ürünün çözmesi gereken NE problemlerini anlamaya çalıştığı bir gereksinimler aşaması vardır. İnsanlar bir süre bunun hakkında tartışırlar ve sonra hepsi bir dizi gereksinime imza atarlar. Bu noktada kapsamınız tanımlanır, sözleşmeler imzalanır ve müşteri uzaklaşıp tanımlanmış gereksinimleri karşılayan bir ürün bulmanızı bekleyebilir.

Sonra bir (veya belki iki) tasarım aşaması vardır. Tasarımcılar (geliştiriciler olabilir veya olmayabilir), sistemin imzalanmış gereksinimleri karşılamak için NASIL birlikte gitmesi gerektiğini tartışırlar. Bir gereksinimi tam olarak anlamadıklarında sorunlar ortaya çıkabilir, bu da müşteriye geri dönmeleri, potansiyel olarak gereksinimler aşamasını yeniden açmaları (ve başka bir oturum kapatma turu almaları) veya en azından değişiklik yönetimini eyleme geçirmeleri gerektiği anlamına gelebilir. . Çoğu zaman, tasarımcılar sadece en iyi tahminlerini yaparlar. Mantıksal bir veri modeli ve yeni bir sistemi ve nasıl çalışması gerektiğini tanımlayan birçok UML ortaya çıkarabilirler. Sonra imzalarlar.

Şimdi geliştiriciler imzalı tasarıma dayanarak kodlamaya başlayacaklar. Tasarımı tam olarak anlamadıklarında sorunlar ortaya çıkabilir, bu da tasarımcıya geri dönmeleri, potansiyel olarak tasarım aşamasını yeniden açmaları (ve başka bir oturum kapatma turu almaları) veya en azından değişiklik yönetimini eyleme geçirmeleri gerektiği anlamına gelebilir. . Tasarımcılar buna karşılık karışıklığın gerçekten gereksinimlere geri döndüğünün farkına varabilir, yani gereksinim tartışmalarını, imzaları ve daha fazla değişiklik yönetimini yeniden açmak zorunda kalırlar. Genellikle, son teslim tarihi olan programcılar en iyi tahminlerini yaparlar. Fonksiyonel kod yapmak için ellerinden geleni yaparlar. Sonra test için serbest bırakırlar.

Şimdi sistem test aşaması devreye giriyor. Test ediciler, gereksinimleri ve tasarımı anladıklarına göre test ediyorlar ve kusur olarak algıladıkları şeyi bir hata izleme / değişim yönetim sistemine kaydediyorlar ve sorunu görmedikleri sürece geliştiricilerin tekrar gelişmeye başlamasına neden oluyorlar. tasarım kusurlarını geri gönderen bir tasarım hatası vb. Sonunda sistem testleri geçer ve kapatılır.

Son olarak, müşteri geri döner ve yeni sistemde kullanıcı kabul testleri yapar. Testçilerin test ettiği çözümün, geliştiricilerin geliştirdiği ve tasarımcıların tasarladığı çözümün aslında istedikleri şey olduğuna karar verdikleri yer burasıdır. Değilse, potansiyel olarak tasarım aşamasına geri dönmeniz veya gereksinimleri tekrar ziyaret etmeniz gerekir.

Şelalenin arkasındaki fikir, bir aşama tamamlandıktan sonra geri dönmenin zor (ve çok istenmeyen) olmasıdır. Farklı insanlar genellikle farklı aşamalarda yer alır, bu nedenle her biri yanlış yorumlama ve bilgi kaybı için çok fazla risk oluşturan birden fazla elden çıkarma vardır. Müşterilerin ne istediklerini söyledikleri ile nelerin inşa edildiğini gördükleri zaman arasında gerçek gereksinimlerin çok iyi değişmiş olabileceği arasında da önemli bir boşluk vardır.

Çevik yöntemler, ilgili tüm taraflar arasında güçlü iletişim ve işbirliğine odaklanır. "Sözleşme görüşmesi üzerinden müşteri işbirliği" ilkesi, bir dizi imza ve teslimden geçmemeniz gerektiği anlamına gelir, bunun yerine müşteriyle birlikte çalışmalıdır, her bir yineleme bulmacanın bir parçası için gereksinimleri belirler ve tüm oyuncular mümkün olduğunca doğrudan iletişim kurarak (elden çıkarma maliyetlerini ve risklerini ortadan kaldırarak) testler, bir tasarım ve çalışma kodu oluşturmak. Çalışma kodu müşteri tarafından hızlı bir şekilde test edilebilir ve gecikme risklerini ortadan kaldırır. Tüm faaliyetler aşağı yönlü bir akışta değil, işbirlikçi bir girdapta gerçekleşir.

Çevik yöntemlerin ne yapmaya çalıştığına dair mükemmel bir genel bakış için, Allistair Cockburn'un Çevik Yazılım Geliştirme: İşbirlikli Oyun'u kesinlikle tavsiye ederim .

Evet, bu aşağı yukarı doğru. Bunun nasıl yapılacağı hakkında çok şey yazıldı ve tartışıldı, ancak bir sürü küçük şelale bunun en önemli noktası.

Bir grup küçük şelalenin nasıl kullanılacağına dair özel bir uygulama olsa da önemsiz değildir. Örneğin, birkaç yıl içinde büyük projeler yapmaktan, bir dizi küçük proje yapmaya geçmeyeceksiniz. Buna 1-2 yıl değerinde büyük bir proje var. Bu yüzden büyük projeyi bir dizi küçük projeye ayırmanız gerekiyor. Bu oldukça açık görünebilir, ancak sayfaları ve kitap sayfalarını doldurur.

Bu doğru mu yoksa bundan daha fazlası var mı

Her ikisi de. Evet, bu kavramın doğru bir özetidir, ancak özetlenecek çok fazla ayrıntı vardır. Yani, planlamanın hemen hemen her yönü, gelecek yıl yerine sadece bir sonraki hafta için planlama yaptığınızda değişir.

Çevik bir projenin statik yapısına (süreç tanımı) bakarsanız, birçok küçük şelaleye benziyor evet. Ancak çevik bir projenin amacı daha hızlı ve daha iyi geri bildirim almaktır .

• Yazılımınızın hala çalışıp çalışmadığını hemen bilmek için test odaklı geliştirme yapıyorsunuz
• Bir müşteri yerinde ve ne zaman bittiğini bilmek için kabul testleri yapar
• Prosesinizi neyin iyi neyin iyi gitmediğine göre ayarlamanız için geriye dönük bakışlarınız var.

Çevik manifesto vurgular (imzalı olanların algıladığı gibi) çevik ve şelale arasında bazı farklılıklar.

Gerçekten "çevik" genellikle hafta değil, 1-2 günlük şelaleler anlamına gelir. Bu, genel bir planı takip etmediğiniz ve gerçek serbest bırakma döngülerinin 1-2 gün olduğu anlamına gelmez. Ancak her gün çalışan, test edilmiş bir ürün elde etmeye çalışmalısınız ve bunu teorik olarak her gün serbest bırakabilirsiniz.

Scrum, örneğin, 4 haftalık sprintler kullanır, ancak bir sprint sadece bir şelale değildir (en azından olmamalıdır). Sprint başlangıcında bir şeyin planlandığı gibi gitmediğini gördüğünüzde her gün öncelikleri değiştirebilirsiniz.