Как мы запускаем Agile-проекты в качестве расширенной распределенной команды клиентов

Недавний отчет Computereconomics показал, что в период 2018–2019 годов процесс разработки приложений стал наиболее перспективным для аутсорсинга: 56% организаций по всему миру передали свои требования к разработке на аутсорсинг.

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

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

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

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

Что мы подразумеваем под распределенной Agile-командой  

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

Почему компании инвестируют в распределенную команду разработки мобильных приложений?

Существует ряд причин, побуждающих компании инвестировать в распределенные команды, в том числе:

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

Теперь, когда мы рассмотрели определение и необходимость, давайте посмотрим, как команда Appinventiv работает как распределенная команда наших клиентов. Но прежде чем мы перейдем к этому, давайте быстро посмотрим, как выглядит наша типичная структура распределенной гибкой команды :

Подход Appinventiv к распределенной Agile-разработке  

Много раз мы получаем проект, в котором требование влечет за собой работу в тесном контакте с FTE клиентов. В таких случаях становится очень важным, чтобы мы не допускали расстояния в тысячи миль между работой и чтобы мы могли вносить изменения и действовать в процессе разработки в режиме реального времени.

Как мы обеспечиваем своевременную доставку без нулевых задержек связи и недоразумений — это вопрос, ответ на который лежит в распределенной методологии Agile .

Подходит как для малого, так и для крупного бизнеса, следование лучшим практикам распределенной гибкой разработки очень удобно, когда нам приходится работать вместе с командой, которая находится в другом географическом месте с совершенно другим часовым поясом.

Давайте посмотрим на метод распределенной гибкой разработки, который мы применяем в процессе разработки нашего мобильного приложения.

После того, как мы представили всех членов команды друг другу и сотрудничали с программным обеспечением для управления проектами, начинается настоящая работа.

Мы формулируем процесс ежедневной методологии Agile Scrum . В то время как в своем традиционном понимании Scrum требует личной встречи продолжительностью 15 минут, на которой каждый участник делится статусом своих задач и информирует команду о задачах, которые они будут решать следующими, почти невозможно следовать тому же процессу, когда половина команды находится в какой-то другой географической стране в другом часовом поясе.

Что мы делаем, чтобы сохранить суть взаимодействия лицом к лицу в схватке, так это проводим видеозвонок в определенное время, которое подходит для всех в команде, работающей над проектом. С помощью совместного использования экрана наш Agile Scrum Master просматривает невыполненную работу виртуального спринта с помощью таких инструментов, как Trello или Jira, позволяя каждому члену команды предоставлять обновленную информацию о том, куда движется проект.

Мы убедились, что очень важно предоставить всем членам команды доступ к легкодоступной и обновляемой платформе отслеживания задач. Мы также подчеркиваем важность использования коммуникационных платформ, таких как Skype или Slack, чтобы каждый мог делиться новостями или задавать свои сомнения между двумя периодами времени схватки.

Еще один подход, который мы используем для ежедневного agile и scrum- процесса, заключается в том, что для каждого отдельного scrum мы назначаем одного scrum-мастера. Таким образом, каждая отдельная команда работает как отдельная команда Scrum со скрам-мастером и владельцем продукта — процесс, также известный как Scrum of Scrums.

При этом все представители схватки дают ответы на следующие вопросы схватки:

• Работа, которую команда выполнила с момента последнего Scrum of Scrums.
• Рабочая группа планирует сделать это до следующей встречи Scrum of Scrums.
• Текущий блокирующий, с которым сталкивается команда
• Блокировщик, который может привести к другой команде Scrum.

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

Уроки, которые мы извлекли, работая над распределенным процессом гибкой разработки

1. Создание распределенной команды — это построение культуры, а не процесса.

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

2. Успешны только SMART-проекты

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

3. Нет альтернативы онлайн-инструментам для совместной работы

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

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

Проблемы с распределенным гибким подходом к разработке и как мы их решаем

1. Разница в культуре

Обычно распределенный гибкий подход к разработке программного обеспечения предполагает работу с командами из разных культур. Эта разница вызывает трения из-за разных ценностей и фигур речи.
Наше решение: мы очень тесно сотрудничаем с командой клиента в первые несколько дней, чтобы привыкнуть к их между строк и контексту.

2. Разница в часовых поясах

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

3. Отсутствие общей идеи «большой картины».

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

4. Отсутствие права собственности на код

Отсутствие коллективного владения кодом означает, что ни один человек не владеет кодом, он принадлежит всей команде, и поэтому, когда что-то идет не так, начинается игра с обвинением.
Наше решение: мы применяем систему контроля версий, чтобы проверить, кто и когда работает над кодом, а также каковы последствия этого. Таким образом, на картинке полная прозрачность и честность.

Итак, это история о том, как мы в Appinventiv стали распределенной командой клиентов, принадлежащих всему миру.
Хотите обсудить, как поднять уровень вашей распределенной гибкой разработки программного обеспечения? Свяжитесь с нашими разработчиками мобильных приложений.