당신과 당신의 팀이 매일 무엇을하고 있는지 추적하는 방법은 무엇입니까?

나는 나 자신과 팀원들이 실제로 매일하는 일을 추적하는 방법에 어려움을 겪고있다. 매주 완성 된 카드를 살펴보면 좋은 사진을 얻을 수 있고 스탠드 업이 약간 도움이되지만 팀의 일상 업무를 잘 처리하지 못하는 것 같습니다. 카드는 매일 업데이트를하지 않고 며칠 동안 계속 진행되며 일부 엔지니어는 내 팀이 가장 의사 소통하지 않습니다.

나는 사람들이 작성하는 일종의 일일 기록을 (메일 링리스트 또는 공유 구글 문서를 통해) 구현하는 것에 대해 생각했지만 상당히 번거롭고 수동적 인 것처럼 보입니다.

GitHub 활동을 모니터링하면 문제가 없지만 매일 발송하는 이메일 수에 약간의 부담이 될 수 있습니다. 다이제스트 시스템을 구축하려고 생각했지만 시간이 여유가 없습니다.

"진행중인"작업에 대한 작업을 측정 할 수 있도록 팀이 매일하고있는 일을 계속 유지하기 위해 어떤 전략을 구현 했습니까?

나는 그들에게 이야기한다.

기술은 사회적 문제를 해결할 수 없습니다. 당신은 짧은 아침 서 있습니다. 어제 무엇을 했습니까? 당신은 오늘 무엇을 할 것인가? 어떤 장애가 있습니까?

뭔가 비린내가 들리거나 궁금한 점이 있으면 멈추고 질문합니다. "어제 XYZ에서 작업하고있었습니다. 어떻습니까?" 이로 인해 사람들은주의를 기울이고 실제로 무슨 일이 일어나고 있는지 알 수 있습니다. 또한 팀의 주도권을 유지하고주의를 기울이고 실제로 무슨 일이 일어나고 있는지 알 수 있습니다. 이것은 필요 시간으로, 짧은 (10 분 최대 ). 다른 것들과 사람들은 "선반"하지 않습니다. 멈추고 스탠드 업을 기다린 다음 다시 시작하는 데 시간이 걸립니다. 어쨌든 어떤 사람들은 그렇게 할 것입니다. 그러나 그것은 피할 수없는 일입니다.

그런 다음 오후에 모든 사람의 책상에 들렀습니다. 매일 오후가 아니라 (새로운 사람들에게는 매일 오후보다 많을 수도 있음), 동시에가 아니라 거의 같은 시간에 (비공식적이고 규칙적입니다). "문제가 있습니까? 어떤 장애가 있습니까?"

사람들이 일대일 때 얼마나 자주 문제가 발생하는지 놀랄 것입니다.

사람들에게 문제가 없다면 위대하다. 다시 일하러가 그들이 일주일 내내 문제가 없다면 ? 문제. 당신은 그들에게 충분히 도전하지 않거나 열지 않습니다. XYZ (스탠드 업에서 언급 한)가 어떻게 진행되는지 물어보십시오. 그것들을 설명하게하십시오.

이것은 소액 관리가 아닙니다. 당신은 그들에게 그들의 일을하는 방법을 말하지 않습니다. 당신은 그들을 보모하지 않습니다. 당신은 그들의 일상 생활에서 장애를 제거 할 수 있습니다. 그렇게하려면 정보가 필요합니다. 팀을 회의에서 벗어나고 프로젝트 관리자가 큐브에서 벗어나면 하루에 한 번 도움을 청하는 사람이 슬픔을 일으키지 않습니다. 그러나 이러한 모든 상호 작용은 "나는 당신을 돕기 위해 여기 있습니다"정맥에서 비롯되어야합니다.

내가 할 또 다른 일은 변경 세트를 (비공식적으로) 검토하는 것입니다. 그런 다음 사람들이 얼마나 자주 체크인하는지, 변경 사항이 얼마나 큰지,보고 된 내용과 얼마나 일치하는지, 얼마나 자주 다시 수행하는지, 얼마나 많은 버그 수정이 있는지 등을 확인할 수 있습니다. 상태가 "완료"로 변경되는 작업 항목은 거의 의미가 없습니다. 코드를보십시오. 그렇게 보입니까?

참고 : 한 가지 심각한 측면은 팀이 얼마나 큰가? 7 명 이상입니까? 물론 팀이 너무 크면 진행중인 모든 것을 추적 할 수 없습니다.

개발자를 미세 관리하지 마십시오!

