애자일 소프트웨어 개발

아무리 멀리 갔을지라도 잘못된 길이라면, 돌아오라. - 터키속담.

• 일시적이 아닌 지속적인 개발
• 에너지를 주입하라
• 애자일 실천방법 - 고도의 협력적인 환경에서 지속적인 조정을 위해 피드백을 사용한다.

애자일 시작하기

결과를 위해 일하라

비난은 버그를 수정하지 못한다.

손가락질하고 누구를 비난할지 토의하는 일은 생산적이지 못하다. ‘좋아, 내가 뭘 도와줄까?’. 문제를 해결하라고 노력하라.

땜질은 늪을 만든다

땜질식 수정에 빠지지 말라

땜질식 수정은 결국에는 프로젝트의 생명을 위협하는 늪을 조금씩 넓힌다. 증상이 아니라 문제를 고쳐라.

• 지뢰를 조심하라 : 진짜 문제를 해결하지 못한 어설픈 수정이 문제다.
• 따로 코딩하지 말라 : 팀원들이 자신의 동료가 작성한 코드를 보는 시간을 갖아라.
• 단위 테스트를 사용하라 : 단위테스트는 실행가능한 문서의 일종이다.

사람이 아니라 생각을 비판하라

사람이 아니라 아이디어를 비평하라

관심사를 말하기 위해 동료에게 질문하라. 의견을 말하지 못하게 하는 분위기는 좋지 않다. 부정적인 생각은 혁신을 죽인다.

• 마감을 정하라 : 확고한 마감은 소모적 이데올로기 논쟁에 매달리지 않게 한다.
• 상대방과 논의하라 : 장단점을 비교하고 장점이 많고 단점이 적은 해결책을 고른다.
• 중재자를 둬라.
• 결정을 지원하라.

위험을 무릅쓰고, 앞으로 나아가라

올바른 일을 하라

맡은 코드가 엿같다면, 불평대신에 바꾸었을때의 장단점을 상사에게 말해 올바른 해결책에 도달하도록 이유를 제시하라. 쟁점에 대해 감정을 제거하고 문제해결에 고민해서 동료에게 솔직히 고백하라. 고객이나 상사에게 용기를 내어 당신의 관점을 설명하라.

애자일 기르기

변화에 뒤처지지 말라

기술 변화를 따라 가라.

변화에 늘 대응하는것과 변화된것에 능숙해지는것은 다른이야기. 변화에 능숙해지는데는 많은 시간이 걸닌다. 변화에 대응을 하면, 능숙해져야하는 기술이 나타났을때 단숨에 많은 단계의 기술을 알필요가 없어 시간을 줄여 오히려 이익.

• 반복해서 조금씩 배우자 : 규칙적, 끊임없이.
• 최신소식을 얻자 : 웹/포럼토론/메일링리스트/블로그 …
• 지역 사용자 그룹에 참석하자
• 워크숍이나 학회에 참석하자
• 열심히 읽자

팀에 투자하라

여러분 자신과 팀에 대한 기대치를 높여라

팀이 교육이 잘된 팀이어야 효율이 오른다. 배운 내용을 공유하면 ‘사용하는 지식’이 되어 모두에게 좋다. 도시락회의를 해보도록 - [pok]는 이것이 ‘규칙적’이라는것과 ‘짧은시간’ 포함된 수단이기때문에 좋다고 생각한다. 도시락 회의든 뭐든간데, 규칙적이고 짧은 팀단위 교육은 좋다고 생각하다.

버려야 할 때가 언제인지 알자

새로운 기술을 배우고 예전 기술은 버려라

버리는 일의 첫단계 : 구식의 접근방식을 사용한다는 사실을 깨닫는것. 또한 오래된 습관에서 해방되는것.

이해할 때까지 질문하라

계속 왜냐고 물어보라

문제를 해결하기 위해서는 큰 그림을 보아야하고, 연관된 사람에게의 질문을 통해 좀더 쉽게 접근할 수 있다. 또한, 질문은 상대방의 생각을 정리하는데 도움을 줄 수 있다. ‘왜 그런가?’의 연속된 - 혹은 진실된, 마치 값진 보물을 캐는것 같은 - 질문을 통해 진짜 문제를 찾아낼 수 있다.

리듬을 느끼라

일이 쌓이기 전에 부딪쳐라.

