XP 초심자가 도서 "익스트림 프로그래밍"을 읽고 느낀 것

[imy...@gmail.com]

안녕하세요 :) 임용민입니다.

저번에 가입 인사 글을 올렸는데 다들 반겨주셔서 감사했습니다.
오늘은 XP 초심자의 입장에서 익스트림 프로그래밍 책을 읽고 생각한 것들을 공유해 드리고자 합니다.

가입 인사 글에 대한 답글 중 '익스트림 프로그래밍' 책을 읽고 소감을 남겨 주신 분이 계셨어요. 그 분께서 최근 책을 읽은 저의 입장에서 XP에 대한 의견을 남기면 좋은 대화의 장이 될 것 같다는 의견을 주셨습니다. 저도 책을 읽은 뒤 그냥 넘기기 보단 제 생각을 공유하는 것이 좋다고 생각해 이렇게 글을 쓰고 있습니다. XP를 최근에 접해서 부족한 것이 많으리라 생각하는데요, 많은 선배분의 고견을 들을 수 있을 것 같아 용기 내어 작성해 봅니다.

• 평소 개발자로서 해왔던 고민

저는 개발자로 일을 한 지 그리 오래되지 않았습니다. 경력으로 치면 한참 주니어죠. 그래서 그런지 고민이 많았어요.

‘어떻게 하면 더 나은 직장 생활을 할 수 있을까?’, ‘어떻게 하면 더 나은 개발자가 될 수 있을까?’, ‘어떻게 하면 내가 맡은 프로젝트를 잘 완수할 수 있을까?’, ‘어떻게 하면 더 나은 팀/회사가 될 수 있을까?’ 등등...

안타깝게도 저는 주변에 이런 고민을 터놓을 수 있는 멘토가 없었습니다. 그래서 저는 고민의 해답을 책에서 찾고자 했습니다. 그 과정에서 '함께 자라기'라는 책을 읽게 되었고 이를 계기로 애자일에 관심을 가지게 되었습니다. 이 관심이 이어져 '익스트림 프로그래밍' 책을 읽게 되었네요.

'익스트림 프로그래밍' 책을 읽고 고민의 많은 부분이 해소되었습니다. 제가 가지고 있던 고민의 본질을 다루고 있었기에 속이 뻥 뚫리는 기분이었어요. 단순히 개발 잘하는 방법을 알려주는 것이 아닌 개발자의 삶을 관통하는 무언가를 다루고 있었습니다. 그 무언가라는 것은 바로 XP가 추구하는 가치(의사소통, 단순성, 피드백, 용기, 존중)였습니다.

• XP는 가치를 추구하는 철학으로 다가왔다.

책에서는 'A라는 방법을 쓰면 더 좋으니 A라는 방법을 써라'라고 이야기 하고 있지 않았습니다. '어떠한 가치들을 추구하기 때문에 A라는 방법을 쓰고 있다'라고 말하고 있었죠. 저는 이 접근법이 굉장히 매력적으로 다가왔어요.

그래서인지 이 책을 읽으면서 철학을 다루는 책을 읽고 있다는 느낌을 받았어요. 제가 깊이 공부하지는 않았지만 경험을 되짚어 보면 철학이라는 것이 본질이 되는 가치를 논한 뒤 그 예시로 행동방식을 들고 있었거든요.

책에서 XP의 실천 방법들을 읽을 때 XP가 추구하는 다섯가지 가치들을 어떻게 반영하고 있는지 생각하면서 읽으니 더 재밌게 읽을 수 있었어요. 또 그렇게 책을 읽으니 XP를 창안한 사람들이 '의사소통, 단순성, 피드백, 용기, 존중'이라는 다섯 가지 가치를 도출하기 위해 얼마나 많은 고민과 생각을 했을지 느껴졌습니다. 그리고 정말 중요한 것은 이 가치들이 아닌가 생각하게 되었어요.

• 실천 방법이라는 족쇄를 풀고 가치를 향해!

제가 재직 중인 회사는 애자일적(?)인 프로세스를 가지고 있진 않습니다. 그나마 다행인 것은 제가 책에서 읽거나 혹은 직접 경험한 것들을 이야기하면 다들 긍정적으로 반응해 주십니다. 그래서 현재 회사에서 여러 가지를 도입 및 전파하고자 노력하고 하고 있어요. 회사 생활을 돌아보면 페어 프로그래밍이나 TDD를 적극적으로 전파하려고 노력했던 것 같아요. 사내 세미나에서 TDD에 대한 발표도 2번 했고요. 문제가 발생하면 페어로 보는 환경을 조성하고자 노력했습니다.

