Chapter 3. Agile Software Development

Introduction to agile methods

Rapid Software Development - Agile이 탄생하게 된 배경 (참고만)

빠른 development와 delivery는 software system에서 매우 중요한 요구사항이 되었다. 

그러나 속도와 질은 trade off 되는 것.

실질적으로 안정적인 software requirements를 이끌어내기란 거의 불가능하다. 왜냐하면 써봐야 req를 알수 있기 때문에.

-> '빨리 뭐라도 만들어서 시험해보자' 는 발상 

plan-driven process는 rapid software development에는 맞지 않는 방식이다. 왜냐면 req가 change되면, rework, retest해야하기 때문에. 

requirements chainging에 대해 잘 handling할 수 있는 rapid software 에 대한 필요성. -> rapid software development가 agile method로 알려지게 되었다.

Agile method에 XP, scrum, kanban 등의 방식이 있다.

 

 

Agile Methods에 대한 공통 특성

1. Specification, design, implementations are interleaved

- 이 activity들의 순서는 지키지 않아도 된다. 

- 문서 작업을 최소화. 대략적인 outline만 작성.

 

2. System은 여러 버전들의 시리즈로 개발된다.

- end-user는 각 increment를 지정하고 평가하는 데 관여

- 약 2~3주마다 새 버전이 나온다.

 

3. 광범위한 tools 사용

- Automated testing tools (JUnit, PyUnit) : 코드를 테스트해주는 프로그램을 짜면, 유닛을 테스트해줌

- Configuration management tools (Git) : 형상관리툴

- Continuous integration tools (Jenkins) : 통합을 간헐적으로(2주뒤, 한달뒤 ,..) 하지않음. 개별 코드 작성하면 바로 unit test하고, 전체에 통합해서 system test. -> 항상 테스트가 완료된, 언제든 출시가능한 완전한 버전이 존재

- Issue tracking systems (Jira) : 카톡같은거 말고 

 

 

 

History

▶ 80,90년대 : plan-driven, heavyweight식 접근

- planning careful하게, 각 단계를 완벽히, 엄격한 프로세스, large team이 large system 개발 시 체계없이 만들기 힘들기 때문에.

 

- planning, design, document 하는 데에 overhead 발생

특히 small~medium system에서는 각 단계를 수행하는데 힘듦. programming,testing보다 planning하는 데에 더 많은 노력과 시간이 쓰임.

 

▶ 90년대 후반 : agile method

- design, documenttation보다, software 그 자체에 집중

- 요구사항 변경 시 빠르게 대응 가능

- 고객에게 software를 빠르게 전달하기 위한 목적

 

- process bureaucracy 감소. 어차피 바뀔 req, design 문서에 대한 것을 최소화하자.

 

고객이 원하는 바를 맞춰나가니깐 success 비율 높음

 

Agile Manifesto선언문

agilemanifesto.org/

 

Individuals and interactions > processes and tools 

사람들에게 맡기자. 강력한 커뮤니케이션과 상호작용 > 엄격한 프로세스와 규율

Working software > comprehensive documentation

더 좋은 코드 > 문서 = 문서를 없애는 대신 더 좋은 코드

Customer collaboration > contract negotiation 

고객과 협업 (1. req에 피드백 2. evaluation/validation) > 계약

Responding to change > following a plan

변화에 맞춤 > 계획에 따름

 

 

Agile Method 예시들

위로 갈수록 지켜야할게 상대적으로 많고, 아래로 갈수록 최신

 

 

 

 

XP, scrum, kanban 등 여러가지 방법이 나왔는데 이것들을 다 agile이라고 무리지음.

 

 

축 위로 갈수록 지켜야될게 좀 많고,

아래로 갈수록 최신

 

 

 

agile 방식은 모두 software를 incrementally하게 develop, deliver한다.

agile방식의 원칙은 다 지킨다. (이제부터 나올 내용)

 

 

Agile Methods의 원칙

▶ Customer involvement : 1. req에 피드백 2. evaluation/validation

