lunes, 28 de febrero de 2011

Agile-Alicante. Febrero 2011.

Scrum, Scrum & Kanban & ScrumBan. Con este título se convoco la segunda reunión del grupo agile de alicante. Y, tomándolo como la excusa perfecta para hacer un viaje de los que me gustan, intensos y rápidos,  me cogí el coche para meterme 1100km en dos días y conocer y compartir experiencias y conocimientos.

Y he de reconocer que ha merecido la pena y mucho.

La reunión estuvo asistida por 7 miembros, más quien escribe estas lineas. Y estaba compuesto por muy un compendio impresionante de sectores de la industria. Dos BI, un investigador, uno de atención al público, uno de hard y soft de televisión, un director de proyectos (de los de verdad), un IT. Y todos con un nivel… que ha sido todo un honor poder disfrutar de la sobremesa –de la cual hablaré más adelante-.

La primera ponencia la presentó Jorge Muria – nuestro anfitrión – que trató sobre Kanban. Para que no se perdiera la costumbre de las reuniones Agile, nos pasamos el 60% de la ponencia charlando, opinando y compartiendo. Entre las múltiples cosas que he aprendido, me gustaría señalar dentro de los artefactos el uso de subpipelines, el concepto de Wip (Work in progress), la sutil diferencia entre Push (cola->wip) y Pull(wip->completado) y los límites (máximo, mínimo y temporal). Estos dos últimos limites me asombraron por desconocerlos y por la potencia que añaden a los límites Kanban. Por último nos hablo del pipeline de emergencia en utilizado para, como su nombre indica, emergencias..

A continuación Gustavo nos dio otra breve ponencia sobre Kanban a Scrum, llena de referencias, comentarios y opiniones por el resto del grupo. Pero de las que saqué varias valiosas conclusiones –no todas relacionadas con Kanban-:
* Las historias de usuario son INVEST
* El compañero de al lado, un IT, nos comentó el ejemplo extremo y real de el concepto HEROE. Una compañía en donde tres “informáticos” tenían, por contrato, viajar en el mismo avión. O, el caso del BDsys que tuvo que volver urgente de sus vacaciones en la India porque “alguien” cayo en la cuenta que aquel era el único que tenia los permisos de administración sobre las BD.
* Gustavo nos comenta que sus Kanban están centrados en el Flow del proyecto completo, incluyendo columnas para la conceptualización, sistemas, etc. Incluso de BD y Sistemas, que en el workFlow, pueden causar cuellos de botella.

Por último, Jorge nos ofreció una exposición final sobre scrumban incluyendo una visita al otro lado de la sala en donde tiene su panel real de scrumban. Nos explicó las prioridades del panel Kanban que amplia el panel Scrum (asap, prioritario y fire). Y nos mostro el título de su tablero Kanban: Brown Dispatcher. (bueniiiiiiisimo, jeje).

Aunque lo intentamos, no hubo forma de hacer la retrospectiva, por lo cual hago la mía propia:

(+)

  • El grupo era muy interesante y completo. En nivel alto. La conversación interesante.
  • El ambiente fue de los mejores que me he encontrado.
  • Una vez más, me llevo muchas cosas nuevas aprendidas.

(-)

  • Que está a casi cuatro horas de Madrid.
  • Nos moríamos de ganas por compartir experiencias y durante las exposiciones interrumpimos demasiado.

No voy a poner deltas, porque no creo que pueda mejorar esta reunión. Ha sido muy buena.

A partir de ese momento nos bajamos al restaurante Vinícolas en donde nos enseñaron la enorme e impresionante colección de vinos. Y, como colofón, nos invitaron a comer un menú degustación que es de lo mejorcito que he comido nunca. Que nivel!!

En la sobremesa se formó uno de esos momentos “mágicos” en donde fluye el conocimiento en todos los sentidos. Y que fue bruscamente interrumpido al darnos cuenta que ya era la una y media de la madrugada. Que rápido pasa el tiempo cuando se está agustito!!

Muchas gracias!!

jueves, 24 de febrero de 2011

Fin del sprint 16.

Más vale una imagen que mil palabras.

037

Que puedo decir…

…cuando el equipo acaba el sprint número 16 (34 semanas)  posando con esa cara de orgullo, de satisfacción por el trabajo bien echo, con ese número de tareas “Done”, con un sprint backlog casi vacío…

…creo que puedo decir sin pecar que estamos haciendo las cosas bien.

miércoles, 23 de febrero de 2011

Madrid-Agile 22/02/2011 Historias de Usuario

Reunión en Nayade a la que llegué tarde, y menos mal que llegué, a causa de un amigo indómito al que le voy a echar una mano con su dominio, su web y todas aquellas cosas que le ayuden a salir del agujero en donde está metido.

Primera sorpresa… que montón de gente!!

064

