"애자일 소프트웨어 개발"의 두 판 사이의 차이

 
(같은 사용자의 중간 판 9개는 보이지 않습니다)
1번째 줄: 1번째 줄:
==개요==
==개요==
;Agile software development
;Agile software development, agile, Agile
;애자일 소프트웨어 개발, 애자일 개발 프로세스, 애자일 방법론, 애자일 모형; 애자일
;애자일 소프트웨어 개발, 애자일 개발 프로세스, 애자일 방법론, 애자일 모형, 애자일
*"가벼운 프로세스"
* "가벼운 프로세스"
*"민첩함", "능동적", "자발적", "형식에 구애받지 않음"
* [[협업]] + [[피드백]] ★
*[[반복 점진 개발]] + [[품질 개선 활동]]<ref name='imaso39368'>http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=39368</ref>
* "민첩함", "능동적", "자발적", "형식에 구애받지 않음"
*프로그래밍에 집중하는 유연한 개발 방식
* [[반복 점진 개발]] + [[품질 개선 활동]]<ref name='imaso39368'>http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=39368</ref>
*요구사항 피드백을 계속 받고 자주 릴리즈
* 프로그래밍에 집중하는 유연한 개발 방식
*프로젝트의 생명주기동안 반복적인 개발을 촉진하는 소프트웨어 공학 개념
* 요구사항 피드백을 계속 받고 자주 릴리즈
*신속하고 적응적으로 소프트웨어 개발을 실시하는 가벼운 개발 방법들의 총칭
* 반복적인 개발주기와 자기조직화 팀을 강조하는 실무적 방법 모음
*아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 함
* 프로젝트의 생명주기동안 반복적인 개발을 촉진하는 소프트웨어 공학 개념
*원리: 고객참여, 반복적 릴리스, 사람 중시, 변경 수용, 단순성 유지
* 신속하고 적응적으로 소프트웨어 개발을 실시하는 가벼운 개발 방법들의 총칭
* 가치가 프로젝트의 맨 마지막에 생성되는 폭포수 프로젝트와 달리, 애자일 소프트웨어 개발은 지속적·점진적인 가치 전달과 프로세스 자체의 진화적 개선에 중점을 둔다.
* 원리: 고객참여, 반복적 릴리스, 사람 중시, 변경 수용, 단순성 유지
*타임박싱을 도입한다. 작동하는 소프트웨어를 기준으로 한다. 협업한다.
----
* 소프트웨어 프로젝트의 모든 이해관계자에 대한 요구사항을 정의, 의사소통 및 이해하는 것은 매우 어렵다.
* 그러나 고객은 소프트웨어 프로젝트가 제 시간에, 좋은 품질로, 예산과 범위 내에서 제공되기를 원한다.
* 폭포수 전략과 달리, 애자일 소프트웨어 개발은 주기적인 특성이 있어 요구사항을 지속적으로 적용하고 더 빠르게 적응할 수 있다.
----
* 애자일 소프트웨어 개발에는 요구공학, 계획, 구현, 검토, 테스트, 전달과 같은 전통적(폭포수와 같은) 전략의 모든 단계가 포함된다.
* 가장 큰 차이점은 소프트웨어 프로젝트의 전체 시간 범위가 각 단계가 모든 단계를 포함하는 반복으로 분할된다는 것이다.
* 각 반복 후에 생성된 가치는 고객과 함께 검토될 수 있으며 요구사항은 최종 목표를 향해 조정될 수 있다.
* 또한 개발 팀은 프로세스 자체를 개선하기 위해 취해야 할 조치사항에 대해 회고한다.


==특징==
==특징==
22번째 줄: 34번째 줄:
:상시적으로 요구를 추가·수정하는 과정 (적응형)
:상시적으로 요구를 추가·수정하는 과정 (적응형)


https://upload.wikimedia.org/wikipedia/commons/thumb/1/1c/Agile-vs-iterative-flow.jpg/620px-Agile-vs-iterative-flow.jpg
[[파일:Agile-vs-iterative-flow.jpg|620px]]
 
==실천예시==
* ★ [[익스트림 프로그래밍]](XP) - 2주 주기로 반복개발
* ★ [[테스트 주도 개발]](TDD)
* [[RUP]]
* [[스크럼]] - 스프린트(30일 주기)마다 동작가능한 산출물
* [[크리스탈 클리어]]
* [[적응적 소프트웨어 개발]]
* [[피처 드리븐 개발]]
* [[동적 시스템 개발 방법]](DSDM)


==의견==
==의견==
34번째 줄: 56번째 줄:
:다만 일정이 지연된다면 어쩔 수 없는 경우도 있음
:다만 일정이 지연된다면 어쩔 수 없는 경우도 있음
:애초에 계획을 잘못 세운 것이 문제임…<ref>... 어떻게 하면 계획을 잘 세우나??? ...</ref>
:애초에 계획을 잘못 세운 것이 문제임…<ref>... 어떻게 하면 계획을 잘 세우나??? ...</ref>
==실천예시==
*[[익스트림 프로그래밍]](XP): 2주 주기로 반복개발
*[[스크럼]]: 스프린트(30일 주기)마다 동작가능한 산출물
*[[RUP]]
*[[크리스탈 클리어]]
*[[적응적 소프트웨어 개발]]
*[[피처 드리븐 개발]]
*[[동적 시스템 개발 방법]](DSDM)


