La importancia de llamarse "equipo"

Pues sí, es importante, y ¿por qué?, simple, el equipo decide y es uno de los factores de éxito principales.

Vaya, si que es importante este equipo ¿eh?, bromas a parte, lo que quiero reflejar en este post, es algo que yo siempre intento dejar claro y que se asuma, y es que el equipo debe tener la capacidad de decisión sobre como organizarse, herramientas, procesos, metodologías, … Por supuesto, para esto el equipo tiene que ser responsable y sobre todo, sentirse “importante”, para tomar estas decisiones con responsabilidad.

Si no tenemos un equipo capaz de auto-organizarse, de hacer cosas como las que se discutían hace poco por http://geeks.ms acerca de las estimaciones, y de hacerlas, siempre con sentido común claro, usando las herramientas que ellos sienten que les funcionan, mejorando los procesos que no les funcionan, utilizando las prácticas del modo que mejor funcionan en ese equipo.

Tenemos que tener en cuenta, que una de las cosas que tenemos las personas, es que cada uno somos diferentes, lo que nos funciona a unos, no les funciona a otros, y esto mismo se traspasa a los equipos, pero lo que nunca funciona es que una persona o un grupo reducido de personas impongan su criterio al resto, cuando este no es compartido.

Esto es una gran fuente de problemas en los equipos, ya que cierta parte del equipo no asumirá como suyas esas prácticas, procesos, decisiones, etc… y otra de las cosas que tenemos las personas, es que cuando no asumimos las decisiones como nuestras, no se llevan a cabo con la misma efectividad.

En ello se basan metodologías como Scrum, en la que se toma al equipo como una unidad que es capaz de decidir como se van a organizar, de estimar las tareas de un modo eficaz para decidir la capacidad del sprint, asumiendo como suyas esas decisiones, y dándole mayor responsabilidad y mayor poder de decisión.

Pero siempre, al equipo, no a una única persona, por muy alto sea el árbol al que se suba, y esto se puede aplicar a metodologías ágiles y no ágiles, tenemos que aprender a respetar a los equipos como tales, incluyendo a todas las personas desde la primera hasta la última de las que están involucrados en el equipo, si necesitamos usar CMMI porque, cosas de la vida, necesitamos que este proyecto esté certificado, bueno esa no es una decisión del equipo, por supuesto, casi siempre será del cliente, pero si podemos dejar al equipo la responsabilidad de decidir como nos vamos a organizar para que todos los entregables, se entreguen en los plazos, y con la calidad exigida por el cliente y en este caso CMMI.

Y, si bien hasta ahora he estado hablando a nivel de desarrollo de software, realmente esta reflexión me viene no por algo vivido en un proyecto, si no en otro entorno completamente diferente al del desarrollo de software (como es el de la asociación dónde colaboro), y dónde se puede ver como los equipos, sean de la disciplina que sean, tienen que tener la capacidad de establecer sus criterios organizativos, acordados y asumidos por todos los miembros del equipo, para que estos sean llevados a cabo con efectividad.

No cabe duda de que hay decisiones que no corresponden al equipo, difícilmente podrá el equipo decidir como se tiene que tramitar un crédito por ejemplo, pero si podrán tomar las decisiones de su implementación, que herramientas son las adecuadas para su implementación, las estimaciones de plazos (que aunque no quiero reabrir el debate, estoy con Rodrigo plenamente, especialmente en la parte de que todo el equipo opina en las estimaciones), como se van a organizar para conseguir el objetivo.

Por supuesto, esto requiere otra cosa de la que podremos hablar más adelante, disciplina y equipos disciplinados y responsables, pero para eso antes tenemos que empezar a darles la responsabilidad.

Gestión de requisitos en Team System

Una de las partes importantes del ciclo de vida de software, es la gestión de requisitos de lo que vamos a construir, esto es básico, conseguir los requerimientos, manejar el cambio en los mismos, gestionar que vamos construir, gestionar su comunicación, etc..