생산적인 소프트웨어 개발에는 집중적 인 노력이 필요합니다. 그들이 일정한 출력을 생성 할 것으로 기대하는 것은 현실적이지 않습니다. 매일 측정을 시작하면 그들은 매일 볼 수 있도록 몇 가지 식별 가능한 인공물을 생산할 수 있도록 작업을 재구성합니다. 소프트웨어 품질에 긍정적 인 영향을 줄 수도 있고 그렇지 않을 수도 있습니다. 개발자의 효율성에 거의 부정적인 영향을 미칩니다.

Robert Harvey가 제안한 것처럼 팀을 미세하게 관리하지 마십시오. 구체적인 비즈니스 가치를 가진 우선 순위가 지정된 작업을 팀에 제공하고 팀이이 비즈니스 가치를 제공하는 가장 좋은 방법을 찾도록하십시오.

팀이 비즈니스 가치를 제공하면 행복해야합니다. 그들이 요청한 기능을 제공하도록하는 방법은 그들에게 달려 있습니다.

하나:

카드는 일일 스탠드 업에서 업데이트하지 않고 며칠 동안 계속 진행됩니다

이는 프로세스에 결함 이 있음을 나타낼 수 있습니다.

실제로 팀으로 기능하지 않는 팀일 수 있으며 서로 갇혀있을 때 서로를 돕기 위해 들어서는 안됩니다. 비즈니스와의 커뮤니케이션이기도합니다. 작업이 너무 커서 필요한 것을 파악하기가 어렵습니다. 사양이 명확하지 않습니다.

또한 실제 문제가 전혀 없을 수도 있습니다. 어쩌면 팀은 완료하는 데 며칠이 걸리는 주요 작업을 나타내는 카드로 잘 작동 할 수 있으며 팀은 이것을 달성하기 위해 잘 노력하고 있습니다.

회고를 귀하의 우려를 표하기위한 플랫폼으로 사용하는 것이 유효하다고 생각합니다. 때로는 외부로부터 관찰을받는 것이 좋습니다.

그러나 팀에 문제가 있는지, 그리고 그 원인이 무엇인지 알아 내십시오. 업무가 팀에 전달되는 방식을 조정해야 할 수도 있다는 점에 동의하십시오.

매일 일어 서서 팀이 작업을 조직하는 데 도움이되는 도구임을 기억하십시오. 관리자가 팀의 활동을 추적하는 도구가 아닙니다.

'풀 메시징'이 아닌 '푸시 메시징'

개발자는 종종 다음 중 하나의 상태에 도달하게됩니다.

1. Yaaay, 나는 X를했다!
2. 나는 X에서 일하고 있지만 시간이 오래 걸릴 것 같습니다 ...
3. 나는 문제 Y에 갇혀 있으며 연구 중이지만 조언이 필요할 수 있습니다.
4. A, B 및 C를 기다리고 있기 때문에 차단되었습니다.

이상적으로는 실제 생산성을 방해하지 않으면 서 이러한 상태에 대한 합리적으로 최신 정보를 얻으려고합니다. 상수 "우리는 아직 있습니까?" 비생산적이지만, 그 수 있습니다 당신은 주 2-4에 유용한 일을 할 수 있습니다, 그래서 당신은 그들에 대한 정보를 얻을 필요가있다.

작동하는 것은 바람직하게는 자동화 된 방식으로 '푸시 메시징'문화입니다. 전체 커밋 로그를 볼 필요는 없지만 모든 팀원의 최신 커밋 또는 최신 해결 티켓 (버그 또는 기능)을 볼 수있는 "대시 보드"를 만들 수 있습니다. 나머지 상황에서는 이러한 업데이트로 적극적으로 전자 메일을 보내거나 (커밋보다 드문 경우가 있습니다) 대시 보드에 관계없이 지속적으로 진행되지 않는지 물어볼 수 있습니다. 멈춰야한다는 내부 합의가 제기되어야합니다 (8 시간이 아닌 80 시간이 소요되는 경우 일부 기능이 필요하지 않을 수 있음). 그러면 최신 상태를 유지하거나 방해 받게됩니다.

또는 https://idonethis.com/ 일일 보고서 와 같은 문화를 팀 전체에 전달할 수도 있습니다. 이렇게하면 다른 사람들도 같은 페이지에있게됩니다.

다른 답변들 (통신에 중점을 두는 것)에 대한 대안은 아마도 노트 카드의 작업이 더 작은 조각으로 나뉘어 더 빨리 피드백을받을 수 있다는 것입니다.

작은 조각으로 팀은 매일 성과를 내고있는 것처럼 느끼며 , 이는 스탠드 업에 반영되어야합니다.

