11 7 Reading_Assignment_4(20094068 3학년 이준서) - JunSeoLee/project_team_5 GitHub Wiki

익스트림 프로그래밍(Extreme Programming)과 변화를 포용해라

익스트림 프로그래밍(Extreme Programming) 옆으로 기존의 소프트웨어 프로세스를 실행하라. XP는 오히려, 계획, 분석, 멀리 떨어진 미래를 설계하는 것보다, XP 프로그래머는 시간에 걸쳐 개발에서 이러한 활동을 거의 모두 수행한다.

초기 프로세스 모델은 폭포수 모델인데 한번 과정이 넘어가면 돌이 킬 수 없었다. 그리하여 폭포수 반복 모델이 나왔다. 하지만 폭포수 반복 모델은 개발 프로그램을 수정하려면 막대한 비용이 들었다. 그리하여 이러한 비용을 떠안기 싫어한 엔지니어들은 획기적이고 수정 비용이 절감적인 기술들을 만들었다. 따라서 모든 기술 혁신은 노력에서부터 시작된다.

XP의 주요 사례를 보면 첫 번째로 계획으로 고객은 프로그래머가 작성한 견적에 따른 구현 범위와 시기를 결정하여 프로그래머에게 알려준다. 그리고 프로그래머는 고객의 요구사항만 구현한다. 두 번째로 예비버전이다. 예비버전은 모든 문제를 해결하기 전 몇 달에 걸쳐 생산과정에 투입된다. 세 번째로 은유인데 시스템의 형태는 고객과 프로그래머 사이의 대화의 은유나 설정에서 결정된다. 네 번째로 단순한 디자인으로 모든 클래스와 메소드는 중복되지 않으며 한 번에 설명할 수 있을 정도로 단순해야 한다. 다섯 번째로 테스트인데 분 단위의 테스트를 실행하고 모두 다 정상 실행되어야 한다. 그리고 고객은 자신의 요구한 기능 테스트를 작성하고 실행해 봐야 하고 결함의 발생 시 비용에 대한 결정을 해야 한다. 여섯 번째로 리팩토링인데 계속적인 테스트의 실행으로 디자인을 변화시킨다. 일곱 번째로 페어 프로그래밍인데 모든 제작 코드는 하나의 화면, 키보드, 마우스에서 두 사람이 기록되게 한다. 여덟 번째로 지속적인 통합으로 새로 짜여진 코드는 테스팅을 거치고 시스템과 통합되어 있어야 한다. 아홉 번째로 집단 소유인데 코드의 공유이다. 열 번째로 현장에서의 고객으로 고객은 풀 타임 팀과 함께 앉아있어야 한다. 열한 번째로 주 40시간 근무이다. 열두 번째로 열린 작업장으로 페어 프로그래머는 가운데 위치하고 다른 프로그래머들은 주변에 열린 공간으로 배치한다.

XP의 구조로는 위에 말한 듯이 XP 옆으로 기존의 소프트웨어 프로세스를 킨다. 오히려 계획, 분석, 멀리 떨어진 미래를 설계하는 것보다 XP 소프트웨어는 소프트웨어 개발을 통해 한 번에 조금 이러한 활동을 모두 수행하는 변경 비용의 감소를 이용한다. XP의 개발 주기로는 위의 사례와 같이 반복한다. 그리고 생산하기 전 XP의 기간을 조정해야 한다. 설계를 할 때에는 고객의 가장 가치 있는 이야기를 중심으로 설계하며 이것들은 이어 붙인다. 생산과정은 위의 과정의 되풀이를 거쳐야 한다. 구현은 두 사람이 파트너가 되어 구현하는데 테스트 케이스를 두고 구현하고 리팩토링을 실시한다. 테스트는 단위 테스트로 한다. XP에서는, 그러나, 기존의 테스트 전략에 왜곡 테스트를 두어 비교하면서 테스팅 한다. 그리고 반복적인 테스트를 실시하여 고객의 신뢰를 쌓는다. 만약 XP의 예기치 않은 또는 원하지 않는 상황이 발생했을 때 수행 할 작업을 사용자가 정확하게 파악하게 된다. 싼 견적은 개발자의 개발을 방해하는데 개발자는 고객에게 요구하여 개발이 편안하게 이루어지게 해야 한다. 비협조적인 고객이 있을 경우 개발자는 고객과의 신뢰를 쌓으려고 노력해야 된다. 그래야 문제가 발생했을 경우 고객에게 도움을 요청할 수 있다. 개발자 문제가 발생할 수 있다. 만약 개발자 한 명이 떠난다면 페이 면에서는 좋겠지만 일의 량 증가와 스트레스가 동반 될 것이다. 그리고 개발 비밀을 알고 있기 때문에 따나 보내려 하지 않을 것이다. 또한 비협조적인 개발자 문제인 경우 XP는 강렬한 사회적 활동이므로 팀원들이 다 알고 있을 것이다. 그레서 비협조적인 개발자는 차라리 없는 것이 낳을 것 이다. 요구 사항의 변화가 있을 경우 XP시스템은 어떤 방향으로 갈지 정해져 있다. 반복의 유사성이 있는데 개월 년 규모로, 주 및 달 규모로 , 일 주간 규모로, 분 의 일 규모로의 반복이 있다. XP는 빛나는 아이디어가 아니며 완성된 것이 아니다. XP의 실패사례가 나와야 하고 그것을 수정하면서 보완해 나가야한다.

