Existe mucha bibliografía; muchos recursos en youtube; muchos cursos baratos, caros, re caros (NOTA: No pongo link a empresas o ganare detractores gratis jejeje. Pero, diablos que caros sus cursos.);
certificaciones caras.
El tema es que lo que debió ser vivir un manifiesto para...
"Estamos descubriendo formas mejores de desarrollarsoftware tanto por nuestra propia experiencia comoayudando a terceros. A través de este trabajo hemosaprendido a valorar:..."
Se ha vuelto un negocio a nivel mundial. En fin mi post querido lector es no desanimarlo a llevar cursos, comprar libros, al final es parte de la vida del informatico, si aparece algún framework, metodologia, lenguaje, habra negocio de por medio.
El tema al que voy es que quienes van por las metodologias agiles deben saber esto, que no solo basta saber lo teorico, hacer suya la filosofia agil, vivirla, en lo técnico tambien tenemos que andarnos con cuidado:
Product BacklogTal vez realizar el Product Backlog tenga algún nivel de complicación. Pero hay muchos casos en que no lo es. Lo que si tenemos que cuidar es en la priorización de las historias de usuario. La recomendación ahí es que los usuarios realmente utilicen las historias entregadas y que estas cumplan sus necesidades. Así que cuidado con simplemente desplegarla en el servidor de producción.
- Si usas Scrum cada X semanas se pondrá en producción una serie de historias de usuario de manera que los usuarios podrán comenzar a utilizarlas.
- Si usas Kanban terminada una historia de usuario (desarrollada, testeada) se pone en uso.
Lo que debemos saber a la hora de aplicarlos
Es se se necesita un entorno de desarrollo EXCELENTE y con conocimiento TECNICO de ALTO NIVEL.
Recordemos Scrum y Kanban no nos dice que usaremos en la parte técnica, por ese motivo muchos promueven el matrimonio Scrum y XP, Kanban y XP. Creo que no usamos RUP porque para los agilistas es como tener herpes jajaja.
Vayamos al grano, lo que se necesita que funcione muy bien (no regular, mas o menos, casi casi) es:
- En tus primeras iteraciones te puedes dar cuenta que el tiempo de 2 o 3 semanas es muy largo o muy corto. Y como te das cuenta que necesitas deployment continuo quieres ir al nivel de integración continua y tener todo casi automatizado.
- El tema tocado en el primer punto es el que me preocupa. Varias veces me han llamado para que instale un sistema de integración continua y cuando les pregunto si hacen pruebas unitarias o bueno aplican TDD. Me dicen "NO". Entonces si querias automatizar la ejecución de pruebas unitarias, ver métricas de tu código, estaríamos automatizando el conjunto nulo o vacío o como decimos en java apuntando a NULL y esperando que el garbage collector nos llegue en algún momento.
- Claro, tambien hay de los que si tienen o hacen TDD, pero, tambien esto requiere buenos conocimientos de programación orientada a objetos, uso de patrones, y frameworks para desarrollo y pruebas. Entonces aquí tambien tenemos un gran reto. Pasa que quieren aprender TDD pero carecen de lo mencionado. Recomendación: participar de coding dojos, hacer katas. Pero, nuevamente es un tema de aptitud, compromiso, filosofía aplicada. Si no estas involucrado, pues no lo haras.
- Tambien si estamos en un tema de deployment continuo, integración continua, se necesita usar repositorios de versiones como subversion, mercurial, git (tan de moda hoy con github.com, bitbucket.org o sourcerepo.com). Y se necesita no solo saber hacer commits, hacer merges a la linea base, se requiere trabajar con branches, descartarlos, fusionarlos con el master, abrir nuevos branches. Es decir toda una serie de conflictos hasta que se tenga un flujo de trabajo (workflow) que funcione.
- Tambien muy pocas empresas tienen un staging, que quiere decir eso? division desarrollo/pruebas/producción. Eso implica buenas configuraciones para desplegar tu app en cada servidor sin sufrir de stress o dolor. Si estas en este nivel es un WIN total. En caso contrario, como estarás en problemas, estarás perdiendo el tiempo en buscar "la configuración" o dejaras de hacerlo.
- Colaboración del cliente para darte el apoyo con los usuarios. Tu stakeholder, product owner o gerente que te contrato tiene que estar contigo. Si el no esta involucrado, pues a rezar, tu proyecto fracasara.
- Manejar bien la presión. Hay veces que los bugs, eventos inesperados aparecerán en tu proyecto. Así que debes tener este tema bien manejado. No quiero hablar del tema "recurso humano", pero hay gente que no soporta la presión. Esto escapa al tema ágil o técnico. Ha pasado que hay colaboradores que hacen freelance aparte del trabajo, tienen vida personal complicada. Todo esto se puede descubrir durante el proyecto y por mas motivación que haya puedes complicarte completamente. En fin ojala esto último no le suceda a nadie.
En fin lo bueno es que si vamos bien con todos los puntos mencionados, el CLIENTE nos tendra una confianza en que somos un buen proveedor. Que hacemos las cosas bien, que somos diferentes. Aunque al principio no daba ni 50 centimos por nosotros.
Ya para terminar lo que quiero decir es que "sin TECNICA no hay bala de plata para matar lobos".
Entonces en este punto querido lector diras: "entonces Jose, vale la pena las metodologias agiles, TDD, integración continua?"
Vale la pena si te consideras PROFESIONAL. Simple como el agua.
Estar en la búsqueda de mejores formas de desarrollar software. Si tu objetivo no es ese pues tal vez estes equivocado con la profesión.
Estar en la búsqueda de mejores formas de desarrollar software. Si tu objetivo no es ese pues tal vez estes equivocado con la profesión.
Estimado lector el camino tecnico es largo, no esperes tampoco a saber todo esto en primer lugar para luego aplicar agilismo. Aplicalo en todo momento, hasta para planear tu boda, tu curso de ingles, un evento, etc.
Sepan que el camino es arduo. Que lidiaremos con muchas cosas complicadas, pero, lo bueno es que sabremos hacer unas configuraciones/comandos/jobs de git, hudson como patear en los huevos a alguien. Así de facil y seras un profesional diferente.
Sino recuerda cuantas veces postulaste a la universidad. Valió la pena no? esto tambien valera la pena.
Sino recuerda cuantas veces postulaste a la universidad. Valió la pena no? esto tambien valera la pena.
Joe
0 comentarios:
Publicar un comentario