Mes: enero 2007

La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo ya desde hace unos meses como excelente escusa para enfrentar la visión clásica y guiada por un plan con la visión ágil de la gestión de proyectos de desarrollo de software. Ya he ‘enfrentado’ estas dos visiones en anteriores entradas de este blog, cuya lectura recomiendo antes de abordar la lectura de este post: ¿Nos podemos caer de maduros?  y Métricas mal entendidas .

Siguiendo con la tradición, voy a tocar el tema de la planificación que Antonio Quirós comentaba en el número de Diciembre de dotNetmania, desde un punto de vista ágil.

No seré yo quien menosprecie el valor de la planificación. A menudo se acusa a las metodologías ágiles, sin fundamento, de adolecer de una ausencia de planificación. Las metodologías ágiles no carecen de planificación, simplemente la abordan de una manera diferente, centrando en lo cercano, evitando caer en la adivinación.

En su artículo Antonio Quirós dice: “Con la planificación el proyecto no está hecho, pero sí tenemos una imagen que se pretende fiel de cómo irán sucediendo las cosas hasta que el proyecto se complete”. Ojalá fuese así, nuestro trabajo sería mucho más simple (y mucho más aburrido dicho sea de paso), pero pensad en los proyectos en los que habéis participado… ¿En alguno de ellos la planificación a sido una “imagen fiel” de algo?.

El plan perfecto es un mito. Un mito atractivo pero un mito al fin y al cabo. De verdad alguien con experiencia en el desarrollo de software puede creer que será capaz de conocer todas las tareas y hitos, dependencias entre estos, los recursos con los que contará, los requisitos del cliente, y además ser capaz de estimar con una precisión suficiente como para poder tratar las estimaciones como certezas… La base de la dificultad para trazar un plan perfecto se encuentra en imposibilidad de establecer un entorno predecible en el que desarrollar el proyecto: La tecnología cambia, los miembros del equipo cambian, los requisitos cambian, la legislación cambia, el negocio cambia todo cambia… esa es la única certeza con la que contamos… Todos sabemos lo que cuesta trazar un plan de proyecto clásico, horas de reuniones, estimaciones, etc… En un entorno tan cambiante no estamos trazando planes, estamos haciendo predicciones, no nos engañemos. Y cuanto más extenso sea nuestro plan, más predicciones estamos haciendo y más nos vamos a equivocar. De todos modos Rappel se equivoca cada año y sigue viviendo de eso… ¿Qué sentido tiene centrarse en seguir un plan que con seguridad se verá sobrepasado por los acontecimientos al cuarto de hora de ser desarrollado?. Si no contamos con un plan perfecto, ¿sigue teneniendo sentido centrar toda la gestión de nuestro proyecto en seguir un plan?. Puede ser, que desde el punto de vista económico, mantener esta falacia tenga sentido, pero ¿Qué es lo que buscamos como empresa?, ¿cual es nuestra primera prioridad?Asegurarnos un margen a toda costa en nuestros proyectos o lograr que nuestros clientes logren valor  y por tanto esten ‘encantados’ de pagarnos. Yo tengo claro por cúal me inclino. Ya escribí anteriormente sobre este tema.

¿Significa esto que desde las metodologías ágiles se propugna que no debamos trazar planes? NO!. Simplemente se nos recuerda que nuestro principal plan debe ser ser ágiles.  Estar preparados para los cambios que con seguridad ocurrirán a lo largo del proyecto. Sobre esto me encanta una cita de Eisenhower: “Durante una batalla los planes siempre son inútiles, pero la planificación es indispensable”. Debemos centrarnos en realizar una planificación adaptativa en lugar de una planificación predictiva. La planificación adaptativa consiste en realizar una planificación de alto nivel, y refinarla solo para el futuro inmediato, para el trabajo que vamos a abordar de inmediato. El futuro cercano es mucho más fácil de predecir con precisión y mucho más útil. Este enfoque nos permite además contar con la información sobre como fueron nuestros anteriores planes a la hora de planear la siguiente iteración o sprint. Este enfoque es el que proponen las metodologías más en auge hoy en día: Scrum y MSF Agile. 

