Introduction

안녕하세요.

오픈소스컨설팅 솔루션 설계팀 김세연입니다.

저희는 기존 시스템을 오픈소스로 전환, 사용 지원하고 있습니다. 더 많은 내용은 www.osci.kr 에서 확인해 주세요.

고객에게 가치를 전달하는 IT 프로젝트는 무엇일까요? 고객의 요구사항을 기간 안에 구현하는 것일까요?


위 그림은 IT 프로젝트의 초기 요구사항의 불확실성, 복잡성에 대해서 각 담당자가 이해한 결과물을 보여줍니다. 사실 고객은 나무에서 타이어 그네를 타고 싶었습니다. 프로젝트가 끝날 때쯤에 알았다면 이미 늦었습니다.

프로젝트 기간, 비용, 품질 3박자를 충족시키고 시장(고객)의 반응이 좋을 때 성공했다고 생각이 듭니다. 여기서 한 가지 더 개발사도 만족할 때 최고의 성공이라고 생각합니다.

저는 프로젝트 성공에 대한 관점을 3가지로 봅니다.

  • 납기일에 가치있는 제품을 고객에게 전달
  • 시장또는 고객의 좋은 반응
  • 고객/수행사의 만족

폭포수 모델(Waterfall model)의 문제점

참조 1. https://ko.wikipedia.org/wiki /폭포수 _모델

폭포수 모델은 분석, 설계, 구현, 테스트를 순차적으로 진행 됩니다. 이 형태는 중간에 요구사항만 변경하지 않는다면 단계가 명확해서 관리가 쉽습니다.

하지만 초반에 요구사항을 모두 분석하기 어렵고, 고객은 실제 제품을 프로젝트 후반부에 가서야 확인할 수 있기 때문에 나중에 요구사항이 많이 변경되는 단점이 있습니다.

후반부에 납기 일정을 맞추기 위해 무리한 야근과 일정으로 품질은 낮아지고 결과가 안 좋아 지는 경우가 많습니다.

문제점을 정리하면 아래와 같습니다.

  • 프로젝트 초기 요구사항은 불확실하다.
  • 요구사항의 변경이 빈번하게 일어난다.
  • QA단계에서 많은 수정사항이 일어난다.
  • 잦은 초과근무가 발생한다.
  • 품질은 낮아지고 유지보수 비용이 늘어난다.

그러면 어떻게 해야 할까요? 조금씩 개발해서 자주 고객에게 보여주면됩니다.

개발 대상, 범위, 시간은 팀, 고객 모두와 조율 되야합니다. PM 또는 스크럼 마스터의 할 일이 여기있습니다.

애자일(Agile) 무엇인가?

소프트웨어 역사는 100년도 안됩니다. 다른 학문에 비해 역사가 짧고 급변하고 있습니다.

90년대 후반까지의 소프트웨어 공학과 개발방법론은 장기간에 걸쳐 많은 사람들을 투입하고 충분한 비용을 투입하여 진행하는 다른 공학의 프로세스와 비슷한 맥락에서 진행되었습니다.

하지만 소프트웨어는 유동적이고 개방적고, 요구사항의 변경에 따른 작업량을 예측하기 힘들었습니다.

애자일은 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며

그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style 이라고 할 수 있습니다.

애자일 선언을 살펴보겠습니다.


우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.


고객과 수행사 모두 애자일 선언에 대한 이해가 없으면 애자일 방법론을 적용하기가 어렵습니다.

처음에는 위 선언문이 어색할지 몰라도 시간이 흐르고 애자일 프로젝트를 수행하다보면

다른 시각으로 보이고 이해가 될 때가 있습니다. 저도 천천히 이해하고 있습니다

애자일 적용 대상

1. 목표 달성을 위한 프로세스를 가지지 않고, 임기응변적인 소프트웨어 개발로 인해 혼란에 빠져있는 조직이다. 이러한 프로젝트 팀에게 있어 애자일 개발 프로세스는, 개선을 위한 좋은 힌트가 될 것이다. 애자일 개발 프로세스는 작고 쉽게 도입할 수 있으며, 그것에 들어가는 비용과 위험도 낮다.

2. 이미 전통적인 소프트웨어 프로세스를 도입하고 있지만, 제대로 동작하지 않는(또는 프로세스 실시를 위한 오버헤드가 너무 커서 오히려 업무에 부담을 주고 있는) 조직이다. 프로세스의 도입은 조직의 문화를 바꾼다. 효과가 크면 클수록 조직문화에 대한 영향은 커지고, 도가 지나치게 되면 고유의 문화를 파괴해 버리기도 한다. 그러나 조직에 있어서 애자일 개발 프로세스는 좋은 결과를 가져다 줄 것이다. 또한 CMMI SPICE 등의 인증을 얻으려고 하는 조직에서는 그들의 요구를 충족시킬 아이디어를 제공해 줄 수 있을 것이다.

