"일반적인"SCRUM 팀이 있으며 스프린트를 위해 일하고 백 로그를 유지하기 위해 노력합니다. 최근에 우리는 밴드 밖에서 일을하는 성과가 뛰어난 개발자의 작업을 통합 / 처리하려고하는 문제에 봉착했습니다 (정상 근무 시간 / 스프린트 이외의 작업 선택).

예를 들어 팀이 50 점의 작업을 수행하는 경우 스프린트가 끝날 때까지 SCRUM 프레임 워크 내에서 모든 작업을 완료하고 회사와 회사가 행복하다고 가정 해 봅시다. 팀 구성원 중 하나가 백 로그 항목에서 자유 시간에 스스로 작업하기로 결정합니다. 그들은이 작업을 체크인하지 않고 대신 저장합니다 (TFS를 사용하며 선반 세트에 있음).

이것을 처리하는 방법? 몇 가지 문제

• 다음 스프린트 동안이 팀원들은 프로그래밍 작업이 99 % 완료되었으며 코드 검토 및 테스트 만 필요하다고 말합니다. 스크럼 및 민첩한 방법론에서이 문제를 어떻게 처리합니까?
• 다른 개발자들은 이러한 이야기와 관련된 디자인 결정에 관여하지 않았다고 불평합니다.
• 당사의 제품 소유자는이 "무료"작업을 수행하려는 유혹을받으며, 성과가 우수한 회원은 스프린트에서 달리 달성 할 수없는 제품에 더 많은 기능을 제공하기 위해이 작업을 의도적으로 수행하고있을 것입니다. 이것이 "프로세스"를 깨뜨리고 있다는 견해가 있습니다. 분명히 QA, UI 및 문서 작업이이 작업에서 수행되어야합니다.

SCRUM 팀이 초과 근무를하지 않는 것에 대해 많은 논의가 있지만 스프린트 계획 및 실행 중에 제시된 기대 이상으로 일하는 팀 구성원은 어떻습니까? 나는이 사람을 통치하고 추가 작업을 할 수 없다고 말하지만 (물론 화상을 입을 때의주의) 동시에 팀의 특정 구성원에게 문제를 일으키는 것 같습니다 (모두는 아님).

성과가 우수한 회원이 수행 한 작업을 소프트웨어 개발을위한 SCRUM 및 민첩한 프로세스에 통합하는 방법은 무엇입니까?

좋아, 누군가 순서대로가 아니라 수행해야 할 훌륭한 코드를 열정적으로 작성하고 있습니다. 모든 적극 강조 :

그들을 보자

스크럼 스프린트에 약간의 합병증이 발생합니다. 그것은 위대한 사물의 제도에서 정말로 중요합니까? 그가 자신이해야 할 일을 완수한다면, 계속해서 당신을 위해 훌륭한 것들을 만드십시오.

나는 프로그래머들이 스크럼과 같은 인공 시스템의 제약을 벗어나지 못하게했기 때문에 회사를 떠난 몇 명의 놀라운 프로그래머를 알고 있습니다 (저는 영광스러운 QA 이상으로 취급받지 않고 마지막 직업을 떠났습니다). 다른 개발자로부터 입력에 대한 불만이있는 경우 (완전히 유효한 불만, 추가 할 수 있음) 최소한의 간섭으로 자신과 다른 사람이 최선을 다할 수 있도록 "20 % 시간"프로그램을 도입하는 것이 가장 좋습니다.

미래의 이야기 (다른 사람들의 의견이 필요할 수도 있음) 대신 개발자가 새로운 기술이나 기능을 시험해 보도록하십시오. 당신은 다른 방법으로는 탐험하지 않았을 새로운 기회를 발견 할 수 있습니다. 나는이 개발자가 당신이 그냥 내버려두면 시도하고 싶은 것이 몇 가지있을 것이라고 확신한다.

여기서 고려해야 할 두 가지가 있습니다.

1. 누군가의 창조적 인 흐름을 방해하지 마십시오.
   • 개발자가 시간 외 근무를하고 싶다면 맡겨주십시오.
2. 다른 사람을 위해 일을 만들지 마십시오.
   • 개발자가 시간 외 근무를하고 싶다면 다른 사람을 위해 더 많은 작업을 작성하지 않는 것이 좋습니다 .

포인트 2는 다른 개발자들이 걱정하는 것입니다.

당신이 언급했듯이, 그들은 전체 팀의 입력없이 코드가 작성된다는 사실을 좋아하지 않습니다. 디자인면에서 열등한 결과 일 수 있습니다. 그리고 열등한 디자인의 코드는 다른 코드를 감염시키는 방법을 가지고 있습니다.

