2022년 하반기 회고

일정 산출, 개발 문화, 팀 문화.. (한 단어로 뭐라고 표현할 수 있을까?)

 

생각이 많았고 팀원들과 대화도 많이 하며 

고민을 정리하다보니 팀으로써 어떻게 움직여야 좋은 결과가 나올 수 있을까에 대한 생각이 되었다.

그리고 마침 12월이기에 2022년 하반기를 회고하는 글이 되었다.

 

 

목차

• What is the Problem?
• Question
  • 하나의 볶음밥을 여러명이 만들어야 한다면 무엇을 해야할까?
• Role Model
• Goals
  • 팀으로써 일하기
  • 문서화의 중요성
  • 일정산출을 위한 일정의 필요
• Specific Goals (Development Processs)
• Solution
  • 기획 분석 문서와 Api Spec을 통해 의사소통 한다.
• etc

 

What is the Problem?

• 일정 산출의 정확성이 떨어진다.
  • 추상적인 상태에서 유의미한 일정 산출이 가능한가?
  • 협업자간의 상호이해 없이 하나의 결과물에 대한 유의미한 일정 산출이 가능한가?
• 비효율적인 작업 방식에 대한 회의감
  • 구현 사항이 추상적인 상태에서 작업 하는 것이 효율적인가?
  • 각자 다른 청사진을 가지고 작업하는 것이 효율적인가?
  • 추측하며 작업하는 방식이 효율적인가?
• 확립되지 않은 신념
  • 우리는 무엇을 위해 일하는가? (비전, 작업 목적)
  • 우리는 어떻게 일하는가?
  • 우리는 왜 일하는가? (비전, 상황, 동기부여)

Question

하나의 볶음밥을 여러명이 만들어야 한다면 무엇을 해야할까?

한 팀이 하나의 볶음밥을 요리 하기 위해선 목표가 확립되어야한다. 각자가 짜장볶음밥, 새우볶음밥, 리조또를 생각하고 준비를 하면 요리가 완성되기 어렵다.

Role Model

Robert C. Martin - Wikipedia

Robert C. Martin - Wikipedia

Known for: Agile Manifesto, SOLID principles, TDD, Clean Code

세계적인 소프트웨어 분야의 장인이자, 애자일, 시스템 디자인, TDD, Clean Code의 선구자

 

애자일 소프트웨어 개발 선언

애자일 소프트웨어 개발 선언

Best Practice를 찾아가는 우리 팀만의 여정이라고 생각하니 즐겁다. :)

Goals

팀으로써 일하기

팀의 상황을 알고, 이해하고, 협력한다.

정보의 단절을 최소화하고 상황을 파악할 수 있도록 개선하자.

1. 적극적으로 공유한다.
   • 현재 회사와 팀의 상황을 공유한다. (동기부여를 위해)
   • 작업 상황을 공유한다.
   • 슬랙 채팅룸 구조를 개선한다.
2. 적극적으로 돕는다.
   • 문제와 상황을 해결하기 위해 “팀”혹은 “동료”에게 필요한것이 무엇인지 고민한다.

문서화의 중요성

문서를 잘 활용하자 (파편화 된 정보는 혼선을 야기한다.)

• 스프린트 기획 (분석) (구성원 모두의 적극적인 참여가 필수) 맛있는 볶음밥을 요리하기 위해
• 기술적 커뮤니케이션
• 우리가 만들어가는 문화
  • 일의 진행 방식
  • 개발 문화
  • etc..

 

Quotes

개발은 물론이고 의사소통 또한 프로 개발자의 임무다. 입력이 형편없으면 출력도 형편없다(garbage-in/garbage-out)는 사실은 프로그래머에게도 해당된다는 사실을 명심하자. 따라서 프로 프로그래머는 팀 동료나 사업부와의 의사소통이 정확하고 도움이 되도록 신경 써야 한다.

