Reunion 22/01/2011

3 respuestas

Día: 22/01/2011
Hora: 10:00 –13:30
Lugar: Sala 26, Centro Cívico Zona Sur, Plaza Juan de Austria – Valladolid

Taller SCM
Aprendizaje y comparativa acerca de distintos sistemas de control de versiones: GIT, Mercurial y Plastic SCM

ASISTENTES

1. Javier Santana
2. Feliz Lopez
3. Jose Da Rocha
6. Isidro Merayo
7. Javier Acero
8. Javier Gamarra
9. Jorge
10. Rafael Cano Parra
11. Daniel Primo
12. Mario de Frutos
13. Eduardo Ferrandez
14. Susana
15. Pablo Santos
15. Amalia Hernandez
16. Jorge Jimenez

RESUMEN

La charla/taller de hoy, consistía en hacer un acercamiento a Git, y PlasticSCM. De la mano de Pablo Codice Software , uno de los desarrolladores de Plastic SCM lo hemos tenido mucho más fácil.

Pablo nos ha contado los entresijos de Git, utilizando una presentación de Scott Chacon y nos ha enseñado desde dentro como funciona Git (ls -C .git), para poder entender un poco más, que estamos haciendo en realidad cuando tecleamos git commit -m “Modificado fichero”.
Conceptos como:

  • DAG, Directed Acyclic Graph, diciendolo de manera simple es la forma en la que se almacenan los objetos Git. Todos se comprimen y se identifican por un hash SHA-1.
  • Cuatro tipos de objetos en Git:

Blob: todos los objetos son datos
Tree: representan los directorios
Commit: se refiere  a un tree
Tag: etiquetas

Como Pablo ha comentado, la implementación de Git es una pasada, brutal. Sencilla, pero tan eficiente: la distribución de información en varios directorios, sacar datos de todos los commmit, etc…

La charla dio para mucho más: momentos distendidos acerca del buen marketing de Git, explicación de la forma de trabajo en Codice Software  por supuesto una presentación de Plastic SCM.

Plastic SCM, es sobre todo una herramienta gráfica.

