Урок за методология на SAFe: Какво е Scaled Agile Framework

Какво е Scaled Agile Framework (SAFe)?

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

Рамката SAFe позволява на екипа за,

• Внедряване на Lean-Agile софтуер и системи на ниво предприятие
• Базира се на принципите на Lean и Agile.
• Той дава подробни насоки за работа в корпоративното портфолио, стойностния поток, програма и екип.
• Той е проектиран да отговори на нуждите на всички заинтересовани страни в рамките на една организация.

SAFe е разработен за първи път в тази област и е разработен в книгите и блога на Дийн Лефингуел . Версия 1.0 е първото официално издание през 2011 г. Последната версия е 4.6, пусната през октомври 2018 г. Тя предоставя насоки за работа на корпоративно ниво на портфолио, стойност на потока, програма и екип.

В този урок SAFe Agile ще научите -

• Какво е Scaled Agile Framework (SAFe)
• Защо да използваме Agile Framework
• Кога да се използва Scaled Agile Framework
• Колко различни от другите Agile практики
• Основи на Scaled Agile Framework
• Agile Manifesto
• Различни нива в SAFE
• Екипно ниво
• Програмно ниво
• Ниво на портфолио
• Ниво на стойност на потока

Защо да използваме Agile Framework

Това е проста и лека рамка, но въпреки това е в състояние да отговори на нуждите на големи потоци от стойности и сложна система за развитие. Чрез прилагането на гъвкавата рамка SAFe ще имате следните предимства:

• Производителността се увеличава с 20 - 50%
• Качеството се е увеличило с повече от 50%
• Времето за пускане на пазара е по-бързо от 30 -75%
• Повишена ангажираност на служителите и удовлетвореност от работата.

Подробната рамкова диаграма е достъпна на уебсайта. Той показва всички ключови роли, Дейности, резултати и потоци. Той също така служи като навигационна помощ за останалата част от сайта.

Изображението по-долу обяснява как работи пъргавият процес. Епосите са обширно произведение, което допълнително се разделя на редица по-малки истории или суб-епоси. Тези под-епоси се разпределят на екипа като история. След това всеки екип работи по тези истории или софтуерни функции съответно.

Кога да се използва Scaled Agile Framework

• Когато даден екип се интересува от прилагане на гъвкав подход последователно в по-големи, многоекипни програми и портфейли.
• Когато множество отбори изпълняват свой собствен начин на Agile изпълнение, но редовно се сблъскват с препятствия, закъснения и неуспехи.
• Когато екипите искат да работят самостоятелно.
• Когато искате да мащабирате Agile в цялата организация, но не сте сигурни какви нови роли може да са необходими или какви съществуващи роли (т.е. управление) трябва да се променят и как.
• Когато сте се опитали да мащабирате Agile в цялата си организация, но се борите да се подредите, за да постигнете еднаква или последователна стратегия в бизнес отделите от портфолио до ниво на програми и екип.
• Когато организацията трябва да подобри времето за разработване на продукти и иска да знае как други компании са успели да мащабират Agile с SAFe.

Колко различни от другите Agile практики

Сега в този урок Scaled Agile Framework, нека видим как Scaled Agile framework се различава от другите гъвкави практики,

• Той е публично достъпен и безплатен за използване.
• Предлага се в изключително достъпна и използваема форма.
• Той е лек, практически доказани резултати и специфичен за нивото.
• Той постоянно / редовно модифицира / поддържа най-често използваните гъвкави практики.
• Предлага полезни разширения на обичайните гъвкави практики.
• Грундира гъвкавите практики в контекста на предприятието.
• Предлага пълна картина на разработването на софтуер.
• Видимостта или прозрачността са повече на всички нива.
• Продължава или редовна обратна връзка за качеството и подобрението.

Основи на Scaled Agile Framework

Scaled Agile Framework (SAFe): Той стои в основата на своя

1. Lean-Agile Principles
2. Основни ценности,
3. Lean-Agile Leadership
4. Lean-Agile Mind-set,
5. Практически общности (Група хора, които постоянно работят по SAFe практики)
6. Изпълнение 1-2-3

SAFe Lean-Agile Principles

Тези основни SAFe Agile принципи и ценности за SAFe трябва да бъдат разбрани, изложени и продължени, за да се получат желаните резултати.