타임박싱 : 연장할 수 없는 활동에 대해 확고하고 짧은 마감을 정하는것. 어떤 면에서 손해를 볼지 선택해야 하지만, 마감은 고정! 확고한 마감이 확고한 선택을 하게한다 - [pok]도 절대 동감. Feature Freeze 나 종료조건이 이 확고한 마감과 비슷한 개념일지도. 정해진 마감시간과 반복에 의한 마감성취는 리듬을 만든다. 리듬을 만드는 반복의 기간은 1주에서 4주정도가 적당. 역시 여기서도 규칙적이 중요한 요소.

사용자가 원하는 내용을 제공하기

적을 만나면 계획은 바뀐다. 여기서의 적은 변화이다. 상황이 바뀌었다면, 어제의 계획에 집착하지 말자. 성공적인 개발은 변화를 깨닫고 적응하는 능력에 달렸다.

고객이 결정하도록 하라

고객이 결정하도록 하라

결정하지 말아야 할 것을 결정하라 : 무엇이 자신의 권한 밖인지를 정하고 그 이슈를 사업주가 결정하도록 하라. 선택사항을 두어 고객이 결정하게 하고 변경에 드는 비용과 시간을 재협상 하라.

설계가 강요하는 대신 안내하도록 하라

좋은 설계는 지도다. 스스로 진화하게 하자.

어쨌든 예기치 못한 일들이 생긴다. 현재 시점에서 따라가는 설계는 요구사항에 대한 현재의 이해에 기초한다는것을 명심하라. 설계는 책임의 관점에서 논의하는것이 더 적절하다. 그런면에서 CRC카드설계는 좋은 지침이 된다.

• Class name : 클래스 이름
• Responsibilities : 클래스는 무슨 일을 해야 하는가
• Collaborators : 작업을 완료하기 위해서 어떤 다른 객체와 같이 작업하는가

코드를 릴리스할 수 있게 유지하라

프로젝트를 항상 릴리스 가능하게 하라

체크인한 코드는 항상 바로 쓸수 있어야한다. 자신이 만든 변경사항에 민감해야 하고, 자신이 시스템의 상태와 팀 전체의 생산성에 영향을 준다는 사실을 계속 명심해야 한다.

• 로컬 테스트를 실행하라.
• 최신 소스를 체크아웃하라
• 체크인 하라 지속적 통합시스템이 자동으로 문제를 지적하게 하라. 시스템에 코드를 브랜치 할 수 있지만 조심해서 해야한다.

일찍, 자주 통합하라

일찍, 자주 통합하라

통합하면서 격리할 수 있다. 모의객체를 사용해서 코드를 의존성에서 분리하여 통합전에 테스트할 수 있다. 격리해서 개발할때의 장점도 많다. 하지만 이것이 통합을 늦추라는 말은 아니다. 대규모 통합을 절대 받아들이지 말라.

배치를 일찍 자동화하라

시작부터 애플리케이션을 자동으로 배치하라

시스템 배치를 일찍 자동화해두면 프로젝트 생애동안 의존관계에 있는 변화를 따라가는 일이 더 쉬워진다.

데모를 사용하여 자주 피드백을 받으라

분명히 보이게 개발하라

요구사항은 잉크처럼 유동적이다. - [pok] 생각. 요구가 유동적이라는것과 마감을 확실히 해라가 서로 충돌되는 가치는 아닐까? 나는 아니라고 생각하다. 요구의 마감을 확실히 하고 그 요구사항이 최종 요구사항에 근접할때까지 주기적으로 요구를 수정하는것이 요구가 유동적이다라는 말의 의미인것 같다. - 요구의 올바른 이해를 위해 프로젝트 용어집을 만들어라. 데모를 보여주고 요구사항을 점검하고 필요한 변경내용을 평가하라. 그리고 이슈를 추적하자.

짧은 반복을 사용하여, 점진적으로 배포하라

점진적으로 개발하라

규모가 큰 프로젝트에 잰걸음으로 달려든다는 생각이 애자일 접근의 핵심이다. 작게 걸음을 떼야 균형을 유지하기 쉽다. - [pok] 생각. 이것이 변화에 대응해서 적응하라는것과 충돌이 나지는 않을까? 프로젝트 진행중에 큰 변화를 받아들이면, 큰 도약을 하게 되는것은 아닐까? - 기능추가마다 개발기간내에서 짧은 반복을 사용하여 반복적이고 점진적인 개발을 하라.

