martes, 18 de enero de 2011

Consumo de Energía

Hace unos días recibí la cuenta de electricidad del año pasado y noté un aumento de un 40% en el consumo eléctrico. Ante ello decidí utilizar un medidor de corriente para investigar qué aparato ha producido dicho aumento.

Compré un Energy Logger 3500 de la firma Voltcraft, cree una biblioteca en C# para procesar los datos almacenados en archivos binarios y programé una pequeña interfaz gráfica en WPF para visualizar los datos y exportarlos en CSV.

Así se ve el resultado:


Si necesitas un programa que convierta o visualize los datos de un Energy Logger 3500 ó 4000 de Voltcraft, envíame un mail y con gusto te ayudaré.

Con esa aplicación me ha sido fácil descubrir al malhechor y preocuparme que el próximo año, la cuenta de electricidad se vea considerablemente mejor.

domingo, 9 de enero de 2011

Kanban, Scrum, XP y la pérdida de agilidad

Existen muchos métodos ágiles para desarrollar software. Cuando uno empieza a buscar, uno se da cuenta de la variedad de métodos que existe. ¿Cuál es el mejor de todos? ¿Por qué hay tantos distintos métodos? ¿Son todos necesarios?


Como en cualquier clase de cosas y en cualquier área de la ingeniería, hay muchos caminos que nos llevan a la meta. Pero no hay un camino ideal, que sea el mejor en toda circunstancia. Lo importante es entender el significado de agilidad y preguntarse de qué manera uno se puede beneficiar de ella. También es conveniente pensar en las posibles desventajas.


Para hacer más difíciles las cosas existen unos factores en torno a la agilidad que reducen la transparencia y aumentan la dificultad de encontrar un método de desarrollo que ayude a aumentar la productividad y calidad del desarrollo de software:

  • El concepto de agilidad no es ni debe ser un dogma: se trata de utilizar la creatividad y la información para adaptarse y encontrar el mejor camino hacia la meta. Hay quienes dicen que sólo se puede hacer software de forma iterativa o que los equipos que no se reúnen día a día (y de pié) no son equipos de verdad. Hacer de algo un dogma es perder capacidad de reaccionar al cambio o sea perder agilidad.
  • Cuando métodos se convierten en sectas: cada método tiene hoy en día su guru y miles de ciegos seguidores. Eso es peligrosísimo, pues lo que en verdad se requiere son ojos abiertos y capacidad de adaptarse. El concepto de seguir ciegamente un plan (o un gurú?) es justamente lo que queremos evitar, ¿no? Hay quienes dicen que hay sólo UN camino correcto, que SCRUM es la verdad o KANBAN es la solución a todos los problemas. El problema no es SCRUM ni KANBAN sino que los ignorantes que predican agilidad sin ser de verdad ágiles.
  • Expertos, expertos y más expertos: hay tantísimos expertos en el área del desarrollo ágil, muchos de ellos no hicieron más que decir una frase correcta en el momento correcto y hoy son venerados hoy como gurús. Varios se han hecho un dineral en libros, cursos y congresos, donde predican acerca de algo que hace más de diez años ya no practican.

Mi recomendación es elegir el método que se usa a partir de los requrimientos y problemas existentes y no a base de lo que otros dicen. Es bueno leer y aprender de la experiencia de otros, pero hay que tener cuidado de distinguir entre el trigo y la paja.

sábado, 8 de enero de 2011

Desarrollo de software en cascada

En un mundo lleno de cambios, en el cual producir con rapidez aplicaciones que satisfagan las necesidades reales del mercado es clave para el éxito, es indispensable pensar y repensar la forma y las herramientas que los equipos que desarrollan software utilizan para trabajar.

Durante muchos años, lo normal era desarrollar software en lo que llamamos "desarrollo en cascada" (waterfall model), que divide el proceso en bloques definidos y donde cada paso depende sólo del paso anterior:
  • Análisis de requisitos
  • Diseño del Sistema
  • Diseño del Programa
  • Codificación / Implementación
  • Pruebas
  • Implantación
  • Mantenimiento
