XP(eXtreme Programming)에 개념과 앞으로의 과제

목차

Ⅰ. 주요내용

1∼60 : xp 관련설명

Ⅱ. 참고설명


1. XP에서 중시하는 개념
2. XP에서 중시하는 가치+부가설명
3. 프로젝트 매니징 방식
4. xp의 단점
5. XP를 이용하여 더 나은 프로젝트를 위해
6. 오늘날 소프트웨어 개발환경에서의 XP의 적절성
7. xp가 현재 극복해야할 과제

본문내용

자인을 개선합니다. 이를 TDD(Test Driven Design)라고 합니다. 테스트가 디자인을 주도하는 것이죠. 켄트 벡은 최근 글에서, 이에 대해 "겨누고 쏴라"라고 했습니다. 테스트 프로그램을 먼저 작성할 때는 마치 실제 코드가 이미 구현되어 있는 듯 작성합니다. MONEY객체를 아직 구현해 놓지도 않았으면서 마치 이미 구현이 다 된 듯이 다루는 것입니다. 이 테스트 코드를 실행하면 당연히 컴파일 에러가 납니다. 에러가 나면 '컴퓨터가 나에게 요구한다'보 보고 이 요구를 들어줍니다. 즉, MONEY 객체를 들어주는 것입니다. 이때 DTSTTCPW를 합니다. 그냥 겉껍질만 만들어 주어서 컴파일이 되면 이번에는 리턴 값이 제대로 나오는지 확인합니다. 그러면 이번에는 테스트 실패가 됩니다. 그러면 이 요구를 다시 충족해 주기 위해 코드를 덧붙입니다. 즉, 실패와 성공을 반복하는 것이죠. 이것은 미로의 목적지에서 거꾸로 내려오는 것과 같습니다. 처음부터 사용 인터페이스를 생각하게 되고, '어떻게' 보다'무엇을'에 더 주목하게 됩니다. 결과적으로 코드의 의도가 분명히 드러나고, 디자인이 더 깔끔해 집니다. 게다가, 코드간의 의존성이 줄어듭니다. 테스트 유닛은 한 개의 클래스만 독립적으로 테스트해야 하기 때문입니다. 그리고 테스트 가능성을 나중에 집어넣는 것은 매우 어렵습니다. 처음부터 테스트 가능성에서 출발하면 거의 모든 코드에 대한 자동 테스팅이 가능합니다 . 심지어는 GUI 코드에 대해서도 그러합니다
3)피드백
테스트 코드를 만들고 이를 구현하는 코드를 단순화하면서 중요한 것은 매번 확인하는 것입니다. 이것은 바로 피드백과 연결됩니다. 여기서 피드백이란 어떤 실질적 결과를 얻는 것이지만 XP에서는 무엇이든 실질적 중간 결과 없이 지속하지 말라고 합니다. 어두운 밤길을 한 방향으로 전력 질주하는 셈입니다. 그러므로 계속 피드백을 확인해야 합니다. 계획에서도 계획 게임을 이터레이션마다 행하고 또 수정하는 것이 모두 피드백에 대한 것입니다. 이제까지 말씀드린 테스팅이 개발자 입장의 피드백이라면, 승인 테스팅은 고객입장의 피드백이 됩니다.
4)용기
용기는 앞의 세 가지 가치가 구현되면 결과로 얻을 수 잇는 것입니다. 남들과 소통이 잘 되고 , 단순한 것에서 시작하고, 지속적인 피드백을 얻을 수 있다면 누구나 용감해 질 수 있습니다. 이 때 비로소 변화를 포용할 수 있게 됩니다.
이제 나머지 마지막 가치인 '주당 40시간 업무'에 대해서 알아보자.
사실 가장 받아들이기 힘든 것이라고 불평하는 사람들이 있긴 하지만, 이는 최근 론 제프리즈의 견해대로 "유지할 수 있는 페이스(Sustainable Pace)" 정도로 이해해야 할 것입니다. 중요한 것은 40시간이냐 50시간이냐가 아니고, 개발자들이 일하고 싶어하는 만큼 일하느냐는 것이겠습니다.
3. 프로젝트 매니징 방식
고전적인 방식 - 폭포수(waterfall)방식 등
최근- XP
4 xp의 단점
체계적인 문서화와 아키텍처의 부재이다.
이에 대해 xp측에서는 '코드가디자인이다' 나, 메타포등으로 응수하지만 비판자들은 그다지 만족하지 않는다.
5. XP를 이용하여 더 나은 프로젝트를 위해
XP를 이용해 프로젝트를 원활하게 진행하기 위해서는 대화능력과 서로를 존중하며 합리적으로 최선의 해결책을 도출하는 자세가 필요하다.
6. 오늘날 소프트웨어 개발환경에서의 XP의 적절성
대규모 프로젝트 수행 시 기존의 무겁고 거대한 방법론이었는데 그 외 확장성 있는 다른 애자일 방법론.
오늘날 XP는 모든 사람이 프로세스에 자신이 할 수 있는 것을 기여할 수 있도록, 또 프로세스에서 자신이 필요로 하는 것을 얻게끔 격려하는 협동적인 방법
기존의 대립적인 방법보다 더 나은 개발결과를 이끌어 낸다.
=> XP팀은 대규모 프로젝트에서 아주 우수한 구성요소가 될 수 있다.
XP팀은 (매니지먼트, 세일즈, 고객지원, 엔지니어링)
7. xp가 현재 극복해야할 과제
1.유기적으로 데이터베이스를 디자인할 수 있는 더 나은 도구가 필요합니다.
-데이터베이스를 하나의 테이블과 하나의 필드에서 시작해서 모든 나머지 디자인을
여기에서 리팩토링 할 수 있어야 합니다.
2.협동적으로 코드를 키울 수 있는 더 나은 프로그래밍 환경도 필요합니다.
3.개방적이고 참가적인 프로세서를 원하고 자신의 부분을 다하려는 그런 고객과 매니저들이
필요합니다.