Los requisitos se pueden dividir principalmente en:

  • Requisitos de negocio: dónde se describen los objetivos principales del software a construir.
  • Requisitos de usuario: dónde describimos las necesidades de los usuarios
  • Requisitos funcionales: aquí vamos a detallar los requisitos internos del sistema.
  • Requisitos de calidad de servicio: rendimiento, escalabilidad, seguridad, internacionalización, etc..

La gestión adecuada de todos estos requisitos, influye de manera muy importante en el éxito de un proyecto, dependiendo de la metodología se gestionarán de un modo u otro, pero como siempre necesitamos de herramientas que nos permitan la gestión integral de los requisitos de un modo compartido en el equipo.

Hasta ahora en Team System teníamos los  Work Items, que en muchos equipos será suficiente, al menos inicialmente, pero en otros proyectos y con otros equipos se necesitan herramientas más completas, como podría ser Borland Caliber, que permitan cosas como jerarquías, que a día de hoy no tenemos en Team System.

Pero esto pronto va a cambiar jeje, Microsoft acaba de publicar un Whitepaper acerca de la gestión de requisitos en Team System, y su futura implementación en Rosario, así como hala de otros sistemas de gestión de requisitos, os lo recomiendo leer, aquí vais a encontrar una descripción mucho más detallada de toda esta gestión de los requisitos y su importancia.

Aquí va el link.

Requirements Management with Visual Studio Team System 2008

Publicado conector de Team Foundation Server con Project server 2007

Pues nada, para todos los interesados en conectar TFS con Project Server 2007 ayer publicaron la versión 2.0 en release en codeplex, recordad que esto no es un conector que tenga soporte de Microsoft, para bajarlo:

http://www.codeplex.com/pstfsconnector

Y la mejor noticia a parte de esto, es que las futuras versiones de Team System, traerán integración nativa con Project Server.

El hombre en el árbol … o a vueltas con las jerarquías

Ayer, hablando con unos colegas sobre experiencias que han tenido en sus trabajos (todos en equipos de desarrollo), un amigo me contó una cosa que le ocurrió en un trabajo, y  que como poco me pareció una curiosa forma de explicarle como iban las jerarquías en esa empresa :o) obviamente no voy a decir nombres.8796_man_in_tree_520


Empecemos contando la curiosa visión de las jerarquías que le pusieron a mi amigo:



  • Su jefe, le sentó, cogió un papel, dibujó un hombrecillo, y le dijo “este eres tú en la empresa”

  • A continuación dibujó un árbol y en las ramas dibujó otro hombrecillo, y le dijo “este soy yo”

  • Por último, pintó otro hombrecillo en la copa del árbol, y dijo, “y este es mi jefe”.

La conclusión que le dijo a mi amigo, es que como podía ver en el dibujo (una representación sin más de la jerarquía), el estaba por encima, y por tanto tenía una “visión más amplia”  de todo, así como su jefe por encima de el, con lo que cuando el (el jefe de mi amigo) le “ordenase” algo, no debía cuestionarlo, puesto que el tenía una visión más amplia, así como cuando su jefe le decía algo el no lo cuestionaba.


En fin, una visión curiosa de como funcionan en algunos sitios, lo primero que se puede observar aquí, es que los marrones siempre van a caer de arriba hacia abajo, cosas de la ley de Newton. Lo siguiente que se me ocurre, si a mi me dicen eso, es que la comunicación, no va a fluir precisamente, facilitando la toma de decisiones en el equipo, si no que me van a tratar como “cadena de montaje”, o “picapedrero”.


