소프트뱅크 손정의 대표님에 관한 책을 몇 권 사러 가까운 대형 서점에 갔는데, 모두 재고가 없었다. 그래서 대신 '린 소프트웨어 개발'을 집어왔다. 집에 이미 사용자 스토리, 익스트림 프로그래밍, 테스트 주도 개발, 소프트웨어 프로젝트 생존 전략, 프로페셔널 소프트웨어 개발, 실용주의 프로그래머 등 읽다 만 애자일 책들이 수두룩 한데 거기에 또 한 권 추가하려니 죄책감이 들었지만 책을 손으로 만져보고는 당장 보고싶은 욕망에 들고올 수밖에 없었다.
좋은 품질의 제품을 적은 비용으로 더 빠르게 만드는 것, 이것이 애자일과 린이 추구하는 것인데 사실 이것은 모든 프로젝트, 모든 기업들이 추구하는 바이기도 하다. 애자일이나 린이라는 단어를 모르는 조직이라도, '즐거운 효율성'에 집중하다보면 몇 가지 좋은 방법들을 발견하게 되고 적용하게 된다.
이미 그런 고민을 적극적으로 하고있는 조직은 애자일 프렉티스, 린 개발, 익스트림 프로그래밍에 관한 체계적인 지식을 접했을 때, 자신들의 방법을 더욱 효율적으로 다듬을 수 있고, 아직 발견하지 못한 다른 지침들 역시 적극적으로 도입할 수 있게 된다. 그리고 자신들이 발견한 방법이 좋다는 것을 체감하면서도, 관습적인 방식과 달라서 느꼈던 소외감을 날려버릴 수도 있다.
린 방법론에서는 프로젝트에서의 낭비 요소를 7가지로 분류하는 데, 가장 가시적이어서 가장 먼저 개선할 수 있는 요소가 가외 프로세스와 직무 전환, 그리고 이동이다. 가외 프로세스의 대표적인 예는 '불필요한 문서화'인데, 이 '불필요'라는 기준의 범위가 일반적인 통념보다 넓다.
가외 프로세스를 제거하기 위해 우선 견제해야 할 것은, 기획자가 혼자 앉아 신나게 기획서를 그리는 상황이다. 이는 소프트웨어, 웹, 게임 등 업계를 가리지 않고 발생한다. 자신이 만든 수북한 기획서와 빼곡한 명세사항을 보면서 기획자는 성취감을 얻고, 자신의 기획에 이런 저런 토를 다는 개발자들이 장애물로 느껴지면서, '개발자들은 밀어붙이면 다 하게 되어 있다'며 기획팀장이 보태주기까지 하면 아주 멋진 스파게티 프로젝트가 된다.
빼곡한 기획서를 '증거'삼아 '여기 분명히 명시되어 있지 않느냐, 왜 이것을 빼 먹었냐'고 개발자들을 밀어붙이기 시작하면, 반대의 상황이 되었을 때 '그런 것 하나 예측 못해서 기획을 수정하느냐'라는 감정 실린 반격을 받아내야한다. 어떻게든 마무리는 되겠지만 이제 둘 사이의 골은 깊어졌고 조직 전체의 개선 보다는 각 팀간의 정치적 서열 관리가 더 중요해지게 된다.
둘 사이가 견제 관계가 아닌 협력 관계가 되려면, 문서 작업을 줄이면서 잦은 대화와 가까운 거리, 그리고 서로의 영역에 대한 깊은 이해를 지향해야 한다. 문서는 꼬투리잡는 증거가 아니라 소통과 기록(잊지 않기 위한) 도구가 되어야 한다.
세부 사항은 PPT 기획서 보다는 문장 템플릿을 갖춘 사용자 스토리와 개발에 곧바로 이용될 테스트 코드로 작성되어야 한다. PPT는 기획서 작성을 위해서 보다는 인터페이스를 '그려보는' 용도로 이용한다. 이런 방식은 세밀한 전문화 보다는 포괄적인 이해와 지속적인 학습을 요구한다.
자신이 얼마나 전문적인지를 표출하는 데 시간을 쓰지 말고, 전체 프로젝트를 성공적으로 끝내서 더 많은 돈을 벌어들이는 데 집중해야 한다. 린에서 사용하는 세련된 문장으로 바꾸면, '제품의 가치를 향상'시키는 데 집중해야 하는 것이다.
또 다른 낭비 요소로 '직무전환'이 있는데, 한 사람, 한 팀이 동시에 여러 개의 프로젝트에 관여했을 때 낭비가 발생한다는 이야기이다. 잦은 직무전환이 효과적인 경우는 단순노무와 같이 반복적이고 개선이 불필요한 일이다. 지식노동에는 집중할 수 있는 충분한 시간이 필요한데, 여기 저기 투입되는 경우 집중력과 프로젝트에 대한 애착을 빼앗겨 효율적으로 사고하기 보다는 단순 반복적으로 사고하게 된다. 린에서는 하나를 끝내고 다른 것을 시작하라고 조언한다.
'이동'은 사람의 이동과 산출물의 이동으로 나뉘는데, 사람의 이동에는 공간적인 거리감 뿐만 아니라 심리적인 거리감도 포함될 수 있다. 거리를 이동하는 데서 발생하는 시간 낭비 뿐만 아니라 이동과 업무의 전환 과정에서 발생하는 집중력의 낭비도 무시할 수 없다. 산출물의 이동은 가외 프로세스에서도 언급되었던, 내용 전달을 위한 문서화 작업, 그리고 그 문서를 이해시키거나 이해하는 과정에서의 시간/노력 낭비를 이야기한다.
공간적 거리, 심리적 거리, 소통의 거리를 줄일 수 있는 방법 중 내가 추구하는 방향은 인력 규모를 줄여서 소수의 인력만 가지고 '제품의 가치를 향상시키는 것' 자체에 집중하는 것이다. 많은 양의 지식이 발신자의 머릿속에 남아 있어서 수신자에게 전달되지 않는데, 그 문제를 세밀한 문서나 잦은 커뮤니케이션으로 해결하는 것 보다는 수신자가 발신자의 지식 습득 과정을 똑같이 밟게 하는 것이 낫다고 본다.
점차 수신자와 발신자의 역할 분담을 제거해 궁극적으로는 한 사람이 하나의 프로젝트를 담당하게 되는 것이다. 애자일의 효율성 추구는 '지속적인 개선'을 전제로 한다. 개선의 대상을 자신의 파트에 국한시키지 않고 프로젝트에 필요한 모든 지식, 비즈니스에 필요한 모든 지식으로 확장해보는 것은 어떨까. 내가 느끼기엔, 포괄적인 지식 습득은 자신의 전문 분야를 더욱 깊게 이해하는데 큰 도움이 된다. 자신의 분야만을 깊이 파려고 노력하는 것보다도 말이다.
좋은 품질의 제품을 적은 비용으로 더 빠르게 만드는 것, 이것이 애자일과 린이 추구하는 것인데 사실 이것은 모든 프로젝트, 모든 기업들이 추구하는 바이기도 하다. 애자일이나 린이라는 단어를 모르는 조직이라도, '즐거운 효율성'에 집중하다보면 몇 가지 좋은 방법들을 발견하게 되고 적용하게 된다.
이미 그런 고민을 적극적으로 하고있는 조직은 애자일 프렉티스, 린 개발, 익스트림 프로그래밍에 관한 체계적인 지식을 접했을 때, 자신들의 방법을 더욱 효율적으로 다듬을 수 있고, 아직 발견하지 못한 다른 지침들 역시 적극적으로 도입할 수 있게 된다. 그리고 자신들이 발견한 방법이 좋다는 것을 체감하면서도, 관습적인 방식과 달라서 느꼈던 소외감을 날려버릴 수도 있다.
린 방법론에서는 프로젝트에서의 낭비 요소를 7가지로 분류하는 데, 가장 가시적이어서 가장 먼저 개선할 수 있는 요소가 가외 프로세스와 직무 전환, 그리고 이동이다. 가외 프로세스의 대표적인 예는 '불필요한 문서화'인데, 이 '불필요'라는 기준의 범위가 일반적인 통념보다 넓다.
가외 프로세스를 제거하기 위해 우선 견제해야 할 것은, 기획자가 혼자 앉아 신나게 기획서를 그리는 상황이다. 이는 소프트웨어, 웹, 게임 등 업계를 가리지 않고 발생한다. 자신이 만든 수북한 기획서와 빼곡한 명세사항을 보면서 기획자는 성취감을 얻고, 자신의 기획에 이런 저런 토를 다는 개발자들이 장애물로 느껴지면서, '개발자들은 밀어붙이면 다 하게 되어 있다'며 기획팀장이 보태주기까지 하면 아주 멋진 스파게티 프로젝트가 된다.
빼곡한 기획서를 '증거'삼아 '여기 분명히 명시되어 있지 않느냐, 왜 이것을 빼 먹었냐'고 개발자들을 밀어붙이기 시작하면, 반대의 상황이 되었을 때 '그런 것 하나 예측 못해서 기획을 수정하느냐'라는 감정 실린 반격을 받아내야한다. 어떻게든 마무리는 되겠지만 이제 둘 사이의 골은 깊어졌고 조직 전체의 개선 보다는 각 팀간의 정치적 서열 관리가 더 중요해지게 된다.
둘 사이가 견제 관계가 아닌 협력 관계가 되려면, 문서 작업을 줄이면서 잦은 대화와 가까운 거리, 그리고 서로의 영역에 대한 깊은 이해를 지향해야 한다. 문서는 꼬투리잡는 증거가 아니라 소통과 기록(잊지 않기 위한) 도구가 되어야 한다.
세부 사항은 PPT 기획서 보다는 문장 템플릿을 갖춘 사용자 스토리와 개발에 곧바로 이용될 테스트 코드로 작성되어야 한다. PPT는 기획서 작성을 위해서 보다는 인터페이스를 '그려보는' 용도로 이용한다. 이런 방식은 세밀한 전문화 보다는 포괄적인 이해와 지속적인 학습을 요구한다.
자신이 얼마나 전문적인지를 표출하는 데 시간을 쓰지 말고, 전체 프로젝트를 성공적으로 끝내서 더 많은 돈을 벌어들이는 데 집중해야 한다. 린에서 사용하는 세련된 문장으로 바꾸면, '제품의 가치를 향상'시키는 데 집중해야 하는 것이다.
또 다른 낭비 요소로 '직무전환'이 있는데, 한 사람, 한 팀이 동시에 여러 개의 프로젝트에 관여했을 때 낭비가 발생한다는 이야기이다. 잦은 직무전환이 효과적인 경우는 단순노무와 같이 반복적이고 개선이 불필요한 일이다. 지식노동에는 집중할 수 있는 충분한 시간이 필요한데, 여기 저기 투입되는 경우 집중력과 프로젝트에 대한 애착을 빼앗겨 효율적으로 사고하기 보다는 단순 반복적으로 사고하게 된다. 린에서는 하나를 끝내고 다른 것을 시작하라고 조언한다.
'이동'은 사람의 이동과 산출물의 이동으로 나뉘는데, 사람의 이동에는 공간적인 거리감 뿐만 아니라 심리적인 거리감도 포함될 수 있다. 거리를 이동하는 데서 발생하는 시간 낭비 뿐만 아니라 이동과 업무의 전환 과정에서 발생하는 집중력의 낭비도 무시할 수 없다. 산출물의 이동은 가외 프로세스에서도 언급되었던, 내용 전달을 위한 문서화 작업, 그리고 그 문서를 이해시키거나 이해하는 과정에서의 시간/노력 낭비를 이야기한다.
공간적 거리, 심리적 거리, 소통의 거리를 줄일 수 있는 방법 중 내가 추구하는 방향은 인력 규모를 줄여서 소수의 인력만 가지고 '제품의 가치를 향상시키는 것' 자체에 집중하는 것이다. 많은 양의 지식이 발신자의 머릿속에 남아 있어서 수신자에게 전달되지 않는데, 그 문제를 세밀한 문서나 잦은 커뮤니케이션으로 해결하는 것 보다는 수신자가 발신자의 지식 습득 과정을 똑같이 밟게 하는 것이 낫다고 본다.
점차 수신자와 발신자의 역할 분담을 제거해 궁극적으로는 한 사람이 하나의 프로젝트를 담당하게 되는 것이다. 애자일의 효율성 추구는 '지속적인 개선'을 전제로 한다. 개선의 대상을 자신의 파트에 국한시키지 않고 프로젝트에 필요한 모든 지식, 비즈니스에 필요한 모든 지식으로 확장해보는 것은 어떨까. 내가 느끼기엔, 포괄적인 지식 습득은 자신의 전문 분야를 더욱 깊게 이해하는데 큰 도움이 된다. 자신의 분야만을 깊이 파려고 노력하는 것보다도 말이다.
TRACKBACK :: http://flyingmate.net/trackback/26
-
Subject: 린 소프트웨어 개발
Tracked from The note of Legendre 삭제린 소프트웨어 개발을 읽었습니다.[footnote]원서는 "Lean Software Development"입니다.[/footnote] 도요타라는 자동차 회사에서 적용하고 있는 작업 방식(혹은 도요타 생산방식이라고 알려진)에 대해서는, 많은 경영서들에서 언급하고 있었고 이런 방식이 소프트웨어 개발에 적용될 수 있다는 점에서 이 책에 관심을 갖게 되었습니다. 책의 부제는 "애자일 실천 도구 22가지"인데, 이 부제대로 책은 각 도구를 기준으로 하여 차분..
2007/10/27 01:43
댓글을 달아 주세요
안녕하세요. 오랜만?에 답글 다네요.. 처음인가?
2007/10/21 23:21정리 잘 해 주셨네요. 잘 읽고 갑니다.
린 소프트웨어 개발을 읽고 느낀 점이 많아 회사네 르네상스 클럽을 진행하고 있습니다. 변화의 씨앗이 되고 싶은 분들과 그 실천으로 회사에 희망을 피워보자는 사람들이 모였습니다. 아래에서의 변화가 진정한 변화라 생각합니다.
이제 어느 정도 계획도 정리 된 것 같네요... 어떻게 실천하고 어떤 난관에 부딪치고 어떻게 극복하고 양보(포기?)하는지 블러그에 정리해 볼까 합니다. 지켜봐주세요..ㅎㅎ
정의의소님 와주셔서 감사합니다 ^-^
2007/10/22 10:42저번 토론회에서도 경험과 의지가
풍부하신 분이라고 느꼈었는데,
이렇게 본격적으로 실천하게 되셨다니
열렬히 응원해 드리겠습니다!
움직이기 쉽지 않은 회사이지만
정의의소님의 맷집(?)이라면 분명
크게 흔들 수 있을 것 같아요~ 화이팅입니다!
비밀댓글 입니다
2007/10/24 17:50감사합니다. 회원정보의 주소로 보내주시면 됩니다^^
2007/10/24 22:07