Computación en la Nube para Automatizar Servidores Informáticos

¿Por qué no uso Gantt para seguimiento y control de mis proyectos?

En variadas reuniones y eventos en los que conversamos sobre la problemática del desarrollo de software en el Perú, siempre observo el rostro de desconcierto de Jefes y Gerentes de Proyectos al escuchar esa afirmación. La alta dependencia de un diagrama Gantt y quizás el día a día de su intenso trabajo, probablemente no les permite explorar otras herramientas de seguimiento y control de sus proyectos que puedan ser más efectivas para este fin.

El diagrama de Gantt fue desarrollado por Henry Gantt en 1910 mientras enfocaba su trabajo en la construcción de Buques durante la Primera Guerra Mundial. Durante sus más de 100 años de existencia se han agregado pocas características a su versión original. Lo que sí es indudable es el uso masivo entre las personas que tienen que ver con la Gestión de Proyectos, convirtiéndolo casi en un estándar de facto para el seguimiento de las actividades del Proyecto.

El desarrollo de software tradicional y el sistema Push

Tradicionalmente, el desarrollo de software se ha basado en un modelo “Push” de flujo de trabajo en donde las tareas son planificadas y programadas. Esto es, tan pronto como cualquier tipo de tarea es identificada, tal como “Crear Prototipo” o “Solucionar el Bug”, es asignado a un individuo. Un Jefe de Proyectos y el equipo viven y mueren con el Gantt.

Hay algunos inconvenientes con los que uno se encuentra en el día a día trabajando con un Gantt como por ejemplo presentar un diagrama de Gantt extenso en un documento, prácticamente no se llega a notar el contenido perdiendo su valor como herramienta visual. Otra cosa que sucede frecuentemente es que no refleja la realidad del proyecto. En un proyecto de software los cambios son constantes, mantener actualizado el diagrama Gantt se vuelve tan tedioso que termina siendo obsoleto continuamente.

Un sistema “Push” también introduce conflictos. Se toma el Gantt como un contrato que fija los plazos y utilización de recursos lo cuales hay que cumplir a como dé lugar. El objetivo muchas veces no llega a ser la entrega de valor a través de un producto de software de calidad, sino el cumplimiento del  cronograma Gantt. El resultado creo que todos lo conocemos: pocas veces se cumple lo establecido y el tiempo de ciclo termina siendo más largo.

Kanban y el Sistema Pull

La alternativa al Sistema Push es el Sistema Pull. En un Sistema Pull el trabajo no es planificado ni programado, el trabajo ingresa al flujo en base a la disponibilidad. Kanban es un ejemplo de un sistema Pull. Este se basa en un sistema de producción que dispara trabajo solo cuando existe capacidad para procesarlo.

Kanban permite la visualización de todo el proceso de desarrollo, mediante un tablero físico, generalmente, públicamente asequible. Esto permite, entre otras cosas, entender mejor el proceso de trabajo actual, conocer los problemas que puedan surgir y tomar decisiones, mejorar la comunicación entre todos los interesados/participantes del proyecto y hacer los futuros procesos más predecibles. Un tablero Kanban, se divide en columnas las cuales representan un proceso de trabajo.

Otra característica de Kanban es el uso de un WIP (Work in Progress o trabajo en curso) que consiste en acordar anticipadamente la cantidad de ítems que pueden abordarse por cada proceso (es decir, por columnas del tablero). El principal objetivo de establecer estos límites es el de detectar cuellos de botella los cuales representan el estancamiento de un proceso determinado que llevan a alargar los plazos de entrega.

¿Porque no uso Gantt para el seguimiento y control de mis proyectos?

Regresando a la afirmación original, en mis equipos de trabajo hemos dejado de usar diagramas de Gantt desde hace un tiempo y solo se generan cuando hay que mostrar hitos del proyecto (sprints) u otra información relevante a los interesados del proyecto.

Para el seguimiento y control del avance de requerimientos y actividades utilizamos herramientas como “Team Foundation Server” que incorpora un tablero Kanban para el seguimiento del proceso de desarrollo. Sin embargo, hay que resaltar que para que esto sea efectivo se planifican “ciclos cortos” de entrega de entre dos a tres semanas de duración, al término del cual se entrega un incremento o avance del producto de software.

El uso de prácticas agiles, así como herramientas tales como el tablero Kanban, nos ha permitido tener una mejor visibilidad y efectividad en el manejo de los ciclos de entrega del producto de software en nuestros proyectos. ¿Qué inconvenientes encuentras tú con los diagramas de Gantt ?

Fuente : http://agiland.pe/blog/por-que-no-uso-gantt-para-el-seguimiento-y-control-de-mis-proyectos/ 

ASP.NET Web Forms o MVC ¿ Cual encaja en nuestra necesidad ?

Este pequeño y humilde artículo tiene el propósito darles a conocer un poco más las tecnologías de desarrollo web que proporciona Microsoft. Si no lo hiciste todavía, te recomiendo que leas Entendiendo el ecosistema de desarrollo web de Microsoft.
Hoy voy a escribir sobre la diferencia entre ASP.NET Web Forms y ASP.NET MVC, que a muchos nos debe pasar, y no sabemos que herramienta elegir para nuestro proyecto, obviamente existen muchos criterios, reglas, escenarios, etc en el cual debemos elegir el mas indicado, con un objetivo que desarrollemos y entreguemos un producto de calidad, un producto que sea compatible, escalable, es lo que debemos entregarle a nuestro cliente y/o usuarios.

Bueno espesemos a explicar un poco,  MVC de ASP.NET no viene a sustituir las aplicaciones de WebForm sino completarlas para aportar una serie de ventajas, por ejemplo:

• Separar aun más la representación de la lógica de negocio
• Facilitar las técnicas de desarrollo test driven development
• Facilitar las técnicas de Inversion of Control (IoC)
• Mayor grado de parametrizacion/instrumentación de la solución
• Permite evitar el modelo Postaback del ASP.NET

Como resultado general las mejoras descritas aportan:

• mayor productividad,
• agilidad en la respuesta al cambio de requerimientos,
• fiabilidad y solidez en las aplicaciones.

Trasfondo

Hace mucho tiempo, con la ayuda de tecnologías como Visual Basic y Visual C++, Microsoft habilitó la creación de interfaces gráficas de forma rápida, con lo cual, los programadores podían enfocarse más en el negocio que en el diseño de las interfaces de usuario.
Esas tecnologías eran limitadas a las aplicaciones de escritorio, en el aspecto web, Microsoft sólo ofrecía ASP.
Cuando hablamos de web y escritorio, hay que considerar dos cosas:

1. Cómo se administra el estado?
2. Cómo funciona el pedido/respuesta?

