The Nature of Software Development 간결하게, 가치 있게, 하나씩 완성하기

Intro

책의 제목이 저자가 말하고자 하는 내용을 간결하게 표현한 것 같다. 간결하게, 가치 있게, 하나씩 완성하기. 특별한 기술을 설명하는 책은 아니다. 애자일을 접해봤던 사람이라면 다 알만한 내용들이다. 그래서 가볍게 술술 읽혀 졌다. 물론 술술 읽혀 졌을 뿐이지 많은 고민과 사색이 필요한 주제들이였다. 책의 끝무렵 쯔음 프로젝트에 바라보는 눈에 다른 시각이 생겨났다. 단순한 무형자산의 소프트웨어가 복잡, 다양한 의미의 가치로 보였다고 할까? 책을 추천해주신 Eddy Kim에게 감사말씀 전하고 싶군요.

시작하는 말

애자일은 간결합니다. 4가지 가치와 12가지 원칙만 있습니다.
…중략…
이 책은 소프트웨어 개발이라는 복잡한 활동 속에서 본질적인 간결함을 찾으려는 하나의 시도입니다.

론 제프리스 — The Nature of Software Development

론 제프리스님 16가지나 되는게 간결하단 말씀입니까?

감사의 말

자유, 믿음, 그리고 위대한 도서관과 같은 나의 부모님께…

론 제프리스 — The Nature of Software Development

동기부여가 되는 멋진 찬사다.

옮긴이의 말

• Part1 : 프로젝트를 성공으로 이끌기 위한 여러 방법
• part2 : Part1을 적용할 때 도움이 되는 여러 조언

들어가기 앞서

소프트웨어 개발에는 본질적인 방법이 존재한다. 그 방법은 모두에게 도움을 준다.

론 제프리스 — The Nature of Software Development

하지만 이 책이 방법을 설명하는 책은 아니라, 본질적인 방법이 어떻게 적용될 수 있는지를 설명한다고 함.

Part1 가치를 이루는 것들

선택과 집중

가치 찾기

Value의 번역이 가치로 되었으나 목표가 더 어울린다고 생각된다. 최종적으로는 추구하는 어떤 것 이란 의미가 있다. 목표를 완성하기 위한 전략을 피라미드 형태를 이용해 표현한다. Value는 이 피라미드의 최상단에 위치해 있으며 최종 결과물, 목표, 성과… 등으로 볼 수 있다. 최하위 층에서 단계적으로 최상위 층인 Value를 향한 프로레스를 설명한다. 조직의 구성과 그 조직을 활용해 단계적인 절차를 거쳐 결과를 만들고 그 결과를 관리하는 방법에 대한 전반적인 설명을 그림으로 잘 표현한 것 같다.
단어의 정의 없이 뜬금없이 피처란 단어를 사용해 설명을 한다. 이런 설명 방식은 정말 마음에 들지 않는다.

가치, 우리가 원하는 것

드디어 피처에 대한 정의가 나왔다. Feature 였다니!!!. MMF라고도 부르며 아래와 같이 정의한다.

Minimum Marketable Feature, 피처가 가치를 만들어낼 수 있는 최소 단위의 집합

론 제프리스 — The Nature of Software Development

피처를 세로(가치) X 가로(비용) 블럭으로 표현해 가치를 위해 어떤방식으로 쌓는게 효율적인지 다양한 그림으로 표현한다. 그림을 보고있노라면 이런 말이 떠오른다. 백번 듣는것 보다 한번 보는게 낫다. 이 책은 그래프와 그림으로 정보 전달을 효율적으로 한다.

피처 단위 개발을 위한 가이드라인

소프트웨어를 직접 보기 전까지는 프로젝트 진행 상황을 알 수 없습니다. 코드를 테스트하는 단계가 오면 어떤 일이 일어날까요? 보통 좋은 일은 일어나지 않습니다.!
…중략…
더 나쁜 것은… 프로젝트가 계획대로 가는 일은 정말 드물다는 것입니다.

론 제프리스 — The Nature of Software Development

정말 공감가는 말이라서 웃을 수 밖에. 가치를 눈으로 확인할 수 있는 단위의 피처로 나누어 진행할 때의 장점에 대해 서술.

피처 단위로 조직 구성하기

제곧내. 제목이 곧 내용이였다. 다만 학습공동체에 대한 설명 중 아래의 인상적인 문구가 눈에 띄였다.

