При разработке одного и того же приложения для нескольких платформ, как вы поддерживаете согласованность реализации?

С точки зрения PM это два отдельных проекта. Если одни и те же разработчики работают над клиентом для Android и iOS, вы можете запустить его как один проект. Вы можете добиться разумного выравнивания функций, имея две версии пользовательских историй (iOS/Android) и расставляя их по приоритету одну за другой.

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

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

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

При этом рекомендуется создавать задачи для каждой платформы (даже если они одинаковые), так как будет легче отслеживать прогресс для каждой версии по следующим причинам:

1. Оценка времени может отличаться

2. Другой правопреемник

3. Предоставьте каждой команде возможность гибко управлять своими задачами. Возможно, команда iPhone захочет начать работу над задачей № 4, а затем № 3, учитывая, что они, конечно, не зависят ни от каких других задач, но команда Android начнет работу над задачей № 3, затем №4.

Вы можете использовать цветовое кодирование (например, красные стикеры для Android, желтые стикеры для iPhone).

Возьмем для примера экран входа в систему.

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

Приемочные испытания:

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

Задачи (стики)

1. визуальный дизайн айфона
2. Визуальный дизайн Android

и так далее.

Надеюсь, это поможет.

В порядке ваших вопросов..

Как вы держите разработчиков iOS и Android на одной волне?

Они строят разных клиентов для одного и того же продукта. Я бы отнес это к одному проекту.

1. Это сценарий, в котором вы должны иметь немного союза и разделения одновременно.
2. Разработчики iOS и Android должны принадлежать к одной скрам-команде (другие мудрые пробелы в общении неизбежны, они будут присутствовать на одних и тех же церемониях схватки, что сделает общение эффективным и беспрепятственным)
3. Таким образом, вы сможете держать команды iOS и Android на одной странице в отношении видения продукта, ожиданий в отношении сроков, проблем заинтересованных сторон и общих коммуникаций.

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

Это то, что я сделал.

1. Задачи разработки/контроля качества/дизайна разделены, так как эти задачи должны выполняться отдельно для каждой платформы, поэтому да, у вас будет один невыполненный продукт, но дублирующиеся задачи для каждой платформы.
2. Учитывая реализацию фичи А, будет пост для Android и еще один пост для iOS с, скорее всего, разными оценками.
3. В вашем случае разные разработчики будут реализовывать функцию A в iOS и Android, поэтому имеет смысл иметь разные задачи.
4. Вы также можете использовать одну диаграмму выгорания (поскольку владельцы продукта заинтересованы в данной итерации, выбранные элементы невыполненной работы должны быть выпущены как для iOS, так и для Android вместе ) .

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

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

В общем:

• Хорошо спроектированное приложение может иметь разную реализацию в зависимости от платформы. Пример: приложение iOS переходит с одного экрана на другой, а кнопка «Назад» находится на панели навигации в левом верхнем углу. Задняя кнопка для приложения Android — это физическая кнопка внизу телефона, а не в приложении.
• Хорошо спроектированное приложение следует рекомендациям, предложенным каждой компанией (Apple или Google), стремится обеспечить наилучшее взаимодействие с пользователем и старается избегать создания вещей, которых нет на платформе.
• Таким образом, реализация каждой из функций/пользовательских историй может быть разной в зависимости от платформы.

Скрам:

• У вас будет два Scrum-процесса параллельно, и у вас будет дублироваться вся пользовательская история.
• Согласно бизнес-правилам, каждое приложение может иметь одинаковое количество функций/пользовательских историй, а может и не иметь.

Данные:

• Для приложений с сохраняемыми данными можно использовать общий репозиторий данных или веб-сервис для совместного использования моделей данных.

Лучшие практики:

• Чтобы обеспечить поведение каждой функции между приложениями (несмотря на возможные различия в том, как выполнять действие в зависимости от устройства), вам нужна команда QA и QC с очень четкими тестовыми примерами и независимой от платформы.
• Если после запуска (вручную или автоматически) всех тестовых случаев все результаты верны, у вас будет 2 приложения с одинаковыми функциями и возможными разными реализациями.

пожалуйста, рассматривайте это как два разных проекта, потому что.

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

Я думаю, что многие люди говорили, что вам нужно рассматривать это как два отдельных проекта.

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

Как вы поддерживаете согласованность двух проектов? Выровняйте проекты. Убедитесь, что:

• Операторы области действия совпадают
• Соответствие KPI — то, как вы измеряете производительность и эффективность, должно совпадать
• Риски совпадают (или, по крайней мере, каждый риск изучается, чтобы увидеть, влияет ли он на другой проект).
• Управление изменениями/управление изменениями согласованы. Любое изменение в любом проекте должно быть изучено, чтобы увидеть, не повлияет ли оно на другой проект.
• Окончательные приемочные испытания.

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

Если это то, что вы собираетесь делать регулярно, может быть полезно рассматривать это как три проекта.

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

  • Проект по реализации продукта на Android.

  • Проект по внедрению продукта на Apple.

Хотя при такой настройке возникает гораздо больше накладных расходов, я думаю, что в долгосрочной перспективе все в команде будут понимать, что они делают. «Я разрабатываю архитектуру для продукта X». «Я внедряю пользовательский интерфейс продукта X в Apple». и т.д.