꼰대 개발자~

푸념! 요즘은 과거 "성문법", "맨투맨"식 영어 교육시대를 살아가는 느낌입니다. 영어를 배우는건지 영어를 가르치기 위한 용어를 배우기 위해 공부를 하는지 알 수 없는 시대! 용어 보다는 실제로 경험해온 개발방법에 최근 정리된 방법론들을 해석해 봅니다. 

나 같은 고대(?) 개발자들은 아직도 애자일에 대한 적응이 힘들다. 솔까말 개발리소스를 최대한 갈아 넣어서 최대한의 이익을 낸다라는 느낌도 버릴 수 없고 워터플에 익숙하지만 시대의 흐름이므로 고대(?) 개발자로써 애자일에 적응해 보자.

간단히 애자일은 짧은 주기로 설계 - 개발 - 테스트 - 리스크분석의 주기를 반복하는 개발방법이다. 1-2주 정도의 기간동안에 할일에 대해서만 생각하기 때문에 설계와 분석에 대한 코스트가 적게 들고 계속해서 Client/Owner의 feedback을 받기 때문에 방향성의 공유와 사업의 변경에 유연하게 대응 할 수 있다.

고대 시대에 프로토타입 개발 방법론에서 좀더 유연한 개발을 강조한 개발방식되겠다. 고대 시대 프로토타입 개발 방법론의 최대 단점이 고객의 무분별한 개입과 조급함을 초래한다는 단점이 언급되었었는데 이걸 장점으로 승화(?) 시킨 방법론이라 생각할수있을듯... 

애자일이 성공하려면?

• 경영진의 의지 / 마인드가 제일 중요합니다.
  • 경영진이 장/단기 비전제시나 단기 계획에 대한 방향성을 위한 경영 정보를 공개하지 않는 성향이면 포기하세요.
  • 스크럼은 빠른 의사결정과 실행력이 최고의 장점인데 경영진이 보고를 통한 의사결정을 하려 한다면 포기하세요.
• 관계자 모두가 같은 큰그림을 보는것이 중요합니다.
  • 짧은 주기로 분석하고 일을 진행하다보면 자연스럽게 방향성을 잃어 버릴수있습니다.
  • 내가 만든 백로그도 못찾는 사태가 벌어지고 서로 상반되는 task들도 만들어집니다.
  • 이번 주기에는 교실을 만듭시다, 이번주기는 교무실이요 어? 우리가 뭘 만들고 있는거지?
  • 우리는 학교를 만들고 있다는걸 이 학교는 어떻게 만들것이라는거 구조가 변경될때 마다 변경된 최종 그림을 공유할 필요가 있다.
• 기간과 목표물이 명확한 프로젝트에 애자일을 끼워넣지 말자

개발프로세스 측면에서 애자일? ( JIRA가 요즘 거의 표준이지요? )

• SPRINT
  
  • 절차
    • 각종 요구사항 / 개선사항 / 개발요건등을 백로그에 쌓아 둡니다.
    • 스프린트 시작시점에 백로그에서 우선순위에 따른 개발 요건들을 스프린트에 넣습니다.
    • 담당자들을 배정하고 스프린트들을 시작합니다.
    • 스프린트를 마칠 시점에 업무들에 대한 평가를 하고 마치지 못한 일들에 대한 전략을 수립합니다.
    • 반복합니다.
  • 특징
    
    • 스프린트 계획 수립시 현재 개발 리소스 / 기간을 확정 할수있으므로 업무 분배가 쉽습니다.
    • 짧은기간에 성과와 리스크를 시각화할 수 있습니다. 잠재된 리스크를 빨리 발견하여 제거 할 수 있습니다.
    • 리더에 입장에서 보면 팀원들의 잘하는거 / 작업처리량등이 자연스럽게 드러나서 코칭 포인트를 찾아낼수있습니다.
    • 짧은 기간이지만 나름 계획으므로 스프린트 기간에 새로운 일감니나 리스크가 발생하면 스프린트를 유기하기 힘들다.
      • 스프린트의 변경을 최소화 해야합니다. 그런데 PM이나 PO입장에서는 일정이 중요하므로 스프린트 변경이 발생할수밖에 없다 -  이런 형태의 업무 / 비지니스 형태면 스프린트 하지 마세요.
      • 칸반 / 스프린트를 프로젝트 / 운영 타스크의 유형에 따라 분리 적용하세요. - 칸반으로 통일하자 스프린트로 통일하자는 꼰대입니다.
