es diferente de la mayoría de las organizaciones de ingeniería (digo sin ningún dato real ). Estamos estructurados de manera diferente, desde lo que constituye un equipo hasta la forma en que desplegamos el código. Vamos a saltar y caminar a través de un día típico en la vida de un desarrollador en .
Para simplificar, pasaré el día según los desarrolladores en la misma zona horaria que nuestra sede: MT (Mountain Time).
Descargo de responsabilidad: Las prácticas individuales y el día de algunos equipos pueden variar un poco. Valoramos mucho la autonomía de los equipos, así que los equipos tienen mucha flexibilidad en la forma en que eligen trabajar.
Levántate
Para la mayoría de los desarrolladores, el día comienza con el pie.
Tres días a la semana, tenemos un stand de la organización de ingeniería a las 9:00 am. Esto es típicamente dirigido por nuestro CTO que da actualizaciones que pertenecen a todo el grupo (o la mayoría). Esto incluye las actualizaciones de la compañía de nuestro equipo ejecutivo, la bienvenida a los nuevos miembros del equipo, etc. El stand up (exceptuando raras excepciones) termina a las 9:15, a menudo antes.
Poco después de que la organización de ingeniería se ponga de pie, cada equipo tiene su propia posición, normalmente alrededor de las 9:20 o 9:30.
¿Qué es un equipo?
Ahora, es importante señalar aquí lo que constituye un equipo. Trabajamos en equipos multifuncionales . Un equipo típico consiste en 4-6 desarrolladores, un gerente de producto, y un diseñador de UX. Además, un ingeniero de desarrollo es asignado a un equipo, pero normalmente no está dedicado. (Yo podría entrar en la cultura de devops – lo que es ideal y dónde estamos, pero eso está fuera del alcance de este post).
Durante el levantamiento, un equipo hace varias cosas:* Poner al día el trabajo del día anterior. Estas actualizaciones están pensadas para mantenerse a un nivel bastante alto, sumergiéndose en los detalles donde tenga sentido. ¿Qué se ha publicado? ¿Qué está todavía en vuelo? ¿Qué nos bloquea? * Asegúrate de que el tablero de Leankit kanban refleje la realidad, particularmente el estado de las tarjetas. No sé tú, pero yo no he descubierto cómo codificar dos cosas a la vez. No te hagas el listo – el código reutilizable no cuenta. La única excepción a la regla de una tarjeta es si algo está bloqueado.
Al final de la parada, todos deberían tener una buena idea de lo que el equipo está haciendo y cuáles son los objetivos a corto plazo.
Escriba el código
Después de levantarse, es hora de sumergirse.
Somos grandes defensores de la TDD y de tener pruebas para guiar nuestro desarrollo. También son valiosos cuando se trata de la integración continua (véase más abajo).
Cuando se trata de escribir el código de producción, tenemos una regla explícita e incuestionable: dos personas deben ver y aprobar el código antes de que vaya a la producción. La mayoría de los equipos usan programación en parejas, un par usan mobbing, y unos pocos usan principalmente solicitudes de extracción.
Veamos más de cerca el mobbing y el emparejamiento.
Tanto en el mobbing como en el emparejamiento, hay un conductor y un navegante . El controlador es el que está en el teclado, escribiendo activamente el código. A veces un controlador se denomina «teclado inteligente», lo que significa que no deben tratar de dictar lo que el código debe hacer, sino más bien escribir el código que el navegador les dice que escriban. En lugar de ser un «teclado», son un «teclado inteligente» porque su navegador puede dar instrucciones de mayor nivel que las que se pueden dar a un teclado real, como: «Hagamos que esta prueba pase escribiendo el método llamado RollDie y devolvamos siempre un 1». La responsabilidad del navegador es decirle al conductor lo que debe hacer. Como no están escribiendo, son más capaces de pensar en cosas a un nivel más alto y ayudar a guiar a la pareja/motora.
Cada persona y cada grupo encontrará su propio equilibrio de cuán estrictamente prefiere asignar y utilizar estos roles. A continuación explico lo que significan estos roles con el mobbing y el emparejamiento.
Mobbing
Imagina un espectro de codificación colaborativa donde la codificación individual está en un extremo. Creo que el mobbing estaría en el otro extremo. El mobbing es cuando todo el equipo está trabajando en la misma cosa al mismo tiempo. A menudo para nosotros, son sólo nuestros desarrolladores en la mafia. Pero el jefe de producto y otros miembros del equipo siempre son bienvenidos a participar, y a veces se les pide explícitamente que se unan.
Configuración física Cada uno de nuestros mafiosos tiene dos televisores muy grandes detrás de un escritorio. El escritorio tiene un (a veces más, dependiendo de las preferencias de estilo de los miembros del equipo) teclado y un ratón.
Nuestros equipos utilizan un temporizador de la mafia que fue escrito internamente en (se encuentra aquí). La duración del temporizador es configurable; nuestros equipos suelen rotar el conductor cada 8-10 minutos.
Conductor/Navegador A veces una turba tendrá un navegador establecido. En este caso, he visto al navegador definido como la persona que está a punto de convertirse en el conductor, o la persona que acaba de terminar de conducir. Con un navegador estricto, el resto de la turba es principalmente silenciosa hasta que el navegador pide la entrada del grupo. Otras veces, una multitud tendrá un enfoque más suelto para navegar donde básicamente todos, excepto el conductor, son navegantes. Cada enfoque tiene sus méritos y contextos ideales.
Puedes leer más sobre el acoso en otro post.
Emparejamiento
En el espectro que mencioné en la sección de mobbing, el emparejamiento estaría en el medio. El emparejamiento es cuando dos desarrolladores trabajan en el mismo código al mismo tiempo.
Hay mucha variación en la forma en que los equipos se emparejan.
Configuración física La mayoría de los equipos tienen 4 monitores por estación de emparejamiento: 2 por persona (¡muy buenas matemáticas!), cada par de monitores reflejando al otro. Con esta configuración, cada persona tiene su propio teclado, ratón y escritorio. Algunos equipos se emparejan a través de la mesa, lo que significa que hay dos escritorios espalda con espalda con una persona a cada lado. Otros equipos se emparejan lado a lado, lo que significa que los dos escritorios y cada miembro del par están sentados al lado del otro.
Conductor/Navegador En mi experiencia, el emparejamiento tiende a ser menos formal que el mobbing. Dicho esto, puede ser implementado de la forma que se desee. He formado parte de un par en el que natural y fluidamente cambiamos entre los roles sin crear nunca ninguna regla explícita. También he sido parte de un par donde estríctamente tenemos un rol de conductor y navegante y cambiamos en una cadencia establecida, ya sea basado en el tiempo o en un par de ping-pong.
¿Qué idioma usamos? Bueno, esto es otra cosa que varía entre los equipos. Un aspecto de la autonomía que valoramos es permitir a los equipos elegir qué herramientas utilizan, dentro de lo razonable. Cada equipo puede elegir de una lista de lenguajes, herramientas y plataformas preferidas o aceptables, según su preferencia y la tarea en cuestión. Cuando se trata de asuntos de desarrollo como un IDE, el equipo tiene completa autonomía. Puede leer más sobre la autonomía y responsabilidad del equipo aquí.
Ahora que hemos escrito algo de código, ¡pongamos un reportaje en producción!
Despliegue
Unas palabras sobre la integración continua (CI)
Después de que el código ha sido escrito y empujado al control de fuentes (usamos github), tenemos una construcción automatizada que se ejecuta (usamos TeamCity). Cada código base tiene un conjunto de pruebas de unidad e integración que se ejecutan. Cuando todas ellas pasan, se crea un artefacto de construcción y en la mayoría de los casos se despliega automáticamente en el escenario. Entonces tenemos pruebas de aceptación y/o de interfaz de usuario que se ejecutan contra esa construcción que está ahora en el escenario.
Una vez que la construcción es verde (todas las pruebas pasan) y en el escenario, hacemos un poco de pruebas manuales – sobre todo una comprobación de la cordura. Si todo se ve bien, ¡es hora de enviarlo!
No todos los lanzamientos se crean igual, lo que significa que algunos pueden requerir algunos cambios en la base de datos primero y la configuración de cada equipo puede ser única. Pero la mayoría de las veces simplemente pulsamos un botón para desplegar a prod . Es tan simple como autenticarse en cualquier herramienta/proceso que su equipo utilice, y desplegar la construcción correcta. No hay ningún intermediario en este proceso – no hay ingeniero de construcción, no se requiere la aprobación del gerente. Con sólo pulsar un botón hemos desplegado el código que escribimos esta mañana (o hace media hora) a la producción!
Monitor
No quiero entrar en muchos detalles, pero sólo quiero mencionar: Cada equipo es responsable de su propio registro, monitoreo y alerta. Tenemos herramientas a nivel de sistema, pero la configuración de esas herramientas recae en cada equipo individual. Depende de ellos asegurarse de que su parte del sistema está disponible y funciona.
Enjabonar, enjuagar, repetir
Eso es realmente todo para el trabajo diario de un desarrollador en… En ocasiones hay reuniones puntuales, pero ¿quién quiere leer (o escribir) sobre ellas? La otra variación de las cosas discutidas anteriormente son las reuniones recurrentes. Cubriré un par más abajo.
Reuniones periódicas
Retrospectiva
La mayoría de los equipos tienen una retrospectiva semanal, pero algunos optan por retrospectivas bimensuales o continuas. Una retrospectiva es merecedora de su propio puesto, pero la vista de 10.000 pies es que proporciona una oportunidad para que el equipo mire hacia el pasado y hable de lo que salió bien y lo que no. Es una oportunidad para identificar formas de mejorar o engrasar las ruedas. No es un juego de culpas, sino más bien un momento para mirar hacia atrás como un equipo.
Las retrospectivas también pueden ser una gran herramienta en otros escenarios. Por ejemplo, un equipo puede realizar una después de la finalización de un proyecto específico (que puede abarcar un período más largo, como un mes o dos, e incluso entre varios equipos), o posiblemente centrada en un tema particular, como la entrega o la retroalimentación de los miembros del equipo.
Planificación
Algunos equipos tienen una reunión de planificación semanal. A diferencia de una típica reunión de planificación, aquí no hay un dimensionamiento o estimación formal. Es simplemente un momento para que todo el equipo se sincronice. Aquí hay algunos objetivos y criterios de salida para una reunión de planificación:* Asegúrate de que todos estén en la misma página sobre cuáles son las prioridades del equipo. * Asegúrate de que los desarrolladores entiendan todo lo que necesitan para poder recoger la tarjeta y empezar a trabajar en ella. Habla de las cosas que han surgido desde la última reunión de planificación y decide su prioridad. Generalmente, decidimos arreglarlos muy pronto o no hacerlo en absoluto. Si vale la pena arreglar un error, arréglalo ahora. * Realmente no hacemos atrasos aquí. Ciertamente no al nivel en el que tenemos que arreglarlos. Si ha surgido algo que otro equipo necesita de nosotros, lo discutimos en la planificación. Normalmente se prioriza para ser trabajado en la próxima semana más o menos.
Conclusión
La forma en que trabajamos ha sido en gran parte moldeada y decidida por nuestros desarrolladores. Valoramos el envío de software de calidad a nuestros clientes, y alineamos nuestros procesos y prácticas en torno a eso. En lugar de optimizar para los individuos, optimizamos para el sistema. Para más información sobre cómo trabajamos y las ideas que hay detrás de ellas, ¡mira otras entradas en el blog y fíjate en las nuevas!
Categorías: cultureTags: testing, emparejamiento, mobbing, integración continua, ágil