블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (41)
Agile Experience (22)
My Family (0)
Life Style (7)
Programming (8)
Android (2)
Total
Today
Yesterday

달력

« » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

최근에 올라온 글

최근에 달린 댓글

James Grenning의 TDD and Refactoring Workshop 참가

 

몇주전 사내 역량강화센터 분들의 도움으로 매우 귀한 교육에 참가하였습니다.

TDD에 대해서는 오래전 부터 관심을 갖고 실무에 적용해보려 하였지만, 지속적으로 유지하지는 못했었습니다.ㅠㅠ

이번에 하던 업무가 정리되던 타이밍에 맞춰서 좋은 교육이 소개 되어 바로 참석하였는데, 이것은 실로 엄청난 경험이었습니다!!

사실 제가 영어 실력이 많이 딸려서, 한마디 한마디 모두 새기진 못했지만, 우리에게는 정말 잘 통하는 언어가 있었습니다. 그가 준비한 코드들과 시연하면서 보여준 코딩 모습들은 모두 저에게 큰 인사이트를 보여주었습니다.

 

 

 

그가 발표한 내용 중 가장 흥미로운 그림은 위의 그림과 같이 무수히 많은 공으로 저글링을 하는 것이었습니다.

현재 우리는 많은 공으로 저글링 하는 것처럼 많은 문제를 모두 다 노출시킨뒤에 해결하고 있다는 것입니다.

저도 그렇게 하고 있었겠지만, 생각만해도 끔찍합니다.ㅠㅠ

TDD는 한번에 하나의 문제만 해결하는데 집중하도록 하고 있습니다.

 

Uncle Bob's Three Rules of TDD

1. Write no production code, except to pass a failing test

2. Write only enough of a test to demonstrate a failure

3. Write only enough production code to pass a test

 

궁금 했던 것들에 대한 해답을 찾다.


제가 궁금했던 부분은 세가지 정도 였습니다.

첫번째는 테스트 코드에 대한 관리 이슈입니다. 프로젝트가 성장하다보면 테스트 코드의 비중도 높아지게 됩니다.

프로덕트 코드가 리팩토링 되면 테스트 코드에도 영향을 줄 수 있습니다. 테스트 코드의 원저작자가 없다면 문제가 될 수도 있습니다. 특히나 요즘처럼 자신의 코드가 아니면 Owner-ship을 전혀 가지지 않는 개발 문화에서는 더욱 문제가 됩니다.

James는 항상 테스트 코드를 깨끗하게 유지하라고 하였습니다. 리팩토링의 대상이 프로덕트 코드만이 아닌 테스트 코드도 포함된다고 하였습니다. 그리고 중요한것 중에 하나는 테스트 코드를 너무 많이 만들면 안되는 것입니다.

Unit Test 30개 + Integration Test 10개로 되는 것을 Integration Test로만 Cover하려다 보면 테스트 코드는 수백개가 넘어도 모자를 것입니다. TDD를 하다보면 자연 스럽게 Unit Test와 Integration Test의 조합을 구성하게 되며, 따라서 적은 테스트로도 높은 Test Coverage를 만들어 낼수 있습니다.


두번째는 TDD를 소개하다보면 "오버헤드가 크다, 작업이 너무 느려진다"라는 질문을 많이 받는데, 그때마다 정확히 설득하지 못했었습니다. 이는 기존의 개발 방법 대비 작업이 느려지게 느끼는 것일 뿐입니다 라고 James는 말하였습니다. Debugging이란 작업은 매우 Unpredictable 한데 비해 개발자는 Debugging 이전에 개발 완료라고 느끼는 경우가 많다는 것이죠. 아래 그림 처럼 Debugging 이전까지는 기존 개발 방법이 빠르게 느껴지지만, 코드가 버그 없이 완성되는 것은 TDD가 빠릅니다.



 

세번째는 TDD Step의 크기가 궁금했습니다. 책에서처럼 너무 작은 단위로 하다보면 살짝 멍청해보였습니다. TDD의 적용 방법은 어떤 작업이냐 혹은 작업자가 그 작업에 대한 경험이 얼마나 있는가에 따라서 달라질 수 있습니다. TDD에서 말하는 Small Step은 어떤 상황에서도 TDD를 적용할 수 있게 하는 기본적인 스킬 입니다. 처음에는 Small Step으로 계속 연습하는 것이 좋을 것 같습니다. 익숙해 진다면 Step의 크기를 자유자재로 조절할 수 있다고 합니다.