Las joyas de la corona de Plastic son:  la creación de ramas, mostrar la diferencias entre ramas, facilidad para crear una nueva release  (http://www.plasticscm.com/features/task-driven-development.aspx)

Se ofreció en streaming la charla como primer experimento porque fue un poco precipitado. Parte de la grabación de la charla la podeis encontrar aqui (perdonad la calidad, mejoraremos en siguientes reuniones):

Algunas imágenes del Taller SCM:

Muchísimas gracias a Pablo por su charla y a todos los asistentes.

En las cañas agiles se plantearon proyectos, reuniones, … vamos a por ellos!!

Reunion 29/11/2010

Deja una respuesta

Día: 29/10/2010
Hora: 19:30 – 21:30
Lugar: Sala 30, Centro Cívico Zona Sur, Plaza Juan de Austria – Valladolid
Posteriormente 5 valientes fueron tomar unas cañas para seguir hablando.

AGENDA

Motivación

ASISTENTES

1. Javier Santana
2. Feliz Lopez
3. Jose Da Rocha
4. Dani Carrión
5. Arancha (e Isabel nuestra benjamina)
6. Isidro Merayo
7. Nestor Diaz
8. Amalia Hernandez
9. Jorge Jimenez
10. Alvaro García
11. Ignacio Cruzado Nuño

RESUMEN

La reunión de Noviembre tenía un único tema: La motivación.

Alvaro nos expuso el tema mediante la siguiente presentación, disponible para todos:

Presentacion motivacion

La charla fue muy amena y participativa.

Descubrimos gracias a Alvaro las teorias de la motivación:

  • Piramide de Maslow
  • Motivación-Higiene de Herzberg

fundamentos, y como en toda teoria no compartes todo lo que muestran.

Una parte importante de la charla discurrió acerca de la automotivación.

Todos necesitamos una motivación que puede encontrarse en nuestro trabajo, en lo que hacemos o puede ser esta sea algo externo pero que nos llene tanto que nos lleva a encontrar la satisfacción personal. Siempre hay factores que nos influyen a la hora de buscar y encontrar la motivación.

Se llego a plantear incluso si hay motivación por sexos en lo relativo al trabajo. Si el reconocimiento del trabajo bien hecho, como parte de la motivación, debe ser distinto en hombres y en mujeres.

Pero con los comentarios tanto de la parte masculina como de la femenina quedo claro, que tod@s buscamos reconocimiento al trabajo que como profesional realizas, independientemente del sexo.

Seguimos comentando, siguiendo el hilo de las transparencias:

  • Motivación en los equipos: permitir esa independencia del equipo que sabe autogestionarse, estar atentos a las necesidades para facilitarles el trabajo. Es verdad que toda esta parte se planteó desde la visión de equipos ágiles.
  • Jefe != Lider. Cada uno comentó cual era su mejor y su peor jefe, que en algunos casos coincidían. Una reflexión al hilo fue que en muchas ocasiones nosotros mismos somos nuestros mejores y nuestros peores jefes.

Incentivos

Fue el otro punto fuerte de la reunión. Alvaro comentó el vídeo que Dan Pink, que para el que no lo haya visto es muy recomendable.

¿Que pasa con los incentivos monetarios? ¿Funciona?

Comentamos las “horas libres” que se le otorgan al equipo, al final del sprint. ¿Como las utilizan? Pues hay de todo, desde gente que se pone a realizar mejoras para los procesos internos, o las dedica a autoformación o incluso que se dedican a Facebook.

La charla mas o menos se dio por finalizada aquí, para continuar con unas cañas.

Muchas gracias Alvaro por presentar este tema para aprender mas y generar debate.

12 meses haciendo Scrum

12 respuestas

Buenas a todos!

La verdad es que no sé muy bien como empezar… y este siempre ha sido un buen comienzo jejeje.

Hace más o menos un año, conseguí que aceptaran mi propuesta de cambiar la forma de gestionar el proyecto “Estrella” de la división donde trabajo. Este cambio vino ocasionado por el semi-caos en el que nos encontrábamos a causa de problemas internos. En realidad, tuve suerte en este aspecto, fue recibido con buenos ojos, aunque con escepticismo, por parte de la dirección. Los cuales me dijeron “Adelante, necesitamos cambiar esta forma de llevar las cosas, y que todo el mundo vuelva a estar ilusionado con su trabajo”.

Realmente este era uno de los principales problemas, gente desmotivada y quemada por siempre hacer lo mismo año tras año. El otro gran problema, fue el ir dando trabajo a cada miembro del equipo, según iba llegando, asignando tareas según carga, especialidad de cada persona, y urgencia. Es decir, saliendo adelante como bien se podía. La gestión del caos dirían algunos.

Pues bien, Lo primero fue concienciar e informar a todo el mundo, de qué era eso de Scrum y la Agilidad. Tarea muy agradable y fácil para alguien que se había empapado bien de cómo funcionan estos temas, además de estar totalmente de acuerdo con los principios que ello conlleva (Manifiesto Ágil). Después de que todo el mundo diera su aprobado, nos pusimos manos a la obra.

Lo siguiente que hicimos, fue repartir papeles.

  1. Propietario del producto (Product Owner). Esto fue fácil de elegir, cliente interno, mi responsable técnica de división.
  2. Equipo. También fue fácil, las 7 personas de mi equipo a las que gestionaba en el proyecto.
  3. Scrum Manager. Yo mismo, al menos por el principio, ya que era el que me había implicado más en este cambio y el que más conocía estos temas.

Yo como “Scrum Manager” junto con el “Product Owner” definimos como tenía que ser la estructura del “Product Backlog” en un principio, y junto con el equipo, definimos el documento “Sprint Backlog”. Estos dos documentos han ido evolucionando en progresión junto con nosotros y nuestras necesidades.

Teniendo todos los papeles asignados, decidimos una fecha que encajase, para que todas las tareas pendientes de terminar en ese momento, se finiquitaran y pudiésemos empezar el 1º Sprint, lo más limpio que se pudiera. Yo por mi lado, acaparé una pizarra de la sala de reuniones y la acondicioné, para eso que me llamaba tanto la atención “Gestión de tareas por Posit” con un tablero Kamban. Y después de tener todo organizado para empezar, dimos el primer gran paso, la reunión de inicio del 1º Sprint!!!

El 1º Sprint fue el más complicado, pero también el más motivador, tanto para mí, como para el equipo. Creo que lo que más agradable fue ver como los miembros del equipo se divertían “jugando” a estimar con la técnica de “Planning Poker” y como se abalanzaban sobre las tareas para autoasignarselas.

Los principales problemas que detecté en este Sprint, fue la difícil adaptación de los miembros del equipo hacia la auto-gestión y auto-organización. Desde el 1º día esperaban a que yo, como su antiguo jefe de proyecto, les diese las pautas de como implementar y realizar sus tareas, además de esperar igualmente a que les dijese que tarea tenían que asignarse después de terminar otra. Poco a poco esta “manía” se les fue quitando y al tercer o cuarto Sprint ya había desaparecido.
Impresionante-mente al finalizar este 1º Sprint, todas las tareas estaban terminas y funcionando para pasar a producción.

La demo también fue bastante motivadora, enseñando orgullosamente todas las funcionalidades implementadas. Más motivación al canto!

A medida que fuimos metiéndonos en un Sprint tras otro, algunos problemas fueron aflorando. Principalmente la dificultad al estimar la duración de las tareas. Esta ha sido recurrente hasta ahora, y creo que siempre estará ahí. Ya que, aunque las estimaciones cada vez se han ido afinando mas, y la mayoría de veces son acertadas, muchas veces nos encontramos con problemas imprevistos que no supimos ver al discutir sobre la estimación de determinada funcionalidad.
Después de discutir mucho sobre este tema en las retrospectivas, hemos llegado a la conclusión, de que la mejor forma para evitar estos problemas es, dividir al máximo las tareas complejas, para así evaluar más acertadamente las tareas resultantes mas simples.

Otros problemas con los que hemos tenido que lidiar han sido los siguientes:

  • Cambios de tareas a mitad de sprint. Este problema fue de fácil solución. Solo dejamos añadir tareas, si hay alguna/as que el “Product Owner” esté dispuesto a retrasar a siguientes Sprints, que sumen lo mismo que esa nueva en su estimación, que no afecte a ninguna otra y si realmente es necesario para el cliente.
Supongo que habrá gente que no esté de acuerdo con esto, y que diga que Scrum no permite estos cambios, pero yo pienso que así es la agilidad, adaptarse a las necesidades en cada momento :P

  • Mala comunicación con la parte comercial al no poder estar presentes en las demos. Nuestro centro está en Valladolid (Boecillo) y nuestros comerciales en Tres Cantos (Madrid). Con lo que no les suele ser fácil desplazarse cada dos semanas a la demo. Para solucionar este problema, junto con el “Product Owner” hacemos un documento de resumen de la demo, explicando cada nueva funcionalidad del producto, además de otro tipo de demos especiales para ellos, en las que digamos juntamos varias de las nuestras. Ahora estoy mirando para poner un streaming de vídeo de las mismas y que puedan verlas desde donde quieran, aunque ya sé que no es lo mismo, es mejor que perdérselas ;D
  • Implementación de una tarea, haciéndola algo diferente a lo que el “Producto Owner” había pensado. Por ejemplo exportar informes a formatos Office, el equipo hacerlo a formatos de OpenOffice en vez de Microsoft Office como se quería. Esto al principio solía ser habitual, pero lo hemos corregido (casi del todo) actualizando diariamente un servidor de desarrollo interno, en el que se pueden ver las funcionalidades que se van implementando. También me encargo de tener un documento explicativo de cada funcionalidad, antes de la reunión de inicio de Sprint, escrito entre el “Producto Owner” y yo. Así queda todo mucho más claro y los miembros del equipo, pueden pensar en cada tarea antes de esta reunión y tener las dudas preparadas.
  • Aparición de errores en las implementaciones después de la demo. Este problema es uno de los peores. Aquí hemos puesto varios frentes. El 1º, empezamos a meter poco a poco técnicas de TDD y Extreme Programing, intentando plagar todo con test para que exploten al mínimo fallo (aún nos queda mucho). Y 2º metimos una 4º columna en el tablero Kamban, en la cual otra persona de la que ha hecho la implementación, tiene que probar la historia de usuario, para que este terminada-terminada, incluyendo revisión de código.

Ha habido muchas cosas que destacar sobre cómo empezamos al principio y cómo vamos evolucionando con la opinión y experiencia de todos. Pero para no alargar esta entrada demasiado, os pongo solo unas pocas:

  • Al empezar a meter técnicas de Extreme Programing, la que más suele chocar es la programación en pareja. Normalmente se suele pensar, que se tira el tiempo de una persona, al ponerse dos a trabajar en el mismo ordenador.
    Pero como yo me convencí de que esto es erróneo, fue al poner a dos personas con unas habilidades, destacadamente distintas a programar juntas. Una sabe programar, estructurar el código y utilizar el lenguaje de programación bastante mejor que la otra. Y por su parte la otra, sabe abstraerse de la solución, pensar más globalmente y contener en su mente problemas más complejos. Esta combinación de mentes, a la hora de resolver un problema y plasmarlo en código es la mejor que me he encontrado, haciendo que los resultados sean impresionantes. Sin hablar ya, de todos los beneficios que conlleva, como el aprendizaje mutuo, la doble revisión, rápida entrada en estado de flow, mejora de moral, propiedad colectiva del código, etc. Si tenéis la suerte de poder probarlo, no dudéis en hacerlo, veréis los beneficios.
  • Como decía antes, el ajuste de las estimaciones suele ser bastante conflictivo. Pero con tan solo un año de ellas a nuestras espaldas, hemos podido comprobar la mejora evolutiva muy a detalle. Un ejemplo que suelo poner, es la estimación de un nuevo informe dentro de nuestro producto. Nuevos informes nos surgen continuamente, todos muy parecidos, pero con necesidades diferentes. Pues bien, en los primeros Sprint, el equipo solía coincidir muy poco en su estimación, unos decían 5 días, otros 1, etc. Con lo que nos salía una media de 3 normalmente. Después de todo un año estimando y todo el equipo repartiéndose los cíclicamente, ahora cada vez que sale uno a estimar, hasta el Product Owner se ríe y murmura 2, antes de que el equipo estime.
    Con esto quiero decir, que no solo ahora todo el equipo sabe de sobra que un informe medio se haga en 2 días, sino que, una tarea que hace un año tardábamos 3, ahora la hacemos en 2. Beneficios de la autoasignación de tareas y repartición del conocimiento al autoasignárselas. Posdata hemos conseguido recortar una media de un 33% una tarea que suele aparecer con frecuencia en nuestro trabajo.
  • La motivación ha sido otro de los puntos fuertes dentro del cambio. Antes de empezar con él, creo que casi ningún miembro del equipo, estaba contento día a día con su trabajo. Ahora puedo afirmar con seguridad, que todos y cada uno de ellos, no solo se sienten bien y trabajan mucho más y mejor que antes Sino que están tan convencidos de ello, que cada vez que me preguntan algo sobre Scrum delante de alguno, saltan antes de mi respuesta y les explican todo el funcionamiento de principio a fin entusiasmados. Esto es mi mayor motivación diaria.
Aún nos faltan muchos pasos por andar y aún nos faltan muchas cosas por afinar y aprender. Pero sin duda, el producto ha mejorado muchísimo y tanto el equipo, el Product Owner, los superiores y yo mismo, estamos muy contentos con la dirección que todo va tomando poco a poco. Me gustaría hacer más a menudo retrospectivas y unificar en la rueda, la integración continua, la gestión de bugs, testing y despliegues, pero todo se va viendo más cerca y vamos poco a poco.

En resumen, cada día que pasa haciendo Scrum, me convence más, de que para este tipo de proyectos, es la mejor gestión que existe, o que al menos yo conozco.

Salu2!

Reunion 25/10/2010

2 respuestas

Día: 25/10/2010
Hora: 19:30 – 21:30
Lugar: Sala 30, Centro Cívico Zona Sur, Plaza Juan de Austria – Valladolid
Posteriormente en cafetería (cerveza en mano, como mandan los cánones).

AGENDA

1. Frecuencia quedada
2. Calendario de trabajo
3. Brainstorming de temas
4. Desarrollo de Temas

ASISTENTES

1. Javier Santana
2. Ignacio Cruzado
3. Olivier Salmon
4. Alfonso Bernal
5. Isidro Merayo
6. Alvaro García
7. Jose Da Rocha

RESUMEN

1. Frecuencia quedada y Orden del día
Se confirmó por parte de todos la utilidad de conocer a priori las citas y quedó aprobado la regla de quedar todos los martes de cada mes.
Se espera reservar el Centro Cívico. En principio queda encargado el pobre Jorge, por no poder asistir ;-) .
Se plantea la posibilidad de tocar dos temas en cada reunión: uno de Gestión y uno más Técnico, dando cobertura a las dos vertientes principales.
En los Temas se desarrollarán PUNTOS (topics) sean teóricos, prácticos o herramientas.
Se podría realizar algún otro SEMINARIO intensivo en algún sábado, en probable colaboración con ExeCyL.