En Scrum, contamos con el Product Backlog como referencia que guía el desarrollo a largo medio plazo, y solo refinamos las estimaciones para los elementos seleccionados durante el Sprint Planning Meeting para ser abordados durante el próximo Sprint. En MSF Agile, es planteamiento es similar, contamos con un plan entrega y un plan de iteraciones, que desgrana que escenarios abordaremos en cada iteración, pero solo durante la planificación detallada de la iteración ser realiza un desglose detallado en tareas. Ambas metodologías reconocen que es un esfuerzo inutil el tratar de desarrollar una planificación detallada a priori.

Asumir la utilidad del enfoque adaptativo en la planificación tambien exige distinguir entre planificación y estimación. No es necesario desentrañar hasta la última tarea para hacer una estimación, siempre que seamos capaces de tratar las estimaciones como estimaciones y no como compromisos.

Para la planificación a medio-largo plazo es mucho más útil centrarse en realizar planes de entrega en lugar de planificaciones detallas. La idea de los planes de entrega es trazar una planificación de en qué orden se entregará la funcionalidad del sistema que se está desarrollando, centrándose en seleccionar la funcionalidad de mayor valor desde el punto de vista del negocio para las primeras entregas. ¿De qué sirve realizar el esfuerzo de planificar en detalle y dividir en tareas un trabajo que realizaremos dentro de seis meses? Mientras trazamos un plan detallado estamos privando a nuestro cliente de la posibilidad de ver software que funciona, que puede usar para descubrir sus necesidades o del que pueda comenzar a disfrutar para mejorar su negocio. ¿Cuántos proyectos conocéis que se han pasado meses en fases de planificación?.

Permitidme que de una nota de humor a este post con una viñeta de Dilbert, esclarecedora, sobre el tema que tratamos hoy. Especialmente interesante es el juego de leer la viñeta dos o tres veces seguidas, para ver como su caracter iterativo hace que el problema que plantea sea especialmente grave.

¡Espero vuestros comentarios y experiencias sobre este tema!

Este miercoles, 31 de Enero, Ibon Landa y un servidor estaremos en la segunda reunión propiciada por el grupo de usuarios del Pais Vasco, Artalde, hablando de gestión de proyectos con Team System.

Agenda:
19:00 Registro
19:15 Gestión de Proyectos en Team System con Rodrigo Corral de Plain Concepts e Ibon Landa de Panda Software.
Presentación de las características de Team System en lo relacionado a la gestión de proyectos; metologías, informes, builds, bugtrack, control de código fuente…
21:00 Fin

Lugar:
Universidad de Deusto
Edificio ESIDE, Aula de videoconferencia (2º piso)
Avda Universidades, 24
48007, BILBAO

Aquellos ineteresados en asistir pueden inscribirse aquí.

Una de las recomendaciones sobre rendimiento de SQL Server más simple y útil es que ‘toda tabla debe tener un índice clustered’. Esto no es 100% cierto y como casi toda norma tiene sus excepciones, pero son pocas.

Las ventajas de tener un índice clustered son varias pero cabe destacar algunos de los motivos por los que influyen en el rendimiento (simplificando algo el tema dicho sea de paso):

• Los registros están fisicamente ordenados según el índice clustered de la tabla (solo puede haber uno por tabla). Esto hace que el acceso a rangos de registros utilizando los campos del índice como filtro sea extremadamente rápido. Tambien es extremadamente rápida la ordenación y el filtrado sobre un índice clustered. Por lo tanto, debemos elegir indicés clustered adecuados para soportar este tipo de consultas, sobre todo cuando se realicen con mucha frecuencia.


• El resto de índices de una tabla que tenga un índice clustered se apoyan en este índice para guardar su información. Por ello debemos tratar elegir índices clustered sobre campos o combinaciones de campos del menor tamaño posible.


• Al final de un índice clustered se encuentra fisicamente los datos de los campos que forman parte del índice, de manera que si nuestra consulta solo necesita campos que se encuentran dentro del índice clustered no necesitará hacer ninguna lectura adicional una vez buscados los registros usando el índice.

A la hora de elegir un índice clustered debemos tener en cuenta las siguientes recomendaciones:

• Se sea usado por el mayor número posible de consultas, sobre todo por aquellas que devuelven un rango de registros seleccionados por el índice o se ordenan o agrupan por los campos del índice. También se benefician aquellas consultas que realizan JOINs sobre los campos cubiertos por el índice.


• No debemos elegir campos que cambian con mucha frecuencia o que almacenan mucha información. Cuanto más pequeño en cuanto a tamaño de los campos sea nuestro índice clustered mejor. Las columnas autonuméricas suelen ser unas exelentes candidatas a índice clustered. Por defecto las claves primarias son índices clustered, suele ser una buena opción, salvo que la clave primaria cambie con mucha frecuencia.


• Cuanto más exclusivos sean los valores del índice clustered mejor. La situación ideal es que los valores combinados de los campos que componen el índice sean únicos.

Por último os dejo un pequeño script T-SQL que nos dice que tablas de nuestra base de datos no tienen un índice clustered, y que por lo tanto requieren nuestra atención:

select t.name from sys.tables t
where t.name not in
(
      select t.name from sys.tables t
      join sys.indexes i
      on t.object_id = i.object_id
      where
            t.type = ‘U’ –Solo nos interesan las tablas de usuario
            and i.type = ‘1’ –1 == Índice clustered
)

Me planteaba una cuestión muy interesante uno de los alumnos de mi curso de Gestión de Proyecto con Team System de CampusMVP: ¿Cómo reducir los problemas en las fases finales del proyecto? Ya respesta obvia es: evitando que exista una fase final. Os imaginaís que pasaria si en los viajes a la luna quien diseño el Apolo hubiese dejado para el final pensar en como aterrizar:

– ¿Algien tiene un sistema de aproximación por ahí?
– Upss… no… pero corre estos scripts que te instalaran uno…
– Han fallado…
– Espera que te parcheo la capa de acceso a datos y quiza funcionen… Manolo!!!! recompila!!!! En debug que en release no hemos probado…
– Ahora funcionan los scripts… pero no veo nada en los controles…
– Lo mismo es no funciona el databinding pero eso los compila Pepe, que esta de vaciones. Solo lo puede compilar en su equipo y no tenemos la clave… Tendrás que aterrizar mañána…
– Cagón la puta, otra vuelta a luna… es ya la quinta…
– Tranquilo que mañana va el programador y te lo instala…

Esto que es absurdo es algo que ocurre a menudo en los proyectos de software.

La fase de implantación de un proyecto de software (o la de liberación en el caso del software ‘en caja’), siempre ha sido problemática. Pasar de un entorno de desarrollo a un entorno de producción nuestro proyecto o asegurar que el software se despliega en los equipos de nuestros clientes de manera correcta y ‘suave’ es algo vital para el éxito de nuestros proyectos. Los motivos por los cambios de entorno o despliegues son tan críticos son diversos, pero están relacionados con dos factores principalmente: la heterogeneidad de los entornos y la mayor carga que sufren las aplicaciones en producción.

La percepción respecto a los problemas de despliegue de los clientes ha cambiado. La percepción de los clientes respecto a la calidad del software en general ha cambiado, escribía sobre esto no hace mucho en mi blog: La calidad en el software no es opcional. Los clientes son cada vez más reacios frente a las aplicaciones que no se depliegan suavemente.

El enfoque tradicional en desarrollo del software ha sido centrarse en desarrollar la funcionalidad del sistema y solo al final preocuparnos por la integración y la desplegabilidad de los diferentes componentes. La industria del software ha descubierto que estas características del software son algo de suma importancia que no se puede dejar para el final del proyecto. Abordar estos aspectos al final del proyecto suele ser equivalentes ha olvidarlos.

