[소프트웨어 공학] 03. Agile Software Development

Agile Software Development

Rapid Software development

• 빠른 개발과 배포는 이제 소프트웨어 시스템에 대한 가장 중요한 요구 사항 중 하나입니다.
  • 비즈니스는 빠르게 변하는 요구 사항 속에서 운영되며, 안정적인 소프트웨어 요구 사항을 도출하는 것은 실질적으로 불가능합니다.
  • 소프트웨어는 변화하는 비즈니스 요구 사항을 신속하게 반영하기 위해 빠르게 진화해야 합니다.
• 일부 시스템 유형에 계획 주도 개발이 필수적일 수 있지만, 이는 이러한 비즈니스 요구 사항을 충족시키지 못합니다.
• 애자일 개발 방법은 1990년대 후반에 등장하여 작동하는 소프트웨어 시스템의 배송 시간을 극적으로 줄이는 것을 목표로 했습니다.

Agile Development

• 프로그램 명세, 설계, 구현 및 테스팅은 서로 중첩됩니다.
• 시스템은 이해 관계자가 버전 명세 및 평가에 참여하는 일련의 버전 또는 증분(a series of versions or increments)으로 개발됩니다.
• 새로운 버전은 자주 배포되어 평가됩니다.
• 개발을 지원하기 위해 광범위한 도구 지원(EXtensive tool support)(예: 자동화된 테스팅 도구)이 사용됩니다.
• 최소한의 문서화 - 작동하는 코드에 중점을 둡니다.

Plan-driven and agile development

Plan-driven and agile development

• 계획 기반 개발(Plan-driven development)
  • 소프트웨어 공학에 대한 계획 주도 접근 방식은 미리 계획된 각 개발 단계별로 분리된 출력물을 만드는 것을 기반으로 합니다.
  • 반드시 워터폴 모델이 필요한 것은 아니며, 계획 주도(plan-driven), 점진적 개발(incremental)이 가능합니다.
  • 활동 내에서 반복이 발생합니다.
• 애자일 개발(Agilie development)
  • 명세, 설계, 구현 및 테스팅은 서로 중첩되며, 개발 프로세스 중 협상을 통해 출력물이 결정됩니다.

Agile methods

• 1980년대와 1990년대의 소프트웨어 설계 방법의 과도한 부담에 대한 불만으로 애자일 방법이 창출되었습니다. 이 방법들은:
  • 설계보다는 코드에 중점을 둡니다.
  • 소프트웨어 개발에 반복적 접근 방식을 기반으로 합니다.
  • 빠르게 작업 소프트웨어를 제공하고, 이를 변화하는 요구 사항에 맞게 적응시키려 합니다.
• 애자일 방법의 목표는 소프트웨어 프로세스의 부담(reduce overheads)을 줄이고(예: 문서화 제한) 변화하는 요구 사항에 신속하게 반응할 수 있도록 하는 것입니다.

Agile manifesto

• 우리는 소프트웨어 개발의 더 나은 방법을 발견하고 다른 사람들이 그렇게 하는 것을 돕고 있습니다.
• 이 일을 통해 우리가 가치 있다고 생각하는 것은:
  • 프로세스와 도구보다 개인과 상호 작용입니다(Individuals and interactions).
    • ex) IDE와 같은 Tool
  • 포괄적인 문서보다는 작동하는 소프트웨어입니다(Working Software).
  • 계약 협상보다는 고객과의 협력입니다(Customer collaboration).
    • 고객에게 참여를 요구해서, 추후 계약상의 다툼같은 일이 발생하지 않도록 함
  • 계획을 따르는 것보다는 변화에 대응하는 것입니다(Responding to change).
• 즉, 오른쪽에 있는 항목들도 가치가 있지만, 우리는 왼쪽의 항목들을 더 중요하게 생각합니다.

The principles of agile methods

• 고객 참여(Customer involvement): 고객의 역할은 새로운 시스템 요구 사항을 제공하고 우선 순위를 정한 다음 시스템의 반복을 평가하는 것입니다.
• 점진적 배송(Incremental delivery): 소프트웨어는 고객과 함께 각 증분에 포함될 요구 사항을 지정하면서 증분으로 개발됩니다.
• 프로세스가 아닌 사람(People not process): 개발 팀의 능력을 인정하고 활용해야 하며, 팀원들은 지시적인 프로세스 없이 자신의 작업 방식을 개발할 수 있어야 합니다. ==> 개개인이 중요하다
• 변화를 받아들임(Embrace change): 시스템 요구 사항이 변할 것으로 예상하고 이러한 변화를 수용할 수 있도록 시스템을 설계해야 합니다.
• 단순성 유지(Maintain simplicity): 개발되는 소프트웨어뿐만 아니라 개발 과정에서도 단순성에 중점을 둡니다.

Agile method applicability

• 제품 개발: 소프트웨어 회사가 소규모 또는 중규모의 제품을 개발하여 판매하는 경우입니다.
  • 거의 모든 소프트웨어 제품과 애플리케이션은 현재 애자일 접근법을 사용하여 개발되고 있습니다.
• 맞춤형 시스템 개발: 조직 내부에서 고객의 참여가 명확하고 소프트웨어에 영향을 미치는 외부 규칙과 규정이 거의 없는 맞춤형 시스템 개발입니다.
  • 반대로 원자력 발전소 SW와 같이 외부 요인에 의한 명세가 엄청 많은 경우, 에자일로 개발하는 것은 어려움

Extreme programming

• 익스트림 프로그래밍(Extreme Programming, XP)은 1990년대 후반에 개발된 매우 영향력 있는 애자일 방법론입니다.
• 이 방법론은 반복적인 개발 접근 방식을 '극단적'으로 취합니다.
  • 하루에 여러 번 새 버전을 만들 수 있습니다.
  • 매 2주마다 고객에게 증분을 제공합니다.
  • 모든 빌드에 대해 모든 테스트를 실행해야 하며, 테스트가 성공적으로 실행되었을 때만 빌드를 수락합니다.

The extreme programming release cycle

• 이 릴리스 주기에서 사용자 스토리를 선택하고, 스토리를 작업으로 나누고, 릴리스를 계획합니다.
• 소프트웨어 개발, 통합, 테스트를 거친 후에 소프트웨어를 릴리스하고 시스템을 평가합니다.
• 위 과정을 계속 반복

Extreme programming practices

• 증분 계획(Incremental planning): 스토리 카드에 기록된 요구 사항을 기반으로 릴리스에 포함될 스토리를 결정하고 이들을 개발 '작업'으로 나눕니다.
• 소규모 릴리스(Small releases): 사업 가치를 제공하는 최소한의 유용한 기능 세트를 먼저 개발합니다. 시스템 릴리스는 자주 이루어지며 첫 릴리스에 기능을 점진적으로 추가합니다.
• 간단한 디자인(Simple design): 현재 요구 사항을 충족하기 위한 충분한 디자인을 수행하고, 그 이상은 하지 않습니다.
• 테스트-우선 개발(Test-first development): 새 기능에 대한 테스트를 그 기능 자체가 구현되기 전에 작성하기 위해 자동화된 단위 테스트 프레임워크를 사용합니다.
  • ex) 스켈레톤 코드를 가지고 테스트를 통과시켜가면서 코드를 완성시킨다
• 리팩토링(Refactoring): 모든 개발자는 지속적으로 코드를 리팩토링하여 코드를 간단하고 유지 관리 가능하게 유지할 것으로 기대합니다.
• 페어 프로그래밍(Pair programming): 개발자들이 짝을 이루어 서로의 작업을 확인하고 항상 좋은 일을 할 수 있도록 지원합니다.
• 집단 소유권(Collective ownership): 개발자 짝은 시스템의 모든 영역에서 작업하여 전문 지식의 섬이 발달하지 않도록 하고 모든 개발자가 코드 전체에 대한 책임을 집니다.
  • 여러 명이 코드를 볼 수 있도록 프로그래밍하자
• 지속적 통합(Continuous integration): 작업이 완료되는 대로 전체 시스템에 통합합니다.
• 지속 가능한 속도(Sustainable pace): 많은 시간의 초과 근무는 허용되지 않으며, 종종 코드 품질과 중기적 생산성을 떨어뜨리는 결과를 초래합니다.
  • 사람이 감당할 수 있는 pace로 개발을 하자
