어제(4월 21일) 애자일 실천법 세미나(Agile Practices Seminar)가 있었습니다. 저는 "애자일 도입 성공 요인 분석"이라는 발표를 했습니다. 못오신 분과 오셨지만 다시 보고 싶은 분들을 위해 슬라이드와 제 설명(일부분은 설명을 줄였고 일부분은 설명을 보충)을 써봤습니다. 원래 20분짜리 발표였는데, 주최측에서 5분을 더 연장해서 해달라고 해서 25분 동안 발표를 했습니다. 길지 않습니다. 하지만 써보니 길군요. 바쁘신 분들은 맨 뒤의 요약만 보셔도 됩니다.

국내 애자일 발전에 도움이 되길 바라는 마음으로 정리했습니다. (애자일 도입 현황 설문에 응답해 주신 분들께 감사드립니다)


안녕하세요. 김창준입니다. 본 발표에서는 애자일 방법론을 도입할 때 성공 요인이 무엇인지 알아보도록 하겠습니다.

이 발표자료는 2008년도에 시작한 애자일 도입 실태 설문을 토대로 한 것으로 설문은 xper 메일링리스트와 제 블로그 등을 통해 홍보를 했습니다. 응답자의 직급은 사원부터 임원까지 다양했는데 43%의 분들이 과장/차장 직급이었습니다.

2008년 말에 1차 분석을 KGC에서 발표했었고, 그 후 자료가 더 추가되어 두번째로 발표하는 것입니다. 지난번 자료를 모두 포함하고 더 추가된 것이기 때문에 통계적 신뢰성은 더 높다고 말할 수 있겠습니다.



70여개의 회사에서 응답이 들어왔는데, 업계별로 응답을 보면 화면과 같습니다. 매끄러운 분류는 아니지만 대략적인 감을 잡는 데에는 큰 무리가 없으리라 생각이 듭니다. 우선 웹서비스 분야가 단연 1위를 하고 있고, 다음으로 시스템 통합이 2위를 하고 있다는 점을 알 수 있습니다. 여전히 게임 및 멀티미디어 쪽도 많은 회사가 하고 있고요. 2008년 분석 때와 비교해 시스템 통합과 임베디드 쪽에서 애자일을 하고 있다는 회사가 많이 늘어난 점이 인상적입니다. 기타 분류로는 모바일, 의료, 시스템 소프트웨어, 생물정보학 연구 등이 있었습니다.

제가 10년 가까이 국내 애자일 도입을 지켜보면서, 또 2008년도와 2009년도 응답을 분석하면서 느낀 점은, 리스크에 대한 태도에 의해 도입 순서가 정해지는 것 같다는 점입니다. 웹서비스나 게임 쪽은 비교적 리스크를 감내하고 적극적(risk-taking)인 태도가 있는 것 같습니다. 그래서 애자일이 먼저 퍼진 것 같고요. SI나 임베디드는 비교적 리스크를 피하는(risk-aversive) 경향이 있는 듯 합니다. 하지만 최근 비즈니스 시장의 변화에 의해 어쩔 수 없이 애자일 쪽으로 떠밀리고 있는 듯 보이는 점이 있고요. 보안이나 금융, 보험 등은 좀 더 늦게 도입이 되지 않을까 싶습니다.



어떤 규모로 도입이 이뤄지고 있는지 보여주는 차트입니다. 개인수준에서 도입, 실천 중이라고 하신 분들도 계셨는데, 대다수(44%)는 하나 이상의 팀이 애자일을 도입, 실천 중이라고 하셨습니다. 공식적으로 회사 전체에서 애자일을 도입, 실천 중이라고 하신 회사는 6%였습니다.



애자일을 도입해서 프로젝트 성공에 도움이 되었냐는 질문에 대한 응답입니다. 53%가 그렇다고 답하셨고, 25%는 매우 그렇다고 답하셨습니다. 전체에서 78%는 애자일이 프로젝트 성공에 긍정적인 영향을 미쳤다고 보신 셈입니다.

프로젝트 성공과는 별개로 현재 실천하는 애자일 실천법의 성숙도를 묻는 질문("현재 애자일을 적용 중인 프로젝트의 애자일 성숙도를 점수로 준다면 몇 점을 주시겠습니까?")이 있었는데, 봉우리가 세 개 있는 분포를 보였습니다. 전혀 안된다는 쪽에 한 그룹, 보통 정도(10점 만점 중 4~5점) 한 그룹, 그리고 잘하고 있다는 쪽(8점대)에 한 그룹이 있었습니다.

