Bu Yazılım Geliştirme Projesi Kontrol Listesine ne eklersiniz? [kapalı]


14

Ben kontrol listelerinin büyük bir hayranıyım. Orada Seyahat Kontrol Listesi , Kontrol Listesi Hareketli ve hatta bir Scrum Kontrol Listesi .

Bağlam : büyük bir şirket tarafından işe alınmış ve tüm yazılım geliştirme ortamını, süreçleri, ekibi, vb. Kurma görevini vermişsiniz. Yazılımın çalışma artışlarının yaratılmasından siz sorumlu olacaksınız. Proje büyüklüğü: 2000 adam / gün.

Aşağıdaki (kasıtlı olarak küçük ve eksik) kontrol listesine hangi öğeleri eklersiniz:

  • Sürekli Entegrasyon Sunucusu Yükleme
  • Bir DoD yazın
  • Bir sayfa kodlama yönergeleri yazın
  • Ürün biriktirme listesi oluşturma
  • Hata İzleme Sistemi Yükleme
  • Düzenli Yüz Zamanını Planla

Yanıtlar:


10

* 1.) Gerçekten neye ihtiyaç duyduklarını görmek için geliştiricilerle konuşun! *

2.) Birden çok ortamı gerçekten hızlı bir şekilde ortaya çıkarmak için bir çözüm araştırın (terim uyumlu değilseniz, genel veya özel bulut örneklerini veya eski moda sanal makineleri düşünün)

3.) Kaynak / sürüm kontrolü

4.) Kod inceleme sistemi (Örnek olarak Crucbile / Fisheye)

5.) Kanban duvarı (veya benzer bir şey)

6.) İletişim protokolleri (gerçek zamanlı sohbet büyük bir artıdır), wikis de işbirliğini teşvik eder. Bu, dahili olarak halkla ilişkileri de kapsar - işletme sahipleriniz, teknik destek personeli ve diğer gruplarla nasıl ilişki kuracaksınız?

7.) Elektronik yazı tahtaları

8.) Geliştiriciler için rahat bir ortam (kanepeler, masalar, chillout alanlar, iyi WiFi vb)

9.) Büyük kahve !!!


kahve fark yaratır:) + 1
RBA

Kullandığınız elektronik yazı tahtaları nedir?

@Pierre 303 - Bir beyaz tahta oturumunun sonuçlarını yazdırmak a (yüksek kaliteli fotoğraf sanırım aynı hile yapacaktır).
Martijn Verburg

8
  • Toolchain kurulumu - IDE'ler, CI sunucusu, kod kalitesi sunucusu, kaynak kontrolü, web sunucusu, veritabanları, sorun izleyici vb.
  • Yedekler - Takımdaki her bir kişinin rolü nedir? Hangi süreçlere / modüllere sahip 've onun yedeği kim?
  • (Kullanıcı Kabulü) Test ortamı kurulumu - Sadece sürekli entegrasyon değil w. birim testleri, ancak gerçekten kötü şeyleri, çoklu platformları, uygulama sunucularını, VM'leri vb. kapsayan entegrasyon testleri.
  • Performans Testleri kurulumu - Ne kadar erken o kadar iyidir, çünkü "Performans hangi özellik / kilometre taşıyla bu kadar kötü düştü?"
  • (Son Kullanıcı) Dokümantasyon özeti - Dokümantasyonda ne olacak? Ne tür belgeler gerekli?
  • Pazarlama kanalları - İç kilometre taşları ve dış sürümler nasıl duyurulur? Yazılım, logo, renkler, ifadeler vb. İçin güzel bir adınız var mı?
  • İç iletişim - Diğer ekiplerden akranlar değişiklikler hakkında nasıl bilgilendirilecekler? İşbirliği nasıl yapılıyor? Wiki? Erişim hakları?
  • Kalite Güvencesi insanlar ve süreç - Kim neyi, ne sıklıkta ve hangi kriterlerle test edecek?
  • Serbest bırakma süreci - Ne zaman, ne sıklıkta, nasıl, kim yapıyor, serbest bırakmayı kim alıyor vs.
  • Risk yönetimi - En Kötü Durum Senaryosu (proje mgmt pov ve çalışma zamanı pov'sinden, örneğin 'yazılım X modülünde başarısız olduğu için müşteri para kaybediyor, yedekleme planı nedir?)
  • Çekirdek geliştirme ortamının güvenliğini sağlama, örneğin Escrow için sanallaştırma
  • Resmi ve gayri resmi toplantılar için yerler
  • Tüm insanlar için eğitim veya tanıtımlar, böylece tüm kurulumun ne olduğunu, her parçanın ne için olduğunu ve nasıl kullandıklarını biliyorlar.
  • Bekçiyi tanımlamak ve ona, işler kötüye gittiğinde gerçekten ilgilenmesi gereken her şeyi (örn. İzinler) vermek