Las aplicaciones web funcionan sobre el protocolo HTTP, el cual es un protocolo sin estado. A diferencia del escritorio, no hay variables que se preserven y no hay una programación completa manejada por eventos. Como en el escritorio, la web espera la entrada de un usuario, pero cada interacción actúa como un pedido nuevo al servidor.
En base a este escenario, Microsoft presentó ASP.NET Web Forms, manteniendo el desarrollo de aplicaciones rápido y la facilidad de aprendizaje.

¿Qué es ASP.NET?

ASP.NET es un framework de aplicaciones web creado por Microsoft, construido sobre el CLR (Common Language Runtime). Permite crear aplicaciones web dinámicas utilizando lenguajes como C# o Visual Basic.NET.

¿Qué son los Web Forms?

Los Web Forms aparecieron para solucionar los problemas que tenía la tecnología ASP clásica. Se creó un nuevo nivel de abstracción sobre la web sin estado, simulando el modelo con estado de los Windows Forms. Se introdujeron conceptos como postback (un envío desde la misma página) y ViewState (un objeto que almacena los valores de los controles durante los postbacks) y se redujo la cantidad de código a escribir.

Ventajas

• Los Web Forms contienen controles de servidor ricos: ASP.NET detecta el navegador del usuario y genera HTML y JavaScript apropiado para él. Además, controles como el GridView o el ListView, contienen funcionalidad para enlazar datos.
• ViewState: Normalmente los controles no retienen los valores entre los pedidos al servidor, pero en los Web Forms esto se logra guardando el último estado conocido en un campo oculto denominado ViewState.
• Programación manejada por eventos: Microsoft introdujo la programación manejada por eventos, con la cual, los desarrolladores no tenían que apoyarse sobre los métodos POST y GET para las interacciones con el servidor. Haciendo doble click sobre un control, se genera un bloque de código que manejará el evento de dicho control en el servidor; sin que el desarrollador tenga que saber qué es lo que ocurre.
• Desarrollo de aplicaciones rápido: Con los controles de servidor + el modelo manejado por eventos + ViewState, el desarrollador queda abstraído de muchas de las complejidades, con lo cual programa más rápido.
• Curva de aprendizaje pequeña: Es posible hacer aplicaciones con muy poco conocimiento de HTML y JavaScript.

Desventajas

• Unit Testing: El Code Behind (archivo que contiene código a ejecutarse en el servidor) termina conteniendo muchos manejadores de eventos, lo cual hace que el unit testing automático sea una tarea imposible.
• Performance: ViewState se convirtió en una solución para varios problemas de ASP, pero como se guarda en la misma página hace que el tamaño de la misma se incremente y se reduzca la performance general.
• Reutilización: El código incluido en el Code Behind de un Web Form no es fácilmente reutilizable en otro.
• Poco control sobre el HTML: Muchas veces no está muy claro cuál es el HTML que resultará de la utilización de los controles, lo cual hace complicada la integración con frameworks como jQuery.
• SEO: No se generan URLs amigables, lo cual afecta el SEO de la página.
• Trabajo en paralelo: Como cada Web Form está atado a su Code Behind, no es recomendable que dos desarrolladores trabajen al mismo tiempo en estos archivos.

ASP.NET 4.0

ASP.NET 4.0 introdujo varias mejoras que solucionaron varios de estos problemas.

• ViewState: Se provee la forma de desactivar o controlar el tamaño del ViewState.
• URL Routing: Utilizando URL Routing se pueden crear URL amigables
• ID: Hay mejor control sobre el ID de los elementos, para mejorar la integración con frameworks de JavaScript.

¿Qué es MVC?

MVC es un patrón de arquitectura de software, no es un concepto nuevo, ni está creado por Microsoft. Por las dudas, me gustaría explicar estas palabras que acabo de utilizar:

• Patrón: Un patrón es una solución a un problema en un contexto.
• Patrón de arquitectura: Son patrones de diseño de software que ofrecen soluciones a problemas de arquitectura de software, tienen un nivel mayor de abstracción que los patrones de diseño. Describen los elementos y el tipo de relación que tienen junto con un conjunto de restricciones sobre cómo pueden ser usados. Expresan un esquema de organización que consta de subsistemas, sus responsabilidades e interrelaciones.

La intención detrás de MVC es la de separación de responsabilidades. Las partes que componen el modelo MVC son:

• Modelo: Maneja los datos y es independiente de las otras partes del MVC.
• Vista: Es la representación del modelo de datos. Puede ser una página, un archivo Excel, un pdf, etc. La vista sólo conoce al modelo.
• Controlador: Maneja la interacción del usuario y la lógica de entrada. Es el encargado de obtener el modelo y entregárselo a la vista.

¿Qué es ASP.NET MVC?

ASP.NET MVC es un nuevo framework para aplicaciones web creado por Microsoft, diseñado bajo la idea de la separación de responsabilidades y la posibilidad de implementar el testing. No posee ni ViewState, ni controles de servidor.

Ventajas

• Arquitectura de proyecto: Al estar fuertemente implementada la separación de responsabilidades, también tenemos una arquitectura del proyecto ordenada.
• Desarrollo manejado por tests: Los controles son clases separadas, por lo cual, es posible hacer test automáticos.
• Reutilización: Los controles no están atados a una vista, por lo cual pueden ser reutilizados.
• Performance: Las páginas son mucho más livianas comparadas con los Web Forms.
• Control total del HTML: Como no existen los controles de servidor, la única opción es utilizar los controles HTML, por lo que sabemos cómo se terminará renderizando la página. La integración con librerías JavaScript es realmente simple.
• Soporte para trabajo en paralelo: Al estar todo realmente separado, es posible que un desarrollador esté trabajando en una vista, mientras otro esté en el controlador y un tercero esté en el modelo, sin que interfieran entre ellos.
• SEO, URL Routing y REST: Las características de routing permiten utilizar interfaces REST.
• Extensión: Soporte para múltiples motores de vistas como aspx, razor, etc.
• Características preexistentes de ASP.NET: Como está construido sobre el framework ASP.NET, provee características como autenticación, caching, session, etc.

Desventajas

La principal desventaja de ASP.NET MVC es que presenta una curva de aprendizaje mucho más importante, por lo cual, puede ser muy difícil para los desarrolladores que recién están empezando.

¿Cuál es mejor?

Ambas tecnologías pueden ser la mejor, todo depende de los requerimientos, el problema dado y el conocimiento que tenga el equipo de desarrollo. Lo que es importante saber, es que una tecnología no suplanta a la otra.
Existen unos factores que pueden hacernos decidir por una o por otra:

• Quiero desarrollar la aplicación de forma rápida: ASP.NET Web Forms
• Quiero poder hacer Unit Testing: ASP.NET MVC
• Mi equipo tiene conocimiento de Windows Forms: Van a aprender mucho más rápido a utilizar Web Forms que MVC.
• Mi equipo no tiene conocimientos de las tecnologías Microsoft: Si ya utilizaban JSP, Ruby On Rails, etc. MVC es la elección.
• El uso de JavaScript va a ser importante: Si se va a utilizar mucho JavaScript, MVC es más adecuado.
• No tengo mucho conocimiento de tecnologías web: ASP.NET Web Forms