고정 가격은 깨진 약속이다

실제 일을 기초로 해서 견적하라

소프트웨어 프로젝트는 변덕스럽고 재생불가능한 본질때문에 미리 가격을 고정하는것은 깨질 약속이 될것이 뻔하다. 이러한 고객에게 몇가지 단계로 제안을 해보자.

• 초기에 작고 유용한 시스템 일부를 만드는 것을 제안하라.
• 첫번째 반복주기 마지막에 고객에게 진행할것인지, 말것인지 선택을 하게 하라.
• 이러한 반복마다 고객에게 선택을 할 수 있게 한다.

애자일 피드백

코드 베이스를 통제할 수 없게 되면 프로젝트는 곤란을 겪는다. 따라서 지속적인 모니터링이 필요하다.

수호천사를 곁에 두기

자동화된 단위테스트를 사용하라

컴파일 때마다 실행되는 로컬 단위테스트와 컴파일과 단위테스트를 실행하는 지속적인 빌드머신의 조합이 우리의 수호천사다. 무언가 고장나면 즉시 알 수 있다.

• 단위테스트로 즉각 피드백을 방는다.
• 단위테스트는 코드를 강건하게 한다.
• 단위테스트는 유용한 디자인 툴이 될 수 있다.
• 단위테스트는 자신감을 증진시킨다.
• 단위테스트는 프로브 역할을 할 수 있다.
• 단위테스트는 믿을만한 문서다.
• 단위테스트는 학습 도우미다.

만들기 전에 사용하라

만들기 전에 사용하라

코드를 작성하기 전에 사용하라. 테스트를 먼저 작성하면, 구현하는 사람의 관점이 아닌 사용자 관점에서 코드를 살필 수 있다. 이것을 통해 유용하고 일관된 인터페이스를 설계할 수 있다. 문제를 단순하게 하는 방향으로 실수를 하는것이 복잡화시키는 것보다 낫다.

차이는 다른 결과를 만든다

차이는 다른 결과를 만든다

플랫폼등의 차이가 다른 결과를 만들수 있기 때문에 이런 차이를 테스트해봐야 한다. 그리고 이러한 테스트에 들어가는 시간을 줄이기 위해 자동화하라.

인수 테스트를 자동화하라

핵심 비지니스 로직에 해당하는 테스트를 만들자

단위테스트와 별도로 고객이 기대하는 바와 같은지를 테스트하는 로직(데이타)의 인수테스트를 자동화하라.

실제 진척 상황을 측정하라

얼마나 많은 일이 남았는지 측정하라

진척상황을 잘 보이게 유지하는 가장 좋은 방법은 백로그를 남기는 방법이다. 백로그는 완료해야 하는 작업목록인데, 작업이 완료했을때 작업을 백로그에서 삭제한다. 새로운 작업들이 생기면 우선순위를 부여해 백로그에 추가한다. 백로그를 사용하면, 다음에 해야할 중요한일을 항상 알 수 있다.

사용자에게 귀를 기울이라

모든 불평은 진실을 담고 있다

받은 사용자 피드백에 귀를 기울여야한다.

애자일 코딩

의도적이고, 의미있게 프로그램하라

독창적이지 않고, 명확하게 코드를 작성하자

PIE 원칙 : 작성하는 코드는 의도를 명확히 전달하고, 반드시 의미가 있어야한다. 어떻게 하면, 읽기 쉽고 이해하기 쉬운 코드가 될 것이다. 코드가 혼란스럽지 않기 때문에, 점재적인 에러도 피할 것이다. 의도적이고, 의미있게 프로그램 하라( Program Intently and Expressively )

코드로 대화하기

이야기하는 주석

코드자체가 의미를 표현하게 하라. 숨기기 위해서 주석을 달지 말자. 이름을 부여하는 것은 중요하다.

능동적으로 트레이드오프 평가하기

능동적으로 트레이드오프를 평가하자

