Un bug a la vez

La Invasión de los Gerentes de Proyecto

2011-09-30T02:20:00.000-05:00

Hace unos días me junté con un viejo amigo, a quien no veía hacía un buen tiempo; llamémoslo Luchín. Mi amigo trabaja hace ya unos 4 años como desarrollador senior en una empresa local proveedora de soluciones de software. Muy acongojado, Luchín me contó: "Ahora sí que se fue todo al diablo. Llegó la invasión de los gerentes de proyecto a la empresa". Mi primera reacción fue de decepción, pues durante 3 años trabajé en esa empresa y me esforcé por forjar una cultura que cultive precisamente lo contrario a lo que esa frase vaticinaba.

Esta situación coincidió con un thread muy activo a inicios de este mes en la lista de la comunidad Agile Perú, el cual fue abierto con una cita extraída de un tweet del mundo real: "Ya no quiero ser ingeniero, quiero ser gerente de proyectos!" El thread creció muy rápidamente hasta llegar a tener más de 60 replies en menos de dos días. Es evidentemente un tema sensible, un tanto polémico y que está "de moda".

¿Pero, de qué estoy hablando exactamente? Vamos al grano. Tomaré como definición general de gerente de proyectos a alguien que:

Ya no desarrolla software
Les dice qué hacer a los desarrolladores
Es pagado considerablemente mejor que a los desarolladores
Es visto con mejores ojos y tiene más status que los desarrolladores ante todo el personal
No es explotado ni forzado a trabajar horas insanas
Tiene el privilegio de repartir tarjetas de presentación y firmar e-mails que dicen "Gerente"

¿Y cuál es problema con todo esto?

Bueno, desde mi humilde punto de vista, veo lo mismo que Tobias Mayer describió muy claramente hace ya 2 años en esta serie de iluminadores artículos:

Extraigo algunas secciones imperdibles:

The tragedy of many revolutions is that once successful the leaders tend towards the same behavior that caused the need for the revolution in the first place. The oppressed become the oppressors, i.e. they take on essentially the same behaviors because they don’t know how else to behave.

George Orwell characterized this tendency in the novel Animal Farm, an allegory for the Russian Revolution and subsequent events. By the end of the book, the revolutionary leader, Napoleon (a pig, by some charming coincidence) is walking on two legs, dressing in human clothing and selling his best friends out for horse meat.

There can be no really pervasive system of oppression . . . without the consent of the oppressed.” —Florynce Kennedy

Too often the oppressed don’t want change; they simply want to be on the other side of the oppression. That is the ugly reality we live in. We have all seen individuals rise to middle-management and change behavior accordingly, fitting in to the system and emulating their superiors. Many of us have seen teams fall apart through infighting — indeed a key part of the Scrum Master training course is focused on dealing with such situations. Reward systems in most software corporations are based on individual superiority, and to be superior, others must be considered inferior.

Commenting on the syndrome of in-fighting between oppressed natives in colonized countries, Paulo Friere notes “At a certain point in their existential experience the oppressed feel an irresistible attraction towards the oppressors and their way of life. Sharing this way of life becomes an overpowering aspiration. In their alienation, the oppressed want at any cost to resemble the oppressors, to imitate them, to follow them.”

En resumen, esto significaría que muchos desarrolladores al hartarse de la opresión a la que son sometidos por sus respectivos jefes o gerentes de proyecto, no ven otra salida que convertirse en opresores ellos mismos y a perpetuar (probablemente de forma inconsciente) el mismo modelo de opresión antes nuevos desarrolladores.

Esta opresión se expresa comúnmente a través del lenguaje de los opresores, con frases del tipo: "No sé que haces pero lo quiero para mañana".

Lo paradójico de todo esto, al menos en mi caso, fue que hace poco tuve que firmar un mail con el título de Gerente de Proyectos. No precisamente por una preferencía mía, sino del cliente con el que estaba trabajando, quien a su vez deseaba proyectar cierta imagen ante su respectivo cliente.

Y ustedes, ¿qué quieren ser cuando "crezcan"?

Propuestas presidenciales SMART

2011-01-19T12:23:00.003-05:00

La primera idea para escribir sobre este tema la tuve durante la campaña para las elecciones municipales de hace unos meses. Pero se puede trasladar tal cual a la presente campaña presidencial.

Existe una sencilla manera de describir los objetivos a los que puede aspirar una persona o una empresa. En inglés, esta técnica recibe el acrónimo SMART (que se puede traducir como astuto, listo o incluso "vivo"). Así, la idea es establecer objetivos SMART (o SMART Goals) en nuestras vidas.

Es una técnica bastante conocida y de hecho ya la había encontrado en libros como Behind Closed Doors y Pragmatic Thinking & Learning. Incluso, es bastante útil cuando se emplea en el contexto de una retrospectiva. Leyendo los posts que mi buen amigo Abner realizó hace poco, fue que me volví a encontrar con este concepto.

La idea es que cuando definamos objetivos, cada uno de ellos debería poseer las siguientes cualidades:

S - Ser eSpecífico
M - Ser Medible
A - Ser Alcanzable
R - Ser Relevante
T - Estar limitado por el Tiempo

Por ejemplo, decir que mi objetivo es "aprender a bailar" no es SMART. Decir, en cambio, que mi objetivo es "poder bailar salsa, cumbia y merengue en las fiestas sin repetir los mismos pasos en cada baile y sintiéndome cómodo y contento al hacerlo en un tiempo límite de 3 meses" sí es SMART.

Es más, gente como Joanna Rothman recomienda que, cuando planifiquemos, nos fijemos objetivos SMART pequeños y progresivos, de modo que podamos medir el avance más fácilmente. Siguiendo con el ejemplo anterior, quizás sería mejor establecer como primer objetivo "aprender 3 pasos básicos de salsa en máximo 2 semanas". Una vez conseguido este objetivo, podríamos fijar el siguiente.

¿A qué viene todo esto? Bueno, a que cuando escucho a algún candidato político hablar sobre sus propuestas, busco evaluarlas según el criterio SMART. Y para ser franco, durante la última campaña municipal, no encontré mucho de SMART en el discurso de ninguno de los candidatos.

Veremos si esta vez, al menos uno me sorprende cuando tome la palabra en alguna entrevista, mitin o debate.

Ágiles 2010: 3ras Jornadas Latinoamericanas sobre Metodologías Ágiles

2010-09-08T12:30:00.001-05:00

Ágiles 2010 es una excelente oportunidad para encontrase con
profesionales de IT de la región, interesados en compartir sus
experiencias, debatir y capacitarse en temas relacionados con el
desarrollo de software a través del uso de metodologías ágiles.

Esta tercera edición, con sede en la ciudad de Lima, Perú, contará
con la presencia de especialistas locales e internacionales, quienes
compartirán su conocimiento durante los cuatro días que durará el
evento.

El programa incluye distintos tipos de actividades: presentaciones,
sesiones interactivas, talleres y espacios abiertos de debate.

Entre los invitados internacionales se encuentran los keynote
speakers Lee Devin y Joshua Kerievsky, que también estarán brindando
cursos durante el evento.

¡Inscríbete y se parte de Ágiles 2010!

La retrospectiva de Scrooge

2010-02-10T22:04:00.004-05:00

Supongo que todos están familiarizados con la novela A Christmas Carol de Charles Dickens (o alguna de sus adaptaciones), en la cual un viejo gruñon, Ebenezer Scrooge, es visitado durante la Nochebuena por tres fantasmas quienes le hacen reflexionar, reencontrase con su niño interior e imbuirse de espíritu navideño. Hace poco Jim Carrey protagonizó una versión en 3D para la pantalla grande.

Bueno, en las últimas fiestas me topé con una de las tantas versiones en televisión, esta vez representada por Patrick Stewart. Sí, el mismísimo Profesor Xavier de X-Men y Capitán Jean-Luc Picard de Stark Trek. Y sí, sé que ya hace tiempo que pasó la Navidad.

El punto es que al observar la narración de la película en cuestión empecé a encontrar asombrosas similitudes entre lo que ocurría con nuestro héroe (¿o anti-héroe?) y lo que usualmente sucede durante las retrospectivas de los proyectos de software. Veamos a qué me refiero, y para esto nos basaremos en el framework flexible de restrospectivas de Esther Derby y Diana Larsen.

El primer fantasma en visitar a Scrooge es el de las navidades pasadas, quien le recuerda a Scrooge sucesos de su pasado, especialmente de su infancia, adolescencia y juventud. Esto coincide con la etapa de Recolección de Datos (Gather Data), pues lo que se busca es que Scrooge contemple, a modo de observador externo, los hechos relevantes que tengan influencia sobre su comportamiento en la actualidad.

El segundo fantasma es el de las navidades presentes. Este le muestra cómo festejan aquéllos del círculo de personas cercanas a Scrooge. Tanto pobres como ricos personifican el espíritu navideño y celebran con lo poco o mucho que poseen. A partir de aquí se comienzan a formar reflexiones profundas dentro del protagonista (Generate Insights), al combinar elementos pasados y presentes,de maneras no obvias para alguien que se había acostumbrado a vivir de cierta manera y sin pensar mucho al respecto.

Finalmente, el tercer fantasma, el de las navidades futuras, le muestra a Scrooge el triste y lamentable porvenir que le espera, acaso decida seguir por el mismo rumbo carente de compasión y benevolencia con el prójimo. Es aquí que termina la etapa de reflexión y Scrooge comienza a tomar decisiones sobre cómo debe comportarse y qué elementos de su personalidad debe cambiar para mejorar (Decide What to Do).

Si tienen la oportunidad de ver esta película, prueben mirándola a través de estos nuevos ojos y se darán cuenta por qué se afirma comúnmente que las retrospectivas (entre otras prácticas ágiles) no son más que sentido común aplicado al contexto de los equipos de trabajo y el desarrollo de nuevos productos de software.

Discos, transparencia y cuellos de botella

2009-12-16T20:36:00.006-05:00

Hace unas semanas fui a comprar unos CD’s a Plaza San Miguel (sí, soy uno de esos especímenes raros que todavía compra discos originales). Hacía tiempo que no iba por allá, así que estaba un poco desorientado, pues varias tiendas se habían mudado de sitio. Dando unas cuantas vueltas por el lugar, encontré Sonodiscos, una tienda que a simple vista se nota que no es parte de una cadena, sino que, más bien, aparenta tener tradición y ser parte de un negocio familiar.

El punto es que, cuando empecé a revisar los discos que tenían a la vista, me vi bastante desorientado. La razón es simple: ninguno de los discos tenía el precio adherido al empaque! Lo que exhibían era un código algo críptico y para nada indicativo.

El producto de esto es que, para un humilde melómano como el que escribe, se me hacía imposible evaluar el costo-beneficio de las posibles compras que deseaba realizar, pues cada vez que necesitaba saber un precio debía consultar con alguno de los empleados del lugar.

La situación llegó a un punto tal, que me comencé a sentir bastante incómodo por la falta de información, o más bien por la falta de rapidez en conseguirla y por el cuello de botella que se generaba con el personal de la tienda al intentar conseguirla.

Ahora, ¿cuál es mi punto con esta historia? Pues básicamente dos: el primero es que, muchas veces en los proyectos de software, pecamos de falta de transparencia. Usualmente, la razón de esto es el miedo. Miedo porque, si somos transparentes, el resto de personas nos juzgará o, peor aún, nos castigará por nuestros errores. Me atrevo a soltar la hipótesis de que, en el caso de Sonodiscos, el dueño podría tener miedo de la competencia y de que ésta acuda a su tienda a espiar los precios.

El segundo punto es que, al ocultar información, creamos cuellos de botella artificiales, innecesarios y que entorpecen la colaboración y la consecución de objetivos. En mi caso, tenía poco tiempo para visitar la tienda y mi objetivo era comprar la mayor cantidad de discos de artistas que no conociera mucho en el menor tiempo posible y bajo un presupuesto predefinido.

