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

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

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

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

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

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

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

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

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

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

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

В компании NVIDIA представлен широкий спектр разнообразных активностей, касающихся разработки и исследований. Методология может варьироваться в зависимости от направления деятельности, команды или проекта. Однако большинство проектов по софтверной разработке подразумевает использование Agile и Continuous Integration.

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

1. Выбор правильной методологии ведения проекта. Это могут быть различные варианты гибкой разработки, водопадная модель или же их комбинации. А учитывая, что заказчик хочет иметь возможность внесения изменений на всех этапах разработки и как можно раньше получать работоспособные версии систем, в том числе и масштаба Enterprise, все большую популярность приобретает подход Scaled Agile.

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

3. Использование «унифицированной среды разработки» — совокупности специально подобранных и проинтегрированных между собой инструментов, необходимых для создания ПО (управление задачами, контроль версий, сервер непрерывной сборки, статические анализаторы кода для различных языков и т.д.), а также корпоративных практик и стандартов, которыми мы руководствуемся при разработке.

4. Разделение тестирования и разработки — на всех наших проектах тестирование производится силами независимой команды, что позволяет предоставить нашим клиентам максимально объективную оценку качества системы.

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

У нас в SAP на этапе постановки задачи все более широко используется методология Design thinking. На этапе создания продукта часто можно видеть варианты Agile, причем иногда совмещенные с Waterfall-подходом.

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

Все начинается с менеджера продукта и менеджера программ — эти две роли, часто объединённые в одном человеке, отвечают за вопросы «какие проблемы решает наш продукт, для каких пользователей и как он это делает». Менеджер программ, по сути, отвечает за ежедневную коммуникацию и представление точки зрения пользователя в команде разработчиков, а также за создание спецификаций на продукт и его компонентов. Рабочие инструменты менеджера программ — система документооборота (например, confluence), системы change management, bug tracking вроде Jira, средства телекоммуникаций (как webex), средства прототипирования и создания «скетчей» интерфейсов, средства для сбора информации о существующих версиях продукта и о том, как его используют живые пользователи. Менеджер программ также выступает заказчиком для следующей роли — дизайнера.

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

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

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

Тестировщики и QA — это люди, которые ответственны за тестирование продукта (ручное или автоматическое) и за внедрение и выполнение методик, повышающих качество продукта, за отмашку «продукт готов к релизу».

Технические писатели/документаторы отвечают за создание пользовательской документации и часто — за средства доставки этой документации к пользователю.
Служба поддержки помогает пользователям разбираться с проблемами, возникающими при работе или внедрению продукта в эксплуатацию.

Кроме того, в реальной жизни все может быть сложнее — есть эпизодические роли (возникающие на определенных этапах разработки), роли, которые хотя и не имеют прямого отношения к разработке — плотно с ней взаимодействуют (вроде маркетинга и sales engineering), роли, которые существуют только для определенных продуктов — например, профессиональные сервисы, появляются новые роли, которые становятся возможны благодаря развитию средств разработки и внедрения (вроде DevOps инженеров).

У нас применяется система СКРАМ с элементами Канбан. И в целом мы адаптируем все технологии, стараемся чтобы здравый смысл руководил. У нас вся компания разбита на команды до 10 человек, мы работаем кварталами и спринтами внутри них. На квартал существуют глобальные планы компании, например, запустить новый продукт, или провести техническую реформу (недавно мы переходили на микросервисы). К этим глобальным планам команды добавляют свои планы, которые возникают из идей внутри команды или от пожеланий пользователей. Мы стремимся делать то, что мы делаем, самым лучшим образом и у нас, как нам кажется, это получается.