Yedekler ve eğitim için +1
Liviu T.

Yedekler, düşündüm ki bunlardan bazıları yabancı.
BlackICE

5

Postmortem İncelemeleri - Bloklar üzerinde çalıştığınız için, herkesin dolaştığı ve neyin doğru yapıldığını söylediği bir yüz yüze görüşme (mümkünse) için bir ila iki saatlik bir inceleme (takım boyutuna bağlı olarak) planlıyorum. daha iyi yapılabilirdi ve ne gerek yoktu. Geliştirme sürecindeki hatalarınızdan erken öğrenebilmek, daha sonra çalışmak için çok zamanınız olmadığında bunları yapmaktan kaçınabileceğiniz anlamına gelir.


4

Projeniz için doğru profesyonellerin iyi bir ekibini işe almaya başlayalım. Tipik bir iş uygulamasında, bir veritabanı geliştiricisi ve bir dba, bir KG personeli, bir sistem yöneticisi, bir iş analisti, uygulama geliştiricileri, bir UI uzmanı ve ekibi en azından işe almanız gerekir. DBA, Sistem Yöneticisi, iş analistleri ve KG, geliştirme ekibinden ayrı bir raporlama zincirinde olmalıdır. Geliştirme veritabanı uzmanı, uygulama geliştiricileri ve kullanıcı arayüzü uzmanı ile aynı teknik müşteriye rapor vermelidir.

Ofis alanını ayarlayın. Özel ofisler onları alabilirsiniz (Bu size bol şans diliyorum) harika, ama bir minumum masaları, telefonlar, bilgisayarlar, yazı tahtaları ve birkaç özel konferans salonu gerekir. Öğle molaları, buzdolabı, alkolsüz içecekler, atıştırmalıklar ve kahve için bir yer olduğundan emin olun. Ücretsiz alkolsüz içecekler ve kahve daha da iyi.

Hem uygulama hem de veritabanları için dev / qa / staging ve prod sunucuları kurun. Veritabanları hiçbir zaman uygulamalarla aynı sunucuda olmamalıdır. Projenin boyutuna ve kapsamına bağlı olarak, her ortam için birden çok sunucuya veya SAN'a vb. İhtiyacınız olabilir.

Sunucular kurulur kurulmaz, dosya sisteminin, veritabanının ve veritabanı işlem günlüklerinin yedeklerini programlayın. Bunu ilk gün yapılacak şeyler yapın. Haftalık saha dışı yedeklemeler almak için Iron Mountain gibi bir firma kiralayın.

Bir kaynak kontrol sistemi kurun ve nasıl kullanılacağını açıklayan bir belge oluşturun. Arama türü tabloları için TÜM veritabanı yapısal değişikliklerinin ve veri eklerinin kaynak denetimindeki komut dosyalarında olması konusunda ısrar etmeyi unutmayın. Bu, konuşlandırmayı kolaylaştıracaktır.

