Çevik - Sivri Uçlar ve Genel Zaman Çizelgesi

Takım ilk sermayesi-Agile projesine başlıyor ve proje, metodolojiyle güzelce uyumlu olacak gibi görünüyor (yani, sadece çevik bir kitap alabilir ve bir tarif gibi takip edebiliriz), bir miktar karışıklık ile:

Proje, ekipte kimsenin deneyimlemediği üç şey içeriyor: Foo Bordro Sistemi ile entegre edin, XYZ89 dosya türünü (burada "XYZ89" = hiç duymadığınız bir dosya türü) işleyebilir ve bazılarını dönüştürebilirsiniz diğer dosyaları Frobnobdicator tarafından ele alınabilir.

Anladığım kadarıyla, standart Agile uygulaması, bunların her biri için ani artışlar planlamak olacaktır, bundan sonra ne kadar süreceklerini belirleyebiliriz (müşterinin yapmamaya karar vermesinin bir şansı olduğundan emin değilim projenin hemen hemen sağlam gereksinimleri olduğu için)

Yani sorularım:

1. Bunları yapmak ve / veya "yürüyen bir iskelet" in çalıştırılması için gereken süreyi daha iyi tahmin etmek için ilk yinelemede tüm ani artışları yapıyor muyuz?

2. Değilse, toplam proje programı, bu özel hikayenin basketbol sahamızdan daha uzun süreceği verilerle geri dönen bu sivri uçlardan birinin insafına olmaz mı?

Temelde bir projenin müzakere edilemez gereksinimleri olduğunda birden fazla ani artışla başa çıkmanın en iyi uygulama yolu nedir?

Daha önce proje planımda bu gölgeli bilinmeyenleri ele alma şeklim, geliştirme ekibinin bilinmeyen işlevsellik prototiplerini önceden yapması için zaman ayarlamaya çalışmaktır. Bu, özel görevleri yapmak için neyin gerekli olacağını açıkça bilmenin yararını sağlar, bunların teknik olarak uygulanabilir olduğunu kanıtlar ve aktif gelişim başladığında önlemek için takımın geri kalanını olası tuzaklar hakkında eğitir.

Bu yüzden birçok Agile projesi genellikle, ne demek istediğim Sprint 0 ile başlar .

Bunu, bir maratona başlamadan hemen önce koşu ayakkabılarınızı bağlamak, esnemek ve meme uçlarınıza bandaj koymak olarak düşünün. Bu süre, ilk proje planlama ve kullanıcı hikayesi oluşturma, tasarım ve mimari sunumunu, yazılım çerçevesi oluşturma işlemini yapmak için kullanılabilir ve geliştiriciler, herhangi bir yeni teknoloji veya kullanıcı hikayesi noktası yapacak bilinmeyen teknik zorluklar için herhangi bir prototip ve kavram kanıtı üzerinde çalışabilirler. tahmin çok daha kolay.

İşleri, ürün sahibi (veya müşteri) tarafından belirlenen öncelik sırasına göre yapmalısınız. Kendinizi gerçekten güzel bir şey üzerinde öldürmenin bir anlamı yok. Fikir şu ki, zamanınız biterse ve bir şey yapılmazsa, en düşük öncelikli öğeler olmalıdır.

Eğer istediklerine öncelik vermezlerse, mücadele edeceksiniz.

Eğer işler nispeten eşitse, en zor öğeyle başlamayın - takıma yeni metodolojiyi ve müşteriyi bu şekilde teslim edebileceklerine biraz güvenerek birlikte çalışmaya alışma şansı veren kolay bir kazançla başlayın. Bir kez kurulduktan sonra, zor bir şeyle başa çıkın. Zor öğenin karmaşıklığını, daha önce yaptığınız daha kolay şeylerin karmaşıklığına karşı ölçün ve bu işlemin ne kadar sürebileceği hakkında bir fikir edinmeye başlayacaksınız.

Karmaşık öğeler gerçekten "sivri" değildir. Bunlar basitçe anlaşılması daha fazla çaba gerektiren şeyler. Onları olabildiğince basit görevlere bölün.

Olası bir çözüm, oyuncak sorunun nasıl çözüleceğini ve zaman kutusunu nasıl çözeceğini anlamak için bir kavram kanıtı yapmak için bir görev oluşturmaktır, daha sonra bu hikayeyi diğer hikayelerle bir sprint'e eklemek.

Bir hack konsolu uygulaması olsa bile, sprint sonunda eşik değeri ve bir ürün sunuyorsunuz. Fikir, tüm ekibin verimliliğini batırmamanızdır, eğer zamanınız biterse, bir sonraki sprint'e benzer bir görev daha eklersiniz.