Proceso de desarrollo transparente en el equipo

Share:

Los equipos de desarrollo dedican años a crear un proceso de gestión y desarrollo eficaz en sus proyectos. Después de numerosos comentarios agradables de nuestros clientes sobre nuestro estilo de trabajo, nos dimos cuenta de que es nuestra fortaleza y decidimos compartir cómo organizamos procesos transparentes de comunicación y desarrollo en el equipo.

Las mayores dudas de los propietarios de productos que quieren contratar un equipo dedicado a su proyecto son:

  • La capacidad de obtener un control total del proceso
  • Confianza
  • Tiempo de respuesta
  • Calidad de trabajo

Para dejar de lado todas estas dudas, programamos una llamada de presentación donde discutimos los próximos pasos de la futura colaboración.

Trabajo Iterativo

El enfoque iterativo significa trabajar en ciclos cortos y entregar nuevas funcionalidades al final de cada iteración. El flujo de trabajo se repite y los pasos generales pueden ser:

  1. Reuniones de planificación
  2. Implementación (incluye revisión y prueba de código)
  3. Entrega
  4. Reunión retrospectiva.

El enfoque iterativo nos ayuda a ofrecer funciones justo cuando están listas, recopilar comentarios de los usuarios y analizar métricas para ver cómo su trabajo influye en el crecimiento del producto. A continuación, describiremos cómo hacerlo transparente.

Reuniones de planificación

Junto con los clientes, discutimos los resultados que quieren lograr, los problemas con las soluciones actuales y las características que planeamos implementar.

En las reuniones de planificación, establecemos el objetivo principal de la aplicación y las funciones que deben implementarse primero. Además, analizamos las métricas que recopilaremos para ver cómo nuestro trabajo influye en el crecimiento del producto. Estos datos ayudan a analizar nuestro trabajo y decidir cuáles son los siguientes pasos.

Implementación

Organizamos nuestro proceso de gestión de tareas utilizando tableros Kanban. El objetivo de dichos tableros es dejar claro el flujo de trabajo general y el progreso para usted y su equipo. Puedes usar Trello, ClickUp, Jira, Asana o Pivotal para visualizar la metodología Kanban. La elección depende del tamaño del equipo o de la complejidad del proyecto.

Tableros Kanban

En general, los tableros Kanban consisten en columnas que representan una determinada etapa en el proceso de desarrollo y tarjetas, donde cada tarjeta es una tarea separada. Se pueden organizar de diferentes maneras. Organizamos el flujo de trabajo en 6 columnas:

  • “To-do”. Aquí ponemos todas las tareas que hemos planeado para la iteración actual. Cuando comenzamos una iteración, los desarrolladores toman una tarea que van a realizar, se asignan a la tarea y la mueven a la siguiente columna.
  • “In Progress”. La tarjeta permanece en esta columna todo el tiempo que un desarrollador trabaja en ella. Cada tarea en esta columna contiene miembros (personas que la realizan), por lo que es fácil para un cliente ver quién puede responder preguntas relacionadas con esta tarea.
  • “Code Review”. Usamos GitHub como un sistema de control de versiones y un proceso de revisión claro. Los desarrolladores abren solicitudes de incorporación de cambios, donde otros compañeros de equipo pueden revisar y comentar los cambios en el código. Cuando se aprueban los cambios, la solicitud de incorporación de cambios se fusiona y se entrega automáticamente a la preparación.
  • “Testing”. Configuramos entornos de prueba y autoimplementación, de modo que tan pronto como se revise y fusione una función, podrá probarla.
  • La columna “Done” contiene tareas que están probadas y listas para ser entregadas a producción.
  • “Backlock”. Esta lista contiene tareas que se planean desarrollar en un producto pero que no están incluidas en la iteración actual.

Cada tarjeta se mueve de columna en columna hasta que llega a la etapa llamada “Done”.

Sugerimos crear tarjetas para cada tarea y nombrarlas en formato de historia de usuario. El formato de historia de usuario le permite omitir la escritura de una especificación de producto larga y muestra la funcionalidad deseada en un par de oraciones. Un formato clásico de historia de usuario es:

Como <actor>, cuando <acción> entonces <resultado esperado>

Pero se puede cambiar si cada lado acepta un formato diferente y entiende claramente la descripción.

Es una buena práctica dejar notas y comentarios debajo de cada tarea. Como no requerimos una especificación detallada, aclaramos los detalles de las tareas en la planificación de reuniones primero y en los comentarios después. Allí también discutimos formas de resolver tareas o problemas que enfrentamos para proporcionar un proceso de desarrollo transparente.

Dividimos las tareas en tareas más pequeñas si lleva más de 1 día implementarlas. Para el seguimiento del progreso por hora, desglosamos las tareas con listas de verificación.

Como puede ver, los tableros Kanban son una forma transparente de monitorear el progreso en tiempo real y descubrir cuellos de botella, si los hay.

Comunicación diaria

Trabajar en equipo significa comunicación diaria por lo que le prestamos mucha atención. Creamos un chat para todos los miembros del equipo, incluidos diseñadores, desarrolladores y clientes. Todos participan en discusiones en chats y comentarios, hacen preguntas si algo no está claro, comparten actualizaciones y noticias.

