애자일 이야기 : 작은 팀이 강하다

작은 팀이 강하다

똑같은 4만 라인을 작성하는 프로젝트입니다. 2.5명 팀이 있고, 29명 팀이 있습니다. 평균적으로 어느 팀이 빠를까요? 29명 팀이 빠릅니다. 얼마나 빠를까요? 2.5명 팀은 365일 걸리고, 29명 팀은 353일 걸립니다. 29명 팀이 고작해야 12일 빠릅니다. (아마 품질면에서는 2.5명 팀의 작품이 더 나았을 겁니다)

왜 이런 일이 벌어질까요? (힌트: 소프트웨어 개발은 벽돌 쌓기가 아니라 지식 노동입니다)

IBM 디벨로퍼웍스에 제가 쓴 작은 팀이 강하다는 기사를 보세요.

--김창준

# by 애자일컨설팅 | 2007/08/28 17:01 | 트랙백(4) | 핑백(2) | 덧글(16)

트랙백 주소 : http://agile.egloos.com/tb/3729760
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]

Tracked from Never Ending.. at 2007/08/28 23:15

제목 : 진정 인력 부족이 문제인가?
작은 팀이 강하다 흠.. 어쩌면 지금의 상황에 딱 맞는 글인듯하다. 요즘 밀려드는 일로 괴로워하며 '인력의 절대적 부족'을 외쳤는데... 반성해 볼 문제... 설사 진정으로 문제가 인력의 부족이라 해도, 현상황에서의 최선의 대책을 세우는데 너무 안일하게 대응 했던것은 아닌가... 대책을 세우자는 말에 딱 잘라, '인력이 부족해서 어떻게 해볼 도리가 없어요' 라고 했으니......more

Tracked from 바늘로 우물파듯이 at 2007/08/30 17:21

제목 : 작은 팀이 강하다
그다지 일이 손에 잡히지도 않고 해서이런저런 곳을 뒤지고 다니고 있다.늦게나마 RSS라는걸 발견하고선 그 전에 설치했다가 거의 안쓰고 있던 Firefox브라우저를 꺼내 열심히 놀고 있다..^^;IBM의 한국 developerWorks라는 곳에 올라온 칼럼인데역시나 알면서도 깨닫지 못했던 부분을 잘 긁어주고 있다.작은 팀이 강하다...more

Tracked from Flying Mate at 2007/08/30 23:23

제목 : Quantity vs Quality
陰뚯닔薏쀞柚묐삊壬쎷薏몄썝薏녠 宥ㅼ닔薏쀞日됰쾾壬쎷薏몄썝蹂대떎 楢곗뼱魏읻飮쀞蟻덈떎孺볖薏댁빞湲곕뒗 毅ㅻ옒 誼꾨?蚓?蟻덉뼱 疑붾떎. 擬쇰쭏魏쀞陰뚯닔疑? 擬쇰쭏魏쀞宥ㅼ닔瑜쁩薏댁빞湲고븯孺붽?. 薏넸諛붾떏, 義메淫쒕퉬泣ｍ陰뚰봽麟몄썾擬넸遺꾩빞椅먯꽌孺볖凹.....more

Tracked from 우렁닷컴 at 2007/08/31 11:26

제목 : 협력이 익숙치 않은 상황에서 인력충원이 되었을 때...
협력이 익숙하지 않은 상황에서 인력이 막상 충원됬을 때 겪었던 개인적인 에피소드가 있다. 2006월 2월에 오픈베타 서비스를 하기로 한 게임사이트를 진행하고 있을 때 였다. 1년이 넘는 동안 사업부 내의 웹사이트 개발팀원은 나 혼자였고, 2월 14일 오픈베타 사이트 오픈을 위해 주구장창 혼자서 야근하기를 몇 달...인력충원을 하려고 꾸준히 노력했지만, 이런저런 이유로 결국 2월 1일쯤에 한명이 충원됐다. (사이트 오픈까지는 이제 2주가 남았던 ......more

Linked at 미친병아리가 삐약삐약 : 20.. at 2007/09/03 00:32

... 를 종용하고, 자신에게 바라는 것이 많은 사람에게는, 성공과 희망이라는 이름의 초청객이 찾아 와서 도전을 장려한다. 그대 인생의 주인은 세상이 아니라 그대 자신이다. 작은 팀이 강하다 정말 공감되는 내용이다.. 댁의 '예금'이 아니라 'PC'가 안녕하십니까? 이슈 되겠어? 적용 되겠어? : 메모리 해킹 인터넷 뱅킹 메모리 해킹...그거까지 했어 ... more

Linked at 매일 매일 Grow up : .. at 2008/02/26 10:37

... 트웨어+서비스' J4F 웹호스팅(PHP 5,000/년, JSP 10,000/년, 가상서버 50,000/년) 포펜딕 부부 서울 강연 일과 삶의 균형을 중시하는 IT 회사 작은 팀이 강하다 야근 금지 오픈소스, 그 현실과 가치 - 노다 테츠오 교수님과의 대화 성황리에 끝난 Daum DevDay 2007 전설의 'C&C' 12주년 기념 무료 ISO ... more

Commented by 기니만 at 2007/08/28 17:16

단순 조립 공정이 아니고서야 이제 man/month 개념은 통하지 않는 세상이라는 의미로 받아들여도 되는건가요?

Commented by TayCleed at 2007/08/28 20:23

0.5명은 왜 0.5명인가요? ㅎ

Commented by 선환 at 2007/08/29 05:58

half time manager 아닐까요..

Commented by David at 2007/08/29 08:25

결함밀도에 대한 이야기는 100% 수긍이 갑니다.
그러나 프로젝드의 크기가 커지면, 개발 코드외의 부산물들이 생김니다.
무엇인지 아시겠지요?
더 많은 미팅과 이해 관계자와의 관계와 보고 자료들...

아참 한가지 프로젝트의 성공과 실패는 무엇으로 판별하나요?
처음 계획에서 벗어나면 실패한 것으로 봐야하나요?(재정, 일력운영, 기간, 요구사항 구현)
책임자는 절대로 실패한 프로젝트라고 이야기 하는 것을 거의 못봐서... ^^;;

Commented by alones at 2007/08/29 09:21

조직의 성숙도 (CMM등에서 말하는 maturity)가 관건일 것 같습니다.

성숙한 조직이어서, 조직이 체계적이고 각 자의 역할 (PM, PL, Developer, etc)을 제대로 잘 수행하고 있다면 - 그리고 ^^ 일정도 - 인력이 투입되어 M/M이 늘어난다면 더 좋은 소프트웨어를 만들 수 있을 것입니다.
그렇지 못한 경우는 사회 문제 (-_-)를 일으킬 소지가 높은 것 같습니다. 제 주위에서도 중간 관리자는 야근을 하는데 새로 투입된 인력에게 교육 (현재 프로젝트에 대한 도메인 지식과 같은) 및 지시를 할 시간이 없어서 눈물 흘리며 신규 인력을 놀리는 것을 본 것 같습니다.

그리고 Risk를 관리해야 할 사항이 아니라면 프로젝트 진행 중간에 인력이 투입되는 것은 좋지 않은 것 같습니다.
프로젝트 시작 시점에 예측을 잘 하고 조직을 잘 구성하는 것이 중요한 것 같습니다.

Commented by 레인블루 at 2007/08/29 11:04

일반적인 경우 성과를 평가할때 부진의 원인을 인원부족으로 몰아가면 서로서로 편한경우가 많죠. ^^

Commented by 푸른달팽이 at 2007/08/29 16:37

2명이서 프로젝트 하는데 2달 걸린다고 할 때..
사람 2명 더 뽑아줄테니 1달만에 해달라고 하는 경우가 있죠..

그럴 때는... "1000명 뽑아주시면 3초만에 끝내드리지요" 라고 대답을 ^^;

Commented by 수말군 at 2007/08/29 20:34

앗. 그런 센스있는 대답문구가 있었군여 = _=)!
푸른달팽이님 감사해요 ' ㅂ' 꼭 한번 써먹어봐야 겠어요

