기립 회의를 문서화해야합니까?

우리 회사의 다른 팀이 대기 회의를 문서화하기 시작했지만 시간 낭비라고 생각합니다. 내가 아는 한, 스탠드 업 미팅은 상태보고 용이 아닌 커뮤니케이션 용입니다 (잘못되면 정정하십시오).

그렇다면 회의를 문서화해야합니까?

애자일의 장점 중 하나는 각 팀이 자신에게 가장 적합한 것을 결정할 수 있다는 것입니다.

그러나 메모를 해야 합니까? 아니; 내 경험상, 팀이 다음과 같은 일부 핵심 원칙에 대해 역 추적을 시작하기로 결정한 순간 :

• 프로세스 및 도구 (스크럼이 아닌 것으로 시작된 문서화 된 스크럼)에 대한 개인 및 상호 작용
• 포괄적 인 문서를 통해 작동하는 소프트웨어 (하루 동안 스크럼 분, 다음에 무엇을 알 수 있는지)

그 팀은 애자일에서 벗어나 문서화가 많고 속도가 느린 작업 방식으로 나아 가기 시작합니다.

Martin Fowler의 "그것은 단지 일 어선 것이 아니다 "에서, 기립 회의의 "분"을 기록하거나 기록하는 것에 대한 언급이 필요하다. 기립 회의에서 빼내야 할 것은 GIFTS입니다.

• 하루를 잘 시작하도록
• 개선을 지원하기 위해
• 올바른 일에 집중하기 위해
• 팀 감각을 강화하기 위해
• 무슨 일이 일어나고 있는지 알리기 위해

니모닉 장치 인 GIFTS : Good Start, Improvement, Focus, Team, Status

그러나 누군가가 자신의 작업을 도와야하는 차단제가 있고 그들이 말하는 내용을 메모하면 완전히 다릅니다. -그것으로 자신을 때려 눕히십시오.

참고로, 저는 제품 소유자이며 현재 회사와 ScrumMaster, 우리가 보유한 모든 민첩한 회의 (스크럼, 스프린트 계획, 스프린트 검토, 스프린트 회고)에서 멘토링을하고 있습니다. 분은 회고 적이다. 왜냐하면 팀이 다음 스프린트를 향해 노력하고 참조 할 구체적인 내용을 제공하기 때문이다.

스크럼은 다음과 같아야합니다.

• 내가 한 일
• 내가 다음에하고있는 일
• 모든 차단제

그게 다야. 빠르고 요점. 최대 5-10 분 물론 문서화 할 필요는 없지만, 누군가가 무언가를 행동으로 적발해야한다면 문제가되지 않습니다.

내가 일한 마지막 회사에서, 우리는 정상 회의 중에 내려진 중대한 결정만을 문서화하는 데 사용했습니다.

당신이 말했듯이, 스탠드 업 회의는 소그룹의 사람들과의 의사 소통을위한 것이며, 특정 그룹의 사람들 ... 어쨌든 ... 때로는 ... 누군가가 중요하고 궁극적으로 할 수있는 흥미로운 것을 말합니다 프로젝트가 진행되는 방식에 영향을 미칩니다 (종종 다루기 어려운 까다로운 버그 나 알아야 할 기술적 인 점에 대한 경고였습니다). 그렇기 때문에 우리는 오직 '더 나은 미래를위한 중요'요점 만 문서화하기 시작했습니다.

컨텐츠의 중요성에 대해 확신이 있고 가까운 미래 나 먼 미래에 팀에 도움이된다고 말할 수있는 경우에만 문서 기립 회의가 현명하다고 생각합니다.

진술이 공식적이고 최종적인 것임을 기대하지 않고 스탠드 업을 평상시 회의처럼 취급하십시오. 사람들이 아직 익숙하지 않은 주제를 제기 할 가능성이 줄어들 것입니다. 팀에게 간단한 이메일 일지라도 다른 곳에서 계속하십시오. 스탠드 업이 전체 프로젝트 회의로 전환되지 않도록하는 것 외에도 특정 스탠드 업에 참여할 수없는 사람은 제외하지 않아도됩니다.

내 경험상, 스탠드 업은 팀이 프로젝트에서 어디에 있는지 "심장 박동"을 얻는 좋은 방법입니다. 내가 참석하는 사람들은 각각 몇 분씩 걸리며 문서 작성에 충분한 시간이 걸리지는 않지만 프로세스가 진행되는 위치를 파악하고 나에게 영향을 줄 수있는 모든 것에 대해 머리를 숙여주는 데 좋습니다. 즉각적인 용어.

