클릭하시면 큰 그림으로 보실수 있습니다. 밑에 글을 읽어 보신후 마인드맵을 살펴 보세요..

위의 그림은 삽집없는 소프트웨어 개발을 위한 린 소프트웨어 개발의 원칙을 마인드맵으로 표현한 것입니다. 우선 7가지 원칙에 대한 밑의 글을 읽어 보신후 마인드맵을 살펴 보시면 훨씬 도움이 되실 겁니다.

1. 낭비를 제거 하라.
(소프트웨어 개발에서의 가장 큰 낭비 세 가지-가외기능,혼란,경계 넘어가기)

  회사에서는 20% 가 80% 먹여 살린다고 합니다. 2 대 8의 법칙이라고 하나요 ? 소프트웨어 에서도 똑같습니다. 20%의 기능이 80%의 가치를 제공한다고 합니다. 그렇기 때문에 개발시 정말 중요한 20%에 집중하고 가외 기능이라고 할수 있는 80%는 천천히 개발 하던지 아예 개발 하지 말아야 합니다.
 
  또한 요구 사항을 먼저 정의 할 경우 요구사항의 변경으로 혼란이 발생 할수 있으며,  코딩을 마친후에 테스트를 시작한다면 테스트의 증가로 실제 개발 보다 테스트가 더 길어지는 혼란 아닌 혼란을 야기 하는데 이것은 중요한 낭비입니다.

  마지막으로 조직간의 경계를 넘어가면서 발생함으로써 발생하는 여러가지 비용 역시 중요한 낭비 사항 입니다. 소프트웨에 개발을 성공적으로 이끌기 위해서는 이러한 낭비요소를 철저히 제거해야 합니다.


2. 품질을 내재화 하라.
(검증 단계에서 늘상 결점이 발견된다면 그 프로세스에 결함이 있는 것이다.)

개발 초기 부터  테스트 주도 개발(TDD) 을 해아 합니다. 개발을 마친후에 테스트를 하면 분명히 실수가 발생할수 있습니다. 또한 레거시 코드 즉, 자동화된 단위테스트와 인수 테스트가 없는 코드는 절대 만들지 말아야 합니다. 마지막으로 나중에 한꺼 번에 하는 빅뱅 통합은 커다란 문제를 발생 시킬 것 입니다.

3. 지식을 창출하라.
(계획은 유용한 것이며, 학습은 필수적인 것이다.)
 
가설을 세우고, 신속하게 다양한 실험을 해보고, 문서를 간결하게 작성하고, 최선의 대안을 구현할 수 있도록 팀을 가르쳐야 하고, 모든 사람들이 따라하고 잘 알려진 실천법을 표준에 포함하되, 누구든지 표준에 도전하고 변경하도록 장려해야 합니다.  그리고 예측 가능한 조직은 미래를 추측하고 그것을 계획이라고 하지 않으며, 그 보다는 미래가 펼쳐질 때 신속하게 대응하기 위한 역량을 개발합니다.

4. 확정을 늦춰라.
(완벽한 명세서를 가지고 개발을 시작하는 것이 좋은 아이디어라는 생각을 버려라.)

시스템 아키텍처는 언제 어떤 기능이 추가 되더라도 그것을 수용할수 있어야 하며, 코드는 실험으로 생각해서 변화를 수용할수 있게 작성 해야 합니다. 그리고 돌이킬수 없는 결정은 마지막 결정의 순간에 해야 하며 그전에 충분한 학습이 선행 되어야 합니다.

5. 빨리 인도하라.
(리스트와 대기열은 일의 속도를 늦추는 조직 간의 버퍼다.)

속도의 경쟁에서 승리하는 회사는 큰 비용우위를 갖고 월등한 품질의 제품을 인도하며 고객의 요구에 더 귀기울 입니다. 그러기 위해서 대기행렬 이론을 개발에 적용해서 배치(batch) 크기를 작게하고 진행 중인 작업량을 줄여 주기 시간(cycle time)을 줄여야 합니다. 마지막으로 고객에게 인도할 수 있는 역량에 맞게 리스트와 대기열의 길이를 공격적으로 제한해야 합니다. 즉 일의 양을 할 수 있는 만큼으로 제한해야 합니다.

신속한 인도, 고 품질, 저 비용은 공존할 수 있습니다.

6. 사람을 존중하라.
(주도적으로 참여하고 연구하는 사람들이 최고의 지속가능한 경쟁우위를 제공한다.)

