요구 사항에 위키 사용

요구 사항 관리를 개선하는 방법을 찾고 있습니다. 현재 웹 사이트에 Word 문서가 게시되어 있습니다. 불행히도 우리는 (내 지식으로는) 한 개정에서 다음 개정으로의 변화를 볼 수 없습니다. 위키 또는 VCS (또는 둘 다, 위키의 비트 버킷과 마찬가지로)와 마찬가지로 그렇게 할 수 있기를 선호합니다.

또한 각 문서는 개발자가 주어진 마감일까지 충족해야 할 변경 사항을 설명합니다. 어디에도 문서화 된 누적 된 앱 기능 모음이 없으므로 레거시 앱을 빠르게 수정하려고 할 때 버그와 (잘못 설계된) 기능을 구분하기가 어려운 경우가 있습니다.

그래서 피드백을 받고 싶다는 생각이있었습니다. 이건 어떤가요:

1. 우리가 때 (주로도에 표시되는 내용 변경 사람 추적 할 수 있도록 위키를 사용 하면 마지막으로 하나가 보였다 때문에 어떤 편집이 이루어졌다).
2. 예를 들어 마감 일당 하나가 아닌 제품 당 하나의 위키 페이지가있어 구현해야 할 변경 사항이 아니라 제품의 모든 기능을 유지할 수 있습니다. 이렇게하면 특정 시점에서 앱이 수행해야 할 작업을 확인하기 위해 페이지의 특정 개정을 볼 수 있으며 다음 마감일까지 구현해야 할 요구 사항에 대한 마지막 릴리스 이후의 페이지 변경 사항을 볼 수 있습니다 .

Waddayathink?

예, 간단한 구조로 페이지를 구성하고 탐색하기 쉬운 경우 좋은 해결책입니다.

간단한 구문으로 위키를 선택하십시오. ( Dokuwiki 는 간단한 것으로 DB가 필요하지 않습니다.)

편집 : 버전 제어 시스템 (SVN 또는 BZR)을 사용하는 경우 Trac을 시도하십시오 . 여기서 마일스톤을 정의하고 버그 및 기능 요청을 유지하며 버그를 관리하는 자체 워크 플로우를 정의 할 수 있습니다! 위키가 포함되어 있습니다!

위키는 좋은 방법입니다. 문서의 버전이 여전히 가장 좋을 것이라고 생각합니다. 최신 기능을 유지하는 플로팅 설명서가있을 수 있습니다. 빠른 히스토리를 위해 만들어졌으며 몇 년 또는 몇 달을 되돌아 보는 데는 적합하지 않은 문서 기록을 보지 않고도 3 버전 이전에 해당 소프트웨어의 문서를 쉽게 찾을 수있는 방식으로 스냅 샷을 찍습니다.

Media Wiki를 사용하기 시작했지만 이제 Xwiki를 사용하고 있습니다. 누구나 교육없이 사용할 수있는 꽤 좋은 GUI 편집기가 있습니다. 또한 각 공간에 새로운 네임 스페이스를 생성하는 'spaces'라는 아이디어가 있으므로 다른 제품은 product_x_features 또는 어리석은 것이 아니라 "features"라는 페이지를 가질 수 있으므로 여러 위키 설치를 관리해야 할 필요성이 크게 줄어 듭니다. 또한 단어와 xwiki를 통합하는 도구가있어 단어 문서를 위키에 직접 저장할 수 있습니다. 모두 훨씬 더 기능이 풍부하다고 말했다.

프로젝트 별 위키 접근 방식이 마음에 듭니다. 비트 버킷을 언급했는데,이를 저장소 호스트로 사용한다고 가정합니다. 그렇지 않다면 GitHub의 위키를 살펴볼 것입니다.

약간의 돈을 기꺼이 보내려면 Lighthouse를 확인하십시오 . 현재 기능 요청 및 버그를 추적하는 가장 좋아하는 방법입니다. 나는 또한 Pivotal Tracker를 사용하는 것을 좋아합니다. 중추는 무료이지만 유료 모델을 향해 움직이고 있습니다.