RSS

태그 보관물: 애자일

당신 팀이 진정한 애자일이 아니란 열 가지 징후들

원본링크: Software and I: 10 Signs that Your Team Isn’t Really Agile

(역자주: 내용이 좋아서 함께 읽고 싶어 원글의 저자 Assaf의 허락을 받고 한글로 번역했습니다. 애자일 쪽 용어가 익숙하지 않아서 번역이 많이 부족합니다. 양해바랍니다. 수정해야 할 부분은 알려주시면 저에게도 많이 도움이 되겠습니다.)

소프트웨어 산업에서 불고있는 애자일, 스크럼에 관한 열풍으로 인해, 이런 ‘방법론’에 대해 기술백서나, 컨퍼런스를 통해 접해본 회사들은 아마도 “이것이 우리에게 필요한 것이야”라고 생각하게 되는 건 당연합니다. 하지만 안타깝게도 어떤 조직은 애자일 방식으로 일하는 것을 받아들이는데 필수적인 사고방식의 변화가 전혀 되어 있지 않습니다.

아래는 당신 팀이 (결정적인 의미는 아니지만) 뭔가 제대로 못가고 있다는 징후의 목록입니다.

만약에 다음과 같다면 참된 애자일이 아닐지도 모릅니다.

1. 당신 팀이 전체 (유저)스토리에 대해 책임을 갖고 있지 않다면…

아마도 ‘상호 기능적(cross functional)’인 점이 애자일 팀에서 가장 중요한 측면이 아닌가 합니다. 이 말은 그 팀이 ‘전체로서’제품에 가치를 더해’ 인도하기 위하여 요구되는 모든 기술력을 보유한다는 의미입니다. 만약에 어떤 팀이 클라이언트 개발자들로만 구성된다면 서버 사이드 작업 전부를 다른 팀으로 미루게 되겠지요.  그 팀은 시작부터 끝까지 완성된 하나의 스토리를 다루지 않고 있는 것입니다. 일을 마무리했지만, 제품의 관점에서 어떤 가치도 추가하지 못한 것이죠. 즉, 고객의 시각에서 봤을 때 아무것도 하지 않은 것이 된다는 것이죠! 이런 팀들은 콘베어 벨트에 제품이 올려져서 다른 팀이 있는 다른 층으로 계속해서 전달되는 공장과 비슷합니다. 마지막 팀 일을 완료하기 전까지는 어떤 기능이나 제품이 완료되지 않는 것입니다.

상호 기능적 특성 없이도 어떤 팀은 성공적인 개발 프로세스를 보유할 수도 있습니다. 하지만 그건 애자일이 아닌거죠.

2. 다른 팀에게 테스트를 맡긴다면…

애자일 팀의 다른 중요한 특성은 작동되는 제품에 기능을 더해서 인도하는 능력입니다. 만약에 개발자들이 코딩만 완료하고 테스트하지 않은 어떤 기능을 “다했다”고 한다면,  완료에 대한 사전적 정의가 심각하게 잘못되어져 있다고 봐야 합니다. 종종 이것은 상호 기능성이 결여된 다른 예라고 볼 수도 있습니다. 단순히 QA가 다른 팀이 되는 경우죠. 한 팀의 작업이 완료되기 위해서, 테스트하고 통합하여 바로 사용할 수 있어야 합니다.

3. 당신의 유저스토리에 “INVEST”하고 있지 않다면…

INVEST 는 Bill Wake가 만든 말로, 좋은 유저 스토리의 가치를 설명하는 약어입니다. Independent(독립적이고 서로 의존성이 없어야 함), Negotiable(유저스토리가 스프린트에 들어가기 전까지는 언제든 수정되거나 다시 쓸 수 있어야 함), Valuable (최종 사용자에게 가치를 부여해야함), Estimable(유저스토리가 어느 정도의 업무량인지 항상 예측할 수 있어야 함), Sized appropriately(계획/실행/우선순위 매기기 불가능할 정도로 너무 크지 않아야 함), Testable(그 유저 스토리가 요구사항을 성공적으로 완료했음을 증명할 수 있어야 함)

