The Nature of Software Development

 

 

• 저자 :론 제프리스
• 번역 :이기곤
• 출간 :2016-12-31

 

론 제프리스가 누구?

---

 론 제프리스는 애자일 선언문 작성과 익스트림 프로그래밍 창시에 한몫 했던 사람으로 애자일과 소프트웨어 발전에 풍부한 경험과 실력을 가지고 있는 분입니다. 따라서 이 책을 읽기 전부터 신뢰가 갔고, 역시 풍부한 경험을 담아서 간접 경험을 할 수 있었습니다.

 

 

-Chapter1-

 

이 책의 핵심은? 작동 하는 소프트웨어로 피처 보여주기

---

우리 모두 가치를 원합니다. 바꿔 말하면, 가치는 우리가 원하는 것입니다.
소프트웨어에서는 보통 피처를 통해 가치를 얻습니다.
가치를 확인해보고 싶다면 이렇게 말하세요
"작동하는 소프트웨어를 보여주세요"

필요한 피처만 모아 만든 간결한 제품으로 높은 작업 효율을 낼 수 있습니다. 이렇게 만든 제품을 MVP라 합니다.

 

 이 책에서 초반에 주장하는 것은 가치를 전달하는 것입니다. 이 가치는 피처라는 기능을 말하는데, 가치를 전달하는 가장 좋은 방법은 작동하는 소프트웨어를 보여주는 것입니다. 개발자들은 작동하는 소프트웨어를 만들기 위해서 가장 중요한 우선순위를 정하고 핵심에 집중하게 됩니다. 가장 중요한 우선수위를 고려해서2주 단위의 스프린트로 계속해서 개발, 개선해나가는 방법이라고 이해하였습니다.

 

 

 

피처단위로 프로젝트를 진행한다면 더 잘 예측할 수 있습니다

---

배포일정단위로, 피처단위로 제품을 배포하는 것이 가치를 더 빨리 전달할 수 있습니다. ...
피처 개발이 얼마나 끝났고 얼마나 빨리 진행 중인지 볼 수 있습니다.
주어진 기간에 얼마나 많은 것을 할 수 있을지 더 쉽게 예측할 수도 있습니다.
우리는 다음에 개발할 가장 중요한 피쳐를 선택해야 합니다.
그리고 원하는 배포일정에 가장 가능성 있는 제품의 형태를 만들어 나갑니다.

 

 그렇다면 결국 '피처' , '배포' 단위로 제품을 배포하는 것이 더 가치를 빨리 전달할 수 있다고 합니다. 평균 약 2주라는 배포일정을 잡고, 피처에 집중합니다. 좋습니다. 이제 지속적인 요청사항이 들어와도 가장 중요한 피처를 단위로하기 때문에, 좀 더 가치를 빠르게 전달 할 수 있습니다.

 

 내가 지금도 일하는 방식이 어느정도 피처단위가 아닌지를 고민합니다. 제가 담당하고 있는 많은 개발건들과 일정들은 기간 내에 하기보다는 가장 중요한 우선순위 작업을 기준으로 진행하고 있습니다. 어떻게 보면 개발건이 피처입니다. 가장 중요한 피처를 먼저 끝내기 위해 노력하고 있습니다.

 

 

계획은 없어서는 안 될 부분입니다

---

먼저 개발해야 할 핵심 피처를 추리하는 것이 중요합니다... 
가치가 낮은 피처는 최대한 뒤로 미루어야 합니다.

모든 피처를 반드시 완료 또는 미완료로 구분해야합니다. 중간은 없습니다

 

 가장 중요한 핵심 피처부터 개발해야 합니다. 정말 일관되게 지속적으로 이야기하고 있습니다.

 

 

추정은 위험합니다!

---