Por supuesto, los crasos errores en los que estaban cayendo en este equipo son muchos de los que se pretenden evitar con las metodologías ágiles:



  • Los equipos jerárquicos, en el desarrollo de software, está sobradamente que no funcionan, debemos formar un equipo de “iguales”, todos con su responsabilidad correspondiente a la hora del éxito o fracaso de l proyecto.

  • Falta de comunicación, cuando alguien te dice que no cuestiones sus “órdenes” puesto que el tiene información que tu no tienes, y que con esa frase demuestra que ni siquiera te va a proporcionar, malo. La información tiene que ser algo compartido en el proyecto, el equipo tiene que ser partícipe de las decisiones, tener la información para organizarse, decidir y apoyar el éxito del proyecto. La comunicación es algo fundamental y básico para el éxito.

  • El equipo de desarrollo no es un equipo al que se le tira “la carnaza” del trabajo desde arriba y esperamos a que nos suban los resultados, los equipos de desarrollo tienen que ser partícipes en todo momento del proyecto, son los responsables más directos de lo que se va a generar: el software, y tienen que tener la capacidad de organizarse del modo que más convenga a todo el equipo, de tomar sus propias decisiones técnicas, basándonos en toda la información de que disponen, no son cadenas de montaje, son equipos que toman sus decisiones informadas en todo momento, para el éxito del proyecto.

Bueno de esto realmente se podría hablar mucho más, se pueden poner diferentes puntos de vista, opiniones, etc, la mía, personal, de Luis Fraile (que luego no haya equivocaciones), es que esa visión del hombre en el árbol, no es válida para un equipo de desarrollo de software maduro, y probablemente esté avocada, a lo mejor no al fracaso, porque es indudable que así se funciona en muchos sitios, pero si está avocada a que el equipo de desarrollo se frustre poco a poco, se de rotación, se produzca código de peor calidad, y nunca consigamos tener un equipo maduro de desarrollo.

Desarrollando para el iPhone … sin el SDK

Si, un post que no es de Team system, ni TFS ni similares 🙂

Una de las cosas que más me gustan de trabajar en algo como Multidomo es la cantidad de cosas que probamos y hacemos y que siempre están a la última, como por ejemplo lo que estoy haciendo ahora.

Esta misma semana Apple ha anunciado el lanzamiento del SDK para el iPhone, bueno, para los interesados, yo ya lo he descargado, pero como no dispongo de una máquina con Mac OS, pues no lo he podido probar :), de todos modos, para desarrollar aplicaciones para iPhone / iPod Touch, no es estrictamente necesario hacerlo con el SDK, lo cierto es que se pueden desarrollar apliaciones web para su navegador Safari.

Y digo para su navegador, porque, aunque es todo HTML, CSS 2.01, y Javascript, bueno tiene ciertas características, como el “viewport” en los metas, pero no es extremadamente complejo, y basándonos en la documentación del DevCenter de apple (que por cierto, ya podrían hacer algo tipo MSDN), y conocimientos de AJAX, CSS, y también apoyándonos en librerías externas como iUI, que nos ayudan a simular la experiencia de usuario del iPhone, podemos desarrollar aplicaciones web para el iPhone, por supuesto, con ASP.NET.

Tampoco quiero meterme en muchas complejidades, entre otras cosas porque yo mismo estoy empezando y por ahora digamos que lo que tengo es una prueba de concepto “venida a más”, pero como recomendaciones haría:

  • Leer la documentación y los ejemplos de aplicaciones web del DevCenter de apple y hacer algún ejemplo sencillo con ASP.NET y los ejemplos de Apple. Os diré que cuanto más podáis “limpiar” el código generado de ASP.NET (evitando controles de servidor que no necesitemos, teniendo cuidado con las plantillas de los controles que si que queramos usar, etc…) mejor, ya que Safari es bastante “toca-narices” en cuanto a esto.
  • Yo estoy usando AJAX.NET y llamadas a webservices (por ahora asmx) con JSON. Los que ya conocéis AJAX.NET sabéis que esto es muy sencillo y funciona perfectamente con Safari para iPhone.
  • Ahora vamos a complicarlo un poco más, si habéis estado jugueteando con un iPhone / iPod Touch, habréis visto que la experiencia de usuario, a mi modo de ver, es espectacular, hay que reconocer que se lo han currado, bueno, esta experiencia de usuario no es complicada de conseguir basándonos en Javascript y CSS, pero ya hay gente que ha desarrollado librerías que con poco esfuerzo y buenos conocimientos de Javascript y CSS podemos adaptar, yo la que estoy usando es iUI, y la verdad es que los resultados son bastante buenos (aunque mejorables).
  • Otra cosa que yo estoy haciendo es desactivar el ViewState en todas las páginas, recordemos que aquí el “peso” es mucho más crítico, ya que los que usen nuestra aplicación, la usarán muchas veces por GPRS y a pesar de las tarifas “planas”, el tráfico es un problema, y puesto que casi todo lo haremos por llamadas con Javascript y JSON, podemos evitar totalmente el ViewState.
  • NUEVO: Ayer se me olvidó 🙁 otra cosa que necesitáis, es instalaros la Beta de Safari, el navegador de Apple, porque las páginas que desarrolléis para el iPhone sólo os van a funcionar bien en ese navegador.

