Experiencias usando SCRUM para el desarrollo de software: 1

Luego de pasar mucho tiempo desarrollando software de la llamada "manera tradicional", me doy cuenta que muchas cosas se pudieron hacer mejor si se hubiera utilizado metodologías ágiles como scrum.

En ocasiones recuerdo cuando teníamos reuniones con algún cliente, nos solicitaba un software que hiciera aquella función u otra , pero no daba mas detalle, no acompañaba el desarrollo, solo esperaba que para el tiempo que el tenia estipulado, se concretara un proyecto y que funcionara a las mil maravillas.

Con que ilusión asentábamos con la cabeza sin reprochar, sin confrontar, sin siquiera recabar por mas información. Pero bueno, como dicen por ahí siempre hay una luz al final del camino y esta me parece hasta hora es SCRUM.

No quiero entrar en definiciones exhaustivas  pero les daré la definición que le doy a la gente cuando me pregunta que es scrum: "SCRUM es un marco de trabajo flexible en el que las personas, las interacciones, la confianza, el software funcionando y respuesta ante el cambio son los principios que rigen el desarrollo de un proyecto".

Luego resulta la pregunta de que ventajas tiene esto respecto a los otros métodos de trabajo, y por donde empezar: 
Bueno pues el equipo de desarrollo se pone las metas para el sprint
Hay re-alimentación  temprana de parte del cliente
El equipo se siente valorado
El cliente se integra al desarrollo del proyecto
Si hay algún problema se busca una solución , se prueba , si funciona esta bien, sino, se busca otra y listo.
No hay sobreesfuerso.

y muchas otras más.

Bueno pero como esto se trata de contar la experiencia con scrum, puedo decir que me gusta, facilita la realización de los proyectos, no se carga una persona con el conocimiento de un negocio, sino que un equipo esta en capacidad de hacerlo por si solos. 

Para poder ser conscientes del cambio que hay que dar, se debe empezar por dejar "el ego atrás"  pues siempre es el primer impedimento silencioso que nos hace reacios al cambio.

Y este punto es muy importante pues si veníamos trabajando de otra forma, algunas veces somos héroes que conocen código que nadie mas a tocado o quiere tocar, algunas veces conocemos negocios que son complejos, y explicarlos son una tarea difícil , otras veces  dejar a cargo a alguien cuando uno se va de vacaciones es una pesadilla, siempre lo van a llamar a uno.

Estas y muchas más situaciones me habrán pasado con los años y que probablemente se me olvido mencionar. Debo aclarar que esta es mi muy humilde y sincera manera de contarles mis experiencias usando SCRUM para el desarrollo de software.

Luces para calabazas

Echa un vistazo al Tweet de @svalencian: https://twitter.com/svalencian/status/381974286690295809

Extractos 3 - del libro SCRUM Y XP DESDE LAS TRINCHERAS de Henrik Kniberg

Por qué insistimos en que todos los equipos hagan retrospectivas 

Lo más importante de las retrospectivas es asegurarse de que tienen lugar. Aun así, todo el mundo coincide en que las retrospectivas son extremadamente  útiles. De hecho, yo diría que la retrospectiva es el segundo evento más importante de Scrum (siendo el primero la reunión de planificación de Sprint) ya que ¡es tu mejor oportunidad para mejorar! 

Difundiendo las lecciones entre los equipos

Reglas importantes para la persona que actúa como “puente de conocimiento”:

• Debería ser bueno escuchando. 

• Si la retrospectiva es poco activa, debería estar listo para realizar preguntas simples pero bien apuntadas para estimular la discusión dentro del grupo. Por ejemplo, “si pudierais rebobinar y hacer este Sprint otra vez desde el día 1, ¿qué haríais de forma diferente?” 

• Debe estar dispuesto a pasar tiempo visitando todas las retrospectivas de todos los equipos. 

• Debería tener algún tipo de autoridad, de forma que pueda actuar sobre las sugerencias que estén fuera del control del propio equipo.

Descansos entre Sprints 

Como mínimo, intentamos que la retrospectiva y la subsiguiente reunión de planificación de Sprint no ocurran el mismo día. Todo el mundo debería tener al menos una buena noche de sueño sin Sprint antes de comenzar el siguiente Sprint.

Scrum se enfoca en las prácticas de organización y gestión, mientras que XP se centra más en las prácticas de programación. Esa es la razón de que funcionen tan bien juntas: tratan de áreas diferentes y se complementan entre ellas. 

Ritmo sostenible / trabajo enérgico

Hace cosa de un año uno de nuestros equipos (el más grande) estaba trabajando un número insalubre de horas extra. La calidad de la base de código era pésima y habían pasado la mayor parte del tiempo apagando fuegos. El equipo de pruebas (que también estaba haciendo horas extra) no tenía ninguna 

posibilidad de hacer aseguramiento de la calidad en condiciones. Nuestros usuarios estaban enfadados y la prensa nos estaba devorando vivos. Después de unos meses conseguimos disminuir las horas de trabajo a un nivel decente. La gente comenzó a trabajar en horarios normales (excepto durante 

algunas crisis de proyecto, a veces). Y, oh sorpresa, la productividad y la calidad mejoraron notablemente. Por supuesto, reducir las horas de trabajo no fue en absoluto el único aspecto que condujo a la mejora, pero todos estamos convencidos de que tuvo mucho que ver.

