[Software Engineering] 애자일(Agile) 소프트웨어 개발

📍 Agile Methods 애자일 방법론

* 애자일 소프트웨어 개발을 위한 4가지 원칙

1. Individuals and interactions over processes and tools 개인과 상호작용에 집중
2. Working software over comprehensive documentation 작동하는 소프트웨어에 집중
3. Customer collaboration over contract negotiation 고객 협력
4. Responding to change over following a plan 변화에 대응

* 변화에 드는 비용 Graph

• 기존 방법론에서는 프로세스가 진행될수록 변경사항에 대한 개발 비용이 굉장히 많이 든다.
• 애자일 방법으로 잘 구현하면 초기에는 비용이 더 들 수 있을지라도, 프로세스 전반에 걸친 변화에 잘 대응할 수 있다. 비용이 적게 든다.
• 요구사항이 계속 바뀔 수 밖에 없음을 인정. 변경에 잘 대응하는 체계로 변경.

* Plan-driven Development

• 전통적인 방법임.
• 정의되고 표준화되고 점진적으로 개선되는 프로세스
• 문서화 강조, 잘 정의된 중간산출물.
• 반복가능성, 예측가능성에 집중
• 미리 정의된 소프트웨어 시스템 아키텍처
• 상세한 계획, 워크플로, 역할, 책임 및 작업 제품 정의
  

* 애자일 선언의 12가지 원칙

1. 당사의 최우선 과제는 가치있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것이다.
2. 개발 후반부에도 변화하는 요구사항을 환영한다. 애자일 프로세스는 고객의 경쟁우위를 위해 변화를 이용한다.
3. 작동하는 소프트웨어를 2주에서 2개월까지 자주 배포하고, 더 짧은 기간을 선호한다.
4. 비지니스 담당자와 개발자는 프로젝트 기간 내내 매일 함께 작업해야 한다.
5. 동기부여받은 개인을 중심으로 프로젝트를 구축하라. 그들에게 필요한 환경과 지원을 제공하고 일을 완수할 수 있도록 믿어준다.
6. 가장 효율적이고 효과적으로 정보를 전달하는 방법은 직접 대면하는 대화이다.
7. 작동 중인 소프트웨어는 진행 상황의 주요 척도이다.
8. 지속가능한 개발을 촉진한다. 후원자, 개발자, 사용자는 일정한 속도를 유지할 수 있어야 한다. 개발 패이스를 균일화 한다.
9. 기술적 우수성과 우수한 디자인에 대한 지속적인 관심은 애자일을 향상시킨다.
10. 단순화, 즉 하지 않아도 되는 일을 줄이는 기술은 필수적이다.
11. 최고의 아키텍처, 요구사항 및 디자인은 스스로 조직화하는 팀에서 나온다.
12. 팀은 주기적으로 어떻게 하면 더 효과적으로 일할 수 있을지 회고한 다음 그에 따라 행동을 조정하고 조정한다.

* 애자일 프로젝트 관리

• Timebox management technique 타임박스 기법
  • 결과물 제작 마감일(상수)은 정해져있으며 변경해서는 안된다.
  • 해당 시간 안에 결과물이 나와야 함.
  • 타임박스는 잘 알려진 정의된 결과물은 주어진 리소스로 제작해야 한다.
  • 결과물의 범위는 프로젝트 관리의 변수 중 하나이다. 하지만 품질(상수)은 결코 변수가 될 수 없다.
• Rolling wave planning
  • 파도치는 모형, 물결이 점점 커지는 plan
  • 가까운 것은 상세하게 planning, 뒷 일정은 대략적인 planning
• Pull system, Not Push system
  • 팀 멤버들이 본인의 일을 끌어가는 방식

📍 eXtreme Programming (XP)

: 1990년대 후반에 개발된 매우 영향력 있는 애자일 방법론. 소프트웨어를 개발하는 중소규모 팀을 위한 경량 방법론. 요구사항이 자주 바뀌거나 모호한 소프트웨어 개발시 사용.

XP의 소프트웨어 개발 문제 해결법

