2장. 애자일 2001년, 소프트웨어 업계 모임에서 익스트림 프로그래밍, 스크럼, 동적 시스템 개발 모델, 적응형 소프트웨어 개발, 피처-드리븐 개발, 실용주의 프로그래밍과 같은 방법론과 테크닉들이 발표되었다. 긴 토론 끝에 애자일 매니페스토가 창안되었고 애자일 연합이 만들어졌다. 애자일은 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합이다. 애자일은 개발팀과 기업들이 변화에 적응할 수 있도록, 변화와 관련된 위험들을 줄여준다.

절차적인 관점에서의 애자일 (올바른 목표를 향해 진행 중인지) 회의 방식 구성원 각각의 역할 요구사항 파악 방법 작업의 진척 속도 파악 방법 점진적/반복적으로 일할 때 취하는 방식 진행 상황을 개발팀 밖의 관계자(고객, 영업 등)에게 전달하는 방식 비즈니스 피드백 방식 등 기술적인 관점에서의 애자일 (목표를 올바르게 실행하고 있는지) TDD 페어 프로그래밍 지속적인 통합 단순한 디자인 원칙 등 애자일을 따른다는 것 애자일은 피드백 루프 메커니즘을 제공해준다. 더 빨리, 더 짧게 피드백 루프를 만들수록 더 애자일 해진다. 애자일이 피드백 루프를 짧게 하고, 프로젝트의 상황을 투명하게 만드는 데는 긍정적이지만, 개발자들을 성장시키는 데는 도움이 되지 않는다. 애자일은 문제 자체를 해결해주지는 않는다. 애자일은 문제를 드러나게 한다. 프로젝트 시작 첫 주부터 ‘동작하는 소프트웨어’를 만든다. 소프트웨어 개발팀은 수평적인 계층구조로 바뀌고 있다. 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 여건이다. 이밖에도 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 외향적인 성격이 요구된다. 애자일 매니페스토 우리는 스스로 소프트웨어를 개발하고, 다른 사람들이 개발하는 것을 도와주면서 더 나은 소프트웨어 개발 방법들을 찾고 있다. 이 과정에서 우리는 다음과 같은 가치를 중요하게 생각한다.

절차와 도구보다는 개성과 화합을 방대한 문서 작업보다는 동작하는 소프트웨어를 계약 조건에 대한 협상보다는 고객과의 협력을 계획을 따르는 것을 넘어서서 변화에 대처하는 것을 더 가치 있게 여긴다. 좌측의 사항도 가치가 있음을 인정하지만, 우리는 우측의 사항에 더 높은 가치를 둔다는 것이다.

애자일 매니페스토의 12가지 원칙 가치 있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달 주기를 짧게 한다. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주 보고 대화하는 것이다. 프로젝트의 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다. 기술적인 탁월함과 좋은 설계에 대한 지속적인 관심은 기민함을 높인다. 단순함, 즉 하지 않아도 될 일은 최대한 하지 않아야 한다. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다. 애자일 행오버 애자일 전환은 온통 절차와 도구로 끝나 버린다. 스크럼을 도입하고, 스탠딩 업 미팅을 하고, 백로그 관리 툴을 사용하는 것만으로 갑자기 소프트웨어의 품질이 더 좋아지거나 개발자들의 역량이 높아질 수는 없다. 기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

대부분의 애자일 전환 프로젝트들은 부분적으로만 전환하는 문제를 안고 있었다. 개발 절차를 바꾸는 데는 도움을 받지만, 더 높은 품질의 소프트웨어를 작성하는 데는 거의 도움이 안 되고 있다. 애자일의 모든 절차에는 기술적 탁월함이 전제되어 있다.

애자일과 소프트웨어 장인정신 소프트웨어 장인정신과 애자일은 서로 상호 보완적이다. 애자일 방법론들은 ‘올바른 일’을 하도록 돕는 것이다. 가치에 따라서 일을 이해하고, 우선순위를 정하고, 관료주의와 낭비를 줄이고, 사람들에게 권한 이양과 동기부여를 하고, 피드백 루프를 만들어준다. 그리고 소프트웨어 장인정신은 ‘일을 올바르게 수행’하도록 돕는 것이다. 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다.

