개발자의 개발량의 편차가 매우 큰 경우
메일링 리스트에 긁적긁적 댓글을 달고나니
그 밖의 것들에 대한 생각들 메모할 필요가 있어 간단히 끄적..
짝프로그래밍 반작용 케이스에 대해서도 생각해 봐야 하지 않을까..
프로젝트팀에서 개인 또는 팀에 바라는 것이
'해낸 분량이 다른 팀원과 비교할때 평균수준 이상인가?'인지 확인해 볼 필요가 있다.
무의식적으로 경쟁을 유도하는 경우..
메일링 리스트에 긁적긁적 댓글을 달고나니
그 밖의 것들에 대한 생각들 메모할 필요가 있어 간단히 끄적..
짝프로그래밍 반작용 케이스에 대해서도 생각해 봐야 하지 않을까..
SI 에서 자주 보는 페어.
도메인에 대한 지식과 주변 협업정보에 월등한 PL과
개발이 뛰어나지만 도메인과 협업정보 획득이 어려운 팀원..
PL이 뒷받침해주지 못할 경우 팀원은 자신의 역량만큼 일을 해내지 못해 괴리감에 빠지고
PL은 책임과 성과에 얽히다 보니 사실은 부드럽고 긍정적인 사람이라 하더라도
'왜 이렇게 쉬운 것을 이런식으로 기간동안 해내지 못했는가..'와 같이 공격/책망하게 되던데..
프로젝트팀에서 개인 또는 팀에 바라는 것이
'해낸 분량이 다른 팀원과 비교할때 평균수준 이상인가?'인지 확인해 볼 필요가 있다.
SI프로젝트들 대부분.. 평균이하가 생길 수 밖에 없지만 모두가 상대적으로 우위에 있기를 기대한다.
무의식적으로 경쟁을 유도하는 경우..
회고, 스탠드업미팅, 현황발표를 예로들면..
A xx점, B xx점.. 이와 같이 단순히 수치로 비교되는 내용을 공유하는 경우가 있다.
의도하진 않았겠지만 A는 B보다 더 많은 일을 했다는 식으로 발표하는 자리를 통해서
협력할 팀과 팀원들 보다 분량상으로 비교우위에 있도록 강조하는 꼴이 되고 만다.
같은 내용이더라도 분량으로 비교가 되지 않도록 내용을 공유하거나 그 밖의 사항들을 언급해주는 것도 필요하다.



덧글
영회 2009/02/13 19:54 # 삭제 답글
첫째 사례는 코드를 공유하며 함께 개발을 하는 짝 프로그래밍의 전형과 거리가 있어 '짝프로그래밍 반작용'으로 이름 짓기는 힘들다 생각하지만, 세 가지 내용 모두 경험과 통찰이 묻어나는 좋은 예시네요.
cavin 2009/02/15 03:16 #
첫째는 코드를 같이 공유하며 '직접 개발에 참여하는 PL'과 팀원 페어를 떠올린거랍니다 :)