그래서 어떻게 할 수 있습니까?

야심 찬 개발자 코드를 그의 마음에 담아 두십시오. 그러나 그의 과외 코드가 사용될 것이라고 가정 할 이유가 없음을 분명히하십시오 .

결국 그는 팀의 일원이므로 모든 코드 개발 방법에 팀이 참여해야합니다.

그러나 그의 작품이 건전하고 팀의 합의 된 디자인에 적합하다면, 그는 이미 작성한 것 (보너스!)을 많이 사용할 수있을 것입니다. 그렇지 않다면, 다음에 그가 먼저 출발하기로 결정할 때 그의 디자인에 대해 더 많이 생각하도록 강요 할 것입니다.

이런 식으로, 아무도 NO 라는 말을 듣지 않으며 아무도 그들을 위해 만든 추가 작업이 없습니다.

팀으로 다시 데려와

스스로에게 자문을 구해야합니다 (또는 과잉 지원자를 포함하여 더 나은 팀).

이 동작이 왜 문제가됩니까?

개발자에게 과도한 사람이라고 레이블을 지정했기 때문에 그의 작품이 좋은 품질이라고 생각하므로 이것이 문제가되지 않는다고 가정합니다.

그러나 다른 문제가있는 것 같습니다.

• 추가 작업이 제대로 테스트되지 않았습니다
• 문서화되지 않았습니다
• 나머지 팀은 그것을 모른다
• 개발자는 PO가 아닌 다음으로 구현할 것을 결정합니다.
• 개발자는 다양한 이해 관계자로부터 자신의 작업에 반영 할 피드백을받지 않습니다.

다음과 같은 이유 :

개발자는 왜 그렇게합니까?

• 스프린트 종료시 작업이 충분하지 않으면 다음에 해결해야 할 사항에 대한 팀 결정 (PO 포함)이 있어야합니다. 개발자가이 결정을 피하는 이유는 무엇입니까?

이러한 질문에 대한 답변이 있으면 자신의 질문에 대한 답변을 시작할 수 있습니다.

• 문제가되지 않으면 그의 일을하도록하세요. 어떤 사람들은 SCRUM을 종교로 취급하지만, 이렇게해서는 안됩니다.
• 팀에 두 가지 문제가있을 수 있습니다. 불량 개발자가 야기한 문제와 불량 개발자의 행동을 유발하는 문제입니다. 나중에 해결할 방법을 찾으면 첫 번째 방법은 사라질 것입니다.

무료 작업을 믹스에 추가하는 것이 좋은 일이라는 생각이 마음에 들지만, 단일 개발자가 테스터, QA, 빌드 담당자, 디자이너 및 기타 모든 것이 아니라면 자유롭지 않습니다. 그의 작품을 아무런 영향없이 다음 스프린트에 넣을 수 있다면 .. 가십시오. 그러나 나는 결코 그렇지 않다고 생각합니다. 다른 모든 사람들은 최소한 그가 한 일과 그 일에 미치는 영향을 이해해야합니다. 그들은 자신의 변화가 진행 중이며 그의 노력을 복제하지 않아야한다는 것을 이해해야합니다. 지난 주에 그 불량한 사람을 찾기 위해 열심히 일한 사람에게 알리기가 어렵습니다.

당신은 민첩한 환경에서 일하고 있으며, 민첩에 대해 내가 아는 한 가지는 그것이 당신을 대항하지 않고 당신을 위해 작동하도록 설계되었다는 것입니다. 따라서 이러한 종류의 과외 활동이 발생하도록 작업 방식을 변경해야합니다. 그것은 모든 사람의 의견과 동의를 얻는 것을 의미합니다. 당신은 그들의 바이 인 없이는 이것을 할 수 없습니다. 중요합니다. 팀이 마음에 들지 않으면 불량 녀석은 그만 하죠. 의 끝. 그의 일이 아무리 훌륭하더라도 팀의 노력은 그가 좋아하는 일을하는 사람이 아닙니다. 팀이 먼저옵니다.

따라서 다음 계획 회의에서 모든 사람이 앉아 토론해야합니다. 모든 팀 구성원은이를 허용하거나 이러한 종류의 활동을 더 잘 관리하기 위해 프로세스를 변경해야합니다.

어쩌면 모든 사람들이 자신이 선호하는 프로젝트를 수행하고 테이블로 가져 오는 솔루션을 얻거나 (처음에 문제를 강조하는 배달에 대한 혼란을 상상할 수 있습니다) 또는 당신은 명령 할 수 있습니다 각 개발자가 원하는 솔루션을 개발할 자율성이있는 영역은 얼마나 많은 오픈 소스 프로젝트가 작동하는지와 유사하게 '기여 된'영역이거나 모든 사람이 실험 할 수있는 자유 시간을 줄 수 있습니다 (이전 20 % 시간).

