Angel "Java" Lopez : Desarrollo de Software, Ingeniería de Software

Manejo del riesgo en proyectos

lopez — Fri, 31 Oct 2008 12:22:03 GMT

El bueno de Maximiliano Amoretti ha escrito una serie de posts sobre manejo del riesgo en proyectos de software:

Permanent Link to Risk Management - Administración de riesgos

Permanent Link to Risk Management [II]- Herramientas para la administración de riesgos

Permanent Link to Risk Management [III]- Aplicación del Radar de Riesgos

Maximiliano ha participado de varios proyectos, y ha sido uno de los líderes de un proyecto a principios de año, que involucró varias semanas, nueva tecnología, y presión de tiempo (timeboxed), con definiciones que cambiaban en el tiempo, todo manejado desde un proceso ágil a la Scrum.

Al comienzo del primer post recuerda la frase:

“En todo contexto de la vida, la primera y más importante manera de evitar víctimas y desastres, es comenzando por la prevención. ¿Por qué no en nuestro proyecto?”

Ciertamente, es una práctica a recomendar en varios proyectos. Ya escribí algunos puntos de lo que puede ir mal en un proyecto, para destinarlo al fracaso:

¿Por qué fallan los proyectos de software-

Algunas frases a destacar de los posts:

El monitoreo debe ser mirando hacia el futuro, y no al presente. El “radar” debe estar encendido constantemente.

Informar: Tener conciencia de las cosas elimina dudas y sorpresas .... “El que avisa, no traiciona…”

Las herramientas deben ser ágiles, simples y estar siempre a la vista.

Muchas veces nos olvidamos de esos puntos. Lo de "estar siempre a la vista" lo extendería a todo el equipo. Cuando hay un equipo donde, digamos, un Project Manager, no comparte esa información, es un indicio de problema. La comunicación de los posibles riesgos de todo tipo, y sus mitigaciones, tiene que darse de tal forma que todo el equipo esté advertido, "aware", de lo que pueda suceder.

Es interesante que Maximiliano mencione una herramienta de representación gráfica, el Radar de Riesgos. Como seres humanos, captamos mejor la situación con una imagen, que tal vez con un informe o cifras. Las habilidades de presentación de una situación, no deben minizarse en un proyecto, y menos, en un proyecto ágil. Tratemos siempre de obtener alguna representación gráfica del estado del proyecto, su evolución, y otras métricas. No tienen por qué hacer un gráfico con un gran programa: un dibujo en papel, basta para transmitir la idea. Lo bueno de las herramientas gráficas, es que podemos cambiar los datos, sobre el mismo gráfico, y cortar/pegar lo producido en otros documentos.

Les recomiendo una lectura de los libros mencionados en los posts, especialmente el de Covey (más allá del desarrollo de software) y el de "Practical Project Initiation". Siempre es bueno encontrar posts que mencionen las fuentes, para poder ir profundizando en el tema tratado.

Un tema a discutir lo encuentro cuando Maximiliano comenta sobre los riesgos técnicos:

... Suelen ser comunes, pero a mi parecer, son los de más fácil mitigación. En un equipo con ganas, la mayoría de las veces se podrán resolver los nuevos “desafíos”, o buscar un camino alternativo.

Como muchas otras cosas, depende del contexto. Hay proyectos donde su núcleo se basa en una tecnología que no es "negociable". Si lo que estamos haciendo es una aplícación de referencia de la tecnología X, y la tecnología X no funciona, estaremos en problemas. Si por razones externas, tenemos que usar la librería Y y encontramos problemas, no siempre es fácil encontrar un camino alternativo. Pongan EJB en lugar de X e Y, y verán lo que puede ser el camino del infierno... ;-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

¿Por qué fallan los proyectos de software?

lopez — Thu, 21 Aug 2008 11:37:50 GMT

Hoy, en el Microsoft Users Group de Argentina, Patricia Scalzone y Leticia Medela, de Vemn Sistemas, dictan una sesión sobre por qué fallan los proyectos:

Jornada de Soluciones

El temario es:

Escenario: ¿Por qué fallan los proyectos de software?
Solución: Entre las diferentes causas que llevan al fracaso de un proyecto de software, la tecnología no es la determinante. Esta sesión se focalizará en presentar técnicas y herramientas adecuadas para prevenir esa situación, tomando ALM (Application Lifecycle Management) como referencia.

