Terminé el curso de agilidad y lean de Javier Garzás
El nombre completo del curso se llama Agilidad y Lean. Gestionando los proyectos y negocios del siglo. XXI (7ª. edición) , este curso esta alojado en la plataforma Miriada X, en la cual ya había hecho anteriormente un curso de aplicaciones web para Firefox OS.
No se si la persona que lo creo tenga en cuenta que México es el país que mas horas trabaja de la OCDE o que sólo el 1.7% de las personas gana más de 20 mil pesos al mes(unos 875 Euros).
Lo anterior va por que a lo largo del curso se estudia los principios del manifiesto ágil, uno de ellos es Individuos e Interacciones sobre procesos y herramientas y vemos temas como el people ware, no trabajar mas de 40 horas por semana, niko niko para 'medir' la felicidad de los equipos, Kudo box para incentivar la motivación, auto organización, equipos pequeños, transferencia del conocimiento por medio de la programación en pareja y lo que le sigue a la programación en pareja llamado Mob Programming.
Se comienza con una animación sin sonido de un equipo de 3-4 personas que están por utilizar SCRUM para desarrollar un proyecto.
En la primera lección se hace referencia que debemos estar conscientes de que hacer software no es lo mismo que construir casas o carros, por que nuestro trabajo la mayoría de las veces es intangible, lleva un proceso de construcción intelectual, es una industria relativamente joven, el software es difícil de predecir, la agilidad no es para todos los proyectos, aunque debería estar presente en mas de los que esta hoy y se debe evitar tener un rambo(persona que es la única que puede modificar ese Stored Procedure de 20k de lineas) en el equipo.
En las lecciones 3( El “Product Owner” y las historias de usuario
), 4(SCRUM) y 5(La planificación ágil) se tratan temas muy ligados a SCRUM y a lo que se le podría llamar agilidad "clásica" , te enseña lo que es, las practicas y técnicas para estimar(Planning poker), organizar (Board, historias de usuario, juntas) y como medir el rendimiento de un proyecto(Burn down y Burn up), velocidad, así como algunos consejos y comparaciones con el ciclo de vida en cascada(historias de usuario vs casos de uso).
Después en las ultimas lecciones 6(Lean y Kanban) y 7(Deuda Técnica y Testing Ágil), hablan de cosas que vi en la facultad como Lean y sabia que de alguna forma se podía aplicar al desarrollo de software, pero nunca lo concretaron en ninguna clase, era mas para manufactura de piezas o productos de acero, cosas que realmente no me importan.
Entonces saltan nombres en el curso como Toyota y Deming hablando sobre el éxito de la calidad, los principios de la calidad y como se aplica al proceso de creación del software como un producto, eliminar el desperdicio, re aprendizaje, etc.
Aparece un concepto nuevo para mi llamado Kanban, que es la técnica principal de Lean, la traducción de Google es letrero, en el curso se maneja como tarjeta visual y trata de tener la visibilidad del trabajo, limitarlo y controlar el flujo del mismo.
Para la visibilidad del trabajo se habla de los elementos/ítems que tenemos como tareas, ya sea una historia de usuario, un issue, requisito, funcionalidad nueva, etc. Debemos definir les los estados en los que pueden estar y que significado tiene cada uno, ya que muchas veces lo que una persona del equipo entiende por terminado no es lo que otros piensan.
Por ejemplo yo puedo decir que ya esta reparado un error y hasta lo tengo en la rama de desarrollo, pero quizá si mi jefe me pregunta, el esperaría que ese reparado es por que ya esta en producción, con esto tratamos de evitar los malos entendidos.
También vuelve la importancia de los tableros en físico en el lugar de trabajo para que sea visible para todo el equipo y que tu tablero de SCRUM se vuelve casi lo mismo que un tablero de Kanban, la diferencia es que Kanban no limita por tiempo, cosa que SCRUM si, con los sprints.
En la limitación del trabajo trata el concepto WIP(Work In Progress, presente en Gitlab ), en el que no debemos de tener mas de "n" cosas sin terminar al mismo tiempo, se debe definir cuantas tareas pueden estar abiertas en cada uno de los estatus y respetarlo, para centrar el equipo en cerrar tareas, por eso de muchas tareas abiertas y ninguna terminada.
La última lección es más técnica y me da entender que no importa que metodología uses, ya sea tradicional o ágil, la excelencia tecnología es lo más importante.
Esto es así por qué si no controlas y mides la complejidad del código en tus proyectos, estos terminan arrastrándose como un zombi, en el que día a día se le van agregando pedazos y pedazos de parches y lo que antes te tomaba un día hacerlo, ahora te toma 2 semanas, ¿Les ha pasado?.
Aquí a los hacks, work arounds, métodos llenos de complejidad se les pone nombre y apellido, uno es el concepto de deuda técnica y el otro es el de la complejidad ciclomatica de los métodos o funciones.
La deuda técnica son nuestros pequeños pecados, que vamos dejando en el código para poder salir a producción, seguir operando, cosas que técnicamente están mal pero que por el contexto son necesarias.
Se explica similar a un crédito bancario donde adquieres deuda para poder ganar un beneficio a corto plazo, pero en algún momento tendrás que pagar sus intereses.
La complejidad ciclomatica en palabras simples es cuántos caminos diferentes pueden existir en tu código, estos caminos se crean por sentencias condicionantes o bucles.
Explicado lo anterior ¿por qué es tan importante mantener una complejidad ciclomatica baja?, La respuesta es que código simple es código sencillo de mantener y fácil de probar, debido a que también se aborda el tema de TDD(Test drive development), el cual evoluciona a BDD(Behavior Drive development).
El desarrollo dirigido por pruebas es una práctica que consiste en desarrollar las pruebas primero y después la implementación, seguido de un nuevo concepto llamado refactorización del código, en el que se pule el código, estás pruebas deben estar automatizadas y deben ejecutarse por lo menos diariamente al construir el ejecutable, aquí entra otro concepto técnico llamado integración continua.
La integración continua es una práctica de la cultura DevOps en la que se debe integrar el trabajo de todos los desarrolladores diariamente.
Veo que es un curso muy completo y vale mucho la pena si estas envuelto en esto del software, aunque no seas desarrollador, muchas técnicas e ideas de este curso te vendrán a la mente en el día a día de tu trabajo en los problemas de organización, normalmente los proyectos de software fracasan por mala organización, ademas se ve muy padre el certificado en Linkedin.