Con los años se han establecido nuevas técnicas que en la mayoría de los casos reducen en cierto grado los problemas producidos por ésta metodología y aumentan la probabilidad de éxito de los proyectos de desarrollo de software. Durante muchos años he tenido que desarrollar software utilizando éste método y ésta es la lista de lo que a mí parecer son sus principales problemas:

  • Malas decisiones, poco uso del aprendizaje: El método obliga a tomar muchas y muy importantes decisiones muy temprano en el proyecto. Las decisiones se toman en el peor momento, cuando menos se sabe del tema y de las tecnologías utilizadas. El costo de cambiar el rumbo tomado es muy alto, pues la información fluye sólo en una dirección (de arriba hacia abajo). Frecuentemente ocurre que cerca del final del proyecto todos los participantes han logrado recién alcanzar un grado suficiente de profundidad en su conocimiento del tema y sus tecnologías como para poder tomar decisiones correctas. Lamentablemente, en ese momento ese conocimiento ya no es requerido.
  • Mala comunicación: El camino de la información es desde arriba hacia abajo (ver lista más arriba). La forma consiste en general en interminables documentos que nadie es capaz de leer ni entender.  La pérdida de información es considerable. Quien describe los requerimientos del sistema no dialoga con quien lo implementa y el testeo ocurre sin conocer al cliente. No es que siempre deba ser así, pero en la mayoría de los casos así ocurre y es difícil revertir esa tendencia.
  • Falta de flexibilidad: Debido a que mucho se define con muchos detalles en un inicio, es muy difícil cambiar la dirección y reaccionar al cambio. En nuestro mundo en el que nuevas tecnologías aparecen a diario y en mercados donde la competencia no duerme es necesario poder reaccionar. Por muy elaborado que sea el plan, si las reglas del juego cambian, habrá que rehacerlo y eso es caro!
  • Responsabilidad diluida: La responsabilidad por un producto no se comparte si cada parte involucrada es únicamente responsable por su trabajo. Los proyectos exitosos no sólo requieren excelentes profesionales que dominen sus áreas, sino que además un equipo en el cual todos trabajan juntos tras un objetivo común.  Si cada quién es responsable sólo por su parte del proceso y no por el resultado común, es difícil producir un buen producto.
La industria del software ha reaccionado a éste fenómeno con movimientos como el desarrollo ágil, que ayudan a subsanar estos problemas. Estoy seguro que el desarrollo en cascada puede ser la solución para uno que otro proyecto de software, pero para la gran mayoría hay alternativas mejores y mi recomendación para todo aquel que gane su vida en la industria del software es que gaste algunos minutos leyendo y pensando acerca de metodologías modernas como por ejemplo Scrum, XP, Kanban, Lean y Feature Driven.

Transición hacia desarrollo ágil de software

El desarrollo ágil de software existe ya hace varios años, pero se ha comenzado a masificar sólo dentro de los últimos años. Ya que el proceso de migrar desde un método "tradicional" a uno ágil es bastante similar en cada empresa y equipo, vale la pena aprender de otros que han vivido el cambio.

Les recomiendo ver este interesante webcast (en inglés) titulado "Agile transformation of a Microsoft product team", en el cual Cameron Skinner (MS) relata lo que él ha aprendido durante ese proceso.

Desarrollo Ágil: ¡Terminado no es lo mismo que terminado!

¿Cuándo se puede decir que se ha terminado o finalizado de implementar algo en nuestro mundo del desarrollo de software? ¿Basta con haber terminado de escribir código? ¿Hay que haber actualizado el código en el sistema de control de versiones (Subversion, TFS, ClearCase, GIT, ...)? ¿Es necesario haber testeado la aplicación? Y de ser así, ¿de qué manera y hasta qué punto? ¿Y qué hay con la documentación?

Ya antes había escrito de lo importante que es en el desarrollo de software (y más aún en el desarrollo ágil o iterativo) la transparencia.  Sin transparencia, o sea sin información, no es posible tomar las decisiones correctas, para dirigir un proyecto -iteración tras iteración- hacia la meta.

Si queremos ser transparentes debemos dejar claro en la comunicación con todas las partes durante el desarrollo de software acerca de lo que queremos decir cuando hablamos de haber terminado algo. La meta es terminar en cada iteración el desarrollo de una cantidad variable de funcionalidad. Al final de cada iteración podemos decir cuanta funcionalidad (user stories, use cases, ...) hemos completado.

La definición ha de ser en mi experiencia lo más estricta posible. La implementación de una funcionalidad sólo se puede llamar completa cuando se esté seguro que la aplicación cumple con todos los requisitos para que pueda llegar a las manos del cliente. Es muy fácil caer en la trampa de dejar abiertos algunos "detalles" que deberán ser terminados "más adelante". La suma de esos "detalles" terminan siempre reduciendo la transparencia produciendo atrasos y aumentos en los costos del desarrollo de software.

Sin duda que cada equipo, su experiencia y su entorno definen el estándar requerido al momento de liberar un software para su uso.  Dicho estándar debe ser definido explícitamente y el nivel de calidad requerido al fin de cada iteración no ha de diferir mucho de aquel que requiere el producto final. ¡Mientras mayor sea la discrepancia, mayor es la probabilidad que se oculte alguna deuda que ha de ser pagada antes que el producto caiga a las manos de sus usuarios!

domingo, 2 de enero de 2011

¿Qué largo debe tener una iteración?

Antiguamente, cuando se hablaba de desarrollo de software, se decía que había que analizar el problema a resolver, hacer un diseño, programar y controlar la calidad.  En ese órden y con una mínima interacción entre las distintas etapas más que una pila de documentos. Esta forma de desarrollar software se conoce como "waterfall".

Hoy en día está de moda el desarrollo ágil - y con mucha razón! Las pilas de documentos nadie las leyó y con el tiempo vimos cómo fallaba proyecto tras proyecto en el mundo de la informática, porque quienes desarrollaban el software no sabían qué era lo que quería el cliente y no eran capaces de estimar cuánto demoraría el proyecto. Finalmente se producía un software cuando ya nadie lo necesitaba y que no satisfacía los requerimientos del usuario.

Uno de los principios de la "agilidad" es el desarrollo iterativo. La idea es que al inicio no hay que definir más que la dirección y durante la ruta se va comprobando frecuentemente la posición para corregir la dirección. De esta manera, los proyectos no sólo se tornan más predecibles, sino que además se benefician de la curva de aprendizaje. Es así que el desarrollo de software es dividido en bloques de tiempo.  Tras cada bloque de tiempo (iteración) se debe producir una versión del producto que esté en un estado que permita ser utilizada potencialmente por el cliente.

Acerca del largo de la iteración se han escrito muchos libros y todos los gurús de la industria han expuesto sus tésis. Cuando convertimos nuestro proceso en uno iterativo, no tenía bien claro qué largo tenía que tener una iteración. Hoy he visto ya muchas iteraciones y me gustaría recomendar algunos parámetros para facilitar la decisón:
  • Las iteraciones deben ser cortas. Mientras más cortas mejor!
  • Las iteraciones largas son malas, porque la presión externa por modificar el contenido de las iteraciones crece a tal punto que es difícil evitarlo. Es más fácil protejer al equipo y al plan de la iteración por periodos más cortos.
  • Las iteraciones tienen ciertos costos fijos, en cada empresa y equipo son distintos.  Es importante mantener bajos estos costos fijos, sólo así se pueden acortar las iteraciones.
  • No existe un número mágico que sirva para todas las situaciones.  Mi recomendación es empezar con un número de semanas en que se puedan implementar pequeñas funciones e ir evaluando en el camino si la decisión fue correcta. El objetivo debe ser siempre buscar caminos para acortar las iteraciones.  Iteraciones largas (más de 3 semanas) son en general un síntoma que el equipo o la organización no ha comprendido el significado del desarrollo iterativo de software.
Si en tú empresa utilizas desarrollo de software iterativo, qué tamaño tienen las iteraciones?