it-swarm-tr.com

Bir Kişi İçin En İyi Geliştirme Metodolojisi?

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?

77
Eli

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.

29
Jon B

İş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 özellik istekleri e-tablosu oluşturabilir, bunlara öncelik verebilir ve en üstteki olanı seçebilirsiniz.
  • kabul kriterlerini tanımlayın (yapılanlar neye benzediğini) ve yürütülebilir bir teste kodlayın
  • Daha sonra yapılacak mühendislik görevlerini tanımlayın
  • Birim testleri yazın, en basit şeyi (YAGNI) yapın ve her zaman yeniden düzenleyin. Amaç dış kabul testini geçmek
  • Her oturumu zamanla. Etkili zaman yönetimi için Pomodoro tekniği konusuna da bakabilirsiniz.
  • Sürüm kontrolünü kullanın ve yazılımınızın bir kurulumunu veya Zip'ini oluşturmak için bir CI sunucusu/toplu iş dosyası kurun
  • Sık sık demo yapın. Geri bildirimi orijinal e-tabloya yönlendirin ve önceliklendirin

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

23
Gishu

Yalnız çalışıyorsanız. İşte öneriler:

  1. Mümkün olduğunca az düşük seviyeli iş yapın. Kolayca kodlayabileceğinizi düşündüğünüz şeyler de dahil olmak üzere olabildiğince çok kütüphane ve araç kullanın (yapmayın, sadece kütüphaneyi kullanın).
  2. Yukarıdan aşağıya yaklaşımı ele alalım. Sadece gerçekten ihtiyacınız olan şeyleri kodlayın.
  3. Soyut terimle ilgili bir sorun gördüğünüzde, Google'da arama yapın ve daha önce kanıtlanmış olan akademik topluluklardan araştırma kağıtları kullanın. Sadece algoritmalarını kodlamanız gerekir.
  4. Sisteminizi, işleri mümkün olduğunca özgürce değiştirebileceğiniz şekilde tasarlayın. (bazı kodları buraya kopyalayıp yapıştırmak dahil). Amaç, bir hata yaptığınızı fark ettiğinizde size zaman kazandırmaktır. Bir hata yaptığınızda atmanız gereken iş miktarını en aza indirmeye çalışın. Atılması gereken bir kod parçası (oradan oradan kopyala yapıştır yerine) bu kodu yazarken kaybettiğiniz zamanın eşdeğerliğidir.
  5. Çok sayıda otomatik teste sahip olun, 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 hale getirin
  7. Hata ayıklamak için bir hata ayıklayıcı ve kusur bulmak için ikili arama kullanın.
  8. Kodlamayı (açık) ve genel yöntemlere maruziyeti (kapalı bağlantı) azaltmak için kodunuzu sürekli olarak yeniden düzenleyin.
  9. Gerçekten hiçbir şey. Yeni bir şey bulabilirsem burada: P
17
InformedA

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 .

13
ChrisF

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.

7
tvanfosson

Ş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.

7
Karl Bielefeldt

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" ifadesini kullanın ve müşterinizin geri aramasını bekleyen facebook'ta kalmak için zamanınız olduğunda onlara geri dönün
  3. Müşterinizi sadece sonuçta değil, koda bakarak satın alacağından kodunuzu yazın, müşterinizi bir kod incelemesi için başkan olarak hayal edin.
  4. Teklif kodunu doldur
4
Gaetano Mendola

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

3
Levi Rosol

felsefe: XP/TDD + GTD

genel taslak:

  • paydaşlarla görüşme
  • ekran modelleri, izlenecek yollar, kağıt prototipler (gerektiği gibi)
  • özellik/hikaye beyin fırtınası (paydaşlarla ve paydaşlarla)
  • test senaryosu beyin fırtınası (paydaşlarla ve paydaşlarla)
  • genel tasarım/mimari düşünme süresi (gerektiği gibi)
  • yineleme planlaması (paydaşlarla)
  • yineleme
  • süreç incelemesi, eğitim, bakım planlaması, vb. (gerekirse)
2
Steven A. Lowe

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.

2
John Kraft

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!

2
bryanatkinson

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.

1
Stephen Bailey

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.

0
Nick

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ü?

0
MalsR

Çevik

ö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.

0
Steven A. Lowe

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.

0
Apalala