Mi No-charla en la CAS 2015 : Necesidades vs Soluciones: una vista diferente al Crossing the Chasm

Este año presenté un par de charlas[1][2] para la CAS 2015.
El nivel es realmente extraordinario, así que no me extraña demasiado que al final no se aceptase ninguna. La parte buena es que podré ir mucho más relajado.

Presenté charlas más como un ejercicio de colaboración con la comunidad que por un objetivo personal. Este año me lo había tomado como de descanso, después de haber ido como ponente a un montón de sitios en el 2014.

Pero lo que me trae a escribir este post rápido es compartir con vosotros el abstract de la charla que creo es muy interesante, así que me encantaría prepararlo y contarlo en un @madriagil.

Necesidades vs Soluciones: una vista diferente al Crossing the Chasm

En mi entorno existe una gran inquietud tecnológica. Llega a ser un ansia feroz por buscar el siguiente best-framework-ever, por no conformarse con soluciones bien probadas.

El pasado agosto estuve en Sofía asistiendo a la ALE y conocí al genial Chris Matts que hizo la keynote inaugural. Hizo una aproximación al clásico Crossing the Chasm, mapeándolo por encima con otros modelos como el Cynevin, Meme Lifecycle o Real Options.

Fue realmente revelador. ¿Por qué algunos se conforman con una solución suficientemente buena y otros buscan continuamente la excelencia? ¿Por qué las buenas prácticas no son tan buenas? ¿Por qué reinventar continuamente la rueda? ¿Qué motivaciones existen en unos y otros?

En esta charla veremos las diferentes comunidades que tenemos a nuestro alrededor y trataremos de alinear todas estas motivaciones dándoles un objetivo común.

Articulos relacionados de Chris Matts Communities of Need & Community of Solutions y Agile – The Broken Learning Machine

Un pequeño sketch que hice ayer para explicarlo en una sesión que tuvimos en Kaleidos:

needs02

La idea clave que puse ayer es que las Necesidades se mantienen, mientras que las Soluciones cambian con el tiempo.

Aquí salió la pregunta “¿No hay un gran desperdicio de tiempo y esfuerzo en estos experimentos constantes?”

Mi respuesta es conseguir el equilibrio entre “Rentabilidad vs Atraer Talento” , “Aburrimiento vs Investigación”, “Estrategia empresarial vs Motivaciones personales”

Más diferencias, foto de Alexis Monville

needs01

Espero que os resulte tan interesante este tema como lo es para mi.

[1] Tarjeta trello de la CAS2015 para la charla de Necesidades vs Soluciones
[2] Tarjeta trello de la CAS2015 para la charla de Discusiones y Decisiones

Etiquetado ,

El UX nos va a cambiar más de lo que pensamos

UX role like analyst

UX role is like a aka analyst

Escribí estos miedos rápidos cuando llegaron los UX a Kaleidos, me quedó aquí en borrador y todavía están vigente.

Va a venir gente con mucha experiencia a liderar los proyectos.

Vienen a ser analistas. Porque el Analista de toda la vida a ha muerto. Y lo que antes me cachondeaba, ahora me preocupa. No quiero perder como informático el liderato de los proyectos para siempre, ni que se me oxiden mis capacidades analíticas.

¿Qué pintamos los Informáticos, como expertos en información, en la nueva manera de hacer los proyectos?

¿Qué diferencias hay entre un UX y un informático?

¿Apesta mi Curriculum?

Etiquetado

Q: “Me gustaría controlar el avance del sprint con las tareas cerradas”

Taskboard

Post publicado también en el blog de Kaleidos

Entre los usuarios de Taiga y soporte, suelen surgir debates y preguntas muy interesantes sobre cómo usar la herramienta y si encaja o no con la filosofía y objetivos del producto.

Os traigo hoy uno sobre control del avance del sprint:

“La gráfica actual del sprint (Sprint Burndown Chart en Taiga) no nos vale porque solo aparecen los puntos quemados cuando se cierran todas las tareas de una User Story con lo cual durante la primera semana del sprint da la impresión de que no se ha avanzado nada, aunque se vayan cerrando tareas de las diferentes User stories.

Los requerimientos que tenemos del scrum master es trabajar con la filosofía de tarea como medida de lo que hace el equipo y avance real (incluso trabajan con horas)”