결국 제가 깨달은것은, "나는 TDD에 대해서 진정 아는 것이 없었구나!" 라는 것이었습니다.

매우 슬펐지만 반대로 무척 기뻤습니다.^^


James의 Workshop을 따라해보면 나도 우리 동료과 TDD를 할수 있지 않을까?


James는 Dojo 시스템을 이용하여 본인이 준비한 코드들과 인스트럭션으로 Group Activity를 진행하도록 하였습니다.

또한 Group Activity는 랜덤하게 2인 단위로 Pair Programming을 유도하였습니다.

Workshop참가자들이 대부분 애자일 개발에 이미 익숙한 사람이 많았고 적극적인 사람들이었기 때문 일수도 있지만, 참가자들 대부분이 매우 몰입해서 Workshop에 임하였다는 것이 매우 흥미로웠습니다.


그래서 따라해보기로 했습니다. 무작정 팀내 공지를 하였고 (약 50여명) 무작정 대회의실을 잡고, 무작정 날짜를 잡았습니다. 회비도 유례없이 미리 선불로 받았습니다. (2만원 - 뒷풀이 비용)

팀내 워크샵 당일까지 약 16명이 등록을 하였고, 모두 참석하여 약 2시간 동안 진행하였습니다. 참가자들의 직위는 책임연구원부터 연구원까지 다양하였습니다. 

 

James가 했던 내용, Group Activity를 그대로 진행하였습니다.

제가 기억 나는데로~ 물론 애드립이 난무하긴 했지만, 초반에 시작할때 성공적인 S/W에 대해서 공유도 하고, 본인이 개발시에 좋아하는 것과 싫어하는 것도 공유하였습니다.

대부분 디버깅과 테스트를 싫어하시더라구요...ㅎㅎㅎ 디버깅은 우리의 적이죠..

제가 30분 정도 TDD로 Circular Queue를 만드는 과정을 데모로 보여드리고, 랜덤하게 2명씩 짝 지어서 30분간 Pair Programming으로 TDD로 Circular Queue를 끝까지 만들어 보도록 하였습니다.

Small Step과 한번에 하나의 테스트 케이스를 계속 강조했습니다.

아래 사진에 맨 앞에 두분이 책임 말년인데 정말 열심히하시더라구요~ 워크샵 끝나고도 자발적으로 며칠 더 진행하셨습니다. Thread-Safe 까지 검증하는 테스트 케이스를 만드셨더라구요..ㅎㅎ 대박..

 

 


어라 이거 효과가 있네요?^^ (회고)

 

매우 간소하게 James 따라하기 워크샵을 진행하고 나서, 간단하게 회고를 진행하였습니다.

질문은 두가지 였습니다.

TDD에 대한 긍정적인 느낌

TDD를 업무에 적용한다고 상상했을때 가장 먼저 떠오르는 걱정


 

먼저 TDD에 대한 긍정적인 느낌에 대해서는 아래와 같이 답해주셨습니다. (작성한 그대로 옮겼습니다.)

생각보다 재미있고 긍정적인 회고 내용이 많았습니다. 제가 말로만 설득할때와는 전혀 다른 반응입니다!

특히 Pair Programming에 대한 긍정적인 느낌은 매우 인상적이었습니다^^

 

- 새로운 개발 방법을 알게 되어서 좋았음. 비록 처음 익히기는 어렵겠지만 익숙해지만 Error를 사전에 예방할 수 있어서 개발시에 많은 도움이 될 것 같음

- Pair Programming 해보니 상대방이 나와 다르게 생각하는 부분을 알게된다. 처음부터 복잡하게 이것저것 다 생각하지 않고, 하나하나 순서대로 해서 좋다.

- 구멍이 없는 프로그램을 만들 수 있을 것 같다. 프로그래밍 개발시에 다른 함수를 추가하면서 기존 함수를 - 고칠 때 기존 함수에 대한 Test가 누적되어서 테스트가 보장됨.

- 쉽게 따라 할 수 있어서 좋았습니다.

- 잠들어가는 나의 뇌를 깨울수 있는 흥미있는 Programming 접근방법

- 반복적인 테스트 Set을 구축/확장하기 용이하다

- Code를 꼼꼼히 생각하며 짤수 있다.

