코세라 Agile Planning for Software Products 강의를 듣고 Agile을 다시 정리해보았습니다
2020년 11월, 우리는 지금까지 일하던 방식을 바꾸기로 했다
애자일 방식으로 일하게 되었고 스크럼과 회고를 시작했다
매일 미팅을 하면서 진행되는 상황들을 체크하기 시작했다, 개인이 아닌 팀단위로
분쇄기에서 In progress 로 그리고 Completed 로 신나게 옮기고 소멸차트를 그렸다
그리고 3개월이 지났다
소멸차트의 선은 예상과 달리 먼 곳을 향하기 시작했고 스프린트 미팅은 으레 2주 단위로 돌아오는 형식적 회의가 되고 있었다
| 1- 3 회 스프린트 | 4- 6 회 스프린트 |
|---|---|
 |
 |
 |
 |
 |
|
어디서부터 잘못된걸까? 애자일 프로세스를 다시 세우기위해 애자일을 다시 공부하며 정리해보았다
스프린트 회의는 쉽지않고 추정치 산정은 항상 어렵다?
추정치는 개발팀이 작업을 완료하는데 걸리는 시간에 대한 추측이다. 이전에 유사한 작업이 있었다면 이 추정을 기반으로 하는 것이 중요하다. 추정치는 협상의 대상이 아니어서 서로 다른 추정치를 이야기한다면 설명을 통해 하나의 추정치로 의견이 수렴되어야 한다.
스프린트 마감일도 클라이언트와 약속한 시한도 역시 협상의 대상이 아니다. 마감일과 시한을 조정할 수 없다면 단지 그때까지 완료해야할 프로젝트 범위를 조정해야할 뿐이다
추정치는 매번 변동되지만 팀의 전체적인 속도는 비슷할 것이다. 팀의 속도를 활용해서 적절한 워크로드 균형을 맞추어야 한다. 완료되지 않은 스토리를 절대 계산에 포함하지 마라
추정치와 약속을 혼동하지 마라 7개월정도 걸리는 작업량을 갖고 7개월이라는 약속시한을 잡아선 안된다
팀의 속도를 향상시키는 방법은 무엇일까?
- 기술 부채를 갚기 위해 점진적으로 개선작업을 진행할 것
- 프로그래머가 고객에게 편하게 질문하고 답을 들을 수 있어야 한다
- 초과근무 금지, 생산성이 낮아진다
- 프로그래머가 불필요한 회의에 방해받지 않도록 보호해야할 의무
- 작업기기를 비롯 필요한 자원을 제공해야 함
- 신입 직원이 적응후 생산성을 높이려면 1-2 개월 걸릴 것으로 예상하라
스토리 포인트
- 시간 기반 추정치는 약속으로 오해될수 있다
- 작업 추정치를 시간이 아닌 스토리 포인트로 계산하라
- 스토리 포인트는 단위가 작고 상대적이다
- 예를 들면 큰 건물의 크기를 예측할 때, 큰 건물의 크기는 옆에 있는 작은 건물의 3배이다. 상대적으로 그 크기를 측정할 수 있음
- 피보나치 수열 값을 사용해라 why? 추정치 6을 사용하고 싶다고 해서 그대로 사용하기 보다 반올림한 8을 사용함으로써 전체적인 불확실성을 감소시킬수 있다 (여유를 만들어서)
스프린트 설정
- 2주단위의 스프린트 기간을 설정하는 이유는 기한을 정하지 않으면 작업범위가 확장되고 작업시간이 느려지는 경향이 있다. 스프린트 기간을 한정함으로써 그 시간에 집중해서 작업을 진행하는 time boxing 효과를 갖는다
- 사용자 스토리의 우선순위는 클라이언트를 포함해서 지정한다
- 스프린트를 설정함으로써 목표가 무엇이고 그 시간까지 수행해야할 작업을 쉽게 확인하는 효과가 있음
- 속도 중심의 스프린트 계획은 단기가 아닌 장기적으로 유용하다 처음 사용하거나 일부 문제가 있는 팀의 경우 서약 중심의 스프린트 계획을 세워라
- 속도 중심적인 방법에서는 추정된 속도치에 맞게 스토리들을 먼저 다 골라 놓은 다음에 시작하지만 서약 중심적인 방법에서는 스토리를 선택하고 작업들로 분할하고 추정하는 과정이 스토리별로 차례대로 이루어지는 차이점이 있다
- 진행중인 스프린트가 이전 스프린트와 다르게 하드웨어 결함이나 기타 다른 이유로 문제에 처해있는 상황이라면 이전 스프린트 중 가장 느린 속도를 사용해야함
- 개발자의 작업은 1-2일 분량으로 나뉘어져야함
Anti-patterns
- Viewgraph Engineering
개발자가 소프트웨어를 개발하기보다 그래프와 문서작업에 치중하게 되는 현상. 관리자 입장에서는 적절한 개발 산출물을 얻을 수 없고 엔지니어는 다이어그램과 보고서 작성을 위해 문서작성 프로그램을 사용하는데 집중
- Death by Planning
소프트웨어 프로젝트에 대한 과대한 계획설정이 복잡한 일정을 가져옴
- Intellectual Violence
이론과 기술지식에 대한 이해도가 높은 사람이 이러한 지식을 이용해 회의에서 다른 사람을 위협
- Project Mismanagement
소프트웨어 개발 프로세스에 대한 관리부재는 방향성을 잃게 하고 다른 부작용을 가져옴
성공적인 개발 활동을 위해선 적절한 모니터링과 프로젝트 관리가 필요하다. 소프트웨어 개발은 마천루를 짓는 것만큼이나 복잡하고 많은 단계를 포함하는 활동이다. 때때로 주요한 활동들이 축소되거나 쉬운일로 여겨진다
- E-mail Is Dangerous
이메일은 소프트웨어 관리를 위한 중요한 커뮤니케이션 수단이지만 불행히도 다양한 주제와 민감한 팀원과의 소통에서는 적절한 수단이 아니다. 직접 대화를 통한 커뮤니케이션이 선호된다
프로젝트가 실패하는 이유는 무엇일까?
- 목표와 비전
프로젝트의 목표를 조직에 전달하고 계획의 초점으로 사용할 수 있는 간결하고 명확한 비전으로 정리하지 못함
프로젝트 목표가 조직 전체 전반적인 비즈니스 목표 및 전략과 불일치
- 리더십과 거버넌스
세 가지 리더십 영역 (비즈니스, 기술 및 조직) 중 하나 이상에서 효과적인 리더십을 구축하지 못함
프로젝트 관리자는 사람들을 하나로 모으고 일을 실현할 수 있는 대인관계 또는 조직기술이 부족
적절한 수준의 프로젝트 감독을 찾지 모함 ( 프로젝트 관리자가 프로젝트를 미세 관리하여 팀의 동기를 잃거나 프로젝트가 통제 불능 상태가 되도록 충분히 면밀히 추적하지 못함)
- 이해 관계자 참여 문제
이해 관계자의 눈으로 프로젝트를 보지 못하면 프로젝트가 이해 관계자에게 어떤 영향을 미칠지 또는 그들이 프로젝트에 어떻게 반응 할 것인지를 이해하지 못하게 됨
프로젝트에 관련된 개인, 그룹 또는 조직 간의 효과적인 커뮤니케이션을 설정하지 못함
- 팀 문제
명확한 역할과 책임이 없으면 혼란, 오류 및 누락이 발생
약속한 작업을 완료하기에는 팀 구성원이 부족
팀 구성원은 새로운 스프린트 계획을 실행하는 동시에 풀타임 운영 작업을 수행해야 함
최고의 자격을 갖춘 사람을 기다리지 않고 역할을 수행할 수 있는 첫번째 사람을 선택함
이미 늦은 프로젝트에 더 많은 리소스를 추가하면 리더십에 부담이 가해져 팀 성과가 훨씬 낮아짐
- 요구 사항 문제
모호하거나 개방적인 요구 사항 (etc로 끝나는 요구사항)
프로젝트가 종료 된 후 작동하는 제품이 나와야하는 운영 상황을 이해하지 못함
- 견적
실제로 작업을 수행할 사람이 견적 과정에서 제외됨
불충분한 정보 또는 분석을 기반으로 추정이 이루어짐 (빠른 예상치가 확고한 약속이 됨)
큰 티켓 항목은 추정되지만 눈에 잘 띄지 않는 소규모 활동은 생략
이전 프로젝트에서 쌓인 추정치 데이터를 다시 참조하지 않고 추정이 수행됨
팀에서 사용하는 새로운 도구, 프로세스 또는 시스템이 즉각적인 생산성 향상을 제공한다고 가정
- 계획
복잡성에 대한 과소평가
추정치가 비생산적 시간을 위한 공간이나 여유버퍼없이 경과된 작업 기간과 동일할 수 있다고 가정
경영진 또는 고객 기대치를 관리하지 못함
대규모 마스터 플랜을 점진적으로 제공 할 수있는 관리하기 쉬운 부분으로 나누지 못함
팀은 일정을 준수해야하는 다른 그룹 및 이해 관계자로부터 먼저 해당 약속을받지 않고 자신 스스로 일정을 약속합니다 (일명 자살 일정).
일부 팀 구성원은 과부하로 인해 프로젝트의 중요한 영역에서 성능이 저하되는 반면 다른 구성원은 활용도가 낮습니다. 요구 사항의 우선 순위가 지정되지 않아 팀이 우선 순위가 높은 작업 대신 우선 순위가 낮은 항목에 에너지를 집중하게됩니다.
프로젝트 계획의 일부로 적절한 팀내 문화 활동을 포함하지 않음
프로젝트에서 생산 된 제품을 운영 환경에 배포 할 때 충분한 사용자 교육을 제공하지 못함
변경 요청은 그 의미를 평가하거나 일정 및 예산 변경에 동의하지 않고 비공식적으로 처리
- 위기관리
미리 잠재적 문제를 예측하지 못하고 해결하지 못함 결과 팀이 실제로 위험 관리를 수행하지 않기 때문에 위험, 문제 및 문제가 혼동됩니다.
- 건축과 디자인
팀은 전체 아키텍처 또는 여러 구성 요소가 함께 통합되는 방법을 먼저 생각하지 않고 개별 구성 요소 개발을 시작합니다. 아키텍처의 부족은 노력의 중복, 격차, 예상치 못한 통합 비용 및 기타 비 효율성을 초래
제품, 시스템 또는 프로세스를 설계 할 때 비 기능적 요구 사항 (특히 성능 요구 사항)을 고려하지 않으면 결과물이 운영상 사용할 수 없게됩니다.
특정 도구로 모든 문제를 해결하려고 노력하는 이유는 해당 도구가 현재 작업에 잘 맞기 때문이 아니라 잘 이해되어 있기 때문입니다.
- 품질
품질을 확인할 수있는 적절한 검토, 테스트 또는 체크 포인트를 프로젝트에 계획하지 않음
프로젝트에서 생성 된 개별 구성 요소의 통합 및 테스트는 문제를 조기에 발견하고 수정하기 위해 지속적인 점진적 감사와 검증을 수행하는 대신 모든 개발 활동이 완료 될 때까지 남겨집니다.
- 프로젝트 추적 및 관리
팀이 일정이 늦었지만 나중에 따라 잡을 것이라고 믿습니다.
고객, 관리자 및 이해 관계자에게 발표 할 때 나쁜 소식이 무시됩니다
팀 구성원이 보고한 작업이 실제로 90 % 완료되었다고 믿습니다 (종종 마지막 10 %가 처음 90 %만큼 긴 시간이 걸린다는 점에 유의하십시오).
어떤 사람이 한 번 (몇 주 또는 몇 달 전에) 무언가를 들었 기 때문에 그들은 무엇을해야하는지, 언제해야하는지 기억할 것이라고 믿습니다 (사람들에게 다가오는 활동을 상기시켜주는 시스템을 제자리에 두지 않고 약속)
- 의사 결정 문제
대안을 식별하거나 고려하지 않고 주요 결정을 내림
참고
Agile Planning for Software Products
WHY DO PROJECTS FAIL? - 101 Common Causes