애자일 & 스크럼 프로젝트 관리

http://www.yes24.com/Product/Goods/26879914

애자일 & 스크럼 프로젝트 관리 - YES24

회사에서 일을 하며 애자일 관련해서 고민하고 있는 부분들이 몇개 있는데, 그에 대한 해답을 얻고 싶어서 책을 읽기 시작했습니다. 몇 개는 파트에서 바로 적용해볼만한 내용도 있었고, 책에서 이야기하는 내용 중에 크게 공감되는 내용도 몇개 있었던 것 같습니다. 그런 내용을 정리해서 블로그에 포스팅으로 남기면 좋을 것 같아서 글을 작성합니다.

 

* 참고

👍 : 당장 파트에 반영해볼만함.

👀 : 개인적인 의견.

 

일정 관리

스티브 맥코넬: 합리적으로 설정한 일정에서 25% 이상은 줄이지 말아라. 그 이상에서는 절대로 달성 할 수 없기 때문이다.

톰 디마르코: 장기적인 야근은 주어진 일을 늘려서 할 뿐 초과근무로 인한 생산성 향상은 없다.

 

애자일 에서는 전체 기간 중 10~20% 범위에서 버퍼 스프린트를 삽입할 것을 권장한다.

 

👀 책에서는 모든 일의 복잡도 계수를 대략 0.8 정도로 잡는 듯.

 

복잡계

소프트웨어 프로젝트는 복잡 적응계다. 복잡계란 태풍의 불규칙한 진로나 기상이변, 부동산, 주식 같은 불규칙하고 복잡한 상호작용으로 다른 새로운 현상과 질서가 나타나는 시스템을 의미한다.

• 발주자들은 초기에 요구사항을 상세히 제시하기 어렵다보니 포괄적인 요구사항만 정해 놓고 발주를 진행한다. 그리고 업무 범위에서 변경되는 상세 요구사항의 변경들을 개발업체가 모두 수용해 주기를 바란다. 이는 비상식적이고 IT 산업의 경쟁력을 약화시키는 원인이다. 
• 프로젝트가 실패하는 가장 큰 이유는 요구사항이 불명확성 때문이다. 
• 과도한 분석 설계는 바람직하지 않으며 해당 요구사항이 분명하고 명확할 때 개발에 착수하는 것이 효과적이다.

 

제조업 문화

• 언제부턴가 야근을 하지 않으면 열심히 일하지 않는 사람이라는 인식이 우리 사회에 자리 잡았다. ... 이런 인식은 제조업 중심으로 발전한 우리나라의 산업 구조와 밀접한 관련이 있다. 제조업에서는 공장을 오래 가동할수록 성과가 올라가므로 업무 성과가 투입 시간에 비례한다고 생각하기 때문이다. 
• 우리 사고 방식은 모두 제조업에서 일하는 방식에 맞춰 있다. 
• 제조업과 소프트웨어는 다르다. 
• 소프트웨어 개발 분야에도 제조업이 대량 생산 방식은 그대로 적용되었다. 분석, 설계, 구현, 테스트 등 일련의 배치 단계를 겨쳐 해당 단계마다 기능 인력을 집중했다. 이런 방식은 제조업 처럼 단위 작업의 효율성을 높이려 했던 것인데, 이렇게 하면 고객에게 소프트웨어가 전달되는 리드 타임이 길어질 수 밖에 없다. 또 표준화된 절차와 규칙은 되려 개발자의 창의성을 저해하는 요인으로 작용했다.

👀 우리 프로젝트에 제조업 같은 잔재가 무엇이 있을까?

 

 

애자일 소프트웨어 개발 선언문

1. 프로세스와 도구보다 개인과 개인간의 상호작용에 더 큰 가치를 둔다.
2. 포괄적인 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다.
3. 계약 협상보다는 고객과 협력에 더 큰 가치를 둔다.
4. 계획을 따르기 보다는 변화에 대응하는 것에 더 큰 가치를 둔다.

 

애자일 소프트웨어의 개발 원칙 12가지

1. 소프트웨어 개발의 최우선 목표는 빠르게 높은 품질의 소프트웨어를 고객에게 전달하여 만족시키는 것이다.
   (👀 우리 팀은 고객에게 기능을 빨리 전달하고 있는가?)
