[밑줄긋기] The Nature of Software Development – 간결하게, 가치 있게, 하나씩 완성하기

한줄평: 2주 안에 개발과 테스트까지 완료할 수 있는 ‘피처’ 단위로 소프트웨어를 개발해 나가자. 
덧붙임: ‘함께 자라기‘와 비슷한 시기에 읽어서 더 좋았던 책.


p25. 가치는 우리가 원하는 것입니다. 

<05 피처 단위로 계획하기>

p54. 먼저 개발해야 할 핵심 피처를 추리는 것이 중요합니다. 이것이 없으면 살 수 없을 정도로 중요한 피처 말이죠. 이런 피처를 먼저 추려내고 기록하세요. 가치가 낮은 피처는 최대한 뒤로 미루어야 합니다. 이런 피처를 생각하는 데 시간을 낭비하지 말고 언제든 찾아볼 수 있도록 기록만 해둡시다.

p60. 프로젝트를 진행할 때, 커다른 피처를 태스크라는 단위로 쪼개는 방법은 추천하지 않습니다. 태스크 단위를 사용한다면 개발자가 아닌 사람들은 피처 개발이 어떻게 진행되는지를 명확하게 파악할 수 없습니다. 개발 주기가 끝날 때까지 어떤 도움이 필요한지 알 수 없는 상황도 자주 생깁니다. 항상 사용자 스토리를 기준으로 개발하세요. 훨씬 더 나은 결과물을 보여줄 것입니다.

-> JIRA에서 Story와 Task를 구분?

p62-63. 팀이 얼마나 많은 것을 할지 결정을 도와주는 연습 방법이 많이 있습니다. 여기에서 소개할 방법은 제가 켄트 벡과 마틴 파울러에게 배운 아이디어를 기반으로 합니다. 어제의 날씨라는 방법이죠.

오늘은 어제의 업무량만큼 일할 수 있습니다. 이 원리를 반복 개발 주기를 사용하는 프로젝트에 적용합니다. 가장 최근 주기의 작업량을 기준으로 업무량을 계획하는 것입니다. (…)

업무량을 개인별로 추정하는 것은 결코 권하지 않습니다. 개인이 아닌 팀 전체를 이해하고 팀이 할 수 있는 양을 추정해야 합니다. 이 방법이 팀에 도움이 된다면 그대로 진행하세요. 단, 조심해야 할 것이 있습니다. 이 일은 추정을 정확히 하고자 하는 것이 아닙니다. 바로 제대로 된 일을 일관된 속도로 수행하기 위한 것입니다!

p64. 추정은 위험합니다!

추정에는 심각한 위험 요소가 존재합니다. 우리는 과장하거나 비교하려는 어쩔 수 없는 욕구를 가지고 있기 때문이죠. 두 요소 모두 매우 위험합니다. 비즈니스와 프로젝트 관리는 반드시 완료돼야 할 일과 그렇지 않은 일을 구분했을 때 최선의 결과를 가져온다는 사실을 기억하세요. 추정에 너무 집중하면 이런 책임감에서 멀어지게 되며, 정확한 추정을 해야 한다는 생각 때문에 보수적으로 추정하기 쉽습니다.

구체적인 추정 없이도 오늘날 많은 팀은 성공적으로 일을 해내고 있습니다. 그들은 모두 해야 할 일에 대해서만 생각합니다. 해야 할 일을 잘게 부숩니다. 보통은 가치 있는 사용자 스토리 하나를 테스트할 수 있는 수준까지 쪼개죠. 그런 다음 작업을 시작합니다. 개발이 얼마나 걸릴지 예측해야 할 때는 단순히 완료된 것들을 세어 봄으로서 쉽게 추측할 수 있습니다. (…)

추정을 더 잘하려다 팀원들을 더 보수적으로 만들어도 그렇게 할 의향이 있나요? 예측이 직접 해보는 것보다 정확할 수 있을까요?

p66. 무리한 목표는 자멸하는 길입니다.