성능과 개발비용/시간 트레이드. - [pok] 생각. 고객이 서비스를 제공하는 경우게 하드웨어의 비용을 올려라고 요구할 수 있지만, 게임의 경우 고객에게 좋은 컴퓨터를 사라고 강요할수 있을까? 트레이드라는것은 한쪽을 포기한다는 것이지만 모두 윈윈할수는 없을까? 좀더 고민해볼만하다. 비록 책에서 최선의 해결책은 없다라고 말할 지라도…..

조금씩 코딩하기

짧은 수정/빌드/테스트 주기 안에서 코드를 작성하자

작성한 프로그램을 테스트해서 제대로 진행되는지 확인하며 코딩하라. 코드를 개량하고 구조화하는데 조금씩 코딩하기가 도움이 된다는 사실을 깨달아라. 지속적으로 평가하고 진짜 진짜 큰 수정 몇개를 하는대신에 자주 작은 수정을 하라. 작고 유용하게 유지하는 것이 애자일 접근 방식이다.

단순하게 유지하기

동작하는 가장 단순한 해결책을 만들자

특정한 문제에 코드를 과도하게 설계하고 복잡하게 만들지 않은지 생각하라. 잘 작동하는 단순한 디자인을 만드는 일에 자부심을 느껴라. 직관에 귀를 기울여라. 직관은 마술이 아니라 경험과 기술의 완성이다. 무언가가 괴롭히면 무엇이 잘못되었는지 이해하라.

응집도 높은 코드를 작성하라

클래스에 집중하고 컴포넌트를 작게 유지하라.

클래스를 만들려고 결심했을때, 이 클래스가 다른 클래스와 비슷하거나 밀접하게 관련되어 있는지 스스로 묻자. 단일 책임원칙에 따르면 모듈 변경에 대해서 단 한가지 이유만을 지녀야 한다.

묻지말고, 말하라

상황극. 신문배달 소년이 이번주 신문값을 요구한다. 여러분은 뒤돌아서서 신문배달 수년이 뒷주머리에서 지갑을 꺼내 2달러를 빼고, 다시 지급을 주머니에 넣게 한다. 그후 신문배달소년은 반짝이는 재규어를 몰고다닌다. - 책임을 잘못 정했을때는 이런 상황이 발생할지도.. 질문(쿼리)에서 명령을 분리해 두라. 쿼리는 부작용(아마 사이드이팩트)에서 자유로워야한다.

계약에 의해서 교체하기

코드를 교체해서 시스템을 확장하자

상속된 객체는 자요롭게 교체 가능해야한다. 인터페이스 계약을 존중하는 클래스를 교체해서 기능을 추가하거나 강화하자.

애자일 디버깅

해결책 로그를 기록하자

문제와 해결책의 로그를 보존하자

두번 불에 데지 않도록 발견한 해결책의 로그를 유지하자. 컴퓨터 검색이 가능한 형식으로 로그를 기록하고 공유하자.

경고는 진짜 에러다

경고를 에러처럼 다루자

경고를 에러로 잡고 불가피한 경고를 구체적으로 금지하자.

문제를 격리해서 공격하라

문제를 격리하기 위한 프로토타입을 만들어놓으면 문제를 고치는것은 더욱 쉽다. 많이 얽힌 컴포넌트라면 관심있는 코드를 떼 내고 작업할 시험대를 만들어 격리시키자.

모든 예외를 보고하라

모든 예외를 처리하거나 전달하라.

예외를 무시하거나 덮어두지말자. 코드가 실패할 수 있다고 생각하며 작성하자.

유용한 에러 메시지를 제공하라

문제를 찾고 해결하는것이 고통스럽다면 에러를 보고하는데 좀더 예방적인 접근이 필요하다는 신호다. 디버깅 정보는 중요하며 얻는 일도 쉽지 않다. 디버깅 정보를 버리지 말자.

애자일 협력

팀의 모든 사람의 행동은 프로젝트의 정황과 관련되어야 한다. 효과적인 협력은 애자일 개발의 초석이다.

정규 대면회의를 가져라

스탠드 업 미팅을 사용하자

스탠드 업 미팅은 회의를 짧게 유지시켜주며 많은 장점이 있다.