Lamentablemente, no conseguí mi objetivo a cabalidad. Lo siento Sonodiscos, pero la próxima vez iré directamente a Phantom. Aunque los precios a veces son ligeramente más caros, me ofrecen una mejor relación costo-beneficio para alcanzar mis objetivos.

Entrevista con Diana Larsen

2009-10-13T20:05:00.018-05:00

El evento Agiles 2009 que se llevó a cabo en Florianópolis, Brasil llegó a su fin la semana pasada. Fue una vivencia gratísima compartir conocimiento y experiencias con tanta gente interesada en la Agilidad, principalmente de Brasil y Argentina, así como también conocer a personas como Diana Larsen, autora del libro “Agile Retrospectives: Making good teams great!” y presidente del directorio de la Agile Alliance.

En esta entrevista, Diana nos habla sobre qué son las retrospectivas, de dónde vienen y cómo se estructuran.

Además toca algunos temas sociológicos, relacionados a las retrospectivas pero un poco más amplios y, finalmente, discute un poco sobre el futuro de la Agile Alliance y de Agile en general.

Pueden bajarse la entrevista aquí.

En los negocios, ¿el tiempo es lo más importante?

2009-09-09T18:41:00.035-05:00

No veo mucha televisión. Es más, ni siquiera tengo cable (!!??). Pero sucede que hace poco estuve mal de salud y tuve que pasar unos días en casa frente a la caja boba. Es así que descubrí este comercial de Interbank que me dejó un tanto intranquilo:

La dinámica de la publicidad gira entorno a la siguiente idea-fuerza: "En los negocios el tiempo es lo más importante." Si bien es obvio que el comercial está realizado en tono de burla o comedia, deja traslucir la que varios empresarios o ejecutivos piensan que es la mejor manera de gestionar a su personal, área o empresa.

Es decir, concentrarse en mantener a los empleados ocupados el 100% del tiempo, asumiendo que los objetivos planteados por los niveles superiores de la jerarquía son los correctos (sin una adecuada validación) y tratando de alcanzarlos lo más rápido posible, evitando crear e spacios para el diálogo, la contrapropuesta y la generación de intercambios de opiniones que aporten valor. O visto de otro modo, desaprovechar la capacidad que cada persona tiene para crear, generar soluciones e ideas; en resumen, para innovar.

Veo varios problemas con esta forma de gestión. En primer lugar opino que lo más importante en los negocios no es el tiempo (a secas), sino generar valor en los clientes. Es decir ofrecerles productos o servicios de calidad que satisfagan sus necesidades. En segundo lugar está la suboptimización. El hecho de tener al personal ocupado todo el tiempo pierde de vista el objetivo real de lo que estamos haciendo y cómo podemos mejorarlo, alienta la separación entre las áreas funcionales de la empresa, la formación de colas de información (con las correspondientes demoras) y una presión excesiva sobre las tareas a realizar, lo que promueve una cultura de "tomar atajos" y acarrea una pérdida de calidad en las actividades que hacemos.

Una vez claro lo anterior, recién podemos empezar a discutir el factor tiempo. Obviamente, si nuestra competencia ofrece un producto o servicio con mejor calidad que la nuestra en la mitad del tiempo, estamos en problemas. Pero esto debe enfocarse como un problema sistémico, a modo de atacar las causas raíz que permitan generar soluciones y que eliminen los desperdicios dentro de nuestros procesos, teniendo en claro todo el flujo de valor, desde que una necesidad es detectada hasta que ésta es satisfecha.

CSP, ¿y ahora qué?

2009-08-20T22:29:00.012-05:00

Hace unos días recibí la buena noticia de que había obtenido la certificación CSP (Certified Scrum Practitioner) de parte de la Scrum Alliance. Mi primera reacción fue de alegría y satisfacción, obviamente. No considero que sea una certificación fácil de obtener pues, a diferencia de muchas otras, lo que se evalúa es un cuestionario de unas 20 preguntas acerca de la experiencia que uno tiene aplicando (o al menos intentando aplicar) Scrum en un contexto específico. A diferencia de la certificación CSM, que sólo requiere llevar el curso (aunque próximamente será exigible un examen on-line de alternativa múltiple) y que tiene aproximadamente 56,000 personas certificadas en todo el mundo, la CSP sólo tiene alrededor de 600.

Una vez pasada la emoción, me empecé a preguntar qué es lo que vino antes y también qué viene después. Un paso lógico sería buscar obtener la CSC o CST, que no son nada fáciles (ni baratas, valgan verdades). Sin embargo, más que eso, en este momento me gustaría reflexionar un poco sobre la real utilidad de las certificaciones.

Hubo un tiempo en que buscaba obtener certificaciones de manera un tanto obsesiva, por varias razones: siendo valoradas en el mercado, usualmente llevan a un mejor sueldo y posición, demuestran el conocimiento que puedes tener en una determinada materia y por supuesto, ¡lo hacen sentir muy bien a uno cuando las recibe! No niego que me sirvieron de mucho, profesionalmente hablando. Pero la verdad es que de, de todo el conocimiento que adquirí estudiando para esos exámenes, una buena parte simplemente ha desaparecido de mi memoria, o para decirlo más elegantemente, no fue correctamente indexado y, por lo tanto, es inubicable.

La realidad es que para que el conocimiento sea realmente útil es indispensable acompañarlo de la experiencia. Es ésta la que permite validar lo aprendido, combinarlo en nuevas formas e incluso descartar aquellas cosas que no son tan válidas en la práctica. Ahora, todo esto suena muy obvio, ¿no? Sin embargo, muchas empresas no lo ven de esa manera. Se concentran únicamente en el certificado y no toman en cuenta la experiencia, confiando en que por poseer el cartoncito (o PDF) la persona será capaz de asumir los retos propios del trabajo. Esto sería similar a que se contrate a un gerente recién egresado de un MBA, ¡pero con ninguna experiencia gerencial!

Ahora, no estoy en contra de las certificaciones. Simplemente pienso que no es un indicador 100% fiable (quizás ni 50%) de lo que una persona puede hacer en el campo laboral y por lo tanto, considero que no debería jamás ser un requisito indispensable o exigible para un puesto relacionado al desarrollo de software. Las veces que he entrevistado gente (que han sido varias) he tenido mucho cuidado en este punto, llegando incluso a rechazar postulantes con muy bonitos certificados pero sin la experiencia necesaria o sin una personalidad que viera que encajaba adecuadamente con nuestra cultura empresarial.

Conferencia Internacional sobre Testing y Calidad del Software

2009-08-06T18:44:00.003-05:00

Me llegó hace poco una invitación a esta conferencia, a llevarse a cabo en Bilbao, España a fines del mes de octubre. El programa se ve muy interesante. Desde mi punto de vista, una de las presentaciones que más destaca es la de Mary Poppendieck, una de las más importantes impulsoras del enfoque Lean en el mundo del software (Lean Software Development).

Tuve la gran suerte de conocer a Mary durante el curso que dictó en Buenos Aires el año pasado, el cual fue una gratísima experiencia para mí. El conocimiento y la experiencia que destila con cada afirmación u opinión que vierte es realmente impresionante y digno de destacar.

Lamentablemte no podré asistir a esta conferencia, pero si alguno de ustedes trabaja con software embebido y está por allá durante esas fechas, creo que es un evento al que no puede dejar de asistir.

Primer Curso Certified ScrumMaster en español en Lima

2009-05-19T12:54:00.007-05:00

Durante los días 31 de agosto y 1 de setiembre de 2009 se dictará por primera vez en Lima el Curso de Certificación de Scrum (CSM) en idioma español, oficialmente reconocido por la Scrum Alliance.

Esta es una excelente oportunidad de llevar este curso, pagando la tercera parte de lo que cuesta en Estados Unidos o Europa. Será dictado por Alan Cyment, el único Certified Scrum Trainer nativo hispanoparlante en el mundo.

Toda la información sobre el curso, así como el formulario de inscripción, la pueden encontrar en la página de la empresa organizadora, Open Edge Technologies, de la cual formo parte.

Espero verlos allí!

Fundamentos de la Agilidad: Gente y Colaboración

2009-04-22T23:37:00.006-05:00

Comparto con ustedes la presentación que brindé en el Lima Agile Day 2009, que por cierto fue un evento muy exitoso, y todo un orgullo para mí co-organizar y ser parte del mismo.

Mi objetivo durante la presentación fue tratar de responder las siguientes preguntas:

¿Por qué es importante la gente en el desarrollo de software?
¿Cómo cultivar un ecosistema ágil?
¿Cómo reconocer en qué fase de madurez se encuentra un equipo de desarrollo?

Realmente es un tema amplio, por lo que el tiempo me quedó bastante corto. Espero poder profundizar algunos conceptos en las reuniones de Agile Perú, en este blog y en futuras charlas que organicemos.

Fundamentos de la Agilidad: Gente y Colaboración

View more presentations from gquiroz.

Lima Agile Day 2009

2009-02-05T01:38:00.005-05:00

[ACTUALIZACIÓN: La fecha confirmada del evento es el Sábado 18 de Abril de 2009]

La comunidad Agile Perú los invita al Lima Agile Day 2009. Este evento está dirigido a todos aquellos interesados en conocer y entender cómo aplicar las llamadas Metodologías Ágiles de Desarrollo de Software (tales como Scrum y Extreme Programming) de boca de algunos de sus más fervientes practicantes en nuestro país.

Acompáñanos a intercambiar conceptos, experiencias y buenas prácticas relacionadas a esta nueva manera de desarrollar software que tanta conmoción está causando en el mundo entero por los beneficios obtenidos mediante su aplicación: mejoras drásticas en tiempos de entrega, calidad, trabajo en equipo y satisfacción de los usuarios.

Fecha: Sábado 18 de Abril de 2009
Hora: 8:30 am a 1:00 pm
Lugar: Auditorio Cibertec, Av Salaverry 2255, San Isidro

INGRESO LIBRE (capacidad 150 personas) previo registro:

Agenda:

8:30 - Registro
9:00 - Presentación del Evento
9:20 - Scrum, una nueva forma de desarrollar software (Deusdit Correa)
10:05 - Fundamentos de la Agilidad: Gente y Colaboración (Gustavo Quiroz)
11:00 - Cómo enfrentar la resistencia al uso de Metodologias Agiles (Raúl Uribe y Gustavo Véliz)
11:45 - ¿Por dónde comenzar? - Primeros pasos aplicando técnicas ágiles (Abner Ballardo)
12:25 - Retrospectiva y Cierre del Evento

Esperamos contar con tu participación!

Como hacemos Scrum: Requerimientos

2009-01-23T19:57:00.008-05:00

Algunos piensan que ser ágil quiere decir que no se tienen requerimientos escritos, que toda la comunicación entre usuarios/clientes y desarrolladores es verbal y que si no están usando User Stories, no se puede hablar de desarrollo ágil. Bueno, tengo que discrepar de estas tres creencias.

Hablaré en el contexto de un proyecto que desarrollamos, el cual consistía en construir una aplicación para una entidad del sector financiero. Esta entidad, como muchas otras similares, tiene procesos un tanto rígidos (por no decir burocráticos ni pesados) que guían sus proyectos de desarrollo.

Cuando iniciamos el proyecto, nos fue entregado un documento de casi 150 páginas en donde se describían en detalle requerimientos, mediante especificaciones de casos de uso y pantallazos de un prototipo previamente construido. ¿Qué hacer en estos casos?

El principio básico en todo esto es algo que les sonará familiar a muchos: LA COMUNICACIÓN. Es decir, debe existir un entendimiento común entre aquéllos que desean resolver un problema (usuarios) y aquellos que pueden resolver el problema (desarrolladores).