XP위 뿌리로는 XP의 뿌리는 없다. 많은 사람들은 요구 사항이 격렬하게 변화하는 환경 때문에 소프트웨어를 제공하는 가장 좋은 방법에 대해 유사한 결론에 도달했다.(나선형 모델, 은유, 물리적 환경 등)

사례: Acxiom : 공통의 목표를 향해 노력 (Jim Hannula, Acxiom ) 익스트림 프로그래밍 (Extreme Programming) 기법의 사공사례.(데이터웨어 하우스의 상단에 Acxiom) XP는 자극성장과 창의성을 유도하고 팀 구성원 기회를 제공한다. 그것은 상식적인 개발 방식 을 사용하는 방법이며 모두가 공통의 목표를 ​​향해 함께 작동해며 노력해야 한다.

사례: DaimlerChrysler: 세계에서 최고의 팀 (Chet Hendrickson, DaimlerChrysler) XP의 원칙을 따르지 않았던 팀의 결과로 힘든 고통을 느꼈다.

사례: Ford Motor: 고유 (Don Wells, Ford Motor) 민첩성과 품질의 조합 포드 자동차 의 금융 시스템은 차량 원가 계산 및 이익 시스템( VCAPS ), 생산 수익 에 대한 보고서, 비용 , 당기 순이익 과 이익 을 생성하는 분석 도구를 개발하고 있었는데 두 가지 요구사항이 있었다. 첫째, 분석가들은 각 실행하기 전에 수정 하는 새로운 기능을 원했다. 둘째, 시스템은 제한된 시간 범위 에서 실행해야 할 필요가 있었다. 이들의 환경은 XP를 쓰기 적절했다. 그리고 결과가 좋게 나왔다.

사례: Tariff System: 당신이 읽을 수 테스트 ( Rob Mee, Independent consultant) 관세 시스템은 주요 국제 컨테이너 운송 회사의 a large Smalltalk/GemStone project 하위 시스템입니다. XP 관행 사용하여, 관세 시스템은 세 팀으로 3개월 만에 생산을 찍어냈다. 그 결과 시스템이 비정상적으로 안정 하고 유지하게 쉬운 것으로 판명 됬다. 개발중 표준 생성자를 사용하여 이 개체를 인스턴스화 하는 코드는 읽기 어려웠을 것으로 느끼고, 또한 테스트 케이스 자체에서 산만하여. 기능 테스트의 발현에 중요한 도구가 될 것을 입증하였고, 전체적으로 같은 시스템 의 큰 설명에 각각의 도메인 언어를 결합 할 수 있는 것을 발견했다. 새로운 작은 언어생성으로 XP의 발전을 이루어 냄.

내 생각

내 생각엔 XP는 아직 완벽한 도구도 아니며 꼭 써야 되는 것은 아닌 것 같다. 하지만 XP의 시스템을 따랐을 때의 효과들은 위의 사례에서 보듯이 엄청 난 것 같다. 그리고 위에서 말했듯이 고객과의 의사소통을 중요시 한 것이 정말 인상 깊었다. 그리고 그 의사소통을 계속 이어가면서 반복하고 리펙토링 하는것도 정말 인상 깊었다. 의사소통이 잘되어야 고객이 원하는 제품이 나올 것이고 그에 따른 원하는 제품이 나올 것이기 때문이다. 그리고 고객과의 신뢰를 두텁게 쌓아야 도움을 많이 받을 수 있을 것 같다는 생각이 들었다. 그리고 새로운 것에 대한 프로젝트를 실시할 때 정말 효과적 일 것 같다는 생각이 들었다.