Tek Kişilik Ekipler için Yazılım Yaşam Döngüsü Metodolojileri [kapalı]


15

Ustalarım projesi için bir yazılım sistemi inşa ediyorum ve "tek kişilik bir takım" a uygun belirli metodolojiler hakkında tavsiye arıyordum ...


1
Bu soruyu sorduğunuz için memnunum, şu anda böyle bir durumdayım. Süreç ve kaynak kontrolü, sürekli entegrasyon, test odaklı geliştirme ve diğerlerini içermeyen iki kişilik bir ekip için görev aldım. Verimliliği artırmak için neler yapabileceğimi ve sonunda altımda insanları işe alma iznim olduğunda en iyi nasıl hazırlanacağımı merak ediyorum.
maple_shaft

Yanıtlar:


11

Yaşamımı çoğunlukla evden çalışan tek kişilik bir "kiralık yazılım tabancası" olarak yapıyorum, bu yüzden diğer insanların bu konuda ne söylediğini duymaya can atıyorum.

Önemli bulduğum birkaç şey:

  • Denis'in dediği gibi, kaynak kontrolü hayati öneme sahiptir - ancak SVN tek seçenek değildir. Ben çoğunlukla Perforce kullanıyorum ve git iyi bir alternatif. Bir "ana hat" geliştirme modelini seviyorum; kod dallarında deneyler yapmama, onları çalıştıklarında ana hatta birleştirmeme ve yapmamaları durumunda önemsiz hale getirme.
  • Notlar için bir not defteri ve görevleri izlemek için bir program kullanıyorum. Şu anda ikincisi için Redmine kullanıyorum; ondan önce Fogbugz kullandım. Ayrıca Redmine'ı da seviyorum çünkü kalıcı notlar ve önemli sitelere bağlantılar için kullanabileceğim gerçekten iyi bir yerleşik wiki var.
  • Ayrıca ne yaptığımı takip etmek ve kendime bir tür makul sınırlar koymak çok önemlidir, bu yüzden yanmadan yapmam yeterli olur - aşağıya bakın.

Diğer tekniklerim yıllar içinde gelişti ve bunları projeye ve müşteriye bağlı olarak değiştirdim. İnsanlar bana çalışma kodu için para ödüyorlar, süreçle dalga geçmiyorlar, bu yüzden süreci hafif tutmaya ve müşterilerimin yüzlerinden uzak tutmaya çalışıyorum. Ama bazı Çevik tekniklerin benim için gerçekten işe yaradığını görüyorum:

  • Mevcut müşterilerimden biri, uygulamak için üzerime büyük özellikler bırakma eğilimindedir ve bitene kadar beni rahatsız etmiyor. Bu yüzden Scrum sprint'leri üzerinde çalışmak harika. Tahminimce, araştırma danışmanınız bir kontrol manyağı değilse, bir yüksek lisans projesi için işe yarayabilir.
  • Diğer mevcut müşterim, "bunun üzerinde çalışmayı durdur ve düzelt" türünde daha fazla acil durum yaşama eğilimindedir. Bunu Scrum ile yapmayı denedim ve bir süratten sonra vazgeçtim. Bunu Kanban kullanarak yapıyorum ve çok daha iyi çalışıyor.

Kendi başınıza çalışmanın bir diğer yanı ise, ne yapacağınızı, ne zaman veya yeterli iş yapıyorsanız veya ne zaman işten ne zaman ayrılacağınızı söyleyecek kimseye sahip olmadığınızdır - bu yüzden yapmanız gerekir kendiniz için. Ben şahsen Scrum'ı tercih ediyorum çünkü sprint hedeflerime göre nasıl yaptığımı takip edebiliyorum. Kanban projeleri için ne kadar zaman harcadığımı takip edebiliyorum, ama bundan hoşlanmıyorum, aynı zamanda daha hedefe dayalı bir şey de değil.

Bazı arkadaşlarım Pomodoro tarafından görevlere odaklanmanın ve kişisel verimliliği takip etmenin bir yolu olarak yemin ediyorlar ve bunu denemeyi düşünüyorum.

Müşterilerime, aldıkları şeyin "doğru" olduğundan emin olmak için kod yayınlamak için resmi bir işlemim de var, ancak bu muhtemelen sorduğunuz şeyin kapsamı dışında.


3

SVN'yi her şeyden önce kullanın, her şeyi versiyonlayın. İzleme için dizüstü bilgisayar daha basit projeler için yapacak, gerekirse birçok ücretsiz görev / hata izleme uygulamanız var (Redmine iyidir). Çevik / XP / Sürekli Entegrasyon / diğerleri bence biraz abartı olurdu.


3

Kişisel Yazılım Sürecinin yanı sıra, tek bir geliştirici tarafından kullanılmak üzere tasarlanmış resmi süreç modelleri hakkında fazla bir şey bulamadım. PSP, iş yapma konusundaki belirli teknikler için söylenecek çok şey olmadan (zaten ham formunda, her ne kadar) dokümantasyon ve evrak işlerinde oldukça ağırdır (bunun yerine PSP, iyileştirilmesi gereken alanları bulmak için veri toplamaya odaklanır), ancak bir başlangıçtır küçük ve orta ölçekli projelerde kullanabileceğiniz kişisel bir süreç geliştirme noktasıdır.

En iyi hareket yolunun, bir dizi süreç modelinden yaygın olarak kabul edilen en uygun uygulamaları (ihtiyaçlarınızı ve projenizi temel alarak) basitçe takip etmek olacağını düşünüyorum. Yapılan işleri / kalan işleri izleme, gereksinimleri yönetme, sürüm kontrolü, test etme (özellikle birim ve kabul testleri), sürekli entegrasyon, kodlama standartları, İhtiyacınız olmayacak vb. Yöntemlerine bir göz atın. Eğer yapmadıysanız, Code Complete ve Pragmatic Programmer'ı okumanızı ve ipuçlarını uygulamayı öneririm.

Bireysel çalışma ile ilgili en büyük şey, dış kuvvetlerin size getirdiği kısıtlamaların yanı sıra, tamamen size kalmış olmasıdır. Sizinle birlikte çalışan başka birini ağırlamanız gerekmez, bu nedenle mümkün olan en verimli şekilde çalışmanızı sağlayacak teknikleri seçmek daha kolaydır. Yıllar boyunca, muhtemelen en iyi nasıl çalıştığınızı anladınız, bu iyi bir başlangıç ​​noktası olacaktır. Daha sonra yeteneklerinizi ve tekniklerinizi geliştirmek için bilinen "en iyi uygulamaları" uygulayın.


1

Adam belirli metodolojileri soruyor ve insanlar “X / Y yazılımını kullan” cevabını veriyor. Bir araç meselesi DEĞİL, aslında birçok yöntem var ve onlar için henüz bir doğrulama raporu yok gibi görünüyor: Çevik, Yinelemeli, Spiral, Şelale, XP, V Modeli, TDD.


Mesele şu ki, araştırmanın çoğu ekiplerle çalışmaya yönelik. Bildiğim kadarıyla, sadece PSP tek bir mühendis tarafından kullanılmak üzere tasarlanmıştır. Ve bunun içinde bile PSP, iyileştirilmesi gereken alanları tanımlamak için verilerin nasıl izleneceğini belirlemeye odaklanmıştır ve bu görevleri nasıl gerçekleştireceğiniz konusunda hiçbir ayrıntıya sahip olmadan, yazılım kalitesini artırmaya yardımcı olabilecek yalnızca birkaç üst düzey görev sağlar.
Thomas Owens
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.