Agile-технология разработки ИС

1.

Agile-технология
разработки ИС

2.

• Кон М. Agile: оценка и планирование
проектов / М. Кон — «Альпина
Диджитал», 2006. — Библиотека
Сбербанка т. 91

3.

Планирование
• Точность планирования +- 60%
• +75% -25%
• Конус неопределенности

4.

Agile-планирование
• Фокус на планировании, а не на плане
• Поощряются изменения
• Составление планов, легко поддающихся
изменениям
• Процесс планирования распределяется на весь
осуществления проекта

5.

Agile-подход
Работа единой командой
Короткие итерации
Поставка результата после каждой итерации
Фокус на бизнес-приоритетах
Проверка и модифицирование

6.

Agile-команда
Роли:
• Владелец продукта (общее виденье, приоритеты,
рентабельность, полезность)
• Клиент (финансирование)
• Пользователь
• Разработчик
• Руководитель проекта (лидерство, а не
менеджмент)

7.

Agile-работа
• Нет разбивки на этапы
• Короткий этап проектирования или
моделирования
• Итерация – все работы (анализ, дизайн,
программирование, тестирование,…)
выполняются параллельно
• Итерации ограничиваются по времени (2-4
недели) даже если приходится урезать
функциональность

8.

Уровни планирования
Стратегия
Портфель
Продукт
Релиз (объем, график (3-6 месяцев),
бюджет, качество)
Итерация
День (Ежедневные совещания)
владелец
Agile-команда

9.

10.

Оценка сроков выполнения
• Трудоемкость в «пунктах». Минимальная
«пользовательская история» – 1 пункт, средняя – 5
• «Идеальные дни» – нет отвлечений, ожиданий,
собраний
• Оценивается история, а не затраты участника

11.

Методы оценки сроков
выполнения
• Экспертная оценка (оценивается срок выполнения
пользовательской истории всеми разработчиками)
• Оценка по аналогии (относительно разных уже
реализованных историй с усреднением полученных
оценок)
• Декомпозиция на части с оценкой трудоемкости по
частям
Покер планирования
• Каждый эксперт получает карточки со сроками 0, 1,
2, 3, 5, 8, 13, 20, 40, 100
• Оценивание и синхронное предъявление
• Объяснение отклонений
• Повторение оценки

12.

Планирование релиза
• Релиз – Темы (Эпопеи) – пользовательские
истории
• Ограничения по времени – проектирование по
функциям, которые можно успеть разработать в
релизе. Владелец проекта выполняет
приоритезацию по функциям
• Ограничения по функциям – определяется время,
за которое можно создать релиз. Владелец
определяет приоретезацию по времени.
• План релиза пересматривается после каждой
итерации

13.

Планирование релиза

14.

Планирование итерации на
основе скорости
Определение целей итерации
Выбор историй в соответствии с целями
Декомпозиция на задачи
Определение времени с учетом
– Совещаний,
– Документирования,
– Тестирования,
– Устранения ошибок
• Спайк – задача поиска ответа на вопрос (влияние
нового кода)
• Оценка трудоемкости в идеальном времени

15.

Планирование итерации на
основе скорости

16.

Планирование итерации на
основе обстоятельств
• Истории добавляются до заполнения итерации
• Коллективная оценка трудоемкости

17.

Планирование итерации на
основе обстоятельств

18.

Оценка скорости работы
над проектом
• Использовать аналогии (технология, область
автоматизации, команда, среда,…)
• По начальным итерациям (учет снижения
неопределенности с каждой новой итерацией)
• Прогноз
– Оценка доступных часов разработчиков (55%-70%)
– Определение суммарных затрат в часах
– Случайный выбор историй для разбивки на задачи и
оценки
– Вывод интервальной оценки

19.

Оценка скорости работы по
итерациям
Динамика неопределенности на основании конуса
неопределенности
№ Нижний
множитель
Верхний
множитель
1
0,6
1,6
2
0,8
1,25
3
0,85
1,15
… 0,9
1,1

20.

Буферизация планов –
резервирование времени
Временной буфер (оценка неопределенности)
Функциональный буфер (выбор обязательных функций и оценка
трудоемкости, выбор 25%-40% дополнительных функций,
включаемых в буфер)
DSDM - Dynamic Systems Development (Выделение функций - Метод
MoSCoW по приоритетам (обязательные не более 70%, остальные буфер):
MUST - требование ДОЛЖНО удовлетворять экономическим нуждам.
SHOULD - СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех
проекта.
COULD - НУЖНО ли оставить это требование, если оно не действует на деловую
потребность проекта.
WON'T - МОЖНО ли отложить выполнение требования, если ещё есть время.

21.

Контроль процесса
разработки
• Прогресс
• Изменение объема работ
• Незавершенка
– Трудно измерить
– Потеря доверия
– Увеличение затрат

22.

Доска задач

23.

Правила применения - 1
1) В осуществлении проекта должна участвовать вся
команда.
2) Планируйте на разных уровнях.
3) Разделяйте оценки размера и сроков, используя
разные единицы (размер в пунктах, сроки в
идеальных днях).
4) Выражайте неопределенность при представлении
либо функциональности, либо даты.
5) Часто пересматривайте планы.
6) Отслеживайте прогресс и информируйте о нем.
7) Признавайте важность обучения.

24.

Правила применения - 2
8) Планируйте функции подходящего размера.
9) Приоритизируйте функции.
10) Стройте оценки и планы на фактах.
11) Оставляйте небольшой резерв.
12) Координируйте работу команд с помощью
опережающего планирования.

25.

https://ru.yougile.com/
• AGILE-ДОСКИ
• ИЕРАРХИЯ: КОМПАНИЯ, ПРОЕКТ, ДОСКА,
КОЛОНКА, ЗАДАЧА
• НАЗНАЧЕНИЕ ИСПОЛНИТЕЛЕЙ
• ГРУППОВЫЕ ЧАТЫ
• МОИ ЗАДАЧИ
• ПРАВА ПОЛЬЗОВАТЕЛЕЙ
• ОТЧЕТЫ, СВОДКИ

26.

Заполнение профиля

27.

Создание компании

28.

Структура компании

29.

Проекты

30.

Доска проекта

31.

Задачи

32.

Календарь проекта

33.

Диаграмма Ганта проекта

34.

Отчеты

35.

Ссылки для входа в
организацию
https://systemdesign.yougile.com