Democracia y desarrollo de software

Discutía el otro día con un amigo sobre los valores democráticos (separación de poderes, libertad de expresión, el concepto de ciudadanía y las elecciones son algunos de ellos). Sin duda los valores democráticos son buenos en esencia y están universalmente aceptados en los países democráticos con pequeñas variaciones. Pero la discusión (más bien el intercambio de ideas) no se planteaba en términos políticos, si no en términos de gestión de proyectos de software. En concreto nos planteábamos si ¿Son los valores democráticos trasladables a la gestión de un proyecto de software? La verdad es que no llegamos a ninguna conclusión totalmente clara, pero si surgieron ideas que considero interesantes y que voy a compartir con vosotros.

La separación de poderes es el concepto de establecer ámbitos claros de actuación, que no se solapan entre sí, con autoridades claras que actúan con autonomía e independencia. Sobre la separación de poderes el principal problema que se plantea es definir el poder en los proyectos de software. Yo creo que una definición útil puede ser: "la capacidad para inducir cambios en el comportamiento de otros miembros del equipo o en el devenir del proyecto". Es curioso que los temas relativos al poder aparezcan a menudo cuando se trata con proyectos que están en problemas, sin embargo no conozco ninguna metodología que aborde este problema de manera clara. Solo las metodologías ágiles entran en el tema, de manera lateral, tratando de establecer un equipo de iguales, donde el poder se diluye, no esta concentrado en ninguno de los miembros del equipo. Scrum hace especial hincapié en este aspecto, haciendo al equipo de desarrollo todo poderoso en lo relativo a completar un sprint. Partiendo de la base de que todos los miembros del equipo van a usar el poder para favorecer el curso del proyecto, es fácil llegar a la conclusión de que cuanto más distribuido este, más gente podrá aportar sus capacidades para llevar el proyecto a buen puerto. Esto esta muy bien como principio y me parece una buena practica, que funciona muy bien en equipos que han demostrado su capacidad para trabajar juntos, es el equivalente a la descentralización. Pero creo que la máxima debe ser que el jefe de proyecto es quien debe detentar todo el poder en lo relativo a la gestión del proyecto y tiene que tener la capacidad para distribuir este poder entre los miembros del equipo y recuperarlo cuando necesite realizar cambios de rumbo radicales y forzados (lo que en principio solo seria necesario si el proyecto se encuentra en graves problemas). La capacidad de que ciertos miembros del proyecto puedan reclamar todo el poder en momentos críticos es imprescindible, a mi modo de ver, puesto que hay ocasiones en que es necesario tomar decisiones claras sabiendo que si te equivocas solo tu, como jefe de proyecto, serás el responsable para bien o para mal.

Entrando a fondo, en el tema de la separación de poderes, es evidente que existen diferentes ámbitos de poder, ámbitos de poder que durante el desarrollo normal de un proyecto deben estar separados. En esencia es sano que haya autoridades claras en las diferentes aspectos del proyecto, es una cuestión de simple economía de recursos, es más económico tener un responsable de, digamos, la arquitectura del acceso a datos que permitir que todos los arquitectos de tu proyecto tenga algo que decir sobre el acceso a datos. También se derivan ventajas de la especialización. Claro que eso no quiere decir que los proyectos de software deban renunciar a los órganos de control con los que cuenta la democracia, en los proyectos el principal órgano de control con el que contamos es las revisiones. Todo debe ser revisado, por excelente que sea nuestro arquitecto encargado del acceso a datos, se puede equivocar. Ojo, un error habitual es sustituir las revisiones, la especialización y la autoridad por el diseño por comité, antipatrón lo suficientemente descrito en la literatura sobre gestión de proyectos.

Otro tema clave en democracia, del que a menudo se habla en la gestión de proyectos es la ciudadanía. Entendamos la ciudadanía como el "sentirse parte del proyecto". Es un valor que debemos promover en los proyectos, MSF 4.0 lo incorpora de manera explicita a los “mindset”, aquellos principios que deben guiar el desarrollo. Todos los participantes deben sentir que son necesarios en el proyecto, que sus aportaciones son valoradas. El concepto de ciudadanía es un reto para los proyectos gestionados de manera autoritaria, porque son los ciudadanos los que reparten la autoridad, no hay castas, no hay jerarquías naturales. En esencia, en democracia, todos los ciudadanos valen lo mismo, no son más valiosos unos que otros. Esto es difícil de llevar a cabo en los proyectos de software gestionados por jefes de proyecto rígidos. Es la cuestión habitual que se plantea cuando tratamos responder a la cuestión ¿Qué es más valioso para un proyecto un analista o un programador? En España, y atendiendo al sueldo la respuesta esta clara. Pero que la respuesta este clara no quiere decir que sea correcta. Yo creo que la respuesta correcta es que es más valioso quien mejor hace su trabajo, sea cual sea este dentro del proyecto. Esto que parece una obviedad no se tiene en cuenta a menudo en los proyectos.

Promover la ciudadanía en los proyectos supone sin duda desde el punto de vista del jefe de proyecto, perder control. Esta perdida de control, se deriva de que si todos los participantes en el proyecto lo sienten como suyo, todos quieren tener capacidad para tratar de influir en la marcha de "su" proyecto. Nosotros debemos como jefes de proyecto debemos articular los mecanismos necesarios para que la gente pueda influir en el devenir del proyecto de una manera en la que esa participación sirva para favorecer el proyecto. El trabajo principal del jefe de proyecto debe ser lograr que la gente pueda dar lo mejor de si mismos. La motivación es el principal combustible de la productividad, que mejor manera de lograr equipos motivados que el que se sientan parte del proyecto, sin duda es el principal factor por el que los proyectos GPL triunfan, porque todos son parte del proyecto.

La única manera en la que los "ciudadanos" de un proyecto pueden llegar a sentirse como tales, es si se dan las condiciones necesarias para que puedan participar con libertad en el mismo y aportar todo lo que puedan aportar. Para ello es condición necesaria la libertad de expresión. Cada vez más, la herramientas de gestión de proyecto, incluyen foros o lugares donde los "ciudadanos" del proyecto de manera anónima o no (siempre a su elección) pueden expresar sus opiniones. La necesidad de un canal anónimo de comunicación es algo que muchos de los grandes autores sobre gestión de proyectos han considerado clave. Sin duda como jefes de proyecto debemos tener todo el interés del mundo en oír las malas noticias cuanto antes, y muchas veces esto no va a ocurrir si no tenemos un canal anónimo de comunicación. Los integrantes de un equipo de desarrollo siempre temen dar malas noticias, retrasan este momento, principalmente por el temor a que "se culpe al mensajero". El canal anónimo de comunicación en los proyectos es el equivalente a la libertad de expresión en democracia, para bien y para mal. No hay mejor manera de que un jefe de proyecto este totalmente informado de que ocurre en su proyecto que un foro anónimo sobre el mismo. Pero ojo, al igual que en democracia, hemos de ser tremendamente cuidadosos para no caer en la tentación de cambiar gestión, por populismo. No debemos sobre reaccionar a las noticias que recibamos por canales anónimos, sino investigar si esas noticias se sostienen en hechos, en métricas y si este es el caso, actuar.

Pero si algo caracteriza a la democracia es la celebración de elecciones. Los ciudadanos votan. Evidentemente esto no es trasladable directamente a la gestión de proyectos. No podemos organizar elecciones para elegir al jefe de proyecto, a los analistas etc… El reparto de poder, del que hablaba antes, no se puede hacer en base a votaciones. Aunque hay que reconocer que seria un ejercicio interesante. Dicho esto, es evidente que los "ciudadanos" de nuestros proyectos votan. No de una manera directa, traducible en porcentajes, pero si de una manera clara. ¿En que desarrolladores del equipo confían más los otros desarrolladores? ¿Cuáles reciben más consultas? ¿Cuáles son más admirados por el resto de miembros del equipo? ¿Cuales son los portavoces de el resto del equipo cuando hay problemas?. Evidentemente los desarrolladores que dan respuesta a estas preguntas han sido claramente votados por el resto del equipo, y sin duda como jefes de proyecto, tendremos mucho más apoyo del resto del equipo si cuando "repartimos poder" lo hacemos sobre estas personas. Básicamente el principio es el mismo que en democracia, dar poder a quien tiene autoridad. Esto es importante por que las decisiones que se perciben como injustas, son dañinas para la motivación del equipo, y eso ya sabemos mina la productividad.

