La primera decisión

La primera decisión que debemos tomar cuando implantamos Team System en un proyecto u organización es ¿MSF CMMI o MSF Agile?, o lo que es lo mismo madurez o agilidad. Existe una tercera via, utilizar nuestra propia metodologia, pero para que esto sea viable, debe existir una metodologia que podamos llevar a Team System y eso rara vez ocurre. Y me refiero a una escrita blanco sobre negro, lo que ocurre menos aún.


 


Y una cuarta, utilizar alguna de la otras métodologias que existen para Tema System y sobre las que ya hable anteriormente.


 


Cuando planteo esta cuestión en los proyectos en los que participo, sea como parte activa de los mismos, como formador o como consultor, la primera respuesta es la misma siempre, agilidad.


 


Sin duda mucha gente no conoce a fondo las diferencias entre los dos enfoques y elige agilidad guiada por la fama de CMMI de ser excesivamente burocrático. El razonamiento que lleva a esta elección es, “lo ultimo que necesito es burocracia, ya tengo bastante trabajo”. Además, ¿A quien no le tienta la agilidad? Es una característica positiva, todos preferimos ser ágiles, tener un coche ágil, una hipoteca ágil, un proyecto ágil…


 


Con posterioridad, hasta ahora en un gran porcentaje de casos, se ve que la respuesta primera es errónea. Tratare de explicar porque.


 


CMMI no es burocrática, aunque muchas de sus implementaciones prácticas en empresas si lo son. De hay viene la inmerecida fama CMMI establece una serie de niveles de madurez en el proceso de desarrollo de software, para cada uno de los niveles establece una serie de objetivos a cumplir para


alcanzarlo, pero nada dice de como se cubren esas metas. Antes de Team System, las organizaciones que avanzaban a lo largo del proceso de mejorar la madurez del su actual proceso de desarrollo, solían hacerlo creando una gran cantidad de plantillas de documentos que se debían completar, efectivamente burocracia. Esto ha cambiado radicalmente con Team System, puesto que la herramienta nos ayuda enormemente en el manejo de la información que es necesario recuperar para alcanzar esa madurez, haciendo esa burocracia casi imperceptible.


 


Madurez significa buenas prácticas, y pocas empresas, al menos en nuestro país, llevan a cabo las buenas prácticas mínimas necesarias para llevar a cabo un proceso de desarrollo sano. Además madurez significa ser predecible, y realmente ese es un gran paso en la mayoría de los proyectos. A menudo el único dato fehaciente que se tiene sobre un proyecto es como se llama, cuando empezó y que esta retrasado. Si a apenas sabemos andar, como vamos a intentar correr, como vamos a ser ágiles, si a duras penas estamos dando los primeros pasos en una metodología de desarrollo de software. La agilidad requiere excelencia, repasad el manifiesto ágil. Excelentes gestores que puedan gestionar los individuos y sus relaciones de una manera diferente a la que estamos acostumbrados. Excelentes programadores que logren crear software que continuamente funcione y que sea capaz de absorber cambios. Excelentes clientes, que sean capaces de involucrarse en el proceso de desarrollo. Y no nos engañemos la excelencia no abunda.


 


La gráfica que representa el beneficio de añadir carga metodológica sobre el desarrollo de software muestra un punto a partir del cual la metodología empieza a ser dañina. Muchas implementaciones de CMMI superan este punto pero sin duda la gran mayoría de los proyectos que actualmente se desarrollan en este país se encuentran en un estado en que por mucha metodología que añadamos no vamos a llegar al punto en el que la metodología empieza a ser dañina, a convertirse en burocracia. Además la implementación de CMMI en Team System se ha desarrollado tratando de evitar esto y eso garantiza que no nos pasemos.


 


Con todo esto no quiero decir que la metodologías ágiles no sean útiles. Si tienes un proyecto donde el cliente esta dispuesto a colaborar, el equipo es excelente y trabaja excelentemente junto, los promotores del proyecto prefieren tener exactamente lo que quieren en lugar de tenerlo exactamente cuando quieren o con el presupuesto con el que cuentan y tu organización demostrado madurez en sus anteriores proyectos, no lo dudes, la agilidad es un gran valor.


 