이 개발자는 테스트를 작성하고 깨끗하고 견고한 코드를 작성합니까, 아니면 자신이 신속하게 수행 할 수있는 모든 것을 밀어 내고 있습니까? 나는 개인적으로 정해진 시간 이외의 시간에 일하는 것을 허용하지 않을 것입니다. 예상을 엉망으로 만들고 다른 문제가 발생했음을 지적합니다.

그러나 프로세스를 엄격하게 수행해서는 안됩니다. 스크럼은 프레임 워크 일 뿐이므로 항상 여분의 시간을 포함하도록 프로세스를 조정할 수 있습니다 (그러나 다른 사람이 무엇을할지 계획하기는 어렵습니다).

또한 프로젝트 이외의 작업을하도록 요청할 수도 있습니다. 새로운 기술을 보거나 다르게 행동하는 것에 대한 교육을 만듭니다. 결론은 계획된 일정 이외의 일로 인해 예상치 못한 결과를 초래할 수 있다는 것입니다.

우리는 같은 문제에 직면했습니다. 기본적으로 우리는 20 점을 투입했지만 지난 주 또는 스프린트 중간에는 코딩 작업이 부족했지만 테스트 및 나머지 프로세스 때문에 다른 PBI를 선택할 위험이 없었습니다. 프로그래머들은 백 로그를 조사하고 미래의 PBI를 개발하기 시작했고 (Passerly!) PBI가 코드 검토 및 테스트 준비가되었음을 계획하는 데 나머지 팀에게 알리는 것이 었습니다! 당신이 말한 것처럼.

실제로 PO에 대한 관심이 높아지면서 더 많은 역량을 발휘할 수 있지만 팀의 잠재력을 완전히 활용하지는 못합니다. 스프린트에 실패 할 위험이있었습니다. 우리는 우리가 스크럼 및 주요 문제에 대한 우리의 관점을 바꿀 필요가 있다는 것을 발견이 문제에 대한 사고 후에 그 사람들이 우리가 있기 때문에 그 위험이 먹고 싶어하지 않는 것입니다 커밋 PBIS을 잘 느끼지 않았다 팀 따기의 위험을 감수 할 수 있도록 무료 프로그래머가있는 경우 새로운 PBI

우리는 약속보다 PBI 를 예측 하기 시작했습니다 . 예측은 기본적으로 스프린트 시작 및 계획시 25 포인트를 선택한다는 의미이며, 더 이상 코딩 작업이 없기 때문에 프로그래머가 스프린트 중간에 자유 로워지면 미래 PBI 중 하나를 선택하여 현재 스프린트에 넣고 작업을 시작합니다. PBI가 동일한 스프린트 내에서 모든 프로세스 (테스트, 병합 등)를 통과 할 수 있다면 PBI로 인해 스프린트에 실패하지 않고 남은 작업을 진행하는 것이 아니라면 팀에게는 보너스 포인트입니다 ( 다음 스프린트에 테스트 또는 meging 등)하고 나머지 작업에 대한 포커. 따라서 최악의 시나리오에서는 두 가지 스프린트로 수행 할 수 있습니다. 나는 그것이 Scrumbut처럼 들릴지 알고 있지만 실제로 우리의 작업 방식을 개선했습니다. 다음과 같이 장점을 요약 할 수 있습니다.

• 더 많은 PBI를 복용 할 위험이 있기 때문에 스프린트 실패의 공포증을 물리칩니다.
• 프로그래머와 팀의 추가 작업을 볼 수 있습니다.
• 팀 속도가 증가합니다

그러나 경험이 적은 팀의 경우 PBI를 완료하기 위해 팀에 대한 노력이 줄어드는 것일 수 있습니다.

다른 답변들 중 일부는 "과도한"개발자가 "도적"이거나 "스크럼의 원칙을 위반"한다고 제안했습니다. 이것은 정확하지 않으며이 개발자에게 권장해야합니다 (이 여분의 시간에 특정 작업을하도록 사람들에게 요청해서는 안되지만 제안을하고 아이디어를 육성하는 데 도움을 줄 수는 있음).

스크럼에는 사람들의 작업 방식과 그가 수행 한 추가 작업을 자연스럽게 팀의 속도에 통합시킬 수있는 방법이 없습니다.

그의 작업은 제품 백 로그로 가져와 다음 계획 회의에서 추정해야합니다. 남은 노력이 무엇인지 곧바로 예측할 수없는 경우 스프린트의 시간 상자 (스파이크)를 파악해야합니다.

개발자가 "과 달라"고 설명하는 데 흥미가 있다면, 이는 다른 팀원보다 더 많은 가치를 부여한다는 의미입니다.

추가 작업을 수행하는 데 어려움이 있다는 것은 팀에 최적이 아닌 (혹은 기능 장애 일 수도 있음) 것을 의미합니다.

이 경우, 약간의 추가 노력만으로 왜 더 많은 성과를 거두는 지 스스로 자문 해보아야합니다.

나머지 팀원이 더 많은 것을 달성 할 수 있습니까?

팀이 미세하게 관리되고 잠재적 인 규범 적 사용자 스토리, 완료에 대한 정의가 개발자에게 어려움을 겪는 상황을 보았습니다. 그 작업 수행이 개발자가 자신이 에 원하는가? 나는 그가 좋은 결정을 내린다고 가정합니다. 일주일에 이런 식으로 일하는 것이 나머지 팀에도 도움이 되겠습니까?

그들에게도 교사가되게하십시오

그룹 내에서 가장 우수하고 고급 기술을 갖춘 스타 개발자가있는 것이 좋습니다. 나는 이것을 칭찬하고 칭찬 할 것입니다. 그러한 사람들은 종종 조직을 하나로 묶는 '접착제'입니다.

나는 그 도전을 '경험이 적은 개발자가 가장 진보 된 개발자의 생산성에 더 가깝게 만드는 방법'으로 본다.

이를 수행하는 좋은 방법 중 하나는 스타 개발자가 경험이 적고 느린 팀원을 가르치고 훈련하고 안내하는 데 더 많은 시간을 소비하도록하는 것입니다. 먼저 스타 개발자와 일대일로 토론하여 그들이하는 일과 이유를 알 수 있습니다. 다른 현명한 그것은 숨겨진 의제 / 가난한 관리로 의심으로 볼 수 있습니다

일 어설 때, 하루에 한두 번,이 사람이 일을하지 않고 다른 사람들이 여전히 일을하고 있다면, 페어 프로그래밍을 통해 그녀가 주니어 멤버들과 짝을 이루어 그녀의 위대한 지식과 경험을 전할 수 있도록하십시오. "누군가 도움이 필요합니까? 누군가 쌍을 찾고 있습니까?"라는 질문을하도록하십시오.

또한 모든 사람이 사용하는 도구 세트 향상, 기술 서적 클럽 토론 그룹 운영 또는 다른 조직 프로젝트에 참여하는 등 일이 없을 때 최고의 개발자를위한 '측면'작업을 찾을 수 있습니다.

다른 질문에 대답하겠습니다. 스크럼에서 이러한 상황을 처리하는 방법은 실제로 중요하지 않다고 생각합니다. 스크럼은 어쨌든 지침과 같습니다. 이런 일이 일어나길 원한다면 단순히 작업이 이미 완료되었다고 가정하는 것처럼 프로세스를 조정할 수있는 간단한 방법을 찾으십시오.

실제 질문은이 개발자가 자신이하고있는 일을하기를 원하는지 여부입니다. 나는 그 질문에 대한 답에서 몇 가지 측면이 핵심적인 역할을한다고 생각합니다.

1. 프로그래머가 잘하고 있습니까?
2. 모든 사람이 자기 자신의 일을하는 것이 좋을까요 (좋은지 나쁜지). 그는 결국 디자인 프로세스를 피하고 있습니다!
3. 추가 시간이 지급됩니까?

이러한 모든 사항은 귀하의 제품이 그가하고있는 일을하는 것이 합리적인지에 영향을 미칩니다. 다시 한 번, 결정을 디자인 프로세스에 포함시키는 것은 실제로 문제가되지 않습니다. 융통성이 있어야합니다.

팀이 스프린트의 작업을 결정하지 않기 때문에 이것은 Scrum의 임차인을 위반합니다. 이 팀 은 스크럼 팀 입니다. 훈련을 실시하려면 팀에서이 프로그래머를 훈련시켜야합니다.

이것이 만들어내는 또 다른 문제는 팀의 속도로 조이는 것입니다. 대역 외 작업은 속도와 계산에 포함되지 않습니다. 따라서이 대역 외 작업이 완료되고 팀의 평균 속도는 50 포인트가되지만 50 포인트 이상이 완료됩니다. 제품 소유자는이를보고 다음 스프린트에서 더 높은 속도를 요구할 것입니다. 불가능한 속도.

팀 (PO 또는 ScrumMaster 아님)은 불량 프로그래머에게이 문제를 해결해야합니다.