Agile

소프트웨어 생명주기 모델

: 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것으로 폭포수 모델, 프로토타이핑 모델, 나선형 모델, 반복적 모델이 있다

 

waterfall (폭포수 모델)

: 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델

타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수

단계별 정의와 산출물이 명확하다. 하지만 기획 단계부터 수정되기 시작하면 일정과 비용 등 여러 항목에서 문제점이 생기기 때문에 요구사항 변경이 어렵다

https://www.boardinfinity.com/blog/a-quick-guide-to-arrays-in-python/

---

소프트웨어 개발 방법론

: 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법

소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론으로 구조적 방법론, 정보공학 방법론, 객체 지향 방법론, 컴포넌트 기반 방법론, 애자일 방법론, 제품 계열 방법론이 있다

 

애자일 방법론

: 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론

개발 기간이 짧고 신속하며, 개발과 함께 즉시 피드백을 받아 유동적으로 개발한다. 대표적으로 XP, Lean, Scrum이 있다

https://soldevelo.com/blog/is-agile-always-the-best-solution-for-software-development-projects/

 

스크럼(Scrum)

: 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

• Backlog : 제품과 프로젝트에 대한 요구사항
• Sprint : 2~4주의 짧은 개발 기간을 반복적으로 수행함으로써 개발 품질 향상
• Scrum Meeting : 매일 15분 정도 미팅으로 To-Do List 계획 수립, 데일리 미팅이라고도 함
• Scrum Master : 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
• Sprint Retrospective (스프린트 회고) : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록함. 보통 해당 스프린트가 끝난 시점이나 일정 주기로 시행한다.
• Burn Down Chart : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
  (백로그는 보통 수직축, 시간은 수평축에 위치)

린 LEAN

: 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론

- JIT(Just In Time), 칸반 보드 사용

• 낭비 제거 : 불필요한 기능, 과도한 문서 작업, 복잡한 프로세스 등 개발 과정에서 가치를 창출하지 않는 모든 활동 제거
• 품질 내재화 : 오류를 사전에 예방하고, 처음부터 높은 품질의 제품을 개발하여 나중에 발생할 수 있는 비용과 시간 소모 감소
• 지식 창출 : 지속적인 학습과 실험을 통해 팀과 조직의 지식을 증진시키며, 이를 통해 프로젝트의 결과와 효율성 개선
• 늦은 확정 : 최종 결정을 가능한 늦게 내려서 변화에 유연하게 대응할 수 있도록 함.
  (더 많은 정보를 바탕으로 더 나은 결정을 내릴 수 있도록)
• 빠른 인도 : 가치를 신속하게 고객에게 전달함으로써 고객의 피드백을 빠르게 얻고, 이를 바탕으로 제품 개선
• 사람 존중 : 모든 팀원이 가치 있는 기여를 할 수 있도록 하며, 그들의 창의력과 동기를 존중하고 활용함
• 전체 최적화 : 개별 부분의 최적화가 아닌 전체 프로세스와 가치 스트림의 효율성과 효과성 극대화

* 칸반(Kanban): 작업의 흐름을 시각화하여 현재 진행 중인 작업의 양을 제한함으로써 생산성을 높이는 방법론. 칸반 보드를 사용하여 작업의 상태(예: 할 일, 진행 중, 완료)를 관리한다

 

XP (eXtreme Programming)

: 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

1~3주의 반복 개발주기를 가지며, 5가지의 가치와 12가지의 실천 항목이 존재한다

 

XP의 5가지 가치

• 용기(Courage) : 용기를 가지고 자신감 있게 개발
  (테스트와 피드백, 테스트에 부합하지 못하는 코드를 리팩토링 할 수 있는 용기)
• 단순성(Simplicity) : 필요한 것만 하고 그 이상의 것들은 하지 않음
• 의사소통(Communication) : 개발자, 관리자, 고객 간의 원활한 소통
• 피드백(Feedback) : 의사소통에 대한 빠른 피드백
• 존중(Respect) : 팀원 간의 상호 존중

XP의 12가지 기본 원리

• 짝 프로그래밍(Pair Programming) : 개발자 둘이서 짝으로 코딩하는 원리
• 공동 코드 소유(Collective Ownership) : 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
• 지속적인 통합(CI: Continuous Integration) : 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
• 테스트 기반 개발(TDD: Test Driven Development) : 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고, 이 테스트를 토오가할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
• 리팩토링(Refactoring) : 프로그램의 기능을 바꾸지 않으면서 중복 제거, 단순화 등을 위해 시스템을 재구성한다는 원리
• 계획 세우기(Planning Process) : 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
• 작은 릴리즈(Small Release) : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리
• 메타포어(Metaphor) : 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다는 원리
• 간단한 디자인(Simple Design) : 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
• 40시간 작업(40-Hour Work) : 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리
• 고객 상주(On Site Customer) : 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
• 코드 표준(Coding Standard) : 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리

---

참고

• 정보처리기사 실기 (저자: NCS 정보처리기술사 연구회 | 출판사: 건기원)
• OpenAI