매뉴얼-최신 정보

오랜 시간 동안 시장에 출시 된 제품이 있지만 여전히 매일 개발중인 제품인 경우 매뉴얼을 얼마나 자주 업데이트해야합니까? 조직에서 최신 버그 수정이 항상 제공되는 버전이라는 사실 때문에 사용자가 최신 버전으로 지속적으로 업데이트되는 경우. 즉, 언젠가는 버그를 고칠 수 있고 다음 날에는 생산을 시작합니다.

매뉴얼을 업데이트합니다.

1. 각 주요 릴리스마다
2. 중요한 새 기능이 안정적이고 성숙 해지면 5 분마다 변경되지 않는다는 것을 알 수 있습니다.

코드 변경으로 인해 설명서의 지침이 변경 될 때마다 (PDF) 설명서를 업데이트하십시오. 릴리스 프로세스의 설명서 부분 만 업데이트하십시오.

사용자가 설명서를 사용하여 제품 사용 방법을 알려주고 제품이 변경되면 설명서의 관련 섹션도 변경해야한다는 것은 상식입니다.

2010 년에도 여전히 인쇄 된 문서를 참조하고 있습니까? 왜? ;)

진지하게, 문서 ( "F1"응용 프로그램 도움말, PDF 또는 온라인 문서)는 모든 단일 릴리스의 일부 여야합니다. 변명의 여지가 없습니다. "게시"하는 것은 간단합니다. 사실, IMO는 문제가 알려지고 수정 되 자마자 릴리스 간에도 정기적으로 (온라인 및 PDF) 문서를 업데이트하지 않는다는 변명의 여지가 없습니다. 동일한 수준의 품질 관리가 필요하지 않습니다.

최종 사용자 설명서에 대해 이야기한다고 가정합니다. 문서를 작성하는 것은 @ $$의 고통이며, 저에게 그 반대를 확신시키는 기술을 개발했지만 여전히 그 문제가 있습니다. 이것이 내가 관리하려고하는 방법입니다.

DoD에 문서 업데이트 통합 ( 정의 정의 )

이렇게하면 각 사용자 스토리 완료시 문서가 최신 상태가됩니다.

여기에 우리가 쓴 완료의 정의가 있습니다. 원래 형식을 유지하려고 했으므로 아이디어를 얻을 수 있습니다. 화이트 보드에 놓인 A4 페이지입니다.

---------- 8 <------------ 여기 잘라 ------------ 8 <----------

협상 할 수없는

"완료"의 정의

• 저장소에서 커밋 된 80 % 단위 테스트 범위의 코드

• 해당되는 경우 스크린 샷 (1024x728, 395x281, 170x121 및 729x329)

• 해당되는 경우 기능 설명 (50 자, 100 자)

• 완전한 최종 사용자 문서

• 새로운 파일이 제대로 업데이트되었습니다

---------- 8 <------------ 여기 잘라 ------------ 8 <----------

물론 문서에서 검토 프로세스를 추가 할 수 있습니다. 우리는 아무도 영어를 모국어로 사용하지 않습니다.

이와 같은 정의 정의의 장점 중 하나는 사용자 스토리가 완료 될 때마다 제품을 배송 할 수 있다는 것 입니다.

와 함께이 기술을 사용하여 이 일 .

우리 조직에는 일반적으로 3 가지 종류의 릴리스가 있습니다.

1. 엔지니어링 릴리스-기본적으로 특정 고객 또는 특정 고객 만 즉시 요청한 일부 기능에 대한 핫픽스입니다.
2. 부 릴리스-버그 수정, 증분 지원
3. 주요 릴리스-새로운 기능 지원 등

기본적으로 주 릴리스에는 온라인과 오프라인 모두에 관련 문서가 있어야합니다. 당사의 추적 시스템은 문서가 점검 목록의 일부가되도록합니다.

부 릴리스는 사용자 인식 수준에서 추가 된 새로운 항목에 대해서만 문서가 필요합니다. 따라서 일부 특정 시나리오에서 시간 복잡성을 줄일 수있는 또 다른 휴리스틱을 포함시킨 경우이를 pdf에 넣는 것이 중요하지 않을 수도 있습니다.

엔지니어링 릴리스는 문서화없이 수행 할 수 있습니다. 일부 비공식적 인 사용 메모는 시작하기에 충분해야합니다.

설명서는 고객에게 제공하는 소프트웨어와 동기화되어야합니다. 다른 불일치로 인해 문제가 발생합니다. 스태프에 작가가없는 경우 계약자를 사용해보십시오. 당신이 좋아하는 것을 찾으면, 그를 유지하십시오.