Cómo hacemos pruebas 

Nuestra experiencia nos dice que eso rara vez funciona. Habrán errores graves. Si la calidad tiene algún valor para ti, es necesario algún tipo de fase de pruebas de aceptación manuales. Se trata de que encargados de pruebas dedicados que no son parte del equipo machaquen el sistema con ese tipo de pruebas que el equipo de Scrum no pudo imaginar, o no tuvo tiempo de hacer o no contaban con el hardware necesario para implementar. Los encargados de pruebas acceden al sistema en la forma exacta en la que los usuarios finales lo harán, lo que significa que debe hacerse manualmente (asumiendo que tu sistema sea para usuarios humanos).

Así que ¿cómo maximizamos la calidad del código desarrollado por el equipo Scrum? Bueno, hay muchas maneras. He aquí dos que nos funcionan muy bien: 

• Incluir encargados de pruebas en el equipo Scrum - Me parece una buena práctica aunque las empresas consideren que no es necesario.

• Hacer menos cosas en cada Sprint.

El encargado de pruebas es quien da el visto bueno.

Un bonito efecto secundario de esta práctica es que el equipo tiene ahora una persona que está perfectamente preparada para organizar la Demo del Sprint.

Extractos 2 - del libro SCRUM Y XP DESDE LAS TRINCHERAS de Henrik Kniberg

Continuación de lo mejor a mi parecer de este libro:

Definiendo la meta del Sprint
"La meta de Sprint debería responder a la pregunta fundamental “¿Por qué hacemos este Sprint en vez de irnos todos de vacaciones?”. De hecho, una forma de obtener la meta del Dueño de Producto es precisamente hacerle esa misma pregunta."

Dividiendo las historias en tareas.
"La diferencia es muy simple. Las historias son entregables de los que el Dueño de Producto se preocupa. Las tareas son no-entregables, o aspectos de los que el Dueño de Producto no se preocupa."

Definiendo el sitio y la hora para el Scrum diario

"Desventaja de Scrums por las tardes: cuando llegas al trabajo por la mañana, tienes que acordarte de qué le dijiste a la gente sobre lo que deberían hacer hoy.

Desventaja de los Scrums por las mañanas: cuando llegas al trabajo por la mañana, debes acordarte de qué hiciste ayer para informar sobre ello hoy."

"En mi opinión, la primera desventaja es peor, ya que lo más importante es lo que vas a hacer, no lo que hiciste ayer.Lo más importante es que sea a una hora a la que todo el equipo acepte con total convencimiento."

Dónde trazar la línea 

"OK, el tiempo se está agotando. De todos los asuntos que queremos resolver durante la planificación de Sprint, ¿qué abandonamos si nos quedamos sin tiempo? 

Bueno, normalmente uso la siguiente lista de prioridades: 

Prioridad 1: Una meta de Sprint y una fecha para la demo. Esto es lo mínimo que necesitas para comenzar un Sprint. El equipo tiene una meta y una fecha de finalización, y pueden trabajar directamente con la Pila de Producto. Apesta, sí, y deberías considerar seriamente organizar una nueva reunión de planificación de Sprint mañana mismo, pero si realmente necesitas que el Sprint comience 

entonces probablemente puedas hacerlo con esto. Para ser honesto, yo nunca he empezado un Sprint con tan poca información. 

Prioridad 2: Lista de qué historias ha aceptado terminar el equipo en este Sprint. 

Prioridad 3: Una estimación para cada historia del Sprint. 

Prioridad 4: “Como probarlo”, relleno para cada historia del Sprint. 

Prioridad 5: Cálculos de velocidad y recursos, como chequeo de la planificación del Sprint. Incluyendo una lista de los miembros del equipo y sus compromisos (de otra forma, no podrías calcular la velocidad). 

Prioridad 6: Un sitio y hora específicos para la realización del Scrum diario. Solo necesitas un momento para decidirlo, pero si te quedas sin tiempo el Scrum Master puede simplemente decidir esto después de la reunión y mandar un correo a todo el mundo. 

Prioridad 7: Historias divididas en tareas. Esta división puede sin embargo hacerse diariamente durante los Scrum diarios, pero interferirá levemente el flujo del Sprint.

Estimando en días vs horas:
1 día-hombre real = 6 horas-hombre reales
(no causa mucho daño sobre-estimar un poco). Elegante y simple. También comparto este apunte pues es mejor quedarle bien al cliente en un tiempo prudente, que satisfacer al cliente con un estimado, y luego empezar a levantar la mano para pedir tiempo que puede no tenerse.

Invitación "Los TLC y las barreras tecnológicas"

La Universidad de los Andes realizará el foro “Los Tratados de Libre Comercio y las Barreras Tecnológicas - El Caso de la Compatibilidad Electromagnética”, el día jueves 22 de agosto de 2013, en el Auditorio SD 1003 del Edificio Julio Mario Santo Domingo. EL foro contará con grandes personalidades, incluyendo al Dr. Ghery Pettit, Presidente de IEEE Electromagnetic Compatibility Society.

