오전 특강

한정헌 멘토님

• 전통적 소프트웨어 개발 프로세스
  • 폭포수 모델(Waterfall Model)
  • 건축 공학에 영감을 받아 소프트웨어에 적용
  • 하지만 소프트웨어는 쉽게 바꿀 수 있다는 특성 때문에 요구 사항이 자주 바뀐다.
  • 애자일 모델(Agile Model)이 등장하게 된 계기가 된다.
• 애자일 모델(Agile Model)
  • 키워드 “요구 사항을 포용하라”
  • 개발 패러다임의 전환
  • 애자일(Agile) : 불확실한 환경에서 효율적으로 일하는 방식(자율, 협업, 피드백)
  • IT 서비스 중심으로 변화면서 소프트웨어는 매우 민첩해져야 한다.
  • Agile Manifesto
  • XP, Kanban, Scrum(제일 대중적인 애자일 방법론)
• 스크럼(Scrum)
  • 스프린트 : 시장의 반응을 분석하고 빠른 피드백 반영
  • 프로젝트 관리 방법
  • 백로그 : 요구사항 목록
  • 스프린트 백로그 : 각각의 스프린트 요구사항
  • 스프린트 : 백로그가 100개이고 스프린트 백로그가 10개씩이면 총 10번의 스프린트
  • 스크럼 미팅 : 일일 회의, 팀원들 끼리 한 명씩 돌아가면서 어제 한 일, 오늘 한 일, 장애물 보고
  • 스프린트 시연 및 리뷰: 고객과 의사소통
  • 스프린트 회고: 스프린트를 진행하면서 좋았던 점, 나빴던 점 투표해서 좋았던 점은 다음 스프린트 반영하고 나빴던 점은 다음 스프린트에서 고쳐야됨
• 스크럼 멤버 역할
  • 프로덕트 오너(Product Own): 고객이 팀에 들어가 있다. 요구사항 도출, 시연시 피드백 제공
  • 스크럼 마스터(Scrum Master)
  • 개발팀(Development)
• 스프린트 백로그
  • 스프린트 진척도 확인 : 스프린트 보드 ( JIRA, TRELLO, Azure Board)
  • 예정, 진행 중, 완료
  • 팀원들의 진행 상황 파악 쉬움
• 스크럼 미팅
  • 스탠드업 미팅
• 스프린트 리뷰
  • 시연하면서 피드백을 듣는다.
• 스프린트 회고
  • 팀원끼리 좋은점/나쁜점을 공유해서 찾아서 다음 스프린트의 개선점을 찾는 활동
  • Keep, Problem, Try
  • Confluence, JIRA, Notion
• 마일스톤(MileStone)
  • 프로젝트 이정표
  • 팀원끼리 준수해야 할 규칙

이동규 멘토님

• 클라우드가 필요한 이유

  서비스 스펙 → 물리 장비 시청 → 로컬 개발 → 장비 배정 → (OS 구성 → Service 구성 : 도커) → 네트워크 구성 → 서비스 오픈

  • 물리 장비 준비 시간을 최소화 : 클라우드 서비스
  • 도커 : OS 구성 → 서비스 구성 단계 최소화

• 퍼블릭 클라우드 vs 프라이빗 클라우드

  • 퍼블릭: 누구나 접근 ( AWS, Azure, Google Cloud)
  • 프라이빗: 특정 인원만 접근

• AWS Azure

  • 팔아서 써주세요 마인드 : 유저 친화적
  • 웹 서비스 : 아마존
  • 게임 서비스 : 애저

• Google Cloud

  • 너희도 쓸래? : 개발자 친화적