Hay otros temas, como migrando a SOA, mejorar la calidad del software, y la implementación de un portal CMS, usando DotNetNuke.

Pero me gustaría hoy enumerar rápidamente algunas de las causas por las que fallan los proyectos de software. No será una lista original en contenido, y seguramente Uds. podrán aportar otras causas o explicar mejor alguna de las que presente. Sin poner una prioridad, veamos algunas causas:

No se tiene en claro qué hacer: los requerimientos son difusos, se toman mal, y terminamos haciendo algo que el cliente no necesitaba ni quería. No se entiende cuál es el problema a solucionar, el problema de negocio, el valor que nuestro entregable debe aportar al cliente. Se piensa más en detalles técnicos que en lo que realmente importa.

El cliente participa una vez cada seis meses: no se habla con el cliente, se trata de evitarlo. Se lo considera más un "enemigo" que parte del proyecto. Cada vez que entregamos un avance de la solución, nos damos cuenta que lo que entregamos no era lo que el cliente esperaba.

Gente no dedicada al proyecto: se lanza el proyecto, pero la gente que lo lleva adelante se dedica mientras tanto, a otros proyectos sin terminar, soporte de cliente, mesa de ayuda, a mover máquinas de un lado a otro por cualquier causa.

La gente de ventas prometió el oro y el moro: pasa en muchas consultoras. Por un tema de comisiones, o de posicionamiento en el mercado, se ofrece una solución "inflada" que no corresponde con lo que podemos hacer.

No conocer y entender la tecnología: hay que conocerla y ENTENDERLA. No sólo es saberse de memoria los namespaces de .NET, o la configuración de Spring: hay que entender para qué está cada cosa que usamos.

Usar mal la tecnología: hay quienes creen que usando J2EE y patrones todo queda solucionado: seguridad, escalibilidad, etc, sin detenerse a pensar en qué afecta la tecnología y las decisiones de diseño en lo que quieren lograr.

Cualquier problema lo arreglamos con más gente: en vez de encarar el problema de raiz. Agregar más gente a un proyecto con problemas, es como hechar querosene al fuego.

Equipo malfuncional: en el equipo hay gente que no sabe trabajar en grupo, tenemos "prima donna" que hacen lo que quieren, en vez de hacer lo que el proyecto necesita.

Cambios para mañana: viene alguien, de ventas o de gerencia, pidiendo cambios para el viernes, y estamos en la tarde del jueves.

Falta de recursos: se nos pide desarrollar el próximo Youtube + Facebook, con una máquina IBM XT de una diskettera.

Complicar la solución: para comunicar unos datos a otra aplicación, adoptamos un ESB, dos sistemas de cola de mensajería, una base de objetos, dos relacionales de última generación, y cuatro especificaciones de web services, aplicando transformaciones XSLT ante cada paso. Tal vez una simple programa hubiera dado el mismo resultado.

Falta de coordinación y cooperación: en un proyecto grande, hay varios equipos, posiblemente de distintas consultoras, resolviendo distintas partes del proyecto. Lo que un equipo hace, lo necesita otro, pero coordinan mal la entrega y prueba de las partes. Los equipos no se ven como colaboradores: cada uno hace lo suyo, y si otro equipo tiene problemas, consideran que no es problema de ellos. También pasa esto entre personas de un mismo equipo.

Uds. tendrán otros ejemplos a aportar.

Las metodologías ágiles ayudan a mitigar varios de estos problemas, o por lo menos, a ponerlos de manifiesto antes de que sea tarde. Hay problemas que van más allá de la metodología, que se tienen que resolver a nivel de la dirección de la empresa.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Agiles 2008 en Argentina

lopez — Sat, 16 Aug 2008 17:27:43 GMT

Se va acercando la primera conferencia latinoamericana de metodologías ágiles:

Primeras jornadas latinoamericanas sobre metodologías ágiles

Entre los referentes internacionales que ya han confirmado su participación en Ágiles 2008 se encuentran Mary y Tom Poppendieck, Matt Gelbwaks y Tobias Mayer.
Ágiles 2008 es un evento sin fines de lucro, el cual es organizado por entusiastas del tema y abierto a cualquiera que tenga ganas de participar.
Si tiene interés en colaborar con la organización de Ágiles 2008, lo invitamos a dejarnos sus datos de contacto aquí

