Category Archives: Noticias

Noticias sobre el sitio

La duplicación en Ruby

16 abril 2010

Durante el día de hoy, hemos estado dando vueltas, tanto Daniel como yo, para ver si encontrábamos alguna forma de solucionar este problema que se nos había cruzado:

irb> a = [[1,2,3], [1,2,3]]
[[1,2,3], [1,2,3]]
irb> a = b
[[1,2,3], [1,2,3]]
irb> b[0][0] = 0
0
irb> b
[[0,2,3], [1,2,3]]
irb> a
[[0,2,3], [1,2,3]]

Con este código se entiende que al igualar dos objetos, en Ruby, no se hace una copia del objeto, sino una referencia al mismo.

Si intentamos hacer algo como:

irb> b = a.clone
irb> c = a.dup

Nos encontramos, al realizar la prueba de modificación sobre b y c el mismo resultado. Esto es porque los comandos de duplicación de objetos (y clonación) no trabajan con recursividad, sino que hacen solo la duplicidad de los objetos inmediatos, por tanto, si se trata de un Array, se duplica como nuevo objeto el Array, pero cada elemento dentro del Array, si es a su vez otro Array o Hash, los elementos que este puede contener se dejan sin duplicar (o clonar).

Esto está así pensado para que cada cual agregue sus propias funciones de clonación (en caso de clone)… solo que en ese caso, para los objetos de tipo Array y Hash se les olvidó hacerlo, claro.

Solución cutre

Buscando un poco por internet, en varios foros se puede encontrar esta solución, la cual es algo chapuza en muchos aspectos:

irb> b = Marshal.load(Marshal.dump(a))
[[1,2,3], [1,2,3]]

Esto lo que hace es realizar una serialización de los objetos y después una deserialización. Funciona, pero no con todos los tipos de objetos, hay que tener especial cuidado con esto.

Solución algo más elegante

Lo ideal sería sobrecargar la función de clone para los objetos de Array y Hash, ya que se ve que se les olvidó hacerlo a los programadores o, realmente, no se preocuparon de hacer esa tarea en profundidad, es decir, a través de todos los objetos.

class Array
  def clone
    a = Array.new
    for i in 0..(size - 1) do
      if self[i].respond_to? :clone
        a[i] = self[i].clone
      else
        a[i] = self[i]
      end
    end
    a
  end
end

Si se ejecuta con el ejemplo, se verá que se suceden algunos errores. Esto es debido a que los objetos como Fixnum, tienen implementado el objeto clone, pero como un error, ya que lógicamente se considera que el objeto Fixnum no se puede clonar.

Esto se puede resolver de dos formas. Agregar tantas excepciones como se encuentren en la función clone escrita antes, o escribir algo como esto:

class Fixnum
    def clone
      self
    end
end

Conclusión

Cada lenguaje tiene ciertas características o lagunas que, cuando se choca con ellas, se convierten en verdaderos escollos en el camino. No obstante, siempre se puede salir de ellos de alguna forma, aunque haya que poner momentáneamente FIXME en los comentarios de nuestro código a fin de revisarlo cuando se tenga una solución algo mejor.

0 Comments

Haciendo buen software

7 abril 2010

Hoy he reparado en una web (que he agregado a mis enlaces) que trata sobre temas de la programación y, en definitiva, se centra en hacer buen software.

