sábado, 27 de junio de 2009

Panel CMMI vs Ágil (2/2)

Voy a comentar algunas de las preguntas que nos hicieron al panel (parte 1: resumen de las presentaciones del panel) y algunos pensamientos y situaciones que tuve luego del evento.

asistente: ¿Puede aplicarse ágil en grupos grandes?
yo: ¿qué es grande para vos?
asistente: El sistema de defenza de China
(no conteste, alguien más lo hizo)

Ugh? ¿acaso estaría esa persona en ese equipo? ¿si no, que interés práctico puede tener una pregunta así? Mi hipótesis es que hay una suposición subyacente: lo que es bueno a un proyecto enorme, debe ser bueno para un proyecto chico. Según esta hipótesis, los problemas de escalamiento sólo se darían al agrandar, no al achicar.

asistente (otro):¿cómo logro con ágil que todos los equipos trabajen en forma similar?
yo: ¿Por qué querés que trabajen en forma similar?
asistente: la compañía tiene que tener una forma definida de hacer las cosas
yo: ¿Qué valor de negocio tiene eso? (y comenté el caso de Toyota, en el que cada planta que hace el mismo vehículo tiene layout diferentes, y cada uno es óptimo en cuanto a condiciones locales)
asistente: pero los trabajos que hacen deben tener algo en común ...
(perdí la atención del asistente, y el hilo del diálogo fue hacia otro lado)
¿Por qué la unificación de las formas de trabajo es visto cómo una verdad indiscutible?

La semana pasada estábamos en una clase de la facultad, en la simulación de una retrospectiva. El problema a resolver era: requierimientos muy cambiantes.
alumno: una mejora sería "estandarizar el proceso de elicitación de requerimientos"
yo: ¿Por qué te parece que esto resolvería el problema?
alumno: está muy estudiado como deben obtenerse los requerimientos. Deberíamos incorporar esto a los procesos.
yo: ¿Pero eso ya se hace en la compañia?
alumno: ...
yo: Digo, porque si decimos que queremos estandarizarlos es porque en algún área o grupo ya se están aplicando y queremos llevarlo a otros, no?
alumno: ...
yo: Si no se usaron nunca, quizás debiérmos probarlos en algún grupo, antes de estandarizarlos
alumno: (cara de no estoy de acuerdo con lo que decis pero sos el docente)
Ya no es sólo la unificación dentro de una compañia, sino la unificación a nivel industria. Implísita está la idea de que debe haber sólo una forma de manejar los requerimientos.

Paréntesis
Recientemente me prestaron Artful Making, espero postear más extensamente sobre el libro, pero para este post basta con comentar que los autores plantean que hay dos formas de hacer las cosas: Artful Making, muy ligada a la innovación, con costo de iteración y de error bajo (ejemplos: teatro, software, estrategias corporativas); e Industrial Making, que es lo que ha tenido tanto éxito (revolución industrial), que nos parece como natural e innegable (producción en serie, economía de escala).

¿Qué encuentro en común en las sitiaciones descriptas arriba?
La idea de "la mejor solución". Esta es una visión Taylorista, en la que alguien pude analizar el problema y encontrar la mejor forma de hacerlo. Por lo tanto, los operarios deben seguir al pié de la letra esa solución, ya que es la mejor.
Esto tiene dos problemas: por un lado, si estamos en una situación que permitiría usar Artful Making, lo estamos perdiendo. Por otro lado, si estamos en una situación de Industrial Making, nos quedamos con métodos de principios del siglo XX. Todo lo aprendido a partir de los '60 por los japoneses, y a partir de los '80 por el resto del mundo, no lo aplicamos: Lean Production.

¿Es esto un problema?
¿Es un problema que algunas personas mantengan la idea de "la mejor solución"? Vuelvo sobre mi post CMMI y Agile, y le doy otra vuelta de tuerca, porque voy a tocar el proceso de evaluación.
En una charla con Mary Poppendieck, ella comentó los efectos nefastos y no deseados de las certificaciones: se incian tomando las buenas prácticas, se estandarizan, se instruye a los evaluadores y se los controla para evitar desvios y subjetividades, esto pone restrincciones externas a las empresas, que para no perder su status (certificación) establecen áreas internas que replican la idea de evaluadores que controlan el cumplimiento.
Todo esto genera una gran inercia. Si una empresa quiere innovar tiene que convencer a sus auditores, que tendrán que convencer a los evaluadores, que tendrán que convencer al organismo originador del estandar.

En el panel, yo noté exactamente esa dinámica. El movimiento ágil se desarrolló casi totalmente fuera del alcance del SEI y las empresas CMMI. Luego que tomó fuerza, se hizo notorio que es algo bueno, por lo que muchas empresas emprezaron a usarlo y el SEI se puso a trabajar (luego que las ideas llegaron al mainstream) en mostrar que CMMI no es incompatible con Ágil. Y ahora está tratando de convencer a sus evaluadores de esto (y le cuesta).

