Tek geliştirici, proje yöneticisi, tasarımcı, QT kişisi (Evet, biliyorum ... Kötü!) Ve bazen müşterim bile olduğum projeler üzerinde çok zaman harcıyorum.

Projeleri planlamak ve kendimi yönetmek için hemen hemen her şeyi denedim, sadece serbest oturmaktan ve serbest çalışmaktan çok uzun bir süre sonra proje bitinceye kadar, kendimle birebir görüşme toplantısı yaptığım tek kişilik bir scrum versiyonuna kadar - Adam her sabah çizelgeyi yakar (şaka yapmaz).

Yalnız çalışmak için çok 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 açık bir listesini tutmak çok önemlidir. Özellik sürünmesinin kendinden yönetilen 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ühendisin veya proje yöneticisinin ne söyleyeceğini hayal etmektir. Sıklıkla hatalı koddan "kendimi utandırabilirim" ya da zamanlama kayıyorsa tekrar izleyebiliyorum.

Buyrun ... http://xp.c2.com/ExtremeProgrammingForOne.html

Küçük odaklı ekipler için ideal olduğundan, XP iyi bir şekilde ölçeklenir.

• Bir özellik istekleri elektronik tablosu oluşturabilir, öncelik sırasına koyabilir ve en iyisini seçebilirsiniz.
• Kabul kriterlerini (neye benziyorsa) tanımlayın ve uygulanabilir bir test haline getirin
• Daha sonra yapılması gereken mühendislik görevlerini tanımlayın
• Birim testleri yazın, en basit şeyi (YAGNI) yapın ve her zaman refactor yapın. Hedef dış kabul testini geçmek
• Her oturum için Timebox. Etkili zaman yönetimi için , Pomodoro tekniğine de bakabilirsiniz .
• Yazılımınızı yüklemek veya zip oluşturmak için sürüm kontrolünü kullanın ve bir CI sunucusu / toplu iş dosyası kurun
• Sık sık demo. Geri bildirimi orijinal e-tabloya yönlendirin ve yeniden sınıflandırın

Bir takımda yapamayacağınız tek şey PairProgramming.

Eğer yalnız çalışıyorsan. İşte öneriler:

1. Mümkün olduğu kadar az seviyeli çalışma yapın. Kolayca kodlayabileceğinizi düşündüğünüz şeyleri dahil edebileceğiniz kadar kütüphane ve araçlar kullanın (yapmayın, sadece kütüphaneyi kullanın).
2. Yukarıdan aşağıya yaklaşımı kullanın. Yalnızca gerçekten ihtiyacınız olan şeyleri kodlayın.
3. Soyut terimde bir sorun gördüğünüzde, google'da arama yapın ve zaten kanıtlanmış akademik topluluktan araştırma makaleleri kullanın. Sadece algoritmalarını kodlamanız gerekir.
4. Sisteminizi, şeyleri mümkün olduğunca özgürce değiştirebilecek şekilde tasarlayın. (bazı kodları buradan kopyalayıp yapıştırmak da dahil). Amaç, bir hata yaptığınızı fark ettiğinizde size zaman kazandırmaktır. Hata yaparken atmanız gereken iş miktarını en aza indirmeye çalışın. Atılması gereken bir kod parçası (buradan ve buradan kopyala-yapıştır yerine) bu kodu yazarken kaybettiğiniz zamanın eşdeğeridir.
5. Çok sayıda otomatikleştirilmiş test uygulayın, böylece her değişiklik yaptığınızda düzenli olarak regresyon testleri yapabilirsiniz.
6. Tasarımınızın sorumluluklarını ayırın (yani kuplajı azaltın). İşleri mümkün olduğunca modüler yapın
7. Hata ayıklamak ve hata bulmak için ikili arama kullanmak için bir hata ayıklayıcı kullanın.
8. (Açık) birleştirme ve genel yöntemlere maruz kalma (örtülü birleştirme) durumlarını azaltmak için kodunuzu sürekli olarak yeniden ayarlayın.
9. Gerçekten hiçbir şey. Bu yeni bir şey bulabilirsem diye burada: P

Kod incelemeleri.

