Si te interesan al menos algunas cosas útiles:
a. disciplina básica
b. La formación de procesos de interacción acordados entre sí y con los aliados.
c. Una explicación de qué y cómo hacen los subcontratistas
d. flexibilidad en la gestión de procesos
e. respuesta oportuna a problemas emergentes
entonces mejorarán el clima laboral en el equipo de desarrollo.
Si desea desarrollarse con calma, debe reunirse, ponerse de acuerdo y escribir reglas transparentes para interactuar entre sí. Al menos lo más básico.
Todos los procesos y acuerdos deben elaborarse con la participación de todas las partes interesadas, y los procesos que afecten negativamente deben destruirse.
Quiero pintar sobre el ejemplo del flujo de trabajo de un sprint qué beneficios aportan sus elementos: qué acciones se realizan, qué artefactos están presentes y por qué se necesita cada uno de ellos. Primero debe familiarizarse con las definiciones de eventos y artefactos scrum.
Sprint N-1 : Preparatorio. Lo cual no es exactamente un sprint.
Antes del comienzo del sprint N del desarrollo en sí, parte del equipo se dedica a trabajos preparatorios: pruebas, aprobación, desarrollo, visualización, etc.
Significado : para que los desarrolladores puedan llevar a cabo la tarea de manera cualitativa, alcanzar los parámetros requeridos o resolver el problema de alguien, antes de que comience el desarrollo:
a. hacer a fondo todo el trabajo preparatorio,
b. reducir las discrepancias,
c. probar en los usuarios u obtener la aprobación de las partes interesadas,
d. crear una visualización detallada.
Salida : un conjunto de artefactos y datos que satisfacen la lista de verificación Definición de listo.
Si desea mejorar la interacción entre los codificadores y todos los demás participantes directos en el proceso de desarrollo, será útil familiarizarse y explicar las funciones y procesos básicos de todos los participantes. Entre los codificadores, hay suficientes introvertidos a quienes no les gusta cuando interrumpen su proceso, pero también necesitan comprender cómo funcionan los demás para que no obtengan el efecto contrario. Empezamos:
Comienzo de Sprint N-1 :
OKR, KPI, requisitos de las partes interesadas , etc. - Un conjunto de condiciones externas entrantes que guían el desarrollo.
Meta de sprint N.Dependiendo de las condiciones entrantes, dónde debe moverse el desarrollo, qué parámetros deben lograrse, a quién y por qué ayudar, se forma el objetivo del próximo sprint de desarrollo.
Significado : el objetivo del sprint actúa como una motivación para el equipo, una explicación del significado de sus actividades, estableciendo indicadores.
En ausencia : los codificadores desmotivados se controlan principalmente con un látigo, estera, finos.
Cualquier equipo necesita motivación para que el desarrollo no se convierta en una serie interminable de tareas sin sentido que no está claro si alguien necesita. Especialmente en las empresas donde el desarrollo no es la base del negocio, a menudo surge un problema cuando el departamento no es apreciado, razón por la cual su autoestima y motivación disminuyen. Necesitamos un objetivo transparente y comprensible: ayudar a alguien a resolver el problema, mejorar algunos parámetros del negocio, mejorar la vida de alguien. Incluso en la empresa más miserable, es bueno tener conciencia del significado de sus actividades.
Preparación del trabajo atrasado - rally o actividad continua. Gestionar la cartera de pedidos de una parte limitada del equipo.
Significado : Cada sprint se lleva a cabo una reunión con una composición limitada para la limpieza, estudio básico, evaluación inicial de complejidad y factibilidad, descomposición, priorización de tareas en el trabajo atrasado.
Salida : una lista de tareas relevantes y factibles.
Si no es así : una gran lista de lista de deseos en la cartera de pedidos, que nadie lee, en la que las tareas permanecen olvidadas durante años.
Planificación del sprint N-1 : un rally en el que parte del equipo de entrenamiento, basado en el propósito y el alcance del próximo sprint N, selecciona, preevalúa y prioriza las tareas.
Sentido : la preparación para el sprint también requiere cierto orden. La gestión de recursos se simplifica.
Salida : sprint N. backlog
Prueba de desarrolloDepende del estilo de desarrollo y la presencia de probadores en el equipo.
Significado : Vale la pena tener planes listos para verificar la salud del código.
Sugiero considerar 2 opciones:
En ausencia de probadores, existe una opción para transferir la creación de pruebas al equipo de desarrollo. En este caso, esta actividad se lleva a cabo como parte del desarrollo de tareas en el sprint N. Según algunas revisiones, este enfoque mejora la calidad del código escrito por los desarrolladores.
Si tiene probadores, puede usar el enfoque cuando las pruebas se escriben antes del código. Una de las ventajas es que el desarrollo de la tarea finaliza en el desarrollador y reduce la posibilidad de devolver la tarea finalizada de los probadores cuando el desarrollador ya ha cambiado a otra tarea.
Estudio de casos de uso : estudio detallado de escenarios de interacción y resultados dentro de la tarea.
Significado : una descripción de los escenarios de interacción de tareas con texto o diagramas mejora la comprensión del problema por parte de todas las partes interesadas. La solución de bajo costo se puede utilizar para crear casos de prueba y creación de prototipos.
En ausencia : la baja elaboración conduce a una divergencia de comprensión de lo que realmente se requiere de la tarea, es posible la pérdida de casos de uso alternativos.
Wireframing, mockuping y prototyping son, en general, un proceso iterativo de desarrollo de visualización de la interfaz, con detalles cada vez mayores. Comenzando con la opción más simple y económica, se prueba a los usuarios / partes interesadas para ver si la opción propuesta cumple con las expectativas de resolver el problema. Las pruebas visuales son muy útiles para reducir la inconsistencia de las descripciones textuales y son muy baratas en comparación con la codificación que en empresas con un diseño sólido y un lobby de productos comenzaron a separarlas en una metodología separada con sus procesos, artefactos y cronograma.
Wireframing : bosquejo aproximado de elementos de la interfaz. Un bolígrafo en una hoja de papel o en un software sin adornos.
Sentido : prueba / aprobación rápida y económica por parte de los interesados de la tarea. Una demostración adicional de visualización mejora dramáticamente la percepción que solo el texto descriptivo.
En ausencia : una discrepancia en la comprensión de lo que realmente se está creando. Incremento en los costos de desarrollo.
En ausencia de aprobación : obtenga la aprobación documental cuando desarrolle para una parte interesada, para minimizar la posibilidad de "no solicité esto".
Salida : proyecto aprobado / probado de estructura metálica.
Mockuping es el segundo paso para visualizar tu interfaz. El aumento en los detalles.
Significado y ausencia : similar a la estructura de alambre. Preparación de contenidos para maquetación.
Salida : maqueta y diseño aprobados / probados.
La creación de prototipos es el tercer paso para desarrollar la visualización de su interfaz. A la visualización de alto detalle se agrega una demostración de imitación de la interacción del usuario con el producto.
Significado y ausencia : similar a la estructura de alambre y maquetas.
Salida : tenemos un prototipo detallado del producto y la visualización de la interacción. Además de la aprobación documental de las partes interesadas o el resultado de las pruebas en los usuarios
DoReady =
Definición de Listo : la lista de verificación de las condiciones acordadas por el equipo de desarrollo y pre-entrenamiento según el cual se verificará: ¿el estudio de las tareas tiene un nivel suficiente, la presencia de todos los artefactos requeridos, para que la tarea pueda ser aceptada en el desarrollo?
Significado : Tener una lista de verificación formal acordada por todas las partes interesadas mejora la comprensión y la interacción dentro del equipo. Todos saben qué y cómo pasar. Puede meter la nariz en la lista de verificación y enviar para terminar a los trabajadores negligentes.
En ausencia : "Oh, casi lo termino, está hecho al 95%". y ... nunca se completará.
En mi humilde opinión, este es el artefacto más importante para resolver conflictos básicos entre codificadores y todos los demás. De inmediato queda claro quién y cómo no terminó su trabajo, qué violaron y cómo afectará a otros. Es mucho más difícil discutir con las reglas establecidas que en el caso de una disputa basada en opiniones o presiones por parte de la autoridad / posición. Aunque el moderador de PM que toca el elemento deseado sigue siendo útil.
Pasó todo más lejos:
Sprint N. Comenzamos el desarrollo.
Sprint Start N :
Definición de Listo, Meta del Sprint, Lista de Tareas Evaluadas Inicialmente: las condiciones (y artefactos) requeridos para iniciar el sprint.
Planificación de Sprint N : una reunión en la que el equipo de desarrollo, basado en el objetivo y el alcance del sprint N, selecciona, evalúa, prioriza y descompone las tareas. Dependiendo de la velocidad promedio del equipo, se gana una cierta cantidad de tareas.
Sentido : la reunión principal en la que el equipo verifica si las tareas se resolvieron satisfactoriamente. ¿Entienden correctamente las tareas establecidas, los criterios de aceptación? Los desarrolladores finalmente evalúan el costo de las tareas.
En ausencia de : caos, las tareas serán establecidas en cualquier momento, por cualquier persona incomprensible, incluso en el medio de realizar otras tareas.
Salida : sprint N. backlog
Nota: dependiendo de la velocidad del equipo, los sprints a menudo requieren el 70-80% de las tareas para el objetivo del sprint, y el 20-30% de las tareas por errores, deudas técnicas o tareas críticas repentinas.
La descomposición y la asignación de tareas a menudo es una mini reunión para un equipo de desarrollo sin personas adicionales.
Significado : un equipo con un líder de equipo descompone las tareas de sprint en subtareas por un período de no más de 1 día (borde 2). Los desarrolladores asignan subtareas según su especialización o preferencias.
En ausencia : depende de la participación del equipo en el proceso si los desarrolladores recibirán tareas interesantes que contribuyan a su desarrollo.
Salir : detalla las tareas pendientes de Sprint N a sub-tareas de 1 día.
Reunión diaria: reunión breve diaria del equipo de desarrollo.
Significado : todos los días, los desarrolladores deben sincronizarse entre sí: quién hizo qué y qué para el día anterior, qué planean lograr el día actual y qué problemas interfieren con la tarea.
En ausencia : nadie sabe en qué están trabajando los demás, sus problemas de implementación. Los plazos de desarrollo están siendo interrumpidos.
Salida : el progreso se registra en el cuadro de quemado: el cronograma de tareas.
Mi opinión es que uno de los principales significados en la existencia de manifestaciones diarias es la introducción de la disciplina. Los codificadores tienen muchos introvertidos que no quieren comunicarse, no quieren saber qué están haciendo los demás, no quieren pasar tiempo en manifestaciones. De ahí las reglas para llevar a cabo de pie, brevemente.
De hecho, si el equipo trabajó bien juntos, se comunica bien en un chat e inmediatamente comparte cualquier problema, el número de reuniones se puede reducir reestructurando las reuniones en un proceso continuo. Pero no deberías cortarlo por completo.
La discusión y la resolución de la interferencia es una continuación directa de la reunión diaria.
Significado : después de que los desarrolladores expresaron problemas con la implementación de las tareas, se lleva a cabo una discusión sobre las tareas que el equipo puede resolver internamente, luego se dirige a los participantes y la interferencia con la solución externa pasa a PM.
Si no es así : los problemas de implementación deben resolverse juntos, lo más rápido posible para que nadie arrastre artificialmente el progreso.
Cuando los introvertidos huyeron en sus rincones, aquí ya puedes discutir los problemas y sus soluciones.
Confirmaciones / Revisión de código: verificación de código por parte de otros miembros del equipo.
Significado : 1-2 miembros del equipo deben mirar el nuevo código y aprobar la calidad, el estilo, etc.
Si no es así : aumente el número de errores en el código, baja calidad y estilo.
Ofrecen llevar a cabo la revisión de código 2 por otros desarrolladores con diferentes niveles, incluso para juniors, esta es una buena manera de aprender. De una forma u otra, el equipo obtiene un estilo aceptable, quién sabe cuándo y quién tendrá que volver al código de trabajo.
Implementación en el servidor de desarrollo / demostración previa : cargue el código en el entorno / servidor de desarrollo.
Significado : cualquier implementación de la tarea puede cargarse en el entorno de desarrollo e invitar a las personas interesadas a realizar pruebas y la aprobación preliminar del trabajo realizado.
Si no es así : en el sprint de demostración final, puede ponerse en una posición incómoda al demostrar una implementación incorrecta o incorrecta.
Salida : aprobación informal de la tarea.
De todos modos, las interpretaciones incorrectas de la tarea, o los criterios de lectura de la tarea indirectamente, a veces llegan a esta etapa. Cuanto antes se verifique y pruebe la tarea, con menos frecuencia será necesario volver a ella.
Definición de Hecho - Similar a Definición de Listo, esta es una lista de verificación de los principios por los cuales PM / PO acepta tareas completadas.
Sentido : creado por el equipo de desarrollo junto con PM / PO para predecir los parámetros de aceptación del trabajo. Todos saben cuál es el criterio de la tarea y cuál no.
En ausencia : sin criterios claros, el "refinamiento" de las tareas aparece después de los intentos de aprobarlas. O las tareas permanecen sin terminar hasta los requisitos finales.
Un acuerdo documental por el cual el PM / PO acepta la tarea y sus criterios, aprobado por ambas partes. Bien reduce la cantidad de puntos controvertidos.
Previene PM / PO insolentemente aplastante poste. Corta las tareas "completadas" en un 95%. Los desarrolladores no deben terminar las tareas completadas después del sprint, si la tarea claramente no cumple con la lista de verificación, entonces no debe considerarse aceptada y pasará al sprint futuro.
Revisión y demostración del incremento del producto : una manifestación en la que los desarrolladores demuestran a las partes interesadas la implementación del objetivo del sprint.
Significado : los propios desarrolladores demuestran un nuevo incremento de producto viable. PM / PO verifica formalmente los criterios de desempeño de la tarea y el cumplimiento del DoD. Las partes interesadas deciden si el nuevo incremento del producto coincide con los Objetivos de Sprint.
En ausencia : la ausencia de una demostración formal y la aceptación del trabajo realizado reduce el valor de los criterios de aceptación, la calidad del trabajo realizado.
Salida : se completa el trabajo del equipo. Las partes interesadas deciden si el próximo sprint será en absoluto.
La demostración por parte del desarrollador de la tarea completada es más útil y comprensible que la provisión impersonal de nuevas funciones a un interesado para el autoanálisis. Y la parte interesada ve quién hizo el trabajo por él, y los desarrolladores ven para quién estaban resolviendo el problema.
Colección de revisiones - continuación Revisión de la manifestación.
Significado : la presencia en un lugar de todas las partes interesadas, el equipo y el producto en sí mismo permite la comunicación informal, para recopilar ideas, sugerencias, etc. Obtenga comentarios sobre la calidad del equipo.
En ausencia : el tiempo formal asignado reduce los contactos innecesarios entre el equipo y las partes interesadas durante otras horas de trabajo.
Salida : nuevos datos, comentarios.
La retroalimentación es generalmente algo útil, incluso la retroalimentación de los interesados sobre su experiencia con los desarrolladores. Motivo para modificar los procesos de interacción con actores externos. Mejorar las relaciones con las partes interesadas actuales y futuras siempre se puede explotar: pedidos, presupuesto, concesiones, etc.
Retrospectiva Sprint N - Un rally para el equipo de desarrollo y PM / PO.
Significado : discusión de los procesos y problemas del equipo durante el último sprint, un intento de cambiar los procesos de trabajo para mejorar el equipo. Qué procesos tuvieron éxito, cuáles no generaron beneficios ni daños, qué problemas nuevos surgieron y cómo se pueden solucionar.
Salida : El plan del experimento del proceso. Los procesos se modifican en el próximo sprint para evaluar qué modificaciones son útiles y cuáles deben descartarse.
En ausencia : la plantación de procesos de desarrollo de equipo desde arriba o la falta de ellos reduce la usabilidad, productividad y previsibilidad de desarrollo del equipo.
Además de la discusión banal de los problemas y cómo deben resolverse, quiero prestar atención al "Plan del experimento del proceso". No trate los procesos grabados como tallados en piedra: inmutables y constantes. Agregar nuevo - prueba, no me gustó - cortarlo.
Fin de Sprint N
Sprint N + 1 . Vierta un nuevo incremento en la producción.
Significado : debido a la finalización frecuente del sprint al final de la semana laboral, la implementación en el servidor de producción y el acceso a los usuarios ya se produce en el próximo sprint, de modo que no surjan problemas potenciales el fin de semana.
El incremento fue para monitorear los parámetros.