Es algo complejo determinar qué es buen software y qué no lo es, por lo que estos siete consejos pueden ayudar a detectar lo que se puede considerar buen software y lo que no. En definitiva y después de muchos años desarrollando, así como leyendo a gente que al igual que yo lleva también muchos años en esto, la clave para hacer buen software es programar lo único necesario para cumplir el objetivo marcado, ni una línea más. Y como dice Alberto: no hay problemas difíciles, solo soluciones difíciles.

  • Fácil de leer: Si el código es fácil de leer, fácil de interpretar, será fácil de mantener: modificar y ampliar. También necesitará menos comentarios y menos documentación, ya que se entiende de por sí.
  • Fácil de usar: Debe de ser intuitivo. Si el código no es intuitivo, es decir, hace algo de una forma que no es la que se espera, puede conducir a situaciones en las que el mantenimiento sea un infierno.
  • Fácil de cambiar: No debe de haber lógica duplicada. Cualquier cambio debe de poder realizarse solo en un sitio.
  • No uses herramientas, librerías o código de terceros, sino es necesario: Cada vez que se usa un framework, librería o código externo para hacer algo de una forma más fascinante, agregamos complejidad extra al proyecto. Esto es algo peligroso que puede hacer que de repente nuestro código no sea fácil de cambiar o ni siquiera de leer.
  • Que parezca simple: Si un código no parece simple, es que no es simple. Si un código parece simple cuando se termina de escribir, viendo su simpleza y pensando incluso que se podía haber escrito en menos tiempo, es que el trabajo se ha hecho bien.
  • Lean: Tener en cuenta los principios del lean software development puede ayudar a realizar un código más simple, fácil y bueno. Se basa también en el principio YAGNI (you ain’t gonna need it?, ¿realmente lo necesitas?): no desarrollar nada que no haga falta.
  • Que sea directo: Esto significa, básicamente, no perderse en capas de abstracción, disparadores y otro código que queda oculto y difícil de trazar. El código tiene que ser directo, fácil de trazar y de seguir, previsible y evidente.

En sí, es sentido común el pensar que, lo que no está hecho no cuesta nada cambiarlo, por ello, sino se desarrolla algo a futuro, pensando en que pueda requerirse, cuando se requiera de otra forma, no habrá nada que cambiar, porque no se habrá hecho nada.

Por otro lado, tomarse el tiempo necesario para no hacer chapuzas, sino modificar lo que haya que modificar y cómo haya que modificarlo, es totalmente necesario y aconsejable para que el código siga siendo bueno.

1 comentario

¿Qué se busca conseguir en un desarrollo?

14 enero 2010

La respuesta rápida y obvia podría ser: que lo desarrollado cumpla con los requisitos pactados.

La realidad, muchas veces, nos demuestra que esto no su cumple, ya que, o los requisitos pactados se engordan, o nos fijamos más en que se cumpla el tiempo pactado, lo cual realmente no es un requisito, en muchos casos. Al final, parece que premia más el tiempo invertido y el dinero gastado que lo que se ha adquirido.

Imagina que vas a comprar unos pantalones, quieres unos pantalones para diario, simples, pero dado que es invierno, que te los puedas pasar sin pasar frío. Ese es nuestro valor a conseguir. Si vamos a comprar los pantalones y hablando con el encargado los pedimos: que sean azules oscuros, con un diseño radical, moderno, de mi talla, … ; quizás al final tengamos unos pantalones que sean como unas mayas… ¡a ver quién se las pone en invierno!, pero claro, por el dinero que dábamos, lo que pedíamos, y el tiempo que le dábamos al encargado para que los buscase… pues es normal.

En desarrollo de software pasa igual. Al principio, el cliente tiene la idea de un software, por ejemlo, para gestionar su almacen. Después piensa que, si se va a invertir mucho tiempo en su desarrollo, entonces puede pedir que venga con sistema de nóminas, contabilidad, gestión de pedidos a mayorista y generación de facturas a clientes… y por el camino, mientras ve algunos proyectos de portfolio, pues se le ocurre pedir también un sistema de carro de compra para internet… y todo eso en el tiempo que se tiene para hacer solo la primera idea… ¿saldría bien?… ¡no!

Volviendo a la pregunta inicial, la respuesta después del planteamiento desarrollado, sería, más concretamente: busco que resuelvan un problema específico que tiene mi empresa, el cual no le permite crecer al ritmo que queremos que crezca.

Por ello, el desarrollo de una aplicación de software debe realizarse siempre con la idea clara en mente de que, el desarrollo, va a cubrir una necesidad detectada, o a automatizar una tarea, que ya se realiza, pero se necesita realizar de forma automática para que los trabajadores puedan realizar más tareas a lo largo de un día. Si el software desarrollado no cumple esta espectativa, no solo no aporta valor, sino que es posiblemente un lastre para la empresa.

0 Comments

Los sectores del software

7 enero 2010