- Test Case 자체가 Application이기 때문에 Caller 입장에서 구현할 수 있음.

- 재밌다(신기) ㅋㅋ 한번 업무에 활용해보고 싶다.

- 코딩이랑 테스트랑 같이하니 시간 절약은 될듯. 그러나 테스트가 명확해야 함.

- 잘하면 좋은 방법론이 될 듯하다.

- 계속해서 코딩단계부터 예외사항을 고려하게 된다.

 

두번째는 TDD를 업무에 적용한다고 상상했을때 가장 먼저 떠오르는 걱정입니다.

역시 업무 속도가 느려질것 같다는 걱정이 많습니다. 위에서 설명한 것처럼 실제로는 느리지 않다는게 핵심이죠

레거시 코드에 대해서 걱정하시는 분도 있습니다. 레거시 코드는 저도 무지 걱정됩니다.^^; 따로 다루어야 할 내용입니다.

 

- 내가 만드는 Test case에 hole이 분명! 있을거다. TDD하고도 이모양이냐는 비난?

- Project 파일에 junit을 어떻게 추가하는지? 코드의 규모가 커졌을 때는?

- 개발 시간이 많이 걸리고 알고리즘이 핵심인 SW에는 적용이 제한적일 것 같음. Step이 커질때 실수 할 수 있지 않을까?

- TDD에 익숙해지기 까지 업무속도가 느려질 것 같다. TDD를 이해하는 협업하는 분위기가 아니라면 좀 힘들듯...

- 코딩 및 설계과정에서 테스트 내용을 명확히 짚고 가야 할 거 같음

- 처음 하는 것이라 시간이 많이 걸릴것 같다. 보통 처음 설계부터 하는 개발이 아는 경우 어떻게 적용?

- 초반에 시간이 많이 걸림. 확실한 test case를 만드는데 어려움 있을듯

- 어느 단위 (어느 레벨)에서부터 적용할지 의문이 생김

- 일정이 촉박하면 이런거 다 무시하고 닥치는 데로 코딩하는 마음이 생길 수 있다.

- 개발 속도가 느리다.

- TDD를 익힐 때까지 기존의 습관을 고쳐야 할 것 같음. Test case를 정하기가 어려움.

- 아직 익숙치가 않아서 그럴지 모르지만 시간이 많이 걸릴것 같다. 내가 뽑은 테스트 케이스 외에 여러가지 다른 케이스가 있을 것 같다. 시간에 쫒겨 개발시에 이걸 적용할 수 있을지

 

생각보다 반응이 너무 좋아서 2부를 진행해보려고 합니다.

2부에는 Test 하기 좋은 클래스 설계하기 및 Mock Object 사용해보기로 진행해보려구요

또한 이러한 워크샵 형태로 스터디를 진행할 예정입니다. 그리고 내년에 제가 참가하는 프로젝트에서는 TDD를 매우 적극적으로 장려하고 적용할 생각입니다. 물론 현재 프로젝트에도 개인적으로 적용을 해봤구요. 정말 흥미 진진한 2013년이 될것 같습니다.

 

James 덕분에 동료들이랑 정말 좋은 경험 하고 있네요!

James가 이 글을 보진 못하겠지만 정말 감사하다고 말씀드리고 싶어요..!^^

Posted by 윤청하
, |

이번 편은 내 경험의 일차적인 마무리로써 앞으로 해결해야할 숙제들을 정리해보려고 한다.
이것은 말단 팀원으로써의 관점이다!

교차 기능 개발팀 구성

스크럼은 개발팀 구성을 스크럼 마스터, 고객, 제품 관리자, 개발자, 테스터 등으로 구성하도록 제안한다.
우리회사의 개발 프로세스는 단계적으로 매우 고립되어 있으며, 개발팀 구성 또한 개발자만으로 구성된다.
따라서 개발자가 프로젝트를 진행하면서 테스터(QA), 고객 혹은 제품 관리자와 피드백을 주고 받는 경우는 매우 드물다.
(프로젝트가 완료된 후 상용서비스에서 장애 발생시에는 직접적으로 피드백을 주고 받기도 한다.)
개발자는 개발 팀장이 간단하게 언급하는 기능 요구사항을 그저 개발만 하면되는 프로세스이다. 

