성숙한 팀을위한 좋은“정의 된 정의”는 어떤 모습입니까?

다양한 소스에서 수행 된 정의의 예를 볼 때 일반적으로 다음과 같은 점이 포함됩니다.

• 코드 완성
• 단위 테스트 실행
• 동료 검토 또는 짝을 이룬 코드
• 코드 체크인
• 설명서 업데이트
• …

우리 팀에는 비슷한 목록이 있지만 아무도 그 단계를 건너 뛰지 않을 정도로 명백하게 보이기 때문에 아무도 그것을 보지 않습니다. 따라서 우리는 이것이 팀이 민첩한 프로세스로 전환하는 데 주로 사용되는 도구인지, 단순히 제거하지 않아야하는지 궁금했습니다.

다른 한편으로, 많은 문헌들은 모든 고성능 팀이 완료에 대한 강력한 정의를 가지고 있다고 주장합니다. 이런 종류의 힌트는 여기서 개선 할 수있는 기회를 놓칠 수 있습니다.

그렇다면 성숙한 팀에 대한 강력한 정의의 예는 무엇입니까? 일반적으로 어떤 점이 포함됩니까?

모든 사람을위한 지침이 있습니다. 당신이 언급했듯이 성숙한 팀에서는 모든 사람들이 그것을하고 있기 때문에 그것을위한 장소가 없다는 것을 의미하지는 않습니다. 이전에이 방법론에 노출되지 않은 새로운 회원이 가입했다고 가정 해 봅시다. 그 구조가 제자리에 있으면 그에게 매우 중요합니다. 그는 다른 회원을 귀찮게 할 필요도없고, 산출물을 "잊어 버리지"않을 것입니다.

내 의견으로는 명백한 것을 포함하여 모든 것을 나열하십시오. 아마도 더 짧은 목록을 원하는 사람들에게 도움이되지만, 새로운 회원이 호핑하는 경우를 고려한다면, 분명하지 않은 사람들을위한 "짧은 치트 목록"을 가질 것입니다.

그것은 반복적 인 과정이며, 개선 할 수있는 것을 볼 때마다 완료의 정의에 추가하십시오. 초과 근무 시간에는 회사와 관련된 목록이 작성됩니다. Anann은 이미 가치있는 것을 언급했습니다.

요점이 명백하게 드러났다고해서 사람들이 항상 그것을 수행한다는 의미는 아닙니다. 조종사와 외과 의사의 두 가지 다른 예를 들어 봅시다. 상업용 여객기 또는 수술실의 조종석에는 여러 사람이 있으며 그들 사이에 많은 교육과 경험이 있습니다. 그러나 여전히 문제가 발생합니다. 단계가 잘못되었거나, 무언가가 잊혀지고, 잘못되었습니다. 필자는 파일럿 오류로 인한 많은 항공기 사고 (예 : 70 %)가 점검 목록으로 예방 될 수있는 여러 출처 사이트를 보았습니다 . 의료계에서는 네덜란드 체크리스트를 사용하여 네덜란드의 과실 소송의 최대 29 %를 예방할 수 있다고 연구원들에 따르면. 비록이 사람들이 훈련을 받았으며, 후시에서 아마도 그들이 잘못한 것을 쉽게 식별 할 수 있었지만, 어떤 일이 발생하여 그들을 잃었습니다. 아직 읽지 않았지만 The Checklist Manifesto 는 관련성이 있어야합니다. 그것은 의료 직업에서 작성되었지만, 수행해야 할 일을 상기시키는 체크리스트 또는 플로우 차트를 표시하는 이점은 모든 직업에 적용 가능합니다.

따라서 1 단계는 완료에 대한 정의의 일부인 항목 목록을 작성하여 표시하는 것입니다. 이야기가 완료된 것으로 간주되기 위해 작업이 완료되어야하는 경우 작업이 얼마나 명백한지는 중요하지 않습니다. 목록은 팀이 볼 수있는 위치에 있어야합니다. 참고 이없는 아무것도 공상이나 형식이 될 이야기가 완료 호출 할 수 있습니다 전에 모든 사람의 요구에 자신을 물어 것을 질문 아마도 단지 시리즈 -.

2 단계는 완료에 대한 정의를 위해 해당 체크리스트에 어떤 일이 발생하는지 결정하는 것입니다. 작업을 완료하는 데 필요한 모든 것은 구체적이고 명확하고 수용 가능하며 현실적이어야합니다. 또한 완료를 고려하기 위해 시간의 맥락 내에 있어야합니다. 예를 들어 완료의 정의에 "코드 수정"또는 "디자인 수정"을 포함 할 필요가 없습니다. 작업 제품을 변경할 필요가 없다면 스토리가 필요하지 않습니다.

완료의 정의를위한 기초로 사용할 수있는 좋은 점검표는 다음과 같다고 생각합니다.