De siempre, se va viendo que las empresas de software se decantan por una forma de hacer las cosas, mientras que otras eligen otro camino distinto y, muy pocas, mezclan elementos de doctrinas tan establecidas y dogmáticas como son: el mundo del software libre, el mundo java o el mundo .net.

El mundo .NET

Como todo lo que tiene que ver con Microsoft, el mundo .NET se mueve, casi exclusivamente, con productos y herramientas desarrolladas por esta misma compañía. Funciona sobre Windows, con base de datos de Microsoft y se diseña con herramientas de Microsoft.

Lo bueno de Microsoft es que desarrollan los productos para un público general y sin conocimientos extensos. Los lenguajes suelen ser o muy fáciles (Visual Basic) o muy complejos (C++, C#), pero cumplen con todas las necesidades de los programadores a los que van dirigidas las herramientas. Así mismo, tienen un alto nivel de operatibilidad entre los diferentes productos, es decir, escribir código ASP con SQL Server es simple, gracias a ese nivel de compactación y simplificación.

Lo bueno de la simplificación lleva a lo malo de la complejidad también. Un programa que se hace de forma simple y fácil, siguiendo los pasos que Microsoft ha pensado para dar es simple, sencillo y rápido. Pero cuando la aplicación debe tener una forma específica o salirse un poco del camino típico, comienzan a surgir problemas solo saldables con código complejo.

Ximian, absorbida por Novell, ha realizado muchas aproximaciones a este mundo para portarlo al mundo del software libre a través de su escritorio Gnome y su proyecto Mono. No obstante, es un tema un poco espinoso, ya que quien usa software libre, por lo general, se aleja de las tecnologías propuestas por esta gran multinacional, por lo que, aunque es usada y tiene su cuota de mercado, Mono no llega a ser usado tanto como podría esperarse.

El mundo Java

El mundo de Java ha estado siempre en una lucha constante y abriéndose camino en el desarrollo de software, sin mucho éxito al principio, sobre todo en lo que respecta a las aplicaciones de escritorio. Esto fue debido a su naturaleza de pseudo-compilación y pseudo-interpretación, ya que es un lenguaje compilado e interpretado que se ejecuta sobre una máquina virtual, y las labores de interpretación de los bytecodes son algo costosos, en relación a código que se ejecuta de forma nativa.

No obstante, en la parte web, de interfaces, desde que comenzó, ha tenido una gran aceptación, puesto que permite el desarrollo de las aplicaciones en cualquier infraestructura (windows, linux, solaris, …) y se han desarrollado grandes herramientas para el desarrollo en este sentido.

Java siempre es el favorito y preferido de las consultoras (a menos en España), donde es empleado para el desarrollo de aplicaciones, tanto de escritorio como web en todos los sectores donde son contratados.

La mayoría de empresas que han tenido relación con Microsoft y han salido de malas con la grande, han terminado montándose al carro de Java y aportando a esta comunidad en modo de open source herramientas, conocimiento, etc. Además de Sun Microsystems (su fundadora), hay otras como IBM, RedHat, Oracle, etc. que se han sumado al carro de Java para el desarrollo y ampliación de esta comunidad.

Hay comunidades de software libre que se han sumado a la aportación de código para el mundo Java. Esto supongo que será erróneamente aportado como el voto útil, sin saber que en nada se beneficia al software libre en sí, sino solo al mundo Java que, aunque pueda parecer atractiva la idea de luchar contra el tirano, no es más que ayudar a una empresa a derrocar a otra. Esto puede ser muy discutible, sobre todo por los defensores de Java :-D

El mundo del software libre

Al margen de la guerra entre .Net y Java, surgen los entornos, sistemas y elementos de software libre. Pensar que todo el mundo tiene que ser Java o .Net es un craso error, ya que hay muchos elementos que se pueden combinar a gusto propio del desarrollador y emplearlos como mejor convenga para obtener los mejores resultados para una tarea concreta.

A este respecto, una de las comunidades con más auge es la de desarrolladores de PHP, por ejemplo, que es el lenguaje que más proyectos de software libre tiene desarrollados, y es el más usado para el desarrollo de sitios como Facebook, Menéame, WordPress, etc.

Otra de las comunidades más activa en los entornos web es la de Ruby, Ruby on Rails más específicamente, que tiene un entorno fácil y profesional para el desarrollo rápido de sitios web. También Python, con su framework Django. Ambos presentes en el mundo Java a través de JRuby y Jython, respectivamente.

Entornos también desarrollados en lenguajes más específicos como Perl, Erlang, Tcl, etc. hacen que se complete el abanico de posibilidades para el desarrollo de software a través de las soluciones que aporta el software libre.

La nota negativa, es que los elementos no son altamente cooperativos, es decir, aunque se basan en estándares, normas y todos son abiertos, hay que realizar desarrollos para poder tener funcionando cosas entre unos y otros, debido a que en el software libre, no todo está hecho o viene dado fácilmente. Pero la nota positiva sobre esto, es que la dificultad que eso entraña es mucho menor que la que entrañaría el desarrollar algo no hecho o no pensado para hacerse, en Java o .Net.

Conclusión

En principio, no te quedes solo con uno, esto no son tres equipos a los que haya que apoyar a muerte, estas son tres formas de ver la tecnología y puede convenir cualquiera de las tres según el contexto en el que haya que ponerse.

Por ejemplo, en una empresa que se haya invertido en infraestructura y software Microsoft, se tenga todo montado en SQL Server, con ASP e interfaces desarrolladas en Visual Basic, desarrollar cualquier nueva ampliación o una nueva herramienta, cabe pensar que será siempre más fácil si nos ceñimos a lo ya establecido que si comenzamos a cambiar lo que hay.

Igualmente, en otra empresa en la que se haya realizado una inversión para Java, incluso con servidores Solaris, y bases de datos Oracle, no conviene pensar en desarrollar nada con Visual Basic, ni PHP, sino pensar en agregar más aplicaciones de tipo J2EE, que será lo más fácil de implementar.

Por último, en una empresa pequeña, con aspiraciones a crecer, que tengan todo desarrollado en PHP y MySQL, se podría cambiar a un framework de desarrollo para PHP, así como agregar elementos más complejos en caso de ser necesarios (como memcached).

En definitiva, no intentar cambiar lo que ya hay si funciona. Otro caso es que no funcione o que haya que realizar adaptaciones y se pueda aprovechar para agregar elementos más generales o estándares.

0 Comments

La Técnica Pomodoro

14 septiembre 2009

pomodoroLa técnica de pomodoro al igual que GTD (getting things done) o ZTD (zend to done), son técnicas para realizar las tareas diarias de forma ordenada y evitando distracciones.

Esta técnica debe su nombre a un reloj de cocina con forma de tomate (pomodoro), ya que, la propia técnica se basa en la medición del tiempo con un cronómetro, como los utilizados en la cocina.

La lista de tareas

Básicamente, hay tres artecfactos que se emplean para poder realizar esta técnica:

  • Inventario de Actividades: donde habrá que recoger todas las tareas a realizar.
  • Tareas para Hoy: las tareas que se han planteado para hacer hoy. El criterio para su selección puede ser la prioridad, dificultad o antigüedad.
  • Registro: donde, diariamente se apuntarán las tareas realizadas, junto con los pomodoros empleados para su compleción.

La gestión del tiempo

La técnica en sí, se basa en la gestión del tiempo mediante cortos periódos de dedicación exclusiva. Esto quiere decir que, cuando se comienza un periódo, se debe de estar completamente dedicado a esa actividad hasta que suene la campana.

Para desarrollar la técnica con precisión, necesitaremos un cronómetro o un sistema que nos alerte de cuando comienza y termina un pomodoro. Como su origen indica, puede ser un cronómetro fijo y real en la mesa del trabajador (lo cual puede ser algo incómodo en una oficina con muchas personas trabajando) o uno informático como este.

Los pomodoros (entendidos como los periódos de tiempo) deben de ser de no más de 30 minutos, con lo que, lo ideal, sería tener períodos de 25 minutos, con 5 minutos de descanso y, cada 4 períodos, hacer el descanso extensible de 15 a 30 minutos.

Cada tarea puede ocupar no solo un pomodoro, sino varios, esto se registra al final en el registro, poniendo las tareas realizadas, junto con el número de pomodoros invertidos en su realización.

Las interrupciones

Cuando se está trabajando en una tarea concreta y entra otra distinta con mucha prioridad, tanto que no puede esperar al final del pomodoro actual, se anula el pomodoro en curso y se comienza otro nuevo con la nueva tarea.

Este es el punto débil, quizás, de esta técnica, ya que si la dinámica de trabajo es hacerlo con incidencias y/o peticiones, podría producirse un momento en el que ningún pomodoro pudiese completarse en ninguna tarea, con lo que, llegamos al punto de que no se usa, realmente, esta técnica.

Conclusiones

Para las tareas de desarrollo y sobre todo en proyectos, sin incidencias, esta es una gran técnica equiparable a GTD y ZTD. No obstante, si el entorno de trabajo es más orientado a eventos, a interrupciones, esta técnica no aplica, puesto que las propias interrupciones son las que van marcando los tiempos a poder aplicar.

Para saber más:

2 comentarios

Entrenador (Coach) de Desarrollo de Software

12 septiembre 2009

El término de entrenador (coach) de desarrollo de software es un papel que suele ser muy importante en el quehacer diario de una empresa que tiene desarrollos de software, ya sean internos o para clientes externos.

¿Qué hace el entrenador (coach)?

Los cometidos del entrenador son dos, que pueden parecer contrapuestos, pero que se pueden combinar para conseguir lo mejor de cada una de ellas, según el momento en que se necesiten emplear:

  • El mentor, de las tareas propias de desarrollo, indicando e incluso enseñando con el ejemplo, el cómo se hacen las tareas. De este tipo, aunque no se suelen dedicar exclusivamente a esto, hay algunos en las empresas de software actuales.
  • El entrenador, propiamente dicho, se encarga de trazar la estrategia y encauzar a los jugadores dentro de la misma a hacer lo que mejor saben hacer para conseguir los mejores resultados. Realmente, cualquier jefe o mando intermedio se encarga de estas tareas mediante órdenes. El trazado del plan estratégico a seguir, el plan de proyecto, es algo que pocos jefes o mandos intermedios hacen.

La faceta del mentor

La labor de enseñanza es algo intrínseco al mundo de la informática, ya que todo avanza tan rápido, que es necesario ponerse cada poco tiempo al día de las nuevas tecnologías, y sobre todo, las que nos ayuden a mejorar el ritmo de desarrollo de nuestras labores cotidianas.

Por tanto, para hacer la labor de enseñanza, el perfil de coach debería de ser técnico, ya que, además, en el mundo en que vivimos, decir a un subordinado, ya estresado por el trabajo, que aprenda solo una tecnología y la aplique a un proyecto, puede ser el detonante principal de quedarse, poco a poco, sin equipo.

Por otro lado, si la formación es impuesta por el coach mediante ejemplos en el propio proyecto de desarrollo, ya sea por él mismo o por gente subcontratada que dé el primer paso (en caso de que el coach no tenga un perfil técnico). Como se suele decir predicar con el ejemplo.

La faceta del entrenador

Como es normal, un gestor de proyectos, es necesario e imprescindible que gestione de la mejor forma posible los recursos humanos y los proyectos que hay que realizar, dados por prioridades, para que cada uno de ellos se consiga terminar en el menor tiempo posible.

El gestor de proyectos debe de facilitar, al igual que el perfil de Scrum Master con su equipo, todo lo necesario para que su equipo pueda realizar sus proyectos.

Conclusiones

El coach es el perfil que estaría, en Scrum, jerárquicamente, por encima del Scrum Master y que ayudaría a los equipos a su gestión y promoción para su mejora.

Se encarga de la recepción de los proyectos, la valoración con los equipos o equipo específico, y su apilación en la lista de proyectos a realizar. Esta es, quizás su faceta más importante.

No obstante, la labor de enseñanza, hacer de mentor o facilitar mentores para sus equipos, no es nada desdeñable y debe de considerarse también como un punto importante en las tareas a desempeñar de este rol.

0 Comments

Kanban: el método Toyota aplicado al software

22 junio 2009

Después de haber aplicado un alto porcentaje de Scrum en los proyectos de software en los que trabajo, siento curiosidad por todas las demás metodologías ágiles que existen, sobre todo, para saber si hay alguna práctica que pueda emplear que me permita optimizar algún aspecto de la actividad diaria a desarrollar.

En este aspecto, he descubierto en Kanban un interesante aliado para aspectos de la metodología que quedaban algo descolgados, y son los procesos rutinarios, o solo tener presente la continuidad de las tareas, ya que las tareas que se realizan en Kanban pueden aparecer en el backlog en cualquier momento e ir haciéndose, según su importancia y/o prioridad.

¿Qué es Kanban?

La palabra kanban (en kanji 看板, en katakana カンバン) parte de las palabras kan (看 o カン) que significa visual y ban (板 o バン), que significa tarjeta o tablero. La idea surge en el seno de la metodología de Lean, la cual fue desarrollada por Toyota, para mejorar la producción, basándose en técnicas como just-in-time (JIT).

Los principios que se promueven son:
 

  • Calidad perfecta a la primera. Todo lo que se hace, debe de intentar hacerse bien, no rápido, ya que cuesta más tiempo hacer algo rápido y tener que arreglarlo después, que hacerlo bien desde el principio.
  • Minimización del despilfarro. Hacer lo justo y necesario (y hacerlo bien, como se decía antes) y no entretenerse en otras tareas secundarias o no necesarias (principio YAGNI).
  • Mejora continua. Ir mejorando continuamente los desarrollos, según los objetivos a lograr y alcanzar.
  • Flexibilidad. Lo siguiente a realizar se decide del backlog pendiente, con lo que las tareas entrantes se pueden priorizar y condicionar según las necesidades puntuales.
  • Construcción y mantenimiento de una relación a largo plazo con los proveedores.

 
En el desarrollo del software, el sistema kanban se puede resumir como la visualización de las tareas mediante un tablero, en el que se van moviendo entre los sectores delimitados, con el objetivo de tener siempre presente el trabajo a realizar y lo que hace cada uno. Que nadie se quede sin trabajo y que todas las tareas importantes se realicen primero.

foto-kanban

El tablero visual

El tablero de kanban, el cual debe estar visible a todo el equipo de trabajo, tiene la peculiaridad de ser un tablero continuo. Esto quiere decir que, no se rellena con tarjetas y se van desplazando hasta que toda la actividad ha quedado realizada (como pasa en Scrum), sino que a medida que se avanza, las nuevas tareas (mejoras, fallos o tareas del proyecto) se van acumulando en la sección inicial, en las reuniones periódicas con el dueño de producto (o el cliente) se priorizan las más importantes, y se encolan en las siguientes zonas.

Además, las secciones que se pueden incluir en el tablero, además de diseño, desarrollo y pruebas, son las de paso a producción, con lo que, se tendrían todas las tareas en un seguimiento exhaustivo, desde que se piensan que deben de hacerse, hasta el punto en que se ha llevado a producción.

project-kanban

Como se puede ver en la figura, cada sección vertical, puede anidarse en conjuntos, de modo que la tarea de desarrollo, por ejemplo, pueda descomponerse en otras más significativas como: en cola y en desarrollo.

Los grandes grupos verticales, pueden pertenecer incluso a grupos de desarrollo diferentes, por ejemplo, un grupo de desarrollo puede encargarse del desarrollo, y otro de las pruebas y subida a producción, o incluso entre departamentos, tomando un último grupo para puesta en producción o incluso un primer grupo para la toma de propuestas y priorización de tareas.

Lo más corriente es que exista un grupo inicial, el dueño del producto, que se encargue de organizar las propuestas o entradas, y sea el propio cliente o incluso, si es para desarrollos internos, los departamentos de comercial y/o marketing. Depende de la empresa.

Las tarjetas

La importancia de la identificación rápida de tarjetas, en un tablero de amplias dimensiones es vital para ahorrar tiempo, con lo que, se pueden asignar colores, como pueden ser: verde para las mejoras, amarillo para las tareas del proyecto y rojo para los errores.

Además de esto, las tarjetas de kanban suelen tener bastante más información, ya que el método consiste en tener todo visual, para saber de forma rápida la carga total de trabajo, ya sea de los grupos, como del departamento, etc.

Se suelen emplear tarjetitas con fotos o caricaturas que se ponen junto con la tarea que está desempeñando en cada momento cada persona, así como emplear post-it sobre las propias tarjetas para indicar observaciones sobre la tarea, o bloqueos que se puedan sueceder, es decir, que la tarea no se pueda realizar porque depende de algún factor no resuelto aún.

tarjetas

Es importante reseñar que las tarjetas debe de tener la estimación de tiempo que tiene asignada la tarea, así como se pueden anotar las fechas de entrada en cada cuadrante, para tener información, al término de la tarea, de si ha sido una buena estimación, así como obtener el rendimiento del equipo de trabajo.

Control del Flujo

El sistema kanban, a diferencia de scrum, no se dedica a llevar la pista de un solo proyecto, sino que se pueden entremezclar tareas y proyectos. El método se basa en tener a los trabajadores con un flujo de trabajo constante, las tareas más importantes en cola para ser realizadas y un seguimiento pasivo, a modo de no tener que interrumpir al trabajador para saber qué hace en cada momento.

Por otro lado, se puede seguir la pista del trabajo realizado por el grupo de trabajo almacenando los datos que las tarjetas nos proporcionan, una vez llegan a el sector final (cuando ya están en producción), con una gráfica de este estilo:

cfd

En el gráfico de áreas apiladas, se ve claramente el tiempo dedicado a cada sector. En el caso expuesto, por ejemplo, se ve que las tareas pasan más tiempo en backlog (el sector de propuestas o esperando a comenzar su desarrollo) que en la zona de desarrollo, propiamente dicha.

Conclusiones

El sistema de kanban tiene ciertas ventajas con relación a otras metodologías que ya había visto, ya que permite no solo llevar el seguimiento de un proyecto de forma individual, sino también de las incidencias que se van sucediendo, así cómo otros proyectos paralelos que tenga que hacer el mismo equipo de desarrollo, por lo que, nos damos cuenta de que, de lo que se lleva la pista en sí, no es de los proyectos, sino de los equipos de trabajo.

Lo veo indicado, sobre todo en sitios donde las operaciones (incidencias, tareas repetitivas y aisladas) son más comunes que el desarrollo puro y duro de proyectos, es decir, en entornos que necesiten de flexibilidad en la entrada de tareas, así como un seguimiento de las mismas, un sistema de priorización, control de un equipo de trabajo e informes de dedicación.

3 comentarios

CASE: escribiendo código más fácilmente

27 marzo 2009

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería del Software Asistida por Ordenador), son herramientas diseñadas para dar soporte al programador a través de una interfaz intuitiva y gráfica que le permita, mediante el posicionamiento de objetos gráficos concretos, relacionados entre sí siguiendo una nomenclatura específica, desarrollar la base de un programa automáticamente.