제품 매니저가 유저 스토리를 INVEST할 때만 비로소 고객을 향한 가치 기준으로 우선순위를 매길 수 있고, 언제 각 기능이 완료될지 약속할 수 있고 제품의 더해진 가치가 고객에게 전달 됩니다. 비슷하게 그 팀도 이 더해진 가치를 재빨리 그리고 질(quality)에 관해서도 자신 있게 인도할 수 있게 됩니다.

4. 매니저가 팀 맴버들에게 작업을 할당한다면…

진정한 애자일 팀에서 각 멤버들이 작업할 다음 일을 직접 고를 수 있습니다. 단 다음으로(역자주: 가장 소중한 것은 직전에 한 작업이 될테니, 다음으로 가장 소중한 것을 선택하는 것이라 보여짐) 가장 소중한 유저 스토리와 관련된 것이어야 하겠지요. 전통적으로 프로젝트 매니저나 팀 리더는 팀원들에게 작업을 종종 몇 달 전에 할당하게 됩니다. 이 방식이 프로젝트 일정에 최적화를 목적으로 된 것이라 할지라도 이것은 낭비적 과정이다. 어떻게 프로젝트 전체 일정이 지연되거나 어떤 시점에 팀원들의 기술과 욕구가 무엇일지 고려할 수 없을 것입니다.

팀원입장에서는 자신의 기술을 연마하는데 집중하거나, 그가 편하게 여기는 영역 바깥의 뭔가를 배우고자 노력하길 원할 수 있습니다. 책임감있고 자율적인 팀은 필요에 따라 일의 완료를 확인할 수 있는 방법과 현시점에서의 프로젝트의 현실에 맞게 우선순위를 세울 수 있는 방법을 찾을 것입니다. 희망을 가질 수 있는 최고의 매니저는 이런 방식(역자주: 작업을 매니저가 직접 할당해주는 방식)을 버리는 사람들입니다. 게다가 그는 더 중요한 할 일들이 있습니다.

프로젝트 관리자가 자원을 할당하는 노력을 기울여야 할 유일한 시점은 팀이 가지고 있지 않은 리소스가 필요한 작업을 할 때입니다. 그런 경우는 흔치않아야 합니다. 만약에 채용을 해야하는 상황이라면, 그 팀이 충분히 상호 기능적이지 못하다는 증거입니다. (앞에 첨으로 언급한 것입니다.)

5. 당신의 팀이 얼마나 작업을 커밋해야 하는지 이야기한다면…

PM이 리소스(멤머)와 납기일(릴리즈나 스프린트)을 팀에게 주고서는 얼마나 커밋해야 할지 말하거나, 혹은 팀원들이 커밋한 것에 대해서 거부한다면, 그 프로젝트 관리자는 튼튼한 관계를 깨는 죄를 범한 셈입니다. 팀은 이터레이션마다 팀원들이 (과거의 경험에 따른 추정을 근거로) 스스로 할 수 있다고 믿는 만큼의 작업을 커밋할 수 있어야 합니다.

그러하지 못하다면 계획에 있어 애자일과 무관한 것입니다.  즉, 계획이 미리 세워졌고, 돌에 새겼고, 재협상의 의지가 없다는 의미입니다. 품질에 대한 암묵적 비용은 생각도 못하는 것이지요.

진정한 애자일한 팀이라면 애초에 세운 모든 유저스토리 보다 더 적은 것이 배포될 수 있다는 것을 받아들여야만 합니다. (물론 그런 것들은 가장 우선순위에서 밀려서 버릴 수도 있는 것들이어야 하겠습니다.)

6. 진도를 토론하기 보다는 보고하고 있다면…

진정한 애자일이 아니란 미묘하고 은밀한 징후가 바로 당신이 자기 진도를 일일 스탠드업 미팅에서 팀이 아니라 프로젝트 관리자나 스크럼 마스터에게 보고 하고 있다는 것입니다. 사실 이 미팅은 전체 팀원들이 각자 뭘 하고 있는지, 뭐가 막히는지, 또 뭘 계획하고 있는 지 공유하기 위해서 있는 것입니다.