Bunlar, özellikle aynı projede çalışmamış birine kodu açıklayacağınız için kullanışlıdır, bu nedenle nasıl çalışması gerektiği konusunda varsayımlarınızdan hiçbirini yapmazlar.

Ayrıca, şirket hakkında bilgi paylaşma avantajına da sahip olacaklar; bu nedenle, başka bir kişi proje üzerinde çalışmak zorunda kaldıklarında (başka yerlerde meşgul olmaları, hasta olmaları, istifaları veya işten çıkarılmaları nedeniyle) sıfırdan başlamaları gerekmeyecek .

Hikayelere, yoğun müşteri etkileşimlerine, sık sık yayımlananlara ve test odaklı gelişime dayanan kendi çevik versiyonumu kullandım. Hikayeleri izlemek, müşteriyi yazarken olabildiğince ilgilenmesini sağlamak ve müşterinin bültenleri önceliklendirmek ve organize etmek için benimle birlikte çalışmasını sağlamak için bir wiki kullanıyorum. Tasarımı sürmek ve uygulamak için TDD kullanıyorum. Hızlı bir şekilde geri bildirim alabilmek için müşterinin sık sık sürümlerini deneyebileceği (bazen yeni özellikler geliştirildiği gibi günlük) bir QA sunucusu kurdum. QA'da serbest bırakılma yapmadan nadiren 3 den fazla tekrar ediyorum. Müşteri, QA sürümünün ne zaman yayınlanacak özelliklere sahip olduğuna ve listeden daha fazla özelliğin geliştirilmemesi gerektiğine karar verir.

Benim şirketimde grubumuz hepsi aynı proje üzerinde çalışıyor, ancak nispeten bağımsız dilimleri üzerinde çalışıyor. Burada çok yaptığımız bir şey, yaptığınız bir şeyin biraz aldatıcı göründüğü veya bir şeyi uygulamak için birden fazla yolun olduğu bir yolun çatalı olduğunuzda, başka birini kapmak ve artılarını ve eksilerini tartışmaktır. sen devam et. Kodunuzu inceleme yapmak için bittiğini düşününceye kadar beklerseniz, kod incelemelerinde kesinlikle birçok hata ortaya çıkmış olsa da, büyük mimari değişiklikleri düşünmek için zaten çok zaman harcadınız.

Ayrıca, Teste Dayalı Gelişimin son zamanlarda doymuş olan küçük bir terim olduğunu fark ettim, ancak solo geliştiriciler için büyük bir yardım olabilir çünkü gittiğinizde kalite kontrol sağlar ve testler yazmak zorlaştığında muhtemelen yeniden yapılandırmanız gerekebilir. kodu. Ayrıca, daha sonra bakıcıların, kodları tesadüfi olarak tespit etmek için zor bir şekilde kırmamalarına yardımcı olur.

Size aşağıdakileri öneriyorum:

1. Test odaklı geliştirme
2. Hemen yapamayacağınız bir şey gördüğünüzde, kodunuzda "TODO: buraya not edin" gibi dolandırıcılık kullanın ve müşterinizin geri aramasını beklerken facebook'ta kalmak yerine zamanınız olduğunda geri gelin.
3. Müşteriniz kodu yalnızca satın aldığınızdan satın alacağından kodunuzu yazın, müşterinizi bir kod incelemesi için başkan olarak hayal edin.
4. Varlıklar kodunuzu doldurun

Keşke zamanın% 100'ünü vaaz ettiğim şeyi uygulayabilseydim diyebilseydim, ama BDD sizin durumunuzda iyi bir yaklaşım gibi görünüyor:

İşte daha fazla bilgi içeren bir link: http://en.wikipedia.org/wiki/Behavior_driven_development

Ben çok benzer bir teknedeyim. Çevik prensipleri (onları anladığım kadarıyla) mümkün olduğunca takip etmeye çalışıyorum. Muhtemelen işleri "doğru" yapmıyorum, ancak çevik ilkeleri takip etmeye çalışarak projelerimde büyük başarı elde ettim. Çok fazla disiplin gerektiriyor, çünkü kısa yol almaya başlamadığınızdan emin olmak için hiçbir takım yok.

ReSharper gibi kod formatlama araçlarını kullanmanın, en azından görsel olarak kodun diğer geliştiriciler için kolay bir şekilde bulunmasını sağladığını biliyorum.

Gerçek metodolojiler açısından, tek bir geliştiricinin herhangi bir özel ürünle kalması zor. Genellikle yalnız çalışan bir danışmanım ve hem kendim hem de müşterinin çevik bir süreç kullanması için en kolay buluyorum. Müşterilerimin gereksinimlerini doğrudan Trac gibi bir araca girmelerini sağlamaya çalışırım (ya da kendi adına yaparım). Bu, yalnızca diğer geliştiricilerin kodun amacını belirlemelerine yardımcı olmaz, aynı zamanda kendinizi 3 ay aşağıya indirmenize yardımcı olur!

felsefe: XP / TDD + GTD

Genel taslak:

• paydaşlarla görüşme
• ekran örnekler, örnek adımlar, kağıt prototipler (gerektiği gibi)
• uzun metrajlı beyin fırtınası (paydaşlı ve paydaşsız)
• test senaryosu beyin fırtınası (paydaşlı ve paydaşsız)
• genel tasarım / mimari düşünce zamanı (gerektiği gibi)
• yineleme planlaması (paydaşlarla birlikte)
• yineleme
• süreç gözden geçirme, eğitim, bakım planlama vb.

Uygun olan herhangi bir metodoloji, projedeki insan sayısına bakılmaksızın yardımcı olacaktır. O zaman bir tanesini seçin ve etki alanınıza nasıl uygulayabileceğinizi ve haritalandırabileceğinizi görün ve başarılarını ölçün.

Belki de daha ilginç olanı, hangi metodolojilerin atılmaması gerektiğini sormak, çünkü projede sadece 1 kişi çalışıyor.

Ve benim için öne çıkan 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). Kişiler bu kodu vermek için cazip olabilirler çünkü "aynı anda birden fazla kişiyi düzenlemeleri gerekmez".

İronik olarak GIT gibi bir dağıtık sürüm kontrol çözümünün SVN gibi bir şey olan bir birey için daha iyi olduğunu düşünüyorum.

Eğer kod atılırsa, metodolojilerle biraz gevşek-ahlaksız olmak mümkün olabilir, ama önemli bir şey var ve bunu bir kişiyle takım projesi olarak ele almanın çok hoş ve disiplinli olduğunu söyleyebilirim.

Bir sonraki çocuğun okuması için kodunu yaz, sen ... ona iyi davranma. "Atma" kodu bile sonsuza dek kalır.

Çevik

özellikleri, hikayeleri ve test senaryoları, resmi belgelere göre çok daha öğreticidir ve bir dizi çalışma testi, herhangi bir ölü ağacın nasıl kullanılacağını veya bir şeyin nasıl çalıştığını göstermede daha iyidir.

Yinelemeler arasında işten çıkarmak da kolaydır.

Kendi kendime bir danışman olarak, herhangi bir görevde her zaman en az iki geliştirici olmanın bir yolunu bulmanızı öneririm.

Çevik davranmaya katılıyorum ve başkalarının izleyebileceği hızlı bir hikayeler ve testler izini bırakmaya katılıyorum, ancak insanlar yalnızken çalışırken buna veya başka bir işlem veya metodolojinin yapışacağına inanmıyorum .

Kod incelemelerinin iyi bir başlangıç ​​olduğunu düşünüyorum, ancak gayrı resmi ve eğlenceli hale geldiğinde, belirli bir sorun / problem ya da bazı iyileştirmelerle başa çıkmak için bir çift kod incelemesi veya çift programlama yapmak gibi (örneğin yeni kodlama standartlarını karşılamak için eski kod değiştirmek) ). Bazen iki göz grubu birinden daha iyidir ve aynı zamanda eğlenceli, paylaşım ve tartışmanın daha açık göründüğünü hissediyorum. Ayrıca resmi / gayri resmi bir öğle yemeği yiyebilir ve bireysel olarak ne yaptığınız hakkında konuşmak ya da bir grup olarak konuşmak için oturumları tartışabilir, örneğin kullandığınız yeni bir kalıptan ya da bir sorunun nasıl çözüldüğünden yeni teknolojilerden bahsedebilir misiniz?