використання вікі для вимог


9

Я розглядаю шляхи вдосконалення управління вимогами. На даний момент у нас є документ Word, опублікований на веб-сайті. На жаль, ми не можемо (наскільки мені відомо) переглядати зміни від однієї редакції до іншої. Я дуже вважаю за краще мати можливість це робити, як і у вікі або VCS (або в обох, як у вікі на бітбукет!).

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

Тож у мене виникла ідея, про яку я хочу отримати відгук. А як на рахунок:

  1. Використовуючи вікі, ми можемо відстежувати, хто змінив те, що коли (в основному, навіть, щоб побачити, чи були внесені зміни з моменту останнього перегляду)
  2. Маючи одну, скажімо, сторінку вікі на продукт, а не одну на термін, в курсі всіх функцій продукту, а не змін, які слід впровадити. Таким чином, я можу переглянути конкретну редакцію сторінки, щоб побачити, що додаток повинен робити в певний момент часу, і я можу переглянути зміни на сторінці після останнього випуску вимог, які будуть впроваджені до наступного терміну .

Waddayathink?

Відповіді:


9

Так, це добре рішення, якщо ви впорядковуєте сторінку в простій структурі, простій для перегляду.

Виберіть вікі з простим синтаксисом. ( Dokuwiki - простий і не потребує БД)

Редагувати: якщо ви використовуєте систему контролю версій, тобто SVN або BZR, спробуйте Trac , де ви можете визначити етап, зберігаючи помилку та запит на функції, а також визначити власний робочий процес для управління помилкою! Вікі включено!


DokuWiki чудовий, дуже простий у налаштуванні, він включає підтримку LDAP, якщо ви працюєте в Enterprise.
Старий рахунок

2

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

Я почав використовувати Media Wiki, але зараз ми використовуємо Xwiki. Він має досить хороший графічний редактор, яким кожен може користуватися без будь-якої підготовки. У ньому також є ідея під назвою "пробіли", кожен пробіл створює новий простір імен, тому різні продукти можуть мати сторінку під назвою "функції", а не product_x_features або щось нерозумне, це значно зменшує потребу в управлінні кількома вікі-установками. Також є інструменти для інтеграції word та xwiki, що дозволяють вам зберігати текстові документи безпосередньо у вікі. Усі сказали, що це набагато більше функціональних можливостей.


1

Мені подобається ваш підхід до вікі за проектом. Ви згадали про бітбукет, я вважаю, що ви використовуєте їх у якості хоста сховища. Якщо ні, то я б також подивився на вікі на GitHub.

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

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