상식적으로 이해할 수 있는 것인데, 성숙도와 성공도의 상관성이 중간 정도(상관계수 0.43)였고 따라서 대체적으로 애자일 성숙도가 높은 조직은 애자일이 프로젝트 성공에 도움이 많이 된다고 느끼는 것으로 나왔습니다. 흥미로운 점은 성숙도를 낮게 평가한 조직들 중에서도, 성공도로 보면 낮은 조직부터 높은 조직까지 다양했다는 점입니다. 대신 성숙도가 높아지면 성공도가 낮은 조직은 없었습니다.

여기에서 말할 수 있는 것은, 우리 조직이 애자일을 성숙하게 실천하고 있지 못하다고 해도, 성공에 도움이 되게 할 수 있다는 희망적인 메세지입니다.



다음은 이제부터 사용할 약어 안내입니다. 모두 애자일의 실천법들로 대표적인 것들만 넣었습니다. 각각의 설명은 "익스트림 프로그래밍"(인사이트 출판)이나 웹 검색을 참고하시면 되겠습니다.

조금 특이할만한 것으로 테스트 주도 개발(TDD)과 코딩 후 자동화된 단위 테스트 붙이기(TLP)를 구분해 놓았는데, TLP는 테스트를 먼저 만드는 TDD와 달리, 코드가 만들어진 후에 그에 대한 자동화된 단위 테스트를 붙이는 것을 말합니다. 레거시 코드가 있는 경우 혹은 TDD를 하기에는 아직 수련이 충분하지 못한 경우 TLP를 하는 조직을 종종 봤고, 저 역시 맥락에 따라 TLP을 우선적으로 권하기도 하기 때문에 TLP를 따로 구분했습니다. 그리고 고객 참여(CP)는 꼭 고객만이 아니라 고객을 대표하는 사람의 참여도 포함하도록 했습니다.

이제부터 보여드릴 자료는 "애자일 실천법 중에서 도입해서 성과에 도움을 준 것들을 모두 고르세요"라는 질문에 대한 응답을 분석한 것입니다.

상관성을 보면, 성공적으로 도입한 실천법 숫자가 많을수록 프로젝트 성공도가 높았고, 둘 간의 상관성은 강한 것(0.57)으로 나타났습니다. 실천법 숫자와 성숙도 간의 상관성도 강한 것(0.58)으로 나타났습니다.



이 슬라이드와 다음 슬라이드에서는 두 가지 정보를 읽으실 수 있습니다. 하나는 색깔에서 알 수 있고, 다른 하나는 상자들을 연결한 선의 종류, 즉 실선이냐 점선이냐, 연결이 없냐에서 알 수 있는 것입니다.

상자 안의 색깔은 성공도와의 상관성을 말합니다. 총 세가지 색깔이 있는데, 적색, 황색, 청색이 있습니다. 적색이 가장 상관성이 높고, 그다음 황색, 다음이 청색 순입니다. 상관계수의 수치를 기준으로 끊었습니다(0.4 이상, 0.35 이상, 그 이하). 상관성이 높다는 것은 달리 말하면, 성공도가 높은 조직이 적색을 잘하거나, 혹은 적색을 잘하는 조직이 성공도가 높거나 할 수 있다는 것입니다.

연결선은 각 상자들, 즉 애자일 실천법들 간의 상관성을 나타냅니다. 실선이면 상관성이 강한 것이고, 점선은 중간 정도, 연결이 없으면 약한 것입니다.

이 슬라이드에서는 코드 공유(CO)가 황색입니다. 그만큼 성공과 관련이 깊다는 것이죠. 하지만 다른 것과 연결되어 있지는 않습니다. 반면 짝 프로그래밍(PP)과 함께 앉기(ST)는 실선으로 연결되어 있습니다. 이 말을 이렇게 해석해 볼 수도 있습니다. 만약 우리가 짝 프로그래밍을 잘 하고 싶은데 왠지 안된다 싶으면 우리가 함께 앉기를 잘 하고 있는가 살펴보라는 겁니다. 통계적으로 두 개가 같이 가기 때문입니다. 반대로 함께 앉기가 잘 안되면 짝 프로그래밍을 잘 하고 있는지를 반문해야 합니다. 상식적으로도 두 가지가 함께 갈 것이라는 점이 쉽게 이해되실 겁니다.