특히 주목할만한 중요한 회의가 스탠드 업 회의에서 나온 경우에는이를 문서화하여 별도로 방송해야하지만 매일 모든 회의를 문서화하는 습관은 들지 않습니다.

그것에 대한 절대적인 대답은 없습니다 (거의있을 수는 없습니다)-그것의 많은 것이 달려 있습니다 ...

실용적으로, "내가 무엇을했는지, 무엇을하려고합니까, 여기에 내 문제가 있습니다"를하고 있다면, 일부 (정상적으로 책임이있는)에 대해 기록 할 수있는 장점이있을 수 있습니다. 다음 회의에서는 (다른 방법으로도 "작업 중"이 분명 해져야하지만) 그 이상의 것을 넘어서는 안됩니다. 즉, 다음 회의가 끝나면 가치를 잃어야하는 정보가 아닙니다 .

또한 스탠드 업에서 발생하는 문제 / 회의가있는 경우 후속 조치가 실제로 발생했는지 여부를 추적하는 것을 기록하는 데 잠재적으로 가치가 있습니다. ).

공식적인 분? 나는 그 것들의 정신에 반하는 사람들을 생각했습니다.

현재 회사에는 별도의 스탠드 업이있는 2 개의 Scrum 팀이 있으며 각 스탠드 업이 끝날 때마다 요약 이메일을 보내 문서화합니다. 그것은 잘 작동하여 중요한 정보를 다른 팀의 모든 구성원에게 즉시 알려줍니다. 우리는 특히 보관 목적으로 메일 기록을 유지하지 않습니다.

그래서 내 조언은 다음과 같습니다.

• 단일 팀의 경우 문서화 스탠드 업은 시간이 충분하지 않을 수 있습니다. 스크럼 마스터는 나중에 자신에게 맞는 경보 또는 중요한 정보를 구두로 전달할 수 있습니다.

• 작업이 밀접한 관련이있는 여러 팀의 경우 문서화 준비는 회의 후 Scrum of Scrums가 발생할 때까지 기다리지 않고 잠재적으로 게임 변경 정보를 방송하는 방법입니다.

나는 그러한 회의에서 멀어지고 중요한 결정이나 발생한 조치를 상기시켜주는 그룹으로서 이메일을 보내는 데 아무런 문제가 없다고 본다. 결국, 당신은 시간이 잊혀지거나 논의 된 내용에 대한 기억이 사라지는 것을 위험에 빠뜨리고 싶지 않습니다.

그러나 공식 회의를 공식적으로 문서화하는 것과 같이 전통적인 회의를 할 때와 마찬가지로 반 직관적 인 것처럼 보입니다. 이러한 회의는 간결하고 민첩해야하므로 너무 많은 '프로세스'로 회의를 진행하는 것은 비생산적인 것처럼 보입니다.

가치를 더합니까? 사람들이 나중에 모임의 문서를 보나요? 그렇지 않다면 시간 낭비 일뿐입니다. 그리고 나는 그들이 그렇게 의심합니다. 아무도 읽지 않는 문서를 작성하는 것은 시간 낭비입니다.

어떤 시점에서 우리는 매일 스크럼에서 상태 변경 사항을 실제로 문서화하고 보관했습니다. 즉 누가 어떤 작업을 수행했는지, 동료 검토를 수행했는지 등이 있습니다. 이는 누군가가 의료 기기 용 소프트웨어를 개발하고 있었기 때문에 시스템 요구 사항에서 코드에 이르는 추적 성 요구 사항

나중에 우리는 경영진에게 이것이 사실이 아니라고 확신하게했으며,이 문서를 담당하는 사람들에게는 그 관행이 크게 기뻐했습니다.

예 .

(a) 작업 항목을 담당하는 사람 및 / 또는 (b) 다른 항목과 비교하여 작업 항목의 중요성에 대해 결정하고 있습니까?

그렇다면,이 결정을 적어 두십시오. 그렇지 않으면, 당신은 그것들을 다시 해쉬 할 것이고, 그들과 같은 결정은 끝없이 있습니다.

그렇지 않은 경우 회의를 개최하지 마십시오.