프로그래밍은 온전히 다른 사람과 함께 일하는 것에 관한 업무다. 프로그래밍을 하며 일과 시간을 보내고 싶다면, 우리가 대화하고자 노력해야 할 상대는 바로 사람이다.

프로는 탑승한 배가 어떻게 항해하는지 관심을 기울인다. 프로 프로그래머는 사업을 이해하는 데 시간을 투자한다. 즉, 사업 목표를 속속들이 이해해야 한다는 뜻이다. 왜 코드를 작성하고, 그 코드로부터 회사가 어떤 이득을 얻을지 알아야 한다.

- Robert C. Martin

 

일정산출을 위한 일정의 필요

1. 일정 산출을 위한 일정은 필수적이다.
2. 결정은 책임을 져야하는 사람이 해야한다.

무엇을 해야할지 명확하지 않은 상태에서는 약속할 수 없다.

 

Quotes

약속은 꼭 지켜야 한다. 프로는 달성할 수 있다는 사실을 알지 못하면 약속하지 않는다.

자신의 시간관리는 자신만이 할 수 있다.

추정은 어림짐작이다. 약속은 포함되지 않는다. 아무런 약속도 하지 않는다. 추정이 빗나가는 일은 전혀 불명예가 아니다. 추정을 하는 이유는 얼마나 걸릴지 모르기 때문이다. 추정은 숫자가 아니다. 추정은 분포다.

프로페셜리즘(professionalism)이란 당연히 명예와 긍지의 상징이기도 하지만, 동시에 책임과 의무를 나타내기도 한다. 프로페셜리즘은 책임이 전부라 해도 과언이 아니다.

- Robert C. Martin

 

스프린트에 일어나는 일에 대해서는 개발자의 책임이기 때문에 스프린트에서 얼마만큼의 일을 하고, 목표를 어떻게 달성할 건지에 대한 결정의 주체는 개발자가 되어야 합니다.

- Willem Jan

 

Specific Goals (Developments Process)

1. 커뮤니케이션 효율을 높이자 (혼선 방지)
2. 오류 해결 비용을 줄인다. (일찍 발견할수록 이슈 해결 비용이 낮아짐)
3. 일정 산출의 정확성을 높인다.

Quotes

소프트웨어는 대부분 팀 단위로 만든다. 팀원들이 프로답게 힘을 모을 때 팀은 가장 효율적이다. 독불장군이나 은둔자는 프로답지 못한 사람이다.

가장 효율적이고 효과적인 코드 검토 방법은 코드를 만들 때부터 힘을 모으는 것이다. 프로는 함께 일한다. 추가로, 혼자 일할 때 더 잘 할 가능성은 그리 높지 않다. 물론 혼자 일하는 게 적절한 경우도 있다.

회의는 필요하다. 하지만 동시에, 회의는 엄청난 시간 낭비다.

- Robert C. Martin

 

 

Solution

구현 기능 문서와 Api Spec을 통해 의사소통 한다.

Basic Process
1. 기획분석단계
2. 설계단계
3. 구현단계
4. 테스트단계
5. 유지보수 단계 (배포)

1. 사전 회의를 통한 문서화 (두가지 단계: 기획 분석, 구현 설계)

• 기획 분석 단계에서는 구현해야 할 기능을 명확히 한다. (구현 기능 문서화)
  • 기획팀과 개발팀의 커뮤니케이션이 필요하다.
  • 이 때 기획 단계에서 고려하지 못한 변수들을 찾아낸다.
•  구현 설계 단계에서 개발팀 회의를 통해 Application에서 구현될 기능의 메커니즘을 이해한다.
  • lo-fi 버전의 Api Spec을 준비하여 Api Spec을 기반으로 소통한다.
  • 회의를 통해 mid-fi 버전의 Api Spec을 정의한다.
    

2. 명확해진 구현사항을 토대로 일정을 계획한다.

 

일정 산출시 고려해야 할 것 (리스트가 구체화될수록 정확도는 높아질 것이다.)