2. 고객의 경쟁력을 위해서라면 개발 후반일지라도 요구사항 변경을 환영한다.
3. 동작하는 소프트웨어를 짧은 간격으로 자주 전달한다.
4. 고객과 개발자는 매일 함께 일한다.
5. 동기부여된 팀원과 함께하고 그들이 일할 환경을 지원하며 일을 잘 끝낼 수 있도록 신뢰한다.
6. 정보 전달의 가장 효율적인 방법은 서로가 얼굴을 마주 보며 대화하는 것이다.
7. 작동하는 소프트웨어가 진척의 주된 척도다.
8. 지속 가능한 개발을 장려하몀 개발 속도를 유지한다.
9. 기술적 탁월성과 좋은 설계에 갖는 지속적 관심이 민첩성을 높인다.
10. 하지 않을 일을 최대화하고 간단하게 한다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직화된 팀에서 창발한다.
12. 정기적으로 어떤 방법이 팀에 효과적인지 숙고하며 이에 따라 행동을 조율한다.

 

애자일 

• 애자일 프로세스는 관찰과 적응을 통하여 지속적으로 개선하는 경험적 프로세스다.
• 저자는 지난 20년간 직간접적으로 경험했던 대다수 중대형 프로젝트에서 개발 관리 산출물에 불만을 토로하지 않는 개발팀을 거의 본 적이 없다. 이런 방법론들이 강조되는 이유는 좋은 프로세스대로 일하다 보면 훌륭한 제품을 만들 수 있다는 가정이 기본적으로 깔려 있기 때문이다. 하지만 기업 나름대로 고민하고 적응하려는 노력 없이 만들어진 프로세스는 오래가지 못한다.
• 애자일 개발에서는 중간에 요구사항을 변경해도 다음 스프린트에 언제든지 반영할 수 있다. 폭포수 방식 개발을 하지 않는다는 것이 스프린트 안에서 분석,  설계, 구현, 테스트를 하지말라는게 아니다. 하되 공식적으로 산출물을 만들고 다음 단계로 넘어가는 형태를 하지 않는다는 것이다. 애자일 개발에서는 개발 범위에 상관 없이 스프린트 기간을 (2~4주일) 정도로 규칙적으로 잡는다.
• 애자일 세미나의 목표는 사람들이 애자일 개발 철학과 주요 내용을 이해하는 것이다.
• 스크럼은 단순한 프랙티스의 집합 이상이자 사고 방식의 변화다. 자기 조직화된 팀과 권한 위임, 지속적인 변화와 개선이 필요하다.

 

린의 주요 원리

1. 지속적인 가치 흐름을 확인하고 낭비를 제거한다.
   린 사고의 핵심은 고객의 요청부터 최종 배포까지 가치 체인을 연결하다 보면 대기 시간이나 과잉 생산 등 낭비 요소가 발생하는데, 이런 낭비 요소를 지속적으로 제거하라는 것이다.
2. 풀 시스템을 활용하여 과잉 생산을 피한다.
3. 사람이나 장비의 부담을 줄이고 오더의 불균일성을 제거한다.
4. 품질과 문제를 해결하는 스톱 문화를 구축한다.
5. 문제를 숨길 수 없도록 시각적으로 관리한다.
   도요타는 현장 모습을 시각적으로 보여 주는 작업 진행 상환판을 만들어 실시간으로 문제점을 찾으려고 노력했다.
6. 근로자의 책임과 참여하에 프로세스를 수립하고 지속적으로 개선을 추구한다.
7. 협력업체를 돕고 지원하여 동반 성장한다.
8. 지속적으로 개선, 학습하는 조직을 구축한다. 
9. 개발팀은 기능 혼합팀으로 구성하며 상호 협력한다.
10. 개발 과정의 낭비를 제거한다.

 

소프트웨어 개발의 낭비 요소 7가지

1. 미완성 작업
2. 추가 프로세스 (불필요한 프로세스)
3. 추가 기능 (불필요한 기능 추가)
4. 멀티 태스킹 (컨텍스트 스위치로 발생하는 몰입도 낭비)
5. 대기 시간 (의사 결정을 기다리는 시간)
6. 문서 전달
7. 늦게 발견된 결함

👀 우리 팀에서 낭비하고 있는 작업이 많다면 어떤 부분에서 낭비를 하고 있을까?

 

창조적인 일

미하이 칙세트미하이: 새로운 과제가 다시 지루해져 기존의 문제로 돌아갈때 아이디어가 떠오른다.

• 최신 기술에 관심을 갖고 실험할 수 있도록 시간적 여유를 제공해야 한다.
• 아무리 근무 환경이 쾌적해도 팀원이 열정적으로 재미있게 일하는 것과 단순히 돈을 버는 수단으로 억지로 일하는 것은 업무의 질적인 면에서 큰 차이가 있다.

 

👀 열정적고 창조적인 일을 할 수 있도록 지원할 수 있어야 한다.

 

짐 하이스미스: 애자일 프로젝트의 관리 목표

