Agile 방법론

최근 Seek.com등의 소프트웨어 개발 구인 광고를 보면 Agile 개발 방법론에 대한 문구가 자주 등장한다. 그러면 이러한 Agile 방법론이란 무엇인가를 한 블로그를 통해 엿보도록 한다.

출처: 네이버블로그
 Agile(애자일) 방법론을 실제로 경험해보니(http://vicfaith.blog.me/150092000497 )

Agile 방법론을 들어본지는 꽤 오래된것 같지만 실제로 이 방법론을 적용하는 회사는 못본것 같다.

요즘은 Agile 아래 Scrum, XP, Rup, Crystal 등등 세부 방법론에 대한 관심이 커지는 것 같다.

현재 회사에서 SW 개발 방법론으로 Agile을 채택하고 이 분야에서 유명한 다국적 컨설팅 회사인 T사와 계약을 해서 많은 프로젝트를 진행중이다. T사의 개발자, QA 인력, PM 까지 와서 같이 작업을 하면서 자연스럽게 애자일 방법론을 경험하게 되었다.

모든 개발은 방법론 정석대로 진행을 한다.

User stories, scores , velocity estimation, iterations, TDD (테스트 주도 개발) 등등을 필수적으로 진행한다.

아침마다 어제 한일, 문제점 및 오늘 할일을 브리핑하는 daily stand-up 미팅, story board 를 가지고 작업 진행 현황을 파악하는 wall-meeting, 반복 구간마다 retrospect 미팅, showcase 미팅 등등...

개발자들이 큰 회의실에 모여서 같이 작업하기 때문에 기술적인 논의나 Q&A 은 즉시로 이루어지고 반영된다.
애자일의 철학은 한마디로 Communication(의사 소통)에 있다. 비단 개발자들뿐아니라 관련된 비지니스, 마케팅, QA등 모든 Stakeholder들이 더 자주 적극적으로 의사 소통하는 것이다.
개발자 관점에서 가장 두드러진 특징은 두사람이 한 PC를 보고 작업하는 짝(Pair) 프로그래밍이다. 같이 키보드를 돌아가며 개발하거나 한사람이 실제 코드를 다른 사람은 테스트 코드를 작성하는 식이다.
처음엔 혼자하는게 스트레스도 없고 빠르겠는데 하며 같이 작업하는것이 익숙치 않았다.
하지만 몇달 지나지 않아 짝 프로그래밍에 여러 가지 장점이 있음을 알게되었고 지금은 혼자 개발하는 것이 오히려 외롭기까지하다.


몇가지 장점을 들어보자.

1. 개인적인 기술 수준이 높아지게 된다. 잘하는 경험많은 사람하고 일하게 되면 자신의 부족함을 많이 느끼게 된다. 혼자 개발할때는 혼자 끙끙대든, 밤을 세우든 어쨌든 코드를 작성하고 문제를 해결한다고 하지만 같은 문제를 더 빠르고 신뢰성 높은 코드로 해결하는 친구들도 많다는 사실을 경험하고 인정하기는 어렵다.

같이 페어링을하는 인도 친구들은 개발자로 7년차였으나 설계를 머리속으로 하면서 하루에 엄청난 코드를 버그도 거의 없이 아름다운 코드를 만들어 내곤하여 나를 놀라게 하였다.

막히는 문제는 약간의 고민과 구글링으로 간단하게 해결하는데 내공이 장난이 아니었다. 이런 친구들과의 공유와 도전을 통해 자신도 성장하게 된다.

2. 스타 개발자가 아닌 팀전체의 기술 수준이 높아지게 된다.

개발자들이 혼자만 알고있는 툴, 팁, 개발 노하우를 서로 자연스럽게 배우게 된다. 보통 시니어 개발자와 주니어 개발자가 짝을 이룬다. 주니어 개발자는 자연스럽게 시니어 개발자의 노하우와 문제 해결능력을 배울 수 있다.

신입사원들은 사실 제대로 된 업무상의 고급 기술을 배우기가 쉽지 않다. 외부 교육을 받거나 스스로 독학으로 내공을 키워갈 수 밖에 없지만 짝프로그래밍에서는 선배들의 노하우가 그대로 전수된다.

3. 시간 효율과 생산성이 높아진다. 혼자 일하는 척하면서 말만 하는 사람이 없어진다. 모두 다 두사람씩 페어링을 하므로 업무 시간에는 상당한 집중과 업무 강도가 요구된다. 인터넷을 같이 보며 서핑할 수는 없지 않은가? 혼자서 집에가서 작업할 수도 없으므로 늘 업무 시간에 계획된 작업을 완료해야 한다. 따라서 업무 강도가 높고 작업에 대한 시간 계획을 효율적으로 세워야 한다. 사실 애자일에서 야근은 프로세스 실패로 간주하고 프로젝트 계획을 수정해야 한다.

부수적으로 한사람이 결근을 해도 다음 사람과 연속적으로 작업이 가능하다.

4. 팀웍이 자연스럽게 향상된다.

스토리 단위로 페어링을 바꾸기 때문에 다른 사람과 작업에 익숙해져야 한다.

팀 단위로 움직이므로 다른 사람이 해결 못하는 문제를 흑기사처럼 해결해주고 으쓱대는 모습은 보기 어렵다. 대부분 자연스럽게 모르는 것은 질문하고 토의한다.

5. SW 품질이 좋아진다.

서로 개발하면서 혼자는 생각하지 못했던 이슈나 잠정적인 문제들을 옆사람이 찾아주기 때문에 버그도 줄어든다.

본인의 방법의 문제점을 누군가가 지적해주면 돌아갈 길도 쉽게 가는 경험을 종종 하게된다.

또한 스토리마다 기본적인 테스트 코드 작성및 인수 테스트(Acceptance Test)를 완료해야 하나의 Iteration(반복 구간)이 완료가 된다.

그러나 이상적이 되기 위해서는 필요한 점이 있다. 이렇게 잘 되려면 먼저 팀문화가 되어야한다. 서로 고과로 경쟁하는 시스템에서는 쉽지 않은 것이 사실이다. 또한 페어링하는 사람들의 자질과 열린 마음이 필요하다. 자신만의 방법이나 코드만을 우기면 서로 페어를 회피하게된다. 때론 자부심과 더불어 잘못도 인정하고 상대의 의견을 받아들일 수 있는 열린 마음이 필요하다.

그래서 개발자의 인성이나 태도도 면접시 중요하게 본다.

Agile에 관한 참고 서적들은 아래와 같다.
- Agile Software Development: Principles, Patterns, and Practices
- Agile Java
- Agile Estimating and Planning - Prentice Hall