• 현장 고객(On-site customer): 익스트림 프로그래밍 과정에서 고객은 개발 팀의 일원이며 시스템 요구 사항을 팀에 제공하고 구현을 위한 책임을 집니다.

XP and agile principles

• 소규모 빈번한 시스템 릴리스를 통해 증분 개발이 지원됩니다.
• 고객 참여는 팀과 함께하는 전일제 고객 참여를 의미합니다.
• 페어 프로그래밍, 집단 소유권을 통한 사람 중심의 접근법 및 장시간 근무를 피하는 프로세스를 통해 변화를 지원합니다.
• 코드의 지속적인 리팩토링을 통해 단순성을 유지합니다.

Influential XP practices

• 익스트림 프로그래밍은 기술적 초점을 가지고 있으며 대부분의 조직에서 관리 관행과 통합하기 어렵습니다.
• 결과적으로, 애자일 개발이 XP의 관행을 사용하지만, 처음에 정의된 방법은 널리 사용되지 않습니다.
• 주요 관행에는 명세를 위한 사용자 스토리, 리팩토링, 테스트-우선 개발, 페어 프로그래밍이 있습니다.

User stories for requirements

• XP에서 고객 또는 사용자는 XP 팀의 일부이며 요구 사항에 대한 결정을 내릴 책임이 있습니다.
• 사용자 요구 사항은 사용자 이야기나 시나리오로 표현됩니다.
• 이들은 카드에 기록되고 개발 팀은 이를 구현 작업(implementation tasks)으로 나눕니다.
  • 이 작업들은 일정 및 비용 추정의 기초가 됩니다.
• 고객은 그들의 우선 순위와 일정 추정을 바탕으로 다음 릴리스에 포함될 스토리를 선택합니다.

A Story Example

• 간단한 할 일 목록 앱 예시입니다.
• 앱에 필요한 것을 설명하는 일곱 개의 사용자 이야기가 있습니다.
• 한 이야기를 선택한 다음에 해야 할 작업을 식별합니다.
  • 이것에 LLM을 사용할 수 있을까요?
• 각 작업은 하위 작업을 가질 수 있습니다. 즉, 계층적입니다.
• 하나의 작업은 더 작은 작업으로 나눌 수 있습니다.
• 신중하게 식별된 작업을 검토하고 토론합니다.
• 이 게시글 최하단에 따로 정리할 예정

Refactoring

• 소프트웨어 엔지니어링에서 전통적인 지혜는 변경을 위해 설계하는 것입니다.
• 변경을 예상하고 이에 시간과 노력을 투자하는 것은 생명 주기 후반에 비용을 줄일 수 있기 때문에 가치가 있다고 합니다.
• XP는 변경 사항을 믿을 수 있게 예측할 수 없기 때문에 이는 가치가 없다고 주장합니다.
• 대신, 지속적인 코드 개선(리팩토링)을 제안하여 변경이 필요할 때 쉽게 할 수 있도록 합니다.
• 리팩토링은 소프트웨어를 개선하는 활동으로 원래의 기능을 수정하지 않습니다.
• 프로그래밍 팀은 가능한 소프트웨어 개선을 찾아서 즉각적인 필요가 없을 때도 이 개선을 합니다.
• 이는 소프트웨어의 이해를 돕고 문서화의 필요성을 줄입니다.
• 변경이 잘 구조화된 코드 때문에 더 쉽게 이루어집니다.
• 그러나 일부 변경은 아키텍처 리팩토링을 요구하며 이는 훨씬 더 비쌉니다.

Examples of refactoring

• 중복 코드를 제거하기 위한 클래스 계층의 재구성입니다
  • 보통 IDE가 이 부분은 Refactoring을 잘 해줌
• 속성 및 메소드를 정리하고 이름을 바꿔서 이해하기 쉽게 만듭니다.
  • 코드의 가독성과 유지 보수성을 높입니다.
• 프로그램 라이브러리에 포함된 메소드를 호출하는 인라인 코드의 교체입니다.
  • 메소드 추출 리팩토링입니다.

Test-first development

