Skip to content

진짜 오랜만의 수업이구나!

돌아보기#

  • [[20230508 estsoft - 김충환 회고강사특강 - 애자일 회고 - 매슬로우의 욕구계층 - 만다라트 과제있음|1일차]]
    • 기업과 나의 이해, 강점을 개발하고 약점을 보완하는 점검과 메타인지의 반복
  • [[20230515 estsoft - 김충환 회고강사특강 - 3점조직 - 야생학습 - 자기계발은 복리 - 수파리 - 실수를 대하는 자세 {만다라트수정필요}|2일차]]
    • 야생학습과 학교학습의 차이.
    • 개발자: 협상과 설득, 의견 조율 Product Owner
    • 프로그래머: waterfall, SI(납기일을 중요시)
    • 실수는 예방하는 것이 아니다. 관리하는 것이다.
  • [[20230522 김충환 회고강사특강|3일차]]
    • 미신 (완벽한 선생 / 전문가)
    • 시각적 추상화, 협력을 통한 추상화 (UML)
    • 객관성의 주관성 → 가치관/직관/감정이 품질과 의사결정에 아주 큰 영향을 준다.
    • 개발자 또한 코칭능력이 중요. 때론 피드백하고 다독여주고, 쓴소리도 하고.

4일차 INDEX#

애자일#

디지털 트랜스포메이션? 아니다, 이젠 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단계: 스프린트 계획회의 아주중요

스크럼 2단계 부터는 다음시간에...#