Este Scrum Master, sigue el libro. La guía oficial de Scrum en su sección de Sprint Backlog habla de:

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Un desarrollo más en profundidad muy conocido es como lo cuenta Henrik Kniberg en su libro “Scrum desde las trincheras” (aquí original) y también habla de contabilizar el trabajo pendiente del sprint.

En los dos casos hablan de preguntar al equipo cuánto trabajo cree que les queda pendiente de cada historia, sea en puntos, sea en horas, sumarlo y ver lo que queda.

Lo que es propio de la implementación que hace este equipo, es contabilizar el avance sumando las horas de las tareas que se han terminado.

El avance de las tareas en una historia no te da información real del avance del sprint, porque si somos fieles a Scrum, en la demo solo se pueden mostrar historias terminadas, no ‘casi’ terminadas.
Una gráfica de tareas pendientes en el sprint que muestra que estamos al 90% de sprint terminado, pero realmente solo tenemos 2 de 8 historias terminadas (25%), puede dar una falsa sensación de tranquilidad. Y evita algo muy importante, que es centrarse en terminar historias.

Además de esto, llevar el control por tareas, y además en horas, hace que haya que estimarlas al inicio del sprint con el correspondiente esfuerzo.
Y el problema de calcular el ‘quemado’ del sprint a partir de una estimación inicial, es que no contempla los cambios y problemas que nos vayamos encontrando. Y si la solución es reestimar las tareas si ‘explotan’, solo hace aumentar la burocracia.

Cuando allá por el 2010 intentamos una aproximación fiel contando las horas pendientes en el sprint, enseguida nos dimos cuenta que era una microgestión que aportaba poca información que no nos diera ya el panel. Los bloqueos que puedas tener en una historia se pueden detectar igual en el daily: “Llevas tres días con esta historia de 2 puntos. Hay algún problema?” , es mucho más efectivo.

En mi opinión, si se quiere tener una gráfica de “Sprint Burndown” con más detalle que la actual de Taiga, haría como recomienda la literatura, preguntando al equipo en el daily “¿Cuántas horas calculas que te quedan de tu historia?”. Es mucho más realista y no depende de tareas terminadas. Y con esa información haría una gráfica para colgar en el tablón o en un doc compartido.

Si se quiere automatizar, en la versión liberada esta semana de Taiga, se puede crear un custom field para ir poniendo esa cantidad de horas pendientes en ese campo y se podrá sacar una gráfica de manera fácil.

Tema muy interesante, sin duda. Volveremos sobre el control detallado de los tiempos, internamente llamado “El dilema del Time-Tracking”, en otras preguntas que nos hacen.

Etiquetado , , ,

Carta abierta para mi cumple

me

by @elhombretecla at #kosdem15

¡Hola!

Soy informático. Trabajo en una empresa de desarrollo muy especial, somos todos muy cracks, pero a la vez especialitos. La montamos juntos.
El esfuerzo personal que requiere es muy alto.

Y soy padre, dos hijos. La mayor tres y el pequeño uno. Ya hace tiempo que dejé de pensar que no aprovecho el tiempo cuando estoy en casa. 🙂

Y el 20 de abril cumplo 40 años… y cuando mis padres y mi mujer me preguntan “¿Qué quieres para tu cumple?”, yo les contesto “Tiempo”. — JA, JA, vale en serio, ¿qué quieres?. — En serio. Quiero que me regales tiempo, no necesito otra cosa.

Me encantaría empezar a ver que después de cada día me queda algo en el colador.

Un abrazo,

Antonio

Etiquetado

PiWeek VII. Done!

piweekvii

PiWeek done!

Goals review

Emacs

  • Change from vim to emacs

Grails

  • Learn async capabilities in grails 2.4.4
  • GPars

Javascript

  • Compare with ajax

Seekagift

  • Upgrade Seekagift to grails 2.4.4
  • Integrate all of this in Seekagift
  • Deploy in public

Writing

  • Write post about CAS 2014
  • Write post about Scrum Day Oviedo
  • Investigate about Time Tracking for Taiga
  • Answer Epic topic conversation

In terms of progress and task done, wasn’t very well. Only achieve two of the goals.