• 테스팅은 XP의 중심이며, XP는 프로그램이 변경될 때마다 테스트되는 방법을 개발했습니다.
• XP 테스팅 특징:
  • 테스트-우선 개발입니다.
  • 시나리오에서 나온 점진적 테스트 개발입니다.
  • 테스트 개발과 검증에 사용자가 참여합니다.
  • 새로운 릴리스가 만들어질 때마다 모든 구성 요소 테스트를 실행하기 위해 자동화된 테스트 하네스를 사용합니다.
  • Test 통과 -> Build하는 흐름

Test-driven development

• 코드 작성 전에 테스트를 먼저 작성하면 구현될 요구 사항을 명확히 할 수 있습니다.
• 테스트는 데이터가 아닌 프로그램으로 작성되어 자동으로 실행될 수 있습니다.
  • 테스트에는 정확하게 실행되었는지 확인하는 점검이 포함됩니다.
  • 주로 Junit, PyTest, Jest와 같은 테스팅 프레임워크에 의존합니다.
• 기존 테스트와 새 테스트는 새 기능이 추가될 때 자동으로 실행되며, 새로운 기능이 오류를 도입하지 않았는지 확인합니다.

Customer involvement

• 테스팅 과정에서 고객의 역할은 다음 시스템 릴리스에 구현될 스토리에 대한 수용 테스트를 개발하는 것을 돕는 것입니다.
• 팀의 일부인 고객이 개발이 진행됨에 따라 테스트를 작성합니다.
  • 따라서 모든 새 코드는 고객의 요구를 충족하는지 확인하기 위해 검증됩니다.
• 그러나 고객 역할을 맡는 사람들은 시간이 제한적이어서 개발 팀과 전일제로 일할 수 없을 수 있습니다.
  • 요구 사항 제공만으로도 충분한 기여라고 느껴 테스팅 과정에 참여하기를 꺼려할 수 있습니다.
• Test case description : Input / Tests / output

Test automation

• 테스트 자동화는 실행 가능한 구성 요소로 테스트가 작성되며 이는 작업이 구현되기 전에 이루어집니다.
  • 이 테스팅 구성 요소는 독립적이어야 하며, 테스트될 입력을 시뮬레이션하고 결과가 출력 사양을 만족하는지 확인해야 합니다.
  • JUnit과 같은 자동화된 테스트 프레임워크는 실행 가능한 테스트를 쉽게 작성하고 테스트 세트를 실행하기 위해 제출할 수 있는 시스템입니다.
• 테스팅이 자동화되어 있기 때문에, 빠르고 쉽게 실행할 수 있는 일련의 테스트가 항상 있습니다.
  • 시스템에 새 기능이 추가될 때마다 테스트가 실행되고 새 코드가 도입한 문제를 즉시 잡아낼 수 있습니다.

Problems with test-first development

• 프로그래머는 테스팅보다 프로그래밍을 선호하며 테스트를 작성할 때 종종 지름길을 사용합니다.
  • 예를 들어, 모든 가능한 예외를 확인하지 않는 불완전한 테스트를 작성할 수 있습니다.
• 일부 테스트는 점진적으로 작성하기 매우 어려울 수 있습니다.
  • ex) 복잡한 사용자 인터페이스에서 '디스플레이 로직'과 화면 간 워크플로우를 구현하는 코드에 대한 단위 테스트를 작성하기 어려울 수 있습니다.
• 테스트 세트의 완전성을 판단하기 어렵습니다.
  • 시스템 테스트가 많을 수 있지만, 테스트 세트가 완전한 커버리지를 제공하지 않을 수 있습니다.

Pair programming

• 페어 프로그래밍은 프로그래머가 짝을 이루어 코드를 함께 개발하는 것을 포함합니다.
• 이것은 코드의 공동 소유(common ownership of code)를 개발하고 팀 전체에 지식을 전파하는 데 도움이 됩니다.
• 코드의 각 라인이 한 명 이상의 사람에 의해 검토되므로 비공식적인 검토 과정(informal review process)으로 작용합니다.
• 이는 전체 팀이 시스템 코드를 개선하는 데 도움이 되는 리팩토링을 장려합니다.
• 페어 프로그래밍에서 프로그래머는 동일한 컴퓨터에 앉아 소프트웨어를 개발합니다.
• 짝은 개발 과정 동안 모든 팀원이 서로 협력하면서 동적으로 생성됩니다.
• 페어 프로그래밍 중에 발생하는 지식 공유는 프로젝트에 대한 전체 위험을 줄이는 데 매우 중요하며, 팀원이 떠날 때 중요합니다.
• 페어 프로그래밍이 반드시 비효율적인 것은 아니며, 함께 일하는 한 쌍이 별도로 작업하는 두 프로그래머보다 더 효율적일 수 있다는 증거가 있습니다.

