Al desarrollar la misma aplicación para múltiples plataformas, ¿cómo mantiene alineada la implementación?

Desde el punto de vista de PM son dos proyectos separados. Si los mismos desarrolladores trabajan tanto en el cliente de Android como en el de iOS, podría ejecutarlo como un solo proyecto. Podría lograr una alineación de características razonable, al tener dos versiones de las historias de usuario (iOS/Android) y priorizarlas una tras otra.

Sin embargo, si se trata de dos equipos diferentes, no puede ni debe intentar alinear el desarrollo de funcionalidades en los dos proyectos. Por supuesto, puede dar la misma prioridad de historia de usuario en las dos versiones, pero no cree dependencias de un proyecto a otro. Esto inevitablemente causará retrasos en un equipo, ya que la misma historia puede variar ampliamente en el tiempo requerido entre las dos plataformas. En esta situación, es mejor ejecutarlo como dos procesos de desarrollo diferentes con tableros kanban separados, etc.

Si hace Scrum, ejecutaría dos procesos Scrum diferentes simultáneamente y luego haría un "scrum de scrums" diario o semanal donde los líderes de cada equipo se reúnan y discutan el progreso.

No debería haber ninguna diferencia en las historias de usuario o las tareas/pruebas de aceptación porque ambos explican la funcionalidad, que será la misma para ambas aplicaciones.

Dicho esto, se recomienda crear tareas para cada plataforma (incluso si son las mismas) ya que será más fácil seguir el progreso de cada versión por las siguientes razones:

1. La estimación del tiempo puede diferir

2. Cesionario diferente

3. Brinde a cada equipo la flexibilidad para administrar sus tareas, tal vez al equipo de iPhone le gustaría comenzar a trabajar en la tarea n. ° 4 y luego en la n. ° 3 dado que, por supuesto, no dependen de ninguna otra tarea, pero el equipo de Android comenzará a trabajar en la tarea n. ° 3 y luego #4.

Puede usar códigos de colores (p. ej., post-its rojos para Android, post-its amarillos para iPhone)

Tomemos la pantalla de inicio de sesión como ejemplo.

Historia de usuario: Como usuario, quiero ingresar mis credenciales para ver mi perfil.

Prueba de aceptacion:

• use credenciales válidas, el usuario debe iniciar sesión en su perfil.
• utiliza credenciales no válidas, aparecerá un mensaje "Nombre de usuario o contraseña incorrectos" para el usuario.
• Haga clic en Enviar sin ingresar datos, aparecerá un mensaje de campo obligatorio.

Tareas (los post-its)

1. Diseño visual de iPhone
2. Diseño visual de Android

etcétera.

Espero eso ayude.

En el orden de sus preguntas..

¿Cómo mantienes a los desarrolladores de iOS y Android en la misma página?

Están construyendo diferentes clientes para el mismo producto. Trataría esto como un solo proyecto.

1. Este es un escenario en el que tienes que tener un poco de unión y separación al mismo tiempo.
2. Tanto los desarrolladores de iOS como los de Android deben pertenecer a un equipo de scrum (de lo contrario, las brechas de comunicación son inevitables, asistirán a las mismas ceremonias de scrum para que la comunicación sea efectiva y fluida)
3. De esta manera, podrá mantener a los equipos de iOS y Android en la misma página sobre la visión del producto, las expectativas sobre el cronograma, las preocupaciones de las partes interesadas y las comunicaciones generales.

¿Qué otras prácticas lo ayudan a asegurarse de que una característica o una historia de usuario se implementen de la misma manera en ambas aplicaciones? ¿Qué son las prácticas estándar?

Esto es lo que he hecho..

1. Las tareas de desarrollo/control de calidad/diseño están separadas, ya que estas tareas deben ejecutarse por separado para cada plataforma, por lo que sí, tendrá una acumulación de productos pero tareas duplicadas para cada plataforma.
2. Teniendo en cuenta la implementación de la función A, habrá una publicación para Android y otra publicación para iOS con estimaciones probablemente diferentes
3. En su caso, diferentes desarrolladores se comprometerán con la implementación de la característica A en iOS y Android, por lo que tiene más sentido tener diferentes tareas.
4. También puede usar un gráfico de quemado (porque, en lo que respecta a los propietarios de productos en una iteración determinada, los elementos seleccionados de la cartera de pedidos deben publicarse para iOS y Android juntos )

