Ayer completé la tercer semana, durísimo. Tuve que ver 4 videos y hacer 5 ejercicios de programación, uno de los cuales me llevó varias horas debido a que la configuración provista en el código base del ejercicio no permitía ejecutar la aplicación en un emulador.
Hasta el momento el curso ha estado enfocado en cuestiones relacionadas a la arquitectura de las aplicaciones Android. Por lo poco que ví de la semana 4, parecer tratar sobre construcción de interfaces de usuario.
Continuará…
A partir de ciertos problemas de calidad en sus aplicaciones, al área de sistemas de una organización decide invertir en la adopción de ciertas prácticas. Trabaja durante un año adoptando prácticas y principios tales como integración continua, control de configuración, mejora continua, planificación adaptativa, automatización de pruebas, etc. Todo esto a la par de un cambio en el proceso de desarrollo y despliegue de las aplicaciones.
Luego de un arduo trabajo de un año todos los equipos de desarrollo de la organización han adoptado (en mayor o menor medida) la nueva forma de trabajo y las prácticas asociadas.
Un día llega un defecto crítico a producción: ¿qué es lo que debería hacerse?
¿que opinas tu?
Luego de investigar y hacer algunas pruebas de concepto, los alumnos eligieron construir la aplicación con Grails y AngularJS, una combinación con la personalmente no tengo experiencia pero que me gusta.
Respecto a la infraestructura, el repositorio será Git (github).
Respecto del build server y el ambiente de tests, yo tenía la ilusión de usar el servicio de CloudBees, pero los alumnos prefirieron ir con Travis y Heroku.
Hace aproximadamente año y medio me embarqué junto a otros 5 colegas de la UBA en el proyecto de escribir un libro sobre desarrollo ágil. Si, en total 6 autores lo cual ya de por si sólo significó un gran desafío. La idea no era hacer una compilación de escritos independientes, sino una obra integrada en la que todos los autores fuéramos responsables por la totalidad del libro y no sólo por las partes que escribió cada uno.
La semana pasada finalmente entregamos el manuscrito a la editorial. Aún nos queda un buen camino por recorrer, la parte más trabajosa (al menos para los autores) parece haber quedado atrás.
Entre las cosas que nos quedan por hacer, está la definición del título del libró, una cuestión no menor.
Continuará…
La Facultad de Ingeniería de la UBA, tiene en curso un programa de estímulo a la graduación de estudiantes. Dicho programa está apuntado a aquellos estudiantes que se encuentren próximos al final de su carrera y que por una u otra razón hayan interrumpido sus estudios. El estímulo consiste en el pago de un monto de $25.000 para aquellos que efectivamente se gradúen.
Pueden encontrar más información en la página de la facultad.
Completé la segunda semana del curso: 4 videos, un par de ejercicios de programación y un cuestionario. Tuve que invertir casi 3 horas.
Me pasa que cuanto más avanzo más dudas me van surgiendo, lo cual en un contexto así lo interpreto como un buen síntoma.
Por lo que visto hasta el momento me va gustando mucho la arquitectura de Android. Aún no me cierra el emulador, tarda demasiado en levantar. Voy a investigar un poco más pues tiene que existir alguna alternativa mejor, me recomendaron usar el emulador de Genymotion, lo voy a probar y les cuento.
Continuará….
Acabo de completar la primer semana de este curso. Me llevó unas 4 horas de estudio entre videos, cuestionarios, tareas de programación y configuración/troubleshooting de las herramientas de desarrollo.
Por ahora viene bastante tranquilo, lo cual es lógico para ser la primer semana, pero pinta realmente muy interesante.
Si quieren aprender Android, creo que aún estan a tiempo de sumarse al curso.
Continuará…
Hace unos días comencé a hacer un curso de Coursera sobre programación de aplicaciones Android. A la hora de hacer las tareas de programación me encontré con algunas dificultades técnicas en mi ambiente de desarrollo cuya solución comparto aquí.
Para desarrollar aplicaciones Android es necesario el uso de un kit de desarrollo (Android SDK) que incluye entre otras cosas el ADT: Android Development Tools, básicamente un Eclipse personalizado.
La primer dificultad que encontré fue que el material del curso está basado en el SDK 4.3 de Android mientras que el SDK actual es el 4.4. Esta diferencia de versiones generaba algunos warnings en código del curso. Para evitar posibles futuros inconvenientes debidos a la diferencia de versión, decidí instalar el SDK 4.3. Esto lo hice utilizando el SDK Manager que es parte de ADT.
La segunda dificultad que encontré fue la velocidad del emulador. Un desastre, por un lado el emulador tardaba mucho en iniciar y luego, una vez iniciado, cada interacción llevaba más de 10 segundos. Investigué un poco y encontré que debía instalar el paquete Intel Hardware Accelerated Execution Manager. Para mi sorpresa, una vez instalado este paquete, la situación emperó, cada vez que iniciaba el emulador de Android, mi maquina quedaba totalmente colgada obligándome a reiniciarla. Luego de probar algunas variantes de configuración, me puse a googlear y descubrí que otras personas ya habían experimentado mi misma situación. Al parecer hay un problema conocido entre MacOS Maverick y el paquete Intel Hardware Accelerated Execution Manager 1.0.6 (R3) que yo había instalado. La solución consistió en instalar este hotfix del paquete de Intel. Luego de instalar esto, el desempeño del emulador mejoró notablemente.
Si tuviera que definir un hito punto de inicio de la comunidad ágil de Argentina, sin duda diría que ese hito fue la Conferencia Latinoamericana de Métodos Ágiles, Agiles 2008. Luego de ese evento, comenzamos con las reuniones mensuales de la comunidad ágil de Buenos Aires.
Recuerdo que la primer reunión estuvo dedicada a debatir sobre lo discutido en el panel de cierre de Agiles 2008 en el que habían participado los Poppendieck y Tobias Mayer entre otros. También recuerdo que no pude asistí a ese encuentro :-(.
Ya en 2009, empezamos con eventos en formato Open Space. El primero fue el Agile Open Buenos Aires 2009. Para mi el evento fue un éxito total, si les interesa pueden leer algunos posts que escribí en aquel momento. Luego de este evento realizamos lo que denominamos el «Agile Open Tour» que consistió en hacer eventos Agile Open en distintas ciudades del interior del país. Entre las ciudades que visitó el tour en todos estos años se encuentran: Buenos Aires, Córdoba, Tandil, Bahía Blanca, Tucumán, Rosario, Paraná, La Plata y Mar del Plata. En varios casos estos eventos fueron el punto de partida para la conformación de comunidades locales.
Hasta el 2010, la comunidad éramos básicamente un grupo de entusiastas autoorganizados con ganas de compartir inquietudes, experiencias, conocimientos y aprendizajes. Esto estaba muy bien, pero no contábamos con ningún tipo de estructura organizacional lo cual resultaba un inconveniente en ciertas situaciones . Un ejemplo de estas situaciones fue cuando organizamos la conferencia Agiles 2008. Algunos de los sponsors de la conferencia pagaban en especias haciéndose cargo de algún gasto del evento. Pero otros aportaban directamente dinero y esperaban una factura de parte de la organización, ¡oops!. Este fue el principal motivo que nos llevó a pensar en la necesidad de contar con una estructura organizacional. Básicamente teníamos dos opciones: armar una asociación civil o bien sumarnos a alguna asociación ya existente como ser IEEE o SADIO. Finalmente fue SADIO.
SADIO es la Sociedad Argentina de Informática, una institución que desde 1960 realiza diversas actividades relacionadas a la difusión de la informática. Posiblemente la actividad más importante sean las Jornadas Argentinas de Informática e Investigación Operativa que año a año reunen a investigadores y profesionales de la informática. SADIO prevé en su estatuto la existencia de grupos de interés denominados divisiones. Lo que nosotros hicimos fue crear la División Ágiles Argentina. Para ello, unos 15 participantes de la comunidad ágil nos asociamos a SADIO y completamos las formalidades para dar origen a la división.
Como comunidad, el ser parte de SADIO nos brinda una estructura organizacional que nos facilita la organización de actividades, como fue el caso de Ágiles 2011, Ágiles 2012 y el Scrum Gathering de Buenos Aires en 2012. Como individuos, el estar asociados a SADIO, brinda descuentos para la participación en eventos/cursos/actividades así como también el acceso a una serie de recursos de la institución.
Desde que somos parte de SADIO hemos participado activamente de las Jornadas Argentinas de Informática, dando cursos de agilismo en el contexto del Simposio de Ingeniería de Software (ASSE). Adicionalmente, en 2013 algunos miembros de ágiles argentina han dictado cursos en SADIO, una actividad que esperamos se repita durante 2014.
La comunidad no tiene un espacio físico, pero si un espacio virtual que está dado por una página y una lista correo, cuya dirección se encuentra en la página.
Agile Open Tandil 2011
Este es un tema que suele prestarse a debate cuando se habla de métodos ágiles. En diversas ocasiones he escuchado afirmaciones tales como:
Los métodos ágiles no sirven para proyectos grandes.
o
En mi equipo no podemos aplicar métodos ágiles porque somos 50 personas.
Quiero dedicar algunas líneas para desmistificar estas cuestiones.
Respecto del tamaño de los proyectos, en primer lugar debemos dejar en claro qué define el tamaño de un proyecto: ¿mucho presupuesto? ¿mucho alcance? ¿mucha gente?. Podríamos decir que el tamaño de un proyecto está dado por su alcance. Naturalmente la cantidad de personas involucradas y el presupuesto del proyecto suelen ser proporcionales al alcance del mismo.
Aclarado qué entendemos por tamaño, podemos entonces preguntarnos ¿existe alguna limitación de tamaño para aplicar métodos ágiles? La respuesta es no. Entonces ¿puedo hacer proyectos de cualquier tamaño usando métodos ágiles? Tampoco.
La cuestión pasa una vez más por el desarrollo iterativo incremental y los ciclos de feedback. En este sentido la propuesta del agilismo es particionar un proyecto grande en varios proyectos pequeños, trabajando en forma iterativa con versiones incrementales que incorporen el feedback en forma temprana.
¿Y que hay del tamaño de los equipos? La respuesta a esto se deriva del párrafo anterior, si trabajamos en proyectos chicos tendremos entonces equipos chicos. Suele decirse que el tamaño de un equipo debe ser tal que lo puedas alimentar con dos pizzas.
Blog de NicoPaez 