2. Calendario de trabajo
Se va a intentar tener ya pre-configurados los TEMAS de las REUNIONES (tanto el técnico como el de gestión) a ser posible al menos 3 semanas antes de la reunión.
En esta reunión (y posteriormente en el foro se completará una lista de 2 Temas al mes para que todo el mundo sepa cuándo se va a tratar qué y pueda organizarse personalmente para asistir a aquellas que le sean más afines.

La idea sería:
Asignar 2 Temas por mes. Esta tarea de planificación a M/P la haríamos ahora, y una única vez en la primera semana (este año de Noviembre; años posteriores podemos comenzar, al menos, un mes antes).

Luego se entraría en un ciclo durante los meses hasta junio (incluido):

    1ª semana del mes: publicar el acta de la reunión y acabar de concretar quién desarrollará qué Punto en cada Tema (Plan).
    2ª y 3ª semanas: los voluntarios generarán algún post en el blog sobre sus topics a desarrollar (Sprint). Al final de la 3ª semana (Sábado); publicación.
    4ª semana del mes: lectura del grupo de los post: asistencia a la reunión (Demo). Repaso y discusión de los post en la reunión; la reflexión de mejora ya en la cafetería (se debería publicar con el acta de reunión las conclusiones o propuestas de mejora más interesantes)

El verano (julio-agosto) podría convenir no considerarlo ‘hábil’ (la gente coge vacaciones y el que no tenga irá generando gusanillo para el otoño).

El Orden del día de una reunión sería (comenzando a las 19:30 -alguien propuso adelantarlo, pero dado que no empezamos hasta las 19:50…):
1. Breve presentación asistentes (1′ por persona).
2. Discusión Tema técnico (40′).
3. Discusión Tema de gestión (40′).
4. Retrospectiva y lanzamiento de ideas de mejora a postear (5′).

Sería importante aplicar más puntualidad a la hora de llegada, para poder aprovechar el poco tiempo disponible del CC. Para ello hay una vieja técnica consistente en pensar que tienes la reunión a las 19:15 :-P

3. Brainstorming de Temas.
Se plantaron los siguientes Temas, a repartir por el calendario anual

Temas de Gestión (escritos por orden de aparición):

  • Gestión de proyectos (general; PMBok)
  • Gestión comercial
  • Dirección
  • Liderazgo
  • Gestión de equipos humanos

Los problemas de la interfaz comercial-técnicos:

  • Gestión del tiempo
  • Gestión de calidad
  • Gestión de imprevistos
  • Gestión del conocimiento

Temas Técnicos (en orden según se aplican en un ciclo de vida de cascada):

  • Administración de sistemas (instalación de software, seguridad, …)
  • Análisis y especificación de requisitos
  • Arquitecturas y Diseño software
  • Implementación y Codificación del software
  • Gestión de configuración (branching, merge…)
  • Pruebas

En ambas pilas de producto se hizo una votación entre los asistentes y se seleccionaron como más deseados (en orden de votación):
Temas de Gestión

  • Gestión de imprevistos
  • Gestión comercial
  • Gestión de equipos humanos

Temas Técnicos:

  • Pruebas
  • Gestión de configuración

Y se decidió dejar para el foro el debate final de cuáles en concreto encajarían en cada mes y cuales, de estos 5 son los dos seleccionados para su desarrollo y reunión en noviembre.
Aquí no encontramos la técnica y herramienta adecuada (¿doodle?) así que salvo que alguien aporte alguna idea mejor (espero!) lo haremos por discusión en un hilo del foro.

4. Desarrollo de Temas
Aquí comenzamos a desarrollar los Puntos de los temas de este mes.
Uso T=Teoría, P=Práctica, H=Herramienta

Pruebas

  • T. Factores a tener en cuenta en la Estimación del trabajo de pruebas
  • T. Debate sobre cuándo se pueden evitar las pruebas
  • P. ATDD y BDD
  • H. Hudson
  • H. Cruise Control

Gestión configuración

  • T. Patrones de ramas (intentar contar con Pablo Santos)
  • P. Gestión de Dependencias en Ruby y Python
  • H. PlasticSCM
  • H. Mercurial
  • Git

Gestión de imprevistos

  • T. Cómo gestionar el conocimiento extraído de los imprevistos sucedidos
  • T. Qué hacer con tareas imprevistas y con las no-terminadas en una planificación agile-time-boxed
  • P. Revisión de historias

Gestión de equipos:

  • T. Motivación
  • T. ¡Reunion-itis!
  • P. Resolución de conflictos
  • P. Equipos distribuidos

Gestión comercial:

  • T. Contratos comerciales y agilismo
  • T. Validación del cliente: ¿el rol del Client-ficticio es operativo?
  • T. ROI (Return Of Inversion) de organizaciones que adopten agilismo
  • P. Mercadotecnia: métricas y argumentos que soporten el agilismo comercialmente
  • P. Comercial interno: cómo evangelizar tu propia organización.

CONCLUSIONES

El nombre de los temas espero que no de lugar a mucha confusión: de ser así los re-nombramos.
Desde luego el nombre de los Puntos se puede mejorar y se pueden meter o sacar, en función de los voluntarios a desarrollarlos.

Ahora nos queda las siguientes tareas:
A. Asignar Temas a los meses (al menos votar las 2 de noviembre).
B. Coger un Punto cada uno de los voluntarios y redactar un Post al respecto.
C. Leer el trabajo de los demás.
D. Afinar nuestro modo de trabajo.

Probando mi TDD

1 respuesta

El sábado 25 de Septiembre, tuvo lugar el segundo taller práctico del grupo agilecyl.

Fue un taller especial por muchas razones: por la gran participación de gente del grupo, por el ejercicio y porque se nos unieron tres personas de Madrid, Jose Manuel Beas, Jesús Jimenez y David Salgado.

El taller estuvo patrocinado por Jorge Jimenez e Isidro Merayo que hicieron de maestros de ceremonias y explicaron el ejercicio. La idea surgió de una sesión de la Conferencia Agile 2010 que dieron Juan Gutierrez y Carlos Ble.

El grupo de personas participantes se reparte por parejas y por lenguajes. Es conveniente que por cada pareja se tenga una contraria que trabaje con el mismo lenguaje.

Hay dos ejercicios a realizar, A y B. En la primera parte del taller, dos pomodoros, cada pareja desarrolla el ejercicio que le ha tocado haciendo TDD, desconociendo el enunciado del otro. En la segunda parte del taller, cada pareja borra el desarrollo realizado y cede su ordenador al otro equipo. El objetivo es que los test, sirvan de guía para poder hacer el desarrollo. Se puede comprobar cuan buenos son los test para conseguir tener todo en verde, o yendo más allá poder entender el problema que se estaba resolviendo.

En la retrospectiva final, salieron detalles como:

  • La diferente dificultad de los problemas
  • Cómo hacer un test sobre elementos aleatorios
  • Si no hay nombres claros de test, se ponen en verde pero no sabes lo que haces

Fue una mañana fantástica, compartiendo ordenadores, código y la sabiduría de cada uno.

¿Quien patrocina la siguiente?

Explicando el ejercicio de TDD

Microsoft Security Development Lifecycle, SDL

1 respuesta

SDL consiste en un proceso de garantía de la seguridad, centrado en el desarrollo software.

SDL es el conjunto de procesos que marca Microsoft en el desarrollo software atacando de dos maneras:

  • Con 4 niveles dentro del Modelo
  • Colocando actividades en cada uno de las fases del ciclo de vida clásico del proceso de desarrollo

Como todo producto Microsoft está orientado a integrase con lo suyo. Así dependiendo de la fase donde estemos diseño,  implementación ofrece plantillas o analizadores que se integran de manera perfecta con Visual Studio Team System 2008.

Os adjunto un resumen muy breve del producto, que la verdad viene bien explicado en la web o en las MSDN.

Desde 2004 se ha instaurado en Microsoft como algo obligatorio en toda la empresa para conseguir con SDL mejorar la seguridad del software. SDL  tiene como objetivo reducir tanto el número como la gravedad  de los bugs del software. SDL se introduce en todas las fases del desarrollo software.

SDL está basado en tres conceptos básicos:

  1. Educación
  2. Mejora en el proceso continuo
  3. Responsabilidad

La educación continua y la mejora de los miembros de un equipo de desarrollo software es crítica. Invertir en formación  ayuda a las empresas a estar preparadas ante los cambios tecnológicos y las amenazas que se deriven de ello. Porque el riesgo no es estático, SDL hace el énfasis más fuerte en entender la causa y el efecto de las vulnerabilidades (bugs)  en la seguridad. Necesita una evaluación periódica de los procesos SDL y una presentación de los cambios en respuesta a los cambios en la tecnología o a las posibles amenazas. Se recogen los datos obtenidos para evaluar la efectividad de la prueba realizada (entrenamiento); se usan procesos de métricas para confirmar la conformidad del proceso  y las métricas a posteriori (post-release) ayudan como una guía a futuros cambios. Finalmente, SDL almacenará todos los datos que podrán ser utilizados a posteriori. Cuando esto se combina con una respuesta detallada tanto de la seguridad de la aplicación como de los planes de comunicación, una empresa puede proporcionar una orientación concisa y convincente a todas las partes afectadas con el problema.

Modelo de Optimización de Microsoft SDL

La integración de los conceptos de desarrollo seguro en un proceso de desarrollo puede ser costosa e intimidante si no se hacen de forma correcta. El éxito o el fracaso dependen de variables como el tamaño del equipo de desarrollo, los recursos que se poseen (tiempo, talento, presupuesto) y el apoyo por parte de la gerencia. El impacto de estos intangibles pueden ser controlados mediante la comprensión de los elementos que componen las buenas prácticas en la seguridad y estableciendo implementaciones prioritarias basadas en los niveles de madurez del equipo.

El modelo de optimización de SDL ha sido diseñado para facilitar de manera gradual una implementación consistente reduciendo los riesgos. El modelo permite hacer cosas tanto a los desarrolladores como a los managers:

  • Permite evaluar el estado de la seguridad del desarrollo mediante el uso de una escala de cuatro niveles  de madurez.

    • Los cuatro niveles de madurez de seguridad del Modelo de Optimizacion de SDL

  • Crear una visión practica y una hoja de ruta para ir avanzando por los niveles de SDL en cada una de las 5 areas del desarrollo software:
    • Formación, Normas, y características  a seguir
    • Requerimientos y diseño
    • Implementación
    • Verificación
    • Lanzamiento y Respuesta
  • Mostrar un esquema práctico y las actividades rentables en cada una de las 5 fases teniendo en cuenta el presupuesto, la planificación y los esfuerzos del equipo de desarrollo del software.

El modelo de optimización de SDL consiste en:

 Una introducción a SDL e indicaciones de cómo usarlo
Un cuestonario para mostrar el estado actual de la seguidad del desarrollo en los niveles de SDL
Tres guias de implementacion con detalles de los pasos necesarios a realizar para ir avanzando en los distintos niveles de madurez en cada una de las 5 areas del desarrollo.

Aplicación de SDL

Es importante dejar claro los tipos de proyectos que pueden ser objeto de los controles impuestos por SDL. La experiencia sugiere que se elijan teniendo en cuenta una o más de las siguientes características:

  • Desarrollo de un producto propio
  • Procesos de identificacion personal (PII) u otra informacion confidencial
  • Comunicaciones periodicas con Internet o con otras redes.

Roles, Responsabilidades de las personas encargadas de la Seguridad

SDL incluye criterios generales y descripciones para los roles que van a llevar la seguridad y la privacidad. Estos roles se indican durante de la Fase de Requisitos del proceso SDL. Estos roles son de carácter consultivo y proporcionan a la empresa la estructura necesaria para identificar, catalogar y mostrar las cuestiones de seguridad presentes en el desarrollo de un producto software.

Estos roles incluyen:

  • Rol de Asesorar, Revisar: estos roles se diseñan para tener una visión global acerca de la seguridad; con permisos para aceptar o rechazar los planes de seguridad del equipo
  • Un Equipo formado por los mejores: estos roles son los que negocian, aceptan y marcan un mínimo en los requisitos de seguridad y el mantenimiento de las líneas claras de comunicación durante el desarrollo del producto software.

Actividades del Proceso SDL

Es un conjunto de actividades de seguridad obligatorias, que se van a mostrar en el orden en que deberían ocurrir y agrupadas por las fases que marcan el ciclo de vida clásico en el desarrollo del software. Muchas de las actividades expuestas deberían proporcionar cierto grado de seguridad si su implementación se lleva a cabo de manera independiente. De todos modos, desde la propia experiencia, Microsoft recomienda que las actividades correspondientes a la seguridad se ejecuten como una parte más del proceso de desarrollo, consiguiendo mayor grado de seguridad que actividades desarrolladas por partes o hechas ad-hoc para un proyecto.
Modelo SDL

Es importante que si la empresa se centra en la calidad, utilice las herramientas y la automatización de SDL, puesto que le ofrece resultados completos y exactos y no se queda simplemente en un documento aislado obtenido en una fase del ciclo de desarrollo.

Actividades Obligatorias de Seguridad

Existen 16 actividades obligatorias de seguridad que todo equipo que vaya a emplear SDL debe realizar. Estas actividades se revisan de manera constante y son fruto del conocimiento y la experiencia de los equipos de Microsoft. Como se acaba de comentar estas 16 actividades marcan un mínimo de realización por parte del equipo, que puede añadir todas las actividades que considere necesarias.

Requisitos Pre-SDL

Practica 1, Formación: todos los miembros del equipo deben recibir la formación adecuada para tener todos los conceptos acerca de la seguridad y la privacidad que se va a llevar a cabo en el proyecto.

La formación básica estaría centrada en temas como:

  • Diseño de seguridad: reducción de ataques, principios de mínimos privilegios, seguridad mínima establecida, etc.
  • Amenazas en el diseño (modelado): restricciones de la arquitectura, implicaciones propias del modelo, etc.
  • Codificación segura: errores aritméticos, bucles infinitos, Cross-site Scripting( de las aplicaciones Web), criptografía no muy robusta, etc.
  • Test de seguridad: diferencias entre test de seguridad y test funcionales, métodos de testeo de la seguridad, etc.
  • Privacidad: en lo relativo a los datos, asumir riesgos, aprender buenas prácticas, etc.

Fase 1 Requisitos

Practica 2, Requisitos de Seguridad: Lo fundamental en el desarrollo de un sistema de seguridad para un producto es considerar que la seguridad y la privacidad son lo primero. El punto óptimo donde definir la integridad del producto se debe decidir durante las etapas iniciales. Esta definición temprana de requisitos, permite a los equipos identificar las claves de los resultados, permitiendo la integración de la seguridad de manera que minimice “el encontronazo” con la planificación del desarrollo.

Practica 3, Umbrales de Calidad: Se marca lo que se considera como nivel mínimo de calidad que se quiere adoptar. Definiendo estos criterios el equipo empieza a asumir los riesgos asociados a la seguridad y privacidad de los datos del proyecto. Por ejemplo, todos los “warning” de la compilación deben estar arreglados antes de subir el código al repositorio. También sería una buena práctica tener un gráfico donde reflejar los niveles de calidad alcanzados, es un indicador muy bueno con vida a lo largo de todo el proyecto.

Practica 4, Seguridad y Evaluación de Riesgos: Son procesos obligatorios que identifican aspectos funcionales del software y para los cuales se necesita dedicación:

  • Aspectos relacionados con la seguridad:
    • ¿Que parte del proyecto necesita un modelo de riesgos antes de ser lanzada?
    • ¿Qué parte del proyecto necesita diseño de seguridad antes de ser lanzada?
    • ¿Existen test adicionales de seguridad o requisitos que se consideran necesarios para minimizar los riesgos en la seguridad?
    • ¿Cuál va a ser el ámbito de los requisitos de test?
    • ¿Cómo se evalúa el impacto de la privacidad de los datos?

Fase 2 Diseño

Practica 5, Requisitos de Diseño: El sitio ideal para marcar el grado de fiabilidad que deseamos en nuestro proyecto es en la parte inicial del ciclo de vida del proyecto, por eso es muy importante considerar todo lo relacionado con la seguridad y el control de los datos en la etapa de diseño. Además es importante que el equipo distinga entre características de seguridad y características seguras:

  • Características Seguras: son aquellas cuya funcionalidad cumple con unos mínimos como validación de los datos antes de procesarlos, o cuenta con una implementación de librerías robustas en materia de criptografía, etc.
  • Características de  Seguridad: describe características tales como autenticación, firewall, etc.

Practica 6, Reducción de Posibles Puntos de Ataque: Se trata de reducir los riesgos de ataque, cuidando los posibles puntos débiles que se tengan en el producto: restringir los accesos a los sistemas, aplicando principios de privilegios en los perfiles, etc.

Practica 7, Modelos de Amenazas: Este punto se indica sobre todo para sistemas donde el riesgo de la seguridad es alto. Con esta práctica se pretende que los equipos documenten y discutan acerca de las implicaciones que puede tener el modelo de seguridad planteado en el contexto real del proyecto. En realidad está pensado para realizarlo de manera conjunta entre desarrolladores, managers, testeadores.

Fase 3 Implementación

Practica 8, Herramientas: En el equipo, todos deben trabajar del mismo modo, con una lista de herramientas aprobadas por todos y que permitan la integración de las mismas con otras que lancen avisos acerca del cumplimiento o no de la seguridad marcada para el proyecto.

Practica 9, Funciones Obsoletas: El equipo debe analizar las API’s que se utilizaran para descartar aquellas que se consideran obsoletas y por lo tanto inseguras. Una opción de trabajo es crear una lista con las funciones inseguras, utilizar ficheros tales como banned.h o strsafe.h, emplear últimas versiones de los compiladores, o utilizar herramientas para escanear el código y verificar que no existen las funciones obsoletas.

Practica 10, Análisis Estático: Un análisis estático del código fuente puede permitir al equipo que de verdad se están cumpliendo los criterios de seguridad marcados. Esto se debería realizar combinado aplicaciones de análisis de código junto con un trabajo por parte del equipo.

Fase 4 Verificación

Practica 11, Análisis Dinámico del Programa: Los programas de verificación del código en tiempo de ejecución son necesarios para asegurar que el programa hace lo que se esperaba según el diseño marcado. La tarea de verificación especifica las herramientas que se emplean por ejemplo en hacer un seguimiento del estado de la memoria por si en algún momento se corrompe, o el cumplimiento de los permisos dados a los usuarios. En el proceso SDL se utilizan herramientas como AppVerifier, junto con otras técnicas como “fuzz testing” para asegurarse que se cumplen  los niveles de seguridad marcados.

Practica 12, “Fuzz Testing”: Es una práctica por la que se induce al programa a fallar mediante datos incorrectos o aleatorios. Se parte de la funcionalidad prevista de la aplicación y se va ampliando el alcance de los test poco a poco.

Practica 13, Revisión de los Puntos Débiles y la Amenazas: Una aplicación es algo vivo, y lo normal es que haya cambios respecto a lo especificado en la fase de diseño. Esto lo que implica es que también se debe revisar lo que en su día se puso como posible amenaza, o parte de débil de la aplicación y por lo tanto susceptible en la seguridad.

Fase 5 Lanzamiento de la Aplicación

Practica 14, Plan para responder a Incidencias: Dentro de los equipo se debe marcar desde donde incluir todas las incidencias, a como clasificarlas, quien contesta en cada caso, etc.

Practica 15, Revision Final del Plan de Seguridad: Consiste en realizar una revisión sobre todas las prácticas llevadas a cabo acerca de la seguridad de la aplicación. No se pretende que esta práctica sea la oportunidad para incluir aquellas actividades que se han olvidado realizar, sino lo que hace es examinar los sistemas de excepciones, las posibles amenazas marcadas, etc.

Practica 16, Archivo con los Datos Seguridad: Para completar el proceso SDL se pide que el equipo incorpore los datos que indican que como mínimo ha realizado las 16 practicas del proceso SDL. Además todos los datos se guardan, permitiendo de este modo revisarlos a posteriori. Esto incluye la revisión del código fuente, los documentos donde se marcan los puntos débiles, un plan de respuesta ante una emergencia, licencias de terceros, etc.

Para todas las fases…

En cada una de las fases existen una serie de herramientas que van desde plantillas para Visual Studio Team System 2008 hasta en la parte de implementación analizadores estáticos de los ensamblados, de código C/C++, de vulnerabilidades para prevenir XSS (Cross Site Scripting).

En la página web se puede ver: http://www.microsoft.com/security/sdl/default.aspx

y también hay información  en la MSDN: http://msdn.microsoft.com/en-us/library/cc307748.aspx

Conclusión

El objetivo de este trabajo es proporcionar un framework sencillo para introducir las prácticas de seguridad en el proceso de desarrollo de software. Esto se realiza mediante una  serie de actividades que se llevan a cabo durante el proceso de desarrollo por parte de un equipo que tendrá como objetivo final  cumplir con los objetivos marcados en el modelo Microsoft SDL, como óptimos.

Mientras que el proceso mencionado establece un umbral mínimo para el cumplimiento de SDL, SDL no significa que no sea ampliable. Los equipos de desarrollo pueden utilizar SDL como una guía y adecuarse  a los recursos y las prácticas de la empresa.
Normalmente los conceptos que se discuten están reconocidos como buenas prácticas de la seguridad y no son específicos de Microsoft o de  Windows. Todas se pueden aplicar sobre diferentes sistemas operativos, plataformas de hardware, y metodologías de desarrollo y hacer una aplicación gradual de algunas de estas técnicas probablemente tendría una influencia beneficiosa sobre la seguridad y la privacidad de una aplicación en fase de desarrollo.
Se puede argumentar que incluso unas prácticas sencillas de los procesos de seguridad realizadas de común acuerdo por todo el equipo de desarrollo puede conducir a mejoras de manera  global que las realizadas de forma individual.

El SDL Microsoft es un proceso de libre disposición para la mejora de software en los aspectos de seguridad y privacidad. Se ha aplicado en numerosos programas de software y sobre millones de líneas de código de producción. SDL se compone de medidas obligatorias que siguen el proceso de desarrollo de software tradicional, pero es lo suficientemente flexible como para permitir la adición de otras políticas y técnicas, creando así una metodología de desarrollo de software que sirva como una guía dentro de la empresa. La combinación de procesos, formación,  y herramientas  produce distintos beneficios: prevenir errores, mejor competencia técnica, optimización del software, lo que se traduce en un menor riesgo tanto para la producto como para el usuario del mismo.

Recortes - el arma secreta en proyectos

6 respuestas

Esta entrada va de “recortar”, de quitar funcionalidad en un producto/proyecto y de cómo mediante esa técnica podemos intentar conseguir mantener los proyectos bajo control.

¿De dónde viene esto de recortar?

La primera vez que leí sobre esto fue en uno de mis libros favoritos sobre gestión de proyectos: “Rapid Application Development” de McConnell (también quizá mi autor preferido). Hablaba del concepto de triage que creo que tiene una traducción difícil pero viene a ser algo así como decidir a quién salvar y a quién no basándose en la gravedad de sus heridas cuando hay una catástrofe, conflicto, etc. El caso es que McConnell explicaba el triage como una forma de decidir qué entra y que no en un proyecto en un momento dado.
Puede parecer evidente pero ese concepto marcó la diferencia para mí: hasta entonces todo el tema de planificación, estimación y demás siempre acababa chocando con la idea de trabajar más horas para poder encajarlo todo y que diera tiempo. Esta idea lo cambiaba todo: deja cosas fuera. Así de simple.
Claro, McConnell dice que hay veces en las que es más importante entregar a tiempo aunque falten funcionalidades, que no llegar para nada. Una idea interesante que además es prácticamente la clave de todos los métodos ágiles, el desarrollo incremental, etc, etc.
En mi opinión (especialmente en desarrollo de productos, pero creo que también en proyectos porque siempre abre las puertas a la negociación) es siempre mejor poder entregar 3 funcionalidades completas en un momento dado que no poder entregar absolutamente nada porque tenemos 5 a medias. Abre las puertas a poder sacar un producto antes que la competencia (esto lo menciona McConnell en su libro), a poder negociar con el cliente (oye, tenemos 3 características listas para poner en producción, con esto podéis empezar a trabajar perfectamente porque lo que falta son puntos adicionales… y con esto comenzar a facturar) y a tener una solución de respaldo en el equipo (cubrirte las espaldas estando siempre, o casi, listo para la entrega).

Recortar siempre funciona

Me he puesto a escribir esto porque el otro día apliqué, de forma casual, esta misma técnica en la vida real, y funcionó bien: estábamos visitando una serie de sitios y comenzaba a hacerse tarde. Nos faltaba un único lugar por ver y posiblemente nos daría tiempo a visitarlo deprisa pero, decidimos dejarlo para otra ocasión y regresar. Vamos, eran las 6 y algo de la tarde, teníamos una hora y pico de vuelta hasta el punto de partida y en lugar de continuar volvimos.
La primera idea que me pasó por la cabeza fue: “¿y qué hacemos el resto de la tarde?”. Porque claro, veía que al final nos iba a sobrar tiempo si no visitábamos ese último sitio… que sería una “pérdida de tiempo”. Al final dimos la vuelta, como dije, pero: en lugar de a las 6 y pico eran casi las 7 cuando comenzamos el regreso, llegamos en algo más de una hora, las 8 y algo, así que no “sobró tiempo” precisamente (siempre hay algo que se complica), y sin embargo nos dio tiempo a volver sin prisa y nos dimos cuenta que de ninguna forma podríamos haber visto el último sitio. Nos dio tiempo a volver, cenar tranquilamente, dar una vuelta… vamos, un buen plan para un fin de semana tranquilo.
¿A dónde voy con esto? Pues que la primera impresión cuando quitas una característica de un SPRINT y dejas algo de holgura es: “qué vamos a hacer con el tiempo que sobra?”. Se crea como una cierta sensación de “desasosiego” en la cual se tiende a pensar que vamos a acabar con los brazos cruzados arrepintiéndonos de no haber metido la característica XXX. Al final, desgraciadamente (o no), eso nunca pasa: las cosas se alargan un poco, siempre se tarda algo más de lo esperado y el haber quitado esa característica nos permite llegar al final del camino en condiciones en lugar de con la lengua fuera y con cosas a medias (como el último punto del camino visitado en 10 minutos en lugar de con calma).

Recortar es la principal herramienta para maniobrar el proyecto

Siguiendo con el mismo autor, en “Software Estimation: Demystifying the Black Art” McConnell cuenta que gestionar un proyecto es posible cuando la diferencia entre la estimación y el tiempo disponible es menor de un 20%. Por encima de esa diferencia el proyecto simplemente es imposible (proyecto suicida, por cierto, otro buen libro sobre este tipo de proyectos es Dead March, de Yourdon, otro clásico), y o se cambian los objetivos o mejor no meterse (o asumir en dónde estamos). Precisamente cuando esto ocurre (y hay muchos más dead march de los que pensamos) estar preparados como equipo y gestionar las funcionalidades a implementar correctamente (cubrirnos las espaldas entregando de forma incremental) puede ser totalmente clave.
Al final recortar puede ser postponer para una siguiente versión, pero quitar de la actual a fin de cuentas.

El impacto del recorte

Hay un aspecto de esto de recortar que me preocupa especialmente y no es el impacto que puede tener en el resto de gente implicada en el proyecto (directivos, clientes, dptos. de marketing, etc), sino el que tiene en el propio equipo de desarrollo.
Los desarrolladores, por alguna razón, (para dar más bibliografía recomendaría el clásico Peopleware), somos demasiado optimistas (de ahí que la Ley de Parkinson, vamos, que el trabajo siempre se extiende hasta ocupar todo el tiempo disponible, no se aplique al desarrollo, y de ahí que como muy bien dice McConnell en “black art”, el problema de la industria de software no sea de “estimación” sino de “subestimación”. Nunca te preocupes por sobrestimar, si los desarrolladores tienen tiempo de sobra, terminarán igualmente a tiempo. Ignorar este punto supongo que crea enormes quebraderos a todos los “jefes de proyecto”…). Como iba diciendo, que somos muy optimistas y siempre pensamos que nos va a dar tiempo a terminar todo, y lo que es peor, nos sentimos mal si nos dejamos algo fuera. De hecho el sentimiento inicial ante el recorte es algo así como de “culpabilidad” ya que el equipo siente que “está haciendo trampa”. Y no es fácil superar ese sentimiento. Hay que explicarlo, hay que coger un poco de distancia, hay que priorizar, y hay que entender que tenemos limitaciones claras de tiempo y de personal y que hay que hacer lo que mejor se pueda con lo que tenemos. Y que para eso hay que recortar.
No sé si esto parece una tontería o no, pero la realidad es que es un punto muy a tener en cuenta para que el desarrollo no se descontrole debido a la desmoralización del equipo.
Siempre me viene a la mente el tema de “ingeniería vs ciencia” o lo de “empresa vs universidad”. Me explico: la tendencia natural de muchos de nosotros es la de intentar lograr la solución perfecta (al menos la que creemos que lo es), lo que normalmente es una aproximación muy buena desde el punto de vista “científico” (o de práctica universitaria) y nos sentimos mal ante la solución “de compromiso”: hacerlo lo mejor que puedas teniendo en cuenta que lo importante es respetar las restricciones del proyecto, y el tiempo suele ser la mayor de ellas. Esto último es casi la definición de ingeniería (o de aprox. más empresarial). Vamos, el tema de “mejor algo que funcione bien en la fecha correcta que una maravilla de la técnica con 4 meses de retraso, acumulando pérdidas, poniendo en peligro el proyecto, la empresa, etc, etc, etc”. Curiosamente esto último encaja con todos los métodos ágiles y la idea de “release often and frequently” y lo de “tener algo cuanto antes” (implicaciones empresariales sobre este tema en Rework). Y no hace falta recurrir a un gurú de scrum, la sabiduría popular ya decía “lo perfecto es enemigo de lo bueno”, ¿no?
En definitiva, que hay que explicar siempre al equipo cuáles son los objetivos globales, y que para tener una versión del sistema en la fecha X, es mejor dejar fuera unas cuantas características que llegar sin tiempo, sin haber probado y sin nada que entregar. Cuando todos crean esto firmemente no habrá problemas de motivación ni de entendimiento. Una vez que sepáis cómo hacerlo (variará en cada caso), repetidlo con frecuencia porque todo desarrollador tiende a olvidarlo rápido :)

