Аналитики не нужны ТребованияАлександр Байкин

Кто я?• Разработчик и сисадмин• Аналитик• Менеджер проектов• CIO• Идеолог uml2.ru• Тренер, консультант• Докладчик на многих конференциях

bas@uml2.ruhttp://baikin.moikrug.ru

Байкин Александр

Зачем эти требования?

Это занимает много времени

Нам и так понятно, что нужно

В итоге все равно переделывать

В Агиле не нужны спецификацииИх все равно не читают

Задача Джоэля Спольски

Анализ Дизайн Разработка Внедрение0

50100150200250300350400450

Стоимость изменененийПростота изменений

Программист 1. Разработка

Программист 1

Программист 1. Переделать

Программист 1

Программист 2. Анализ

Программист 1

Программист 2

Программист 2. Разработка

Программист 1

Программист 2

Что мы увидели со спекой?• Сроки разработки уменьшились• Получили более качественный продукт• Не нужно по 100 раз спрашивать• Можно нормально протестировать• Можно составить адекватный план• Сэкономили нервы себе и заказчику

Почему тогда нужны Аналитики?• Разработчики: f(технологии) >>> f(бизнес)• Разработчики не любят писать текст• Разработчики плохо общаются с Бизнесом• Бизнес не может писать спецификации• Сложность бизнеса и технологий растет• Нужен subject matter expert

Кит в шляпе и с сигаретой

Почему люди не верят?• Не знают, что нужен• Попробовали, не понравился– Аналитик плохо работал– Процесс неправильно поставлен

• В Агиле нет Аналитика

Хороший Аналитик

Профессионал

Разработка Тр

Пр. Обл. и Технологии

Коммуни-кации

УТ

Управление людьми

Треу

голь

ник

упра

влен

ия т

ребо

вани

ями:

лю

ди, п

роце

ссы

, ин

стру

мен

ты. Л

АФ 2

103

Кого я часто вижу?• Обычный писарь• Не понимает процесс• Нет концептуального взгляда• Верит в магию инструментов• Нет опыта полного цикла разработки• Не хочет работать

Аналитика превыше всего• Понимание – зачем все это нужно?• Структурирование информации• Выявление взаимосвязей и противоречий• Получение требований в итоге• Отсутствие вопросов и предположений• Сделать понятным всем

Хорошие требования

Полные и точные Приоритет

Важные

Реализуемые Непротиворечивые

Проверяемые

Немного советов• Мы одно и тоже по нескольку раз переделываем!• Мы делаем не то, что нужно Заказчику!• Мы разговариваем с Заказчиком на разных языках!• Да блин, этот Заказчик сам не знает, что хочет!• У нас постоянно расширяется скоуп проекта!• Уже никто не знает, как работает наша Система!• В одном месте правим, в другом ломается!• Но мы же договаривались о другом!!!

Много раз переделываем• Понимать реальные проблемы• Выделять больше времени на анализ• Лучше понимать предметную область• Делать ретроспективу с Заказчиком• Наладить процесс управления изменениями• Много работать ≠ хорошо работать

Говорим на разных языках• Больше общаться с Заказчиком• Изучать предметную область, БП и ПО• Определить Глоссарий• «Посвятить» Заказчика в Технари• Привлечь других экспертов в Пр. Обл.

Заказчик не знает, что хочет• Понимать реальные проблемы• Больше изучать предметную область• Предлагать решения, прототипы• Изучать аналоги, смотреть вместе• Привлекать больше ЗЛ

Расширяется скоуп проекта• Правильно определяйте цели разработки• Хорошие требования и планирование• Baseline требований и приоритет• Управление изменениями требований• Больше объем – намного больше изменений• Изменения будут – это естественно

Не знаем, как работает Система• Договориться о норме документирования• Что-то изменяем → документируем• Восстанавливаем по частям• Минимальная трассировка• Удерживать ключевых сотрудников

Мы же договаривались о другом• Аналитик формирует ожидания• Не давать нереальных обещаний• Больше информации и обратной связи• Раньше намного лучше, чем позже• Сэндвич: «+», «–», «+»• Баланс между «получить» и «дать»

В итоге получаем• ↓ ошибок и издержек при выпуске ПО• ↓ времени разработки ПО и переделок• ↑ удовлетворенности и вовлеченности ЗЛ• ↑ качества ПО• ↑ точности планирования• ↑ точности стратегического развития

Задавайте вопросыКниги: Сайты:

uml2.ru

FB - Анализ в ИТ

webursitet.ru