Excelentes listas de comprobación para Scrum

A mí me encanta las listas de comprobación. Me parecen un método excelente y ràpido de detectar puntos que exigen nuestra atención. Las listas de comprobación, de manera similar a las lista de riesgos del proyecto, benefician la economía de la gestión de proyectos, ayudandonos a poner nuestros recursos en aquellos puntos que necesitan atención y no desperdiciarlos gestionado cuestiones de relavancia menor.


Además, las listas de comprobación, nos protegen de errores pasados, de tropezar dos veces en la misma piedra. A menudo cometemos el mismo error una y otra vez en la gestión de nuestros proyectos. Si añadimos una entrada en la lista de comprobación que nos obligue a considerar de manera explicita el error anteriormente cometido, es probable, que no lo volvamos a caer en él.


Ya deje anteriormente la lista de comprobación de Project Survial Guide de Steve McConnell traducida al castellano.


Hoy le toca, el turno a una serie de listas de comprobación para Scrum, que nos ofrece en pdf InfoQ. Yo hos he dejado el archivo en mi carpeta de documentos para facilitaros la vida, pues exige registro para su descarga; pero una vez la echeís un vistazo, tal y como piden los autores, os recomiendo que os registreís en el sitio y la descargueís desde allí. Además si os parece lo suficientemente interesante, podeís comprarlo ya impreso.

Migrando a SQL Server 2005

Con la llegada de un Service Pack para SQL Server 2005 se ha cumplido el hito que muchos estaban esperando para comenzar a migrar sus servidores de datos a esta nueva versión de SQL Server. La verdad es que las ventajas de esta nueva versión son infinitas.

En principio, la migración no es un proceso especialmente complejo, ya que Microsoft proporciona muchas herramientas para ayudarnos en este proceso. Pero, cuando se trata de algo tan crítico como migrar un servidor de base de datos, que puede estar dando servicio a muchas aplicaciones críticas para nuestro negocio, debemos ser especialmente cuidadosos.

Microsoft pone a nuestro alcance dos recursos muy interesantes para ayudarnos en esta tarea crítica.

El primero es una herramienta, llamada Microsoft SQL Server 2005 Upgrade Advisor, que analiza instancias de SQL Server 7.0 y 2000 para prepararlas para una actualización a SQL Server 2005. Esta herramienta identifica que características y cambios en la configuración pueden afectar a la actualización y proporciona links a la documentación que describe cada uno de los problemas identificados.

El segundo es una guia técnica, llamada SQL Server 2005 Upgrade Technical Reference Guide, un documento de obligada lectura antes de abordar la actualización de nuestro servidor SQL Server. El documento solo está disponible en inglés, al menos de momento.

Estaré en ExpoQA: Presentación: Integrando la calidad en el ciclo de desarrollo

Estaré este Jueves, 30 de Noviembre, en ExpoQA con una presentación que lleva por título:


Integrando la calidad en el ciclo de desarrollo.
Una de las grandes trabas que los desarrollos de software han sufrido siempre a la hora de lograr calidad ha sido la heterogeneidad de la herramientas empleadas y su escasa integración. Esto además repercute en la gestión del proyecto por la dificultad de recolectar y analizar información fiable sobre como evolucionaba la calidad en nuestro proyecto. Visual Studio Team System nos permite integrar la calidad de manera simple, natural y completa en el ciclo de vida del desarrollo.


ExpoQA «se dirige a profesionales que necesitan mejorar procesos, cumplir plazos cada vez más cortoes e incrementar al calidad de sus productos. Lo hace acercándolos a las tecnologías, servicios y tendencias actuales. Crea un espacio privilegiado en el sector de la Calidad del Software en España, donde los profesionales que buscan soluciones y los proveedores líderes del mercado que las proporcionan intercambian conocimientos y necesidades».


La asistencia es gratuita, así que si estaís interesados podeís inscribiros. Quiza aun no este disponible la entrada para mi presentación, pero espero que lo este en breve. En cualquier caso si quereís inscribiros se que sustituye a una, no se cual, de las que se celebran a las 16:45h.

Iteraciones en Team Foundation Server

Un punto de confusión habitual en las implantaciones de Team Foundation Server son las áreas y las iteraciones. ¿Qué son? ¿Para qué sirven? ¿Cúantas defino? ¿Cuales defino?.


En este primer post voy a abordar las iteraciones y en uno posterior las areas.

MSF define las iteraciones como un periodo fijo de tiempo en el que programar tareas. Una iteración es generalmente un periodo fijo de entre dos y seis semanas. Las iteraciones generalmente son numeradas consecutivamente y siguen una a otra de manera continua.

A parte de esta definición, que puede ser más o menos acertada, las iteraciones son siempre puntos de control, aprendizaje y planificación. Con independencia de la metodología utilizada, lo que todas las metodologías populares tienen en común, es que al principio de una iteración se planifica el trabajo que se va a abordar a corto plazo y al final de una iteración se sacan conclusiones de la iteración reciente terminada. Este proceso de mirar atrás se debe hacer siempre con el afán de que nos sirva para ir hacia adelante. El final de una iteración siempre coincide con el comienzo de otra, de manera que en ese punto lo que vemos al mirar atrás son los resultados de una iteración y estos resultados son los que nos deben guiar a la hora de planificar la siguiente iteración.

Evidentemente, el proceso descrito, se puede aplicar de manera anidada. Una iteración puede contener a otras. Esto es así porque al principio de un proyecto es habitual no tener claro en un alto nivel de detalle c uales serán nuestras iteraciones, y por lo tanto podemos definir 3 o 4 iteraciones que luego iremos refinando en subiteraciones. Otro motivo para anidar iteraciones es la posibilidad de tener, en desarrollos grandes, diferentes equipos en diferentes iteraciones, pero esto no es habitual.

A veces se tiende a definir iteraciones en función de hitos en lugar de en función de un horizonte temporal. En mi opinión esto es una mala práctica. Supongamos que definimos una iteración cómo «Implementación de los servicios del backend». Si acumulamos retraso, lo que ocurre es, que cuando a ese punto de control y planificación que es el fin de una iteración, es cuando vemos que estamos retrasados y poco podemos hacer ya. Es claro que parece conveniente realizar periódicamente actividades explicitas de control, aprendizaje y planificación detalla. A la hora de establecer iteraciones es conveniente establecer una meta, «Completar la implementación de los servicios del backend» es sin duda un buen objetivo para una iteración, suponiendo que sea realista para la duración de la iteración.

La duración de las iteraciones es fija en algunas metodologías como Scrum, en otras como MSF se decide como parte de la planificación de la misma.


En la planificación de una iteración debemos:



  • Decidir cuanto durará

  • Establecer que trabajos se realizaran

  • Estimar en detalle estos trabajos

  • Asignar quien realizará estos

  • Establecer una meta para la iteración

Todo ello sin perder de vista los que logramos en la iteración anterior.


Es útil que las iteraciones sean todas de la misma duración en días laborables, porque esto las hace directamente comparables entre sí. Si en la iteración anterior se descubrieron 20 bugs y en la actual 30, algo ha pasado con la calidad de mi proyecto o su control. De todos modos nada en Team Foundation Server liga iteraciones y tiempo.

Un factor que no debemos perder de vista es que la gran mayoría de los informes de Team Foundation Server nos permiten filtrar los datos por iteración. En consecuencia, otro aspecto a tener en cuenta a la hora de definir las iteraciones en Team Foundation Server es con que granularidad nos resultará cómodo manejar las métricas del proyecto.


En un siguiente post abordaré el tema de las áreas y su utilidad.

Por fin: Code Snippets en Visual C++

Con la liberación de Microsoft Visual Studio 2005 IDE Enhancements hace pocas semanas, los code snippets han llegado a Visual C++. Para insertarlos podemos usar los nuevos menus contextuales que nos aparecerán:

La otra opción para insertarlos es escribir el identificador del Code Snippet y pulsar dos veces TAB.

Lo bueno no es solo que contemos con unos cuantos Code Snippets ya disponibles, sino que podemos comenzar a crear los nuestros propios. Es sencillo escribir Code Snippets pues se crean en un simple archivo XML. Os dejo a continuación el código del Code Snippet que introduce un Console.WriteLine en nuestro código, para que os hagaís una idea de los sencillo que es crearlos. Si os animaís a crear Code Snippets leed Crear fragmentos de código en la MSDN. Lo contado aquí sirve tambien para C# o VB.Net

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>cw</Title>
      <Shortcut>cw</Shortcut>
      <Description>Code snippet for Console.WriteLine</Description>
      <Author>Microsoft Corporation</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Code Language="cpp"><![CDATA[System::Console::WriteLine($end$);]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Primera edición del Plain Flash

Dios mio como se como en Galicia!!! Esa es la primera y clara conclusión de la primera edición del Plain Flash que hemos celebrado este fin de Semana en Lugo.


El Plain Flash es un evento periodico (no sabemos cual será la perioricidad) que reune a los miembros de Plain Concepts, con el afán de geekear, compartir unos agradables ratos juntos, formarmos unos a otros y hablar de nuestra empresa. Esta primera edición conto con la asistencia de Cristian Maintega, Iván González, Jorge Serrano, Marco Amoedo, Pablo Alvarez Doval, Pablo Pelaez, Eduardo Quintas y Unai Zorrilla. Tambien acudio a la comida el socio no friki de Plain Concepts, Carlos Costas, que alguien tiene que saber de negocios, no solo de tecnología vive la empresa… y que amablemente nos cedio las instalaciones de otra de sus empresas, Costas Asesores, para nuestras reuniones. La verdad que contar en un proyecto empresarial con alguien de su experiencia y conocimiento es un lujo.


Cristian se encargo del alojamiento con gran exito. Se estaba espectacularmente en su casa de campo, ya rebautizada como Plain Palace.



La agenda…


Día 25 (Sábado)


09:30 Quienes somos, a donde vamos y de dónde venimos a.k.a desayuno(Pablo Pelaez)
10:00 Windows Communication Foundation (Unai)
11:00 Windows Presentation Foundation (Cristian – Pablo)
12:00 Windows Workflow Foundation (Unai-Iván)
16:00 Que hay de nuevo viejo en Visual Basic 2005 (Jorge)
17:00 Los 7 magníficos. IIS 7  – Resumen del IT Forum(Iván)
19:00 Metodologías ágiles: SCRUM (Rodrigo)
20:00 Microsoft Dynamics CRM (Marco)


Día 26 (Domingo)
08:00 Toque de Diana
10:00 Diseño de la capa de acceso a datos (Pablo Doval)
11:00 ORMs: NHibernate (Eduardo)
12:00 SharePoint Server 2007 (Cristian) ´

Los temas propuestos solo fueron una excelente escusa para discutir y aprender sobre estas cuestiones y otras mil que se cruzarón. Algunos incluso acabaron crackeando el buscaminas a las 2 de la mañana (es cierto en sentido literal), mientras la gente normal dormia: Doval, espero un post en tu blog contando el proceso de crackear el buscaminas!!!

 

Además fuera de agenda dos «jamadas» impresionantes, porque con la tripa llena todo el mundo sabe que se habla mucho mejor de tecnología.


Las reglas de Scrum (y IV): El Sprint Retrospective Meeting

Aquí teneís la cuarta y última entrega de la traducción de las reglas de Scrum. Antes de leer este post deberíais leer el primero, sobre la reglas del Sprint Planning Meeting, el segundo, sobre las reglas durante el Sprint y el tercero, sobre las reglas del Sprint Review Meeting.

El Sprint retrospective meeting es una reunión promovida por el ScrumMaster en la cual el Equipo discute el Sprint más recientemente finalizado y determina que puede ser cambiado para hacer el próximo Sprint más divertido y productivo. El Sprint Review se centra en ‘que’ está construyendo el Equipo, la Sprint Retrospective se centra en el ‘como’. La motivación para realizar esta reunión es lograr la mejora continua del proceso de desarrollo. Scrum no es una metodología prescriptiva sino un marco metodológico que debe ser continuamente adaptado a cada proyecto, equipo o empresa.

El Sprint restropective meeting está limitado a 3 horas de duración.


  • Solo asisten el Equipo, el ScrumMaster y el Product Owner, este último es opcional.
  • La reuniñon comienza con todos los miembros del equipo contestando dos preguntas:
  • ¿Qué ha ido bien durante el último Sprint?
    ¿Que puede ser mejorado en el siguiente Sprint?

  • Es ScrumMaster apunta las respuestas del Equipo en un fomrulario de resumen.
  • El Equipo prioriza en que orden quiere hablar acerca de las potenciales mejoras.
  • El ScrumMaster no está en esta reunión para proporcionar respuestas, sino para facilitar la búsqueda del equipo de mejores vias de que Scrum funcione para ellos.
  • Aquellos puntos que merezcan atención que puedan ser añadidos al siguente Sprint considerado como un backlog no funcinal de alta prioridad. Las retrospectivas que no resultan en cambios son esteriles y frustrantes.

Las reglas de Scrum (III): El Sprint Review Meeting

Aquí teneís la tercera entrega de la traducción sobre las reglas de Scrum. Antes de leer este post deberiaís leer el primero, sobre la reglas del Sprint Planning Meeting y el segundo, sobre las reglas durante el Sprint.


El Sprint review meeting proporciona un punto de inspección para el progreso del proyecto al final de cada Sprint. Basándose en esta inspección, se pueden hacer adaptaciones al proyecto. El Equipo estimó donde estaría al final del Sprint y estableció su camino hacia ese punto. Al final del Sprint el equipo presenta el incremento del producto que ha sido capaz de implementar. Los gestores, clientes, usuarios y el Product Owner determina el incremento del producto, escuchan las historias que el equipo tiene que contar sobre su camino durante el Sprint, Oyen que ha ido bien y que ha ido mal. Después de esto, estarán capacitados para tomar una decisión basada en información sobre que hacer después. En otras palabras, determinarán el mejor camino a tomar para alcanzar las metas perseguidas.


  • El Sprint review meeting está limitado a 4 horas.

  • El propósito del Sprint review es que el Equipo presente al Product Owner y los stakeholders la funcionalidad que está completada. Aunque el significado de «completado» puede variar de una organización a otra, habitualmente significa que la funcionalidad esta completamente desarrollada y, potencialmente, podría ser entregada o implementada. Si «completado» tiene otro significado debemos estar seguros que el Product Owner y los stakeholders lo entienden.

  • La funcionalidad que no esta «completada» no puede ser presentada.

  • Artefactos que no son funcionalidad no pueden ser presentados excepto cuando se usan para mejorar el entendimiento de la funcionalidad demostrada. Los artefactos no pueden ser mostrados como productos de trabajo, y su uso debe ser minimizado para evitar confundir a los stakeholders o exigir que estos entiendan como funciona el desarrollo del sistema.

  • La funcionalidad deberá ser presentada en los equipos de trabajo de los miembros del Equipo y ejecutada desde un servidor lo más parecido posible a uno de producción, usualmente un servidor del entorno de aseguramiento de la calidad.

  • El Sprint review comienza con un miembro del Equipo presentando las metas del Sprint, el Product Backlog comprometido y el Product Backlog completado. Diferentes miembros del equipo pueden comentar que fue bien y que no fue bien en el Sprint.

  • La mayoría del Sprint review se consume con los miembros del Equipo presentando funcionalidad, respondiendo preguntas de los stakeholders sobre la presentación y descubriendo que cambios desean estos.

  • Al final de la presentación, los stakeholders son encuestados, uno a uno, para recoger sus impresiones, que cambios desean, y la prioridad de esos cambios.

  • El Product Owner discute con los stakeholders y el Equipo el potencial cambio del Product Backlog basándose en su feedback.

  • Los stakeholders son libres de realizar en voz alta cualquier comentario, observación o crítica sobre el incremento de funcionalidad potencialmente entregable entre presentaciones.

  • Los stakeholders pueden identificar funcionalidad que no ha sido entregada o no ha sido entregada según sus expectativas y solicitar que dicha funcionalidad sea incluida en el Product Backlog para su priorización.

  • Los stakeholders pueden identificar cualquier funcionalidad que se les ocurra mientras ven la presentación y solicitar que dicha funcionalidad sea añadida al Product Backlog para su priorización.

  • El ScrumMaster debe intentar determinar el número de personas que se espera asistan al Sprint review meeting y montar la reunión para acomodarles.

  • Al final del Sprint review, el ScrumMaster anuncia al Product Owner y los stakeholders el lugar y la fecha donde tendrá lugar el próximo Sprint review meeting.

Si quieres licencia no hagas chapuzas…

Una tradición en el desarrollo de software en lo que ha interfaces de usuario se refiere, ha sido, es y será el ‘parecerse a Office’. Con cada nueva release de Office, un montón de aplicaciones rehacian su interfaz para adaptarse al nuevo aspecto.


Con la nueva versión de Office, para seguir con la tradición tendremos que licenciar el uso de la interfaz de usuario de Office 2007. Quietos, quietos, no empeceís a tirar vuestros nuevos controles y los formularios desarrollados los últimos meses!!!! Que esa licencia es gratuita y perpetua!!!, así que no ‘punda el cúnico’… El proceso para obtenerla es sencillo, visitad Office UI Licensing web site.


Estareís pensando, Microsoft… Licencia… Gratis… Aquí hay gato encerrado!!! Si, hay gato encerrado, no nos va a costar a dinero, sino algo mucho más dificil para muchos desarrolladores… Estamos obligados por la licencía a respetar la guia de estilo de la interfaz de usuario de Office 2007!!!! Se acabo que la intefaz parezca Office y se comporte como vi.


Excelente idea la de Microsoft. El argumento viene a ser: hemos invertido mucha pasta en la intefaz de Office, como para que cualquier desgarramantas con un editor gráfico, cuatro componentes y un entorno RAD nos la joda… Excelente… una imagen y un comportamiento coherente de aplicación en aplicación.


Solo espero que esto se traslade a WPF, y nos evitemos ver aberraciones… Sin una guia de estilo clara, en mis manos sin ir más lejos, WPF es como dejar una granada a un mono. Es más… creo que esta inicitiva se tiene que extender a un más y retirar la licencia de Visual Studio a todo el que le uso para hacer código que no siga las recomendaciones de nomenclatura, internacionalización, seguridad etc… Si FxCop se queja… adios licencia!!!. Y en arquitectura, el que se pase por el forro los Patterns & Practices, pues sin licencia para usar el Framework…


¿Se podrá ‘denunciar’ a quien se salte la licencia? Se me están afilando los colmillos solo de pensarlo…


Que nadie piense que este post esta escrito en todo ironico ¿eh?.

Las reglas de Scrum (II): Durante el Sprint

Depués de hablar de las reglas relativas al Sprint planning meeting le toca el turno a las reglas que rigen que ocurre durante un Sprint:


 El Sprint es limitado en el tiempo a 30 días consecutivos en el calendario. Sin considerar otros factores, esta es la cantidad de tiempo necesaria para que un Equipo pueda construir algo de interés significativo para el Product Owner y los stakeholders y llevarlo a un estado en que sea potencialmente entregable. Este es también el máximo tiempo que puede ser asignado sin que el Equipo tenga que hacer tanto trabajo que requiera artefactos y documentación para soportar su proceso de razonamiento. Es también el máximo tiempo que la mayoría de los stakeholders esperarán sin perder interés en el progreso del equipo y sin perder su convencimiento de que el Equipo está haciendo algo significativo por ellos.


  • El equipo puede buscar consejo, ayuda, información y soporte fuera de él mismo durante el Sprint.

  • Nadie puede proporcionar consejo, instrucciones, comentarios o dirección al Equipo durante el Sprint. El Equipo es completamente autogestionado.

  • El Equipo se compromete con el Product Backlog durante el Sprint planning meeting. No se permite a nadie cambia el Producto Backlog durante el Sprint. El Producto Backlog esta congelado hasta el final del Sprint.

  • Si se prueba que el Sprint no es viable, el ScrumMaster puede terminarlo anormalmente e iniciar un nuevo Sprint planning meeting para comenzar un nuevo Sprint. El ScrumMaster puede hacer este cambio por su voluntad o a petición del Product Owner. El Sprint puede no ser viable si la tecnología plantead no se puede emplear, si las condiciones del negocio cambian con el resultado de que el Sprint no será de valor para el negocio, o si el Equipo sufre interferencias de personas ajenas a él mismo durante el Sprint.

  • Si el equipo se siente incapaz de completar todo el Product Backlog comprometido durante el Sprint, puede consultar con el Product Owner que elementos quitar del Sprint actual. Si se eliminan tantos elementos que el Sprint pierde su valor y significado, el ScrumMaster puede terminar anormalmente el Sprint.

  • Si el Equipo determina que puede abordar más Product Backlog durante el Sprint que el seleccionado durante el Sprint planning meeting, puede consultar al Producto Owner que elementos adicionales del Product Backlog pueden ser añadidos al Sprint.

  • Los miembros del Equipo tienen dos responsabilidades administrativas durante el Sprint: Acudir al Daily Scrum meeting, y mantener actualizado y públicamente disponible el Sprint Backlog. Nuevas tareas pueden ser añadidas al Sprint Backlog según sean detectadas, y la estimación contínua realizada día a día para cada tarea debe ser mantenida actualizada.