▶ Embrace change : 변화를 수용

▶ Incremental delivery : 

▶ Maintain simplicity : 단순함의 대상 =1. 프로세스 규정 단순화 2. 코드 단순화(누구든 읽고 쉽게 고칠 수 있도록. 지금 짜기로 한 것만 코드 짜기, 불필요한 로직 x) 

▶ People, not process : 

 

 

 

Agile Method Applicability 장단점

약점 1. small~ medium sized product만 가능. 큰 프로젝트 X. 소규모 인원이 한 방에 모여있을 때. 

- 규율이 없는 대신 강한 커뮤니케이션이 있어야 하므로.

 

약점 2. customer가 잘 참여해줘야함. 책임감이 있어야함.

 

약점 3. 대기업같은 수직적인 규모 X

 

 

 

Extreme Programming (XP)

- 변화하는 소프트웨어 개발문화에 대한 가장 중요한 접근방식. (Kent Beck. 1998)

 

- 반복적인 개발 -> 시스템의 여러 새 버전을 하루에 개발, 통합, 테스트할 수 있다.

 

- User Stories : Req를 시나리오처럼.

- Pair programming : 2인 1조로 개발. 

- Test first programming : 코딩하기 전, 테스트할 코드부터 짠다. (1. 내가 짠 코드 testing)

- 모든 test를 통과해야만 팀 코드에 통합될 수 있음. (2. 통합하고 난뒤 testing)

 

- Releases of the system의 gap이 약 2주로 짧다.

 

 

XP Release Cycle

 

XP는 Agile 5개 원칙에 대해서 어떻게 적용하는지

Customer involvement

▶  customer의 대표가 아예 개발팀으로 출근. 끊임없는 피드백 + test

Embrace change

▶ 니가 코딩할 땐 니 코드에 대한 test를 미리 개발해줘. test를 통과해야만 코드 합칠거야

Incremental delivery 

▶ 2주마다 새 버전이 꼭 나와야함. 잦은, 빈번한 기능 추가,

    Req는 simple user stories, scenarios에 기반함.

Maintain simplicity 

▶ 프로세스 단순화, 코드 단순화(refactoring)

People, not process

▶ Pair programming : 2인 1조로 같이 있으면서 개발. 문서 없이도, 논의를 하기 때문에 없어도 됨. 모든 코드가 공동 소유

 

그 외에도,

Incremental planning : 매 버전마다 새로운 plan. 

요구사항은 "story card"에 기록되고, release에 포함될 story는 사용 가능한 시간과 상대적 우선순위에 따라 결정된다. 개발자는 user stories를 task로 나눈다.

Small release : 중요한 기능부터 개발. system release를 자주 하며, 잦고 빈번한 기능 추가

Simple design : 

Test-first development : 

Refactoring : 코드 다듬기. ch2에 자세한 설명

Pair programming : 커뮤니케이션 강화

Collective ownership : 공동 소유. 개발자들은 시스템의 모든 영역에서 작업하므로 모두가 코드에 관여. 누구나 무엇이든 바꿀 수 있다.

Continuous integration : 1. 내 코드 짜고 test 통과시키고, 2. 합칠 땐 다른 모든 test들을 통과해야 합칠 수 있다. -> 중앙 서버에는 언제든 출시가 가능한 완벽한 코드가 있다.

Sustainable pace : 과로 금지. 여유롭게

On-site customer : system의 ens-user인 customer가 XP팀을 위해 풀타임으로 업무 가능해야함. 극단적으로, 개발팀의 구성원이며, 구현을 위해 팀에 시스템 요구 사항을 제공할 책임이 있다.( evaluation, validation)

 

 

 

Influential XP Practices

 -XP는 좀 극단적인 면도 있고, 굉장히 어렵다. 대부분의 기업에 스며들기 어려운 방식이다.

따라서, 기업은 그들의 작업방식에 적합한 XP방식을 선택한다. 때로는, 이런게 그들의 own process에 포함되기도 한다. (ex. scrum)

 