Replanteando la pregunta, ¿será que por construcción el CMMI refleja el mainstream, lo común, y no fomenta la innovación?
¿Puede incorporar el estado actual de las prácticas ágiles, pero inmediatamente lo congelará como el nuevo estándar, sólo para ser superado por las empresas que no son CMMI?

Panel CMMI vs Ágil (1/2)

Hace un mes tuve la suerte de participar en un panel organizado por Liveware sobre CMMI y Desarrollo Ágil.
Asistió mucha gente, creo que con alto porcentaje de gente de áreas de mejora de procesos, y por lo tanta bastate CMMI.
Antes del panel huvo una presentación de Jorge Boria sobre la evolución de la Ingeniería del Software, para poner en contexto la aparición de CMM/I y de Agile Software Development, explicando brevemente Scrum y XP, y relacionándolos con ideas previas. Es muy dificil hacer todo esto en 2 hs, exige un nivel de síntesis muy grande. Creo que Boria logró hacerlo bien. Algunos puntos de Scrum y XP yo los habría comentado distintos, lo que me pasa con cualquier discertante.
Luego fue el panel, muy bien moderado por Alejandra Goldin (Liveware). Sobre el panel voy a comentar mi resumen, y en otro post algunas preguntas que se hicieron e ideas que me surgieron, todo filtrado por mi subjetividad y memoria. Espero que los otros panelistas y asistentes me corrijan.
Esteban Zuttion (Liveware): planteo el enfoque que tanto el modelo CMMI como las ideas ágiles pueden ser útiles en la mejora, y que ser evaluados con cierto nivel de CMMI puede tener beneficios de negocio. Que se hace es una decisión que debe analizarse con respecto a la estrategia de la compañía y las necesidades del negocio, como algo absoluto.
Martín Salías (Southworks): comentó que las prácticas ágiles soportan los objetivos de CMMI, incluso las métricas. Se generan un montón de datos como subproducto de las prácticas ágiles (nro de build rotos, % cobertura, etc). Comentó que en algunos casos no hay métrias pero las prácticas pueden equipararse a métricas (me hubiera gustado que se explayara en esto).
Santiago Ceria (Hexacta): Si uno aplica la típica combinación ágil de Scrum + algunas prácticas de XP logra un buen cubrimiento de los Niveles 2 y 3 de CMMI, en particular Scrum con prácticas de Nivel 2 y XP con las de Nivel 3. Digamos por ejemplo que la cobertura es de un 50%. El tema es que al implementar el resto de las prácticas que pide CMMI, se deben hacer cosas que presentan incompatibilidades con los principios ágiles expresados en el Manifesto. En particular mencioné la cantidad de documentación que hay que generar, el concepto de Quality Assurance que es incompatible con el principio de “trust” y la presencia por todos lados en CMMI de cosas que llevan a una implementación de una organización jerárquica (“senior management”, “Project manager”, “Project leader”, “team leader”) que es incompatible con las estructuras horizontales auto organizadas propuestas por los métodos ágiles.
Juan Gabardini (Agilar): hablé sobre lo extraño que es ver que, partiendo de premisas parecidas (mejoras continua, Deming), se llegan a culturas a primera vista tan distintas. Me pregunto si esas diferencias culturales son compatibles en una misma organización, si una de las culturas se impondrá o si surgirá una nueva cultura que sea la síntesis de ambas. Más detalle de mis 10 min aquí.
Mariela Rodriguez (Globant): después de mi vuelo estratosférico, Mariela comentó la realidad de Globant, en la que se realizan proyectos de desarrollo ágil aún con contratos de tiempo y costo cerrado. Hay reuniones periódicas, se muestra producto y se puede agregar nueva funcionalidad ... siempre que se saque otra. Algunos puntos muy interesantes: no lo pueden hacer con todos los clientes, algunos no quieren esto de reunirse cada mes. Y por otro lado, los equipos que trabajaron agilmente no quieren trabajar de otra forma.
Viviana Rubinstein (Liveware): tomó el guante de Santiago y diferenció claramente entre la evaluación y el modelo CMMI. En su punto de vista, el modelo no tiene conflictos con el desarrollo Ágil, pero la evaluación si. Me encantó una frase: "Cuando algún evaluado empieza a quejarse sobre lo que tiene que hacer (para que la evaluación de cierto nivel) le digo: yo estoy acá porque vos me llamaste"
También refutó a Santiago sobre la obligatoriedad de algunas actividades. No puedo opinar sobre este cruce, no tengo conocimiento. Resumen: si querés ser evaluado, y si, te va a salis más caro que si no lo haces.

Finalmente Alejandra resumió nuestras ideas y rescató la cercanía de las mismas.