• Вземете икономическа гледна точка
• Прилагайте системно мислене
• Да приемем променливост; запазване на опции
• Изграждайте постепенно с бързи, интегрирани учебни цикли
• Основни етапи на обективна оценка на работещите системи
• Визуализирайте и ограничете WIP, намалете размера на партидите и управлявайте дължините на опашките
• Приложете ритъм, синхронизирайте с междудоменно планиране
• Отключете вътрешната мотивация на работещите в областта на знанията
• Децентрализира вземането на решения

SAFe пъргави основни ценности

Методологията SAFe Agile се основава на тези четири стойности.

Подравняване:

• SAFe поддържа подравняване.
• Подравняването започва в,
  • Стратегически теми при натрупване на портфолио и
  • Преминава надолу към Визия и Пътна карта на програмните изоставания и след това
  • Преминава към изоставанията в екипа.

Вградено качество:

• Той гарантира, че всяка допълнителна доставка отразява стандартите за качество.
• Качеството не е "добавено по-късно" е вградено.
• Вграденото качество е предпоставка за Lean и е задължително

Прозрачност:

• Прозрачността е средство за доверие.
• SAFe помага на предприятието да постигне прозрачност на всички нива - изпълнителни директори, мениджъри на портфейли и други заинтересовани страни.
• Всеки може да види изоставането на портфолиото / Kanban, изоставането на програмите / Kanban и Backlog / Kanban.
• Всяко ниво има ясно разбиране за целите на PI.
• Програмите за влакове имат видимост в изоставанията на екипа, както и други изоставания в програмите
• Екипите и програмите имат видимост в бизнеса и архитектурата Epics. Те могат да видят какво може да се насочи по пътя им.

Изпълнение на програмата:

• SAFe поставя голям фокус върху работещите системи и резултатите от бизнеса.
• SAFe не е полезен, ако екипите не могат да изпълняват и непрекъснато да доставят стойност.

Lean Agile Leaders:

Lean-Agile Leaders са учещи през целия живот и учители. Той помага на екипите да изграждат по-добри системи чрез разбиране и излагане на Lean-Agile SAFe принципите.

Като възможност за екипите, основната отговорност е приемането, успехът и непрекъснатото подобряване на Lean-Agile разработките. За промяната и непрекъснатото усъвършенстване лидерите трябва да бъдат обучени.

Лидерите трябва да възприемат нов стил на ръководство. Този, който наистина овластява и ангажира индивиди и екипи, за да достигнат най-високия си потенциал.

Принципи на тези постно-пъргави лидери

• Водете промяната
• Познайте Пътя; Наблегнете на ученето през целия живот
• Развийте хората
• Вдъхновете и приведете в съответствие с мисията; Минимизиране на ограниченията
• Децентрализира вземането на решения
• Отключете вътрешната мотивация на работещите в знанието

Lean Agile Mind-Set:

Lean-Agile мисленето е представено в две неща:

1. SAFe House of Lean
2. Agile Manifesto

SAFe House of Lean :

SAFe произтича от принципите и практиките на Lean производство. Въз основа на тези фактори SAFe представя "SAFe House of Lean". Той е вдъхновен от "къщата" на слабата Toyota.

Целта на постно е непобедима: да се предостави максимална стойност на клиента в най-кратки срокове с възможно най-високо качество на клиента

По-долу фигурата обяснява целта, стълбовете и основата на „SAFe House of Lean“.

Agile Manifesto

Разкриваме по-добри начини за разработване на софтуер, като го правим и помагаме на другите да го правят. Чрез тази работа ние достигнахме до стойността:

Ето защо, докато има стойност в елементите вдясно, ние оценяваме повече елементите вляво.

Agile Manifesto

