Tutorial이 뭐하는 건지도 모르는 상태에서 참여했다. 사실 오전, 오후 시간만 잘 맞으면 DDD를 듣고 싶었는데, 오후 강의가 마음에 들지 않아서 The Zen of Agile Management를 듣게 되었다. 결과적으로 말하면 영어가 되지 않는 상태에서 개발 방법론을 들은 것은 실수였다는 생각이다. 하루 종일 듣는 것이라면 아예 Domain Specific Language(DSL)를 듣는 것이 좋은 선택이지 않을까라는 생각이 든다.
오늘 컨퍼런스의 첫째날을 보내면서 느끼는 것이 최근 DSL에 대한 관심도가 높아지고 있다는 것이다. 국내에서는 거의 이야기되지 않는 내용인데 이곳에서는 벌써 활용사례부터 아키텍처까지 이야기하고 있으니 참 빠르다는 생각이 든다. 이 내용은 내일 정리해보도록 하겠다.
강의 문서가 있는 상태에서 블로깅을 하는 것이 좋을 것으로 생각되어 하루나 이틀씩 늦게 포스팅이 가능할 것으로 생각한다. 강의 문서를 하루 늦게 전달하는 바람에.. 사진과 말빨로 때우기는 힘들거 같다.
The Zen of Agile Management Tutorial의 처음은 팀내의 신뢰가 바탕이 되어야 한다는 내용으로 하루 강의가 시작되었다. 신뢰가 바탕이 되지 않는 상태에서는 프로젝트를 진행하기 힘든 것은 어느 곳이나 기본적으로 깔려 있어야 될 것으로 생각한다.
David Anderson이 프로젝트 성공을 위한 요소는 다음과 같다.
위 구성 요소 중에서 가장 인상 깊게 남은 부분은 Work-in-Process(이하 WIP)를 줄이기 위하여 Lead Time을 측정해 활용하는 부분이었다. 지금까지 스크럼을 기본 개발 프로세스로 사용하면서 활용한 차트는 Burndown 차트뿐이었다. Burndown 차트를 활용할 때의 단점은 프로젝트가 지연되고 있을 때 어느 조직이 Bottleneck인지를 측정하기 힘들다는 것이다. 따라서 David Anderson은 Lead Time을 측정해서 활용하는 방법을 제안했다.
Lead Time이란 하나의 사용자 스토리를 시작해 완료할 때까지의 시간을 의미한다. 하나의 사용자 스토리가 Started, Designed, Coded, Complete 단계를 거쳐 완료할 때 각 단계별 사용자 스토리의 누적 수를 구해나가는 방식이다.
위 그림은 일반적으로 진행되는 프로젝트의 모습을 보여주고 있다. Complete에 해당하는 Feature수가 단계형을 가지면서 지속적으로 증가하고 있다. 가로축의 시간 또한 대략적으로 1주 정도의 Lead Time 보여주고 있다. 하지만 Lead Time이 길 때의 모습을 보면 다음과 같다.
위 그림의 Lead Time은 한번의 사이클이 3달동안 지속되는 것을 볼 수 있다. 위 그림에서 Lead Time이 길어지는 가장 큰 원인은 어디에 있을까? 위 그림에서 Lead Time이 가장 긴 구간을 분석해보면 Coded 상태에서 상당히 오랜 시간을 대기하고 있는 것을 확인할 수 있다. 이는 개발기간이 길거나 QA의 테스트 기간이 길다는 것을 확인할 수 있다. 현재 Complete 상태로 바뀌는 Feature수가 갑자기 증가하는 것으로 보아 개발은 완료되었으나 QA를 한번에 모아서 진행한 것으로 파악할 수 있다. Lead Time을 이용할 경우 현재 프로세스 상의 병목 지점을 찾는데 유용하게 사용할 수 있다. 기존의 Burntown Chart도 유용하게 사용할 수 있으나 Burntown Chart가 가지는 한계점을 WIP와 Lead Time을 활용하여 보완하는 것이 가능할 것으로 판단된다.
두번째로 눈여겨 볼 부분은 각 Iteration별로 일정을 산정하는 부분이었다. 지금까지 각 Iteration별 일정을 산정할 때 큰 고민없이 산정했는데 상당히 구체적인 방법으로 일정을 계획하고 산정하는 것을 알 수 있었다.
위 그림에서 보는 바와 같이 각 Iteration(또는 Sprint)별로 Iteration을 초기 세팅하는 비용이 발생하며, Iteration을 완료한 후 회고나 소스 코드 리뷰와 같은 Cleanup 작업까지 일정 산정에 잡아서 처리한다. 이와 같은 비용을 Transaction Cost와 Coordination Cost로 분리하여 실습을 진행했다. 실습을 통하여 분석한 각각의 항목은 다음과 같다.
# Transaction Cost
- 각 Iteration 초기 Planning
- 회고
- 소스 코드 리뷰
- 데모준비 및 데모
- Branch 관리 및 소스 통합
# Coordination Cost
- 일일 Standup 회의(매일 15분)
이번 Tutorial에 참석한 많은 개발자 중에 Scrum을 사용하고 있는 곳이 많아서 Transaction Cost와 Coordination Cost가 그리 높지 않았다. 일반적으로 애자일 프로세스에서 추천하는 Transaction Cost + Coordination Cost는 전체 프로젝트 비용의 20% 내외라고 한다. 그러나 국내의 많은 프로젝트는 잦은 회의와 잡다한 업무로 인해서 30~40%가 넘어가는 경우도 많을 것으로 생각한다. 프로젝트를 효율화하기 위한 Lean의 방안이 Transaction Cost와 Coordination Cost를 제거하거나 줄이는 것이라고 한다. 이 비용을 줄이고 가치를 만드는 업무에 더 많은 시간을 투자하자는 것이다. Lean의 관점에서 본 Iteration Lifecycle을 보면 다음과 같다.
지난번에 프로젝트를 진행할 때 고민했던 부분이 각 Iteration별로 발생하는 버그를 어떻게 처리할 것인가였다. 그런데 이번 Tutorial에서는 일정 계획을 수립할 때 버그 처리, 요구사항 변경 같은 부분도 일정에 포함시키도록 가이드하고 있다.
처음에 각 Iteration별로 일정을 수립하는 실습을 진행했다가 위 그림에서 볼 수 있는 프로젝트 초반에 예측하지 못한 작업까지 포함하여 일정을 산정하는 부분에 대한 실습을 진행했다.
이번 Tutorial을 통하여 Agile Management의 모든 부분을 이해하고 파악하기는 힘들었다. 하지만 프로젝트 초기에 일정을 수립하고 지속적으로 관심을 가져야 한다는 것에 대해서는 공감할 수 있었다. 지속적인 관심이 없다면 언제든지 쉽게 무너질 수 있는 것이 프로젝트 관리라는 것을..
또한 미국에서는 각 Iteration별로 우선 순위에 따라 기능을 구현하고 QA까지 진행하는 사례가 예상보다 많은 것으로 보였다. 아마도 개발 단계가 국내의 디자이너, HTML 코딩, 서버측 개발과 같은 형태로 세분화되어 있지 않기 때문에 가능한 일이라고 생각한다. 이와 같이 우선 순위에 따라 기능을 구현하면 QA를 진행하는 것이 가능하다. 하지만 국내의 경우 UI가 없는 상태로 기능이 개발되기 때문에 프로젝트 초반 Iteration에서 QA를 진행해도 무의미한 경우가 많아 포기하는 경우가 종종 있다. 내가 지난번 진행했던 프로젝트가 그러했으며, 현재 진행하는 프로젝트 또한 그렇다. 아마도 조직적인 변화가 없는 상태에서 무리하게 Iteration 단위로 QA를 진행할 경우 리소스만 낭비했다는 비난을 받을 수도 있을 것으로 생각한다.
Tutorial에 참석했던 한 개발자의 말에 의하면 프로젝트에 참여하는 개발자는 30명이고, QA는 20명이란다. 이러니 비교가 될 수 있을까? 현재 N사에서는 5~10당 한명의 QA가 지원하는 상황이고, 국내 많은 프로젝트에서는 아예 QA가 없는 경우도 대부분인 상황에서 제대로 된 테스트를 하기란 어쩌면 힘든 일인지도 모르겠다. 특히 테스트 자동화까지 고려하기에는 턱없이 부족한 인력 구조이다.
이 Tutorial에서 기억에 남는 또 한부분은 각 Feature를 4가지 유형으로 분류한 후 각각의 유형에 따른 요구사항 변경 가능성을 파악하는 부분이다. 그리고 요구사항 변경 가능성이 적은 Feature에 우선 순위를 두어서 개발하는 형태를 제안하고 있다.
지금까지 정리한 내용은 David Anderson이 몇년째 비슷한 내용으로 강의를 하고 있기 때문에 이미 많은 개발자가 알고 있을 것으로 생각한다. 하지만 나는 모르고 있던 부분을 이번 기회를 통하여 새롭게 알게되어 다음에 진행하는 프로젝트에서는 필요한 부분을 참고해볼 생각이다. 아직까지 강의 자료를 제공해주지 않아서 이 포스팅에 사용한 모든 자료는 http://www.agilemanagement.net/ 에서 구했다. 역시 예상한대로 비슷한 내용의 PDF가 많았다. 이번 자료도 조만간 공개될 것으로 생각한다.
이번 Tutorial에서 아쉬운 점은 언어의 한계 때문에 궁금한 부분이 많았는데 질문을 하지 못했다는 것과 깊이 있게 이해 못한 부분이 몇군데 된다는 것이다. 아쉽지만 이 정도의 경험에 가치를 부여하고 돌아가서 적용하면서 노하우를 쌓아갈 수 밖에 없을 것으로 생각한다.
오늘 컨퍼런스의 첫째날을 보내면서 느끼는 것이 최근 DSL에 대한 관심도가 높아지고 있다는 것이다. 국내에서는 거의 이야기되지 않는 내용인데 이곳에서는 벌써 활용사례부터 아키텍처까지 이야기하고 있으니 참 빠르다는 생각이 든다. 이 내용은 내일 정리해보도록 하겠다.
강의 문서가 있는 상태에서 블로깅을 하는 것이 좋을 것으로 생각되어 하루나 이틀씩 늦게 포스팅이 가능할 것으로 생각한다. 강의 문서를 하루 늦게 전달하는 바람에.. 사진과 말빨로 때우기는 힘들거 같다.
The Zen of Agile Management Tutorial의 처음은 팀내의 신뢰가 바탕이 되어야 한다는 내용으로 하루 강의가 시작되었다. 신뢰가 바탕이 되지 않는 상태에서는 프로젝트를 진행하기 힘든 것은 어느 곳이나 기본적으로 깔려 있어야 될 것으로 생각한다.
David Anderson이 프로젝트 성공을 위한 요소는 다음과 같다.
위 구성 요소 중에서 가장 인상 깊게 남은 부분은 Work-in-Process(이하 WIP)를 줄이기 위하여 Lead Time을 측정해 활용하는 부분이었다. 지금까지 스크럼을 기본 개발 프로세스로 사용하면서 활용한 차트는 Burndown 차트뿐이었다. Burndown 차트를 활용할 때의 단점은 프로젝트가 지연되고 있을 때 어느 조직이 Bottleneck인지를 측정하기 힘들다는 것이다. 따라서 David Anderson은 Lead Time을 측정해서 활용하는 방법을 제안했다.
Lead Time이란 하나의 사용자 스토리를 시작해 완료할 때까지의 시간을 의미한다. 하나의 사용자 스토리가 Started, Designed, Coded, Complete 단계를 거쳐 완료할 때 각 단계별 사용자 스토리의 누적 수를 구해나가는 방식이다.
위 그림은 일반적으로 진행되는 프로젝트의 모습을 보여주고 있다. Complete에 해당하는 Feature수가 단계형을 가지면서 지속적으로 증가하고 있다. 가로축의 시간 또한 대략적으로 1주 정도의 Lead Time 보여주고 있다. 하지만 Lead Time이 길 때의 모습을 보면 다음과 같다.
위 그림의 Lead Time은 한번의 사이클이 3달동안 지속되는 것을 볼 수 있다. 위 그림에서 Lead Time이 길어지는 가장 큰 원인은 어디에 있을까? 위 그림에서 Lead Time이 가장 긴 구간을 분석해보면 Coded 상태에서 상당히 오랜 시간을 대기하고 있는 것을 확인할 수 있다. 이는 개발기간이 길거나 QA의 테스트 기간이 길다는 것을 확인할 수 있다. 현재 Complete 상태로 바뀌는 Feature수가 갑자기 증가하는 것으로 보아 개발은 완료되었으나 QA를 한번에 모아서 진행한 것으로 파악할 수 있다. Lead Time을 이용할 경우 현재 프로세스 상의 병목 지점을 찾는데 유용하게 사용할 수 있다. 기존의 Burntown Chart도 유용하게 사용할 수 있으나 Burntown Chart가 가지는 한계점을 WIP와 Lead Time을 활용하여 보완하는 것이 가능할 것으로 판단된다.
두번째로 눈여겨 볼 부분은 각 Iteration별로 일정을 산정하는 부분이었다. 지금까지 각 Iteration별 일정을 산정할 때 큰 고민없이 산정했는데 상당히 구체적인 방법으로 일정을 계획하고 산정하는 것을 알 수 있었다.
위 그림에서 보는 바와 같이 각 Iteration(또는 Sprint)별로 Iteration을 초기 세팅하는 비용이 발생하며, Iteration을 완료한 후 회고나 소스 코드 리뷰와 같은 Cleanup 작업까지 일정 산정에 잡아서 처리한다. 이와 같은 비용을 Transaction Cost와 Coordination Cost로 분리하여 실습을 진행했다. 실습을 통하여 분석한 각각의 항목은 다음과 같다.
# Transaction Cost
- 각 Iteration 초기 Planning
- 회고
- 소스 코드 리뷰
- 데모준비 및 데모
- Branch 관리 및 소스 통합
# Coordination Cost
- 일일 Standup 회의(매일 15분)
이번 Tutorial에 참석한 많은 개발자 중에 Scrum을 사용하고 있는 곳이 많아서 Transaction Cost와 Coordination Cost가 그리 높지 않았다. 일반적으로 애자일 프로세스에서 추천하는 Transaction Cost + Coordination Cost는 전체 프로젝트 비용의 20% 내외라고 한다. 그러나 국내의 많은 프로젝트는 잦은 회의와 잡다한 업무로 인해서 30~40%가 넘어가는 경우도 많을 것으로 생각한다. 프로젝트를 효율화하기 위한 Lean의 방안이 Transaction Cost와 Coordination Cost를 제거하거나 줄이는 것이라고 한다. 이 비용을 줄이고 가치를 만드는 업무에 더 많은 시간을 투자하자는 것이다. Lean의 관점에서 본 Iteration Lifecycle을 보면 다음과 같다.
지난번에 프로젝트를 진행할 때 고민했던 부분이 각 Iteration별로 발생하는 버그를 어떻게 처리할 것인가였다. 그런데 이번 Tutorial에서는 일정 계획을 수립할 때 버그 처리, 요구사항 변경 같은 부분도 일정에 포함시키도록 가이드하고 있다.
처음에 각 Iteration별로 일정을 수립하는 실습을 진행했다가 위 그림에서 볼 수 있는 프로젝트 초반에 예측하지 못한 작업까지 포함하여 일정을 산정하는 부분에 대한 실습을 진행했다.
이번 Tutorial을 통하여 Agile Management의 모든 부분을 이해하고 파악하기는 힘들었다. 하지만 프로젝트 초기에 일정을 수립하고 지속적으로 관심을 가져야 한다는 것에 대해서는 공감할 수 있었다. 지속적인 관심이 없다면 언제든지 쉽게 무너질 수 있는 것이 프로젝트 관리라는 것을..
또한 미국에서는 각 Iteration별로 우선 순위에 따라 기능을 구현하고 QA까지 진행하는 사례가 예상보다 많은 것으로 보였다. 아마도 개발 단계가 국내의 디자이너, HTML 코딩, 서버측 개발과 같은 형태로 세분화되어 있지 않기 때문에 가능한 일이라고 생각한다. 이와 같이 우선 순위에 따라 기능을 구현하면 QA를 진행하는 것이 가능하다. 하지만 국내의 경우 UI가 없는 상태로 기능이 개발되기 때문에 프로젝트 초반 Iteration에서 QA를 진행해도 무의미한 경우가 많아 포기하는 경우가 종종 있다. 내가 지난번 진행했던 프로젝트가 그러했으며, 현재 진행하는 프로젝트 또한 그렇다. 아마도 조직적인 변화가 없는 상태에서 무리하게 Iteration 단위로 QA를 진행할 경우 리소스만 낭비했다는 비난을 받을 수도 있을 것으로 생각한다.
Tutorial에 참석했던 한 개발자의 말에 의하면 프로젝트에 참여하는 개발자는 30명이고, QA는 20명이란다. 이러니 비교가 될 수 있을까? 현재 N사에서는 5~10당 한명의 QA가 지원하는 상황이고, 국내 많은 프로젝트에서는 아예 QA가 없는 경우도 대부분인 상황에서 제대로 된 테스트를 하기란 어쩌면 힘든 일인지도 모르겠다. 특히 테스트 자동화까지 고려하기에는 턱없이 부족한 인력 구조이다.
이 Tutorial에서 기억에 남는 또 한부분은 각 Feature를 4가지 유형으로 분류한 후 각각의 유형에 따른 요구사항 변경 가능성을 파악하는 부분이다. 그리고 요구사항 변경 가능성이 적은 Feature에 우선 순위를 두어서 개발하는 형태를 제안하고 있다.
지금까지 정리한 내용은 David Anderson이 몇년째 비슷한 내용으로 강의를 하고 있기 때문에 이미 많은 개발자가 알고 있을 것으로 생각한다. 하지만 나는 모르고 있던 부분을 이번 기회를 통하여 새롭게 알게되어 다음에 진행하는 프로젝트에서는 필요한 부분을 참고해볼 생각이다. 아직까지 강의 자료를 제공해주지 않아서 이 포스팅에 사용한 모든 자료는 http://www.agilemanagement.net/ 에서 구했다. 역시 예상한대로 비슷한 내용의 PDF가 많았다. 이번 자료도 조만간 공개될 것으로 생각한다.
이번 Tutorial에서 아쉬운 점은 언어의 한계 때문에 궁금한 부분이 많았는데 질문을 하지 못했다는 것과 깊이 있게 이해 못한 부분이 몇군데 된다는 것이다. 아쉽지만 이 정도의 경험에 가치를 부여하고 돌아가서 적용하면서 노하우를 쌓아갈 수 밖에 없을 것으로 생각한다.
이올린에 북마크하기
