Solo Geliştirici için Çevik

Biri Çevik süreç kavramlarını solo geliştirici olarak nasıl uygular? Agile, uygulamaları daha hızlı bir şekilde geliştirmek için faydalı görünüyor, ancak aynı zamanda ekip odaklı da görünüyor ...

• Test odaklı geliştirme yaparak
• Küçük sprintlerde gelişerek
• Müşteriyle çok fazla iletişim kurarak

Kovboy Geliştirme hakkında bir tez okuduğumu hatırlıyorum, bu solo geliştiriciler için çok çevik, ama nerede bulduğumu hatırlayamıyorum.

Klez'in cevabına ek olarak (tüm iyi öneriler), şunları öneriyorum:

• Ürün biriktirme listesi tutma
  Ürün biriktirme listesi, temel olarak, bu ürün için bir aşamada tamamlamayı düşündüğünüz tüm öğelerin bir listesidir.
• Sprint yakma ve ürün yakma işlemlerini sürdürme
  Sprint yakma işlemi, bu sprintte tamamlamaya karar verdiğiniz tüm görevlerin bir listesiyle başlar (belirli bir süre boyunca tamamlanmak üzere ürün birikiminizin bir alt kümesi - örneğin 2 hafta) Gerekli işin tahmini. Bir şeyleri işaretlerken, onları olduğu gibi işaretlersiniz; böylece o sprint için kalan işi azaltıyor (veya yakıyor).
  Benzer şekilde, bir ürün kaybı, tüm ürün birikimi için kalan işi izler
• Göreceli tahmin ve hız kavramlarını benimsemek
  Göreceli tahmin, diğer görevleri (veya hikayeleri) rehber olarak kullanan bir tahmin tekniğidir. Örneğin, A görevinin B görevinden daha kolay olduğunu ve C görevinin iki katı kadar karmaşık olduğunu biliyorsanız, A görevinin "puanlarının" bu beklentilere göre doğru olduğundan emin olursunuz.
  Vurgu, gerekli iş miktarını doğru tahmin etmekten ibaret değil, tahminleri birbiriyle tutarlı tutmak.
  Hız, bir sprint içinde kaç tane "puan" aldığın ölçüsüdür. Göreceli tahmininiz tutarlılık sağlıyorsa, bu hız yaklaşan sprintlerde hangi işleri yapabileceğinizi tahmin etmek için kullanılabilir. Bu hızın sürekli revize edilmesi gerektiğine dikkat edin.

• Limit çalışmaları devam ediyor (zaman boksuna ek olarak). Bir yineleme yöntemi kullanıyor olsanız bile (Kanban'ın aksine), hızınızın yineleme başına 8 puan olduğunu varsayalım. Aynı anda 8 üzerinde çalışmaya başlama. WIP'i hem hikaye sayısı hem de hikaye puanı ile sınırlamak gayet iyi.
• Tüm kullanıcı öyküleriniz için otomatik kabul testlerini yapın. Genel olarak mümkün olduğunca otomatikleştirin.
• Kullanıcı hikayeleri çok küçük yapma tarafında Err. Genel bir kural olarak , en büyüğün en küçüğüne oranını 3: 1 yapın . Scrum'da bir hikayeyi küçümsüyorsanız ve çok büyük çıkıyorsa, birden çok geliştirici onu tekrar izlemek için parçalayabilir. Ama senin yeterince insanın yok.
• Düzenli bir takım bağlamında, bir kullanıcı hikâyesinin yükselişini ayırmaktan çekinmeyin - solo veya küçük takım bağlamında, herhangi bir tereddüt etmeden başak yapmak. Bu, hikayeleri daha küçük ve daha öngörülebilir tutmaya yardımcı olur.
• Retrospektifler genel olarak çevik olarak önemlidir, bu nedenle Kanban (ki bu Kişisel Kanban olacaktır) burada daha fazla puan alıyor, çünkü geriye dönük süreci daha fazla veri odaklı. Yeterli insanınız olmadığında Triple Nickels oynamak zor.

Bu şeyler muhtemelen hem solo hem de küçük takım (2 veya 3 geliştirici) durumu için geçerlidir.

EKLENDİ: Bir ara bu cevabı yazdıktan sonra, bu konferans konuşmasını buldum ve çok etkilendim: Kişisel Kanban: Bireysel Kodlayıcıyı Optimize Etme

• Ya iyi tanımlanmış sprintler için çalışın ya da kasıtlı olarak bir Kanban yaklaşımı seçin. Yanlışlıkla Kanban'a gelme.
• İlk önce böcekler, ikinci özellikler.
• Yine de Değere karşı özellik bloğuna odaklanın. (Altın Kaplama Üzeri YAGNI)
• Retrospektifler de aynı derecede değerlidir. Ve en önemlisi, küçük parçalarda işlem değişiklikleri yapın. Bugün ATM sunacak herhangi bir harici özelliğiniz yoksa, tek seferde TDD, Mock ve IoC'ye başlamaya karar vermeyin. Her seferinde bir tane getirin.

Sonuç olarak, Agile'yi “ekibiniz ve müşteriniz için anlamlı kılan şeyleri yapmak ve eski uygulamalara bağlı kalmak değil, geçmişte çalışmış gibi göründüğü için olduklarını” gerçekten tanımladım.

Çevik, ekipler için olduğu kadar bireyler için de işe yarar. Sizin için işe yarayan bir süreç bulma ve projeniz başladıktan sonra değişen koşullara uyum sağlamanıza izin verme ile ilgilidir. Ayrıca, yazılımın gerçekten "bitmiş" olup olmadığına bakılmaksızın, müşterinize düzenli olarak değer sunmakla da ilgilidir.

Çevik süreçler oldukça yinelemelidir. İş kısa TimeBox / sprints / cycles / iterations yapılır. Bazı tasarım çalışmaları önceden gerekli olabilir, fakat ne yapmanız gerektiğine dair daha fazla şey öğrendiğiniz için yeniden kontrol edilebilir. Birim testi, neredeyse tüm Çevik geliştirme yöntemlerinin bel kemiği olup, yazılımınızın çalışıp çalışmadığını ve yazılımınıza yapılan eklemelerin / değişikliklerin mevcut kod tabanını kıracağını gösterir.

BDD / TDD'ye bağlı kalırsanız, gereksinimlerinizin rüzgarla değişmesine izin verin ve özellik önceliklerini buna göre ayarlayabilir, tüm sisteminizi kurar ve tüm testleri sık sık çalıştırırsanız ve her sprintin sonunda çalışma kodu verirseniz , sen zaten çeviksin.

Vay. Başım beladayken çağırabileceğim bir arkadaşımı kancada tutmaya çalışırdım - ve kodlama probleminden konuşurdum. Ne demek istediğimi ... yüksek sesle bir sorunu açıklayan sadece hareket için bir çözüm getiriyor biliyorum benim zihin zaman% 90.