단점 은 이러한 개별 카드가 서로 많이 의존 할 가능성이 있다는 것입니다. 서로 매우 쉽게 의사 소통을 할 수있는 팀이 여기에 도움이되거나 조각들이 합쳐지지 않아야합니다. 특정 작업을 먼저 수행해야하는 경우 일부 카드를 다시 보관해야 할 수도 있습니다.

즉, 사람들은 여전히 ​​갇히 거나 작업이 자신이나 당신이 생각하는 것보다 훨씬 더 어렵다는 것을 알게 될 것입니다. 그렇기 때문에 다른 사람들 이 문제가있는 사람을 판단하지 않고 조언 을 제공 할 수있는 상황에서 공개적으로 문제를 논의하는 것이 여전히 도움이되는 이유 입니다.

다른 답변들 중 일부가 제기 한 것처럼 소액 관리 문제에 대답하기 위해 : 사람들이 매일 작은 작업을 수행 할지라도 각 사람이 실제로 얼마나 많은 일 을하고 있는지 이해하기 위해 수행 한 작업 에 대해 더 폭 넓은 시각 이 필요합니다. 그들의 일상적인 성취로 그들을 판단하기보다는.

의사 소통이 매우 쉽고 사람들이 쉽게 접근 할 수있는 8 명으로 구성된 팀에서 일하기 때문에이 방법을 제안합니다. 우리는 이틀 이상의 일을 할 것으로 예상되지 않는 작업을 받았습니다. 때때로 이러한 작업은 밀접한 관련이 있으므로 각자 자신의 작업 방식에 대해 서로 업데이트해야합니다. 우리는 2 주마다 달성 한 성과를 관리자에게보고 할 책임이 있습니다.

질문을 다시 읽은 후에는 리더가 아닌 팀원으로 질문 할 수 있으므로 작업을 제어하지 못할 수도 있습니다.

1. 리더에게 과제를 더 많이 나누라고 제안 할 수 있습니다.
2. 작업이 차단되거나 다른 팀 구성원의 작업에 의존하는 경우 자유롭게 확인하고 필요한 경우 다른 작업을 수행하십시오.

우선 시간과 기술 측면에서 자신을 분석해야합니다. 이전에 실무 경험 이있는 기술 담당자 인 경우 마감일을 맞추기 만하면되는 관리자 (개발자가 실제로 수행중인 작업에 대한 강력한 기술적 지식이없는) 인 경우와 다를 수 있습니다. .

공통점 두 경우에 당신이 당신의 팀을 촉진하고 당신이 그들을 신뢰하는 느낌을 만들 수 있어야한다는 것입니다. 당신은 그들의 성과를 판단하지 않고 공감하고 그들의 경험을 재미 있고 쉽게 만드는 데 도움을 주려고 노력하고 있습니다.

이제 내가 위에서 말한 것처럼 관리자라고 가정하십시오.이 경우 일부 개발자가 심각한 개발 관련 문제에 직면하더라도 도움이되지 않을 수 있습니다. 실제 문제는 시간이 오래 걸리고 집중력도 요구할 수 있습니다. 또한 개발자가 자신의 업무에 진심으로 그 문제를 해결하기 위해 풀 타임 (추가 시간까지)을 지불하지만 불행히도 여전히 해결할 수 없다고 가정합니다. 그리고 그러한 상황에서 (문제를 완전히 이해할 수 없을 때) 매일 매일 그리고 비공식적으로 하루에 두 번 진행하여 문제에 대해 계속해서 묻습니다. 결과적으로 개발자에게는 극도로 좌절과 혼란이 생길 ​​수 있습니다. 매일 진행 상황을 수집하기위한 앱이든, 매일 진행되는 회의 만해도 실망 스러울 수 있습니다.

반면에 다른 모든 요소를 ​​동일하게 유지하면서 기술적 인 배경이 강하고 과거에 동일한 기술을 사용했다고 가정 해보십시오. 이 경우 매일 진행하거나 회의를 갖는 것이 정말 도움이됩니다. 개발자는 반드시 귀하와 귀하의 전문 지식을 신뢰하고 그들이 직면 한 큰 도전에 대해 편안하게 논의 할 것입니다. 도움이 될 수있는 제안이나 직접적으로 도움이되지 않더라도 대안적인 접근 방법을 제공하는 데 도움이 될 것입니다.

