버전 2 - 이력 - 익스트림 프로그래밍(Extreme Programming XP) - 01.역량강화 - Fehu_Redmine

1

이태훈

h1. 익스트림 프로그래밍(Extreme Programming XP)

2

3

* 짧은 주기의 이터레이션(Iteration)을 통해 요구 변화에 신속하게 대응하여 고품질의 소프트웨어를 빠르게 전달하는 애자일의 방법론 중 하나입니다.

4

6

1

이태훈

7

* 신속한 개발 : RUP(Rational Unified Process)의 산출물 부담으로 신속한 개발이 불가능 하기 때문에 필요합니다.

8

* Time To Market : 빠른 시장 대응 능력이 향상되고 적시에 배포가 가능합니다.

9

* 유연한 대처 : 프로세스 중심의 전통 방법론으론 빠른 시장 대응이 어렵기 때문에 필요합니다.

10

12

1

이태훈

13

* 개발자, 관리자, 고객의 조화로 개발 생산성을 높입니다.

14

* 고객 요구 사항 변경에 적극적이고 긍정적으로 대응이 가능합니다.

15

17

1

이태훈

18

h3. 1. 사용자 스토리(User Story)

19

20

 * 사용자 요구 사항/UML의 Use Case와 같은 목적

21

 * 릴리즈 게획을 작성하기 위한 단위

22

 * 기능 단위로 필요한 내용을 간단하게 기재, 필요 시 간단한 테스트 사항도 표기 가능

23

 * 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술

24

25

h3. 2. 아키텍처 스파이크(Architectural Spike)

26

27

 * 어려운 요구 사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램

28

 * 사용자 스토리의 신뢰성을 증대시키거나 기술적인 문제의 위험을 줄이고자 하는데 목적

29

30

h3. 3. 배포 계획(Release Planning)

31

32

 * 전체 프로젝트에 대한 배포 계획을 생성

33

34

h3. 4. 반복(Iteration)

35

36

 * 하나의 반복을 1주~3주 정도로 나누고 프로젝트 전반에 균일하게 유지

37

 * XP의 반복은 프로세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목(반복 계획 미팅)

38

 * 사용자 요구 사항 변경, 기술적인 문제 등 상황에 따라 릴리즈 및 반복 계획 수정 가능

39

40

h3. 5. 승인 테스트(Acceptance Test)

41

42

 * 릴리즈 전의 인수 테스트, 고객이 수행

43

44

h3. 6. 소규모 배포(Small Release)

45

46

 * XP 주기의 마지막 단계

47

 * 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공

48

 * 프로그램은 빠른 피드백을 제공 받음

49

50

h3. 7. 기립 회의(Standup meeting)

51

52

 * 전체 팀원들 사이의 의사소통으로 현재의 문제점 해결책 등을 논의하고 팀이 초점을 잃지 않도록 하기 위해 사용

53

55

1

이태훈

56

* 의사소통(Communications) : 개발자, 관리자, 고객 간의 원활한 의사소통

57

* 단순성(Simplicity) : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제

58

* 피드백(Feedback) : 지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백

59

* 용기(Courage) : 고객의 요구사항 변화에 능동적인 대처

60

* 존중(Respect) : Stakeholder는 팀원의 기여를 존중하여 소프트웨어 개발 생산성과 인간성을 동시 개선

61

63

1

이태훈

64

* 인간성(Humanity)

65

* 경제성(Economics)

66

* 상호 이익(Mutual Benefit)

67

* 자기 유사성(Self-similarity)

68

* 개선(Improvement)

69

* 다양성(Diversity)

70

* 반성(Reflection)

71

* 흐름(Flow)

72

* 기회(Opportunity)

73

* 중복(Redundancy

74

* 실패(Failure)

75

* 품질(Quality)

76

* 아기발걸음(Baby Steps)

77

79

1

이태훈

80

h3. 1. Fine Scale Feedback

81

82

* Test Driven Development

83

84

 - 개발자 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성합니다.

85

86

 * 고객은 기능 테스트를 작성하여 요구 사항이 모두 반영되었는지를 확인합니다.

87

88

* Planning Game

89

90

 * 사용자 스토리를 이용해서 다음 릴리즈의 범위를 빠르게 결정합니다. 비즈니스 우선 순위와 기술적 평가가 결합되어있습니다.

91

92

* Whole Team

93

94

 * 개발 효율성을 위해 고객을 프로젝트에 상주시킵니다.

95

 * 고객은 스토리를 명확하게 해주고, 중요한 비즈니스 결정사항에 대해 명확한 답을 제공해주는 역할을 합니다.

96

97

* pair Programming

98

99

 * 두 사람이 함께 프로그램 작업을 합니다(Driver/Partner)

100

 * 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동작업을 합니다.

101

102

h3. 2. Continuous Process

103

104

* Continuous Intergration

105

106

 * 컴포넌트 단위로 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때 마다 지속적으로 통합되고 동시에 테스트됩니다.

107

108

* Design Improvement

109

110

 * 프로그램 기능은 변경 없이 중복/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 통해 시스템을 재구성 합니다.

111

112

* Small Release

113

114

 * 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈, 고객이 소프트웨어가 어떻게 돌아가는지 아주 짧은(2주) 싸이클로 볼 수 있도록 자주 새로운 버전을 배포합니다.

115

116

h3. 3. Shared Understanding

117

118

* Simple Design

119

120

 * 당장 필요하지 않은 디자인 배제합니다.

121

 * 항상 가장 간결한 디자인 상태 유지합니다.

122

123

* System Metaphor

124

125

 * 공통의 name system(의사 소통 및 공통 개념 공유)

126

 * 전체 개발 프로세스에 걸쳐서 시스템의 동작에 대한 전체 그림을 표현하는 것으로, 이해하기 쉬운 스토리로 이루어집니다.

127

128

* Collective Code Ownership

129

130

 * 팀의 모든 프로그래머가 소스 코드에 대해서 공동 책임을 지는 것으로, 시스템에 있는 코드는 누구든지 언제라도 수정 가능해야 합니다.

131

132

* Coding Standard

133

134

 * 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화 된 관례에 따라 작성되어야 합니다.

135

136

h3. 4. Programmer Welfare

137

138

* Sustainable Pace

139

140

 * 일주일에 40시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버 타임 하지 않도록 합니다.

프로젝트

일반

사용자정보

문서 » 01.역량강화

익스트림 프로그래밍(Extreme Programming XP) » 이력 » 버전 2