구체적인 추정 없이도 오늘날 많은 팀이 성공적으로 일을 해내고 있습니다. 
그들은 모두 해야 할 일에 대해서만 생각합니다. 해야 할 일을 잘게 부숩니다. 
보통은 가치 있는 사용자 스토리 하나를 테스트할 수 있는 수준까지 쪼개죠

 

 많은 책에서 추정을 뜯어말리고 있습니다. 얼마나 개발자들이 잘못된 추정을 하는지 보여줍니다. 맞습니다.

저만해도 항상 내가 생각하는 일정에 비해 어떤 기능이 실제 운영에 배포되는데에 조금씩 밀립니다.

현업에서 테스트를 늦게한다거나 중간에 다른 일이 생기거나, 각종 이벤트로 지연되는 경우들이 있습니다.

 

 

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

---

프로젝트를 계획할 때는 '더 큰 목표를 계획'하거나 '
과제 하나만 더 추가'하자고 개발팀을 설득하고 싶을 것입니다...
서두르다 보면 결함이 더 많이 심게 됩니다. 
결함은 방지하는 것보다 수정하는데 훨씬 오래 걸리므로 프로젝트 일정도 지연시킬 수 있습니다. 
압박하는 행동은 치명적입니다. 
절대 하지 마세요

완성돼야 할 일과 미룰 수 있는 일을 구분하여 가장 가치잇는 피처를 먼저 개발함으로써 
일정 지연 없이 프로젝트를 성공적으로 끝낼 수 있습니다...
하지만 안타깝게도 추정의 간절함이 프로젝트 추정에서 터무니없이 많은 목표를 세우는 원인이 됩니다.

 

 하지만,,, 가끔 아니 대부분의 경우 처음 분석 설계와는 다르게 더 많은 요구사항들이 추가됩니다.  계속 개발을 하면서 느낀 것은 실제로 가끔이 아니라  정말 자주... 거의 99% 요구사항이 추가된다는 것입니다.  계획대로 되는 것이 거의 불가능에 가깝습니다.

 

 

자주 계획하고, 다음에 할 일을 정하세요, 과욕은 금물입니다

---

우리는 짧은 개발 주기마다 계획을 세우며 다음에 할 가장 중요한 것들을 정합니다. 
항상 가치 있는 아이디어를 먼저 선택하세요. 그것이 바로 가치를 빨리 전달할 방법입니다.

 

 '생각대로 살지 않으면 사는 대로 생각하게 된다' 라는 말이 떠오릅니다. 실시간으로 예상치 못한 사고나 일정이 있다면 계획은 무너집니다. 매순간 최선의 계획을 세우기 위해서 노력해야 합니다. 그 중심에는 가장 가치있는 피처를 선택하는 것입니다.

 

 

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

---

비지니스 담당자는 거대하고 모호하며 광범위한 요구사항을 작고
 실질적인 피처들로 분리하는 능력을 길러야만 합니다... 
그러므로 제품에 반드시 있어야 하는 피처와 단순히 있으면 
좋은 피처를 구분하여 제품이 가진 특징을 더욱 뚜렷하게 만들어야 합니다.

 

 비지니스 담당자라고 하지만 이는 개발자에게도 필요한 덕목입니다. 전체 요구사항을 다시 개발을 위해서 잘게 쪼개는 작업이 필요합니다. 무엇이 가장 중요한지 우선순위를 세우는 것, 그렇지 않은 후순위를 정하는 것 이 안목을 기르기 위해 노력해야 합니다.

 

 

몇 번의 개발 주기로 피처를 개선하세요

---

마감일까지 기반을 얼마나 만들 수 있을지, 얼마나 많은 피처를 배포 일정에 맞추어
개발할 수 있을지 생각하며 프로젝트를 진행하기 보다는 작고 간결한 버전으로 시작하세요.
제품이 가진 피처를 버전이 올라갈수록 개선하므로 언제든지 최상품을 배포할 수 있습니다.
개발주기마다 피처를 개선하는 작업을 반복하세요

 

 항상 마감일이라는 큰 틀 안에서 얼마나 많은 기능을 개발할지 고민했었습니다. 그런데, 큰 그림을 그려서 작고 간결한 버전으로 먼저 만드는 습관을 들여야 함을 알았습니다. 내가 해야 할 일은 엄청나게 많은 피처들을 하나라도 더 개발하는 것이 아니라 실제 동작하는 소프트웨어라는 뼈대를 만들어가면서 살을 붙이는 것입니다. 무작정 성을 쌓는 것과 틀을 다지며 큰 그림을 보고 가는 것은 정말 다르다는 생각이 들었습니다.

 

 

