Agile y software embebido

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"

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?

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:

1. La red es confiable.
2. La latencia es cero.
   
3. El ancho de banda es infinito.
   
4. La red es segura.
   
5. La topología no cambia.
   
6. Existe un único administrador.
   
7. El costo del transporte es cero.
8. 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

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

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”

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

[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ú

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

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:

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


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


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


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


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


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


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


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


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


10. 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

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

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:

• OSGi for Beginners
• Eclipse, Equinox and OSGi

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

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

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

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

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

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

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

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

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í:

• Scrum et al.
• Scrum en Wikipedia
• What is Scrum?
• The Scrum Development Process
• Scrum Alliance

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í:

• Agilo for Scrum
• Banana Scrum
• Tackle
• Scrumworks
• XPlanner
• Ice Scrum
• Mingle
• Rally Software
• Version One
• Scrum for Team System

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?

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)

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:

• Peopleware (Parte I)
• Peopleware (Parte II)
• Peopleware (Parte III)
• Peopleware (Parte IV)
• Peopleware (Parte V)

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.

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

Peopleware (Parte V)

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

• Peopleware (Parte I)
• Peopleware (Parte II)
• Peopleware (Parte III)
• Peopleware (Parte IV)
  

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

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.