소프트웨어 장인정신 그리고 애자일 방법론

Intro

얼마전 회사에서 새로운 프로젝트를 시작했다. 지금까지 하던 프로젝트 중 가장 큰 프로젝트였다. 프로젝트 리더는 이번 프로젝트는 기존의 폭포수 방식의 개발방법이 아니라 애자일 방법으로 진행하고 싶다고 했다. 나는 그동안 애자일 방법론에 대해 공부하고 있었다. '익스트림 프로그래밍' '린 스타트업' '소프트웨어 장인정신' 그리고 각종 블로그와 서적을 보면서 애자일 방법론이 왜 필요한지? 그리고 어떤 장점이 있는지 공부했다.

그런데 회사에서 진행하는 애자일은 내가 공부한 애자일 방법론이 아니었다. 일정은 터무니 없이 부족했고, 스프린트(Sprint) 진행을 어떤식으로 할 것인지도 정하지도 않은채 평소와 같은 폭포수 방법과 같은 일정으로 무늬만 스크럼(Scrum) 프로젝트를 시작했다.

스프린트 #1이 끝나갈 무렵 우리의 프로젝트는 아래와 같은 큰 문제가 있었다.

• 동기부여가 되지 않음
• 수많은 PL과 각 모듈별 책임자
• 터무니 없이 짧은 개발일정
• 대부분의 정보가 공유되지 않음
• 자율성과 다양성이 없음

이 문제들이 왜 큰 문제인지 애자일 방법론에 대해 아래에서 자세히 다루도록 하겠다.

아직 프로젝트는 끝나지 않았다. 지금이라도 왜 애자일을 하는지 고민해볼 필요가 있다. 애자일을 하는 이유는 기존 폭포수 개발방식의 단점인 1. 납기일 전 철야 2. 철야에도 불구하고 납기일 지연 3. 지연에 따른 스트레스로 개발자 이탈 4. 결국 납기된 솔루션이 고객의 요구를 충족시키지 못하는 부작용을 해소하기 위해 나타난 개발 방법론이다. 애자일에 대한 오해중 가장 큰 것은 애자일의 전환만으로 큰 장점이 생길거라고 생각하는 것이다. 팀 전체가 애자일의 가치와 원칙을 공유하고 실천하지 않는다면 오히려 폭포수 방법론보다 더 큰 부작용만 가져올 수 있다.

얼마전 가까운 스타트업을 다니는 친구와 애자일방법론을 토론하던 중 이런 결론을 내렸다.

"애자일은 방법론에 대한 이해도 중요하지만, 개개인이 최고의 능력을 갖고 있어야 한다."

Agile

그동안 애자일에 대해 모은 자료를 정리하려고 한다.

내가 내린 애자일 방법론의 정의는 "지속적인 개선과 변화관리를 통해 고객에게 더 나은 제품을 제공하는 것" 이다.

결국 소프트웨어는 고객과 소통하면서 끊임없이 개선되어야 한다.

[ 애자일 개발 ]

애자일 개발방법의 종류

1. 익스트림 프로그래밍(Extreme Programming) : 비즈니스상의 요구가 시시각각 변할때 적용하는 방법론으로 고객이 원하는 양질의 소프트웨어를 빠른 시간내에 전달하는 것이다. 특징은 TDD(Test Driven Development)를 기반으로 프로젝트를 완성시키는 것이다.
   
   
2. 스크럼(Scrum) : 애자일 방법론중 가장 포괄적으로 사용되며, 새로운 프로젝트, 유지보수, 프로그램 등 어디서나 사용할 수 있다. 기능/개선점에 우선순위를 부여한뒤 Sprint 개발주기(1~4주)마다 기능을 완성하고 테스트 및 방법론에 대한 리뷰를 갖고 이를 반복하는 것이다. 여기서 중요한 점은 Sprint 기간중에는 개발 목표와 기간이 변경되어서는 안된다는 것이다.
   
   
3. 크리스털 패밀리(Crystal Family) : 사용자들의 요구사항이 담긴 표식을 개발자가 완성하면 다음단계로 넘어가는것과 같이 소프트웨어 개발이 "협력적 게임"이라는 것에서 출발한다. 프로젝트의 규모에 따라 Clear, Yellow, Orange, Red로 나뉜다. 특징은 사용자를 개발팀에 포함시키며, 방법론을 끊임없이 개선해 나가는 워크숍을 개최한다.
   
   
4. FDD(Feature Driven Development) : 상품이나 서비스 단위가 아닌 신규기능 단위로 개발을 진행하는 방법론이다. 2주마다 반복개발을 시도하며 UML을 이용한 설계 방법과도 밀접한 관련을 가진다.