피처는 계속 추가되고 개선됩니다

---

오직 테스트만이 결함을 최소화하는 방법입니다. 
피처를 추가하거나 개선할 때마다 더 많이 테스트해야만 
더 나은 소프트웨어를 만들 수 있습니다.

 

 피처를 안정적으로 개발하기 위해서 얼마나 테스트가 중요한지도 많이 설명하고 있습니다. 피처개발은 완료, 미완료 2가지만 있을 뿐 90%는 없기 때문에, 오류 없이 완료가 되어야 합니다. 따라서, 테스트를 하는 것이 정말 중요합니다.

 

 

개발 주기가 끝날 때마다 반드시 비즈니스 테스트를 수행합니다

---

약 2주의 개발 주기마다 제품에 새로운 피처를 추가하세요.
새로운 피처가 잘 작동하는지 뿐만 아니라 이전에 있던 피처들에 문제는 없는지도 확인해야 합니다...
테스트에서 사용하는 비지니스 용어로 피처를 서술하고
그 테스트가 자동으로 수행되도록 하여 해당 피처가 잘 작동함을 보장할 수 있다면 좋겠죠.
그런 방법 중 유명한 것이 바로 인수테스트 주도 개발입니다.

 

 개발을 하다보면, 다른 기능을 수정하거나 다른 기능을 침범하는 일이 있습니다. 그렇다면, 새로운 개발 때문에 과거 개발 코드들이 영향을 미치는 경우가 있을 것입니다. 따라서 지속적인 테스트로 신구 조화가 잘 이루어지는 항상 예의주시해야 합니다.

 

 

개발 단계에서도 더 자주 테스트를 수행해야만 합니다

---

개발자도 자동화된 전체 테스트를 진행해야만 결함을 조기에 발견하고 
수정하여 제품을 더 안정적으로 만들 수 있습니다...
개발자에게 테스트를 먼저 작성하게 한 뒤, 그 테스트를 통과하게끔 제품을 개발하는 것입니다. 
이 방법이 테스트주도개발입니다.

 

 또한 테스트를 먼저 작성하면서 개발을 하는 것이 작업 단위를 더 작게 쪼개고, 설계를 고민할 수 있다는 점에서 굉장히 도움이 됩니다. 이미 개인프로젝트는 이와 같은 방식으로 진행하고 있습니다. 피처를 개발할 때는 테스트 주도 개발을, 전체적인 테스트를 확인할 때는 인수테스트를 활용하도록 합니다.

 

피처를 개발할 때마다 설계를 개선해야 합니다

---

개발팀은 각 피처를 개발할 때마다 반드시 그 피처를 지원하도록 설계를 개선해야 합니다. 
설계를 올바르게 유지하려면 지속적으로 설계를 개선해야 합니다. 
올바른 설계를 유지하는 일을 리팩토링이라 부릅니다.

피처 단위로 개발하려면 테스트와 리팩토링을 함께 진행해야합니다. 
이 개발 방법의 본질이 테스트와 리팩토링에 있기 때문이죠.

 

절대적으로 완벽한 소프트웨어 설계와 개발은 없습니다. 시간이 지나면서 레거시가 되고 새로운 기법과 새로운 구조에 맞춰서 변경이 필요할 수 있습니다. 이를 리팩토링이라고 명시하고 있습니다. 피처를 개발할 때는 꼭 테스트와 리팩토링을 고려해서 하도록 해야 겠습니다.

 

 

-Chapter2-

 

 

가치란 무엇인가?

---

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