Para lograr ese entendimiento debe existir un canal amigable entre ambos frentes. En nuestro caso, lo que hicimos fue acordar reuniones dos veces por semana entre nuestro equipo y los analistas del cliente para conversar acerca del documento de requerimientos. Teníamos como objetivos:

Compredener de qué diablos trataba la lógica de negocio a un nivel suficiente para que uno de nosotros actuara como Proxy del Product Owner en nuestras reuniones de planeamiento.
Poder definir un Product Backlog en base a este documento.
Priorizar el Product Backlog con los representantes del cliente.

El Analista Funcional del cliente se convirtió, casi sin darse en cuenta, en nuestro Product Owner y acompañó a nuestro equipo a lo largo de todo el proyecto, estando siempre dispuesto a absolver dudas y repriorizar ítems, cuando fuera necesario.

Aquí un punto clave es descomponer los casos de uso para poder llegar a un nivel de granularidad suficiente que permita planificar los ítems del Product Backlog dentro de cada iteración o sprint. La técnica que usamos fue considerar a cada escenario como un requerimiento o ítem distinto. Por ejemplo, si hablamos de un mantenimiento de países, los ítems (o stories) serían:

Consultar países por nombre
Consultar países por código internacional
Crear país
Modificar país
Inactivar País
Reactivar País

Otro punto importante son las demos o reviews del producto que se realizan al finalizar cada iteración. En nuestro caso, además de los analistas del cliente y de nuestro equipo, participaban los usuarios finales de la entidad financiera. Como es normal, al interactuar o apreciar el incremento de funcionalidad que se está presentando, a un usuario se le van a ocurrir muchas ideas de cómo mejorar o cambiar el producto. Es básico el poder manejar su expectativa y guiarlo sobre cuáles se van a poder incorporar y cuáles no (por razones de tiempo, costo y/o complejidad).

Lo que hicimos nosotros fue recoger todas las sugerencias e ideas, para posteriormente (o a veces durante la reunión misma) conversarlas con nuestro Product Owner. Aquellas que el equipo consideraba sencillas las incorporamos sin ningún problema. Pero aquéllas que se estimaba iban a tomar más tiempo, quedaron en el tintero para futuras versiones del producto.

Cómo hacemos Scrum

2009-01-23T19:56:00.007-05:00

Cuando la gente comienza a aplicar métodos ágiles en un proyecto u organización, las preguntas más comunes son: ¿por dónde empiezo? y ¿cómo realizo esto o aquello? Entiéndase "esto o aquello" como algo que saben que se tiene que hacer pero no tienen mucha idea de dónde encaja dentro un entorno ágil: documentación, estimación, planificación, etc.

Es por eso que en esta serie de posts voy a contar un poco acerca de cómo usamos Scrum/Agile en los proyectos que desarrollamos en la empresa donde trabajo y de cómo aplicamos principios emparentados con agile o lean en la organización de nuestra área.

Trataré de tocar temas como: planeamiento, estimación, capacitación, gestión del talento, retrospectivas, documentación, requerimientos, testing, espacio de trabajo, etc.

Disclaimer: Las opiniones vertidas en esta serie de posts no representan la posición oficial de la empresa ni de los clientes involucrados (según el caso).

LinkedIn usa Spring y Tomcat

2009-01-08T11:48:00.002-05:00

Hoy encontre esta excepción mientras navegaba por LinkedIn:

Al menos están usando Spring!

Agile y software embebido

2008-11-18T11:15:00.005-05:00

Al menos un par de veces cuando he dado una charla o curso de Scrum/Agile, me ha sucedido que surgen preguntan acerca de si el desarrollo iterativo-incremental puede aplicarse a sistemas embebido o que involucren Hardware. Si bien sé que es algo que se hace en diversos lugares alrededor del mundo, lo que me faltaban eran casos concretos para mencionar y mostrar.

En este enlace se resume el éxito del proyecto AGILE del programa ITEA de la red de investigación europea EUREKA, el cual se desarrolló entre los años 2004-2006 a un costo de 20 millones de euros. El balance de esta iniciativa fue que se logró producir sistemas embebidos de alta calidad con tiempos y costos menores (hasta 70% menos) en comparación con técnicas tradicionales.

El programa se llevó cabo en 68 proyectos dentro de unas 20 empresas, entre ellas Philips, Nokia y DaimlerChrysler. Algo que vale la pena destacar es la opinión del Dr Pekka Abrahamsson, líder del proyecto, quien afirma que si los resultados obtenidos pudieran sostenerse a lo largo de todo Europa, sería más barato hacer outsourcing de desarrollo desde India hacia Europa que en el sentido inverso!

Durante el evento Ágiles 2008, me enteré de otro caso digno de resaltar. Conversando con Matt Gelbwaks, pude conocer acerca de su experiencia como director de Product Management & Development del famoso Segway. Para desarrollar este producto, Matt empleó un mix de Agile y Critical Chain Scheduling, con muy buenos resultados.

Conferencia: "Experiencias en la aplicación de Metodologías Ágiles"

2008-09-29T16:06:00.007-05:00

Este miércoles 15 de octubre voy a dar una conferencia junto a mi estimado amigo Abner Ballardo en la PUCP. La organización corre por cuenta del grupo SPIN-PERÚ.

A continuación transcribo el mail de convocatoria:

Las metodologías ágiles (XP, SCRUM, etc.) presentan un esquema de desarrollo diferente a las metodologías tradicionales. En estas metodologías se pone especial énfasis en la comunicación con el cliente y en la adaptación a los cambios y es una realidad que su uso se viene difundiendo cada vez más en el ambiente de software. Además cuentan con el visto bueno de algunos de los mejores en el área de Ingeniería de Software (Booch, Gamma, Fowler, Cockburn, De Marco, Ambler) .Este año la V Conferencia SEPGLA (http://www.esi.es/SEPGLA/) tiene como título “Combinando Disciplina con Métodos Ágiles”. Si alguien desea participar en el evento, la fecha de inscripción con descuento se ha ampliado hasta el 10 de octubre y pueden inscribirse en la página del evento.

De otro lado en el ambiente nacional algunas empresas y profesionales han optado por este tipo de metodologías por lo que hemos organizado una charla en la que podamos compartir experiencias en el uso de estas metodologías. La charla se llevará a cabo el día miércoles 15 de octubre a las 7:00 p. m. en el campus de la Pontificia Universidad Católica del Perú. Para compartir sus experiencias tenemos confirmados a dos expositores:

1) Gustavo Quiroz se ha desempeñado como Desarrollador de Software, Especialista en IBM WebSphere, Arquitecto de Software y Líder de Proyectos para una amplia variedad de aplicaciones empresariales a lo largo de más de 6 años, sobre todo en las industrias de banca, seguros y telecomunicaciones. Actualmente se desempeña como Arquitecto de Soluciones y Coach Ágil, formando equipos y líderes en las prácticas y valores ágiles.

2) Abner Ballardo se ha desempeñado como Desarrollador de Software, Arquitecto de Software y Líder de Proyectos en la implementación de aplicaciones empresariales y de telecomunicaciones usando metodologías ágiles. Ha participado en múltiples proyectos de Software Libre en los últimos 9 años, fomentando su difusión, llevando técnicas y buenas prácticas del Software Libre a su labor profesional. Actualmente se desempeña como Especialista en IBM WebSphere Portal y Consultor Independiente en metodologías ágiles.

Ingreso libre previa inscripción al correo spin.peru@pucp.edu.pe indicando nombre y e-mail.

Se enviará un mail de confirmación.

Web Services para todo?

2008-09-28T21:04:00.005-05:00

En lo que va de este año, ya van por lo menos dos clientes en los que observo una especie de "obsesión" con la utilización de Web Services, indicando que las aplicaciones a construir deben estar basadas en SOA y, por lo tanto, deben consumir servicios internos mediante SOAP. WTF?

Para tener una arquitectura basada en u orientada a servicios, no se requieren Web Services! Es más, si las aplicaciones consumidoras y proveedoras de servicios están escritas en el mismo lenguaje de programación, se vuelve una pésima opción, por cuestiones de rendimiento y complejidad innecesaria en el diseño. Recordar los principios KISS y YAGNI!

Acerca del tema de la distribución innecesaria de los objetos se ha dicho bastante. Es más, es una de las razones por las que surgió Spring como respuesta al status quo impuesto por el estándar EJB 1.x/2.x. Esto lo explican bastante bien Rod Johnson y Juergen Hoeller en su libro J2EE Development without EJB.

Por poner otro ejempo, y citando a Martin Fowler:

Rule # 1 of Distributed Computing - Don't distribute your objects!

Finalmente, todos deberían conocer las 8 falacias de la computación distribuida:

La red es confiable.
La latencia es cero.
El ancho de banda es infinito.
La red es segura.
La topología no cambia.
Existe un único administrador.
El costo del transporte es cero.
La red es homogénea.

Personalmente, recomiendo utilizar Spring (o algo parecido) para exponer servicios y sólo hacerlos accesibles remotamente si la necesidad de integrar clientes externos (por ejemplo implementados en una plataforma o lenguaje distinto) surge.

Agiles 2008

2008-09-05T21:26:00.004-05:00

Les reproduzco el aviso que anuncia la realización del evento Agiles 2008. A aquellos que puedan asistir, avisen. Yo voy a estar por allá y espero nos podamos juntar.

Está abierta la inscripción a las Jornadas Ágiles 2008, a realizarse los días 22 y 23 de Octubre de 2008 en el Hotel Bauen, Buenos Aires, Argentina.

Ágiles 2008 es una excelente oportunidad para encontrarse con profesionales de IT de la región, interesados en compartir sus experiencias, debatir y capacitarse en temas relacionados con el desarrollo de software a través del uso de metodologías ágiles.

Entre los invitados internacionales que participarán en Ágiles 2008 se encuentran Matt Gelbwaks, Tobias Mayer, Dave Nicolette y los keynote speakers del evento, Mary y Tom Poppendieck.

El programa incluirá distintos tipos de actividades: presentaciones, sesiones interactivas, talleres y espacios abiertos de debate.

Las jornadas son gratuitas pero es necesario registrarse para reservar un lugar. El formulario de inscripción está en http://www.agiles2008.org/es/registracion.php

Más información relacionada con el evento, el hotel y el programa en www.agiles2008.org

Cualquier inquietud, envíenos un mail a info@agiles2008.org

Scrum y RUP

2008-08-06T18:19:00.003-05:00

Mucha gente acostumbrada a RUP, cuando comienza a aprender acerca de Scrum y métodos ágiles, se hace preguntas similares a la siguiente:

"Para hacer el diseño de un software en RUP se hacer realización de casos de uso (diagramas de secuencia, colaboracion, etc), diagramas de clases, componentes y otros. ¿Se pueden utilizar estos entregables de RUP adicionalmente a los usuales de Scrum (Product Backlog, Sprint Backlog, Impediment List, Burndown chart)?"

Mi respuesta es la siguiente:

En vista de que Scrum es un framework mínimo para crear un proceso de desarrollo de software, no prohibe la creación de artefactos o documentos adicionales a los que indica como obligatorios. Lo único que dice Scrum al respecto es que juzgues la necesidad, la utilidad y el costo (vs. el beneficio) de cada uno de los artefactos que decides agregar. Mi opinión es que siempre es necesario realizar ciertas actividades de modelamiento antes de iniciar un desarrollo.

Lo importante es que los modelos producidos sean como una luz que guíe el resto del proyecto, no una camisa de fuerza, y dejar que evolucionen junto con el código producido. Más aún, es crucial comunicar estos modelos al resto del equipo, por lo que muchos equipos ágiles prefieren utilizar pizarras (vs. herramientas CASE) para realizar sesiones de modelamiento en conjunto.

