Construir una Maquinita Arcade con Scrum Usando Prácticas Ágiles – Parte 3

Sprint 2 – No todo lo que brilla es oro

Terminado el primer Sprint, se realizó la segunda Planning, la motivación del equipo seguía alta y se tomaron un montón de historias para hacer en las siguientes 2 semanas, pero esta vez el objetivo ya no era tan claro.

Nos propusimos ajustar el presupuesto, comprar las palancas, la madera, los tornillos, marcar y cortar las maderas, probar distintos emuladores, hacer un diseño para los stencil, difundir lo que estábamos haciendo a toda la empresa, crear estos posts, en fin un montón de tareas.

Que creen que paso? La realidad nos pegó de lleno en la cara, si bien estábamos motivados, cada uno tenía obligaciones en sus respectivos proyectos y por supuesto una vida fuera de las 8hs laborales.

Los típicos problemas de un proyecto eran ahora nuestros problemas, teníamos un presupuesto ajustado, recursos acotados y nos habíamos comprometido con nosotros mismos a tener todas las historias terminadas en dos semanas.

Comenzamos a tener problemas para hacer las Standups en horarios que todos pudiéramos, cambiamos los horarios una y otra vez pero no logramos coordinar al equipo.

El resultado no fue bueno, al final del sprint solo teníamos dos historias terminadas, las palancas compradas (traídas de China en menos de 10 días, todo un logro) y una pequeña difusión de nuestro objetivo al resto de la empresa.

arcade2

La moral del equipo estaba baja, pero gracias a Scrum teníamos la Retrospectiva para desahogarnos, hicimos un poco de catarsis como es de esperar en la segunda Retrospectiva de un sprint que no salió como esperábamos y luego nos pusimos a tratar de resolver algunos de nuestros problemas, definimos que las Stundups se hicieran al mediodía para así poder estar todos, acordamos no tomar tantas historias y dijimos que teníamos que tener un objetivo más claro para el próximo sprint.

To be continued…

Consideraciones al Migrar SharePoint Server 2010 a 2013

En UruIT comenzamos este año con todo migrando granjas productivas de SharePoint Server 2010 a granjas de servidores de alta disponibilidad en la última versión del producto, SharePoint Server 2013.
Durante estas tareas de migración de diferentes ambientes nos encontramos algunas consideraciones que nos parece interesante compartir con aquellos de ustedes que estén evaluando realizar (o directamente ya estén realizando) una migración a SharePoint Server 2013.
No es el objetivo de este artículo ser exhaustivos sino simplemente compartir con ustedes algunos puntos a tener en cuenta;

Cambios en requisitos:

Desde el punto de vista de Hardware, si comparamos los Requisitos de SharePoint 2010 con los de SharePoint 2013 lo primero que notamos es que los requerimientos de cantidad de RAM en los servidores Web aumentaron. Esto es en realidad bastante natural entre cambios de versiones, pero es algo a tener en cuenta. Un ejemplo de esto es que en SharePoint Server 2010 se podía configurar un servidor de evaluación o desarrollo con 4GB de RAM. En SharePoint Server 2013 este piso pasó a ser de 8GB lo que es un aumento significativo. Si lo que queremos además es que el mismo servidor cuente con la base de datos integrada, escalamos rápidamente a los 24 GB de RAM. Este aumento en los requerimientos de memoria lo hemos notado en la práctica ya que en esta versión el servicio de búsqueda hace un uso de memoria significativo.

Por otra parte, al aumentar la cantidad de memoria de los servidores Web debemos planificar un aumento en la cantidad de espacio disponible en disco, ya que se recomienda mantener una cantidad de espacio libre en disco que sea mayor a cinco veces el de la RAM. En la práctica esto se traduce en que si tenemos un servidor Web de SharePoint en producción con 24GB de RAM lo ideal es que el mismo por lo menos cuente con 96GB de espacio libre en disco, en caso contrario SharePoint nos alertará en la Administración Central.

Desde el punto de vista de Software notamos que lo más interesante sucede en el BackEnd. Los requerimientos del Motor de Base de Datos pasan de ser MS SQL Server 2005 SP3 CU3, MS SQL Server 2008 SP1 CU2 o SQL Server 2008 R2 en SharePoint Server 2010 (todos 64 bits) a SQL Server R2 SP1 o MS SQL Server 2012 (también todos 64 bits). Aquí un error común es suponer que SharePoint 2013 funcionará en una versión similar (por ejemplo MS SQL Server 2008 SP1) y no es así. El instalador valida que la versión sea la requerida o superior, y en caso de no cumplir directamente no permite instalar.

Y ya que estamos hablando de versiones de Backend, en caso de poder elegir entre MS SQL Server 2008 R2 SP1 y MS SQL Server 2012, lo recomendable es ir por la versión 2012, ya que permite utilizar funcionalidades Enterprise que con un Backend MS SQL 2008 R2 SP1 se verán recortadas (como Excel Services) o directamente no las podremos utilizar (como ser Report Server, Reporting Services add-in y Power View entre otras).

Seguridad

Al crear una Aplicación Web de Contenido en SharePoint Server2010 podemos hacerlo en modo de autenticación Clásica o Claims. No es la idea entrar en detalles técnicos pero el modo de autenticación Clásica se utilizaba en las versiones anteriores de SharePoint (2007 para atrás) y el modo Claims si bien en SH 2010 era el nuevo mecanismo de autenticación recomendado, tenía ciertas limitantes que hacían que fuera común seguir utilizando el modo de autenticación Clásica.

Ahora en SH2013 el modo de autenticación por defecto es Claims y desde la interface web ya no se pueden crear Aplicaciones Web de Contenido en modo de autenticación Clásica. Si bien utilizando PowerShell podemos saltear esta restricción y habilitarla, debemos dejar de utilizar autenticación Clásica ya que es considerada obsoleta (“deprecated”). Además el modo Clásico será removido de próximas versiones del producto y hay funcionalidades de SH2013 que no funcionan en este modo.

Caché Distribuida:

SharePoint Server 2013 incluye un nuevo servicio de Caché Distribuida que como indica su nombre provee un caché que permite mejorar la performance general del sistema en aspectos como tiempos de carga de páginas, de autenticación, entre otros. Este servicio puede correr en un único host o en clúster y en caso de no quedar bien configurado (ya sea por falta de asignarle suficiente memoria o porque no levanta correctamente) puede verse afectada la performance de la Granja.

En este sentido es importante considerar que si tenemos una Granja con más de un Servidor Web SharePoint con el Caché Distribuido habilitado debemos tener especial cuidado de habilitar en cada servidor los puertos necesarios para que este servicio funcione correctamente como clúster. En caso contrario la performance de la granja posiblemente se vea afectada.

Flujos:

SharePoint Server 2010 utiliza como motor de ejecución de flujos Windows Workflow Foundation 3.5 mientras que la versión 2013 pasa a utilizar Windows Azure Workflows. Si bien SharePoint Server 2013 es capaz de ejecutar los flujos diseñados para 2010, los nuevos flujos en modo 2013 ahora pasan a correr en un servicio separado de SharePoint. Lo más interesante es que ahora los flujos pueden correr en la misma granja, en una máquina dedicada o incluso en un servicio externo. Esto trae aparejadas un conjunto de mejoras que van desde escalabilidad, monitoreo y confiabilidad del servicio. Lo importante a tener en cuenta a la hora de configurar una nueva granja SharePoint Server 2013 es que ahora se debe instalar y configurar aparte el servicio de Windows Azure Workflows ya que no se instala por defecto.

Martin Ferreira

SharePoint Practice Lead