팀은 자부심, 책임감, 신뢰, 칭찬을 통해 번성합니다. 단순한 워크그룹이 아닌 팀은 공동 목표를 달성하기 위해 상호간 책임의식으로 뭉쳐있습니다. 효과적인 팀에는 팀을 최고로 이끄는 훌륭한 리더가 존재한다. 또한 조인트 벤처를 위한 헌신은 절대로 이해상반을 만들지 않습니다. 파트너를 존중 하십시오..

7. 전체를 최적화 하라.
(빼어난 제품은 기회와 기술의 특별한 만남에서 나온다.)

고객요구에서 소프트웨어 배포까지 전체 가치 흐름에 초점을 맞춰야 합니다. 소프트웨어만이 아닌 완전한 제품을 개발해서 완전한 제품을 인도 하세요.완전한 제품은 완전한 팀에 의해 만들어집니다.주기 시간으로 프로세스 역량을 측정하고, 인도된 비즈니스 가치로 팀 성능을 측정하며, 순추천고객지수(NPS)로 고객 만족을 측정 하세요..

오픈 마루에 계신 이창신님께서 지난 주말에 밤을 새가면서 마무리를 해주신 덕에 드디어 JRuby on Rails 를 출간합니다.

JRuby는 6월에 정식 1.0 버전이 릴리즈되었습니다. 이를 통해 루비를 자바의 세계로 끌어들임으로써 그동안 자바에 익숙해 있던 자바 개발자들에게 웹과 엔터프라이즈 개발에 대한 새로운 도전의 기회를 열어줄 것입니다.

어쩌다가 위키북스에 엮여서(?) Ruby 책 번역에서부터 완전히 저서에 가까운 세계 최초의 JRuby 책을 만들기까지의 기나긴 고행을 겪으신 이창신님의 일년(?)기는 역자서문을 통해 보실 수 있습니다.

그동안 책을 쓰시느라 고생하신 이창신님께 다시 한 번 진심으로 감사드립니다.

위키북스 오픈소스 & 웹 시리즈 에디터인 일래스틱의 web2.0business 블로그에 '[iBATIS] 동적으로 SqlMap Xml 로드하기'란 제목으로 새 글이 올라왔습니다. 독자분들께 유익한 정보가 되길 바라며, 앞으로도 'web2.0business 블로그'에 많은 관심과 성원 바랍니다.

위키북스에서 세 번째로 내는 책입니다. 소프트웨어 공학, 프로젝트 관리 분야와 더불어 위키북스에서 앞으로 주로 다룰 '오프소스 & 웹 시리즈'입니다. 앞으로 검증되고 국내에 꼭 소개할 만한 오픈소스와 차세대 웹을 이끌어나갈 신기술들을 소개하고자 합니다. 2탄으로는 4월에 출시할 iBatis in Action이 있습니다. 국내에 소개할 만한 좋은 오픈소스와 웹기술이 있다면 언제든지 알려주시면 적극 반영하겠습니다.

1장 팀원과 업무에 대해서 알아가기

그림을 클릭하시면 크게 보실수 있습니다.




1. 한사람씩 관리하기 - 일대일 회의


  매주 일정한 시간을 정하세요. 매주 같은 시간에 자신의 팀원을 한 사람씩 만나세요. 지속적인 회의는 고유한 흐름을 만들고 팀장과 팀원에게 준비해야 한다는 사실을 기억하게 합니다.

  몸가짐을 조심하세요. 일대일 회의동안 전화를 받거나 걸고, 서류를 보거나 다른 일을 하지 마세요. 일대일 회의를 하는 도중 관리자의 개인적인 일로 회의를 중단하면 상대방보다 자신의 시간이 더 중요하다는 메시지를 상대 팀원에게 전달하는 셈입니다.

  일대일 회의를 충실히 지키세요. 일대일 회의를 취소하면 팀원들은 자신이 무시당했다고 느낍니다. 그렇게 되면 얼마 지나지 않아 팀에서 벌어지는 일을 알 수 없게 됩니다. 일대일 회의를 계속하세요. 그러면 프로젝트 지연, 불행한 팀원, 곪아 터지는 문제 때문에 당황하지 않을 겁니다.

  일대일 회의에서 일관된 형식을 따르세요. 일관된 형식을 유지한다면, 팀원은 여러분을 변덕스럽지 않고 신뢰할 수 있는 사람이라고 믿게 됩니다. 모든 사람에게 같은 형식을 사용하고, 특별한 경우에도 이 형식을 지켜야 한다는 의미는 아닙니다. 그러나 시간이 지나고 나서도 일관성을 유지하면 여러분이 변덕스럽지 않고 믿을 만하다고 팀원은 생각합니다.

  융통성을 발휘하세요. 사람과 작용하고 반응하는데 변화를 주지 못한다면 지속적인 회의는 쓸모 없습니다. 개인마다 여러분의 관리 스타일을 바꾸고 문제를 다루는데 공정해야 합니다. 잘못된 방향으로 나가려는 사람이나 새로운 사람과 매주 만나세요. 업무를 계획하는 사람과 격주로 회의하는 것도 고려해야 합니다.