좀 의외의 점은 ST는 실천법들 중에서는 성공도와의 상관성이 가장 낮았습니다(-0.01). 즉, 적어도 이 설문에 응답한 분들 기준으로는 ST를 했다고 해서 성공에 직접적으로 도움이 되거나 하지는 않았다는 점이죠. 긍정적으로 보자면 ST가 안되는 프로젝트, 예컨대 사람들이 서로 파티션으로 갈라져 있거나 해도 애자일로 성공을 시키는 데에 불리하지 않다는 식으로 해석할 수 있습니다.



이 슬라이드는 좀 더 인상적입니다.

우선, 코딩 후 자동화된 단위 테스트 붙이기(TLP), 지속적 통합(CI), 고객 참여(CP)가 성공과 관련이 깊습니다. 리팩토링도 중요하고요. 다른 나머지 것들도 성공과 관련이 있지만 강하지는 않습니다. 다만, FR과 RS, SM은 황색이 되지는 못했지만 황색에 매우 가까운 실천법들이었습니다.

연결선을 보면, CI가 다른 실천법과 가장 연결이 강한 것을 알 수 있습니다. 네 개의 실선이 CI와 연결되어 있죠. 그 다음은, 기립 회의(SM)와 정기적 회고(RS)입니다. 두 개의 실선, 한 개의 점선으로 연결되어 있습니다. 다음은 짧은 반복 개발 주기(FR)네요. 하나의 실선, 두개의 점선입니다. 이렇게 연결이 많이 되어 있는 실천법은 핵심적인 혈자리라고 볼 수 있습니다. 다른 것들을 가능하게 해주는 조력자(enabler)라고 볼 수도 있고요.

저는 여기에서 CI의 중요성에 대해 놀랐습니다. 2008년 이 결과를 분석해 보기 전에는 CI를 그렇게 중요하게 생각하지 않았거든요. 하지만 분석을 해보고 제 경험과 연결을 해보니 나름 고개가 끄덕여지는 부분이 있었습니다. 왜 그런지 한 번 봅시다.

아침에 15분 정도 팀 내의 기립 회의를 하려고 하는데 잘 안됩니다. 왜 안될까요? CI가 안되면 SM이 잘 안되는 경우가 많습니다. 왜냐하면 그 회의에서 남의 이야기를 들을 필요가 없기 때문입니다. 각자 작업하는 코드를 통합하지를 않는데, 남의 업무가 내 업무랑 상관이 있다고 느낄 수 있을까요? 일단 동기가 부족하게 되겠죠. 정기적인 회고도 그렇습니다. 서로 업무가 연결될 건덕지가 없는데 같이 모여서 회고하면서 팀 레벨에서 좋은 점, 개선할 점 이야기하는 것이 의미가 없죠.

또 반대로 지속적 통합이 잘 안되면 SM이 제대로 안되어서 그럴 수 있습니다. 서로 어제 무슨 작업 했는지, 오늘 뭘 할지를 충분히 공유하지 않은 상황에서 억지로 통합해봐야 계속 컴파일 오류만 나겠죠.

CI가 다른 실천법들과 연결성이 가장 강하다는 면에서 저는 CI를 일종의 팀 내 센터(center, 크리스토퍼 알렉산더의 개념으로 생명의 느낌이 자라나기 위해서는 센터들이 서로 연결되어 더 큰 센터를 만들어야 한다)를 제공해주는 실천법으로 보고 있습니다.

여러분들이 팀에서 적용하고 있는 실천법인데 잘 안되는 것이 있다 하면, 이 그림을 잘 보시고 연결된 다른 실천법이 제대로 되고 있는가 생각해 보시길 권하고 싶습니다. 고객 혹은 고객을 대표하는 사람의 참여(CP)가 잘 안되면 정보를 제공하는 작업 공간/정보방열기(IR)가 제대로 되고 있는지를 확인하셔야 합니다. 고객의 참여를 유도하는 데에 가장 도움이 되는 것 중 하나가 IR이 되는 이유는, IR을 통해 고객이 프로젝트의 진행 상황을 즉각적으로 확인할 수 있기 때문입니다.

또, TDD가 잘 안된다면, RF를 충분히 잘 하고 있는지 생각해 보셔야 하고, RF가 잘 안되면, TLP를 해볼 생각을 하시고, TLP가 안되면 CI를 해볼 생각을 하시면 됩니다.