겉으로 보기에 관리적 속성에도 불구하고 이 세가지 질문(지난번 미팅이후로 뭐하고 있니?, 다음 미팅까지 뭘  할거니?, 진행하는데 막히는 게 뭐니?)은 관리자가 팀을 감시하기 위한 게 아니라 문제를 바라보는 다른 팀원들의 생각을 이끌어낼 목적으로 있는 것입니다. (‘내가 도와줄까?’, ‘이게 내 작업에 영향을 줄까?’ 등)

각 팀원들은 팀의 다른 동료들에게 이야기하고 있어야 하며, PM는 거기서 듣고, 질문에 대답해줘야지 자신이 미팅에서 중심이 되어서는 안됩니다.

7. 당신이 가장 중요한 유저스토리를 완료하는데 집중하고 있지 않다면…

때때로, 가장 우선순위의 스토리 하나에 집중해서 팀원들에게 작업으로 나눠주는 대신에 여러 스토리들를 나누고, 그 스토리를 더 잘게 나눠 작업단위로 분배하는 팀이 있습니다. 이 경우 두 가지 애자일스럽지 않은 결과를 유발할 수 있습니다.

첫번째 문제는, 주어진 시간에 스토리 중에 일부가 (가치측면에서) 완벽하게 완료되기보다, 모든 스토리가 (가치와 상관없이) 부분적으로 완료될 수 있습니다. (역자주: 팀 전체가 가장 중요한 스토리에만 집중해서 그 스토리가 완전한 가치를 갖도록 완료시키는 것이 애자일이란 의미)

두번째 문제는, 각 팀원들의 노력이 자신의 팀원들에게 충격과 중요성을   크게 주지 못하게 됩니다. 결국에는 멤버 각자가 이야기하는 스토리가 전체 스토리와 차이가 생기게 됩니다. 다른 팀원들은 그 팀원이 갖고 있는 문제를 듣거나 도움을 주기에 덜 적극적이게 됩니다. (역자주: 왜냐면 같은 스토리를 작업하고 있는게 아니기 때문에) 일일 회의는 그저 단순한 진행 보고로 전락하게 되고 ALM(application lifecycle management) 툴을 뭘로 쓸건지같은 주제로 쉽게 대체되어 버립니다.

애자일한 팀이라면 팀전체가 같은 문제를 풀고있도록 준비되어야만 합니다. 또, 가능한 빨리 해당 기능을 완료하는데 모든 노력을 기울여야 합니다.

8. 작년에 애자일로 바꿨는데 그후로 바뀐게 없다면…

여기에 어려운 부분이 있는데요. 당신은 해냈다고 생각하고,  당시 전문적인 방식으로 도입했으며, 계획대로 추진했고 잘 되는 것 같습니다. 이젠 표준화 되어서 누구도 바꿀 수 없다 여깁니다. 애자일이 되기위해 가장 중요한  부분을 놓치고 있는데 그게 뭘까요? 바로 실제로 기민해지는(agile) 것이죠. 현실은 바뀌어 새 아이디어나 새로운 영향이 늘 있습니다. 더 좋게 만들 수 있는 뭔가는 항상 존재하는 법입니다.

일반적인 애자일 팀은 정기적으로 회고를 합니다. 이 자리는 머리를 맞대고 이전에 비해 올바르게 한 것이 무엇인지, 다음에 더 잘할 수 있는 방법은 뭘지, 또 성장을 위해서 구체적인 액션을 모두 함께 생각하는 자리입니다.

이러한 구체적인 액션들이 대개 일하는 방식의 변화로 나타납니다.

노트: 만약에 당신 팀이 IT기반의 ALM툴(TFS, Greenhopper, etc, Version One)을 사용중이라면, 툴 상에서 그러한 변화의 영향을 주의깊게 관찰해 보세요.

출시 시점

가끔 데드라인이 지났는데 계획된 일을 모두 마치지 못하는 예기치 않은 문제가 있습니다. 주어진 스토리를 재빠르게 처리하고 반드시 한번에 하나씩 스토리를 완성해서 배포한다면, 상당히 만족스러운 제품을 갖게 될 것입니다. (앞서 이야기 한 것이지만, 반복할 가치가 있습니다.)

자 다시 글을 쓸 시간입니다. 제가 10가지 징후에 대해서 약속했었던 것 압니다. 하지만 그게 불가능하단 게 드러났네요. 적어도 시간 내에 가장 중요한 것은 다뤘다고 봐야겠죠? 아닌가요?