Y bueno, creo que no me dejo nada para poder empezar, he de reconocer que tampoco es que sea un “crack” en aplicaciones web, así que seguro que muchos de los que ahi por aquí tienen muchas más ideas :).

Simplemente aquí os dejo unas capturas de Multidomo en iPhone iPod Touch, ya os iré enseñando más según lo vaya teniendo.

multidomo_iPod menu_multidomo_ipod camaras_multidomo_ipod

Presentaciones de ALM de los Techdays

Bueno, pues ya hemos subido las presentaciones de las dos charlas de ALM que di con Bruno Capuano y Rodrigo Corral en los TechDays, así que aquí las tenéis.

La verdad es que nos lo pasamos muy bien, y fue un placer dar esas charlas con esos dos máquinas.

Y como bien comenta Bruno en su post, interesante ronda de preguntas que tuvimos después de la segunda charla, y en las preguntas por los pasillos en las que se ve la cantidad de cosas y cuestiones que se plantea la gente acerca de Team System, lo cual demuestra que hay mucha gente utilizándolo, y mucha más gente deseando instalarlo y probarlo.

También fue un placer encontrarse con mucha gente que hacía tiempo que no veía, y que es frecuente encontrarse en estos eventos, la verdad es que a pesar de acabar totalmente destrozado, y además con una pequeña sorpresa, que me esperaba, por parte de la asociación con la que colaboro de voluntario que me comunicaron durante el miércoles mientras que yo estaba de fiesta en el palacio de congresos 😛

Team Foundation Server en la radio

Y no, no es que sea el nuevo hit de los 40 principales, es que Mickey GoussetMartin Woodward y Paul Hacker, MVPs de Team System, han creado hace bien poquito un “programa de radio” en forma de podcasts para llevar en vuestro iPod Zune y aprender de estos grandes expertos.

Las grabaciones actuales las tenéis en http://teamsystemrocks.com/files/30/radiotfs/default.aspx y también podéis suscribiros al feed en: http://feeds.feedburner.com/radiotfs

Por cierto, buscan tanto feedback, como preguntas que queráis hacerles para que las respondan en los postcasts, podéis escribirles a radiotfs@gmail.com

Lista de eventos disponibles en TFS

Bueno aquí estoy de vuelta del primer día de los TechDays, haciendo la “digestión” de todo lo visto hoy, de toda la gente que hacía tiempo que no veía y que he visto, y terminando de dar unos retoques a las presentaciones que doy mañana 🙂

Y bueno he visto algo interesante, muchos de los que me conocéis que entre las muuuuchas cosas raras que me gustan, una es la extensibilidad de Team Foundation Server, y uno de los puntos más sencillos de extender (que si queréis podemos tocar más adelante) es los eventos de TFS, básicamente, son determinados “anuncios” que el TFS manda ante determinadas acciones como un CheckIn, el fin de una build, o la modificación de un WorkItem, estos eventos, por si solos no hacen “nada”, pero tenemos la posibilidad de suscribir a estos eventos un web service de nuestra “cosecha” para realizar los procesos que necesitemos en nuestro entorno, o bien, simplemente suscribirnos con una dirección de correo electrónico para recibir alertas.