Tüm ilgili kullanıcılar için lisanslarla kullanmaya karar verdiğiniz araç seti için ticari yazılım satın alın veya açık kaynaklı yazılım indirin.

Hızlı çığlık atan ve iki monitörü olan geliştirici makineleri satın alın. Yavaş ve kullanıcıların masaüstünde ne olacağını tipik inilti en az bir test kullanıcı makinesi satın.

Yeni geliştiricilerinize işleri nasıl istediğiniz konusunda eğitin. Bazı genç geliştiriciler için yeterince büyük bir ekibiniz varsa, onlar için ekstra eğitim planlayın ve zamanı proje planlamanıza ekleyin. Çocukları en az üç ay boyunca çok yakından izleyin. Tüm yeni çalışanları ilk ay boyunca yakından izleyin. En kısa sürede deadwood ve haydut geliştiricilerden kurtulun.

Hangi sırayla yapılması gerektiğini belirleyin (kritik yol). Bağlı oldukları görevler tamamlanana kadar kritik yolun sonunda görev atamayın.

Test planları ve gereksinimler oluşturun.

Müşterilerle düzenli olarak planlanmış ilerleme toplantıları düzenleyin. Ne yaptığınızı ve birlikte gösterimlerin neler olduğunu bilmeyi hak ediyorlar. Onlara işlerin ne zaman geç kalacağını söylemeyin. Eğer son teslim tarihinden üç hafta uzaksanız ve bunu kaçıracağınızı zaten biliyorsanız, müşteriye söylemeden önce bu eksiklik sihirli bir şekilde ortadan kalkmayacaktır. Müşteri, ek gereksinimlerin ek maliyetler ve zaman anlamına geldiğini ve her ek gereksinimin ya başka görevlerin reddedilmesi gerektiğini ya da son tarihin yeni görevlerdeki saat miktarıyla değişeceğini bildiğinden emin olun. Bunu en baştan netleştirmek, müşteri tarafından değil, grubunuz tarafından emilen çok fazla acı ve fazla mesai saatinden ve maliyet aşımlarından tasarruf sağlayacaktır.

Performans testine yalnızca bir kullanıcının hızını değil, aynı zamanda beklenen sayıda eşzamanlı kullanıcıyı test edebileceğiniz bir ortam oluşturun. Bu testi yayınlanmadan önceki güne kadar yapmak için beklemeyin.

Proje planlamasında KG'nin hataları bulacağını ve düzeltilmesi zaman alacağını varsayalım. KG'yi yalnızca bir gün için planlamayın.

Kabaca veritabanının olacağını düşündüğünüz boyutta test verileri oluşturun. Tüm geliştiricilerin kodlarını bu boyuttaki veritabanına karşı test etmelerini sağlayın. Geliştiricilerin kişisel makinelerinde yalnızca küçük bir veritabanına karşı geliştirmelerine izin vermeyin. Bu, üretime çarpana kadar iyi çalışan kodun sık görülen bir nedenidir.

Ödüllerinizi bütçeye göre planlayın. İnsanları aylarca kıçlarını çalıştırdıklarında motive eder ve sadece yöneticiler bonus alır. Ayrıca sık sık ve yazılı olarak teşekkür ederim.

İzlemeniz gerekenleri izlemek için bir proje yönetim sistemine veya en azından e-tablolar ayarlamanız gerekebilir. Proje planlaması yaparken, planınızda günde altı saatten fazla olmamalıdır. Bu, projeye harcanmayacak zamanı, örneğin tatil, hasta zaman, tatiller, İK toplantıları, performans incelemeleri, vb. Hesaplamaya yardımcı olur. Kasım 1 - 1 Ocak ABD'de), daha fazla izin ve tatil zamanı için ek ödenekler yapmanız gerekebilir. Geliştiricilerin izinlerini ve tatillerini bırakmasını beklemek adil değildir ve hiç kimse hasta zaman, jüri görevi, yas süresi vb. Şeylerin ne zaman olacağını tahmin edemez. Bu projede ekibinize olacaklarını varsayalım.