Entonces, como señalé anteriormente, para todas las comunicaciones relacionadas con características, requisitos, planificación de sprints, los miembros del equipo de diseño de interfaz de usuario que trabajan en ambas plataformas deben unirse, ya que exigen una cierta cantidad de sincronización.

Durante la implementación, los miembros del equipo de control de calidad y lanzamiento que trabajan en cada plataforma tendrán tareas específicas de la plataforma.

En general:

• Una aplicación bien diseñada puede tener una implementación diferente según la plataforma. Un ejemplo: la aplicación iOS navega de una pantalla a otra y el botón Atrás está en la barra de navegación en la parte superior izquierda. El botón trasero para la aplicación de Android es un botón físico en la parte inferior del teléfono, no en la aplicación.
• Una app bien diseñada sigue los lineamientos propuestos por cada empresa (Apple o Google), busca brindar la mejor experiencia de usuario y trata de evitar hacer cosas que no existen en una plataforma.
• Por lo tanto, la implementación de cada una de las características/historias de usuario podría ser diferente según cada plataforma.

Melé:

• Tendrá dos procesos Scrum en paralelo y tendrá todas las historias de usuario duplicadas.
• De acuerdo con las reglas comerciales, cada aplicación podría tener la misma cantidad de características/historias de usuario, o no.

Datos:

• Para aplicaciones con datos persistentes, es posible usar un repositorio de datos compartidos o un servicio web para compartir modelos de datos.

Mejores prácticas:

• Para garantizar el comportamiento de cada función entre aplicaciones (a pesar de las posibles diferencias sobre cómo realizar una acción según el dispositivo) es necesario contar con un equipo de QA y QC, con casos de prueba muy claros y agnósticos a la plataforma.
• Si después de ejecutar (manualmente o de forma automática) todos los casos de prueba, los resultados son todos válidos, tendrá 2 aplicaciones con las mismas funcionalidades y posibles implementaciones diferentes.

por favor véalo como dos proyectos diferentes porque.

Los problemas que surgen al tratar de crear interfaces de usuario para diferentes teléfonos móviles o teléfonos inteligentes no se limitan a la forma en que el contenido diseñado aparece en la pantalla. Por ejemplo, diseñar una interfaz de usuario para teléfonos sin pantalla táctil es muy diferente de diseñar para teléfonos con pantalla táctil. Un tipo de interfaz no se adapta necesariamente a los requisitos técnicos de todos los dispositivos.

Creo que varias personas han dicho que debes tratarlo como dos proyectos separados.

Creo que debe tratarlo como un programa: un conjunto de proyectos gestionados con una metodología similar y con un objetivo coherente en mente.

¿Cómo mantienes los dos proyectos alineados? Alinear los proyectos. Asegurarse de que:

• Las declaraciones de alcance coinciden
• La coincidencia de KPI: cómo mide el rendimiento y la eficacia tiene que coincidir
• Coincidencia de riesgos (o al menos se examina cada riesgo para ver si tiene implicaciones para el otro proyecto).
• El control de cambios/Gestión de cambios están alineados. Cualquier cambio en cualquiera de los proyectos debe examinarse para ver si tiene implicaciones para el otro proyecto.
• Partidos finales de pruebas de Aceptación Operacional.

Cuando los dos no coincidan, asegúrese de que haya una razón. Si hace su parte en la configuración de esto, también identificará claramente qué parte del trabajo es el núcleo de su proyecto y qué partes son específicas de la plataforma.

Si esto es algo que va a hacer regularmente, puede ser útil tratarlo como tres proyectos.

• Un proyecto para producir un nuevo producto: énfasis en la arquitectura, la funcionalidad, etc. Una vez que se determinan la arquitectura y la funcionalidad, todo el trabajo se subcontrata a uno de los otros dos equipos, que son tratados como subcontratistas.

  • Un proyecto para implementar el producto en Android.

  • Un proyecto para implementar el producto en Apple.

Aunque hay muchos más gastos generales al configurarlo de esa manera, creo que es posible que, a la larga, todos los miembros del equipo entiendan lo que están haciendo. "Estoy desarrollando la arquitectura para el producto X". "Estoy implementando la interfaz de usuario del producto X en Apple". etc.