- 상황에 맞춘 프로세스 / 방법론 / 도구 선택
- 수단을 목적으로 하지 말자. 목적은 항상 프로젝트의 완성이 되어야 한다.
- 커뮤니케이션
- 사람은 비슷한 사람들끼리 만남. 따라서 의견이 다양한 건 당연한 일. 오히려 다양한 의견을 도출해내자
- 의견이 안 좁혀진다면 한 가지를 고르고 구현 / 테스트 / 피드백
- 기본적인 예의( 비꼬기, 언성 높이기, 탈주)는 지키기
- 업무 프로세스
- 워터폴 모델
- 계획~구현까지 한 번에 끝내기
- 프로토타입 모델
- 고객의 요구사항을 파악할 때까지 계속해서 프로토타입 만듦. 요구사항이 개선되면 실제 제품 완성
- 나선형 모델
- 프로토타입이 계속해서 진화하여 결과적으로 실제 제품이 됨
- 애자일 모델
- 대부분의 팀이 사용.
- 전체적인 기능을 완성하는 프로토타입이 아닌 특정 작업을 진행하기 위한 스프린트 작업
중 하나 선택하기
선협님 추천 - 애자일 방법론 기반 극단적인 단축 프로세스
1. 1~3일 단위 짧은 스프린트 검토
2. 태스크 정리
3. 데일리 스크럼 및 작업 분배
4. 오늘 할 일 정리
5. 작업 및 커뮤니케이션
- 스프린트 / 태스크 정리
- 기능 요구사항 - 사용자에게 제공되는 기능
- 비기능 요구사항 - 서비스가 되어야 하는 품질
유스케이스 → 작은 단위(Feature, Refactor, Enhancement, Bug) → 스프린트 추가 → 기한 내에 완성
칸반 작업 활용하는 것도 좋다!
- 방법론 - 팀의 특성에 맞게
- 논리적 오류가 잦다 → TDD
- 도메인이 중요한 제품 → Domain Driven Design
- 기능 중심으로 개발하고 싶다 → Feature Driven Development
- 기능의 단위가 크고 복잡 → Usecase Driven Development
- 길고 복잡한 프로세스 → Scenario Driven Development
- 당장 정할 수 있는 규칙
- 기술 스택
- 커밋 메시지
- 코드 리뷰
- 브랜치 전략
- 컴포넌트 레이어
- 업무프로세스, 방법론
- Git flow or GitHub Flow