민첩한 프로세스 : 어떻게 그리고 무엇을 문서화해야합니까?

얼마 전 제가 일하는 회사는 개발 프로젝트를 제 3 자에게 아웃소싱했습니다. 그들은 솔루션 개발에 민첩한 사례를 사용했습니다. 그러나 문서를 요청할 때 위키에 포함되거나 스프린트의 일부로 필요하다고 말했을 것입니다.

그들은 프로젝트 팀 중 하나를 제외하고 프로젝트가 완료 될 때 떠나게되었습니다. 연간 구독이 마감되면 프로젝트 위키 사이트가 폐쇄되었습니다.

그들이 떠났을 때 그들은 그들과 함께 개발 된 것에 대한 지식과 이해를 대부분 가져 갔다.

그래서 두 가지 주요 질문이 있습니다.

1. 이것이 민첩한 것이지, 아니면 쓰고 싶지 않은 변명일까요?
2. 개발 요구 사항, 디자인, 주요 결정 사항 및 상황을 기록하는 민첩한 프로젝트의 문서화에 대한 업계 표준은 무엇입니까?

이것이 민첩한 것이지, 아니면 쓰고 싶지 않은 변명일까요?

내 이론은 민첩 확산이 너무 빨리, 특히 왜 점이다 스크럼 . 회사 전체가 아니라 자신을 보호하기 위해 민첩성을 원하는 팀이 너무 많습니다. 문제는 많은 경우에 방법론이 경영진에 의해 사용된다는 것입니다 (자신을 보호하고 싶어하기 때문에).

이것이 애자일이 전혀 작동하지 않음을 의미합니까? 물론 이것은 민첩성이 몇 가지 일반적인 문제를 해결하는 데 도움이되지만 여전히 다른 모든 문제를 담당한다는 것을 의미합니다. 그리고 대부분의 경우 민첩성은 해당 회사의 해당 팀에 적합하지 않습니다.

개발 요구 사항, 디자인, 주요 결정 사항 및 상황을 기록하는 민첩한 프로젝트의 문서화에 대한 업계 표준은 무엇입니까?

짧게 말하면 :

팀은 필요한 문서의 양을 정의해야합니다

그들은 영역을 알고, 전문가이며, 더 중요하게는 그것을 구축합니다!

이것이 Agile Manifesto의 포괄적 인 문서 에 대한 Working 소프트웨어가 의미 하는 바입니다 .

그들은 당신에게 TDD 시험, 합격 시험 또는 다른 단위 시험 세트를 남겨 두었습니까? 응용 프로그램의 작동 방식과 작동 방식을 문서화하고 개발 된 기능을 사용하는 방법에 대한 샘플 구현을 제공합니다.

어쨌든 민첩한 전문가는 아니지만 대답은 다음과 같습니다.

1. 특정 문서를 요구하는 이야기 / 요구 사항이 있습니까? 그렇지 않은 경우 요청한 내용을 어느 정도 얻었을 때 문제의 일부입니다. 변명이며 여기서 "정상"이 무슨 뜻인지 궁금 할 수 있습니다. 애자일 원칙을 따르는 것이 대부분 정상입니까, 아니면 예상해야하는 전체 프로세스의 일부입니까? 이것이 제가 볼 수있는 두 가지 견해입니다. 편집 : 문서화와 관련하여 대부분의 팀이하는 일이 의심 스럽지만 내 생각에는 추측입니다.

2. 관심이있을 수있는 몇 가지 링크는 내가 할 수있는 최선의 방법입니다.

   • 민첩하고 마른 문서에 대한 모범 사례
   • 민첩하고 기술적 인 문서

애자일 (Agile)은 manifesto 에 몇 가지 특정 사항 이 있습니다.

포괄적 인 문서에 대한 작업 소프트웨어

즉, 오른쪽에있는 항목에는 가치가 있지만 왼쪽에있는 항목은 더 중요하게 생각합니다.

그들은 단지 끔찍합니다. 민첩성이 전혀 문서화를 의미하지 않는다고 생각하지 않습니다. 최소한 응용 프로그램 설명을 추적해야합니다. 위키를 내보내는 것이 좋았거나 다른 사람이 서비스 요금을 징수 할 수 있었을 것입니다.

시도만큼 상세하지 않을 수 있습니다. 이론은 타임 크런치시 사양이 더 이상 코드와 일치하지 않는다는 것입니다. 따라서 코드를 작성하고 세부적으로 정의하지 않는 충분한 문서가 있습니다 (일부 유사 언어 텍스트 / 다이어그램 코드 및 실제 코드로 코드를 작성하는 것과 같은 종류).

당신의 문제는 애자일과 아무 관련이 없습니다. 그들은 당신이 요청한 문서를 작성했을 것입니다. 프로젝트가 제대로 관리되지 않았습니다.

최소한 어딘가에 기능, 사용자 사례 및 테스트 사례에 대한 설명이 있어야합니다 . IT는 프로젝트의 ReadMe 파일에 있고 소스 코드 주석에 있거나 디자인 문서에있을 수 있습니다. 위의 모든 것 또는 MIA 일 수 있습니다!

내 경험에는 항상 문서를 요구하는 사람들이 많이 있지만 (내가 그 중 하나였습니다) 실제로 실제로 문서를 만들 시간이나 열망이있는 사람은 아무도 없습니다. 때때로 노력이 있지만 일반적으로 작성된 문서는 매우 빨리 구식이되고 시스템의 실제 기능과 동기화되지 않습니다. 이로 인해 문서를 가지고 있지 않아도 문서를 확인하는 사람이 실제로 문서의 정확성을 믿지 못하는 원인이됩니다.

실제 정확성과 신뢰성있는 정보를 얻으려면 코드와 테스트를 읽을 수 있어야합니다. 자신의 시스템이하는 일을 (재) 발견하려는 고객은 항상 시스템에 대한 사실을 제시 할 수있는 프로그래머와 인터뷰하고 질문 할 수 있습니다.

좋은 문서를 작성하는 것은 쉽지 않으며 비용이 많이들 수 있습니다. 둘째, 청중에 대해 궁금해 할 수있는 사람은 누구이며, 누구에게 필요한 문서이며 무엇을 제공해야합니까?