Agile back to basics

Editor's Notes

• #2: 안녕하세요. 오늘 제가 발표할 주제는 애자일입니다. 우선 애자일의 근본을 살펴보고, 도입 사례를 소개하겠습니다.
• #3: 그러고자 저는 이 책을 선택했습니다. 클린 애자일입니다 저자인 로버트 마틴은 애자일 선언에 발의자 중 한 분이십니다. ------ 로버트 마틴, 그러니까 엉클 밥의 책입니다 분명 이 분의 책을 한 권 쯤은 읽어보셨을겁니다. 아니면 적어도 책꽂이에 꽃혀 있을겁니다. 확고한 개발 철학을 가지고 계신 분이죠 로버트 마틴은 애자일 방법론을 최초로 선언한 여러 개발자 중 한 명이고, 그런만큼 애자일 방법론에 대해서도 확고한 철학을 가지고 계십니다 이 분이 애자일 방법론에 대해 하실 말이 있으시답니다. 본인의 표현에 따르면 호통과 꾸짖음입니다 저자에 대해 대충 설명하고 넘어가자 이 책의 내용을 위주로 개념을 설명한 후, 사례를 이야기하겠다
• #4: 그래서 이 분이 말씀하시는 애자일의 근본이란 무엇일까요? 물론 단지 빨리 일하는 게 애자일은 아닙니다. 빠르게 일할 수 있다는 건 애자일의 효과이지, 애자일 그 자체는 아닙니다. --------- 왜 호통과 꾸짖음일까요? 애자일이 변질되었기 때문입니다 애자일 선언의 첫 의도는 잊혀지고, 장사꾼들의 허황된 약속으로 변질되었기 때문입니다 제 경험 하나를 말씀드리면, 처음의 좋았던 의도는 어느 시점부터 사라지고, 처음부터 불가능했던 목표를 달성하기 위해 스프린트 종료일까지 계속 야근을 해야했던 기억이 납니다. 그래서 저는 애자일에 대한 기억이 그리 좋지만은 않습니다. 그렇다고 워터폴 방법론을 찬양하는 쪽도 아닙니다만… 아마 엉클밥도 비슷한 생각을 했나봅니다. 그리고 애자일 방법론의 선언자로서 두고 볼 수 없었나봅니다. 그러면 엉클밥이 주장하는 애자일이란 대체 뭘까요?
• #5: 애자일은 아주 간단한 아이디어에서 출발합니다. 애자일은 우선 작은 목표를 세우고 그 진행 상황을 측정한 후, 그 결과를 기반으로 다음 목표를 세워 실행하는 것입니다. 다시 말해, 측정 가능한 작은 단계를 기준으로 일을 하는 게 애자일의 핵심 아이디어입니다. 더 간단히 말하자면, 애자일은 피드백입니다 --------------- 애자일은 아주 간단한 아이디어다. 그리고 모두가 알고 있는 방법론이다. 작은 목표를 세우고 그 진행 상황을 측정하여 다음 목표를 세워  실행한다. 즉, 측정 가능한 작은 단계를 기준으로 일을 하는 게 애자일의 핵심 아이디어. 새로울 게 하나도 없는 아이디어다. 아마도 선사시대부터 시작된 아이디어일 것이다. 그러니 애자일 선언 이전에도 애자일 방법론은 존재했다. 하지만 애자일 선언 이전 약 30년 간 업계는 워터폴 방법론이 지배했습니다. 먼저 계획하고, 계획대로 개발한다는 워터폴은 듣기에는 별 문제 없어보였지만, 제대로 동작하지 않았다 무엇이 문제였을까?
• #6: 애자일이 무엇을 측정한는지 더 자세히 살펴보겠습니다. 첫째는 팀의 속도이고, 둘째는 남아있는 일입니다 작은 반복주기(1~2주 단위)로 나눠 업무 속도와 진행률을 측정할 수 있습니다. 그리고 이렇게 4~5 사이클을 반복하면 프로젝트를 언제쯤 끝낼 수 있을지 알 수 있습니다. 이 데이터를 사용하여 관리자는 프로젝트를 가능한 한 최선의 결과로 이끕니다. 데이터를 기반으로 의사결정을 하기에, 합리적인 조직이라면 프로젝트를 조정할 수 있습니다. 마감일은 못 바꾸더라도, 필수적인 기능부터 개발하고, 불필요한 기능은 뺄 수 있습니다. -------------- 어떻게? 데이터를 기반으로 프로젝트를 관리한다. 팀의 속도, 그리고 남은 일이 애자일에 필요한 데이터다. 왜 이래야 하냐고? 다시 말하지만, 마감일은 정해져있고, 요구 사항은 유동적인 것이 소프트웨어 프로젝트의 본질이기 때문이다. 애자일은 작은 반복주기(1~2주 단위)로 나눠 업무 속도와 진행률을 측정한다. 이것이 애자일의 데이터다. 이렇게 4~5 사이클을 반복하면 프로젝트를 언제쯤 끝낼 수 있을지 알 수 있다. 이 데이터를 사용하여 관리자는 프로젝트를 가능한 한 최선의 결과로 이끈다. 데이터를 기반으로 의사결정을 하기에, 합리적인 조직이라면 프로젝트를 조정할 수 있다. 마감일은 못 바꾸더라도, 필수적인 기능부터 개발하고, 불필요한 기능은 뺄 수 있다. 보다 구체적인 실천 방법은 뒤에 다시 설명하겠습니다. ----- 애자일은 어떻게 관리하는가? 데이터가 무엇인지, 그래서 무엇을 얻을 수 있는지를 장표에 추가하자
• #7: 이제 애자일을 구체적으로 어떻게 실천하는지를 살펴보겠습니다. 우선 비즈니스적 측면부터입니다.
• #8: 애자일 프로젝트는 계획부터 시작합니다. 우선 프로젝트를 작은 조각으로 쪼갭니다. 쪼개는 목적은 각 단위마다 필요한 에포트를 추정하기 위해서입니다. 쪼개는 단위는 스토리라 부릅니다. 스토리는 사용자 관점에서의 하나의 기능을 말합니다. 예를 들자면, ATM에서 돈을 인출한다. 가 하나의 스토리가 되겠습니다. 세부 사항은 생략하고 아주 간략하게 만듭니다. ----------- 기능 하나당 사용자 관점에서 아주 간략한 스토리로 만든다. 세부 사항은 생략. 여러 스토리가 나올 것이다. 계획은 어떻게 해야할까요? 프로젝트를 작은 조각으로 쪼개서 추정하자. 얼만큼 작게 쪼개나? 추정이란 본디 불확실하므로, 필요한 만큼만. 프로젝트 전체 계획을 위해서는 장기 추정 이 필요하다. 삼변량 분석 최선(정확도 5%), 최악(95%), 일반적 경우(50%)로 나눠서 추정 일상적인 관리에는 정밀도가 낮음 스토리: 기능 하나당 사용자 관점에서 아주 간략한 스토리로 만든다. 세부 사항은 생략. 여러 스토리가 나올 것이다. 스토리는 계속 추가, 삭제, 변경된다
• #9: 쪼개는 단위는 스토리라 부릅니다. 스토리는 사용자 관점에서의 하나의 기능을 말합니다. 예를 들자면, ATM에서 돈을 인출한다. 가 하나의 스토리가 되겠습니다. 세부 사항은 생략하고 아주 간략하게 만듭니다. 스토리는 작성의 원칙은 INVEST 로 정리할 수 있습니다. Independent: 각각 독립적이어야하고 Negotiable: 개발 스펙에서 제외하거나 더할 수 있으며 Valuable: 개발할 가치가 있어야하고 Estimable: 에포트와 가치를 측정할 수 있어야 한다 Small: 그러려면 물론 그 단위는 작아야 하겠지 Testable: 그리고 개발이 완료되었는지 테스트가 가능해야 한다
• #10: 각 스토리 당 필요한 에포트는 포인트라 합니다. 포인트는 시간 단위도 아니고, 맨먼스나 맨데이도 아닙니다. 오로지 추정한 노력의 단위입니다. 포인트는 최대한 객관적으로 추정합니다. 모든 구성원이 독립적으로 추정하고, 그 평균을 내는 방식을 많이 사용합니다.
• #11: 이제 프로젝트를 시작해보겠습니다. 우선 최초 추정 단계에서는 스토리를 여럿 만들고 포인트를 추정합니다. 첫번째 반복주기에서 개발자는 반복 주기 한 사이클 동안  몇 포인트나 처리할 수 있는지 추정하고 투자 수익률(ROI)를 계산하여 가치높고 저비용인 스토리를 골라 모읍니다. 개발자가 추정한 포인트만큼만 모으면 됩니다. 그리고 개발을 시작합니다. 주기 중 중간 중간 진행 상황을 확인하여 이번 주기의 스토리 처리 목표를 조정해 나갑니다. 첫번째 주기가 끝나면 이제 최초 단계에서의 추정이 얼마나 틀렸는지를 알 수 있습니다. 그리고 반복 주기 1회에 처리할 수 있는 노력 포인트를 알 수 있습니다. 그리고 이렇게 알게 된 포인트 처리량을 기준으로 다음 반복 주기 계획을 세우고 실행합니다. 스토리는 반복 주기 중에 새로 만들거나, 합치고, 쪼갤 수 있습니다. ----------------
• #12: 개발을 할 때는 가급적 스토리를 완전히 끝내는 데 집중하는 편이 좋습니다. 테스트는 각 주기의 시작과 함께 작성하고, 스토리당 테스트가 있으며, 테스트가 끝나면 그 스토리는 끝납니다. 매 주기가 끝나면 릴리스를 합니다. 릴리스 주기도 점점 줄일 수 있습니다. 물론 짧은 주기가 더 좋습니다. 피드백이 빨라지니까요. 이렇게 주기를 반복해 나가다가 마침내 더이상 구현할 가치가 있는 스토리가 없을 때 프로젝트는 종료됩니다.
• #13: 각 반복 주기가 끝날 때마다 속도 차트와 번다운 차트를 기록합니다. 속도 차트는 각 주기마다의 포인트 소진 속도를 나타내고 번다운 차트는 남은 스토리의 포인트를 나타냅니다 반복 주기를 몇 번 넘기면 그래프의 기울기가 보이기 시작할겁니다. 개발 속도는 일정한 게 가장 좋습니다. 만약 속도가 변한다면 무언가 문제가 있는 것이라 보고 조치를 취해야합니다. 속도가 오르면 개발자들이 일정 압박 때문에 거짓말을 하고 있다는 신호입니다. 속도가 떨어지면 코드 품질에 문제가 있어 점점 건드리기 어려운 코드가 되고 있다는 신호입니다.
• #14: 이러한 과정을 통해 믿을 수 있는 개발 일정을 뽑아낼 수 있습니다.
• #15: 이제 애자일을 위하여 우리가 어떤 팀이 되어야 하는지를 살펴보겠습니다. 팀 빌딩은 간단한 원칙을 지키는 것에서부터 시작합니다. 첫째, 모두가 이해할 수 있는 용어로 통일하여 사용해야합니다. 둘째, 지쳐 쓰러지지 않도록 적당한 속도를 유지해야 합니다. 셋째, 코드는 전체 팀의 공동 소유입니다. 어느 한 사람만 수정할 수 있는 사태는 피해야 합니다. 넷째, 자주 머지하고 배포해야 합니다. 그러지 않으면 머지하기 힘들어집니다.
• #16: 그리고 스탠드업 미팅입니다. 흔히 스크럼 미팅이라고 합니다. 스탠드업 미팅은 각자 최대 30초 동안 3가지 질문에 답합니다 지난 미팅 이후 무엇을 했는지, 다음 미팅까지 무엇을 할 것인지, 어떤 장애물이 있는지, 원한다면 ‘누구에게 감사하고 싶은지’ 를 말합니다 토론을 하거나 해결책을 찾을 필요는 없습니다. 짧게 끝내면 됩니다. 10분을 넘기면 안됩니다. 매일 할 필요도 없고, 반드시 참석할 필요도 없습니다. 최대 10분 진행합니다. 반드시 개발자만 말하고, 관리자나 다른 사람은 듣기만 할 뿐 끼어들면 안됩니다. 이렇게 각자 업무를 공유하는 자리가 스탠드업 미팅입니다. ======= 팀 내에서의 의사소통 스크럼 참석 필수 아님 각 팀의 일정에 맞게 할 것(매일 할 필요 없음) 최대 10분. ppt에 추가 최대한 빨리 끝내기 위해 스탠드업 미팅을 한다. 피티에 추가 각자 3가지 질문에 답한다 지난 미팅 이후 무엇을 했나? 다음 미팅까지 무엇을 할까? 어떤 장애물이 있는가? 토론, 설명을 할 필요없다. 1인당 30초 걸릴 것 필요하다면 4번째 질문을 추가하라. '누구에게 감사하고 싶은가’(옵셔널 하다고 괄호치고 써놓으라) 결론 작은 팀이 진짜 팀으로 일하는 법을 알아봤다. 위 설명이 의사소통의 언어, 서로를 어찌 대할지, 프로젝트를 어찌 대할지에 도움이 될 것.
• #17: 이제 개발자로서 우리가 어떤 일을 실천해야 하는지를 살펴보겠습니다. 사실 다 아는 것들입니다. 다만 실천하기 어려울 뿐입니다. 그래도 애자일의 핵심이니만큼 하는 게 좋습니다. TDD는 테스트 코드 먼저 만들고, 테스트를 통과하는 코드를 작성하는 것입니다 리팩토링은 코드 퀄리티를 위해 지속적으로 이루어져야 합니다. 대규모 리팩토링이라도 그렇습니다. 설계는 단순해야 합니다. 다만 적당히 단순해야 합니다. 너무 단순하기만 하면 복잡한 앱을 만들 수 없으니까요. 페어 프로그래밍은 하나의 팀이 되기 위한 최고의 방법입니다. 페어 프로그래밍을 하면 자연히 코드 리뷰가 되는 장점도 있습니다. ==== 이 실친방법은 강박증적인 행동으로 보일 수도 있다 그만큼 실천하기 어렵다는 얘기 그래도 빼놓을 수 없는 애자일의 핵심 테스트 주도 개발 반드시 하라. 구현은 2번 해야한다. 한 번은 테스트, 또 한 번은 코드. TDD 원칙 테스트 먼저 테스트 코드는 실패하기 위한 코드만 프로덕션 코드는 테스트 통과하기 위한 코드만 테스트 코드는 가장 좋은 문서이자 예제다. 테스트 코드를 나중에 만나면 귀찮아서 안하게 된다... 테스트 커버리지 90%면 충분 테스트 커버리지를 묙표나 목적으로 사용하면 안된다. 그랬다가는 개발자가 성공하는 테스트만 만들거다. 테스트 먼저 짜면 잘 분리된 설계가 가능하다. 테스트가 있어야 코드를 개선할 용기가 생긴다. 좀 생략. 다 아는 얘기니까. tdd 원칙 정도 까지만 얘기하라 ===== 코드의 구조를 개선하면서 동작은 바꾸지 않는 실천 방법 개발 순서: 우선 동작하게 하고 -> 코드를 정리한다 리팩터링은 일상적인 작업이어야 한다. 개발 중에 계속 하라. 대규모 리팩터링도 일상적으로 하라. 오래 걸리더라도 계속 하면 된다. 장표와 내용이 너무 다르다. 정의를 장표에 넣기보다는 실천 방법을 넣어라. 리팩토링은 항상 해야 한다는 내용 리팩터링은 일상적인 작업이어야 한다. 개발 중에 계속 하라. 대규모 리팩터링도 일상적으로 하라. 오래 걸리더라도 계속 하면 된다. 요거 ====== 설계는 단순해야 한다 규칙을 나열해보았다. 물론 말이 쉽지, 아주 어려운 작업이라는 건 안다. 목표: '설계 무게'를 가능한 가볍게 단 주의할 점은 설계가 복잡해지면 설계 무게가 늘어난다. 대신 복잡한 기능을 만들 수 있다. 설계의 복잡도와 기능의 복잡도 사이에서 균형을 잡자. 빼버릴까??? 단순한 설계를 하자. 를 주제로 써야한다. ====== 의무가 아니다. 잠깐씩 한다. 업무 비중은 50%가 좋다. 하지만 상황에 따라 유동적이다. 정해진 방법은 없다. 팀이 되기 위한 최고의 방법 페어 프로그래밍을 하면 코드 리뷰도 자연히 되는 장점이 있다 여럿이 해도 된다. 결론 이 모든 실천 방법들은 어렵지만 필수적 테스트, 짝 프로그래밍, 리팩터링을 해도 되냐고 허락을 구하지 말라. 니가 전문가니 니가 결정해라. 페어프로그래밍 방법도 예시를 들어보자 P145
• #18: 이제 실제 사례를 소개하겠습니다 라인 페이 개발팀에서 스토리 포인트를 활용해서 프로젝트를 진행한 사례입니다
• #19: 우선 스토리를 작성합니다. 사용자는 최종 사용자 뿐만 아니라, api를 사용하는 개발자도 포함했습니다. 스토리는 최대한 쪼갰고, 사용자 입장에서 가치있는 것들로만 추려내었습니다. 예를 들어 ‘일반 사용자는 로그인과 로그 아웃을 할 수 있어야 한다면, ‘로그인’과 ‘로그아웃’을 스토리로 뽑았습니다. 포인트의 기준이 되는 스토리는 앱은 UI 엘리먼트 전환 1건 당 1포인트 서버는 단순 정보 제공 API당 1포인트
• #20: 포인트는 오로지 사용자에게 가치가 있는 스토리에만 부여하기 때문에, 개발자로 하여금 사용자에게 가치를 주는 게 무엇인가 고민하게 해주는 계기가 되었다고 합니다 포인트는 피보나치 수열을 사용했는데, 각 숫자 사이의 간격이 큰만큼, 13 포인트 이상의 스토리는 더 잘게 쪼갰습니다 리팩토링은 포인트를 부여하지 않았습니다. 사용자 입장에서는 바뀔 게 없기 때문입니다 디버그 포인트도 0입니다. 원래 스토리의 포인트에 포함되어 있기 때문입니다. 리팩토링과 디버그는 스토리 포인트를 미리 땡겨 쓴만큼의 기술부채를 갚 는다는 개념으로 보았습니다. 이렇게 하면 리팩토링과 디버깅 하는 사람은 일을 안 하는 것 처럼 보일 수 있는데요. 특히 퇴사자의 버그를 해결하러 온 신규 투입자가 서러운 일이 있었다고 합니다 그러니 포인트는 개개인을 평가하기 위한 도구가 아니라, 팀이 어떻게 나아가고 있는지를 보여주는 수치라는 사실을 팀원 모두가 명심해야 합니다. 데이터 추출 요청에도 포인트를 부여했습니다. 사용자가 가치를 얻기 때문입니다. 다만 예전에 했던 작업의 날짜만 바꾸는 경우라면 0포인트를 부여하고, 신규 유형의 요청이면 쿼리의 어려움을 고려해 포인트를 부여했습니다.
• #21: 애자일하게 일하면 지속적으로 데이터가 발생합니다. 각 주기마다 얼마만큼의 포인트를 처리했는지부터 시작하여 버그라든가 사용자의 요청이라든가, 분류가 애매한 이슈도 있을 수 있습니다. 이러한 데이터를 분석해서 더 가치있는 일에 집중할 수 있도록 개선을 시도해야 합니다. 예를 들어 자주 요청되는 데이터 추출 건은, 사용자가 직접 뽑을 수 있도록 도구를 제공하는 방법이 있겠습니다 포인트를 다룰 때 주의할 점이 있습니다 아무래도 사용자에게 가치를 제공할 때마다 포인트가 쌓이니만큼, 이를 기준으로 평가를 하면 어떨까 생각하실 수 있겠습니다. 하지만 포인트를 그렇게 사용하면 안됩니다 우선 포인트 추정 기준은 각 팀마다 다르기 때문에 팀 평가에 사용할 수 없습니다 포인트를 기준으로 개인을 평가해서도 안됩니다 포인트는 팀에서 스토리 처리를 하려면 얼마나 어려운지를 나타내는 값일 뿐입니다. 포인트가 쌓인다는 건 팀의 현상황과 속도를 나타낼 뿐입니다. 만약 포인트를 기준으로 개인을 평가했다가는 개발자는 결국 포인트 처리를 과장하게 될 겁니다. 그랬다가는 포인트를 측정 기준으로 사용할 수 없게 됩니다. 이렇게 스토리와 포인트를 사용해서 프로젝트를 관리할 때는 항상 그 본질에 주목해야 합니다.
• #23: 너무 감동적이라 뺄 수 없었음 그래서 고객과 개발자 모두를 위해 애자일 권리장전을 선언합니다. 우리 개발자에게, 그리고 고객에게는 권리가 있다 이겁니다. 고객은 알 권리가, 개발자는 장인이 될 권리가 있습니다. 애자일 권리장전이 지켜지면? 개발자는 멋진 개발자가 되고, 고객은 만족한다. 여기서 애자일이 어느 범주에 속하는지 지금까지 제가 했던 정의를 뒤집겠습니다. 애자일은 방법론이 아니다. 소프트웨어 윤리 규범이다. ---- 이것도 앞서 설명한 내용. 중복할 필요 없음