프로젝트를 계획할 때는(짧은 기간이라면 더더욱) ‘더 큰 목표를 계획’하거나 ‘피처 하나만 더 추가’하자고 개발팀을 설득하고 싶을 것입니다. 물론 그렇게 하면 절대 안 됩니다. 이런 행동은 프로젝트 전체에 치명적인 손상을 입힙니다. 그렇게 부탁하거나 목표를 더 많이 잡으면 개발팀은 정말로 그렇게 해보고자 무의식적으로 서두르게 됩니다. 몇 가지 테스트는 생략하겠죠. 코드도 생각만큼 깔끔하게 만들지 않을 것입니다. 단지 피처 하나 늘었기 때문이지만 팀원들은 많은 압박을 받게 됩니다. (…)
압박하는 행동은 치명적입니다. 절대 하지 마세요.

-> 쪼아서 되는 일은 없다. 정확한 예측은 불가능하다.

p69. 10가지 일을 형편없이 진행하는 것보다는 8가지 일을 잘 진행하는 것이 낫습니다. 팀이 감당할 수 있는 업무보다 일이 많다고 깨달았다면 그 즉시 업무를 덜어내야 합니다. 프로젝트가 끝날 때까지 팀이 버틸 수 있도록 업무량을 관리하세요.

<06 피처 단위로 개발하기>

p72. 짧은 주기마다 작지만 완전한 제품을 완성하세요.

처음에는 이 방법이 낯설겠지만 주기를 몇 번 거친 후에는 상당히 익숙해질 것입니다. 그 순간부터는 주기마다 프로젝트의 피처가 어떻게 진행되는지 충분히 예측할 수 있습니다. 각 주기가 지날수록 예측은 더욱 정확해지고 배포할 수 있는 제품의 버전도 다양해집니다. 조직은 주기마다 여러 가지를 배울 수 있습니다. 주기마다 얼마나 많은 것을 할 수 있는지, 만들기로 계획한 피처들이 얼마나 테스트됐는지 알 수 있습니다. 낭비 없이 가장 효율적으로 피처를 만드는 방법, 프로그램의 코드와 설계를 명확하게 유지하면서 피처 단위로 제품을 개발하는 방법에 대해 많은 것을 배울 수 있습니다.

p73. 제품이 가진 특징을 다듬으세요.

비즈니스 담당자는 거대하고 모호하며 광범위한 요구 사항을 작고 실질적인 피처들로 분리하는 능력을 길러야만 합니다. 그것이 최소한의 노력으로 최대한의 가치를 얻는 방법입니다. (…)

이것은 결코 작은 일이 아닙니다. 게다가 성공하기도 어렵죠. 그러므로 제품에 반드시 있어야 하는 피처와 단순히 있으면 좋은 피처를 구분하여 제품이 가진 특징을 더욱 뚜렷하게 만들어야 합니다. 이런 노력이 소프트웨어에 눈에 띄는 결과를 가져오게 됩니다.

-> 디자이너와 일하기에서도 중요한 내용. 기획자 혹은 프로덕트매니저의 역할은 ‘중요한 가치를 포착하고, 그것을 원자 단위까지 쪼개서, 눈에 보이고 손에 잡힐 듯한 구체적 언어로 표현하기’로 정리할 수 있을 것 같다. 2019년 1월 현재까지의 정리.

p75. 가장 높은 가치를 가진 피처를 먼저 개발하세요

피처 단위 개발에서는 매 주기가 지날수록 개발 완료 시점까지 얼마나 많은 것을 완료할 수 있을지 점점 명확해집니다. (…)
이 과정은 반드시 투명하게 진행해야 합니다. 조직 내 모든 사람이 실제로 진행되는 상황을 볼 수 있어야 하죠. 90% 완료라는 것은 허용할 수 없습니다. 모든 피처를 만드시 완료 또는 미완료로 구분해야 합니다. 중간은 없습니다. 

p76. 실제 진행 상황을 확인하세요

피처 단위 개발에는 매 주기가 완벽한 개발 프로세스를 포함합니다. 프로세스는 요구 사항, 설계, 코딩, 그리고 테스트를 포함하죠. 이 모든 것을 주기마다 수행해야 전체 개발 기간 내내 진행 상황을 볼 수 있습니다. 피처 단위 개발은 안전하고 실용적이며 매우 효율적입니다. 

p77. 테스트-수정 과정이 완료 단계에서만 있어서는 안 됩니다

피처 단위 개발을 제대로 적용하려면 각 주기가 끝나는 시점에서는 소프트웨어의 결함이 없어야 합니다. 그뿐만 아니라 모든 개발 기간에도 소프트웨어에 결함이 있어서는 안 됩니다. 결합이 없다는 것을 확신하려면 항상 모든 것을 확인해야 합니다. 생각보다 어렵지 않습니다. 

