Si no puede describir la estructura de su organización, departamento, trabajo en general con los dedos, significa que lo está haciendo de manera ineficiente.
Eficiencia y transparencia nunca son lo mismo. Puedes hacer cosas ineficaces de manera transparente y hacer cosas que son opacas de manera efectiva.
Construir una estructura de trabajo es un proceso complejo e individual, con un toque de audacia. Porque no solo necesitamos coraje y reflexión (“trabajamos de manera ineficiente, ¿por qué?”), Sino también la capacidad de hacer montones elegantes.
Los montones elegantes son la clave para crear estructuras. Parece que "no necesitamos, trabajamos y está bien, por qué necesitamos capas adicionales", pero de hecho, una capa reflexiva elevará su trabajo a un nuevo nivel. Es un montón, pero es elegante. Algo como la inyección de dependencia o el uso de Photoshop en lugar de pintura.
Si ahora pensabas "no, todo es efectivo con nosotros", ni siquiera esperes. Inefectivamente Incluso si nunca te atascas completamente en tu trabajo, entonces simplemente vives en ilusiones. Esto no es posible. La eficiencia es un proceso de mierda, no un hecho. Y una persona específica debe proporcionar este proceso. Y otros - para apoyar. No porque "lo dijeron", sino porque todos estarán bien, todos trabajarán como se sientan cómodos y sean efectivos.
En resumen, llamamos a nuestra creación de montones elegantes "el pájaro descarado de las estructuras" o "flujo de desarrollo". Ahora lo describiremos, y también comeremos a un par de sus perros en disputas.
¿Por qué es necesario?
Development Flow está diseñado para cumplir 4 obligaciones:
- Estructuración de procesos
- Soluciones a problemas
- Da comentarios
- Proporciona un lenguaje de interacción universal.
Development Flow es una herramienta de creación de
sistemas .
El sistema
El sistema consta de elementos, los elementos son diferentes y los "actuales" los atraviesan: el proceso de trabajo. En TI, "hablar" es el código, el diseño, los documentos y otras cosas con las que trabajamos.
Faltan sistemasSi no sabe en qué etapa de su flujo privado se encuentra actualmente (por ejemplo, "desarrollando una función"), y no sabe en qué etapa se encuentra en el flujo general (por ejemplo, la cuarta, después del propietario del producto, el asistente de Scrum y el diseñador), y qué la etapa debe ir detrás de ti, cuáles son sus criterios de devolución y muchas otras pequeñas cosas aún ...
O si lo sabe, pero por su trabajo, el Gerente de Proyecto debe sentarse a su lado y recordarle exactamente qué debe hacer en ese mismo momento (no se separe del monitor, luego los siguientes programas) ...
O si simplemente sientes que eres ineficaz ...
... entonces lo más probable es que no tenga un sistema.
El sistema no funciona correctamenteNo todo el oro que brilla. No todos los V12 están debajo del capó. Y lo más importante: no todos los motores funcionan correctamente, incluso si están viajando (hola, querida industria automotriz).
Es importante tener un sistema que funcione correctamente, porque es nuestra confianza. En su trabajo, en el trabajo de todo el sistema. Inmediatamente encontrará problemas, la mayoría de los cuales puede resolver.
Un motor en marcha tiene un sonido. Es rítmico, agradable. Si hay un problema, lo escucha el oído sensible del maestro. Grieta, estornudos, alteración del ritmo, golpes. Destruye el motor lenta o rápidamente, y la "máquina de negocios" se descompone justo cuando tomaste una hipoteca en dólares por una nota de tres rublos dentro del anillo.
En el sistema de trabajo de las personas, estos ruidos: violación de los plazos, descontento, filtración de personal, tono bajo de los empleados, problemas al siguiente departamento, y mucho más. Un buen gerente camina por la oficina con localizadores supersensibles extendidos en lugar de orejas. Él conoce la tormenta inminente, siente que la presión ha bajado. Oye todos los suspiros cortos y nota sus ojos retraídos. El es el sistema.
Flujo de desarrollo: sistema
El sistema DF implica dos secciones: flujo general (funcionamiento del sistema como un todo) y flujo privado (funcionamiento de sus partes individuales).
Flujo total
El sistema consta de elementos combinados en una estructura para lograr el objetivo previsto.
El objetivo en TI es lanzar el producto en el momento adecuado, con la calidad adecuada. Elementos del sistema: participantes en el proceso: Propietario del producto, Jefe de proyecto, Scrum Master, Desarrollador, Diseñador, Probador, Escritor técnico ... Estos son todos elementos, y no todos están presentes todo el tiempo. A veces los roles se combinan. Necesitas resaltar tus elementos.
Necesitas resaltar tus elementos. Escríbelas y dibuja tu primera flecha de flujo. Esto se llama flujo común.
Propietario → SM → Diseñador, Desarrollador → Probador → Escritor técnicoLa tarea es combinar los elementos en una estructura y mostrar qué interacciones profesionales son posibles. Poco profesional: no es necesario que el diseñador y el propietario del producto vivan juntos. Solo son roles necesarios. El propietario no debe interactuar con el Diseñador o Desarrollador. Solo Scrum master. Solo Scrum master.
Cuando resaltamos las interacciones, estas flechas, debemos mostrar lo que da el Primero, y que el Segundo lo devuelve como retroalimentación. Entonces el sistema comienza a vivir.
Propietario → da una descripción de la tarea → SMSM lo reformulará tanto para el propietario como para el resto. La evaluación de la tarea, aproximada, se alineará. Pero la tarea de SM: desde una simple descripción, aplicando un montón elegante, para hacer una DESCRIPCIÓN SUFICIENTE. Él discutirá y distribuirá partes de esto ANTES con el equipo.
SM → da partes a → Diseñador y DesarrolladorDO incluye un esquema, todos sus estados posibles y mucho más (no quiero acumular aún). Todos tienen su parte. No siempre al mismo tiempo. Por lo general, el diseñador está un sprint por delante del desarrollador.
Diseñador y desarrollador en una reunión diaria a medida que los comentarios de SM le devuelven su visión de la tarea. Nos aseguramos de que entendemos todo de la misma manera. Tarda entre 25 y 28 segundos. Y ahorra horas y semanas.
El desarrollador → después de su flujo privado (más sobre eso más adelante), pasa el código → al ProbadorEl desarrollador da el código, el probador mira su parte del TO y cumple con su flujo. La retroalimentación del probador es para SM → "positivo", es decir, cómo entiende la tarea, y para el desarrollador → "negativo", solo si está roto.
El desarrollador no tiene idea de que su código se prueba hasta que haya problemas.
Creo que
General Flow está formulado correctamente de la siguiente manera. El primero da al segundo, el segundo proceso, devuelve retroalimentación "positiva" o "negativa", avanza en el flujo general. La retroalimentación positiva es la creencia de que todo funciona según lo previsto; Comentarios negativos: muestra dónde y qué salió mal.
Flujo privado
En este artículo, describiré el flujo privado de Propietario, CM y Desarrollador, como ejemplo. Si está interesado, entonces publicaré el resto del trabajo.
El dueño
Objetivo principalEnunciado del problema (backlog ← descripción), lea los comentarios
Que sigueCuando el propietario formula las tareas, el SM las describe → conduce a Suficiente_Descripción.
Comentarios deEl SM reescribe la tarea y discute los hitos clave con el Propietario rápidamente, incluida la línea de tiempo.
Interactúa conSM
SMObjetivo principalAcepte la tarea, tráigala en forma de Descripción adecuada, evalúe las tareas, distribuya, lea los comentarios
Que sigueDistribuye tareas a los empleados.
Comentarios deDiseñador, Desarrollador, Probador, Escritor Técnico
Interactúa conPropietario, Diseñador, Desarrollador, Probador, Escritor técnico
Desarrollador
Objetivo principalDesarrollo de funciones y corrección de errores. En General Flow, recibe tareas de SM y, con la ayuda de su actividad profesional, las implementa (git flow, rebase flow, feature flow, etc.).
Que siguePuede hacer sugerencias para modificaciones, discutiéndolas con SM y el Diseñador.
Comentarios deCM, Diseñador, Probador
Interactúa conSM, por el diseñador, (es importante, no puede generar interacción con el probador)
(En esta descripción, no me gusta mucho el esquema,
esta es mi presentación con una descripción diferente, y estoy más contento de trabajar con ella. Pero estoy explorando opciones, intentando, perfeccionando, y resultó así).
En el residuo seco
Development Flow resuelve los siguientes problemas:
- Estructuración de procesos
- Resolviendo problemas
- Da retroalimentación
- Proporciona un lenguaje universal del que aún no hemos dicho una palabra
Las principales ventajas: todos saben lo que está sucediendo, qué hacer y no están cargados de trabajo innecesario.
Los Scrum Masters tienen mucho trabajo (Timlid, CTO). Pero debería ser así, él es el tractor principal en este enfoque.
presentación muy corta y secaQuédese en la oscuridad o cree estructuras audaces. Ofrecemos nuestro pájaro, pero es grande y esto es solo una parte, en la primera aproximación. Necesitamos más que cualquier caso. Por lo tanto, le pregunto: cuelgue todos los perros sobre mí, quiero descifrar un tema mejor.
(Tuve que cortar mucho para reducir el tamaño del artículo al menos un poco. Debido a esto, podría perderme algo, pero lo corregiré rápidamente, escriba).