INDEX

• Background of SW Development
• Agile SW Development
  • Agile vs Traditional Methods
  • Manifesto for Agile SW Development
  • An Agile Process
  • Agility Principles
• Scrum
• eXtreme Programming(XP)
• Kanban
• DevOps
• Reference

Background of SW Development

• 90년대 후반까지의 소프트웨어 개발
  • 장기간에 걸쳐 많은 인력과 충분한 비용을 투입하여 진행
    => 소프트웨어공학의 주된 대상이 프로젝트가 됨
• 최근 소프트웨어 개발 동향
  • 짧은 개발기간, 적은 비용 투자, 매우 복잡하며 개방적
  • 사회적 상황 및 시장 변동에 따라 변화가 심함
    =>요구사항이 다양
• 객체지향
  • 자주 발생하는 사회적 환경과 비즈니스 상황에 잘 적응 & 대응할 수 있는 기술적 해결책
  • Agile 개발 프로세스
    
    
    

Agile SW Development

Agile vs Traditional Methods

• 대규모 시스템 개발 프로세스의 문제점
  • 오버헤드 : 철저한 계획 및 품질보증 필요
  • 프로그램 개발 자체보다 다른 업무(code review, testing 등)에 더 많은 시간을 소비

    Testing 절차

    unit testing
    - 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증
    
    integration testing
    - unit testing이 끝난 소프트웨어를 결합해가며 검증
    
    system testing
    - 정보시스템이 완전히 통합되어 구축된 상태에서 정보 시스템의 기능을 총체적으로 검증
    
    acceptance testing
    - 시스템이 실제 운영 환경에서 사용될 준비가 되었는지 최종적으로 확인하는 단계
    
    

• Agile 방법론
  • 부가적 산출물(설계 & 문서화)보다 소프트웨어 그 자체에 초점을 둠
  • 사용자 요구사항의 빈번한 변경이 반영 가능한 환경 제공 => 빠른 피드백
    
    
    

Manifesto for Agile SW Development

• 2001년 Kent Beck외 16인
• 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
• 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
  • 공정과 도구보다 개인과 상호작용을
  • 포괄적인 문서보다 작동하는 소프트웨어를
  • 계약 협상보다 고객과의 협력을
  • 계획을 따르기보다 변화에 대응하기를
• 위는, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다.
  
  

An Agile Process

• Agile Process의 3가지 가정
  • 유지사항, 우선 순위의 유지 OR 변경을 예측하기 어려움
  • 소프트웨어 increment를 어떻게 나누는 것이 효과적인지 판단하기 어려움
  • 초기 단계에서 프로젝트 프레임워크 activity를 유효성있게 예측하는 것이 어려움
    => 예측 불가능성을 관리할 수 있는 적절한 프로세스를 만들어야하는데 프로세스의 적응성을 높이면 문제를 해결할 수 있다.
• 고객이 기술한 요구사항에 기반하며 고객의 피드백에 대응
• 계획은 단기적(short-lived)으로 개발은 반복적(repetitive)으로
  • 구현에 중점을 두고 요구를 조금씩 단계적으로 개발
• 다수의 소프트웨어 increments를 배포
• 프로젝트 및 기술 변경을 포용
  • 변경에 조화되도록 설계
  • 단순함 유지 : 가능하면 단순하게, 복잡한 것은 배제
    
    

Agility Principles

• to satisfy the customer through early and continuous delivery of valuable software
  - 고객 만족이 최우선 : 신속하고 지속적인 소프트웨어 배포
• welcome changing requirements, even late in development
  - 요구사항 변경은 언제든지 적극 반영
• deliver working software frequently, from a couple of weeks to a couple of months, with a preference to shorter timescale
  - 작동하는 소프트웨어를 자주 배포
• business people and developers must work together daily
  - 모든 이해관계자와 개발자들은 프로젝트 내내 매일 함께 협업
• build projects around motivated individuals
  - 개인 존중 : 동기부여 및 독려
• the most efficient and effective method of conveying information is face-to-face conversation
  - 대면 대화가 팀 내외로 정보를 전달하는 가장 효과적 방법
• working software is the primary measure of progress
  - 작동하는 소프트웨어는 일의 진척에 대한 가장 좋은 척도
• Agile processes promote sustainable development
  - 지속가능 / 적절한 개발 환경 조성
• continuous attention to technical excellence and good design
  - 기술적 우월성 및 좋은 설계에 대한 지속적 관심
• simplicity is essential
  - 단순성
• the best architectures, requirements, and designs emerge from self-organizing teams
  - 최적 설계, 요구사항, 디자인은 모두 자기 조직 팀으로부터
• at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour
  - 주기적으로 어떻게 해야 더욱 효율적일지 생각하고 조율
  
  
  

Scrum

Jeff Sutherland와 개발 팀이 90년대 초에 고안
이후 Schwaber와 Beedle이 추가 개발 제안

Scrum 원칙은 Agile Manifesto를 따름

특징

• 개발 작업을 패킷(packet)-Product Backlog으로 분할
• 작업은 스프린트(sprint)에서 진행되며 기존 요구사항의 백로그(backlog)-Sprint Backlog에서 파생됨
  • Backlog : 프로젝트 요구사항 또는 기능의 우선 순위 목록
  • Sprint : 프로세스 패턴 내 업무
• Daily Scrum Meeting 진행
• Time-box에 맞춰 고객에게 데모 제공
  
  
• Scrum 산출물 -> Product Backlog, Sprint Backlog, Code Increment
  • Product Backlog
    • 우선 순위가 지정된 제품 요구사항 / 기능 목록
    • 제품 소유자는 모든 이해관계자의 가장 중요한 목표 달성을 위해 백로그 항목의 우선 순위 설정
    • 이해관계자의 요구 충족을 위해 제품이 진화하는 동안 백로그는 완료되지 않음
    • 제품 소유자는 스프린트를 조기에 끝내거나 연장할지 여부를 결정할 수 있는 유일한 사람
  • Sprint Backlog
    • 스프린트 동안 팀이 Code Increment로 완료할 product backlog의 부분집합
    • increment : 지난 스프린트에서 완료한 그리고 현 스프린트에서 완료할 제품 백로그 항목
    • 개발 팀은 스프린트에서 제품 소유자와 협상하여 소프트웨어 증분 배포 계획을 수립
    • 대부분 스프린트는 3~4주의 time-box 내 완료
    • 증부 완료 방법 및 시기는 개발 팀이 결정
    • 스프린트가 취소되고 재시작되지 않은 한 백로그에 새로운 기능 추가 불가
      
      

Scrum Team

• 제품 소유자, 스크럼 마스터, 소규모 개발 팀(3~6인)
  • 소규모 작업 팀 -> 소통 최대화, 오버해드 최소화, 정보 공유 최대화
• 스크럼 마스터 : 모든 스크럼 팀원에게 촉진제 역할
  • 일일 스크럼 회의 운영 - 회의 중 팀원이 식별한 장애요소 제거의 의무가 있음
  • 가능한 경우 개발 팀원이 서로 도움을 주며 스프린트 작업을 완료하도록 지도
  • 제품 소유자가 제품 백로그 항목 관리에 적절한 기법을 찾도록 도움
  • 백로그 항목이 명확하고 간결한 용어로 명시되도록 함
    
    

  Scrum 회의 종류

• 백로그 개선 회의 : 개발자는 이해 관계자와 협력하여 제품 백로그를 작성
  • 개발 팀 밒 제품 소유자는 비지니스 요구의 중요성과 각 항목을 완료하는데 필요한 소프트웨어공학 작업의 복잡성에 따라 우선 순위 설정 - 비지니스 가치 판단
  • 사용자에게 필요 기능을 제공하는데 누락된 부분 식별
• 스프린트 계획 회의 : 제품 백로그를 스프린트 백로그로 분할하고 다음 스프린트를 정의
  • 제품 소유자는 완료해야 하는 increment의 개발 목표 명시
  • 스크럼 마스터와 개발 팀이 제품 백로그에서 스프린트 백로그로 옮길 항목 선택
  • 개발 팀은 스프린트의 time-box 내에서 increment로 도출 가능한 결과물과 이를 위해 필요한 작업 결정
  • 개발 팀은 필요 역할과 이 역할 할당 방안을 결정
• 일일 스크럼 회의 : 팀원은 활동을 동기화하고 하루 작업을 계획
  • 매일 업무 시작 전 최대 15분 - 팀원 각자의 활동 동기화 및 앞으로 하루 동안 작업 계획
  • 스크럼 마스터와 개발 팀 필수 참석 & 제품 소유자 때때로 일부 팀에 합류
  • 3가지 주요 질문 및 답변
    • 이전 팀 회의 이후 무엇을 하였는가?
    • 어떤 장애 요소가 발생했는가?
    • 다음 팀 회의까지 무엇을 달성할 것인가?
  • 스크럼 마스터는 회의를 진행하고 각 참석 인원의 응답을 평가
  • 스크럼 회의는 팀이 잠재적 문제를 가능한 빨리 발견하도록 도와줌
• 스프린트 검토 회의 : 이해 관계자에게 프로토타입 데모 승인/거부 결정
  • 스프린트 검토 : 스크럼 마스터, 개발 팀, 선택된 이해 관계자
    • 스프린트 끝에 개발 팀이 increment가 완료 되었다고 판단하면 진행
    • 4주 스프린트에 4시간 회의로 time-box 지정
  • 주요 활동 : 스프린트 동안 완료된 소프트웨어 increment의 데모
  • 제품 소유자는 increment를 수락 혹은 거부
    • 거부 시 제품 소유자 및 이해 관계자는 피드백을 제공하여 새로운 스프린트를 계획
• 스프린트 회고 : 스프린트 완료 후 팀은 잘 진행된 부분과 개선이 필요한 부분을 고려
  • 이상적으로 다음 스프린트 계획 회의 시작 전 스크럼 마스터가 개발 팀과 (4주 스프린트 기준) 3시간 회의를 계획하고 스프린트에서 잘된 부분 / 개선 가능한 부분 / 다음 스프린트에서 팀이 개선할 부분에 대해 토론
  • 스크럼 마스터 : 회의 진행 및 다음 스프린트에 개발 실무가 더 효과적일 수 있도록 개선할 점 권장
  • 개발 팀 : '완료'의 정의를 조정하여 제품 품질을 향상시키는 방안을 계획
    
    

장점

• 제품 소유자가 우선 순위를 결정 -> 확고한 요구사항 도출 가능
• 팀이 의사 결정권을 가짐
• 가벼운 문서 작성
• 빈번한 업데이트 지원 -> increment가 sprint로 나누어져 진행되기 떄문
  
  

단점

• 변경 비용 통제가 어려움
• 대규모 팀에는 적합하지 않음
• 전문가 팀이 필요
  
  

eXtreme Programming(XP)

1999년 Kent Beck이 제안한 가장 널리 사용되는 Agile 프로세스

1. XP 계획(Planning)
   • 소프트웨어에 요구되는 특징 및 기능을 설명하는 사용자 스토리(user story) 생성으로 시작
     • User Story : 출력, 특징, 기능 등을 자세히 설명
   • 고객은 각 스토리에 가치를 할당
   • Agile 팀은 각 스토리를 평가하고 비용을 추정하여 할당
   • 스토리는 배포 가능 증분(deliverable increment)으로 그룹화
   • 첫 increment 수행 후, velocity를 추정하여 추후 increment의 배포일을 결정하는데 도움을 줌
     
2. XP 설계(Design)
   • KIS 원칙 고수 - Keep It Simple
   • CRC(Class-Relationship-Collaboration) 카드 사용 권장
   • 복잡한 설계 문제에 대해서는 'spike solution' 작성
   • 리팩토링을 권장
     • 실질적으로 코딩 단계에서 수행되지만 design 단계에서 simple하게 설계를 함
       
3. XP 코딩(Coding)
   • 코딩 시작 전 각 스토리에 대한 단위 테스트 생성 권장
   • pair programming 권장
     
4. XP 테스트(Testing)
   • 매일 모든 단위 테스트 실행 -> 생성된 unit test를 자동적으로 testing하는 프레임워크를 사용
   • 인수 테스트는 고객이 정의하고 고객이 보고 검토할 수 있는 기능을 평가하기 위해 실행
     

CRC Card

CRC 카드(Class-responsibility-collaboration card)는 객체 지향 소프트웨어 설계에서 사용되는 브레인 스토밍 툴이다.
일반적으로 디자인을 시작할 때 어떤 객체가 필요하고 그들이 어떻게 상호 연계할지 여부를 결정하는 데 사용한다.

• Class : 객체
• Responsibility
  • Knowing : class가 갖는 attribute와 거기에 담긴 data를 보고 class가 알아야한는 것들
  • Doing : operation은 class가 해야하는 일들(function), class가 use case 요구 사항에 따라서 해야할 operation과 그 일을 하기 위해서 필요한 데이터가 담긴 attribute
• Collaboration : class와 class가 협력, request에 대해 서비스를 제공하기 위해 class들이 함께 일을 하는 것

XP의 원칙

• 세심한 피드백

  지속적 테스트 : 개발과 동시에 단위 테스트 병행
  
  계획 세우기 : 우선순위와 기술사항을 고려하여 범위 결정
  
  현장 고객 : 고객이 개발 사이트에 상주하며 참여
  
  pair programming : 가장 좋은 구현 방법과 전략을 고민
  

• 지속적 개발

  지속적 통합 : 개발한 것을 즉시 또는 매일 통합, 빌드
  
  리팩토링 : 코드의 품질을 지속적으로 개선
  
  작은 릴리스 : 짧은 사이클로 작은 릴리스를 반복 개발
  

• 상호이해

  단순 설계 : 최대한 설계를 단순하게 유지
  
  메타포 : 시스템 전체에 대해 은유적 접근
  
  코드 공유 : 누구나 코드를 수정하고 집단적 소유로 간주
  
  코드 표준 : 표준에 맞추어 코딩
  

• 복지

  40시간 작업 : 초과 근무를 줄이고 계획적으로 작업
  

장점

• 고객의 참여를 강조 -> user story를 고객이 같이 작성
• 합리적 계획과 일정 설정
• 프로젝트에 대한 높은 개발자의 헌신
• 제품 거부 가능성 감소
  
  

단점

• 비용 증가에 대한 빈번한 회의가 필요
• 과도한 변경을 허용
• 숙련된 팀원에 의존

Kanban

Toyota에서 산업 공학의 실무로 시작
David Anderson이 소프트웨어 개발에 적용

특징

• 변경 관리 및 서비스 제공에 집중
  - 변경 관리 : 요청된 변경이 소프트웨어에 반영되는 프로세스 정의
  - 서비스 제공 : 고객의 요구 / 기대를 이해하는데 초점을 맞추는 것을 장려
• 팀원 스스로 업무를 관리하고 이를 완료하기 위한 자기조직화의 자유
• 매일 Kanban 스탠드 업 회의 진행
  - 일일 Kanban 스탠드 업 회의

  회의 주관자는 매일 교체됨
  팀원은 보드에서 누락된 항목을 식별하여 보드에 추가
  팀은 모든 항목을 "complete" 상태로 진행 -> 비지니스 가치의 우선순위에 따라 진행
  팀은 흐름을 보고 작업량 및 위험 요소를 살펴 완료에 방해되는 요소를 식별

• 매주 회고 회의 진행을 통한 프로세스 측정 및 검토
• 다른 Agile 개발 실무와 쉽게 결합될 수 있음

6 핵심 실무

1. visualise workflow using a Kanban board
2. limiting the amount of work in progress at given time
3. managing workflow to reduce waste by understanding the current value flow
4. making process policies explicit and the criteria used to define "done"
5. focusing on continuous improvement by creating feedback loops where changes are introduced
6. make process changes collaboratively and involve all stakeholders as needed.

장점

• 낮은 비용 및 시간 요구
• 조기 제품 제공이 가능
• 프로세스 정책이 기록됨
• 지속적 프로세스 개선

단점

• 팀 협업 능력이 성공을 좌우
• 열악한 비지니스 분석은 프로젝트를 망침

DevOps

Patrick Debois 제안 -> 개발와 운영을 결합
Agile & Lean 개발 원칙을 소프트웨어 공급망 전체에 적용

Operation

1. 개발 : 소프트웨어 결과물은 여러 스프린트로 분류 및 개발되며 increment는 테스트를 위해 개발 팀의 QA 멤버에게 전달됨
2. 테스트 : 자동화된 테스트 도구를 사용, 팀 구성원이 동시에 여러 코드 increment를 테스트하여 통합 이전 결함 유무를 확인
3. 통합 : 새로운 기능의 코드는 기존 코드, 실행 환경에 추가되고 배포 이후 오류가 없는지 확인
4. 배포 : 통합된 코드가 프로덕션 환경에 배포
5. 모니터링 : 운영 직원은 프로덕션 환경에서 성능 모니터링하여 소프트웨어 품질을 향상

장점

• 코드 배포 시간 단축
• 팀에 개발자와 운영자가 공존
• 팀은 end-to-end 프로젝트 소유권을 가지고 있음
• 배포된 제품의 사전 모니터링

단점

• 기존 및 신규 코드 모두에 대한 작업 압박
• 효과적 자동화 도구에 크게 의존
• 전문가 개발 팀 필요

Reference

• CRC Card 위키백과
• Scott Uk-Jin Lee 소프트웨어공학 강의