1. 생각하고 코드를 작성하는 시간 이외에 구현에 필요한 일들을 고려한다.
   • 구현
   • 구현중 생기는 커뮤니케이션
   • 구현중 생기는 이슈 (happy path는 불가능하다.)
     • 파악하지 못한 경우의수
     • 기존 코드를 수정하며 생기는 side effect
   • 구현 중 테스트
   • 예외처리
   • 코드리뷰 (개인과 회사 모두의 성장을 위해)
   • 코드리뷰를 반영한 2차 구현
   • 문서화: Swagger, 혹은 기능이나 테이블에 대한 매커니즘 문서화
   • App QA
   • 배포
2. 스프린트 작업 이외의 작업
   • 스프린트 작업 이외의 커뮤니케이션 및 요청
   • 다음 스프린트 관련 lo-fi, mid-fi, 등에 대한 피드백 시간
3. 스프린트 이외의 긴급 이슈는 스프린트 일정에 포함시키지 않는다.
   • 긴급 이슈가 생겼을 경우 스프린트는 일시 중단된다.
4. 나눠서 설계한다.
   • MVP 형태를 지향하는 마인드셋이 필요하다.
   • 애자일의 핵심은 빠르게 자주 반복해서 피드백을 받는 것이다.
   • 구현 사항을 나눌 수 있는지, 구현을 간단하게 할 수 있는지 생각한다.

Quotes

스크럼 팀은 일정에 맞춰 결과물을 산출해내는데에 집중하는게 아니라 스프린트 목표를 설정하고 이를 달성하기 위한 가장 효율적인 방법을 찾는것에 몰두한다. 

- Willem Jan

기타

의미없는 애자일이 되지 않기 위해

• 애자일 스터디를 제안합니다.
  • 각자가 공부한, 리서치한 정보를 공유하고 토론합니다.
• Try를 더 중요하게 생각합시다. 피드백하고 반영하는 것 까지가 진짜!
  • Try를 상기하기 위한 방법을 논의합시다.
  • 데일리, 혹은 미니 게임을 활용 해볼 수 있을 것 같습니다. : )

 

정리되지 않은 고민들에 대해 정말 잘 정리되어있는 글들 입니다. 시간 관계상 링크만 첨부합니다.

스크럼이 개발자를 괴롭히는 9가지 이유 | 요즘IT

마이크로 매니징이란 무엇인가?

 

매 스프린트마다 더 많은 일을 해내려고 하게 되고, 애자일의 12원칙중 하나인 ‘단순성’과 멀어지게 됩니다.

 

일정 맞추기에 급급한 팀들

매번의 스프린트에서 무슨 일이 일어날지 알 수 없는 불확실한 환경에 대응하고자 고안되었는데 정해진 일정에 따르는 건 스크럼의 의도를 완전히 무시하는 겁니다.

 

스크럼 팀은 일정에 맞춰 결과물을 산출해내는데에 집중하는게 아니라 스프린트 목표를 설정하고 이를 달성하기 위한 가장 효율적인 방법을 찾는것에 몰두한다.

 

쓸모없는 스크럼 이벤트

• 불평만 늘어놓는 회고
• 영양가 없이 현재 상황 체크만 하는 미팅

외부 의존성을 최소화하기 위한 교차 기능적 구성
(다른 요인으로 인해 일을 진행 하지 못하는)

스크럼팀은 주도적으로 자신을 관리해야한다.

스프린트에 일어나는 일에 대해서는 개발자의 책임이기 때문에 스프린트에서 얼마만큼의 일을 하고, 목표를 어떻게 달성할 건지에 대한 결정의 주체는 개발자가 되어야한다.

 

 

참고)

클린 코더 - The Clean Coder

개발자 일정 산출 잘하는 방법 📆

등등 한 달 동안 정말 많은 정보를 보며 참고하고 인용하였습니다. 놓친 부분들은 알려주시면 정정하겠습니다.

게시글 썸네일 출처: hankyung.com/sports/article/202212032261Y