Whale Rider 2013

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

2. Кто я?
•
•
•
•
•
•
•
Разработчик и сисадмин
Аналитик
Менеджер проектов
CIO
Идеолог uml2.ru
Тренер, консультант
Докладчик на многих конференциях
bas@uml2.ru
http://baikin.moikrug.ru
Байкин Александр

3. Зачем эти требования?
Их все равно не читают

4. Задача Джоэля Спольски
450
400
350
300
250
200
150
100
50
0
Стоимость измененений
Простота изменений
Анализ
Дизайн
Разработка Внедрение

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

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

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

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

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

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

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

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

13. Треугольник управления требованиями:
люди, процессы, инструменты. ЛАФ 2103
Хороший Аналитик
Профессионал
Разработка Тр
Пр. Обл. и
Технологии
Коммуникации
УТ
Управление
людьми

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

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

16. Хорошие требования
Полные и точные
Приоритет
Реализуемые
Непротиворечивые
Важные
Проверяемые

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

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

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

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

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

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

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

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

25. Задавайте вопросы
Книги:
Сайты:
uml2.ru
FB - Анализ в ИТ
webursitet.ru