Agile -
able to move quickly and easily
признан был решать две проблемы
- Time to market
- Time to decision
Agile Manifesto
4 ценности
- ЛЮДИ и их взаимодействие важнее (над) процессов и инструментов
- работающий ПРОДУКТ важнее исчерпывающей документации
- взаимодействие с ЗАКАЗЧИКом важнее согласований условий контракта.
- реакция на ИЗМЕНЕНИЕ важнее чем следование плану
12 принципов
- Наивысшим приоритетом для нас является Удовлетворение Потребностей Заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение Требований Приветствуется даже на поздних стадиях разработки.
- Работающий продукт следует Выпускать как можно Чаще с периодичностью от пары недель до пары месяцев
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать Мотивированные Профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное Общение является наиболее практичным и эффективным способом обмена информации как с самой командой, так и внутри команды.
Если вы людям даете формулу собственного счастья, зависимую на деньги, люди будут эксплуатировать эту формулу.
Если вы даете людям возможность на работе реализовать свой потенциал и не думать о каких-то деньгах, то тогда реализуют свой потенциал. Мы берем людей, мотивированных, заряженных, и наша задача с вами — это сделать так, чтобы их мотивация не растерялась. Мы обеспечиваем им условия работы, мы обеспечиваем поддержку с точки зрения руководства, с точки зрения заказчика, мы выпрямляем все коммуникации и полностью доверяем им то, как стоит делать продукт. И они будут делать продукт, лучший продукт.
Помните, что самая быстрая коммуникация у нас — она все-таки вербальная, с глазу на глаз. А еще лучше, если два человека, или три человека, или команда, которая общается вербально, они имели у себя фломастеры и какую-то доску, на которой могли бы визуализировать свои идеи.
- Работающий Продукт — основной Показатель Прогресса. Т.е. мы меряем все работающим продуктом
- Разработчики, инвесторы и пользователи должны иметь возможность Поддерживать Постоянный Ритм бесконечно - sustainable pace.
- Постоянное внимание к Техническому Совершенству и качеству проектирования повышает гибкость проекта. Команда, которая готовит новый продукт, которая делает новый продукт, она должна постоянно развиваться
- Простота, искусство минимизации лишней работы — она крайне необходима - KISS: Keep It Simple Stupid («Делай это просто, глупышка»)
Ее смысл в том, что чем проще сделан ваш продукт, тем проще его поддерживать и изменять. Нам не надо делать универсалию, в универсалии она слишком сложна. Универсалия тяжело проектируется, универсалия тяжело делается, а потом вся наша универсальность разбивается очень легко любым требованием от клиента, которое не входит в изначальную идею, которая входила в продукт.
- Самые лучшие требования, архитектурные и технические решения рождаются у Самоорганизующихся Команд.
Мы собираем людей, даем им возможность самим определить, каким образом они будут достигать целей, каким образом они будут делать тот или иной продукт.
- Команда должна систематически анализировать возможные способы Улучшения Эффективности и, соответственно, корректировать стиль своей работы.
Если у нас есть время, чтобы оглянуться назад, посмотреть, как мы работали и придумать что-то, что может улучшить нашу работу в будущем, давайте это будем использовать
Если мы в своих коммуникациях, в своем процессе работы входим в какой-то ритм, то, работая в этом ритме и поддерживая его, мы можем постоянно создавать новый продукт, искать на рынке тот самый продукт.
3 больших круга Agile-подходов
- Процессы
- Продукты
- Инструменты (IT)
Scrum - фреймворк, предполагающий разделение процесса разработки продукта на отдельные шаги - спринты, в течение которых пользователю представляется продукт с новыми возможностями - инкрементами. Scrum-доска состоит из трёх колонок: «сделать» (to-do), «в процессе» (in progress), «сделано» (done). карточки бизнес-задач располагаются на доске сверху вниз в порядке убывания приоритета
Kanban - система организации производства, снабжения, разработки по принципу «точно в срок». способствующий равномерному распределению нагрузки между работниками. При данном подходе весь процесс разработки прозрачен для всех членов команды. Задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу. На производстве способствует снижению запасов товаров и деталей, которые могут скрывать дефекты.
Scrumban
DSDM
Lean startup
Lean customer development
Design thinking
XDD
DDD
Automated testing
Пограничные вещи (фасилитационные техники)
Story mapping - разбивать большие требования к продукту на инкрементальные (пошаговые, приращение) поставки
Impact mapping - сверять конкретные действия с тем, что они ведут к глобальной цели нашего продукта
Компании мы можем условно поделить на две части:
- Run
Мы эксплуатируем те процессы, модели и продукты, которые у нас уже есть. У нас есть продуктовая линейка, мы примерно понимаем как ее развивать, мы ее развиваем, мы продаем эти продукты, оказываем услуги, зарабатываем деньги. Здесь высокая определенность, понятно что делать, можно легко планировать вперед на месяцы, а иногда и на годы
- Сhange
Мы придумываем новые процессы и новые продукты, захватывая новые рынки. Там высокая неопределенность, непонятно что делать, есть только предположения и гипотеза.
Для этой части был придуман Agile
Что нам для этого надо?
- Культура интрапренерства
это выращивание в компании людей с высокой ответственностью. Иногда такие люди отвечают полностью за свой продукт и их иногда даже называют мини CEO, то есть мини генеральный директор, который полностью отвечает за развитие определенного продукта или продуктового направления практически как генеральный директор.
- Полная клиенто и продукто-центричность,
Мы смотрим не на то, как наших стейтхолдеров удовлетворить и как можно больше дивидендов им принести, а именно смотрим на то, что сейчас называют Customer Delight, удовлетворенность клиента нашим продуктом.
- Что касается людей
Мы делаем на них ставку, мы пытаемся раскрыть их потенциал и вовлечь их в производственный процесс.
Теория запутанности (Модель Кеневин)
поможет понять те области, в которых стоит применять Agile
придумал Дэйв Сноуден - генеральный директор и основатель компании Cognitive Edge
Смысл ее заключается в следующем: он рассматривает все как какую-то систему, то есть производство какого-то продукта, процесс — это все система
Система состоит
- из агентов взаимодействия .
- и причинно-следственных связей, по которым они взаимодействуют
в зависимости от того, что мы об этом знаем, они попадают к одному из пяти доменов
- «Беспорядок» - мы точно не знаем, сколько у нас есть агентов взаимодействия и какие причинно-следственные связи.
С беспорядком ничего нельзя сделать, кроме как навести в нем порядок, поэтому как только мы начинаем расследования с этим проектом, мы попадаем в какой-то из четырех других доменов.
Домен №1 называется «Простой» — в нем хранятся простые системы - Простые системы —
Домен №2. Сложные - PM BOOK
алгоритм действий простых систем, он такой: мы ощущаем внешнее воздействие, категоризуем его, ищем в голове у нас какую-то папочку, в которой лежит рецепт того, как надо на это воздействие реагировать, и реагируем.
Используем Лучшие практики. (Чек-листы, жесткие регламенты)
Ощути - анализируй - реагируй
Хорошие практики (наборы хороших практик). Управление проектами (гибридные жизненные циклы)
Домен №3 Запутанные (комплексные) системы
огромное количество агентов взаимодействия, но такие же простые и понятные причинно-следственные связи.
это системы, в которых ограниченное количество агентов взаимодействия, но небольшое, и простые понятные причинно-следственные связи - приготовить яишницу
Агентов взаимодействия опять же большое, но причинно-следственные связи уже непонятные. То есть их много, мы знаем, что они есть, но какие, непонятно. Система легких ограничений и агентов
Во-первых, запуск нового продукта или создание нового продукта, стартап - покер.
Мы делаем гипотезу, мы пытаемся ее реализовать, соответственно, ощущаем, что же было, получилось или нет? В зависимости от того, что получилось, мы, соответственно, выбираем определенный отклик. И, таким образом, мы действуем в цикле, пока мы не наткнемся на нужный нам продукт или на то, что удовлетворяет нашего клиента. Проводим безопасные эксперименты, не делаем проектирования отказоустойчивых систем. Если эксперимент удается, мы расширяем его, если не - сворачиваем. Не прибегаем к тестированию, пока не определимся со стратегией расширения и сворачивания
Практик здесь нет никаких, они здесь возникают, то есть мы их здесь порождаем. Новые знания, новейшие (уникальные) практики. Частая проверка гипотез (адаптивные жизненные циклы)
Домен №4. Хаотические системы
Огромное количество агентов взаимодействия, но непонятно, сколько и какие есть причинно-следственные связи. - новый генеральный директор пришел
Алгоритм такой: я действую, анализирую и реагирую (Делай хоть что-то). И это в цикле. Новые практики. Взаимосвязи. Представьте: я выходил на комитет, один раз, два раза я не понимал, что от меня хочет новый руководитель. Но после этого у меня появилась идея: ага, он хочет вот эту вещь. И я из хаотического домена перехожу уже в запутанный. У меня есть гипотеза о том, что с этим руководителем надо действовать определенным образом. И я начинаю с ним пытаться действовать методом проб и ошибок. И в какой-то момент я нахожу к нему ключ, и мы начинаем работать вместе. И, следовательно, сразу же я из запутанных систем перехожу в сложные. У нас, действительно, сложные отношения, но я точно знаю, как понять, что этому руководителю нужны вот такие-то вещи, у нас есть определенная синергия. И, возможно, в будущем эти наши коммуникации совсем выпрямятся. И система взаимодействия меня и моего руководителя станет простой.
Простые системы легко становятся сложными, как только расширяется домен наших знаний. Они становятся простыми, когда количество взаимодействий, количество причинно-следственных связей, количество агентов взаимодействия уменьшается. Сложные системы становятся запутанными, когда мы выходим на новые рынки или пытаемся сделать какой-то инновационный продукт. Запутанные системы становятся сложными, как только мы поняли, как это делается. Запутанные системы становятся хаотичными, когда у нас даже пропадают возможности придумать гипотезу, и хаотические системы становятся запутанными, когда мы эту гипотезу нашли. Из хаотической системы мы не можем попасть в простую систему, потому что здесь путешествие должно быть полностью через весь цикл, прямого взаимодействия здесь нет. Но в обратную сторону из простых систем в хаотические мы можем попасть очень легко. Это когда мы неправильно распознали нашу систему, либо когда происходит что-то серьезное, кризис.
Область применения
При высокой неопределенности, то есть когда мы не можем знать или спроектировать конечный результат, конечный бизнес-процесс или продукт. То есть это область change в нашем бизнесе.
Когда нужно разработать инновационный продукт, когда надо построить или усовершенствовать процесс, в котором есть высокая доля неопределенности, когда мы работаем с заказчиком или с размытыми потребностями.
Инструмент - матрица Стейси
X - По горизонтали эта ось так называемых требований, когда мы понимаем, что мы должны сделать. Ближе к нулю, это чёткая зона, где у нас известно, что нам надо делать. Ближе к правой части нашей оси X - то, где мы не понимаем, что нам надо сделать.
Y - По вертикали, это известность того, как это делается. Соответственно, ближе к нулю, это когда у нас известно как решение делается. Ну и соответственно, по оси Y в бесконечность уходит неизвестность/
- когда мы знаем точно, что делать и точно знаем как делать, Agile применять не надо. Здесь работают более дешевые, более простые подходы. Это то, что в модели Киневин мы называли простыми системами,
- если мы знаем, что надо делать, но не знаем как это делать. Это сложная система. Аналогично, сложная система, если мы знаем как это делать, но не знаем, что делать. Тут тоже Agile возможно не стоит применять.
- если мы точно не знаем что делать и точно не знаем как это делать, то тут Agile подходы нам очень сильно подходят.
Возьмите эту матрицу, попробуйте разместить на ней весь портфель ваших проектов или продуктов, которые надо разработать и посмотрите с какими инструментами вам лучше сейчас пообщаться - Где использовать классические подходы или подходы, которые мы привыкли называть водопадными или каскадными (как поток, последовательно проходящий фазы 1.анализа требований, 2.проектирования, 3.реализации, 4.тестирования, 5.интеграции и 6.поддержки), а где стоит обратить внимание на Agile.
.
Почему нельзя везде применить Agile?
Не так просто встраивается в кампанию. Они сталкиваются с моделями, которые мы используем при построении нашей компании
Просто взять и использовать гибкие методологии в компании достаточно сложно. Они сталкиваются с моделями, которые мы используем при построении нашей компании.
- Например, с моделями бюджетирования. Agile подход подразумевает то, что у нас бюджетирование будет тоже гибкое. Почему? Да потому, что мы работаем с какими-то инновациями, мы смотрим гипотезы, если у нас фиксированная стоимость на проект, мы можем просто не уложиться в эти деньги. Здесь работает совсем другая модель бюджетирования.
- Отношение к неудачам. Если мы с первого раза делаем неудачные гипотезы и за это нас депремирует наше руководство или ставят нам на вид, то мы потом перестанем просто напросто эти гипотезы выдвигать.
- организационная структура. Для того, чтобы работать в сфере в Agile, для того, чтобы работать с так называемыми кросс-функциональными, самоорганизующимися командами нам нужна определенная организационная структура, которая позволит нам эти команды собирать и позволит нам делать так, чтобы эти команды могли существовать в вашей организации, существовать достаточно длительное количество времени.
Fail Fast
- если мы говорим, что процесс создания инноваций - это работа с гипотезами, это значит, что мы говорим о стоимости этой гипотезы. Если мы работаем с чередой гипотез, их может быть достаточно много и нам необходимо сделать проверку гипотез дешевой, чтобы просто не разориться.
- Второй поинт, это скорость. Если мы работаем с чередой гипотез и их может быть достаточно много, то нам необходимо сделать проверку гипотез быстрой, чтобы мы могли отбросить неудачные гипотезы как можно быстрее и успеть попасть в окно рыночных возможностей.
- толерантность руководства. Каждая гипотеза - это инвестиция в общее дело, если руководство не толерантно к неудачам, то люди будут бояться экспериментов и работа с гипотезами просто не получится.
Cтарайтесь делать гипотезы быстрыми, старайтесь делать гипотезы частыми и дешевыми и, соответственно, разговаривайте с руководством, добивайтесь того, чтобы оно было к ним толерантным. И вот эти три поинта ложатся в идеологию, которая называется FAIL FAST, FAIL EARLY, FAIL OFTEN
Фреймворк "Кеневин" - среда обитания, место хранения вашей собственности
1000чи модуляторов повлияли на ваше развитие, но вы не полностью осознавали их влияние
- Это смыслообразующая, а не Категоризационная модель (классическая матрица 2 на 2, из консалтинга, где структура идет впереди данных. Надо поместить данные в нужные ячейки и принять решение. Но мы не увидим мелких различий, пока не будет слишком поздно. Категоризация хороша для эксплуатации, но не годится на стадии разработки или внедрения изменений)
- В смыслообразующем фреймворке Данные предваряют сам фреймворк. Структура вытекает из самих данных, получаемых в процессе. Но одна модель может перетекать в другую
Построение фреймворка
за основу берем 3 типа систем:
- Упорядоченные
- Комплексные
- Хаотические
через категорию Беспорядок разделяем Упорядоченные системы на простые и сложные
Простые
Сложные
Если заходим обдуманно, то возникают инновации / Если случайно - нужно срочно стабилизироваться
Любая практика будет полностью новой
Помогает понять, в какой области мы находимся, следует ли проводить замеры или привлечь эксперта
Зона самоуверенности между простой и хаотичной системами, обрыв с риском свалиться в хаос = максимально долго оставаться в комплексной и сложной областях, и переводить только небольшое количество материалов в простую область, опасную для ускорения изменений
Это аналитическая система принятия решений - нахождение пути подбора систем