Size: 8217
Comment:
|
Size: 8248
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 4: | Line 4: |
{{{#!wiki muilti-columns |
|
Line 34: | Line 36: |
}}} |
서론
이 책은 7장으로 구성되어 있으며, 각 장은 7가지 린 원칙과 각 원칙을 애자일 실천방법으로 바꾸는 사고 도구를 주제로 다룬다.
1. 낭비를 제거하라
낭비는 제품에 가치를 부가하지 못하는 모든 것을 일컫는데, 이때 가치란 고객이 인지하는 것을 말한다. 린 사고에서 낭비의 개념은 높은 장애물이다. 만약 컴포넌트가 먼지가 쌓인 채 선반 위에 놓여 있다면 그것이 바로 낭비다. 만약 개발 주기에 따라 요구사항을 책으로 정리했는데 거기에 먼지가 쌓인다면 그것도 낭비다. 개발자가 당장 필요한 기능보다 많이 코딩한다면, 그것도 낭비다. 제조 과정에서 제품을 이리저리 끌고 다니는 것도 낭비다. 제품 개발에서 개발 과정을 한 집단에서 다른 집단으로 넘기는 것도 낭비다. 이상적인 것은 고객이 원하는 바를 알아내고 정확하게 그들이 원하는 것을 개발, 생산해서 거의 즉시 전달해 주는 것이다. 무엇이든지 고객의 필요를 빨리 만족시키지 못하게 방해하는 것은 모두 낭비 요소다.
2. 배움을 증폭하라
개발이 새로운 발견을 연습하는 과정이라면 생산은 변동 줄이기를 연습하는 과정이다. 이런 이유 때문에, 개발을 하기 위한 린 접근법은 린 생산 실천방법과는 꽤 차이가 있다. 개발이 조리법을 만드는 것이라면 생산은 요리를 만드는 것과 같다. 조리법은 어떤 것이 동작하는지에 대한 감각과 상황에 맞게 재료를 이용하는 능력을 갖춘 숙련된 주방장에 의해 만들어진다. 하지만 위대한 주방장조차새로운 조리법을 반복해 보면서 여러 가지 변형을 시도하는 과정을 거쳐 맛이 더 좋고 요리하기 쉬운 조리법을 만든다. 주방장도 처음 시도에서 완벽한 조리법을 기대하지 않는다. 그들은 배우는 과정의 일부분으로 한 가지 테마에 대해서 몇 가지 변형을 일으켜 본다. 소프트웨어 개발은 개발팀이 크고 결과가 조리법에 비해 훨씬 복잡하다는 도전이 있긴 하나, 이와 유사한 학습 과정으로 생각하는 것이 좋다. 소프트웨어 개발 환경을 개선하는 가장 좋은 방법은 배움을 증폭하는 것이다.
3. 가능한 늦게 결정하라
결정을 늦추는 개발 실천방법은 불확실성을 포함하고 있는 영역에서 효과적이다. 왜냐하면 이 방법은 선택에 기반을 둔 접근방법을 제공하기 때문이다. 불확실성에 마주하여 대부분의 시장경제는 미래가 가까워지고 예측하기 쉬워질 때까지 투자자들이 결정을 늦출 수 있또록 여러 가지 옵션을 개발한다. 추측이 아닌 사실이 바탕이 될 때 더 나은 결정을 할 수 있기 때문에 결정을 늦추는 것은 유용하다. 진화하는 시장에서는 설계의 선택사항을 열어놓는 것이 빨리 결정해 버리는 것보다 가치가 있다. 복잡한 시스템을 개발할 때, 결정을 늦추는 핵심적인 전략은 변화할 수 있는 능력을 시스템에 주는 것이다.
4. 최대한 빨리 납품하라
최근까지 소프트웨어를 신속히 개발하는 것은 가치가 없었다. 조심스럽게 진행해서 실수하지 않는 것이 더 중요해 보였다. 그러나 지금은 알려진 통념들 목록에 '품질이 더 가치 있다'와 함께 '속도가 더 가치 있다'도 넣어야 할 시점이 되었다. 신속한 개발은 장점이 많다. 속도 없이는 결정조차 미룰 수 없다. 속도 없이는 신뢰성 있는 피드백도 없다. 개발에서 발견 주기는 학습하는 데 매우 중요하다. 주기는 설계, 구현, 피드백, 개선으로 이루어진다. 이 주기가 짧을수록 더 많은 것들을 배울 수 있다. 속도는 고객이 어제 원했던 것이 아니라 지금 원하는 것을 얻도록 해준다. 또한 고객이 진짜로 원하는 것에 대해서 더 많이 알 때까지 결정을 미루도록 해준다. 가치 흐름을 가능한 한 압축하는 것이 낭비 요소를 줄이는 기본적인 린 전략이다.
5. 팀에 권한을 위임하라
가장 좋은 실행은 구체적인 사항이 제대로 되느냐에 달려 있으며, 그 일을 실제로 하는 사람이 그 누구보다도 구체적인 사항들에 대해 더 잘 알고 있다. 기술과 관련된 구체적인 결정을 할 때 좋은 성과를 내기 위해서는 개발자와 함께 해야 한다. 일선에 있는 사람들은 세세한 구체적인 지식과 많은 의견을 결합시킨다. 이들은 필요한 전문지식을 갖추고 리더의 지도를 받으면 기술에 관한 결정이나 프로세스에 관한 결정을 내릴 때, 누구보다 더 나은 능력을 발휘할 것이다. 결정은 늦게 내려지고 실행은 빠르기 때문에, 중앙에서 작업자들의 활동을 조정하는 것이 불가능하다. 따라서 린 실천방법은 작업을 계획하는데 당김 기법pull techniques을 사용하고 국지적으로 신호를 보내는 메커니즘local signaling mechanisms을 사용하여 작업자들이 어떤 것이 완료되어야 하는지 서로 알게 한다. 린 소프트웨어 개발에서, 당김 메커니즘은 일정한 간격으로 작업 소프트웨어를 점점 발전된 버전으로 만들기 위한 것이다. 현지 의사소통은 눈에 보이는 표, 일일 회의, 잦은 통합 그리고 포괄적인 테스트를 통해 하게 된다.
6. 통합성을 구축하라
사용자가 '그래! 이게 바로 내가 원하던 거야. 누군가가 내 마음에 들어왔다 간 것 같군!'이라고 생각할 때, 시스템은 통합성을 갖추었다고 인식된다. 시장 점유율은 제품의 인식 통합성perceived integrity을 나타내는 대략적인 수치이다. 왜냐하면 시장 점유율은 시간에 따른 고객의 인식을 측정하는 것이기 때문이다. 개념 통합성conceptual integrity은 시스템의 중심 개념이 유연하면서 총체적으로 응집력 있게 작동하는 것을 의미하며, 그것은 통합성을 인식시키는데 필수적인 요소이다. 소프트웨어에는 시간이 지나도 유용성을 유지해야 하는 추가적인 통합성이 요구된다. 소프트웨어는 전형적으로 미래에 적응하면서 품위 있게 진화해야 한다. 통합성을 지닌 완전한 소프트웨어는 구조가 일관되고, 목적에 대한 유용성과 적합성에서 높은 점수를 받으며, 유지보수가 가능하며 적응성과 확장성이 좋다. 한 연구에 따르면 통합성은 현명한 리더십과 적절한 전문적인 기술, 효과적인 의사소통, 그리고 건전한 규율에서 온다는 것을 보여준다. 프로세스, 절차, 측정으로는 충분히 대신할 수 없다.
7. 전체를 보라
복잡계에서 통합성이 있으려면 다양한 분야에 걸친 깊은 전문지식을 갖춰야 한다. 제품 개발에서 가장 처리하기 힘든 문제 중 하나는 어떤 분야(예를 들어 데이터베이스 혹은 GUI)라도 전문가는 전체 시스템의 성과에 초점을 맞추기보다는 자신의 전문성을 잘 보여주는 부분에 성과를 최대화하려는 경향이 있다는 점이다. 만약 자신의 분야에만 관심을 가지고 고집을 부리다 보면 개발 프로젝트 자체가 고전을 면치 못하기도 한다. 개인 혹은 조직이 전체적인 성과 대신 그들의 특화된 기여도에 따라 평가된다면, 부분 최적화suboptimization가 결과일 것이다. 이 문제는 두 조직이 서로 계약을 맺을 때 더 두드러진다. 왜냐하면 사람들은 본래 자기 회사의 성과를 높이고 싶어하기 때문이다. 큰 조직에서 부분 최적화를 피하는 방법으로 실행하는 것은 힘들고, 계약이 뒤엉킬 때에는 그 크기의 정도에 따라 더 어려워진다.