¿Cuales son las soluciones que plantean la ingeniería del software y las herramientas de desarrollo modernas?

Pues el uso de técnicas como las construcciones frecuentes, bien sean diarias o incluso continuas. Las construcciones diarias consisten en construir una vez al día el software completo, desplegarlo en diferentes entornos de manera automática y ejecutar nuestros test automáticos en esos entornos. La construcción continua lleva la construcción frecuente al extremo, de manera que cada vez que se integra código en el gestor de fuentes se realiza el proceso de construcción, despliegue y testeo automático. Si estas pruebas automatizadas se ejecutan de manera correcta, podemos pasar esa build a nuestros testers para que ejecuten aquellas pruebas de aceptación que hayamos definido. Evidentemente, esto no es posible si no tenemos un tester en nuestros proyectos. Utilizando estas técnicas desde el comienzo de nuestros proyectos nos aseguramos que distribuimos la carga de trabajo necesaria para integrar y asegurar la desplegabilidad durante toda la vida del proyecto, evitando el efecto ‘en mi entorno funciona’ consistente en que cuando creemos que el proyecto esta ‘completo’ tenemos una fase muy larga y tortuosa de implantación y despliegue que siempre genera tensiones entre stakeholders y equipo de desarrollo.

Desde el punto de vista de las herramientas, Team System soporta estas técnicas modernas de desarrollo de software permitiéndonos definir construcciones automáticas, que ejecuten aquellos tests que consideremos necesarios o interesantes, y que podremos ejecutar a nuestro antojo para construir, integrar y desplegar nuestro software en entornos de test de manera automática cada vez que lo consideremos conveniente.

Desde el punto de vista de las metodologías modernas de desarrollo, casi todas abordan el tema de un modo u otro. Scrum obliga a que al final del cada sprint tengamos software que este completo para su implantación en si así lo decide el Product Owner. Solo el software que es completamente funcional y tiene la calidad suficiente puede ser demostrado en el Sprint Review Meeting. En MSF tenemos un rol dedicado a asegurar la desplegabilidad y facilidad de operación del sistema, el Deployment Manager y además el principio ‘Invertir en la calidad’ es uno de los que guían esta metodología.

Supongamos que necesitamos añadir soporte para Workflow Foundation a un proyecto que no hemos creado usando las plantillas de proyecto para proyectos de Workflow.

Pues bien, para ello basta con abrír nuestro archivo de proyecto (tipicamente *.*proj) y en la sección PropertyGroup añadir el texto que aparece abajo en verde. A partir de este momento ya tendremos disponible el menu contextual que nos permitirá añadir worflows y actividades a nuestra proyecto (vease imagen adjunta).

<PropertyGroup>
….
<ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
…
</PropertyGroup>

Espero que este truquito os sea útil. Si alguien se pregunta como lo he descubierto, la respuesta es usando WinMerge para comparar un proyecto de Workflow Foundation con uno de libreria de clase normal y corriente.

Últimamente he recibido esta pregunta en dos ocasiones, en un corto espacio de tiempo, por correo. Además siempre que doy un curso sobre gestión de proyectos aparece. No es de respuesta facil y mucho más dificil aún es dar una respuesta universal.

Elegir una metodología no es una cuestión simple, se prodría escribir un libro sobre este tema. En mi opinión es algo que depende principalmente de dos factores, el tipo de proyectos y la cultura que exista en la empresa.

Otro factor que puede tener cierto peso, pero que no tiene por que ser determinante del todo, es que esa metodología este soportada por determinadas herramientas, por ejemplo Team System o que existan herramientas de nuestro gusto que nos faciliten la adopción de la metodología elegida. Aunque no es un factor determinante, contar con una herramienta adecuada es algo que puede hacer mucho más llevadera la implantación de una metodología.

