Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».
Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.
Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.
Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:
Задача Джоэля Спольски
Зачем нужны аналитики?
Кто такой хороший аналитик?
Как бороться с извечными проблемами?
Как быть с Agile?
2. Кто я?
•
•
•
•
•
•
•
Байкин Александр
Разработчик и сисадмин
Аналитик
Менеджер проектов
CIO
Идеолог uml2.ru
Тренер, консультант
Докладчик на многих
конференциях
bas@uml2.ru
http://baikin.moikrug.ru
11. Что мы увидели со спекой?
•
•
•
•
•
•
Сроки разработки уменьшились
Получили более качественный продукт
Не нужно по 100 раз спрашивать
Можно нормально протестировать
Можно составить адекватный план
Сэкономили нервы себе и заказчику
12. Почему тогда нужны Аналитики?
•
•
•
•
•
•
Разработчики: f(технологии) >>> f(бизнес)
Разработчики не любят писать текст
Разработчики плохо общаются с Бизнесом
Бизнес не может писать спецификации
Сложность бизнеса и технологий растет
Нужен subject matter expert
14. Почему люди не верят?
• Не знают, что нужен
• Попробовали, не понравился
– Аналитик плохо работал
– Процесс неправильно поставлен
• В Агиле нет Аналитика
15. Треугольник управления требованиями: люди, процессы,
инструменты. ЛАФ 2103
Хороший Аналитик
Профессионал
Разработка Тр
Пр. Обл. и
Технологии
Коммуникации
УТ
Управление
людьми
16. Кого я часто вижу?
•
•
•
•
•
•
Обычный писарь
Не понимает процесс
Нет концептуального взгляда
Верит в магию инструментов
Нет опыта полного цикла разработки
Не хочет работать
17. Аналитика превыше всего
•
•
•
•
•
•
Понимание – зачем все это нужно?
Структурирование информации
Выявление взаимосвязей и противоречий
Получение требований в итоге
Отсутствие вопросов и предположений
Сделать понятным всем
19. Немного советов
•
•
•
•
•
•
•
•
Мы одно и тоже по нескольку раз переделываем!
Мы делаем не то, что нужно Заказчику!
Мы разговариваем с Заказчиком на разных языках!
Да блин, этот Заказчик сам не знает, что хочет!
У нас постоянно расширяется скоуп проекта!
Уже никто не знает, как работает наша Система!
В одном месте правим, в другом ломается!
Но мы же договаривались о другом!!!
20. Много раз переделываем
•
•
•
•
•
•
Понимать реальные проблемы
Выделать больше времени на анализ
Понимать лучше предметную область
Делать ретроспективу с Заказчиком
Наладить процесс управления изменениями
Много работать ≠ хорошо работать
21. Говорим на разных языках
•
•
•
•
•
Больше общаться с Заказчиком
Изучать предметную область, БП и ПО
Определить Глоссарий
«Посвятить» Заказчика в Технари
Привлечь других экспертов в Пр. Обл.
22. Заказчик не знает, что хочет
•
•
•
•
•
Понимать реальные проблемы
Изучать больше предметную область
Предлагать решения, прототипы
Изучать аналоги, смотреть вместе
Привлекать больше ЗЛ
23. Расширяется скоуп проекта
•
•
•
•
•
•
Правильно определяйте цели разработки
Хорошие требования и планирование
Baseline требований и приоритет
Управление изменениями требований
Больше объем – на много больше изменений
Изменения будут – это естественно
24. Управление изменениями тр.
• Неуправляемые изменения требований – ПРОБЛЕМЫ
– переработки ↑, качество
↓, план †, риски ↑, нужность ↓
• Определите процесс управления изменениями
– Разделяйте типы запросов: bugs (где?), ERequests
– Запрос соответствует рамкам?
– Кто проверяет и подтверждает/отменяет запрос? Приоритет?
– Кто оценивает влияние изменений?
– Комитет по управлению изменениями (CCB)
• Все запросы должны следовать принятому процессу
• Изменения могут повлечь увеличение бюджета и
сроков
• Изменения будут – это естественно
• Инструменты: СУТ, Bug tracking system или Excel
25. Не знаем, как работает Система
•
•
•
•
•
Договориться о норме документирования
Выделить время на min описание
Что-то изменяем → документируем
Минимальная трассировка
Удерживать ключевых сотрудников
26. Мы же договаривались о другом
•
•
•
•
•
•
Аналитик формирует ожидания
Не давать нереальных обещаний
Больше информации и обратной связи
Раньше на много лучше, чем позже
Сэндвич: «+», «–», «+»
Баланс между «получить» и «дать»
27. А у нас Agile
•
•
•
•
•
•
•
•
•
Активное вовлечение ЗЛ
Приоритезация Требований
Не забывайте про Концепцию и Цели
Договориться о min документирования
Требования итерационно, чуть раньше
Ближе к разработке → более детализировано
Больше моделей
Proxy product owner
Wiki
28. В итоге получаем
•
•
•
•
•
•
↓ ошибок и издержек при выпуске ПО
↓ времени разработки ПО и переделок
↑ удовлетворенности и вовлеченности ЗЛ
↑ качества ПО
↑ точности планирования
↑ точности стратегического развития