그러나, 어떤 경우에도 매일 스탠드 업 미팅은 헤드 / 리드 / 매니저가 아닌 팀원이라는 느낌을 만들어야합니다. 그들이 귀하의 팀 구성원이 동일한 수준을 고려하지 않는 한, 그들은 등 자신의 문제 / 제안 / 문제 / 피드백을 통신 할 수 없습니다
고려해야 할 또 다른 점자동화 된 진행률 추적 소프트웨어를 사용하거나 상호 작용을 늘리기 전에 팀의 규모와 관리 시간을 말합니다. 팀이 제기 한 우려 사항이 있으면 최대한 빨리 해결할 수 있어야합니다. 팀원의 주요 동기 요인은 우려 / 제안 / 피드백이 심각하게 고려되지 않거나 가치가 없다는 것입니다. 매일 진행 상황을 아는 것이 중요하지만 팀 작업에 완전히 참여한 경우에만 중요합니다. 일부 부업에 종사하는 경우 팀과 더 많은 교류를 시도하지 마십시오. 팀의 응답이 압도적이며 시간이 지나기 전에 과제를 제출하고 우려와 질문을 제기하지만 적시에 피드백과 검토를 제공 할 수없는 상황을 생각해보십시오. 그런 상황에서

다양한 구성을 위해 다양한 IM 대화방을 만들고 활용하십시오. 일부는 @engineers와 같이 광범위하고 일부는 @newFeatureA와 같이 구체적 일 수 있습니다.

기내 티켓 검토를 포함하여 매일 스탠드 업을 고려하십시오.

협업을 지원하는 개방형 환경을 사용하고 QE와 기본 제품 소유자가 개발자의 중간에 앉아 있는지 확인하십시오. 당신은 많은 이야기를 듣고 주변의 화면을 보면서 아이디어를 얻습니다.

Robert가 지적한 바와 같이, 무엇보다도 소량 관리하는 것으로 보지 않습니다 (예 : 실제 의도와 상관없이 '보임'사용에 유의하십시오).

궁극적으로 우리는 시간이 지남에 따라 성취되는 것을 추적하고 그 속도가 무엇인지 확인합니다. 사람들이 탈퇴하고 퇴사하게되면 하루의 진행 상황에 집중하는 것은 비생산적입니다.

여기서 아무도 GitHub 또는 BitBucket과 같은 시스템에 내장 된 "followed"또는 "starred"리포지토리 메시징을 언급하지 않은 것에 놀랐습니다.

우리의 기술 이해 관계자 (프로젝트 리더, 개발 및 지원 관리자)는 모두 우리의 문제를 따르고 관련 프로젝트에 대한 업데이트 기록을 작성합니다. 소규모 팀 (15 명의 FTE + 계약자)이 있지만 이것은 우리에게 효과가있는 것 같습니다

이 중 어느 것에 대해서도 측정 된 사람은 없지만 PM의 주간 상태 보고서 외에도 최소한 모든 영역이 어떤 작업이 진행되고 있는지 알 수 있도록 프로젝트에 대한 일일 견해를 제공하므로 가시성이없는 사람은 없습니다.

또한 개발자와 계약자 및 비즈니스 연락 담당자의 투명성을 높이는 데 도움이되어 모든 사람이 산출물 일정에 책임을지게합니다.

특정 리포지토리 또는 전체 조직과 관련된 RSS 피드와 결합되면 이메일을 제한하고 (필요한 경우) RSS 리더를 통해 유사한 데이터를 실시간으로 요약하여 제공 할 수있었습니다. 일부 사용자에게는 이것이 Outlook이므로 기본적으로 전자 메일이지만 약간 다르지만 다른 사용자에게는 완전한 필터링 기능을 갖춘 본격적인 RSS 클라이언트를 사용하여 정확한 요구에 맞게 사용자 정의해야합니다.

처음에는 전자 메일 볼륨에 대해 비슷한 우려가 있었지만 최종 사용자는 엔지니어링 조직이 Outlook을 사용하지 않는 고객을 제안하는 것 외에 많은 작업을 수행하지 않아도 RSS 시스템을 고안했습니다. 여러 사무실과 시간대에서 1 년 내내 약 20-30 명의 FTE + 계약 업체를 위해 다시 일했습니다. 분명히 YMMV.

이것은 매우 미미한 추가 사항이며 프로그래머별로 다르지 않지만 최근 프로젝트에서 Asana 를 성공적으로 사용 했습니다.

기존 온라인 협업 도구와의 통합을 위해 Slack을 찾아보십시오 . 대화방을 중심으로 구축되었지만 Asana, GitHub 및 Bitbucket을 비롯한 다른 도구를 위한 매우 미니멀 한 허브 역할을합니다 . API는 사전 제작 및 커뮤니티 제작의 "통합"컬렉션을 제공합니다. 물론 API를 사용하여 직접 만들 수도 있습니다.