Управління написанням спец


9

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

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

Буде один чи більше сценаріїв:

  1. Спеціалізацію неможливо відновити, ніхто не знає, де знаходиться специфікація
  2. Різні версії специфікації виходять з різних джерел; потребує великих труднощів з’ясувати, яка саме версія є останньою версією чи є найновіша версія.
  3. Специфікація є неповною, деякі частини документів, на які вона посилається, відсутні.

Тому управління спекуляціями є важливим, і не менш важливо, щоб кожен мав лише одне єдине джерело специфікації.

Як ви керуєте своїми характеристиками? Я намагався змусити всіх використовувати Документи Google, але всі заперечували. Усі просто надто прив’язані та закохані в Microsoft Word, який - на їхню думку - дуже простий у використанні, дуже простий вставку зображення, дуже простий набір рівнянь та багато іншого.

Як переконати їх у тому, що MS Word просто жахливий для спільного використання?

Відповіді:


6

Як переконати їх у тому, що MS Word просто жахливий для спільного використання?

Не витрачайте час.

Спочатку. Spec має бути в простому тексті (дійсно) та під контролем вихідного коду. Використовуйте Markdown або RST або який -небудь інший інструмент легких розміток для створення PDF або HTML - сторінки. Простий текст.

Друге. Візьміть різні джерела. Об’єднайте їх. Напишіть власний підсумковий документ.

Коли вони заперечують, у них є два варіанти.

  1. Використовуйте Документи Google (або інструмент контролю вихідного коду) для редагування вашої версії.

  2. Продовжуйте надсилати вам зміни, які ви редагуєте, фільтруєте та перетворюєте у підсумковий документ.

Я віддаю перевагу №2. Комусь потрібно «володіти» специфікацією. І купа людей (у стилі вікі) призводить до дебатів та воєн змін, а також сторонніх документів та офлайн-розмов тощо.


1
+1, і пам’ятайте правило найменшої потужності - той, хто хоче фантазійну версію в редакторі WYSIWYG, може просто скопіювати відтворену розмітку.
l0b0

@ l0b0: Приємне посилання.
S.Lott

6

Я не думаю, що це питання "інструменту", а скоріше "процес" (або відсутність процесу).

Напевно, у вас вже є процес випуску програмного забезпечення (перевірка блоку, тест інтеграції, лист випуску, доставка тощо), вам також потрібно впровадити процес документації.

  • Хто збирається писати характеристики? Хто збирається їх оновлювати чи підтримувати?
  • Хто збирається переглянути характеристики?
  • Хто збирається затвердити характеристики? Архітектор, керівник проекту, QA?
  • Як зберігаються специфікації?
  • Хто збирається переконатися, що не використовуються застарілі версії?

2
+1: проблеми з інструментами часто є симптомами проблемних процесів.
S.Lott

у нас є процес, але люди просто люблять скаржитися, що процес не працює і вирізати кути, коли це можливо.
Гравітон

@Graviton: Ваша основна проблема, ймовірно, полягає в тому, що керівництво не може бачити використання документації і, отже, не застосовувати суворі правила. Якщо ви хочете, щоб речі покращилися, вам, мабуть, доведеться показати їм, як це важливо.
Ксав’єр Т.

4

Певний контроль обов'язково потрібен.

Її потрібно обгрунтувати та підписати, і цей процес повинен бути суворим.

У занадто багатьох місцях виписом нехтують, і це призводить до боїв із балками.

Місце не має значення, поки його можна відстежувати

  • Поділитись думкою
  • безпечний, резервний копій спільного диска
  • Я бачив, що в деяких місцях використовується керування джерелом коду !!

Але ще важливіше, що вам потрібно придбати у всіх залучених та 1 або 2 людей, хто відповідальний за це - керувати як документом, так і підписом, наприклад. керівник проекту.


+1, я настійно пропоную перемістити документ-специфікатор до контролю джерела, якщо нічого іншого не допомагає. Однією з переваг є отримання історії версій. Навіть якщо ви не можете зробити різницю версій (якщо ви не знайдете плагін, який може відрізнятись від файлів Word), ви все одно можете витягнути всю версію та побачити, що змінилося. Це може бути дуже корисним у суперечці щодо специфікацій. Вихід також дуже хороший. А також важливість того, щоб усі учасники процесу брали участь (тому ніхто не може сказати "коли це було прийнято?") Не можуть бути підкреслені достатньою мірою.
FrustratedWithFormsDesigner

0

MS Word ідеально підходить для створення специфікації. Ми управляємо нашими в SharePoint, який також обробляє версію. Якщо у вас немає SharePoint або іншого продукту для управління документами, Google Docs у порядку (тепер ви можете завантажувати файли .doc / .docx, не перетворюючи їх у формат Google Документів). Або як запропонували інші, ви навіть можете зберігати їх у системі контролю версій вихідного коду (якщо люди, що створюють специфікації, мають доступ до цієї системи).


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

Ви не можете легко порівняти різницю двох випадків у системі управління версіями.

З цієї причини мені не подобаються словосполучення. Але оскільки це політичне рішення використовувати слова-специфікації, ми маємо як першу сторінку "відомості про історію" з цими колонками:

номер версії (стосується продукту-версії), автор, дата, опис

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.