Yo que pensaba que íbamos a ser cuatro gatos, me encuentro con la sala petada de peña, todos con unas ganas de aprender tremendas. JMB ya estaba de pié haciendo de jefe de proyecto (mira que le gusta) y había muchas caras nuevas y caras de gente ya largamente conocidas. Quiero señalar a Luís Fraile que demostró de largo porqué es un MVP de Microsoft y que no solamente sabe un rato, si no que es un muy buen comunicador.

Mr. Ballano tomo el rol de cliente e hicimos, siguiendo la batuta de JMB, una primera puesta en común de lo que es una historia de usuario. A continuación, siguiendo los dictados del “limonchelo” nos embarcamos en tres pomodoros para ir construyendo historias de usuario según las indicaciones del cliente. Lo cual resulto muy, muy fructífero al revisar cada paso desde múltiples ángulos y experiencias. Y no dudar en detenernos hasta quedar todos conforme del porqué y del cómo de las historias que iban surgiendo. Finalmente completamos dos y casi tres historias, en un interesante diálogo constante. Y que condenso en las siguientes conclusiones:

Historias de usuario

  • Las reuniones iniciales con el cliente han de ser con pocas personas.
  • El uso de las palabras en inglés no tiene sentido si la conversación se hace en castellano. Es decir utilizar As a role, ability, benefit queda muy “guay”. pero al final lo que usamos es “Cómo”, “quiero” y “para”.  Vamos, mi sensación de que hay mucho esnobismo se ha reforzado. Teniendo en cuenta que soy bastante “taliban” del uso del castellano en el software (toma contradicción)
  • El glosario del dominio lo debe construir el cliente y nosotros lo debemos seguir de forma lo más natural posible para que no halla errores de apreciación como entre las palabras  “ver” o “consultar” un resultado. Lo importante es lo que signifique para el cliente y nosotros asumir ese significado como lenguaje del dominio.
  • Tengo que tener más paciencia. Acostumbradísimo como estoy a tratar con clientes de todos colores y sabores, con cuatro preguntas y media obtuve la misma información que se tardo media hora en alcanzar más tarde. Y me apresuré y “saque los pies fuera del tiesto”. Lo bueno es que me di cuenta de mi impaciencia en ese momento y no volví a salirme del timming.
  • Al principio del dialogo con el cliente sobre lo que quiere, lo que se obtienen son historias épicas. Osea, aquellas que no tienes claro el cómo se van a desarrollar. Y de las cuales van a salir historias de usuario concretas.
  • Los roles van emergiendo en la propia construcción de las historias. Si bien hay que tener unos roles “épicos” al principio, siguiendo el principio de tomar las decisiones en el último momento, hay que esperar que dichos roles se definan a sí mismos según las historias vayan adquiriendo más precisión. Aquí JMB nos hizo gala de lo que ocurre en un equipo cuando un miembro sale “por peteneras”… que el resto del equipo pasa de el (eso sí, con mucho cariño). Y se entra en un dialogo de conflicto con el cliente. Trampa en la que hay que tener mucho cuidado en no caer cuando piensas que sabes más que tu cliente sobre su producto y que, además, se lo tienes que demostrar.
  • Es importante la primera premisa “Como”. Es decir el rol va a marcar el resto de la historia de usuario ya que puede no ser la misma dependiendo de quien la realice. Yo caí en la confusión de cambiar el rol de acuerdo a la premisa en que estábamos y me monté un lio yo solo que de forma muy satisfactoria el resto de los asistentes (los que hablaban claro) me ayudaron a clarificar.
  • Mi gran descubrimiento de la reunión: “Confirmación”. O la prueba de validación. A primera vista es algo tan simple como que el cliente diga cuales son las condiciones que se han de cumplir para que se de por realizada la historia. Pero, es curioso, con esta premisa hace emerger mucha más información de la esperada. Primeramente, al ser dependiente del rol, conduce al cliente a ponerse en la situación de dicho rol y a marcar las diferencias con otros roles -emergen las características propias del rol-. A continuación, las pruebas de aceptación inducen a encontrar nuevas historias de usuario o requisitos, ya que es ver el cubo desde otro punto de vista. Y, como en el caso de la tercera historia de usuario, si existen aceptaciones dependientes o condicionales, te permite “oler” que van a surgir aún más historias de usuario o requerimientos que en las premisas anteriores era mucho más difícil de obtener.

Mi retrospectiva (+)

  • La idea de Ballano ha sido muy buena.
  • Me he quedado con ganas de más.
  • El nivel de los participantes era alto. Quien no aportaba experiencia, aportaba conocimientos. Pero no hubo grandes “salidas de tiesto”.
  • He aprendido mucho. Ha sido una buena reunión.