참고. 위키

1번은 프로세스가 없고 2번은 전통적인 프로세스를 도입하고 있지만 제대로 동작하지 않는 조직입니다. 저는 1번, 2번 조직에서 작게 시작하는 방법을 제안 하겠습니다.

팀원에게 애자일 조금씩 주입하기

조직 문화, Micro Service Architecture(MSA), 애자일, Devops 많은 방법이 있습니다. 이 세트가 다 같이 가면 좋겠지만. 나비의 작은 날갯짓처럼 작은 변화 작은 팀부터 적응하시기를 제안합니다.

애자일 거부감이 있는 팀원이 있을 수 있습니다.

  • 내 일을 남에게 공유하기를 싫어함.
  • 지금 하고있는 일에 일이 더해진다고 느낌.

하지만 애자일 방법론을 잘 적용/적응하면 개발자들은 정시퇴근과 업무의 높은 만족도를 얻으면서 가치있는 소프트웨어를 얻을 수 있습니다.

애자일 선언 첫번째가 '개인과 상호작용에 가치 있게 여긴다'입니다. 그러기 위해서는 팀 커뮤니 케이션부터 개선하는 방법을 제안합니다.

팀 커뮤니케이션 개선하기

전통적인 커뮤니케이션 채널은 리더 중심의 의사소통이 이루어졌습니다. 한명의 리더의 채널의 지연이 생기면 팀 전체의 의사결정이 지연됩니다.

하지만, 자기 조직화된 팀에서는 360도로 소통을 합니다.

관리자의 지시가 아니라 팀원이 스스로 해야 할 일을 계획하고 상호 협력하여 업무를 수행하는 팀의 형태를 자기 조직화된 팀이라고 합니다.

우리는 이런 팀을 만들어야합니다. 경직된 조직은 리더와 소통합니다.

다른 개발자와는 잡담은 하지만 일에 있어스는 소통이 잘 이루어지지 않습니다.

다른 개발자의 일을 잘 모르기 때문에 도와주고 싶어도 못도와 줍니다. 안다고 해도 선뜻 도와주기 쉽지 않습니다.

애자일 방법론의 일일 스크럼 회의(Daily Scrum Meeting)을 제안합니다.

일일 스크럼 미팅은 4개의 구성요소로 이루어져 있습니다.

  • 어제 한 일
  • 오늘 할 일
  • 리스크 공유
  • 전체상황 공유

일(work)에 대해서 기록/트레킹 하는 도구가 있으면 많은 도움이 됩니다. 저는 Atlassian JIRA를 추천합니다. JIRA는 애자일 프로젝트를 관리하는데 최적화 되어있습니다.

물론 비즈니스 팀, 전통적인 프로세스, 결재 프로세스등 JIRA를 통해 많은 도구를 통합하면서 줄일 수 있습니다.

리스크 및 전체상황을 문서로 공유할 때는 Atlassian Confluence를 추천합니다. Confluence는 Content 중심의 Pages를 협업에 최적화 되어있습니다.

일일 스크럼 Step by Step

  • 주최자가 공유 순서를 정한다.
  • 한 사람당 발언 시간을 5분을 넘지 않는다.(절충 되어야한다)
  • 발언 중 끈지않고 끼어들지 않는다.
  • 발언자는 JIRA, Confluence 또는 다른 도구를 참고하여 어제 한 일, 오늘 할 일, 리스크를 공유한다.
  • 모든 참여자의 발언이 끝나면 전체 상황을 공유한다.
  • 오늘 할 일이 무엇이지 모른다면 팀 리더와 또는 스크럼 마스터와 충분한 업무 공유 및 소통을 한다.

처음부터 잘하는 사람, 팀은 없습니다. 시행착오를 격으면서 소수의 인원과 함께 적용하시기를 바랍니다.

결론

이번 글에서는 전통적인 프로세스의 문제점을 해결하기 위해서 애자일 방법론 소개로 시작해서 팀 커뮤니케이션을 개선하기 위해서

일일 스크럼 회의를 제안했습니다.

하지만 지금의 일들이 정리가 안되면 내일일도 모르는 상황일 수 있습니다.

다음 글에서는 애자일 스크럼, 칸반으로 신규 프로젝트와 운영 프로젝트를

어떻게 하면 애자일 스럽게 진행하는지 소개해 보겠습니다.


it2seiyon's profile image

it2seiyon

2017-06-13

Read more posts by this author