애자일 프로세스

[parksunwoo]

Agile Planning for Software Products

강의 내용정리

• 스프린트 회의는 쉽지않고 추정치 산정은 항상 어렵다?

  추정치는 개발팀이 작업을 완료하는데 걸리는 시간에 대한 추측이다. 이전에 유사한 작업이 있었다면 이 추정을 기반으로 하는 것이 중요하다. 추정치는 협상의 대상이 아니어서 서로 다른 추정치를 이야기한다면 설명을 통해 하나의 추정치로 의견이 수렴되어야 한다.

  스프린트 마감일도 클라이언트와 약속한 시한도 역시 협상의 대상이 아니다. 마감일과 시한을 조정할 수 없다면 단지 그때까지 완료해야할 프로젝트 범위를 조정해야할 뿐이다

  추정치는 매번 변동되지만 팀의 전체적인 속도는 비슷할 것이다. 팀의 속도를 활용해서 적절한 워크로드 균형을 맞추어야 한다. 완료되지 않은 스토리를 절대 계산에 포함하지 마라

  추정치와 약속을 혼동하지 마라 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 %만큼 긴 시간이 걸린다는 점에 유의하십시오).

  어떤 사람이 한 번 (몇 주 또는 몇 달 전에) 무언가를 들었 기 때문에 그들은 무엇을해야하는지, 언제해야하는지 기억할 것이라고 믿습니다 (사람들에게 다가오는 활동을 상기시켜주는 시스템을 제자리에 두지 않고 약속)

  • 의사 결정 문제

  대안을 식별하거나 고려하지 않고 주요 결정을 내림

  참고자료 WHY DO PROJECTS FAIL? - 101 Common Causes

  불확실성과 화해하는 프로젝트 추정과 계획

  • 중요내용 메모

  • 1 문제, 그리고 목표

  • 이터레이션 동안 개발하는 기능은 사업 관점에서 바라본 우선순위에 따라 선정한다. 그래야 가장 중요한 기능들이 가장 먼저 개발되도록 할 수 있다.

  • 2 규모추정

  • 스토리 점수는 수행될 일의 규모에 대한 추정치다. 프로젝트 기간은 추정하는 것이 아니며, 프로젝트에 포함된 스토리 점수의 총 합을 팀의 속도로 나누어 구한다.

  • 이상적 작업일 '하루'를 '아무런 방해도 받지 않고 집중한 상태에서 작업에 몰두하는 여덟 시간'으로 정의한다면 여러분의 작업 환경에서 '이상적 작업일 하루'를 실제 경과 시간으로 환산하면 몇 시간 정도가 되리라고 보는가? 이런 상황을 개선하기 위해 어떤 조치를 취할수 있는가?

  • 가까운 미래에 구현을 시작해야 할 기능들로 꽤 신뢰성 있는 추정치를 필요로 하는 기능들은 그 크기를 작게 만들어 1에서 10 사이에 있는 1,2,3,5,8 이나 1,2,4,8 과 같은 비선형 수열 가운데 하나의 값으로

  • 부분적으로만 구현이 끝난 스토리에 대해서도 일정 점수를 주는 문제를 해결하는 가장 좋은 방법은 스토리의 크기를 충분히 작게 만들어 그 구현이 부분적으로만 끝날 여지를 두지 않는 것.

  • 3 가치 창조를 위한 계획 과정

  • 우선순위를 매길때 고려해야할 주요 요소들로는 다음의 네 가지가 있다

    • 해당 기능을 구현했을 때 얻을 수 있는 재정적인 이득
    • 새로운 기능을 구현하거나 지원하기 위해 발생하는 비용
    • 해당 기능을 구현할 때 획득하거나 새롭게 창조되는 지식의 양과 그 중요성
    • 해당 기능을 구현함으로써 제거되는 위험 요소들의 양

  • 요구사항들의 우선순위가 서로 다를 경우에는 그에 따라 스토리를 분할한다

  • 기능을 구현하기 위해 필요한 작업의 성격에 따라 스토리를 분할하는 것은 피하라 ← 개발기능 단위로

  • 4 일정배치

  • 현재 여러분이 수행하는 프로젝트는 일정 중심적인 프로젝트인가 아니면 기능 중심적인 프로젝트인가? 왜 그렇게 되었는가?

  • 멤버별 하루 가용시간 계산표를 작성해볼것. 어떻게 하면 각각의 팀원이 프로젝트에 투여하는 시간을 늘릴 수 있겠는가?

  • 기능에 관한 불확실성에는 기능 버퍼를, 일정에 관한 불확실성에는 일정 버퍼를 두어 프로젝트를 불확실성으로부터 보호해야 한다.