이 슬라이드는 계층적 클러스터링(hierarchical clustering)을 통해 그린 덴드로그램(dendrogram)입니다. 통계적 과정을 통해 서로 가까운 실천법끼리 묶었다고 보시면 됩니다. 앞에서 보신 두 장의 슬라이드와 거의 비슷합니다. 이 그림도 비슷한 식으로 활용하실 수 있겠습니다.



제가 트위터에서 발표날 아침에 "저는 애자일 도입에 대해 흥미롭고 무서운 결과를 발표할 예정"이라고 썼습니다. 앞에까지가 흥미로운 결과라면 이제는 무서운 결과입니다.

성공도를 종속변수로 보고 각 실천법을 독립변수로 해서 중회귀분석(multiple regression analysis)을 했습니다. p-value를 기준으로 통계적으로 유의미한 실천법만 뽑아서, 계수가 큰 것부터 나열한 것이 이 표입니다.

고객 참여는 계수가 0.77인데, 이 말은, 고객 참여를 잘 하는 프로젝트는 성공도가 0.77 높아질 수 있다는 뜻이 됩니다. 예를 들어, 우리가 "애자일을 해서 프로젝트 성공에 도움이 되었는가"라는 질문에 "그저 그렇다"(3점)라고 대답하는 조직이었는데, 고객 참여를 잘 하면 "그렇다"(4점) 쪽으로 근접할 수 있게 된다는 것이죠. 애자일이 프로젝트 성공에 매우 도움이 되었다라고 답한 그룹에서는 59%가 고객 참여가 도움이 된 실천법으로 꼽은 반면, 그 나머지 그룹에서는 12%만이 고객 참여 실천법을 선택했습니다. 그리고 "그 나머지 그룹" 중에서 성공에 도움이 되었다라고 한 집단(4점)을 제외하면, 즉 성공에 도움이 되었는가에 그저 그렇다, 아니다, 매우 아니다로 답한 그룹에서 고객 참여를 선택한 조직은 하나도 없었습니다.

성공도에 5점을 준 집단에서는 59%가 고객 참여를 선택했고, 4점 집단에서는 17%, 그 이하 집단에서는 0%가 고객 참여를 선택했습니다.

고객 참여 다음의 세가지는 성공 기여도가 비슷합니다. 리팩토링, 코딩후 자동화 단위 테스트 붙이기, 코드 공유 순입니다. 어쨌건 이 네가지가 잘 되어야 프로젝트 성공에 애자일이 도움이 될 수 있습니다.

그런데, 많은 조직들이 고객 참여와 코드 공유를 뒤로 미룹니다. 우리 상황에서는 할 수 없다, 어렵다라고 생각합니다. 두 가지 모두 "사람"이 개입하기 때문입니다. 고객 참여는 고객을 설득해야 하고, 코드 공유는 개발자를 설득해야 합니다. 사람과의 대면과 충돌이 무섭고 두려운 것이죠. 하지만 이런 것들을 제대로 하지 않으면 프로젝트 성공을 하기가 더 힘들어 집니다.

저는 애자일 초보팀들과 애자일 전문가팀을 보면서 공통된 차이점을 발견했습니다. 초보팀일수록 처음에 쉽고 안심이 되는 것에서 시작합니다. 그것은 별 문제될 것이 없습니다. 그렇게 해서 얻는 "작은 성공"의 심리적 효과가 도움이 되거든요. 하지만 어렵고 두렵지만 중요한 것을 얼마나 미루느냐가 중요합니다. 그런데 초보팀들은 그걸 미룹니다. 프로젝트가 접히기 직전까지요. 오손도손 영차영차 우리끼리 재미있게 하자고 합니다. 좋습니다. 그러다가 우리들의(혹은 나만의) 잔치로 끝나는 경우를 종종 봤습니다.

전문가팀은 무섭고 두렵더라도 중요하다면 그 리스크를 인식하고 꾸준히 시도하는 점이 다릅니다.

이 결과에서 제가 얻은 교훈은 이겁니다. 두려워도 중요하다면 시도해봐야 하지 않겠는가. 이 질문은 그 자체로 참 무섭습니다. 그래서 제가 트위터에 "무서운 결과"라고 했습니다. 그런데 더 무서운 결과가 있습니다.