Agile project management

• 소프트웨어 프로젝트 관리자의 주요 책임은 소프트웨어가 제시간에 그리고 예산 내에 전달되도록 프로젝트를 관리하는 것입니다.
• 프로젝트 관리에 대한 표준 접근법은 계획 중심입니다.
  • 관리자들은 프로젝트에 대한 계획을 수립하고, 무엇이 제공되어야 하는지, 언제 제공되어야 하는지, 그리고 누가 프로젝트 산출물 개발 작업을 할지에 대해 계획을 그립니다.
• 애자일 프로젝트 관리는 증분 개발과 애자일 방법론에서 사용되는 관행에 적응하는 다른 접근 방식을 요구합니다.

Scrum

• 스크럼은 특정 애자일 관행보다 반복적 개발 관리에 중점을 두는 애자일 방법입니다.
• 스크럼에는 세 단계가 있습니다.
  • 초기 단계(The initial phase)는 프로젝트의 일반 목표를 설정하고 소프트웨어 아키텍처(software architecture)를 설계하는 개요 계획 단계입니다.
  • 이는 스프린트 사이클 시리즈(a series of sprint cycles)를 따르며, 각 사이클은 시스템의 증분을 개발합니다.
  • 프로젝트 마감 단계(The project closure phase)는 프로젝트를 마무리하며, 시스템 도움말 프레임과 사용자 매뉴얼과 같은 필요한 문서를 완성하고 프로젝트에서 배운 교훈을 평가합니다.

Scrum terminology

• 스크럼 용어에는
• Development team (개발 팀) : 직접 조직한 7명 이하의 개발자 그룹 (개발하고 필수 문서를 만드는 작업을 함. / face to face meeting을 해야하기에 소규모(7명이하)로 팀을 짬. )
• Potentially shippable product increment (잠재적으로 전달 가능한 소프트웨어 증분) : Sprint에서 개발팀이 완료한 모든 작업을 통합한 결과물로, 고객에게 직접 제공할 수 있는 상태의 제품 증분
• Prouduct backlog (제품 백로그) : 해야될 일들의 리스트들 ( To-do list ) (소프트웨어의 특징 정의, 요구사항, 사용자의 말, 추가적으로 해야될 업무 기록)
• Product owner (제품 소유자) : 고객 / 프로젝트매니저 or 회사 대표일 수도 있음, 소공 프로젝트에선 팀장
• Scrum (스크럼) : 스크럼 팀이 매일( 중간중간 문서화를 안하기 때문에) 대면으로 하는 회의 => 매일 정보 공유
• ScrumMaster (스크럼 마스터) : 회의를 주도하는 사람(project leader/manager)
• ( 역할 : 팀가이드, 회사와 조율 ) (프로젝트 관리자와는 같거나 다를 수 있다)
• Sprint : 반복되는 개발 주기, 2~4주를 주기로 함.
• Velocity : 백로그를 얼마나 감당할 수 있는지 (한 팀이 한 sprint 동안)

The Scrum sprint cycle

• 스프린트는 고정된 기간으로, 일반적으로 2-4주입니다.
• 계획의 출발점은 프로젝트에서 수행할 작업 목록인 제품 백로그입니다.
• 선택 단계는 프로젝트 팀의 모든 구성원이 고객과 함께 일하여 스프린트 동안 개발될 기능 및 기능을 제품 백로그에서 선택합니다.

The Sprint cycle

