🔦 🍷 🤦🏻 Cómo trabajar eficazmente con problemas en GitHub 🐎 🚶 👃

Los tickets en GitHub son diferentes: solicitudes para la implementación de algunas características, informes de errores, quejas de los clientes, alertas de los sistemas de seguridad, retrospectivas para el equipo, etc. Aquí vemos cómo el equipo puede usarlas y analizarlas.

Contenido:

¿Qué es un boleto?

Para muchos equipos, "boleto" es un término genérico que puede significar:

Solicitud de implementación de características.
Reporte de error.
Queja de un cliente.
Alerta de seguridad.
Retrospectiva para el equipo.

¿Público o privado?

Para proyectos, puede crear tickets públicos y privados. Público, por regla general, está destinado a usuarios, clientes, agentes, etc. Privado: para desarrolladores, contratistas, socios, etc.

Para entradas publicas

Centrarse en el resultado final.
Enfatice lo que se puede hacer.
No publique información confidencial.

Para entradas privadas

Céntrate en los detalles.
Destaque la información de investigación, ya que ayuda a identificar posibles patrones entre diferentes tickets.
Agregue información confidencial según sea necesario.

Clasificación

Todos los tickets deben evaluarse de tal manera que puedan compararse entre sí y comprender exactamente en qué se debe trabajar. Existen diferentes formas de evaluar, y en la práctica, las siguientes funcionan bien.

Calificación de prioridad

Ejemplo : Prioridad 1 (hacer primero), Prioridad 2 (hacer segundo), Prioridad 3 (hacer tercero), etc.
Analogía : una lista de tareas en la que la Prioridad 1 es la máxima prioridad.
: , . , .
: 0 (P0), , .

: 1 ( ) 5 ( ).
: - 1 (), 2 (), 3 (), 4 (), 5 ().
: . . , .
: 0 () 5 (). , .

: 1 ( ) 10 ( ).
: 1 ( ) 10 ( ).
: . . . , .

: — «», «», «».
: .
: , .

MoSCoW

: MoSCoW — «must», «should», «could», «won't». « », «», « », « ».
: , , - : « » « ».
: . .

: «would» «won't», , , «would» , , - : « , ...».

: « 1 %» , 1 % , « 100 %» — .
Analogía : la frecuencia de ocurrencia de algo o repetición durante un período determinado o en la muestra en cuestión.
Ventajas : le permite evaluar con qué frecuencia ocurre el problema. Se puede convertir a calificaciones como "20 veces al día". Puede resumir en forma de "siempre", "a menudo", "a veces", "rara vez", "nunca". Se puede expresar como un porcentaje: "el 80% de los casos están afectados".

Calificación acumulativa

Ejemplo : evaluación del ticket mediante una combinación de prioridad, influencia, daño, tamaño, MoSCoW y frecuencia.

Supongamos que un cliente importante llega a la oficina para firmar un acuerdo dentro de una hora, y el equipo de ventas encuentra un error tipográfico en el nombre de la empresa del cliente en el sitio.

Los vendedores primero establecen el ticket Prioridad 1.
1 ( ), .
3 (), .
«» , .
MoSCoW « », .
2 %, 2 % .

Aquí hay ejemplos de discusión de calificaciones de boletos.

- Por lo general, además del peligro, la frecuencia también se evalúa de forma independiente. Si es poco probable que ocurra el error durante el uso normal, incluso con un alto riesgo, se puede reducir la prioridad. Así es como se gestionan los riesgos.

- Un desarrollador o probador puede evaluar bien el peligro de un error, pero no sabe si todos los usuarios o solo algunos de ellos enfrentarán este problema. La frecuencia es otra dimensión. La prioridad se puede calcular multiplicando el peligro por la frecuencia.

- El formulario debe ser el siguiente: peligro * frecuencia - facilidad de solución = prioridad. Si alguno de los miembros de la ecuación cambia (por ejemplo, se encuentra una nueva solución, o resulta que casi nadie va a la página web que cae), entonces se ajustará la prioridad. Solo hay un peligro sin "estimar el número de personas que afectará" y "¿cuánto les afectará?" Se ve solo una parte de la imagen.