이 슬라이드는 전체 조직에 대한 분석결과인데, 중위값을 기준으로 성숙도가 낮은 조직(즉, 애자일을 시도한지 얼마 안되었고, 스스로 잘 모른다고 생각)과 높은 조직을 나누어서 각 그룹별로 분석을 해봤습니다.

먼저 성숙도가 낮은 조직을 보시죠.



통계적으로 유의미한 실천법 딱 하나입니다. 고객 참여. 그리고 기여도는 0.94로 아까 전체로 볼 때보다 더 높습니다. 거의 1입니다.

우리가 애자일을 도입한지 얼마 안되었다. 잘 못한다. 그런데 어떻게든 프로젝트가 더 성공적이 되었으면 좋겠다. 답은? 고객 참여 뿐입니다. 이게 안되면서 다른 것들이랑 씨름하는 것은 두렵고 중요한 것에 대한 회피일 수 있습니다.



성숙도가 높은 조직을 보시죠. 짧은 반복 개발 주기가 1등입니다. 고객 참여보다 더 기여도가 높습니다. 그말은 성숙도가 높은 조직에서는 고객 참여보다 짧은 반복 개발 주기가 성공에 더 도움이 될 수 있다는 점입니다. 그만큼 짧은 반복 개발 주기를 통해 고객 참여가 잘 안될 때를 어느 정도 보완할 수 있다는 뜻일수도 있겠습니다.

애자일에 대해 어느 정도 이해는 하고, 실험도 좀 해봤다 싶은 조직에서 성공기여도를 높이려면 짧은 반복 개발 주기, 고객 참여, 코드 공유에 관심을 기울이셔야 합니다. 이런 것들을 제대로 하지 못하면서 다른 실천법에만 계속 신경을 쓰면 프로젝트 성공을 미루는 일이 될 수도 있습니다.



이 슬라이드는, 아직 도입하고 있지는 못하지만 도입하면 가장 도움이 될 것 같은 실천법을 하나만 고르라는 묻는 질문에 대한 답입니다. 많은 분들이 테스트 주도 개발과 고객 참여를 뽑으셨습니다.

TDD는 대부분의 경우, 익숙해지는 데에 시간이 걸리는 것 같습니다(반대로 TDD가 제일 쉬웠어요라고 하는 회사도 있습니다). 개발자 입장에서는 일하는 방식의 변화가 환골탈태에 가깝기 때문입니다. 도입해서 프로젝트 성공에 도움이 되었다고 하신 분들은 38%나 됩니다만, 동시에 가장 많은, 26%의 분들이 TDD를 도입하면 가장 도움이 될 것 같다고 했습니다. 그만큼 양극화가 되어 있다고 이해할 수 있습니다. 시간이 지나면서 TDD가 더 많이 확산이 되고 또 효과적인 교육법 등이 퍼지면서 극복될 문제라고 생각이 듭니다.

고객 참여는 19%의 조직에서 도입하면 도움이 될 것 같은데 아직 못하고 있다고 하셨습니다. 반면 28%의 조직이 고객 참여를 성공적으로 도입했다고 답변했습니다.

이걸 보면서 고객 참여가 중요한 것은 알겠는데, 우리는 절대 안될 것 같다, 어쩌냐. 포기하라는 말이냐 하는 반응을 하는 분들이 계실 것 같습니다. 하지만 앞에서도 언급했다시피 고객 혹은 고객을 대표하는 사람의 참여입니다. 진정 중요한 것은 프로젝트의 성패를 좌우하는 사람과 최대한 가까운 사람을 참여시키려고 우리가 계속 노력하고 있냐 하는 점입니다. 이런 노력을 아예 시도할 수도 없는 프로젝트는 제가 아직 접하질 못했습니다.



마지막 슬라이드입니다. 이 슬라이드는 이번 통계분석에서 나온 것이 아닙니다. 순전히 제 10년 컨설팅, 코칭 경험에서 나온 교훈입니다. 제 관찰에 따르면 성공하는 조직들에는 항상 뛰어난 애자일 코치가 있었습니다. 그 점이 가장 핵심이었습니다.

어떻게 보면 애자일 도입 성공의 메타적 요소라고 할 수 있습니다. 뛰어난 애자일 코치를 통해 실천법을 더 잘 도입할 수 있게 되니까요.