• KANBAN
  • 일감이 생길때마다 지라를 생성하고 담당자를 배정합니다.
  • 의사결정과 업무가 수시로 생기고, 업무가 외부에서 생기는경우 적합합니다.
  • 현재의 일감들의 상태를 한눈에 볼수있어서 좋습니다.
  • 그러나 성과 측정 및 마일스톤 및 목표점 찾기가 힘듭니다.
  • 보안으로 OKR과 TDD가 있습니다

조직 관리 측에서서 애자일

• Daily Sync / Stand up
  • 필수적으로 진행하는것이 좋습니다.
  • 그날 그날 하는 일에 대한 상세한 공유가 필요합니다.
  • 짧게 공유하고 더 논의가 필요한 부분은 따로 시간을 잡는것이 좋습니다.
  • 업무 지시나 방향성의 변화는 없는 공유에 의미를 두어야 합니다.
• 1on1 Meeting
  • Daily Sync를 통하여 스크럼을 생성했다 하여도 리더와 팀원간의 합을 맞출 부분이 필요합니다.
  • 무조건 들어주는 기술이 필요합니다.
  • 개인적인 관심사 / 고민등의 공유는 리더쉽에 지대한 영향을 미칩니다.
• Pair Programming
  • 주기적으로 하는것도 좋지만 어느정도 스탈이 맞았다면 필요시에만 하는것도 좋습니다.
  • 새로운 아키텍처나 프락티스의 도입시에 유용합니다.
• Code Review
  • 간단한 변경이 아니고 로직의 변경이 많은 경우 PR을 나눠서 하도록 가이드하는것이 좋습니다.
  • 공통 Lint를 적용하는것이 좋습니다. Lint가 만들어내는 변경사항은 PR리뷰를 어렵게 합니다.
  • 코멘트는 최대한 드라이하게 리뷰내용이 개인적인 습관의 문제라면 pair programming이나 1on1을 통하여 교정합니다.
  • PR에서 싸우지 않습니다 - 논쟁 발생시 당사자들을 모아서 해결합니다.
• 회고
  • 팀의 성과 / 개인 성과를 명확히 구분하여 공유합니다.
  • KPT 를 통하여 에로사항을 간접적으로 인지합니다.
  • Problem이 관계에 문제가 있다면 바로 결정하지 말고 pending하고 당사자들을 모아서 해결합니다.
  • 회고 준비도 상당한 시간을 소모하므로 정리하는 부분도 팀원들과 나누기 위한 아이디어가 필요합니다.

고대 개발자들의 애자일 리더쉽 전략

• "너의 성과는 팀의 성과다, 팀이 잘되야 너도 잘된다."라는 생각은 꼰대입니다.
  • 애자일의 성공여부는 개인의 역량과 동기부여가 전부입니다.
  • 개인의 성과를 모아서 팀의 목표 달성 / 성과를 만들어 낸다는 느낌입니다.
• 스프린트 시작때 task들에 대해 성과점수와 성과인정 방법에 대한 적절한 공유가 필요합니다.
  • 내가낸 성과인데 같이 먹는건 장기적으로 스크럼을 깨뜨릴수있습니다.
  • task들에 대한 테스트 방법등에 대해 질문하고 인정점위를 정합니다.
  • 이때 자연스럽게 왜 해야하는가와 목표가 설정됩니다.
  • 이때 성과 측정방식으로 Unit Test의 형태로 진행합니다 - 자연스럽게 품질도 보장되고 성과 측정도 됩니다.