¿Cómo se maneja un gran backlog de producto?

Question

Tenemos una gran acumulación de cosas que debemos hacer en nuestro software, en una gran cantidad de diferentes categorías, por ejemplo:

• nuevas áreas problemáticas para nuestros productos para resolver
• Nueva funcionalidad apoyar las áreas problemáticas existentes
• Nueva funcionalidad solicitada por nuestros usuarios existentes
• usabilidad y "mirar" son las mejoras
• actualizaciones de arquitectura en el back-end
• Bug f ixes

Administrar todos estos de una manera sensata es un trabajo que recae en la administración de productos, pero es complicado por muchas razones. En primer lugar, tenemos varios sistemas diferentes que contienen las diferentes cosas (documentos de requisitos del mercado en archivos, errores en una base de datos de errores, requisitos del cliente en nuestro sistema de mesa de ayuda, lista de deseos de ingeniería en nuestra intranet, etc.). Y, en segundo lugar, muchos de los artículos son de un tamaño, alcance, complejidad y, por supuesto, muy distintos, lo que significa que elegir no es tan simple como ordenar una lista por prioridad.

Dado que ahora somos bastante grandes, tenemos un producto complejo y muchos clientes, las soluciones básicas (una hoja de cálculo, un documento de Google, una lista de tareas de basecamp) simplemente no son suficientes para solucionar esto. Necesitamos una forma de agrupar las cosas de varias maneras, priorizarlas de forma continua, dejar en claro lo que estamos haciendo y lo que está por venir, sin que esto requiera todo el tiempo de alguien solo para administrar alguna herramienta.

¿Cómo se maneja esto de una manera que le permite a la empresa hacer siempre lo que es más valioso para los clientes existentes, ayuda a obtener otros nuevos y mantiene la integridad del software en su sano juicio?

Tenga en cuenta que esto es diferente del lado del desarrollo, que creo que hemos bajado bastante bien. Desarrollamos todo de manera ágil e iterativa, y una vez que se ha elegido algo para el diseño y la implementación, podemos hacerlo. ¡Es la parte en la que necesitamos saber qué hacer más difícil!

¿Has encontrado un método o una herramienta que funcione? Si es así, por favor comparte! (Y si le gustaría saber la respuesta también, velocidad de la cuestión para que se mantenga visible :)

Adición: Por supuesto que es agradable para corregir todos los errores en primer lugar, pero en un sistema real que realmente está instalado en las máquinas de los clientes, eso no siempre es práctico. Por ejemplo, podemos tener un error que ocurre muy raramente y que tomaría una gran cantidad de tiempo y un trastorno arquitectónico para solucionarlo, podríamos dejarlo por un tiempo. O podríamos tener un error donde alguien piensa que algo es difícil de usar, y creemos que solucionarlo debería esperar a una mayor renovación de esa área. Por lo tanto, hay muchas razones por las que no solo las solucionamos de inmediato, sino que las mantenemos abiertas para que no las olvidemos. Además, es la priorización de los no bichos la más difícil; simplemente imagine que no tenemos ninguno :)

Answer 1

Administrar una gran acumulación de manera agresiva es casi siempre un desperdicio. En el momento en que llegas al medio de una pila priorizada, las cosas cambian más de las veces. Te recomiendo la adopción de algo parecido a lo Corey Ladas llama un filtro de prioridad:

http://leansoftwareengineering.com/2008/08/19/priority-filter/

Esencialmente, usted tiene un par de cubos de tamaño creciente y la prioridad decreciente. Permite que las partes interesadas los llenen, pero los obliga a ignorar el resto de las historias hasta que haya vacantes en los cubos. Muy simple pero muy efectivo.

Editar: Allan preguntó qué hacer si las tareas son de diferentes tamaños. Básicamente, una gran parte de hacer que este trabajo sea correcto es dimensionar sus tareas. Solo aplicamos esta priorización a las historias de los usuarios. Las historias de los usuarios suelen ser significativamente más pequeñas que "crear un sitio de la comunidad". Consideraría que el sitio de la comunidad mordió una épica o incluso un proyecto. Tendría que dividirse en bits significativamente más pequeños para ser priorizados.

Dicho esto, todavía puede ser un reto hacer historias de tamaño similar. A veces simplemente no puede, por lo que se comunican durante sus decisiones de planificación.

Con respecto a mover dos píxeles, muchas de estas cosas que son fáciles de hacer se pueden hacer para "libre". Solo tienes que tener cuidado de equilibrar estos y solo hacerlos si están realmente cerca de ser libres y en realidad son algo importantes.