Fue muy interesante participar, y me dejó pensando, con los resultados que pueden verse en este post.

miércoles, 24 de junio de 2009

Juegos en educación

En la enseñanza de el desarrollo ágil solemos usar actividades lúdicas (también llamados juegos :D).
En los cursos oficiales de Certified Scrum Master suelen usarse. En los cursos de Scrum que yo doy (no oficiales) uso juegos. También los aplicamos en las clases de la materia Administración de Proyectos Informáticos II - FI UBA. El juego del Pajarraco (una versión del XPGame hecha por Alan Cyment, pueden ver algunas fotos aquí) lo uso en toda ocasión en que necesito explicar desarrollo iterativo e incremental.
El IEEE tiene un programa (
TISP) orientado a acercar a los estudiantes secundarios a las ingenierías a través de juegos.

Hay muchos más, y paso una lista de recursos para los que les interese.

Para los que quieran recursos,
http://blog.tastycupcakes.com/ (el caso de Mr Happy Face)
http://wilderdom.com/games/InitiativeGames.html
http://www.dosideas.com/wiki/Juegos_Agiles
http://www.tryengineering.org/

martes, 23 de junio de 2009

Agile Open La Plata

El sábado nos reunimos en la Universidad Católica de La Plata unas 70 personas para intercambiar experiencias sobre el desarrollo ágil de software.
Como en todos los casos en los que participé (Buenos Aires, Córdoba, Tandil), la experiencia fue muy buena. Las gente es entusiasta, y se crea un clima de aprendizaje muy bueno.
Verán en las fotos que no logramos hacer que la sesión inicial y el cierre fueran con un círculo plano. Sin embargo esto no afectó el funcionamiento. Además, hacer las sesiones en un museo, entre pinturas y esculturas, le dió un toque interesante. Podríamos haber usado el patio, pero estuvo lloviznando de a ratos.
Martín Alaimo facilitó la apertura y las dinámicas de las sesiones, mientras que Diego Fondevila facilitó el cierre.
Apertura: En la apertura, tardamos en votar y en armar la agenda. Creo que fue por no tener suficiente lugar para que varias personas estén paradas frente al mercado o a la agenda. La gente para votar se toma un par de minutos, leyendo las propuestas. Esto es algo parecido a lo que pasó en Córdoba. Pero no encontramos mucha alternativa.
Las sesiones salieron rápidamente, sin miedo. Pero también se cortaron rápido. No fue necesario descartar sesiones, cuando se unieron las similares, había suficientes slot para todas.
Sesiones: a diferencia de otros AO, no estuve en ninguna sesión con poca gente (menos de cuatro). Las sesiones fueron muy buenas. Tuvimos el juego del pajarraco, que facilitó Nico Paez, pero pasé a tomar fotos.
En otra sesión se dió un caso interesante: en una sesión se dieron cuenta que todos querían escuchar una intro a metodologías ágiles, pero no había nadie presente para comentar el tema, ¿cómo lo resolvieron? se fueron a la sala de al lado y pidieron ayuda. Nico tomó la posta.
En un par de sesiones me levanté luego de un rato. Un poco porque habían perdido empuje, y otro poco para fomentar que la gente se mueva un poco. No vi mucho movimiento, me parece que la gente en general se quedó en las sesiones.
Las sesiones a las que fui: Intro Lean, Equipos Chicos, Testing, Retrospectivas, Arquitectura.
Cierre: como en los cierres de Cba y Tandil, el radar/termómetro del final es bueno por paliza. Esto no es tan raro, ya que se quedan hasta el final los que están más enganchados, pero aún así, se quedaron muchos. Hubo muchos comentarios positivos, y se habló un poco de como seguir. Sin embargo, los próximos pasos fueron más hablados en los pasillos, y en los mails posteriores.
Termino agradeciendo a Liliana Rathmann, Horacio Sampaoli y Martín Alaimo, que llevaron en sus hombros gran parte del peso organizativo (el costo de ser local!)

domingo, 14 de junio de 2009

Fomentando la ingeniería (TISP)


El viernes particié en una actividad TISP en el Instituto 13 de Julio.
TISP (Teacher in Service Program) es un programa del IEEE para fomentar las carreras de ingeniería. La idea es que los alumnos de secundario no eligen ingeniería porque es visto como algo aburrido y poco interesante. Se trabaja entonces con los docentes, difundiendo actividades que sirvan a los objetivos educativos del secundario pero que además sean divertidos.

La Rama Estudiantil de IEEE AR - URN Regional Bs As, ya había organizado una actividad TISP, y de allí surgió las ganas de los docentes del Instituto para hacer las actividades con los alumnos.

