IT 업계의 조직 구성
목적 조직
- 프로젝트 A : 기획, 개발자, 디자이너
- 프로젝트 B : 기획, 개발자, 디자이너
- …
프로젝트가 커지면 관리가 힘듦
기능 조직
- 기획 : 기획자, 기획자, 기획자
- 클라이언트 : 개발자, 개발자, 개발자
- 서버 : 개발자, 개발자, 개발자
부서내 개발자마다 하는 프로젝트가 다름
개발 방법론
Waterfall 개발 방법론
- 명확한 요구사항을 가지고 프로젝트를 진행
- 장점
- 대략적인 일정 산출이 가능함
- 프로젝트의 시작과 끝이 명확함
- 단점
- 피드백 처리가 느리다
- 중간에 수정이 어렵다
Agile 개발 방법론
- 짧은 개발 주기를 가지고 피드백을 계속 반영하면서 진행
- 단점
- 프로젝트의 시작과 끝이 명확하지 않다
- 프로젝트 관리가 상대적으로 어려움이 있음
Kanban : 프로젝트 관리 도구
-
카드를 이용해서 “할일”, “진행 중”, “완료” 항목을 나누어서 각 테스크의 상태를 관리하는 보드
-
시각적인 표현을 통해 현재 작업들의 진행상태를 확인 가능 함
-
일반적으로 Trello, JIRA, Github에서 제공하는 툴들을 이용하여 사용
-
장점
- 시각적인 표현으로 확인 가능 -> 용이함
- 팀원들이 서로 어떤 일들을 하고 있는지 공유 가능
- 업무 우선순위를 효과적으로 정할 수 있음 -> 유연함
- 단점
- 전체적인 상황을 파악하기 어려움
Scrum
- Sprint Backlog : Sprint 목표를 위한 실제 작업 목록
- Daily Scrum Meeting : 각자 한 일들에 대한 공유
- Sprint Review Meeting : Sprint 목표가 잘 달성되었는지 확인하는 미팅
- Sprint Retrospective : Sprint에 대한 회고
테스트 코드의 중요성
- 새로운 코드를 추가하거나 리팩토링을 하는 경우 기존의 기능에 영향을 끼치는 경우가 많음
- 기존의 기능이 새로운 코드를 추가 했을 때 잘못된 행동을 일으키는지 검증하는 용도로 사용 가능
TDD 방법론
- 소프트웨어 개발자가 코드를 작성하기 전에 테스트 케이스를 작성하고, 테스트 케이스를 통과하는 코드를 작성하는 방식으로 개발을 진행
- 테스트 케이스 작성 -> 코드 작성 및 리팩토링 -> 테스트 케이스 실행 -> 성공 여부 확인을 반복적으로 진행하는 방법론
문서화
- 문서화는 두가지 관점에서 필요함
- 내가 개발하려는 기능의 스펙과 상세 구현에 대한 팀원들의 이해력을 높이는 것
- 내가 개발한 기능을 팀원들이 별다른 히스토리에 대한 기억없이 바로바로 찾아낼 수 있는 것