자, 여러분이 그렇게 생각지 않고 납기일을 맞추는 것보다, 모든 것을 배포하는 것이 더 중요하다고 여긴다면 여기 아홉 번째 징후가 있습니다.

9. 제시간에 불완전한 부분으로 배포할 준비가 되지 않았다면…

만일 특정 시점에(특히나 납기일에) 당신이 완료한 가장 중요한 기능들을 배포 가능하게  일을 정리할 수 없다면, 당신의 계획은 애자일 하지 않다고 볼 수 있습니다. 아마도 제품의 가치를 증가시키는 Vertical slice(역자주: 모든 구성요소들간의 상호 동작을 강조하는 일정수립방식 참조) 대신에 집처럼 층계로 된 제품을 만들고 있을 것같군요.

애자일 제품은 한번에 하나의 유저 스토리(혹은 가치 증가, 최소한의 시장성이 있는 기능. 뭐라 부르든 간에)로 만들어집니다. 이것에 대해 더 많은 내용은 애자일 출시 어떻게 계획하나는 제 블로그 글을 읽어보시기 바랍니다.

여기 또 다른게 있습니다.

여러분은 다음에 언제든 남은 기능들을 마이너 릴리즈를 하나 올리면서 릴리즈할 수 있습니다.

10. 매 스프린트마다 고객의 피드백을 받고 있지 않다면…

매 스프린트의 끝에 애자일 팀은 제품의 최종적으로 향상된 기능을 시연해봅니다. 프로젝트의 모든 이해당사자들은 누구도 청중이 될수 있는데, 당연히 제품 책임자와 프로젝트 매니저와 필요시에 고객도 포함해야 합니다. 어떤 팀들은 자신의 진도를 보여주기 위해서 공식적인 일정으로 이용하고 그 결과에 무관하게(!) (원래) 계획을 다음 스프린트에서 계속하는데 이것은 애자일이 아닙니다.

진정한 애자일 팀은 프로젝트 당사자들에게서 최근의 개발에 대한 의견을 이끌어내고 팀이 제대로 하고 있는지 확인하기 위해서  데모를 지렛대 삼을 것입니다. 마지막 스프린트동안 요구사항이나 환경이 바뀌었다면 그 변화가 제품의 백로그와 잠재적으로 오는 스프린트의 백로그에 반영될 것입니다.

기억하세요. 애자일 팀은 변화를 피하기 보다 끌어안아야 합니다.

요약

여기까지 열가지 징후였습니다. 저는 여러분들이 본 내용을 즐길 뿐만 아니라 교훈도 함께 발견할 수 있길 바랍니다.

당신도 어떤  다른 징후를 가지고 있다면 이 목록에 더해줄꺼지요? 댓글로 남겨주세요.

Assaf.

아삽

[편집]

11. You’re not agile if you can’t deal with a change in the original scope.

11. 원래의 범위에서 어떤 변화도 줄 수 없다면 당신은 애자일하지 못하다. (역자주: 자신이 10개만 하겠다고 해놓고 그 범위를 수정하는 것을 변증하는 듯한 열 한번째 징후)

그런데, 서두에 “오직” 10가지 경우라고 말했지만 초안에 대한 의견을 참조해서 한가지 경우를 더하라는 요청을 받아서 11가지가 되었네요. 10가지 내용을 포스팅하기 전에 한 친구에게 보여주었더니 마음에 들어했습니다. 사실 그 친구는 열가지의 내용을 아주 좋아해서 한가지 경우를 추가할 것을 권고했고, 그 의견을  받아들여 한가지 내용을 추가한 11가지 내용을 포스팅하고 나니 그 친구는 다시 ‘어순’을 정리해서 뜻을 명확하게 할 것을 권했습니다. ‘어순’을 변경해서 편집한 내용이 더 마음에 들길 바라면서..

(역자주: 글 내용이 도움이 되셨다면 원본 링크를 타고 가서 저자에게 댓글을 달아주면 좋겠습니다.)

 
댓글 5개

게시자: 켬 2012년 2월 11일 in Agile, Uncategorized

 

태그: , , ,