- El ingeniero de control de calidad durante la investigación inicial identificó el peligro basándose en criterios técnicos. Este es solo uno de los factores que utiliza el especialista del producto para determinar la prioridad, que a partir de este momento se convierte en un parámetro clave.

- Para algunos usuarios, el programa a veces falla, pierden todo el trabajo realizado y están muy enojados. Asignan el mayor peligro al boleto. Pero si solo una persona encuentra un problema, y esto sucede periódicamente, y el usuario ya se ha adaptado para ahorrar más a menudo, entonces el tecnólogo del producto debería darle una menor prioridad al ticket.

- El peligro caracteriza la percepción de un problema por parte de una persona: si lo encuentra en un caso determinado, evaluará el peligro como máximo. La prioridad describe cómo el equipo de gestión del proyecto percibe un error: los errores que informan los reclamantes más valiosos: los clientes que aportan mucho dinero, un director que tiene dificultades, etc. reciben un valor más alto. No utilice el peligro de errores para evaluar la prioridad, porque están interconectados indirectamente .

- La experiencia de usar prioridad y peligro sugiere que en teoría puede haber una diferencia entre ellos, pero en realidad la mayoría no lo ve. Estos términos se confunden tan a menudo que se vuelven inseparables.

- El sistema de seguimiento de errores interno de Google maneja tanto la prioridad como el peligro. P0 S0 es la tarea más urgente, P2 S2 es el estándar, P4 S4 es la menos urgente. Esta es una broma de servicio que dice que el peligro no tiene sentido (porque de hecho no difiere de la prioridad).

- Usamos solo prioridad. El probador asigna un valor inicial basado en la heurística (por ejemplo, caídas - P1, mejoras cosméticas - P5). El desarrollador se centra en este valor para seleccionar los errores con los que necesita comenzar a trabajar primero. Y luego la prioridad se ajusta de acuerdo con la experiencia del usuario y el comportamiento de la aplicación. Si realmente necesitamos ver qué valores establece el probador, entonces usamos la función "historial" o "revisión" en nuestra aplicación para rastrear errores.

Plantilla de entradas

La plantilla ayudará a su equipo a cubrir de manera efectiva y completa temas importantes.

Puede usar:

El principal reclamante: una descripción general del problema dada por la persona que lo ha encontrado.
Participantes: quién está involucrado en la situación: usuarios, empleados, socios, personas específicas, etc.
Síntomas: signos obvios de un problema: opiniones de los usuarios, disparadores, alertas, etc.
Historia: información secundaria relevante a la situación: casos similares, informes, enlaces, etc.
Diagnóstico: lo que sucede debajo del capó: las causas subyacentes o la cadena de causas, etc.
Pronóstico: evaluación de posibles consecuencias, cambios, etc.
Fracturas: pérdida de información, bloqueo de aplicaciones, proceso bloqueado, etc.
Tratamiento: qué hacemos para mejorar la situación: procedimientos, listas de tareas, restricciones, etc.

Archivo de plantilla de autor: TEMPLATE.md

Lanzamiento post mortem

El lanzamiento de mensajes post mortem le dirá al equipo cuándo lidiar con la situación.

Puedes ejecutar el análisis:

Con cualquier problema notable para el usuario, como fallas o errores inesperados.
En caso de cualquier intervención previa solicitud, por ejemplo, por ingenieros o gerencia.
En cualquier investigación de incidentes, ya que esto refleja la necesidad de monitoreo.
En el caso de solicitudes de partes interesadas para realizar revisiones, auditorías o reducir las consecuencias de los incidentes.

Post mortem inocente

Con una autopsia inocente, vale la pena centrarse en los síntomas, las causas y el tratamiento, en lugar de culpar a alguien. Dichas revisiones comienzan con la confirmación de que todos tienen buenas intenciones, que todo lo posible se hizo utilizando la información disponible en ese momento.

Cómo trabajar eficazmente con problemas en GitHub