Como conclusión, si es que hay conclusión posible, creo que la democracia es en cierto modo trasladable a la gestión de proyectos y que es un ejercicio interesante y sano. La clave de quienes gestionan la democracia, es sin duda, crear un entorno donde la gente pueda vivir mejor, como jefes de proyecto la clave es crear un entorno donde la gente trabaje mejor, si la democracia ayuda a lo primero quizás pueda ayudar también a lo segundo.

Espero que este post, suscite cierto debate.

Nota: Este post va sobre gestión de proyectos, no sobre política, por lo tanto cualquier comentario al mismo con tintes única o marcadamente políticos serán eliminados.

Estadísticas del blog con Google Analytics y Community Server 2.1

En Geeks.ms hace un tiempo que estamos recolectando estadísticas sobre las visitas que recibimos con Google Analytics. Estas estadísticas son sobre todo el sitio. Con la migración que hemos efectuado hace unos dias a Community Server 2.1, se habre la puerta a que cada uno de los bloggers de Geeks.ms configuren sus propias estadísticas, algo que algunos ya nos habeís pedido. Voy a comentar como hacerlo usando Google Analytics como proveedor de estadísticas.

El primer paso es conseguir una cuenta de Google Analytics. Para ello tendreís que esperar algún tiempo, puesto que se basa en invitaciones. Una vez conseguida la cuenta, tendreís que configurar un perfil para las estadisticas de vuestro blog, lo único que necesitaís es conocer su url. Podeís tener hasta cuatro perfiles asociados a diferentes urls en cada cuenta de Google Analytics. El resultado de configurar una cuenta es un código javascript que debemos poner en cada una de las páginas que queramos agregar a esas estadísticas:

El problema es ¿cómo conseguimos que todas la paginas de nuestro blog emitan este código javascript (o cualquier otro)?. Hasta la versión 2.1 de Community Server esto no era posible, pero ahora sí. Tenemos que ir a la página e administración de nuestro blog, seleccionar Global Settings->Title, Description, and News, y en el textbox Raw Header escribir el código que queremos que se emita junto con nuestro blog. Evidentemente esto se puede usar para emitir cualquier código javascript, incluso uno dañino, así que como administrador de Geeks.ms advierto de que cualquiera que haga un uso dañino de esta posibilidad será dado de baja como blogger de Geeks.ms.

Espero que disfruteís de vuestras estadísticas.

Port 25: El escaparate del laboratorio de código abierto de Microsoft

Ya se sabía desde hace un tiempo que Microsoft estaba 'jugando' con software de fuente abierta con el proposito de aprender, comparar y mejorar la integración de sus productos con este software.

Recientemente, ese laboratorio ha ido un punto más allá en su comunicación con el público, en forma de weblog. Port 25 es el nombre que ha recibido este nuevo servicio de la casa de Redmond, y está operado por la gente del Microsoft Open Source Software Lab.

Este portal está orientado a enlazar los contenidos de los blogs de miembros relevantes en dicho observatorio, así como noticias que estén relacionadas con la actividad del mismo. Una buena referencia para estar al día de lo que opinan en Microsoft sobre el código abierto.

Autenticación contra un servidor Team Foundation Server

En alguno de los ejemplos que he publicado anteriormente sobre como trabajar con el modelo de objetos de Team Foundation Server, vemos que siempre el primer paso es conectarse con el servidor de Team Foundation Server. En principio este no es un paso muy complicado, pero tenemos que lidiar con la obtención de credenciales de usuario para realizar la conexión. Obtener las credenciales de un usuario es algo que todas las aplicaciones hacen, pero que en pocas ocasiones se realiza con la seguridad que requiere el tema. Al fin y al cabo estamos pidiendo a alguien sus credenciales y estas podrían servir para comprometerle o incluso realizar acciones ilegales en su nombre.