가장 영향력있는 XP 

- User stories

- Refactoring

- Test-first development

- Pair programming

 

 

1. User Stories

- 사용자가 그 기능을 쓰는 모습을 묘사하여 story card에 적음

- Req Engineering을 쉽게하기 위해 개발됨. 

Story card가 다 됐으면, tasks로 바꿈

 

 

 

 

Task cards

 

 

그리고 customer가 구현할 stories에 우선순위를 매기고, 다음 release에 포함할 stories를 선택. (2주 내에 구현할 수 있는 유용한 기능 식별)

 

 

User Stories의 장단점

(장점1) 바꾸기 쉬움

Req가 change할 때, 구현하지 않을 stories는 바꾸거나 버림 , 새로운 story cards를 만들 수 있음.

user story는 계속 바뀔 수 있음 (2주마다)

 

(장점2) 쓰기 쉬움. easiness

 

(단점) completeness. 기술적으로 쓰는게 아니라 유저 입장에서 대강 쓰는 것이기 때문에 모든 걸 다 썼는지는 보장 X. 

-> 이를 보완하기 위해, customer가 지속적으로 피드백 줘야함. 

completeness 약점 = community로 보완!

 

 

2. Refactoring

- Traditional software engineering 방식인 plan-driven으로는, 향후 생길 변화를 예상해야 하고, 이후 배용을 줄이기 위해 변경을 예상하는 데 시간을 할애할 가치가 있다.

 

- Extreme programming 에서는, 예측해봤자 시간낭비이고, 2주 만큼만 완벽히 계획하고자 함.

 

- 대신, 2주 뒤에 날아온 피드백을 위해서, 코드는 항상 깔끔하게.

 

Refactoring이란?

- 기능은 그대로. 코드만 improve

- 개발팀은 코드의 개선사항을 찾고 즉시 개선. 즉각적인 필요가 없을 때에도 개선.

 

- Incremental development의 근본적인 문제점 : Local changes는 s/w 구조의 degrade를 야기함. 결국 구현이 점점더 힘들어짐

 

- Refactoring은 software structure와 readability를 개선하여, software 변경 시 구조적 degrade를 막고자 함.

 

 

 

Examples of Refactoring

 

변수 및 메서드 이름 바꾸기, 중복 코드 제거, 클래스 계층 구조 재구성 등등

** 중복은 최악 중의 최악

 

 

 

 

 

프로그램 개발 환경에는 일반적으로 리팩토링을위한 도구가 포함된다. : 코드 간의 종속성 찾기, 전역 코드 수정 등

 

 

- 때때로 새로운 기능 개발하느라 refactoring이 뒷전이 되기도 하는데, 코드를 지속적으로 변경해야하므로 최대한 빨리 refactoring해야한다. 개발 기간을 산정할 때, refactoring하는 기간 반드시 포함하자!

 

- 일부 새로운 기능 및 변경사항은 refactoring으론 어림없고, architecture modification(수정)을 해야할 수도 있다.

 

함수는 최대한 조각조각내라. reuse할 수 있도록. 관리도 편해짐

 

3. Test-first Development

- Incremental development는 plan-driven 에 비해 좀 허접한 testing을 행한다.

 

- XP에서 test는 automated + 개발 프로세스의 중심(central)

- 모든 test를 통과하지 못하면 개발 진행 X

 

- XP에서의 testing의 핵심 특징들

(1) Test-first development

(2) Incremental test development from scenarios

(3) User involvement in test development and validation

(4) The use of automated testing frameworks

 

3-(1) Test-first development

- software engineering의 가장 혁신적인 것들 중 하나.

- 지금은 보다 일반적인 test-driven devleopment(TDD)로 진화함.

 

코드를 짜고, 그거에 대한 테스트 코드를 짜는게 아니라,

코드를 짜기 전에 테스트 코드를 짬.

 

 

 

 

 

 

* Interface. 함수 정의 - 3가지 정의. 1) 함수이름 2) 함수의 parameter 3) 리턴하는 것

* Behavior. 예외사항 같은거 처리

 

장점 

- 구현할 requirement를 명확히 함. 

test를 먼저 짜면서 먼저 interface와 behavior를 정의하기 때문에. 

- "test-lag" 문제를 피할 수 있음.

개발자가 tester보다 빠르게 작업하면 test를 건너 뛰는 경향이 있습니다.

- 모든 코드에 대해서 test가 존재하게 됨

 

3-(2) Incremental Test Development

- XP에서 요구사항은 user story로 점진적으로 개발되며, 이러한 요구사항은 일련의 task로 나뉜다.

 

- 각각의 task들에 대해,  하나 이상의 unit test가 task에 적힌 구현해야할 것들을 체크하기 위해 제작된다.

 

 

 

 

 

[ Unit test case ]

input, 뭘 수행하는지, output 3개 정의

 

ex) assert (divide(3,2) == 1.5)

 

 

 

 

3-(3) User involvement

- Testing process에서의 customer의 역할 : 시스템의 다음 release에서 구현될 story에 대한 acceptance test 개발을 돕기 위해

 

- Acceptance testing : 고객 데이터를 사용해서 시스템을 테스트하여 실제 요구사항을 충족하는지 확인하는 프로세스

 XP에서는 customer가 test를 작성한다. ( 코딩하는게 아니라 test할 것을 정의하는거임)

 

- user(customer) involvement의 문제점 : customer는 개발팀과 풀 타임으로 작업할 수 없다. 현재 요구사항만으로도 충분하여 테스트하기를 꺼려할 수도 있음.

 

3-(4) Test Automation

Test는 실행가능한 요소로 작성된다. task가 구현되기 전에. 

Test의 조건들 

- stand-alone : 독립적으로 수행가능해야함

- input, output 신경써야함

 

automated test framework는 위처럼 test가 executable 하도록 하는 것을 쉽게 해준다.

 

testing이 자동화되면, 항상 빠르고 쉽게 실행되는 tests 들이 존재한다. 

시스템에 기능이 추가될 때마다 test를 실행하고 새 코드의 문제를 즉시 알 수 있다.

 

 

Test-first development의 문제점

- testing 보다 programming을 선호할 수도 있고, 그러다보면 불완전한 test를 작성하거나, test writing을 잘 안하게 됨. test수가 줄어듬

 

- 함수의 리턴값을 얻어내는 테스트만 가능. display logic같이 화면 배치 등은 test 불가능

 

- tests의 completeness를 판단하기 어려움. test가 아무리 많아도 '완벽'하다고 단정지을 수 없음.

 

 

 

 

4. Pair Programming

- 짝을 이루고 같은 컴퓨터를 두고 앉아서 같이 개발. 

- 조원이 바뀌면서 맡은 모듈도 달라짐 -> 코드가 공동책임 ( collective ownership)

 

장점

- collective ownership and responsibility 

 누군가 퇴사한다 하더라도 별문제 x

 

- informal review process

같은 코드를 적어도 두 명 이상의 사람이 보니깐

test말고 이러한 code inspection and review로 60-70%의 에러를 잡아낸다. 코드의 숨어있는 에러 찾기에는 테스트보다 이게 적합.

단점) 코딩속도 느려짐. 

장점) bug, error 잡아냄, rework 적어짐

 

- refactoring 활발

앞팀이 코드를 개떡같이 짜면 뒷팀이 보고 refactoring 할수밖에 없음

 

 

Pair programming의 생산성. 이게 진짜 좋은가?

- 코딩 실력이 보통인 사람 2명을 짝 지어놓으면 효과 good. cross check의 긍정적 영향.

- but, 코딩실력이 높은 사람들은 따로 하는 것이 낫다. 

 

- sharing of knowledge는 정말 좋음.

 

 

 

 

Difficulties in Agile Project Management

- 매니저 입장에서 곤란. 관리하기 어려움