• 이들이 합의되면, 팀은 소프트웨어를 개발하기 위해 자신을 조직합니다.
• 이 단계에서 팀은 고객과 조직으로부터 격리되며, 모든 커뮤니케이션은 스크럼 마스터라고 불리는 사람을 통해 이루어집니다.
• 스프린트 마스터의 역할은 개발 팀을 외부 방해로부터 보호하는 것입니다.
• 스프린트의 끝에서, 완성된 작업은 검토되고 이해관계자들에게 제시됩니다.
  • 그리고 다음 스프린트 사이클이 시작됩니다.

Teamwork in Scrum

• '스크럼 마스터'(The 'Scrum Master' is a facilitator) 는 일일 회의를 정리하고, 수행해야 할 작업의 백로그를 추적하며, 결정을 기록하고, 백로그에 대한 진행 상황을 측정하며, 팀 외부의 고객과 관리진과 커뮤니케이션합니다.
• 전체 팀은 짧은 일일 회의에 참석하여(Scrums) 모든 팀원이 정보를 공유하고, 이전 회의 이후의 진행 상황을 설명하고, 발생한 문제와 다음 날 계획된 작업을 논의합니다.
• 즉, 팀의 모든 사람이 무엇이 진행 중인지 알고(every on. he. eam knows what is going on), 문제가 발생하면 단기적인 작업을 재계획하여 대처할 수 있음을 의미합니다.

Scrum benefits

• 제품은 관리 가능하고 이해하기 쉬운 덩어리로 나누어집니다.
• 불안정한 요구 사항은 진행을 방해하지 않습니다.
• 전체 팀은 모든 것을 볼 수 있으며 따라서 팀 커뮤니케이션은 개선됩니다.
• 고객은 증분의 제시간 배송을 보고 제품 작동에 대한 피드백을 받습니다.
• 고객과 개발자 간의 신뢰가 구축되며 모두가 프로젝트의 성공을 기대하는 긍정적인 문화가 조성됩니다.

Agile Planning

• 소프트웨어 개발의 애자일 방법론은 고객에게 단계적으로 소프트웨어를 개발하여 제공하는 반복적 접근 방식입니다.
• 계획 중심 접근법과 달리, 이러한 증분의 기능은 사전에 계획되지 않고 개발 중에 결정됩니다.
  • 증분에 포함할 사항을 결정하는 것은 진행 상황과 고객의 우선 순위에 따라 다릅니다.
• 고객의 우선 순위와 요구 사항은 변경될 수 있으므로 이러한 변경을 수용할 수 있는 유연한 계획을 가지는 것이 합리적입니다.

Agile Planning Stages

• 릴리스 계획(Release planning)은 몇 개월 앞을 내다보며 시스템의 릴리스에 포함될 기능을 결정합니다.
• 이터레이션 계획(Iteration planning)은 더 짧은 기간 동안 전망하며 일반적으로 2-4주간의 작업을 팀에게 계획합니다.

Approaches to Agile Planning

• 스크럼에서의 계획은 프로젝트 백로그(해야 할 일들)를 관리하고 매일의 진행 상황과 문제를 검토하는 데 기반을 둡니다.
• 플래닝 게임은
  • 원래 익스트림 프로그래밍(XP)의 일부로 개발되었습니다.
  • 프로젝트의 진행 상황을 측정하는 데 사용자 스토리에 의존합니다.

Story-based Planning

• 플래닝 게임은 시스템에 포함될 기능을 반영하는 사용자 스토리를 기반으로 합니다.
• 프로젝트 팀은 스토리를 읽고 토론하여 구현에 필요한 시간을 고려하여 순위를 매깁니다.
• 스토리에는 구현의 크기와 난이도를 반영하는 '노력 포인트'가 할당됩니다.
• 하루에 구현되는 노력 포인트 수를 측정하여 팀의 '속도'를 추정합니다.
• 이를 통해 시스템을 구현하기 위해 필요한 전체 노력을 추정할 수 있습니다.

Release and Iteration Planning

• 릴리스 계획은 시스템의 릴리스에 구현될 기능을 반영하고 스토리의 구현 순서를 정하는 작업을 포함합니다.
• 각 이터레이션에 구현될 스토리는 이터레이션을 전달하는 데 필요한 시간을 반영하는 스토리 수로 선택됩니다(보통 2-3주).
• 팀의 속도는 이터레이션이 효과적으로 전달될 수 있도록 스토리 선택을 안내하는 데 사용됩니다.

