함께 자라기 애자일로 가는 길
책 소개
1달 책한권 2021년 7월에 읽을 예정인 책은
함께 자라기 애자일로 가는 길이다.
원래는 Head First PMP를 읽고 있었지만 600페이지가 넘는 이론서이기 때문에 다음달까지 읽는걸로하고 이번달은 가벼운 책을 읽으려한다.
현재 다니는 회사에서 다른직원들과 성장하고 싶기도 하고 애자일 방식으로 프로젝트는 어떻게 진행하는지 궁금했었기 때문에 이 책을 골랐다.
후기
정리를 마치고 마지막 후기를 남긴다.
이번 책은 얇았던만큼 생각보다 깊이있는 책은 아니었다. 3년차가 되면서 설계에 대한 중요성도 느끼고 도제학습하는 고등학생들이나 피텍을 하는 대학생들도 있어 함께 성장하고 싶어 함께 자란다는 말이 매우 궁금했다.
책은 200p정도인데 솔직히 아무리 압축해도 이런 심오한 내용들이 들어가기엔 부족하다. 솔직히 말하면 개발관련 서적보단 자기개발 서적에 가까웠다.
하지만 팀적으로 동기부여를 하고싶고 애자일을 팀에 도입하고 싶다면 한권정도 구매하여 팀원들과 같이 읽어보는것도 좋지 않을까 싶다.
개인으로서는 이책에서 애자일에 대한 상세 프로세스를 전혀 보지 못했기에 또 다른 서적을 찾아 추가 공부해야겠다는 생각을 했다.
자라기
- 개발자를 뽑을 때 경력만 보는 경우 실패할 확률이 높다. 최근에는 경력이 훤씬 모잘라도 더 일을 잘하는 경우가 많다. 때문에 기업에선 테스트나 협업에 대한 경험을 통해 뽑는것이 더 현실적으로 도움이 된다.
- 어떻게 채용을 해도 실패할 수 있기 때문에 새롭게 채용된 직원이 성장할 수 있는 시스템을 만드는것이 중요하다.
- 애자일 방식으로 프로젝트를 진행한다면 설계이후 오랜뒤에 개발을 하는게 아닌 설계와 개발이 거의 같이 진행되기 때문에 피드백을 빠르게 자주 받을 수 있어 개발자의 성장을 돕는다.
- 잡코리아의 조사에 따르면 일반적인 직장인은 40%정도가 1~2시간 정도의 자기계발을 하는걸로 조사되었다. 만약 본인이 1시간도 자기계발에 투자를 하지 않는다면 1년을 생각해보면 어마어마한 격차가 생길것이다.
- 개인이 성장하는것보다 집단으로 성장하는것이 속도가 훨씬 빠르다. 현재하는 업무를 A라고 한다면 이런 업무를 개선하는 작업인 B가 필요하고 업무를 개선하는 작업을 발전시키는 C작업이 필요하다.
- 새로운 지식을 배웠다면 기존것과 같이 사용하면서 어떻게 발전할 수 있을지 고민하라
- 내부적으로만 개선하는게 아닌 외부적인 평가도 간혹 필요하다.
- 혼자 작업하는것도 작업 결과물에 대해 개선할 점을 회고하는 과정과 그런 개선을 찾는 방법들을 발전시킬 방법들을 찾아야한다.
- 이런 평가가 동반되는 작업들은 자주 일어날수록 좋다. 1년짜리 큰 실험을 하기보단 1달, 1주 정도되는 작은 단위로 프로세스를 구성해라
- 성과를 보이기위해 작업하는것과 학습을 위해 작업하는것 중 학습을 위해 작업하는것이 성장에 도움이 된다.
- 설계부터 협상까지 전반적으로 다루는 소프트웨어 개발자가 프로그램만 작성하는 컴퓨터 프로그래머보다 유망하다.
- 실력을 개선할 동기가 있어야하고 적절한 피드백을 자주 받을 수 있어야 한다.
- 실력이 보다 난이도가 높은 일을 받으면 불안감이 커지고 실력에 비해 낮은 난이도의 일을 받으면 지루해진다. 이 사이에 적절한 난이도의 일을 해야 몰입할 수 있다.
- 만약 현재 주어진 일이 지루하다거나 불안하다면 몰입할 수 있는 전략이 필요하다.
- 만약 지루하다면 운동선수들이 모래주머니를 차고 훈련하듯 에디터의 도움을 최소화 한다던가 키보드로만 작업한다던가 하는 패널티를 부여한다. 또는 일을 일부러 어렵게 만드는 방법도 있다. 1시간 만에 일을 종료한다는 조건을 걸거나 디버그 없이 작업한다거나 테스트 코드를 상세하게 만들거나 리펙토링에 신경쓰는 등 하는업무에 제약을 걸어 난이도를 올린다.
- 불암감을 느낀다면 더 잘하는 개발자에게 질문을 하던가 협업을 요청하여 배우면서 작업을 한다던가 지루한 경우와 반대로 최대한 에디터의 최신기능의 도움을 받으면서 작업한다. 반대로 업무의 난이도를 낮추는것도 가능한데 최소한의 핵심기능만 들어간 버전을 목표로 작업함으로써 좀 더 쉬운 업무를 진행하는게 가능하다.
- 새로운 개발언어를 공부할때 이론을 보면서 단순히 이론만 보는게 아니라 실재라면 어떻게 적용시킬지 구상해보던가 직접 코딩하면서 공부한다. 표준 라이브러리를 찾아 읽어보며 해당 언어의 스타일을 파악한다. 오픈소스를 찾아 기능을 추가해본다.
- 실수를 예방하는것이 아니라 관리하는 것이다. 예로 미국의 산림청에서는 예전에는 예방을 하려했으니 예방을하려다 보면 가끔 일어나는 사고로 인해 오히려 더 큰 사고가 다는걸 알게되고 화재발생을 막는게 아닌 발생할 수 밖에 없는 화재들을 관리하도록 바뀌었다.
함께
- 뛰어난 개발자는 이미지와 다르게 협력과 커뮤니케이션 능력이 뛰어나고 개발에 들어가는 시간은 일반적인 개발자와 크게 다르지 않다.
- 같은일을 혼자할때보다 둘이한다면 추상화 규칙이 많아진다. 같은 일도 개인마다 보는 시각이 다른데 서로 다른 생각을 공유하다보면 서로다른것을 이어주기 위한 추상화가 필요하기 때문이다.
- 탑다운은 문제 해결 과정을 추상적인 숲에서 구체적인 나무로 내려오는 접근법이고 바텀업은 나무에서 출발해서 숲으로 올라오는 과정이다. 큰 그림을 보는 탑다운이 전문가 처럼 생각할 수 있지만 전문가일수록 탑다운과 바텀업을 업무에 특성에 따라 바꿔가며 작업한다. 명확한 목표가 있는 작업일수록 탑다운이 좋고 작업에 목표가 불문명할수록 이것저것 확인해보면서 작업하는 바텀업이 유리하다.
- 연구에 따르면 프로그램을 이해할 때 고수는 상호 참조 전략을 쓴다. 프로그램을 연구하면서 이해한 것을 도메인 어휘로 번역하고 이 도메인 어휘를 다시 프로그램상의 어휘로 바꿔 검증한다.
- 세계에서 뛰어난 개발팀들이 공통적으로 가지고 있는 특징이 있는데 그 중 하나가
삼투압적 의사소통이다. 팀이 가까운 거리에서 일하고 편하게 질문하며 각각의 멤버들이 본인들의 생각을 애기하며 정보를 공유한면서 본인에게 스며들게 되는걸 의미한다. - 개발의 추상화는 전략, 범위, 구조, 뼈대, 비주얼의 과정이 필요하고 개발은 분석, 설계, 구현, 테스트, 전개의 과정이 필요한데 프로젝트 전체 범위에서 이런 순차적인 단계의 일을 계획할게 아니라 이런 일정들을 최대한 빠르게 구현해서 자주 결과물을 보여주고 피드백 받아야 한다.
- 구글에선 관리자가 없는 팀을 만들기 위한 실험을 했지만 실패했고 관리자의 특징에 대한 연구를 지속하였다. 이런 연구에 대한 결과가 일부 공개되었는데
- 첫번째는 팀에 전문가가 있는것보다 서로 어떻게 상호작용하고 자신의 일을 어떻게 바로보는지가 훨씬 중요하다는 것이다.
- 두번째는 성공적인 팀은 심리적 안전감을 가지고 있다. 심리적 안전감이란 내 생각이나 의견을 애기하거나 질문을 해도 처벌하거나 놀리지 않고 실수하는것에 대한 두려움이 없는 조직문화가 있는것을 애기한다.
- 세번째는 이런 심리적 안점감을 위해 토론이나 교육을 제공하는것이 좋다는 것이다.
- 일반적으로 개발자들이 개발에 걸리는 시간을 예측할 경우 틀릴 확률이 매우 높고 오류가 난다던가 디버깅, 배포, 셋팅 등의 변수들과 또 개발하는 사람이 1명이 아니기 때문에 여러명이 같이 작업을 하기 때문에 예측한 것보다 훨씬 많은시간이 소요된다. 실제로 일반적인 보통 개발자들이 예측한 시간보다 2배에서 3배정도의 시간이 걸리는 경우가 많다는 소프트웨어공학 연구가 있다고 한다.
- 관리자가 팀에게 일을 부여할 때 보통 각각의 일을 주고 개별적으로 일을 주는 경우가 많은데 애자일에서는 팀 전체에 3가지 일을 주고 완료되면 또다시 3가지 일을 주는 식으로 일을 팀이 전체적으로 해결하게 한다. 이런식으로 일을하면 매번 새로 조직화하고 일을 분배하며 서로 일을 배우는 시너지가 생길 수 있다.
- 애자일에서는 이렇게 모두가 같이 일을 한다. 위에서 말한것처럼 여러명이서 일을 할때 일정관리를 실수 없이 하는것은 매우 어렵지만 애자일에서는 다같이 하기 때문에 먼저 일을 마친사람이 다른사람들을 도우면 되어 리스크가 분산된다. 또 같이 하기 때문에 이번 프로젝트로 뭔가 새로운 발견이 있을 때 팀적으로 성장할 수 있다.
애자일
- 이전에 소프트웨어 프로젝트를 진행할 때 주로 사용되던 방법은 계획주도의 방식이었는데 이런 방식을 사용했던 것은 초반에 계획을 정교하게 함으로 써 실행단계는 간단해지고 모든 변수들을 예측가능하게 만들 수 있다고 생각했기 때문이다. 애자일은 이런 변수들을 완벽하게 통제할 수 없다는걸 인정하고 불확실성에 어떻게 대처할지 고민한 결과물이다. 이런 애자일은 불확실성이 높은 프로젝트에 적합하고 불확실성을 제거하기 위해 짧은 주기로 개발 사이클을 완료하여 피드백을 더 많은 사람들에게 자주 받아 완성도를 높인다.
- 애자일을 한문장으로 압축하면
고객에게 매일 가치를 전하라입니다. 고객에게 어떻게 보다 일찍 보다 자주 피드백을 받을 것이며 이런 피드백을 자주 받음으로써 이번 프로젝트에서 고객에게 중요한것이 무엇인지 파악하여 완성도를 높여야 합니다. - 70여개의 회사에 애자일을 도입한 후 만족도에 대해 조사를 했는데 73%의 회사는 만족스럽다는 답변을 했다. 이런 조사를 통해 어떤점이 애자일을 성공하게 했는지 분석하였는데 고객참여가 가장 높은 순위였다. 즉 애자일의 중요한점은 고객에게 자주 피드백을 받아야 한다는 것이다. 이외에도 리펙토링, 코딩 후 자동화 단위테스트 붙이기, 코드 공유가 주요 원인으로 뽑혔다.