¿Cuál es el principal problema en el desarrollo de software (o tal vez en cualquier trabajo)? Cuando les hice una pregunta a mis colegas, recibí diferentes respuestas: cambios en los requisitos, desajuste de las expectativas, calidad del código, interacción con otros equipos ... en resumen: la comunicación es uno de los problemas más importantes.
Durante la comunicación, todos entienden todo a su manera, lo interpretan de manera diferente a lo que se dijo. El cliente guarda en su cabeza cierta imagen que está tratando de convertir en palabras e imágenes, el desarrollador, al escuchar estas palabras, las convierte en su cabeza en algún tipo de su propia imagen. Y en esta cadena puede haber muchos enlaces.
Intentando resolver este problema, la gente escribe un ToR detallado. ¿Pero esto resuelve el problema? Bob Martin y Martin Fowler, junto con sus colegas, hicieron las mismas preguntas, según veo, cuando escribieron el Manifiesto Ágil en febrero de 2001. Intentemos resolverlo juntos en este tema y en el manifiesto Agile.
La historia
En el invierno de 2000 hubo una reunión de los líderes de la llamada Programación Extrema, discutieron las metodologías de desarrollo y como resultado comenzaron a ofrecer algunas metodologías de Luz. Pocas personas estaban interesadas (no quiero ofender a nadie), lo más probable es que hayan hecho más bromas sobre este tema. Sin embargo, varios extraños de esa reunión organizaron la suya un año después. Todo comenzó con el hecho de que Bob Martin (escribió el famoso libro sobre la calidad del código), envió un boletín a los líderes de la última reunión: reunámonos y hablemos. En realidad nada concreto. Durante algún tiempo discutieron sobre el lugar y la hora. Como resultado, se reunieron el 11 de febrero de 2001 en Utah, en una estación de esquí. 17 personas del sector de desarrollo, incluidos Bob Martin, Martin Fowler y otros. Bebieron, Fowler fue a esquiar y, después de las discusiones, surgió el
Manifiesto Ágil .
En principio, todo lo más importante puede ser transmitido literalmente por una página de texto, que puede leerse
aquí .
Pero como todo breve y meticulosamente pensado, entender esto simplemente leyendo no fue fácil para mí personalmente. Por lo tanto, consideremos en detalle lo que esas personas que firmaron el manifiesto Ágil tenían en mente.
Principios ágiles
Es decir, sin negar la importancia de lo que es correcto,
sin embargo, valoramos más lo que está a la izquierda.
Este es un aspecto muy importante que siempre debe tenerse en cuenta al leer un manifiesto, y de hecho todos los días en el trabajo. Discutamos las principales declaraciones de manifiesto.
Las personas y la interacción son más importantes que los procesos y las herramientas.
A primera vista, esto puede parecer una llamada para descartar todos los proyectos de Jira, rastreadores de errores, registradores de tiempo y otras herramientas y todos los procesos configurados. Lo que podría ser más fácil es discutir verbalmente con sus colegas lo que alguien está haciendo. Si tan solo todos fueran felices. Pero se ve un poco utópico, ¿verdad?
Este principio sugiere que cuando se construye el proceso de desarrollo de cualquier cosa, es importante recordar por qué se hace, para quién y con qué propósito. Tiene poco sentido crear un proceso por el propio proceso. Debido a que el trabajo finalmente será realizado por personas, usted y yo. ¿Qué sucederá si toda la chispa, todo el interés en nuestros ojos se reemplaza por la tarea en el yutrek o los errores en el jir? No sirve para nada un proceso bien organizado que brinde seguridad completa ante el cliente, pero no resuelva problemas de desarrollo reales. Los detalles burocráticos (formales) pueden conducir fácilmente a la pérdida de personas en un proyecto. Tiendo a pensar lo mismo para la planificación. ¿Cuándo fue la última vez que hizo la planificación, que al final resultó ser precisa al menos 60-70 por ciento?
En mi opinión, este principio del manifiesto podría sonar así:
Procesos para personas, no personas para procesos
¿Cómo sugiere el manifiesto que nos acercamos a la implementación de este principio?
- Profesionales motivados deben trabajar en el proyecto.
- La comunicación directa es la más práctica y efectiva.
- Los mejores requisitos y soluciones arquitectónicas provienen de equipos autoorganizados.
- El equipo debe analizar constantemente su trabajo y optimizar el proceso.
¿Qué desarrolla el equipo en general? Producto para el cliente.
Un producto que funciona es más importante que la documentación completa
Si se interpreta como es, en la frente, creo que muchos estarán de acuerdo. ¿Pero qué más ves aquí? Personalmente, veo aquí que un producto que funciona, y funciona a
tiempo , es más importante que el código perfectamente escrito. Estas son palabras crueles y aterradoras en muchos aspectos, así que no debería decir eso. Pero toda mi carrera, aprendiendo de diferentes personas, me convencí cada vez más de la idea: si elijo entre un proyecto que es ideal en términos de código y arquitectura, y un proyecto que no es muy hermoso por dentro, pero que beneficia al mundo, elegiré el segundo. Y sí, lo mejoraré lo mejor que pueda.
Y aquí deberías pensar por un momento. Pero, ¿qué se puede hacer para que estos problemas sean menos comunes? ¿Para que no tengamos que elegir entre refactorizar un módulo y desarrollar una nueva característica?
- Un producto que funcione debe lanzarse con la mayor frecuencia posible.
- Un producto que funciona es un indicador clave de progreso.
- La atención continua a la excelencia técnica y la calidad mejora la flexibilidad del proyecto.
- La simplicidad y la minimización son necesarias.
Presta atención al punto sobre la excelencia técnica. Manteniendo el código en buena calidad (necesaria) y suficiente, es mucho más fácil tolerar cambios en los requisitos y, en consecuencia, cambios en el código.
Todos los principios, les recuerdo, no son negativos. Uno no excluye al otro. Esto se trata de priorización. Todo es importante: el producto, la calidad del código y la documentación. ¿Pero qué elegir, cuándo elegir? Trabajando en un cierto equilibrio entre calidad y producto, el producto es más fácil de priorizar, sin negar la calidad.
Como ejemplo de mi vida, recuerdo el trabajo en un proyecto bancario para un cliente ruso. El trabajo se realizó con la participación de analistas y estrictamente sobre conocimientos tradicionales volumétricos. Una vez cada seis meses, el gerente fue a la oficina central del cliente y mostró los resultados del trabajo. Es fácil adivinar que, por regla general, los resultados fueron significativamente diferentes de las expectativas del cliente. El contador del cliente, que vio por primera vez el nuevo sistema y, en general, sabía que se estaba creando, estaba horrorizado: no había nada como su proceso de trabajo habitual en el nuevo sistema. Lo que nos lleva al siguiente tema.
La colaboración con el cliente es más importante que negociar los términos del contrato.
Debes tener mucho cuidado con esta afirmación. Y nuevamente, recuerde que no se niega el lado derecho de la declaración. Por el contrario, decimos que el contrato es importante. Justo cuando sopesemos los términos del contrato y la cooperación, las asociaciones correctas a largo plazo, la relación será más importante. Sin negar el segundo. Llamo tanta atención a esto porque vivimos en el mundo real y, a veces, tenemos que trabajar con clientes muy diferentes. Hay casos en que el cliente, para sus propios fines egoístas, puede aprovechar la ingenuidad y, a expensas del contrato, vencer las condiciones que son inaceptables para los desarrolladores.
Sin embargo, si hablamos de cierto buen cliente abstracto
en el vacío , es más importante mantener una relación a largo plazo que conduzca a nuevos proyectos.
¿Cómo lograr la comprensión y el cumplimiento de las expectativas durante todo el proyecto?
- A lo largo del proyecto, los desarrolladores y representantes del negocio personalizado deben trabajar juntos todos los días.
- La comunicación directa es la más práctica y efectiva.
Al mismo tiempo, uno no debe olvidarse de confirmar los acuerdos por su propia seguridad. Por cierto, (afortunadamente raramente) hay clientes que generalmente se niegan a pagar después de los acuerdos.
Cualquiera sea el cliente, la actividad del desarrollador siempre es útil.
También agregaría por mi cuenta que esto debería funcionar en ambos sentidos.
Esto nos lleva a una continuación lógica: cambios en el trabajo y los planes. A pocas personas les gusta hacer cambios, si se piensa en la naturaleza del hombre. Cualquier sistema se esfuerza por alcanzar un cierto punto de equilibrio e inmutabilidad. Pero es el desarrollo el que siempre está asociado con el movimiento y el cambio.
La preparación para el cambio es más importante que seguir el plan original.
No se niega la existencia de un plan como tal. Por el contrario, el plan es importante. Pero es aún más importante estar preparado para cambiarlo, si en algún momento nos damos cuenta de que este plan ya no funciona en el entorno actual.
Un ejemplo de la práctica de mis colegas es un proyecto para una inspección fiscal de uno de los países de la CEI. El proyecto estatal, en esencia, los conocimientos tradicionales, la legislación, no se habló de ningún ágil. Pero el equipo tuvo que mostrar flexibilidad en el momento en que el estado en el país del cliente cambió su legislación fiscal para que el proyecto no tuviera ningún sentido en la forma en que fue planeado. Tuve que cambiar las especificaciones técnicas y rehacer el proyecto casi terminado para que el cliente pudiera usarlo. De lo contrario, no tendría sentido en el trabajo, bueno, excepto tal vez por las ganancias como tal.
Quizás este no sea el ejemplo más revelador, ya que los cambios fueron provocados por factores externos. Y, por otro lado, el cliente puede, nuevamente debido a factores externos, simplemente tener que cambiar los requisitos. De lo contrario, no obtendrá una ventaja competitiva.
Todo esto toca un tema un poco doloroso para mí. Pero, ¿qué pasa si estamos haciendo un proyecto durante todo un año, y luego, un año después, el cliente dice: está bien, eres genial y ahora pondremos todo esto en el archivo, no lo usaremos y comenzaremos un nuevo proyecto? Me duele bastante esto, tuve una experiencia similar. Pero realmente, ¿qué pasó? El trabajo realizado ayudó al cliente a comprender que la ruta elegida es incorrecta. O ineficaz. Para obtener una ventaja competitiva, debe trabajar de manera diferente, hacer otro proyecto. Y recibió este conocimiento con nuestra ayuda.
¿Qué aspectos de nuestro trabajo ayudarán a suavizar estos rincones y hacer que la flexibilidad sea menos aterradora?
- Entrega de software regular y temprana.
- Los cambios son bienvenidos incluso en las etapas posteriores.
- Los cambios ayudan a proporcionar al cliente una ventaja competitiva.
Al mismo tiempo, vivimos en el mundo real, con personas reales, donde ningún juicio, incluido esto, debe elevarse a lo absoluto. Sí, los cambios son bienvenidos cuando conducen a un valor agregado al producto final. Pero es importante mantener el equilibrio. Si hacemos cambios sin fin, nunca lanzaremos un producto en producción. Por lo tanto, en algún momento debería decir: deténgase, lanzamos el producto, verificamos todo en la práctica y comenzamos a hacer la versión dos, que contendrá estos cambios. Cada vez que aclara con el cliente, qué valor ve en este o aquel cambio.
Hace poco leí la frase en Facebook,
si no te avergüenzas de tu producto, entraste al mercado demasiado tarde
Con bastante precisión refleja la esencia de lo anterior. Necesitamos buscar un cierto punto de equilibrio, en el que el producto estará lo suficientemente listo para el próximo lanzamiento en términos de cambios, y en el que aún no hemos comenzado a gastar demasiado esfuerzo en cambios menores.
En lugar de resumir
Los creadores del manifiesto Ágil no prescriben ninguna regla, e incluso viceversa. Pero plantean cuestiones importantes en nuestro trabajo: la interacción de personas, desarrolladores y clientes, la disposición para el cambio. Estos principios son importantes en la naturaleza. Con la importancia innegable de la documentación, los contratos, los procesos y la planificación, la interacción humana, la preparación para cambios valiosos y aportar algo útil al mundo son aún más importantes.