Посібники - як до цього часу?

Якщо у вас є продукт, який тривалий час є на ринку, але він все ще активно розвивається щодня - як часто слід поновлювати посібники? Якщо ваші користувачі постійно оновлюються до крайньої версії через те, що ваша організація вважає за потрібне, що останні виправлення помилок завжди є у постачаній версії. Це означає, що ви можете виправити помилку одного дня, а наступного дня вона вражає виробництво.

Я б оновив посібник:

1. Для кожного основного випуску та
2. Коли важливі нові функції стають стабільними та зрілими, ви знаєте, що вони не збираються змінюватися кожні п’ять хвилин.

оновлюйте посібник (PDF) будь-коли, щоб зміна коду змінила інструкції в посібнику - просто зробіть оновлення ручної частини процесу звільнення

якщо користувачі покладаються на посібник, щоб сказати їм, як користуватися продуктом, а продукт зміниться, тоді єдиний здоровий глузд має також змінити відповідний розділ посібника.

У 2010 році ми все ще маємо на увазі друковану документацію? Чому? ;)

По суті, документація (довідка щодо додатків "F1", PDF або онлайн-документація) повинна бути частиною кожного випуску. Нульові виправдання. Це так просто "опублікувати". Насправді, IMO, немає жодного приводу для того, щоб не оновлювати документацію регулярно (в Інтернеті та PDF), навіть між випусками, як тільки проблеми будуть відомі та виправлені. Для цього не потрібен той самий рівень якості - навіть близько.

Я припускаю, що ви говорите про документацію для кінцевого користувача. Написання документації болить у $ $ і, хоча я розробив певну техніку, щоб переконати мене в зворотному, у мене все ще виникають проблеми з цим. Ось як я намагаюся ним керувати:

Інтегруйте оновлення документації у свій DoD ( Визначення зроблено )

Це забезпечить оновлення вашої документації в кінці кожного завершення історії користувача.

Ось визначення зробленого ми написали. Я намагався зберегти оригінальне форматування, щоб ви зрозуміли ідею. Це сторінка формату А4, розміщена на дошці.

---------- 8 <------------ Виріжте тут ------------ 8 <----------

Не оборотний

Визначення "Готово"

• Код із покриттям тесту на 80%, виконаний у сховищі

• Знімки екрана, якщо застосовується (1024x728, 395x281, 170x121 та 729x329)

• Описи функцій, якщо це можливо (50 символів, 100 символів)

• Повна документація для кінцевого користувача

• Що нового файл належним чином оновлений

---------- 8 <------------ Виріжте тут ------------ 8 <----------

Звичайно, ви можете додати процес огляду в документацію. Ми маємо це, оскільки ніхто з нас не є носієм англійської мови.

Однією з переваг подібного визначення Done є те, що ваш продукт потенційно може бути доставлений в кінці кожного завершення історії користувача.

Використовуйте цю техніку в поєднанні з цією .

У моїй організації, як правило, є три види випусків:

1. Інженерний реліз - в основному гаряче виправлення для певного конкретного замовника або деяку функцію, яку тільки конкретний клієнт просив негайно.
2. Незначний випуск - виправлення помилок, додаткова підтримка
3. Основний реліз - підтримка нових функцій тощо.

За визначенням, майор-реліз повинен мати відповідну документацію як в Інтернеті, так і в режимі офлайн. Наша система відстеження забезпечує, що документація входить до складу контрольного списку.

Незначні випуски потребують документації лише на все нове, що було додано на рівні сприйняття користувача. Тож якщо ви включили ще одне евристичне, що може зменшити складність у часі в деяких конкретних сценаріях, це може бути, а може, і не бути значним закликом помістити його у pdf.

Випуски інженерії можуть обійтися без документації. Деякі примітки щодо неофіційного використання повинні бути досить хорошими, щоб розпочати роботу.

Документація повинна синхронізуватися з програмним забезпеченням, яке ви постачаєте клієнту. Будь-який інший невідповідний збір створить вам проблеми. І якщо у вас немає письменника на персоналі, спробуйте підрядників. Як тільки ви знайдете той, який вам сподобався, тримайте його на фіксаторі.