Resumen

Hoy profundizamos un poco más en las tecnologías Microsoft, para poder discernir cuál es la que mejor se adapta (o adaptará) a nuestras necesidades. 

¿Qué es entiendes de Procesos?

Definición de proceso..

 

 

Es habitual hablar de proceso, de secuencia de actividades, de que involucran inputs y outputs y todo ese conjunto de conceptos conocidos por muchos. Para el analista, la identificación de sus elementos es más útil que el concepto en sí. Aquí presentaré una definición básica de lo que es un proceso y de los elementos que lo componen, a la luz de la óptica con la que se viene trabajando en este tratado.

 

Proceso es el conjunto de actividades o tareas, mutuamente relacionadas entre sí que admite elementos de entrada durante su desarrollo ya sea al inicio o a lo largo del mismo, los cuales se administran, regulan o autorregulan bajo modelos de gestión particulares para obtener elementos de salida o resultados esperados . Las entradas al proceso pueden ser iniciales o intermedias. Asimismo, los resultados o salidas a lo largo del proceso pueden ser intermedios o finales. La presencia e interacción de los elementos que lo componen conforman un sistema de trabajo, al cual puede denominarse “Sistema de gestión del proceso”. Gráficamente se puede entender lo anterior así:

 

Dentro del proceso, hay un tratamiento de entradas de diversos tipos en cada actividad o tarea agregándoles valor, de tal manera que se cumplan los requerimientos o necesidades del cliente interno o externo.

Cabe indicar que, el propósito del diseño de un proceso de servicio es que se contribuya en cada una de sus actividades con una cuota de valor (léase Cadena de Valor de Porter) y que de esta cadena se genere finalmente una contribución de valor mayor que el experto denomina "margen". En este sentido, los procesos deben agregar valor entre etapa y etapa, subproceso o subproceso o entre operaciones. Estamos hablando de servicios y también de procesos de manufactura, bajo una concepción de gestión positiva tal y como debe hecerlo un gerente, administrador o alguien encargado de manejar procesos.
No obstante a ello, existen procesos en los cuales, cada etapa resta valor. ¿Cómo es eso?. Veamos.

 

Formulemos la pregunta: ¿existen procesos que no agregan valor final al resultado?. En principio no todo proceso tiene porque agregar valor, citemos por ejemplo a los procesos degenerativos en el cuerpo humano, enfermedades como Alzeimer, Espondiloartropatías, esclerosis múltiple, cáncer, etc.

Estos son procesos autoregulados (seguramente por alguna condición seronegativa, es decir, que el mismo organismo lo genera y no puede controlar teniendo que recurrir a ayuda externa). Ciertamente, estos son procesos que escapan al àmbito empresarial y de gestión de servicios, pero clarifica 100% lo que se quiere dar a entender: una empresa puede tener alguna enfermedad, es decir, tener procesos degenerativos.

En este punto quiero ser claro en lo siguiente: si bien existen procesos que no agregan valor como los que mencioné antes, es cierto que este "fenómeno" o esta "enfermedad" puede darse también en una organización, una empresa y también en un proceso de servicio. ¿Cómo?. Veamos.
Cuando se habla de cultura organizacional se toma en cuenta entre muchos elementos a los valores, costumbres o hábitos de sus trabajadores. Buenos hábitos contribuyen con la creación de valor en las actividades de la empresa y por ende, en la creación de valor de todos sus procesos. Pero, si el personal contribuye con hábitos malos como por ejemplo, llegar temprano, marcar tarjeta y salir media hora a tomar desayuno por ahí, asistir a las reuniones sólo para criticar y no aportar, hablar mal de los compañeros, ser burlón con algunas personas, ser soberbios, no comunicar a sus empleados las decisiones de la semana o los temas prioritarios en agenda, no saludar a los compañeros o no acordarse de las necesidades de su personal, entre otras cosas más (propias de las relacionse humanas), constituyen actos y conductas que NO AGREGAN VALOR, a pesar que van construyendo y moldeando procesos de cultura organizacional en la empresa: a la larga, el comportamiento interno en tu organización estará compuesto por procesos de relaciones humanas que no posean valor, más bien, degradan o degeneran a la cultura deseada afectando nocivamente al desempeño del recurso humano (falta de motivación, descontento, falta de condiciones adecuadas interpersonales en cantidad mínima o suficiente, sentimientos de rivalidad, celos profesionales, quejas manifiestas o conflictos declarados, muestras de indiferencia, mal trato y humillación evidentes, entre otros).

 

NI que decir si estos procesos internos acaban por ser externos y tengan que llegar al cliente o usuario final. Imaginemos el trato y conducta del personal de servicio hacia los clientes bajo las condiciones de los ejemplos citados.

 

Otro caso es cuando se planifica mal y como resultado de ello no se tiene cómo medir los avances, se generan reuniones para "reprogramar" o "reformular" los planes, las tareas, y en peores casos hasta los objetivos. Se generan discusiones bizantinas que buscan un consenso sin tener un criterio común previo, consumiéndose hasta horas de dar vuelta y vuelta a un mismo tema.

 

En este tipo de reuniones ¿hubo valor?. Si miramos comprativamente entre el antes y el después, cualquiera de los participantes en dichas reuniones dirá que sí se está agregando valor al proceso de planificación (claro, sí forma parte del mismo). Pero si miramos con ojos de gerente, la cosa cambia. Porque cuando existen procesos estratégicos como los de planificación, no podemos darnos el lujo de estar como el cangrejo (hacia adelante y hacia atrás), menos aún cuando el tiempo es recurso irrecuperable y peor aún si se trata de servicios. Si el gerente o la alta dirección no comprende este hecho y supone que TODO retroceso es por algo bueno, seguramente requiere que le digan que la organización o área que dirige está compuesta de procesos que están DESVALORIZANDO su gestión. Escuchando esto, tal vez podría comenzar a reflexionar.

Volviendo al tema y por ello, en el gráfico mostrado, apuntamos a procesos, subprocesos u operaciones que sólo agregen valor. Esa es nuestra meta al diseñar o rediseñar procesos de servicios como analistas o consultores.
Mencionaré algunos ejemplos de procesos guiándonos siempre de la clasificación de producto presentado en artículo del 18 de enero. Recordemos que siempre debemos partir de conocer cuál es el resultado del proceso, es nuestro objetivo a donde queremos llegar. Los resultados de un proceso pueden ser:

 

- Bienes tangibles

- Bienes intangibles

- Servicios

 

Veamos algunos ejemplo de procesos, en función a su resultado:

 

Para producir Bienes tangibles:

 