El primer paso es conocer a fondo las metodologías que evaluamos o buscar a alguien que las conozca, y en una situación ideal haber trabajado con varias de ellas. No hay metodología que funcione de manera universal, de hecho cada vez más las metodologías se conciben como ‘marcos’ metodológicos que es necesario ajustar para cada organización y tipo de proyecto. Realizar este ajuste es algo que necesita de una experiencia y un conocimiento previo. El problema con la implantación de una metodología es que no se suele tener una segunda oportunidad.

A la hora de seleccionar una metodología la primera decisión que se plantea es: ¿Una metodología ágil o una metodología guiada por plan? En mi opinión la gran mayoria de proyectos se pueden beneficiar mucho del uso de una metodología ágil, pero indudablemente existen proyectos y entornos en los que es condición, generalmente impuesta por el cliente o la dirección de la empresa, que el proyecto se desarrolle con ‘más control’.

Para plantearte el uso de una metodología ágil tenemos que ser capaces de asumir completamente el Manifiesto Ágil y ser capaces de hacer que sea el paradigma que guie la gestión de nuestro proyecto, y desde luego es sumamente importante que logremos un sponsor. Tener un sponsor es vital en todo proyecto de implantación de una metodología, pero sobretodo es vital para implantar una metodología ágil, pues exige que se produzcan profundos cambios en la cultura tradicional relativa a la gestión de proyectos.

Poniendo de menos a más ágil, de más ‘revolucionaria’ a menos, las metodologías más populares, nos queda la siguiente lista:

• CMMI con una implanción tradicional


• Rational Unified Process


• MSF for CMMI Process Improvement


• MSF Agile


• Scrum


• eXtreme Programming

Sin conocer a fondo el tipo de proyecto, las herramientas con las que se puede contar (RUP y MSF se implanta bien si se tienen las herramientas de Rational, carísimas, o Team System respectivamente) y cual es la cultura de la empresa en lo que a gestión de proyectos se refiere y en que grado se busca impactar en esa cultura, a veces es precisamente lo que se busca o se necesita, aplicaria la maxima de que ‘en el punto medio esta la virtud’ y me iria a MSF.

A grosso modo creo Team System + MSF Agile es una combinación que puede funcionar para una gran rango de proyectos y un gran rango de culturas de empresa. Al contar con métricas nos puede ayudar mucho a la hora de ganar el apoyo de los gestores de la empresa, pero tenemos que se vigilantes con el uso que se hacer de las métricas.

Si no puedes contar con una herramienta ‘cara’ entoces Scrum sería una excelente opción, pues se puede llevar con Excel o con herramientas gratuitas como Trac o VersionOne (tiene una versión gratuita hasta 5 usuarios), que están a años luz de Team System pero aun así son de mucha ayuda. A mi Scrum me gusta especialmente por varios motivos, principalmente porque es simple y de sentido común, pero tengo que reconocer que exije un cambio de mentalidad que no siempre es posible.

Por último, hace algún tiempo hable en mi blog de por qué puede fallar una implantación de Team System, algunos de los motivos son de aplicación a la implantación de cualquier herramienta o metodología.

Una pregunta que recibo habitualmente cuando imparto cursos sobre Team Foundation Server es ¿Cómo se lleva Visual Basic 6.0 con Team Foundation Server? Siempre tenía que responder que lo único que sabía sobre el tema es que existe un plugin para Visual Basic 6.0 desarrollado por Microsoft que permite trabajar contra Team Foundation Server.

No deja de sorprenderme la de gente que sigue desarrollando en Visual Basic 6.0. Hay muchísimos desarrolladores que aun usan este venerable lenguaje. De hecho uno de los servicios más exitosos de que ofrecemos en Plain Concepts es ayudar a estos equipos a migrar su desarrollos y arquitecturas a entorno .Net.

Bueno, volviendo a lo que nos ocupa, ya que estaba harto de hablar de oidas, me decidí a instalar Visual Basic 6.0 (que recuerdos, a poco se me escapa una lagrimita… anda que no tiré líneas de Visual Basic ‘clasico’) y el Visual Studio 2005 Team Foundation Server MSSCCI Provider, que nos permite acceder a Team Foundation Server desde:

Visual Studio .NET 2003

Visual C++ 6 SP6

Visual Visual Basic 6 SP6

Visual FoxPro 9 SP1

Microsoft Access 2003 SP2

SQL Server Management Studio

Sparx Systems Enterprise Architect 6.1

Sybase PowerBuilder 10.5

Toad for SQL Server 2.0

Hasta aquí nada nuevo, pero lo que si he podido comprobar por mi mismo es que:

Se instala como un plugin de Visual Basic que hay que activar desde el Administrador de complementos (Add-In Manager), con una entrada llamada Source Code Control, tal y como podeís ver en la siguiente imagen:

A partir de este momento tenemos a nuestra diposición, una vez añadamos el proyecto de Visual Basic 6.0 a nuestro Team Foundation Server, los menus contextuales habituales para trabajar con el gestor de fuentes. Además contamos con un nuevo menu Team Foundation en el menu Herramientas (Tools) de nuestro Visual Basic 6.0. La entradas de este menu nos permiten interactuar con nuestro Team Foundation Server desde Visual Basic 6.0:

La gran duda que yo tenía y que ha quedado desvelada, con respuestas positiva es si al subir fuentes podiamos relacionarlas con Work Items y ‘matar’ estos desde Visual Basic 6.0. El dialogo de Check-In es exactamente el mismo que el que vemos desde Visual Studio 2005:

Un patrón que, a lo largo de mi experiencia como desarrollador se repite, es que alguien ajeno al equipo de desarrollo, generalmente alguien con cierto nivel dentro de la empresa, y con no demasiados conocimientos sobre desarrollo de software o gestión de proyectos de software, no pierda oportunidad de dejar patente que el equipo de desarrollo tiene que mantener ‘la tensión’.

Siempre parece que, desde fuera de los equipos de desarrollo, se percibe que los desarolladores de software no ponemos suficiente interés en que el proyectos progrese. Siempre se duda de la profesionalidad de lo desarrolladores y quizás, desde un punto de vista general, nos lo hemos ganado a pulso.

Sin embargo desde dentro de los equipos de desarrollo lo que se suele percibir es una presión hueca, solo de palabra y no acompañada de acciones que ayuden al equipo a progresar.

Varias metodologías modernas de desarrollo abordan esta cuestión. MSF utiliza los ‘advocacy groups ‘ y los equipos entre iguales para construir un entorno que permita que el proyecto avance de una manera sana. En Scrum el Sprint Retrospective Meeting y la gestión que el Scrum Master realiza sobre los impedimenetos, trata de asegurar que se actua sobre aquellas cuestiones que entorpecen el progreso del proyectos. Inclluso la gestión clásica del riesgo de los proyectos sigue este enfoque, aunque de una manera menos explicita.

Si bien parece claro y esta totalmente asumido en las metodologías modernas de desarrollo, que es mucho más efectivo el enfoque de eliminar impedimentos o riesgos que el enfoque de ‘introducir tensión’, es evidente que los proyectos necesitan de cierta tensión para lograr una ‘velocidad de crucero’ que asegure que el proyecto avanza de manera continua, enfocada y sotenible.

Steve McConnell en su libro Rapid Development (Pag. 600) muestra un gráfico, basado en numerosos estudios, que deja pantente que si no hay cierta tensión en la planificación, la motivación de los desarrolladores no alcanza su punto optimo . Tambien deja patente que pasado cierto punto de tensión en la planificación la motivación del equipo cae en picado. Esta demostrado que la motivación del equipo de desarrollo es un factor de vital influencia sobre exito de un proyecto, quizás incluso el factor más influyente, según mucho autores.Es peligroso adentrarse en los terrenos de la tensión excesiva en la planificación, si el desarrollador no siente como posible la planificación ni siquiera intentará cumplirla. Scrum maneja extraordinariamente esta situación, puesto que es el propio equipo el que establece su compromiso con la planificación decidiendo libremente que parte de Product Baclog aborda. En MSF esta decisión la toma, al principio de cada iteración, el jefe de proyecto, pero siempre debe tener en cuenta la opinión del resto del equipo y los datos de los ocurrido en anteriores iteraciones.