1. XP의 개념?
eXtreme Programming은 기존의 개발방식과는 다른 새로운 개발방식이다. 기존의 개발방식이 사용자의 요구사항을 명확히 도출한 이후에 개발을 진행해나가는 방식이라면, XP, DSDM 등의 개발방식은 개발 도중에도 사용자의 요구사항 변경에 유연히 대처할 수 있는 개발방법을 목표로하고 있다. 또한, XP는 생산성의 향상을 위하여 극단적인(extreme) 개발형태를 취하고 있다.
2. XP에서 중시하는 가치를 서술하시오.
1. 스탠드업 미팅
주로 아침에 목적은 팀원간의 의사소통이다.
2. 짝프로그래밍
프로그램 코드를 개발 할 때 두 명이 함께 개발하게 하는 것이다.
3. 리팩토링
잘 정리된 방식으로 코드를 다시 구조화하는 것
4. 집단 코드 소유
코드에 대한 소유권이 없다는 뜻이다.
5. 지속적 코드 통합
팀원들간에 코드를 수정하고 컴파일해 나가니 코드저장소에 수시로 저장을 하고, 최신버전 코드를 사용한다.
6. 유닛테스트
어떤 클래스나 모듈을 만들 때 이를 테스트하기 위한 프로그램도 같이 만드는 것을 말한다.
7. 승인 테스트
프로그램을 맡긴 고객의 요구대로 잘 동작하는지 테스트한다.
8. 단순한 디자인 (Simple Design)
9. 메타포 (Metaphor)
3. XP가 극복해야 할 과제?
1.유기적으로 데이터베이스를 디자인할 수 있는 더 나은 도구가 필요합니다.
-데이터베이스를 하나의 테이블과 하나의 필드에서 시작해서 모든 나머지 디자인을
여기에서 리팩토링 할 수 있어야 합니다.
2.협동적으로 코드를 키울 수 있는 더 나은 프로그래밍 환경도 필요합니다.
3.개방적이고 참가적인 프로세서를 원하고 자신의 부분을 다하려는 그런 고객과 매니저들이
필요합니다.

키워드

XP 개발방식,   eXtreme Programming,   프로젝트 매니징 방식,   xp 단점,   소프트웨어 개발환경,   XP 적절성,   xp 과제,   사용자 스토리