이렇게 4가지 개발방법론 중 어떤 방법론으로 프로젝트를 진행해야 하나 고민하는 분들이 많을 것 같다. 답은 일단 정해서 시작하라는 것이다. 애자일은 제품에 대해서만 문제를 찾고 지속적으로 개선하는게 아니라 개발 과정을 되돌아보고 앞으로 더 나은 방법을 찾기 위해 끊임없이 고민하는 것이다. 

이중 스크럼에 대해 더 자세히 살펴보면 먼저 그림은 아래와 같다.

자유로울것 같지만 스크럼을 지키기 위한 나름의 규칙이 있다.

1. 역할은 Product Owner, Scrum Master, Team Member 3가지로 구분한다.
   * PO(Product Owner)가 제품 백로그를 정리해서 우선순위를 정해주고, Scrum Master는 PO가 독단적으로 목표를 결정하지 못하도록 팀원과 의견을 조율한다.
2. 팀원들 개개인은 목표의식이 뚜렷하고 동기부여가 되어있어야 한다.(PO가 아닌 팀원이 스프린트 목표를 정한다.)
3. 기능과 개선점에는 항상 우선순위가 존재해야 한다.
4. 개발 주기는 30일 정도로 조절하고 실제 동작하는 소프트웨어 결과를 제공해야 한다.(테스트도 완료되어야 함)
5. 정보의 양이 넘쳐야 한다.(모든 정보가 공유되고 열린마음의 소통이 필요하다.)

이중 하나라도 제대로 동작하지 않는다면 대부분의 스크럼은 실패하게 된다. 만약 하나의 팀에서 Web파트 모바일파트로 나누어 개발을 진행할때, Web파트의 진행을 모바일 파트가 따라가지 못해서 다음 스크럼을 못할 경우도 생기기 때문이다.(스크럼 마스터가 팀원간의 원활한 커뮤니케이션으로 역할분담과 스프린트 백로그를 적절히 조정해야 한다.)

마지막으로 애자일 선언문이다.(소프트웨어 장인정신은 이보다 한단계 업그레이드 된다.)

애자일 선언문(Agile Manifesto)

• 절차와 도구를 넘어선 개성과 화합을
  Individuals and interactions over processes and tools
• 종합적인 문서화 보다 제대로 동작하는 소프트웨어를
  Working software over comprehensive documentation
• 계약 협상보다 고객과의 협력을
  Customer collaboration over contract negotiation
• 세워진 계획을 따르기 보다 변화에 대한 대응을
  Responding to change over following a plan

왼쪽에 있는 것들도 가치가 있지만 오른쪽에 있는 것을 더 높은 가치로 둔다.

소프트웨어 장인정신

최근 소프트웨어 방법론의 책중에 가장 감명깊게 본 책이 소프트웨어 장인정신(저자 : 산드로 마쿠소)이다. 책을 다 보고나서 이전 직장의 PM이자 학교 선배가 했던 말이 생각났다.

"우리는 다 프로야, 행동한 일에는 책임을 져야해. 그리고 아무도 가르쳐주지 않아 프로는 스스로 성장하는거야"

소프트웨어 장인정신은 곧 개개인이 프로패셔널(professional) 해진다는 것이다. 책에서는 먼저 소프트웨어 장인정신 선언문이 나온다.

소프트웨어 장인정신 선언문(Software Craftsmanship Manifesto)

• 동작하는 소프트웨어뿐만아니라, 정교하고 솜씨 있게 만들어진 작품을
  Not only working software, but also well-crafted software
• 변화에 대응하는 것 뿐만 아니라, 계속해서 가치를 더하는 것을
  Not only responding to change, but also steadily adding value
• 개별적으로 협력하는 것 뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을
  Not only individuals and interactions, but also a community of professionals
• 고객과 협력하는 것 뿐만 아니라, 생산적인 동반자 관계를
  Not only customer collaboration, but also productive partnerships

왼쪽의 항목들을 추구하는 과정에서, 오른쪽 항목들이 꼭 필요함을 의미한다.

평소에 개발자는 단순히 개발만하면 되고 나는 개발이 즐거워서 개발자로 첫 취업을 했다. 그런데 프로젝트를 진행하다보면 고객과 소통해야 하고, 테스트도 해야하며, 개발할 내용에 대해 정리도 하며 심지어는 리더와 더나은 프로젝트 방법에 대해 의논도 해야 했다. 개발자의 영억은 단순 개발이 아님을 이 책에서는 아주 자세히 나와있다. 아래는 내용의 일부를 발췌했다.