1. Най-големият приоритет е да се удовлетвори клиентът чрез непрекъсната и ранна доставка на ценен софтуер.
2. Приемете променящите се изисквания, дори в края на разработката. Agile SAFe методологията обработва промените в полза на клиента.
3. Предоставяйте работещ софтуер често, от няколко седмици до няколко месеца, с предпочитание към по-краткия срок.
4. Разработчиците и бизнесмените трябва да работят заедно всеки ден по време на проекта.
5. Изграждайте проекти около мотивирани индивиди. Осигурете им подкрепа и средата, от която се нуждаят, и им се доверете, за да свършат работата.
6. Най-ефективният метод за комуникация с екип за разработки е разговорът лице в лице.
7. Работещият софтуер е основната мярка за напредък.
8. Подвижните процеси насърчават устойчивото развитие. Спонсорите, разработчиците и потребителите трябва да могат да поддържат постоянно темпо за неопределено време.
9. Непрекъснатото внимание към техническото съвършенство и добрият дизайн повишава пъргавината.
10. Простотата - изкуството да максимизираш обема на неизвършената работа - е от съществено значение.
11. Най-добрите архитектури, изисквания и проекти възникват от самоорганизиращи се екипи.
12. На редовни интервали екипът обмисля как да стане по-ефективен, след това настройва и коригира поведението си съответно.

Различни нива в SAFE

Има два различни типа прилагане на SAFe:

1. Прилагане на SAFe 4.0
2. Внедряване на SAFe 3.0

• В изпълнението на SAFe 4.0 имаме 4 нива: портфолио, поток от стойности, програма и екип.
• В изпълнението на SAFe 3.0 имаме 3 нива: портфолио, програма и екип
• 3-Level SAFe е за по-малки внедрения със 100 или по-малко хора. Програми, които не изискват значително сътрудничество.
• 4-Level SAFe е за решения, които обикновено изискват много стотици специалисти, които да разработят внедряване и поддръжка на софтуер.

Екипно ниво

Роли / Екипи		Събития		Артефакти
* Agile Team		* Планиране на спринта		* Натрупване на отбор
* Собственик на продукта		* Подреждане на изоставане		* Нефункционални изисквания
* Scrum Master		* Ежедневно изправяне		* Цели на екипа PI
		* Екзекуция		* Итерации
		* Демонстрация на спринт		* Истории (работещ софтуер)
		* Sprint Retrospective		* Спринт цели
		* IP спринтове		* Вградено качество
				* Шипове
				* Екип Kanban

• Всички екипи на SAFe са част от един или друг Agile Release Train (ART).
• Екипите на SAFe са упълномощени, самоорганизиращи се, самоуправляващи се, междуфункционални екипи
• Всеки екип е еднакво отговорен за дефинирането, изграждането и тестването на историите от техния резерв в отбори в итерации с фиксирана дължина
• Екипите планират и изпълняват двуседмични итерации с определен период от време в съответствие с договорените цели за повторение.
• Екипите ще използват рутинната програма ScrumXP / Team Kanban, за да доставят висококачествени системи за изготвяне на демонстрация на системата на всеки две седмици.
• Всички различни екипи в ART (Agile Release Trains) ще създадат интегрирана и тествана система. Заинтересованите страни ще оценят и ще отговорят с бърза обратна връзка
• Те прилагат практики за вградено качество.
• Всеки екип на ScrumXP ще има 5-9 членове на екипа, което включва всички роли, необходими за изграждане на качествена допълнителна стойност във всяка итерация.
• Ролите на ScrumXP включват:
  • Екип (Dev + QA)
  • Scrum Master
  • Собственик на продукта. И т.н. ...
• SAFe разделя сроковете за разработка на набор от итерации в рамките на PI (Увеличение на програмата).
• Продължителността на PI е между 8 -12 седмици.
• Екипът ще използва истории, за да достави стойността. Собственикът на продукта ще има правомощия за съдържание върху тяхното създаване и приемане на историите.
• Историите съдържат изискванията на клиента.
• Team Backlog включва истории за потребители и активисти, които се идентифицират по време на планирането на PI. Когато Управлението на продуктите представя Пътна карта, визия и изоставане в програмата.
• Идентифицирането, разработването, приоритизирането, планирането, внедряването, тестването и приемането на историите са основните изисквания на управленската работа на ниво екип.
• Всяка итерация осигурява:
  • Ценен прираст на нова функционалност
  • Постигнете чрез постоянно повтарящ се модел
  • Планирайте итерацията
  • Ангажирайте се с някаква функционалност
  • Изпълнете итерацията чрез изграждане и тестване на истории
  • Демонстрирайте новата функционалност
  • Ретроспективна
  • Повторете за следващата итерация
• Екипите също поддържат демонстрацията на системата в края на всяка итерация. което е критичната точка за интеграция на ART.
• Потоците с по-голяма стойност ще имат множество ART.
• Итерациите за иновации и планиране (ИП) използват екипите с възможност за иновации и проучване.