La programación siempre ha estado respaldada por el diseño de gráficos que, de un solo vistazo, den una imagen gráfica de lo que hace un programa, como se estructuran los datos que maneja, o cómo se organiza el código que se está escribiendo. Esto se hace mediante diagramas como los de flujo de datos, organigramas, entidad/relación, jackson, OMT y UML, entre otros.

Actualmente, no hay proyecto de grandes dimensiones que no se desarrolle usando metodologías que no estén respaldadas por diagramas como los de UML. La mayoría de proyectos que se subcontratan actualmente, por consultoras, se desarrollan, principalmente, en Java.

Esto es debido a varios factores, el principal, es que los sistemas heterogéneos a los que se enfrentan los consultores, les hacen decantarse por entornos multiplataforma, como Java, para facilitar su tarea, otro motivo es que Java ha crecido de forma considerable y tiene multitud de herramientas para el desarrollo de aplicaciones de negocio.

A día de hoy, por tanto, la mayoría de herramientas CASE se basan en el uso de diagramas UML que permitan especificar una organización del código, un comportamiento, con definición de casos de uso y secuencias, para después autogenerar la estructura o esqueleto base y escribir el resto del código, dentro de los métodos que quedasen vacíos después de la autogeneración.

Las herramientas CASE más usadas en el entorno laboral y las que hay disponibles de forma libre (algunas no gratuitas) son las siguientes:

  • Visual Paradigm: esta empresa cubre con su oferta de herramientas la generación de casi todo el código y asistentes para el mantenimiento del mismo código una vez acabado, para seguir completándolo, corrigiéndolo y adaptándolo a las nuevas necesidades del cliente. Es una solución no libre y de pago, pero muy completa y aconsejable.
  • ArgoUML: de las herramientas libres que he probado, esta es una de las más completas. El desarrollo a nivel individual es muy potente y permite desarrollar de forma muy rápida una gran cantidad de diagramas UML que después se pueden autoconvertir a Java, C#, C++, Base de Datos…
  • Innovator: este software incluye características para diseño y desarrollo de software de lógica de negocio, basado en SOA y BPM. Es de pago, pero cuenta con una gran cantidad de características.
  • Umbrello: este proyecto, lo usé durante un tiempo, antes de decantarme por ArgoUML y, solo decir que, aunque es libre y tiene bastante buena pinta, el hecho de que haya quedado descontinuado (no se ha liberado ninguna nueva versión desde finales de 2007), tenía bastantes fallos.