Priorización

Y una vez que todos nos creemos que esto de recortar va bien… ¿cómo lo hacemos? ¿Qué se deja fuera? Vuelve el debate y el problema. En el fondo es fácil, hay que identificar aquello que realmente es importante considerando los objetivos globales del proyecto. Se dice muy fácil pero luego no lo es tanto porque nos metemos en nuestra burbuja y tendemos a perder la visión global un poco, y nos parece que esa característica super-hacker es muy, muy importante cuando al final el usuario ni la va a ver.
“Black art” nos vuelve a dar unas cuantas pistas: me gusta la técnica T-Shirt sizing que consiste en clasificar cada característica con una escala sencilla en 2 aspectos: desde el punto de vista de implementación y desde el punto de vista de “impacto de negocio”. Por ejemplo, desde el punto de vista de desarrollo:
• Funcionalidad 1: pequeña
• Funcionalidad 2: grande
• Funcionalidad 3: mediana
Y desde el punto de vista de negocio:
• Funcionalidad 1: alto
• Funcionalidad 2: medio
• Funcionalidad 3: alto
Nos llevaría a planificar primero la Funcionalidad 1 (alto impacto y poco coste de implementación), luego la 3 y dejar para lo último (incluso potencialmente fuera) la Funcionalidad 2.
Como decía, McConnell lo explica mucho mejor y en detalle en “Black art”, así que guardad el “puntero”.
Hay otro libro muy conocido “Agile Estimating and Planning”, de Mike Cohn que dedica un buen número de capítulos a cómo priorizar: desde a nivel financiero hasta un punto que considero muy interesante y que es “prioritizing desirability” (capítulo 11) y en el que introduce el modelo de Kano de satisfacción de cliente para identificar qué características son las que hay que implementar primero basándose en si son obligatorias (sin ellas el producto no sirve aunque no “emocionan” a nadie), lineales (cuántas más, mejor), o realmente “innovadoras” (aquellas que marcan la diferencia realmente). Incluso habla de formas de trabajar en las que te saltas alguna característica obligatoria (poniendo los pelos de punta a los desarrolladores más “científicos” :-P ) para tener antes el producto en la calle impactando con “delighters” (como él los llama) y así ganar a la competencia.
Cohn explica cómo hacer encuestas a clientes para saber, de forma objetiva, de qué tipo es cada funcionalidad (Kano model).

User pain

La técnica que usamos en Códice para priorizar bugs es el “user pain” y nos permite “objetivizar” un poco los bugs que metemos en nuestro sistema de “issue tracking”. Básicamente en lugar de meter prioridad alta, media, baja (siempre es alta!!) respondemos a ciertas preguntas en plan:

Hay un cálculo por detrás que da un valor de 1 al 100 (100 es mucho “dolor”) según las respuestas y luego tenemos la lista priorizada, intentando no tener nunca bugs por encima de un valor 30 (de hecho ahora que lo miro veo que tenemos uno del 29!).

Conclusión

Recortar es una “trampa” fantástica que permite que todo encaje. No podíamos aplicarlo en el colegio (“profe, no me examine de los temas 5 y 6 que no me ha dado tiempo a estudiarlos, pero los 4 primeros me los sé de memoria!”) y eso nos ha marcado mucho, pero en “la vida real” puede ser clave para tener éxito en los proyectos y además hay mucha bibliografía aplicable al tema.

Libros: Rework!

1 respuesta

¿Cómo andáis de lectura veraniega? Creo que tengo una propuesta buena y aunque el calificativo “veraniego” no sé si será muy positivo, se lo aplico al libro en cuestión :)

El último que me he leído es: Rework: http://37signals.com/rework/.

