Muchos productos se desarrollan para una necesidad específica o se construyen para probar si una idea funciona, o simplemente se trata de un enfoque de "construirlo y ellos vendrán". La primera vez que se construye un MVP (Producto Mínimo Viable), no se tiene tiempo para pensar en la escalabilidad o en cómo trabajar con características y funcionalidades más complejas. En todos los casos, un proceso de desarrollo de producto ágil estandarizado y transparente es una buena idea para seguir, con el fin de obtener resultados predecibles.
Para mantener y mejorar continuamente un producto, contar con un proceso para manejar las solicitudes, así como las correcciones de errores, ayudará a llevar a cabo las cosas y liberarlas.
Nuestro proceso de desarrollo de producto comienza en la etapa de la idea.
Esta etapa captura todas las ideas de cualquier persona en la empresa. Estas pueden ser ideas breves o ideas grandes que se discuten en reuniones de ideas o de brainstorming. Dado que todos pueden crear estas ideas, también es una forma de mantener abierta el desarrollo del producto. Cómo se pasa de esta etapa depende, tal vez sea por votación o simplemente por calificaciones del Product Owner.
Normalmente todas las solicitudes llegan aquí; errores, cambios, nuevas características. Es el carril de captura para todo lo que empleados o líderes quieren que se haga. Un problema bien capturado contiene una captura de pantalla, una breve descripción y una URL. La persona detrás de las solicitudes se llama Reporter, y es quien defiende el ticket a lo largo del proceso.
Solo los tickets que han pasado, se entienden bien y se han revisado pueden llegar a esta etapa, y solo pueden ser movidos por el Product Owner, o quien tenga el rol. Una vez movidos, se priorizan de arriba hacia abajo. Los desarrolladores elegirán de la parte superior hasta donde puedan, sin embargo, ellos deciden cómo trabajarán en ellos (otro gran motivador). Nadie, excepto el Product Owner, puede re-priorizar o mover cosas a esta etapa. Vale la pena repetirlo.
Desde esta etapa, los desarrolladores son responsables de mover el ticket a "Hecho". Esto ayuda con todo el proceso, ya que el desarrollador lo adaptará y hará que avance como él desea que se haga. Por lo tanto, no hay reasignaciones. El desarrollador líder que recogió el ticket es el encargado. Varios desarrolladores pueden trabajar en el mismo ticket, pero el asignado nunca cambia. Los desarrolladores comparten información con el resto del equipo todos los días en forma de una reunión de stand-up y responden a las tres preguntas del scrum: 1) ¿Qué he hecho hasta hoy? 2) ¿Qué haré hasta mañana y 3) ¿Tengo algún problema que necesite ayuda?
Si un desarrollador no puede avanzar, el ticket se mueve a la etapa Bloqueada. Puede haber contenido faltante, necesidad de esperar a un Reporter o la solución no se ha encontrado. Colocar algo en la etapa Bloqueada en un proyecto Kanban significa que algo no está moviéndose como debería y debería ser atendido.
Una vez que un ticket se fusiona con un entorno de staging o de pruebas, se invita al Reporter a ayudar a probarlo. Por supuesto, se pre-prueba por el desarrollador antes, como debería ser el comportamiento predeterminado de cualquier desarrollador. Personalmente, no quiero alejar la responsabilidad del desarrollador a un equipo de QA, lo cual lleva más tiempo. Pero para algunas pruebas más grandes y complejas, podría ser necesario y más rápido. También se realizan pruebas automatizadas.
Una vez que algo se fusiona con la rama principal y, por lo tanto, se libera a producción, se marca como Hecho. Esta es una definición clara de "Hecho".
¡Wow, acabas de describir un proyecto de la vieja escuela! Aguarda un momento, lo que tenemos aquí permite que las ideas/tickets individuales se muevan a través del proceso de forma independiente de las demás. Esa es la principal diferencia. Además, podemos mover hacia adelante y hacia atrás en cualquier momento por cualquier razón válida. Esto no se puede comparar con el proyecto de cascada con todas sus dependencias y problemas de pruebas.
Ayudamos a las empresas con su tecnología, proporcionando servicios de CTO y gestión de productos. Confiados en nuestros servicios de CTO, trabajamos con tanto startups como empresas establecidas en los países nórdicos, Suiza y EE. UU.
Somos una Compañía Suiza (LLC) con sede en 
Suiza.