En mis tiempos de estudiante de Ing. Tec. Industrial Mecánica, una asignatura que me gustaba especialmente era Resistencia de Materiales. Las principales tensiones que podian aparecer en un cuerpo solido eran la tracción y la compresión. Simplificando el tema, un elemento estructural se sometia a compresíón cuando se ejercia presión en sus extremos y a tracción cuando se tiraba de ellos. Las estructuras de acero responden mucho mejor a la tracción que a la compresión. Pensad en lo dificil que es romper un clavo tirando de sus extremos con unos alicates, por fino que el clavo sea, y sin embargo lo facil que es doblarlo.

Siguiendo con el simil, hay dos maneras de intruduccir la necesaria tensión en los equipos de desarrollo: Por tracción, liderando el equipo en su avanze, motivándolo, ayudandolo y eliminando los obstaculos que surgan en su camino o por compresión, realizando una planificación lo más comprimida posible, y tratando de que lo único que importe sea su cumplimiento olvidando otros parémtros vitales para el exito de todo proyecto: calidad y motivación del equipo. Como las estructuras de acero, los equipos de desarrollo responden mucho mejor a la tracción que la compresión. Si una estructura de acero recibe compresión de intensidad y duración excesivas se colapsa, lo mismo ocurre con los equipos de software. Los ingenieros de estructurass se encargan de que las estructuras de acero no trabajen bajo compresión, los jefes de proyecto deben hacer los mismo con sus equipos de desarrollo.

He descubierto por casualidad un sitio muy interesante sobre Scrum: Implementing Scrum.

Se trata del blog de un Certified Scrum Master y Scrum Certified Trainer que escribe sobre Scrum, pero no solo escribe sino que acompaña las interesantes entradas de su blog con una tira ‘cómica’. No es que las tiras sean para morirte de risa, pero transmiten siempre ideas interesantes sobre Scrum. Además las tirás cómicas solos son un pretexto para tocar temas relevantes sobre la implantación de Scrum que explica en las entradas de su blog.

Muy recomendable.

Os dejo un par de tiras que me han gustado especialmente:

¿Qué es Scrum?

La clásica historia del cerdo y el pollo

Para aquellos menos familiarizados con Scrum, decir que en esta metodología se habla de cerdos y pollos o gallinas. Los cerdos son aquellos que relamente estan comprometidos en el proyecto, son los responsables de llevarlo a cabo y serán medidos en su desempeño profesional por  los resultados del proyecto. Las gallinas son aquellos que añun estando involucrados en proyecto y teniendo interés en proyecto y mucho que aportar no están directamente involucrados en llevarlo a cabo. La metáforma elegída en Scrum para

Bueno, parece que los amigos Miguel y Eugenio me han tocado… me recuerda a cuando de niños jugamos a ‘la peste’, pero visto la difusión del juego parece que se trata de algo mucho más virulento!!!. Parece que aquí no casa, ni alturita, ni caballito blano. Así que paso a contaros cinco cosas que en la blogosfera no se saben de mi.

1. Soy PUNKY. PUNKY con mayúsculas, bajo esta apariencia de cuarentón (a persar de tener solo treinta años mi aspecto se empeña en aparentar lo que realmente he vivido) se oculta un PUNKY como un castillo. Más de uno fliparia si me viese en un concierto de La Poya Records, Marea, Extremo, Platero y Tu (si, muchos que canturreaís a Fito deberías saber que antes hizo músca de la de verdad) o Reincidentes… Durante una gran parte de mi vida, ir a conciertos de estos grupos fue mi principal hobby. Aún canto, para sorpresa de mis compañeros de Plain Concepts (a los que despierto a ritmo de punk), canciones de estos grupos mientras me ducho por las mañanas. Lo de ir a conciertos lo tengo un pelín abandonado.

