개발 팀을위한 지원/유지 관리 문서

Question

저는 대형 전자 상거래 회사의 개발 부서 (약 40 명의 개발자)에서 일하고 있습니다. 우리는 빠르게 성장했지만 업무를 문서화하는 분야에서는 진화하지 않았습니다. 우리는 개발 및 테스트를 통해 민첩한/스크럼과 같은 방법론을 사용하지만 문서는 소홀한 것처럼 보입니다.

우리는 회사에서 일하기 전 또는 회사를 처음 보지 못한 개발자를 지원할 수있는 문서를 만들 수 있어야합니다. 또한 지원 부서에서 추가 구성 설정 및 발생할 수있는 알려진 문제점의 수정 사항을 설명하기 위해 더 높은 수준의 정보를 작성해야합니다.

현재 우리는 오래된 SharePoint/TFS 사이트를 기반으로 위키를 심어 놓았습니다.

설명서 표준을 향상시키는 데 이상적인 링크 나 조언이 있습니까? 다른 회사에서 효과가있는 것은 무엇입니까?

민첩 프로세스의 일부로 문서를 어떻게 개발할 수 있습니까?

Answer 1

우리는 매 밤마다 Doxygen 주석 블록을 사용하고 매일 밤 Doxygen을 실행하므로 문서가 매일 밤 생성되고 프로젝트 인트라넷 페이지에서 출력에 액세스 할 수 있습니다. 또한 코드 검토 프로세스의 일부로 소스 모니터를 사용합니다. 코드는 소스 코드 행에 대한 주석 행 비율을 충족해야합니다. 사람들은 때로는이 문제를 해결하기 위해 속일 수 있지만 코드가 수동으로 검토되기 때문에 남용됩니다.

Answer 2

전체 book은이 주제에 대한 내용을 전했습니다.

일반적으로 '너무 많은 것'대 '전혀없는 것'간의 적절한 상충 관계를 찾는 것은 매우 어렵습니다.

일반적으로 팀 통신에 자원을 투자하는 것은 시간이 많이 지나치게 오래된 구식 텍스트보다 더 유용합니다. 누구도 거의 읽지 않습니다. 새로운 개발자는 이미 코드, 프로세스 및 팀 문화를 충분히 알고있는 스승을 확보해야한다고 제안합니다. 멘토링을하는 동안 문서가 부족하고 더 완벽해질 수 있습니다. 쓸모없는 콘텐츠를 삭제하는 것도 매우 중요합니다. 잘못된 문서는 매우 혼란스럽고 전혀없는 것보다 훨씬 나쁩니다.

더 나은 것은 "조치"와 같은 더 많은 레시피입니다. checklists, 개발 설정, FAQ 또는 문제 해결 목록

편집 : 고정 링크는

Answer 3

내가 쓴 당신을 도울 수 add-in for Visual Studio (2010, 2008, 2005)는. C#, C++, C++/CLI, C, Java 및 Visual Basic의 모든 유형의 코드 요소에 대한 설명서 (Documentation XML, Doxygen 또는 JavaDoc)를 자동 생성하고 업데이트 할 수 있습니다. 이 도구는 코드 (이름 지정, 예외 발생, 이미 다른 메소드 또는 기본 클래스에있는 다른 문서)에서 최대한 많은 정보를 수집 한 다음 지능적으로 요약하고 대량의 문서를 생성하므로 개발자가 더 많은 정보를 입력하면됩니다 흥미롭고 중요한 문서 ("자체 문서화"코드에서 신성화 할 수없는 "이유"와 "방법"에 대한 설명). 또한 코드를 코드와 동기화하여 유지하기 위해 문서를 업데이트하고 코드 유지 관리 부담을 최소화하기 위해 형식을 깔끔하게 유지합니다 (단어 줄 바꿈 등). 훌륭한 시간을 절약하고 문서화 작업을 훨씬 덜 지루한 비즈니스로 만듭니다. 이는 종종 개발자 유형을 실제로 코드를 문서화 할 수있는 유일한 방법입니다.당신이 스크럼 조언이 비트를 사용하는 경우

Answer 4

가 : 당신이 그것을 할 그것에게 당신이 그 순간부터 할 것 모두를 시행하기 시작하면

• 추가가 완료 당신의 정의/코딩 있었는지를 변경 문서화에게, 이후가 될 것입니다 문서화되었거나 불완전한 것으로 간주됩니다. 이렇게하면 문제가 눈에 보이고 문제를 해결하는 데 도움이됩니다.
• 과거 작업 문서화에 명시 적으로 노력해야하므로 이제 백 로그에 적절한 이야기를 추가하고 제품 소유자를 설득하여 각 스프린트에 과거 문서화에 명시 적으로 시간을 투자해야합니다.