Esto es lo que se conoce como Agile Modeling.

Una buena fuente de información sobre cómo combinar Scrum y RUP, es el site del OpenUP.

Conferencia "Scrum: Agilidad en el Desarrollo de Software”

2008-07-25T17:46:00.005-05:00

El sábado 2 de agosto voy dar una charla en la UNMSM. Este es el aviso publicado en el site de la Facultad de Ingeniería de Sistemas e Informática:

CONFERENCIA
"SCRUM: AGILIDAD EN EL DESARROLLO DE SOFTWARE”
Sábado 02 de agosto de 2008 – 17:00 a 19:00 hrs.
Aula Magna de la FISI

La Unidad de Postgrado, la E.A:P. de Ingeniería de Software y el CEUPS de la Facultad de Ingeniería de Sistemas e Informática de la UNMSM, invitan a la comunidad académica y público en general, a la Conferencia: "Scrum: Agilidad en el Desarrollo de Software”, que contará con la ponencia del Ing. Gustavo Quiroz (Ingeniería Informática, PUCP), quien ha jugado el rol de Desarrollador de Software, Especialista en IBM WebSphere, Especialista en Análisis de Requerimientos, Arquitecto de Software y Líder de Proyectos para una amplia variedad de aplicaciones empresariales. Asimismo cuenta con más de 6 años de experiencia en las industrias de banca, seguros y telecomunicaciones. Actualmente se desempeña como Arquitecto de Soluciones y Líder Ágil de Proyectos de Desarrollo de Software en Systems Support & Services.

Se otorgará Constancia de Participación a solicitud de los interesados.

Las inscripciones se efectúan en la Unidad de Postgrado (2do. Piso del pabellón administrativo), teléfono 619 7000 (anexo 3603) o al correo electrónico: upgfisi_academica@unmsm.edu.pe

La entrada es libre, incluso para gente que no es de la univesidad. Espero ver a algunos de ustedes por allá!

Curso de Desarrollo Agil de Software

2008-07-17T12:45:00.006-05:00

[UPDATE: El curso se ha reprogramado para el sábado 9 de agosto de 2008]

Esta noticia sí que es nueva. Acabo de concretar la realización de un curso en sociedad con la empresa JoeDayz de mi amigo José Diaz. La fecha de inicio es el 9 de agosto con una duración de 15 horas en total a lo largo de 5 sábados (9:30 am a 12:30 pm). Los temas que tocaré son los siguientes:

INTRODUCCIÓN AL DESARROLLO ÁGIL DE SOFTWARE
1. Orígenes y Fundamentos
2. Principios y Valores
3. El Manifiesto Ágil
4. Frameworks y Metodologías (Scrum, XP, AgileUP/OpenUP)
5. Ciclo de vida de los proyectos ágiles

GESTIÓN ÁGIL DE REQUERIMIENTOS
1. Historias de Usuarios,
2. Casos de Uso vs. Historias de Usuario
3. Backlog del Producto y Backlog de la Iteración
4. Técnicas de priorización y estimación
5. Buenas prácticas para la creación de Historias de Usuarios

DISEÑO ÁGIL DE SOFTWARE
1. Principios de Diseño Orientado a Objetos
2. Modelamiento Ágil
3. Refactoring y Diseño Evolutivo
4. Refactoring y Patrones de Diseño
5. Arquitectura ágil de software

ASEGURAMIENTO ÁGIL DE LA CALIDAD
1. Pruebas unitarias automatizadas de código, Test-driven development
2. Automatización de pruebas de integración, de sistema y de aceptación
3. Building automático de código
4. Métricas y Reportes de Aseguramiento de la Calidad
5. Integración continua

GESTIÓN ÁGIL DE PROYECTOS
1. Fases de un proyecto ágil y adaptativo
2. Planeamiento de los releases
3. Planeamiento de las iteraciones
4. Seguimiento, métricas, concepto de velocidad
5. Retrospectivas
6. Herramientas ágiles de gestión

El costo es de S/. 350.00. Si desean más información sobre el contenido del curso pueden preguntarme directamente a mí y si desean inscribirse pueden contactarse con José a los teléfonos 994-104-448 / 994-104-357.

De más esta decir que espero verlos por allá!

Comunidad Agile Perú

2008-07-17T11:54:00.003-05:00

Les comunico esta noticia un poco tarde, pero hace unos días creamos la Comunidad Agile Perú en donde discutimos todo lo relacionado a la difusión y aplicación de métodos ágiles en nuestro país. Pronto tambien inauguraremos un web site con artículos e información al respecto.

Son todos bienvenidos a unirse a este emprendimiento, para compartir experiencias, dudas y conocimiento en general.

Aplicando Agile en un ambiente Waterfall

2008-06-29T23:11:00.005-05:00

En esta excelente presentación, Michele Sliger, experimentada consultora en la aplicación de métodos ágiles en ambientes difíciles (léase acostumbrados a procesos orientados a fases divididas por competencias o producción de entregables documentales) cuenta sus experiencias y recomendaciones para comenzar a construir lo que ella llama "un puente" entre Agile y Waterfall.

Toca temas como: la resistencia que uno encuentra de parte de la gerencia, el negocio y el equipo (y cómo enfrentarla), los aspectos de cultura organizacional y asociados a los valores que uno tiene que tomar en cuenta, cómo manejar la relación no-ágil/ágil entre clientes y empresas proveedoras de software, cómo enfrentar las auditorías, reportes de estado, contabilidad de costos y performance reviews orientadas a los individuos en lugar del equipo, entre otros.

Finalmente, ofrece los siguientes 10 tips:

Find an Executive Champion (ayuda bastante a remover impedimientos organizacionales)

Socialize, Don't Evangelize (en lugar de predicar, uno debe buscar tener conversaciones donde se exponen ideas y experiencias)

Use the Power of the Backlog (para organizar la producción de documentos requeridos, no sólo funcionalidades del software)

Don't wait until everything's perfect (es decir, "lanzarse al agua" y empezar a aplicar el enfoque ágil)

Use the "Barely Sufficient" Guideline (tener claro qué es lo que requiere la audiencia, en cuanto a documentación sobre todo)

Invite Non-Agile Representatives to all Agile Planning Meetings (para comprender los entregables que el equipo necesita de otros equipos no-ágiles)

Establish a Rythm of Inspection and Adaptation (para mejorar poco a poco; muy relacionado al punto 4)

Send Agility Up the Chain (comunicar los logros a lo largo de la organización)

Pay Attention to Behaviors (para no volver a los hábitos y valores anteriores)

Include Everyone in the Project Retrospective (para mejorar no sólo al interior del equipo sino en toda la organización)

Dentro de mi experiencia, me he enfrentado con muchos de los obstáculos que se mencionan en la presentación, y he llegado a varias de las mismas conclusiones, por lo que estoy seguro de que aquéllos interesandos en aplicar Agile en ambientes tradicionales y no tienen claro por dónde empezar, pueden encontrar aquí un buen punto de partida.

Curso Certified ScrumMaster fue todo un éxito

2008-06-27T12:56:00.009-05:00

Esta semana se llevó a cabo, por primera vez en Lima, un curso oficial Certified ScrumMaster. El instructor fue Tobias Mayer y realmente fue una experiencia única y bastante enriquecedora. Partiendo de las dinámicas de grupo que aplicó Tobias para que todos experimentáramos los valores y principios de Scrum, pasando por las historias que contó de su trabajo aplicando Scrum en Yahoo! y Business Week, sumado al aporte de cada uno de nosotros y culminando en una suculenta cena en Antica, fueron dos días bastante productivos, en los que compartimos muchas ideas, opiniones e inquiedudes con Tobias y con todos los asistentes.

Gracias a todas la personas que hicieron esto posible: Deusdit Correa y la gente de Voxiva, el Capítulo PMI de Lima, el Colegio de Ingenieros, Tobias y todos los asistentes al curso.

Por lo experimentado en esos dos días, estoy seguro que se vienen muchas cosas interesantes aquí en nuestro medio en lo concerniente a la aplicación de métodos y prácticas ágiles de desarollo. Estén atentos!

Introducción a OSGi

2008-05-09T23:04:00.006-05:00

Con el lanzamiento de SpringSource Application Platform y el creciente interés de los fabricantes de servidores de aplicaciones JEE en este framework (junto con la popularidad ya ganada de Eclipse como plataforma basada en OSGi) el interés por conocer y aprender los fundamentos detrás de esta tecnología es cada vez mayor.

Pero ¿qué es OSGi exactamente? Bueno, para decirlo en muy pocas palabras:

OSGi is a [component] framework for Java in which units of resources called bundles can be installed. Bundles can export services or run processes, and have their dependencies managed, such that a bundle can be expected to have its requirements managed by the container. Each bundle can also have its own internal classpath, so that it can serve as an independent unit, should that be desireable. All of this is standardized such that any valid OSGi bundle can theoretically be installed in any valid OSGi container.

Para este fin, recomiendo estos dos breves pero útiles artículos sobre el tema:

El primer artículo (del cual extraje la definición) introduce, mediante ejemplos concretos, los principales conceptos de este framework, con código cuya ejecución es demostrada en los contenedores Equinox y Apache Felix, mientras que el segundo explica los conceptos de OSGi dentro del contexto de Eclipse y su utilidad del lado del servidor.

Se prohibe el uso de Waterfall en Indiana, USA

2008-04-25T12:08:00.003-05:00

Este post es algo que no pueden dejar de leer:

State of Indiana Makes Using Waterfall SDLC’s a Criminal Offense

Noticias del curso Certified Scrum Master

2008-04-21T11:18:00.007-05:00

Como pueden leer en el Portal del PMI Chapter Lima, el curso ha sido reprogramado para el lunes 23 y martes 24 de junio. El instructor confirmado hasta el momento es Tobias Mayer. Esta es una muy buena noticia, por la gran experiencia que tiene practicando y enseñado Scrum en diversas empresas. Fue uno de los responsables de introducir Scrum en Yahoo!, como se menciona en este artículo, escrito por un arquitecto de software argentino que asistió al curso.

Hasta donde sé, hay unos 28 interesados en inscribirse (y sólo 25 vacantes) por lo que no dudo que será todo un éxito.

Dilbert Daily Stand-up meetings

2008-04-21T10:49:00.010-05:00

Al volverse las metodologías ágiles (y particularmente Scrum) cada vez más mainstream, encuentra uno cosas como éstas:

Por cierto, Dilbert es una de mis tiras cómicas favoritas y sirve muchas veces (como en este caso) para ilustar muchas de las malas prácticas de gestión, y de clima organizacional en general, que encontramos por doquier en las empresas.

Como ven, las daily stand-up's puede ser muy beneficiosas, pero sólo si se entiende la razón de su aplicación dentro de un contexto de valores, principios y prácticas ágiles. Como leí hace poco, "forman parte de un ecosistema ágil". Queda claro que si dicho ecosistema no existe, esta práctica va a traer muy poco o ningún beneficio a la organización/proyecto, como podemos apreciar gracias a nuestro estimado Pointy Haired Boss.

World Of Warcraft Agility

2008-04-06T23:49:00.009-05:00

En este artículo se exponen varias de las razones por las cuales World Of Warcraft se ha convertido en un suceso mundial en lo que a videojuegos se refiere, constituyéndose, de lejos, en el más exitoso MMORPG (aprox. 10 millones de jugadores). Lo interesante de esto es que de las 11 razones que allí se mencionan, más de la mitad se relacionan a las ventajas que brindan las metodologías ágiles de desarrollo (adaptabilidad a los cambios, feedback constante, diseño evolutivo, trabajo incremental e iterativo). Incluso se hace una mención directa a Scrum y a XP en el punto 7.

Esto es algo digno de destacar, pues el artículo no está orientado a desarrolladores o gente del mundo del software y definitivamente es una muestra más de qué tanto el uso de este tipo de técnicas y prácticas puede ayudar a crear productos innovadores y exitosos.

