O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Аналитики не нужны требования (поставь запятую, где нужно)

827 visualizações

Publicada em

Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».

Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.

Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.

Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:
Задача Джоэля Спольски
Зачем нужны аналитики?
Кто такой хороший аналитик?
Как бороться с извечными проблемами?
Как быть с Agile?

Publicada em: Arte e fotografia
  • Seja o primeiro a comentar

Аналитики не нужны требования (поставь запятую, где нужно)

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

×