Tobias Mayer es un entrenador de metodologías ágilas, que nos enseñó a muchos de nosotros, acá en Argentina. Una persona de múltiples intereses (como la actividad teatral), muy amable y con grandes habilidades de comunicación, para inspirar a la gente en el método ágil. Podemos considerarlo "el padrino" del movimiento ágil en mi país...:-)

Los organizadores están convocando a enviar "papers", ideas, y propuestas para actividades:

¡Ir a una conferencia a escuchar es demasiado aburrido! Recibimos su idea para participar activamente de Ágiles 2008. En principio tenemos pensadas tres tipos de actividades: Presentaciones (tradicionales, con transparencias, gente sentada escuchando y preguntas al final), Sesiones Interactivas (gente parada haciendo ejercicios tipo teatrales) y Mesas de Discusión (similar a un debate). Pero a no amedrentarse: escuchamos cualquier idea y tratamos de darle un lugar y un momento.
Los bloques serán de 45 minutos, pero es posible tomar más de uno para una misma actividad.
Hay tiempo hasta el 1 de septiembre para presentar una propuesta.
http://www.agiles2008.org/es/call4papers.php

Por años, las metodologías ágiles fueron ganando aceptación en mi país, Argentina, y en Latino América. Y ahora es el tiempo para mostrarlas al resto de la industria, para que vean qué es el movimiento ágil.