Програмно ниво

Роли / Екипи		Събития		Артефакти
* DevOps		* Планиране на PI (нарастване на програмата)		* Визия
* Екип на системата		* Демонстрации на системата		* Пътна карта
* Управление на изданията		* Проверете и приемете семинар		* Метрика
* Управление на продукти		* Архитектурна писта		* Основни етапи
* UEX архитект		* Пуснете по всяко време		* Пускания
* Освободете инженера на влака (RTE)		* Agile Release Train		* Програма Epics
* Системен архитект / инженер		* Освобождаване		* Програма Kanban
* Собственици на бизнес				* Натрупване на програми
* Lean-Agile Leaders				* Нефункционални изисквания
* Практически общности				* Първо претеглена най-кратка работа (WSJF)
* Споделени услуги				* Цели на PI на програмата
* Клиент				* Особеност
				* Разрешител
				* Решение
				* Координация на стойностния поток

• На ниво програма Стойността на SAFe се доставя от дълготрайни Agile Release Trains (ART). Итерацията е за екип, а тренировката е за програмата.
• Agile Release Trains (ART) е основното средство за доставка на стойност на ниво програма. Той предоставя поток на стойност на организацията.
• Продължителността на програмните увеличения (PI) е от 8 до 12 седмици.
• ART е от 5 - 12 пъргави екипа (~ 50 - 125+ души), което включва всички роли и инфраструктура, необходими за предоставяне на напълно тестван, работещ софтуер на системно ниво.
• Всеки PI е времева кутия с множество итерации. По време на което се разработва и доставя значителен, ценен прираст на системата.
• Във всеки PI ще се случат сесии "демонстрация" и "Проверка и адаптиране" и планирането започва за следващия PSI.
• На ниво програма SAFe акцентира върху принципа на привеждане в съответствие. Това е така, защото са интегрирани множество опитни екипни усилия за създаване на стойност за клиента.
• SAFe йерархията на артефактите е Epics-> функции-> потребителски истории .
• На ниво програма, продуктов мениджър / програмен мениджър има правомощия за съдържание. Той определя и приоритизира изоставането в програмата.
• Натрупването на програми е приоритетен списък с функции.
• На програмно ниво функции могат да бъдат създадени или да произтичат от епоси, дефинирани на ниво портфолио.
• Функциите се разлагат на потребителски истории и се вливат в изоставания на ниво екип.
• Продуктовият мениджър или ролята на Release Train Engineer могат да бъдат изпълнявани от мениджъра на програмата / старши мениджър на проекти
• Ролята на системния архитект на ниво програма е да си сътрудничи ежедневната работа с екипите. Той гарантира, че са изпълнени нефункционалните изисквания. Също така те работят с корпоративния архитект на ниво портфолио, за да се уверят, че има достатъчно архитектурна писта, която да поддържа предстоящите потребителски и бизнес нужди.
• Дизайнът на интерфейса, насоките за потребителски опит и елементите на дизайна за екипите се предоставят от UX Designers.
• Ролята на Главен Scrum Master се играе от „Освободете инженера на влака“.
• Различен екип (от маркетинг, разработка, качество, операции и внедряване) формира „Екип за управление на освобождаването“. Те ще одобрят рутинни издания на качествени решения за клиентите.
• Внедряването на софтуер в клиентска среда и успешната доставка се грижи от екипа на DevOps.

Ниво на портфолио

Роли / Екипи		Събития		Артефакти
* Архитект на предприятието		* Стратегическо инвестиционно планиране		* Стратегически теми
* Портфолио на програмата Mgmt		* Kanban Portfolio (Epic) Planning		* Предприятие
* Epic Owners				* Натрупване на портфолио
				* Портфолио Kanban
				* Нефункционални изисквания
				* Epic и Enabler
				* Стойност поток
				* Бюджети (CapEx и OpEx)