좋은 프로그래밍 관례나 기술이 서로 다른 종류의 시스템이나 환경에 공통으로 적용될 수 있지만, 코딩은 개발자가 해야 하는 많은 일들 중 하나일 뿐이다. 코딩을 잘 하거나 특정 언어나 프레임워크에 매우 익숙하다고 해서 고참 개발자가 되는 것은 아니다. 이제 개발자들은 다음과 같은 여러가지 일을 할 수 있어야 한다.

• 고객과 대화하기
• 테스트/배포 자동화하기
• 전체 비즈니스에 영향을 미칠 기술 선정하기
• 지리적으로 분산된 팀들과 협업하기
• 고객을 도와 필요한 작업을 정의하기
• 우선순위 선정하기
• 진척 상황 보고하기
• 변경사항과 기대일정 관리하기
• 잠재 고객 및 파트너에게 제품 소개하기
• 사전 영업 활동 지원하기
• 개발 일정과 비용 산출하기
• 채용 면접하기
• 아키텍처 설계하기
• 비기능적 요구사항과 계약조건
• 사업 목표 이해하기
• 주어진 여건에서 최적의 결정하기
• 새로운 기술 주시하기
• 더 나은 업무 방식 찾기
• 고객에게 가치 있는 상품이 전달되고 있는지 고민하기

 - '소프트웨어 장인', p32-33 '새로운 현실'

주의깊게 본 것은 '소프트웨어 장인의 태도' 부분이었다. 이야기의 시작은 '내 커리어의 주인은 누구인가'로 시작된다. 또한 끊임없는 자기계발을 위해 1. 독서, 많은 독서 2. 블로그 3. 기술 웹사이트 의 중요성을 강조하며 '팔로우할 리더찾기'와 개발 훈련으로 1. 카타 2. 펫 프로젝트 3. 오픈 소스 4. 페어프로그래밍을 강조한다.

그중 나는 펫(Pet)프로젝트의 중요성에 대해 가장 공감했다. 회사에서 주어진 환경과 오래된 시스템을 개선하는 업무가 주어졌다면 펫프로젝트에서는 과감하게 신기술을 사용하고 최신 UI를 이용해 자신만의 서비스를 만들어 볼 수 있다.

사실 나도 구글 플레이스토어에 처음 출시한 서비스가 첫직장에서 6개월간 펫프로젝트로 진행한 프로젝트이다. 안드로이드앱이 거의 없던 시절 아이폰에서 목표를 관리하는 앱을 벤치마킹해서 안드로이드에 출시했다.

업데이트를 2년동안 못하고 있지만, 이 펫 프로젝트의 SVN 히스토리는 최근에도 Commit로그가 있을 만큼 시간이 날때마다 조금씩 펫프로젝트를 진행하고 있다.(조만간 업데이트를 꼭 할 것이다.!...)

펫프로젝트를 위해서는 아래와 같이 진행하는 것이 좋다.

1. 아이템 선정 : 본인이 가장 하고싶었던 아이디어중 규모가 작아서 완성하기 쉬운것으로 선택한다.
2. 기간 설정 : 기간은 최대한 길게 작은 기능이라도 제대로 만들어야 한다.
3. 기반 기술 선정 : 최신기술, 사용해보고 싶은 언어로 시작한다.
4. 개발 : 끈기있게 개발해야 한다. 회사일을 하다보면 펫프로젝트는 신경쓰기 어렵다.
5. 상용화 : 사업성이 있다면 일단 출시해본다. 안되도 그만이다. 겁먹을 필요가 없다.

주의해야 할 점은 대부분의 펫프로젝트가 4. 상용화가 안된다는 점이다. 필자도 몇개의 펫프로젝트가 개발이 중단되고 소스코드 저장소에 올라가 있다. 이유는 개발의 90%는 쉽지만 나머지 완성시키는 10%가 많은 시간이 걸리고 대부분 노가다 작업이 병행되기 때문이다.

그러나 상용화를 하고 하지 않고는 많은 차이가 난다. 상용화를 하게되면 사용자의 목소리를 들어보고 서비스를 지속적으로 개선할 수 있으며, 본인의 아이디어가 실제로 효과가 있는지 확인할 수 있기 때문이다.

펫프로젝트는 애완동물과 같다 끊임없이 다듬고 보살펴주어야 한다.

마치며..

같이 펫프로젝트 하실분 있으면 좋겠네요^^ 지금은 기획자로의 일이 많지만 개발의 끊을 절대 놓지 않고 있습니다!