De todos modos, antes aun que la metodología, están las buenas practicas. Si no estas haciendo aquello que siempre has leído, escuchado y sabido que debes hacer, olvídate de metodologías, empieza a hacerlo. Utiliza un gestor de fuentes, una herramienta de gestión de defectos, se capaz de construir e integrar tu software ejecutando un solo comando, escribe pruebas unitarias, realiza pruebas de humo, escribe una especificación por pequeña que sea, gestiona los cambios, involucra al cliente etc… Una vez que hagas todo esto o, al menos, una buena parte, empieza a preocuparte por hacerlo de forma metódica. Resumiendo, pasa el test de Joel y luego preocupate de la metodología.

Dos respuestas para dos preguntas…

Hay dos preguntas que frecuentemente me realizan sobre Team System. La primera, es ¿Qúe aporta Team System a los desarrolladores de Visual C++ nativo?. Esta la recibo a menudo, no en vano soy MVP de C++ y gran parte de mi carrera profesional se ha desarrollado en ese lenguaje y aun conservo muchos contactos de esa epoca.


Aunque conozco lo que aporta Team System a un desarrollado de Visual C++, hasta ahora no tenia una respuesta, clara concisa, organizada y con referencias a este tema, pero gracias a Rob Caron, Content Architect de Team System, a partir de ahora la tengo.


La otra pregunta, que recurrentemente aparece en los cursos que imparto sobre Team System es: ¿Ayuda Team System en la captura de requisitos? 


La respuesta es que la ayuda que ofrece es muy poca y en gran parte depende de lo organizado y hábil que seas utilizando Sharepoint. Basicamente lo único que Team System aporta es que puedes guardar con facilidad tus documentos de requisitos en Sharepoint y crear Work Items que representen los requisitos. Pero, la mejor caracteristica, a mi modo de ver de Team System es que es plenamente extensible, no dudeís en ver el SDK de Visual Studio 2005, hay un montón de documentación sobre el tema. Nada impide construir una solución para el manejo de requisitos sobre Team System,  de hecho Borland lo esta intententando con CaliberRM, a mi modo de ver con escasísimo exito, pero solo he visto betas. Una solución que si me ha parecido bastantante comoda, sobre todo por su integración con Office, es Mindjet Requirements Management. Hechadla un vistazo, podeís descargar un versión de prueba gratuita, aunque exige registro.

Publicado el primer Service Pack de SQL Server 2005

Es lo que muchos administradores estaban esperando para migrar sus instalaciones en versiones anteriores, el Service Pack 1 de Sql Server, ¿a qué esperais para descargarlo?. Esta disponible en varios idiomas.


Hechadle un vistazo al readme para saber las novedades.


Destaca especialmente que ahora los indices unicos no clustered pueden ser creados online.

¿Y si no me sirve MSF?

Cuando creamos un proyecto en Team System la primera decisión que debemos tomar es que metodología utilizar. Team System nos proporciona dos métodologias directamente: una ágil y otra que nos permite cubrir las metas que marca CMMI. Muchas veces estas métodologias serán suficiente para nuestras necesidades sobre todo si estamos en un punto en el que no tenemos establecida ninguna metodología de manera formal.


Siempre existe la posibilidad de desarrollar una plantilla metodológica propia pero, es un trabajo importante que conviene evitar, salvo que sea totalmente indispensable, por eso es importante conocer que tenemos a nuestra disposición varias plantillas de otras metodologías que podemos aplicar a nuestros proyectos:


Scrum for Team System
BSDAgile (eXtreme Programming)
Rational Unified Process (RUP)


Os remito a la Wikipedia para más información sobre Scrum, XP y RUP

La pata de cabra…



No se por que, en los equipos de desarrollo en los que participo, mis dichos y redichos se van quedando. Siempre ha sido así. Algunos no pasan de ser tonterías, pero otros, de diferentes maneras acaban ayudando al desarrollo. La mayoría de la veces simplemente cumplen un cometido de transmitir conocimiento, o crear una especie de tensión (como el dicho que da título a este blog, que como ya conté iniciaba el proceso de realizar una build)


Una de las frases que últimamente se ha popularizado es: “Le voy a dar con la pata de cabra…”. Todos hemos vivido esa situación en la que durante el desarrollo de software nos atascamos y no hay manera de seguir para adelante, de encontrar el error. Habitualmente para salir con el atolladero basta con levantar la cabeza de tu PC, interrumpir a unos de tus industriosos y concentrados compañeros de equipo y que este le eche un vistazo a tu código, para que al poco rato de con la solución al enigma que te tenia ocupado las tres ultimas horas.


El problema de esto es que a nadie le gusta interrumpir a la gente que esta concentrada y los desarrolladores siempre parecemos concentrados, aunque quizás solo estemos leyendo Geeks.ms en ese momento. Pero claro quien tiene el problema no lo sabe, se tienta la ropa antes de preguntar.


En esta situación, es cuando la frase comentada antes se ha vuelto de ayuda, cuando alguien del equipo dice algo como “Solo me falta darle con la pata de cabra…”, aunque sea entre dientes, el resto del equipo, los que no están tan concentrados como parecen (nadie lo esta siempre), oyen esa llamada de auxilio y rápidamente se interesan por el problema de su compañero. Es curioso como algunas cosas que surgen de manera absurda se convierten en útiles.


De toda esta historia yo he extraído la siguiente conclusión: en los equipos de desarrollo es util un mecanismo, cuanto más ágil mejor, para que los miembros “ociosos” del equipo puedan saber que un compañero esta en apuros. Cual sea este mecanismo es irrelevante. Las ventajas con claras, nadie se desespera peleando horas con un problema de minutos, y lo que es mejor, no se molesta a nadie que realmente este en ese momento produciendo al 100%. Es curios como la frase en cuestión no es oída por nadie que este realmente metido en harina.


Otra historia es como se popularizo esta la frase … quizás algún día lo cuente.

Otra joya encontrada… SharePoint Portal Server 2003 Discovery Kit

He encontrado de casualidad una de esas joyas que están ocultas entre la maraña de descargas que Microsoft pone a nuestra diposición, se trata del SharePoint Portal Server 2003 Discovery Kit.


Se trata de una guia completa que explica, en formato hand on lab, como desarrolla una solución empresarial con [SPS]. Empezando por como instalar un servidor con una configuración básica, hasta como monitorizar la actividad del servidor usando Microsoft SQL 2000 Server Report Pack for Microsoft Office SharePoint Portal Server 2003.


Aprovecho para recordar que ya están diponibles los packs de informes para SQL Server 2005. Incluidos los informes para Sharepoint.

VSTS Customization Toolkit

GotDotNet nos proporciona otra utilísima herramienta a la hora de adaptar Team System a nuestras necesidades: VSTS Customization Toolkit


Esta herramienta nos permite modificar los WorkItems de nuestra metodologia y las listas globales. No permite modificar la guia de proceso (Process Guidance).


Esta herramienta puede trabajar directamente sobre un sevidor Team Foundation Server o sobre una plantilla métodologica descargada al disco (aunque este modo tiene algunas pequeñas limitaciones).


Una de sus mejores caracteristicas de esta herramienta es que permite previsualizar como quedarán los formularios de edición de los WorkItems.


Menos mal que existe esta herramienta, no quiero pensar en tener que hacer estas modificaciones a base de tocar un montón de archivos XML.

Microsoft Virtual Server 2005 R2 gratis!!!

Ahora que Microsoft Virtual Server 2005 R2 puede se puede descargar gratuitamente o pedir un CD, ambas opciones requieren registro, muchos vamos a recorrer el camino de la virtualización.


Un problema que encontraremos, yo me le he encontrado, es como migrar nuestra máquinas físicas a máquinas virtuales. En esta labor la herramienta Virtual Server 2005 Migration Toolkit es imprescindible, básicamente, lo que permite es hacer imagenes de maquinas fisicas que podemos luego cargar en Virtual Server.

Reflector y sus amigos…

Que Reflector es una herramienta indispensable para todo desarrollador que quiera ir un poco más alla en la plaforma .Net y comprender como esta funciona es algo que nadie discute.


Si ha esto le añadimos que la herramienta es extensible y que existen numerosos plugins realmente espectaculares y útiles ¿Qué más se puede pedir?. Algunos de ellos son bastante espectaculares, a mi me gusta especialmente Reflector.Graph, si lo usais necesitareis un visor SVG.


Si alguien a estas alturas no conoce Reflector seguro que tampoco conoce a fondo .Net.


Otras herramientas que a mi me resultan de gran utilidad son:


Fiddler, que permite ver el trafico HTTP que genera tu máquina de una manera realmente comoda, ideal para ver que manda Asp.net realmente al navegador.


The Regulator, usar esta herramienta es la única manera que he encontrado de no volverme loco trabajando con expresiones regulares.


Por último, hay dos articulso muy interesantes en MSDN Magazine sobre herramientas de este estilo:


Visual Studio Add-Ins Every Developer Should Download Now
Ten Must-Have Tools Every Developer Should Download Now