Tratamos los errores de manera similar. Los errores obtienen una de tres categorías, ahora, pronto o eventualmente. Solucionamos los errores de Ahora y Pronto lo más rápido posible, con la única diferencia cuando publicamos las correcciones. Eventualmente, los errores no se corrigen a menos que los desarrolladores se aburran y no tengan nada que hacer, o de alguna manera se vuelven de mayor prioridad.

Answer 2

No estoy seguro si la herramienta es tan crítica como el proceso. He visto que los equipos tienen mucho éxito usando algo tan simple como fichas y pizarras blancas para administrar proyectos bastante grandes. Una cosa que recomendaría en la priorización es asegurarse de tener una lista completa de estos elementos juntos. De esta forma puede sopesar la prioridad de solucionar un problema en comparación con una nueva característica, etc.

Answer 3

Creo que debe tenerlos todos en un solo lugar para poder priorizarlos. Tener que reunir varias fuentes diferentes hace que esto sea prácticamente imposible.Una vez que tienes eso, entonces alguien/un grupo tiene que clasificar cada error, función solicitada y desarrollo deseado.

cosas que podría dar prioridad al son:

• valor añadido al producto
• importancia para los clientes, tanto existentes como potenciales
• magnitud de la tarea

Answer 4

Debe solucionar todos los errores primero y solo luego pensar en agregarle nuevas funciones.

Answer 5

Una técnica simple es usar una matriz de priorización.

Ejemplos:

• http://erc.msh.org/quality/pstools/psprior2.cfm

• http://it.toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

También útil es la cuadrantes de priorización (dos dimensiones: importancia, urgencia) que Covey propone: http://www.dkeener.com/keenstuff/priority.html. Centrarse en lo importante y urgente, luego lo importante y no urgente. Las cosas no importantes ... bueno ... si alguien quiere hacer eso en sus horas libres :-). Una variante de los cuadrantes Covey que he usado es con las dimensiones de Importancia y Facilidad. La facilidad es una buena forma de priorizar las tareas dentro de un cuadrante Covey.

Answer 6

Más allá de cualquier herramienta y proceso, debe haber algunas personas ...;)

En nuestra tienda, se le llama un release dey se determina el siguiente perímetro funcional para enviar a la producción.
Luego hay un Freeze Manager que realmente conoce el código y los archivos y errores (generalmente es uno de los programadores), y aplicará las opciones del administrador de versiones, y supervisará las fusiones necesarias para tener algo que prueba y luego suelta.

Entre ellos dos, una priorización se puede establecer, tanto a nivel alto (solicitudes funcionales) y de bajo nivel (errores y problemas técnicos)

Answer 7

Todas estas cosas podrían ser rastreados por un sistema de seguimiento de insecto bueno que tiene las siguientes características:

• posibilidad de marcar los elementos de trabajo como insectos o mejora de las solicitudes
• campo Categoría de la región de la responsabilidad de que el elemento de trabajo cae bajo (interfaz de usuario, servicios de fondo, etc.)
• Versión # fi campo para cuando está prevista la revisión o característica que se haga
• campo de estado (en curso, completada, verificada, etc)
• campo Prioridad

Answer 8

La clave es la categorización y priorización agresiva.

Soluciona los problemas que mantienen a los clientes alejados rápidamente y agrega más características para mantener a los clientes a la vanguardia.Rechace los problemas que solo afectan a un pequeño número de personas, a menos que sean muy fáciles de corregir.

Answer 9

Dado que ya está haciendo las cosas de una manera ágil, usted podría tomar algunas ideas de XP:

• poner todos sus historias en gran pila de fichas (o alguna otra herramienta)
• ahora los desarrolladores deben estimar cuán grandes o pequeñas son esas historias (aquí los desarrolladores tienen la última palabra)
• y dejar que el cliente (o su representante como gerente de productos) ordene esas historias por su valor comercial (aquí el cliente tiene la última palabra)
• y si los desarrolladores piensan que hay algo técnico que es más importante (como corregir esos molestos errores), deben comunicarlo al cliente (persona de negocios) y hacer que el cliente ascienda esa prioridad (el cliente todavía tiene la palabra final)
• seleccionar tantas historias para la próxima iteración como su equipos de velocidad permite

esta manera:

• hay una única cola de tareas, ordenadas por las necesidades del negocio
• clientes a obtener mejor retorno de su inversión
unidades de valor
• negocio de desarrollo, no en la tecnología y los chiflados
• desarrolladores llegan a decir cómo las cosas difíciles son para implementar
• si no hay ROI, la tarea permanece cerca del fondo de esa pila

Para obtener más información, consulte planificación de programación extrema por Kent Bech y Martin Fowler. Lo dicen mucho mejor de lo que puedo hacer.