Aquí está mi situación:
Trabajo con dos equipos SCRUM, iOS y Android
Cada miembro del equipo SCRUM tiene su propio Product Backlog y Sprint
Hemos compartido Planeaciones de Sprint, Revisiones y Retrospectivas (ambos equipos asisten) para que los productos puedan mantenerse alineados y que un equipo determinado pueda beneficiarse del conocimiento de otro equipo para abordar un problema específico, así como en la estimación de puntos de historia.
Debido a que la hoja de ruta y las características de iOS y Android son bastante similares, ambos productos comparten los mismos ingenieros de back-end como recursos. Como resultado, creamos subtareas de back-end para historias de usuario dadas en sprints y los ingenieros de back-end asisten a Sprint Planning como parte del equipo multifuncional.
Por trabajo de fondo me refiero al trabajo del lado del servidor . Estamos hablando de aplicaciones móviles aquí, así que cualquier cosa relacionada con la gestión de usuarios, por ejemplo. es decir, supongamos que un usuario quiere eliminar su perfil pero aún no puede. Una CTA de eliminación de perfil de usuario debería estar disponible en el cliente, pero debería funcionar con solicitudes HTTP al servidor. Así que aquí, como parte de la misma historia de usuario ("como usuario, quiero poder eliminar mi perfil), haríamos que tanto el cliente como el servidor trabajaran juntos.
Estos ingenieros de back-end son principalmente un recurso para los productos móviles, ya que somos una empresa emergente enfocada en dispositivos móviles.
¿Debería el backend tener su propio backlog, separado de los equipos móviles, o solo ser considerado el propietario de las subtareas del backend en cada uno de los sprints de los equipos móviles?
Creo que los desarrolladores de back-end se pueden separar en un tercer equipo.
Por supuesto, alguien puede decir que los equipos perderán su funcionalidad cruzada. Pero si observamos esta situación desde otro punto de vista, veremos que el equipo de back-end implementa un producto independiente.
En ese caso, ambos equipos de clientes serán partes interesadas en el producto del equipo de back-end. Por supuesto, el equipo de back-end debe tener un Propietario del producto, que será un requisito de back-end separado de las Historias de usuario de los clientes y creará un Product Backlog (para el servicio de back-end) basado en ellos.
La interacción entre los equipos se realizará dentro de las reuniones de revisión del equipo de back-end (los equipos de clientes, como partes interesadas, darán su opinión sobre los problemas de back-end, la usabilidad de la API, etc.).
La desventaja de este enfoque, que describí a continuación, es que el equipo de back-end debe estar un paso (es decir, Sprint) por delante de los equipos de clientes. Esto significa que los propietarios de productos de los equipos de clientes deben planificar dos primaveras con anticipación para permitir que los propietarios de productos del equipo de back-end recopilen información sobre el próximo Sprint. Esto hace que el proceso sea un poco menos flexible.
Además, puede haber algunos problemas con la distribución de costos para los trabajos de back-end entre los equipos de los clientes. Pero, si los tres equipos trabajan para un cliente (o en su caso, para un proyecto), no le importa.
Como con la mayoría de las cosas ágiles, la respuesta es "depende". Voy a abordar esto en dos niveles, Product y Sprint Backlogs.
Sprint Backlog: el equipo del servidor tiene otro trabajo: si el equipo del servidor tiene trabajo que no está relacionado con las necesidades de los dos equipos de la aplicación, entonces absolutamente debería tener su propio Sprint Backlog. Tiene su propio trabajo por hacer y el trabajo de la aplicación es solo una parte de él.
El equipo del servidor solo es compatible con las aplicaciones . En este caso improbable, mi consejo sería trasladar a los miembros del equipo del servidor a los equipos de la aplicación. En este punto, está creando un "porción de pastel" en el que el equipo tiene a todos los necesarios para lanzar un software probado y que funcione.
Lista de pedidos del producto : una lista de pedidos del producto es la lista total de todo lo que desea crear para su producto. Por lo general, una aplicación de iOS o Android no es su producto, es un método de entrega. Por ejemplo, Evernote (simplemente eligiéndolo como un producto popular que la mayoría de nosotros conocemos) tiene aplicaciones basadas en iOS, Android, PC, Mac y web. Todos ofrecen esencialmente la misma funcionalidad (dentro de los límites del software).
Cuando tiene un producto y múltiples vehículos de entrega, entonces la recomendación es tener una acumulación de productos única. Utiliza las pruebas de aceptación de la cartera de productos para determinar qué equipos están comprometidos. Por ejemplo, digamos que Evernote quiere poder imprimir notas. No quieren lidiar con la impresión en la nube, por lo que las pruebas de aceptación solo enumeran PC, Mac y Web. Sin embargo, la creación de una nueva nota tiene pruebas de aceptación para todos sus métodos de entrega. Estos también se pueden estructurar como "características" o "épicas", historias de usuario de nivel superior que se descomponen a nivel de equipo.
Los elementos de la cartera de productos se pueden descomponer en historias de usuario específicas del equipo. Por lo tanto, tanto el equipo de iOS como el de Android tendrán una historia de usuario para crear una nueva nota que alimenta el elemento de la cartera de productos de "crear una nueva tarea".
Y de vuelta al equipo del servidor, también impulsa las historias de usuario del equipo del servidor desde el mismo elemento de trabajo pendiente. Por lo tanto, imprimir en la nube requeriría el trabajo del servidor, por lo que cuando Evernote comenzó eso, agregaron las pruebas de aceptación para respaldar eso y estas se descompondrán para el equipo del servidor como historias de usuario.
Al mantener alineada la cartera de pedidos de su producto, termina con menos desviación del producto (algunas aplicaciones de computadora son totalmente diferentes entre una Mac y una PC) y también tiende a reducir la carga en los equipos de soporte, ya que sabrán que tienen que apoyar a más de un grupo. . Sentiría pena por el equipo del servidor de Evernote si se les pidiera que admitieran iOS y luego, seis meses después, Android y construyeron la impresión en la nube para codificarla en iOS, el doble de trabajo.
No, aunque es común verlo.
De hecho, diría que dividir su equipo entre Android/ios probablemente tampoco sea una buena idea.
Aquí está mi razonamiento.
Tienes un producto, la aplicación. Las historias de usuario deben escribirse desde la perspectiva del usuario, no desde una perspectiva técnica. es decir, tendrías:
"Como usuario, quiero la función X para poder lograr el objetivo Y"
no
"Como programador que trabaja en la plataforma Z, necesito la API para exponer la función X, de modo que pueda implementar la función X en la plataforma Z"
El equipo de scrum puede dividir la Característica X en tareas
etc.
cuando todos están completos, se entrega la historia de usuario
Si tiene tres equipos, el equipo de API terminará con dos solicitudes de funciones potencialmente conflictivas del equipo de ios y android para implementar una API que diseñaron de forma independiente.
Esto lleva a :
Ewan
Serguéi Kudryavtsev
Serguéi Kudryavtsev
Ewan
Serguéi Kudryavtsev