Oracle y Sybase también tienen sus entornos para desarrollo rápido de aplicaciones, solo que son de pago y no es fácil acceder a una copia para probarlos, por lo que no los comento en la lista anterior.

Para más información puede ver la página de la wikipedia sobre CASE, la cual completa con algunos conceptos más, y mucho más software.

Comentarios desactivados

¡Debian Lenny 5.0 ya es estable!

16 febrero 2009

La liberación de etch se produjo el 8 de abril de 2007, ya hace 20 meses de eso, en informática es mucho tiempo, pero sin embargo, es un tiempo de liberación muy corto, teniendo en cuenta los lapsos a los que nos tenía acostumbrados Debian.

Desde entonces, en el mundo de GNU/Linux ha habido muchos cambios y, la distribución, se estaba quedando atrás en pro de otras más dinámicas como Ubuntu.

No obstante, en este fin de semana, el día de los enamorados, San Valentín, el Proyecto Debian nos ha brindado una nueva liberación de Debian, la correspondiente a la versión 5.0, con el nombre clave lenny.

Los avances:

  • Kernel de linux 2.6.26
  • Escritorios Gnome 2.22.2, Xfce 4.4.2, KDE 3.5.10, LXDE 0.3.2.1, GNUstep 7.3…
  • Base de Datos PostgreSQL 8.3.6, MySQL 5.0.51a
  • Lenguajes GCC 4.3, Python 2.5.2 y 2.4.6, Perl 5.10.0, PHP 5.2.6…
  • Servidor Apache 2.2.9, Samba 3.2.5…
  • Xen Hypervisor 3.2.1
  • OpenJDK 6b11
  • …

