과거에는 SW가 자체가 수익의 목표였다. (ex. MS Office, Adobe Photoshop..) 하지만 지금은 open-source, web-site 기반의 서비스를 제공을 통해, 광고등을 주 수익모델로 하고 있다.
또한 과거에는 SW 개발기간이 길었으며, 거대 프로젝트 및 인력, 엄격한 deadline이 있었다. 하지만 요즘은 "서비스를 누가 먼저 생각하여 도입을 할 것인가"에 초점이 되어있으며, release하는 속도가 매우 빠르며, 사용자의 반응을 SW에 즉각적으로 반영하고자 한다.
waterfall 방식 (past)
개발의 체계화와 분업을 위해서 굉장히 많은 문서들을 필요로 하였다. 앞단계에서 뒷단계를 고려하여 상당하는 문서를 만들어서, 보다 명확하게 하고자 하였다. Waterfall 방식은 하지만 상황에 대한 대처가 부족하다는 단점이 있으며, needs에 맞는 변화 수용이 가능한 새로운 방법이 필요해졌다.
Agile Manifesto
Agile 개발 철학
1. 개인과의 상호작용을 프로세스와 도구보다 중시하였다
2. 작동하는 소프트웨어를 문서들보다 중시하였다
3. 고객과의 협력을 계약 협상보다 중요시하였다
4. 변화에 대한 대응을 중시하였다.
12 Principles of Agile Development
Agile manifesto가 추상적이니, 조금 더 구체화하여 12가지의 원칙들로 정리하였다.
- 고객(사용자)를 만족시키는 것이 가장 높은 우선순위다.
- 변화를 받아들이는 것을 중시한다
- 중간 결과물 SW를 자주 보여주어라.
- 서로 대화를 통해 소통을 많이 하여라
- motivated된 팀원들고 일을 하여라!
- 자주자주 얼굴을 보며 대화를 나눠야 한다.
- 작동하는 소프트웨가 주된 프로세스의 척도이다.
- 모든 프로세스들은 지속가능한 속도로 진행되어야 한다
- 지속적인 노력을 통해, self-motivated 되어야 한다
- 단순하게 하는 것이 필수적이다
- 자기 조직화 된 팀에서 최고의 결과가 나온다
- 팀은 정기적으로 효율성을 재고해야 한다.
Scrum
- 애자일 개발 철학에 따라, 소프트웨어 개발 자체에 중점을 두어 일을 관리하는 방법이다.
- Scrum을 통해 agile 정신에 따라 빠르게 시장에 대한 반응을 하며, 팀원들간의 interaction 위주로 작업을 진행한다.
- Sprint(주기)의 반복을 통해 개발을 하며, daily scrum을 통해 팀원들은 매일 짧은 시간의 미팅을 가진다.
Scrum process
▶ product backlog: 요구사항목록
▶ sprint backlog : 스프린트 미팅을 통해 정리된 작업의 목록
▶ sprint planning : 처음에 개발자들이 진행할 내용을 협의하고 각자의 역할을 정하는 행위
▶ daily scrum : 매일 sprint backlog에서 완료된 목록을 제거하고 팀원들과 공유하는 행위
▶ sprint review : 스프린트를 되돌아보고, 피드백을 줄 수 있는 단계이다.
DevOps
소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.
- 데브옵스는 운영 프로세스의 예측 가능성, 효율성, 보안, 유지보수 가능성을 극대화하는 것이 목적이다.
- 자동화 도구들이 중시되어, integration, testing, realse, management까지 모니터링