•  Fabricación de papel
•  Fabricación de pastas y fideos
•  Elaboración de libros escolares
•  Fabricación de cerveza
•  Elaboración de leche pasteurizada
•  Fabricación de embutidos
• Construcción de carreteras y puentes
• § Construcción de inmuebles
• § Producción de energía eléctrica
• § Producción de gas licuado
• Para producir Bienes Intangibles:
• § El Aprendizaje por parte de los alumnos
• § El Aprendizaje – experiencia de parte de los padres de familia en un hogar
• § La Adaptación de un niño adoptado en una familia

niño adoptado

Foto: www.cruzadadelrosario.org.ar

§ La Adaptación de un empleado en un nuevo trabajo

§ La Reinserción en la sociedad de un ex convicto

§ El Enamoramiento entre dos personas de diferente sexo

jj

Foto: www.elpais.com/recorte2004071/elpepuage_1/SCO250

§ La Automotivación para lograr un mejor desempeño

§ El Liderazgo y acercamiento personal bajo técnicas de coaching ontológico

§ El Desarrollo y evolución de la familia

§ El Desarrollo y crecimiento de una PyME

§ La Capitalización y aprovechamiento del talento humano en una empresa

§ La Alfabetización lograda en la población de una comunidad andina

Para servicios:
- Proceso de Selección de personal

- Proceso de Enseñanza escolar a lo largo de los 10 meses

- Proceso de Enseñanza universitaria de pre grado

- Procesos de Adiestramiento y capacitación específica a personal de una empresa

- Procesos de Planificación, Organización y ejecución de procesos electorales

- Procesos de Compras y adquisiciones de bienes y servicios estatales

- Proceso de Organización de eventos

- Proceso de Distribución de energía eléctrica

- Proceso de Distribución de pastas y fideos

- Proceso de Distribución de libros escolares

- Proceso de Administración de obras de infraestructura víal terrestre (carreteras, puentes)

- Proceso de Ventas de proyectos de construcción civil

- Proceso de Asistencia Técnica para la realización de elecciones internas de una organización

- Proceso de Ventas de seguros de vida

- Proceso de Ventas de soluciones y aplicativos informáticos.

sahk

Foto: http://farm2.static.flickr.com/1411/564949212_b585279e25

§ Procesos de servicios de salud

§ Procesos de Supervisión de negocios y comercialización

§ Procesos para el Transporte de valores

§ Procesos de Seguridad Integral (física, material, de intangibles)

§ Procesos de Servicios de Entretenimiento

§ Procesos de Servicio de Consultoría empresarial

Nótese una distinción importante. Cuando nos referimos a la producción de energía eléctrica, es decir, al proceso que ocurre en una central hidroeléctrica estamos hablando de un bien tangible como resultado de ese proceso (la energía eléctrica es un bien físico, es materia). Cuando nos referimos a la distribución de energía eléctrica digamos en una ciudad, estamos hablando ya de un proceso de servicio: cómo hacer llegar esa energía eléctrica a la población bajo ciertas condiciones y mediante una tarifa determinada.
Definiendo adecuadamente el resultado asociado al proceso en análisis podemos ver de manera más clara si el proceso es o no de un bien físico, no físico o si se trata de un servicio. Asimismo, para cualquiera de estos ejemplos podremos aplicar el diagrama antes mostrado. Con él se podrá identificar a cada uno de sus elementos y así proceder a un análisis efectivo.
ELEMENTOS DE UN PROCESO
En todo proceso se distingue una serie de elementos o componentes fundamentales. No hay proceso que no cuente con alguno de estos elementos. Lo que si puede ocurrir que existan procesos en los cuales sus elementos no han sido identificados correctamente.

Ø Entradas.

Ø Subprocesos, operaciones o tareas

Ø Salidas, resultados o productos

Ø Clientes (internos, externos)

Ø Sistema de monitoreo, control y evaluación

Ø Responsable del proceso

Las entradas se dividen en recursos o insumos.
Recursos:
Financieros.

Humanos.

Espacio físico (plaza e infraestructura).

Energía.

Software y aplicativos informáticos.

Equipamiento (tecnología dura).

Información (cuantitativa y cualitativa).

Conceptos, modelos de gestión, políticas, procedimientos y formas de proceder (tecnología blanda).

Especificaciones del cliente (requisitos).

Marco legal.

Servicios.

Bienes no materiales (condiciones, facilidades, seguros).

Insumos:

Materias primas.

Bienes materiales (Datos cuantitativos y cualitativos en medios transportables).

1. ENTRADAS
1.a. Recursos
Sin ellos no podría iniciarse, desarrollarse ni terminarse el proceso en su integridad. Los recursos proporcionan las facilidades para desarrollar las operaciones o tareas del proceso. Pueden ser tangibles (materiales) o intangibles (no materiales). Se les puede agrupar en los siguientes tipos:
cuadro
1.b. Insumos
Un insumo es todo bien material que va a ser procesado (ensamblado o transformado). La data sin procesar, contenida en medios magnéticos (CD, USB) o en forma electromagnética, constituyen insumos. Ejemplo: Materias primas que deban ser procesadas.Papel para las oficinas.Personas (cuando se trata de procesos de capacitación o formación);Data e información en medios transportables para ser procesada.
Las entradas, tanto recursos como insumos, pueden ser iniciales o intermedias. Serán iniciales si es que se incorporan con el inicio del proceso. Serán intermedias si es que se van incorporando durante el desarrollo del proceso.
2. SUBPROCESOS, ACTIVIDADES U OPERACIONES
Los subprocesos, actividades, operaciones o “tareas”, también son procesos de “menor jerarquía”, pues, de manera individual o colectiva, también hacen uso de los recursos transformándolos o agregándoles valor dentro del sistema de gestión particular.
La realización de un subproceso, actividad u operación constituye servicio en desarrollo, es decir, una acción que está produciéndose y siendo “consumida” de manera simultánea. Al término de ello, se tendrá a un servicio consumado asociado a un bien tangible o a un bien intangible.
Todo subproceso, actividad u operación como parte del proceso delimitado para nuestro análisis, atenderá a un cliente interno a excepción de la última operación a lo largo de la cadena del proceso pues atenderá al cliente final del proceso en si.
Estos subprocesos, actividades u operaciones pueden aparecer y trabajar individualmente sirviendo al proceso en algún punto del mismo (recordemos un Diagrama de Operaciones de Proceso DOP para un material).
3. SALIDAS, RESULTADOS O PRODUCTOS
Las salidas (outputs), resultados o productos, que genera el proceso, pueden constituir entradas de un siguiente proceso cuando el cliente es interno, o constituir el producto final (bien o servicio) cuando el cliente es externo. En resumen, y como se indicó anteriormente, los resultados o productos pueden ser bienes o servicios:
§ Servicios consumados

§ Bienes materiales (bienes tangibles)

§ Bienes no materiales (bienes intangibles)