Y ahora viene la pregunta ¿cuales son estos eventos? para 2005 salió una lista hace tiempo en un blog, pero la verdad es que no había ninguna lista “oficial”, y bueno, hoy Charles Sterling ha publicado en su blog la lista “definitiva” de eventos disponibles en TFS, así como algunos obsoletos, los podéis consultar directamente en su blog: http://blogs.msdn.com/charles_sterling/archive/2008/02/26/definitive-list-of-events-that-are-supported-in-tfs.aspx

Y aquí os pongo la lista:

Work Item Tracking

· WorkItemChangedEvent -> Este evento se lanza cuando se crea/modifica un work item

Version Control

· CheckInEvent -> se lanza cada vez que se produce un check-in en Source Control

Team Build

· BuildCompletionEvent2 -> se lanza cuando se completa una build

· BuildStatusChangeEvent  -> cuando cambia la calidad ed una build, ojo, sólo la calidad, que cambiamos nosotros manualmente, digamos que el nombre del evento no está muy bien escogido

· BuildCompletionEvent  -> cuando se completa una build (si, tengo que revisar las diferencias con el otro)

CSS

· ProjectCreatedEvent -> se lanza cuando se termina de crear un Team Project

· ProjectDeletedEvent -> cuando nos cepillamos un Team Project 🙂

GSS/Authorization/CSS

· DataChangedEvent -> este es un nuevo tipo de evento génerico que se lanza cuando se cambian permisos (GSS), algo de estructura (areas, iteraciones, …) . PEro bueno este es nuevo y tengo que revisarlo bien.

o Type: STRUCTURE – sequence id for Services/v1.0/CommonStructureService.asmx?op=GetChangedNodes

o Type: SECURITY – sequence id for Services/v1.0/AuthorizationService.asmx?op=GetChangedAccessControlEntries

o Type: IDENTITY – sequence id for Services/v2.0/GroupSecurityService2.asmx?op=GetIdentityChanges or Services/v1.0/GroupSecurityService.asmx?op=GetChangedIdentities

Obsoleted… -> estos son los que NO deberíamos de usar

· BranchMovedEvent – Fired, but also signaled with new DataChangedEvent of type STRUCTURE

· NodeCreatedEvent – Fired, but also signaled with new DataChangedEvent of type STRUCTURE

· NodeRenamedEvent – Fired, but also signaled with new DataChangedEvent of type STRUCTURE

· NodesDeletedEvent – Fired, but also signaled with new DataChangedEvent of type STRUCTURE

· MembershipChangedEvent – Obsolete; DataChangedEvent of type IDENTITY

· IdentityDeletedEvent – Obsolete; DataChangedEvent of type IDENTITY

· IdentityCreatedEvent – Obsolete; DataChangedEvent of type IDENTITY

· IdentityChangedEvent – Obsolete; DataChangedEvent of type IDENTITY

· CommonStructureChangedEvent – Obsoleted… DataChangedEvent of type STRUCTURE

· AclChangedEvent – Obsolete; DataChangedEvent of type SECURITY

En fin, según vaya probando cositas nuevas os iré diciendo 🙂

Test Driven Development, ¿por qué hacer las pruebas antes?

Lo primero, bueno, hace mucho que no escribía, y sí, se que eso es un error a la hora de mantener un blog, pero lo cierto es que entre unas cosas y otras, andaba liado, y sin muchas ganas de escribir, pero bueno, cojo el toro por los cuernos y vuelvo a la carga.

Ayer, con mis amigos Rodrigo Corral, Bruno Capuano, y Unai Zorrilla (O Bruxo Mobile El follonero), surgió una interesante cuestión acerca del TDD, y es, la siempre puntillosa cuestión de hacer las pruebas unitarias antes siguiendo TDD al pie de a letra o después del código, que se saldría en parte de la definición de TDD.

La propia definición específica de TDD, dice que las pruebas se han de escribir siempre antes que el código, cosa que a veces es difícil de hacer entender y explicar a gente “novel” en el tema del TDD.