• 모든 관련 단위, 통합, 시스템 및 승인 테스트가 업데이트 되었습니까?
• 작업 물이 방출 가능한 형태로 변형 되었습니까? 예를 들어, 코드 빌드, 내보낼 수있는 파일 형식의 문서 등
• 모든 관련 업무용 제품이 상호 검토 되었습니까? 작업 제품의 예로는 소스 코드 (생산 및 테스트), 주석, 디자인 문서, 테스트 절차 및 사용 설명서가 있습니다.
• 모든 관련 테스트 (모든 수준의 테스트)가 실행되고 통과 되었습니까?
• 코드가 통합 저장소에 병합 되었습니까?

물론, 팀과 고객이 부가가치를 느끼는 다른 활동을 포함하여 완료에 대한 올바른 정의를 제시해야합니다. 점검 목록에있는 경우 누군가 (팀, 고객, 사용자)에게 가치를 더하기 위해 수행해야합니다. 수행 한 작업을 명확하게 열거함으로써 프로세스를 개선하기 위해 불필요한 활동을 식별하고 제거 할 수도 있습니다.

이것은 실제로 당신이 운이 좋은 사람처럼 들립니다.

우리 팀에는 비슷한 목록이 있지만 그 점이 너무 명백하게 보이기 때문에 아무도 그것을 보지 않습니다.

귀하의 팀은 이미 "성숙한";-)입니다. 그러나 항상 개선의 여지가 있습니다!

귀하의 질문에 :

그렇다면 성숙한 팀에 대한 강력한 정의의 예는 무엇입니까? 일반적으로 어떤 점이 포함됩니까?

목록 상단에 다음을 추가 할 수 있습니다.

다양한 코드 품질 메트릭 :-불안정성, 추상화-LOC vs DLOC (문서화)-기타 ...

경험상 커밋으로 인해 메트릭이 악화되지 않아야 할 수 있습니다. 누군가가 실제로 메트릭스를 향상시키는 경우 "완료 : withExcellence"를 공식화 할 수 있습니다. 이 기능 (메트릭이 향상됨)은 일반적으로 개발 단계 (새로운 기능)의 일부가 아니라 리팩토링 단계의 일부입니다.

과거의 회사 중 하나에서 "완료"에 대한 정의를 가지고 있는데,이를 통해 측정 항목이 특정 임계 값 이하로 유지되어야한다고합니다. (복잡한 종아리와 같이 아주 좋은 변명을 가지고 있지 않는 한, 순환 복잡도는 15를 넘지 않아야합니다.)

Checkstyle 유형의 위반에 대해서도 마찬가지입니다. 특히 팀 코드 스타일을 점검하기위한 사용자 정의 규칙 세트가있는 경우에 마찬가지입니다. 코딩 표준을 위반하는 경우 아직 완료되지 않은 것입니다.

그런 다음 UnitTest를 실행할 수있을뿐만 아니라 코드 적용 범위를 측정 할 수 있습니다. 50 % 이상이 보장되지 않으면 완료되지 않은 것입니다. 이것은 일종의 불완전한 정의이지만, 코드베이스의 100 %가 아닌 핵심 / 기본 / 중요 메소드에 대한 테스트가 있어야하기 때문입니다.

아 맞다. 자동화 된 지점 통합 기능을 갖춘 CI 서버를 보유하고 있다면 DEV 지점의 커밋이 현재 LIVE 지점과 병합되어 오류가 발생하지 않는 경우에만 수행된다. (단위 테스트 등)

흠 ... 그것은 당신의 목록에 언급되지 않은 과거 회사 / 프로젝트에서 알 수있는 전부입니다.

나는 그것이 당신에게 아이디어를 줬기를 바랍니다.

건배,

아난

TDD / BDD 환경에서 "완료"의 정의 (기술적으로 "실제로"완료 ""에 대한 Matt S의 정의가 정확하기 때문에 "코드 완성")는 매우 간단합니다.

• 모든 자동 테스트 통과 (자동 테스트에는 필요한 기능 또는 동작이 존재하고 작동하는지 확인하기 위해 해당 스토리에 대해 작성된 새로운 테스트가 포함되어야 함)
• 코드 검토 통과 (팀의 한 명 이상의 수석 개발자는 작업이 코드베이스의 일부가되고 스토리를 진행하는 동안 "속임수"또는 "해킹"하지 않은 내용)
• 커밋 성공 (모든 자동화 테스트를 통과 한 빌드 봇, 코드 커버리지 메트릭, 스타일 경찰 확인 등)

이 시점에서 계속 진행할 수 있습니다. 이 세 가지 요점은 중요하지만 일반적인 팀 코더가 고려해야 할 모든 것입니다. 쓰거나 쓰지 않은 TDD 환경에서는 불가피합니다. 코더가 문서화를 수행하는 문서 인 경우 문서가 추가 포인트입니다. 마지막 애자일 팀에서는 BA / QA가 문서를 처리했습니다. 그들은 클라이언트가 원하는 것을 알고 UAT를 실행 했으므로 클라이언트에게 의미있는 방식으로 새로운 기능을 문서화 할 수 있었으므로 설명서는 "완료"에 대한 코더의 정의에 포함되지 않았습니다. 팀의 정의.