Сразу хочется сказать, рассказ не о том как мы используем модный современный эджайл и работаем по скрам и канбан. Эджайл, конечно, хорошая прогрессивная методология, но она не универсальный рецепт для успешной реализации проекта. Хотя основные положения эджайл мы тоже исповедуем.
Мы ставили целью рассказать доступно о нашем подходе к реализации проектов по разработке ITрешений: независимо, разработка ли это мобильных и Web-приложений или разработка на С++или решения для программ 1С.
Надеюсь, что понимание внутренней кухни разработки сделает нас немного ближе и улучшит взаимопонимание между заказчиком и исполнителем.
Итак, как обычно по порядку: обратился заказчик с какой-то задачей.
Некоторые примеры какие нам встречаются задачи от клиентов:
- Это может быть необходимость в разработке красивого мобильного приложения,
- Может быть требуется внедрить продукт 1С, а перед этим попросить помощи в выборе наиболее оптимальной конфигурации
- Разработать драйвер на Си ++ для интеграции 1С Предприятия с нестандартным оборудованием
- Разработать SCADA или MES систему для оперативного управления производством и диспетчирования.
- Разработать web-приложение. Например, платежный сервис или магазин.
- Исправить ошибки внедрения 1С: неправильный расчет себестоимости, не закрываются периоды, отрицательные остатки - и по возможности разработать решение по недопущению или минимизации таких ошибок.
Как видно, задачи самые разные. Соответственно, и подходы к реализации задачи тоже разные. Не придумали пока универсального подхода на все случаи. И нескоро придумают. Да и не надо. К каждой задаче мы выбираем наиболее подходящий. Не буду вас грузить моделями по Кеневину и прочей айтишной замудрёностью. Просто расскажу про те, которые мы используем при проектировании ИТ систем и разработке ПО. И в каких ситуациях.
На сегодняшний день среди доброго десятка (это известных мне, реально их больше) разных методологий разработки ПО, мы используем в разработке решений для бизнеса только некоторые, нам их хватает для охвата почти всего круга задач.
Попробую кратко описать их простым языком на самых популярных примерах реальных задач.
1. Разработка мобильного приложения.
Один из наши частых видов заказов. Давайте попробуем разобрать проект и определить как мы будем его делать.
Сначала определим общие рамки задачи, возьмем наиболее популярный формат:
Некий интернет-магазин, возможность онлайн-оплаты, личный кабинет, история заказов и просмотров, корзина, избранное, каталог с витриной в разных видах представления, поиск по каталогу, чат с клиентами.
Что у нас есть по имеющимся наработкам:
1. Многообразие витрин, готовые механизмы. Но … это лицо магазина и каждый хочет свои плюшки.
2. Онлайн-оплата – есть отработанные техники, но зависит от эквайера: может быть платежный сервис - агрегатор или конкретный банк.
3. Личный кабинет – масса вариантов как готовых так и кастомных
4. Остальное – дополнительные сервисы и плюшки, присутствующие почти в каждом магазине, которые мы делали.
Как будем определять технологию реализации.
Не буду углубляться в разбор технологии решения, скажу лишь что такая система относится к «сложным» системам, поскольку не ко всем ее элементам есть хорошо отработанные качественные практики как в «простых», но нет и совсем неизведанных мест, где нужно пробовать и исследовать.
Для такого проекта лучше подойдет так называемый итеративный процесс. Почему?
В задаче такого типа мы не имеем полного детального состава требований. Более того, многие требования могут и будут меняться в процессе разработки приложения. Зато можно достаточно полно описать требования к базовому функционалу и довольно быстро разработать минимальную функциональную версию продукта (MVP). Далее с каждой итерацией будем расширять функциональность приложения. При этом изменение требований существенно не скажется на сложности разработки и сроках. Подробнее об методиках разработки можно почитать в материале.
2. Доработка или исправление программ на платформе 1С:Предприятие
Пожалуй, самый массовый сегмент в нашем портфеле заказов.
В наличии от клиента:
Требование по разработке некоего логистического функционала с отражением в финансовом и бухгалтерском учете, отсутствующего в типовом решении 1С: Комплексная автоматизация 2.
Имеем: обширный опыт в разработке решений в области логистики, бухучета, управленческого учета и бюджетирования, отличное знание конфигурации 1С: Комплексная автоматизация 2, проверенные технологии разработки расширений конфигураций 1С:Предприятие, доработки конфигураций,отличное знание внутренних механизмов платформы 1С.
Пожалуй, такую систему можно отнести к «простым». Не потому что легко разрабатывается, а потому что имеется огромный опыт, практически во всех предметных областях от простых задач до сложных систем. Нет практически ничего, где нужно экспериментировать и придумывать что-то новое для реализации решения.
Для такой задачи самое оптимальное – применить Водопадный процесс (или каскадный).
- Анализируем бизнес, определяем цели, реально необходимые бизнесу.
- Формулируем функциональные требования
- Делаем детальное ТЗ
- Реализуем
- Тестируем
- Запускаем.
Да, иногда возможны «отскоки» на ступень назад для уточнения и корректировки, но чаще всего они не несут существенных архитектурных изменений решения.
3. Разработка web-приложения на блокчейн-платформе Rippple
Да, была и такая задача. Что требуется:
Задача по разработке приложения для торговли криптовалютой. Требуется «горячий» кошелек, торговое ядро, средства визуализации в форме web-интерфейса, ведение истории торгов и операций, чат с администрацией платформы и другими участниками, новостная лента, «стакан», журнал ордеров, личный кабинет с настройками.
Что имеем:
Некоторый опыт в разработке на блокчейн-платформе, опыт разработки приложений для трейдинга, обширный опыт в web-приложениях.
То есть, у нас много проверенных кейсов в некоторых компонентах, но мало опыта в создании комплексного приложения, использующего эти наработки.
На лицо «комплексная система». В ней требуются исследования в разработке взаимосвязанных решений, в которых есть опыт разработки по отдельным компонентам.
Оптимальный подход – Agile, или гибкая методология. Идем небольшими итерациями, пробуем, на ходу корректируем требования и функциональность, двигаемся от малого и частного к большому и общему