• Най-високото ниво на интерес / загриженост / участие / към SAFe е портфолиото на SAFe
• Портфолиото предоставя основните блокове за организиране на Lean-Agile Enterprise потока от стойности чрез един или повече Стойностни потоци.
• Портфолиото помага да се разработят системи и решения, които са описани в стратегически теми (свързва SAFe портфолиото с променящата се бизнес стратегия на предприятието).
• За да се постигнат стратегически цели, портфолиото включва тези елементи. Той осигурява основно бюджетиране и други механизми за управление. По този начин той гарантира, че инвестицията в потоците на стойността осигурява възвръщаемостта, необходима на предприятието.
• Портфолиото е свързано с бизнеса двупосочно:
  • За да насочи портфолиото към по-големите променящи се бизнес цели, той предоставя стратегически теми.
  • Друга посока показва постоянния поток от стойности на портфейла.
• Управлението на програмния портфейл действа като заинтересовани страни и те са отговорни за постигане на бизнес резултатите.
• Нивото на портфолиото SAFe съдържа хора, процеси и необходими системи и решения за изграждане, от които едно предприятие се нуждае, за да изпълни стратегическите си цели.
• Стойностните потоци са основните цели в портфолиото, с което се финансират хората и други ресурси, необходими за изграждането на решенията.
• Важни ключови понятия, използвани тук, са:
  • Връзка с предприятието,
  • Управление на програмното портфолио,
  • Управление на потока от портфейлни епоси.

Ниво на стойност на потока

Роли / Екипи		Събития		Артефакти
* DevOps		* Планиране преди и след PI (нарастване на програмата)		* Визия
* Екип на системата		* Демонстрации на решение		* Пътна карта
* Управление на изданията		* Проверете и приемете семинар		* Метрика
* Управление на решения		* Agile Release Train		* Основни етапи
* UEX архитект				* Пускания
* Value Stream Engineer (RTE)				* Value Stream Epics
* Архитект / инженер на решения				* Value Stream Kanban
* Споделени услуги				* Value Backlog Backlog
* Клиент				* Нефункционални изисквания
* Доставчик				* Първо претеглена най-кратка работа (WSJF)
				* Цели на PI на Value Stream
				* Способност
				* Разрешител
				* Контекст на решението
				* Координация на стойностния поток
				* Икономическа рамка
				* Намерение на решението
				* MBSE
				* Въз основа на набор
				* Agile Architecture

• Нивото на стойността на потока не е задължително в SAFe.
• Value Stream Level е ново в SAFe 4.0.
• Нивото на стойностния поток е предназначено / предназначено за предприятия / строители / организации, които са:

1. Големи по размер
2. Независим
3. Имате сложни решения
4. Техните решения обикновено изискват множество ART
5. Те имат принос на доставчиците.
6. Те са изправени пред най-големите системни предизвикателства
7. За кибер-физически системи
8. За софтуер, хардуер, електричество и електроника, оптика, механика, флуидика и др.

• Изграждането на този вид системи често отнема стотици, дори хиляди специалисти, външни и вътрешни доставчици.
• Ако системите са от ключово значение за мисията. Неизправността на Решението или дори подсистемата има неприемливи икономически и социални последици.
• Ако Предприятията могат да бъдат изградени с няколкостотин практикуващи, може да не са му необходими конструкциите от това ниво. В този случай те могат да използват от „ сгънатия изглед“, който е SAFe на 3 нива.
• Изграждането на решения за поток на стойност в Lean-Agile модел изисква допълнителни артефакти, координация и конструкции. Така че това ниво съдържа икономическа рамка за осигуряване на финансови граници за Стойностния поток
• Той поддържа каданс и синхронизация за множество ART и доставчици. Той включва срещи за планиране преди и след PI и демо решение.
• Той дава допълнителни роли, които са: Value Stream Engineer, Solution Architect / Engineering и Solution Management.

Резюме:

• SAFe е доказан в индустрията, фокусиран върху стойността метод за мащабиране на Agile на ниво предприятие.
• Той отговаря на въпросите като „Как да планираме?“, „Как да финансираме?“ И „Как да станем многофункционални в архитектурата и DevOps?“
• Рамката SAFe Agile помага на големите организационни екипи да постигнат стратегическите цели на организацията, а не само индивидуалните цели на проекта.
• Рамката предлага способността да се поддържа и създава централизирана стратегия за постигане на стойност.
• Моделът SAFe има три / четири нива, които централизират стратегическите теми на организацията.
• Централизирана стратегия, съчетана с децентрализираното гъвкаво изпълнение на разработката.

Препратки:

SAFe за постно предприятие 5.0:

http://www.scaledagileframework.com

Тази статия е предоставена от Jyothi Rangaraj