3장. 소프트웨어 장인정신 소프트웨어 장인정신은 마스터가 되어가는 긴 여정이다. 한마디로 ‘소프트웨어 개발의 프로페셔널리즘’이다.

소프트웨어 장인정신 매니페스토 소프트웨어 장인을 열망하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다. 이러한 일을 하는 과정에서 우리는 다음과 같은 가치를 추구한다.

동작하는 소포트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을, 변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을, 개발적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을, 고객과 협업하는 것뿐만 아니라, 생상적인 동반자 관계를, 이 왼쪽의 항목들을 추구하는 과정에서, 오른쪽 항목들이 꼭 필요함을 의미한다.

4장. 소프트웨어 장인의 태도 내 커리어의 주인은 누구인가 오래전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면, 그것은 그동안 배운 것이 없다는 뜻이다. 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다. 언제, 무엇을 배울지를 스스로 결정해야 한다.

끊임없는 자기 계발 1) 독서, 많은 독서

특정 기술 서적 : 자바, 하이버네이트, Node.js, 클로저 특정 개념 서적 : TDD, 도메인 기반 개발, 객체 지향 설계, 함수형 프로그래밍, NoSQL DB 모델 행동양식 서적 : 애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 철학, 경영 혁명적 서적 : 실용주의 프로그래머, The Mythical Man-Month, 디자인 패턴(Gof), 테스트 주도 개발, 익스트림 프로그래밍, 클린 코더, 소프트웨어 장인정신, 리팩터링 2) 블로그

3) 기술 웹사이트

끊임없는 훈련 훈련할 때는 작성 가능한 최선의 코드를 만드는 데 집중해야 한다. 테스트 하나를 만드는 데 몇 분이 걸리든 몇 시간이 걸리든 관계없다. 시간은 걱정하지 말고 변수, 메서드, 클래스들의 이름을 가장 이해하기 쉽고 의미를 포괄할 수 있도록 최선을 다해 네이밍 한다. 훈련할 때는 그 훈련이 완벽하도록 노력해야 한다.

1) 카타 : 이해는 쉽지만 해결하기에는 꽤 복잡한 문제들을 새로운 테크닉과 접근방법을 훈련하는데 활용할 수 있다. 같은 코딩 카타를 반복하더라도 매번 다른 테크닉, 다른 언어, 다른 기술, 다른 접근 방법을 사용해야 효과를 최대화할 수 있다. http://codekata.pragprog.com/

2) 펫 프로젝트 : 먼저 무엇을 배울지, 즉 어떤 실행 관례, 실행 원칙, 방법론, 기술을 배울지 정하고 그다음에 그것을 이용해서 해결할 문제를 찾는다. 매우 안전한 환경에서 시험하고, 발견하고, 배우고, 즐길 수 있는 기회를 만든다. 실제 프로젝트의 몇 가지 측면을 미리 경험할 수 있다는 점에서도 중요하다.

3) 오픈 소스 : 배우고 싶은 내용과 연관 있는 것을 찾는다. 그다음에 소스 코드를 내려받아, 실행해보고, 테스트 코드가 있다면 읽어본다. 디버깅해보고, 이용해 본다. 기여할 부분이 보인다면 작은 것부터 시작하자.

4) 페어 프로그래밍 : 페어 프로그래밍을 이용하면 새로운 내용을 빨리 배울 수 있다. 나 자신의 실제 역량을 파악하는 기회도 된다.

의도한 발견 소프트웨어 프로페셔널이 할 수 있는 최대의 실수는 자신이 모르는 것을 모른다고 받아들이지 않는 것이다. 아직 배울 내용이 많음을 인정하는 것은 성숙하다는 증거이고 마스터가 되기 위한 첫걸음이다.

보통 일의 예측했던 작업량보다, 실제로 소요된 작업량이 훨씬 많을 것이다. 이러한 문제의 영향을 최소화하는 한 가지 방법은 현재 처한 상황과 관련해 새로운 사실들을 계속 익히도록 스스로를 노출시키는 것이다. 특히 프로젝트 초반, 주요한 기능 모듈들이 아직 만들어지기 전 시점에 매우 중요하다. 생각 가능한 모든 측면에서 우리가 파악하지 못한 것을 찾아내기 위해 시간을 투자해야 한다. 모르는 것을 배우는 기회로 만들기 위해 항상 노력해야 한다. 무지에 대항하는 습관을 들이면 프로페셔널로 성장하는 데 큰 도움이 된다. 무지의 수준을 최대한 빨리 낮추면 낮출수록 업무 생산성과 효율이 매우 높아진다.

모르는 것을 배우는 기회로 만들기 위해 항상 노력해야 한다. 무엇을 모르는지를 모른다면, 최신 동향을 따라가기 위해 동료는 어떤 노력을 하고 있는지 물어보거나, 기술 커뮤니티에 참여하거나, 다른 사람에게 내가 작성한 코드를 보여주면서 피드백을 요청하자. 프로젝트에서 시도하지 않은 부분이 무엇인지 찾아보고 동료와 토론하거나 시험용 코드를 만들어보자.

5장. 영웅, 선의 그리고 프로페셔널리즘 ‘아니오’라고 말하는 방법 배우기 빠듯한 일정과 부딪혀야 하는 상황은 흔히 일어난다. 빡빡한 일정을 다루는 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다. 불명확하거나 불편한 사실들, 걱정되는 사항들을 최대한 이른 시점에 문제 제기해야 한다. 가장 중요한 것은, 주어진 일정을 준수할 수 있을지에 대해 어느 정도 자신감을 가지고 있는지 꾸준히 표명해야 한다는 점이다.

개발자들이 일정이 너무 짧다고 이야기를 해도 관리자들이 그냥 흘려들을 때가 많다. 차드 파울러는 그저 실망시키지 않기 위해 말하는 ‘네’는 거짓말에 지나지 않는다고 했다. 개발자들은 협상 기술을 익혀야 한다. 다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다.

대안 제시 항상 ‘아니오’라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 ‘아니오’에는 반드시 하나 이상의 대안들이 따라와야 한다. ‘아니오’라고 대답하기 전에 문제를 분석해서 대안이 있어야 한다. 실용적인 대안이 없을 경우, 최소한 브레인스토밍은 해보아야 한다.

어떤 때는 단지 문제를 어떻게 풀어야 할지 방법을 모를 수도 있다. 이때는 최대한 이른 시점에 그 사실을 정직하게 알려야 한다. 그리고 문제 해결을 위해서 최선의 노력을 다하고 있음을 보여주어야 한다. 진척 상황을 가능한 자주 공유하는 것이 할 수 있는 최선의 방법이다.

6장. 동작하는 소프트웨어 기능을 수정하거나 새로 추가할 때, 코드 베이스에 너무 많은 시간을 들여야 한다면, 개발자들이 기존 코드에 손을 대는 것을 두려워한다면 지체 없이 대응해야 한다. 디버깅 스킬이 중요하기는 하지만, 자동화된 테스트를 만들고 활용하는 데 능숙한 개발자라면 코드 디버깅을 해야 하는 상황이 매우 드물다. 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다. 테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다. 레거시 코드를 다룰 때는 보이스카웃 규칙 ‘처음 발견했을 때보다 더 깨끗하게’를 지속적으로 적용해야 한다. 작은 부분씩 집중해서 한 번에 하나씩 이해해 나간다면 조금씩 개선 가능하다. 테스트 코드를 작성하고 메서드와 클래스를 정리하며 변수명을 적합하게 바꾸는 등 점차적으로 코드에 대한 이해도를 높이고 리팩터링을 해나간다. 레거시 코드를 다루는 것은 직소 퍼즐을 맞추는 것과 비슷하다. 무언가 마음에 들지 않는다면 바꾸어라. 그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라. - 마리 엥겔브레이트 7장. 기술적 실행 관례 올바른 일 vs. 올바른 실행 애자일 방법론은 빠르고 짧은 피드백 루프를 제공하여 ‘올바른 일’을 실행하고 있는지 점검하도록 도와준다. 이러한 실행 관례와 활동들이 애플리케이션의 품질 상태가 어떠한지는 알려주지 않기 때문에 이 부분에서 문제가 된다. 일을 올바르게 제대로 수행하고 있다는 것은 어떻게 알 수 있을까?