2. 돌아다니며 경청하면서 관리하기(Management by Walking Around and Listening)


  팀원의 공간과 시간을 존중하세요. 팀원을 방해하지 않도록 조심하세요. 부하 직원이 전화하거나 일에 집중하고 있다면 조용히 빠져 나옵니다. 부하 직원이 한가하다면 들러서 일 이분 정도 이야기를 나누세요. 어떤 질문은 모호해서 오해의 소지가 있습니다. 즉 “뭐하고 있어요?”나 “어떻게 되고 있어요?”와 같은 질문은  깐깐한 관리의 인상을 줄 수 있는데, 특히 팀원이 시간에 쫓겨 일할 때는 말이죠. “잘 지내고 있어요” 같은 중립적인 질문을 사용하세요.

중립적인 질문보다 더 나은 질문은 도움을 주는 질문입니다. “필요한 게 있나요?”나 “제거해 줄 장애물은 없나요?” 같은 질문입니다. 상황, 조직의 문화, 여러분과의 관계가 팀원이 질문을 이해하는 방향을 결정합니다

  메모를 하세요. 팀원이 뭔가를 요청한다면 요청을 즉시 받아 적으세요. 말 없이 돌아다니면서 메모를 하면 팀원들은 여러분을 의심스럽게 생각할지도 모르기 때문에, 사무실로 돌아와서 관찰한 내용을 기록하세요. 관찰 내용을 기록하기 위해서 메모장을 사용하세요. 시간이 흐르면서 메모는 조직과 여러분의 관리 방법에서 패턴을 발견하는데 도움이 될 것입니다.

3. 업무파악을 위한 데이타 수집하기


  업무 내용을 담을 수 있는 크고 눈에 띄는 차트를 만드세요. 모든 업무를 도표 안에 펼쳐 놓기 위해서 화이트보드나 벽을 사용하세요. 모든 업무를 가시적으로 만들어서 부서원 앞에 두면 부서원이 큰 그림과 패턴을 이해 하는데 도움을 줍니다.

  반복하세요. 차트를 처음으로 작성할 때는 필요한 모든 정보를 얻지 못할 겁니다. 하지만 계속하세요. ‘코딩’이나 ‘테스트’ 같은 일반적인 업무는 충분한 정보를 주지 못합니다. 일의 결과와 이러한 결과가 비즈니스에 어떻게 가치를 만드는지에 집중하세요. 또 질문을 할 때는 “누가 산출물을 사용하죠?” “누구에게 이 산출물이 필요하죠?” “당신이 산출물을 제공하지 못하면 어떤 결과가 생길까요?” 와 같이 구체적으로 물어보세요. 필요한 상세 정보의 수준을 명확히 표현하면 팀원이 작업의 우선 순위를 결정하는데 도움이 됩니다.

  반감을 이해하세요. 팀원은 실제로 무슨 일을 하는지 여러분에게 이야기하길 꺼려할 때도 있습니다. 아마도 당신이 지나치게 깐깐하게 굴거나 자신들을 신뢰하지 않는다고 느끼고 있기 때문일 겁니다. 팀원은 조직에게는 의미가 없을 수도 있지만 자신에게 가치가 있는 일을 포기해야 한다는 사실을 두려워할지도 모릅니다(여러분도 그렇겠죠). 하지만 계속해서 노력하세요. 즉 팀원이 큰 그림을 이해하도록 도와 주세요. 어떤 업무가 무슨 이유로 중요하고 조직의 목표에 그 업무가 어떻게 부합하는지 말이에요. 그리고 팀원의 이야기에 흔쾌히 귀를 기울이세요. 여러분이 모르는 것을 팀원은 알고 있을지도 모릅니다.