[TIL] # 31 Scrum, Kanban

ddalkigum·2020년 12월 30일
2

TIL

목록 보기
31/50
post-thumbnail

Agile

에자일... 스크럼 들어보기는 했지만, 궁금증을 갖지 않았엇는데

회사 요구사항을 보다가 궁금해서 찾아봤다

의미

Agile에 딱 정해져있는 뜻은 없지 않을까 생각했다

굳이 뜻을 정하자면 나는 이렇게 생각할 것같다

그렇게 일하는 방식... 좀더 들어가보면

내가 생각하는 에자일이란 뜻은 유연하게 일하는 방식 이다

유연하다.... 무엇에 유연한 걸까??

유연하다 = 빠른 대처가 가능하다

  1. 짧은 개발 주기를 가지고, 프로젝트를 완성하는 것이다
  2. 협업과 패드백의 중요성

협업과 피드백을 강조하는 걸 보면 devops와 비슷한 성향이지 않을까 생각했다

Agile에서 뻣어나간 여러 방법론이 있는데 그중 하나다 Scrum이다


Scrum

Scrum은 Agile의 대표적인 관리방식이다

방법론에 의존하지 않으며, 제품개발 뿐만 아니라 일반적인 프로젝트 관리에도 사용가능한
프로세스 프레임 워크

스크럼은 짧은 주기로 개발 및 검토를 하며 효율적인 협업 방법을 제공한다

나온 이유

복잡한 제품을 개발하고, 유지하기 위한 프레임워크

프로젝트가 커지면서, 복잡한 제품을 더 효과적으로 개발하고 유지하기 위한 프레임워크

작은 목표를 짧은 주기를 가지고 제품을 지속적으로 개발하고 관리하기 위한 관리 프레임워크

Scrum방식이 왜 등장했고, 많은 회사들이 이러한 방식을 사용하는지

이렇게 쭉 나열해 놓으면 감이 잡힌다

특징

Sprint

개발 주기를 의미하며, Sprint를 반복하며 최종 목표에 도달한다

  1. 개발주기는 1~4주로 하며, 개발주기마다 실제로 동작하는 결과를 제공

    짧은 개발주기를 통해 성취감을 얻게되고, 한칸한칸 올라가다 보면
    어느순간 목표에 도달하게 된다

    개발주기는 너무 짧지도 길지도 않게 잡는데
    개발주기가 짧게 되면 심리적인 압박감이 있고,
    너무 많은 피드백을 받는 경우가 늘어나기 때문에 개발주기는 너무 짧게 잡지 않는다

    반대로 개발주기가 길게되면 사람이 심리적으로 느슨해진다

  2. 개발주기마다 적용할 기능이나 개선에 대한 목록을 제공한다

    이렇게 개발주기 마다 목록을 제공 함으로써
    눈에 보이는 목표가 생긴다

  3. 매일 15분 정도의 Scrum meeting을 갖는다

    미팅을 한다는 건 피드백이 오가는 것이며,
    프로젝트의 진행 상황을 공유하는 것이다

    미팅은 공유의 장소가 되어야 한다
    Agile의 협업과 피드백의 중요성을 져버리고 미팅이 지시를 하고
    보고를 하는 시간이 되어 버리면, Scrum이 아닌 것이다

    수평적인 위치에서 미팅을 진행하며, 서로 의사소통을 진행한다

  4. 우선순위는 나 자신이 아닌 팀에 있다

    개인의 목표도 중요하지만 결국 개인의 목표가 모여
    전체적인 팀목표가 달성이 된다

    협업의 중요성을 강조하는 만큼 개인의 목표가 너무 급한게 아니라면
    다른 팀원을 도와가면서 팀의 목표에 도달할 수 있도록 노력하는게
    결과적으로는 나에게도 도움이 되는 행동이 될 것이다.

칸반

Scrum과 비슷한 방법이 아닌가 헷갈렸습니다

칸반의 경우는 매일 15분정도의 미팅을 진행하며,
어제 한일과 오늘 할일에 대한 것이 미팅의 내용이며
약속된 마감일이 없다

둘의 차이점?

칸반

  1. 계획한일, 진행중인 일, 완료한 일을 나누어 하나씩 완료를 해나가는 형식

  2. hotfix가 발생하면 바로 해야할 일에 포함시켜 hotfix를 진행한다

  3. 스크럼에 비해 치계적인 구조를 갖지 않는다

스크럼

  1. sprint 기간을 정해놓고, 그에 맞춰 스케쥴을 진행하는 방식

  2. hotfix가 발생하면 지금 진행중인 sprint에 포함시키지 않는다

  3. 쳬게적인 구조를 갖는다

제가 생각하기로는 위 세가지가 차이점이 아닐까 싶습니다

2020년에 쓰여진 글도 잇고, 2015년도에 쓰여진 글도 잇고
책으로도 있지만 현재에 가까워 질 수록 둘의 경계가 모호해지고 있다는 느낌을 받았습니다

둘의 본질이 변하지는 않겟지만 받아들이는데 있어

참... 애매해 질 수 밖에 없지 않나 생각이 듭니다

둘 모두 유연한 대처를 위해, 프로젝트 목표 달성을 위해 필요한 것이고
Agile에서 뿌리를 뻗어 나온것이 사실입니다

이 둘이 모호해지더라도 개발자는 어떤 상황에도 유연하게 대처해야 하고
개발자라는 직업을 택했으면,, 평생 공부하면서 극복해야죠 😁


켄트백

소프트웨어의 모든것은 변한다
요구사항도 변하고, 설계도 변한다
비지니스도, 기술도, 팀도, 팀구성원도 변한다
변화는 반드시 일어난다.
문제는 변화가 아니다 변화를 극복하지 못하는 무능력이 문제다

화이팅 😁

profile
딸기검 -본캐🐒 , 김준형 - 현실 본캐 🐒

1개의 댓글

comment-user-thumbnail
2021년 2월 24일

치계적인 오타 발결 ㅋㅋㅋㅋ벨로그 킹

답글 달기