¿Cuál es la diferencia entre un error o defecto de software y una solicitud, mejora o mejora de funciones?

Me gusta pensar en esta pregunta en términos de contratos. No soy un abogado, y probablemente tampoco haya nadie más involucrado en esta discusión, pero si puede preguntar “¿Hubo un contrato vigente que dijera que el software haría X? ¿Se ha violado ese contrato por alguna razón?”. Si la respuesta es sí y sí, es un error. De lo contrario, es una mejora.

Esto a menudo funciona como una explicación razonable para las personas de negocios no técnicos, ya que todos han tratado con contratos antes.

En términos de aplicar esto a situaciones reales, por supuesto, el contrato probablemente no se escribió formalmente. Pero es posible que se haya documentado algo parecido a un contrato: revise el correo electrónico, los documentos de especificaciones técnicas, los mensajes de confirmación del código fuente, los documentos de soporte para el usuario, etc. Descubrí que muchas personas tienen buenos recuerdos de este tipo de detalles, por lo que a menudo puedes entender el contrato a través de una conversación rápida.

En algunos casos, la característica en cuestión puede haber sido especificada, y acordado ser desarrollada, pero fuera de un lanzamiento antes del envío. Puede valer la pena hacer una pregunta simple: “¿Por qué no enviamos la función X?” Si la respuesta es algo así como “todos acordaron que no lo necesitábamos” o algo similar “se nos acabó el tiempo para ese lanzamiento y lo pusimos a prueba desde entonces”, entonces la característica no estaba en el contrato “final” (solo un borrador) y, por lo tanto, agregarlo ahora sería una mejora.

Y sí, solo pasa tiempo en esto si realmente importa. Por ejemplo, si el trabajo fue realizado por un contratista, a menudo aceptarán corregir errores como parte de la entrega del proyecto (por un costo bajo o sin costo adicional), mientras que necesitaría contratar a alguien para implementar la función si se considerara Una mejora. Probablemente no valga la pena la distinción para el trabajo típico de software. Más importantes son cosas como: ¿Por qué ese cliente quiere esa característica? ¿Expone un problema mayor en el producto? ¿Es probable que otros clientes estén sufriendo el mismo problema, pero simplemente no están hablando? ¿Cuánto dolerá perderlos?

La cosa debería funcionar “como se esperaba” donde lo esperado se define como funcionalidad preexistente o especificaciones de características documentadas proporcionadas dentro de la versión actual. Se debe presentar un error si lo anterior no es el caso.

Las creencias, la esperanza y la fe (BHF) no tienen lugar en el desarrollo de software, nunca.

Las “áreas grises” ocurren cuando la gente elige inyectarse sus propias opiniones sobre “cómo deberían funcionar las cosas” después de que se haya producido el lanzamiento del software objetivo. Si se crea una solicitud de función o error depende de la madurez de los procesos de desarrollo de software dentro del negocio (quizás otros factores como la cultura y / o la política).

Para trazar una línea más clara entre errores y características (solicitudes, mejoras y mejoras), los requisitos de características iniciales deben incluir la mayor cantidad de detalles posible con respecto al flujo, la forma, la función y las pruebas. Si lo hace, dejará poco espacio para BHF, aclarará las expectativas y ayudará a eliminar esas solicitudes de características disfrazadas de errores.

Clasificaría todo lo que “se puede hacer (y sabemos)” como un error (si es algo que está “roto”) o una solicitud de función (de lo contrario).
Las solicitudes de funciones pueden clasificarse como mejora (usaría esto para “esta nueva función que aún no tiene”) o mejora (“Simplemente agrandar este botón” – de alguna manera el usuario quiere mejorar una función existente )

Finalmente, ignoraría toda esta categorización por completo, porque no es muy productiva; No hay una regla que indique que los errores son más importantes para corregir que las características que se agregarán.
En su lugar, trate de evaluar cada elemento de la tarea en términos de costo y beneficio : cuánto costará completar la tarea (generalmente en términos de tiempo del desarrollador) y qué tan beneficioso es para el usuario / cliente. Entonces es más fácil priorizar.

La mala noticia es que, por lo general, ni el costo ni el beneficio se pueden estimar con un grado razonable de precisión; Pero puede esperar que los errores sean al menos algo consistentes.

En la fase de mantenimiento, realizamos o cumplimos tres tipos de requisitos de cambio:

1. Cambio adaptativo: para adaptarse con nueva tecnología o entorno para evitar la descomposición del código.
2. Cambio correctivo: para corregir errores o defectos para que funcionen correctamente.
3. Cambio de mejora: para agregar una nueva función.
4. Cambio perfecto: para mejorar la calidad y el diseño del código.

Me gusta pensar que un defecto / error es cuando los usuarios se hacen creer que hay un cierto comportamiento en el sistema, pero el sistema se comporta de manera diferente. Si bien una característica / mejora / mejora es cuando los usuarios entienden cómo se comporta el sistema pero desean que se comporte de manera diferente. Por ejemplo, si vas a un restaurante y pides un artículo en el menú y te dicen que no pueden hacer ese artículo para ti => eso es un error; si, en cambio, les pide que hagan un pedido especial que no está en el menú =>, eso es una mejora.