2. A pesar de lo punky que salí después, mi madre se empeño en que tocase el violín. Llegue a hacerlo más que decentemente, he incluso a ser miembro de la orquesta del conservatorio de Burgos. Lo único que retengo de mi formación musical es la capacidad de silvar cualquier tonadilla de una manera más o menos decente.

3. Aunque pase por la universidad (ing. tec. industrial, rama mecánica) y estube unos cuantos años, siempre preferí una buena partida de cartas, trastear con un PC, irme a leer a la biblioteca (sobre historia o informática!!!) o trabajar como freelance (empece con 18 tacos) que ir a clase. Así me pinto el pelo, a final sabia mucho más de informática, de historia y de jugar a cartas que de ingeniería mecánica. Me encanta la historia de la segunda guerra mundial, especialmente lo relativo a las batallas navales y el surgimiento de los facismos (hay que conocer los errores a fondo para no volver a cometerlos). Durante mucho tiempo deboré las infames, desde un punto de vista liteario, pero realmente adictivas novelas de Sven Hansell (Batallón de castigo, La legión de los condenados, Gestapo, Monte Cassino etc…) y todos los libros que cayeron en mis manos sobre la segunda guerra mundial.

4. Soy Beliforano. Del mismísimo Belorado (a 48 km de Burgos, cerca de la Rioja). Nací en Burgos y viví en Burgos la mayor parte de mi vida y ahora en vivo en Bilbao, pero soy Beliforano. Mi mujer me hace rabiar con este tema. Soy capaz de ‘comerme’ a quien me diga que no soy de Belorado. Duermo a mi hija de cuatro meses a ritmo de himno a Belorado, ¿se puede ser más beliforano?. Además ya lo dice el refrán: El buey no es de donde nace sino de donde… se divierte!!!. Y porque mi empeño en declararme beliforano: pues bien la culpa es de los veranos en casa de mis abuelos y del puñao de amigos que tengo allí y a los que veo allí(aupa dissidente y aupa la horca). Otra prueba clara de que soy beliforano de pura cepa es mi total conocimiento del significado de palabras como: avocinar, cañutero, chospar… Todos mís equpos informáticos se llaman como parajes de mi pueblo: cerezera, borbullon, tirón, barcenas… Resumiendo: Que soy BELIFORANO COJONES!!!!.

 5. Durante un tiempo además competí en ciclismo sin demasiado exito, aunque acabe alguna carrera que otra. Ahora mi pasión deportiva se ha movido hacia la pelota mano. No se por qué se empeñan en llamarla pelota vasca cuando los mejores son siempre navarros y el mejor pelotari de todos los tiempos es riojano: Titín III, el mago de Tricio. Vale, vale, ya se que no es el que mas títulos tiene, pero lleva más de una década llenado frontones y a sun 36 años aun vende carísimas su pocas derrotas. Suelo ser un tio muy paciente y templado, pero en el frónton, si juega Titín, soy un autentico holligan. Además de ver, tambien juego a pelota mano. Me encanta jugar, es llegar al frontón y olvidarme de todo. No lo hago mal del todo y además me divierto un huevo. Es un deporte muy duro y muy completo, y a pesar de los esterotipos la principal cualidad que hace falta en el frontón es la inteligencia. Os dejo una foto de los tacos de mi mano derecha, seguro que nunca habeís visto las proteciones que se usan. Por cierto ¿alguien se atreve con un partido? jejejejeje…. Mientras escribo este post estoy viendo en telecinco (en el norte hechan la pelota en telecinco) Titín-Lasa vs. Bengoetxa VI – Patxi Ruiz, partidazo…

No me queda mucha gente a la que tagear y la verdad es que odio las cadenas, pero bueno… voy a poner un tag a: Gorka Elexgaray, Jorge Serrano, Iván González, Eladio Rincón y Marco Amoedo.