Tema: process
-
DACI y RACI para decisiones técnicas: una persona que aprueba, contribuyentes nombrados
DACI nombra a quien impulsa (driver) la decisión, a una única persona que aprueba y la toma, a contribuyentes que tienen voz pero no voto, y a partes informadas que conocen el resultado; RACI asigna roles de responsable, quien rinde cuentas, consultado e informado a las tareas. Cualquiera de los dos funciona para decisiones técnicas cuando los roles se escriben antes de que empiece la discusión.
-
La deuda técnica como decisión consciente con contabilidad
La metáfora de Cunningham: el código que no es del todo correcto es un crédito, y cada minuto de trabajo extra que exige es el interés. La metáfora solo funciona si la deuda se contrae de forma consciente, se anota y se evalúa con regularidad; como término genérico para todo lo que resulta feo, o como excusa para el descuido, carece de valor.
-
Escribir un informe de error útil
Un informe de error es útil cuando una persona ajena puede reproducir el fallo sin necesidad de preguntar: un título preciso, el entorno con sus versiones, pasos numerados para reproducirlo, el resultado esperado y el real por separado, el mensaje de error textual y un ejemplo lo más reducido posible. Las hipótesis sobre la causa van en una sección aparte.
-
Llevar los elementos de acción de un postmortem hasta su cierre: bugs de seguimiento, un único responsable y revisión por antigüedad
El Site Reliability Workbook advierte de que, sin un proceso formal de seguimiento, los elementos de acción de los postmortems se olvidan con frecuencia; asignar a cada elemento un bug de seguimiento, un único responsable, un tipo y una prioridad, revisar los elementos abiertos por antigüedad de forma periódica, y tratar un elemento que ha superado su fecha como una decisión que tomar y no como una línea que se puede pasar por alto.
-
Los principios ágiles como acuerdos de trabajo concretos
Los doce principios que sustentan el Manifiesto Ágil resultan útiles cuando se traducen en acuerdos de equipo verificables: cadencia de entrega, comunicación directa, ritmo sostenible, excelencia técnica y reflexión periódica.
-
Las actas de reunión con una sección de decisiones separada reducen las decisiones reabiertas
Hipótesis: los equipos cuyas actas de reunión enumeran cada decisión por separado (enunciado, opciones rechazadas, responsable, fecha) y la copian en un registro de decisiones duradero reabren con menos frecuencia cuestiones ya zanjadas que los equipos con actas narrativas, porque una decisión que puede encontrarse y citarse tiene menos probabilidad de discutirse de nuevo desde cero.
-
Tratar una solicitud de titular de datos como un proceso de ingeniería: exportar y eliminar
Tratar la solicitud de una persona de obtener una copia o la eliminación de sus datos como un trabajo: recepción verificada, un exportador por cada almacén del mapa de datos que produce un manifiesto, entrega mediante una descarga autenticada que caduca, eliminación a través del pipeline, exenciones enumeradas con códigos de motivo y una prueba con un sujeto sintético con una periodicidad fija; qué solicitudes deben atenderse y cuándo no se aborda aquí.
-
Documentación de incorporación: el camino desde una máquina nueva hasta un cambio fusionado
La documentación de incorporación es un único camino numerado que lleva a quien se incorpora, humano o agente, desde no tener nada instalado hasta un cambio fusionado usando solo lo que está escrito; cada persona nueva corrige aquello con lo que tropezó, y el camino lleva asociado un responsable y una fecha de vigencia.
-
Un calendario de cambios y ventanas de mantenimiento para un equipo de operaciones pequeño
Poner todo cambio planificado que pueda afectar a los usuarios en un único calendario compartido, con responsable, ventana, línea de reversión y reglas de bloqueo (blackout); el libro de SRE de Google afirma que SRE ha comprobado que alrededor del 70 % de las interrupciones se deben a cambios en un sistema en producción, de modo que «¿qué cambió?» es la primera pregunta en cualquier incidente, y el calendario es donde se responde.
-
Escribir un documento de diseño (RFC) sobre el que quienes revisan puedan decidir
Un documento de diseño recaba la decisión antes de que exista código: primero el problema, después los objetivos y los no objetivos, una explicación a nivel de usuario y otra a nivel de referencia, las alternativas descartadas con su justificación, las desventajas y una lista explícita de preguntas abiertas. La estructura sigue lo que exigen PEP 1, la plantilla de RFC de Rust y la práctica de documentos de diseño de Google.
-
Triaje de issues para un proyecto pequeño: un conjunto fijo de etiquetas y una pasada regular
Hacer triaje significa decidir, para cada issue nueva, qué es, si es accionable y quién actúa a continuación. Un vocabulario de etiquetas pequeño en tres familias (tipo, estado, área) más una pasada breve a un ritmo fijo mantiene honesto el tracker; las etiquetas por defecto de GitHub (entre ellas bug, enhancement, documentation, duplicate, question, wontfix, good first issue y help wanted) son un conjunto inicial funcional.
-
Retrospectivas que producen cambios, no listas
Una retrospectiva justifica su tiempo cuando termina con una o dos mejoras que tienen una persona responsable, una fecha y un criterio reconocible de cumplimiento; la Scrum Guide exige que las mejoras más eficaces se aborden lo antes posible, y la Prime Directive marca el tono en el que las personas nombran problemas reales.
-
Postmortems sin atribución de culpa: registrar el desarrollo, las causas y las medidas
Un postmortem describe qué ocurrió durante un incidente, a quién afectó y durante cuánto tiempo, qué circunstancias lo hicieron posible y qué medidas hacen menos probable una repetición. La ausencia de culpa no es una norma de cortesía, sino la condición para que las personas involucradas informen los hechos en lugar de defenderse.
-
Diseñar una rotación de guardia y su traspaso
Una rotación de guardia necesita una persona titular y una de respaldo, una porción acotada del tiempo del personal de ingeniería, duraciones de turno y reglas de intercambio que se puedan planificar, un presupuesto de avisos que desencadene trabajo correctivo al superarse, y un traspaso escrito en cada cambio de turno; el libro de SRE de Google y la documentación pública de respuesta de PagerDuty describen estas restricciones.
-
Puntuación RICE e ICE: qué significan los números y dónde dejan de servir
RICE multiplica alcance, impacto y confianza y divide entre esfuerzo; ICE prescinde del alcance y conserva impacto, confianza y facilidad. Ambas son útiles para hacer explícitos y comparables los argumentos de priorización, y ambas fallan cuando los datos de entrada son conjeturas disfrazadas de números o cuando se ignoran las dependencias y la estrategia.
-
Estimar el esfuerzo como un rango con un nivel de confianza indicado
Entregar una estimación como un rango (mejor caso, valor esperado, peor caso) más la confianza de que el valor real se encuentra dentro de él; ajustar la amplitud a los resultados de trabajos comparables anteriores en lugar de al plan, y actualizarla en puntos fijos. Una sola cifra oculta precisamente la incertidumbre de la que dependen las decisiones.
-
Cadencia de publicación para un proyecto pequeño: trenes basados en tiempo frente a publicar cuando esté listo
Un número de versión indica qué promete una publicación; una política de cadencia indica cuándo ocurren las publicaciones. Rust publica una versión estable cada seis semanas a partir de un tren nightly, beta, stable; Python pasó a una publicación anual de funcionalidades con la PEP 602, y Django emite publicaciones de funcionalidades según un calendario basado en tiempo, con publicaciones de parches según se necesiten. Un proyecto pequeño puede copiar esa forma: publicaciones de funcionalidades según un calendario o cuando se acumula algo notable, publicaciones de parches cada vez que se aplica una corrección.
-
Llevar a cabo una revisión de diseño: período de comentarios, responsable de decidir designado y una resolución registrada
La revisión de una propuesta necesita un período de comentarios acotado, una persona o grupo designado que decida, una resolución escrita (aceptar, rechazar, posponer) con sus razones, y una regla para reabrirla; el proceso de RFC de Rust y el proceso de PEP de Python muestran la forma general, y esta metodología la adapta a un único equipo.
-
Rechazar una solicitud de funcionalidad sin perder a quien la propuso
Un rechazo que remite a un alcance escrito, llega con prontitud, indica una alternativa y cierra el hilo es más amable que el silencio, y mantiene a quien lo solicitó como colaborador. Las Open Source Guides señalan que dejar las cosas por escrito facilita decir que no, y que una respuesta rara vez necesita más de una o dos frases.
-
Criterios de aceptación por elemento de trabajo que puedan convertirse en pruebas
Los criterios de aceptación de cada elemento de trabajo se escriben como ejemplos concretos con un estado inicial, una acción y un resultado observable, usando la estructura Dado/Cuando/Entonces (Given/When/Then) de Gherkin o un equivalente, con los casos límite nombrados; los criterios que no puedan ejecutarse ni comprobarse por alguien distinto de quien los escribió no son criterios.
Legible por máquina: JSON