1. 지속적인 혁신
2. 제품을 적시에 출시
3. 확작성있는 제품을 출시
4. 사람과 프로세스의 적응력
5. 신뢰성 있는 결과

 

요구사항 이해관계자 식별

• 전통적 소프트웨어 개발에서는 요구사항을 도출할 때 소수의 분석가나 선임 개발자가 중심이 되어 요구사항을 도출했다. 애자일에서는 스킬이 다양한 팀 구성원과 고객이 함께 참여하여 요구사항을 도출할 수 있어야 한다.
• 프로젝트를 직접적으로 책임지는 이해관계자는 정기적으로 만나서 프로젝트의 진행 상황과 이슈, 협조사항 등을 논의하거나 스프린트 리뷰를 통하여 사용자 관점에서 피드백을 받아야 한다.

👀 우리의 고객은 누굴까?

 

백로그 관리

• 개발 성과를 정량적으로 파악하고 싶다면, 나중에 점검하거나 개발할 때 규모가 너무 작게된 스토리를 다시 추정하는 것도 괜찮다.
• 초기 제품 백로그는 그야말로 초기 계획일 뿐이며 프로젝트 진행에 따라 내부 스토리들은 언제든지 갱신할 수 있다는 것을 전제로한다. 

 

제품 백로그 작성 지침

1. 상호 독립적이어야 한다.
2. 변경이 가능해야 한다.
3. 사용자와 고객에게 가치가 있어야 한다.
4. 추정이 가능해야 한다.
5. 크기가 적절해야 한다. 
   프로젝트 상황에 따라 다를 수 있지만 1~2주일 이내에 수행할 수 있는 크기로 나누는 것을 권장한다. 스프린트 백로그의 크기는 2~3일 안으로 끝낼 수 있도록 분할하면 좋다. (👀 이것도 너무 큰거 아닌가?)
6. 테스트가 가능해야한다.

 

플래닝 포커

플래닝 포커가 기존 추정 기법과 다른 몇가지 특징을 정리하면 아래와 같다.

1. 프로젝트 참여자가 함께 토론함으로써 업무 이해도가 향상된다.
2. 다양한 전문가의 경험을 하나로 수렴한다.
3. 추정 과정 자체가 재밌다.
   (👀 우리 팀은 이 부분을 놓치고 있는 것 같아서 조금 아쉽다.)

 

👍 각 스토리의 시작일자와 완료일자를 지정하지 않는다. 지정해 봤자 일을 진행하면 수시로 바뀌기에 시작 일자와 완료일자를 관리하는 노력이 큰 의미가 없기 때문이다. 고객 입장에서는 해당 스토리가 스프린트에서 끝나기만 하면 되지 특정 완료 일자에 끝났다는 것은 그다지 중요하지 않다.

👍 팀원이 모두 스킬이 달라 독립적인 일을 한다면 추정은 각자가 단독으로 해도 무방하다.

 

스프린트 관리

• 고객 가치를 높이는 최선의 방법은 세부 요구사항을 초기에 모두 확정하기 보다는 필수 요구사항만 확정하고, 나머지는 스프린트 단위로 요구사항의 타당성과 우선순위를 조정하면서 개발하는 것이다.
• 통합 테스트 단계에서 개발팀의 주요 활동은 테스트 활동에서 발생하는 결함을 수정하고 안정화한다. 결함이 언제 어떻게 발생할지 모르기 때문에 스프린트 관리를 하기가 어렵다. 이때는 일주일 단위의 백로그 계획 미팅이나 데일리 스탠드업 미팅으로 진행상황을 고유하고 상호 협력한다. 
• 👍 스프린트 리뷰 절차에 개발팀은 구현된 기능을 보여주면서 개발 과정에서 발생되었던 고충이나 이슈를 함께 이야기한다.

👀 이미 너무 잘하고 있는데?

 

팀 사기 측정 (각 항목당 1~10점)

1. 나는 내가 하는 일이 즐겁고 보람 있다.
2. 우리 팀은 최선을 다해 서로 돕고 지원하려한다.
3. 우리 팀은 토론이나 회의를 매우 유익하게 행한다.
4. 우리 팀은 모두 해당 과제에 최선을 다해 매진한다.
5. 우리 팀은 갈등이 생겼을 때 빨리 해결하는 편이다.

 

프로젝트 리더와 애자일

같은 개발자를 설득하는 것조차 서툰 사람들이 많은 상황에서 어느날 갑자기 프로젝트 리더가 되어 요구사항 관리를 고객에게 논리적으로 설명하고 잘 진행하기를 바라는 것은 우물가에서 숭늉을 찾는 것과 같다.  ... 상대방을 단기간에 설득할 수 없다면 관심을 갖고 끈기 있게 당위성을 증명하면 된다. 대부분의 프로젝트 리더가 고객과 밀고 당기는 심리 게임에 익숙하지 않아서 불리한 조건에도 합의를 한다.

 

👀 결국 나도 준비해야하고 익숙해져야하는 것들

 

더글라스 맥그리거의 XY 이론적 관점

X 이론적 관점 : 대부분의 사람은 일하기 싫어하고 야심도 별로 없으며 지시를 받아야 움직인다.

Y 이론적 관점 : 사람은 동기부여가 되면 열심히 일하려 하고, 맡은 바 목표를 달성하려 스스로 계획하고 조정하는 능력이 있다.

 

경영자가 X 이론적 관점에서 벗어나지 못하는 경향이 있는 이유는 본인이 팀원일 때 자기 주도적으로 일을 수행한 경험이 거의 없어서다. 

 

 

짐 하이스미스: 애자일 프로젝트 리더가 가져야 할 마인드 셋

1. 지속적인 가치 흐름을 만들어 투자 수익률을 높인다.
2. 고객과 빈번히 상호 작용하여 신뢰할만한 결과를 만든다.
3. 프로젝트의 불확실성을 관리한다.
4. 개인이 가치의 창조 원천임을 인식하고 환경을 조성한다.
5. 결과에 공동으로 책임을 진다.
6. 우리에게 특화된 전략과 프로세스를 이용하여 효과와 신뢰성을 높인다.

 

오픈 스페이스 미팅

참석자가 자유롭게 이동하면서 관심 있는 주제를 찾아가 이야기하는 미팅. 아래 기본 원칙 4가지를 바탕으로 진행한다. 

• 누가 오든 오는 사람이 맞는 사람이다.
• 어떤 결과가 나오든 있을 수 있는 유일한 결과다.
• 언제 시작하든 시작하는 시간이 맞는 시간이다.
• 끝나면 끝난 것이다.

 

후기

애자일에서 가장 중요한건 "자기조직화 된 팀"을 만드는 것이라는 인상을 받았다. 구글 소프트웨어 엔지니어링 책에서는 이를 "자율주행 가능한 조직"이라는 말로 표현한다. 그리고 결국 종합하면 애자일에서 하고 싶은 말은 "소프트웨어 개발 자체가 복잡계이므로 표준화된 절차와 규칙을 통한 해결보다는 팀 자체를 어떤 상황에서도 대처 가능한 팀으로 만들어야한다." 가 아닐까?

 

책을 읽기 전에는 현재 팀에서 겪고 있는 몇몇 문제들의 해답을 얻고 싶어서였다. 예를들어 플래닝 포커를 하는데 시간이 굉장히 오래걸리고 쉽게 지루해지는데, 혹시 우리 팀에서 뭔가 잘못하고 있는게 있어서 그런게 아닐까? 그렇다면 다른 방식이나 새로운 도구를 도입하면 이를 해결할 수 있지 않을까? 같은 고민들 말이다. 아쉽게도 이러한 문제에 대한 답은 얻지 못한 것 같다. 대신 현재 겪고있는 문제가 굉장히 일반적인 문제이며, 보편적인 고민이라는 위로는 얻을 수 있었다.

 

그 동안 팀에서 어떤 고민사항이 있을 때 이를 해결하기 위해 프로세스나 새로운 도구를 도입하는 방식으로 해결책을 찾아보려했던 것 같다. 그런데 책에서 말하는 애자일은 어떤 프로세스나 해결책이 아니며, 정신 무장에 가까운 것이었다. 그래서 애자일을 달성하려면 조직 문화에 좀 더 집중해야한다라는 인사이트를 얻었다. 이런식으로 계속 생각하다보니 역설적이게도 뭔가 다른쪽에서 답을 얻을 수 있었던 것 같다.

 

이런 책을 읽을 때마다 좋은 소프트웨어 개발을 위한 방법론에서 꾸준히 언급되는 내용이 개발자의 행복이다. 재택근무가 시작된 이후 뭔가 그 동안 이런 부분에 대한 논의가 잘되지 못했던 것 같다. 아쉬우면서도 동시에 생각해보니, 우리 팀은 지난 스프린트 회고때 이미 이런 고민들에 대해 이야기하는 자리를 갖고 공감대를 형성해서, 개선하기 위한 방법을 시행하고 있다는 사실이 떠올랐다. 변화에 적응하고 계속해서 더 나은 방법을 고민하고 이를 시도하고 있는 것만으로도 우리 팀은 이미 애자일한 조직이지 않을까? 라는 생각도 들었다.