1. 스크럼 실무 적용 경험담
    1. Backlog 정리와 스프린트 목표 산정하기
      • 요구사항 확인. 개발가능 여부 검토와 R&D.
      • Backlog 작성과 우선순위 판단 (긴급성과 중요도 판단).
      • Backlog 담당자 지정.
      • 스프린트 진행 (5일간 진행. 스프린트의 마지막날 회고 진행)
  2. 일감 작성하기

    1. Backlog 확인과 일감 작성.

      1. 예상 작업 내역 생성

      2. 예쌍 개발 기간 작성 (시간 or 일 단위.) ⇒ burn down chart 작성을 위해서

    2. 스크럼 보드를 이용한 DSM(Daily Stand-up Meeting) 진행

      1. 스크럼 보드는 To do, In progress, Done 로 구성.
      2. DSM 진행.
        • 매일 10분을 초과하지 않도록 진행
        • 일감의 상태 공유.
        • 업무 지원이 필요할 경우 상세 내용과 의견 조율
        • 일감 완료 시, 실제 개발에 소요된 시간 작성.
        • 생각보다 할당할 수 있는 시간이 얼마 없기에 너무 많이 시간을 할당하기에는 한계가 있다. ⇒ 현실적인 목표를 세울 필요가 없다.
      3. 회고
        • 동료간 의견을 공유하고 개발 프로세스에 대한 개선의 시간을 갖는다.
        • 번다운 차트를 통해 일감의 예상 시간과 개발에 소요된 시간을 확인하고 기간 산정에 문제가 없었는지 확인한다.
      4. 일갑 작성 방법
        • 작업의 목적을 명확하게 이해하고 작성한다.
        • 작업량과 소요 시간을 예상하고 예상하고 작성한다.(목표 설정)
        • R&D가 필요한 경우 진행과정과 내역을 정리하고 고유한다.
          • 관련 Doc 문서의 링크 등을 포함하여야 한다.
          • 공개된 기술을 적용할 경우 사유와 사용법 등을 정리한다.
        • 작업 완료 후, 작업 내역과 투입시간을 기록한다.
      5. Sprint in Jura
        • 지라에서는 스프린트 기능이 있고 매 스프린트를 만들때마다 특정 백로그 내역들을 추려서 게시할 수 있다.
        • 개발자들은 불편함을 참으면 안된다 ⇒ 찾아보는 습관을 가지도록 하자.(Docs)
  3. 우선순위 정하기
    1. 우선순위의 종류
      1. 중요하고 급한 일 (1순위): 지금 당장 해야하는 업무. ⇒ 먼저한다.
      2. 중요하지만 급하지 않은 일 (2순위): 차분히 생각하며 완성도를 높이는 것이 관건. ⇒ 계획한다.
      3. 중요하지 않지만 급한 일 (3순위): 다른 사람의 도움을 빌리거나 효율적으로 처리할 방법 모색 ⇒ 맡긴다. (3번이 1번이 되지 않도록 경계해야한다.)
      4. 급하지도 중요하지도 않은 일 (4순위): 최대한 지양하는 것이 좋고, 자동화로 전환할 필요성이 존재한다. ⇒ 하지 않는다. (그럴 수 없겠지만.)
  4. 의사소통의 중요성
    1. 근무 중 의사소통이 필요한 상황
      1. 예상하지 못한 문제로 작업 결과물이 변경되어야 하는 경우.
      2. 일정의 변경이 필요한 경우. (작업량 증가로 인한 소요시간 변경 등)
      3. 동료의 지원이 필요한 경우.
      4. 의사결정이 필요한 경우.
      5. 업무의 우선순위 변경이 필요한 경우.
      6. 기술적인 방법으로 해결이 가능할 수 있다. ⇒ Docker + mySQL + SQL file (on git repo) ⇒ DB 변경 내역을 공유할 수 있는 방법이 될 수 있다.
  5. 개발자로 일하기
    1. 개발자에게 필요한 소양
      1. 경험하지 못한 것과 하지 못하는 것 구분하기.
        • 새로운 기능과 언어들은 못하는 것이 아니라 아직 경험하지 못한 것이다.
      2. 기술 공유 문화 실천하기.
        • 한 프레임워크에 대해서 BoilerPlate를 만들어보자…!
      3. 새로운 경험에 익숙해지기.
        • 대부분 70%에서 한계를 느낀다. 힘들때는 내가 70%나 왔다는 생각을 하며 마지막까지 힘을 내보자.
      4. 코드부터 작성하지 않기.
      5. 주석 달기.
        • 개발 전 주석으로 순서를 작성한다. ⇒ 작성한 순서를 보면서 다시 한번 정리를 하고 개발에 들어간다.
        • 코드를 작성할때는 인수인계 받는 사람이 본다고 생각하고 작성할 것.
      6. 동료의 코드 흉보지 않기.
        • 흉보지 말고 내가 개선하면 된다.
      7. 코드의 완벽함과 간결함을 위해 목숨 걸기.
        • 람다와 스트림을 공부하자….
        • ChatGPT 활용해보자…. (내 코드와 비교한다.)
      8. 이 모든 것을 즐기기.
    2. 회사 생활에 필요한 소양
      1. 스스로 결정하는 훈련을 하자.
      2. P-R-E-P (Point - Reason - Example - Point) ⇒ DSM 때 적용해보자.
      3. 아는 것을 안다고 하고 모르다고 하는 것이 진정으로 아는 것.
      4. 업무의 롤을 구분하여 담 쌓지 않기.
      5. 쉴 때 쉬고 해야 할 때 절대 집중하기.
      6. 동료를 배려하는 마음.
        • 플젝트는 절대 혼자 할 수 없으며, 프로젝트의 끝엔 동료가 남는다.
    3. 나만의 루틴 만들기
      1. 신호: 루틴을 촉발시키는 환경
      2. 루틴: 습관화 하거나 지속하고 싶은 행동
      3. 보상
        • 습관 루프가 미래에 기억할 가치가 있다는 것을 알려주는 수단
        • 루틴 행위 자체를 보상으로 하는 것이 가장 좋음.
    4. 나만의 회고 시간 갖기 (자기 성찰과 반성)
    5. 의미 부여와 가치 상승