Özel Yazım Yönetimi


9

Spesifikasyon olmadan yazılım yazmayı hayal bile edemiyorum. Ne kadar kabataslak veya üst düzey olursa olsun, spec programcıların programın işlevleri hakkında clueless programcılara açıklamak önemlidir.

Ancak spec ile ilgili sorun, tüm yazılım geliştirme döngüsünde bir şekilde ikinci sınıf bir vatandaş olması; gelişme buharı aldığında ihmal edilir. Ancak anlaşmazlık ortaya çıktığında, geliştiriciler ve testçiler ve satışlar, gerekçelerini haklı çıkarmak için spesifikasyonu bulmak için uğraşacaklar.

Bir veya daha fazla senaryo gerçekleşir:

  1. Spesifikasyon kurtarılamaz, kimse spesifikasyonun nerede olduğunu bilmiyor
  2. Spesifikasyonun farklı versiyonları farklı kaynaklardan ortaya çıkar; o son sürümüdür sürümün hangisi olduğunu öğrenmek için büyük zorluklara alır ya da orada olmadığını ise mevcut bir son sürümü.
  3. Spesifikasyon eksik, atıfta bulunduğu belgelerin bazı kısımları eksik.

Bu nedenle spec yönetimi önemlidir ve herkesin sadece Tek Bir Spec Kaynağı olması da eşit derecede önemlidir.

Spesifikasyonlarınızı nasıl yönetiyorsunuz? Herkesin Google Dokümanlar'ı kullanmasını sağlamaya çalıştım, ancak herkes itiraz etti. Herkes, Microsoft Word ile çok fazla bağlı ve büyülüyor, bu da - onların görüşüne göre - kullanımı çok kolay, resim eklemek çok kolay, denklem yazmak çok kolay ve ne olursa olsun.

Onları MS Word'ün paylaşım için korkunç olduğuna nasıl ikna edebilirim?

Yanıtlar:


6

Onları MS Word'ün paylaşım için korkunç olduğuna nasıl ikna edebilirim?

Zamanını boşa harcama.

İlk. Spesifikasyon düz metin (gerçekten) ve kaynak kodu kontrolü altında olmalıdır. Kullanım Markdown veya RST veya başka hafif işaretleme aracı bir PDF veya HTML sayfası üretmek. Düz metin.

İkinci. Çeşitli kaynakları ele alalım. Onları birleştir. Kendi nihai belgenizi yazın.

İtiraz ettiklerinde iki seçenekleri vardır.

  1. Sürümünüzü düzenlemek için Google Dokümanlar'ı (veya kaynak kodu kontrol aracını) kullanın .

  2. Düzenlediğiniz, filtrelediğiniz ve son belgeye dönüştürdüğünüz değişiklikleri göndermeye devam edin.

# 2'yi tercih ederim. Birisi özellikleri "sahip" gerekir. Ve bir grup insan (wiki tarzı) tartışmalara ve değişim savaşlarına, yan belgelere ve çevrimdışı sohbetlere ve benzerlerine yol açar.


1
+1 ve En Az Güç Kuralı'nı hatırlayın - WYSIWYG editöründe süslü bir sürüm isteyen herkes işlenen işaretlemeyi kopyalayabilir.
l0b0

@ l0b0: Güzel bağlantı.
S.Lott

6

Bunun bir "araç" sorunu değil, bir "süreç" (veya süreç eksikliği) sorunu olduğunu düşünüyorum.

Muhtemelen yazılımı serbest bırakmak için bir işleminiz var (birim testi, entegrasyon testi, serbest bırakma mektubu, teslimat, vb.), Ayrıca bir belge süreci de uygulamanız gerekir.

  • Teknik özellikleri kim yazacak? Onları kim güncelleyecek veya koruyacak?
  • Teknik özellikleri kim inceleyecek?
  • Teknik özellikleri kim onaylayacak? Mimar, Proje lideri, KG?
  • Teknik özellikler nasıl saklanır?
  • Kim eski sürümlerin kullanılmadığından emin olacak?

2
+1: takım problemleri genellikle süreç problemlerinin belirtileridir.
S.Lott

bir sürecimiz var, ancak insanlar sürecin mümkün olmadığı ve köşeleri kesmediğinden şikayet etmeyi seviyorlar.
Graviton

@Graviton: Temel probleminiz yönetimin belgelerin kullanımını görememesi ve bu nedenle katı kurallar uygulamamasıdır. Eğer bir şeylerin gelişmesini istiyorsanız, muhtemelen onlara ne kadar önemli olduğunu göstermelisiniz.
Xavier T.

4

Bir çeşit kontrol kesinlikle gereklidir.

Sürümlendirilmesi ve imzalanması gerekiyor ve bu sürecin katı olması gerekiyor.

Çok fazla yerde, çıkış ihmal edilir ve bu da topuz kavgalarına yol açar.

Konum, izlenebildiği sürece önemli değil

  • Paylaşım Noktası
  • güvenli, yedeklenmiş paylaşılan bir sürücü
  • Bazı yerlerde kod kaynak kontrolünü kullandığını gördüm !!

Ancak daha önemli olan, ilgili tüm ve 1 veya 2 kişiden satın almanız gerekir. Proje Yöneticisi.


+1, başka bir şey yardımcı olmazsa spec doc'yi kaynak kontrolüne taşımanızı şiddetle tavsiye ederim. Bir avantajı sürüm geçmişini almanızdır. Sürüm diffs yapamasanız bile (Word dosyalarında diffs yapabilen bir eklenti bulamazsanız) yine de tüm sürümü ayıklayabilir ve nelerin değiştiğini görebilirsiniz. Bu özellikler üzerinde bir anlaşmazlık ÇOK yararlı olabilir. Çıkış da olması çok iyi. Ayrıca herkesin sürece dahil olmasının önemi (böylece hiç kimse "ne zaman karar verildi?" Diyemez) yeterince vurgulanamaz.
FrustratedWithFormsDesigner

0

MS Word, bir özellik oluşturmak için mükemmel bir seçenektir. Biz de SharePoint'te yönetiyoruz. SharePoint veya başka bir doküman yönetimi ürününüz yoksa, Google Dokümanlar tamamdır (artık .doc / .docx dosyalarını Google Dokümanlar biçimine dönüştürmeden yükleyebilirsiniz). Veya başkalarının önerdiği gibi, bunları kaynak kodu sürüm kontrol sisteminizde bile saklayabilirsiniz (özellikleri oluşturan kişiler bu sisteme erişebiliyorsa).


0
 > How to convince them that MS Word is just terrible for sharing?

bir sürüm kontrol sistemindeki iki örneğin farkını kolayca karşılaştıramazsınız.

Bu nedenle kelime özelliklerini sevmiyorum. Ancak, sözcük özelliklerini kullanmak politik bir karar olduğu için, bu sütunlarla ilk sayfa "tarih bilgileri" olarak var:

sürüm numarası (ürün sürümü ile ilgilidir), yazar, tarih, açıklama

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.