¿Los proyectos Agile utilizan informes abreviados de defectos? [cerrado]

7

Estoy acostumbrado a la notificación de defectos relativamente rígida, algo como esto.

Steps to reproduce:
1. Access customer manager for user Test01
2. Check "User must change password" and click Apply
3. Access login page
4. Enter user name and password
5. Click Login

Expected results:
6. Site displays user profile page (see use case 21.1.2)

Actual results:
6. Site displays error page (see attached screen shot)

Recientemente me uní a un proyecto Agile donde los informes de defectos se parecen más a esto:

Can't sign on with user Test01, see screenshots

En mis muchos años de experiencia en desarrollo, he encontrado que los informes de defectos más largos tienen varios propósitos, por ejemplo. comunicó de manera sucinta el problema preciso y evita cualquier tipo de lenguaje crítico, y representa claramente el defecto como una desviación de un comportamiento requerido, en lugar de permitir que el ingeniero de control de calidad compense defectos por comportamientos que "parezcan" incorrectos.

La metodología ágil subestima la importancia de la documentación. En su lugar, se nos anima a levantar el teléfono y hablar con los demás.

¿Es esta una aplicación válida de los principios ágiles? ¿O deberían ser los informes de defectos bastante detallados incluso cuando intentamos ser ágiles?

    
pregunta John Wu 23.09.2014 - 17:02

6 respuestas

10

Si alentar a las personas a que se interrumpan entre sí con frecuencia debido a la simple pereza se considera Ágil, entonces debo admitir que mi comprensión de Ágil está gravemente dañada.

Una descripción suficiente del problema no es una documentación del producto (potencialmente superflua), sino que es una colección distinta de todos los hechos necesarios para eficientemente reproducir y resolver el problema.

Si la descripción en cualquier forma es suficiente, está bien. Si ese no es el caso, ciérrelo como " No es reproducible, vuelva a abrirlo si hay nueva información disponible " - con una excepción: si siente la necesidad de investigar debido a los riesgos potenciales descubiertos por el problema, Puede considerar morder la bala y el seguimiento. No quieres (por ejemplo) un problema de seguridad que no se haya solucionado solo por una mala descripción.

    
respondido por el JensG 23.09.2014 - 17:39
6

"Ágil" no significa que no tenga reglas y procesos, solo que debe intentar arreglárselas lo menos posible (pero no menos, parafrasear la cita de Einstein). El Manifiesto Agile expresa esto como "Individuos e interacciones sobre procesos y herramientas".

En su caso, eso significa que debe discutir esto con sus colegas. Explique los beneficios que ve al tener informes de errores más estructurados e intente encontrar una solución con la que todos puedan trabajar.

Tal vez algunos de sus colegas tienen buenas razones para no querer exigir informes más estructurados (por ejemplo, no asustar a los usuarios que quieren informar de errores, o porque encontraron que la estructura nunca tuvo sentido), o quizás simplemente nunca lo había pensado. Solo lo descubrirás preguntando :-).

    
respondido por el sleske 24.09.2014 - 10:36
2

Es importante recordar que Agile no es un conjunto de reglas estrictas, sino una mentalidad de mejora de procesos. Como Dave Thomas ha señalado, agile es un adjetivo, no un sustantivo. Por definición, no puedes hacer ágil, solo puedes ser ágil.

Entonces, la forma en que un equipo ágil maneja los informes de errores se debe basar en la forma más efectiva que el equipo ha descubierto que ayuda a entregar un software funcional. Esto podría ser diferente para diferentes equipos dependiendo del contexto en el que trabajen. Si el proceso que está utilizando no funciona para usted, cámbielo. Si ves una forma en que podría ser mejor, cámbiala. (Si no se puede cambiar, no eres ágil)

Lo que hay que hacer sería averiguar por qué es así. Otras respuestas aquí han propuesto posibles explicaciones. Hable con su líder técnico o con el líder de su equipo y pregunte cómo llegaron al proceso actual. Haz sugerencias sobre cómo mejorar el proceso.

    
respondido por el epotter 24.09.2014 - 15:15
2

Los informes de errores de los usuarios siempre parecen seguir esta plantilla:

  

No puedo {acción aquí} cuando {otra acción aquí}

O

  

Cuando {action here} no funciona

No hay mucho que puedas hacer al respecto. Sin embargo, independientemente de su metodología de desarrollo, obtener este tipo de informes de errores de los evaluadores de control de calidad es absolutamente inaceptable . Cuando el control de calidad envía un informe de errores a mi manera con esa poca información, los reprocho para que me den los pasos para reproducirme y establezca claramente qué salió mal y qué debería estar pasando.

Si el control de calidad solo puede proporcionarle un informe de error en uno de los formatos anteriores, eso significa que el evaluador de control de calidad puede necesitar la ayuda de un desarrollador para eliminar el problema, o si el probador es nuevo Al proyecto y no familiarizados con las reglas de negocio. Esto es aceptable, pero no hasta después de la diligencia debida del evaluador .

Puede animar a los usuarios a que le den informes de errores más detallados, pero sepa que probablemente obtendrá poca información. Cuando eso ocurra, haga que el control de calidad revise el error para ver si se puede reproducir o póngase en contacto con el cliente y programe un recorrido.

    
respondido por el Greg Burghardt 24.09.2014 - 14:42
1

No hay reglas en Agile que digan que debe tener informes abreviados de errores: el tipo de informes de errores está controlado por lo que mejor funcione para su equipo u organización. Si los informes abreviados funcionan para todos, eso es ágil. Si los informes de errores complejos funcionan mejor, eso también es ágil.

Agile está capacitando al equipo para hacer lo que sea que les permita ser los más productivos, sin verse obligados a adherirse a un conjunto particular de reglas establecidas por alguien fuera del equipo.

    
respondido por el Bryan Oakley 24.09.2014 - 16:30
0

Ambos ejemplos podrían ser perfectamente ágiles. Todo depende de sus necesidades, su gente y la fase actual del ciclo de desarrollo. En general, he visto que los equipos de control de calidad utilizan capturas de pantalla y grabaciones como herramienta de soporte para complementar el informe de errores. ¿Por qué? Según el personal de control de calidad, obtener buenas capturas de pantalla y grabaciones no es tan fácil como escribir. También hay algunos pasos que son menos propensos a ser representados como una captura de pantalla, como cambiar las configuraciones por línea de comandos; a los desarrolladores les encantará que hayas escrito eso, así que simplemente pueden c & p it; te odiarán si solo adjuntas una captura de pantalla :)

    
respondido por el CantGetEnough 25.09.2014 - 02:05

Lea otras preguntas en las etiquetas