그런데, 이 책을 읽은 뒤로는 조금 더 본질적인 생각을 하고 있습니다. 꼭 페어 프로그래밍이나 TDD를 해야 한다는 생각에서 벗어나게 되었어요. "현재 상황에서 '의사소통, 단순성, 피드백, 용기, 존중'을 실현하려면 어떻게 행동하는 것이 좋을까?"라는 것을 먼저 생각하게 되었습니다. 예를 들어 페어 프로그래밍이나 TDD를 할 때에도 방법에만 초점을 맞추는 것이 아닌 XP의 가치들이 발현되고 있는지가 중요해졌습니다.

나의 행동, 언행, 업무 태도 등이 XP의 가치인 '의사소통, 단순성, 피드백, 용기, 존중'에 부응하는가? 저는 이 점이 XP의 본질이고 중요한 점인 것 같아요. 책을 읽은 뒤로 이 가치들을 마음속에 새기며 하루하루를 보내려고 노력하지만 쉽지는 않네요.

다들 XP란 어떤 것이라 생각하시고 어떻게 실천하고 계신가요? 많은 선배님의 고견을 듣고 싶습니다.

책을 다 읽자마자 블로그에 독후감을 남겼는데 이렇게 또 정리하고 나니 새롭네요.
긴 글이 되었는데 읽어주셔서 감사합니다.
모두 건강 조심하시고 즐거운 하루 보내세요!

[Chungha Yun]

안녕하세요 윤청하입니다.

제가 했던 고민들과 실천들과 비슷한 부분이 많아서 반가웠습니다. 같이 고민을 나누고 실천할수 있는 동료를 구하는 것은 정말 중요한것 같습니다.

말씀하신 XP의 가치는 매우 중요하다고 생각하고 이는 채용에서부터 검증되어야 한다고 생각합니다. 기본적으로 자질이 되는 분들이 모여야 좋은 팀이 될수 있다고 생각합니다.

(실례로 예전에 다니던 회사에서 같은 의견을 가진 분들과 함께 CTO분께 공채를 폐지해야 한다고 주장하기도 했었죠...^^;;)

하지만 저의 경우에는 그 이전에 소프트웨어 엔지니어로써 가장 중요한 덕목은 코딩이라는 것을 나중에 깨닳고 애자일 관련 스터디는 홀딩하고 몇년간은 코딩 스터디에 집중했던 것 같습니다.

그때 했던 스터디 주제들중에 하나는 손코딩 뇌컴파일 눈디버깅 이었는데 알고 보니 실리콘 벨리의 채용 인터뷰에서 가장 중요하게 보는 요소였습니다.

결국 채용에서 중요한 평가 요소는 '완벽한 코딩 실력 (머신이 없어도 완벽한 코드를 생산할 정도의)' + '의사소통, 단순성, 피드백, 용기, 존중' 인 것 같습니다.

제가 현제 재직중인 회사는 위의 말씀드린 평가 요소만을 가지고 인터뷰를 진행합니다. 6회 이상의 인터뷰를 통해 꼼꼼히 체크하고 채용에 신중합니다.

그러다보니 말씀하신 고민들 보다는 팀원들과 리더들을 통해 배우는 것이 너무 많아서 벅차기도 합니다. 애자일 혹은 XP도 도구(또는 프로세스)이기 때문에 사람이 가장 중요하고, 따라서 누구랑 하느냐가 중요한것 같습니다.

XP의 가치도 몸에 베기 위해서는 좋은 성장을 위한 피드백도 많이 받아보고 회고를 통해 개선하고 많은 의사소통을 해봐야 하는데 (좋은 질문도 사실 어렵습니다) 이도 좋은 팀에서나 혹은 배울수 있는 리더가 있어야 가능합니다.

요즘은 큰회사에서도 팀별로 혹은 조직별로 채용 프로세스를 다르게 가져가는 경우도 있다고 합니다. 채용 프로세스를 보면 그 팀(혹은 조직)을 가늠해 볼수 있기도 한것 같습니다.

제 결론은 조직을 바꾸려 하는 것은 (그것도 매니져급이 아닌 상태에서) 하책이요, 좋은 조직에서 성장하는 기회를 만드는 것이 상책이라고 생각합니다.

감사합니다.

--
이 메일은 Google 그룹스 'xper' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 xper+uns...@googlegroups.com에 이메일을 보내세요.
웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/xper/7544344c-0e1f-4e85-860d-00b42f19f679n%40googlegroups.com을(를) 방문하세요.

--

Chungha Yun
blog : http://sozu.tistory.com

[정수 박]

흥미로운 생각 거리를 남겨주셔서 감사합니다.

 

---

 

저도 처음 애자일 공부를 시작했던 때가 2007년쯤이었던 것 같은데, 그때 이렇게 말했던 기억이 납니다.

 

"애자일을 도입하기 위해, 팀원들에게 페어 프로그래밍을 하라고 하고, 데일리 미팅을 하는데, 잘 동작하지 않는 느낌이었어요.

그런데 Jenkins로 자동 빌드 시스템을 구축해서, 사람들이 커밋하면 자동으로 빌드가 되어 나오는 환경을 구축했는데, 그게 느낌이 좋았어요. 사람들 개입 안해도 나 혼자 시스템 구축하면 되니까 진척도 빨리 되는 것 같고요. 뭔가 시스템이 맞물려 돌아가는 느낌이 드니까 제대로 되는 느낌도 들고, 그 효과를 팀원들도 쉽게 향유할 수 있는 것 같고요.

그래서, 애자일 도입할 때, 이런, 시스템 도입을 먼저 하는게 더 매끄러운 것 같아요.”

 

기억은 잘 나지 않지만, 그 분이 ‘정말 그렇게 생각하세요?’라는 느낌으로 저를 쳐다보셨던 어렴풋한 기억이 나네요.

 

지금 돌이켜 생각하면 완전히 거꾸로 된 생각이었어요.

 

사람이 개입되지 않으니까 뭔가 추진하기 쉬운 느낌이 들었을 것 같습니다. 반대로 사람이 개입되면, 문제가 더 복잡해지고, 다루기도 어려워지겠죠. 하지만 프로젝트 성공, 팀 운영을 위해서는 ‘사람이 개입되는 활동’이 더 중요한 것 같습니다. 결국은 그런 시스템들을 활용해서 소프트웨어를 만드는 최종적인건 사람이니까요. 더 중요하고 어려운걸 하느냐, 덜 (또는 전혀?) 중요하고 쉬운걸 하느냐의 차이라고 볼 수 있을까요?

 

---

 

그 후 계속 10여년동안 애자일의 관점으로 여러 팀이나 조직을 바라보면서, 때로는 그곳에 애자일 철학을 심으려고 노력해오면서, 저도 용민님이 말씀하신대로 ‘가치’와 ‘원칙’의 중요성을 계속 깨달아오고 있습니다. 저보다 더 일찍 깨달으신 셈이네요.

 

그 과정에서, 가치와 원칙이 우선되지 않고 실천방법만 도입되었을 때 나타나는 부작용들을 많이 봤던 기억이 납니다. 일례로 이런 것들이죠.

 

• 데일리 미팅이 엄청나게 길다. 30분~1시간. 끝나면 사람들이 지쳐한다.
• 데일리 미팅이 일일 보고하는 느낌이다. 각 사람이 돌아가면서 어제 한 일, 오늘 할 일을 말하면, 팀장이 하나씩 코멘트한다. 다음 사람이 공유하면, 팀장이 또 그 사람이 한 일, 할 일에 대해 코멘트하고. 반면에 팀원들간의 대화는 거의 없다. 재미있는 점은, 참여하는 사람들의 시선이, 발표하는 사람에게 향했다가, 팀장에게 향했다가, 다음 발표자에게 향했다가, 다시 팀장에게 향했다가. 서로간의 시선은 별로 없다. 역시 끝나면 사람들이 지쳐하고, 끝나고 나서 서로간의 대화는 별로 없다.
• 데일리 미팅이 엄청나게 짧다. 각 사람이 두루뭉술하게 한두마디씩 하고  끝난다. (어제는 결제모듈 작업했고요, 오늘도 계속 작업할 예정입니다. 끝.) 미팅 중간, 미팅 후에 서로간의 대화도 거의 없다.
• 팀장이 “데일리 미팅합시다”라고 얘기하지 않으면 데일리 미팅이 열리지 않는다. 혹시라도 팀장이 바빠서 잊거나 부재시에는 역시나 열리지 않는다. 데일리 미팅 열리는 시간도 들쭉날쭉하다. 대략의 시각은 정해져 있지만, 팀장이 ‘아, 맞다. 데일리 미팅 합시다’고 하면 그때 열린다. ‘오늘은 데일리 안하나요?’라고 묻는 팀원도 없다.

 

데일리 미팅을 함으로써 뭘 달성하고자 하는 것인지, 애자일스러운 데일리 미팅은 일일 보고와 어떻게 다른지 깊이 생각하지 않고, 실천방법으로서 도입하면 발생하는 현상들인 것 같습니다. (모두 제 팀에서, 혹은 다른 팀에서 목격한 것들입니다.)

 

---

 

이번에 익스트림 프로그래밍을 읽으면서는 새롭게 ‘원칙’이 왜 중요한가도 눈에 들어왔는데요.

 

‘가치’라는건 너무 추상적이기도 하고, 너무 당연하기도 합니다. ‘존중’, ‘의사소통’, ‘단순성’, ‘피드백’, ‘용기’. 다 중요한 것들이고, 이것들이 중요하지 않다고 말할 팀장-임원은 별로 없을겁니다. 그런데 문제는, ‘의사소통’이 중요하다고 하는데, 어떤 종류의 의사소통이냐, 그걸 어떻게 이룰 것이냐의 각론에 들어가면 또 각자의 생각이 너무 다른 경우가 있습니다.

 

익스트림 프로그래밍 책에서도 원칙에 대해 설명하면서 든 예가, 의사소통이 중요한 가치라고 하는 경우에도, 긴 문서를 만드는 것도 의사소통을 위해서이고, 매일 나누는 대화 역시 의사소통을 위해서라고 할 수 있습니다. 기획안을 만드는데, 그 결과물을 길고 꼼꼼한 문서로 만드는 것이 낫느냐, 대략적인 개요 정도만 정리하고, 구체적인건 논의하면서 진행하는게 낫느냐 하는 점에서는 의견이 갈릴 수 있는데, 그 때 판단의 기준이 되는게 원칙이라는 말을 합니다.

 

피드백의 경우에도, 경험이 생각나는데, 직원들에게 피드백을 하는 것이 중요하니, ‘인사평가 제도를 도입하고, 그것을 인센티브 및 인사고과에 반영하자’라는 논의가 나왔었어요. 같은 ‘피드백’이라는 가치가 중요하다고 말하는 것인데도 생각의 방향이 너무 다르구나 하는걸 느꼈습니다.

 

‘애자일은 빨리 실행해보고 그걸 수정/개선해서 다시 하는걸 반복하는거 아니야?’라고 하는 경우도 많은데, 실제 일어나는 일들은 뭔가 애자일과 안맞는 것 같은 느낌(빠른 워터폴?)이 드는 경우도 많고요.

 

그래서, ‘가치’만으로는 또 뭔가 부족하고, 그걸 더 지지해주는 기둥이 필요하다는 느낌이 있었는데, 켄트 백이 ‘원칙’을 말하면서 그런걸 말하고자 했던게 아닌지 하는 생각을 하고 있습니다 .

 

---

 

요즘 스크럼이 스타트업에 유행처럼 쓰이는 것 같은데, 정작 스크럼의 핵심 가치가 무엇인지, 그 guiding principle이 무엇인지 아는 사람, 그리고 그것을 신경쓰는 사람은 너무 적지 않은가 하는 생각도 많이 듭니다. 그냥 실천방법들만 하는 경우가 많지 않나 싶습니다. 스크럼은, 실천방법이 구체적으로 미리 정해져 있어서 더 그런 것 같습니다.

 

Q. ‘스크럼이 뭐예요?’

A. ‘아, 스크럼은요, 백로그 만들고요, 스프린트를 2-3주 정도로 정해서, 스프린트에서 뭐할지 플래닝 미팅에서 정하고요, 그 다음에는 스프린트를 달리면서 데일리 미팅하고요. 끝나면 회고하고, 그거 반복하는거예요.’

라고 답하기에 너무 좋은거죠.

반면에 XP는 뭐라고 딱 찝어서 얘기하기가 애매하고요.

 