[parksunwoo]

• 생각하는 실제 스프린트 문제점
• 진행중에서 완료로 넘어가지 못한 task들은 작업이 명확하지 않고 모호하다 → 분석/설계에 더많은 시간을 쏟아서 해결해야함, 분석/설계까지도 더 쪼개야한다
• 반복되는 일보다 새로운 task 생기는 경우가 많다. 이런경우 추정치 측정을 어떻게 해야할까?
• 특정 task 가 예상시간보다 오랜 시간이 걸릴때 개발에서 시간이 오래걸릴때 다른 디자인/기획은 시간이 생김 이를 어떻게 해결? 더 자세한 계획으로? 애자일방식으로?
• KPT 사항은 개선되고 계속 참고 되어지고 있는가?
• 스토리간 우선순위는 어떻게 정하는 것이 좋을까? PO 와 대표가 함께, 이런 회의를 언제해야할까? 자주해야할까?
• 갑자기 치고 들어오는 업무를 어떻게 관리할 것인가?

[parksunwoo]

Problem / Try 이하 P. T.

❓ P. 진행중에서 완료로 넘어가지 못한 task들은 대개 작업이 명확하지 않고 모호하다 ✅ T. 작업 예상일이 2일을 넘어서고 모호한 task 는 작업의 성격에 따라 아래 4가지 분류로 나누어본다 작업의 성격: 문제점분석, 신규/수정 기능 설계, 개발, 테스트 기능타입: 생성, 조회, 수정, 삭제,

❓ P. 특정 task 가 예상시간보다 오랜 시간이 걸릴때 어떻게 처리할것인가? 더 자세한 계획으로? 애자일방식으로? ✅ T. 1주차 마지막 날에 재추정이 필요한 task 에 대해 재추정하는 작업을 진행 재추정은 그 스토리의 상대적 크기가 변경된 경우에만 한정되어 실시하고 부분적으로 완료된 스토리에 대한 재추정을 진행하고 완료된 task는 완료로 옮긴다,

❓ P. 반복되는 일보다 새로운 task 생기는 경우가 많다. 이런경우 추정치 측정을 어떻게 해야할까? ✅ T. 중간 정도의 크기를 가질 것으로 생각되는 스토리 하나를 골라, 스토리에 할당될 점수 범위의 중간쯤에 오는 값을 할당하는 방식을 지속하는 수 밖에 없다. 크기가 큰 경우는 위 4개분류를 적용해서 나누어야한다 일의 버퍼를 감안한 시간을 사용하고 3일(24)을 넘지 않게 사용하는 것도 방법이 될수있다. 추정치는 추정치일뿐, 맞지않는게 당연하다, 학습효과를 통해 다음 스프린트때 반영하는게 중요 추정치와 실제 결과치를 계속해서 측정필요

❓ P. KPT 사항은 개선되고 계속 참고 되어지고 있는가? ✅ T. 이전 스프린트 KPT 를 진행하는 스프린트 맨위에 올려두어 계속 체크 애자일 회고는 어떻게 하는가?

1) 잘한 것은 무엇인가? 2) 잘못한 것은 무엇인가? 3) 무엇을 배웠는가? 4) 아직도 안 풀린 궁금증은 무엇인가? 5) 향후 어떻게 다르게 할 것인가?

이 질문에 답을 할 때는 기술적인 측면과 사람 측면을 함께 다룬다. 예컨대 기술적인 측면으로는 "프로젝트 방법론"에 대해서, 사람 측면으로는 "팀 내에 팀워크"를 들 수 있다.

가장 중요한 것은 심리적 안정감.

회고를 절대 형식적으로 하지말자 스프린트에서 학습할수있는 기회로 삼아야함

• 시도해볼만한 다른팀 회고방식 : 스포카에서는 회고를 어떻게 할까?
  1. 온도 체크 (5분)
  2. 자료 모으기 (10분)
  3. 그룹으로 만들기 (10분, 휴식 5분)
  4. 더 이야기하기 (10분)
  5. 액션플랜 도출 (10분)
  6. 마무리 온도 체크 (5분)
  7. 회고의 회고 (5분)

❓ P. 스토리간 우선순위는 어떻게 정하는 것이 좋을까? PM과 함께, 이런 회의를 언제해야할까? 현재까지 진행된 스프린트 당 스토리 갯수 5번째 스프린트 (5개) - 6번째 스프린트 (6개) - 7번째 스프린트 (7개) - 8번째 스프린트 (4개) - 9번째 스프린트 (3개) - 10번째 스프린트(4개) ✅ T. 프로덕트 마일스톤을 가지고 이야기해야함, PM과 정기적으로 어떤자료를 가지고 소통할 것인가 월단위 진척 현황리뷰 및 이슈가 있을때 바로 협의하는게 이상적