Commented by Solid_One at 2007/08/29 23:23

기발한 대답이네요. ^^
저도 꼭 써먹어야 겠군요.

Commented by 애자일컨설팅 at 2007/09/03 10:40

[TayCleed님] 0.5명은 아마 작은 팀의 평균 인원수인 2.5명에서 소수점 이하 숫자를 말씀하시는 것 같은데, 평균 수치이기 때문에 0.5가 나올 수 있습니다. 5명 이하인 소규모 팀들의 팀원 숫자를 평균 내었더니 2.5가 나왔다는 말이죠.

Commented by 애자일컨설팅 at 2007/09/03 10:42

[푸른달팽이님] 비슷한 답변 방식이 있습니다. 최적화(속도)와 정확성(corretness)에 대한 우스개 이야기인데, 다음과 같습니다. "오류가 있긴 하지만 실행 시간을 5시간에서 4시간으로 줄였습니다"/"정상 작동하지 않는다면 저는 0.001초로 줄여드릴 수 있습니다" 제랄드 와인버그 책에서 본 것으로 기억합니다.

Commented by 어이 at 2007/09/03 17:17

와인버그 할아버지가 할 만한 농담이네요. 맞는 것 같아요.

Commented by 굴돌 at 2007/09/05 19:37

Mythical Man-Month에서 나오는 임산부(pregnant) 얘기도 유명하죠.
10명의 임산부를 투입한다고 1달만 애가 튀어나오지는 않으니까요.(정확한 문장은 기억이 안나네요)

그러나, 개인적으로는 설계에 따라서는 충분히 기간을 단축할 수도 있다고 봅니다. david님의 의견에 동의 한표...
물론 10달 -> 1달이 될 수 있을지는 모르겠지만요.

위에서는 꽤나 극단적인 얘를 드신 듯 싶네요. ^^;

Commented by 時雨 at 2007/09/06 16:43

다른 업계도 비슷한 것이지요... 프로그래머이지만 부업으로 가끔 번역을 하는데 번역자의 숫자가 늘어나면 감당이 안됩니다. 문체는 통일시켜야 하는데 번역자마다 문체가 틀리고 약간의 검색만 할 수 있는 것도 자신이 아닌 범위에서 혹은 사전적 범위 내에서만 끝내니 오역도 무시못하지요... 뭐 개발쪽 일도 마찬가지이긴 하지만요...

Commented by 태즈 at 2007/09/10 02:18

'적정선'을 넘는 인원은 오히려 저해요소가 된다고 봅니다. 문제는 그 '적정선'을 어떻게 규정하느냐가 되겠지요. 이는 프로젝트 자체의 규모 뿐만이 아니라, 업무의 의존성/일관성/작성단위분할 등과 같은 업무특성에 기인해서 정리되어야 할 것 같습니다. 역시, 플젝 자체와 전반적인 업무 내용들을 제대로 파악한 상태에서 초반 리소스 할당이 이루어져야할 것 같네요.
항상 좋은 글, 감사드립니다~.

Commented by prostars at 2007/10/02 17:13

단일 프로젝트에서는 작은 팀이 강한 것에 수긍이 갑니다.
하나의 팀이 여러 가지 프로젝트를 진행하는 과정에서는 역시 인력이 더 필요하다는 것을 많이 느낍니다.
쿠쿠...위의 1000명에 3초는 정말 기발하네요~

< 이전페이지

다음페이지 >