• 스탠드 업 미팅은 집중하는 방식으로 하루를 시작하게 한다.
• 개발자에게 어떤 문제가 있다면, 개발자는 이슈를 공공연하게 만들고 능동적으로 도움을 구할 기회를 얻는다.
• 스탠드 업 미팅은 추가적인 도움이 필요한 분야를 결정하고 팀 리더나 관리자가 인력을 얻거나 재할당하도록 한다.
• 스탠드 업 미팅은 프로젝트의 다른 분야에서 무엇이 진행되고 있는지 팀원이 인식하게 한다.
• 스탠드 업 미팅은 다른 사람이 해결책을 갖고 있는 분야나 중복을 재빨리 파악하도록 해준다.
• 스탠드 업 미팅은 코드와 아이디어 공유를 촉진해서 개발을 가속시킨다.
• 스탠드 업 미팅으 앞으로 나아가게 서로 북돋는다. 즉, 다른 사람이 진행 상황을 보고하는 것을 봄으로써 우리 각자가 같은 일을 하도록 동기를 부여한다.

아키텍트는 코드를 작성해야 한다

좋은 디자인은 활동적인 프로그래머로부터 진화한다

지도만 보고 수마일 떨어진 곳에서 전투를 지휘할 수는 없다. 적략적인 결정은 수마일 떨어진 곳에서 만들어져도, 전술상의 결정은 전투지역을 상당히 잘 이해해야한다.

공동 소유를 실천하라

코드 공동 소유를 강조하자.

작업마다 팀원을 순환시키면 팀의 전체적인 지식과 경험수준이 향상된다. 장기적으로 코드를 주시하는 다수의 시선을 붐으로써 코드 전체 품질이 향상되고 유지보수와 이해가 더 쉬워지며 에러를 줄일수 있다.

멘토가 되자

멘토가 되자.

아는것을 공유하는 즐거움을 누리자. 얻은만큼 베풀자. 더 나은 목표달성을 위해 다른 사람을 자극하자.

사람들이 알게 하라

다른 사람에게 문제를 해결할 기회를 주자

아리스토텔레스가 말하길, “교양있는 마음가짐의 표시는 하나의 생각을 받아들이지 않고도 그 생극을 즐길 수 있는 것이다``` 라 했다. 다른사람의 관점을 즐기자. 힌트를 주어 아이디어나 문제해결 방법을 들고오게 하자.

준비되었을 때만 코드를 공유하라

준비 되었을 때만 코드를 공유하라

다른 사람이 쓸 수 있도록 준비되지 않은 코드는 절대 체크인하지 마라.

코드 리뷰

모든 코드를 리뷰하자

작업이 끝내면 코드리뷰를 하자. pok 생각. 코드리뷰후에 새로운 ‘마감’이나 정책방향을 적절히 바꿀수도 있을것이다.

다른 사람에게 계속해서 알리기

다른 사람에게 계속해서 알리자.

해결못한게 있다면 알려서 그 해결책을 찾도록 그들에게 기회를 주어야 한다. 관리자가 무슨일이 일어나고 있는지 정확히 알도록 해야 한다.

에필로그 : 애자일로 이동하기

새로운 실천방법 하나

잘못된 대화에 대한 즉각적인 새로운 실천방법은 ‘스탠드업 미팅’이었다. 이러한 새로운(뭔가 기존과 구분이가는) 실천방법하나가 팀에 커다란 차이를 만들수 있다.

실패하는 프로젝트 구출하기

죽어가는 프로젝트를 환자에 비유해서 책의 컨설턴트는 일단 환자를 안심시킨다. <사람이 아니라="" 생각을="" 비판하라="">, <정규 대면회의를="" 가져라="">, <준비되었을 때만="" 코드를="" 공유하라="">, <다른 사람에게="" 계속해서="" 알리기=""> 등의 방법을 사용해서 대화와 협업 중심적인 방법을 실천한다. 그리고 간단한 릴리스 실천방법을 소개하고 유용한 코딩 실천방법을 시작했다고 한다.

애자일 도입하기 : 관리자 지침

관리자나 팀 리더라면 팀 전체를 하나로 모으는것부터 시작하라. 그리고 개발기반 환경을 도입하라. 중요한것은 팀원간의 협력이다. 팀에게 피드백을 받으며 고칠점을 고려하자.

애자일 도입하기 : 프로그래머 지침

이익이 명확하다면, 팀 동료는 여러분의 행동에 동참하길 원할것이다. 작은 실천방법부터 당장 시작하라.

끝?

http://www.pragmaticprogrammer.com 에서 자료를 찾을수 있다. 힘내시길.