그래서 스크럼이, 도입하기는 좋으면서도, 잘 되지 않기 쉬운 방법론이 아닌가 하는 생각이 듭니다.

 

 

Sent from Mail for Windows 10

--

[imy...@gmail.com]

안녕하세요. @Chungha Yun님.
경험에서 우러러 나오는 경험들과 조언을 공유해주셔서 감사합니다.

말씀 주신 내용을 보니 XP 가치를 진정으로 공감할 수 있는 동료, 더 나아가 팀과 리더가 주변에 있다면 행복할 것 같아요. 좋은 성장을 위한 피드백을 받을 수 있도록 노력해야겠네요.
본문에는 적지 못했는데 제가 가지고 있던 고민 중 하나가 '잘하는 것이란 무엇인가?', '어떻게 잘 할 수 있는가?' 였어요.
실력을 키워야 한다는 것은 알고 있는데 어떻게 하면 실력을 키울 수 있을지 항상 고민 되었는데 새로운 방법을 하나 알게되었네요. ㅎㅎ
특히, 머신 없이 코딩 한다는 것을 생각하지 못했었는데, 현재 제 상황에서 큰 도움이 될 것 같습니다. 간단한 알고리즘 문제부터 손 코딩, 뇌 컴파일, 눈 디버깅을 시도해 봐야겠네요.

그런데 생각해보니 눈 디버깅과 유사한? 활동을 하고 있는 것 같아요. TDD를 하다 보면 자연스레 디버거를 사용하는 빈도가 줄어들고 테스트 코드부터 시작해 눈 디버깅을 하게 되더라고요. ㅎㅎ
말씀 주신 내용을 토대로 앞으로 나아가보겠습니다. 감사합니다.

2020년 8월 26일 수요일 오전 4시 8분 14초 UTC+9에 Chungha Yun님이 작성:

[imy...@gmail.com]

안녕하세요. 박정수님.
좋은 생각 공유해 주셔서 정말 감사드립니다.

실제 경험을 예시로 말씀해 주셔서 이해가 잘 되었고 XP에 대해 더 깊은 생각을 하게 되었어요.
특히, 적어주신 데일리 미팅 예시는 현재 제가 경험하고 있는 상황과 유사해서 굉장히 공감되네요.
빠른 워터폴이라는 단어도 그렇고요. 업무 공유의 시간을 갖지만 각자 할 이야기만 하게 되어 다른 사람이 말할 때 모니터만 보게 되는 상황이 발생하는 것 같더라고요.
어떻게 하면 더 나은 미팅을 만들지도 고민해 봐야겠네요.

가치라는 것이 추상적이어서 같은 가치를 추구하여도 모두가 같은 방향을 가리키지 않을 수 있다는 것도 알게되었고...
잠깐 놓치고 있던 원칙의 중요성도 다시금 생각해보게 되었습니다.

XP와 관련되어 이런 소중한 견해를 들을 수 있어 감사하고 행복하네요.
일단, 저는 말씀해주신 내용을 토대로 현실에서 더 부딪혀 봐야 할 것 같습니다. ㅎㅎ
감사합니다!

2020년 8월 26일 수요일 오후 12시 58분 49초 UTC+9에 tor...@gmail.com님이 작성:

[정수 박]

업무 공유 시간에 각자 할 이야기만 하고, 심지어 모니터만 보게 되는 (무관심한) 상황이 발생할 때, ‘왜 다른 사람 업무에 관심을 갖지 않느냐’라고 각 개인을 다그칠 수도 있겠고, ‘사람들이 자꾸 이렇게 행동하는데는 뭔가 근본적인 원인이 있지 않을까?’라고 생각해볼 수도 있겠지요.

 

제 생각에는, 지금 조직이 ‘팀’인지 ‘워크 그룹’인지 한번 고민해보면 좋을 것 같습니다.

서로간의 업무가 별로 연관성이 없어서, 다른 사람 이야기 들어봐야 맥락도 잘 모르겠고, 나랑 별로 맞닿는 부분도 없으면, 자연스레 무관심하게 될 것 같습니다.

서로간의 업무가 연관성을 가지도록 하면, 자연스레 ‘백엔드를 저렇게 짜놓으면 나중에 내가 프론트 붙일 때 이런 문제가 생길텐데…?’ 처럼, 서로의 일이 나와 관계가 있게 되기 때문에 정보 공유가 조금 더 의미 있게 되지 않을까 싶습니다.

