Nuevos posters de referencia rápida de Team System

Hola, entre rato y rato que me deja libre el trabajo y aledaños, he acabado de traducir unos cuantos pósters de referencia rápida de Team System, aquí tenéis el listado (corresponde al nombre de fichero):

  • 0202 Microsoft Team System – Spanish
  • 0202 Microsoft Team System Branching – Spanish
  • 0202 Microsoft Team System Planning – Spanish
  • 0202 Microsoft Team System Project Source Migration – Spanish
  • 0202 Microsoft Team System Single Server Deployment – Spanish
  • 0202 Microsoft Team System Source Control – Spanish
  • 0202 Microsoft Team System Source Structure – Spanish
  • 0202 Microsoft Team System Workspaces – Spanish

Y los podéis descargar de: http://www.drp.co.za

Espero que os gusten y os parezcan interesantes 🙂

Preview de Power Tool para TFS 2008: herramienta de system tray para resultados de builds

Pues nada, aquí os pongo para que le deis un vistazo al blog de Buck Hodges que anuncia una nueva Power Tool, y publica la primera versión. Es una herramienta que a mi me gustaba bastante con CruiseControl.NET y que era el CCTray for CruiseControl, que nos avisa, desde el system tray, de los resultados de las compilaciones,  ya os contaré cuando la instale y la pruebe.

OJO, sólo funciona con TFS 2008 y Team Explorer 2008 Beta 2.

Aquí va:

http://blogs.msdn.com/buckh/archive/2007/09/21/build-notification-tray-applet-power-tool-for-tfs-2008.aspx

Compilando proyectos de bases de datos con Team Build (2005 y 2008)

Aunque sea hacer de “repetidor”, y aunque supongo que muchos estaréis subscritos a este blog, para los que no, me permito poner aquí un enlace a un artículo de Jon Liperi (tester de Team Build) que ha publicado Buck Hodges en su blog, y que trata a cerca de los problemas (y sus soluciones) más comunes a la hora de compilar proyectos de la versión de database professionals con Team Build, realmente me ha parecido de gran ayuda, ya que algunos de estos problemas los he tenido yo mismo y no había un sitio donde buscar la soluciones (sólo en gugle) concretas, así que aquí va:

VSTS 2005 and 2008: Building Database Projects with Team Build

Proceso y buenas prácticas

Leo hoy un artículo de Roy Osherove acerca de la relación entre proceso y las buenas prácticas a nivel técnico en el desarrollo, que es algo que a veces se deja de lado, y quería comentarlo por aquí, y añadir también ciertos comentarios en la parte de proceso.

Lo primero como ha hecho el propio Roy, empezemos definiendo el proceso, como aquella parte de la metodología que se encarga de todo lo que es la gestión de requisitos, iteraciones, relación con el cliente, lo que se podría decir, la parte no técnica, esta parte, y aquí al igual que otros, como Roy, Rodrigo Corral y más gente de por aquí, yo creo que Scrum es una metodología perfecta para proyectos ágiles, es muy ligera, y una vez que conoces los principales conceptos es “sencilla” de seguir y aplicar.

También es cierto que existen otros tipos de proyectos, en los que tenemos que adecuarnos a otras metodologías más “formales” como CMMI, esto es necesario cuando o bien nos obligan por requerimientos del cliente, o bien lo tenemos que realizar así por requisitos de auditorías en las que nos exigan un determinado nivel de auditabilidad, que con las directrices de Scrum no se llega. De todos modos, las prácticas de Scrum, aunque sigamos otra metodología, nos van a ser de gran utilidad, como las reuniones diarias (Scrum), el modo de gestionar los requisitos, los sprint, etc., si bien, tendremos que apoyarnos en generar mayor nivel de documentación (generalmente) ya que estas metodologías más formales nos lo exigen. Por tanto, y aunque estemos en proyectos “formales” no olvidemos nunca todas estas prácticas que tenemos a nuestra disposición, y que nos van a facilitar la tarea de gestión.

A otro nivel tenemos todas las buenas prácticas del desarrollo, si hablamos de Scrum, no hace referencia a ninguna práctica como pueda ser la integración contínua, Test Development Driven, y otras buenas prácticas, esto es porque en este caso, Scrum es una metodología pura de gestión, pero esto no quiere decir que tengamos que abandonar estas prácticas, al revés, debemos de tenerlas siempre presentes en nuestro desarrollo, estas son las que nos van a permitir poder gestionar los cambios de requerimientos, defectos, etc. a nivel técnico, estas prácticas nos van a llevar a mejorar la calidad de nuestro código, así como hacernos la vida más sencilla (y si recordad proyectos que no tengan pruebas unitarias, a la hora de cambiar una funcionalidad).

Por supuesto, todas estas buenas prácticas TAMBIÉN son de gran ayuda en todo tipo de proyectos formales, de vez en cuando se pueden ver proyectos, que por seguir metodologías formales, dejan de lado prácticas consideradas como de meotodologías ágiles, cuando realmente son simple y llanamente buenas prácticas de desarrollo.

Un poco en resumen, despues de este pequeño ladrillo, la conclusión a la que quiero llegar, es que independientemente del tipo de metodología de proceso que estemos usando recordemos que tenemos prácticas de otras metodologías que nos pueden complementar, y ayudarnos en los proyectos. Y por supuesto, e independiemente del tipo de proyecto, recordad, prácticas como integración contínua, pruebas unitarias, etc. son BUENAS PRÁCTICAS de desarrollo., y como tales, tenemos que aprender a integrarlas en el día a día del desarrollo, independientemente del tipo de metodología de gestión.