Slide
개요
Jira 의 Agile 에 대한 글을 정리 및 번역합니다.
Agile
효과적이고 민첩한 팀의 작업을 위한 몇 가지 가치와 원칙의 집합.
‘애자일(Agile)’이란 용어는 소프트웨어 개발 방식의 하나로 통용되던 말이다. 작업 계획을 짧은 단위로 세우고 시제품을 만들어 나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고도 신속하게 대응하는 개발 방법론이다. 이와 반대되는 개념이 전통적 개발 방법론이라 할 ‘워터폴(Waterfall) 방식’이다
작업의 관리가 아니라 능동적인 변화 대응이 핵심이며, 일하는 방식은 업무를 작게 쪼개고 더 중요한 일부터 먼저 하되 가능한 반복을 통한 업그레이드를 원칙으로 한다
Agile Manifesto
현대 project management 의 방법론의 근간이 된 문서. 4가지 핵심 가치와 12가지 원칙으로 구성. 2001 년 17명의 software engineer 들이 유타주의 스키장에서 만들었다고 함.
Agile 4 values
프로세스 자체보다 팀원 간 상호 작용, 문서보다 동작하는 소프트웨어, 계약과 협상보다 고객과의 협력, 계획의 준수보다 변화에 민첩한 대응에 더 큰 가치를 둔다는 것. ⇒ 계획의 완수가 아니라 고객에게 전달할 가치를 중시한다는 의미다.
Agile 12 principles
•
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- MVP 를 통해서 가설과 아이디어를 검증한다
- 주기적인 배포를 통해서 제품과 고객 사이의 피드백 사이클을 지속한다.
- "배포"와 "done" 은 동의어가 아니다. 완성된 제품을 출시하는 것이 아니라 지속적으로 계속 고객과 고객의 피드백을 통해서 개선해나가야함
•
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
•
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
제품 개발 단위를 작게, 개발 및 배포 주기를 짧게.
•
Business people and developers must work together daily throughout the project
business 와 technical 의 관점의 간극이 좁혀질 수 있도록 한다.
•
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
애자일 철학에서 핵심은 팀원 개개인을 전적으로 신뢰하고 자율성을 보장하도록 하는 것이다.
•
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
•
Working software is the primary measure of progress
완전한 기능의 집합체를 디자인하고 배포하는 것 보다 Minimum Viable Features! (useful better than perfect)
•
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
지속적으로 빠른 일정은 팀에게 부담이 된다. 특히 기대치가 너무 높을 때 그렇다.
애자일 원칙은 위 사항을 염두해두고 현실적이고 명확한 기대치를 설정하도록 권장한다. 팀의 사기진작이나 burn out 을 막을 수 있다.
•
Continuous attention to technical excellence and good design enhances agility
항상 technical debt 를 염두해두어야함
•
Simplicity—the art of maximizing the amount of work not done—is essential
80/20 의 rule ⇒ 일반적으로 20%의 일로 의도한 목표의 80% 결과를 낼 수 있다.
목표를 달성하는데 필요한 backlog 를 전략적으로 짜고 우선순위화 한다.
•
Promote self-organization in the team.
The best architectures, requirements, and designs emerge from self-organizing teams
피라미드형 구조의 팀과 반대! 작업자가 제일 최적화 잘한다.
•
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Scrum(참고해야함 - https://scrumguides.org/scrum-guide.html)
팀이 협업할 수 있도록 도와주는 Agile 프레임워크. 복잡하고 해결해야할 문제를 해결할 수 있도록 실행하는 working way
주로 Agile 과 Scrum 은 동의어처럼 사용되기는 하지만 다르다.
Agile 은 원칙들을 규정한 것, Scrum 은 framework 다.
Sprint
정해진 양 만큼의 일을 정해진 기한 안에 완수하도록 정해진 기간
•
스크럼과 애자일 방법론의 핵심
With Scrum, a product is built in a series of iterations called sprints that break down big, complex projects into bite-sized pieces
- Megan Cook
Agile 의 원칙인 "delivering working software frequently,", "responding to change over following a plan." 를 팀이 잘 따를 수 있도록 도와준다.
Scrum 의 가치인 명확성(transparency), 점검(inspection), 적응(adaption)? 은 Agile 을 보완해주면서도 Sprint 개념의 중심이다.
Agile ceremonies
How to plan and execute scrum sprints
•
Sprint planning
스프린트에 적합한 작업 항목을 팀원들이 함께(Product owner, scrum master, development team 등) 결정하고, 어떻게 이루어낼 것인지를 계획하는 작업
다음의 두 가지 기본적인 질문에 대해서 답변을 해가면서 Sprint 를 기획해나갈 것이다.
"이 스프린트에서 어떤 작업을 수행할 수 있을까?
"선택한 작업은 어떻게 완료할 수 있을까?"
그리고 planning 중 만들어진 목록들(작업 항목, plan)은 모두 backlog 라고 한다.
Product Owner 와 develop team 이 조율하여 sprint plan 을 완성한다.
모든 팀원이 스프린트 목표와 성공을 측정하는 방법을 설정하고 이해하도록 해야함.
Product Owner 가 지난 스프린트의 리뷰, 이해관계자의 피드백, 제품의 비전, 이번 스프린트의 목표 등을 준비된 상태로 진행하는 것이 좋다.
최대 시간을 정해두고 하는 것이 좋다 (일반적으로 주당 최대 2시간. 예를들어 2주 스프린트는 최대 4시간 회의. 그 이상 하지 않도록) 때문에 backlog 의 세부사항보다 sprint 의 목표에 초점을 두는 것이 좋다. planning 을 하다보면 작업 세부사항에 빠지기 쉽다. 이를 경계해야한다. scrum 은 애초에 경험적이고 역동적인 작업 흐름에 더 초점을 맞추고 있다. 완벽한 계획은 어차피 불가능하다!
Sprint planning 을 통해서 모든 stories, bugs, tasks 들을 sketch 하도록 독려한다.
•
Daily Scrum (Daily Stand-up)
Sprint 기간 중 작업이 어떻게 진행되고 있는지 체크하기 위한 모임. 가능한 15분 이상 하지 않는다.
이 회의의 목적은 스프린트 목표를 달성하는 팀의 능력에 영향을 주는 방해요소나 도전 과제를 파악하는 것. 그리고 작업량이 적절한지 회고하고 realign 할 수 있는 시간도 된다.
다음 세 가지 질문에 답을 한다
◦
What did I complete yesterday?
◦
What will I work on today?
◦
Am I blocked by anything?
•
Sprint Review (Iteration Review)
production 에 배포하기 전에 팀원들과 이해 관계자 앞에서 시연해보는 시간.
Sprint 사이에 Sprint spend 주당 약 1시간 정도의 시간 (2주 스프린트는 2시간)
팀의 성취를 자축하고, 완료된 작업을 시연하고, 이해관계자로부터 즉각적인 피드백을 얻는 것에 의의가 있다. 때문에 완전히 시연할 수 있으며, 팀의 품질 기준을 충족해야하고, 시연할 준비가 된 상태여야한다.
•
Sprint Retrospective
스프린트 회고 시간. 일반적으로 주 당 45분의 시간을 가짐 (2주 스프린트 = 90분)
다음 스프린트 및 앞으로 개선할 점 등을 함께 논의해봄.
Agile 은 빠른 피드백을 통해 제품과 개발 문화를 더 개선한다. 무엇이 잘 되었고 안되었는지 팀원들 사이 공유가 되는 것이다.
Agile ceremonies 는 팀 간에 소통을 가능하게 할 뿐, 팀이 Agile 을 달성하도록 만들어주지 않는다. 견고한 생산 문화(convention), 변화에 대한 전략적인 접근, 팀원들 간의 원활한 협업을 통해서 Agile 은 완성된다.
Sprint Reviews
결과물을 공유하는 것은 Agile 팀을 구성하는데 중요한 요소 중 하나이다
회고(retrospective)와는 다르다. 팀이 모여서 공식, 비공식적인 작업의 결과물에 대한 데모를 진행하는 것이다. 이 시간을 통해서 시연, 직접 경험, 피드백, 질문을 할 수 있다. (회고 전에 하는 것이 좋다)
적대적이고 시험적인 모임이 아니라 각자 팀의 결과물을 공유함으로써 피드백을 얻고 질문을 받을 수 있는 시간이다. 오히려 팀의 사기 진작을 위한 시간이 될 수도 있다.
만약 스프린트 리뷰 미팅이 팀 사이에서 긍정적인 활동이 되지 않는다면 다음의 사항들을 생각해보자
•
The team taking on too much work and not completing it during an iteration
•
The team struggling with existing technical debt
•
Features not being developed sustainably to ensure new bugs are not introduced into the codebase
•
The team’s development practices aren’t as tuned as they could be
•
The product owner is changing priorities within an iteration, and the development team is sidelined by scope creep
다음의 두가지 사항에 대한 장점이 있다
•
제품에 대한 의도, 이론적 근거 및 구현에 대한 것을 팀 전체가 이해할 수 있다.
•
team building.
효과적으로 Sprint Review 를 실행하면 팀의 사기와 동기를 자극할 수 있다.
마지막으로 다시 한 번 말하지만 회고와는 다른 ceremony 이다. 노동의 결과를 마음껏 즐기는 시간이 되길!
Backlogs
Roadmap 과 Requirements 로부터 파생된 (우선순위가 정리된) 작업의 리스트. epic, user stories, bugs, tasks, tech debt 등의 아이템들이 있다.
우선순위가 잘 정리된 backlog 들은 planning 을 쉽게 만들고, 팀원들이 내부적으로 어떤 일들을 하고 있는지 잘 알 수 있도록 해준다 (그것이 심지어 우리의 제품을 사용하는 고객들이 알지 못할 일이라도)
그리고 팀으로부터 어떤 것이 product 를 위해서 좋을 것인지 논의와 선택을 하도록 유도한다. (모든 것이 우선순위가 될 수 없다)
backlog 는 Roadmap 과 Requirements 로부터 파생된다.
Roadmap initiatives 는 여러 epic 으로 나뉘고, 각각의 epic 은 여러 requirements 및 user stories 로 나뉜다.
예시
1.
로드맵에서 teams in space website 라는 initiative
2.
teams in space website 를 만들기 위한 epic 들을 분해한다.
3.
각각의 epic 에 필요한 user stories 들을 설정한다
4.
우선순위 설정 - 다음의 항목을 통해서 설정한다.
•
Customer priority
•
Urgency of getting feedback
•
Relative implementation difficulty
•
Symbiotic relationships between work items (e.g. B is easier if we do A first)
stories
user stories 라고도 불림. user 입장에서 적혀진 작은 요구사항 혹은 요청 (ex - pay page 에서 빨간색으로 강조된 결제 버튼을 볼 수 있다 / 계좌이체가 아니라 카드 등록을 통해 정기구독을 할 수 있도록 한다.)
“As a [persona], I [want to], [so that].” 를 기반으로 작성되어야함. (페르소나 + 필요 + 목적) ⇒ 사용자에게 어떤 가치를 제공할 것인지에 더 집중하게함.
•
as a persona
누구를 위해
•
want to
무엇을 원하는지.
•
달성하려는 전반적인 이점이 무엇인지
examples
•
As Max, I want to invite my friends, so we can enjoy this service together.
•
As Sascha, I want to organize my work, so I can feel more in control.
•
As a manager, I want to be able to understand my colleagues progress, so I can better report our sucess and failures.
위와 같이 작성하는 것은 필수는 아닌데 done 을 정하는데 도움이 됨.
epics
작은 단위(stories)로 나눌 수 있는 작업의 큰 틀 (ex - 결제를 더 편하고 쉽게 할 수 있도록 하자)
initiatives
목표를 위한 epic 의 집합 (ex - 순이익 10% 를 늘려보자)
themes
조직 전체가 바라보는 큰 관점
애자일 팀에서 story 는 1~2주 내에 완료하기로 약속할 수 있는 것.
Scum metrics
스크럼 팀이 효율을 증가시키기 위해 track 하고 사용하는 data point. 팀이 planning 이나 execution 을 할 때 결정을 돕는데 사용된다. 또한 팀의 performance 를 알 수 있고, 팀원 개개인에게 더 동기부여를 할 수도 있다. 또 시간이 지남에 따라서 팀의 만족도와 행복도를 알 수 있게 한다(?)
또한 ROI 를 측정할 수 있는 수단 또한 될 수 있을 것이다.
burn down chart
Sprint 기간동안 작업 시간(or storypoint) 과 남은 시간을 계산해서 chart 로 표현한다. 지정된 시간 안에 작업을 완료할 수 있는 팀의 능력을 예측하고 변화를 추적하는데 유용하다.
개인을 공격하는 무기가 되어서는 안된다. 개인의 생산성을 평가하는데 사용한다면 팀의 사기가 저하될 수 있다. 대신에 팀이 자신이 얼마의 작업량을 소화하고 있는지, 어디에 도움이 필요한지 공개적으로 공유할 수 있는 환경을 만드는 것이 중요하다.
ex - 보니 너무 user story 작업보다 tech debt 과도하게 많은 시간을 사용하는 것을 알았다. 이유를 알아보니 test convention 이 정해져있지 않아 항상 test code 를 짤 때마다 고민하는 시간 및 code review 시간이 길었다는 것을 알게 되었다. test convention 을 명확히 정하는 작업을 next sprint 에 포함시키기로 했다.
scrum 의 목적이 팀이 일을 더 잘할 수 있게 위한 것이다. scrum metrics 의 목적은 scrum 이 제대로 작동하고 있는지 팀원들에게 알 수 있도록 하게 위한 것이다. metics 가 사용될 때는 팀원들이 너무 부담을 느끼는 것이 아니라 insight 를 얻도록 하는 것이 좋다.
Kanban
agile 구현에 사용되는 쓰이는 유명한 framework. 작업 사항들은 kaban board 로 표현되고, 해당 작업 사항들의 상태를 팀원들이 실시간으로 언제나 볼 수 있다.
역량에 대한 실시간 커뮤니케이션과 완전한 투명성을 요구함. commitment point 에서 delivery point 로의 시간을 줄이는데 초점을 맞춘다.
장점
•
팀이 더 유연하게 작업을 계획할 수 있도록 하면서 작업을 더 빠르고 명확하게 집중적으로 처리할 수 있도록 도와준다. 작업 간의 의존도도 확인해서 우선순위를 정하기에도 좋다
•
time cycle 단축
time cycle 이란 하나의 작업에 대해서 상태가 변경되기까지 걸리는 총 시간이다.
skill set 을 공유하는 것은 time cycle 을 줄일 수 있는 방법이다. 한 사람만 하나의 skill set 을 가지고 있을 때 작업의 병목현상이 발생할 수 있다. 때문에 code review, mentoring 등의 방법을 통해서 knowledge 를 분산하면 time cycle 을 줄일 수 있을 것.
•
병목 현상 감소
Multitasking 은 효율성이 떨어진다. 자주 switching 이 일어나면 작업을 완료하는데 잦은 방해가 발생한다. kanban 의 핵심 요소 중 하나는 WIP 상태의 작업량을 제한하는데 있다.
WIP limits
팀이 작은 단위의 작업에 집중할 수 있도록 도와주며, blocker, bottleneck 을 찾는데 도움을 준다. 팀원들이 blocking issue 에 대해서 이해하고 해결하며 무엇이 병목현상을 발생하게 하는지 이해하도록 돕는다.
일단 작업을 진행하려는 유혹을 뿌리칠 수 있도록 팀원들에게 WIP limits 을 하는 가치, 이유를 공유하는 것이 좋다.
흥미로운 예가 있어서 공유해본다
한 개발팀에서 To Do, In Progress, Code Review, Done 상태들을 가지고 있다. 그리고 WIP 상태를 인 당 2개로 제한을 했다. 매우 작은 제한이라고 생각할 수도 있겠지만 개발자들은 주로 코드 리뷰를 하는데 사용하는 것 보다 새로운 코드를 작성하는 것을 더 선호한다. 제한을 작게 두는 것은 review state 에 있는 작업에 집중하는 것을 더 장려한다. 궁극적으로 전체적인 cycle time 을 줄이게 될 것이다
개개인의 작업량을 일관적으로 관리하도록 한다. 때문에 하나의 요구사항에 대해서 하나의 작업이 16시간을 넘지 않도록 작업을 쪼개는 것이 중요하다.
그리고 지속 가능한 개발 문화를 만드는 것이 중요하다. WIP limits 는 작업 회피의 대상이 아니다. 빨리 작업을 끝내고 WIP limit 때문에 빈둥거리거나 노는 것이 아니라 code review 를 장려하고, pair programming 을 장려할 수도 있다. 그리고 제품의 quality 및 code base 향상을 위해 노력할 수도 있을 것이다.
kaban boards
팀의 작업 상태들을 시각화하고 팀들 간의 work flow 최적화 하는데 사용된다. 일반적으로 Todo, In Progress, Done 의 상태를 가지는데, 팀의 사이즈, 워크 플로우 등에 따라서 상태를 추가해도 관계 없다.
kanban cards
작업을 하나의 카드로 표현하는 것은 팀원들이 workflow 를 구상하기 위해서 작업의 상태를 tracking 하는데 주된 목적이 있다. 누가 이 작업을 처리하고 얼마나 걸릴지, 어떤 범위까지가 이 작업의 범위인지 등이 표현된다.
CI / CD
CI/CD pileline 은 빠른 개발과 high quality 를 위해서 개발팀에게 필수적이다. Kanban 과 CD 는 적시에, 한번에 하나씩 고객들에게 가치를 전달한다는 점에서 상호 보완적으로 작동할 수 있다.
metrics
Scrum vs Kanban
둘 모두 Agile 원칙에 도달하기 위한 framework 다.
사실 둘의 사용 방법을 비교하는게 쉽기는 하지만 둘의 원칙을 비교하는 것이 더 좋을 것이다.
Show All
Search
Scum 에서도 kanban board 를 사용하기는 하지만 kanban framework 와 핵심적으로 차이점이 있다
•
scrum 은 sprint 라는 주기가 있어서 start, end date 가 정해져있다. kanban 은 계속 진행하는 process 이다.
•
scrum 에서는 role 이 명확히 구분이 된다.
•
kanbanboard 는 프로젝트 전체 수명 주기에서 사용이 되는데, scum board 는 스프린트 기간 후 비워지고 recycled 된다.
•
kanban boards 가 상대적으로 더 작업을 수행하는데 더 유연하다. (scum 이 더 sprint 계획 및 estimate 에 초점을 맞추는 반면 (변화를 거부하는 것은 아니지만 가능한 정확한 sprint 계획과 estimate 를 요구), kanban 은 언제든지 필요에 따라 우선순위를 재정렬하고 작업 담당이 재할당될 수 있으며, 수정될 수 있다.
Scrumban 과 kanplan 이란 것도 있다.
Estimation
estimation 을 잘하면 Product Owner 가 좋은 제품을 개발할 수 있도록 효율성 및 영향력을 높이는데 도움이 된다.
애자일은 추정이다. 피의 맹약 같은게 아니다! 이것을 지키기 위해 야근할 필요가 없다!
story point
기존 프로젝트에서는 estimate 를 시간 단위로 측정했다.
agile 팀에서는 backlog item 을 해결하는데 드는 종합적인 노력의 추정치를 표현하기 위한 측정 단위로 story point 를 사용한다. (일의 복잡성, 작업량, 위험 or 부정확성 등을 종합 고려) 때문에 point 를 더 정확히 표현하기 위해서 작업을 더 작은 단위로 쪼개는 것이 좋다.) 이러한 story point 를 사용하는 이유는 무엇일까?
•
시간 단위 estimate는 프로젝트와 관련되지 않은 작업(예로 회의, 인터뷰, 등)은 고려되지 않는 경우가 많다.
•
시간 단위 estimate 에 비해서 감정적인 요소를 제거 ⇒ 뭔소리지?
•
각 팀들의 work 를 평가할 때 일괄적으로 시간을 통해서 평가하기엔 적합하지 않은 요소가 있다.
•
story point 는 소요 시간이 아니라 난이도에 따라 문제를 해결한 팀원에게 보상으로 주어짐. 때문에 시간을 사용하는 것 보다 높은 가치를 제공하는데 더 많은 노력을 하게 될 것.
단! 팀원들을 평가하는데 사용되거나 상세한 일정 및 리소스를 할당하는데 사용될 때, 그리고 생산성의 척도가 때는 story point 를 잘못 사용하는 것이다. 대신 팀은 스토리 포인트를 사용하여 작업의 크기와 작업의 우선 순위를 이해해야한다.
planning poker
팀이 함께 story point 를 estimate 한다.
smart estimating
상한선을 정하고 estimate 를 한 후 상한선을 넘어서는 개별 작업에 대해서는 더 세분화한다.
예를 들어서 시간은 max 16시간으로 정했다면 16시간을 넘는 작업에 대해서는 세분화하는 작업이 필요하다.
estimate 을 확실히 하면 물론 좋겠지만 대략적인 추정치를 제공하는 것만으로 충분하다. 왜냐하면 실제 작업을 하기 전이나 중간에 요구사항이 변하기도 하며, 아무리 신경써서 해도 estimate 이 정확하지도 않을 수 있기 때문이다. 때문에 Product Owner 에게 제품 로드맵의 우선 순위를 적절하게 지정하는 데 사용할 수 있는 주요 수치를 제공하기만 하면 된다.
과거 추정치로부터 개선하기
회고는 팀이 추정의 정확성을 포함하여 과거 반복에서 얻은 통찰력을 통합하는 시간이다. 예를 들어, 스토리 포인트 값 8로 팀이 전달한 마지막 5개의 사용자 스토리를 가져온 후. 해당 작업 항목 각각이 비슷한 수준의 노력을 가졌는지 토론해본다. 이 과정을 통해서 시간이 지날수록 estimate 이 더 좋아질 것이다.
이 모든 것은 팀 개개인을 평가하는 것이 목적이 아니라 팀의 workflow 를 관리하는 것!
그리고 interaction 이 중요하고 정보의 공유가 중요하다!
열심히 일하지 말고 똑똑하게 일하자!
우리 팀의 현황은?
•
Framework - Scrum!
Default view
Search
현강님 Role 이 많다.
우리 팀에 더 효율적으로 적용하기 위해서는 어떤 방법들이 있을까?
•
현강님 Role 을 나눠갈 분을 채용하면 좋겠다.(언젠가...)
◦
그게 아니라면 Kanban Framework 의 일을 통해서 Role 의 부담을 없앤다? (사실 이건 어떻게 될지 잘 모르겠음)
•
모두의 작업 상태를 볼 수 있는 통일된 Kanban 을 사용하면 좋을 것 같다. (현재 개발팀만 볼 수 있는 Epic 과 서비스 기획이 있긴한데 뭔가 나뉘어져 있다는 느낌이다. 현강님도 Epic 에 포함될 때도 분명이 있을텐데.)
•
Daily Scrum 에서 backlog kanban 을 사용한다
위 방법을 사용하는 이유는 더 적극적으로 epic 및 story 를 생성하도록 유도하는 것. 현재 우리 팀에서 나온 문제의 사항으로 epic, story 사항들을 꼼꼼히 기록하지 않는 것, 그리고 기타 작업에 대해서 story 를 생성하지 않고 그냥 작업하는 것 등이 있었다.
현재 팀에서 Daily Scrum 문서를 따로 만들어서 작성하고 있는데 이것은 나쁘지 않다고 생각이 된다. 그러나 각자가 어제 한 일, 오늘 할 일, 막힌 것들에 대해서 말할 때 backlog kanban 을 보면서 하면 각각의 팀원들이 story 생성 및 관리를 더 장려할 수 있을 것이다.
•
epic state 에 workflow 를
todo - in progress - code review - done - staging - production
위와 같은 state 로 있으면 좋을 것 같다. code review state 때문에 항상 카드 옮기는게 힘들었다.
더 명확히 state 구분해서 작업 현황을 구분하면 좋겠고, 더 병목 현상을 찾기 쉽다는 장점도 있지 않을까
그리고 카드를 옮기면서 얻는 성취감이나 그런 것도 좋을 것 같다.
•
userStory 및 Epic 에 action type 을 정하자 (bugfix, feature, tech-debt, demo modify).
어느 영역에서 시간을 많이 쓰는지도 확인하면 좋을 것 같다.
•
우리가 정말 효율적으로 일하고 있는가? 에 대한 트래킹이 이루어지고 있는가? story point 도, epic 도 사용하고 있지만? 우리 팀 전체에서 공유되는 것 보다는 리드급에서만 트래킹하는 것이 좋을까?
•
적합한 tool 을 사용하는 것이 좋을 것 같다. (개인적으로 JIRA 좋았다)
notion 틀도 너무 잘 만들어놓았다. 하지만 모두가 편하게 볼 수 있고 좀 더 scrum 에 적합한 형태의 툴을 쓴다면 일을 더 편하게 할 수 있지 않을까?