10 Cosas que Todo Arquitecto de Software Debería Conocer

2008-04-02T15:11:00.004-05:00

Richard Monson-Haefel, uno de los fundadores de los proyectos Geronimo y OpenEJB y miembro de varios grupos importantes de definición de estándares dentro del JCP (JSR-151, JSR-153, JSR-220 y JSR-241) ha publicado una presentación muy interesante sobre las cosas que todo aquel que se hace llamar "arquitecto" dentro de un proyecto o empresa de desarrollo de software (ej: arquitecto de software, arquitecto de soluciones, arquitecto empresarial, etc) debería conocer y entender.

En resumen, son las siguientes:

People are the platform
All solutions are obsolete
Data is forever
Flexibility breeds complexity
Nothing works as expected
Documentation is the universal source code
Know the business
Maintain the vision
Software architects should also be coders
There is no substitute for experience

Este es el enlace para bajar la presentación: 10 Things Every Architect Should know. Me parece una excelente oportunidad de difundir las ideas de Monson-Haefel entre varios de nuestros muy apreciados powerpoint architects (seguramente deben conocer a más de uno).

Digan NO al Crunch Time

2008-03-31T17:58:00.008-05:00

Los gringos le dicen crunch time a esa fase dentro de los proyectos en la cual el equipo de desarrollo ingresa a un estado de sobre-dedicación, trabajando hasta tarde, incluso los fines de semana. Muchos de los que desarrollamos software sabemos, al menos intuitivamente, que esto esto es altamente contraproducente (no me refiero solamente a la salud, estado de ánimo y motivación del equipo) y mientras más tiempo dure, peor.

Lo que no había encontrado hasta ahora era una explicación lo suficientemente documentada como para convencer a un escéptico (léase project manager). La idea básica es que la calidad del código disminuye drásticamente como consecuencia de aplicar esta "práctica".

Aquí tienen un resumen de lo que significa el crunch time y como decir NO:

The Crunch Mode Paradox: Turning Superstars Average

Y esta es la fundamentación detallada de por qué se debe evitar a toda costa:

Why Crunch Mode Doesn't Work: 6 Lessons

Curso Oficial Certified Scrum Master en Lima

2008-03-21T19:49:00.006-05:00

A continuación transcribo un mail que acabo de recibir, de parte del Capítulo PMI de Lima, que muy gratamente me tomó por sorpresa:

Cumpliendo con nuestra propuesta de brindar cursos de nivel avanzado, proponemos a la comunidad PMI, el dictado del curso CSM “CERTIFIED SCRUM MASTER”.

CERTIFIED SCRUM MASTER TRAINING ( CSM), es un curso que consiste en 2 días de Presentaciones, discusión en grupo y ejercicios de tipo interactivo/experiencial, diseñados para enseñar efectivamente los principios y practicas SCRUM. El curso será dictado por un entrenador oficial certificado.

El curso esta dirigido a los potenciales SCRUM MASTERS, a todos aquellos que están trabajando como parte de un equipo, así como los propietarios de producto y a la Gerencia que se beneficiará de los principios y prácticas enseñadas en este curso.

Al finalizar el curso, los participantes recibirán la designación oficial como “CERTIFIED SCRUM MASTER”, un título concedido por la Alianza SCRUM.

Fechas: Lunes 21, Martes 22 Abril 2008 (*).
Costo : US$ 500.00, Incluye Certificación.

Descuentos Especiales:
20% de descuento por inscripción de grupo, mínimo 3 participantes.
15% de descuento por pago adelantado.
10% de descuento para miembros PMI.
Los descuentos no son acumulables.

Las fechas de preinscripción estarán abiertas desde el Lunes 17 hasta el 31 de marzo 2008. Para la Preinscripción enviar sus datos completos o si tuviera alguna consulta, favor enviarlo a este mail: patricia.montero@pmi.org.pe

No me queda más que agradecer a los organizadores. Definitivamente es un oportunidad increíble de aprender, difundir y certificarse en Scrum. Ahí estaré de todas maneras.

(*)[UPDATE: El curso se ha reprogramado para el lunes 23 y martes 24 de junio de 2008. Más información en el Portal del PMI Chapter Lima]

Herramientas para Scrum

2008-03-19T17:24:00.011-05:00

Ya hace varios meses estoy intentando aplicar Scrum en los proyectos en los que me veo involucrado de una u otra forma. Por ahora no voy a entrar en detalles sobre qué es Scrum y para qué sirve. Si no han escuchado hablar de esta metodología de gestión de proyectos de desarrollo de software, pueden encontrar más información aquí:

Lo que quiero comentar es uno de los problemas que uno usualmente encuentra cuando desea aplicar Scrum a un proyecto real. Siendo una metodología bastante ágil, ligera y poco prescriptiva, es muy frecuente realizar una labor de adaptación al contexto real del proyecto en cuestión. Una adaptación fundamental es elegir las herramientas a utilizar para tener visibilidad, control y seguimiento sobre los artefactos propios de Scrum (básicamente product backlog, sprint backlog, burndown chart e impediment list). Sobre este tema se han escrito incontables posts en los blogs y mensajes en la lista de correo oficial de Scrum.

Algo que es casi un consenso dentro de la comunidad Scrum/Ágil es que siempre que sea posible se deben preferir los paneles informativos (también llamados big visible charts o kanban boards) sobre cualquier tipo de herramienta de software. Esto es mucho más fácil cuando todos los miembros del equipo se encuentran en un mismo lugar (la co-localización es fundamental por muchas otras razones también) y tienen el espacio suficiente en la paredes (siempre deberíamos luchar por tener tal ambiente de trabajo).

Pueden encontrarse ejemplos de cómo hacer esto en el excelente libro Scrum and XP from the Trenches y en varías galerías de fotos de equipos que muestran sus paneles, por ejemplo aquí y también acá. La principal ventaja de esta opción es que utiliza el modelo push de transmisión de información versus el modelo pull de una herramienta de software, convirtiéndose en un information radiator. Es decir, un miembro del equipo recibe la información que requiere sobre el estado del proyecto, prácticamente sin ningún esfuerzo de su parte. Esta información es irradiada hacia él casi sin que se dé cuenta. Con solo levantar la mirada tiene una idea de qué es lo que pasa. Como Scrum advoca mantener esta data permanentemente actualizada, se convierte en una poderosa herramienta de comunicación.

Es cuando el equipo se encuentra distribuido en distintas locaciones, o cuando se desea poder utilizar la información para otros fines, o se quiere mantener informado a stakeholders del proyecto que no participan directamente del desarrollo del mismo, que se hace necesario contar con herramientas de sofware que nos permitan compartir la información de manera más sencilla. Para esto cada vez hay más opciones, tanto gratuitas como comerciales. Esta lista es un pequeño resumen de lo que he encontrado por ahí:

Si buscan algo que puedan usar inmediatamente sin necesidad de instalación o de una curva de aprendizaje, pueden utilizar un Excel compartido (si están dentro de una intranet) o algo como Google Spreadsheets si desean comunicarse a través de internet.

Si bien no he probado todas las opciones mencionadas anteriormente, el producto que más he utilizado y que recomendaría es Scrumworks porque provee una licencia gratuita, es bastante sencillo de instalar y utilizar y provee tanto una interfaz de cliente pesado para modificaciones, como una interfaz web para consultas.

Mi recomendación es que hagan lo posible por tener al equipo de desarrollo en un mismo lugar y con comodidad y privacidad suficientes para poder comunicarse y colaborar sin interrupciones externas. Una vez logrado esto coloquen un panel lo suficientemente visible y actualícenlo con la información producto de las reuniones e hitos del proyecto (daily stand-up meetings, sprint planning meeting, sprint review meeting, retrospectivas, etc).

Además de esto, aconsejo utilizar una herramienta de SW para poder comunicar y acceder a la información de manera remota y también a modo de backup (nunca se sabe cuando puede presentarse un temblor o una remodelación inesperada y no autorizada del ambiente físico del proyecto) . Esto también brinda la posibilidad de exportar la información y de transformarla para generar reportes adicionales.

Test Driven Job Hunting?

2008-03-14T15:18:00.012-05:00

Buceando en la red, encontré este aviso de búsqueda de desarrolladores y me pareció un crimen no mencionarlo acá. Definitivamente es bastante original y está inmejorablemente enfocado al grupo de candidatos que podrían y/o desearían postular.

Proviene de una empresa francesa llamada Leirios. Fue publicado hace casi dos años en el mailing list XP Jobs:

LEIRIOS is looking for 2 senior java developers for its R&D department based in Besançon (France). (French-speaking and fluent with technical English)

We develop our products using eXtreme Programming and we are looking for developers mastering agile methodologies and willing to improve development processes.

Our acceptance tests are the following:

class SeniorDeveloperAcceptanceTest extends TestCase {
  Developer candidate;
  Collection team;

public void setUp() {
  candidate = new Developer();
  team = Leirios.getTeam();
}

public void testTechnicalSkills() {
  assertTrue(candidate.isJavaExpert());
  assertTrue(candidate.canDesignLargeApplication());
  assertTrue(candidate.canReduceTechnicalDebt());
  assertTrue(candidate.practiceTDD());
}

public void testTeachingSkills() {
  assertTrue(candidate.canImproveTeamSkills());
  assertTrue(candidate.canArgueAboutAgility());
}

public void testHumanBehavior() {
  assertTrue(candidate.canPairProgram());
  assertTrue(candidate.canIntegrateWith(team));
  assertTrue(candidate.hasPositiveAttitude());
}

public void testMethodologySkills() {
  assertTrue(candidate.knowExtremeProgramming());
  assertTrue(candidate.canImproveTeamVelocity());
}
}

class SeniorDeveloperBonusAcceptanceTest extends TestCase{

String[] bonusSkills = new String[]{
  "canDevelopEclipsePlugins",
  "knowSoftwareEdition",
  "isReallySmart"};

public void testAcceptedCandidate(){
  Collection candidates = Leirios.gatherCandidates();
  Developer toBeHired =
      Leirios.selectCandidateWithMaxBonus(bonusSkills);

  for(Developer candidate: candidates){
      if (candidate.equals(toBeHired))
          assertTrue(Leirios.willHire(candidate));
      else
          assertFalse(Leirios.willHire(candidate));
  }
}
}

LEIRIOS is an innovative software editor, founded in 2003.
(25 people, offices in Paris, Besançon and München).
http://www.leirios.com

Send your application to job at leirios.com

Peopleware (Parte VI)

2008-01-24T12:28:00.001-05:00

Finalmente, esta es la última entrega de los resúmenes del libro Peopleware y corresponde a la sexta sección. Los resúmenes anteriores están en los siguientes enlaces:

PART VI

Whether it is named or not, coaching is an important factor in successful team interaction. It provides coordination as well as personal growth to the participants. It also feels good. We tend to look back on significant coaching we've received as a near religious experience. We feel a huge debt to those who have coached us in the past, a debt that we cheerfully discharge by coaching others.

The act of coaching simply cannot take place if people don't feel safe. In a suitably competitive atmosphere, you would be crazy to let anyone see you sitting down to be coached; it would be a clear indication that you knew less than your coach about some subject matter. You would be similarly crazy to coach someone else, as that person may eventually use your assistance to pass you by.

Our point here is somewhat more limited: Any action that rewards team members differentially is likely to foster competition. Managers need to take steps to decrease or counteract this effect.

The paradox of the CMM is that process improvement is good, but process improvement programs aren't, or at least they often aren't. Competent people are involved in process improvement all the time: They take pride in progress and growth, and these can only come from getting more proficient at what they do. This kind of low-level process refinement is the basic hygiene of knowledge work, but formal process improvement moves responsibility up from the individual to the organization. The individual may strive for, practice, and/or promote good skills, but the organization can only institutionalize them. It is in this institutionalization that the danger lies.

Organizations that build products with the most value to their customers win. Those that build products that make the world yawn lose, even though they build them very, very efficiently. Even those who stumble while building products of high value win over the efficient yawners. Process isn't worth a rip unless it's applied to projects that are worth doing.

When process improvement (as in "Level 3 by the end of the year!") becomes the goal, the scary projects get put onto the back burner. It's those scary projects, unfortunately, that are
probably the ones worth doing. All the projects that carry real benefit carry real risks along
with them. It is the project that has some novelty, some innovation or invention, that might grab the customer's imagination and wallet.

Peopleware (Parte V)

2008-01-24T12:13:00.001-05:00

Esta es la quinta entrega correspondiente al resumen de la quinta sección del libro Peopleware. Pueden acceder a las anteriores entregas aquí:

PART V

A pilot project is one in which you set the fat book of standards aside and try some new and unproved technique. The new technique will be unfamiliar initially, and so you can expect to be inefficient at the start in applying it. This is a cost of change. On the other side of the ledger is the improvement in productivity gained from using the new technique. Also on the plus side of the ledger is the Hawthorne Effect, the boost in energy and interest that infuses your people when they're doing something new and different.

One caveat about pilot projects: Don't experiment with more than one aspect of development technology on any given project. For all the talk about the importance of standards, it's surprising how often managers abandon all standards on the rare project that is designated a pilot. They often try out new hardware, new software, new quality control procedures, matrix management, and new prototyping techniques, all on the same project.

War games help you to evaluate your relative strengths and weaknesses and help the organization to observe its global strengths and weaknesses. For these reasons, two of our client companies are now undertaking a program of annual war games, used by their employees to gauge improvements in their own skills over time. Once a year, they subject themselves to the confidential testing process, much as you would submit yourself to a physical exam.

For the purpose of stimulating creative disorder, the most effective form of war game calls for participants to take part in teams. When you pull this off successfully, people will tell you they've had the most exciting and enjoyable experience of their entire careers; nothing less than that is your goal. Expect to achieve that goal, though it may take a few tries.

Running the project through a whole night, for some reason, adds to the fun. People love an excuse to get tired together, to push back sleep and let their peers see them with their hair down, unshaved, rumpled, and grumpy, with no makeup or pretense. And it makes them feel more closely bound to each other.

Perhaps this is a sad comment on the dismal corporate workplace, but everybody relishes a chance to get out of the office. The chance that workers relish most is one combining travel with their peers and a one-of-a-kind experience. It might be going off together for a training session, particularly a provocative one, or taking in the International Conference on Whatever.

Is a few thousand dollars for a getaway experience too rich for your discretionary disorder budget? Maybe you could spring for forty dollars. One of the most innovative managers we know has a penchant for putting on unexpected lunches for his staff. He once went down to the city street and hired a hot dog vendor, complete with cart, sauerkraut, yellow mustard, and a blue and orange umbrella, to come up thirty floors and serve lunch to the team. The
lunch was a nutritionist's nightmare but a sociologist's dream come true. Those who were there got high on good spirits and began to do bits and skits about their work, their managers, and each other. The noise level went up with their enthusiasm. It cost forty dollars and has been talked about ever since. Of course, that manager wrote it up as a business lunch, but it wasn't a lunch at all, it was a celebration.

The mark of the best manager is an ability to single out the few key spirits who have the proper mix of perspective and maturity and then turn them loose. Such a manager knows that he or she really can't give direction to these natural free electrons. They have progressed to the point where their own direction is more unerringly in the best interest of the organization than any direction that might come down from above. It's time to get out of their way.

It doesn't take great prescience to see that one of these measures is all you're likely to pull off successfully. If you try more, you will just diffuse your efforts. The rumpus you'll raise will be more confusing than constructive, and your colleagues and those above you in the corporate hierarchy are likely to write you off as a whiner. One change is plenty. Even a single substantive change to the sociology of your organization will be a mammoth accomplishment.
The key to success in fostering the kind of change we're advocating is that you not try to wrestle the bull. You're certainly not strong enough for that.A single person acting alone is not likely to effect any meaningful change. But there's no need to act alone. When something is
terribly out of kilter (like too much noise in the workplace), it takes very little to raise people's consciousness of it. Then it's no longer just you. It's everyone.

Sociology matters more than technology or even money. It's supposed to be productive, satisfying fun to work. If it isn't, then there's nothing else worth concentrating on. Choose your terrain carefully, assemble your facts, and speak up. You can make a difference...
Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

Sobre optimización de aplicaciones

2008-01-02T15:51:00.000-05:00

Acerca de la optimización prematura de aplicaciones hay tres citas famosas que copiaré a continuación:

"The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." - Michael A. Jackson
"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

Creo que ya pueden intuir por donde va mi opinión al respecto. Básicamente, la tendencia moderna dentro de la ingeniería de software es escribir código bien diseñado desde el punto de vista del paradigma de programación que se esté utilizando (ej: OOP) y legible, es decir, que sea comprensible para aquellos que lo van a mantener o modificar en el futuro. Por lo tanto, debería ser expresivo, minimizar las duplicaciones y exhibir, idealmente, algunas (o todas) de las cualidades mencionadas aquí.

Esto no quiere decir que uno debe olvidarse del rendimiento de la aplicación. Lo hay que tener es la capacidad de comprender y prevenir aquéllos puntos críticos donde el performance podría verse adversamente afectado. Como bien sabemos, casi todos los sistemas empresariales actuales tienen interfaces a sistemas externos (bases de datos, ERPs, middlewares, legacies, etc). Por lo tanto, hay que tener en cuenta todas estas interacciones, junto con la configuración del application server y de la JVM, pues el rol que juegan en el ámbito del rendimiento suele ser mucho mayor que, por citar algo que comúnmente se menciona, la cantidad de instancias de una determinada clase.

En realidad, lo que se recomienda al diagnosticar y resolver problemas de performance es aplicar un enfoque similar al que explican en este artículo. La idea es eliminar todas las posibles causas externas para un rendimiento subóptimo antes de empezar a revisar el código (asumiendo que el código está bien estructurado y diseñado).

Desde luego, como las suposiciones siempre son peligrosas, todo buen desarrollo debe efecutar pruebas periódicas de stress y rendimiento (de preferencia lo más pronto posible) para encontrar y corregir problemas antes de que exploten en producción. Para esto hay herramientas específicas que se pueden utilizar (load testers, profilers, extensiones de JUnit como JUnitPerf, etc)

En conclusión, mi recomendación (y la de muchas otras personas dentro de la industria), en lo que al desarrollo de aplicaciones empresariales se refiere, va por privilegiar un buen diseño que exprese el dominio del problema o negocio lo mejor posible mediante un código correctamente estructurado y lo más legible posible. Una vez alcanzado este objetivo, los problemas de performance (que siempre los hay) se pueden atacar y resolver con las herramientas adecuadas.

Peopleware (Parte IV)

2007-12-13T15:22:00.001-05:00

Despues de varios meses, me animo a continuar publicando el resumen con lo más resaltante de Peopleware. A continuación la cuarta entrega correspondiente a la cuarta sección del libro. He aquí las anteriores:

PART IV

Believing that workers will automatically accept organizational goals is the sign of naive managerial optimism. The mechanism by which individuals involve themselves in the organization's objectives is more complex than that. You wouldn't be surprised to learn, for example, that the fellow you know as a database specialist is more inclined to describe himself as a father, a boy scout leader, and a member of the local school board. In these roles, he makes thoughtful value judgments all the time. What would be a surprise is if he stopped making value judgments when he arrived at work. He doesn't He is continually at work examining each claim for his individual energies and loyalty. Organizational goals come in for constant scrutiny by the people who work for the organization, and most of those goals are judged to be awfully arbitrary.

While the executive committee may get itself all heated up over a big increase in profits, this same objective is pretty small potatoes to people at the bottom of the heap.

Goals of corporations are always going to seem arbitrary to people-corporations seem arbitrary to people-but the arbitrariness of goals doesn't mean no one is ever going to accept them. If it did, we wouldn't have sports. The goals in sports are always utterly arbitrary.
The Universe doesn't care whether the little white ball goes between the posts at Argentina's end of the field or those at Italy's. But a lot of people get themselves very involved in the outcome. Their involvement is a function of the social units they belong to.

We stopped talking about building teams, and talked instead of growing them. The agricultural image seemed right. Agriculture isn't entirely controllable. You enrich the soil, you plant seeds, you water according to the latest theory, and you hold your breath. You just might get a crop; you might not. If it all comes up roses, you'll feel fine, but next year you'll be you'll be sweating it out again. That's pretty close to how team formation works.

If the staff comes to believe it's not allowed to make any errors of its own, the message that you don't trust them comes through loud and clear. There is no message you can send that will better inhibit team formation.

The common thread is that good managers provide frequent easy opportunities for the team to succeed together. The opportunities may be tiny pilot sub-projects, or demonstrations, or simulations, anything that gets the team quickly into the habit of succeeding together. The
best success is the one in which there is no evident management, in which the team works as a genial aggregation of peers. The best boss is the one who can manage this over and over again without the team members knowing they've been "managed." These bosses are viewed by their peers as just lucky. Everything seems to break right for them. They get a fired-up team of people, the project comes together quickly, and everyone stays enthusiastic through the end. These managers never break into a sweat. It looks so easy that no one can believe they are managing at all.