최근에 구매해서 보고 있는 책에서 교차 기능팀(cross-functional team, Wikipedia)에 대해 소개하고 있다.
이해 관계자 중심 소프트웨어 개발
고객의 비즈니스 가치를 드높이는 개발 접근법
칼 케슬러, 존 스웨이처
차영호 역
인사이트
이 책에서 저자는 개발팀은 가능한한 교차 기능팀으로 구성되어야 한다고 주장한다.
개발팀으로써의 교차 기능팀의 인적 자원 구성은 스크럼에서 요구하는 구성원 정도면 충분하다.
교차 기능 개발팀이 됨으로써 개발자는 고객의 요구사항에 어떤 비즈니스 가치가 있는지 알고 개발할 수 있고, 고객과 함께 서로 윈윈 할수 있는 프로젝트가 될수 있다.
교차 기능 개발팀에서는 모든 팀원이 프로젝트의 비전에 대한 이해도가 높아지며, 소수의 이해관계자만을 만족시키는 결과물을 생산할 가능성이 줄어든다.

교차 기능 개발팀만으로 조직이 구성된다면 문제가 될 수 있다. 하지만, 필요한 경우 교차 기능 개발팀을 유연하게 구성할수 있는 조직이라면 조직의 휴먼 리소스 효율면에서 탁월한 조직이라 할수 있겠다.
애자일 문화가 퍼져서 그 성과가 보여진다면 조직도 바뀔수 있지 않을까?

XP 적용하기

스크럼을 적용하면서 나와 희찬씨(L씨)는 XP의 실천법중 짝프로그래밍과 테스트주도개발을 팀에 적용하고자 하였다. 짝프로그래밍은 팀장님이 반대하셨으나, 테스트주도개발은 한번 해보면 괜찮을것 같다는 반응이셨다.
익스트림 프로그래밍 2판
변화를 포용하라 
켄트벡, 신시아 안드레스
정지호, 김창준 역
인사이트
우리는 제대로된 짝프로그래밍은 못하였으나 짝을 지어서 개발을 하도록 노력하였다.
단일 기능에 대한 요구사항 분석, 설계, 개발, 테스트등을 짝을 지어서 개발하였다. (원래는 혼자 해야 한다.)
그나마 다행인것은, 팀장님의 배려로 짝으로 구성하여 자리를 옮길 수 있었다.
혼자 고민하던 것을 짝을 지어서 실시간으로 피드백을 주고 받다 보니 선택의 기로에서 정체되는 일이 드물었으며 개발의 완성도 또한 높았다. 하지만 혼자해야 할 작업에 두명이 투입되었기 때문에 시간적으로 2배 빠르게 진행되어야 했다.
또다른 장점은 코드 공유의 범위가 확대 되었으며, 무 집중도가 매우 크게 상승했다는 것이다.
불행히도 위에 열거한 장점들은 나와 희찬씨만 느꼈을 뿐 다른 팀원들은 이전 방법으로 되돌아 갔다.

올해 우리회사 슬로건 중 하나는 "장애율 0%" 이다. 
이 슬로건을 연구소에 내밀었을때 연구소의 개발자들은 매우 흥분하였다. "버그 없는 소프트웨어는 없다!"
이와 같은 슬로건이 나오게 된 것은 당연히! 작년에 회사의 신뢰도에 문제가 있을 정도로 장애가 많았기 때문이다.
VoIP가 대체 통신 수단에서 주 통신 수단으로 서서히 변경되면서 품질에 대한 걱정은 더 커져갔다.
연구소에는 자동화 테스트의 개념은 전혀 없었으며, 제품에 새로운 기능이 추가될 때 회귀 테스트도 없었다. (기본 기능의 성공 케이스만 확인하는 정도)

난 켄트백의 테스트 주도 개발 책을 보면서 이것이 바로 우리 회사에서 적용해야 할 첫번째 실천법이라고 생각했다.
테스트 주도 개발
Test Driven Development by example
켄트 벡
김창준 역
인사이트
그리고 회사 내의 수석 개발자를 찾아갔다. 그분이 이미 알고 있는 듯한 눈치였으며, 이런거는 회사 현실에서는 맞지 않는다는 뉘앙스를 풍기셨다. 팀장님도 그다지 환영하는 분위기는 아니었다.
물론 두분 다~ 자동화 테스트가 정말 필요하다는 것은 동의하셨다. 
테스트 주도 개발은 자동화 테스트를 누구나(?) 쉽게 만들 수 있는 명료한 방법이다.
  • 테스트 먼저 작성하라
  • 중복을 제거하라
