Bir proje için yazılım sürecini nasıl yaratırsınız?

Burada başka sorularda da bahsettiğim gibi, üzerinde çalıştığım projenin yazılım süreci yok. Bu, hiçbir belge (basılı kopya gereksinimleri veya belirtimi dahil) , kaynak kontrolü , hata veritabanı yok , hatalar "sabittir" (umarım) ve aynı anda yeni kod eklenir ve resmi bir test kullanıcısı olmaz - Joel Testinde başarısız oluruz çok kötü, komik bile değil.

Dün yöneticim benden bu eksikliklerin nasıl giderileceğine dair bir belge yazmamı istedi. Burada sadece 6 ay stajyer olduğumu unutmayın. Okula dönmek için Kasım ayında Şükran Günü'nden ayrılacağım. Ancak, belki de bu projeyi doğru yönde ilerletebileceğimi düşünüyorum, ancak nereden başlayacağından bile emin değilim. Şu anda CiteSeer ve Wikipedia'yı yazılım süreçlerini tanımlayan ve uygulayan bazı makaleler bulmaya çalışmak için kullanıyorum , ancak herhangi bir öneri, kişisel deneyim veya bloglara, kağıtlara, wiki makalelerine veya başka bir şeye bağlantılar çok takdir edilecektir.

Agile programlamaya bakmanızı öneririm.

Çok sayıda varyant var, ancak birkaç ortak yönleri var:

• Özelliklerin düzenli olarak gözden geçirilmesi ve yeniden önceliklendirilmesi.
• Sürekli entegrasyon ve otomatik birim testleri.
• Dokümantasyon üzerinden iletişime odaklanın (pratikte, önceden yazılmış büyük esnek olmayan özelliklerin üzerinden geçerken wiki tarzı dokümantasyon anlamına gelir).
• Yakma çizelgeleri ve hız metrikleri ile sonuçlanan esnek tahminler.
• 200 sayfalık teknik özelliklere sahip, oturum kapatılan düzenli prototipler.
• Kaynakta kalite veya mümkün olduğunca yakın.
• Düzenli paydaş incelemesi - müşterilerinizi anlamanın bir uzantısı.
• Yazılımı en kısa zamanda piyasaya sürün (ve para kazanın).
• Mümkün olduğunca doğrudan iletişim.

Başlamak için iyi bir yer MSF Agile veya Scrum olacaktır .

Durum göz önüne alındığında, 6 ay içinde gitmiş olursanız ve takım hiçbir işlemden başlamazsa, makul bir şekilde uygulanabilecek ve orada bulunduğunuz süre içinde tutabileceğiniz bir veya iki şeye tanıttığınız şeyin kapsamını sınırlayacağım. Eğer ben olsaydım bir kaynak kontrol aracına ve bir hata izleyiciye bakardım.

Orada başlamamın nedeni, bu araçların yerine getirilmesinin ekiplerin mevcut performansı için bir temel oluşturmanıza ve muhtemelen tekrar eden sorunları belirlemenize yardımcı olmasıdır. Süreç değişiklikleri güzeldir ancak bunlar ilk olarak uygulanması gereken temel temel öğelerdir.

Prince2'yi proje yönetimi süreçleri için kullanıyoruz ve çok iyi çalışıyor. Olsa bile, hiçbir proje yönetimi olan bir şirket için dolambaçlı görüneceğini öneriyoruz!

CI sunucumuz olarak TeamCity'yi kullanarak bu videoda özetlenen geliştirme boru hattını kendi ihtiyaçlarımıza uyarladık.

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TC, çekmekten ziyade bir depo itme gerçekleştirdiğinin farkında olduğum tek CI sistemidir, bu da (teorik olarak) artık kırık yapıların olmadığı anlamına gelir!

Yukarıdakilerin bazılarının düşüncelerini yankılamak için, yapısı olmayan bu takımlar çevik bir yapıya daha iyi uyacaktır. Kaynak kontrolünü bugün alın, değişikliklerinizi SVN'ye koymaya başlayın ve hata avlarken bazı geliştiricilerinize farklılık gösterin. Düzeltme günlükleri eklemeye başlayın. SVN'nin faydalarını ve kullanım kolaylığını göremezlerse mahkum olurlar.

MSBuild, CruiseControl.NET, FxCop, NUnit, NCover ve Subversion kullanarak .NET programlama için Sürekli Entegrasyon hakkındaki bu makalelere göz atın ...

Yazılım geliştirme siperlerinden