회의

주간회의

회사 전체 돌아가는 상황을 공유합니다.
  • 시간 - 매 주 월요일 오전 9시
  • 참석자 - 회사 구성원 모두
  • 내용
  • 주말 어떻게 지냈나, 소소한 이야기
  • 한 주 간 Product/Project 단위 업무 진행사항과 이슈 공유
  • 세미나

주간 회의 보고 방법
  • Project와 Product에 대해 담당 팀장이 보고합니다.
  • 주요 Milestone이 무엇이고 현재 어디까지 진도가 나갔는지 서술합니다.
  • 현재 진행중인 Milestone에서 현재 진행중인 Task, Issue, Risk는 무엇이고, 어떻게 대응하고 있는지 설명합니다.

Project의 경우 주간 회의 보고 예
  • 주요 마일스톤 (앞쪽의 숫자는 확정된 날짜입니다)
    .aRFP 사전 협의
    .b3월 초 공고
    .c계약
    .dKick-off meeting
    .eZephyr RTOS 분석, 사내 세미나 ➝ 현재 단계
    .fZephyr RTOS의 Device Driver 분석, 사내 세미나
    .gNetwork Device Driver 개발
    .hNetwork Device Driver 성능 시험
    .i11월 30일 최종 보고서 작성
    .j12월 초 중 최종 보고
  • Task, Issue, Risk, 대응
    .aZephyr RTOS 주요 문서 분석 중 (Task에 대한 설명)
    .bZephyr RTOS 문서 중 Network Device Driver 부분이 예제로만 존재해 예제를 분석해야 함 (Issue에 대한 설명)
    .cNetwork Device Driver는 x86 예제는 있는데 RISC-V 예제가 없어서 차후에 porting 해야 할 가능성이 있음 (Risk에 대한 설명)
    .dQEMU 기반의 x86에서 예제를 먼저 구동 후 역으로 설계를 뽑아내 차후 RISC-V에 대응하기로 (대응 방법에 대한 설명)

Product의 경우 주간 회의 보고 예
  • 주요 마일스톤 (앞쪽의 숫자는 날짜 입니다)
    .a2.15 TSN HAT 보드 Requirements 확정
    .b2.30 부품 수급과 예상 생산 비용 수립
    .c3.15 PCB 설계
    .d5. 30 Sample #1 생산
    .e6.15 Sample #1 기능/성능 시험
    .f7.1 Sample #2 생산
    .g7.20 Sample #2 기능/성능 시험
    .h8.15 Sample #2 대상 S/W Stack과 통합 ➝ 현재 단계
    .i9.1 S/W 통합 기능/성능 시험
    .j10.1 제품화를 위한 홈페이지, Documentation
    .k11. 1 초기 양산 제품 생산
  • Task, Issue, Risk, 대응
    .aNetwork Device Drvier를 Sample #2에 맞추어 포팅 중 (Task에 대한 설명)
    .bSample #1과 Sample #2에서 크게 바뀐 부분은 없어 특별한 Issue 없음 (Issue에 대한 설명)
    .cRX Interrupt 가 아직 구현 안 되어 있어 RX시 성능이 낮아질 수 있음 (Risk에 대한 설명)
    .dSW TX 구현 작업과 HW의 RX Interrupt 작업을 병행해 일정 맞출 예정 (대응 방법에 대한 설명)

Daily meeting

팀 별로 오전 9시에 팀원들이 각자 전날 진행했던 Task와 오늘 진행할 Task에 대해 논의하고, 주요 Issue에 대해 논의합니다. 시간은 10분 (최대 15분) 이내로 짧게 정보를 전달하는 회의입니다.

아래는 진행 방법입니다.
    .1팀의 구성원 모두가 돌아가며 보고합니다.
    .2ClickUp의 Dashboard를 이용해 어제 진행했던 업무가 무엇이고, 오늘 진행할 업무가 무엇인지, 그리고 Issue가 무엇인지 설명합니다. 업무 보고 시는 아래 Dashboard를 화면 공유합니다.
    .3팀장은 Task가 peer review가 완료 되어 "업무 완료 기준"을 충족 시켰는지 확인합니다. ➝ Task의 완결성 확인
    .4팀장은 팀원의 업무 속도가 하루 6~7 points 정도로 유지 되는지 확인합니다. ➝ 팀원의 업무 속도 확인
    .a팀원에 따라 업무 속다가 빠를 수 있고, 느릴 수 있습니다. 일정한 속도가 유지되는 것이 중요합니다.
    .b업무 속도가 너무 높을 경우(하루 10 points 이상, 그리고 야근을 자주 하는 경우) 야근을 자제시켜주세요.
    .c업무 속도가 너무 낮을 경우(하루 4 points 이하) 무슨 문제가 있는지 확인해주세요.
    .d팀원의 업무 속도에 문제가 있는 경우 이사회에 보고해주세요.
    .5팀장은 Task 상태를 확인합니다.
    .a예상 시간(Sprint point)대비 ±50%면 Green
    .b예상 시간 대비 2배 이상 시간이 소요 되면 Yellow ➝ 팀장이 직접 개입해야 합니다.
    .c예상 시간 대비 3배 이상 시간이 소요되면 Red ➝ Task 실패로 간주하고 해당 Task를 다른 팀원에게 위임해야 합니다.
    .6팀장은 개인 별 업무 내용을 Task, Issue, Risk, 대응 방안으로 나누어 팀과 이사회에 보고합니다. 팀과 이사회에 보고할 때는 아래와 같이 메일을 보내주세요
    .a제목: 2024-02-15