제가 느끼기에 뛰어난 애자일 코치의 특징은 이와 같습니다. 애자일 코치는 팀장일 수도 있고, 팀원일 수도 있고, 사장일 수도 있습니다. 이것은 어느 누가, 어느 조직이 정해줄 수 있는 것이 아닙니다. 자신의 조직적, 정치적 위치와는 관계가 없습니다. 오로지 자신의 선택입니다. 애자일 코치는 그런 것입니다. 내가 애자일 코치가 되어야지 결심하는 것이 가장 중요합니다. 이 사람이 어떻게 행동하고 의사소통 하느냐에 따라 팀의 행동과 의사소통 방식이 바뀔 수 있습니다. 맨 마지막에 기술적 능력하고 옆에 물음표를 달았는데, 그 이유는 중요하긴 하지만 필수적이라고 생각이 들지는 않아서 입니다. 최소한도의 능력 이상은 있어야 하지만 어느 정도 수준을 넘으면 다른 변수들이 훨씬 중요해지는 것 같습니다.

이 부분에 대해서 조금만 부연설명을 더하고 싶습니다.

최근 성과 높은 사람으로서의 전문 S/W 엔지니어(단순히 경력이 긴 사람이 아닌)에 대한 연구로부터 밝혀진 것은 사회적 능력(social/interpersonal skill)의 중요성입니다. 지적 능력(general mental ability)이 뛰어난 프로그래머들의 성과를 구분하는 것은 사회적 능력임이 밝혀졌습니다(Ferris 2001). 대졸 신입사원에게 어떤 조언을 해주겠냐는 질문에 대해, 중간 정도 성과를 내는 S/W 엔지니어에 비해 높은 성과를 내는 엔지니어는 "다른 사람과의 협력"을 훨씬 더 자주 언급했고(Sonnentag 1998), 실제로 뛰어난 S/W 엔지니어들은 높은 대인 능력을 갖고 있는 것이 관찰되었으며(Riedl 1991), 설계, 코딩, 테스팅 등의 소프트웨어 개발 활동에 대한 시간 투자는 전문가와 그렇지 않은 사람에 큰 차이가 없는 반면, 리뷰 회의나 다른 사람과 상담하는 등의 의사소통과 협력 활동에서는 전문가가 훨씬 많은 시간을 사용한다는 것이 밝혀졌습니다(Sonnentag 1995). 상위 5%(1차 연구, 2차 연구에서는 상위 30%)의 탁월한 S/W 엔지니어에 대한 연구에서도 그런 사람과 그렇지 못한 사람을 구별하는 효과적인 요소는, 개인과 주어진 업무 외에도 관심을 갖는가 하는 점이었습니다. 탁월한 엔지니어들은 프로젝트 전반에 대한 큰 그림을 가지려고 하고, 경영진에게 더 적극적인 태도로 다가가고, 다른 엔지니어들을 도와줍니다(Turley 1995).

마지막으로, 뛰어난 애자일 코치는 정해져 있다고 믿지 않습니다. 성장할 수 있다고 믿습니다. 누구나 뛰어난 애자일 코치가 될 수 있다고 믿습니다. 이것은 "누구나 작년보다 더 나은 나"가 될 수 있다고 믿는 것과 크게 다르지 않습니다. 그것이 제 길지 않은 AC2 교육 과정에서 얻은 교훈입니다.

오늘의 발표를 요약하자면 다음과 같습니다.

  1. 애자일을 도입해서 성공하는 조직들이 국내에 있다.
  2. 애자일 실천법을 잘 실행하면 성공률도 높아질 수 있다. (애자일을 한지 얼마 되지 않더라도)
  3. 특정 실천법이 잘 안되는 경우 연결된 다른 실천법이 제대로 되고 있는지 확인해라.
  4. 지속적 통합이나 일일 기립 회의, 정기적 회고 등은 다른 실천법을 가능케 해주는 혈자리(enabler)이다.
  5. 실천법 중에서 비교적 성공과 직결되는 것들이 존재한다. 그것은 고객 참여, 리팩토링, 코딩후 자동화 단위테스트 붙이기, 코드 공유 등이다.
  6. 애자일 성숙도가 낮은 조직일수록 고객 참여를 하지 않으면 프로젝트 성공이 어렵다.
  7. 무섭고 두렵지만 중요한 일이라면 계속 미루지 말라.
  8. 뛰어난 애자일 코치가 있는 것이 애자일 도입 성공에 핵심적이다.
  9. 뛰어난 애자일 코치는 스스로 더 나은 사람이 되려고 노력한다.




Agile Adoption Success Factors
View more presentations from juneaftn.