If you've got decent people under you, there is probably nothing you can do to improve their chances of success more dramatically than to get yourself out of their hair occasionally. Any easily separable task is a perfect opportunity. There is no real management required for such work. Send them away. Find a remote office, hire a conference room, borrow somebody's summer house, or put them up at a hotel. Take advantage of off-season rates at ski areas or at beaches. Have them go to a conference, and then stay over for a few days to work together in peace. (We've heard of a least one instance of each of these ploys.)

Such a plan will cost you some points with your own management and peers, because it's so audacious. How can you know, they'll ask you, that your people aren't loafing this very minute? How can you be sure they won't knock off for lunch at eleven and drink away their afternoons? The simple answer is you'll know by the product they come back with. By their fruits, ye shall know them. If they bring back a carefully thought-out and complete result, they worked. If they don't, they didn't. Visual supervision is a joke for development workers. Visual supervision is for prisoners.

Presented below is an admittedly simplistic list of the elements of a chemistry-building strategy for a healthy organization:

Make a cult of quality.
Provide lots of satisfying closure.
Build a sense of eliteness.
Allow and encourage heterogeneity.
Preserve and protect successful teams.
Provide strategic but not tactical direction.

Organizations also have some need for closure. Closure for the organization is the successful finish of the work as assigned, plus perhaps an occasional confirmation along the way that everything is on target (maybe a milestone achieved or a significant partial delivery completed). How much confirmation corporations require is a function of how much money is at risk. Frequently, closure only at the end of a four-year effort is adequate for the needs of the organization.

People require a sense of uniqueness to be at peace with themselves, and they need to be at peace with themselves to let the jelling process begin. When management acts to stifle uniqueness, uniqueness happens anyway. People simply express their uniquenessin uncontrolled dimensions. For example, employees who tak a perverse pride in being difficult to manage or hard to motivate or unable to work with others may be reacting to too much control. They would almost certainly rather express themselves in some less difficult way, something that would not work to the detriment of the group's effectiveness.

If a team does knit, don't break it up. At least give people the option to undertake another project together. They may choose to go their separate ways, but they ought to have the choice. When teams stay together from one project to the next, they start out each new endeavor with enormous momentum.

You can't always make it happen, but when a team does come together, it's worth the cost. The work is fun, the people are energized. They roll over deadlines and milestones and look for more. They like themselves. They feel loyal to the team and to the environment that allows the team to exist.

Waterfall

2007-02-20T22:16:00.000-05:00

Como muchos ya sabemos, esta conocida y ampliamente utilizada metodologia de desarrollo (o modelo de ciclo de vida) de software no funciona. Revisen esta pagina, creada en tono de burla, para que se den una idea de por que....

Waterfall 2006

Algunas secciones destacables (que me hicieron retorcer de risa):

Finalmente, un pensamiento:

"Waterfalls are wonderful tourist attractions. They are spectacularly bad strategies of organizing software development projects."

Scott Ambler

La Historia de las Consolas de Videojuegos

2006-12-23T22:42:00.001-05:00

Este articulo de PC World es bastante nostalgico, completo y atrayente visualmente. Muestra la historia de las consolas de videogames (desde Pong, pasando por Atari 2600, NES, SuperNES, PSOne, etc... hasta llegar a XBOX 360, Wii y PS3).

Lo novedoso es que la historia es contada unicamente a traves de comerciales de TV de las respectivas epocas. Disfruten!

A Brief History of Game Consoles, as Seen in Old TV Ads

Creating passionate Users

2006-11-18T00:35:00.000-05:00

Este blog es excelente.... tanto conocimiento que no se encuentra facilmente acerca de como funcionamos como personas y como afecta esto lo que hacemos (vida familiar, profesional, academica, etc). Para muestra dos botoncitos:

Angry/negative people can be bad for your brain

Add graphics to your blog, book, or presentation

Basecamp

2006-11-15T03:53:00.000-05:00

Estoy revisando esta herramienta de Gestión de Proyectos y Colaboración y me parece muy buena. Tiene un enfoque bastante ágil, intuitivo y sencillo pero a la vez poderoso. Ha sido desarrollada entre otras cosas con RubyOnRails y Ajax. Aunque no es Open Source, se puede probar gratuitamente y las tarifas que cobran son razonables incluso para proyectos pequeños.

Definitivamente, una alternativa válida para los que (como yo) desconfiamos y estamos hartos de Microsoft Project!

Hasta la gente Microsoft lo reconoce:

"Basecamp is the first product I have seen that is truly project management for everyone"
"I worked in the project management software industry for nearly fifteen years and Basecamp is the first product I have seen that is truly project management for everyone. It is nice to see someone finally figured it out."-Jim Dunnigan, Former Product Manager Microsoft Project
Fuente: http://www.basecamphq.com/buzz

Joel on Software

2006-10-27T10:23:00.000-05:00

Hace poco descubir esta pagina (blog?) y me parecio altamente recomendable para cualquiera que desee saber mas sobre la profesion de desarrollo de software (en un sentido amplio) desde el punto de vista de alguien con experiencia e historias que contar. El susodicho (Joel Spolsky) tiene años haciendo esto, incluso antes que los blogs fueran populares. Aqui una seleccion de sus cronicas, para que se entretengan y aprendan un poco:

Si les vacilo, una seleccion aun mayor ha sido publicada como libro. Esta barato, asi que pueden aprovechar.

Life at Google

2006-10-27T10:14:00.000-05:00

Este post esta bastante interesante. El tio explica como es el ambiente y la filosofia de trabajo en Google. Aunque no estoy necesariamente de acuerdo con su vision sobre las metodologias agiles:

http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

Peopleware (Parte III)

2006-07-26T19:17:00.000-05:00

Continuando con lo mejor de Peopleware (IMHO, por supuesto), aquí esta lo correspondiente a la tercera parte del libro. Si no lo han hecho, les recomiendo que primero revisen los posts anteriores:

PART III

Management science is much more concerned with the boss's role as principal strategist and tactician of the work. You are taught to think of management as playing out one of those battle simulation board games. There are no personalities or individual talents to be reckoned with in such a game; you succeed or fail based on your decisions of when and where to deploy your faceless resources.

get the right people
make them happy so they don't want to leave
turn them loose
Anything that upsets the weak manager is almost by definition unprofessional. So popcorn is unprofessional. Long hair is unprofessional if it grows out of a male head, but perfectly okay if it grows out of a female head. Posters of any kind are unprofessional. Comfortable shoes are unprofessional. Dancing around your desk when something good happens is unprofessional. Giggling and laughing is unprofessional. (It's all right to smile, but not too often.)
Conversely, professional means unsurprising. You will be considered professional to the extent you look, act, and think like everyone else, a perfect drone. Of course, this perverted sense of professionalism is pathological. In a healthier organizational culture, people are thought professional to the extent they are knowledgeable and competent.
Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.
Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.
Manager: Do you work with flaming objects?
Candidate: Sure.
Manager: ... knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.
Manager: Do you have a line of funny patter that goes with your juggling?
Candidate: It's hilarious.
Manager: Well, that sounds fine. I guess you're hired.
Candidate: Umm ... Don't you want to see me juggle?
Manager: Gee, I never thought of that.

Aptitude tests are almost always oriented toward the tasks the person will perform immediately after being hired. They test whether he or she is likely to be good at statistical analysis or programming or whatever it is that's required in the position. You can buy aptitude tests in virtually any technical area, and they all tend to have fairly respectable track records at predicting how well the new hire will perform. But so what? A successful new hire might do those tasks for a few years and then move on to be team leader or a product manager or a project head. That person might end up doing the tasks that the test measured for two years and then do other things for twenty.
The idea is simple enough. You ask a candidate to prepare a ten- or fifteen-minute presentation on some aspect of past work. It could be about a new technology and the experience with first trying it out, or about a management lesson learned the hard way, or about a particularly interesting project. The candidate chooses the subject. The date is set and you assemble a small audience made up of those who will be the new hire's co-workers.
Of course the candidate will be nervous, perhaps even reluctant to undertake such an experience. You'll have to explain that all candidates are nervous about the audition and give your reasons for holding one: to see the various candidates' communication skills, and to give the future co-workers a part in the hiring process. At the end of the audition and after the candidate has left, you hold a debriefing of those present. Each one gets to comment on the person's suitability for the job and whether he or she seems likely to fit well into the team. Although it's ultimately your responsibility to decide whether to hire or not, the feedback from future co-workers can be invaluable. Even more important, any new person hired is more likely to be accepted smoothly into the group, since the other group members have had a voice in choosing the candidate.
In companies with high turnover, people tend toward a destructively short-term viewpoint, because they know they just aren't going to be there very long. So if you find yourself campaigning for better workspace for your staff, for example, don't be surprised to bump into someone up the hierarchy who counters with an argument like this:
"Hold on there, Buster. You're talking about big bucks. If we gave our engineers that much space and noise protection and even privacy, we might end up spending fifty dollars per person per month! Multiply that times all the engineers and you're into the tens of thousands of dollars. We can't spend that kind of money. I'm as much in favor of productivity as the next guy, but have you seen what a terrible third quarter we're having?"
Many of us have come to believe that companies that promote early are where the action is. That's natural, because as young workers we're eager to get ahead. But from the corporate perspective, late promotion is a sign of health. In companies with low turnover, promotion into the first-level management position comes only after as much as ten years with the company. (This has long been true of some of the strongest organizations within IBM, for example.) The people at the lowest level have on the average at least five years' experience. The hierarchy is low and flat.

The insidious effect here is that turnover engenders turnover. People leave quickly, so there's no use spending money on training. Since the company has invested nothing in the individual, the individual thinks nothing of moving on. New people are not hired for their extraordinary qualities, since replacing extraordinary qualities is too difficult. The feeling that the company sees nothing extraordinary in the worker makes the worker feel unappreciated as an individual. Other people are leaving all the time, so there's something wrong with you if you're still here next year.

Peopleware (Parte II)

2006-06-26T23:14:00.000-05:00

Continuando con mi humilde selección de lo más resaltante de Peopleware, aquí esta lo correspondiente a la segunda parte del libro. Revisen también el post anterior.

PART II

Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It's only when you're in flow that the work goes well.

Unfortunately, you can't turn on flow like a switch. It takes a slow descent into the subject, requiring fifteen minutes or more of concentration before the state is locked in. During this immersion period, you are particularly sensitive to noise and interruption. A disruptive environment can make it difficult or impossible to attain flow.

If the average incoming phone call takes five minutes and your reimmersion period is fifteen minutes, the total cost of that call inflow time (work time) lost is twenty minutes. A dozen phone calls use up half a day. A dozen other interruptions and the rest of the work day is gone. This is what guarantees, "You never get anything done around here between 9 and 5."

If you're a manager, you may be relatively unsympathetic to the frustrations of being in no-flow. After all, you do most of your own work in interrupt mode -that's management- but the people who work for you need to get into flow. Anything that keeps them from it will reduce their effectiveness and the satisfaction they take in their work. It will also increase the cost of getting the work done.

What matters is not the amount of time you're present, but the amount of time that you're -working at full potential. An hour in flow really accomplishes something, but ten six-minute work periods sandwiched between eleven interruptions won't accomplish anything.

Management, at its best, should make sure there is enough space, enough quiet, and enough ways to ensure privacy so that people can create their own sensible workspace. Uniformity has no place in this view. You have to grin and bear it when people put up odd pictures or leave their desks a mess or move the furniture around or merge their offices. When they've got it just the way they want it, they'll be able to put it out of their minds entirely and get on with the work.

We are trained to accept windowless office space as inevitable. The company would love for every one of us to have a window, we hear, but that just isn't realistic. Sure it is. There is a perfect proof that sufficient windows can be built into a space without excessive cost. The existence proof is the hotel, any hotel. You can't even imagine being shown a hotel room with no window. You wouldn't stand for it. (And this is for a space you're only going to sleep in.) So hotels are constructed with lots of windows.

Even if there is a higher cost per worker to house people in the more agreeable space, the added expense is likely to make good sense because of the savings it provides in other areas. The real problem is that the cost is in a highly visible category (space and services), while the offsetting advantage is in poorly measured and therefore invisible categories (increased productivity and reduced turnover).

Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

El auge y la caida de CORBA

2006-06-20T11:17:00.000-05:00

Este artículo me parece interesante. Habla de por qué fracasó CORBA como tecnología distribuida. En resumen, según el autor, se debió a graves errores técnicos y políticos (OMG):

The Rise and Fall of CORBA

Como para que los profes de algunos cursos de mi alma mater le den una revisada... no?

Peopleware (Parte I)

2006-06-13T13:25:00.000-05:00

Este libro es excelente en mi opinión, así que he decidido colocar los extractos que me parecen más resaltantes. Todo programador, desarrollador, líder técnico, funcional, arquitecto o jefe de proyecto debería leerlo. Mejor aún si lo compran. Aquí va lo más resaltante de la primera parte:

PART I

The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work.

The project that has to be done by an impossible fixed date is the very one that can't afford not to have frequent brainstorms and even a project dinner or some such affair to help the individual participants knit into an effective whole.

The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.

The Eagle project at Data General is a case in point. The project was a Spanish Theory triumph: Workaholic project members put in endless unpaid overtime hours to push productivity to unheard of levels. At the end of the project, virtually the entire development staff quit.

People under time pressure don't work better; they Just work faster. In order to work faster, they may have to sacrifice the quality of the product and their own job satisfaction.

We all tend to tie our self-esteem strongly to the quality of the product we produce, not the quantity of product, but the quality. Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.

Managers jeopardize product quality by setting unreachable deadlines.

The nation (Japan) that is an acknowledged quality leader is also known for its high productivity. The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.

Hewlett-Packard is an example of an organization that reaps the benefits from increased productivity due to high, builder-set quality standards. The company makes a cult of quality. In such an environment, the argument that more time or money is needed to produce a high-quality product is generally not heard. The result is that developers know they are part of a culture that delivers quality beyond what the marketplace requires. Their sense of quality identification works for increased job satisfaction and some of the lowest turnover figures seen anywhere in the industry.

In some Japanese companies, notably Hitachi Software and parts of Fujitsu, the project team has an effective power of veto over delivery of what they believe to be a not-yet-ready product. No matter that the client would be willing to accept even a substandard product, the team can insist that delivery wait until its own standards are achieved. Of course, project managers are under the same pressure there that they are here: They're being pressed to deliver something, anything, right away. But enough of a quality culture has been built up so that these Japanese managers know better than to bully their workers into settling for lower quality.

In a healthy work environment, the reasons that some people don't perform are lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. In none of these cases is schedule pressure liable to help very much. When a worker seems unable to perform and seems not to care at all about the quality of his work, for example, it is a sure sign that the poor fellow is overwhelmed by the difficulty of the work. He doesn't need more pressure. What he needs is reassignment, possibly to another company.

"In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group. She was a walking example of much of what I now think of as enlightened management. One snowy day, I dragged myself out of a sick bed to pull together our shaky system for a user demo. Sharon came in and found me propped up at the console. She disappeared and came back a few minutes later with a container of soup. After she'd poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do. She gave me her patented grin and said, Tom, this is management."

Copyright © 1999, 1987 by Tom DeMarco and Timothy Lister.

Decisiones... cada dia....

2006-06-09T11:11:00.000-05:00

Este texto me parecio un buen resumen de las decisiones que debemos enfrentar cuando desarrollamos aplicaciones Web J2EE (o Java EE). IMHO, tener el poder de decidir es bueno. Es uno de los pilares de la democracia y es una de las razones por las cuales prefiero el modelo open source a la dictadura de Microsof.

Yes, there seems to be nothing but choice when it comes to developing web applications.

To begin with, someone has to choose between ASPX, Java, PHP, Python, Ruby, et al. Once you choose Java, then you have to choose a web container, such as Jetty, Tomcat, Resin, WebLogic, or WebSphere, to name a few. Of course, you also have to build the application that runs in the container, which is where choosing Apache Struts comes in. Then, most teams also use a data access framework. Choices there include Cayenne, iBATIS, Hibernate, JDO, Turbine, and OJB, to name a few.

(Right about now, Ruby's single-stack approach must be sounding pretty good!)

But, wait, there's more! You also have to choose an editor or IDE: Eclipse? IDEA? NetBeans? UltraEdit? Some other? (Many teams decide to use more than one!) And do we use Ant, Maven, or the IDE to build it all?

Lest we forget: Someone also needs to choose a database system (DB2? Derby? Oracle? PostGres? MySQL?), a version control system (CVS? Subversion? Perforce?), a development methodology (eXtreme Programming? RUP? Scrum? Waterfall?), and, if you're lucky, an issue tracker (Bugzilla? JIRA? Scarab?).

Welcome to the jungle!

Tomado de: http://struts.apache.org/roadmap.html#choice

El Codigo Florinchi (Parte II)

2006-06-02T13:40:00.000-05:00

En nuestro ultimo episodio, nuestros heroes se encontraron ante un misterio aparentemente insodable.

Sigamos ahora con la historia...

Despues de la info proporcionada por los "tios del cliente", decidimos buscar en internet el parche para las clases propietarias de encriptacion. Finalmente lo encontramos en la pagina del proveedor (aunque no estaba muy visible que digamos). Pero, una vez mas, la suerte jugo en contra. Al intentar bajarlo, por algun motivo el browser nos daba time-out. Se habra caido la pagina? -pensamos.

Tras un par de llamadas a la gente indicada nos enteramos que la conexion a internet se habia caido en esa zona de San Isidro! En este punto ya empezamos a conjeturar por que estabamos teniendo tan mala suerte en este fuxxxing pase a produccion!! Y entonces........ sucedio.

Al voltear la mirada vimos la fuente de nuestra desdicha. Teniamos frente a nuestros ojos a Mr. Flores (alias Flowers). Ya empiezan a entender el por que del titulo de la presente saga... Y quien es este personaje? -se preguntara Uds. Pues es nada menos que uno de los "tios del cliente", el cual estaba a cargo del pase. El problema con el susodicho -que por cierto es buena gente y no tengo nada personal contra el- es que tiene una mala suerte con los pases a produccion que ni el personaje de Hanna-Barbera se le compara . Para muestra, baste decir que una vez empezo un pase un viernes por la noche y termino el domingo a las 3pm. Y no es exageracion...

Pero volvamos a la historia... tras intentar una y otra vez bajar el parche, finalmente lo conseguimos y tras unos pequeños tropiezos con la instalacion del mismo -pues no estaba bien documentada- todo salio bien. Al momento de probar el producto, sin embargo, obtuvimos nuevos mensajes de error. El tiempo seguia corriendo y si o si teniamos que dejar todo operativo para la mañana siguiente o eramos historia.

Indagando en los logs del servidor de aplicaciones y del web server, descubrimos que este ultimo estaba teniendo dificultades al intentar comunicarse con el primero mediante SSL. Buscando de nuevo en internet, decidimos bajar el ultimo parche del servidor web. Nos llevamos otra sorpresa cuando vimos que no habian parches sino que habia que reinstalar el servidor web... en fin. A estas alturas ya no podiamos ponernos exigentes.

Hicimos un backup del archivo de configuracion y reinstalamos el servidor. Al probar de nuevo la conexion, encontramos nuevos errores. Despues de un par de maldiciones a la mala suerte de Flowers, decidimos regenerar el certificado digital para reconfigurar la comunicacion SSL entre los servers. Finalmente lo logramos, pero al hacer la prueba obtuvimos nuevos errores. Esta vez, Jadclipse mediante, vimos que el problema era que el producto no podia desencriptar los passwords almacenados en los archivos de configuracion. Casi seguro se debia al upgrade que habiamos hecho de las librerias de seguridad.

Ya eran casi las 2 am y nuestra paciencia, si bien no se agotaba, ya saba señales de cansancio. Afortunadamente, los "tios del cliente" se portaron bien y compraron un pollito a la brasa, el cual fue devorado por los presentes. Armandonos de valor, buscamos el mensaje de error en la documentacion on-line y por suerte encontramos una pista.

Si bien lo que hallamos se referia a otra version del producto, al parecer aplicaba a nuestra situacion. La solucion pasaba por correr unos queries en la BD y regenerar otros archivos mediante comandos. Al realizar esto y probar otra vez... finalmente funciono! Pudimos extraer los documentos del servidor de contenido y todo se veia bien.

Sin embargo, la mala suerte de Flowers paracia no descansar. Esto lo descubrimos al salir del edificio y dirigirnos al estacionamiento donde el Agente X habia dejado su auto. Era tan tarde que estaba cerrado y no habia nadie que nos abriera las rejas.... chess!!! Despues de un par de gritos y forcejeos decidimos zafar a nuestros hogares... en el fondo satisfechos de haber cumplido la tarea.

Pero aun hay mas!! ....Cuando todo parecia bien... al dia siguiente tuvimos una desagradable sorpresa. Como nos habiamos amanecido en el bendito pase, nos correspondia llegar tarde a la chamba. Pero a eso de las 10 u 11 recibi varias llamadas de gente del cliente y de mi empresa diciendo que los usuarios no podian conectarse a "El Content" y subir sus documentos escaneados. Diablos!! Si ayer todo funcionaba....

Tuve que dejar mi merecido descanso y volar al lugar del desastre para encontrar que simplemente se trataba de un error de conexion. Como la prueba que habiamos hecho la noche anterior fue en el mismo server todo habia salido OK. El tema era que al regenerar el certificado digital habiamos cambiado el hostname por el nombre calificado de la maquina (hostname + dominio) y las maquinas de los usuarios estaban apuntando al nombre anterior.

Para colmo, el servidor de contenido no estaba inscrito en el servidor DNS -por extrañas razones que no comprendo-, sino que estaba en cada archivo hosts de los usuarios. Y, obviamente, solo estaba el nombre corto. Corregido este impase todo fluyo a la perfeccion y pudimos respirar tranquilos.... no sin antes decir una vez mas... Flowers salado!!

El Codigo Florinchi (Parte I)

2006-05-24T02:29:00.000-05:00

Lo que supuestamente iba a ser un relativamente normal pase a produccion de fixes en los servidores del ambiente de produccion del cliente XYZ SAC -normal segun los estandares del cliente en cuestion (o sea, de dos a 3 horas extras de trabajo nocturno) -terminó conviertiendose en una busqueda casi interminable de errores plagada de pistas e indagaciones digna de la proxima novela de Dan Brown. Claro, si Brown esuviera interesado en retratar el devenir de un grupo de arquitectos de SW, gente de infraestructura y programadores.

Pero vamos por partes. Nuestra mision imposible, que decimos aceptar pues nadie nos pregunto si queriamos o no, era parchar un producto que llamaremos "El Content" que sirve para la administracion y manejo de contenido de todo tipo, el cual es vendido por una conocida empresa transnacional de IT y que actualmente utiliza extensivamente el cliente XYZ SAC.

Por motivos de falta de coordinacion y prevencion se decidio cancelar el pase a eso de las 9 pm. Sin embargo ya habiamos realizado el primer paso que consistia en backapear la BD que usa "El Content". Antes de irnos reiniciamos el server y procedimos a probar que todo funcionaba OK.

Grande fue nuestra sorpresa cuanto intentamos acceder a los documentos almacenados y obtuvimos errores innesperados. Sospechando que este percance nos iba a tomar mas tiempo de lo calculado, decidimos convocar refuerzos, o mas bien un refuerzo, alguien quien tiene amplia experiencia con el producto y que estaba planeado que viniera de todas maneras, pero que aun no llegaba pues tenia un compromiso previo ese dia. Llamemoslo Agente X.

Al llegar el susodicho se puso a revisar el estado del backup, el cual se habia realizado con exito. Porsiaca corrio uno mas y tambien termino OK. La BD estaba consistente y podiamos loguearnos sin problemas. El error ocurria cuando accediamos al contenido propiamente, el cual es provisto por un servidor de aplicaciones J2EE de una version un tanto antigua (digamos que era V2 y la actual es V4). Lo extraño es que ni siquiera habiamos tocado el dichoso servidor por lo que nuestra perplejidad se duplico. Y esta se triplico al ver en el log un mensaje de NoClassDefFoundError.

Varias preguntas rondaron mi cabeza: ¿Como era posible que faltara una clase en una aplicacion que viene con un producto como este? ¿Como podia pasar asi de pronto? Tenia que haber una explicacion logica y como tanto el Agente X y yo somos tercos y nos gusta resolver problemas (ademas que teniamos a los tios responsables del pase por parte del cliente "watching our backs") teniamos que encontrar la causa y resolver el impase.

Nos decimos a sacar el kit de rastreo de huellas digitales, o sea el poderoso JadClipse para descompilar las clases Java del producto que estaban lanzanado el NoClassDefFoundError. Fue asi que llegue a la madre del cordero. Al parecer el error se lanzaba al momento de instanciar mediante reflection una clase propietaria para encriptacion/desencriptacion. Pero, ¿como era posible que una clase que estaba funcionando bien se no se pueda instanciar de repente? ¿Era acaso que las clases tiene fecha de caducidad o algo asi? jeje.... nica.....

Pues......sica! Haciendo memoria por parte de los tios del cliente, resulto que habian recibido un mail de parte de la empresa que fabrica el producto hacia un par de dias atras que decia que el 18 de mayo del 2006 vencian las clases de encriptacion usadas en la version de App Server que estabamos usando!!

To be continued...

Bienvenidos

2006-05-23T18:35:00.000-05:00

Bueno, por fin me anime a crear un blog 'geek'. Aunque en realidad no sera tan geek pues pienso colgar historias personales, claro que siempre relacionadas al ambiente desarrollo de software en los ambientes y empresas que conozco personalmente y por amistades. Espero lo disfruten!