Hemos pensado y trabajado mucho en el desarrollo de las prácticas de ingeniería que usamos cada día. Estas prácticas se basan en principios que hemos llegado a valorar y esos principios conducen a las prácticas. Con el fin de preservar y desarrollar nuestros principios y prácticas, hicimos que nuestros ingenieros nominaran a algunos de nuestros más respetados ingenieros para codificarlos; esto dio lugar a nuestro documento Engineering at. Puede leer más sobre eso aquí.
Si echas un vistazo a ese documento, notarás que en el lado izquierdo de cada página hay un principio que valoramos, y en el lado derecho hay una lista de elementos que Hacemos , Fomentamos , y Evitamos . La sección Do son elementos que hemos acordado que todos los ingenieros harán en . La sección Fomentar es un guiño a la autonomía del equipo, son cosas que valoramos y fomentamos, pero no todos los equipos están obligados a hacerlas si pueden encontrar enfoques alternativos que aún cumplen el valor de la izquierda. Y la sección Evitar son cosas que todos estamos de acuerdo en evitar en .
Hay varios principios en este documento, este post se va a centrar en el primero: La entrega continua de valor a la producción.
Lo que hacemos
Para apoyar la entrega continua de valor a la producción, aquí están las prácticas que pedimos a todos los ingenieros en adoptar:
Nos centramos en la eficiencia del flujo sobre la eficiencia de los recursos. Lo que significa que valoramos el valor del flujo de la producción por encima de que todos estén ocupados o el sistema parezca estar ocupado. Los términos eficiencia de flujo y eficiencia de recursos vienen del mundo de la Manufactura Esbelta. En , el Desarrollo de Software Lean es nuestro sabor de Ágil. Valorar la eficiencia del flujo apoya prácticas como la Programación Mob, la Programación en Pares y el flujo de una sola pieza. El flujo de una sola pieza sugiere que tendremos un equipo enfocado en una sola característica (o historia para usar un término Ágil) y trabajaremos en esa característica juntos hasta que sea lanzada hasta la producción. En un mundo tradicional, con un uso eficiente de los recursos, esto causa incomodidad; por ejemplo, la gente podría preguntarse «¿Por qué tener cuatro personas trabajando en un solo largometraje cuando podrías tener cuatro personas trabajando en cuatro largometrajes simultáneamente? La respuesta es que valoramos la eficiencia del flujo y creemos que podemos hacer llegar el valor a nuestros clientes de forma más rápida y eficiente centrándonos en sólo uno (por medio del mobbing) o dos (por medio del emparejamiento) artículos a la vez hasta la producción.
Con frecuencia liberamos pequeños cambios en la producción. ¡En un mes reciente nos desplegamos a la producción más de 1.000 veces! Esto se reparte entre unos 40 pequeños equipos, así que unos 6 lanzamientos a producción por semana por equipo – pequeños y frecuentes lanzamientos. El flujo de una sola pieza, pequeños límites de WIP (Work in Progress) y varios otros principios nos ayudan a conseguirlo.
Seguimos nuestro trabajo en las tablas digitales Kanban. Usamos tablas Kanban para rastrear nuestro trabajo. Estos son tableros que muestran, de un vistazo, el estado de lo que estamos trabajando. En pocas palabras, tienen columnas que esencialmente comunican el To Do, Doing, and Done, etc. Esto nos permite ser capaces de priorizar el trabajo y recoger el siguiente elemento más importante y pasarlo a producción. También nos permite ver cuánto trabajo tenemos en marcha y gestionar ese trabajo con límites WIP.
Establecemos y seguimos los límites del trabajo en curso (WIP). Los límites del trabajo en progreso son una forma de ayudar al equipo a reconocer cuando están tratando de hacer demasiado a la vez. Nuestros tableros Kanban tienen límites WIP establecidos para cada columna y si excedemos ese límite la columna se volverá roja. Típicamente cuando esto sucede el equipo comenzará a expresar sentimientos de caos, de estar abrumado o de cambio excesivo de contexto. Nuestros límites WIP sirven como recordatorio para centrarse en la eficiencia del flujo, no sólo en estar ocupado.
Extraemos las plataformas del código de trabajo. Esto habla de la cantidad (o falta) de arquitectura y planificación por adelantado que hacemos. Aunque es importante para nosotros pensar profundamente en las características y otros trabajos que hacemos, intentamos evitar crear diseños y arquitecturas masivas por adelantado. Hacemos lo suficiente para que podamos ver hacia adelante para no caminar en la oscuridad, pero no creamos plataformas o arquitecturas enteras antes de comenzar con ellas. solía ser simplemente un sitio web para encontrar y ver contenido de video de alta calidad para aprender nuevas habilidades tecnológicas. Hoy en día es una plataforma entera de habilidades tecnológicas que va mucho más allá de eso. Pero esa plataforma no fue concebida y diseñada hace años, sino que surgió a medida que identificamos nuevas propuestas de valor para nuestros clientes y las llevamos a la producción. A medida que se entregaba más y más valor a la producción, comenzamos a organizarlas en una plataforma. Esto nos ayuda a centrarnos en la entrega de valor en primer lugar y evitar la creación de grandes plataformas por adelantado que no han sido validadas por nuestros clientes.
Lo que alentamos
Para apoyar la entrega continua de valor a la producción, aquí están las prácticas que animamos a todos los ingenieros a adoptar. Son importantes para nosotros y creemos que aportarán un valor adicional, pero también respetamos la autonomía de nuestros equipos e ingenieros. Así que, aunque creemos que son valiosas, permitimos cierta flexibilidad aquí basada en el contexto en el que cada equipo está trabajando.
Alentamos el desarrollo basado en el tronco. El desarrollo basado en el tronco significa que cuando empujamos el código a nuestro repositorio, lo empujamos a la rama maestra (o tronco). También significa que siempre mantenemos la rama maestra en un estado desplegable – eso es desplegable, no deplorable. 🙂 Para lograr esto utilizamos banderas de características en lugar de ramas de características. Un equipo puede estar trabajando en una característica que está incompleta, pero aún así quieren empujarla al repositorio. Para que ese código incompleto sea empujado a la rama maestra puede que necesite estar rodeado de una bandera de característica que esencialmente ignore ese trozo de código. Esto requiere un poco de rigor, pero significa que frecuentemente estamos validando nuestro código a medida que pasa por nuestros procesos de CI y se despliega en la etapa de producción. Nos permite hacer despliegues más pequeños y frecuentes y validar con mayor frecuencia que no hemos causado ninguna regresión involuntaria al código circundante. En los equipos que no están practicando el flujo de una sola pieza, también les permite integrar su código juntos a menudo en las múltiples (aunque pocas) características que están simultáneamente en desarrollo.
Fomentamos el flujo de una sola pieza. Aunque esperamos que todos los ingenieros establezcan límites de WIP pequeños y resonantes, no requerimos que todos los equipos utilicen el flujo de una sola pieza. Por ejemplo, un equipo de 6 que elija el par en lugar de la turba, probablemente tendrá alrededor de 3 piezas en el flujo en un momento dado. Valoramos la mentalidad de trabajar en una sola cosa a la vez, pero también valoramos que los equipos elijan la mejor manera de trabajar para su equipo dentro de su contexto. En los equipos en pareja, también pueden ganar valor de una mentalidad de flujo de una sola pieza al enfocarse en una sola área de características más grandes. Por ejemplo, siempre que sea posible sería mejor tener dos parejas en un equipo de cuatro personas que trabajen en dos partes diferentes de una sola característica en lugar de trabajar en dos características totalmente separadas.
Alentamos a limitar nuestro horizonte de planificación. Ya hemos tocado este tema un poco, pero típicamente tenemos atrasos muy pequeños. De hecho, somos muy reticentes a llamar a cualquier cosa un retraso. Si se imaginan una tabla de Kanban con columnas de «Hacer, hacer y hacer», la columna de «Hacer» no está llena de cosas que hacer en el próximo año o trimestre o incluso en el mes – idealmente son cosas que esperamos llegar en la próxima semana o dos. No trabajamos en sprints y por lo tanto no estamos planeando para los sprints de una o dos semanas, tampoco. Más bien, estamos identificando la siguiente pieza de valor más importante que podemos proporcionar a nuestros clientes y ese es nuestro horizonte de planificación. También puede haber algún trabajo de descubrimiento de productos que esté ocurriendo más allá de ese horizonte para «lo que sigue» después de que entreguemos la pieza de valor actual, pero eso es más o menos el alcance de nuestro horizonte de planificación. Esto permite a nuestros equipos multifuncionales (que consisten en un ingeniero de desarrollo, un gerente de producto, un diseñador y algunos ingenieros de software) concentrarse realmente en el trabajo en cuestión y entregar rápidamente valor en esa área a nuestros clientes.
Lo que evitamos
Esto es esencialmente lo opuesto a la sección «Lo que hacemos». Pedimos a todos los ingenieros que eviten estas prácticas.
No creamos grandes diseños por adelantado. Ya hemos discutido esto anteriormente, pero esta práctica de Lo que evitamos es otro recordatorio de que esto es algo que hemos elegido específicamente para evitar.
No trabajamos con horarios insostenibles. La práctica de evitar los horarios de trabajo insostenibles apoya muchos de nuestros valores. Es una práctica que apoya la parte «continuamente» de «Entregamos continuamente valor a la producción». Los horarios de trabajo insostenibles llevan a la entrega en ráfagas de horas extras seguidas de períodos de inactividad. También apoya el valor que estamos entregando ya que los horarios insostenibles inevitablemente llevan a una reducción de la calidad y por lo tanto a una reducción del valor para nuestros clientes. Nos centramos explícitamente en el trabajo de horarios sostenibles para que podamos entregar valor continuamente.
La entrega continua de valor a la producción es uno de los muchos principios que valoramos y hemos documentado en Ingeniería en . Estos principios rectores y las prácticas correspondientes nos han ayudado a escalar la ingeniería a la vez que comunicamos, mantenemos y evolucionamos nuestros valores y prácticas a medida que crecemos. Ha sido valioso para nosotros separar los valores y principios de las prácticas – esto nos permite adaptar nuestras prácticas para apoyar lo que realmente valoramos. Las prácticas son un medio para un fin. Los valores, o principios, definen el fin y las prácticas son nuestra mejor comprensión actual de cómo alcanzar el fin. ¿Ha pensado en las cosas que valora en su organización? Si usted fuera a crear algo como la ingeniería en, ¿cómo se vería para su organización?
Categorías: practicesTags: agile, lean, continuous integration, continuous deployment, values