• 일정 지연 Schedule slips -> 릴리즈를 자주 함(1-4주기), 우선순위가 높은 기능을 우선적으로 개발.
• 프로젝트가 취소됨 Project Canceled -> 고객이 기능 우선순위를 선택하게 해서 개발.
• 시스템을 다시 개발해야하는 상황 System goes sour (needs replace) -> 지속적인 통합, 자동 테스트로 해결
• 운영중인 S/W의 높은 결함률 High Defect Rate of S/W in production -> 개발자와 고객에 의한 테스트 강화
• 비지니스에 대한 잘못된 이해 Business misunderstood -> 고객을 팀의 필수로 포함.
• 비지니스가 변경됨 Business change -> 짧은 릴리즈 주기로 인해 변경사항을 적게 유지하며, 신규/변경된 기능을 환영한다.
• 엄한 feature가 많음 False feature rich -> 우선순위가 가장 높은 작업에 집중
• 이직률 Staff turnover -> 개발자가 자신의 작업을 추정하고 완료할 수 있도록 책임과 권리 부여.(Pull방식)

XP Practices

*XP의 practice들은 잘 엮여있다.

• The Planning Game
  • 심플하게 게임처럼 계획 세움.
  • 요구사항은 스토리카드(명세서X)에 기록되고, 릴리즈에 포함될 스토리는 소요시간과 우선순위에 의해 결정된다.
  • 비지니스 담당자는 범위scope, 우선순위, 릴리즈 구성, 날짜, 릴리즈 등의 사항을 결정.
  • 기술 담당자는 규모, 결과, 프로세스, 세부일정 결정
• Small releases 소규모 릴리즈
  • 간단한 시스템을 신속하게 프로덕션에 적용한 다음, 매우 짧은 주기로 새버전을 릴리즈한다.
• Metaphor
  • 전체 시스템에 대한 간단한 공유 스토리로 전체 개발을 안내한다.
• Simple design 단순한 디자인
  • 현재 요구사항을 충족할 만큼만 설계.
  • 올바른 디자인 - 1.모든 테스트 실행. 2.중복된 로직이 없음. 3.개발자에게 중요한 코드 명시. 4.가능한 클래스와 메서드는 적게.
• Testing 테스트
  • XP의 핵심이며, 모든 변경이 이루어진 후 프로그램을 테스트하는 접근방식 개발
  • XP 테스트 특징
    • 테스트 우선 개발
    • 시나리오부터 점진적 테스트 개발
    • 테스트 개발 및 검증에 사용자가 참여
    • 테스트 자동화
  • 테스트 중심 개발(TDD, Test-Driven-Development)
    • 코딩 전에 테스트를 작성하면 구현해야 할 요구사항이 명확해짐.
    • 테스트 자동화 - Junit과 같은 테스트 프레임워크 사용. 새 기능이 추가되면 모든 이전 테스트와 새 테스트가 자동으로 실행.
• Pair programming
  • 프로그래머가 짝을 이루어 같은 컴퓨터에 앉아 함께 코드를 개발함.
  • 모든 팀원이 개발 과정에서 서로 협력할 수 있다.
  • 코드에 대한 공동의 소유권을 개발하고 팀 전체의 코드에 대한 이해도 상승.
  • 리팩토링 시 많은 도움이 됨.
• Refactoring
  • 기능은 유지하고 내부 코드 구조는 더욱 좋게 개선한다.
  • 소프트웨어 개선이 가능한 부분을 찾아서 당장 개선이 필요하지 않은 부분까지 개선한다.
  • 이렇게 하면 소프트웨어의 이해도가 향상되어 문서화할 필요성이 줄어든다.
  • 코드가 체계적이고 명확하기 때문에 변경하기가 더 쉽다.
• Collective ownership 공동 소유권
  • 모든 사람이 전체 시스템에 대한 책임을 진다.
  • 코드의 어떤 부분에 가치를 더할 수 있는지 발견한 사람은 누구나 언제든지 그렇게 할 수 있다.
