과거를 잘 돌아보는 법
우선 강사님 첫인상이 기억에 남는다. 마치 가만히 있어도 "나 SW 개발 외길을 수십년 걸은 사람이야" 하는 아우라로 가득하다.
처음엔 주변 사람 몇몇이 모여 각자 소개와 온 목적을 이야기하는 시간을 갖는다. 그리고 다시 모여 처음 모였을때 어땠는지 에 대해 회고하기 시작한다. 처음 이야기할 때는 별 생각 없었으나, 다시 모여 회고하니 "내가 이 자리에 온 목적을 왜 구체적으로 생각하지 않았는지" 뒤돌아보게 됐다. 아주 작은 변화이지만 이런식으로 돌아보는 것이구나 하며 스스로 납득했다. 작은 것이라도 아~! 로 시작하는 생각을 떠올리게 되면 그 회고는 잘 된 회고다. 회고는 팀원들 끼리 뿐만 아니라 개인 단독으로도 꾸준히 지속적으로 하는 것이 중요하다.
"회고는 자전거다". 지속적으로 페달을 굴리지 않으면 넘어진다. 회고를 하는 목적이 실용적인 것들만 있는게 아니다. 문제를 해결하기 위해, 프로세스를 개선하기 위해, 원활하게 정보를 공유하기 위해 서만 하는 것이 아니다. 감정을 공유하기 위한 목적도 있다. 이지점에서 아! 탄성이 나왔다. 나는 왜 감정 공유란 부분을 완벽하게 잊고 살았을까. 업무 자체의 양이나 난이도보다도 동료, 조직원간 감정, 관계 상 문제로 업무 효율이 떨어지는 경우가 부지기수다. 평상시에 회고를 통해 지속적으로 그런 문제들을 양지로 끌어내면 응어리를 풀거나 타협할 수 있다. 꼭 업무시간, 회의시간에는 업무와 관련된 얘기만 해야되고 감정 이야기는 하면 프로답지 못한 것이 되는 전설과 같은 이야기는 이제 식상하다. 프로는 결국 성과로 이야기하면 된다.
회고를 잘 하려면 어떻게 해야하나. 먼저 회고할 시간이 필요하다. 출근해서 퇴근할때까지 바빠 정신없는 가운데서 뭔가를 돌아보기가 어렵다. 일을 잘게 쪼개 중간중간에 30분마다 1시간마다 한번씩 습관화하는게 좋다. 그렇지 않으면 루틴, 일상이라는 관성에서 벗어난 관점을 취하기 어렵다.
회고할때 뭘 회고하면 되나. 내가 뭘했는지, 어떻게 했는지, 놓친건 없는지, 뭐가 더 필요한지. 더해야할건 뭔지. 이제 더 뭘할건지 등을 생각한다. 동료와 회고시에는 상대방으로 하여금 구체적인 사실, 기억 등을 떠올리고 몰입할 수 있도록 질문을 던져주는 것이 좋은 Skill 이다.
애자일 회고기법은 문화로 정착이 되는 것이지 개발방법이나 툴로 같이 저거 좋다던데 한번 해볼까 하는 식의 접근으로는 효과를 보기 어렵다고 한다. 문제가 생겼을때 문제 자체에 초점을 두는 팀과 문제를 만들어낸 사람에게 초점을 두는 팀이 있다고 쳐보자. 문제만든 사람을 갈아치우는 것과 문제가 발생되는 시스템을 바꾸는 것. 어느 것이 조직과 개인에게 더 나은 방법인지 모르는 사람은 없을 것이다. 하지만 그런 개인들이 모여있어도 조직문화나 책임자의 인식이 그대로라면 달라지는 건 없다.
애자일은 만병통치 약은 아니다. 어떤 변화든 간에 그것을 받아들일 생각이 없거나 니즈가 없는 곳에서는 일어나기 어렵다. 남들부터 바뀌길 바라는 건 오버고 개인부터, 작은 팀 단위부터 시작해보자. 최소한 자신의 삶과 팀원간 분위기부터가 달라지기 시작할 것 같다.
'호기심, 관심사' 카테고리의 다른 글
| 회고의 목적 (0) | 2016.08.30 |
|---|---|
| 훈육 거름망 (0) | 2016.08.26 |
| 가난한 나라가 가난한 지리적 이유 (1) | 2016.08.21 |
| 사업가를 위한 비즈니스 모델 그리기 ( by 박성혁 ) 강의 (0) | 2016.08.19 |
| 자녀가 부모와 대화를 하지 않으려는 이유 (0) | 2016.08.15 |
애자일(Agile)은 무엇인가요
"소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다."
내가 하는 두가지 메인 업무중 하나가 SW Requirement 작성이다. 고객이 요구하는 기능을 명세서로 만들면 SW 개발자가 이 문서를 가지고 설계를 하고 실제 프로그래밍을 한다. 돌아보건데 문제가 생기는 대부분은 각자의 Guessing 때문이였다. 고객 요구사항 분석하는 앞단에서 guessing 이 들어가 이런걸 원하나보네 하며 명세서를 작성. 개발자는 명세서를 보고 이렇게 만들면 되겠구나 guessing 해서 개발을 진행. 릴리즈된 SW를 검증하는 쪽도 명세서와 SW 를 보고 guessing 해서 이렇게 요만큼 test하면 되겠구나 하고 진행한다. 각자 나름대로의 guessing 들이 모여 다양한 문제와 해야될 일이 쌓이고, 납기는 어느새 코앞으로 다가온다. 우리 이래서야 되겠는가. 소 잃고 외양간 고치지 말고 각 단계별로 모여 추측하지 말고 도장 찍어가며 합시다. 좋다. 그럽시다. 소통. 상호작용 중요하지요. 이 과정에서 바뀌는게 있더라도 서로 짜증내지 맙시다. 서로 변화의 당위성을 공감한다.
어설프게 정리해본 시나리오지만. 그렇다. 난 제일 어려웠던 것은 변화도 아니고 능력도 아니고 바로 서로간 공감이였다.
# 애자일(Agile) 은 무엇인가
- 방법론?, 프로세스?, 일하는 방식?, 애자일이란 용어 자체의 뜻은 '기만한', '재빠른', '민첩한' 이라는 뜻.
# 애자일 소프트웨어 개발 선언 中
- 공정과 도구보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 소프트웨어를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응하는 것을 가치있게 여긴다.
# 고객의 요구사항 : 야외에 있는 여성의 초상화를 그려주세요. ( 구체적이지 않고 모호함 )
- 전체에 대한 스케치 => 애자일 선언문에서 말하는 '동작하는 SW'
- 피드백 반영, 빠르게 내용과 방향성 수정.
- 옷 색, 머리색 언제든지 변경, 반영
# 애자일의 개념을 잘 실천하기 위해 만든 도구들
: 스크럼(Scrum), 칸반(Kanban), XP(eXtream Programming), Lean SW Development
애자일은 일하는 방식, 문화. SW를 만드는 주체가 바로 사람이기 때문.문화가 되어야 할 것을 사람을 다그치는 채찍질로 사용한다면 안쓰니만 못하게 됨.
'호기심, 관심사' 카테고리의 다른 글
| Square vs Stripe 비교 (0) | 2016.03.08 |
|---|---|
| 트럼프나 샌더스가 뜨는 이유 (0) | 2016.03.07 |
| 2016 미국 대선 슈퍼화요일 이후 (0) | 2016.03.05 |
| 직장인이 임대소득이 있는 경우 건강보험료를 더 내야 하나? (0) | 2016.03.03 |
| 세상의 모든 문제는 두 가지로 나뉜다. (0) | 2016.03.02 |