Task allocation

• 작업 계획 단계에서 개발자들은 스토리를 개발 작업으로 분해합니다.
  • 개발 작업은 4~16시간 걸려야 합니다.
  • 해당 이터레이션에서 완료해야 할 모든 작업이 목록으로 나열됩니다.
  • 개별 개발자들은 그들이 구현할 특정 작업을 선택합니다.
• 이 방법의 이점들:
  • 전체 팀이 한 이터레이션에서 완료해야 할 작업의 개요를 볼 수 있습니다.
  • 개발자들은 이러한 작업에 대한 소유감을 갖고 이는 그들이 작업을 완료하도록 동기를 부여할 가능성이 큽니다.

Software delivery(소프트웨어 전달)

• 소프트웨어 증분은 항상 각 프로젝트 이터레이션의 끝에 전달됩니다.
• 이터레이션에 포함될 기능이 시간 내에 완료될 수 없는 경우 작업 범위가 줄어듭니다.
• 전달 일정은 절대 연장되지 않습니다.

Agile planning difficulties

• 애자일 계획은 고객의 참여와 가용성에 의존합니다.
• 고객 대표들이 다른 일을 우선시하고 계획 게임에 참여할 수 없어서 이를 조정하기 어려울 수 있습니다.
• 또한, 일부 고객은 전통적인 프로젝트 계획에 더 익숙하며 애자일 계획 프로세스에 참여하는 것을 어려워할 수 있습니다.

Agile planning applicability(애자일 계획의 적용성)

• 애자일 계획은 함께 모여 구현될 스토리를 논의할 수 있는 작고 안정적인 개발 팀에 잘 맞습니다.
• 그러나, 팀이 크거나 지리적으로 분산되어 있거나 팀 구성원이 자주 바뀔 경우,
  • 모든 사람이 애자일 프로젝트 관리에 필수적인 협력적 계획에 참여하는 것은 실질적으로 불가능합니다.

Agile Planning(애자일 계획)

• 당신은 이미 To-Do app을 위한 작업을 식별했습니다.
• 식별된 작업을 바탕으로 개발을 계획하세요.
• 일부 작업은 다른 사용자 스토리의 다른 작업이 먼저 완료되어야 시작될 수 있습니다.
• 이러한 경우를 식별하고 전체 릴리스 및 이터레이션도 계획하세요.
• 작업 식별이 팀원에게 할당하기에 충분히 좋습니까?
• 어떤 스토리/작업을 먼저 해야 할까요?
• 맨 아래에 관련 내용 추가 예정

요약

• 애자일 개발의 주요 아이디어는 소프트웨어 개발의 불필요한 부담을 줄이고 작동하는 소프트웨어 개발에 집중하는 것입니다.
• 소프트웨어는 요구사항과 비즈니스의 빠른 변화에 빠르게 적응해야 합니다.
• 애자일 개발의 핵심 원칙은 고객 참여, 프로세스가 아닌 사람, 그리고 변화를 수용하는 것입니다.
• 애자일 개발의 중요한 실천 방법으로는, 사용자 스토리로 명세하기, 리팩토링, 테스트-퍼스트 개발, 그리고 페어 프로그래밍이 있습니다.

Story 7

---

스토리

Gildong은 항상 속도를 따라잡기가 쉽지 않다고 느낍니다. 그래서 그는 자신의 업무 수행을 격려받거나 적어도 관리하기를 원합니다. 예를 들어, 각 업무 완료마다 일정 점수를 부여하고, 모든 업무를 시간 내에 계속 완료하면 추가 점수를 받습니다. 반면, 기한 전에 업무를 완료하지 못하면 일부 점수가 차감됩니다. 그런 다음 점수를 관찰함으로써, 자신의 진행 상황과 성과를 이해할 수 있습니다. Gildong은 일별로 획득한 점수와 누적 점수 변화를 보여주는 차트를 보고 싶어합니다. 이 차트에서는 주간 또는 월간 점수 변화를 볼 수 있는 옵션을 선택할 수 있어, 이번 주/월의 성능을 이전 주/월과 비교할 수 있습니다.

GPT 4.0

1. 요구 사항 정의 및 분석

