Software engineering
- 소프트웨어를 효율적으로 개발하기 위한 철학 및 방법론을 다룸
- 스프트웨어 개발의 가장 큰 리스크는 사람
- 협업 개발 중 커뮤니케이션을 줄이기 위해 규약, 툴을 사용한다 -> 진입장벽이 높아짐
소프트웨어 공학을 배워야 하는 이유
- 수많은 실무 현장 지식의 성공과 실패사례가 담긴 결정체
- 이미 검증된 것이 많다.
- 조직을 나에게 맞추는 것보다 자신을 조직에 맞추는 것이 빠름
- 신규 패러다임 도입 대비
소프트웨어 공학 분야
- 소프트웨어 요구사항
- 소프트웨어 설계
- 소프트웨어 개발
- 소프트웨어 시험
- 소프트웨어 유지 보수
- 소프트웨어 형상 관리
- 소프트웨어 공학 관리
- 소프트웨어 개발 프로세스
- 소프트웨어 공학 도구
- 소프트웨어 품질
폭포수 모델 (Waterfall model)
- 전통적인 개발 방법론
- 하드웨어(제조업) 개발 단계를 차용
- 요즘은 거의 사용하지 않는다.
애자일 (Agile)
- 개발 방법론들의 그룹
- 반복주기가 존재
- 반복이 지속되면서 요구사항과 솔루션이 동시에 진화
- 개인의 자발성이 필수
- 큰 그림을 보여주고 개발을 진행하면서 해상도를 높여간다.
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다
애자일 선언 이면의 원칙
우리는 다음 원칙을 따른다:
우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
작동하는 소프트웨어가 진척의 주된 척도이다.
애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.
기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
단순성이 – 안 하는 일의 양을 최대화하는 기술이 – 필수적이다.
최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
팀은 정기적으로 어떻게 더 효과적이 될지숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
eXtreme Programming
-
애자일 방법론의 일종
- Fine-scale feedback
- Pair programming (짝 프로그래밍, 고수-초보, 고수-고수)
- Planning game (동시에 일정 말하기)
- Test-driven development (테스트주도개발, 테스트코드를 먼저 작성)
- whole team (고객도 우리팀으로 만들어 개발에 참여시킴)
- Continuous process
- Continuous integration (지속적으로 통합, git, jenkins)
- Refactoring or design improvement (다른 사람 코드의 사이드이펙트)
- Small release (빠르게 릴리즈, 1일 1빌드, 고객에게 모두 공개)
- Shared understanding
- Coding standards (naming 등)
- Collective code ownership (팀이 코드를 동시에 소유, 누구든지 수정 가능하게, reasonable naming..)
- Simple design (알아보기 쉽게 코딩)
- System metaphor
칸반 (kanban)
- 일의 흐름을 시각화 (가용자원 및 병목지점 확인이 용이)
- 팀장이 일을 배분(push)하는 방식이 아닌 팀원들이 자기 능력만큼 가져감(pull)
- 다른 지식 노동에도 적용 가능
칸반 규율
- 시각화 (visualization)
- 작업의 단순화 (limiting work in progress)
- 흐름 관리 (flow management)
- 명시적인 정책 수립 (making policies explicit)
- 피드백 루프 활용 (using feedback loop)
- 협업 (collaborative) 및 실험 정신 (experimental evolution)
레드마인
스크럼
- 대략 3~10명 단위의 팀을 위한 방법론
- 스프린트라는 개발 주기를 갖는다.
- 1주~1달사이 보통 2주 매일 짧게 스탠드업 미팅을 갖는다.
- (서서하는 미팅) 대규모 팀을 위한 스크럼은 또 따로 있음
스크럼 핵심 규율
- 고객은 요구사항을 바꿀 것이다.
- 그리고 그 요구 사항이 무엇인지 예측하는것은 불가능하고 다만 그 요구 사항의 난이도는 높을 것이다.
스크럼 주요 용어
- 백로그(Backlog) : 요구사항 리스트, 제품의 개발 대상 목록쯤으로 이해하자. 애자일에서는 요구사항을 User Story라고 부른다.
- 스프린트(Sprint) : 애자일은 짧은 기간 동안에 동작하는 SW를 사용자에게 제공하면서 피드백을 받아서 고쳐 나간다고 하였다. 이 ‘짧은 기간’을 일반적으로 이터레이션(Iteration)이라고 하며, 스크럼에 서는 스프린트(Sprint)라고 한다. 보통 1주~4주의 기간을 상황과 조직에 맞게 선정한다.
- 제품 백로그(Product Backlog) : 전체 기간 동안 개발할 백로그를 제품 백로그라고 한다.
- 스프린트 백로그(Sprint Backlog) : 1개 스프린트에서 개발할 백로그들을 스프린트 백로그라고 한다.
역할 (role)
제품 소유자 (Product Owner)
- 팀당 한명 / 스크럼 마스터와 겸임 안됨
- 제품의 비지니스 영역에 집중 해야함
- 스테이크 홀더의 니즈 파악
- 우선순위, 범위, 예산, 일정을 협상
- 의사소통의 핵심 책임자 (공감능력)
- 팀이 기술적 해결 방법을 내는데 독재 하려 해서는 안됨
- 제품 개발 방향을 제시하는 조타수 역할
- 릴리즈를 정의함 (중요)
- 사용자 스토리작성 -> 우선순위 설정 -> 제품 백로그에 추가
- 제품 백로그를 눈에 보이게, 투명하게, 공정하게 하는 역할
개발팀 (Development Team)
- 각 스프린트 마다 제품을 발전 시켜 완성하는 역할
- 3~9명으로 구성
- 실제 제품을 만드는 사람 (기획자, 개발자, 디자이너)
스크럼 마스터(Scrum Master)
- 스크럼을 돕는 사람 / 코칭 (스크럼에 익숙한 사람)
- 스크럼 마스터 != 팀 리더, 프로젝트 매니저
- 목표를 도달하는데 장애요인의 제거가 목표 (버퍼 역할)
- 제품 소유자가 제품 백로그를 유지하는데 도움을 줌
- 팀이 해야할일을 잘 이해 했는지 관리
- 제품 개발의 완료 조건을 팀이 결정하는데 도움을 줌
- 스테이크 홀더에게 스크럼 교육
- 프로젝트 메니저(명령하는 사람)와 스크럼 마스터(경청하는 사람)의 차이