• Continuous integration(CI) 지속적인 통합
  • 개발자 코드 변경 > 변경사항 Build > Test > 결과 노티스
  • 코드통합 및 테스트는 몇시간 후 혹은 최대 하루 이내에 완료.
  • 테스트를 빠르게 실행.
• 40 hour week - 지속적인 개발을 위함
• On-site customer 현장고객
  • 실제 고객(시스템 사용자)이 팀에 참여하여 질문에 답변하고, 기능 테스트에 대한 테스트케이스 작성, 우선순위 결정 등을 할 수 있어야 한다.
  • 고객이 프로젝트의 가치를 창출할 수 있다.
• Coding standards - 표준을 지켜 개발한다.

📍 Scrum 스크럼

반복적인 개발을 관리하는 데 중점을 두는 애자일 방법.

Relay race VS. Rugby approach

• 릴레이 (Waterfall 방식)
  • 프로젝트는 순차적으로 진행, 단계에서 단계로
  • 기능이 전문화되고 세분화
  • 부서들이 명확함
• 럭비 접근 방식
  • 다분야 팀의 지속적인 상호작용을 통해 이루어진다.
  • 멤버들은 처음부터 끝까지 함께 일한다.
  • 팀 전체가 최종적인 목표를 이룬다.

속도와 유연성을 제공하는 6개 특징 (스크럼 철학)

1. Built-in instability 불안정성이 내포됨

• 명확한 신제품 컨셉이나 구체적인 작업 계획을 제시하는 경우는 거의없다.
• 프로젝트 팀에게 매우 도전적인 목표와 프로젝트를 수행할 수 있는 큰 자유가 주어진다.

2. Self-organizing project teams 자체 조직화 된 프로젝트 팀

• 본사는 초기에만 개입하고, 팀은 자유롭게 방향을 설정할 수 있다. 한계를 향한 끝없는 탐구
• 다양한 기능적 전문성, 사고 프로세스 및 행동패턴을 가진 구성원들로 구성됨

3. Overlapping development phases 중복되는 개발단계

• 개발 형태를 오버랩핑 방식으로 진행.
• 문제 해결에 초점을 두고 주도적인 자세를 취하도록 한다.
• "공유 분업" 필요

4. Multi-learning

• 다단계 학습 : 개인 수준의 학습 > 그룹 수준의 학습 > 기업수준의 학습
• 다기능 학습 : 자신의 분야가 아닌 다른 분야에서도 경험을 쌓도록 권장됨.

5. Subtle control 섬세한 제어

• 프로젝트 팀은 대부분 독립적으로 운영되지만 통제를 받지 않는 것은 아니다.
• "자기 통제", "또래의 압력을 통한 통제", "사랑에 의한 통제"에 중점을 둠.
  • 적합한 사람 선택 / 개방적인 업무 환경 조성/ 고객의 의견을 경청하도록 장려 / 그룹 성과에 따른 평가 보상 시스템 구축. 팀워크 강조 / 실수를 예측하고 관용 / 협력업체 또한 스스로 조직화하도록 장려

6. Organizational transfer of learning

• 조직 내에 경험이 내재화, 표준화 되어 공유되도록.
• 후속 신제품 개발 프로젝트 또는 조직의 다른 부서로 학습을 전이하는 작업은 정기적으로 이루어짐
• 기업들은 성공에서 얻은 교훈을 제도화하기 위해 노력함.

소프트웨어 개발을 위한 스크럼 프로세스

• 스크럼은 일반적으로 사용되는 반복적/점진적 개발주기를 강화한 것이다.
• Pregame(계획, 시스템 아키텍처, 상위레벨 디자인) > Game(개발 스프린트) > Postgame(릴리즈)

Sprint cycle 스프린트 주기

• 스프린트는 일반적으로 2-4주 동안 고정된 기간으로 진행
• Product backlog : 프로젝트에서 수행해야할 작업 목록(feature list)
• 선택 단계에서는 고객과 협력하여 스프린트 기간 동안 개발할 기능을 Product backlog에서 선택함.
• 개발 기능에 따른 개발팀이 구성되면, 개발팀은 고객과 조직으로부터 분리되며, 모든 커뮤니케이션은 '스크럼마스터'를 통해 이루어짐.
• 스크럼 마스터의 역할은 외부의 방해요소로부터 개발팀을 보호하는 것
• 스프린트가 끝나면 완료된 작업을 검토하고 이해관계자에게 발표함. 그러면 다음 스프린트 주기가 시작됨.

