ДЕНЬ 12
Методики разработки приложений
СЕГОДНЯ
День посвятим разбору подходов к разработке дата-продукта, рассмотрим чем отличаются каскадный от гибкого процесса. Проработаем примеры для иллюстрации концепций. Обсудим наш вариант гибкой методологии проектирования дашбордов. Пятницу завершим легким тестом на усвоение концепций и уйдем на выходные листать новое издание на нашей библиотечной полке.
День посвятим разбору подходов к разработке дата-продукта, рассмотрим чем отличаются каскадный от гибкого процесса. Проработаем примеры для иллюстрации концепций. Обсудим наш вариант гибкой методологии проектирования дашбордов. Пятницу завершим легким тестом на усвоение концепций и уйдем на выходные листать новое издание на нашей библиотечной полке.
Разбираемся
В двух противоположных подходах разработки
Разработку отчетности часто приравнивают к полноценной разработке самостоятельного ИТ-продукта, только инструментом его реализации выступают не языки программирования, а Qlik Sense.
Два подхода к разработке продукта
Каскадный versus Гибкий
Наибольшее распространение в сфере ИТ получило два подхода для разработки продуктов: каскадный и гибкий.
Каскадная модель
Каскадная разработка состоит из четкой последовательности действий по этапам:
1. Определение требований
2. Проектирование
3. Конструирование (реализация, кодирование)
4. Тестирование и отладка (верификация)
5. Внедрение и поддержка
1. Определение требований
2. Проектирование
3. Конструирование (реализация, кодирование)
4. Тестирование и отладка (верификация)
5. Внедрение и поддержка
Плюсы этой методологии заключаются в том, что мы всегда понимаем конечную цель и когда мы к ней придем. Но как только речь заходит о технически сложном продукте, особенно если у него велика вероятность изменения конечных требований, такой подход может не подойти.
Когда использовать каскадную методологию?
Плюсы:
Минусы:
- когда требования известны и непротиворечивы
- когда требования зафиксированы
- когда продукт относительно небольшой
- когда есть нужные ресурсы с необходимой квалификацие
Плюсы:
- хорошая документация
- спланированность действий, понятная последовательность этапов
Минусы:
- отсутствие возможности вернуться на предыдущий этап таким образом высокая цена ошибки
- очень поздно начинается этап тестирования
Пример по каскадной модели
При постройке жилого дома, мы изначально понимаем, что строим монолитно-кирпичный дом, в 24 этажа, на заводненной почве, в определенных климатических условиях. Условия постройки дома стабильны по большей части, при проведении качественных подготовительных и геодезических работ. Тип почвы не изменится, климат останется прежним, согласованную этажность даже при желании не изменить, следуя заложенному фундаменту и используемым технологиям. Мы понимаем по средней стоимости кв.м. в этом районе и себестоимости проекта, сколько денег нам принесет постройка дома, и эти цифры не будут сильно колебаться от изначально заложенного бюджета.
“
Планирование – это все. Планы – ничто.
Гибкий подход
В противоположность каскадной модели, ставят гибкий подход. Agile ставит во главу угла не когда мы получим результат, а какой результат мы получим.
Этот подход хорош тем, что мы можем быстро управлять изменениями за счет коротких итераций планирования и оперативного релиза базовой версии продукта, и далее – за счет регулярных установок обновлений (версий или сервис-релизов продукта). Заказчик может наблюдать результат и понимать, удовлетворяет он его или нет после каждой итерации.
Этот подход хорош тем, что мы можем быстро управлять изменениями за счет коротких итераций планирования и оперативного релиза базовой версии продукта, и далее – за счет регулярных установок обновлений (версий или сервис-релизов продукта). Заказчик может наблюдать результат и понимать, удовлетворяет он его или нет после каждой итерации.
В Agile работа ведется на основе спринтов – недельные (1 неделя, 2 недели, 1 месяц) отрезки, по которым ведется планирование. Команды собираются также ежедневно на короткую встречу, чтобы обновить статус своих задач. При этом, от заказчика требуется постоянное участие в процессе разработки, поскольку у него есть возможность внесения оперативных изменений.
На ежедневных встречах участники команды обсуждают:
Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка.
На ежедневных встречах участники команды обсуждают:
- отчёт о проделанной работе с момента последней встречи
- список задач, которые сотрудник должен выполнить до следующего собрания
- затруднения и блоки, возникшие в ходе работы
Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка.
Практический пример
Есть идея оптимизация работы отдела продаж путем создания отчетности «АРМ отдела продаж», который будет показывать менеджерам по продажам и их руководителям полную статистику продаж их направления, основанную на нескольких источниках данных – запасы товаров на складах, статистика покупок по клиентам, данные по сопутствующим товарам.
Продолжение примера под катом
В качестве выгоды от внедрения ожидается прирост продаж на 15%. К тому же, освобождение 0,5-1 рабочего дня в неделю у руководителей отделов продаж, который они тратят на составление отчетности по своим подразделениям.
Полная разработка проекта оценена разработчиками в 6 месяцев, плюс тестирование и отладка займет не менее 3 месяцев, а полная дистрибуция с подключением и обучением 1500 пользователей новому инструменту – еще 3 месяца. Таким образом, мы сможем получить полную прибыль от проекта через 1 год.
Что делать, если у нас постоянное расширение штата, мы планируем смену системы учета, что в большинстве случаев ведёт к смене метаданных – структуры и типа исходных таблиц и справочников. Ждем смену системы учёта и потом запускаем проект? Как следствие несем убытки в качестве упущенной прибыли?
Каскадный подход в случае запуска проекта грозит либо затяжкой сроков, либо отказом от запуска (в случае изменившейся системы учета). В таком случае остаётся решение: свести разработку к так называемому гибкому подходу.
При гибком подходе мы –
Таким образом, мы приступаем к работе сразу без четкого видения окончания проекта. Планы строим только на ближайшие итерации, а на каждую итерацию выделяем по 1-2 недели – этого достаточно для разработки отчетности. Мы всегда можем держать руку на пульсе и управлять актуальностью содержимого как с технической стороны, так и со стороны наполненности данными. Через 1.5-3 месяца мы имеем рабочий прототип, который мы можем отдавать фокус-группе, тестировать отчет в боевых условиях, и вносить изменения в следующих спринтах.
Через полгода мы готовы транслировать первую версию продукта на всю сеть. При смене системы учета и базы данных, в один из следующих релизов включаем подмену источников, через 7-8 месяцев мы имеем работоспособный инструмент на новых источниках и 50% функционала опубликованного в проде. На момент завершения разработки продукта, система будет полностью протестирована и доработана. Гибкий подход оправдывает себя с точки зрения эффективности внедрения.
Полная разработка проекта оценена разработчиками в 6 месяцев, плюс тестирование и отладка займет не менее 3 месяцев, а полная дистрибуция с подключением и обучением 1500 пользователей новому инструменту – еще 3 месяца. Таким образом, мы сможем получить полную прибыль от проекта через 1 год.
Что делать, если у нас постоянное расширение штата, мы планируем смену системы учета, что в большинстве случаев ведёт к смене метаданных – структуры и типа исходных таблиц и справочников. Ждем смену системы учёта и потом запускаем проект? Как следствие несем убытки в качестве упущенной прибыли?
Каскадный подход в случае запуска проекта грозит либо затяжкой сроков, либо отказом от запуска (в случае изменившейся системы учета). В таком случае остаётся решение: свести разработку к так называемому гибкому подходу.
При гибком подходе мы –
- выясняем цели внедрения проекта,
- объём совместно с разработчиками делим на крупноблочные сервис-релизы,
- а их в свою очередь на стримы,
- и в работу берём только самое первостепенное,
- остальное мы считаем неопределенными параметрами, так как не имеет смысл планировать работы на несколько месяцев вперед
Таким образом, мы приступаем к работе сразу без четкого видения окончания проекта. Планы строим только на ближайшие итерации, а на каждую итерацию выделяем по 1-2 недели – этого достаточно для разработки отчетности. Мы всегда можем держать руку на пульсе и управлять актуальностью содержимого как с технической стороны, так и со стороны наполненности данными. Через 1.5-3 месяца мы имеем рабочий прототип, который мы можем отдавать фокус-группе, тестировать отчет в боевых условиях, и вносить изменения в следующих спринтах.
Через полгода мы готовы транслировать первую версию продукта на всю сеть. При смене системы учета и базы данных, в один из следующих релизов включаем подмену источников, через 7-8 месяцев мы имеем работоспособный инструмент на новых источниках и 50% функционала опубликованного в проде. На момент завершения разработки продукта, система будет полностью протестирована и доработана. Гибкий подход оправдывает себя с точки зрения эффективности внедрения.
Agile + BI
Особенности ведения BI-проектов
При разработке отчетности, обычно используется следующий цикл действий для BI-команды:
На наш взгляд, особое внимание стоит уделить сбору требований и изучению данных, так как правильная продуманная постановка задачи ускоряет процесс разработки и снижает количество повторяющихся лишних действий.
Мы вывели свой вариант гибкой методологии к проектированию дашбордов и созданию дата-продуктов. Основная цель – оптимизация ресурсных затрат.
- изучение первчиных данных
- сбор требований
- разработка БД / сборка таблиц / источников данных
- разработка дашбордов
- масштабирование
На наш взгляд, особое внимание стоит уделить сбору требований и изучению данных, так как правильная продуманная постановка задачи ускоряет процесс разработки и снижает количество повторяющихся лишних действий.
Мы вывели свой вариант гибкой методологии к проектированию дашбордов и созданию дата-продуктов. Основная цель – оптимизация ресурсных затрат.
Методология DataYoga
Этап 1. ПЛАНИРОВАНИЕ
На первом этапе, рекомендуем хорошо формализовать процессы коммуникации с заказчиком, чтобы сэкономить энергию. На этом же этапе создается первый набросок проекта, который затем уточняется.
На первом этапе, рекомендуем хорошо формализовать процессы коммуникации с заказчиком, чтобы сэкономить энергию. На этом же этапе создается первый набросок проекта, который затем уточняется.
Этап 2. ОЦЕНКА
При наличии большого количества участников проекта и широкой коммуникации внутри компании, хорошей практикой будет организация воркшопа для обсуждения ключевых элементов проекта, однозначного понимания целей и решаемых бизнес задач, выработки единого взгляда на KPI и источники данных. Имеет смысл как можно раньше запросить у заказчика Руководство по стилю Бренда организации, чтобы получить на руки цветовые и шрифтовые стандарты практикуемые внутри организации.
Для изучения данных, заполните ДатаЙога Blueprint – таблицу-анкету с описанием важным метрик, методикой их расчета, и владельцами необходимых данных. На данном этапе, заказчик оценивает все ли нужные ему показатели собраны и правильно посчитаны?
При наличии большого количества участников проекта и широкой коммуникации внутри компании, хорошей практикой будет организация воркшопа для обсуждения ключевых элементов проекта, однозначного понимания целей и решаемых бизнес задач, выработки единого взгляда на KPI и источники данных. Имеет смысл как можно раньше запросить у заказчика Руководство по стилю Бренда организации, чтобы получить на руки цветовые и шрифтовые стандарты практикуемые внутри организации.
Для изучения данных, заполните ДатаЙога Blueprint – таблицу-анкету с описанием важным метрик, методикой их расчета, и владельцами необходимых данных. На данном этапе, заказчик оценивает все ли нужные ему показатели собраны и правильно посчитаны?
Этап 3. ПРОТОТИПИРОВАНИЕ
Не забывайте о создании прототипов – они помогают получить результат быстрее. Определите функциональность продукта: фильтры, экшены, взаимодействия. Подготовьте визуальный макет дашборда на основании рекомендаций по стилю бренда. Загрузите тестовые данные такой же структуры как и основные и создайте работающий макет в программном продукте.
На этапе прототипа заказчик уже может дать свою обратную связь и оценить результаты работы.
Не забывайте о создании прототипов – они помогают получить результат быстрее. Определите функциональность продукта: фильтры, экшены, взаимодействия. Подготовьте визуальный макет дашборда на основании рекомендаций по стилю бренда. Загрузите тестовые данные такой же структуры как и основные и создайте работающий макет в программном продукте.
На этапе прототипа заказчик уже может дать свою обратную связь и оценить результаты работы.
Этап 4. РАЗРАБОТКА
Получите основные полные данные и соберите работающую логику со всеми вычислениями.
Этап 5. ПОЛЬЗОВАТЕЛЬСКИЙ ОПЫТ
Поработайте над внешней составляющей. Уточните мелочи взаимодействия, мобильный доступ и качество данных и расчетных показателей. Будет полезно провести необходимое обучение пользователей в удобном для них формате (очные презентации, вебинары, детальные инструкции, видеозаписи).
Получите основные полные данные и соберите работающую логику со всеми вычислениями.
Этап 5. ПОЛЬЗОВАТЕЛЬСКИЙ ОПЫТ
Поработайте над внешней составляющей. Уточните мелочи взаимодействия, мобильный доступ и качество данных и расчетных показателей. Будет полезно провести необходимое обучение пользователей в удобном для них формате (очные презентации, вебинары, детальные инструкции, видеозаписи).
При разработке BI-продуктов по Agile, многие компании советуют не увлекаться чрезмерно методологией как таковой, а именно, придавать больше ценности:
- людям и действиям, а не инструментам и процессам
- рабочему инструменту, а не сложной документации
- прямому сотрудничеству, а не переговорам по контракту
- приходящим изменениям, а не следованию плану
В идеале, BI-команды должны стремиться к self-service пользователей и децентрализованной аналитике.
СОВЕТ ЭКСПЕРТОВ
Следует понимать, что внедряя отчётность в компании, у нас сразу появляется пул пользователей, которые не привыкли пользоваться новыми инструментами и будут забрасывать разработчиков как техническими вопросами, так и вопросов по части корректности и сверки данных с их старыми источниками. Поэтому, лучше сразу создать либо отдельный почтовый ящик для обращений и выделять время специалистов на его обработку, или создать отдельную компетенцию в подразделении на разбор «ошибок»
Конечно, в крупных организациях, в которых много корпоративной отчетности, хорошей практикой является создание полноценных и самостоятельных центров компетенции, которые бы сопровождали пользователей как с технической точки зрения, так и с информационной.
Визуализация – только часть процесса
Практикуемся
Сегодня мы пройдем пятничное задание-тест на понимание agile концепции в целом.
Файл с решением предыдущего дня 12
Файл с решением предыдущего дня 12
Тест
Насколько вы готовы к эджайлу?
Проверьте свои догадки и удивитесь результату теста
| Начать тест |
Выберите правильное утверждение:
| Далее |
| Проверить |
| Показать результат |
Выберите правильное утверждение:
| Далее |
| Проверить |
| Показать результат |
Выберите правильное утверждение:
| Далее |
| Проверить |
| Показать результат |
Выберите правильное утверждение:
| Далее |
| Проверить |
| Показать результат |
Выберите правильное утверждение:
| Далее |
| Проверить |
| Показать результат |
Выберите правильное утверждение:
| Далее |
| Проверить |
| Показать результат |
Возможно, вы из другого лагеря
... И вам больше подойдет долгая каскадная модель разработки
| Пройти еще раз |
Вы близки к истине
Кое-где еще доносятся отголоски прошлого – "Каскадные моделииии, долгое прототипированиеее, неэффективноооость", но вы стараетесь. Молодцы
| Пройти еще раз |
Ого! Да вы же супер
Вы ответили правильно на большинство вопросов. Вот что называется гибкий подход! Клик клик ура!
| Пройти еще раз |
Вдохновляемся
Изучаем прекрасное в сети
Полезные ссылки по теме
Погружаемся
В тематические книжки и видео
Артефакты
Помогут Вам лучше усвоить и вовремя вспомнить основные элементы методик, подходов, последовательностей действий, проверенных практик
Два практичных файла по методологии DataYoga: шаблон планирования и блюпринт – схема – всех показателей.
Книги
Практичная книга обсуждает, какие процессы нужно внедрять повсеместно – от аналитиков и менеджмента до высшего руководства и совета директоров – чтобы создать такую культуру. Карл Андерсон рассказывает о цепочке аналитической ценности, которая поможет вам строить предиктивные бизнес-модели – от сбора данных и анализа до идей и конкретных обоснованных действий. Что там еще:
- Как собирать правильные данные правильным образом
- Нанимать аналитиков с правильными навыками и собирать их в команды
- Узнайте о статистических методах и инструментах визуализации данных
- Узнайте, как аналитики и их менеджеры могут способствовать развитию data-driven-культуры
Итоги этапа
Оценили для себя преимущества разных подходов разработки, взяли на вооружение ДатаЙога Blueprint для каталогизации метрик, пообсуждали с коллегами текущие методологические приемы и готовимся к выходным, чтобы на следующей неделе стартануть неделю тематик, посвященным построению дашбордов. Начнем в понедельник с построения набросков и освоим подходы к прототипированию для экономии времени разработки. Клик клик урааа!
~