A hacerlo! (eso sí, antes escriban un "backlog" ... ;-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

Jornadas Agiles 2008: los Poppendieck en Buenos Aires

lopez — Sat, 16 Feb 2008 09:41:46 GMT

Se siguen preparando las Jornadas Agiles 2008. Se ha confirmado la presencia de Mary y Tom Poppendieck, que darán un curso de dos días sobre Lean Software Development.

Leemos en el sitio del evento:

Ágiles 2008, las primeras jornadas latinoamericanas sobre metodologías de desarrollo ágil, tienen como objetivo ser el principal punto de encuentro de 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 estas metodologías.
Esta primera edición, a realizarse en Buenos Aires durante el mes de octubre de 2008, contará con la presencia de especialistas locales y del exterior, quienes compartirán su conocimiento a través de charlas y mesas de debate que se llevarán a cabo durante los dos días que durará el evento. A su vez, previo a la realización de las jornadas, tendrá lugar el dictado de cursos de certificación oficial -como el Certified Scrum Master training- a definirse de acuerdo al interés de los posibles participantes.
Ágiles 2008 es un evento sin fines de lucro, el cual es organizado por entusiastas del tema y abierto a cualquiera que tenga ganas de participar.
Ágiles 2008, the first Latin-American conference about agile development methodologies, hopes to become the main meeting point for IT professionals interested in sharing experiences, discussing and learning about topics related to agile software development.
This 1st edition, to have place in Buenos Aires during October 2008, will have the collaboration of local and foreign agile specialists, who will share their knowledge through lectures, round tables, and discussions during this two-day event. Prior to the conference, special training courses will be held -such as the Certified Scrum Master training and the Lean Software Development course- which will be defined according to the assistants' interests.
Ágiles 2008 is a non-profit event, organized by agile enthusiasts and open to anyone willing to participate. If you want to be part of Ágiles 2008 organization you can post your comments and suggestions, as well as get informed about the latest news, at http://jornadasagileslatam2008.wetpaint.com/

Pueden ver más información y colaborar con sugerencias y organización, en:

http://jornadasagileslatam2008.wetpaint.com/

Ahora, para organizar mejor el evento, hay una encuesta que podemos llenar:

http://www.custominsight.com/start/?agiles2008

No lleva más de 3 minutos, y servirá para tener una mejor idea de las expectativas de los asistentes.

Los interesados en metodologías ágiles, pueden participar de la lista (en español):

http://tech.groups.yahoo.com/group/laasd/

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Una breve historia de CMMI

lopez — Sat, 02 Feb 2008 08:33:49 GMT

Cuando me inicié en el desarrollo de software, fines de los 70, comienzos de los 80, la situación de software, hardware, recursos, metodologías, formas de trabajo, eran totalmente diferentes a las de ahora. Los mainframe eran (por lo menos en Argentina) el equipo ha usar. Los sistemas eran ejecutados dentro de un centro de cómputos, todo controlado. Los usuarios finales sólo recibían el resultado de proceso, posiblemente, horas y horas de listados de impresoras de puntos, dando información que la gerencia debía digerir, tal vez una vez al mes.

Pero el resto del mundo, ya estaba cambiando. La aparición de la computación personal, y de software para esos sistemas, la adopción luego de las redes para ese tipo de máquinas, el incremento espectacular del acceso a esos recursos por los usuarios finales, y la creación de un nuevo mercado, el software de aplicaciones, cambió todo el horizonte.

Antes de ese cambio, el control y la disciplina en el procesamiento de datos se conseguía por lo que se llamó "estabilidad por limitación". No cualquiera podía programar, no cualquiera accedía a sistemas de información, no cualquiera los operaba y los usaba. Pero al cambiar el entorno, surgieron problemas en mantener la estabilidad de los sistemas. La adopción de nueva tecnología se volvió una ventaja, pero también un problema a manejar. El gobierno de EE.UU. reacciona, estableciendo el Software Engineering Institute en la universidad Carnegie Mellon. El instituto no es una iniciativa privada, sino que está soportado por los impuestos que pagan los norteamericanos. Inicialmente fue "sponsoreado" por el Departamento de Defensa (el DoD), que estaba preocupado por la calidad del software que quería adquirir y soportar (recordemos que en ese tiempo, su preocupación también dió pie a otras iniciativas, como el lenguaje ADA).

En esos momentos, había modelos de manejo de la calidad, principalmente implantados en la industria. La serie ISO 9000 comenzaba a obtener amplia adopción, los japoneses producían innovaciones como entrega Just In Time y Assembly-Line-Control. Six Sigma estaba emergiendo en lugares como Motorola y General Electric.

El SEI toma estudia esas implementaciones, y a los trabajos de americanos expertos y promotores de la calidad, como Philip Crosby, Malcolm Balbridge, George Box y Edwards Deming. Ese esfuerzo dió un primer fruto con la publicación del trabajo de Watts Humphrey en 1987: Managing the Software Process. El libro sintetizaba el pensamiento crítico en el manejo de la calidad, y aplicaba una serie de pasos prácticos, organizados en niveles de maduración. Una empresa podría entonces ir implementando en forma escalonada, esos niveles.

Ese mismo año, el SEI usa lo planteado por Humphrey como base para la primera versión del Capability Maturity Model.

Me gustaría en otros post ir viendo más en detalle qué eso de CMM, y cómo evolucionó, hasta llegar a distintos "flavors", y al CMMI-Dev, por ejemplo. Pero ahora, revisemos dos puntales del CMM.

El CMM está fundado en dos bien conocidos principios de calidad. El primero: "el proceso funciona". Es decir, que si una organización o grupo tiene que producir un resultado, sea producto de software o un auto, se logra asegurar una mejor calidad usando una serie de pasos definidos, un proceso, que usando cada vez lo que se nos ocurra.

El otro gran principio es "la organización que ejecuta es un organización que aprende" ("performing organization is a learning organization"). Ante el cambio continuo de tecnologías y ambiente de mercado, una organización exitosa debe no quedarse en el tiempo, o anquilosarse en un proceso fijo, sino que debe aprender, y aprovechar las lecciones aprendidas para mejorar justamente el proceso. La organización opera siempre en "modo de aprendizaje". La actitud "ya lo sabemos todo" no se acepta. La organización debe tener conciencia de lo que sabe, de lo que aprende, de lo que puede mejorar, y de los cambios que acontecen.

Esos dos principios, si bien venían de otros ámbitos, eran nuevos en la industria del software. El DoD creyó en esos principios, y adoptó el modelo. Luego vendrían otros "early adopters". En 5 años, más de 5000 organizaciones de IT habían adoptado el CMM como el modelo de calidad. Aparecieron varios CMM para distintas disciplinas.

Con el tiempo, se integraron varios de esos "flavors" en el CMMI (I de integrado), en 1999. En 2006, quedó establecido el CMMI-Dev para desarrollo, y el CMMI-ACQ para compras.

En los últimos años, hemos visto cómo cada vez más empresas, fuera de EEUU, y en mi país, Argentina, han ido adoptando e implementando las ideas y niveles de CMMI. Y en los contratos, cada vez más se pide al proveedor cumplir con algún nivel.

Fuente consultada: Process Improvement Essentials, CMMI, ISO 9001, Six Sigma, James R. Persse, O'Reilly. Gracias a la biblioteca de Southworks!

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/