역할

• 프로덕트 오너
  • 제품 기능 또는 요구사항을 식별하고 개발 우선순위를 정함.
  • Product backlog를 지속적으로 검토, 비지니스 요구사항을 충족하는지 계속 확인.
  • 고객일 수도 있고 소프트웨어 회사의 제품관리자일 수도 있음.
• 스크럼 마스터
  • 스크럼 프로세스를 준수하는지 확인하고 팀을 가이드 함.
  • 다른 부서와의 인터페이스를 담당함
  • 스크럼 팀이 외부의 간섭에 의해 방향을 전환하지 않도록 하는 책임이 있다.
  • 프로젝트 관리자(PM)로 생각해서는 안된다.
• 개발팀
  • 자체적으로 조직된 소프트웨어 개발자 그룹.
  • 소프트웨어 및 기타 문서 개발을 담당.

워크플로우

* 스크럼 미팅의 목표 - 프로젝트/스프린트 목표 공유, 진행상태 매일 갱신, 위험과 이슈 식별 및 해결

• 스프린트 계획 미팅 : 각 스프린트 시작시 / Product backlog 검토 / Sprint backlog 추정
• 일일 스크럼 미팅 : 어제 오늘 무엇을 할건지 / 어떤 이슈가 있는지 (15분 남짓)
• 스프린트 검토 미팅 : 스프린트 검토 / 이해관계자에게 데모 시연
• 스프린트 회고 : 스프린트 프로세스 검토

Artefacts 산출물

• Product backlog : 스크럼 팀이 처리해야 하는 '해야할일' 항목의 정렬된 목록 (덜 상세함)
• Sprint backlog : 스프린트 기간동안 개발팀이 해결해야 하는 작업 목록 (매우 상세함)

진척(진행상황) 추적

• Task board 작업보드 : 스프린트 작업의 상태 (할일/진행중/완료)
• Sprint Burn-down chart : 매일 진행상황 추적, 남은 노력에 집중 (X축 타임라인, Y축 남은 작업)
• Release Burn-down chart : 각 스프린트 별 스토리포인트 남은 정도 차트. 전체 프로그레스 확인. (X축 스프린트, Y축 남은 작업)

📍 Lean Software Development 린 소프트웨어 개발

: Toyota 시스템에서 시작. 근본적인 린 원칙 - 낭비(고객에게 가치를 창출하지 못하는 모든 것)의 절대적 제거
ex) 과잉생산으로 인한 낭비, 시간 낭비, 운송 낭비, 재고 낭비, 결함이 있는 제품을 만드는 낭비 등..

7가지 린 원칙

1. 낭비를 제거 Eliminate waste

• 소프트웨어 개발의 7가지 낭비 : Partially Done Work / Extra Processes / Extra Features / Task Switching / Waiting / Unnecessary Motion / Defects

2. 학습 증폭 Amplify Learning

• 피드백으로부터 배움. 짧은 반복

3. 가능한 늦게 결정 Decide as late as possible

• 동시에 소프트웨어 개발 - 변화하는 요구 사항에 대처
• 의사결정 지연

4. 최대한 빠르게 전달 Deliver as fast as possible

• 비지니스 유연성 확정
• 진행중인 작업을 줄이고 빠르게 결과물을 제공.
• 가능한 한 늦게 결정을 보완한다.
• 풀(Pull) 시스템을 통해 직원들이 가장 효과적으로 시간을 활용할 수 있도록 지원

5. 팀역량 강화 Empower the team

• 리더십 : 관리자 vs 리더
• 관리자 - 복잡성에 대처 : 계획 및 예상 / 조직 및 직원 구성 / 추적 및 제어
• 리더 - 변화에 대처 : 방향 설정 / 사람 정렬 / 동기부여 활성화