전문가는 단지 전문가이기 때문에 높은 연봉을 받는 것이 아닙니다. 그들이 다른 사람을 전문가로 이끌어 줄 수 있어 그런 것입니다.

론 제프리스 — The Nature of Software Development

피처 단위로 계획하기

계획은 쓸모없을 때가 많습니다. 하지만 동시에 없어서는 안 될 부분입니다.

아이젠하워 장군

계획은 세밀하게 보단 러프하게. 모든 계획을 처음부터 완벽하게 세울순 없다. 그렇다고 계획없이 개발을 진행하는건 길을 헤매기 쉽상.

프로젝트를 시작할 때 계획을 세우는 것만으로는 충분하지 않습니다. 프로젝트는 가치를 우선하므로 계획은 프로젝트 기간 내내 필요합니다.
…중략…
사용자 스토리를 기준으로 개발하세요. 훨씬 더 나은 결과물을 보여줄 것입니다.

론 제프리스 — The Nature of Software Development

앞에서 러프하게 계획했기 때문에 피처 단위로 개발이 들어갈 때는 다시 세밀한 계획을 수립하는 식으로 항상 계획을 세워야 할 것 같다. 그리고 피처의 단위를 사용자 스토리 기준으로 개발하라는데. 테스트 스토리가 생각났다. 개발자 기준이 아닌 사용자 기준의 개발 단위가 의미있는 피처 단위로 생각된다. 이후 피처 단위를 나눌때의 주의 사항들에 대해 나온다. 전의 개발일정을 기준으로 추정기법, 일정에 대한 과욕은 금물…

피처 단위로 개발하기

개발팀이 작동하는 소프트웨어를 보여주니 관리와 계획이 간결해지기 때문입니다.

론 제프리스 — The Nature of Software Development

피처 단위를 한번에 크게 밀어붙이기 보다는 눈으로 확인할수 있는 짧은 주기들로 나누었을 떄의 장점에 대해 설명한다.

피처와 기반을 동시에

제품에 들어갈 피처는 반드시 기반을 견고히 해야 합니다. ‘기반’이라는 단어는 종종 아키텍처, 디자인, 또는 인프라라고 불립니다.
…중략…
피처와 기반을 동시에 개발할 때는 프로젝트를 잔정적이고 빠르게, 시간과 노력을 최소화할 방법으로 개발해야 합니다.

론 제프리스 — The Nature of Software Development

피처와 기반의 비중을 어떻게 정해 동시 개발해 나갈껀지에 대해 설명, 이를 위해 MVP(Minimum Viable Product) 설명.

무결점과 견고한 설계

컨설턴트 톰 드마르코가 말한 것처럼, 레스토랑 바닥에서 아무도 바퀴벌레를 본 사람이 없을 때 저기 바퀴벌레가 지나가네요.라고 하는 것이죠. 버그는 마치 바퀴벌레와 같습니다. 버그 하나를 발견했다는 것은 이미 수많은 버그가 있을 수 있다는 말입니다.
…중략…
오직 테스트만이 결함을 최소화하는 방법입니다.
…중략…
올바른 설계를 유지하는 일을 리팩토링이라 부릅니다. 리팩토링은 올바른 설계를 유지하는 데 꼭 필요한 기술이죠.

론 제프리스 — The Nature of Software Development

결함이 프로젝트에 미치는 악영향에 대해서 설명합니다. 결함 수정이 일정을 얼마나 지연시킬지 다음 피처의 추가계획에 얼마나 차질를 불러일으키는지 경각심을 가지게 하며 이를 대비하기 위해 테스트주도 TDD 방법의 필요성을 강조합니다. 그리고 설계는 fix되고 유지되는게 아니라 유연성 있게 수정되고 피처와 함께 발전되어 나가야 함을 설명합니다.

요약

앞의 내용들을 5가지로 요약하고 있습니다. 저작권상 나열할 순 없고 가치와 작동하는 소프트웨어 두 단어로 표현하고 싶네요.
특출난 기술을 설명하는 것도 처음 듣는 내용도 아닙니다만 막연히 알고있고 생각헀던 내용들을 정리해주고 프로젝트를 효율적으로 수행할 수 있는 방향성에 대해 한번 생각해보게 만들어 준 것만드로도 Part1 감사히 잘 읽었네요. Part2 로 들어가 봅시다.

