Acabo de terminar de leer este libro de Sam Guckenheimer, otro compañero de geeks.ms, Rodrigo Corral, ya habló de este libro, y ahora me toca a mí, lo compré ya que otro MVP de Team system habló de el en el TechEd, y me pareció interesante, si ya ha pasado mucho tiempo, pero hasta ahora no he podido leerlo, ya que he estado ocupado sacándome el carnet de moto
El libro en general se hace bastante sencillo de leer, y eso me ha gustado, ya que es un libro perfecto para la gente que está empezando a gestionar o a trabajar en proyectos con Team System, y habla de cómo usar Team System en los proyectos de un modo muy sencillo, quizá se echa en falta algo más de profundidad en ciertos temas, pero como el propio autor dice en las conclusiones, pretende ser un libro introductorio.
Todo el libro lo centra desde la perspectiva de la gestión de los proyectos desde la perspectiva de «value-up», que, resumiendo bastante, ya que ocupa dos capítulos del libro en detallarla, esto es, trabajar siempre desde la perspectiva de construir la solución iterativamente, centrándonos en aportar siempre valor al cliente, y tomando los cambios como oportunidades de incrementar ese valor, adaptándonos a ellos.
Casi todo el libro se centra en metodologías ágiles de gestión, pero también hace bastantes apuntes acerca de cómo utilizar Team System en proyectos con CMMI, que requieren más datos para ser auditados a posteriori.
Otro punto interesante del libro es la diferenciación que hace siempre, entre la utilización de métricas de modo descriptivo contra las métricas usadas de modo prescriptivo, teniendo que tener mucho cuidado con estas últimas, ya que se pueden volver fácilmente en contra del proyecto. Esto lo podemos ver a lo largo de todo el capítulo de gestión de proyectos, así como el capítulo de «troubleshooting» de proyectos.
También dedica capítulos acerca del desarrollo, el testing y la gestión de bugs que se puede hacer en Team System, como son las Team Builds, la integración contínua, la gestión de bugs con work items, y que son «armas» muy valiosas para después poder afinar en la gestión del proyecto, usando los datos proporcionados por estas herramientas en los informes de Team System, todo este proceso de descubrimiento de los puntos «débiles» del proyecto, y de cómo solucionarlos, los da en el capítulo 9, el de «troubleshooting» de un proyecto, este capítulo, a pesar de no entrar en mucha profundidad, es bastante interesante, ya que aquí podemos ver algunos de los típicos problemas que se dan en los proyectos, como detectarlos con Team system, y que posibles soluciones se le dan, en definitiva un capítulo bastante recomendable.
Y ya por último, me gustaría comentar el capítulo acerca de la arquitectura, y que nos explica como debemos empezar a definir una arquitectura, para hacerla lo suficientemente flexible a la hora de los cambios, esto es bastante importante a la hora de gestionar un proyecto «ágil» en el que se promuevan los cambios, y es un punto en en el que no siempre se acierta, creando a veces arquitecturas muy rigídas y que luego nos dificultan el cambio.
Por último, igual que Rodrigo, también es interesante el capítulo de gestión de los requerimientos y las estimaciones de proyecto y de las iteraciones, aunque sea bastante por encima, da una visión de cómo se deben gestionar estos elementos, que son la base de los proyectos (recordemos que lo más importante es dar soluciones que aporten valor a los requerimientos del cliente).
En definitiva, y como decía al principio, os recomiendo que leáis este libro todos aquellos que estéis interesados en metodologías de gestión de proyectos y/o estéis involucrados en un proyecto con Team System.