Solo Geliştirici için Çevik

Klez'in cevabına ek olarak (tüm iyi öneriler), aşağıdakileri öneririm:

• Bir ürün biriktirme listesi tutma
  Ürün biriktirme listesi temel olarak bu ürün için belirli bir aşamada tamamlamayı planladığınız tüm öğelerin listesidir.
• Sprint ve ürün burndown'larını korumak
  Bir sprint burndown, bu sprint'te tamamlamaya karar verdiğiniz tüm görevlerin (belirli bir süre içinde tamamlanacak ürün birikiminizin bir alt kümesi - örneğin 2 hafta) bir listesiyle başlar. gerekli iş. Bazı şeyleri işaretlediğinizde, bunları tamam olarak işaretlersiniz; böylece o sprint için kalan işi azaltır (veya yakar).
  Benzer şekilde, bir ürün geri dönüşümü, tüm ürün biriktirme listesi için kalan işleri izler
• Bağıl tahmin ve hız kavramlarını benimsemek
  Göreceli tahmin, diğer görevleri (veya öyküleri) kılavuz 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 "noktalarının" bu beklentilere göre doğru olduğundan emin olursunuz.
  Vurgu, gereken iş miktarını doğru bir şekilde tahmin etmek değil, tahminleri birbiriyle tutarlı tutmaktır.
  Hız, bir sprint'te kaç "puan" yaptığınızın bir ölçüsüdür. Göreceli tahmininiz tutarlılığı sağlıyorsa, bu hız gelecek sprintlerde hangi görevleri yapacağınızı tahmin etmek için kullanılabilir. Yine de bu hızın sürekli olarak gözden geçirilmesi gerektiğini unutmayın.

• Devam eden işi sınırlandırın (zaman boksuna ek olarak). Yinelemeli bir yöntem kullansanız bile (Kanban'ın aksine), diyelim ki hızınız yineleme başına 8 puan. Tüm 8 üzerinde aynı anda çalışmaya başlamayın. Devam Eden Çalışma'yı öykü sayısına veya öykü sayısına göre sınırlamak iyidir.
• Tüm kullanıcı hikayeleriniz için otomatik kabul testlerine sahip olun. Genel olarak mümkün olduğunca otomatikleştirin.
• Err kullanıcı hikayeleri çok küçük yapma tarafında. Genel bir kural olarak, en büyük hikayenin en küçük hikayeye oranı 3: 1. Scrum'daki bir hikayeyi hafife alırsanız ve çok büyük çıkarsa, birden fazla geliştirici onu tekrar izlemek için sürülebilir. Ama yeterli insanınız yok.
• Düzenli büyüklükte bir ekip bağlamında, bir kullanıcı hikayesinden bir ani bölünme olup olmadığını tereddüt ederseniz - solo veya küçük ekip bağlamında, ani tereddüt etmeden yapın. Bu, hikayelerin daha küçük ve daha öngörülebilir olmasına yardımcı olur.
• Retrospektifler genel olarak çevik olarak önemlidir, bu nedenle Kanban (Kişisel Kanban olacaktır) burada fazladan puan alır, çünkü retrospektif süreci daha fazla veriye dayalıdır. Yeterli sayıda insan olmadığında Üçlü Nikel oynamak zor.

Bunlar muhtemelen hem solo hem de küçük ekip (2 veya 3 geliştirici) durumları için geçerlidir.

EKLENDİ: Bu cevabı yazdıktan bir süre sonra, bu konferans konuşmasını buldum ve çok etkilendim: Kişisel Kanban: Bireysel Kodlayıcıyı Optimize Etmek

• Ya iyi tanımlanmış sprintler için çalışın ya da kasten bir Kanban yaklaşımı seçin. Yanlışlıkla Kanban'a gelme
• Önce böcekler, ikinci özellikler.
• Yine de Değer ve özellik şişkinliğine odaklanın. (Altın Kaplama Üzeri YAGNI)
• Retrospektifler de aynı derecede değerlidir. Ve en önemlisi, küçük parçalar halinde süreç değişiklikleri yapın. Bugün ATM teslim edecek harici bir özelliğiniz yoksa, TDD, Mock ve IoC'yi tek seferde kullanmaya başlayacağınıza karar vermeyin. Her seferinde bir tane getir.

Nihayetinde, Agile'yi gerçekten "ekibiniz ve müşteriniz için anlamlı olan şeyleri yapmak ve eski uygulamalara bağlı kalmamak, çünkü geçmişte çalışıyormuş gibi görünmeleri" olarak tanımlıyorum.

Agile, bireyler için takımlar için olduğu kadar iyi çalışır. Sizin için çalışan bir süreç bulmak ve projeniz zaten başladıktan sonra değişen koşullara uyum sağlamanıza izin vermekle ilgilidir. Ayrıca, yazılımın gerçekten "tamamlanmış" olup olmadığına bakılmaksızın, müşterinize düzenli olarak değer sağlamakla da ilgilidir.

Çevik süreçler oldukça yinelemelidir. Çalışma, kısa TimeBox'lar/sprintler/döngüler/yinelemeler ile yapılır. Önceden bazı tasarım çalışmaları gerekebilir, ancak ne yapmanız gerektiği hakkında daha fazla bilgi edindikçe yeniden düzenlenebilir. Birim testi, neredeyse tüm Çevik geliştirme yöntemlerinin bel kemiğidir ve size 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 tüm sisteminizi oluşturursanız ve tüm testleri sık sık çalıştırırsanız ve her sprint sonunda çalışma kodu verirseniz özellik önceliklerinizi buna göre ayarlayabilir zaten çeviksiniz.

Vay. Başım beladayken çağırabileceğim bir arkadaşımı kancada tutmaya ve kodlama probleminden bahsetmeye çalışırdım. Ne demek istediğimi biliyorsun ... sadece bir problemi yüksek sesle açıklama eylemi benim zihin zamanının% 90'ına bir çözüm getiriyor.