[Software Engineering] Agile Software Development

Agile Development

• Requirement change에 대해서 민첩하게 반응하는 model
• 배경
  • Software process하는데 overhead가 너무 많다
  • Waterfall 의 경우 , 각 단계마다 끝났다는 기준은 그 단계에서 요구하는 document를 끝내야 끝난 것이다.
  • 그러한 것들이 overhead ( documentation)이 많더라
• 목표
  • System delivery time을 requirement change에 빠르게 대응하여 줄이자
• 실질적 문제점
  • Software document의 부족 (waterfall은 각 단계에서 모두 문서화가 끝나야 넘어가는 반면 에자일은 그렇지 않기 때문)
    • Requirements의 불안정 야기
  • Version up 계속되는 system 에서는 original development team의 유지가 힘듦
    • 개발자가 떠나면 큰 risk 발생 ⇒ 문서화가 제대로 되어 있지 않다 보니 기존 개발자가 떠나면 유지보수 및 이해하는데 리소스 발생 (에그픽 시발새끼)
  • Agile을 제대로 알고 해야한다.
    • Agile이 poorly applied된다면 pressure , 더 빨리해야 한다는 요구 등 부정적인 영향을 끼친다.
    • 오히려 더 느려지는 progress
  • 적합한 상황
    • Small 하고 co-located team의 경우에 하기 좋음
    • 유지 보수보다는 처음할 때 더 적합
    • Customer가 팀에 항상 합류해 있을 때 적합

Plan-driven(phase iteration) and Agile Development (process iteration)

• Plan-based development
  • Requirements engineering
    • Specification 단계이며 잘못되면 iteration한다.
  • Requirements specification
    • Document
  • 전체 iteration인 Requirements change requests
• Agile development
  • Document가 Plan-based development에 비교하여 빠져있지만 아예 없는 것은 아니며 굉장히 적어졌다.
  • Iteration없이 문제 생기면 다음 incrementation에서 해결 = 빨리 돌아간다.
    
  • 특징
    • Incremental Development
      • Versions 혹은 increments의 시리즈로 개발되어진다.
      • 아주 작은 단위로 작게 release한다.
      • 하나의 increment가 작다.
      • Incremental 하게 iteration하며 그 단위는 작다.
    • Customer involvement
      • 직원이 process 내내 들어가 있으며 requirement관여와 testing할때의 역할을 한다.
    • ==Documentation을 minimizing함에 따라 process overhead를 줄인다.==
  • Applicability
    • Release를 자주하지만 버전을 하루에도 몇개씩 나올 수는 없다.
    • 자주 release하고 increment 사이즈를 줄이며 조그마한 팀 내에서 같이 일할 수 있다.
    • User에게 확인 받고 피드백 받으며 개발하는 것이 효과적 ( Customized software development)

Extreme Programming ( XP ) ⇒ user story, refactoring, tdd, pair programming

• Increment 단위가 extreme하게 작다.
• 굉장히 영향력 있는 agile method이며 자주 사용한다.
• Iterative development에 ‘extreme’한 접근을 한다.
  • 새로운 버전이 하루에도 몇번씩 만들어지며 그 정도로 작다.
  • Customer에게 2주마다 release한다.
• Release cycle

Key XP Practices

• User stories for requirements
  • ==User가 XP team에 involve하고 stories에 관여한다.==
    • Requirements에 관한 결정을 한다.
  • Requirements를 user story 혹은 scenarios로 만들어서 진행한다.
  • ==실제 개발 팀이 stories를 보고 task로 나누어서 개발하며 testing 또한 customer(user)가 결정한다.==
  • Customer가 다음번 release할 stories를 결정한다.
    • 우선순위와 schedule estimates에 근거하여
• Refactoring
  • 더 나은 코드로 만드는 것
  • ==기존 코드를 재구성한다.==
    • 외부 interface에는 영향 없이 안쪽 code에만 영향
  • Refactoring하는 이유는 ==maintenance를 위해 더 쉽게 반영할 수 있으며 문제 발생 소지가 적어지고 change에 대비하여야 하기 때문에==
    • Software improvements에 가능성을 느끼고 이 improvements를 현재 필요하지 않더라도 미리 대비
    • Software에 대한 이해도 상승과 Documentation에 대한 need가 줄어든다.
  • Examples of refactoring
    • Class 간 중복된 것이 나오면 superclass로 만들 수 있다.
    • 중복된 코드가 없어지며 구조를 바람직한 방향으로 계속 고쳐나간다.
    • Function의 이름을 고치고 정리한다.
• Test-first development
  • ==Testing planning을 coding하기 전에 미리 한다.==
  • Requirement가 나오면 어떻게 testing할까를 먼저 고민한다. =이해도 상승
    
  • 이번에 개발한 부분만 test하는 것이 아니라 전체 모두를 test
    • 자동화된 testing program을 만드는 것이 좋음 ( tool 사용 )
  • User의 testing 개발과 평가에 참여
  • Accpetance test를 하는데 도움이 된다.
    • Acceptatnce : 알파 테스트 ( 실제 유저가 사용하는 것처럼 테스트 , 출시 전 마지막 test)
• Pair progamming
  • 두명이서 짝지어 programming하는데 한명은 코딩, 한명은 review (inspectation,반드시 필요)
  • I==nformal한 review process를 진행한다.==
    • ==한 사람 이상이 모든 코드를 본다==.
  • 전반적으로 코드에 대한 지식, 이해도가 올라간다.
  • 멤버가 떠나더라도 project risk가 줄어든다.

Agile vs Plan-driven

• 실제 개발로 넘어가기 전 아주 디테일한 specification이 있는 것이 중요한가?
  • Yes : Plan-driven , No : Agile
• Software가 delivery되는 process가 realistic한가?
  • Yes : Agile, No: Plan-driven
• 개발되는 system이 큰가?
  • Yes : Plan-driven, No: Agile
• Development team이 co-located되어있나?
  • Yes : Agile, No : Plan-driven
• 대부분의 projects들은 plan-driven 과 agile의 요소를 갖고 있다.
  • 각 subsystem or component에 다른 process를 적용할 수 있다
    • Agile : UI, Entertainment components
    • Plan-driven : Autonomous driving

Choosing the right software process model

• 다양한 software process models들이 있다.
• Requirements flexibility, scale, customer involvement, team location , etc … 등을 고려하여 가장 적당한 process model 을 고르면 된다.