Como decía, el libro tiene un poco de pinta de libro de “auto-ayuda” para “empresarios-pcworld” que tira para atrás, pero bueno, el caso es que me llamó la atención, más que nada porque la empresa de los tíos que escriben sí que es la caña: 37 signals, os suena??

37 signals es, en mi opinión, una empresa web 2.0 modélica donde ocurren cosas como:

  • son pequeños y no se avergüenzan de ello sino todo lo contrario (tengo que sufrir a comerciales, propios!, que intentan que parezcamos una gran corporación todos los días :) )
  • tienen millones de usuarios (clave en los nuevos modelos)
  • rompen con muchos esquemas (el libro cuenta unos cuantos)
  • son ágiles!

¿De qué va el libro? Pues, y de ahí que lo meta en esta lista, de cómo montar una empresa en plan “ágil”.

Puntos interesantes:

  • Meetings are toxic: ¡¡cuánto tiempo perdemos en reuniones!! En una página le dan caña al máximo y dicen que hay que huir de las reuniones como del diablo… reducirlas al mínimo (suena muy scrum).
  • Planning is guessing: esto, aunque suene a chungo, encaja con autores de prestigio: Steve McConnell en su libro “Estimation, demystifying the black art” cuenta muy bien cómo diferenciar entre estimar rápido y con bastante aproximación, o tardar mucho en estimar (ciencia, COCOMO, etc) para conseguir resultados sólo un poco mejores. Es mi libro favorito de estimación junto al de Mike Cohn.
    http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=sr_1_2?ie=UTF8&s=books&qid=1280919608&sr=8-2.
  • Underdo your competition: esto sí que me ha gustado! No hagas más que la competencia… haz menos!! Pero hazlo más simple, más usable. Un ejemplo es su aplicación BaseCamp. Me recuerda también a todo lo de “triage” en gestión de proyectos, y de nuevo McConnell lo explica muy bien en el siguiente clasicazo:
    http://www.amazon.com/Rapid-Development-Taming-Software-Schedules/dp/1556159005/ref=pd_sim_b_1, que es uno de mis libros favoritos de gestión de proyectos.

