[Software Engineering] 5주차 (2)

XP in Practice

 

The XP method itself is not widely used now, since extreme programming has a technical focus and is not easy to integrate with management practice in most organizations.

XP방법론은 그것 자체로는 현재 많이 쓰이지 않습니다. XP는 기술적인 집중도를 갖고있으며, 대부분의 기업에서 이를 관리하며 통합하는 것이 쉽지 않기 때문입니다.

 

However, XP practices are widely used in other development methods.

• User stories for spectification
• Refactoring
• Test-first development
• Pair programming

 

User Stories for Requirements

 

User requirements are expressed as user stories or scenarios.

사용자의 요구사항은 사용자 스토리나 시나리오로 표현됩니다. 이는 use case scenarios로 불리기도 합니다.

• Written on cards and the development team break them down into implementation tasks. Tasks are the basis of schedule and cost estimates.

사용자 요구사항들을 카드, 포스트잇 같은데에 써놓고, 개발 팀은 그것들을 구현 태스크로 분해합니다. 그 각각의 태스크들은 스케쥴이나 비용 예상의 기반이 됩니다.

 

• Customer or user is part of the XP team and is responsible for making decisions on requirements. The customer chooses the stories for inclusion in the next releases.

고객이나 사용자는 XP팀의 일원이 됩니다. 그래서 요구사항에 대한 결정에 책임을 집니다.

 

Refactoring

 

Conventional wisdom in sofrware engineering is to design to change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.

변화, 변경을 위한 디자인은 소프트웨어 공학에서 전통적으로 내려져오는 지혜입니다. 이는 소프트웨어 생명 주기의 이후 단계에서의 비용을 줄이는 측면에서 가치있습니다.

 

XP, however, claims that this is not worthwhile as changes cannot be reliably anticipated. XP proposes constant code improvement (Refactoring) to make changes easier when they must be implemented.

하지만 XP는 변화가 안정적으로 이루어질 수 없기 때문에 이는 가치가 없다고 주장합니다. 따라서 XP는 지속적인 코드 개선(* 리팩토링)을 통해 변화가 쉽게 이루어질 수 있도록 합니다. 즉, "나중에 고치기 쉽게 설계해라." 혹은 "나중에 쉽게 고칠 수 있는 자리를 미리 만들어 놔라."라는 말입니다.

 

Refactoring은 기능은 유지하되, 코드를 조금 더 clean하게 바꿔주는 것입니다. 예를 들어, class간의 dependency를 끊어 주기 위해 중간에 interface를 추가해주는 것이 refactoring에 해당합니다. 이때 기능 유지 여부는 test를 통해 평가되는데, 이를 위해서 CICD나 CTIP환경이 필수적입니다.

 

Test-First Development(* Design principle, 개발 방법론이 아닌 일종의 개념)

 

Testing is central to XP. "The program should be tested after every change has been made."

검사는 XP의 핵심입니다. 모든 변화에는 test가 따라갑니다.

 

Difficulties in TFD

• Programmers prefer programming to testing and sometimes they take short cuts when writing tests.
• Some tests can be very difficult to write incrementally
• It is difficult to judge the completeness of a set of (a lot of) tests.

프로그래머들은 testing보다 구현, 프로그래밍을 좋아해서, test를 작성할 때, 대충할 수 있습니다. 또한 몇몇 테스트는 만들기 매우 힘듭니다. 마지막으로 테스트 셋이 그 프로그램, 유닛의 완벽함, 완전함을 증명한다는 보장이 없습니다.

 

애초에 테스트를 하기 힘든 상황이 있을 수도 있습니다. 예를 들어, 어떤 유닛 단위의 테스트를 위해서는 다른 유닛들과 같이 테스트를 수행해야 하는 경우가 있을 수 있고, 해당 유닛의 실행을 위해서는 특정한 device가 필요할 수도 있습니다.

 

그렇기 때문에 new release가 만들어질 때마다 모든 컴포넌트들을 테스트할 수 있게 도와주는 CTIP환경이 필수적입니다.

 

CTIP 환경

 

Test-Driven Development(* 개발 방법론, coding methodology, TDD를 통해 만들면 TFD도 만족한다)

 

TDD, "Writing tests before code clarifies the requirements to be implemented."

요구사항들을 구현하기 전에 test먼저 작성해라.

 

Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly.

자동적으로 실행되기 위해 테스트는 프로그램으로서 작성되야합니다. 그 테스트는 그 컴포넌트가 정확히 실행되는지를 확인합니다.

 

Automated test execution environment is mandatory. All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors.

자동적인 테스트 실행환경이 필수적입니다. 이전에 모든 테스트들과 새로운 테스트들은 새로운 기능이 추가될 때, 자동적으로 실행되어야합니다. 그러므로 새로운 기능이 에러를 갖는지를 확인합니다.

 

기존의 개발 방법은 "구현 → 테스트 케이스 만들기 →  테스트" 였다면, TDD는 "테스트 케이스 만들기 →  구현 → 테스트"입니다. 하지만 테스트 케이스를 만드는 것이 굉장히 어렵습니다. 하지만 TDD를 하면 test case가 쌓인다는 장점이 있습니다.

 

Customer Involvement

 

The customer is a part of the team in XP. they help develop acceptance tests for the stories that are to be implemented in the next release of the system.

고객 혹은 사용자는 XP의 팀원입니다. 그들은 acceptence test(Validation)을 돕습니다.

 

test case ≠ test data

 

test case는 requirement analysis단계에서 개발자와 고객이 같이 만들 수 있습니다. 하지만 test data는 test단계에서 진짜 사용하는 테스트 예시들로 이는 개발자가 만듭니다. 예를 들어, 짝수면 제곱을 출력하고, 홀수면 세제곱을 출력해야 한다는 requirement가 있다면, 이것 자체가 test case가 됩니다. 이때 입력으로 2,4,3,17 ... 을 넣는 데이터는 test data입니다.

 

Pair Programming

 

"Involves programmers working in pairs, developing code together."

짝을 지어 일하며, 코딩합니다.

 

Advantages

• Helps develop common ownership of code and spreads knowledge across the team.
• Serves as an informal review process as each line of code is looked at by more than 1 person,
• Encourages refactoring as the whole team can benefit from improving the system code

이는 코드에 대한 공통의 소유감을 느끼게 하고, 지식은 팀 전체와 나눠 갖습니다. 또한 적어도 한 명 이상의 비공식적 코드 리뷰를 제공할 수 있습니다. 마지막으로 리팩토링을 장려합니다. 이를 통해 코드의 질이 향상될 수 있습니다.

 

pair programming은 두 명의 프로그래머가 각각 코딩하는 것보다 더 나은 성능을 보인다는 몇몇 증거가 존재합니다.

 

Agile Project Management

 

The principle responsibility of software project managers is to manage the project so that the software is delivered on time and within the planned budget for the project.

소프트웨어 프로젝트 매니저의 기본적인 역할은 제 시간에 계획된 예산 안에서, 제 시간에 프로젝트를 만듬으로써 프로젝트를 관리하는 것입니다.

 

The standard approach to project management is the plan-driven. but agile project management requires a different approach. it should be adapted to incremental development and the practices used in agile (development) methods.

가장 기본적인 프로젝트 관리방법은 계획대로 하는 것입니다. 하지만 agile 프로젝트 관리방법은 다른 접근을 필요로 합니다. 이는 agile개발 방법론에 적용할 수 있는 프로젝트 관리 방법이어야 합니다.

 

Scrum

 

An agile method that focuses on managing iterative development rather than specific agile practices. Scrum is the name of a short daily meeting.

Scrum은 특정한 agile활동이 아닌 반복형 개발을 관리하는데에 집중하는 agile방법론입니다. Scrum은 짧은 미팅의 이름입니다.

 

3 phases in Scrum

• Initial phase
  • An outline planning phase, where you estabilish the general objectives for the project and design the software architecture.
• A series of sprint cycles
  • Each cycle develops an increment of the system
• Project closure phase
  • Wraps up the project, completes requires documentation, and assesses the lessons learned from the project

 

Scrum Terminology + sprint backlog

The Scrum sprint cycles