Mi retrospectiva (-)

  • El facilitador debió de ser Ballano. JMB, con toda su buena intención, se convirtió en un proxy de ideas y decidía cual y de qué manera se plasmaban. Dirigió en demasía, para mi gusto, la actividad.
  • Hubiera querido que nos ajustáramos al guion de la reunión y hacer grupos de trabajo. Para sentarnos en circulo y quitarnos la palabra el uno al otro (menos los que levantaban la mano) podíamos irnos a tomar cervecitas. Suena estricto, pero es que en dos horas hubiéramos echo más que dos historias de usuario. Y centrar un poquito más las disertaciones, que al final nos vamos por los cerros de Úbeda.
  • La retrospectiva fue terrible. No se hablo por turnos, por lo cual hablamos los que hablamos siempre. Por lo cual muchos no hicieron retrospectiva. JMB saco finalmente el látigo y obvió todo aquello que a sus oídos no le parecía correcto o con suficiente interés. Por lo cual en el tablero se leía lo que el pensaba y no lo que el grupo decía. Por lo cual el grupo no se sintió identificado con la retrospectiva y es como si no la hubiéramos echo. Y así se levantó la reunión, sin ninguna conclusión más que “esto se ha acabado. Vamos que nos vamos”.

Mi retrospectiva (Λ)

  • Hacer otra reunión o incluso una User History Dojo.
  • El cliente debe ser el facilitador. Podría ser una pareja. Y debe ser mucho más contundente.
  • Quitarle el lápiz a JMB.
  • Buscar un sitio más grande que Nayade. Que petamos su sala.
  • Incentivar que la gente callada hable más.
  • Un token para el turno de palabra. Y así evitar un poquito que los de siempre estemos rajando todo el rato y no caer en corrillos. Que, aunque poco, caímos todos.

063

 

Y ahora, este viernes, nos vemos en alicante!!

lunes, 14 de febrero de 2011

HTML.Helper y EF4.0. Evitar los campos nullables.

Estoy construyendo una pequeña aplicación CRUD para aprender y practicar MVC3 + Razor + Entity Framework 4.0. El objetivo es hacer un pequeño programa muy liviano para poder correr en un navegador de cualquier smartphone actual sin necesidad de tener que tener un programa cliente.

Empezando de la manera clásica, primero me he echo mi modelo de datos en sql y después he creado el modelo en EF 4.0. Coser y cantar. Sin los extraños problemas de la versión anterior.

Lo curioso es que algo que me he encontrado y que me sigo encontrando en los diferentes esquemas de datos, es la posibilidad de tener campos nullables en la sql. Y en el EF provocan cierta incomodidad al trabajar con ellos.

Por ejemplo, algo tan sencillo como declarar un helper para poder editar un número se complica si el campo que estamos trayendo es del tipo nullable (int?).

        <div class="editor-field">
@Html.EditorFor(model => model.numeroEntradas)
@Html.ValidationMessageFor(model => model.numeroEntradas)
</div>



Osea, un buen consejo para trabajar más cómodo: haz tus campos en la base de datos “no nullables” y ponle un valor por defecto. Te evitaras dolores de cabeza.

jueves, 10 de febrero de 2011

Los límites de smalldatetime

SQL es para mí una fuente de contradicciones constante. Por una parte es indudable que es el lenguaje perfecto para su objetivo: manipular datos de la forma más eficiente posible. Pero, como desarrollador en lenguajes de programación, la lógica me parece enrevesada y muchas veces confusa.

Así tenemos el objeto smallDateTime. Un objeto de fecha normal y corriente. ¿No? Pues no. Tiene márgenes temporales más reducidos que el tipo DateTime. Exactamente del 01/01/1900 al 06/06/2079. Me imagino que la literatura del porqué de estos valores será variada y completa. Pero la limitación de 1900 convierte un error de traducción en una excepción de la base de datos.

Asique, en mi opinión, no utilices smallDateTime y utiliza siempre DateTime.

jueves, 3 de febrero de 2011

ActionLink a otro controlador

Curioso, además inesperado. Quiero hacer un enlace desde mi tabla de competiciones a el detalle de puntuaciones de  dicha competición. Las competiciones se generan en CompeticionesController y quiero que llamen a PuntuacionesController, al método Details. Pos ná, miro por encima el porrrón de sobrecargas del helper Html.ActionLink y pongo:
@Html.ActionLink("Puntuar", "Details", "Puntuacion", new { id = item.idCompeticion })

Lo cual provoca un curioso error ya el enlace en vez de llamarme a Puntuación, sigue apuntado a Competicion, además de meterme un parámetro que no es el esperado.

http://localhost/ArcherySystem/Competicion/Details?Length=10

La solución es añadir un quinto parámetro, de los 9 que existen sobrecargados.

@Html.ActionLink("Puntuar", "Details", "Puntuacion", new { id = item.idCompeticion }, null)

Espero que sea de utilidad.