Ben test kullanıcı makine "yavaş çığlık" değil, "yavaş inilti";) çok güzel bir liste olması gerektiğini düşünüyorum.
BlackICE

@david, önerinizi beğendim ve metinde değiştirdim.
HLGEM

Mükemmel yanıt - madde işaretleri veya bölüm adları biraz yardımcı olabilir.
JBRWilkinson

3

Soruda göremediğim bazı şeyler ve sonraki cevaplar:

  • Felaket kurtarma planı. Geliştirici kutularını nasıl yedekliyorsunuz, hazırlama, test etme vb. Her geliştiricinin ara sıra kar gününde evden çalışmak için ihtiyaç duydukları şey var mı? Vb.

  • Egzersiz planı. Geliştiricilerinizin keskin kalması için kaç haftalık eğitim gerekiyor? Bunu izleyen var mı? (Bir e-tablo çoğu takım için yeterli olabilir.) Rapor etmeleri için bir mekanizmaya sahip olma (birine "ne olursa olsun" için 2 saatlik web yayınlarını izlediklerini söyleyen bir e-posta gönderme) ve yönetim planlaması için - örneğin neyi kime göndermemiz gerektiğini konferansı bu yıl yapılacak.

  • a Takım Konumu. Bu bir "hepinize bir MSDN aboneliği veriyoruz; lütfen iş makinelerinize başka bir şey yüklemeyin" veya bir "kod istiyoruz, ancak düzenlemek, derlemek ve test etmek için ne kullandığınız umrumda değil " Yer türü. Karar verin ve kaydedin.

  • dayanabileceğiniz veya ödeyebileceğiniz kadar entegre ALM. Genellikle "empedans uyumsuzluğu", çift giriş, takım üst üste binme ve döner sandalye uygulama entegrasyonunun nedeni, sistemin parça ve parçalarla büyümesidir. Sıfırdan başlayarak, halkınızın döngü boyunca tek bir araçta kalabileceğini göstermek istiyorsunuz. X'a kod yazmamak, Y ile derlemek, Z ile test etmek, iş öğesinin / görevin durumunu A ile değiştirmek, B ile geçirdiği zamanı bildirmek, bekleyen C'ye şimdi bekleyebileceklerini söylemek, anlamaya çalışmak D ile bir sonraki adımda ne yapacağını, E ile genel ilerlemeyi guauging vb.


2

Daha fazla insan gününü olumsuzlayın.

İnsanların başlangıçta yeterince tahsis ettikleri nadir bir olaydır.

[Daha sonra ... daha fazlasını yeniden tartışmak ...]


Daha fazla adam gününün her zaman müzakere edilmesi gerektiği görüşüne sahip olmak, tavsiye edeceğim bir şey değil, bir iş veya proje süresinin doğru ve güvenilir tahminlerini sunmayı tercih ederim.
NimChimpsky

@NimChimpsky Burada son zamanlarda bilgisayar projelerinde güvenilir bir şekilde tahmin yapabilme yeteneğinin bir efsane olup olmadığı üzerine bir tartışma vardı. İş çok iyi bilinmedikçe ve araştırma içermedikçe, zamanı tahmin etmek doğal olarak zordur. Kendi ekibinizin programını tahmin edebilseniz bile - dış faktörleri ve gecikmeleri tahmin etmek imkansızdır. Dolayısıyla "doğru ve güvenilir" tahminler, genel olarak var olduğuna inandığım bir şey değildir.
Orbling

@Orbling, çalıştığım yerde varlar. Bir ftse 250 İngiltere'de ulusal perakendeciyi listeledi. Bazı projeler gecikti, ama geç değil ve istisna.
NimChimpsky

