이미 소장하고 있다면 판매해 보세요.
|
1부. 기민함 개선하기
1장. 애자일이란 무엇인가? __애자일의 탄생 __위기 속에서의 탄생 __애자일 개발 선언 __애자일의 정수 __애자일이 승리하는 이유 __애자일이 작동하는 이유 __애자일이 실패하는 이유 2장. 애자일하게 되는 방법 __애자일 연습하기 __마스터하기 위한 여정 __시작하기 3장. 기민함을 선택하라 __애자일 플루언시 모델 __영역을 선택하라 4장. 기민함에 투자하라 __학습 시간을 확보하라 __애자일 팀을 선택하거나 만들어라 __애자일 코치를 선택하라 __팀에 권한과 책임을 위임하라 __팀 매니지먼트 스타일을 바꿔라 __팀 룸을 만들어라 __팀별로 학습 친화적인 목적을 만들어라 __워터폴 거버넌스의 가정을 바꿔라 __해로운 인사 정책을 바꿔라 __보안 문제를 해결하라 5장. 변화에 투자하라 __변화 이해하기 __대규모 변화 __변화 만들기 __경영진을 끌어들여라 __팀을 끌어들여라 __이해관계자를 끌어들여라 __더 읽을거리 6장. 기민함 확장하기 __플루언시 확장하기 __제품 및 포트폴리오 확장하기 2부 가치에 집중하기 __집중하기 영역으로의 길 __집중하기 플루언시 달성하기 7장. 팀워크 __전체 팀 __팀 룸 __안전감 __목적 __컨텍스트 __정렬 __활력이 넘치는 업무 8장. 플래닝 __스토리 __적응적 계획하기 __시각적 계획하기 __플래닝 게임 __실질적인 고객 참여 __점진적 요구 사항 9장. 오너십 __태스크 플래닝 __수용량 __슬랙 __스탠드업 회의 __정보가 풍부한 업무 공간 __고객 예시 __‘완료 완료’ 10장. 책임 __이해관계자 신뢰 __이해관계자 데모 __예측하기 __로드맵 __매니지먼트 11장. 개선 __회고 __팀 다이내믹 __장애물 제거 3부. 신뢰성 있게 전달하기 __전달하기 영역에 온 것을 환영한다 __전달하기 플루언시 달성하기 12장. 협업 __집단 코드 오너십 __페어 프로그래밍 __몹 프로그래밍 __유비쿼터스 언어 13장. 개발 __제로 프릭션 __지속적인 통합 __테스트 주도 개발 __빠르고 안정적인 테스트 __리팩터링 __스파이크 솔루션 14장. 디자인 __점진적 디자인 __단순한 디자인 __반영적 디자인 15장. 데브옵스 __운영을 위한 빌드 __피처 플래그 __지속적인 배포 __진화적 시스템 아키텍처 16장. 품질 __버그 없음 __사각지대 발견 __사건 분석 4부. 결과물 최적화하기 __최적화하기 영역에 온 것을 환영한다 __최적화하기 플루언시 달성하기 17장. 자율성 __비즈니스 전문성 __비즈니스 의사 결정 __책임과 감독 __자금 지원 __실험과 더 읽을거리 18장. 발견 __검증된 학습 __적응성 __실험과 더 읽을거리 19장. 미래를 위해 |
James Shore
김모세의 다른 상품
|
* 이 책에서 다루는 내용
- 기민함을 개선하라: 애자일을 성공하기 위해 필요한 조건들을 만들고 조직에 맞게 확장하라. - 가치에 집중하라: 팀으로 작업하고, 우선 순위를 이해하고, 가시성을 제공하고, 지속적으로 개선하라. - 소프트웨어를 신뢰성 있게 전달하라: 오너십을 공유하고, 개발 비용을 줄이고, 설계를 진화시키고, 지속적으로 배포하라. - 가치를 최적화하라: 제품 계획, 예산, 실험을 소유하라. 시장을 이끄는 소프트웨어를 만들라. * 이 책의 대상 독자 애자일 팀에서 업무를 하거나 미래에 그렇게 하기를 희망하는 모든 사람을 위한 책이다. 프로그래머는 물론이고 관리자, 경영진, 도메인 전문가, 테스터, 프로덕트 매니저, 프로젝트 관리자, 아키텍트, 운영, 보안, 디자이너, 비즈니스 분석가들을 모두 읽기에 적합하다. * 지은이의 말 나는 여러분이 애자일 개발의 기술을 마스터하도록 돕고 싶다. 애자일 개발은 여느 팀 기반 소프트웨어 개발 접근 방식과 마찬가지로, 개인과 상호 작용의 변화를 다루는 인간에 관한 기술이다. 애자일 개발을 마스터하려면 매 순간 무수한 가능성을 평가하고, 최상의 조치를 직관적으로 선택하는 방법을 배워야 한다. 그런 어려운 기술을 어떻게 하면 배울 수 있을까? 오로지 연습뿐이다! 가장 먼저 이 책은 방법을 가이드(how-to guide)하는 책이다. 애자일 개발을 연습하는 방법에 관해 자세히 설명한다. 익스트림 프로그래밍이 기반이지만 스크럼(Scrum), 칸반(Kanban), 데브옵스, 린 소프트웨어 개발(Lean Software Development), 린 스타트업(Lean Startup)같은 아이디어와 사례를 가져왔다. 궁극적으로 애자일 개발을 팀과 조직에 성공적으로 도입할 수 있는 실용적인 가이드가 될 것이다. 또한 애자일이 여러분의 상황에 적합하지 않는지 판단하는 데도 도움이 될 것이다. 둘째, 이 책은 여러분이 애자일 개발의 예술을 마스터하도록 도움을 주기 위한 목적으로 썼다. 기민함(agility)을 마스터한다는 것은 프랙티스 가이드를 뛰어넘는 것을 의미한다. 소프트웨어 개발은 컨텍스트에 민감하기 때문에 어느 한 가지 접근 방식이 완벽하게 들어맞지 않으며, 너무나 미묘해서 책 한 권으로 모든 것을 알려줄 수도 없다. 완벽함은 내부에서 나온다. 선택의 조약돌이 일으키는 파문에 관한 경험과 직관적인 이해가 바탕이 돼야 한다. 처음에는 각 프랙티스의 적용 방법을 이해하는 데 어려움을 겪을 수 있다. 글로는 쉬워 보이지만, 실제로 몇 가지 프랙티스를 실행하는 것은 쉽지 않을 것이다. 쉬워질 때까지 계속 연습하는 것이 중요하다. 애자일이 쉬워지는 순간 내 조언 중 일부는 여러분에게 효과가 없음을 알게 될 것이다. 처음에는 문제가 내가 제공하는 가이드에 있는 것인지, 혹은 해당 가이드를 따르는 여러분의 방식에 있는지 역시 알 수 없을 것이다. 확신이 들 때까지 계속 연습하라. 그리고 규칙을 어겨보라. 여러분이 처한 상황에 더 잘 맞도록 내 가이드를 수정하라. 모든 프랙티스는 탐색해 볼만한 아이디어를 담은 ‘대안과 실험’ 섹션을 제공하고 있다. 언젠가는 규칙에 대한 흥미를 잃어버릴 것이다. 애자일은 결국 규칙을 따르는 것이 아니라 ‘단순함과 피드백, 커뮤니케이션과 신뢰에 관한 것’이라 생각하게 될 것이다. “애자일은 가치를 제공하고 적시에 올바른 일을 할 수 있는 용기를 갖는 것이다.” 매 순간 무수한 가능성을 평가하고 직관적으로 최선의 행동을 선택하게 될 것이다. * 옮긴이의 말 애자일은 어디에나 있지만, 역설적으로 어디에도 없다. 2001년, 1990년대에 만연했던 소프트웨어의 위기에서 탈출하기 위해 선언된 애자일 소프트웨어 개발 선언문은 개발자라면 적어도 한 번 정도는 들어봤거나, 직접 누군가에게 말해봤을 만큼 널리 알려졌다. 많은 기업이 “우리는 애자일하게 일하고 있습니다.”라는 슬로건을 내 걸지만 그 실체를 자신 있게 구현해 낸 이들을 찾아보기는 쉽지 않다. 애자일하게 일하고 있다고 말하는 사람들은 자신들이 하고 있는 여러 가지 프랙티스를 소개한다(그리고 거기에 약간의 성공과 상당한 실패가 함께 한다). 애자일은 프랙티스나 방법론이라기보다는 가치이자 철학이다. 여러분이 알고 있는 애자일은 다음의 네 가지 원칙으로 설명할 수 있다. 그 어디에서도 특정한 프랙티스에 관해 말하지 않는다. 공정과 도구보다 개인과 상호작용을 / 포괄적인 문서보다 작동하는 소프트웨어를 / 계약 협상보다 고객과의 협력을 / 계획을 따르기보다 변화에 대응하기를 그렇지만 우리에게는 이를 구체화하고 실체화할 수 있는 방법이 필요한 것 또한 부정할 수 없는 사실이다. 이 책에서는 애자일의 근본이 되는 가치와 철학을 재조명하고, 애자일이 동작하는 방식, 성공과 실패에 도달하는 이유, 애자일을 실질적으로 구현할 수 있는 다양한 방법과 도구를 설명한다. 2판은 1편을 출간한 이후 저자가 겪은 10년 이상의 경험을 통해 제시하는 더 실천적인 방법을 다루고 있다. 여러분이 애자일이라는 가치와 철학을 더욱 잘 이해하고, 이를 현실에 녹여낼 수 있는 아이디어를 제시하기에 충분할 것이다. 여러분이 있는 그곳에 애자일이 함께 하기를 바란다. |
|
우리가 애자일 소프트웨어 개발 선언문을 작성했을 때, 업계의 변화를 시도했던 소수의 사람만이 우리를 지지했다. 20여 년이 흐른 지금 ‘애자일(agile)’은 주류로 자리잡았다. 그러나 애자일 소프트웨어 개발을 하고 있다고 말하는 사람들이 하는 행동은 우리가 20여 년 전에 공유한 비전과 비슷한 점이 거의 없다.
애자일 방식으로 작업하기 위해서는 소프트웨어 개발 작업 관리 및 기술적인 실행 모두에 상호 연결된 프랙티스의 그물(web)이 필요하다. 이런 프랙티스 중 많은 부분, 특히나 기술적인 프랙티스에 관해서는 이해가 부족하거나 이해하고 있더라도 프랙티스를 널리 가르치지 않는다. 그 결과 너무 많은 사람이 소프트웨어 제품을 구축하는 효과적인 방법이 무엇인지에 대한 왜곡된 관점을 갖고 있다. 제임스 쇼어는 애자일 운동(Agile movement)의 핵심 기둥인 익스트림 프로그래밍(Extreme Programming)의 길을 걸은 개척자들 중 한 명이다. 이 책의 1판은 내가 가장 좋아하는 책으로, 팀에서 애자일 프로세스를 적절하게 실행하기 위해 알아야 할 것을 보여주는 핸드북이었다. 제임스는 이후 다이애나 라센(Diana Larsen)과 함께 애자일 플루언시 모델(Agile Fluency Model)을 만들었다. 이 모델은 사람들이 애자일 접근 방식을 이용해 기술을 개발할 수 있는 다양한 방법에 대한 경험을 담았다. 이 모델에서 기본 스크럼 접근법이라 불리는 프로젝트 관리 기술의 단순한 적용은 고객의 요구사항에 초점을 맞춤으로써 어느 정도의 가치를 제공하지만, 많은 팀이 달성하고자 하는 높은 생산성과 안정성을 얻는 데 필요한 기술적 스킬은 부족하다. 이런 관점은 가치에 집중하는 방법과 해당 가치를 안정적으로 전달하는 방법에 많은 비중을 둔 이 책의 구조를 올바르게 이끌고 있다. 가치에 집중한다는 것은 강력한 팀워크의 중요성을 이해하고, 적응적 계획(adaptive planning) 기술을 개발하고, 그 결과 개발된 소프트웨어의 고객 및 사용자와 긴밀하게 협업하는 것을 의미한다. 딜리버리 신뢰성 테스트, 리팩터링, 디자인 및 공동 개발을 위한 필수 기술 사례에 중점을 둔다. 내부 품질이 높은 소프트웨어를 구축하면 비용이 절감되고 코드 전달 속도가 빨라진다는 직관적이지 않을 수도 있는 개념을 인식한다. 데브옵스(DevOps) 문화 및 지속적인 제공과 결합해 높은 빈도의 기능을 신속하게 프로덕션에 적용할 수 있게 지원한다. 팀은 이를 통해 소프트웨어가 실제로 사용되는 방법을 관찰함으로써 무엇이 더 가치 있는 것인지 더 많이 배울 수 있다. 나는 20년 전 운이 좋게 소트웍스(Thoughtworks)에 둥지를 틀었다. 우리 팀은 이런 유형의 기술을 사용해 고객이 새로운 소프트웨어 제품을 구축하고 오래된 레거시(legacy)를 대체하도록 지원한다. 제임스와 마찬가지로 우리는 익스트림 프로그래밍이 확고한 기반을 제공하는 것을 발견했고, 지난 20년 동안 이 기술을 적용해 큰 성공을 거뒀다. 그렇기에 나는 제임스가 10년 동안의 코칭 경험을 2판에 반영한 것을 보게 돼 너무나도 기쁘다. 가치 있는 일에는 시간이 걸리고 그 과정에서 좌절도 있을 것이다. 하지만 이 가이드북에는 껍데기만 남은 의식에서 벗어나 제임스와 내가 수년 전 이 기술을 처음 사용했을 때 느꼈던 활력이 있다.이 활력은 여러분의 여정을 도울 수 있을 것이다. - 마틴 파울러 (소트웍스(Thoughtworks) 수석 과학자) |