Yo me sumé, y fue una muy linda experiencia. Suelo hacer capacitaciones que incluyan juegos (Lean, Scrum), pero nunca los había hecho con chicos de 4to año. Todos teníamos dudas, ¿cómo andaría? ¿Se entusiasmarían con los juegos?

El resultado fue muy bueno (fotos), les gustó, y durante los momentos de diseño se los veía muy compenetrados en la discusión de alternativas y en el proceso de armado del prototipo. Notable la satisfacción de ver su producto soportar pesos que nunca hubieran imaginado que pudierna soportar: bolsas hechas con separadores de nylon para freezer y hilo de algodón soportando más de 2,5 Kg, o estructuras hechas con 12 cartas soportando a una persona parada arriba!
O... no se si tan notable. Ver el producto de nuestro trabajo es siempre bueno,

Espero que haya servido y al menos a uno o dos de los chicos les haya despertado la inquietud de ingresar a una carrera de Ingeniería.

Muy buena la organización (Federico Di Vruno, Juan Pablo Perello y Santiago Maudet) de la Rama Estudiantil! (FRBA UTN)

Muy buena onda, tanto los estudiantes como los docentes del Instituto (Hernán Bosco y Pablo Milione). Muchas gracias!

sábado, 13 de junio de 2009

Introducción al Testing de Seguridad en Aplicaciones Web

Ya está disponible en la página web del IEEE la documentación de la Conferencia 'Introducción al Testing de Seguridad en Aplicaciones Web' dictada por Andrés Riancho y Martín Tartarelli el 19 de mayo ppdo. En la misma sección también hay información sobre otras actividades realizadas en el ámbito de IEEE Argentina.
Andrés y Martín presentaron la necesidad y técnicas para realizar este tipo de pruebas. Andrés además presento la w3af, la herramienta FLOSS en que está liderando

Acceder desde
http://www.ieee.org.ar vía Botón 'Actividades' y opción 'Documentación'.

La conferencia la organizamos junto con Marcelo Doallo (IEEE AR - computer Society).

¡Gracias, Andrés y Martín!


jueves, 11 de junio de 2009

Ágiles 2009!


Estamos organizando Ágiles 2009 - 2das Jornadas Latinoamericanas sobre Metodologías Ágiles.
Este año se organizan en Florianópolis (Floripa para los amigos) – SC – Brasil, entre el 6 y 9 de Octubre. Para los que no la conocen, Floripa tiene unas playas espectaculares.
Pero no vamos (sólo) por eso. Ya están confirmados Brian Marick, Diane Larsen, Matt Gelbwaks y Naresh Jain. Alan Cyment estará dando un curso de CSM, y... los invitamos a que propongan sesiones sobre sus ideas y experiencias, para presentaciones, tutoriales, y workshops, relacionados con la adopción de Desarrollo Ágil en Latinoamérica y en el mundo.
Si te interesa, puedes visitar el sitio oficial. Si querés ayudar, por favor difundilo y blogea al respecto.
Este evento tiene el impulso del éxito de Ágiles 2008, sumado al tamaño de Brasil. Tendrá mucha mayor difusión (InfoQ).
¡Espero que nos veamos allá!

miércoles, 10 de junio de 2009

Calidad de Software y Desarrollo Ágil



Participé en un evento organizado por IRAM y la Universidad de Belgrano.
Luego de breves comentarios de Juan Lestani (UB) y Gustavo Pontroliero (IRAM) sobre las organizaciones, Paula Angeleri (IRAM y UB) comento algunos temas de normas que impulsa IRAM, más allá de ISO 9001. Me enteré que tienen normas de evaluación de nivel de madurez (estilo CMMI) y una norma estilo MoProSoft, de alcance latam. Otras cosas, ya las había escuchado, como la norma de calidad de producto y la certificación de ITIL.
No me queda claro por qué una empresa estaría interesada en esas normas. Creo que eso merece más tiempo para ser explicado.

Después yo presente un básicamente el Desarrollo de Software Ágil (la presentación, de 45 min la pueden bajar aquí). Fue tan básico que no nombré el rol del ScrumMaster. Por suerte luego Diego completó los huecos que yo dejé.
También me da la impresión que hay que hablar del cliclo más ámplio: los releases. Hablar sólo de los sprint deja una impresión incompleta. Por suerte, esto también fue comentado, en este caso por Pauline, la otra presentadora. Esta obra está bajo una licencia de Creative Commons.

Diego Gonzalez comentó la experiencia de Lagash, que entiendo fue una presentación similar a la que dió en Ágiles 2008, de la cual pueden ver los videos, salvo el hecho de tener 10 meses más de experiencia con ISO.
Pauline Morrison Fell comento el caso ThreeMelons. Una cosa que me gustó mucho de este caso es el uso de los posters, que creo son muy piolas como forma de documentación y difusión.

Llamativa la cantidad de personas, unas 90.

Espero que se repita.