Урок за SAFe (мащабирана гъвкава рамка).
⚡ Умно обобщение
Scaled Agile Framework (SAFe) е база от знания за прилагане на Lean-Agile практики на корпоративно ниво, организирана на нивата на екип, програма, портфолио и поток от стойност, за да помогне на големите организации да планират, бюджетират и предоставят стойност със съгласуваност и вградено качество.

Какво е SAFe (Scaled Agile Framework)?
Мащабирана гъвкава рамка (SAFe) е свободно достъпна онлайн база от знания, която ви позволява да прилагате практики за икономична гъвкавост на ниво предприятие. Той предоставя просто и леко изживяване за разработка на софтуер. Това е набор от организации и модели на работни потоци, предназначени да насочват предприятията за мащабиране на икономични и гъвкави практики. Той е разделен на три сегмента, които са екип, програма и портфолио.
сейф рамката позволява на екипа за,
- Внедряване на Lean-Agile софтуер и системи на корпоративно ниво
- Базиран е на принципите на Lean и Agile.
- Той дава подробни насоки за работа в предприятието Портфолио, Поток от стойност, Програма и Екип.
- Той е проектиран да отговори на нуждите на всички заинтересовани страни в една организация.
SAFe е разработен за първи път в тази област и е разработен през Дийн Лефингуелs книги и блог. Версия 1.0 е първата официална версия през 2011 г. Последната версия е 4.6, пусната през октомври 2018 г. Тя предоставя насоки за работа на корпоративно портфолио, поток от стойности, програма и екип.
Защо да използвате SAFe Agile Framework
Това е проста и лека рамка, но същевременно е в състояние да се справи с нуждите на големи потоци от стойност и разработка на сложна система. Чрез внедряването на гъвкавата рамка на SAFe ще имате следните предимства:

- Производителността се увеличи by 20 - 50%
- Качество се увеличи повече от 50%
- Време за пазар е по-бързо от 30 -75%
- Повишена ангажираност на служителите намлява удовлетворение от работата.
Подробната диаграма на рамката е достъпна на уебсайт. Той показва всички ключови роли, дейности, резултати и потоци. Той също така служи като навигационна помощ за останалата част от сайта.
Изображението по-долу обяснява как работи гъвкавият процес. Епосите са голямо произведение, което е допълнително разделено на редица по-малки истории или под-епоси. Тези под-епоси са разпределени на екипа като история. След това всеки екип работи съответно върху тези истории или софтуерни функции.
Кога да използвате Scaled Agile Framework
- Когато един екип е заинтересован да прилага гъвкав подход последователно в по-големи програми и портфолиа с множество екипи.
- Когато множество екипи изпълняват свой собствен начин на внедряване на Agile, но редовно се сблъскват с препятствия, забавяния и неуспехи.
- Когато екипите искат да работят независимо.
- Когато искате да мащабирате Agile в цялата организация, но не сте сигурни какви нови роли може да са необходими или какви съществуващи роли (т.е. управление) трябва да се променят и как.
- Когато сте се опитали да разширите Agile във вашата организация, но се борите за привеждане в съответствие, за да постигнете единна или последователна стратегия в бизнес отделите от портфолио до ниво програма и екип.
- Когато една организация трябва да подобри времето за разработване на своя продукт и иска да знае как други компании са успели да разширят Agile със SAFe.
Колко различно от другите Agile практики
Сега в този урок за Scaled Agile Framework, нека видим как Scaled Agile Framework се различава от другите гъвкави практики,
- Той е публично достъпен и безплатен за използване.
- Предлага се в много достъпна и използваема форма.
- Той е лек, с практически доказани резултати и специфичен за ниво.
- Постоянно/редовно модифицира/поддържа най-често използваните гъвкави практики.
- Предлага полезни разширения на обичайните гъвкави практики.
- Основава гъвкавите практики в корпоративния контекст.
- Предлага пълна картина на разработката на софтуер.
- Видимостта или прозрачността е повече на всички нива.
- Постоянна или редовна обратна връзка относно качеството и подобрението.
Foundations на Scaled Agile Framework
Мащабирана гъвкава рамка (SAFe): Стои върху основите на своята
- Принципи на Lean-Agile
- Основни ценности,
- Lean-Agile лидерство
- Lean-Agile Mind set,
- Общности от практикуващи (Група от хора, които постоянно работят върху SAFe практики)
- Изпълнение на 1-2-3
SAFe Lean-Agile принципи
Тези основни принципи и ценности на SAFe Agile за SAFe трябва да бъдат разбрани, изложени и продължени, за да получите желаните резултати.
- Вземете икономически поглед
- Приложете системно мислене
- Приемете променливост; запазване на опциите
- Изграждайте постепенно с бързи интегрирани цикли на обучение
- Базирайте етапи на обективна оценка на работещи системи
- Визуализирайте и ограничете WIP, намалете размера на пакетите и управлявайте дължините на опашката
- Приложете каданс, синхронизирайте с междудомейн планиране
- Отключете вътрешната мотивация на работещите със знания
- Децентрализирайте вземането на решения
Основни ценности на SAFe Agile
Методологията SAFe Agile се основава на тези четири ценности.
Подравняване:
- SAFe поддържа подравняване.
- Подравняването започва от,
- Стратегически теми в Portfolio Backlog и
- Преминава надолу към Визия и пътна карта на неизпълнените програми и след това
- Премества се в екипа Backlogs.
Вградено качество:
- Той гарантира, че всяка поетапна доставка отразява стандартите за качество.
- Качеството не е вградено „добавено по-късно“.
- Вграденото качество е предпоставка за Lean и е задължително
Прозрачност:
- Прозрачността е факторът за доверие.
- SAFe помага на предприятието да постигне прозрачност на всички нива – ръководители, портфолио мениджъри и други заинтересовани страни.
- Всеки може да види в портфейлното изоставане/Kanban, неизпълнените програми/Kanban и Team Backlog/Kanban.
- Всяко ниво има ясно разбиране на целите на PI.
- Програмите за обучение имат видимост в неизпълнените задачи на екипа, както и в други неизпълнени програми
- Екипите и програмите имат видимост в бизнеса и архитектурата Epics. Те могат да видят какво може да се насочи към тях.
Изпълнение на програмата:
- SAFe поставя голям фокус върху работещите системи и произтичащите от това бизнес резултати.
- SAFe не е полезен, ако екипите не могат да изпълняват и непрекъснато да доставят стойност.
Lean Agile лидери
Lean-Agile лидерите са учещи през целия живот и учители. Помага на екипите да изградят по-добри системи чрез разбиране и демонстриране на принципите на Lean-Agile SAFe.
Като средство за подпомагане на екипите, крайната отговорност е приемането, успехът и непрекъснатото подобряване на Lean-Agile разработките. За промяната и непрекъснатото усъвършенстване лидерите трябва да бъдат обучени.
Лидерите трябва да възприемат нов стил на лидерство. Такъв, който наистина дава сила и ангажира индивиди и екипи да достигнат най-високия си потенциал.
Принципи на тези Lean-Agile лидери
- Водете промяната
- Познай пътя; Наблегнете на ученето през целия живот
- Развивайте хора
- Вдъхновяване и привеждане в съответствие с мисията; Минимизиране на ограниченията
- Децентрализиране на вземането на решения
- Отключете вътрешната мотивация на работещите със знания
Lean Agile Mind Set
Lean-Agile мисленето е представено в две неща:
- SAFe Къщата на Lean
- Агилен манифест
SAFe House of Lean:
SAFe произлиза от принципите и практиките на Lean производство. Въз основа на тези фактори SAFe представя „SAFe House of Lean“. Той е вдъхновен от „къщата“ на тънката Toyota.
Целта на lean е непобедима: да се достави максимална клиентска стойност в най-кратки срокове с възможно най-високо качество за клиента
Фигурата по-долу обяснява целта, стълбовете и Foundation на „SAFe House of Lean“.
Агилен манифест
Откриваме по-добри начини за развитиеping софтуер, като го направите и helping други го правят. Чрез тази работа ние научихме да ценим:
Ето защо, въпреки че има стойност в елементите отдясно, ние ценим повече елементите отляво.
Агилен манифест
- Най-високият приоритет е да се удовлетвори клиентът чрез непрекъсната и ранна доставка на ценен софтуер.
- Прегърнете променящите се изисквания, дори в по-късна фаза на разработка. Методологията Agile SAFe обработва смяната на сбруята в полза на клиента.
- Доставяйте работещ софтуер често, от няколко седмици до няколко месеца, с предпочитание към по-краткия срок.
- Разработчиците и бизнесмените трябва да работят заедно ежедневно по време на проекта.
- Изграждайте проекти около мотивирани личности. Дайте им подкрепа и средата, от която се нуждаят, и им се доверете, за да свършат работата.
- Най-ефективният метод за комуникация с екипа за разработка е разговор лице в лице.
- Работещият софтуер е основната мярка за напредък.
- Гъвкавите процеси насърчават устойчивото развитие. Спонсорите, разработчиците и потребителите трябва да могат да поддържат постоянно темпо за неопределено време.
- Постоянното внимание към техническото съвършенство и добрия дизайн подобрява гъвкавостта.
- Опростеността – изкуството да се максимизира количеството несвършена работа – е от съществено значение.
- Най-добрите архитектури, изисквания и проекти възникват от самоорганизиращите се екипи.
- На редовни интервали екипът обмисля как да стане по-ефективен, след което настройва и коригира поведението си съответно.
Различни нива в SAFE
Има два различни типа изпълнение на SAFe:
- Внедряване на SAFe 4.0
- Внедряване на SAFe 3.0
- В изпълнението на SAFe 4.0 имаме 4 нива: Портфолио, поток от стойност, програма и екип.
- В изпълнението на SAFe 3.0 имаме 3 нива: Портфолио, програма и екип
- 3-Level SAFe е за по-малки реализации със 100 или по-малко хора. Програми, които не изискват значително сътрудничество.
- 4-Level SAFe е за решения, които обикновено изискват много стотици практици за разработване на внедряване и поддръжка на софтуер.
Отборно ниво
| Роли/Екипи | Събития | Артефакти |
|---|---|---|
| Agile екип | Sprint Планиране | Изоставане на екипа |
| Каталог на Owner | Подреждане на натрупани задачи | Нефункционални изисквания |
| Scrum магистър | Ежедневен стендъп | Цели на екипния PI |
| Изпълнение | Итерации | |
| Sprint Демонстрация | Истории (работещ софтуер) | |
| Sprint ретроспективен | Sprint Целите на | |
| IP Sprints | Вградено качество | |
| Шпайкове | ||
| Екип Канбан |
- Всички екипи на SAFe са част от един или друг Agile Release Train (ART).
- Екипите на SAFe са овластени, самоорганизиращи се, самоуправляващи се, многофункционални екипи
- Всеки екип е еднакво отговорен за дефинирането, изграждането и тестването на истории от своя Team Backlog в итерации с фиксирана дължина
- Екипите планират и изпълняват двуседмични ограничени във времето итерации в съответствие с договорените цели на итерацията.
- Екипите ще използват ScrumXP/Team Kanban рутина, за да предоставят висококачествени системи за създаване на демонстрация на системата на всеки две седмици.
- Всички различни екипи в ART (Agile Release Trains) ще създадат интегрирана и тествана система. Заинтересованите страни ще оценят и ще отговорят с бърза обратна връзка
- Те прилагат вградени практики за качество.
- Всеки ScrumXP екип ще има 5-9 членове на екипа, което включва всички роли, необходими за изграждане на качествена нарастваща стойност във всяка итерация.
- ScrumXP ролите включват:
- Екип (разработка+осигуряване на качеството)
- Scrum магистър
- Собственик на продукта. и т.н.
- SAFe разделя графика за разработка на набор от итерации в рамките на PI (програмно увеличение).
- Продължителността на PI е между 8 -12 седмици.
- Екипът ще използва истории, за да предостави стойността. Собственикът на продукта ще има правомощия за съдържанието върху тяхното създаване и приемане на историите.
- Историите съдържат изискванията на клиента.
- Team Backlog включва потребителски и активиращи истории, които се идентифицират по време на планирането на PI. Когато продуктовият мениджмънт представя пътната карта, визията и изоставането на програмата.
- Идентифицирането, разработването, приоритизирането, планирането, внедряването, тестването и приемането на историите са основните изисквания на управленската работа на ниво екип.
- Всяка итерация осигурява:
- Ценно увеличение на новата функционалност
- Изпълнете чрез постоянно повтарящ се модел
- Планирайте итерацията
- Ангажирайте се с някаква функционалност
- Изпълнете итерацията чрез изграждане и тестване на истории
- Демонстрирайте новата функционалност
- ретроспективен
- Повторете за следващата итерация
- Екипите също поддържат демонстрацията на системата в края на всяка итерация. което е критичната интеграционна точка за ART.
- Потоците с по-голяма стойност ще имат множество ARTs.
- Итерациите за иновации и планиране (IP) предоставят на екипите възможност за иновации и проучване.
Ниво на програмата
| Роли/Екипи | Събития | Артефакти |
|---|---|---|
| DevOps | Планиране на PI (програмен инкремент) | Визия |
| Системен екип | Системни демонстрации | Пътна карта |
| Управление на издаване | Работилница за инспекция и приемане | Метрика |
| Продуктов мениджмънт | Archiтектурна писта | Важни събития |
| UEX Archiвор | Публикуване по всяко време | Пресата |
| Инженер по освобождаване на влака (RTE) | Agile Release Train | Програмни епоси |
| Система Architect/инженер | Освободете | Програма Канбан |
| Собственици на фирми | Изоставане по програмата | |
| Lean-Agile лидери | Нефункционални изисквания | |
| Практически общности | Претеглена най-кратка работа на първо място (WSJF) | |
| Споделени услуги | Цели на програмния PI | |
| Клиентски | Особеност | |
| Енблеър | ||
| Решение | ||
| Координация на потока от стойност |
- На ниво програма, стойността на SAFe се доставя от дълготрайни гъвкави релейз влакове (ART). Итерацията е за екипа, а обучението е за програмата.
- Agile Release Trains (ART) е основното средство за предоставяне на стойност на ниво програма. Той доставя поток от стойност на организацията.
- Продължителността на увеличаването на програмата (PI) е от 8 до 12 седмици.
- ART се състои от 5 – 12 гъвкави екипа (~50 – 125+ души), които включват всички роли и инфраструктура, необходими за доставяне на напълно тестван, работещ софтуер на системно ниво.
- Всеки PI е времева кутия с множество итерации. По време на което се разработва и доставя значително, ценно увеличение на системата.
- Във всеки PI ще се провеждат сесии „демо“ и „Инспектиране и адаптиране“ и започва планирането за следващия PSI.
- На ниво програма SAFe акцентира върху принципа на привеждане в съответствие. Това е така, защото усилията на множество гъвкави екипи са интегрирани, за да се създаде стойност за клиента.
- Йерархията на артефактите на SAFe е Епоси->функции->потребителски истории.
- На ниво програма продуктовият мениджър/мениджърът на програмата има правомощия за съдържание. Той определя и приоритизира изоставането в програмата.
- Изоставането на програмата е списък с приоритети от функции.
- На ниво програма функциите могат да бъдат създадени или могат да произтичат от епоси, дефинирани на ниво портфолио.
- Функциите се разлагат на потребителски истории и се вливат в неизпълнени задачи на ниво екип.
- Ролята на продуктов мениджър или Release Train Engineer може да се изпълнява от програмен мениджър/старши ръководител на проекти
- Система ArchiТектната роля на ниво програма е да си сътрудничат в ежедневната работа с екипите. Той гарантира, че са изпълнени нефункционалните изисквания. Освен това те работят с корпоративния архитект на ниво портфолио, за да се уверят, че има достатъчна архитектурна писта за поддържане на предстоящи потребителски и бизнес нужди.
- Дизайнът на интерфейса, насоките за потребителско изживяване и дизайнерските елементи за екипите се предоставят от UX Designers.
- Ролята на Chief-Scrum Master се играе от 'Release Train Engineer'.
- Различен екип (от маркетинг, разработка, качество, операции и внедряване) формира „Екип за управление на версиите“. Те ще одобряват рутинни издания на качествени решения за клиентите.
- Внедряването на софтуер в клиентски среди и успешната доставка се грижи от екипа на DevOps.
Ниво портфолио
| Роли/Екипи | Събития | Артефакти |
|---|---|---|
| Enterprise Architect | Стратегическо планиране на инвестициите | Стратегически теми |
| Управление на програмен портфейл | Планиране на Канбан портфолио (Epic) | Enterprise |
| Епични собственици | Изоставане в портфолиото | |
| Канбан портфолио | ||
| Нефункционални изисквания | ||
| Епично и Подкрепящо | ||
| Поток на стойността | ||
| Бюджети (капиталови разходи и оперативни разходи) |
- Най-високото ниво на интерес/загриженост/участие/ в SAFe е Портфолио на SAFe
- Портфолиото предоставя основните блокове за организиране на потока от стойност на Lean-Agile Enterprise чрез един или повече потоци от стойност.
- Портфолиото помага за разработването на системи и решения, които са описани в стратегически теми (свързва портфолиото на SAFe с променящата се бизнес стратегия на предприятието).
- За постигане на стратегическите цели нивото на портфолиото капсулира тези елементи. Той предоставя основно бюджетиране и други механизми за управление. По този начин се гарантира, че инвестицията в потоците от стойност осигурява възвръщаемостта, необходима за предприятието.
- Портфолиото е свързано с бизнеса двупосочно:
- За да насочи портфолиото към по-големите променящи се бизнес цели, то предоставя стратегически теми.
- Друга посока показва постоянния поток от стойности на портфейла.
- Управлението на портфейла на програмата действа като заинтересовани страни и те носят отговорност за постигането на бизнес резултати.
- Нивото на портфолиото на SAFe съдържа хора, процеси и необходими системи за изграждане и решения, от които едно предприятие се нуждае, за да постигне своите стратегически цели.
- Потоците от стойност са основните цели в портфолиото, с които се осигурява финансиране за хората и другите ресурси, необходими за изграждането на решенията.
- Важни ключови концепции, използвани тук, са:
- Връзка с предприятието,
- Управление на портфолиото на програмата,
- Управление на потока от портфолио Epics.
Ниво на потока от стойности
| Роли/Екипи | Събития | Артефакти |
|---|---|---|
| DevOps | Планиране преди и след PI (програмен инкремент) | Визия |
| Системен екип | Демонстрации на решения | Пътна карта |
| Управление на издаване | Работилница за инспекция и приемане | Метрика |
| Управление на решения | Agile Release Train | Важни събития |
| UEX Archiвор | Пресата | |
| Инженер по потока на стойността (RTE) | Епоси на потока от стойност | |
| Решение Architect/инженер | Канбан на потока от стойност | |
| Споделени услуги | Натрупани задачи по потока на стойността | |
| Клиентски | Нефункционални изисквания | |
| Доставчик | Претеглена най-кратка работа на първо място (WSJF) | |
| Цели на PI на потока от стойност | ||
| Способност | ||
| Енблеър | ||
| Контекст на решението | ||
| Координация на потока от стойност | ||
| Икономическа рамка | ||
| Намерение за решение | ||
| МБСЕ | ||
| Базирано на множество | ||
| Пъргав Archiтекстура |
- Нивото на потока от стойности не е задължително в SAFe.
- Нивото на потока от стойности е ново в SAFe 4.0.
- Нивото на потока от стойности е предназначено/проектирано за предприятия/строители/организации, които са:
- Голям по размер
- Независим
- Имайте комплексни решения
- Техните решения обикновено изискват множество ARTs
- Те имат принос на доставчици.
- Те са изправени пред най-големите системни предизвикателства
- За киберфизически системи
- За софтуер, хардуер, електричество и електроника, оптика, механика, флуиди и др.
- Изграждането на този вид системи често отнема стотици, дори хиляди практици, външни и вътрешни доставчици.
- Ако системите са от решаващо значение за мисията. Отказът на решението или дори на подсистемата има неприемливи икономически и социални последици.
- Ако Предприятията могат да бъдат изградени с няколкостотин практикуващи, може да не се нуждаят от конструкции от това ниво. В този случай те могат да използват от „свит изглед' който е 3-ниво SAFe.
- Изграждането на решения за поток от стойност в Lean-Agile модел изисква допълнителни артефакти, координация и конструкции. Така че това ниво съдържа икономическа рамка за предоставяне на финансови граници за потока от стойности
- Той поддържа каданс и синхронизация за множество ARTs и доставчици. Включва срещи за планиране преди и след PI и демонстрация на решение.
- Той дава допълнителни роли, които са: Инженер на потока от стойности, Решение Architect/Engineering и Solution Management.