가치를 정했다면 망설임 없이 피처를 개발하여 제품을 배포하도록 하세요.
그리고 사용자에게 의견을 들어야 합니다. 
이 과정을 반복하는 것이 핵심입니다

 

가장 중요한 것은 만드는 제품이 실제 사람들에게 도움이 되어야 하는 것입니다. 따라서, 내부적으로 여러가지 가치를 정했다고 하더라도 결국 중요한 것은 사용자에게 피드백을 받는 것입니다.

 

 

물론 힘든일입니다

---

중요하게 여기는 가치에 집중하세요
실제로 작동하는 소프트웨어가 짧은 주기로 배포돼야 합니다 
그래야만 우리가 원하는 것이 진정 무엇인지 깨달을 수 있습니다

가능한 한 피처의 크기를 작게 쪼개어 만드세요. 
그래야만 프로젝트의 진행상황을 쉽게 알 수 있습니다
우리에게 필요한 계획, 관리, 그리고 기술적인 것을 항상 배워 나가세요. 
그래야만 프로젝트를 빠르게 진행할 수 있습니다

 

아직 이러한 과정을 경험해보지는 못했지만 이런 흐름으로 갈 것 같습니다. '이렇게 짧은 주기로 배포해야하나?', '좀 더 완성도 있게 만들어서 배포하면 되지 않을까?' 라는 생각을 시작해서 '짧은 주기동안 가장 중요한 가치는 무엇일까?' , '가치를 어떻게 고객에게 전달할 수 있을까?'와 같은 생각 말입니다. 

 

 

뭉치면 살고, 흩어지면 죽는다

---

항상 팀 단위로 무엇을 할지 결정하고 일을 진행하고 결과를 관찰하세요. 
항상 쉽지만은 않습니다. 
훌륭한 소프트웨어를 만드는 것은 언제나 어렵습니다. 

그러나 우리의 팀이 가진 능력은 점점 더 향상되고, 
개발속도도 더 빨라질 것입니다

 

모든 팀이 한마음 한뜻으로 굴러가야 한다는 것을 의미합니다. 처음에는 삐걱거릴수도 있겠지만, 시간이 지나면 서로가 서로를 보완해주는 협업 관계라고 생각합니다. 현재팀도 서로가 어려움이나 필요가 있을 때 기꺼이 도와주며 이렇게 해결한 문제들이 많습니다. 앞으로 만나게 될 팀은 애자일 기반으로 가치를 생각하며 나아가는 조직이기를 기원합니다.

 

 

그리 단순하지 않습니다

---

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

 

오직 가치를 위해서 나아가야 합니다. 이 이야기를 정말 수도 없이 반복하고 있습니다. 고민되고 더디다고 느낄 때, 꼭 명심해야합니다. 피드백도 받아야 합니다. 내가 아무리 가치있다고 생각해도 사용자들이 가치가 있다고 느끼지 않으면 과감하게 버릴줄도 알아야겠습니다.

 

 

경영장의 자세

---

일하는 사람에게 권한을 위임하는 것입니다.

개발팀이"작동하는 소프트웨어를 보여주세요"를 받아드릴 때,
우리는 프로젝트가 어떻게 진행되는지 알 수 있습니다

 

이 책의 챕터 2에서는 경영자들을 위한 조언들이 있는데, 대부분의 역할은 일하는 사람에게 권한을 주는 것입니다. 투자와 큰 계획과 그림은 가지고 나가지만, 각 팀들에게 작업하는 권한을 적절히 위임하는 것이야말로 경영진의 역할입니다. 개발팀에 권한을 위임한만큼 책임감을 가지고 기한 내에 경영자들, 사용자들에게 동작하는 소프트웨어를 보여주는 것이 필요하다고 생각합니다.

 

 

모든 길이 전부 구불거린다면?

---

야영지 규칙을 따릅니다. 
야영지는 그곳을 발견했을 때보다 떠날 때 더 나은 곳이어야 한다는 규칙입니다. 
피처가 작동한 이후에는 코드를 정리하세요. 
정리는 자주 할수록 좋습니다

 