@NimChimpsky Bir proje içindeki tüm çıktıların tam kontrolüne sahipseniz, dış kişiler tarafından engellenmiyorsa ve eldeki görev hiçbir araştırma içermiyorsa, nispeten doğru bir tahmin elde etmek mümkündür. Bütçenizi sağlamak, zaman tahmininden önce kapsamlı bir analize kadar uzanır. Çoğu şirkette bütçe başlamadan önce tam olarak araştırılamaz.
yörüngede

@orbling Her zaman daha fazla zaman istemenin delillere, çıktılara, analizlere veya bütçelere dayanarak tamamen keyfi olması mümkündür.
NimChimpsky

2

Üçüncü taraf kütüphaneleri ve kullanımları ile ilgili en fazla sorun yaşadığımı görünce:

  1. Kullanacağınız kitaplıkları ve sürümleri belirleyin.
  2. Kütüphane güncellemelerini projenize entegre etme işlemini oluşturun.
  3. Geliştiricilerin hepsinin kütüphane tercihlerinde bulunduğundan emin olun.
  4. Kullanılan teknolojiler hakkında açık tartışma için faydalı bir kanal oluşturun.

Neden? Üçüncü parti kütüphanelerinin (tescilli) kaç haftalık geliştirme sürelerini bize geri gönderen kötü hatalara sahip olduğunu söyleyemem çünkü yukarı veya aşağı hareket etme sürecimiz yoktu. Veya geliştiricilerle "hangi sürümü kullandınız? Neden kullanım dışı olarak işaretlenmiş işlevleri kullandınız?"


1

Organizasyonlar için büyük bir maliyet, kalkınma yaşam döngüsü boyunca güvenliğe bütçe tahsis etmiyor, yani güvenlik genellikle çok iyi yapmak için çok geç yapılan etkisiz, pahalı faaliyetler veya kontroller gerçeğinden sonra ortaya çıkıyor.

İlk proje planından, temel kilometre taşlarıyla, gelişimin diğer tüm yönlerinde olduğu gibi güvenliği sağlayın ve güvenlik rehberliğini güncel tutmak için yinelemeli bir süreç kullanın. Güvenlikten son imza, tüm güvenlik kontrollerinin tasarıma göre uygulandığına dair sürpriz olmayan bir kontrol olmalıdır.

Aksi takdirde, uygulamadan sonra güvenliği çalıştırırsınız - bunun maliyeti 8 - 10 kat daha fazla olabilir (Gartner, IBM ve diğerlerinden gelen rakamlar), işlevsellikten etkilenme olasılığı olduğundan insanları rahatsız edecek ve sömürüyü önlemek için çok geç olabilir ve hasar.


Merak ediyorum, bu proje kurulum kontrol listesinin bir parçası olmalı? Bunu yazılım geliştirmenin bir parçası olarak koyardım ama proje kurulumunu bilmiyorum. Dev kilometre taşlarına koyardım, ama OP'nin sorduğu şey bu değil, yanlış olabilirim.
BlackICE

David - belki de bu ayrıntı düzeyinin orada olmaması gerektiğinde haklısın, ama bence en azından güvenlik için bir satır öğesi olmalı. Daha iyi?
Rory Alsop

1

1. Takıma götürün

Programcılara sorun! Gerçekten, bu en önemli şey. Geliştiriciler bu değişikliğe doğrudan dahil değilse, çok fazla direnişle karşılaşacaksınız. Sonuçta, bu nasıl çalıştıklarıyla ilgili , sen değil. Söylemeye gerek yok, ama insanlar üzerinde yöntem ve araçları zorlamaya çalışmak genellikle korkunç ateşler.

2. Kontrol edin ve uyarlayın

Deneyiminizi kullanarak seçilen piste hafifçe yardım etmelerini sağlamak için ekibin en iyi çalışma yolunu bulmasını sağlayın. Ardından, düzenli ve işbirliği içinde, nasıl bir iş yaptığınıza bakın ve süreci daha iyi hale getirmek için uyarlayın.

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.