Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Как из хаоса рождается порядок

233 views

Published on

Доклад Екатерины Евстифеевой на конференции Analyst Days-6
www.analystdays.com

Published in: Education
  • Be the first to comment

  • Be the first to like this

Как из хаоса рождается порядок

  1. 1. Как из хаоса рождается порядок Евстифеева Екатерина e.evstifeeva@superjob.ru Skype: evstifeevaK
  2. 2. Краткие данные о компании Продуктовая разработка в области ИБ Водопадная модель разработки Департамент разработки ≈ 80 чел Команда аналитиков 8 человек
  3. 3. Глобальная проблема На тот момент компания уже несколько лет не могла выпустить стабильный продукт и существовало множество проблем внутри самой команды разработки.
  4. 4. • Непредсказуемость сроков разработки и окончания релиза. • Внесение изменений приводило к значительным трудозатратам и делало продукт нестабильным. • В процессе тестирования всплывал незапланированных функционал. • Изменения вносятся спонтанно, и без согласования. • Никто не знает, как должна работать система в целом или даже отдельные ее функции. • Чтобы сделать новую фичу, которая действительно нужна конечному пользователю, приходится все переделывать по несколько раз. • Было много дефектов и споров о том, что “Это функция, а не дефект!” ▪Разработчики и тестировщики тратили много своего рабочего времени, чтобы выяснить, что же в итоге нужно сделать. ▪Команда не знала, где найти актуальные требования к продукту. Отсутствие единого понимания работы системы Несогласованность работы Непродуктивная работа и трата времени сотрудников
  5. 5. Требования представляли из себя набор отдельных неформализованных документов в формате doc Хранились разрозненно без системы версионирования Документы не актуализировались Требования на проекте:
  6. 6. Часть документов были очень громоздкими и сложными и команда отказывалась работать с ними Изменения в требованиях вносились в процессе работы, сразу после устной договоренности или уже на этапе тестирования Отсутствовали требования к основному функционалу продукта Требования на проекте:
  7. 7. Что делать? Как новому аналитику решить такие проблемы? Сможет ли он вытащить всю команду из хаоса и неопределенности?
  8. 8. Шкала уровней зрелости процесса управления требованиями
  9. 9. Уровень 0. Отсутствие требований. Полный хаос Когда я пришла в компанию, мы находились между 0 и 1 уровнем зрелости, так как часть функционала все же была описана в том или ином виде. Перед нами возник вопрос: "Как из практически полного хаоса дойти до верхней ступени зрелости в управлении требованиями и решить все проблемы?" С чего нам начать?
  10. 10. На данном этапе зрелости требования должны выявляться и документироваться. На этом этапе форма описания требований не имеет особого значения, но факт наличия требований создает основу для дальнейшей работы. Уровень 1. Организация требований Требования организованы
  11. 11. Задачи и цели Задача №1. Восстановить требования к основным фичам в продукте. Цель: обеспечить единое понимание работы и границ системы. Сократить количество создаваемых дефектов и споров в команде. 11
  12. 12. Шаги для достижения 1 уровня Шаг 1. Выбор версии для восстановления требований Проблемой, с которой мы столкнулись при восстановлении требований, был вопрос: “К какой версии продукта нужны требования?” А что, если у вас одновременно эксплуатируются несколько версий продукта разными заказчиками?”
  13. 13. Шаги для достижения 1 уровня Шаг 2. Оцениваем объем работ Задачи на восстановление требований Выявили список функций в системе, работа которых не документирована. Объем работ Задачи на преобразование требований в новый формат Отметили документы, качество и структура которых нас не удовлетворяла. Задачи на актуализацию требований Устаревшие документы, которые необходимо актуализировать. Задачи на дополнение требований Выявили документы, по которым возникает много вопросов и есть много связанных дефектов.
  14. 14. Шаги для достижения 1 уровня Шаг 3. Приоритизация фич Оценка команды, какие функции кажутся им наиболее проблематичными Оценка функции с точки зрения критичности для заказчика Количество созданных дефектов из-за отсутствия требований Приоритет, «вес» фичи
  15. 15. Шаги для достижения 1 уровня Шаг 4. Планирование работ Спланировать работы по восстановлению требований на конец проекта Выделить фиксированное время. Например, каждую неделю выделять по 3-4 часа Давать задачи на восстановление требований всем новым аналитикам в отделе
  16. 16. Шаги для достижения 1 уровня Шаг 5. Организация ревью требований Ответственный аналитик Команда аналитиков Проектная команда Аналитик готовит требования Внутренние кросс-ревью внутри отдела Внешние ревью проектной командой (разработчики, тестирование) Документ согласован!! Для достоверности данных мы организовали проверку восстановленных требований
  17. 17. Что случилось после… 17
  18. 18. Оставшиеся проблемы Несогласованность работы • Сроки проекта по прежнему были нестабильными, часто сдвигались. • Некоторые функции все еще приходилось переделывать. • Внесение изменений одобряли в спешке и сразу вносили в требования. Плохое качество требований • Требования интерпретировались часто по-разному. • В требованиях не хватало информации для разработчиков. • Участники проекта использовали разную терминологию. Отсутствие версионирования требований • Невозможно было различить различные версии спецификаций. • Требования часто не читались, так как не все знали, где их найти и актуальны ли они. • Никто не знал точно, когда добавилась новая функция и в каком документе ее искать.
  19. 19. Данный уровень модели зрелости для управления требованиями уже говорит о качестве требований – их формате, сохранности и версионности. Качественные требования понятны как заказчику, который их формирует, так и всем членам проектной команды, которые разрабатывают ПО, удовлетворяющее потребностям заказчика. Для этого требования должны быть не только читаемыми, но и однозначными и непротиворечивыми. Уровень 2. Организация требований Требования организованы
  20. 20. Задачи и цели Задача: обеспечить быстрый и удобный доступ к нужной версии требований. Цель: сделать требования единым источником информации для всей команды. 20
  21. 21. Шаги для достижения 2 уровня Шаг 1. Определить критерии выбора системы хранения Разграничение прав доступа к требованиям Версионирование документов Удобное и быстрое форматирование Быстрый доступ к актуальной версии требований для всех участников проекта вне зависимости от ОС Система хранения требований
  22. 22. Шаги для достижения 2 уровня Шаг 2. Разработка единого шаблона документа Добавили в документ обязательные атрибуты (название документа, автор, статус документа, задача на разработку и версия) Добавили правила при написании требований и выбрали структуру документа Была добавлена история изменений, где фиксировалось, кто, когда, какое изменение внес и на основании какой задачи
  23. 23. Шаги для достижения 2 уровня Шаг 3. Создание регламента работы Мы провели презентацию и обучение работы с новой системой управления требованиями для всех отделов технического департамента Создали регламент работы отдела аналитики
  24. 24. Наши достижения после… Можно было быстро найти необходимою версию требований к определенной функции продукта Требования стали источником информации для команды Уменьшилось количество дефектов, связанных с отсутствием требований или путаницей в них
  25. 25. Оставшиеся проблемы Путаница в уровне требований • Заинтересованные лица обсуждали требования, не называя их тип, часто возникала путаница в разных понятиях. • Части пользовательского интерфейса рассматривались как требования, без указания их типа и предназначения Не согласованные изменения • Изменения в требования все еще вносились спонтанно и на ходу. • В процессе тестирования выявлялся новый функционал. • Информация об изменениях не доносилась всем заинтересованным лицам. • Изменения оказывались более сложными, чем ожидалось. После внесения изменений появлялось множество связанных с ними дефектов. • Аналитики часто не могли принять обоснованное решение о компромиссах, когда появлялись новые требования.
  26. 26. Уровень 3. Структурирование требований Третий уровень модели зрелости для управления требованиями концентрируется на атомарности и типах требований: бизнес- требования или системные, функциональные или нефункциональные и т.д.
  27. 27. Задачи и цели Задачи: 1. Разделить требования на уровни, обеспечить единую терминологию и формат требований. 2. Сделать процесс внесения изменений согласованным и контролируемым. Цели: 1. Сократить количество путаницы и споров в команде. 2. Избежать срывов сроков выпуска релиза. 27
  28. 28. Шаги для достижения 3 уровня Шаг 1. Выделить основные типы требований Высокоуровневые бизнес-требования (Документ концепции и границ) Нефункциональные требования (атрибуты качества, ограничения, макеты и требования к интерфейсу) Функциональные требования (описание работы функций) Требования к системе
  29. 29. Шаги для достижения 3 уровня Шаг 2. Обеспечить единый формат требований Высокоуровневые бизнес- требования (Документ концепции и границ) Функциональные требования (описание работы функций) Нефункциональные требования Модель решения по фиче Cценарии использования + диаграммы действий, состояний и т.д. Требования к интерфейсу заменили на макеты = = =
  30. 30. Шаги для достижения 3 уровня Шаг 3. Исключить дублирование и неточность информации Выделить отдельные документы с общими требованиями к системе (локализация данных, меню, требования к быстродействию и т.д.) Исключить описание одной и той же функциональнос ти в разных документах Исключить формулировки «сделать так же, как…» (в старой системе, в другой системе, у конкурентов и т.д.) Создать общий словарь данных (Глоссарий)
  31. 31. Шаги для достижения 3 уровня Шаг 4. Организация процесса изменения требований Проблему желательно решить Аналитик Проектная команда Менеджер проекта Аналитик Список изменений Оценка трудозатрат Принятие решения о включении в релиз Изменение требований
  32. 32. Шаги для достижения 3 уровня Шаг 4. Организация процесса изменения требований Уведомление команды Сравнение версий в истории Блок «История изменений» с ссылкой на причину (задачу или дефект) Изменение требований
  33. 33. Наши достижения Достигнув 3 этапа уровня зрелости, мы наконец смогли стабилизировать работу и планирование релизов. Большинство вопросов и споров в команде решалось.
  34. 34. Оставшиеся проблемы • Вносимые изменения оказывались более сложными, чем ожидалось, и затрагивали сразу несколько модулей в системе. • Даже согласованные изменения иногда приводили к срыву сроков. • Изменения приводили к ухудшению качества системы. • Внесенные изменения противоречили другим требованиям.
  35. 35. Уровень 4. Трассировка требований Достижения предыдущих трех уровней зрелости приведут проектную команду к тому, что можно будет определять отношения между требованиями. Установка отношений (трассировка) позволяет отслеживать влияние требований друг на друга (анализ влияния) и определять избыточные и неучтенные требования (анализ покрытия).
  36. 36. Задачи и цели Задача: создать матрицу трассировки между функциональными требованиями к системе. Цель: избежать возникновения критических дефектов после внесения изменений. 36
  37. 37. Шаги для достижения 3 уровня Шаг 1. Трассировка требований Определить влияние изменений одного требования на другие. Создать матрицу связей требований между собой и со связанными документами Добавить в процесс внесения изменений анализ взаимосвязей по матрице трассировки требований
  38. 38. Пример матрицы трассировки требований Изменения в → Могут повлиять на: ↓ Авторизация в системе Атрибуты карточки заказа Создание годового отчета Интеграция с системой отправок Удаление заказов с истекшим сроком хранения Авторизация в системе Да - - - - Атрибуты карточки заказа - Да - - - Создание годового отчета - Да Да - - Интеграция с системой отправок - Да - - Удаление заказов с истекшим сроком хранения - - - - Да
  39. 39. Какие проблемы не позволяет решить 4 уровень 1. При реализации была упущена часть функционала и это обнаружилось только на этапе тестирования. 2. Есть дефекты, связанные с непониманием или отсутствием каких-то деталей в требованиях. 3. При тестировании были упущены некоторые моменты или часть функционала протестирована не в полном объеме. 4. В тест - кейсах есть неточности и ошибки. 5. В пользовательской документации есть неточности и неописанная часть функций.
  40. 40. Уровень 5. Интеграция требований Как мы уже говорили, требования служат неким соглашением между тем, что заказчик хочет, и тем, что должно делать ПО. Но до этого момента мы не могли четко проследить связь от потребностей заказчика до кода в ПО. На пятом уровне мы должны согласовать процесс управления требованиями с процессами управления изменениями, проектирования, разработки, тестирования и управления проектом.
  41. 41. Для перехода с 4 ступени на 5 аналитику необходимо обеспечить: Связь и контроль полного покрытия требований Требования Тест - кейсы Задачи на разработку ПО Документация
  42. 42. Что дальше… Четвертый уровень говорит о высокой степени организованности и формализации процессов. На данном этапе удается решить практически все проблемы, избежать срывов сроков проекта даже при меняющихся условиях и требованиях и сделать процесс полностью предсказуемым. Наша компания приняла решение пока остаться на 4 уровне, так как достижение 5 было очень дорогим и сложным процессом.
  43. 43. Подведение итогов Внедрение процессов по разработке и управлению требованиями позволило нам стабилизировать работу и выпускать релизы в срок. Весь процесс «путем проб и ошибок» занял около 2 лет работы.
  44. 44. Обратная сторона медали 44 Несмотря на столь внушительные результаты, достигнутые нашей командой, всегда стоит помнить о том, что принятие решения о достижении того или иного уровня зрелости процесса управления требованиями должно осуществляться взвешенно и на основании четкого понимания целей и задач, стоящих перед компанией.
  45. 45. Спасибо за внимание Евстифеева Екатерина e.evstifeeva@superjob.ru Skype: evstifeevaK

×