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

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

Их все равно не читают
Задача Джоэля Спольски
450
400
350
300
250
200
150
100
50
0

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

Анализ

Дизайн

Раз...
Программист 1. Разработка
Программист 1
Программист 1. Переделать
Программист 1
Программист 2. Анализ
Программист 1

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

Программист 2
Что мы увидели со спекой?
•
•
•
•
•
•

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

Разработчики: f(технологии) >>> f(бизнес)
Разработчики не любят писать текст
Ра...
Кит в шляпе и с сигаретой
Почему люди не верят?
• Не знают, что нужен
• Попробовали, не понравился
– Аналитик плохо работал
– Процесс неправильно по...
Треугольник управления требованиями:
люди, процессы, инструменты. ЛАФ 2103

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

Профессионал
Разработка Тр
П...
Кого я часто вижу?
•
•
•
•
•
•

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

Понимание – зачем все это нужно?
Структурирование информации
Выявление взаимосвязей и...
Хорошие требования
Полные и точные

Приоритет

Реализуемые

Непротиворечивые

Важные

Проверяемые
Немного советов
•
•
•
•
•
•
•
•

Мы одно и тоже по нескольку раз переделываем!
Мы делаем не то, что нужно Заказчику!
Мы ра...
Много раз переделываем
•
•
•
•
•
•

Понимать реальные проблемы
Выделять больше времени на анализ
Лучше понимать предметную...
Говорим на разных языках
•
•
•
•
•

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

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

Правильно определяйте цели разработки
Хорошие требования и планирование
Baseline тр...
Не знаем, как работает Система
•
•
•
•
•

Договориться о норме документирования
Что-то изменяем → документируем
Восстанавл...
Мы же договаривались о другом
•
•
•
•
•
•

Аналитик формирует ожидания
Не давать нереальных обещаний
Больше информации и о...
В итоге получаем
•
•
•
•
•
•

↓ ошибок и издержек при выпуске ПО
↓ времени разработки ПО и переделок
↑ удовлетворенности и...
Задавайте вопросы
Книги:

Сайты:
uml2.ru

FB - Анализ в ИТ
webursitet.ru
Upcoming SlideShare
Loading in …5
×

Александр Байкин (UML2.ru)

445 views

Published on

Whale Rider 2013

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
445
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Александр Байкин (UML2.ru)

  1. 1. Аналитики не нужны Требования Александр Байкин
  2. 2. Кто я? • • • • • • • Разработчик и сисадмин Аналитик Менеджер проектов CIO Идеолог uml2.ru Тренер, консультант Докладчик на многих конференциях bas@uml2.ru http://baikin.moikrug.ru Байкин Александр
  3. 3. Зачем эти требования? Их все равно не читают
  4. 4. Задача Джоэля Спольски 450 400 350 300 250 200 150 100 50 0 Стоимость измененений Простота изменений Анализ Дизайн Разработка Внедрение
  5. 5. Программист 1. Разработка Программист 1
  6. 6. Программист 1. Переделать Программист 1
  7. 7. Программист 2. Анализ Программист 1 Программист 2
  8. 8. Программист 2. Разработка Программист 1 Программист 2
  9. 9. Что мы увидели со спекой? • • • • • • Сроки разработки уменьшились Получили более качественный продукт Не нужно по 100 раз спрашивать Можно нормально протестировать Можно составить адекватный план Сэкономили нервы себе и заказчику
  10. 10. Почему тогда нужны Аналитики? • • • • • • Разработчики: f(технологии) >>> f(бизнес) Разработчики не любят писать текст Разработчики плохо общаются с Бизнесом Бизнес не может писать спецификации Сложность бизнеса и технологий растет Нужен subject matter expert
  11. 11. Кит в шляпе и с сигаретой
  12. 12. Почему люди не верят? • Не знают, что нужен • Попробовали, не понравился – Аналитик плохо работал – Процесс неправильно поставлен • В Агиле нет Аналитика
  13. 13. Треугольник управления требованиями: люди, процессы, инструменты. ЛАФ 2103 Хороший Аналитик Профессионал Разработка Тр Пр. Обл. и Технологии Коммуникации УТ Управление людьми
  14. 14. Кого я часто вижу? • • • • • • Обычный писарь Не понимает процесс Нет концептуального взгляда Верит в магию инструментов Нет опыта полного цикла разработки Не хочет работать
  15. 15. Аналитика превыше всего • • • • • • Понимание – зачем все это нужно? Структурирование информации Выявление взаимосвязей и противоречий Получение требований в итоге Отсутствие вопросов и предположений Сделать понятным всем
  16. 16. Хорошие требования Полные и точные Приоритет Реализуемые Непротиворечивые Важные Проверяемые
  17. 17. Немного советов • • • • • • • • Мы одно и тоже по нескольку раз переделываем! Мы делаем не то, что нужно Заказчику! Мы разговариваем с Заказчиком на разных языках! Да блин, этот Заказчик сам не знает, что хочет! У нас постоянно расширяется скоуп проекта! Уже никто не знает, как работает наша Система! В одном месте правим, в другом ломается! Но мы же договаривались о другом!!!
  18. 18. Много раз переделываем • • • • • • Понимать реальные проблемы Выделять больше времени на анализ Лучше понимать предметную область Делать ретроспективу с Заказчиком Наладить процесс управления изменениями Много работать ≠ хорошо работать
  19. 19. Говорим на разных языках • • • • • Больше общаться с Заказчиком Изучать предметную область, БП и ПО Определить Глоссарий «Посвятить» Заказчика в Технари Привлечь других экспертов в Пр. Обл.
  20. 20. Заказчик не знает, что хочет • • • • • Понимать реальные проблемы Больше изучать предметную область Предлагать решения, прототипы Изучать аналоги, смотреть вместе Привлекать больше ЗЛ
  21. 21. Расширяется скоуп проекта • • • • • • Правильно определяйте цели разработки Хорошие требования и планирование Baseline требований и приоритет Управление изменениями требований Больше объем – намного больше изменений Изменения будут – это естественно
  22. 22. Не знаем, как работает Система • • • • • Договориться о норме документирования Что-то изменяем → документируем Восстанавливаем по частям Минимальная трассировка Удерживать ключевых сотрудников
  23. 23. Мы же договаривались о другом • • • • • • Аналитик формирует ожидания Не давать нереальных обещаний Больше информации и обратной связи Раньше намного лучше, чем позже Сэндвич: «+», «–», «+» Баланс между «получить» и «дать»
  24. 24. В итоге получаем • • • • • • ↓ ошибок и издержек при выпуске ПО ↓ времени разработки ПО и переделок ↑ удовлетворенности и вовлеченности ЗЛ ↑ качества ПО ↑ точности планирования ↑ точности стратегического развития
  25. 25. Задавайте вопросы Книги: Сайты: uml2.ru FB - Анализ в ИТ webursitet.ru

×