Как мы разбирали слона. Целые, сломанные и лишние детали
•Als PPTX, PDF herunterladen•
0 gefällt mir•421 views
Доклад Алексея Козлова на Analyst Days-7. 13-14 октября 2017. Минск www.analystdays.com
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (12)
Mehr von SQALab
Mehr von SQALab (20)
Как мы разбирали слона. Целые, сломанные и лишние детали
- 1. Война с зайцелопами От фантазий к требованиям Алексей Козлов стр. 54
- 2. Как всё начиналось Команда аналитиков 3 >10 С опытом работы в компании 2 5 С опытом в предметной области 1 2 Согласование ТЗ Обследование и написание ЧТЗ Передача в ПЭ и сопровождение/доработка Резкое увеличение команды За несколько лет до начала проекта 2
- 4. Айда все всё сделаем! • Для ускорения процесса выделена продуктовая и проектная команда. • Написание ЧТЗ происходит параллельно с реализацией. В ЧТЗ – подробная спецификация. • Реализация идёт параллельно с обследованием. И почти независимо. • Фронт работы непредсказуемо увеличивался во время работы. 4
- 5. Что в ЧТЗ? ЧТЗ Неопределённость и противоречия Счастье завтрашних нас Системность и возможность реализации Сроки Проще сейчас дать что просят 5
- 6. Столкновение интересов • Внедрение показало, что «надо не так». • Начала поступать обратная связь о том, что надо поменять, и… • Запросы на изменение «ломали» смежный функционал • А ещё запросы на изменение невыполнимы, непроверяемы, противоречивы, нецелесообразны или избыточны . . . • Проблема: ни один человек не может описать то, как должна работать система, от и до. 6
- 8. Что на самом деле хочет Заказчик? • Должны торчать твёрдые штуки из головы • По бокам что-то должно висеть • Нужно чтобы было четыре лапы • Должен быть хвост • Должен питаться растениями • Не должен бояться воды 8
- 9. Как сделать то, что Заказчик хочет? • Должны торчать твёрдые штуки из головы • По бокам что-то должно висеть • Нужно чтобы было четыре лапы • Должен быть хвост • Должен питаться растениями • Не должен бояться воды 9
- 10. Выбор инструмента ЖЦ История изменения Трассировка Сложность внедрения Совместная работа Связь с задачами JIRA Цена Confluence Devprom Google Docs JIRA Enterprice Architect, Reqisite pro, Sybase Power- Designer 10
- 11. Версия 2 Решение по реализации Версия 1 Решение по реализации Объекты рабочего процесса в JIRA Требование заказчика Требование заказчика Внешнее ограничение Требование законодательства Требование заказчика Решение по реализации Задача Задача Задача Задача Задача Задача Задача Задача Задача Итерация 1 Итерация 2 Итерация 3 Итерация 4 11
- 12. Планирование и управление процессом До После Источник приоритетов и сроков реализации Внутреннее убеждение Реальная необходимость и ожидания Заказчика Критерии оценки корректности задач Самостоятельный анализ решений Соответствие задач связанным требованиям Критерии оценки необходимости реализации и приоритетов задач Глубокое погружение в предметную область Обоснованность задач требованиями Уровень верификации Технический дизайн целиком 1) Набор требований 2) Декларация соответствия набора требований техническому дизайну 3) Технический дизайн в части спорных моментов 12
- 14. Переход к процессу сопровождения Версия 8 Группа доработок Требование заказчика v15 Группа доработок Задача (ЗНИ) Задача Задача Задача Задача Итерация 56 Итерация 57 Итерация 58 Требование заказчика v16 Требование заказчика 14
- 15. Как избежать проблем внедрения? Донести до заказчика цели внедрения и преимущества. Согласовать, что будет являться артефактом рабочего взаимодействия и проговорить требования к нему. Договориться, что обязательно должна фиксироваться цель. Или вообще фиксировать цели отдельно. Если заказчик не понимает формальный язык требований – дополнять примерами, писать User Story. Проводить проверку полноты покрытия требованиями. 15
- 16. Результаты Решенные проблемы общие Отсутствие единой терминологии, неоднозначность понимания требований Несоответствие артефактов проекта компетенциям участников проектной команды и производства Заказчика и проектной команды Фактпередачи требований в реализацию не зафиксирован Статус выполнения требований к ПОне зафиксирован производства Не понятно, зачем нужны некоторые задачи Неттребуемых сроков реализации функционала Забываются существующие требования, рождаются противоречия Производственный план не основан на приоритетах Не фиксируется источник конкретного требования Тяжело и долго вникать в то, что просятсогласовать Слишком много ненужной конкретики, чтобы заложить универсальность Неудовлетворительное качество анализа решений 16
Hinweis der Redaktion
- Комплексная непрофильная деятельность госзаказчика. Требования. Проблемы.
- Что такое госзаказ, чем отличается ТЗ и как понять, что было надо. Как нам достался контракт. Команда аналитиков, рост команды. Объём работы. Планы на продукт. Сроки. Всё может поменяться.
- Заказчик. ИТ-подразделение. Что в ЧТЗ? Судьба первых документов, замечания. Куча совещаний и обсуждений.
- Успевать надо, на передовой места ограничены. Разделили последовательные этапы в параллель. Кто что делал. Ответственность, коммуникации.
- Заинтересованный стороны. Интересы сторон. Чем руководствовался БА? Документы, опыт и здравый смысл -> конкретика в ЧТЗ. Как это воспринимал Заказчик? В какую ситуацию был поставлен Заказчик? Бизнес-анализ балансирует между заказчиком и производством. Между настоящим и будущим. Выбор и его причины. Как это отразилось на ЧТЗ.
- Началось внедрение, всё не нравится. Проблемы каждой из сторон. Запросы на изменения, примеры. Что с ними не так? Не оправдались ожидания, что можно описать нечто от и до. Конфликты. Невозможно работать.
- Поняли – процессы и артефакты надо менять. Упростить сбор требований. Упростить согласование. Сделать возможным функциональное проектирование. EARS. ISO-29148. Требование. Примеры. Набор требований вместо ЧТЗ. Куда же делось ЧТЗ? Преимущества подхода.
- Раньше – надо вот так. Приходит, приносит. Сто раз переделываем. Внедряем – не то. Теперь – набор требований верхнего уровня. Преимущества. Прозрачность.
- У ответственного за реализацию на входе – какие-то данные. На выходе – технический дизайн. Чем это было раньше. Много интерфейсов. Мало фиксации. Отвечать ХЗ кому. Теперь на входе цели и ограничения. Больше простора для творчества, больше ответственности. Есть на что ссылаться. Там, где не хватает требований – глубже и вдумчивее анализ. Требования НПА.
- Пару слов об инструментах. 1) Совместная работа 2) Простота внедрения 3) Почему JIRA а не Confluence
- Проблемы управления: содержание и сроки. Почему не скрам?
- Когда стоит применять? Заказчик не знает, чего хочет. Заказчик знает что хочет. И их много. Заказчик един, знает что хочет, но хочет не то.
- Для нас – прорыв, но есть проблемы.
- На практике такой подход, пусть и не сразу, но заработал, решив ряд проблем. Выделение большего количества простых и уместных для обсуждения на каждом уровне артефактов устранило проблему соответствия артефактов проекта компетенциям участников. Упрощение требований и повышение уровня абстракции позволило Заказчику быстрее и проще вникать в то, что просят согласовать, тем самым придав согласованию смысл. Оно позволило повысить глубину анализа, дало цели, которые необходимо достигнуть при проработке решений, устранило избыточную ненужную конкретику во входных данных, и дало простор для построения более универсального ПО. Заведение каждого требования отдельно с указанием автора и способа поступления (конкретного совещания, в ходе которого было озвучено, сообщения электронной почты) повысило прозрачность в работе, позволило ссылаться на них при дальнейшем обсуждении, урегулировать конфликты интересов внутри Заказчика и уменьшить количество случаев изменения постановки. Указание в требованиях сроков, когда они должны соблюдаться в продуктивной среде, и приоритетов, привело производственный план в соответствие реальным потребностям бизенса. Статусная модель самих требований позволила фиксировать факт их передачи в производство, а вместе с ведением связи требований и задач на реализацию упростила отслеживание хода приведения ПО в соответствие этим требованиям, с одной стороны, и проверку необходимости реализации описываемого в задачах функционала – с другой. Процесс в целом стал более осмысленным и прозрачным, общая команда обрела единый вектор и стала работать эффективнее.