클린 애자일 | Clean Agile(Back to Basics) | Robert C. Martin

인턴십에서 리더님께 선물받아 읽은 책 

🟩 인상깊은 부분 & 이유

1. (p15) 완성된 네 문장은 다음과 같다. 공정과 도구보다 개인과 상호작용, 포괄적인 문서보다 작동하는 소프트웨어, 계약 협상보다 고객과의 협력, 계획을 따르기보다 변화에 대응하기

애자일 기법이 추구하는 방향이 네 가지 문장에 집약적으로 정리된 것 같다는 생각이 들어 꼽았다.

2. (p21) 마감 기한은 한번 정해지면 절대 바뀌지 않는다. (...) 동시에, 요구 사항은 대단히 유동적이고 절대 확정되지 않는다.

마감 기한은 변하지 않고, 요구 사항은 유동적이므로 애자일 기법이 필요한 것 같다.

3. (p25) 그러는 동안 요구사항은 여전히 계속 바뀐다. 새로운 기능이 계속 추가되고 기존 기능은 계속 빠지거나 변경된다. 앞 단계로 돌아가서 이 변경 사항을 재분석하고 재설계하고 싶지만, 이제 몇 주밖에 남지 않았다.

폭포수 3단계의 치명적인 문제점을 되짚는 문장이라고 생각한다. 이런 현실적인 문제점 때문에 애자일 기법을 더 추구하게 된 것이라고 생각이 들었다.

4. (p32) 애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다. 최대한 빨리 알아야 상황을 관리할 수 있기 때문이다.

실제로 프로젝트를 진행하게 되면 최초 계획에서 엎어지는 부분과 변경되는 부분이 지속적으로 발생한다.

5. (p54) 기존 코드가 바로 재설계된 시스템이 구현해야 할 동작을 정확하게 기술한 유일한 문서다.

기존 코드를 참고하고 분석하는 부분도 새로운 기능을 추가하는 것만큼 중요하다는 생각이 든다.

6. (p55) 소프트는 바꾸기 쉽다는 뜻이다. 따라서 소프트웨어는 바꾸기 쉬운 제품이다. 기계의 동작을 빠르고 쉽게 바꾸는 방법이 필요했기 때문에 소프트웨어를 발명한 것이다. 동작을 바꾸기 어렵게 만들고 싶었다면, 하드웨어라고 불렀을 것이다.

소프트웨어는 지속적으로 변경 사항이 발생할 수 밖에 없는 구조이다. 책에서는 소프트웨어를 변경하기 어렵게 만들었다는 것 자체가 소프트웨어의 진정한 존재 이유를 훼손한 것이라고 말하고 있는데 인상깊었다.

7. (p57) 건드리는 순간 망가질 것이기 때문이다. 망가뜨리는 순간, 당신의 코드가 되기 때문이다. 결국 당신은 코드를 정리해서 개선할 수 있었던 기회로부터 뒷걸음질 친다. 이것은 두려움에서 오는 반응이다.

이미 잘 돌아가고 있는 코드에 추가적인 기능을 얹고 싶을 때 기존 코드가 망가질까봐 건드리는 것을 굉장히 망설였던 순간이 생각이 났다.

8. (p62) 해결책이 없을 때는 '아니요'라고 말해야 한다. (...) 프로그래머는 무엇이 가능한지를 아는 사람이다.

가능한 것과 불가능한 것을 명확히 구분해내는 것은 생각보다 어렵다는 생각이 든다.

9. (p68) 팀에서 프로그래밍을 하다 보면, 때로는 경험이 많은 사람과 때로는 경험이 적은 사람과 밀접하게 일하게 된다. 누가 어떤 일을 할지 팀 전체가 함께 결정할 권리가 있다.

협업에서 팀 전체의 의사소통과 결정이 중요하다는 생각이 들었다.

10. (p79) 그저 반복 주기 동안 포인트를 얼마나 처리할 수 있을지 짐작해 본 것일 뿐이다. 이 짐작은 아마 매우 부정확할 것이다.

애자일은 큰 작업을 쪼개서 반복 주기를 반복하며 완성도를 높이는 작업이다. 매번의 반복이 의미있고 그 안에서 도출해내는 거라는 생각이 든다.

11. (p81) 이번 반복 주기는 실패일까? 아니다. 반복 주기에 실패란 없다. 반복 주기의 목표는 관리자에게 데이터를 제공하는 것이다. (...) 그렇게 하지 못했더라도 데이터는 만들어 냈을 것이다.

반복을 거듭하며 얻은 데이터로 점차 정확성을 높이는 것이 애자일인 것 같다.