<07 피처와 기반을 동시에>

p86. 필요한 피처만 모아 만든 간결한 제품으로 높은 작업 효율을 낼 수 있습니다. 제품에 필요한 피처는 그 피처가 견고해질 수 있는 기반이면 충분합니다. 이렇게 만든 제품을 MVP(Minimun Vialble Product)고 합니다. 프로젝트를 진행할 때는 MVP를 가능한 한 빨리 개발하는 것이 중요합니다.

<08 무결점과 견고한 설계>

p97. 인수테스트 주도 개발 ATDD- Acceptance Test-Driven Development

p98. 테스트 주도 개발 TDD – Test-Driven Development

-> 들어는 보았지만 무슨 개념이고 어떤 행위인지 잘 모르는 TDD, 처음 들어본 ATDD

p104. 피처 단위로 개발하려면 테스트와 리팩토링을 함께 진행해야 합니다. 이 개발 방법의 본질이 테스트와 리팩토링에 있기 때문이죠. 오늘날까지 이보다 나은 방법은 없습니다.

p106-107. 요약

p117. 하지만 가치를 평가하는 진정한 방법은 제품 책임자와 이해관계자, 그리고 팀과 함께 무엇이 정말로 가치 있는 것인지 고민하고 만들어 나아가는 것입니다. 개발자와 이해관게자를 한 데 모아 우리가 무엇을 하려는지 함께 고민해보세요. 다음에 할 것을 몇 가지 선택해보세요. 여러 사람이 거기에 동의한다면 그것이 가장 가치 있는 피처가 될 것입니다. 진정한 가치는 여러 사람의 의견이 일치할 때 발견할 수 있다는 점을 배우게 될 것입니다. 가치를 정했다면 망설임 없이 피처를 개발하여 제품을 배포하도록 하세요. 그리고 사용자에게 의견을 들어야 합니다. 이 과정을 반복하는 것이 핵심입니다.

-> ‘여러 사람이 거기에 동의한다면’에서 또 인사/채용의 중요성을 떠올린다. 우수하거나 우수하지 않거나의 문제가 아니라, 함께 일할 때 편안하고 신뢰가 가는 팀원과 일하는 것의 중요성.

<14 성장하는 개발팀 만들기>

p125. 다니엘 핑크가 쓴 『드라이브』에서, 그는 목적, 자율성, 숙련이 직원의 만족과 제품의 생산성을 이끄는 핵심이라고 설명합니다. 이는 제 의견과 상당히 비슷합니다. 이 책에서 설명하려는 본질적인 방법이 뜻하는 의미와 많은 부분에서 일치합니다. 왜 그런지 살펴봅시다.

-> 합리적인 목적을 구체적이고 명료한 언어로 공유하고, 그 목적의 구현 방법은 개발팀의 자율성에 맡기고 (물론 책에서 소개하는 ‘본질적인 방법’으로), 그러면서 개발팀이 스스로 성장할 수 있는 환경을 만들기.

<17 더 강한 채찍질>

p144. 압박한다면 개발팀은 잘못 돼가는 것을 알면서도 포기합니다. 테스트를 충분히 하지 않죠. 나쁜 코드를 방치합니다. 이 현상은 가치를 떨어뜨리고 가치를 얻는 데 필요한 일정을 지연시킵니다. 그 결과 제품의 가치도 떨어지고 배포도 늦게 되죠.

p146. 압박을 받는다면 개발팀은 의식적이든 아니든 보수적으로 일합니다. 평소보다 더 크고 더 어렵게 등급을 매기기 시작하죠. 그래야 그들이 더 빠르게 일한다는 인상을 주기 때문입니다. 하지만 실제로는 그렇지 않죠. (…) 개개인의 생산성을 높이려면 더 열심히 일하라고 재촉하지 말고 개개인의 능력을 향상시키세요. “열심히 일하지 말고 똑똑하게 일하세요.”라는 말은 그들을 똑똑하게 만들어야 한다는 뜻과 같습니다. 프로젝트 일정이 지연된 진짜 이유가 무엇인가요? 무언가를 결정하려다 늦어진 적은 없나요? 결함 수정? 팀 내외 간 소통 비용? 무엇이 일정을 지연시켰나요? 계속 생각해보세요.

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

p148. 팀은 이렇게 말합니다. 우리는 이 모든 피처를 2주 내로 끝낼 수 없습니다.

맞아요. 일반적인 문제입니다. 이 방법을 도입할 때 흔히 일어납니다. 개발팀은 2주 내로 제품에 통합될 피처들을 완성하지 못하고 시간을 더 달라고 요청합니다. 저는 시간을 늦추는 것 대신 작은 피처를 개발하게 하는 것을 추천합니다. 그리고 개발팀에게 2주가 아닌 1주 안에 완성해달라고 요청하세요.

-> 본질적인 방법을 따른다고 가정했을 때, 프로젝트 관리의 깨알 팁

p151. 이제 모두가 말합니다. 진행이 꽤 느린데요.

처음에는 느리다고 느낍니다 조금 지나면 이 방법이 유연하며 효율적으로 느껴지고 절대 서두르지 않게 되죠. 배포할 수 있는 제품이 개발 주기마다 성장한 상태로 있어야 합니다. 이를 달성하려면 우리가 개발한 피처는 설계, 테스트, 모든 면에서 완벽해야 합니다. 이 말은 개발팀이 개발 주기마다 평소보다는 작은 피처를 맡는다는 뜻이므로 진행이 더디다고 느낄 것입니다. 차이가 있다면 개발이 끝났을 때 정말로 모든 피처가 완성된다는 것입니다.

모든 피처를 완벽하게 개발하도록 노력하기 때문에 더딘 느낌은 착각일 뿐입니다. 우리는 개발이 끝나야만 진행할 수 있었던 고통스러운 테스트 및 수정 단계를 제거하는 과정에 있습니다. 혹시 제품이 배포될 때, 또는 배포된 이후 우리가 투자했던 그 모든 시간을 잊어버린 것은 아니겠죠?

-> 책에서 유일하게 별표를 그린 부분.최종 QA라는, 테스터와 개발자와 기획자 모두가 힘든 그 시기를 피할 수 있는 방법. 지금 보니 ‘매일매일 조금씩 예습 복습 하면 시험 직전에 벼락치기 하지 않아도 된다’는 얘기랑 비슷한데, 그만큼 원칙이 자명하면서 실제 달성하긴 어려운 일이구나 싶다.

<19 리팩토링>

p159. 가장 훌륭한 개발 방법은 야영지 규칙을 따릅니다. 야영지는 그곳을 발견했을 때보다 떠날 때 더 나은 곳이어야 한다는 규칙입니다. 피처를 추가할 때마다 주변 코드를 깔끔하게 정리하면서 시작하세요. 완벽할 필요는 없습니다. 피처가 쉽게 자리 잡을 수 있는 정도면 충분합니다.

<20 애자일 방법들>

p161. 작고 간결한 프레임워크부터 도입하세요. 너무 커서는 안 됩니다. 충분한 것도 안 됩니다. 애자일 선언문을 따르자면 프로세스와 도구보다는 개인과 상호작용을 선호합니다. (…) 프로젝트에 참여하는 모든 사람에게 그 어떤 프레임워크나 규칙에 얽매이지 않는 방법으로 상호작용을 할 수 있는 자유를 만끽할 수 있는 공간이 필요합니다.

-> 애자일이고 워터폴이고가 중요한 게 아니다. 동료 간의 신뢰와 편안한 분위기! 터 놓고 피드백을 주고받을 수 있는 여건.

p162. 프레임워크를 통제하세요. 프레임워크에 통제당해서는 안 됩니다. 프로젝트를 더 효율적으로 만들려면 프레임워크를 수정해 나가야 합니다. (…) 이 책에 담긴 아이디어와 여러분이 가진 아이디어는 여러분을 향상시키는 도전 과제입니다. 각자의 능력에 맞춰 아이디어를 변화시키세요. 하지만 여러분 자신도 조금은 변할 필요가 있습니다.

<21 애자일 확장>

와닿지 않아서 조금 읽다가 지나쳐 버림.


독서 기간: 2019.01.01 – 2019.01.06
정리 날짜: 2019.01.06

One thought on “[밑줄긋기] The Nature of Software Development – 간결하게, 가치 있게, 하나씩 완성하기

Leave a Reply

Your email address will not be published. Required fields are marked *