XP 2007 준비 페이지에 대하여
- 간다는 가정하에 스스로 준비하고 지식을 습득하고 모두와 공유하기 위해 페이지를 엽니다. (안되면 삽질이겠지만, 그래도 관련 공부하면 서로에게 남을테니까..)
XP 2007은
- 기간 : 2007.6.18 ~ 2007.6.22 (5일) 출장기간(8일)
- 출장 종류 : 교육출장
- 출장 기간 : 출장 기간 6월 17일 ~ 6월 24일 (8일간)
- 출장 여비표에 따른 기준 : B지(US$) 숙박료 150$ + 일당 65$
- 항공기 탑승등급 기준 및 구입방법: economy class, 인사도움방을 통해 구입 실비처리
- 항공기 제외 교통편 이용 : 실비처리
- 컨퍼런스 참가비용 : 실비처리
세션에 관해
- 세션들을 공부하려고 하면서 점점 더 두려움이 밀려오고 있습니다 쿨럭...
- 1) mapping XP (Beck's session)은 나의 needs 와 practice 를 설명해야 하는 과정
- 2) how to guide agile adoption efforts 은 organization 이나 agile consultant 가 되어서 상황에 대한 설명 대화를 나눠야 함
중간 지식
- Lean Software Development : program 중에 처음 듣는 Lean Software Development 라는 녀석이 있어서 wikipedia 에서 찾아본 자료를 올립니다.
- lean manufacturing(군살없는 제조) 에서 나온 단어로 군살없는 소프트웨어 개발 방법입니다. 전통적인 push 방법에서 벗어나 고객이 계약서에 사인을 해야 개발을 시작하는 pull 방식의 가장 효율적인 lean process 를 지향하는 개발 방법이고 아래의 theme 들을 다룹니다.
- Seeing Waste
- Value Stream Mapping
- Set-Based Development
- Pull Systems
- Queuing Theory
- Motivation
- Measurements
- Evolutionary Database Design(DBA와 appl. 개발자가 협동하여 지속적 빌드와 자동화된 DB 개발 리팩토링을 병행하는 기술) martinfowler.com 내용 대충 번역
- Dealing With Change - 애자일 방법론을 사용하기위한 첫번째 관문은 그 속성을 이해하는 것이다. 폭포수 방법론과 같이 모든 설계를 먼저 마치는 plan-driven cycle 이 아닌 변화는 통제(Controlled)되고 수용(embrace) 되어야 하는 evlolutionary design을 사용하는 것이다. 지난 3년간 100명 이상의 규모가 큰 프로젝트에 evolutionary database design을 적용하고 성공한 사례이다
- Limitation - 아직까지 풀지 못한 문제점 2 가지
- multiple 데이터베이스틑 통합하며 개발한 시도가 현재까지 없었음
- We don't have to keep the production databases up 24/7 (해석 필요 : 무슨말인지 모르겠음)
- The Practice
- DBA 가 개발자와 긴밀하게 협조 - 사람은 저마다 배경이 틀리기 때문에 공식적인 문서나 미팅을 통해 커뮤니케이션하는데 어려움을 겪는다(갈등이 심해질수도 있다)이러한 형식적인 시간을 갖는것보다 PM, 컨설턴트, 개발자, DBA들이 항상 서로 대화하고 같이 일하는 것이 중요하다. 모든 개발자들의 일은 잠재적으로 DBA의 도움을 필요로 한다. 개발자나 DBA모두 어떤 개발 업무에 대하여 스키마를 변경할 것인지 아닌지 여부를 결정하는 중요한 업무를 맡게된다. 또한 개발자는 DBA에게 어떻게 수정하면 좋은지 조언을 받을 수도 있다. 개발자는 어떤 기능이 원하는지를 알고 DBA는 전체적인 DB관점을 볼 수 있기 때문이다. 이러한 커뮤니케이션을 활성화 시키려면 DBA에 가까이 앉아 쉽게 친해지게 해야한다. 보통 많은 프로젝트에 DBA와 개발자 사이의 벽이 존재한다. evolutionary database design 은 이를 무너뜨리는 것을 추구한다
- 모든 이들이 그들의 고유 database instance 를 가짐 - evolutionary design은 사람들이 시도하며 스스로를 발전시키는 것을 추구한다. 여러 시도가 있어야 보다 나은 대안이 나오는 법이다. database 도 같은 맥락으로 각 개발자가 스스로의 sandbox 를 가지고 자기가 실험하는 내용이 다른 쪽에 영향을 주지 않는 다면 보다 나은 design 이 될 수 있다. 보통 DBA가 멀티 DB를 사용하는 것을 병적으로 싫어한다. 그러나 우리는 백개 이상의 DB instance 도 쉽게 관리 될 수 있다는 것을 확인했다.
- 개발자들은 빈번하게 통합 DB(개발)에 내용을 반영 - 개발자가 자신의 instance 에서 반영한 내용 각각을 자주 통합하여 확인하는 것은 매우 중요하다. 적어도 하루에 한번은 통합해야 한다 아마도 이 긁은 읽은 사람들은 소스코드에서 수행하는 continuous integration 과 같은 개념이라고 인식 할 수 있을 것이다. 사실 이것은 DB를 다른 종류의 소스코드라고 간주하는 것이다. 마스터 DB의 경우 소스코드의 설정 관리와 매우 유사하다. 빌드가 성공하면 DB는 코드의 설정 관리 시스템으로 체크되고 소스, DB 둘다 동기화된 히스토리 버젼으로 관리된다. 우리는 소스코드에서 자동 빌드 시스템으로 통합의 고통을 견뎠다. DB에는 실제로 보다 많은 노력이 들어가기 마련인데 자동화된 DB refactoring(나중에 논의한다) 이 병행되면서 DB의 변화가 이루어져야 한다. 이러한 작업이 잘 이루어지기 위하여 갑작스런 큰 변화는 통합때 이루어지면 안된다. 이는 DBA가 개발자과 긴밀하게 협조하는 상황에서 이루어 질 수 있다. 우리가 자주 통합하는 것을 강조하는 이유는 작은 통합이 큰 규모의 통합보다 훨씬 문제점을 찾을때 쉽기 때문이다. 통합의 크기에 exponential 하게 통합의 어려움은 증가한다
- DB는 스키마와 테스트 데이터를 포함 - DB라는 개념은 단순히 스키마만 이야기하는 것이 아니라 데이터의 또한 포함한다. 이 데이터는 어블리케이션을 위한 공통 데이터(ex) 주소 우편번호체계)를 포함한다. 데이터가 DB에 존재해야 하는 이유는 당연히 테스트를 위해서이다. 어플리케이션의 개발을 안정화하기 위해서 자동화된 테스트에는 커다란 정치의 데이터가 필요하고 이 데이터는 Agile 로 가기위한 공통적인 방법이다. 코드 테스트를 돕기위한 테스트 데이터는 궁극정르로 우리가 개발하며 변경하는 스키마의 데이터 마이그레이션 작업의 테스트를 할 수 있게 만단다. 대부분의 프로젝트는 고정된 데이터를 사용하고 일부 소수 프로젝트만 레거시 시스템으로 부터 자동화된 마이그레이션 스크립트로 가져온 실제 데이터를 사용한다.
- 모든 변화들 자체가 DB 리팩토링 - 리팩토링의 기술을 존재하는 코드 베이스를 숙련되고 정제된 기술로 변화시키는 방법이다. 마찬가지로 DB 리팩토링 또한 변화하는 DB에 숙련미와 정제됨을 필요로 한다. DB 리팩토링 방법은
*DB 스키마를 변경한다 , DB에 데이터 마이그레이션을 실시한다, DB access code 를 변화시킨다. 현재까지도 우리는 다양한 DB 리팩토링을 문서화 하는 작업을 하고 있다. 그래서 더이상의 언급은 하기 어렵다. 컬럼이 추가될 때 코드가 커뮤니케이션 없이 새로운 스키마를 사용하면, 그 컬럼은 자연스레 사용되지 않을 것이고 우리는 이것을 파괴적인 변화라고 정의한다.
- 리팩토링의 자동화 - 코드의 리팩토링은 이미 정해진 여러 이름으로 툴에 의해 자동화 될 수 있고 이것은 적어도 스키마 변화와 데이타 마이그레이션의 범주안에 DB또한 반드시 필요한 내용이다. 이들 활동의 결과로, 모든 리팩토링의 SQL DDL의 형태 자동화되었다. 이는 메뉴얼하게 이루어지면 안되고 반드시 변화를 수행하는 작은 SQL script 로 마스터 DB에 작은 변화를 시키는 방법으로 수행한다. 한번이 끝나면 이 스크림트 화일을 모든 DB변화에 따른 로그를 생산하고 이를 DB 리팩토링의 결과로 DB를 변경시킨다. 이 결과물로 모든 instance 에 적용하여 가장 최근의 마서트 DB형태로 만들 수 있다. 이 변화에 대하여 순서를 정하는 작업은 지속적인 통합과 DB 마이그레이션을 위해 반드시 필요한 작업이다. 제품 DB를 위해 Iteration cycle 동안은 어떠한 변화도 일으키지 않는다. Iteration 마지막에 릴리즈를 한번 수행하면 이전 릴리즈 버전부터 DB 리팩토링의 전체 로그를 적용할 수 있다. 이것은 큰 변화이며 어플리케이션을 비가동 한 상태에서만 작업할 수 잇다. 이때문에 실 DB에 적용하기 전에 테스트 하는 작업은 매우 현명한 시도이다. 현재까지 이 작업은 상당히 잘 이루어질 수 있었다. 모든 DB의 변화를 작은 순서로 나뉘어 커다란 변화로 통합할때 드는 문젲머을 줄일 수 있다.
- 개발자들의 모든 DB 업데이트를 자동화 - 사람들이 materDB를 수정하고 업데이트 하는 것은 잘 알려져 있지만 그들이 마스터DB를 변화했다는 사실은 어떻 알 수 있을까? 소스로 이루어지는 지속적인 통합에는 개발자들은 commit 을 실시하기 전에 master를 업데이트 시킨다. 이 방법으로 자신의 instance 에서 먼저 업데이트를 실시하여 마스터 DB 의 변화를 commit 하기전에 빌드 issue를 해결 할 수 잇다. DB에 이런 방법을 사용하는 것은 물론 수행할 수 있는 방법중에 하나이지만, 우리가 발견한 보다 나은 방법이 있다. master DB에 변화가 있을때마다 프로젝트 구성원 모두의 DB를 자동으로 업데이트 한다. 이때는 master DB에 사용하는 동일한 스크립트를 사용한다. 이는 개발자들에게 개발자들의 DB를 자동으로 업데이트 시키는 것이 문제를 야기할 수 있다는 인상을 주었지만 실제로는 별 문제가 없었다.
- 모든 DB access code 를 분리 - DB 리팩토링을 이해하기 위하여 DB가 어플리케이션에 어떻게 사용되는지를 이해하는 것이 중요하다. SQL이 code base로 분리되어 퍼져있으면 이는 작업하기 매우 어렵다. 이를 위해 P of EAA 를 제안한다. 명확한 DB layer 를 지니면 좋은 ㅈ머이 많다. 이는 개발자가 SQL로 조작할 수 있는 영역과 공통 영역을 명확하게 구분하여 어떻게 DB가 돌아가는지 쉽게 이해하도록 한다.
- The Variations - 많은 practice 들처럼 이들은 특정한 상황에 많이 좌지우지 된다. 이 pratice가 얼마되지 않은것이기때문에 많이 검증되지못해 많은 변수들을 다루지는 못했지만 아래와 같은 내용들이있다
- 교통편 이탈리아여행한글사이트
- 17일날 코모로 가는 기차편은 milano에서 21:12 가 막차임 기차정보클릭
- 17일날 코모로 가는 시외버스편은 이탈리아 어 사이트밖에 검색을 못했음 제길..
- milano 에서 22일에 묵을 호텔 (짐은 어쩌까나 들고 다녀야 하는가? 아님 맡길 곳 혹은 locker 가 있나?)
- 항공편
- 출발 - 인천 -> 프랑크푸르트 17일 13:25출발 17일 17:35도착, 프랑크프르트 -> 밀란 20:05출발 21:20도착
- 도착 - 밀란 -> 파리 23일 17:55 -> 19:25, 파리 -> 인천 23일 21:00 -> 24일 14:45
참가 준비과정
- 5월 21일 인원 확정 메일 확인
- 5월 22일 센터에 답장 메일 전송
- 안녕하세요? 교육부 교무업무시스템에서 근무하는 신황규입니다.우선 이런 좋은 기회를 저희에게 주셔서 무엇보다 감사드립니다. 센터에서 저희 연구회에 이렇게 전폭적으로 지원을 해주셔서 어깨가 무거워짐을 느낍니다.앞으로 더욱 발전하는 연구회 및 센터의 구성원이 될 것임을 약속드립니다. 사전에 계획서로 제출한 XP2007은 8번째로 열리는 애자일 방법론과 익스트림 방법론을 위한 행사이고 이탈리아 코모에 있는 팔래스 호텔에서 6월 18일 ~ 22일(5일간) 열립니다. 현재 컨퍼런스에 참가할 구성원들은 이를 위한 준비를 위해 항공편 및 컨퍼런스 신청 방법등을 확인중입니다. 컨퍼런스에 참가해서 최대한 얻고 오기 위해서 무엇보다 신속하고 철저한 준비가 필요하다고 생각합니다. 저희들이 위의 처리들을 언제까지 마무리 지어야하는지와 센터에서 어떠한 고려사항이나 지원 또는 절차를 염두하시는게 있다면, 사전에 말씀해 주시면 준비하는데 훨씬 도움이 될 것입니다. 감사합니다.
- 5월 23일 참석할 tutorial 이나 workshop 결정 - 첨부화일 참조
- 5월 27일 출장 신청방법 확인
- 열린마당 -> 해외출장 신청/정산
- 출장 기간 20070617 ~ 20070624
- 출장 내용 : XP2007 Conference 참석
- 출장 기간 : 2007.6.18 ~ 2007.6.22 (5일)
- 출장 목적 : 전세계 Agile 전문가들이 모이는 세미나에 참석하여 선진 Agile 방법론으로 진행된 Practice들을 익히고 국내 도입 및 적용방안을 찾아보기 위하여
- 출장 내역 : 국가 - 이탈리아, 시작일 - 20070617, 현지도착일 - 20070617, 종료일 20070623
- issue 1 - 교통비를 어떻게 해야 할 것인가? milano에서 como로 가는 기차편에 대한 정산 방법 확인
- (maybe) 국내 출장처럼 다녀와서 신청할 수 있을것이다.
- 호텔예약 시스템 : 이탈리아 como 는 삼성의 호텔예약 시스템으로 관련 호텔이 없기 때문에 사용 불가 직접 숙박시설을 확인해야함
- issue 2 - 항공권 신청은 어떻게??
- (maybe) 현재까지 총무그룹 인사도움방에서 신청하는 것까진 알겠는데.. 메뉴를 모르겠다.
- 사내 규정 절차
- 항공권 발급 - ① 발권절차(왕복권(Round Trip Ticket)으로 발권함을 원칙으로 함) (출국예정자)-> 항공권 발권신청(해외출장 신청) -> 총무그룹(인사도움방) -> 스케줄 확인 및 항공권 예약·발권 (총무그룹) -> 신청자에게 전달
- 출장결과 보고 및 여비정산 - (1) 적용환율 : 출장비 지급일의 달러화 현찰매입율을 적용하여 숙박비와 일당 등을 원화로 환산하여 지급함, 출장 후 여비정산시 출장전일의 달러화 현찰매입율을 적용하여 정산하며, 이때 환율차이로 발생하는 손익은 출장자의 손익으로 함 (2) 출장자는 출장결과·정보입수사항·출장소감 등을 상세히 기술한 보고서를 아리샘에 등록하여야 함 (3) 출장자는 귀국 후 3일 이내에 출장여비를 정산하여야 함
- 5월 29일 항공권 예약
- 5월 30일 호텔 예약, 결재 확정 - [결재 통보]선진 개발 방법 도입 및 적용을 위한 XP2007 컨퍼런스 참가 품의, 감사메일 전송
- 6월 4일 항공권 확인, 22일 묵을 호텔 예약
Attachments
Download in other formats:
