Scaling
비교적 작은 과제에 효과적인 방법입니다.
그러나 Scrum이 작은 과제들에서 성공적인 결과를 보이면서
규모가 큰 과제로도 확장을 하는 사례가 많이 있습니다.
큰 규모의 과제를 수행하게 됩니다.
원칙은 각 팀별로 Scrum Master가 있을 수 있으나
1명의 Product Owner가
하나의 Product Backlog을 관리하게 됩니다.
LeSS (Large-Scale Scrum) framework 은
Scrum의 기본적 개념을 큰 규모로 확장한 방식입니다.
규모에 따라
LeSS : 8개 팀 이하인 경우
Less Huge: 9개팀 이상인 경우로 나눕니다.
기본적 Scrum과 다른 점들로:
Sprint Planning Part 1: PO와 모든 팀원들이 함께 진행
Sprint Planning Part 2: 각 팀별로 진행
팀 별 Product Backlog Refinement에 추가적으로
Overall Product Backlog Refinement를 가질 수 있고
팀 Sprint Retrospective에 추가적으로
Overall Retrospective가 있습니다.
Essential, Large Solution, Portfolio, Full
등으로 구분됩니다.
이에 대해 지나치게 규범적 (prescriptive) 이어서
별로 Agile하지 않다는 비판이 많이 있는 것이 사실입니다.
Agile Glossary : SAFe
SAFe에 대한 전문가들의 의견 1
SAFe에 대한 전문가들의 의견 2
미국 공군의 Chief Software Officer는
2019.11.26.에 Software에 관련된
모든 Program Executive Officer들과 Project Manager들에게
DevSecOps와 Agile의 활용에 관한
메모 (Memorandum for Record)를 보냈습니다
(오른 쪽 그림).
Cloud Infrastructure인 Cloud One과
DevSecOps를 제공하는 Platform One by LevelUP과 같은
획기적 기술들을 효과적으로 활용하기 위하여는
익숙해 보이는 Waterfall 방식이 아닌
가볍고 유연한 Agile Framework을 선택하여야 하고
XP, Kanban, Scrum 등을 권장한다고 되어 있습니다.
흥미롭게도 Scaled Agile Framework (SAFe)과 같은
엄격하고 규범적인 (prescriptive) 방법을 사용하는 것은
강하게 반대한다고 명시하고 있습니다.
이 메모에 대한 관련자들과의 질의 응답이 있었는데 그 이유로:
국방성 (Department of Defence)는 아직
Waterfall 내지 Water-Agile-Fall 방식을 사용 중이어서
우리가 Scrum이나 Kanban 등을 제대로 구현할 수 있을 때 까지는
확장할 그 무엇이 없다.
DevSecOps의 주요 원칙 중 하나는 일과 팀을 분리시키는 것이고
팀들 사이의 동기화는 Product Owner를 통하여 이루어져야 한다.
Software 개발에 있어서 중요한 것은
혁신 (Innovate)과 창조 (Create) 이다.
위험을 무릅쓰지 않으면 창조할 수 없다.
빠른 실패 (fail fast)를 통해 지속적으로 배워가는 것이 필요하다.
성공적인 기업들 (Facebook, Google, Netflix 등)은 SAFe를 쓰지 않는다.
믿지 못한다면 Agile 전문가들의 얘기를 들어 보라: