Latest revision as of 17:12, 9 October 2020

Цель

• Понять важность эмпирицизма в Agile и роль ПО в поддержке эмпирицизма

Тезисы

Простые системы и сложные системы

Вводная: Когда и почему возникли разговоры об Agile в IT и с чем это связано? Ведь десятилетиями классический подход успешно работал!

Первая публикация о скрам - 1986-й год (см. https://agileforgrowth.com/scrum-history/). 1993 - презентация Джеффа Сазерленда, 2001 - манифест Agile.

• 80-е годы
• Появление ПК
• Широкое распространение компьютеров
• Применение их к решению ежедневных бытовых и бизнес задач.
• До этого решались инженерные и научные задачи. Но эти задачи - простые - мост всегда мост, и луна всегда летает по законам физики миллионы лет. Задачи из человеческой деятельности оказались сложнее.

А что такое сложность?

Теория сложных системы выросла из теории систем управления (Деминг и др) и окончательно оформилась к 70-м годам.

Определение: Сложная система - это система поведение которой нельзя понять изучив её отдельные части. Отличительный признак - наличие поведения, которое возникает только у системы в целом, когда части собраны в одно целое. Такое поведение называется эмержетным.

См. диаграмма стейси о сложности структуры/поведения

Предиктивный метод и простые системы

Предиктивный (классический) метод управления проектами базируется на следующих действиях и предпосылках:

• Мы описываем требования к системы разбивая её на маленькие части (декомпозиция) и предполагаем что совокупность требования к отдельным частям позволит получить нам требуюемую систему.
• Мы описываем весь перечень работ для создания системы (опять декомпозиция, но уже работ) и предполагаем что совокупность выполненных работ позволить получить требуюемую систему.

Это все работает если системы по определению выше - простая. Это то условие когда предиктивный метод работает. Потому что создание отдельных элементов и проверка их поведения не описывает, не гарантирует эмержетного поведения.

Agile как ответ на сложные системы

Agile - ответ на приход сложных системы как класса задач. Принципы agile "working software over comprehensive documentation" и "working software is primary measure of the progress" отражает именно неспособность любых требований, как модели основанной на декомпозиции - отражать систему целиком.

Полное смещение парадигмы от аналика к владельцу продукта (ПО, PO, product owner). От мы знаем что хочет заказчик к мы предполагаем что вот эти наши действия приведут к получению заказчиком вот такой ценности.

Эмпирицизм как движущая сила Agile

Эмпирицизм - подход когда мы доверяем только знаниям полученным из опыта. Это ответ на вопрос - "если мы не можем точно предсказать - то как собирать требования? как планировать проект?".

Основными инструментами эмпирицизм являются гипотеза и эксперимент по проверке гипотезы.

Отличия гипотезы от утверждения:

• Утверждение всегда 100%, гипотеза имеет определенную степень достоверности (вероятность с которой мы обоснованно ожидаем что гипотеза подтвердиться).
• Поскольку гипотеза нуждается в проверке - мы становимся вынуждены определить критерии по которым мы можем проверить или опровергнуть верность гипотезы практически.
• Поскольку гипотеза имеет степень достоверности то мы вынуждены сделать три важных вещи

• Иметь план что делать на случай если гипотеза окажется ложной
• Отражать степень достоверности в наших утверждения и оценках
• Стремиться к снижению стоимости эксперимента (чтобы не тратить слишком много на гипотезу которая может оказаться недостоверной).

По сути все действия в Agile являются гипотезой и проведенным для её подтверждения экспериментом.

Цикл Демминга как основа эмпирического подхода

Классический метод проведения эксперимена называется цикл Демминга (PDSA/PDCA)

4 этапа

P - plan. Нужно продумать как имменно мы подтвердим или опровергнем гипотезу и какие действия нам надо для этого совершить.

D - do. Нужно совершить запланированные действия и провести запланированные измерения.

S - study (S - это оригинальная версия, в Kaizen часть используют C - check) - Нужно изучить измерения и принимаем решение о достоверности или опровержении гипотезы.

A - act. Если эксперимент подтвердил что мы имеем делао с простой системой - мы передаем дальше в предиктивный процесс. Иначе мы формулируем новую (более точную/детальную или альтернативую) гипотезу и повторяем цикл уже для неё. Без этого пункта три предыдущих теряют смысл. Три предыдущих - это всего лишь получение опыта, а именно Act - это и есть эмпирицизм - действие на основе практического опыта.

Цикл Демминга как адаптация приемов декомпозиции для сложных системы

Цикл Демминга - это декомпозиция примененная для упрощения сложной системы. Для простой системы мы разбиваем наше знание системы на части-требования и изучаем часть в рамках декомпозиции. Для сложной системы - мы разбиваем наше незнание на гипотезы, и подтверждая или опровергая гипотезу за гипотезой упрощаем наше восприятие сложной системы.

ПО и эмпирицизм

ПО обеспечивает эмпирическую природу с точки зрения продукта. В этом его ключево отличие от business analyst. ПО может делегировать (но может делать и сам) работу по сбору информации и формулированию гипотез, но именно ПО отвечает за то, что:

• Backlog как средство управления продукт организован и воспринимается всеми, в том числе команду и стейкхолдеров как набор гипотез.
• Что работа команды в backlog выражается в проведении экспериментов (а не решении задач, выполнении требований...)
• Что результаты экспериментов должны образом применяются для пересмотра существующих гипотез и формирования новых

Вопросы для самоконтроля

1) Почему предиктивный процесс не может быть эффективно применен к созданию сложной системы или для разработки при помощи инструмента, который является сложной системой?

2) Что является ключевым отличием гипотезы от утверждения?

3) Как элементы цикла PDSA проверяют гипотезу и как они поддерживают эмпирицизм?

4) За что отвечает Product Owner?

Замечание к лектору

p.s. Возможно надо разбить на две лекции. Много информации, почти 2 часа занимает.