Si bien es cierto que en algunos sitios si que he visto gente que dice que a pesar de hacer TDD, hacen las pruebas después, y además Rodrigo ayer, nos comentó que el tenía una referencia de uno de los “grandes” que da dos aproximaciones “Test at first” (test al principio) y “Test at last” (test al final).

Tampoco escribo este post para que el follonero Unai, rodrigo, Bruno, et al. nos metamos de nuevo en una discusión jeje, sólo pretendo exponer mis ventajas, y si digo “mis”, ya que estoy hablando desde mi punto de vista subjetivo (como veis hablaré siempre en primera persona), de como me ayuda el tema de hacer la prueba al principio:

  1. Las pruebas me dan la funcionalidad, si, si empiezo diseñando la prueba, se me hace más claro que tiene que hacer exactamente el método, con lo cual, me disperso menos a la hora de la realización del método, y por tanto, menos dispersión == menos fallos.
  2. Diseño, al hilo con lo anterior, la prueba me da el diseño del método, que necesito de entrada, que voy a obtener de salida, y que tiene que pasar entre medias, esto es muy parecido a la anterior, si, pero aquí ya bajo de nivel a la parte más puramente técnica.
  3. K.I.S.S., keep it simple stupid, yo soy de los que siempre empiezan a pensar “¿y si añado este if aquí y este for aquí?”, con esto consigo que el código que haga, sea totalmente dirigido a solucionar la prueba, ni más ni menos, para futuras situaciones, casuísticas, tendré más pruebas.
  4. Cobertura de código, esto es básico, si hago todo los puntos anteriores, consigo una mayor cobertura de código.

Bueno, esta es mi pequeña aportación a porque lo hago así, además, con Visual Studio 2008 (¡¡¡¡venid al lanzamiento!!!!) todos sabemos que tenemos la posibilidad de crear el método y luego darle al botón de crear pruebas unitarias, lo cual es muy tentador, pero yo os hago la propuesta inversa, cread la prueba, y hacer la llamada al método fantasma con los parámetros (tanto de entrada como de salida) necesarios, y luego, una vez terminada de escribir la prueba, ejecutarla y recibir el puntito rojo, sobre esa línea de código de la llamada al método fantasma pulsad (con los settings de VS C#) Alt+Shift+F10, y milagro, os sale esto:

Untitled-2

Vaya, con esto, podemos generar la definición del método en la clase adecuada, y favoreciendo el TDD.

Por supuesto, y aunque yo me declare a favor de hacer la prueba siempre antes, es una opinión basada en mi propia experiencia, y aquí está el punto clave, nuestra experiencia, pero como siempre, aconsejo que empezemos (siempre que no tengamos experiencia previa) basándonos en el conocimiento de los que nos han precedido, y en este caso yo apostaría por el mantra del TDD: red, green, refactor.

PD: Unai, jeje no me odies por lo de el follonero, y de veras, fue muy divertido, y gracias por el feedback 🙂

PDII: Vale Rodrigo, me he puesto de parte de Unai, pero no me pegues muy fuerte, que eres mucho más grande que yo 🙂

TFS sidekicks 2.0

No se si muchos conocéis los Team Foundation Server sidekicks de Attrice (dónde está involucrado Eugene Zakhareyev MVP de Team System).

Estos sidekicks, son pequeñas herramientas (aunque es un único instalable), que haciendo uso del modelo de extensibilidad de TFS y de VSIP, nos añaden una interfaz gráfica para poder hacer ciertas tareas administrativas que no están disponibles por defecto más que por línea de comandos por modelo de objetos.

La verdad es que si echáis un vistazo al listado de utilidades que incluyen, esi mpresionante el trabajo que han hecho: http://www.attrice.info/cm/tfs/index.htm

Además acaban de sacar la versión 2.0, que está preparada para TFS 2008, os recomiendo que os la descarguéis y la probéis porque realmente merece la pena.