Agile하게 협업하기

김재현·2022년 8월 16일
0

오프라인 특강

목록 보기
9/12

프로그램을 어떻게 설계해야하나?

  • 디자인 패턴(MVC, MVVM, OOP)
  • 프로젝트, 기능 설계 관점

협업을 어떻게 해야할까?

  • Git, GitHub

Agile

  1. 날렵한, 민첩한
  2. (생각이) 재빠른

폭포수 모델(Waterfall Model)

  • 요구사항 분석 > 설계 > 구현 > 검증
    하드웨어 개발에는 여전히 사용. 소프트웨어 개발에는 X.
  • 문제점 1. 일단 한번 시작된 폭포수 모델은 중간에 고치기 어렵다.
    하드웨어 개발에는 적용 가능하지만, 소프트웨어의 경우 업데이트가 느리다는 것은 치명적인 결점이다.
  • 문제점 2. 분리된 책임/ 의사소통의 한계.
  • 문제점 3. 정확하고 완벽한 문서화.
    소프트웨어의 경우 변경점이 너무 많기 때문에 문서화하기도 어렵다.
  • 문제점 4. 빠른 소프트웨어 시장에 대응하기 어려움.
    소프트웨어 시장은 너무 빠르게 변화한다.

애자일 소프트웨어 개발 방법론

  • 소프트웨어 개발이
  1. 예측하기 어렵고
  2. 복잡하며
  3. 쉽게 변경된다.
    는 관찰을 기반으로 만들어진 방법론.

개발 선언

  • 개인과 상호작용 중시
  • 작동하는 소프트웨어 중시
  • 고객과의 협력 중시
  • 변화에 대한 대응을 중시

유연한 의사소통/협업/빠른 가치 창출

스크럼

  • 변화에 빠르게 대응하기 위해 서비스 가능한 최소한의 단위(MVP)로 먼저 개발, 유저의 피드백을 받아 새로운 가치를 계속해서 유저에게 전달하기 위해 워터폴 모델을 최소화하여 사이클을 여러번 돌린다.
  • 개발자들끼리 어떤 업무를 하는지 적극적인 상호작용이 필요하다.

스프린트

  • 워터폴 모델을 최소화한 사이클의 다누이.
  • 스프린트가 진행될수록 프로그램이 점진적으로 개발된다.
  • 포괄적인 문서보다 작동하는 소프트웨어 개발!

스프린트 회의

  • 스프린트 때 해야할 작업 명시 및 추출
    해야할 작업을 사용자 스토리(유저 스토리)라고 한다.
  • 어떤 기능을 개발할지 정하는 것이 아니라, 어떤 가치를 유저에게 전달하는지 정하고 개발은 그 수단이 되어야 한다.
  • 고객과의 협상!

사용자 스토리

  • 사용자의 요구사항을 사용자 관점에서 이야기하는 것(가장 작은 비즈니스 가치)

일일회의(데일리 스크럼)

  • 오늘 어떤 스토리의 어떤 태스크를 진행할건지, 어제 어떤 태스크를 진행했는지, 현재 문제가 되는 부분이 있는지...
    기타 등등.. 을 팀원들과 공유
  • 개인과 상호작용을!

스프린트 회고

  • 주기마다 회고를 통한 프로세스 최적화.
    지금 팀이 잘 굴러가고 있는지에 대한 회고 진행.
  • 현재 팀 문화에 대한 건의사항
    스프린트 진행 방향에 대한 회의
  • 변화에 대응하기를!

결론

  1. 애자일하게 개발하자!
  2. 애자일하다는 것은 사용자의 관점에서 생각하고 기꺼이 변화를 받아들인다는 것.
  3. 애자일하게 개발하려면 스크럼을 해야 한다.

0개의 댓글