Part2 메모와 에세이

가치에 대해서

Part1을 통해 무수히 언급되었던 가치의 의미에 대해 다양한 관점의 예를 들어 설명하고 있습니다. 제게 소프트웨어란 무형자산 정도로만 생각되었는데 이 부분을 읽고는 소프트웨어를 바라보는 시점이 조금 바뀌게 되었네요.

가치를 정하는 기중

가치를 측정하는 방법은 주관적일 수 밖에 없다. 비용 등 객관적인 지표로 가치를 판단하는 것에 대한 어려움과 불확실성을 이야기 하며 아래와 같이 결론을 냅니다.

가치를 평가하는 진정한 방법은 제품 책임자와 이해관계자, 그리고 팀과 함께 무엇이 정말로 가치 있는 것인지 고민하고 만들어 나아가는 것입니다.

론 제프리스 — The Nature of Software Development

물론 힘든 일입니다

훌륭한 소프트웨어를 만든다는 것은 너무나도 힘든 과정이지만 꾸준한 노력을 통해 개선해 나가면 한발짝 더 가갈수 있을거라 합니다.

처음에만 해야 할 일를 구체적으로 결정하는 것뿐만 아니라 지속적으로 검토하고 바꾸어 나가는 것이 좋습니다.

론 제프리스 — The Nature of Software Development

그리 단순하지 않습니다

우리는 소프트웨어 개발 과정이 정말 간결해질 수도 있다는 것을 인지할 필요를 언급하며 아래 3가지 기준을 제시합니다.

항상 가치에 집중할 것, 가치를 기준으로 계획하고 관리할 것, 사용자가 어떤 반응을 보이는지 살펴볼 것.

론 제프리스 — The Nature of Software Development

성장하는 개발팀 만들기

자율성은 팀에게 책임감을 부여합니다.
…중략…
관찰하고 적용해 나아간다는 스크럼의 정신
…중략…
제품이 나아가야 할 목표를 함께 이해하는 숙련된 자기 조직화 팀

론 제프리스 — The Nature of Software Development

초기 계획을 위한 ‘파이브 카드’

포커의 파이프 카드가 아닙니다. 애자일의 파이브 카드입니다.

경영진을 위한 소프트웨어 개발의 본질

개발팀에 자율권 보장, 작업 결과물을 살펴보고 조언, 훈련, 예산, 인력, 책임 조정

더 강한 채찍질

팅을 압박한다면 코드는 나쁜 상태로 방치되고 새로운 피처를 추가하는 것은 힘들어지며 가치를 전달하기까지 점점 더 오래 걸립니다. …중략…
압박을 받는다면 개발팀은 의식적이든 아니든 보수적으로 일합니다. 평소보다 더 크고 어렵게 등급을 매기기 시작하죠.

론 제프리스 — The Nature of Software Development

일정에 대한 압박이 프로젝트에 미치는 악영향을 설명하며 채찍질 대신 성장을 돕도록 권한다.

속도를 내기 위한, 특별한 빌드 기술

개발팀이 무리한 일정이라 주장에는 보통 빌드 시간, 통합 시간, 테스트 시간을 언급한다. 효율적인 성과를 요구하는걸 채찍질 하는 것과 혼동해서는 안된다. 그리고 효율적인 성과를 내기 위해 필요한 것들을 기술한다.

리팩토링

프로젝트는 일정한 속도를 유지해야 합니다. 일정한 속도는 설계를 항상 깔끔하게 유지해야 나옵니다. 설계를 깔끔하게 하려면 반드시 리팩토링해야 합니다.

론 제프리스 — The Nature of Software Development

정사각형의 꼭지점에서 대각선 방향 꼭지점을 향하는 경로가 꼬불꼬불해질 경우 최단한 직선에 가깝도록 수정하는걸 리패토링에 비유하여 그림으로 설명하네요.

애자일 방법들

여러 애자일 방법들에 대한 설명과 프레임워크에 대한 조언.

애자일 확장

애자일을 확장할 필요는 없습니다. 그저 따라 하면 되는 것이죠.

론 제프리스 — The Nature of Software Development

긴 지면을 할애하나 결론은 just do 애자일이라고 말하는 것 같다.

결론

소프트웨어 개발을 등산을 비유로 설명하면서 글을 마칩니다.