희찬씨와 나는 신규 비디오 코덱 개발에 테스트 주도 개발을 적용하였다. 결과는 참담했다.
비율로 보자면 20 : 80 정도로 기존 개발 방식을 거의 고수하였던 것이다.ㅠㅠ

얼마전에 있었던 xper 정기모임에서 나는 테스트 주도 개발 실천법이 적용하기 어렵지만 그 효과는 매우 크다는 것을 다시 한번 깨달았다. 테스트 주도 개발을 팀에 제대로 적용할 수 있다면 지금처럼 팀의 리소스의 30% 이상을 유지보수에 힘쓰고 있지는 않을 것이다.

문화 바꾸기

애자일에서 팀웍은 매우 중요하다. 즉, 혼자 잘해서 될일이 아니다.
팀 혹은 조직의 문화가 바뀐다면 사람도 바뀔 것이고 조직의 가치도 바뀔 것이다. 
그 안에서 애자일 실천법의 적용은 매우 쉬울 수도 있다.
팀장도 아닌 말단 개발자인 내가 팀과 조직의 문화를 바꾸려면 매우 힘들다는 것을 잘 안다.
하지만 나의 지지자(도반)들을 꾸준히 늘려나간다면, 그리고 이와 같은 생각들을 공유한다면 언젠가는 내가 속해있는 조직도 고효율의 조직이 될 수 있을 것이라 확신한다.

마무리

당분간, 난 테스트 주도 개발에 익숙해 지기 위해 매진할 것이다. 일단 고!
같이 하실분 없나요?^---------^

읽어주셔서 감사합니다!~ 
그냥 가지 마시고 리플로 피드백을 해주신다면 정말 정말 백만개 감사할 것 같습니다.^^
Posted by 윤청하
, |

토요일 오후 2시, 명동 LG CNS 본사 2층 대회의실에서 xper 10월 정기모임이 진행되었다.
나는 청하 쥬니어 탄생 준비로 미뤄왔던 xper 정기모임에 처음으로 참가하였다.

LG CNS 건물 1층에서 어떻게 들어가야 할지 방황하던 다른 두분과 함께 모임 장소에 도착했을때에는 10명 정도 되는 분들이 자리에 계셨으며, 발표를 위한 셋팅 준비를 하고 계셨다.
일단 조촐하게 그룹을 만들어서 자기소개를 진행하고, 이런 저런 얘기를 나누었다.
처음 참석하는 모임이고 오프라인으로 아는 분들이 한명도 없어서 내심 긴장했는데, 편안한 분위기 속에서 진행되었고, 다른 분들도 딱히 서로 잘 아는 것 같지 않아서 좋았다^^;;;

첫번째 발표, "존재하기와 발전하기 - 변신철"
우리의 일상은 엉망진창이다.
TDD는 명료하며, 현재 엉망진창이라는 것을 확실히 알려준다.
짝프로그래밍은 같이 바라보는 것이다. "너 봤니? 나도 봤어" 같이 하면서 성공하게 되면 하이파이브를 하게 되고 매우 신나게 된다.
비난 받지 않는 회고를 진행하였다. 팀원들은 비난받지 않을 권리와 경청해야할 의무를 가진다.
비난 받지 않기 때문에 개인적인 일까지 회고한다. "웹서핑 시간이 많아졌어요. 이유는 핸드폰을 사야해서..ㅋ"
애자일은 우리를 우리(짐승을 가두어 기르는 곳)에 가둔다. 화를 낼수 없다.
혁명은 실천법(practice)나 개발 프로세스로 쉽게 얻을 수 있는 것이 아니다. 노력하고 힘들어져야 변화할 수 있다.
소통하기 어려운 팀원이 있었다. 드디어 소통하게 되었다. 그것은 내가 힘들어지고 바뀌게 되어서 된일이었다.
애자일이 실천법으로만 설명되지 않았으면 좋겠다.
변할만 할때 변화한다. 은탄환(silver bullet)은 없다.
애자일은 사람과 관련된 일이다. 켄트백왈 "프로그래밍은 사람이 하고 사람에 의해 사람을 위한 것이다.(맞나?^^)"
TDD가 가장 쉬었다는 변신철님, TDD를 실무에 적용하기로 마음먹고 실천한지 몇개월이 지났지만, 아직도 TDD를 자주 빼먹는 나로써는 매우 공감할 수 없는 표현이었다.ㅠㅠ
변신철님은 TDD를 통해 프로젝트를 성공적으로 이끄셨다고 한다. 개발 플래폼에서 완료된 프로그램을 상용 플래폼으로 이식할 때에 작업이 한번에 이루어졌으며, 그 후 3년간 개정 없이 상용 서비스 중이라고 한다. 일어나서 박수라고 치고 싶었다.ㅠㅠ