En el API de Team Foundation, nos han facilitado la vida, y es realmente simple mostrar el cuadro de dialogo para autenticarnos contra un servidor Team Foundation:


//Creamos un proveedor de credenciales
ICredentialsProvider provider = new UICredentialsProvider();
TeamFoundationServer tfs =
 TeamFoundationServerFactory.GetServer(“server_name”, provider);
try
{
  /*
  Intentamos autenticarnos.
  Podemos usar los métodos Authenticate o EnsureAuthenticated. 
  Authenticate siempre va a llamar al servidor, con independencia de que el usuario ya se encuentra autenticado. EnsureAuthenticated, nos ahorra la llamada al servidor si el usuario ya se encuentra  autenticado, por ejemplo desde Visual Studio por lo que no penaliza el rendimiento si se  llama varias veces.
  */
  tfs.EnsureAuthenticated();
}
catch (UnauthorizedException)
{
  //El usuario no esta autenticado.
}


Esto funciona perfectamente en aplicaciones Windows, para ver como autenticarse desde el propio servidor o desde una aplicación de consola, mirad el documento: Team Foundation Server Object Model.doc, del SDK de Visual Studio 2005. Aunque el proceso es muy similar.


Hasta aquí lo que ocurre en Team Foundation, en otro post os hablaré de cómo implementar la recogida de credenciales de manera segura en nuestras propias aplicaciones.

Hay que pagar por la Beta 2 de Office 2007 ¿y qué?

Leo en el blog del amigo Cristian que tendremos que pagar por la beta 2 de Office 2007, y entre los comentarios, como no, hay uno que expone lo absurdo que le parece que Microsoft nos cobre por usar un producto Beta cuando estamos haciendo un trabajo para ellos: descubrir bugs.

Bueno, la experiencia me dice, depués de participar en unas cuantas Betas como MVP, que el ratio descargas / bugs reportados es muy bajo, infimo diría yo. Luego el argumento de que las Betas tienen el proposito de que los usuarios encontremos bugs, se cae por su propio peso.

Seamos francos, ¿cuantos de los que hemos descargado alguna Beta de Microsoft hemos llegado a reportar tan solo un bug?. Seguro que una minoria de los que leen este post podrán alzar su mano.

La autentica verdad es que a pesar de lo que argumenta la gente, que siempre esta dispuesta a subirse al carro de criticar a Microsoft (a todos nos encanta criticar al poderoso, a mi tambien, pero cuando hay motivos), no solemos descargar las Betas para hacer testing. No seamos hipócritas, los motivos por los que descargamos las Betas son otros, por citar algunos, que se me ocurren a bote pronto:

La posibilidad de formarnos en futuras tecnologías.
La posiblidad de utilizar productos casi acabados y punteros a un precio irrisorio.
La necesidad de adaptar nuestros desarrollos y productos, para asegurar su perfecto funcionamiento con futuras versiones de los productos de Microsoft.
La posibilidad de acceder a funcionalidades que solucionan problemas actuales antes de que el producto sea RTM.

¿Realmente menos de 2€ nos van quitar la intención?

Otro tema, es que la justificación de Microsoft, de los costes de gestión de las descargas y el coste del ancho de banda, sea de fundamento. ¿Es qué en Microsoft nadie conoce las redes peer to peer y bittorrent?.

He leído: Agile Project Management with Scrum de Ken Schwaber

He leido gran cantidad de libros sobre metodologías de desarrollo de software. Ninguno de ellos, de menos de 300 páginas. Sin embargo en Agile Project Management with Scrum de Ken Schwaber (uno de los padres de esta original metodología que crece como la espuma) es capaz de introducirnos en en la gestión de proyectos con Scrum, en apenas 150 páginas.

Muchos de esos libros, eran interesantes, pero no amenos y faciles de leer como este. Ken Schawber a base de contarnos historias reales, vividas en sus años de consultoría sobre Scrum, hace que de manera sencilla y amena, vayamos comprendiendo las peculiaridades de Scrum y como adaptar Scrum a los más diversos escenarios.