리팩토링에 대해 적절한 비유를 설명하고 있습니다. 항상 리팩토링을 염두하고 코드들이 조화를 이룰 수 있도록 신경써야 합니다. 저는 가끔씩 회사코드든 개인 프로젝트든 당시에는 최선이라고 생각했던 코드들의 빈틈이 보입니다. 좀 더 효율적인 구조나 개선점들이 보입니다. 이럴 때, 적절한 시기를 선택해서 리팩토링을 합니다. 내가 보기 좋은 코드가 남도 보기 좋다고 생각합니다.

 

 

애자일 팀은 테스트를 통해 협업합니다

---

숙련된 애자일 팀은 인스테스트 주도 개발이나 
테스트 주도 개발과 같은 방법론으로 
자동화된 검증 방법을 사용하여 성장하는 제품을 만듭니다.

 

 애자일이 조직이 커져서 여러 팀들이 있더라도 이들은 모두 테스트를 통해 안전하게 협업합니다. 개인적으로 테스트코드를 만들어서 하고 있던 방식이 결국은 애자일 방식과 크게 다르지 않았다고 느꼈습니다. 그래서 내가 개발을 하더라도 100%아니지만 90%이상 부담이 없는 것은 서로의 테스트코드가 프로젝트를 지탱하고 있기 때문입니다.

 

 

애자일 방법으로 작업할 수 있는 일 단뒤로 쪼개질 수 없는 것이 있을까요?

---

작은 일로 쪼갤 수 없는 거대한 규모의 개발이 있다고 생각하지 않습니다.

 

네, 결국 규모가 크든 작든 모두 작은 단위로 쪼개기가 가능합니다. 우리가 큰 상어든 고래든 잘게 부위를 나누면 모두 쪼개기가 가능한 것과 비슷한 것 같습니다. 항상 작은 일로 쪼개는 것을 다시한번 명심합니다. 

 

 

정리

---

이 책은 어려운 개념없이 굉장히 쉽게쉽게 읽혔습니다. 계속해서 반복하는 것은 작동하는 소프트웨어 만들기, 가치를 전달하기, 피처를 작게 쪼개기, 테스트와 리팩토링하기입니다. 어떻게보면 굉장히 당연한 이야기들만 있다고 생각 할 수 있습니다. 하지만 제 입장에서는 애자일 문화가 회사 문화가 아니므로, 상당히 흥미롭고 재미있게 읽었습니다. 머리속으로 이런 조직에서 일하는 것은 어떤 것일지 상상하며 읽어 간접경험을 할 수 있었습니다.

 

결국 한번에 얼마나 대단한 가치와 기능을 만드는 것은 중요하지 않다고 생각합니다. 사용자의 피드백에 따라 가치는 계속 변하며 10가지 기능을 준비했을 때, 어떤 것이 가장 반응이 좋을지 예상할 수 없습니다. 단지 매 순간마다 최고의 가치를 우선순위로 두어 피처로 만들고 협업하는 것입니다. 짧은 주기로 피드백을 통해서 계속 나은 가치를 만들 수 있습니다.

 

챕터 2에서는 경영진들을 위한 이야기도 나오는데, 이들은 결국 일하는 사람들에게 비전과 신뢰를 제공하는 것이 중요합니다. 아직 경영진과는 괴리감이 깊어서 이해하지 못했지만, 반대로 내가 어떻게 경영진에게 잘 보여질 수 있을지 고민했을 떄, 작동하는 소프트웨어를 보여주는 것입니다.

 

요즘따라 개발 기술과 능력도 중요하지만, 평소에 어떤 생각을 가지고 개발을 해야 하며, 서로 협업을 하는데 중요한 것은 무엇인지 관심이 많아지고 있습니다. 절대 나혼자 모든 것을 할 수 없습니다. 서로가 정말 같이 성장하며 보람을 느끼는 문화에 꼭 일조하고 싶습니다.