2009-08-25 30 views
10

Al planificar y priorizar lo que se debe incluir en un lanzamiento, ¿distingue entre errores, mejoras de características y nuevas características?Errores frente a la mejora frente a la nueva función

Por ejemplo, no siempre tienen prioridad errores - se puede arreglar todos los errores conocidos antes de trabajar en nuevas características? ¿Usas un sistema formal para comparar el costo versus el valor de cada cambio en tu backlog? Y si es así, ¿se comparan errores y características con la misma fórmula? ¿Es esto diferente para software comercial vs. software corporativo de código abierto vs.

EDIT: Algunas buenas respuestas, gracias. Si bien tenía una opinión preconcebida de que necesita tratar los errores, las características, las mejoras de todos modos, y simplemente seleccionar el trabajo según el costo/beneficio de cada uno, creo que la realidad es que esto depende de su situación.

Respuesta

19

Esta elección se llama triaje, un término de los servicios de urgencias en los hospitales en los que tienen que decidir a quién se trata (y, a veces, por desgracia, que vive y muere).

Como con todas las decisiones comerciales, es un problema de costo/beneficio. ¿Cuál es el beneficio de corregir un error o agregar una característica? ¿Cuánto costará (incluido el costo de oportunidad de no hacer otra cosa)?

Elija los que tienen el mayor beneficio al menor costo. Lo que pretendes es el máximo beneficio por acción. Los recursos son limitados, los deseos no lo son, el problema perenne del capitalismo :-)

No tiene sentido solucionar un error experimentado por un solo cliente que nunca va a lanzar más negocios repetitivos a su manera si eso significa una característica que venderá cientos de copias se elimina mientras tanto.

Por lo que vale la pena, nuestra empresa cuenta con una base de datos de los cambios solicitados en donde los clientes, básicamente, pueden votar por lo que quieren ver en las próximas versiones de nuestros productos. La creación real de estos cambios solicitados en esa base de datos está limitada a la fuerza de ventas, ya que no queremos que todo tipo de solicitudes se muestren sin ser evaluadas y discutidas al menos un poco con los clientes.

Además, regularmente nos acercamos a nuestros clientes más importantes (en términos de ingresos generados) con la lista para descubrir qué características se deben agregar (son libres de sugerir sus propios deseos, que también se ingresan en la base de datos - obviamente, el poder de voto depende un poco de los ingresos).

Esto es bastante separada de nuestro sistema de fallos, aunque muy a menudo insectos son criados que en realidad son nuevas peticiones de características, y son enviados a través de la nueva base de características. Es posible que esto incluso ocurra con errores reales que se consideran de bajo impacto o que tienen soluciones provisionales adecuadas.

+2

Estoy de acuerdo con todo lo que dices ... salvo que tengas en cuenta tu última oración. Si ese cliente para quien no soluciona el error comienza a hablarle a la gente sobre usted, puede comenzar a perder negocios. – Martin

+1

Ese es un buen punto (y es parte del costo potencial de no solucionar un error). – paxdiablo

+0

Dejaré que la comunidad elija la "respuesta seleccionada". –

2

me gusta pensar que las correcciones de errores siempre debe venir antes de mejoras y nuevas características, en todos los casos. Incluso si el error en particular no te molesta demasiado como desarrollador, alguien en algún lugar está arruinando su día cuando aparece tu pequeño error.

+3

No estoy de acuerdo ... un error que ocurre una vez al día con una solución de 30 segundos en comparación con una mejora que ahorrará 2 horas de trabajo a la semana? – Martin

3

Siempre nos fijamos en el costo de corregir el error en comparación con los problemas causados ​​por él. A veces, simplemente no vale la pena tener todos los errores correctamente triaged, raíz causada, y luego corregidos.

Un montón de veces que un realce particular, o una nueva característica está siendo financiado o al menos muy recomendable que se produzca por un gran buen cliente /, por lo que también afecta a las cosas.

1

distinguir, sí.

errores tienen prioridad, sí.

todos los errores críticos/anteriores prioritarios y superiores primero, sí.

sí, la regla 80/20.

no, los errores y las características deben tratarse de manera diferente porque tienen una ponderación diferente.

sí, todas las aplicaciones comerciales, de código abierto y domésticas tienen su propia forma de hacer las cosas.

Como ejemplo, FogBugz usa programación basada en evidencias y es la única administración/rastreador que conozco que usa esa fórmula.

Espero que ayude!

4

Preguntamos a nuestros usuarios. Tenemos un producto de nicho y una pequeña base de usuarios.

En serio, el grupo de usuarios está pagando mantenimiento, o pensando en comprar.

Entonces les preguntamos qué les gustaría.

Sugieren correcciones, solicite nuevas funciones.

Les decimos acerca de la hoja de ruta de desarrollo: porque tenemos cosas que queremos hacer para el producto, debido a que los tiempos cambian, ideas de diseño. Cambios a las regulaciones.

Y si cada cliente dice "realmente necesitamos la función X": entonces vendrá después.

Si dicen "ustedes necesitan arreglar el error donde hago clic allí y no funciona bla": entonces ese error se soluciona.

Software comercial: con los clientes votando por los cambios. Por supuesto, tomamos sus decisiones sobre asesoramiento: la compañía tiene otras cosas que están pensando.

1

Tienes que mirarlo desde el punto de vista de cuál es el error. Un error show-stopper es siempre la prioridad número uno. Si las personas no pueden iniciar sesión o no se pueden ingresar o ajustar datos críticos, etc., eso debe tener prioridad sobre casi todo.

Se pueden solucionar errores de menor importancia según sea necesario. Podemos retrasar la reparación de un error porque sabemos que estamos trabajando en esa sección para una mejora la próxima semana. Entonces la corrección de errores irá con la mejora. Podemos retrasar la reparación de un error si es menor y una mejora planificada reemplazará el código por completo en breve. Una mejora importante podría tomar precendencia sobre corregir algunos errores tipográficos en la interfaz. Un cliente puede decirnos que este otro proyecto es más crítico y hacerlo antes de corregir el error (nuestro software es altamente personalizado por el cliente). Todo depende del efecto del error y los planes existentes y las políticas corporativas una vez que haya pasado el tope de la demostración. Un error que está molestando a un cliente importante puede tener mayor prioridad, incluso si parece menor para el desarrollador. Si el CEO quiere que se solucione ahora, no importa cuán poco importante parezca en comparación con el resto de la carga de trabajo, ahora se soluciona.

0

Para los errores, es bastante simple: si va a arreglarlo, corríjalo antes de escribir más código. ¿Por qué? Cuantos más códigos agregues, más difícil será encontrar el error existente.

Si está de acuerdo con la idea de que el error nunca se corrija, apúntelo y agregue características.

0

Bugs? No tenemos errores. Son características no documentadas.

Para nosotros, la elección siempre se basa en decisiones comerciales y como desarrollador no tengo más información que ofrecer mi opinión sobre lo que debería ser la máxima prioridad. En la mayoría de los casos, las características se aprovechan de los errores porque agrega funciones al área comercial, como se está progresando y los errores que pude haber solucionado hace un año siguen existiendo porque la parte comercial solo quiere ver el "progreso". El triage es excelente si está permitido, pero con demasiada frecuencia en el entorno corporativo, se trata de resultados visibles, no de funcionalidad.

0

Una cosa no menciona hasta ahora la gravedad del error. Si el error tiene una gran gravedad (como crash, no puede pasar la prueba de duración, y seguramente depende del tipo de aplicación que tenga), definitivamente debe solucionarlo antes de agregar una nueva función.

Cuestiones relacionadas