El objetivo del foro es, en primer lugar, analizar la legislación colombiana en materia de reglamentos técnicos aplicables a la compatibilidad electromagnética (incluidos los TLC ya ratificados y aquellos en proceso de serlo), así como los requisitos en materia de instalaciones y equipos para las pruebas, la formación del recurso humano y la cultura de la gestión de la compatibilidad electromagnética a lo largo del desarrollo de los productos. A partir de este análisis, se pretende identificar políticas públicas que faciliten la reglamentación e implementación de requisitos en materia de compatibilidad electromagnética, cruciales para que las empresas colombianas puedan desarrollar todo su potencial exportador, salvaguardando al mismo tiempo los derechos de los consumidores colombianos.

Estoy convencido de que el tema del foro puede ser de interés para usted, por lo que me complace invitarlo a asistir a este evento. La asistencia es gratuita, previo registro en la página web http://foroemc.uniandes.edu.co, donde también  podrá encontrar información detallada del evento.

Cordialmente,

Roberto Bustamante Miller

Presidente Capítulo IEEE EMC Colombia

Extractos 1 - del libro SCRUM Y XP DESDE LAS TRINCHERAS de Henrik Kniberg

Luego de leer el libro, me tome la libertad de sacar los apuntes más significativos y representativos que me encontré:

"En palabras de Ken Schwaber, Scrum no es una metodología, es un marco de trabajo. Eso quiere decir que Scrum no te va a decir exactamente lo que debes hacer".

"El dueño de producto debe comprender cada historia (normalmente él es el autor, pero en algunos casos otras personas añaden solicitudes, que el Dueño de Producto puede priorizar".

"El propósito de la planificación de Sprint es proporcionar al equipo suficiente información como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas, y para ofrecer al Dueño de Producto suficiente confianza como para permitírselo".

"Una planificación de Sprint produce, concretamente: 

• Una meta de Sprint. 

• Una lista de miembros (y su nivel de dedicación, si no es del 100%) 

• Una Pila de Sprint (lista de historias incluidas en el Sprint) 

• Una fecha concreta para la Demo del Sprint. 

• Un lugar y momento definidos para el Scrum Diario"

"La razón por la que el equipo y el Dueño de Producto deben asistir a la planificación de Sprint es que cada historia contiene tres variables que son muy dependientes unas de otras".

Dueño de Producto

"El Dueño de Producto comienza la reunión resumiendo cuál es su meta para el Sprint y las historias más importantes. A continuación, el equipo las repasa y les asigna una estimación, comenzando con la más importante".

Planificación de Sprint 

"El propósito de la planificación de Sprint es proporcionar al equipo suficiente información como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas, y para ofrecer al Dueño de Producto suficiente confianza como para permitírselo". 

"El alcance y la importancia los fija el Dueño de Producto. La estimación la proporciona el equipo. Durante una planificación de Sprint, estas variables sufren un ajuste fino y continuo a través del diálogo cara a cara entre el equipo y el Dueño de Producto".

"Todo en Scrum tiene una duración determinada (time-boxed). Me encanta esa única, simple y consistente regla".

"Aprende a mantener tus duraciones determinadas, aprende a establecer duraciones realistas. Esto aplica tanto a las reuniones como a los Sprints".

"Los Sprints cortos están bien. Permiten a la compañía ser “ágil”, es decir, cambiar de dirección frecuentemente.

Sprints cortos = ciclo de feedback corto = más entregas y más frecuentes = más feedback del cliente = menos tiempo desarrollando en dirección incorrecta = aprender y mejorar más rápido, etc. "

"Pero los Sprints largos tampoco están mal. El equipo tiene más tiempo para conseguir impulso, tienen más espacio para recuperarse de los problemas que surjan y aun así cumplir la meta del Sprint, tiene menos carga de gestión en términos de reuniones de planificación de Sprints, Demos, etc".

Excel en php

Para generar un archivo excel en php se debe crear una tabla la cual contenga la estructura del encabezado y correspondiente se recorre un arreglo con los datos a mostrar se va llenando de posición en posición.

Ej:

Tener una variable  llamada $html_tabla como otra variable se le pasa el borde.

$html_tabla .= ' ';

Dato_1

Dato_2

Dato_3

Dato_4

Luego con un ciclo recorremos el arreglo:

foreach($datos as $i => $dato) { $cant = ($i%2 == 0) ? 'tr0' : 'tr1'; $html_tabla .= ' ' . $dato['ID'] . ' ' . $dato['NOMBRE'] . ' ' . $dato['APELLIDO'] . ' '; } $html_tabla .= " ";

Por último colocamos estas cabeceras que permiten tener el archivo para descargar e imprimimos la tabla

header('Content-Type: application/octet-stream');

header('Content-Disposition: attachment; filename=InformeIndividualEstado.xls' );

header('Content-Transfer-Encoding: binary');

header('Expires: 0');

header('Cache-Control: must-revalidate, post-check=0, pre-check=0');

header('Pragma: public');

echo $html_tabla;