Habla también de cosas como por qué no es bueno ser un adicto al trabajo (workaholic) y cómo eso símplemente genera más trabajo pero no mejores resultados (encaja con el manifiesto ágil).

El libro se lee en dos patadas porque tiene más páginas con gráficos y portaditas y chorradas que texto.

No es una maravilla… pero ya que me lo he mirado… os lo cuento y os tuesto un poco!! ;)

Un oasis en el desierto

1 respuesta

Bienvenido al blog sobre metodologías ágiles en Castilla y León…España.

Los compañeros de la comunidad ágil de Castilla y León me han pedido que haga la primera entrada de este blog, un honor que creo no merecer y una responsabilidad que es difícil de asumir pero que les agradezco. Y lo agradezco principalmente porque con el nacimiento de este blog se da fe de la existencia de una comunidad ágil en una tierra que siempre vive tapada por la sombra de Madrid, porque ha sido el fruto de unos meses en que nos hemos conocido algunos profesionales que trabajábamos muy cerca con las mismas inquietudes sobre nuestra profesión pero que como siempre vivíamos aislados entre nosotros.

¿Qué son las metodologías ágiles?

Sacando la definición de la Wikipedia (tan recurrida y a veces tan inexacta)  son las metodologías que surgen en contraposición a las metodologías tradicionales o pesadas y que evolucionan el concepto de ingeniería de software de proceso iterativo y prototipado. En el año 2001 se juntaron una serie de profesionales de reconocida valía en el desarrollo de software para crear un manifiesto donde se reflejaran los principios que rigen estas metodologías. Este manifiesto resume la filosofía ágil valorando:

  • Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas
  • Desarrollar software que funciona más que conseguir una buena documentación
  • La colaboración con el cliente más que la negociación de un contrato
  • Responder a los cambios más que seguir estrictamente un plan