Además, si no estamos especialmente interesados en Scrum aún así es un libro muy valioso, pues de manera implicita en las historias, presenta todo un arsenal de tácticas sobre como actuar con el mayor sentido común cuando trabajamos como consultores en lo relativo a gestión de proyecto. Explica como vencer reticencias, constumbres, culturas, y creencias prestablecidas cuando tratamos de mejorar como una empresa se enfrenta al desarrollo de software.

En el punto flojo, decir que solo presenta aquellas historias que han llegado a un final feliz y en las que Scrum triunfa explendorosamente, como no podía ser de otro modo. Además algunas de las historias carecen de detalles, supongo que con el afán de no alargarlas demasiado, que hubiesen sido de gran interés. He incluso alguna de las historias, no es del todo creible, aunque en cualquier caso, cumplen su cometido de explicarnos Scrum a base de ejemplos, que en definitiva es de lo que va este libro.

Resumiendo, el libro merece la pena, y se lee en un 'volao'.

¡Ojo!: Vuestro Team Foundation Server puede estar a punto de caducar

Si fuisteis tempraneros instalando la Release Candidate de Team Foundation Server o la versión Trial, que sepaís que esta a punto de caducar. Si es el caso vereís el mensaje:


«TF30072: The Team Foundation Server trial period has expired or its license is otherwise invalid. Install a licensed edition of Team Foundation Server to continue.»


Si estaís a la espera de que os llegue una licencia válida, y teneís instalada la Release Candidate, una posibilidad que os dará algo de tiempo de maniobra es instalar la Trial sobre la Release Candidate.


Aunque parezca mentira, ya han pasado seis meses seis desde que se libero la versión definitiva de Team Foundation Server.

Instalar Sharpoint Portal Server con SQL Server 2005

Los primeros aventureros que nos atervimos a instalar SPS sobre SQL Server 2005 lo hicimos a base de leer blogs, foros y cruzar los dedos. Pues bueno para que aquellos que lo vayaís a intentar en el futuro, que sepaís que por fin Microsoft ha liberado unas ‘instrucciones oficiales’ sobre como realizar el proceso.


Resumiendo: Hay que instalar el Service Pack 2 de Sharepoint Portal Server y el de Windows Sharepoint Services, antes de configurar el portal.


Si instaláis sobre Windows 2003 R2, que sepáis que ya está incluido Windows Sharepoint Services SP2 como parte del sistema operativo, y que la podeís añadir desde el panel de instalación y gestión de componentes del sistema operativo.

Scrum + Team System: Una mezcla perfecta

Estoy profundizando en Scrum. Siempre me ha llamado la atención esta metodología ágil, y ya hace un tiempo estoy metido bastante de cabeza en ella. Y la verdad es cuanto más conozco, más me gusta.

Scrum es, según el Process Template de Cochango 'un proceso ágil y ligero que puede ser utilizado para gestioner y controlar el desarrollo de software y producto usando practicas iterativas e incrementales. Envuelve prácticas de ingeniería existentes incluyendo Extreme Programming y RUP, Scrum proporciona las ventajas del desarrollo ágil junto a las ventajas de una implementación simple. Scrum incrementa significativamente la productividad y reduce el tiempo de retorno de la inversión a la vez que facilita el desarrollo adaptativo y empírico de sistemas'

Hoy he instalado la implementación de Scrum que existe para Team System, de cuya existencia ya hable anteriormente y que es totalmente gratuita. Me ha parecido, en las 2 horas que he trasteado con ella, excepcionalmente bien acabada. Supongo que para desarrollarla se ha utilizado Scrum como metodología, así que queda pantente que se pueden hacer productos de calidad con Scrum y que se puede hacer rápido, pues es una de las primeras implementaciones de una metodología que existe para Team System desarrollada por terceros y realmente madura.

Llama la atención que la implementación del Process Guidance, sea una referencia a un sitio web, y no una serie de páginas locales, como es habitual. Ventaja, ellos mantienen el Process Guidance siempre actualizado, la desventaja es que no puedes adaptarlo a tu gusto.

Os dejo unos pantallazos, para que os hagaís idea de lo que ofrece el producto.

Selección de la plantilla de proceso:

Árbol del proyecto:

Portal del  proyecto:

Guia de proceso: