스크럼 가이드 | 14. 개발자의 실수

개발 팀은 독립적인 전문가 그룹입니다. 그러나 그들이 구현하는 프로젝트의 성공은 공동의 노력에 달려 있습니다. 그리고 이것은 많은 성숙도와 팀워크 기술을 요구합니다. 개발자의 가장 흔한 실수는 무엇입니까? 제품 목표 추구를 어렵게 하거나 불가능하게 만드는 것은 무엇입니까?

개발자의 일반적인 실수 – 목차:

1. 개발자의 일반적인 실수
2. 당신의 생각에 지나치게 집착하는 것
3. 자기 고용
4. 개발자 철수
5. 독립
6. 권한 범위에 대한 책임 제한
7. 스프린트 백로그 혼란
8. 요약

개발자의 일반적인 실수

스크럼에서 일하는 개발자의 실수 중 많은 부분이 팀워크에 대한 접근 방식에서 비롯됩니다. 한편으로는 독립성을 잘못 이해 하고 팀의 이익에 반하여 자신의 아이디어를 옹호하는 것입니다. 반면에 남에게 의존하고 독립심이 결여되어 있다. 문제의 또 다른 원인 은 팀 책임에 대한 오해일 수 있습니다.

당신의 생각에 지나치게 집착하는 것

개발자의 일상적인 책임에는 복잡한 문제에 대한 혁신적인 솔루션을 찾는 것이 포함됩니다. 솔루션 개발에 들인 노력으로 인해 아이디어에 지나치게 집착하게 될 수 있습니다. 이로 인해 제품 목표를 놓치고 비즈니스 관점에서 유용하지 않은 부가 솔루션을 개발하는 데 너무 많은 시간 을 소비하게 됩니다. 그리고 그들은 또한 팀의 민첩성을 위협하는 대체 솔루션을 찾는 것을 꺼립니다.

자기 고용

개발자가 팀에서 자신의 역할을 이해하는 데 어려움이 있는 경우 스프린트 목표에서 작업을 분리하려고 합니다. 설상가상으로, 그들은 나머지 팀을 참조하지 않고 그 일을 할 것입니다. Sprint Backlog를 임의로 변경하는 경우에도 문제가 될 수 있습니다. 이것이 바로 개발자 중 한 명이 잘못 이해한 독립성이 커뮤니케이션 문제에서 비롯될 수 있는 방법입니다.

과도한 독립 욕구 는 개발자 개인의 성취에 대한 인식 부족에서 비롯될 수 있습니다. 팀이 수행한 작업에 대한 기여도가 투입된 노력과 작업의 난이도에 비해 상대적으로 평가될 때 나타납니다.

혼자서 작업하는 것은 팀 내에서 심각한 갈등의 원인이 될 수 있습니다. 그렇기 때문에 스크럼 마스터가 가능한 한 빨리 근본적인 문제에 대응하고 해결하는 것이 중요합니다. 이는 실수가 개발자에게 있는 것이 아니라 개발자의 참여에 대한 잘못된 평가에 있음이 판명될 수 있기 때문입니다.

개발자 철수

앞의 두 가지 문제, 즉 혼자 일하고 자신의 아이디어에 지나치게 집착하는 문제는 의사 소통 부족의 문제일 수 있습니다. 그런 다음 해당 개발자는 팀에서 자신을 분리하기 시작합니다. 그들은 스프린트 백로그에 따라 임무를 수행하지만 팀의 삶에서 물러납니다.

이러한 상황에서 스크럼 마스터는 철회된 개발자에게 특별한 주의를 기울여야 합니다. 팀에 대한 그들의 공헌에 감사하고 능동적인 태도를 취하도록 격려하십시오.

독립

자기 조직화는 이전 기사에서 설명한 성숙하고 잘 구성된 개발 팀 의 특징입니다. 이는 어려움에도 불구하고 개발자가 다른 사람에게 작업을 그들 사이에 분배하는 방법, 완료 방법 및 시기를 알려주는 데 의존하지 않는다는 것을 의미합니다. 그러나 자기 조직화는 대인 관계에 대한 오해를 불러일으킬 수 있습니다.

이러한 경우 스프린트 목표를 달성하기 위해 수행해야 하는 작업이 분산되도록 하기 위해 항상 스크럼 마스터가 있어야 합니다. 이때 개발자의 종속성 문제가 발생합니다.

다시 말하지만, 스크럼 마스터는 개발 팀 구성원이 스스로 결정하고 자신의 작업에 대한 책임을 지도록 격려하여 구조에 나서야 합니다.

권한 범위에 대한 책임 제한

개발자가 특히 포밍 팀에서 직면해야 하는 또 다른 문제 는 개발자의 핵심 역량에 속하는 작업 이외의 작업을 수행하지 않으려는 것입니다.

이 실수는 개발팀의 효율성을 크게 떨어뜨릴 수 있습니다. 모든 스프린트가 각 팀원의 핵심 역량을 활용하는 것은 아닙니다. 따라서 그들은 스프린트 목표와 동등하게 관련된 기타, 보조 또는 조직 작업을 수행하는 데 열려 있어야 합니다 .

스프린트 백로그 혼란

그러한 작업 중 하나 는 스프린트 백로그를 순서대로 유지하는 것입니다. 개발팀의 원활한 운영을 위한 핵심 과제입니다. 그러나 일반적인 실수는 개발자 간에 유지 책임을 옮기는 것입니다. 이것은 스프린트 목표에 대한 작업뿐만 아니라 팀의 발전과 지속적인 개선을 방해합니다.

개발자의 일반적인 실수 -요약

요약하자면, 개발자들의 가장 흔한 실수 는 팀 전체에서 스스로를 단절시키려는 시도를 포함합니다. 즉, 스스로 작업하고, 자신의 아이디어를 추진하고, 철회하는 것입니다. 또한 개발 팀의 무결성은 독립성 개발 문제, 스프린트 백로그의 혼란, 개발자의 핵심 역량 외의 의무를 수행하려는 의지가 없는 문제로 인해 위협을 받습니다.

콘텐츠가 마음에 들면 Facebook, Twitter, LinkedIn, Instagram, YouTube에서 바쁜 꿀벌 커뮤니티에 가입하십시오 .

저자: 캐롤라인 베커

프로젝트 관리자인 Caroline은 최고의 워크플로를 설계하고 프로세스를 최적화하기 위한 새로운 방법을 찾는 데 전문가입니다. 그녀의 조직적 기술과 시간 압박 속에서 일하는 능력은 그녀를 복잡한 프로젝트를 현실로 만드는 최고의 사람으로 만듭니다.

모든 게시물 보기

스크럼 가이드:

1. 기본 용어, 역할 및 개념의 용어집
2. 스크럼이란?
3. 스크럼 값
4. 회사에서 스크럼을 구현하는 방법은 무엇입니까?
5. 스크럼 팀 - 무엇이며 어떻게 작동합니까?
6. 제품 소유자는 누구입니까?
7. 제품 소유자의 가장 일반적인 실수
8. 스크럼 마스터는 누구인가?
9. 좋은 스크럼 마스터의 특징
10. 스크럼 마스터의 가장 흔한 실수
11. 스크럼 마스터가 추적해야 하는 통계 및 메트릭은 무엇입니까?
12. 제품 소유자와 스크럼 마스터 간의 협력
13. 스크럼 개발팀
14. 개발자의 가장 흔한 실수
15. 스크럼 아티팩트
16. 스케일링 스크럼
17. 스프린트 백로그
18. 제품 백로그란 무엇입니까?
19. 사용자 스토리란 무엇입니까?
20. INVEST로 최고의 사용자 스토리 만들기
21. 가장 흔한 사용자 스토리 실수
22. 사용자 스토리 수락 기준
23. 스크럼의 추정 및 스토리 포인트
24. 계획 포커
25. 팀 평가 게임
26. 증분 정의
27. 스크럼 이벤트
28. 스크럼에서 스프린트란?
29. 스크럼 팀 약속 - 제품 목표, 스프린트 목표 및 완료의 정의
30. 번다운 차트란 무엇입니까?
31. 번다운 차트를 만들고 해석하는 방법은 무엇입니까?
32. 번다운 차트의 장점과 단점
33. 스크럼과 스크럼반의 칸반 보드
34. 스크럼의 속도 - 개발 팀의 속도
35. 일일 스크럼
36. 스프린트 계획
37. 스프린트 리뷰
38. 스프린트 회고란 무엇입니까?
39. 스프린트 회고 중 일반적인 실수
40. 제품 백로그 육성