❓ P. 갑자기 치고 들어오는 업무를 어떻게 관리할 것인가? ✅ T. 요청 채널을 일원화하고 (요청등록된 건에 순차적 진행) 마감시한이 있는 경우 함께 기재 스프린트 계획을 세울때 유지보수(요청포함) TASK 비율을 20% 정도 확보해두어야 한다 예) 팀의 스프린트 당 속도가 75라면 15정도는 유지보수 task 로 잡아야함

❓ P. test 단계를 따로 두어서 모든 task가 test 단계를 지나게 되는점 ✅ T. 테스트가 필요한 개발건은 따로 테스트 카드를 만들어서 진행한다 why? 모든 task가 테스트가 필요하지않다. 단계가 많아지면서 차트 소멸이 바로 반영되지 않는 단점이 있었음

단, 테스트 카드에는 검수자와 검수조건을 명시해서 테스트가 제대로 이뤄질수있게 함

예) 컨테이너 연결 노드정보 표기 Assign : (모두연) 박선우 착수일 : 2021, 04, 14 검수자 : (모두연) 홍길동

Description (검수조건) GIVEN, 클라우드 유저로 LMS 에 접속한 상황에서 WHEN, 이전 생성된 컨테이너가 있고 다시 새로운 컨테이너 생성요청을 할때 THEN, 컨테이너 안내팝업이 나오면서 안내팝업에 이미 연결되어있는 컨테이너와 연결 노드정보가 표기된다

테스트 시행전에는 테스트 시나리오 작성을 앞선 task로 진행해서 테스트를 계획적으로 진행하고 공통적인 테스트 시나리오 템플릿 작성으로 이어져야함

❓ P. 시한이 임박해서 테스트를 진행하는 경우가 잦다 ✅ T. 되도록 테스트 일정을 TASK 완료일 직전에 잡지않는다. 최소한 테스트는 남은 일정 중간에 1번, 일정 종료 3일 전에 2번째(최종) 테스트를 진행한다.

[parksunwoo]

• 스프린트 관리

프로젝트 리더가 스크럼 팀에서 스크럼 마스터일 필요는 없다. 스크럼 팀은 Product Owner(PO), Scrum Master(SM), Team Member 로 구성되어지며

SM은 일일 스크럼 미팅을 주관하고 도출된 이슈나 리스크들을 어떤 방식으로든 해결해줘야 하는 역할을 맡는다

스크럼을 늘어지지 않게 진행하고 길어지는 경우 SM이 적어 놓았다가 미팅 이후에 논의가 되도록 진행한다

• 일일 스크럼 미팅

본인의 컨디션을 간단히 이야기한다 - Check-in 어제 한일, 오늘 할일, 이슈 사항에 대해 공유한다

• 스프린트 리뷰 (스프린트 회고와 함께 진행)

팀원 전체가 모여서 각자가 한 일을 리뷰한다. 모두가 한 일을 모두를 대상으로 자세하게 공유하는게 중요

팀이 만든 산출물을 모두 함께 모여서 살펴보는 행위를 통해 다른 팀원을 이해

• 학습조직

팀이 매 스프린트를 함께함으로써 지속적으로 학습하고 성장하는게 중요함 이슈나 KnowHow, 해결방법을 검색가능한 위키 형태로 관리하면, 축적된 데이터가 팀의 지식자산이 되고 이는 결국 추정치를 정확히 추정하고 팀의 속도를 개선하는데 도움이 된다.

• 주 단위 사이클

매주 월요일 오전에는 Iteration Planning Meeting 을 통해 2-3주 정도 수행이가능한 백로그의 크기산정, 우선순위 하는 작업을 수행, 금요일 오후에는 회고 (Restrospect, Retro)

• 회의평가

회의를 하고나선 회의에 대한 평가도 진행하고 꼭 필요한 회의였는지? 개선하려면 어떤부분이 필요할지 고민필요

전체회의, 팀간회의, 팀회의는 스프린트에 넣고 추정치 산정까지 해야함

예) 전체회의 가 1시간 지연되면 팀전체적으로 3시간의 작업시간이 추가됨, 이걸 야근 1시간을 추가할것인가? 작업을 조정하고 앞으로 개선포인트로 삼을것인가?

순수하게 개인이 작업에 몰두할 수 있는 시간을 추정하기 위함