20230619 estsoft 김충환
진짜 오랜만의 수업이구나!
돌아보기
- 1일차
- 기업과 나의 이해, 강점을 개발하고 약점을 보완하는 점검과 메타인지의 반복
- 2일차
- 야생학습과 학교학습의 차이.
- 개발자: 협상과 설득, 의견 조율 Product Owner
- 프로그래머: waterfall, SI(납기일을 중요시)
- 실수는 예방하는 것이 아니다. 관리하는 것이다.
- 3일차
- 미신 (완벽한 선생 / 전문가)
- 시각적 추상화, 협력을 통한 추상화 (UML)
- 객관성의 주관성 → 가치관/직관/감정이 품질과 의사결정에 아주 큰 영향을 준다.
- 개발자 또한 코칭능력이 중요. 때론 피드백하고 다독여주고, 쓴소리도 하고.
4일차 INDEX
- 질문 피드백 | 20230522 김충환 회고강사특강 질문
- 애자일 개론
- 칸반 & 스크럼
애자일
디지털 트랜스포메이션? 아니다, 이젠 AI 트랜스포메이션이다!
- 스크럼
- 30일마다 동작가능한 제품을 제공하는 스프린트
- XP
- 고객참여를 많이 유도. 테스트 우선 개발(TDD)을 토대로 개발
- 2001년에 Agile Manifesto + 2003년에 Lean SW라는 XP의 업그레이드 버전이 나오게 됨.
- 12원칙
- 가치있는 SW를 일찍, 자주 전달하여 고객의 빠른 피드백을 유도.
- 개발의 후반부일지라도 요구사항 변경을 환영.
- 변화를 활용해 고객의 경쟁력에 도움이 되게 하라. ==> 왜 진작에 고객의 요구사항을 발굴하지 못했어? 에 대한 책임감
- 작동하는 SW를 자주 전달하라. 2-3주에 한 번, 엔터프라이즈의 경우 분기당 한 번.
- 비즈니스 쪽 사람들과 개발자들이 날마다 함께 일하라.
- 부서별로가 아니라 프로젝트별로! 잡담에서 아이디어가 나온다!
- 동기부여가 된 개인 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경을 지원하는 것이 중요. 관리자에게 적극적으로 지원을 요청하라.
- 그들이 일을 끝내리라고 신뢰하라
- 면대면 대화
- 작동하는 SW가 진척의 주된 척도
- 퇴근하기 전에는 동작하게끔 (유닛 테스트라도)
- 지속가능한 개발을 장려. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
- Interrupt가 없게끔 환경을 만들어주자. 업무시간의 확보가 안되는 경우 관리자에게 적극적으로 지원을 요청하라.
- 일하는 티를 내라 X 시그널을 주거나 인지하라 O
- 기술적 탁월성과 좋은 설계 (수파리)에 대한 지속적 관심이 기민함을 높인다.
- 단순성이 필수. 낭비를 줄여라.
- 안 해도 되는 일, 요구사항 변동으로 인해 버려지는 일을 최소화
- 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발
- 외부에 있지 않다. 알고리즘이야 외부에서 착안할 수 있겠지만, 이것을 커스터마이징 하고 설계하고 구현하는 일은 내부에서 일어난다.
- "선수교체": 프론트, 미들웨어, 백엔드 개발자 세명이 진행중이다가 백엔드 개발이 진척이 느리다고 해서 새 백엔드 개발자로 교체한들 퍼포먼스 향상이 보장되지 않는다.
- 팀은 정기적으로 어떻게 더 효과적일지 숙고하고, 팀의 행동을 조율하고 조정한다.
- 효율: 기존의 노력을 줄여도 같은 성과
- 효과: 같은 노력으로 더 높은 성과
방법론
- 업무관리
- 프로젝트 관리, 대시보드(목표관리), 협업 고취, 툴 간에 연동, 결재, 일정관리, 거래처관리, CRM(Customer Relationship Management), 회계, ...
- 일하는 방식 | Framework
- Agile | Waterfall | Scrum | Kanban | Six sigma | CPM(Critical Pass Management) 병목현상 방지 | Lean | PMBOK | XP
- 프로젝트를 관리하는 툴 | PM-Tool
- monday.com / clickup / Hubspot / miro / notion / wrike / Asana / Swit / MS project / Redmine / Jira / VersionOne (OKR) / ScrumWorks / XPlanner+…
Scrum vs Kanban Board
-
WIP 제한
- Kanban 방식이 WIP에 개수를 제한하게 되면 자연스레 뭣이 중헌디? 를 추구하게 된다.
- Scrum 방식은 WIP에 따로 제한을 두지 않음. SNS의 형식으로(백로그) 전체 일감이 0이 될 때까지 달리는 식
-
- 혼란스러운 상황을 즐기는 문화 | 지식을 창조하고 창발하기 때문
- 조직 내에서 정보의 결핍을 피하기 위해 정보의 과잉을 만들어냄
- 팀의 멤버에게 자유로운 행동을 지향하는 열린 시스템
- 조직 구성원의 다양성 존중
- 추구하는 가치
- 약속, 전념, 정직, 존중, 용기(coaching)
- 진행양상
- 제품 백로그: 스토리 기반 요구사항 목록
- 스프린트: 반복적인 개발주기(이터레이션) | 2주 ~ 1분기
- 스프린트 계획회의: 스프린트의 목표, 백로그 계획
- 스프린트 백로그: 백로그를 위한 스프린트
- 일일 스크럼 회의: 어제 한 일, 오늘 할 일, 장애 현상 공유
- 실행 가능한 제품 배포 및 데모. 피드백. 다음 백로그에 적용.
- 역할
- PO(Product Owner): 백로그 정의, 우선순위
- Scrum Master: 프로젝트 관리자
- 팀원코칭, 문제상황 해결. | 고객, 관리자, 팀원이 모여 목표를 설정
- 1단계: 제품 백로그 만들기
- 스토리: 요구사항
- 태스크: 비기능 요구사항
- 결함: 결함
- DoD (Definition of Done): 백로그의 완결 조건
- 중요도: 10 ~ ∞, 반드시 중요도가 중복되지 않게끔
- 추정치: 속도를 추정. 상대적인 Man day 개념, 버퍼까지 들어간 주니어 기준 예상 소요일 | Planning Poker |
- 일 단위는 사실 아님| 걍 포인트 단위| 대-충. 개발자, 디자이너, 기획자가 모두 동시에 포커카드를 꺼낸다. 그러면 분명 예상 추정치가 다르겠지?1,2 포인트를 줄일건지, 다른 우선순위를 낮추고 포인트를 높일건지
- "기획자 알아서 주세요"가 절대로 아니다. | 동시에 꺼내기 때문에 선입견을 줄일 수 있다.
- 제품 백로그에서 볼 수 없던 세부적인 사항 (스프린트 백로그) 식별에 도움이 된다.
- 2단계: 스프린트 계획회의 아주중요