질문/답변 시간에 나왔던 내용들..
애자일 팀을 구분할 수 있는 특징은 무엇인가요?
-  야근을 안한다.(진심으로 부럽다ㅠㅠ) 팀장이 소리치지 않는다. 벽에 무언가 많이 붙어있다.
요구사항, 품질, 팀의 밸런스는 어떻게 조절하나요?
- 품질이 가장 높은 우선순위를 가진다. 잦은 릴리즈 주기로 높은 품질을 제공했더니 고객이 스스로 요구사항을 줄였다.
- 팀장이 고객 옆에서 계속 질문하며 일한다. (질문은 정확히 기억나지 않음)

휴식시간에 있었던 김창준님의 부연설명 (어떤 내용에 대한 부연설명이었는지 까먹었음ㅠㅠ)
위험을 어떻게든 줄여서 애자일을 조직에 적용하려 한다면, 성공하기 어렵다. 책임을 지고(위험을 감수하고) 애자일을 적용해야 성공할 수 있다. (노출, 다치기 쉬운, vulnerable)
어떻게든 쉽게, 위험 없이 애자일을 적용하려고 했던 내 지난날을 반성했다ㅠㅠ

두번째 발표, "캐빈문화 소개, 즐거운 일터 만들기 - 김종욱"
캐빈문화란, 다음 뷰 서비스를 개발하기 위해 기획자, 개발자, 디자이너 등이 한군데 모여 팀을 이룬 것이다. (장소가 옥상이라 캐빈이라 지은듯.. 창문 밖으로 한라산이 보인답니다ㅠㅠ부러우면 지는거다..)
우리는 포스트잇으로 테스크 관리를 한다.
각 테스크는 추정시간이 따로 없으며, 4시간단위로 쪼갠다. (갯수로 파악한다 - 한눈에 파악될듯..)
현재 프로젝트 상황은 포스트잇을 백로그/ToDo/Doing/Done/협의중 으로 분류하여 화이트보드에 붙여서 표현한다.
백로그로 파악되지 않는 일상 업무를 양지로 끌어올리기 위해 노력했다.
주간회고를 통해 구성원들이 더 많은 고민을 하게 만들었으며, 더 많이 공개하도록 하였다. (도움, 칭찬, 격려, 비폭력대화, 성향별대화)
도반(불교, 함께 도를 닦는 벗)을 얻는 것이 중요하다.
애자일 문화를 다른 팀까지 전파시키는데에는 조직적인 한계가 있다. (새로운 회사를 차리는게 빠를수 있다.)
직군은 할일을 제한시키며 많은 시도를 하기 힘들게 한다. 직군 파괴를 해야한다.
여유(다음의 ctime)를 주어서 더 많은 시도를 할수 있도록 해야 한다.
업무를 포스트잇과 화이트 보드로 하는 것은 현재 우리팀이 하고 있는것과 다르지 않았다. (기분 좋았다^^)
직군 파괴는 정말 괜찮은 아이디어 같았다. 현재 우리 회사도 직군을 더 세분화 시키려고만 하고 있다.ㅠㅠ

개인 회고
  • 그동안 실패했던 TDD를 다시 제대로 적용해야겠다는 다짐을 하게 되었다.
  • 애자일 문화가 전파되기 위해서는 더 많은 도반이 필요함을 느꼈다.
  • 기존의 세분화된 조직에서 애자일 문화를 전파시키는데는 한계가 있다는 것은 아쉽다.
    정말 방법은 없는 것일까?
    내가 애자일 팀으로 이직을 하던지, 새로 회사를 차리던지 하는게 유일한 방법일까?
  • 애자일과 야근과의 관계를 명확히 알수 있어서 좋았다.^^
  • 변화하고 싶다면, xper 정기 모임을 추천한다! (xper 메일링 리스트)

Posted by 윤청하
, |