프로그램을 어떻게 설계해야하나?
- 디자인 패턴(MVC, MVVM, OOP)
- 프로젝트, 기능 설계 관점
협업을 어떻게 해야할까?
Agile
- 날렵한, 민첩한
- (생각이) 재빠른
폭포수 모델(Waterfall Model)
- 요구사항 분석 > 설계 > 구현 > 검증
하드웨어 개발에는 여전히 사용. 소프트웨어 개발에는 X.
- 문제점 1. 일단 한번 시작된 폭포수 모델은 중간에 고치기 어렵다.
하드웨어 개발에는 적용 가능하지만, 소프트웨어의 경우 업데이트가 느리다는 것은 치명적인 결점이다.
- 문제점 2. 분리된 책임/ 의사소통의 한계.
- 문제점 3. 정확하고 완벽한 문서화.
소프트웨어의 경우 변경점이 너무 많기 때문에 문서화하기도 어렵다.
- 문제점 4. 빠른 소프트웨어 시장에 대응하기 어려움.
소프트웨어 시장은 너무 빠르게 변화한다.
애자일 소프트웨어 개발 방법론
- 예측하기 어렵고
- 복잡하며
- 쉽게 변경된다.
는 관찰을 기반으로 만들어진 방법론.
개발 선언
- 개인과 상호작용 중시
- 작동하는 소프트웨어 중시
- 고객과의 협력 중시
- 변화에 대한 대응을 중시
유연한 의사소통/협업/빠른 가치 창출
스크럼
- 변화에 빠르게 대응하기 위해 서비스 가능한 최소한의 단위(MVP)로 먼저 개발, 유저의 피드백을 받아 새로운 가치를 계속해서 유저에게 전달하기 위해 워터폴 모델을 최소화하여 사이클을 여러번 돌린다.
- 개발자들끼리 어떤 업무를 하는지 적극적인 상호작용이 필요하다.
스프린트
- 워터폴 모델을 최소화한 사이클의 다누이.
- 스프린트가 진행될수록 프로그램이 점진적으로 개발된다.
- 포괄적인 문서보다 작동하는 소프트웨어 개발!
스프린트 회의
- 스프린트 때 해야할 작업 명시 및 추출
해야할 작업을 사용자 스토리(유저 스토리)라고 한다.
- 어떤 기능을 개발할지 정하는 것이 아니라, 어떤 가치를 유저에게 전달하는지 정하고 개발은 그 수단이 되어야 한다.
- 고객과의 협상!
사용자 스토리
- 사용자의 요구사항을 사용자 관점에서 이야기하는 것(가장 작은 비즈니스 가치)
일일회의(데일리 스크럼)
- 오늘 어떤 스토리의 어떤 태스크를 진행할건지, 어제 어떤 태스크를 진행했는지, 현재 문제가 되는 부분이 있는지...
기타 등등.. 을 팀원들과 공유
- 개인과 상호작용을!
스프린트 회고
- 주기마다 회고를 통한 프로세스 최적화.
지금 팀이 잘 굴러가고 있는지에 대한 회고 진행.
- 현재 팀 문화에 대한 건의사항
스프린트 진행 방향에 대한 회의
- 변화에 대응하기를!
결론
- 애자일하게 개발하자!
- 애자일하다는 것은 사용자의 관점에서 생각하고 기꺼이 변화를 받아들인다는 것.
- 애자일하게 개발하려면 스크럼을 해야 한다.
