Agile 방법론

06.Agile 2009.10.07 15:58

 

제가 전달하고자 하는 부분은 애자일(Agile)개발 방법론에 대한 것이 아니라, 애자일(Agile)개발 방법론을 어떤식으로 현재 개발상황에 어떤식으로 어떻게 적용시킬 것인가에 대한 내용입니다.

 

그전에 애자일(Agile)개발 방법에 대한 개념에 대해 설명하도록 하겠습니다.

애자일 개발 프로세스란, 어느 특정 개발 방법론을 가리키는 말이 아닌, 애자일(Agile=기민한, 좋은 것을 빠르고 낭비없게 만드는 것)개발을 가능하게 해주는 다양한 방법론 전체를 일컬어서 "우리는 이것을 애자일(Agile)이라고 합시다" 라고해서 이름 붙게 되었습니다.

 

다음은 애자일(Agile) 개발 프로세스로 불리는 개발 방법론에 대해서 간단한 소개를 하겠습니다.

 

  • 익스트림 프로그래밍(Extreem Programing, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
  • 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.
  • 크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.
  • Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.
  • Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 어플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는것이 조금 다르다.
  • 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.

- 위 내용은 <위키백과>에서 참조하였습니다.

 


애자일에 대해서 말하자면 수많은 좋은 내용들이 있겠지만, 게임 개발자 컨퍼런스(KGC2008)(08.11.14)에서 강연을 했었던,

  1. 엔트리브의 김기웅씨 "애자일 게임 개발이란?"
  2. 애자일 컨설팅의 김창준씨 "애자일 게임 개발 도입하기(월드 카페)"

강연을 듣고 이야기하고 나누었던 내용들에 대해 정리해보고자 합니다.

 

단순히 자리에 앉아서 졸고 인터넷에 널리 퍼져있는 말들이나 스크린에 비춰가면서 와닿지도 않는 말들을 노트에 끄적이고 했던 다른 강의와는 달리 전문강사가 아닌 현역 개발자분들이 직접 나와서 경험한 개발 방법론에 대해 설명하다보니 미숙할 수도 있었지만, 제가 참가한 월드 카페식 토론에서 짧지만 약 6시간중...50여명의 개발자분들의 다양한 경험이나 의견 및 이야기를 공유할 수 있었습니다.

 

 

월드 카페 진행 주제 : 어떤식으로 애자일(Agile)을 적용할 것인가?

 

1. 애자일(Agile) 방법론을 꼭 적용해야 하는가?

아니다. 애자일(Agile)에서 추구하는 것은 더 낳은 개발 프로젝트 관리 및 성공을 위한 열쇠로 사용되려 하는 것이지, 무조건적인 적용으로 불필요한 시간을 낭비해서는 안된다.(* 어떠한 방법론이라도 마찬가지 일 것이다)

애자일(Agile)이 아니더라도 현 프로젝트에 가장 적합하고 성공으로 이끌 수 있는 개발 방법론을 사용하고 있다면, 무리하게 적용할 이유가 없다.

 

2. 어떤식으로 애자일(Agile)을 적용할 것인가?

- 소규모 팀 단위 적용실천법 -

 발표자 : 조현희(소속 :  포뎁스)

"화이트 보드를 활용한 방법에 대해 제시하겠습니다"


  1. 업무를 단위별로 구분(업무 기간별 조정 필요)

    포스트잇등의 메모장을 활용하여 업무에 대한 내용을 기재, 화이트보드에 업무단위별(대기,진행,완료등..)로 구분짓고 게시한다.

  2. 업무에 대한 담당자를 표시하여 게시한다.

    다른 팀원이 어떤일을 하는지 모두가 파악이 가능해지며, 업무관한 자연스런 토론 및 미해결건에 대한 해결책을 자연스럽게 제시 할 수 있는 환경이 만들어질 것이다.

  3. 완성된 업무에 대한 분류

    업무에 대한 진척도가 파악되어 프로젝트의 전체적인 일정관리 및 조정이 한결 수월할 것이다.

 

이를 활용하게 되면 현재 진행하고 있는 프로젝트의 진행상황 및 문제점등이 투명하게 관리되어 전체적인 현황관리가 수월해 질 것입니다.

 

"완성된 업무에 대하여 개발과정이나 문제점 해결 방법등에 대한 간단한 발표를 통해 팀원간 성과에 대한 인식 및 칭찬을 통하여 다음업무를 위한 '파이팅'을 부여하면 좋을 것 같습니다" - 발표 후 토론중 의견제시...

 

- 개인별 적용 방안제시 -

발표자 : (소속 : 루벤소프트)

"화이트보드 활용 방법을 재구성하였습니다"

  1. 업무별 주제 부여
  2. 단위별 업무에 대한 익명게시

    다른 팀원이 가벼운 마음으로 업무에 대해 접근할 수 있도록 환경제공

  3. 해결된 업무에 대한 이력 게시

    '담당자'와 '해결자(해결방안 제시자)'가 의견을 주고받은 내용을 기록하여 각 팀원들이 알 수 있도록 내용을 게시 및 전파한다.

    애자일(Agile)이라는 생소한 단어를 꺼내서 "해봅시다!"라고 하는것 보다 팀원들이 이러한 과정에 대하여 '호기심'을 가질 수 있도록 유도하여 자연스럽게 접할 수 있도록 하는 것이 주목적.

 

이론적인 개발실천법을 따라가는 것이 아닌, 팀원 모두가 실천법에 대해 '이해'하여 우리팀에 맞게 재구성하면 새로운 개발론에 대한 어려움이 들할 것이다.

 

- 패턴 로그 제시 -

개발하면서 성공적인 사례를 패턴화하여 관리하는 프로그램을 구성.

게시된 패턴을 보고 각자의 생각 및 의견을 반영하여 더 낳은 구성으로 패턴을 '진화'시키며, 팀원들이 타프로젝트 혹은 이전프로젝트에서 사용되었던 패턴을 활용하게 되면 패턴개발등으로 소모될 시간을 단축하여 더 높은 품질의 프로그램을 제작하는데 시간을 투자할 수 있을 것이다.

잘은 기억이 안나지만 김흥배(?)님께서 경험공유로 의견을 내주신것 같다.

 

- 기타 의견들 -

  1. Daily Meeting

    매일매일 약 20여분간의 간단한 회의를 통해 자신이 그날&그주에 맡은 업무에 대해 다시 한번 확인한다.

  2. 열린 개발환경 제시

    간단한 회의를 위해서 모두 자리를 뜨고 회의실로 몰려가는 불필요한 자리이동 없이 서로 마주 볼 수 있도록 업무환경에 대해 개선

    일과 회의가 자연스럽게 하나가 되어 즉흥적이면서 유기적인 관계를 통해 신속정확한 대처로 업무의 효율성을 극대화 시킬수 있을 것이다. ( 엔트리브 김기웅씨 강연내용 )

     

    ms-pnp_teamTable.jpg

    강연내용에 소개되었던 샘플사진을 구하지 못하여,  

    인터넷에서 MS PNP(patterns & practices)팀의 개발환경사진을 구해 대체하였습니다.

    사진에서 볼수 있듯이 팀원간에 파티션이 없어 간단한 업무 협의나 회의장소의 이동없이 쉽게 이루어 질수 있습니다.

     

     

  3. 회의 방식에 대한 개선 필요

    '팀장'주도하에 이루지는 회의는 책임감이 떨어진다.

    '팀원'들 모두 진행하는 프로젝트에 대한 '이해'속에서 서로의 의견을 주고받음으로써 다양한 의견속에서 가장 좋다고 판단하는 의견을 팀원들이 선택, 반영 및 검토한다.

    '팀원'들 스스로가 자기일의 '책임자'가 되어 자신의 업무와 관련된 팀원들간의 자발적인 회의를 통해 의견을 주고 받으면서 '일'에 대해 정확히 '이해'하여 전체적인 그림을 그려나간다.

 


- 애자일 방법론 적용경험 공유 -

 

개발자라 상상을 한다면 사무실 구석에서 자기만의 성을 짓고, 문서만을 넘겨받아 요건을 충족시키고 그 요건에 맞추어 개발을 완성하였을때, 클라이언트가 건네준 문서의 요건과 클라이언트가 실제 기대하는 요건과는 조금 틀릴수 있다는 것을 눈치채지 못한채 자기만족을 느끼며 '개발완료'라고 도장을 찍고는 했습니다.

 

애자일 개발방법론에 대해 어느정도 이해를 하고 나서는 생각을 고치게 되었습니다.

 

애자일 개발헌장을 참조하게 되면,

 프로세스와 개발 보다 사람과 의사소통

                  기획문서 보다 눈에 보여지는 결과물

                                                계약과 협상 보다 고객과의 협업(빠른 피드백으로 회의시간 단축)

계획에 대한 맹종 보다 변화에 대한 대응

 

고객과의 협업, 즉 클라이언트와의 피드백 교환으로 클라이언트가 원하는(중간중간 변할수 있는) 요건에 대해 발빠르게 대응하여 결과적으로 문서가 아닌 클라이언트가 원하는 프로그램을 보여주는 것이 완성도 높은 프로그램을 만드는 것이라 생각하게 되었습니다.

 

현재 1인파견개발자로써 본사 사무실 구석에 앉아 문서만 챙겨서 개발하는 것에 변화를 주어 직접 클라이언트의 회사에 자리를 마련하여 실담당자와 많은 의견교환과 문서로 파악한 내용이 맞는지 대한 확인절차를 통하여 이유없이 고민해야할 부분들에 대한 시간단축을 통해 완성도 높은 프로그램을 만들어 내기 위한 노력을 하고 있습니다.

 

제가 한 행동은 본사 사무실에서 단지 클라이언트의 회사로 자리를 옮긴 것 뿐이지만, 그 효과는 약 1주일의 시간단축을 가져왔고, '어떻게 만들어야 하지?'라는 맹목적인 고민에 대해 빠른 결단을 내릴 수 있게 되었습니다.

그리고 앞서 말한 애자일 개발헌장에 있듯이 사람과 의사소통, 눈에 보여지는 결과물, 고객과의 협업, 요구조건이 바뀌더라도 그에 대응하게 되는 점들 모두 충족하면서 개발하고 있다고 생각합니다.

 

2008.12.19 - 내용추가-_-;

새로운 방법론에 대한 부작용이랄까...너무 잦은 의견교환으로 클라이언트가 나에게 사소한것까지 일처럼 불려서 나한테 시키고 있다는 단점을 알게 되었습니다.(클라이언트가 스스로 해도 되는데 말이지요.)

휴가기간임에도 불구하고 어김없이 날아오는 업무메일이 증거. ㅠㅠ..이건 꼭 애자일이 아니어도 그럴꺼라는 생각이 드네요...

  

  ...

신고

'06.Agile' 카테고리의 다른 글

Agile 방법론  (0) 2009.10.07
스크럼, 팀의 생산성을 극대화시키는 애자일 방법론  (0) 2009.08.25
Posted by Stewie

TOW는 윈도우에서 Trac을 쉽게 만들어 사용할 수 있도록 해주는 all-in-one 인스톨 프로그램이다. 
(인스톨 프로그램이기 보다는 그냥 디렉토리만 덩그러니 넣어주면 끝..)

간단한 사용방법 이며 필수적인 내용을 적어놓은다.

1. 사용자 등록
C:\TOW>add-user.bat <UserName> <Password>
2. 프로젝트 등록
C:\TOW>create-svn-repo.bat <ProjectName>
C:\TOW>create-trac-repo.bat <ProjectName>

 해준 후 http://localhost:8080/projects/<ProjectName> 으로 접속하면 됨.


3. Admin 설정 방법

C:\TOW>trac-admin.bat <ProjectName> permission add stmoon TRAC_ADMIN

 

4. 시작시 항상 데몬으로 띄우는 방법 (실패)

C:\>sc create trac binPath= “c:\TOW\start-tow.bat” start= auto displayname= “Trac Service of TOW”

 

신고

'05.IDE' 카테고리의 다른 글

Eclipse 4.2 + plugins  (0) 2012.08.30
Runtime ClassNotFoundExceptions may result 문제 해결  (0) 2011.05.16
CVS fileattr.xml 에러 발생 해결  (0) 2009.10.20
Subversion을 이용한 형상관리  (0) 2009.10.08
TOW All-in-One 설치하기  (0) 2009.09.29
Posted by Stewie

okcode 님이 http://sourceforge.net/forum/forum.php?thread_id=914883&forum_id=206693 내용을 다시 요약정리한 글입니다

 

1. 2개의 프레임웍의 분류

a. Hibernate: Object Relational Mapper
b. iBatis: SQL mapper

2. Object Relational Mapper란?
a. Database 엔티티(일종의 테이블 row)와 자바 객체를 동기화 하는 역할을 담당
b. Hibernate는 이러한 역할을 하는 프레임웍
c. 모든 sql문은 프레임웍에서 생성되고 실행됨
d. sql작업이 필요할 경우 HSQL을 통하여 이루어짐(EJB-QL과 유사)
e. HSQL은 실제적인 sql의 앞단에서 처리되는 객체지향 쿼리 랭귀지
f. 종류: hibernate, TopLink, Cocobase, JDO 구현체

3. SQL Mapper
a. 자바객체를 실제 sql 문장에 맵핑.(자바 코드에서 sql 관련부분 제거)
b. Sql 문장은 자동 생성되는 것은 아니고 개발자가 기술해 줌
c. 맵핑 자체는 데이터베이스이 엔티티와 관계(relationship)에 독립적임.(mapping 자체가 sql문에 국한)
d. 실제적으로 모든 임베디드 sql 시스템은 모두 sql mapper로 간주가능
e. 예: iBATIS SQL Maps, Oracle SQLJ, Forte 4GL Embedded SQL, Pro*C Embedded SQL
f. iBatis sql map의 경우 xml에 임베디드된 sql (자바코드의 sql을 xml 파일로 분리)

4. Hibernate와 iBatis의 비교우위
a. Hibernate와 iBatis는 다른 특성을 갖는 프레임웍임
b. 일차원적인 비교는 불가능
c. 상황에 따라 적용 프레임웍의 효율성이 달라짐
   c-1 Hibernate가 적절한 경우
    * 새로운 프로젝트가 시작된 상태
    * 객체 모델과 데이터베이스 디자인이 미완성인 상태
   c-2 iBatis가 적절한 경우
    * 3rd party databases에 접근하는 경우
    * 레거시 데이터베이스와 연동이 필요한 경우
    * 적업하고 디비 디자인이 부적절한 상태(지져분한 설계)시
    * O/R Mapper가 이러한 상황을 제어할 능력이 없을수도 있음.
    * SQL Mapper를 사용할 경우 객체 모델과 데이터 모델사이의 멥핑에는 아무런 제약 사항이 없음.
    * sql문을 인력을 사용하여 수작업으로 tuning이나 최적화를 해야 할경우

5. Performance 측면의 비교

a. 과거 embeded sql mapper
    * 컴파일 랭귀지를 사용하여 제작됨
    * 매우 빠른속도를 제공하고 시스템 환경에 최적화 되어 있음
b. O/R mapper
    * sql mapper에 비하여 다양한 일을 수행
    * 대부분 reflection 방식 (hibernate),
    * binary code inhencement 방식(JDO).
    * hibernate의 향후 버전에서는 binary code inhencement방식을 채용
    * reflection 방식을 사용한다는 측면은 iBatis와 공통점

6. 프레임웍 성능비교는 무의미
a. 프레임웍 성능이란 프레임웍을 어떻게 사용하는 방식에 따라서 결정
b. 일반적으로 O/R mapper가 sql mapper에 비해서 훨씬더 효율적인 맵핑을 하고 수행전략을 수립.
c. O/R mapper는 객체 모델과 데이터베이스 모델에 대한 광범위한 정보를 포함있음
d. 간단한 CRUD 어플리케이션에 테이블-클래스 맵핑을 사용한다면  단순성과 성능이란 측면에서 O/R mapper많은 장점을 갖고 있음
f. 복잡한 데이터 전송방식의 환경에서는 sql mapper가 효율적임
g. Sql mapper가 더 효율적인 sql의 장점들을 표출할 수 있음

7. 결론
a. 하나이상을 선택하여 테스트 해보라.
b. 프로젝트에 대한 컨셉에 따라 세밀하게 테스트 해보라.
c. 모든 프로젝트의 특정은 모두 다르며 상황에 따라 Hibernate, iBATIS SQL Maps, TopLink, raw JDBC를 유연하게 사용해야 함

8. 필자의 의견 (Clinton Begin-iBatis 개발자)
이러한 이유에서 다양한 툴(프레임웍)을 빠르고 효과적으로 선택하고 테스트 하는 방법을 배우는 것이 더 중요하고 유용하다. 프레임웍중 하나만을 사용할 줄 아는 것은 중요한 것이 아니다. 다양한 상황에서 연습을 해보고, 더 좋은 결정을 내려보시길 바랍니다. 성배를 찾는 것은 중요한 것이 아닙니다
신고

'09.Framework' 카테고리의 다른 글

Spring Framework / ReloadableResourceBundleMessageSource  (0) 2011.08.16
Spring MVC SimpleMappingExceptionResolver  (0) 2011.08.16
Spring 3.0 에서 Quartz 설정  (0) 2011.08.09
iBatis 동적 SQL 작성  (0) 2009.10.25
WebWork in Action  (0) 2009.10.07
Hibernate VS iBatis  (0) 2009.09.23
Posted by Stewie


티스토리 툴바