12. (p82) 프로젝트는 스토리 더미에 구현할 가치가 있는 스토리가 더 이상 없을 때 끝난다. (...) 그 당시 이 스토리가 중요하긴 했는데 훨씬 급한 다른 스토리를 먼저 구현해야 했다. (...) 원래 중요했던 스토리가 이제는 별 볼 일 없어져 버렸다.

애자일의 스토리 기법을 거치면 꼭 필요한 일에 더 집중할 수 있게 되는 것 같다.

13. (p105) 시스템이 테스트를 통과하는지 확인하는 사람은 QA가 아니다. 그렇다면 누가 확인해야 할까? 물론 프로그래머다.

QA가 모든 테스트를 도맡는 줄 알았는데, 코드의 품질에 대해서는 여전히 개발자의 책임이라는 생각을 다시금 하게 됐다.

14. (p105) 사용자와 프로그래머가 물리적으로 가까이 있을수록 의사소통하기 좋을 것이다. 그러면 개발도 더 빠르고 정확하게 할 수 있을 것이다.

사용자는 사용성이 좋은 프로그램을 원하기 때문에 사용자와 의사소통을 가까이서 할수록 사용성이 좋은 프로그램을 만들어내기 수월할 것이다.

15. (p116) 밤에 저지른 실수를 만회하느라 진짜 제정신인 시간을 계속해서 써야만 했다. (...) 결과적으로 우리가 절약한다고 생각했던 시간보다 훨씬 더 많은 시간을 추가로 써야 했다는 점만 밝혀 두겠다.

반드시 개발 분야에만 해당되는 이야기가 아니라는 생각이 든다. 조급한 마음이 들어도 지속 가능한 속도로 일하는 것이 결과적으로는 더 효율적이고 지속적인 방식같다.

16. (p120) 하지만 전문성을 키우면서도 넓게 알아야 한다. 전문성을 발휘할 수 있는 업무와 그 외 분야의 코드에 대한 업무를 두루 맡아야 한다. 언제나 잘하는 영역을 벗어나서 일할 수 있어야 한다.

반성하게 만드는 문장이었다. 언제나 잘하는 일만 맡게 되는 것이 아니기 때문에 전반적인 시스템 동작을 잘 이해하고 있어야 한다는 생각이 든다.

17. (p.122) 아무도 코드를 공유하지 않았다. (...) 당연히 의사소통이 불편했다. (...) 더 나쁜 것은 완전히 똑같은 코드의 중복이 말도 안될 정도로 많았다.

저자는 팀 실천 방법 중 하나로 코드를 공동소유해야 한다고 강력히 말한다. 모든 코드에 공동의 책임이 있고 모두에게 개방되어야 의사소통, 협업, 인적 자원의 효율이 올라간다고 보고 있는데 개인적으로 깊이 와닿아서 꼽게 되었다.

18. (p 139) 코드를 건드리는 것을 두려워하고 코드를 망가뜨릴 때 당신에게 벌어질 일을 두려워한다. 그래서 코드를 정리하는 데 실패한다. (...) 완벽한 테스트 묶음이 있으면 코드를 고치는 두려움이 사라진다.

이 문장이 애자일 방법론에서 TDD를 함께 추구해야 하는 이유를 관통하는 문장 같았다.

19. (p 154) 어떤 방법론을 택하든 상관없이 결국에는 프로세스를 당신의 필요에 맞게 고치고 다듬게 될 것이다.(...) 올바르게 하는 것 때문에 고민하지 말라.

애자일을 너무 엄격하게 받아들일 필요는 없을 것 같고 유연하게 받아들이되 애자일의 가치를 따르는 방식으로 나아가는 것이 더 중요한 것 같다.

20. (p200) 실천 방법이 아니라 가치에 집중하자. (...) 사람들은 그 가치를 깨닫기 전에는 일하는 방식을 바꾸지 않는다.

가치를 먼저 깨닫고 나서 그 실천 방법에 대하여 이야기 하는 것이 일하는 방식을 제대로 바꾸는 데 더 도움이 된다는 생각이 들었다.

---

🟩 느낀 점 및 현업 적용 방안

애자일의 핵심은 '반복을 거듭하여 변화에 유연하게 대응하자' 인 것 같다. 책을 읽는 내내 애자일이 추구하는 가치들이 정말 많이 와닿았고, 실제로 필요하다고 생각했다. 다만, 실질적으로 적용하는 데에는 어려움도 많이 따르겠다고 생각했다. (특히 TDD같은 적용이) 책에서도 언급됐듯이, 짧은 반복주기를 위해서는 높은 숙련도가 요구되는데, 아직 개발 실력이 미숙한 상태에서는 애자일 적용이 쉽지 않겠다는 생각도 들었따.