• 업무 완료 및 점수 시스템에 대한 요구 사항을 명확하게 정의합니다.
• 시간 내 업무 완료, 기한 초과 시의 점수 부여 및 차감 로직을 정의합니다.
• 주간 및 월간 성과를 비교할 수 있는 기능에 대한 요구 사항을 정리합니다.

2. 데이터베이스 설계

• 업무 목록, 완료 여부, 기한, 부여된 점수 등을 저장할 수 있는 데이터베이스 스키마를 설계합니다.

3. 백엔드 개발

• 업무 추가, 수정, 삭제, 조회 기능을 구현합니다.
• 업무 완료 시 점수를 계산하고 업데이트하는 로직을 개발합니다.
• 점수가 차감되는 경우를 처리하는 로직을 개발합니다.
• 사용자의 일일, 주간, 월간 성과를 계산하는 기능을 개발합니다.

4. 프론트엔드 개발

• 업무 목록을 보여주고, 새로운 업무를 추가할 수 있는 인터페이스를 제공합니다.
• 각 업무의 완료 여부를 사용자가 표시할 수 있도록 합니다.
• 일별, 주별, 월별 성과를 차트로 표시하는 기능을 구현합니다.
• 성과 비교를 위한 시간 범위 선택 기능을 구현합니다.

5. 차트 및 시각화 도구 선정

• 사용자의 성과를 시각화하기 위한 차트 라이브러리 또는 도구를 선정합니다. 예: Chart.js, D3.js 등.

6. 테스트 및 디버깅

• 각 기능별로 단위 테스트를 수행합니다.
• 전체 시스템 통합 테스트를 진행하여 버그를 찾고 수정합니다.

7. 사용자 피드백 및 개선

• 초기 사용자로부터 피드백을 받습니다.
• 피드백을 바탕으로 시스템을 개선하고 추가 기능을 개발합니다.
• 사용자와 Task를 관리할 수 있는 시스템이 필요함

팀원 의견 공유

• 사용자 시스템에서 Task 완료에 따른 점수 감산 / 가산을 구현해야함

• DB Schema 정의
  • Task Table
    • 시작 전 / 진행 중 / 완료 등의 Attribute
  • 점수와 점수를 획득한 일자를 저장할 수 있는 필드

• Task 속성을 구현
  • 시작 전 / 진행 중 / 완료 등의 Task 상태를 지정하는 메서드 구현
  • 마감기한 지정할 수 있는 메서드 구현

• 사용자 시스템에서 Task가 완료되면 마감기한을 지켰는지 확인한 후 점수 가산 / 감산
  • 점수와 점수를 획득한 일자를 DB에 저장하도록 메서드 구현
  • Task 상태의 변화를 감지해서 점수 계산 후 동기화

• 저장된 기록을 바탕으로 업무 능률을 평가할 수 있는 점수 차트를 시각화
  • 주간 / 월간 변화에 따른 점수 변화 추이 구현

Test case

• Input
  • Task의 이름 / Task 마감기한
  • Task 완료 여부에 대한 입력
  • 날짜 / 점수 입력

• Test
  • Task 마감기한과 현재 시각, Task 상태를 비교하여 점수 계산
  • Task가 완료처리 되었을 때 DB에 제대로 갱신이 되는지
  • 데이터 무결성 Test(실제 DB에 저장된 데이터와 입력한 데이터가 같은지 확인)
  • 점수를 읽어와서 기간별로 점수 변화 추이가 제대로 작동하는지
  • 날짜 별 점수를 잘 출력하는지

• Output
  • Score를 리턴
  • Task 상태를 리턴
  • True/False
  • 점수 증감율을 리턴
  • Score 리턴

Planing

첫 번째 스프린트

• requirement 확인
• Task DB 스키마 정의
• Task Interface 정의
• User DB 스키마 정의
• 사용자 클래스 정의

두 번째 스프린트

• 팀원 A
  • Query 작성(Model)

• 팀원 B
  • Task 시각화(GUI)

• 팀원 C
  • 점수 계산하는 메서드

• 팀원 D
  • 점수 시각화(GUI)

• 팀원 E
  • 점수 변화 추이 계산하는 메서드

세 번째 스프린트

• Code Review 및 Merge

• QA 진행