과거의 소프트웨어는..
- MS windows & Office, adobe photoshop, packaged game과 같이 소프트웨어 자체를 판매하였다.
- 개발기간이 길고 많은 자본과 인력이 투입되었다.
- 부동산/인프라와 같은 간접적 투자비가 높았다.
- 출시기간이 명확하였으며 엄격하게 지켜져야 하였다.
최근의 소프트웨어는..
- google & naver search service, free game with pay items, kakao & line instant messenger, ad-based free services와 같이 서비스 중심으로 판매된다.
- 소프트웨어는 도구적 관점에서 이루고자하는 서비스의 도구로써 인식되며 최대한 빠르게 출시되면서 제한된 인력과 비용을 사용한다.
- 시장의 요구사항을 충족하는 것에 집중한다,
- 소프트웨어가 최종 결과물이 아니기에 개발의 기반이 되는 소프트웨어를 협업하여 만들고 공유하며, opensource 환경 위 web을 기반으로 하는 기술이 발전하여 소프트웨어의 개발 과정이 크게 달라졌다.
Water-fall
- 전통적인 소프트웨어 개발 방법론, Plan-driven process의 일종
- 요구사항 분석 / 디자인 / 개발 / 테스트 / 유지보수 순으로 개발이 이루어지며 설계가 잘못되었다면 개발 과정 전체에 문제가 발생하기에 초기 과정에서 문제가 없도록 많은 시간을 투입한다.
benefits
- 소프트웨어를 구현하기 전, 굉장히 많은 분석과 고민이 이루어지기 때문에 후속 과정에서 발생할 수 있는 문제를 미리 고민하고 해결할 수 있다.
- 개발 과정의 초기 단계에서 문제를 발견한다는 것은 후속 과정에서 발견하는 것보다 적은 비용이 들며 더 낮은 위험성을 가진다.
- 상당량의 문서로 명확하게 작업과 결과를 규정하기 때문에 서로의 경험/이해 부족의 문제와 새로운 팀원의 교육과 관련된 문제를 최소화할 수 있다.
- 일관되고 절차적인 개발을 진행할 수 있으며 잘못된 의사소통과 error의 가능성을 줄인다.
- 개발의 진척에 있어 milestone을 제공한다.
- 엄격한 개발 구조는 팀원의 규율과 일정 관리 측면에서 효율을 가져다준다.
criticism
- 과정과 서류에 상당량의 시간을 사용함으로써 실질적인 소프트웨어 개발이 미루어질 수 있다.
- water-fall 구조 상에서 후속 단계로 지정된 절차를 진행함으로써 선행 절차의 문제를 해결할 수 있다. 하지만 엄격한 구조로 인해 앞선 단계를 진행하기 전 후속 단계를 진행하지 않음으로써 앞선 단계가 불완전하게 끝날 가능성이 있다.
- 고객의 요구사항 변화는 불가피하며 water-fall model에서 요구사항 변화는 많은 인력과 비용 소모를 유발한다.
- 이전 단계에서의 고민과 요구사항 분석에 대한 신뢰성 문제가 발생하며 후속 과정을 진행하면서 여전히 유효한가에 대해서도 문제가 발생한다.
- 소프트웨어 개발 도구로써 선택된 프로그래밍 언어와 도구가 구식 기술일 수도 있다.
- 이전 단계에서 고려한 사항을 후속단계에서 모두 끝내지 못한다는 불확실성이 존재한다.
- 서비스 중심의 빠른 개발과 업데이트가 필요해진 최근 IT 비즈니스 모델과 맞지 않는다.
Agile (개발 방법론 / 철학 / 조직문화)
개발자는 스스로 동기 부여하고 자기발전하며 스스로 공부하고 나누려는 사람이여야 한다.
Agile Manifesto (vs Waterfall)
- Individuals and interactions over process & tools
- 공정과 도구보다 개개인의 능력과 노력, 서로의 상호작용
- Working software over comprehensive documetations
- 포괄적인 문서보다 소프트웨어, 소프트웨어에 대한 가치와 애정
- Customer collaborative over Contract negotiation
- 계약협상보다 고객과 협력
- Responding to change over following the plan
- 계획보다는 시장 반응에 대응, 계획은 수단일 뿐 목표에 따라 변화
12 Principles of Agile Development
- 고객 만족 - 의미 있는(사용자가 만족할 수 있는) 소프트웨어
- 변화된 요구사항을 환영 - 시대에 따라 바뀌는 고객의 요구사항에 대응
- 소프트웨어의 주기적인 배포
- 개발자와 고객과의 대화와 협력
- 프로젝트를 수행할 때는 Motivated 사람들 모아 환경을 제공하고 Trust해라.
- 효율적이고 효과적인 정보 전달은 Face to Face 상호작용
- 인터넷을 통한 원격회의, 물리적으로 멀어도 얼굴을 보며 회의를 해야한다
- 화상회의는 사담이 적은 경우가 많으므로 5~10분 정도 일상적인 대화를 하며 신뢰감을 쌓아야한다.
- 작동하는 소프트웨어 (최소한의 문서도 필요하다)
- 지속 가능한 개발 - 고객, 개발자, 사용자가 전 과정에서 유기적으로 연결
- 끊임없고 지속적인 자가발전 - Self-Motivation and Self-Learning
- 간결성 - 가장 중요한 것을 중심으로 단순화
- Self-organizing teams
- 주기적인 재검토 - 논의와 토론, 개선과 반영
SCRUM - Agile 개발방법론(Agile Framework)
- sprint를 진행하며 software개발에 착수하면 15분 정도의 stand-up meeting을 통하여 계획을 재수립하고 수정한다(daily scrum).
sprint
- 3~9명의 개발자로 이루어진 개발팀이 작업을 분담하여 timeboxed iteration 내에 작업을 수행한다.
time boxing
- 반복형 개발에서 쓰이는 프로젝트 기획/관리 기법으로, iteration에서 할당된 작업을 완수하지 못하였을 경우 다음 iteration으로 넘긴다는 지극히 단순하고 간단한 규칙의 일종
scrum 단계
backlog
- 전반적인 기능과 요구사항을 나열한다.
Sprint planning
- 우선 순위 중심으로 가장 중요한 것부터 구현하며 기능을 분할한다.
sprint & scrum
- 소프트웨어의 주기적인 배포
review
- 개발 완료 후 시장의 반응에 따라 재수정 등의 논의와 토론이 이루어지고 소프트웨어에 반영한다.
DevOps - 개발 문화 / 개발 철학
- 개발과 QA(원하는 성능과 기능을 검증), 운영을 동시에 즉, 개발과 운영이 밀결합 되어 있는 형태의 개발 철학이자 문화를 의미한다.
- 기존에는 개발팀과 운영팀이 따로 존재하였지만, 최근 빠르게 소프트웨어를 개발하고 서비스를 제공하고, 그에 따른 피드백도 빠르게 운영에 반영해야하기에 software build의 자동화가 이루어져야 했으며 이에 따른 자동화를 위한 여러 도구들이 등장하였다.
DevOps Tools
KHU, SWCON