문서가 없으니깐, 얘네가 뭘하는지, 주어진 예산이나 시간 내에 목표 달성할 수 있을지 등등 알수가 없음

 

- visibility에 대한 비즈니스 요구사항과 충돌

 

XP에 없는 것 : 1) 전체적인 view를 보는 것 2) 개선하는 프로세스(improve) 

근데 이걸 갑자기 도입하기 어려움 -> Scrum 시행

 

 

 

Scrum 

스크럼의 등장

- 위에 말한 것처럼 manage의 어려움.

- 스크럼은 framework for organizing agile projects / external visibility 제공

framework :

incremental delivery를 어떻게 수행하면 좋을까에 대한 framework.

- 도입하기 쉬움. (특정 개발 관행(specific development practices)을 의무적으로 시행하는게 아니라서)

- 개발 뿐만 아니라 기획팀 등에서도 쓸 수 있음. widely used method

 

 

Scrum Sprint Cycle

Product Backlog

전체 해야할 일의 총집합 (user stories)

user stories나 기능이 아니더라도 이것저것 해야할 일들.

 

- 얼마나 자세하게 적을까? 다양한 레벨의 detail로 적어질 수 있는데, 팀끼리 정해야 한다. 

- Product Owner 가 backlog 관리. 이 사람 스크럼할 때 개발자들을 이끌어서 제품에 책임을 지는 사람. customer-개발자 간의 중간다리 역할도 함.

 

Sprint Backlog

user story에서 몇 개 골라서 task. 

이번 기간동안 만들 것만 추린 것.

 

 

Sprint Cycle

각 sprint cycle의 주기는 고정되어있다.

 

1. sprint cycle의 초반에는, 팀끼리 sprint planning meeting을 해야한다. 

product backlog -> sprint backlog 단계. 하루정도 잡고 다 모여서 결정. 

- product backlog에서 우선순위 매기고, 몇개 추려서 sprint backlog 정의

- sprint backlog의 user story를 개발자 관점으로 task로 쪼갬.

- task를 개발자들에게 분담.

 

2. sprint backlog가 만들어지면, 이제 sprint cycle로 들어간다. 

* sprint backlog는 실패한다하더라도 중간에 바뀌지 않는다.

 

Daily Scrums

- 모든 팀원들이 모여서 정보 공유

- 어제 뭐했고, - 오늘 뭐할거고, - 문제는 뭐였는지

- 따라서 모두가 프로세스 진행 상황을 알 수 있게 된다.

- 모두 동등한 위치에서 논의 (scrum master+members. product owner는 조직에 따라 다름)

- 짧게 하기 위해 서서 해야함. 최대 15분. 보통 정시에 시작

- 디테일한 토의 X

 

3. sprint cycle의 마무리 단계에는, 두개의 meeting이 있다.

1) Sprint review (about product)

- 이해관계자들과 제품에 관한 토의

 

2) Sprint retrospective (about process)

- 팀워크, 프로세스 등 이것 저것에 대한 토의

 

 

Scrum Ceremonies

1) Sprint cycle이 돌기 전에 Sprint Planning Meeting

2) 전체적인 view를 볼 수 있는 Daily Scrum Meeting

3) Sprint review meeting. 제품에 대한 리뷰

4) Sprint retrospective meeting. 팀웤, 프로세스 등 전체적으로 리뷰. 개선할 점 논의. 

XP에 없던 것 2가지. 

 

 

Scrum Board

 

 

 

포맷이 정해져 있진 않지만 일반적으로 그림과 같다.

User story

 

To do : 이번 cycle 에 할 일

 

Status 를 한눈에 볼 수 있는 도구 (XP에는 없는 것!)

 

 

 

 

 

목적 : - 팀의 상태를 공유, - 누구나 저 포스트잇을 바꾸거나 옮길 수 있음. - 누구든지 저걸 보고 status를 파악할 수 있음

 

 

 

Scurm Master

- 스크럼 개발팀 중 1인.