No escondemos nuestro equipo. Además, fomentamos las discusiones entre ingenieros y clientes (propietarios de productos). Todo el equipo ahorra una cantidad significativa de tiempo al tener la capacidad de discutir cosas entre ellos sin malas interpretaciones.

Chats públicos

Usamos canales públicos en lugar de mensajes directos porque los mensajes directos pueden provocar una falta de comunicación y pueden dejar a un cliente en la oscuridad. Puede sonar extraño para algunos equipos, pero no tenemos miedo de mostrar problemas a los clientes si los tenemos (todo el mundo los tiene :)).

Slack funciona perfectamente para tales necesidades. Sugerimos crear diferentes canales dentro del espacio de trabajo: #general, #dev, #product, #standups, #random. Cada canal puede tener su propio propósito. Mira cómo lo organizamos:

  • #general. Utilizamos este canal para saludos, desde el cual se le informa quien y cuando esta disponible. Publicamos resultados retro y consultas generales aquí.
  • #dev: este canal se crea para discusiones técnicas de bajo nivel. Los clientes generalmente silencian las notificaciones desde allí, pero aún pueden ver todas las discusiones si así lo desean.
  • #producto: aquí discutimos requisitos de alto nivel como preguntas relacionadas con el producto, estrategia, competidores, características y errores.
  • #standups: utilizamos un canal separado para los informes de standup generados por chatbots, recordatorios automáticos sobre el tiempo de standup y la discusión de standups.
  • #random: este es un chat más divertido para discusiones, memes y bromas que no son de proyectos.

Los chatbots que usamos para standups se pueden configurar para una hora determinada del día con preguntas especiales. A partir de los standups, puede aprender cómo se sienten los compañeros de equipo y qué es lo que están enfocando en este momento.

En nuestro equipo, siempre escribimos los resultados y los puntos importantes en los chats después de las discusiones fuera de línea o las videollamadas para que todos estén informados sobre los cambios. También es una buena práctica guardar estas notas en algún lugar para volver a ellas más tarde o consultarlas.

Integraciones con otras herramientas

Es conveniente monitorear los cambios en todos los servicios y ver las notificaciones en un solo lugar. Para ello configuramos integraciones entre Slack, Trello, GitHub y otras herramientas.

Los famosos “Zooms” (Videollamadas)

Trabajamos de forma remota con los clientes y sabemos lo difícil que es generar confianza cuando nunca se ha conocido en persona. Intentamos tener videollamadas al menos una vez a la semana, prender cámaras y demostrar que somos personas reales ????

Tanto los propietarios de productos como los desarrolladores se benefician de las videollamadas. Los clientes aprenden más sobre el equipo de desarrollo, mientras que los desarrolladores sienten que son parte del negocio del cliente. Además, la interacción cara a cara es más atractiva que el audio. Ayuda a generar confianza y relaciones más sólidas. Para tales reuniones, usamos Zoom o Skype.

Entrega

Preferimos automatizar todo lo que se pueda automatizar. Entregamos funciones con frecuencia tan pronto como están listas y no dedicamos tiempo a implementarlas a mano.

Hemos implementado la Integración Continua (CI) para garantizar que el código no tenga conflictos. CI ejecuta todas las pruebas necesarias y verifica el código automáticamente. Ayuda a encontrar errores y fallos y a mantener limpio el código.

Al adoptar la Entrega e Implementación Continuas, podemos publicar nuestro trabajo en la etapa de pruebas y los servidores automáticamente. Es útil tanto para los desarrolladores como para los clientes porque obtienen funciones más rápido y ven los cambios de forma interactiva.

Reuniones retrospectivas

Siempre pensamos en cómo mejorar nuestro trabajo. Para estas necesidades, tenemos retrospectivas semanales/quincenales. En retrospectivas, discutimos las siguientes preguntas:

  • Qué salió bien
  • Lo que necesitamos mejorar

Durante estas llamadas, analizamos nuestro trabajo anterior decidiendo qué haremos de la misma manera y cómo arreglar las cosas que no nos gustan. Recopilamos comentarios de todos los miembros del equipo para tener la oportunidad de mejorar nuestro trabajo.

Además, analizamos la eficacia con la que los miembros de nuestro equipo emplean su tiempo. En nuestro equipo, los desarrolladores y gerentes registran su tiempo en Toggl. Lo hacen para cada tarea en la que están trabajando. Luego enviamos informes detallados a nuestros clientes. Basándonos en las estadísticas de Toggl, podemos medir si usamos nuestros recursos de manera eficiente.

Creemos que la retrospectiva honesta es una de las partes más importantes del desarrollo de productos.

Los puntos clave del proceso de desarrollo transparente

En esta publicación, compartimos el enfoque habitual que permite que un equipo de desarrollo de productos sea transparente con los clientes. Los puntos clave de este proceso son:

  • Planifique cada semana y mida el progreso para mantenerse efectivo y no perder el enfoque.
  • Utilice tableros Kanban para una gestión de tareas transparente.
  • Use solo chats públicos y no oculte nada a los clientes
  • Inicie videollamadas para involucrar a todos los compañeros de equipo. Construyen un ambiente de confianza en el equipo.
  • Automatice las tareas rutinarias y use bots para verificar el código.

Deja un comentario