"Entonces, quiero hablarles sobre Agile y Scrum ".
"A principios del siglo XXI, la forma en que la gente pensaba sobre la programación se puso patas arriba".
"Todos estaban convencidos de que la planificación a largo plazo no estaba funcionando, así que decidieron abandonarla por completo".
"¿Cómo hicieron eso?"
"Así es cómo."
"Inventaron el enfoque de gestión de proyectos más flexible posible".
Estas son las ideas principales detrás del desarrollo ágil :"
- las personas y la comunicación son más importantes que los procesos y las herramientas;
- un producto funcional es más importante que una documentación exhaustiva;
- colaborar con el cliente es más importante que cumplir con los términos de un contrato;
- la voluntad de cambiar es más importante que apegarse al plan original.
Estos son los principios del desarrollo rápido:
- satisfacer al cliente mediante el suministro de software valioso de manera temprana y continua;
- aceptar cambios en los requisitos incluso al final del desarrollo (esto puede aumentar la competitividad del producto final);
- entregar software que funcione con frecuencia (cada mes o semana o más a menudo);
- estrecha comunicación diaria entre el cliente y los desarrolladores a lo largo de todo el proyecto;
- el proyecto es trabajado por personas motivadas a las que se les brindan las condiciones de trabajo, el apoyo y la confianza necesarios;
- el método preferido para comunicar información es una conversación personal (cara a cara);
- el software funcional es la mejor medida del progreso;
- los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante por un período indefinido;
- enfoque constante en mejorar la excelencia técnica y el diseño fácil de usar;
- la sencillez es el arte de no hacer trabajo superfluo;
- los mejores requisitos técnicos, diseño y arquitectura provienen de un equipo autoorganizado;
- constante adaptación a las circunstancias cambiantes.
"El principal problema con el desarrollo de software fue que en ninguna etapa ninguno de los participantes tenía información completa sobre qué hacer".
"El cliente puede decirle cómo visualiza el programa, pero dejará algo fuera o dará algo por sentado".
"El gerente generalmente tiene que traducir los requisitos de la jerga de programación al idioma del cliente y viceversa".
"Hay demasiada incertidumbre".
"A menudo, los requisitos del cliente son así: hazlo de alguna manera, luego muéstramelo; si no me gusta, puedes rehacerlo".
"Eh... eso es horrible".
"Según el nuevo paradigma, los programadores ya no están desarrollando un producto o programa. En su lugar, están implementando la funcionalidad que el cliente necesita".
"¿Cual es la diferencia?"
"Bueno, supongamos que el desarrollo del programa solía tomar un año. Y tenían que pasar seis meses antes de que hubiera algo que mirar. Es como construir una casa grande: primero, cavas un hoyo para los cimientos, luego viertes los cimientos, los construir las paredes, el techo, las molduras, etc.”
"Pero ahora los programadores intentan liberar la funcionalidad necesaria lo antes posible. Esto sería como construir primero una choza, luego una casa rodante, luego una casa pequeña y luego una casa grande, a plazos".
"Teniendo en cuenta que es probable que el cliente no sepa exactamente lo que quiere, entonces este es un enfoque muy razonable".
"Supongamos que el cliente quiere un gran pabellón de caza".
"Los desarrolladores le construyen una pequeña. Vive en ella durante un invierno. Luego decide que no le gustan las casas de madera. Hagamos una de ladrillo".
"Vive cerca del lago durante un verano, pero los mosquitos se lo comen vivo. Había oído en alguna parte que los lagos son frescos, así que le apetecía tener uno. Pero ahora no quiere un lago. Y será más fácil de construir". la casa de esta manera: sin lago significa que no hay amenaza de inundaciones, y puedes construir la casa sobre el suelo en lugar de sobre pilotes, lo que será un 25% más rápido".
"Una analogía interesante. ¿Los clientes realmente cambian sus requisitos con tanta frecuencia?"
"Sí, pero el problema no es el cliente".
"Primero, es muy difícil imaginar cómo resultarán las cosas en el futuro. Los gerentes, evaluadores y programadores también hacen esto. También cambian de opinión dependiendo de cómo se desarrollen las cosas".
"En segundo lugar, ¿no son los requisitos del cliente lo que más importa? Después de todo , el objetivo de todo este trabajo es crear lo que el cliente necesita , no lo que inicialmente dijo que creara ".
"De hecho, solía funcionar así: los analistas comerciales hacían una lista de todos los requisitos. Incluían esta lista en un contrato, lo firmaban y trabajaban solo de acuerdo con la lista".
"Si a la lista le faltaba algo que el cliente realmente necesitaba pero había olvidado, nadie haría nada al respecto".
"Ya veo. Es más fácil seguir un plan, ¡pero no todo se puede hacer de acuerdo con un plan!"
"Exactamente."
"Es por eso que se inventaron los métodos de desarrollo ágil".
"Y hoy les hablaré sobre Scrum , el más popular entre ellos.
"La característica principal de Scrum es la división del desarrollo del proyecto en pequeñas iteraciones, generalmente de 2 a 4 semanas de duración. Cada iteración se denomina sprint".
"Al comienzo de un sprint, se lleva a cabo una reunión de planificación del sprint. Dura de 3 a 4 horas".
"Al final, hay una demostración de todas las tareas completamente completadas".
"Así es como todo suele funcionar:"
"Antes del primer sprint, el cliente (o un representante del cliente) forma una lista de requisitos, es decir, el conjunto de cosas que el programa debería poder hacer. Estos requisitos generalmente se denominan historias de usuario, y el cliente generalmente es llamado el propietario del producto ".
"Se le llama propietario del producto , porque el producto está escrito para él. Él, y solo él, define la lista de requisitos: qué, cuándo y en qué orden".
"Además, el propietario del producto generalmente asigna prioridades de tareas. Las tareas con la prioridad más alta se implementarán primero. La lista completa de requisitos también se denomina acumulación de productos ".
"Cuando comienza un sprint, todos se reúnen para una reunión. El scrum master , normalmente un miembro del equipo, suele dirigir la reunión. El objetivo de la reunión es seleccionar las tareas ( historia de usuario ) para el sprint actual (iteración de desarrollo). "
"Primero, el equipo asigna a cada tarea una estimación aproximada en días-hombre abstractos, también conocidos como puntos de la historia. Luego, el equipo decide cuántas tareas tendrán tiempo de completar durante el sprint".
"De nuevo, es el propio equipo el que decide cuántas tareas tendrán tiempo de completar durante el sprint".
"Digamos que el propietario del producto esperaba que el equipo seleccionara las primeras 7 tareas, pero seleccionó solo 5, luego las tareas 6 y 7 se posponen para el próximo sprint. Si eso no le conviene al propietario del producto , puede aumentar la prioridad de las tareas 6 y 7 para garantizar que se seleccionen, pero luego algunas de las otras tareas desaparecerán del sprint".
"El scrum master también puede proponer dividir algunas de las tareas en tareas más pequeñas y establecer diferentes prioridades para que el propietario del producto esté lo más feliz posible".
"Ese es el punto de la reunión: las tareas se pueden cambiar y dividir, las prioridades se pueden cambiar, etc. Este es el trabajo que no era visible al principio, pero que aporta mucho valor".
"Entendido. Es como conducir un automóvil. Incluso si inicialmente crees que solo necesitas seguir derecho, la realidad es que debes evitar constantemente los baches, girar a la derecha y a la izquierda, y pasar a otros o dejar que te pasen a ti".
"Si algo como eso."
"La lista de tareas elegidas para el sprint se denomina acumulación de sprint ".
"Los programadores deciden quién hará qué, y solo entonces se ponen a trabajar". Para mejorar la eficiencia, Scrum sugiere que se celebre una reunión de 5 a 15 minutos todos los días en la que todos puedan decirse qué hicieron ayer y qué están haciendo. va a hacer hoy".
"Trabajo en equipo. ¡Puedo respetar eso!"
"Para facilitar la visualización de las cosas, generalmente se recomienda mostrar el estado actual del sprint en un tablero especial:"
"Observe las tres columnas de la izquierda".
"Los nombres de las tareas abreviadas se escriben en notas adhesivas. Y las notas adhesivas se colocan en diferentes columnas según su estado (planeado, en progreso, terminado)".
"A la derecha, puede ver un gráfico de trabajo pendiente . Para cada día, este gráfico enumera las tareas que aún quedan por hacer. Idealmente, la cantidad de tareas incompletas se reduce a cero durante el sprint".
"Cuando termina el sprint, el scrum-master hace una demostración para mostrar la lista de todo lo que se ha terminado por completo".
"Luego realiza una reunión de retrospectiva del sprint, que también dura un par de horas. Durante esta reunión, los participantes suelen tratar de averiguar qué salió bien y qué (y cómo) se podrían haber hecho mejor las cosas".
"Por lo general, después de 2 o 3 sprints, puedes identificar y eliminar los principales problemas que impiden que el equipo trabaje de manera más eficiente. Esto conduce a una mayor productividad sin aumentar la carga de trabajo del equipo. Esto no era posible antes de la era de las metodologías ágiles " .
"A veces también se lleva a cabo una reunión de preparación durante el sprint. Su propósito es planificar el siguiente sprint. Los participantes suelen aclarar las prioridades de las tareas en esta reunión. También pueden dividir algunas tareas en partes y/o agregar nuevas tareas a la cartera de productos " .
"Bueno, eso es básicamente todo lo que tengo. Esto es solo una descripción general. Es imposible explicarlo todo en unas pocas palabras, pero puedes leer un buen artículo sobre el tema aquí:"
https://en.wikipedia.org/wiki/Scrum_(desarrollo_de_software)
GO TO FULL VERSION