El Kitapları - Nasıl Güncel?

Uzun zamandır piyasada olan bir ürününüz varsa, ancak hala günlük olarak aktif bir gelişme gösteriyorsa - kılavuzlar ne sıklıkta güncellenmelidir? Kuruluşunuzun en son hata düzeltmelerinin her zaman gönderilen sürümde olduğundan emin olması nedeniyle kullanıcılarınız sürekli kanayan sürüme güncellenirse. Yani, bir gün bir hatayı düzeltebilirsiniz ve ertesi gün üretime çarpıyor.

Kılavuzu güncelleyeceğim:

1. Her büyük sürüm için ve
2. Önemli yeni özellikler, her beş dakikada bir değişmeyeceklerini bilecek kadar istikrarlı ve olgunlaştığında.

bir kod değişikliğinin kılavuzdaki talimatları değiştireceği her zaman (PDF) el kitabını güncelleyin; yalnızca sürüm sürecinin manuel kısmını güncellemeniz yeterlidir

kullanıcılar ürünü nasıl kullanacaklarını söylemek için kılavuza güveniyorsa ve ürün değişiyorsa, kılavuzun ilgili bölüm (ler) inin de değişmesi sadece sağduyu

2010'da hala basılı belgelere mi atıfta bulunuyoruz? Neden? ;)

Tüm ciddiyetle, belgeler ("F1" uygulama yardımı, PDF veya çevrimiçi belgeler) her bir sürümün parçası olmalıdır. Sıfır bahane. "Yayınlamak" çok kolay. Nitekim IMO olarak, sorunlar bilindiği ve düzeltildiği anda yayınlar arasında bile belgelerin düzenli olarak (çevrimiçi ve PDF) güncellenmemesi için hiçbir mazeret yoktur. Aynı QA seviyesine ihtiyaç duymaz - hatta yakın değildir.

Son kullanıcı belgelerinden bahsettiğinizi varsayıyorum. Belgeleri yazmak @ $$ 'da bir acıdır ve beni tersine ikna etmek için bazı teknikler geliştirirken, hala bununla ilgili problemlerim var. Bu şekilde yönetmeye çalışıyorum:

DoD'nizdeki dokümantasyon güncellemesini entegre edin ( Tanımı tamamlandı )

Bu, her bir kullanıcı hikayesinin tamamlanmasının sonunda belgelerinizin güncel olmasını sağlayacaktır.

İşte yazdığımız tamamın tanımı. Orijinal formatları korumaya çalıştım, böylece fikri anladınız. Beyaz tahtaya yerleştirilmiş bir A4 sayfası.

---------- 8 <------------ Burada Kes ------------ 8 <----------

Pazarlık edilemez

“Done” un tanımı

• % 80 birim test kapsamına sahip kod, depoda işlendi

• Varsa ekran görüntüleri (1024x728, 395x281, 170x121 ve 729x329)

• Varsa özellik açıklamaları (50 karakter, 100 karakter)

• Tam son kullanıcı belgeleri

• Yeni dosya düzgün bir şekilde güncellendi

---------- 8 <------------ Burada Kes ------------ 8 <----------

Tabii ki belgelere bir inceleme süreci ekleyebilirsiniz. Hiçbirimiz ana dili İngilizce olan biri olmadığımızdan emin olduk.

Bunun gibi Tanımın Tamamlanması'nın avantajlarından biri, ürününüzün her kullanıcı hikayesinin tamamlanmasının sonunda potansiyel olarak gönderilebilir olmasıdır .

Birlikte bu tekniği kullanın bu bir .

Kuruluşumda genellikle 3 çeşit bültenimiz var:

1. Mühendislik Sürümü - temel olarak belirli bir müşteri veya yalnızca belirli bir müşterinin hemen talep ettiği bazı özellikler için sıcak düzeltme.
2. Küçük Sürüm - hata düzeltmeleri, artımlı destek
3. Büyük Sürüm - yeni özellik desteği vb.

Tanımı gereği, Major Release, çevrimiçi ve çevrimdışı ilgili belgelere sahip olmalıdır. İzleme sistemimiz, belgelerin kontrol listesinin bir parçası olmasını sağlar.

Küçük sürümler, yalnızca kullanıcı algısı düzeyinde eklenen yeni her şeyin belgelerine ihtiyaç duyar. Bu nedenle, bazı belirli senaryolarda zaman karmaşıklığını azaltabilecek başka bir buluşsal yöntem eklediyseniz, pdf'ye koymak için önemli bir çağrı olabilir veya olmayabilir.

Mühendislik sürümleri dokümantasyon olmadan yapılabilir. Bazı gayri resmi kullanım notları, başlamak için yeterince iyi olmalıdır.

Dokümantasyon, bir müşteriye gönderdiğiniz yazılım ile senkronize olmalıdır. Başka herhangi bir yanlış eşleşme size sorun yaratacaktır. Ve eğer personelinizde bir yazarınız yoksa, yüklenicileri deneyin. Beğendiğiniz birini bulduğunuzda, tutucusunda tutun.