- 스크럼을 잘 지키도록 가이드. Ex) review가 이루어지도록 사람들에게 알림, daily scrum이 잘 이루어지도록 회의실 예약 등등

- servant-leader 역할. 서포터같은. 

- product owner를 도와서 product backlog가 유지되도록 도움. 

- 스크럼 교육을 받음.

 

Product Owner

- 개발팀X. 개발팀을 이끌어 제품에 대한 책임을 지는 사람. 

- 고객-개발팀 중간다리 역할. (얼마나 고객을 만족시킬지, 얼마나 돈을 벌수 있을지 등. 비즈니스 적으로 좋은 결과가 있도록)

- 주요 역할 : product backlog를 유지하는 것

 

- Scrum team은 반드시 오직 한 명의 product owner가 있어야한다.

- scrum master와 product owner는 같은 사람이 할 수 없다.

 

 

팀원 모두가 모든 것을 공유하는 수평적 구조

 

Kanban

- 눈으로 보는 판. 눈으로 flow 파악

- 소프트웨어 프로세스를 정의, 관리, 개선하는 간단한 방법. 원래는 도요타에서 썼던 방법

목적 

- visualize your work

- 효율성 up

- 연속적인 improve. : 막힌 부분이 보이면 다같이 해결함 / cycle의 제약이 없음

flow가 계속 흘러가도록 

 

Scrum의 문제점

- 개발 주기(development cycle)이 너무 짧다. 보통 2-4주.

-> 각각의 work item이 small 할 수 밖에 없음. 

- 4주를 못지키고 testing을 아직 못한 기능들이 빠지는 불상사 발생.

 

 

Kanban에서는 cycle의 제약을 아예 없앰. continuously하게 버전업. 

* WIP limit (WorkIn Process limit) : 일에 제한을 두어 더욱 확실하게. maximum amount of work items in the different stages.

 

4 Basic Principles 

1. 지금 하고 있는 일에서 시작하라. 지금 하는 일을 칸반으로 표시. 

2. 꾸준하고 점진적인 변화

3. 모든 일을 공유. 모든 구성원이 100% 동등한 지식을 가지고 같이 리더십을 발휘해서 같이 고쳐나가자

4. 모두가 연속적인 improvement에 기여하기

 

가능한 한 기존 것을 건드리지 말고, visualize해서 발전시키기. 

flow를 시각화 함으로써, 점진적으로 발전. 

 

 

6 Practices 

1. Visualize the Workflow

- 가로행엔 workflow(process) step을 적음 

- 각 칸반 카드에는 work item.

- 무언가 아이템을 시작할 때는 맨 처음인 To do 부터 시작. 

-> bottleneck. 막히는 부분을 쉽게 찾을 수 있다.

 

2. Limit Work in Process 

work-in-process (WIP) limit 

각 단계마다 WIP limit을 두어 각 단계에 보다 집중하도록. 

- 전체적으로 manage할 수 있는 양만큼 부여

- 사람들의 role을 지정하지 않고 다같이 함

 

3. Manage Flow

flow : 개발 프로세스에서의 work items들의 움직임

flow관리하는 것에 집중하여 빠르고 효율적으로 work할 수 있도록

 

----1,2,3 : flow에 관한 이야기

----4,5,6 : 사람들이 모든 걸 투명하게 & 협심

 

4. Make process policies explicit 프로세스 정책을 명시적으로 만들기

팀의 프로세스를 명확하게 게시하고 알림.

결정이 일어나는 근거 등을 모든 사람들이 알아야함.

 

5. Implement feedback Loops

어떤 사람이 improve에 관한 의견을 냈으면 (ex. 저 부서에서 문제 있는거 아니냐), 그 의견에 대한 피드백을 줘야함

조직은 변화에 적절히 대응하고 이해 관계자간에 지식을 전달해야 한다.

 

6. Improve collaboratively

협업을 통해 개선. 

각자 특정 role을 가지고 있지 않고, 다같이 공유하고 문제 해결

 

 

Kanban의 장점

- 다같이 움직인다.

