Project Process
• Scrum의 과정
○ Planning Meeting
○ Kanban board - Trello 등을 사용하여 진행
○ Daily Standup Meeting 서서 진행한다는 것은 회의 후 바로 일을 시작하고자 하는 효율성의 상징
○ Github - PR & Code Review
• 2 week projects - 2 Sprints
나무 그네 이야기 비유
위 그림은 IT 프로젝트의 초기 요구사항의 불확실성, 복잡성에 대해서 각 담당자가 이해한 결과물을 보여준다. 사실 고객은 나무에서 타이어 그네를 타고 싶었습니다. 프로젝트가 끝날 때쯤에 알았다면 이미 늦어 버린 것이다.
프로젝트 기간, 비용, 품질 3박자를 충족시키고 시장(고객)의 반응이 좋을 때 성공했다고 판단한다. 여기서 한 가지 더 개발사도 만족한다면 최고의 성공이라고 생각한다.
따라서 프로젝트 성공에 대한 관점을 3가지로 보게되는데,
- 납기일에 가치있는 제품을 고객에게 전달
- 시장또는 고객의 좋은 반응
- 고객/수행사의 만족
Intro To Scrum
전체 개발 프로젝트의 68% 정도가 실패하게 된다고 한다 여기서 말하는 실패란 다음과 같은 상황을 이야기 한다.
- 목표 기능 미달 및 불량
- 일정 및 비용 초과
- 개발중도포기(완전 실패)
소프트웨어 개발 프로젝트 운영은 어렵다. 단순히 시간을 많이 쓴다고 해서 잘되는게 아니다. 만일 단순히 시간과 비례한다고 하면 노동시간이 긴 회사나 국가가 소프트웨어 개발을 잘했을 것이다. 하지만 현실은 그렇지 않다. 왜냐하면 인류에게도 길게 잡아 60년정도. 우리나라는 20년 정도로 새로운 분야이기 때문에 아직까지 발전단계에 있어서 그렇다. 산업이 비교적 최근에 생긴 만큼 소프트웨어 프로젝트 운영에 관해 많은 노하우나 경험이 쌓여있지 않기 때문에 많은 회사들과 담당자들이 자신들이 익숙한(그러나 소프트웨어 프로젝트 운영에 적합하지 않은) 방식으로 운영하기 때문에 그런 것도 있다.
• 그래도 역시 미국이 선두주자
• 소프트웨어 프로젝트 운영 방법에 대해서 많은 고민과 토론을 하고 방법론들을 발명하였음
• 그 중 가장 효과가 입증되었고 널리 쓰이고 있는 것이 Scrum(스크럼)이다.
• 스크럼은 1986년 일본 도요타에서 먼저 발명
Scrum의 기본 철학
- 개발 업무는 소요시간과 진행과정을 예상하기가 굉장히 어려움.
- 한시간 걸린다고 생각하면 2~3시간 기본, 1달 걸린다고 하면 2~3달
- 이것은 초급 개발자부터 고급 개발자, 한국 개발자부터 미국 개발자까지 예외사항 없음
실제로 구글 페이스북, 아마존, MS 같은 기업들 모두 프로젝트의 기한 및 비용 초과의 문제가 있다.
- 개발을 진행하면서 생기는 예상치 못한 어려움과 문제를 미리 알 수 없기 때문에, 단순하고 긍정적으로 생각해서 예상 하고 실행
- 프로젝트가 완성되기 까지의 소요시간 예상은 정말 어려움 예를 들면 사람이 3달의 일정을 정확하게 예측, 계획하기가 매우 어렵다.
- 그러나 단기적인 시간안에 할 수 있는 일을 결정하는것은 비교 가능
- 따라서 실패를 최소화 하고 작은 성취 및 목표들을 더해 큰 성취로 나아가기 위해 계획을 짤때 장기적인 계획이 아닌 단기적인 계획을 여러번 짜는 것이 필요.이러한 짧은 단기 주기를 Sprint라고 한다.(예를 들어 2 weeks sprint는 2주기)
Sprint 진행 방법
○ 스프린트가 시작하는 첫 날 Planning 미팅을 갖고, 스프린트 동안 할 일을 결정 ○ 스프린트를 진행하면서 각자 주어진 일을 완료 ○ 매일 standup 미팅을 통해 팀원끼리 서로의 진행사항을 공유.(standup 미팅의 목적은, 앉지 않고 빨리 서로 진행사항 공유하고 다시 일하자는 취지) ○ Stand up meeting에서는 다음 3가지를 한 사람 씩 돌아가면서 이야기 1. 어제 했던 일 2. 오늘 할 일 3. 다른 사람에 의해 막혀있는 것 이나 다른 사람이 해줘야 하는 것(blocker) 4. 이야기가 너무 길어 질 것 같으면 끊고 다른 시간을 만들어 이야기를 이어나가거나 해야 할 일 속행(이러한 주기를 프로젝트가 끝날 때 까지 반복) ○ 즉 큰 프로젝트를 sprint 단위로 나누어서 계획하고 실행하는 것 ○ 이렇게 함으로 좀 더 현실적인 계획을 할 수 있다. ○ 또한 프로젝트의 진행상황 파악이 쉬워짐으로 문제나 차질이 있을 때 미리미리 대처할 수 있게 된다.
Waterfall vs Scrum
Waterfall 방식 : 설계, 구현, 테스트를 순차적으로 진행 된다. 이 형태는 중간에 요구사항만 변경하지 않는다면 단계가 명확해서 관리가 쉽다. 하지만 고객 자신도 원하는 것이 모르는데(요청 사항이 수시로 바뀜) 변경사항에 대한 반영이 늦고 비용도 많이 들 수 있다. 최종적으로 실패할 가능성이 높다.
Scrum 방식 : overhead가 조금씩 있지만 변동사항에 대해 짧은 주기로 빠르게 해결하면서 개선해 나감 고객의 요구사항을 즉시 받아들여 프로젝트에 늦지 않게 대응할 수 있다.
MVP(Minimum Viable Product) scrum의 이점을 간략하게 보여주는 예시그림
실제 하게 될 scrum의 진행과정(trello)
Product backlog(작업할 내역들이 생기면 backlog에 누적) -> Sprint planning meeting -> In Progress(작업 진행) -> Done(작업 완료)
Code Of Conduct
- 시간 엄수
○ 미팅 시간
○ 각자 맡은 일 제시간에 완성 - 책임감
○ 다른 사람에게 의존하거나 떠넘기려고 하지 말자.
○ 내가 맡은 역할과 일을 모두 책임감 있게 완수는 기본. 내가 하지 않아도 되는 것도 하는 사람이 되자! - 팀워크
○ 우리 모두 성인. 내 기분 대로 하지 말자.
○ 서로를 배려하자. 팀 분위기를 좋게 하자. - 도전 정신
○ 쉬운것만 하려고 하지말자. 쉬운 것만 하면 발전이 없다. 어려운 것을 해라.
○ 두려워 하지 말라. 모르겠고 이해 안되는 것이 당연하다.
Reference