==같이 보기==
==같이 보기==
* [[애자일 소프트웨어 개발 선언]]
{{z컬럼3|
* [[애자일 선언 이면의 원칙]]
* [[스크럼]]
* [[소프트웨어 공학]]
* [[반복 점진 개발]]
* [[폭포수 모델]]
* [[린 스타트업]]
* [[분진합격]]
* [[분진합격]]
* [[분할정복]]
* [[분할정복]]
* [[스크럼]]
* [[린 스타트업]]
* [[폭포수 모델]]
* [[반복 점진 개발]]
* [[소프트웨어 공학]]
* [[페어 프로그래밍]]
* [[페어 프로그래밍]]
* [[애자일 선언 이면의 원칙]]
* [[애자일 소프트웨어 개발 선언]]
}}


==참고==
==참고==

2022년 7월 18일 (월) 14:43 기준 최신판

1 개요[ | ]

Agile software development, agile, Agile
애자일 소프트웨어 개발, 애자일 개발 프로세스, 애자일 방법론, 애자일 모형, 애자일
  • "가벼운 프로세스"
  • 협업 + 피드백
  • "민첩함", "능동적", "자발적", "형식에 구애받지 않음"
  • 반복 점진 개발 + 품질 개선 활동[1]
  • 프로그래밍에 집중하는 유연한 개발 방식
  • 요구사항 피드백을 계속 받고 자주 릴리즈
  • 반복적인 개발주기와 자기조직화 팀을 강조하는 실무적 방법 모음
  • 프로젝트의 생명주기동안 반복적인 개발을 촉진하는 소프트웨어 공학 개념
  • 신속하고 적응적으로 소프트웨어 개발을 실시하는 가벼운 개발 방법들의 총칭
  • 가치가 프로젝트의 맨 마지막에 생성되는 폭포수 프로젝트와 달리, 애자일 소프트웨어 개발은 지속적·점진적인 가치 전달과 프로세스 자체의 진화적 개선에 중점을 둔다.
  • 원리: 고객참여, 반복적 릴리스, 사람 중시, 변경 수용, 단순성 유지
  • 타임박싱을 도입한다. 작동하는 소프트웨어를 기준으로 한다. 협업한다.

  • 소프트웨어 프로젝트의 모든 이해관계자에 대한 요구사항을 정의, 의사소통 및 이해하는 것은 매우 어렵다.
  • 그러나 고객은 소프트웨어 프로젝트가 제 시간에, 좋은 품질로, 예산과 범위 내에서 제공되기를 원한다.
  • 폭포수 전략과 달리, 애자일 소프트웨어 개발은 주기적인 특성이 있어 요구사항을 지속적으로 적용하고 더 빠르게 적응할 수 있다.

  • 애자일 소프트웨어 개발에는 요구공학, 계획, 구현, 검토, 테스트, 전달과 같은 전통적(폭포수와 같은) 전략의 모든 단계가 포함된다.
  • 가장 큰 차이점은 소프트웨어 프로젝트의 전체 시간 범위가 각 단계가 모든 단계를 포함하는 반복으로 분할된다는 것이다.
  • 각 반복 후에 생성된 가치는 고객과 함께 검토될 수 있으며 요구사항은 최종 목표를 향해 조정될 수 있다.
  • 또한 개발 팀은 프로세스 자체를 개선하기 위해 취해야 할 조치사항에 대해 회고한다.

2 특징[ | ]

  • 짧은 기간 단위[2]의 반복 절차를 통해 리스크를 줄임
  • 개발 주기(계획, 개발, 출시)가 여러 번 반복
  • 요구사항이 추가·변경됨
  • 고객의 피드백에 민첩하게 반응
  • 문서작업 줄이고 프로그래밍에 집중
  • 고전적인 개발방법론, 폭포수 모형의 반대 개념
  • 일정한 주기를 가지고 끊임없이 프로토타입 작성
상시적으로 요구를 추가·수정하는 과정 (적응형)

Agile-vs-iterative-flow.jpg

3 실천예시[ | ]

4 의견[ | ]

  • 문서화 금지?[1]
문서를 통한 의사소통, 인수인계 지양하는 것은 맞음
문서를 만들지 말라는 것은 아님
문서를 어떻게 작성하는지가 중요…[3]
  • 야근 금지?[1]
비효율적이므로 지양해야 하는 것은 맞음
다만 일정이 지연된다면 어쩔 수 없는 경우도 있음
애초에 계획을 잘못 세운 것이 문제임…[4]

5 같이 보기[ | ]

6 참고[ | ]

  1. 1.0 1.1 1.2 http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=39368
  2. 보통 1~4주
  3. ... 그래서 어떻게 작성하나??? ...
  4. ... 어떻게 하면 계획을 잘 세우나??? ...
문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}