Какие методологии разработки применяются в различных IT-компаниях — Tproger собирает рассказы представителей индустрии

Наш подписчик задал вопрос:

Какие методологии разработки применяют у вас в компании? Как вы вообще организуете процесс от постановки задачи до выхода продукта на рынок?

Мы передали его на рассмотрение нашим экспертам, а теперь делимся с вами полученными ответами.

Михаил Игонин, ведущий инженер, Дирекция по разработке программного обеспечения, «ПЕТЕР-СЕРВИС»

Наша компания производит программные продукты для операторов сотовой связи. Спектр решений довольно широк: от систем самообслуживания абонентов (хорошо известный всем личный кабинет) до сложных распределенных и высоконагруженных систем, взаимодействующих с сетевым оборудованием оператора. При этом рынок, на котором работают операторы связи — очень конкурентная среда. Там быстро появляются новые технологии, сервисы и бизнес-инициативы. Чтобы донести это до своих клиентов, оператору необходимо изменить многие собственные ИТ-системы. Следовательно, компания-производитель этих систем должна уметь быстро реагировать на требования рынка и выпускать качественный софт в условиях ограниченного времени.

Существующий в нашей компании процесс разработки помогает решить эту непростую задачу. Во-первых, над созданием продуктов работают кросс-функциональные команды. В них присутствуют все стандартные роли: аналитик, разработчик, тестировщик. Во-вторых, важным фактором для нас является инженерная культура. У каждого сотрудника есть базовый уровень знаний: ревью кода, билд-сервер с автоматическим запуском тестов и статическим анализатором кода, автоматическое развертывание продукта, общая модель ветвления в репозиториях исходного кода. При этом многие команды пошли дальше: они расширяют свои знания и применяют практики экстремального программирования, контейнерную виртуализацию для разработки и многое другое.

Чтобы быть в тренде, программисты должны непрерывно развиваться как профессионалы. В этом компания им активно помогает. Мы отправляем ребят на обучение, конференции, а также организуем различные мероприятия на своей площадке. В-третьих, в процессе разработки мы используем итеративно-инкрементальный подход. Многие автономные продукты выпускаются каждые две недели через прямую поставку софта в тестовую зону заказчика, а иногда сразу в пром. Продукты с высокой степенью комплексности выпускаются синхронно каждые 3 месяца, при этом каждые 2 недели команды демонстрируют потенциально готовый к отгрузке продукт и собирают обратную связь от заказчика, пользователей системы и других заинтересованных лиц.

Конечно, у нас есть много открытых вопросов, ведь общее число команд — более 70! Но благодаря целенаправленному и регулярному улучшению собственных процессов и инструментов на всех уровнях мы знаем, что сможем справиться с любой задачей. И в этом заключается, четвертый, пожалуй, самый важный секрет нашего успеха.


Василий Кораблев, директор практики бизнес-архитектуры в AT Consulting

Как компания мы очень адаптивны, поэтому на каждом проекте используем оптимальные методологии. Для «коробочных» внедрений, где есть отработанные схемы, это обычно референтные (эталонные) подходы, учитывающие специфику конкретного решения, например, Oracle AIM.

Для разработки систем с нуля мы используем один из подходов гибкой (Agile) или водопадной (waterfall) разработки, либо их комбинации. Сам Agile не является чем-то революционным: он содержит ряд элементов, известных еще со времен артелей начала прошлого столетия и бригадного подряда с 80-х годов прошлого века. Так что многое новое — это хорошо забытое и перевнедренное старое.

Процесс вывода продукта на рынок и его непрерывного совершенствования традиционно основан на цикле непрерывного совершенствования качества Деминга (циклическое повторение этапов Plan-Do-Check-Act), ускоренного Scrum, дизайн-мышления и других современных техниках.


Николай Добровольский, вице-президент Parallels

В разных проектах у нас используются различные подходы – где-то Agile с одно-двухнедельными спринтами, а где-то — почти что Waterfall с майлстоунами по несколько месяцев. За многие годы работы у нас сложилось ощущение, что чем больше проект и команда, работающая над ним, тем сложнее и менее эффективно стараться запихнуть разработку в agile-процесс. Да и не всегда это нужно.

Намного более важно, чтобы даже в маленькой команде были не только разработчики, но и тестировщики и обязательно продакт- и програм-менеджеры — люди, которые работают над тем, какая функциональность важна и как ее сделать красивой и удобной для пользователя. Поэтому у нас сначала идея продукта разбивается на отдельные части, которые прописываются достаточно подробно с точки зрения дизайна и функциональности. Дальше все они обсуждаются в деталях с разработчиками и тестировщиками, а только потом мы приступаем непосредственно к разработке, тестированию и дальнейшему выпуску.


Михаил Вайсман, CEO Trinity Digital

Мы работаем с гибкими методологиями разработки (Agile). После постановки задачи проводим аналитику, создаем дизайн мобильного приложения. Далее разработка — ведется по двух-трехнедельным спринтам. В рамках спринта решаются задачи по разработке, дизайну, проводится тестирование. И, наконец, релиз! После релиза мы оказываем услуги по поддержке приложения и по продвижению, а также начинаем работу над новым функционалом и новыми версиями.


Владислав Никитин, технический директор компании Itransition

Как компания, оказывающая услуги по заказной разработке программного обеспечения, мы стараемся быть гибкими при выборе подхода к разработке: адаптируемся к специфике каждого проекта, учитываем требования клиентов. Для всех наших проектов можно выделить следующие ключевые аспекты, которые мы считаем неотъемлемой частью процесса разработки:

  1. Выбор правильной методологии ведения проекта. Это могут быть различные варианты гибкой разработки, водопадная модель или же их комбинации. А учитывая, что заказчик хочет иметь возможность внесения изменений на всех этапах разработки и как можно раньше получать работоспособные версии систем, в том числе и масштаба Enterprise, все большую популярность приобретает подход Scaled Agile.
  1. Привлечение бизнес-аналитиков на всех этапах разработки для выяснения, спецификации, уточнения и, что важно, верификации требований. Это позволяет минимизировать риск искажения или неверной интерпретации требований на всем протяжении процесса разработки.
  1. Использование «унифицированной среды разработки» — совокупности специально подобранных и проинтегрированных между собой инструментов, необходимых для создания ПО (управление задачами, контроль версий, сервер непрерывной сборки, статические анализаторы кода для различных языков и т.д.), а также корпоративных практик и стандартов, которыми мы руководствуемся при разработке.
  1. Разделение тестирования и разработки — на всех наших проектах тестирование производится силами независимой команды, что позволяет предоставить нашим клиентам максимально объективную оценку качества системы.

Также мы активно используем автоматизацию тестирования и практики DevOps.


Статья продолжает дополняться.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на admin@tproger.ru, мы расскажем, как это сделать.