Tek geliştirici, proje yöneticisi, tasarımcı, QT kişisi olduğum projeler üzerinde çalışmak için çok zaman harcıyorum (Evet, biliyorum ... Kötü!) Ve hatta bazen müşteriyim.
Projeleri planlamak ve kendimi yönetmek için, sadece oturmaktan ve serbest çalışmadan projenin ne kadar uzun sürdüğüne kadar bitene kadar, kendimle bir ilerleme toplantısı yaptığım tek kişilik bir scrum versiyonuna kadar her şeyi denedim. -man her sabah grafik yakmak (şaka değil).
Yalnız çalışmak için fazla zaman harcayanlar için, kendinizi organize etmenin, büyük (bir kişi için) projeleri yönetmenin ve üretkenliği mümkün olduğunca yüksek tutmanın en iyi yolu nedir?
Hedeflerinizin net bir listesini tutmak çok önemlidir. Özellik sürünmesinin kendi kendini yöneten bir projeyi devralması kolaydır. TDD “işe yaradığında yapılır” yaklaşımı da faydalıdır. Bu mükemmeliyetçi olmanızı engeller.
Bana gerçekten yardımcı olan bir şey, herhangi bir durumda başka bir mühendis veya proje yöneticisinin ne söyleyeceğini hayal etmektir. Genellikle kötü koddan "kendimi utandırabilirim" ya da program kayıyorsa tekrar işe başlayabilirim.
İşte başlıyoruz ... http://xp.c2.com/ExtremeProgrammingForOne.html
Küçük odaklanmış takımlar için optimum olduğu için XP güzelce ölçeklenir.
Bir takımda yapamayacağınız tek şey PairProgramming.
Yalnız çalışıyorsanız. İşte öneriler:
Kod incelemeleri.
Bunlar özellikle aynı projede çalışmayan birine kodu açıklayacağınız için faydalıdır, böylece nasıl çalışması gerektiği konusunda herhangi bir varsayımınız olmaz.
Ayrıca şirket etrafında bilgi paylaşmanın ek avantajına sahip olacaklar, böylece başka biri proje üzerinde çalışmak zorunda olduğunda (başka yerlerde meşgul olmaları, hasta olmaları, istifa etmeleri veya kovulmaları nedeniyle) sıfırdan başlamak zorunda kalmayacaklar .
Hikayelere, yoğun müşteri etkileşimlerine, sık sürümlere ve test odaklı geliştirmeye dayanan kendi çevik versiyonumu yuvarladım. Hikayeleri izlemek için bir wiki kullanıyorum, müşterinin bunları yazarken mümkün olduğunca katılımını sağlıyorum ve müşterinin öncelikleri belirlemek ve bültenlerde düzenlemek için benimle çalışmasını sağlıyorum. Tasarım ve uygulama için TDD kullanıyorum. Müşterinin sık sık sürümleri (bazen yeni özellikler geliştikçe günlük olarak) deneyebileceği bir QA sunucusu ayarladım, böylece hızlı bir şekilde geri bildirim alabilirim. QA'ya yayın yapmadan nadiren 3'ten fazla tekrarlama yapıyorum. Müşteri, KG sürümünün ne zaman yayınlanacak yeterli özelliğe sahip olduğuna ve listenin dışında başka özelliklerin geliştirilmesine gerek olmadığına karar verir.
Şirketimde grubumuz aynı proje üzerinde çalışıyor, ancak nispeten bağımsız dilimleri üzerinde. Burada çok şey yaptığımız bir şey, yaptığınız bir şey biraz zor görünüyorsa veya bir şeyi uygulamak için birden fazla yolla yolda bir çataldaysanız, başka birini yakalar ve daha önce artılarını ve eksilerini tartışırsınız devam edin. Kodunuzun bir inceleme yapmayı bitirdiğini düşünene kadar beklerseniz, kod incelemelerinde kesinlikle çok fazla kusur ortaya çıkmasına rağmen, genellikle büyük mimari değişiklikleri düşünmek için çok fazla zaman harcadınız.
Ayrıca, Test Odaklı Gelişimin son zamanlarda biraz doymuş bir buzzword olduğunu fark ettim, ancak solo geliştiriciler için büyük bir yardımcı olabilir, çünkü gittikçe kalite kontrolü sağlar ve testler yazmak zorlaştığında muhtemelen kodu. Ayrıca, daha sonraki bakım görevlilerinin kodu tespit edilmesi zor yollardan yanlışlıkla kırmamalarına da yardımcı olur.
Size aşağıdakileri öneriyorum:
keşke ben zaman% 100 vaaz ne pratik başardık diyebilirim, ama BDD durumunuzu almak için iyi bir yaklaşım gibi görünüyor:
Daha fazla bilgi içeren bir bağlantı: http://en.wikipedia.org/wiki/Behavior_driven_development
felsefe: XP/TDD + GTD
genel taslak:
Ben çok benzer bir gemideyim. Çevik ilkeleri (anladığım kadarıyla) mümkün olduğunca takip etmeye çalışıyorum. Muhtemelen işleri “doğru” yapmıyorum, ama çevik ilkeleri takip etmeye çalışarak projelerimde büyük başarı elde ettim. Çok kısa bir disiplin gerektiriyor, çünkü sadece kısayollar kullanmaya başlamadığınızdan emin olacak bir takım yok.
ReSharper gibi kod biçimlendirme araçlarını kullanmanın, en azından görsel olarak, kodun diğer geliştiriciler için almayı kolaylaştırdığını buluyorum.
Gerçek metodolojiler açısından, tek bir geliştiricinin belirli bir geliştiriciye sadık kalması zordur. Ben genellikle yalnız çalışan bir danışmanım ve hem kendim hem de müvekkilim için çevik bir süreç kullanmanın en kolay yolunu buluyorum. Müşterilerimin ihtiyaçlarını doğrudan Trac gibi bir araca girmelerini sağlamaya çalışırım (ya da onların adına yapacağım). Bu sadece diğer geliştiricilerin kodun amacını belirlemelerine yardımcı olmakla kalmaz, aynı zamanda 3 ay boyunca kendinize de yardımcı olur!
Herhangi bir uygun metodoloji, projedeki kişi sayısına bakılmaksızın yardımcı olacaktır. Bu nedenle, her seferinde birini seçin ve alan adınıza nasıl başvurabileceğinizi ve haritalarınızı nasıl oluşturabileceğinizi görün ve başarılarını ölçün.
Belki de daha ilginç olanı, hangi metodolojilerin atmamalarını sormaktır, çünkü proje üzerinde çalışan sadece 1 kişi var.
Ve göze çarpan anahtar Kaynak Kontrolüdür (Evet, bu bir araçtır, ancak iş akışınızın bir parçasıdır, aynı zamanda bir süreçtir). İnsanlar, "aynı anda birden fazla kişinin kodunu düzenlemesini desteklemelerine gerek duymadığından" bu geçiş hakkını vermek için cazip gelebilir.
İronik olarak, GIT gibi bir dağıtım sürümü kontrol çözümünün SVN gibi bir şey için daha iyi olduğunu düşünüyorum.
Eğer atmak kodu metodolojileri ile biraz gevşek-goosey olabilir, ama önemli bir şey ve ben bunu bir kişi ile takım projesi olarak ele alma yolunuzu söyleyebilirim çok güzel ve disiplinli.
Bir sonraki adam için kodunu yaz, sen değil ... Ona iyi davran. "Uzaklaşma" kodu bile sonsuza dek kalır.
Kod incelemeleri iyi bir başlangıç olduğunu düşünüyorum, ancak belirli bir sorun/sorun veya bazı iyileştirme (örneğin yeni kodlama standartlarını karşılamak için eski kodu değiştirme) için bir Pair kodu incelemesi veya çift programlama yapmak gibi gayri resmi ve eğlenceli yapıldığında beğendim ). Bazen iki göz seti birinden daha iyidir ve aynı zamanda eğlencelidir, paylaşmanın ve tartışmanın daha açık olduğunu hissediyorum. Ayrıca resmi/gayri resmi öğle yemeği yiyebilir ve bireysel veya grup olarak ne yaptığınız hakkında konuşmak için oturumları tartışabilirsiniz. kullandığınız yeni bir modelden veya yeni teknolojilerden bahsedin, bir problem nasıl çözüldü?
özellikler, hikayeler ve test senaryoları, daha resmi belgelere göre çok daha öğreticidir ve bir dizi çalışma testi, bir şeyin nasıl kullanılacağını veya bir şeyin nasıl ölü ağaçlardan daha iyi olduğunu göstermede daha iyidir
Ayrıca, yinelemeler arasındaki işi teslim etmek daha kolaydır.
Kendim bir danışman olarak, herhangi bir görevde her zaman en az iki geliştirici olması için bir yol bulmanızı öneririm.
Çevik olmayı kabul ediyorum ve diğerlerinin takip edebileceği öyküler ve testlerden oluşan çevik bir iz bırakmaya katılıyorum, ancak insanlar yalnız çalışırken çalışırken ya da başka herhangi bir süreç ya da metodolojinin sopa olduğuna inanmıyorum.