Las salidas también pueden ser intermedias o finales. Serán intermedias si es que corresponden a productos resultantes durante el desarrollo del producto, y finales si es que corresponden a productos resultantes al final del proceso.
4. CLIENTES
Los resultados o salidas de un proceso se dirigen a las personas, áreas o procesos Clientes o Usuarios. El término cliente denota a quien se atiende “una o más de una vez”. El término usuario denota a quien “usa” o “se beneficia” del servicio o bien que resulta del proceso). Ambos términos pueden ser considerado como lo mismo si es que cumplen el mismo papel (Un análisis en mayor profundidad es el presentado en el articulo anterior en el presente blog).
Dependiendo de su aparición durante el proceso y de cómo se ha definido su alcance, los clientes o usuarios pueden ser internos o externos. Son internos si forman parte del sistema de gestión del proceso y externos si no forman parte de ese sistema.
5. SISTEMA DE MONITOREO, CONTROL Y EVALUACIÓN
Las actividades, operaciones o tareas dentro de todo proceso, requieren contar con criterios, instrucciones e instrumentos para:
Detectar probables irregularidades y medir el desempeño del proceso en sus puntos críticos.

Controlar, corregir o suprimir las irregularidades.

Evaluar el desarrollo del proceso y sus implicancias.

El monitoreo permite “estar atento” al desarrollo de nuestro proceso, de nuestro producto o servicio y de saber cómo está percibiéndolo el cliente. Para ello, necesitaremos instrumentos de medición que permitan “medir” estos avances, desarrollos o evoluciones.
No sólo basta con monitorear, hay que tomar las medidas correctivas. Aquí aparece el control es decir, “corregir” lo que está ya en marcha. Esto significa “enderezar” lo que vemos que se está torciendo. ¿Cuánto enderezar?, esto lo dirá la medición que obtengamos en la etapa anterior correspondiente al sistema de monitoreo.
Luego de monitorear (estar al tanto y medir), controlar (ajustar, corregir) debemos evaluar, es decir, extraer conclusiones relevantes sobre el impacto, el resultado, el desarrollo y hasta del diseño de nuestro servicio. Por lo general, las evaluaciones de proceso de servicio se hacen luego de terminado los calendarios de cumplimiento de planes operativos estableciéndose periodos para tal fin (trimestrales, semestrales, anuales), pero siempre coinciden por lo general con el termino de algún periodo de sustentación.
6. RESPONSABLES
Los responsables de la ejecución del proceso, son las áreas o personas involucradas en el cumplimiento de cada una de las actividades u operaciones de acuerdo a los objetivos, funciones y procedimientos acordados para tal fin.

Si quiere tener mayor conocimiento de procesos, visite mi otro blog:

pulse AQUI

Notas:
(1): La palabra proceso viene del latín processus, que significa avance y progreso.

(2): Se puede hablar de resultados esperados cuando estos son predecibles. Hay hechos no predecibles e incontrolables que afectan a nuestros procesos (cambios en el marco legal o en el entorno macroeconómico o social de un proyecto). La gestión eficaz en la actualidad debe prever estos hechos con un grado de seguridad que minimice el riesgo implícito.

Identificacion De Procesos De Negocio

Para poder identificar correctamente cuáles son los requerimientos de un proyecto, es necesario conocer las características del negocio en el que se inserta. En el proceso de desarrollo del software la modelación del negocio adquiere mayor importancia por el impacto que tiene la utilización de las nuevas tecnologías. Este trabajo describe algunas reglas que ayudan a identificar procesos de negocio.

El punto de partida es la propuesta de RUP y se incluyen recomendaciones
y ejemplos derivados de su aplicación en diferentes entornos.

INTRODUCCIÓN

Un proceso de desarrollo de software es ..." el conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema informático".
1 Un proceso define quién está haciendo qué, cuándo y cómo alcanzar un determinado objetivo.
Obtener los requisitos funcionales que se derivarán en un producto de software nuevo o la
mejora de uno existente, requiere de un estudio de la organización. Este estudio está contemplado dentro del flujo de trabajo de Modelamiento del negocio, desarrollándose la mayoría de sus actividades dentro de la fase de concepción (o inicio).

En este trabajo se toman como referencia los libros clásicos que describen RUP, 1-3 aunque es importante señalar que en esta literatura esta es una de las áreas de conocimiento cuya descripción no es suficiente para la modelación. La identificación de los procesos de negocio es una actividad que resulta difícil de ejecutar por que los criterios aquí incluidos pueden servir de referencia.

Los resultados que se presentan parten del análisis de dos años de experiencia en la enseñanza de esta temática.

MODELACIÓN DEL NEGOCIO

Un sistema, por pequeño que sea, generalmente es complicado. Por eso se necesita dividirlo en piezas si se pretende comprenderlo y gestionar su complejidad.

Esas piezas se pueden representar a través de modelos que permitan abstraer sus características esenciales. De ahí, que en el campo84 Industrial del software también resulte útil la creación de modelos que organicen y presenten los detalles importantes de problemas reales que se vinculan con el sistema informático a construir.

Estos modelos deben cumplir una serie de propiedades, entre ellas la de ser coherentes y relacionados. Uno de los modelos útiles previo al desarrollo de un software es el modelo del

negocio.

PROCESOS DE NEGOCIO

El modelo del negocio describe el negocio en términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos.

El modelo de casos de uso del negocio es un modelo que describe los procesos de un negocio (casos de uso del negocio) y su interacción con elementos externos (actores),  tales como socios y clientes, es decir, describe las funciones que el negocio pretende realizar y su objetivo básico es describir cómo el negocio es utilizado por sus clientes y socios. 

Implica la determinación de los actores y casos de uso del negocio. Con esta actividad se
pretende: Identificar los procesos en el negocio, definir las fronteras del negocio que van a modelarse, Definir quién y qué interacturán con el negocio y crear diagramas del modelo de

casos de uso del negocio.

IDENTIFICACIÓN DE PROCESOS DE NEGOCIO

Para identificar los procesos de negocio es muy importante tener en cuenta que deben generar un valor para el negocio o mitigar los costos del negocio.

1. Clasificación de procesos de negocio.

Para encontrar casos de uso del negocio se pueden clasificar los procesos de negocio en tres categorías:

• Núcleo: Considere qué valor reciben los actores del negocio
primarios y más importantes: los clientes. Busque los procesos
del negocio respondiendo a la pregunta: ¿cuáles son los servicios
básicos que un cliente recibe del negocio?

• Soporte: Contiene las actividades que no benefician al cliente
directamente. Para identificarlos se pueden buscar actividades
como las siguientes: desarrollo y mantenimiento de personal, de
las tecnologías de información y de la oficina, seguridad y
actividades legales.

• Gerencial: Estos procesos se encuentran bucando los
procesos que tienen que ver con el manejo del negocio en su
coonjunto. Normalmente se relacionan con el actor propietario.
Busque actividades como las siguientes. Desarrollar y
poporcionar información sobre el negocio a los dueños e
inversionistas, preparar las metas del presupuesto a largo plazo,

etcétera.

2. Identificación de funciones

Otra manera de encontrar los casos de uso del negocio es que los expertos del dominio describan cada actividad en el negocio existente, y entonces se agrupan estas actividades en procesos de negocio. 

Scrum con Team Fundation Server / Services

Scrum con TFS

En los últimos años estamos asistiendo a un cambio radical en la forma de gestionar los proyectos de desarrollo de software. Empieza a resultar extraño encontrar ofertas de trabajo en las que no se mencione scrum, o proyectos que empiecen en los que no se haya planteado el uso de metodologías ágiles. Pero de nada nos sirve una metodología, por muy buena que pueda ser, si perdemos más tiempo gestionando el proceso que programando. Por lo que nos vemos casi obligados a empezar a usar herramientas que nos ayuden con esta tarea. A lo largo de este artículo trataremos una de esas herramientas, que consideramos más potentes: TFS.

Team Foundation Server/Service

Las siglas TFS pueden significar Team Foundation Server o Team Foundation Service. En ambos casos se trata del mismo producto, pero en diferentes formas de distribución.

Este software es la herramienta que nos ayudará con la gestión del ciclo de vida de aplicaciones (ALM), propuesta por Microsoft. TFS nos aportará una serie de utilidades que nos facilitarán la gestión de los procesos, el control de versiones del código fuente, el testing de aplicaciones, el deploy, y además nos aportará diferentes informes sobre todo esto.

Las dos formas de distribución en las que podemos encontrar TFS hoy en día son:

• On-premises: la modalidad de distribución de software tradicional que podemos instalar en nuestras propias máquinas, tantas veces como licencias hayamos adquirido. En resumen, la forma en la que siempre hemos comprado software, que recibe el nombre de Team Foundation Server 2012.

• Saas: que significa Software as a service, una modalidad de venta de un software que en lugar de instalarlo, lo utilizamos directamente sin preocuparnos por la infraestructura. Por lo general esto implica que ya no tendremos que realizar un desembolso económico grande para usar un producto, solo pagaremos por lo que consumamos. Esta versión recibe el nombre de Team Foundation Service y por ahora, permanece gratuita para equipos de hasta 5 miembros.

Las diferencias entre ambas versiones sobre todo radican en que la versión on-premises permite la personalización de las plantillas de procesos y tiene una mejor herramienta de generación de informes. Pero para el proceso que vamos a describir a continuación es indiferente cual de estas utilizar.

En los ejemplos que veremos a lo largo de este artículo hemos utilizado la versión Saas: Team Foundation Service. Para ello nos dirigimos primero a la página oficial: tfs.visualstudio.com. Allí nos dimos de alta y creamos una nueva cuenta:

En nuestro caso usamos el nombre de “programandonet” con una cuenta de Live ID que ya teníamos anteriormente. Una vez has finalizado el proceso, al entrar en: misitio.visualstudio.com, deberíamos encontrarnos algo parecido a esto:

En nuestro caso ya tenemos algunos proyectos creados, pero si es la primera vez, para poder seguir los ejemplos, deberíamos crear un proyecto nuevo, presionando el botón de “New Team Project”, y usando la plantilla de scrum:

Para poder entender mejor la plantilla de proceso que estamos usando, primero tendremos que definir la metodología que tenemos pensado usar: scrum.

¿Qué es scrum?

Podríamos definir scrum como un marco de trabajo, un conjunto de herramientas y protocolos a seguir con el fin de obtener un objetivo común: el éxito de un proyecto. Una metodología ágil que a pesar de estar enfocada en el desarrollo de software, es aplicable también a muchos otros campos como por ejemplo, el desarrollo de un vehículo de Formula 1.

La idea de un desarrollo ágil se fundamenta en la reducción de riesgos basándose en la división de un gran problema en problemas más pequeños. Estas divisiones serán acometidas como proyectos en si mismas, que deberán ser desarrollados a lo largo de un corto espacio de tiempo. A este ciclo se le denomina iteración y está compuesto por las fases de: planificación, análisis, diseño, codificación, revisión y documentación. Una vez finalizamos una iteración, se realiza una retrospectiva de cómo han ido las cosas, y se empieza una nueva iteración con las mejoras que se han propuesto.

Básicamente se asume que en un proyecto no todo va a ser como podemos pensar en un principio. Nos vamos a encontrar problemas no previstos y los requisitos van a cambiar con el paso del tiempo. Ante estos cambios lo único que podemos hacer es adaptarnos. Por esta razón dividimos el proyecto: para que las cosas que pueden ir mal vayan mal pronto, y así podamos ir afinando el proceso antes de que sea demasiado tarde.

Dentro de scrum estas iteraciones reciben el nombre de sprints y suelen durar de 2 a 4 semanas. El objetivo de cada sprint es que al finalizarlo, el equipo haya conseguido un producto potencialmente entregable. Es decir, algo que funcione, que se pueda probar y sobre lo que se puedan proponer modificaciones.

Roles

Antes de comenzar a trabajar debemos definir los roles de los diferentes miembros del proyecto. Scrum divide en dos grandes grupos de participantes:

Los comprometidos por el proyecto:

• Product owner: representa a cliente, a las personas que han solicitado el producto resultante de este proyecto. Es quien marca los requisitos y gestiona la prioridad de estos.

• ScrumMaster: es la persona responsable de que el proceso de scrum se ejecute correctamente. Se asegura de que se respeten las reglas y aísla al equipo de cualquier influencia externa. No hay que confundir este rol con el de jefe de equipo o project manager.

• El equipo: es el grupo de personas que tiene la responsabilidad del desarrollo del producto. Se auto-organiza, por esa razón no existe ningún rol de líder o jefe. Por lo general debe ser multidisciplinario, un conjunto de no más de 8 personas que puedan abarcar todas las tareas que conlleva el proyecto: análisis, diseño, desarrollo, pruebas, …

Y los implicados con el proyecto;

• Stakeholders (partes implicadas): Es esa gente que hace el proyecto posible, los implicados de alguna manera con el resultado del desarrollo. Los clientes, vendedores, usuarios finales…

• Administradores: Es la gente que se encuentra jerárquicamente por encima del proyecto. Los gerentes y managers que establecen el ambiente para el desarrollo.

En lo que respecta a la gestión que deberíamos realizar, solo serían relevantes los perfiles comprometidos con el proyecto. Para añadirlos a TFS lo primero que tendríamos que hacer es crear un equipo de trabajo. Para ello nos tendremos que dirigir al portal web principal de nuestro sitio de TFS (misitio.visualstudio.com), y dentro de este, al panel de configuración. Esto se hace presionando en el icono con forma de rueda, arriba a la derecha:

Si no lo hemos hecho ya, nos aparecerá una pantalla para que seleccionemos el proyecto que queremos configurar. Y al seleccionarlo, veremos que automáticamente el sistema nos ha creado un equipo con el mismo nombre que nuestro proyecto. Al presionar sobre este equipo podremos gestionar los miembros del mismo:

En este caso, hemos añadido a todo nuestro equipo de desarrollo que está formado por 4 personas.

Otra forma que tenemos de realizar esta operación es entrar en la página “home” (dashboard) de nuestro proyecto y fijarnos en el panel de equipo de nuestra derecha. Haciendo clic en “Manage all members…”:

El proceso

Como hemos comentado anteriormente, scrum es iterativo. Se divide en una serie de sprints que se van realizando hasta el momento en el que el proyecto se considera terminado. Una forma rápida de explicar el proceso sería el siguiente gráfico:

Aquí se puede observar que todo el proceso se inicia con la recogida de requisitos, y terminará cuando el resultado del feedback proporcionado por las partes implicadas sea que el producto está terminado.

Gestión del backlog

Asumimos que ya están todos los roles preparados para empezar con el proyecto, o al menos ya tenemos una figura de Product Owner, el propietario del producto. Entonces es el momento de empezar a recopilar requisitos. El product owner, además de ser la voz de nuestro cliente, también debe ser la persona que ordene y priorice aquellas necesidades que el cliente le ha comunicado.

Todos los requisitos relacionados con la aplicación, se recogen en un listado priorizado que recibe el nombre de pila de producto o Backlog. Y los elementos que encontramos en este backlog se denominan “user stories” o historias de usuario. Estas historias no son más que requisitos únicos, cortos, fácilmente redactarles, y que definen un requisito de forma rápida y en el propio lenguaje del usuario.

Es muy común que una historia de usuario esté definida mediante la plantilla:

As a [user] i want [something] so that [i can achieve that]

Donde los parámetros entre corchetes son sustituidos por el rol de la persona que lo solicita, qué es lo que le gustaría que pasará y cual el el objetivo que busca con dicho comportamiento.

Para la gestión del backlog, TFS nos ofrece dos herramientas que podremos encontrar en la sección “Work > backlog”. Una es la lista de requisitos como una lista ordenada según prioridad, que podemos ver en la imagen anterior. Y la otra es en forma de tablero, en la que podremos ver visualmente la evolución de las historias de usuario:

En adición, en la parte superior, conforme vayan desarrollándose los sprints, tendremos dos gráficas que nos darán un claro estado del proyecto y de la velocidad de nuestro equipo. Eso siempre y cuando se siga usando TFS en el resto de las fases.

Preparando el entorno

Antes de ponernos a programar, debemos definir nuestro marco de trabajo: responder preguntas como el tiempo del que dispone cada miembro de nuestro equipo, cuanto va a durar cada sprint inicialmente o qué tipo de especialidad tiene cada uno.

Una vez tenemos respuesta a estas preguntas tendremos que introducir estos parámetros en el portal de nuestro proyecto de Team Foundation Server.  Así pues, en la página principal del proyecto buscaremos a mano derecha la opción de “Configure schedule and iterations…”:

Al  hacer clic en esta opción aparecerá una ventana donde podremos decidir qué días tendrán lugar los próximos sprints:

Tampoco deberíamos obsesionarnos con configurar todos los sprints, ya que la duración de los mismos podría cambiar si el equipo considerara que son, o demasiado breves, o demasiado largos. En este sentido recomendamos mantener consistente la duración y que por lo general tengamos entre ninguno y un solo cambio de duración de un sprint por proyecto. Pero no obstante, creemos que es mejor ir configurando todo sprint a sprint.

Otro de los datos que serán muy útiles, sobre todo cuando nos encontramos con equipos multidisciplinares, es el cálculo de capacidades. Una vez tenemos definido el sprint, podemos seleccionarlo dentro de la pestaña “Work” e introducir para cada uno de los miembros del equipo, cual es la actividad que van a desarrollar, el tiempo que van a dedicar al trabajo por día y si tienen vacaciones durante el sprint:

En realidad es una tarea que no nos tomará más de 10 minuto y a cambio, gracias a estos datos, más adelante, seremos capaces de medir el trabajo que podemos asumir a lo largo de un sprint.

Planificación del sprint

Para comenzar con las liturgias que engloban al equipo, está la reunión de planificación del sprint o “sprint planning”. El resultado de esta reunión debe ser un listado de tareas que se van a desempeñar a lo largo del sprint para conseguir un objetivo marcado.

Al principio de la reunión, el product owner deberá explicar el backlog y proponer las historias de usuario más prioritarias. Y el equipo deberá realizar preguntas sobre las dudas que puedan surgir, evaluar estos requisitos y decidir cuales son los que se compromete a entregar a final de sprint.

Desde la vista del product backlog del tfs podremos arrastrar los elementos que hemos planificado encima del sprint que les corresponda:

Y haciendo doble clic en la user story, podremos añadir comentarios con la información extra que recolectemos durante la exposición del product owner.

Además de esto, el equipo deberá dividir las historias en tareas. Estas tareas serán estimadas (usando el poker planning, por ejemplo) y en algunos equipos hasta se auto-asignan según las cualidades de cada uno.

Así que una vez hemos asignado los elementos del backlog al sprint actual, podemos hacer clic la etiqueta y añadir tareas que dependan de los requisitos. Haciendo doble clic en las tareas podremos añadir detalles sobre su implementación, las estimaciones e incluso a qué actividad se refiere:

Lo interesante de asignar la actividad de una tarea es que automáticamente podremos ver en unas barras a la derecha si estamos excediendo el tiempo de trabajo de las personas dedicadas a esas actividades o por el contrario si podríamos comprometernos a realizar más trabajo.

Ahora ya tememos todo preparado para que el equipo empiece a trabajar…

Trabajo diario

Dentro de un sprint, dividimos el trabajo por días. El empezar la jornada, aunque algunos equipos lo dejan para el final del día, tiene lugar la daily meeting o standup meeting. Ambas nomenclaturas definen bien este tipo de reuniones ya que se realizan de forma diaria y los asistentes deben estar de pie. Esto responde a que esta reunión tiene que durar un máximo de 15 minutos, y si permaneciéramos sentados la gente se siente cómoda y es más fácil extenderse.

A un daily meeting puede asistir cualquier persona interesada, pero solo tendrán voz los roles comprometidos por el proyecto: el equipo, el scrummaster y el product owner. Generalmente se hace una ronda en la que cada uno de los asistentes debe responder a tres preguntas:

• ¿Qué hice ayer?
• ¿Qué problemas encontré?
• ¿Qué voy a hacer hoy?

Esto no se hace para controlar a las personas, si no para favorecer la comunicación entre los miembros del equipo. Casi todas las liturgias de scrum van dirigidas a este objetivo. Se sustenta en la premisa de que si hay buena comunicación, es más fácil que las cosas salgan bien.

La ubicación de esta reunión debería ser todos los días la misma y a la misma hora, para que no exista duda alguna. Y sería interesante realizarla junto a la scrumboard. Esto es una tabla sobre la que vamos a ir gestionando las tareas del sprint, de la que ya nos habló Albert Cumplido en este artículo.

Team Foundation Server nos proporciona un tablero virtual para scrum que encontraremos en las sección “Work > board”:

Como podemos observar automáticamente nos muestra el tablero del sprint actual y podemos agrupar las tareas por elemento del backlog o por miembro del equipo. La mejor parte de esta scrumboard virtual es que podemos ir moviendo las tareas y estas se irán actualizando en tiempo real. Eso si, en scrum, cuando una tarea se da por terminada (se han cumplido todos los requisitos de la definición de “hecho”), no puede volver atrás. Si por A o por B el desarrollo de esta tarea ha tenido unas consecuencias no esperadas, esto debería repercutir en la aparición de un bug o una nueva historia que subsane los problemas que hayamos generado.

Otro de los artefactos relacionados con scrum en particular, y las metodologías ágiles en general, es el burn down chart. Una gráfica que podemos ver en la parte superior derecha de la scrumboard. Al hacer clic sobre ella podremos tener una vista ampliada, en la que se observarán mejor los detalles de la gráfica:

Es importante que el equipo tenga clara esta gráfica, ya que nos muestra el estado actual del sprint. Si estamos muy por encima de la línea de tendencia ideal es que vamos con retraso y si estamos por debajo, podría significar que hemos sobre-estimado el esfuerzo de las tareas.

Pero para que TFS nos muestre todos estos datos de una forma correcta, es necesario que el equipo vaya actualizando las tareas día a día. Y el control de código fuente junto con el Team Explorer de Visual Studio, nos van a ayudar.

Bastará con que dentro de Visual Studio, cuando un programador vaya a realizar un checkin, asocie mediante drag ‘n drop, una tarea. Esto se realiza en el panel de “Peding Changes” de la ventana de “Team Explorer”:

El punto negativo y que podría resultar tedioso es que el esfuerzo que le hemos dedicado a la tarea, deberemos introducirlo manualmente. Con respecto a este tema, una práctica muy útil es que antes de irnos a casa, cada miembro del equipo debe ser responsable de haber actualizado sus tareas y la scrumboard. O al menos si sería necesario hacerlo antes de cada daily meeting.

En scrum no se aceptan tareas con una estimación de duración de más de una jornada de trabajo. Si así fuera, se debería dividir en varias tareas más pequeñas. Por lo que todos los días deberá haber movimiento en la scrumboard.

El último punto del trabajo a tener en cuenta desde el punto de vista de TFS sería el Continuous Integration, que tendría lugar con la ayuda de la configuración de los procesos de build. Aunque este punto, quizá lo podamos tratar en un futuro con mucho más detalle.

Revisión del sprint

Una vez hemos llegado a la fecha de finalización del sprint, nos encontramos en el momento de la revisión del trabajo realizado. Tanto si hemos terminado todas las tareas como si no, se deberá informar y apuntar, para tenerlo en cuenta en posteriores sprints.

En el proceso de revisión es necesario involucrar a todos lo roles definidos en el proceso de scrum, tanto los implicados como los comprometidos. Se presentará el producto tal y como está en ese momento. Se responden preguntas y se admiten sugerencias.

La forma que nos provee TFS de recolectar el feedback de las partes interesadas del proyecto es la herramienta “Microsoft Feedback Client for TFS 2012”. Todo el proceso comienza con la petición de este feedback.

Si nos dirigimos a la página “home” de nuestro proyecto de Team Foundation Service, encontraremos en el widget de “Activities”, una opción llamada “Request Feedback”. Al pulsarla, se abrirá una nueva ventana donde se nos permitirá rellenar los detalles de esta petición:

Los tres detalles que nos permite rellenar son: los invitados a dar feedback, la forma de acceder a la aplicación para poder probarla y los elementos que deben tener más en cuenta, por ser los objetivos principales del sprint, a la hora de revisar.

El resultado de enviar esta petición será un email a cada uno de los stakeholders especificados, donde se le informará de todo. En este email además encontraremos un enlace para descargar la herramienta de feedback de Microsoft de forma gratuita.

Después de instalar el “Microsoft Feedback Client”, al ejecutarlo, lo primero que nos pedirá es la conexión con el TFS:

Acto seguido la aplicación nos pedirá que abramos la demo de prueba, siguiendo las instrucciones que especificamos anteriormente. Y después irá pasando por todos los elementos que indicamos que se debían revisar, para que el usuario pueda añadir comentarios, capturas de pantalla, notas de voz, …

Después de enviar el feedback, podremos acceder a él desde el portal de TFS, “Work > work items > Feedback”:

Es muy recomendable que la reunión de revisión sea en persona y con todos los roles a la vez. No obstante, de cualquier forma, también es muy recomendable usar la herramienta de feedback para poder almacenar en TFS todos los datos y así poderlos revisar con más calma. Tanto si la persona que reporta está o no en la reunión.

Retrospectiva  del sprint

La última reunión que tiene lugar en a lo largo de un sprint es la retrospectiva. Una vez tenemos el feedback, esta vez reuniremos al scrummaster y el equipo, aunque el product owner puede estar invitado de oyente.

A lo largo de esta reunión se debatirán temas como la gráfica de burn down, la velocidad del equipo, las cosas que han ido bien en el sprint, que podría haber ido mejor y lo más importante: que cosas se van a hacer de forma diferente, buscando sacar el mejor resultado, en el siguiente sprint.

En esta reunión será muy importante manejar todos los datos que hemos ido recolectando con TFS, e incluso almacenar un resumen con las conclusiones de la reunión también dentro del sistema. De esta forma todo quedará archivado y accesible por todos los miembros del equipo.

Es la reunión donde más partido sacaremos a TFS de todas.

Al finalizar esta reunión deberemos volver al primer paso del proceso y volver a empezar con el siguiente sprint. Eso si, esta vez habiendo retroalimentado el proceso con la experiencia del sprint anterior.

Conclusiones

Aún sabiendo que scrum varía en cada equipo que se aplica, hemos intentado exponer un proceso lo más aséptico que hemos podido, para observar la potencia de TFS.

Hemos de reconocer que scrum nos parece un escenario muy bueno para el desarrollo de software. Y en este sentido, tantoTeam Foundation Server 2012 como Team Foundation Service han demostrado ser dos herramientas muy completas que nos ayudarán mucho con la gestión del proceso.

Todo esto a pesar de que muchos más detalles sobre la personificación del proceso, se nos han quedado en el tintero, como por ejemplo: las builds, la entrega continua, la integración continua, los code reviews o la potencia de las herramientas de testing.

Nosotros lo hemos probado y hemos llegado a la conclusión de que nos gusta. Si aún no lo has hecho, te invitamos a que uses una cuenta gratuita de Team Foundation Service, y durante el próximo sprint, realices un seguimiento en paralelo con esta herramienta, para que saques tus propias conclusiones.