- workflow 의 bottleneck을 쉽게 파악가능

- flexibility. 유연하게 어디든 적용이 가능하다.

- 팀의 응답속도 빠름. responsive

- 현재의 task에 집중할 수 있음. 너무 많은 task가 오지 않음. WIP덕분에. 

만약 문제가 발생하면 collaborate해서 해결

 

Scrum vs Kanban

 

 

 

DevOps

software development (Dev) + IT operations (Ops)

 

-agile은 아니지만 깊은 연관.

 

목적 : - system development의 life cycle 축소   - continuous delivery with high software quality

 

개발, 테스트, 서버 설정 등 다 손으로 하면 흐름이 느림 -> tools를 이용한 자동화

 

 

 

 

 

 

 

 

 

DevOps vs Agile

agile과 DevOps는 독립된 것이 아니라 complementary roles. 

몇몇 DevOps practices는 agile methods로부터 유래됨 ( automated build and test, continuous integration, continuous delivery)

 

 

DevOps Toolchain

 

 

개발의 전 과정과 운영의 전 과정을 스무스하게 연결

Tools를 통해 자동화 함으로써 continuous delivery

 

tools을 많이 알수록 devops를 잘 아는 것. 

 

DevOps = 개발 + QA(결과물을 test) + 운영

 

 

 

 

- code, build, test, package, relese, configure, monitor 

 

 

 

 

 

Problems with agile methods

1. Requirement를 뭘 해야하는지 정확히 모르니까 법적인 계약서 성립X. 

Traditional model vs Agile model

Traditional model : 기능 확정 -> 기간과 비용을 예측

Agile method의 경우엔, 기간과 비용을 먼저 fixed -> 기능을 예측하며 개발

 

 

2. small co-located team에만 적용 가능

 

3. customer가 협업하는 것 쉽지 않음. 

 

4. 팀원의 퇴사 등으로 인해 개발팀이 유지되지 않을 경우, 이어서 하기 어렵다. document도 없고.

 

 

 

Agile Principles에서의 어려움

Customer involvement : customer도 본업이 있으니까 계속 피드백하기 어려움

Embrace change : req는 변한다고 가정하고, cycle마다 req를 받아서 버전업을 하자고 했는데, 이해관계자가 많은 시스템에서 변경사항에 대해 서로 다른 우선순위를 부여할 수 있음

Imcremental delivery : 비즈니스나 마케팅 쪽에서의 longer-term planning 장기적인 계획 어려움. 

Maintain simplicity : 일정의 압박으로 code refactoring, 코드/프로세스 단순화 어려울 수 있음 

People, not process : 사람과의 커뮤니케이션 잦아야하는데 이건 사람의 성격에 따라 불편할 수 있음

 

 

 

 

 

Agile vs. plan-driven methods

System 측면

1. system size.  small->agile / larger ->plan-driven

2. system type. 

3. system lifetime. 

long -> plan-driven (more documentation)  / agile은 문서가 없으니까 1년뒤에 그거 다시 해, 하면은 잘 못함. 개발팀이 그대로 유지되는 경우도 적음

4. external regulation 외부규정

yes -> plan-driven. 규정상 승인을 받아야 하므로 문서 필요

 

Development Team 개발팀의 성향

1. 스킬 high->agile / low ->plan-driven

2. 팀 조직이 분산 -> plan-driven

3. 개발을 서포트할 기술, 도구에 익숙 -> agile / 아니면 -> plan-driven

 

Management 측면

1. 계약상의 이유로 구현으로 이동하기 전에 매우 상세한 사양과 설계를 갖는 것이 중요 -> plan-driven

2. 고객 또는 다른 시스템 이해 관계자에게 소프트웨어를 제공하고 그들로부터 신속한 피드백을받는 점진적 제공 전략이 가능 -> agile

3. 고객이 대표성이 충분하고, 개발팀에 참여를 기꺼이 받아들인다. -> agile

4. 회사분위기가 전통적 -> plan-driven