Ver: http://www.debian.org/News/2009/20090214

Comentarios desactivados

Documentos en bosqueviejo.org

16 febrero 2009

Después de unos días desarrollando un sitio apto para incluir mis manuales y documentos más largos, puesto que considero que el blog está bien para vivencias y experiencias, descubrimientos y “recetas”, pero, para los manuales, tutoriales y documentos, en sí, de mayor calado, es mejor tener algo un poco más orientado a la gestión documental.

Tras probar muchos wikis, me he dado cuenta de que el entorno web está bien, pero es insuficiente, al menos para mi. No me gusta el hecho de tener que trabajar siempre en una ventana de navegador tirando de javascript, para tener comandos óptimos para edición, o tener que copiar y pegar de un editor más completo y complejo a la web.

Por lo que me decidí a emplear DocBook. Este sistema de escribir documentos es como SGML o HTML, con la diferencia de que la riqueza sintáctica para la confección de documentos, es más cercana a LaTeX que a los anteriores.

Todo lo he montado en bosqueviejo.org, mi sitio de gestión documental, en el que iré actualizando e introduciendo, espero que a buen ritmo, documentos, libros, tutoriales, manuales y todo lo que pueda generar.

En principio, y para probar la sintaxis básica, he eliminado los artículos de redes en gnu/linux y asterisk y zaptel, por el hecho de que eran artículos muy extensos e incómodos de leer en el blog. Ahora están en formato HTML, un poco mejor organizado, y en formato PDF.

Espero comentarios :-)

Comentarios desactivados
« Older posts