6. 무결성 구축 Build Integrity in

• 시작부터 모든 단계에서 품질 구축.
• 고객 테스트 참여.
• 리팩토링을 해서 변화에 대처할 수 있도록.

7. 전체를 보기 See the whole

• 시스템 사고 : 시스템은 상호의존적이고 상호작용하는 부분으로 구성됨. 최고의 부품이 최고의 시스템을 만드는 것은 아니다.
• 로컬 최적화 피하기
• 측정 : 전문화된 기여도를 기준으로 측정

📍 KANBAN 칸반

: Just-In-Time(JIT)기반의 애자일 프로젝트 관리방법

• Timeboxing 기반의 iteration계획을 수립하지 않고 WIP(Work-In-Process)의 양을 관리

📍 DevOps

: Development(개발) + Operations(운영)

• 지속적인 배포에 집중 Continuous Integration and Delivery

도구 카테고리 및 참조 도구

• 협업도구 : 잔디(JANDI), Slack, Microsoft Teams, Flow, Confluence 등
• 프로젝트 관리/요구사항관리 도구 : Redmine, Trello 등/Doors등
• 결함/이슈 추적: mantis, Bugzilla, Jira, ClearQuest등
• 코드품질(static analysis, code review) / 제품품질(test자동화)
  • 정적분석 Static analysis: PMD, CPPCheck, Prevent, Klockwork, sonarqube, Veracode 등
  • Code review: Gerrit, code collaborator, crucible 등
  • 테스트 자동화 도구 (code level, feature level, UI 포함 등)
• Continuous Integration / 형상관리 : Jenkins, Hudson 등 / SVN, GitHub, ClearCase 등

+ WBS (Work Breakdown Structure, 업무 분류 체계)

: WBS - 모든 계획작업의 기초. 프로젝트 전체 범위를 구성하고 정의함. 프로젝트 팀이 프로젝트 목표를 달성하고 필요한 인도물을 산출하기 위해 실행하는 작업을 인도물 중심의 계층 구조로 세분해 놓은 것.

• 1단계 프로젝트(Project) > 2단계 단계(Phase) > 3단계 작업(Task) > 4단계 작업패키지(Work Package, 가장 작은 수준의 작업)
• WBS의 목적
  • 전체상 파악
  • 각 단계의 목표와 달성수단의 명확화
  • 일정, 자원, 범위의 계획을 제대로 세우기 위한 기준
  • 업무누락 방지
  • 이후 프로젝트의 진행, 추적 관리의 기준
  • 원가 집계, 요약/보고의 체계
• Decomposition 분해 : 프로젝트 범위와 프로젝트 결과물을 더 작고 관리하기 쉬운 부분으로 나누는 기법
• Expert Judgement 전문가 판단 : 사전에 정의된 템플릿 제공. 잘 세분화하는 방법에 대해 의견 제공.
• WBS 작성시 유의사항
  • 최하위 타스크(워크 패키지)의 경우, 산출물이 누락되지 않도록 정의
  • MECE(Mutually Exclusive and Collectively Exhaustive)의 원칙에 맞게 작성
  • WBS 작성 후 번호 부여
  • 번호는 업무의 순서와는 관계가 없고 위계 (Hierarchy)를 나타냄.
  • WBS 구조 : Top-down 또는 Bottom-UP 둘다 가능

프로젝트 진척율 계산

• WBS구조에서 작업패키지(Work Package, 최하위 task)에 진척율을 입력하여 상위task로 집계
  -> 각 Phase 또는 전체 프로젝트 진척율 계산
• 진척율 산정 - 가중치 적용
  • Task별 가중치를 부여한다.
  • 상위레벨에 가중치 부여, 하위레벨은 필요시 가중치 부여.
  • 최하위 레벨부터 가중치 부여하여 sum-up도 가능
  • ex) 단계별 기능점수 가중치
    분석(0.19), 설계(0.24), 구현(0.32), 시험(0.25). 합계(1.0)

+ 실제 개발 프로세스

하이브리드 모델 주로 많이 사용됨.