소프트웨어 장인정신은 기술적 실행 관례에 집중함으로써 코드의 품질에 대한 빠르고 짧은 피드백 루프를 제공해 애자일을 보완하는 효과가 있다. 기술적 실행 관례들은 우리가 일을 ‘올바르게’ 하고 있는지 알 수 있게 해 준다.

소프트웨어 장인정신은 좀 더 프로페셔널한 태도를 북돋우는 것과 더불어 XP의 실행 관례들을 활용하도록 한다. XP 실행 관례에는 TDD, 페어 프로그래밍, 리팩터링, 단순한 디자인, 지속적인 통합 등이 있다.

XP의 실행 관례들 1) 자동화된 테스트 : 클릭 한 번으로 전체 시스템을 단 몇 분 만에 검증할 수 있게 해 준다.

2) 테스트 먼저 : 한 번에 하나씩만 집중할 수 있고 코드 작성 완료 후 강하게 확신할 수 있다. 테스트 코드가 준비되어 있으면 피드백 루프가 빨라지고, 오버 엔지니어링을 줄인다.

3) 테스트 주도 개발 : 가장 큰 오해가 TDD와 단위 테스트를 동일하게 생각하는 것이다. TDD는 테스트 단위가 어느 정도로 작아야 하는지 강제하지 않는다. TDD의 이름 자체에 테스트가 들어 있기는 하지만, 사실 TDD는 설계에 대한 실행 관례다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다.

4) 지속 가능한 통합 : 지속적인 통합은 TDD와 함께 수행되어 피드백 루프를 단 몇 분으로 줄일 수 있다. 개발자가 코드를 올릴 때마다 전체 테스트 슈트가 실행되고 테스트가 실패하면 이메일이 모든 팀에 전달된다. 이러한 실행 관례는 ‘일단 멈추고 버그부터 수정한다’는 태도가 필요하다.

5) 페어 프로그래밍 : 페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다. 같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다.

6) 리팩터링 : 실용주의적인 관념 없이 리팩터링 하는 것은 대단히 위험하다. 몇 년 동안 바뀐 적이 없는 부분을 리팩터링 하는 것은 의미가 없다. 리팩터링은 더 자주 변경되는 부분을 대상으로 시작해야 한다. 보이스카웃 규칙은 모든 것이 아니라, 해당 부분을 이해하여 변경할 필요가 있을 때 적용해야 한다.

실용주의 무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다. 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다. 지금 하는 방법보다 더 나은 다른 방법이 없는가? 우리가 선택한 실행 관례가 우리 프로젝트에 적합한가? 그 실행 관례의 가치는 무엇인가? 무언가 다른 것을 시도해볼 시점인가?

어떤 실행 관례가 다른 실행 관례보다 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해보는 것이다. 기억해야 할 것은 꼭 이렇게 해야만 한다라는 법은 없다는 점이다. 특정 실행 관례가 더 이상 우리에게 가치를 주지 못한다면 그 실행 관례를 버려야 한다. 소프트웨어 장인으로서, 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행 관례를 선택할 수 있도록 개방적인 사고방식을 가져야 한다.

8장. 길고 긴 여정 결단과 집중 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 예를 들어 새로운 프로그래밍 언어나 기술들을 배운다. 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다. 다른 개발자, 비즈니스맨들과 교류한다. 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다. 오픈 소스 프로젝트에 참여한다. 프로젝트를 만들고 공개한다. 콘퍼런스에 참석한다. 콘퍼런스에서 연사로 나선다.

출처 : [https://devpad.tistory.com/11?category=773728]