Desde AgileCyL queremos hacer llegar los procesos y métodos ágiles al resto de compañeros y empresas en Castilla y León porque creemos que ayudan al desarrollo de proyectos software. Nuestro objetivo es aportar la información necesaria para que cualquier interesado pueda aprender y comparar con las metodologías tradicionales. Como dijo una vez Xavi Albaladejo, una de las personas que más ha extendido la agilidad en España:

agilidad es calidad y competitividad

y tenemos un compromiso moral con nuestra industria en mejorar los productos que desarrollamos en nuestra profesión.

Desde este blog os animamos a participar en las reuniones mensuales que realizamos donde discutimos diferentes aspectos relacionados con la agilidad, desde charlas sobre la gestión ágil de proyectos hasta talleres y debates técnicos de Extreme Programming.

En la lista de correo estamos en contacto y os invitamos a participar y aprender con nosotros. Si quieres colaborar puedes escribir en el blog pidiendo un usuario en la lista de correo y algún administrador del blog te lo creará. Intentaremos superar la barrera idiomática con la traducción de artículos, siempre que contemos con el consentimiento expreso del autor, publicaremos los resúmenes de los encuentros ágiles que hagamos en la comunidad y más actividades que irán surgiendo entre todos, que para eso es una COMUNIDAD.

Gracias por visitar el blog.

REUNION 23/06/2010

Deja una respuesta

LUGAR DE ENCUENTRO

Ciudad: Valladolid

Hora: Desde 19:30 a 21:00
Punto de encuentro: Cafetería Púrpura (en la parte de arriba)

Ver mapa

  • C/ Las Mercedes, 7 (en el portal) 47006 Valladolid

OBJETIVOS

  • Resumen y conclusiones sacadas de las sesiones a las que asistimos en CAS2010

REFERENCIAS

Blogs

Podcasts

Presentaciones

AGENDA

  1. Presentaciones individuales
  2. Revisión de los tracks de CAS2010
  3. Retrospectiva de la reunión.
  4. Actualización de Backlog de temas para los encuentros
ASISTENTES
  1. Jorge Jiménez Pérez
  2. Amalia Hernández García
  3. Jezabel González Diez
  4. Alvaro Garcia Loaisa
  5. Jose Antonio Da Rocha Padilla
  6. Pencho Herrero
  7. Javier Acero Guerra
  8. Susana Mielgo Fernández

RESUMEN

Los miembros de Agile-CyL que asistieron a la CAS2010  realizaron un resumen de la coferencia para el resto del grupo. Lo que empezó en el bar, acabo en una terraza con una charla muy productiva pues el resultado de ella es este blog que podeis leer. Ya tenemos otro lugar donde compartir nuestras experiencias.