Problems:

  • Retake a 2 years old project was not as good idea as I thought.
  • Upgrade to grails 2.4.4 was easy
  • Upgrade facebook login plugin was a little bit hard to integrate with the actual project.
  • Review all facebook permissions, accounts and api calls. Most of them deprecated.
  • Review all amazon credentials and api calls. Hard problems with the API keys valid to connect with Amazon Affiliates.

Retrospective

Stop doing

  • Lost a lot of time and effort in an application that I’m not sure I’m going to maintain in the future.
  • Retake a very old project that I didn’t pay attention any more.

Less of

  • Focus less in ‘Working Software’ and more in ‘Personal Innovation’.

Continue doing

  • A PiWeek where I have to do my best.
  • Solo projects are not so bad.

More of

  • Learn knowledge that I can apply on next monday.
  • Create conversations during piweek that help to achieve the goals
  • In my Next PiWeek-team project, I will assure that all members share the vision

Start doing

  • Pivot much earlier, leaving useless knowledge.
  • Prepare before piweek the basic software I need.

Conclusions

I’m very proud of effort, very happy to concentrate in the goals and very happy to feel exhausted.

See you next PiWeek in July 2015!

Etiquetado

Go PiWeek, Go! (My goal for PiWeek VII)

piweek vii breakfast

This post will be the first of one post-per-day for PiWeek VII (I hope so)

Mission for this PiWeek

Remember the great feeeling I felt this year in Euskal Encounter, having enough time to develop without any rush.

Goals

Emacs

  • Change from vim to emacs

Grails

  • Learn async capabilities in grails 2.4.4
  • GPars

Javascript

  • Compare with ajax

Seekagift

  • Integrate all of this in Seekagift
  • Deploy in public

Writing

  • Write posts about CAS 2014 and Scrum Day Oviedo
  • Investigate about Time Tracking for Taiga
  • Answer Epic topic conversation

What can I show on Friday?

A very improved version of Seekagift

Go for it!

Etiquetado

Mira mi pedazo de MO

Moteam Kaleider

¡Estamos en Movember!

Observa el pedazo de MO, que me estoy dejando.. ¿a que mola?

Movember en 101

Como todos los años en Kaleidos formamos el equipo Movember!

¿Por qué es esto?… ¡Dentro vídeo!

Y este año está siendo muy especial.

La primera semana con bigote fue un poco horrible, como siempre. “¡Qué vergüenza!” y demás pensamientos.
Hasta que pensé: “Molaría ir colgando fotos en las que se supone que paso mucha vergüenza…”
Así que me animé con la primera, en casa, y luego la segunda, que fue en el metro y luego la tercera, en las oficinas de un cliente…

¡El efecto fue brutal! ¡Llevo ahora mismo 140 eurazos recaudados!

Muchísimas gracias a todos por vuestra generosidad.

Porque fuera pijadas, yo también tuve que hacer un análisis para mirar el nivel de PSA y no mola nada la espera de los resultados.

Volviendo al cachondeo, ¿queréis ver las fotos de la vergüenza? Atentos a mi twitter, pero aquí un resumen:

El pase de diapositivas requiere JavaScript.

¡Gracias!

Etiquetado

¿Qué es una historia épica?

Epic User Story

La semana pasada se lanzó una pregunta dentro del equipo muy interesante:

¿Qué es una historia épica?

La pregunta venía motivada, porque es una petición muy recurrente entre los usuarios de Taiga.

Mi respuesta en un correo fue esta:

Una épica, según los que lo inventaron, es una historia grande y muy indefinida que se va a dividir.
La Epic, tiene que desaparecer, en sus historias más pequeñas.

Historias de usuario que recuerdo deben seguir el patrón: INVEST
​remarcando la I de “​Independent” y la V “Valuable”

En mi opinión la EPIC puede tener sentido y ser visible, incluso con otro color, pero más reflejando ese estado de proto-historia, de idea sin madurar, de historia ‘gorda’… que como algo que vaya a ser parte de la estructura de la aplicación.

Preguntas que pueden surgir:

“Realmente todas las pequeñas historias no subirían solas a producción, están relacionadas”
Aquí puede ser útil el concepto de Epic, como agregador de us. Es decir, tenemos el concepto de módulo. Pero cuidado, esto generalmente es muy confuso de gestionar en cualquier plataforma, incluso en papel.
Hace al cliente muy difícil prioririzar, hay muchas dependencias.
Los tags aquí harían un buen trabajo, creo.

“Los prototipos de UX son para la historia grande, la epic”:
Eso es un problema de documentación, o de que el UX hace los prototipos antes de dividir, o que las divide back, con el sesgo que tiene, o todo a la vez.
Si las historias son independientes deberían tener su prototipo clarito. No rebuscar en el prototipo 17.0.3 y ver qué botón es la us que estamos mirando ahora.

“Pero las EPICs no son formas de agrupar los grandes bloques de un proyecto, por ejemplo API, Front Web, Front Movil, …”
No, eso se podrían llamar módulos o similar, pero esos módulos no tiene valor ‘per se’.

La palabra epic, la usa Mike Cohn en su libro, así que es ‘oficial’ 🙂

Busco en google y me encuentro este precioso artículo de Mike Cohn de este año hablando de todo esto!
http://kcy.me/1cu9f

que es una copia de éste del 2011
http://kcy.me/1cu9p

Espero que ayude. 🙂

Después de este correo tuvimos una reunión para definir:

“Qué sería una historia épica en Taiga”

Una de las máximas necesidades que tiene el usuario de una épica, es servir de base para el primer análisis y puede estar acompañada de un buen hilo de conversaciones, diagramas, wireframes e incluso prototipos. Y esa información no la queremos perder.
Si dividimos la épica en historias más pequeñas, ¿dónde metemos toda esa información previa?

Por lo que el formato final en Taiga, será una historia de usuario, que se marcará como ‘épica’ en sus propiedades, y se distinguirá de las demás en el backlog por el color.
La épica y sus historias derivadas estarán relacionadas y así podremos acceder a toda la información del análisis previo si fuera necesario.

Como bonus, esa agregación de historias en la épica, nos da la posibilidad de hacer un seguimiento de ver cuántas historias están hechas, y así tenemos algo parecido a un módulo o conjunto de historias que tenemos agrupadas.

Como bonus++, esas historias que salen de la épica, puede que no estén en el mismo proyecto, puede que estén en un subproyecto.
Esto abre la posibilidad de tener un proyecto ‘base’ que se llama ‘Dirección General’ una épica que se llama ‘Campaña de Navidad’ e historias de esta épica en el subproyecto de ‘Dpto. de Marketing’ como ‘Anuncios en Televisión’. Pudiendo seguir el avance de todas estas historias desde la épica.

¿Qué os parece? 🙂

Foto gracias a Kulawat Wongsaroj de su post Visualizing the Big Picture of your Agile Project

Etiquetado , , ,

Deseo concedido! Kaleidos is hiring 2 UX!

Kaleidos loves UX

Ya sabréis lo que me está gustando a mi este año hablar de la integración de los perfiles de Diseño especialmente los de UX en los equipos de desarrollo.

Vamos que no hacer un water-scrum entre los equipos de diseño y desarrollo.
Me podréis ver por última vez este año en la CAS. 🙂

Pero no vengo a hablar de mi. Vengo a contaros que por fin en Kaleidos vamos a dar ese paso de integración total y estamos buscando no uno, sino que DOS UX para el equipo y especialmente porque ya habíamos hecho demasiado mal por nuestra cuenta. 🙂

Podéis ver aquí los detalles de la oferta:
Kaleidos is hiring 2 UX

Ya sabéis, contadlo en casa! 🙂

Abrazos, y nos vemos en la CAS!

Etiquetado ,

ALE 2014 – en tres tweets

ALE14

Como adelanto a un post más sesudo, resumen de lo que es para mi la ALE en tres tweets:

¿Es diferent​​e la energía de la ALE respecto el AOS o la CAS? ¿En caso de ser diferente, en que lo notas?

Definitivamente sí. La energía emana de todos. La ALE con sus mil formas de participar hace que todos seamos protagonistas

y menos relación conferencia: ponente/asistente.Y en inglés, estamos casi todos fuera de nuestra zona de confort.

Y por último: hay mucha más mezcla. Hay managers, desarrolladores, coachs, scrumasters, teamleaders, …

Del original en twitter en respuesta a Vanesa Tejada.

 

Etiquetado , , , ,