아래는 팀 보고 예시입니다.
  • 원종: TSN NIC Network Device Driver ➝ Product 이름
  • 드라이버에서 버퍼 두 개로 늘려서 테스트 ➝ 어제 Task 설명
  • 스핀락이 너무 길게 걸려서 성능이 제대로 나오지 않음 ➝ Issue 설명
  • 공유자원을 최대한 줄이고 스핀락을 최대한 짧게 이용하도록 진행 예정 ➝ Issue의 대응방안, 오늘 Task 설명
  • 지훈: ns-3 과제 ➝ Project 이름
  • NS-3와 MCTP를 붙였을 때 로스율이 높아지는 문제 원인 분석 ➝ 어제 Task 설명
  • rpi로 집에서 물리적인 환경 구성해서 테스트 예정 ➝ 오늘 Task 설명
  • PV 코드 리뷰 받은 부분 수정 ➝ 오늘 Task 설명
  • 윤식: ns-3 과제 ➝ Project 이름
  • Station REST API 코드 리뷰 받은 것 수정
  • ns-3 co-simulation 부분은 박준혁 박사에게 완전 위임 되어있음 ➝ Risk 설명
  • ETRI에서 ns-3를 사용하지 않고 다른 simulation으로 바꾸는 방안이 있음 ➝ 대응방안 설명
  • 아름: 회의방 자동생성 프로그램 ➝ Product 이름
  • 회의방 자동생성 - 참석추적 기능 안 켜지는 문제 분석, 수정
  • PR들 2차 코드 리뷰
  • 1큐 TSN 구상
  • Yellow, Red Task 목록 ➝ Yellow 또는 Red Task가 있을 경우 상세 내용을 설명
  • TSN NIC x86 Linux network device driver (Red) ➝ 대표이사가 옆에서 구현 방법을 도와주고 있음
  • MCTP 성능 개선 (Yellow) ➝ 아름 팀장의 도움을 받아 지훈씨가 작업 중

Sprint Planning Meeting

Sprint 시작 시점(2주에 한 번 업무 첫 날) 팀 단위로 그 2주간 진행할 Task를 정리하고, 예상 point를 정합니다. Sprint 중간 월요일 또는 화요일엔 Semi-sprint planning meeting을 합니다. 한 주 동안 진행하며 조정해야 하는 Task를 조정하는 시간입니다.
  • 회의 주체 - 팀장 또는 팀장 대리
  • 참석자 - 팀 구성원
  • 일시 - Sprint 시작 첫 날(월요일 또는 화요일) 주간회의 이후
  • 팀 단위에서 수행해야 할 Task를 뽑습니다. Task는 아래 요소가 꼭 확인 되어야 합니다.
  • 이사회에서 보았을 때 어떤 Task인지 알 수 있는 명확한 명칭 e.g. 드라이버 성능 개선 (X), x86 Linux TSN Network Device Driver 성능 개선 (O)
  • 팀원 모두가 동의하는 업무 예상 시간을 Sprint point로 할당: 2~6 points 권장, 8 points 초과 시 Task를 쪼갤 것
  • 업무 수행을 위한 명확한 업무 절차를 명시
  • 업무 완료 조건을 Checkpoint로 할당
  • 업무 완료 조건엔 Peer review를 반드시 포함할 것
  • Task는 인원수 x 업무일수 x 6 points 분량을 뽑아야 합니다.
  • Task를 뽑은 이후에 각 Task를 누가 담당할 것인지 정합니다. Task 할당은 대략 1주일 분량만 먼저 할당해도 괜찮습니다. 할당되지 않은 Task는 팀에게 할당하면 됩니다.
  • 어떤 업무인지 몰라 Research가 필요한 경우 Research 업무(Sprint point가 정해진)를 할당하고, Research 업무 이후 상세 Task를 할당하도록 합니다.
  • 가능하면 Sprint planning meeting 당일 Research를 집중해 Task를 상세히 나누도록 합니다.
  • Sprint planning meeting이 끝나면 팀 담당 이사에게 Sprint Task review를 받습니다.

Sprint Retrospective Meeting

Sprint 끝나는 날 오후 4시에 팀 단위로 2주 간의 Sprint를 검토하는 회고 회의입니다.
  • 회의 주체 - 팀장 또는 팀장 대리
  • 참석자 - 팀 구성원
  • 일시 - Sprint 마지막날 오후 4시 (가장 이른 퇴근자 퇴근 1시간 전)
  • 회고 회의는 아래 사항을 검토해야 합니다.
  • 각자 완료한 Task의 sprint point 기입
  • Sprint 운영 관점에서 이번 Sprint에서 잘 한 것
  • Sprint 운영 관점에서 이번 Sprint에서 잘 못 한 것
  • Sprint 운영 관점에서 다음 Sprint에서 개선해야 할 것
  • Sprint retrospective meeting이 끝나면 팀 담당 이사에게 회고 시트를 Review 받아주세요.

회의 주최자

회사 회의는 대표이사, 팀 회의는 팀장이 주체합니다. 회의 주최자가 없을 경우 아래 규칙에 따라 회의 주최자를 결정합니다.
회사 회의
  • 이사회 내에서 합의로 정한 사람이 주최함
  • 또는 CEO ➝ CTO ➝ 노동자 이사 순으로 결정함
팀 회의
  • 팀 내에서 합의로 정한 사람이 주최함
  • 또는 입사일 순으로 결정함

회의록

모든 정규 회의에는 회의록이 있어야 합니다. 비정규 회의의 경우에도 차후에 내용을 참고해야 하거나, 중요한 결정사항이 있을 때는 꼭 회의록을 작성해야 합니다.
  • 회사, 팀 폴더에 회의록을 작성합니다.
  • 회의록은 회의에 참석하지 않은 사람도 내용 파악을 할 수 있도록 상세히 정리합니다.