Tabla de contenido:
Ser un equipo de desarrollo de software ágil ciertamente significa cosas diferentes para diferentes personas. Hay grados de adopción en un espectro muy amplio, y aparentemente muy pocas organizaciones piensan que lo hacen bien. Según la encuesta State of Agile de VersionOne (publicada en abril de 2017), el 80% de sus encuestados dicen que están "en un nivel de madurez o por debajo de él". Desafortunadamente, los equipos de desarrollo a menudo no ponen mucho esfuerzo en la parte de "aprender" de la iteración. Queremos darnos prisa y terminar las ceremonias de Scrum para que podamos volver a escribir código. Después de todo, ¡hay mucho trabajo por hacer! Pero, ¿es realmente el problema el tiempo de codificación insuficiente?
Para muchos de nosotros, la lucha contra incendios también podría incluirse específicamente en la descripción de nuestro trabajo. Vamos a trabajar todos los días sabiendo que tenemos que estar listos para deslizarnos por el poste en cualquier momento, agarrar nuestros sombreros y saltar al camión. Lo aceptamos tal como son las cosas y asumimos que no hay nada que podamos hacer al respecto. Pero, ¿y si la causa fundamental de nuestras luchas es una grave falta de eficiencia? Todo el mundo sabe lo importante que es hacerlo mejor que esa otra empresa de allí. Parece que no podemos llegar allí, parece que no tenemos el ancho de banda. Los gerentes agregan más personas y aumentan el tamaño de sus organizaciones y aún tienen las mismas luchas. Parece que no puede superar el obstáculo porque sus equipos no están desarrollando software de manera eficiente (y no está solo).
Principios del desarrollo eficiente
Pixabay
Entonces, ¿qué nos hace ser ineficientes? Para la mayoría de nosotros, lo primero que nos viene a la mente es la falta de automatización (compilaciones, implementaciones, pruebas automatizadas). "Una vez que tengamos suficiente automatización, la vida mejorará". Desafortunadamente, eso es solo una parte de la solución. Considere el efecto de la reelaboración en su proyecto. La forma más eficaz de crear una función es hacerlo correctamente una vez y nunca volver a tocarla. Los errores, la refactorización y otras actividades similares esencialmente están reabriendo al paciente después de que ha salido de la sala de operaciones y existe un riesgo inherente asociado con eso. No podemos eliminar el reproceso, pero ciertamente debemos esforzarnos por minimizarlo.
"¿Pero ágil no acepta la reelaboración (por ejemplo, la refactorización)?" De hecho, lo hace de alguna manera, porque los creadores de Agile entendieron que dos causas clave de reelaboración son circunstancias imprevistas y requisitos comerciales cambiantes. Resulta que los humanos son terribles para predecir el futuro. Los creadores ágiles también entendieron que un gran contribuyente a la ineficacia es lo que los desarrolladores llaman "chapado en oro": empaquetar la funcionalidad que creemos que alguien usará aunque los usuarios finales nunca lo hayan pedido. Es como un cerdo para su producto de software: una completa pérdida de tiempo. "No construyas una estación espacial cuando todo lo que piden es un Volvo". Por lo tanto, las empresas comenzaron sabiamente a dejar de lado la carne de cerdo y adoptar la refactorización en su lugar, solo agregando funcionalidad cuando hay una necesidad clara. Pero la imprevisibilidad de la vida no es el único factor que impulsa el retrabajo, ¿verdad?
Los detalles perdidos en cualquier etapa del desarrollo de funciones en última instancia, harán perder tiempo y dinero. Colaborar de manera efectiva desde el principio, con el tiempo, le ahorrará un montón de reelaboración (lidiar con requisitos omitidos, un diseño miope, etc.) Todos tenemos puntos ciegos y todos necesitamos pares de ojos adicionales. Muchos equipos de desarrollo adoptan esto en el back-end durante la revisión del código, pero dedican mucha menos energía a colaborar desde el principio cuando los problemas se pueden resolver de forma económica y con una inversión mínima.
¿Cuántas veces ha implementado una función y ha encontrado fallas importantes cerca del final que deberían haberse detectado durante las discusiones de requisitos / diseño? Es como intentar conducir de Atlanta a Montgomery y darse cuenta de que, después de varias horas de viaje, condujo accidentalmente a Birmingham. ¿Cuánto tiempo se dedicó a intentar obtener el código correcto solo para volver a abrir al paciente más tarde porque se omitieron requisitos importantes? Aprovechar la inteligencia colectiva absolutamente ahorraría tiempo y dinero, pero en cambio, los desarrolladores a menudo trabajan en funciones de forma aislada.
Enjambre tradicional
Pixabay
El enjambre tradicional significa que el equipo trabaja en colaboración en historias con varias personas que trabajan en una función pequeña al mismo tiempo, acortando el ciclo de retroalimentación y reduciendo el tiempo total de finalización de la función (es decir, dividir y conquistar). Esto es esencialmente un enjambre dentro de cada disciplina (desarrolladores de backend, desarrolladores de UI, etc.). Antes de que comience el desarrollo, los desarrolladores de la interfaz de usuario trabajan para identificar tareas independientes que se pueden realizar al mismo tiempo. Discuten los puntos de la interfaz para que cada persona sepa cómo encaja su pieza en el todo. Luego, los miembros del equipo pueden continuar con la finalización de sus tareas asignadas y unir todo al final durante la integración. Las confirmaciones frecuentes y las revisiones periódicas del código ayudan a garantizar que todo se mantenga sobre los rieles. Este enfoque requiere la colaboración entre los desarrolladores,lo que ayuda a producir un mejor resultado final de todos modos. A menudo priorizamos el tiempo dedicado a escribir código (cualquier código) sobre el tiempo dedicado a asegurarnos de no escribir el código incorrecto. Cuando se considera el tiempo potencialmente ahorrado, el valor se vuelve claro.
Desbloquear
Pixabay
Otro enfoque valioso para el enjambre es enfocar al equipo desde el principio en la mitigación de la dependencia para facilitar el desarrollo simultáneo en todas las disciplinas. Considere el flujo de desarrollo natural de una función de interfaz de usuario. Los probadores de automatización (SDET) dependen de una interfaz de usuario en funcionamiento para realizar las pruebas, los desarrolladores de la interfaz de usuario dependen de una API de backend que funcione y los desarrolladores de backend dependen de la configuración, las actualizaciones de la base de datos y las compilaciones / implementaciones automatizadas. Por lo tanto, es posible que los desarrolladores de UI no comiencen su trabajo hasta que las API estén listas y los SDET no comiencen su trabajo hasta que la función esté completa. Cada disciplina trabaja de forma aislada, lo que dificulta la colaboración porque las personas con las que necesita interactuar están ocupadas trabajando en otras cosas.Pero, ¿y si pudiera mitigar las dependencias antes y permitir que todas las disciplinas trabajen simultáneamente en la misma función?
Aquí hay unos ejemplos:
1. UI funcional implementada con stubs
Para desbloquear SDET, los desarrolladores de UI pueden proporcionarles una UI funcional que funcione lo suficiente como para permitirles escribir pruebas. La integración de la API de backend y los estilos CSS aún pueden estar pendientes, ya que a los marcos de prueba automatizados como Selenium no les importará si esas cosas están sin terminar. Todo puede ser humo y espejos. Si bien pueden ocurrir cambios que causen algunas modificaciones, el beneficio de comenzar las pruebas temprano supera ese riesgo.
2. API de backend implementadas (datos codificados de forma rígida)
Proporcionar API de back-end con las que los desarrolladores de UI pueden probar permite la detección temprana de problemas de integración entre el front-end y las API. A veces, descubre que la API proporcionada no satisface las necesidades de los desarrolladores de aplicaciones para el usuario. Es posible que falten llamadas completas, que la firma sea incorrecta o que la estructura de los datos tenga problemas. Si hay una desconexión, es mejor que lo averigüe antes de que nada se haya endurecido.
3. Cree una versión HelloWorld de nuevas aplicaciones y servicios.
Si se necesita un nuevo servicio (por ejemplo, un microservicio), cree el repositorio y cree una versión de "hola mundo" del servicio. Esto permite que los recursos de desarrollo se inicien en los trabajos de Jenkins y los scripts de implementación antes de que se desarrolle realmente el servicio.
Estas optimizaciones facilitan un ciclo de retroalimentación inicial en el que alguien puede decir "Necesito algo diferente" antes de que se complete el desarrollo del componente que requiere el cambio.
Envolviendolo
Es increíblemente importante que descubramos cómo acortar el tiempo de comercialización de las funciones en las que estamos trabajando. La empresa no obtiene ningún valor por tener un montón de funciones en progreso, y los desarrolladores necesitan desesperadamente que las funciones se implementen rápidamente para que los defectos puedan resolverse lo más cerca posible del punto de inyección. Los desarrolladores también necesitan desesperadamente interactuar entre ellos, aunque todo lo que realmente quieren hacer es escribir código. Es mejor para todos los involucrados, incluido el usuario final que solo quiere un producto mejor. Si no se lo da, irán a otro lugar para encontrarlo.
Swarming es una herramienta extremadamente valiosa en la caja de herramientas de su organización, si las personas se toman el tiempo para aprender cómo hacerlo. No es un marco ni siquiera una actividad, es una forma de pensar. Para cada historia de usuario, los miembros del equipo se hacen dos preguntas:
- ¿Cómo organizamos las tareas de esta historia para que varias personas contribuyan a la vez?
- ¿Qué es lo mínimo que debo hacer para desbloquear a alguien que me está esperando?
¿Qué pasaría si su equipo creara funciones rápidamente en conjunto en lugar de crear lentamente un montón de funciones de forma independiente? De hecho, podrían responder a los requisitos comerciales cambiantes y satisfacer las necesidades de la empresa cuando la empresa las necesite. Los competidores te temerían, los clientes te amarían. Esa es una receta para un negocio exitoso.
© 2017 Mike Zapatería