스펙 작성 관리

9

나는 스펙없이 소프트웨어를 작성하는 것을 상상할 수 없다. 아무리 스케치 적이거나 높은 수준이더라도, 프로그램의 기능이 무엇인지 실마리가없는 프로그래머에게 설명하는 것이 중요합니다.

그러나 스펙의 문제점은 전체 소프트웨어 개발주기에서 다소 2 등 시민이라는 점입니다. 개발 과정에서 스팀이 발생하면 무시됩니다. 그러나 분쟁이 발생하면 개발자와 테스터 및 영업 담당자는 자신의 근거를 정당화 할 사양을 찾기 위해 열광 할 것입니다.

하나 이상의 시나리오가 발생합니다.

사양을 복구 할 수 없습니다. 사양이 어디에 있는지 아무도 모릅니다
스펙의 다른 버전은 다른 소스에서 나옵니다. 어떤 버전이 최신 버전인지 또는 사용 가능한 최신 버전 이 있는지 확인하는 데 큰 어려움이 있습니다.
사양이 불완전하며 참조하는 문서의 일부가 누락되었습니다.

따라서 스펙 관리가 중요하며 모든 사람이 하나의 단일 스펙 소스 만 갖는 것이 중요합니다.

사양을 어떻게 관리합니까? 모든 사람이 Google 문서 도구를 사용하도록했지만 모두 반대했습니다. 모든 사람들은 Microsoft Word에 너무 집착하고 매료되어 사용하기 쉽고 이미지를 삽입하기 쉽고 방정식을 입력하기가 매우 쉽습니다.

MS Word가 공유하기에 끔찍하다고 확신시키는 방법은 무엇입니까?

specifications

— 그 라비 톤
소스

6

MS Word가 공유하기에 끔찍하다고 확신시키는 방법은 무엇입니까?

시간을 낭비하지 마십시오.

먼저. 사양은 일반 텍스트 (실제로)이고 소스 코드로 제어되어야합니다. 사용 마크 다운 또는 RST 또는 다른 경량의 마크 업 도구는 PDF 나 HTML 페이지를 생성합니다. 일반 텍스트.

둘째. 다양한 출처를 살펴보십시오. 병합하십시오. 최종 문서를 작성하십시오.

그들이 반대 할 때는 두 가지 선택이있다.

Google 문서 도구 (또는 소스 코드 제어 도구)를 사용 하여 버전 을 편집 하십시오 .
최종 문서에서 편집, 필터링 및 변경 한 변경 사항을 계속 보내십시오.

나는 # 2를 선호합니다. 누군가 스펙을 "소유"해야합니다. 그리고 많은 사람들 (위키 스타일)은 토론과 변화, 사이드 문서, 오프라인 대화 등으로 이어집니다.

— 로트
소스

1

+1하고 최소한 의 규칙을 기억하십시오 -WYSIWYG 편집기에서 멋진 버전을 원하는 사람은 렌더링 된 마크 업을 복사하면됩니다.

— l0b0

@ l0b0 : 좋은 링크.

— S.Lott

6

"도구"문제가 아니라 "프로세스"(또는 프로세스 부족) 문제라고 생각합니다.

소프트웨어를 릴리스하는 프로세스 (단위 테스트, 통합 테스트, 릴리스 레터, 전달 등)가 이미있을 수 있으며 문서 프로세스도 구현해야합니다.

누가 사양을 쓰려고합니까? 누가 업데이트하거나 유지 관리합니까?
누가 사양을 검토 할 예정입니까?
누가 사양을 승인 할 것입니까? QA 설계자, 프로젝트 리더?
사양은 어떻게 저장됩니까?
더 이상 사용되지 않는 버전을 사용하지 않는 사람은 누구입니까?

— 자비에르 T.
소스

2

+1 : 공구 문제는 종종 프로세스 문제의 증상입니다.

— S.Lott

우리는 프로세스를 가지고 있지만 사람들은 프로세스가 작동하지 않고 가능할 때마다 모서리를 자르지 않는다고 불평하기를 좋아합니다.

— Graviton

@ Graviton : 주된 문제는 아마도 경영진이 문서 사용을 볼 수 없으므로 엄격한 규칙을 시행하지 않는 것입니다. 개선하기를 원한다면 아마도 그것이 얼마나 중요한지 보여 주어야 할 것입니다.

— Xavier T.

4

명확한 제어가 필요합니다.

버전을 지정하고 사인 오프해야하며이 프로세스는 엄격해야합니다.

너무 많은 곳에서는 사인 오프가 무시되어 롤빵 싸움으로 이어집니다.

위치를 추적 할 수있는 한 중요하지 않습니다

공유 지점
안전한 백업 공유 드라이브
일부 장소에서 코드 소스 제어를 사용하는 것을 보았습니다 !!

그러나 더 중요한 것은 문서와 사인 오프를 모두 관리하는 것입니다. 프로젝트 관리자.

— 오즈
소스

+1, 아무것도 도움이되지 않으면 사양 문서를 소스 제어로 옮기는 것이 좋습니다. 한 가지 장점은 버전 기록을 얻는 것입니다. 버전 diff를 수행 할 수없는 경우에도 (Word 파일에서 diff를 수행 할 수있는 플러그인을 찾지 않는 한) 여전히 모든 버전을 추출하고 변경된 내용을 볼 수 있습니다. 이는 사양에 대한 분쟁에서 매우 유용 할 수 있습니다. 사인 오프도 매우 좋습니다. 또한 프로세스에 모든 사람을 참여시키는 것의 중요성 (따라서 "언제 결정 되었는가?"라고 말할 수있는 사람)은 충분히 강조 할 수 없습니다.

— FrustratedWithFormsDesigner

0

MS Word는 스펙 작성에 완벽하게 적합합니다. 버전 관리도 처리하는 SharePoint에서 관리합니다. SharePoint 또는 다른 문서 관리 제품이없는 경우 Google 문서 도구가 정상입니다 (이제 Google 문서 형식으로 변환하지 않고도 .doc / .docx 파일을 업로드 할 수 있습니다). 또는 다른 사람들이 제안했듯이 소스 코드 버전 제어 시스템에 저장할 수도 있습니다 (사양을 작성한 사람이 해당 시스템에 액세스 할 수있는 경우).

— 마시에
소스

0

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

버전 제어 시스템에서 두 인스턴스의 차이점을 쉽게 비교할 수는 없습니다.

그런 이유로 단어 사양을 좋아하지 않습니다. 그러나 단어 사양을 사용하는 것이 정치적 결정이기 때문에 우리는 이러한 열과 함께 첫 페이지 "역사 정보"를 갖습니다.

버전 번호 (제품 버전과 관련됨), 작성자, 날짜, 설명

— k3b
소스