쓰다 보니, 애초에 ‘서로 간의 정보 공유가 필요한 상황인가?’, ‘정보 공유를 하면 각자에게 도움이 되는가?’라는 부분을 질문해봐도 좋을 것 같다는 생각이 드네요. 애초에 왜 정보를 공유하고자 했는지, 발단이 뭐였는지.

이런 상황에서는, 자연스레 각 팀원끼리는 별로 관심이 없고, 팀장만 각각의 팀원과 이야기하게 되는 상황으로 흘러가게 될 것 같습니다.

 

그리고, ‘어떻게 더 나은 미팅을 만들지’라고 하셔서 생각이 든건, 미팅은 ‘정보 공유’ - 가치의 단어로 말하자면 ‘의사소통’일텐데, 꼭 미팅 안에서의 의사소통만 생각할 필요는 없을 것 같습니다. 그런 액티비티에서 일어나는 상황들은, 평소의 상황들의 연장일 수 있을 것 같거든요.

평소에 일할 때 팀이 거의 의사소통이 없이 조용한 사무실이었다면, 미팅때도 비슷한 패턴이 나올 수 있을 것 같습니다. 반대로 말하면, 미팅을 활기차게 만들기 위해서, 평소에 작은 의사소통들이 일어나도록 하면 뭔가 달라지지 않을까 하는 생각이 드네요.

 

10년도 더 전에, 제가 첫번째 회사에 다닐 때, 개발팀 구성원들은 모두 병역특례로 근무하는 사람들이었고, 그래서 비슷한 나이 또래의 젊은 친구들이었어요. 애자일 같은건 명시적으로 하지도 않았고, 아무런 애자일 프랙티스도 하지 않았지만, 뭔가 자기가 코딩하다가 잘 안풀릴 때, 옆 사람 붙잡고, ‘잠깐 이것 좀 같이 봐줄래? 아, 진짜 안풀리네’라고 물어보는게 일상적이고 자연스러웠어요. 이를테면 ‘의사소통’이라는 가치가 잘 정착되어 있었기 때문에, XP 프랙티스는 하나도 하지 않았지만, 페어 프로그래밍이라는게, 그냥 ‘물어보고 같이 봐준다’라는, 일상적인 행동으로 나타나고 있었던 것 같습니다.

 

그런 점을 떠올려 볼 때, 평소에 동료에게, ‘이것 좀 한번 같이 봐줄 수 있어요?’라고 부탁하면서 업무의 오버랩을 만든다던지 하는, 작은 일상 안에서 바탕을 만들어가는 것도 도움이 되지 않을까 싶습니다.

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/xper/64896717-984d-46bc-89d2-ed458601be22n%40googlegroups.com을(를) 방문하세요.

 

[Klaus Youm]

안녕하세요, 임용민 님.

20년 8월에 xper 메일링 그룹으로 보낸 메일에, 한참동안 플래그해두었다가 이제야 회신을 하네요.

저는 xper로서 살아간지(?) 19년 정도 되어가네요. 대학교 다닐 때에 친구와 함께 TDD + 페어프로그래밍하면서, XP에 관심을 갖게 되었고, 영민 님과 비슷하게 사내에서 XP, TDD에 대한 발표를 했었네요. 이 부분이 참 비슷해서, 이렇게 메일을 쓰고 있나봅니다. :)

그러한 저의 가치는 계속 발전해서, Agile development, 비폭력대화, Agile organization 등으로 관심사가 계속 성장 하더라고요.

보내주신 메일을 보니, XP의 가치는 충분히 체득하신 거 같네요. :) 비록 내 주변의 환경이 그 가치를 모르거나 잘 몰라주지만, 그러한 가치를 추구하는 행동을 지속하면, 적어도 자신의 주변은 조금씩 변하는 것을 느끼셨으면 좋겠습니다.

XP, Agile 관련된 책들도 이미 많이 보고 공부하실 거 같은데요. "소프트웨어장인"이라는 책도 추천드립니다. 나중에 Agile 관련 meetup이나 컨퍼런스에서 만나서, 더 많은 대화를 나눌 수 있는 기회가 있으면 좋겠네요.

항상 건강하시고, 즐거운 하루를 보내세요.

감사합니다.

2020년 8월 25일 (화) 오후 10:14, imy...@gmail.com <imy...@gmail.com>님이 작성: