El concepto original "Campo de Scrum" definido por Nonaka y Takeuchi describe un entorno de trabajo con principios ágiles en equipos motivados, con delegación y  "empowerment", que desarrollan proyectos de forma iterativa a incremental, que no dividen el ciclo de desarrollo en fases, comparten el conocimiento por socialización (comunicación directa)...  

La implementación de un campo de scrum no depende de las prácticas empleadas (Backlog - Burndown / historias de usuario / Etiquetas kanban ...) o del ámbito de aplicación (proyecto, producto o empresa).

La implementación que Jeff Sutherland realizó en 1993 en su equipo en Easel Corporation, a nivel de proyecto, que Ken Schwaber  documentó, en el libro Agile software development with scrum y que difunde la Scrum Alliance, es una implementación concreta, como lo son tambien cada una de las desarrolladas originalmente por Canon, NEC, Xerox, hp, Honda,  Epson... Es buena, pero nada impide diseñar un campo de scrum con flexibilidad en las prácticas para  adecuarlas a cada realidad, y con ámbito de proyecto, producto o de empresa, según sea para un equipo, departamento (por ejemplo de I+D en una software factory de procesos), o de organización en su conjunto.

Tomando el concepto original de Scrum y "des-monopolizándolo" de la Scrum Alliance, es posible plantear implementaciones con diferentes prácticas y también a nivel de producto o de empresa. Con esta visión de Scrum Manager la agilidad da su mejor resultado cuando se implican y alinean los diferentes ciclos de la empresa: estratégico, proyectos y producción.

 

 

Leer más...

Desde el día de hoy, soy consultor titular en la comunidad internacional Agilar! He aquí la prueba. Estoy muy contento con esto, Agilar está conformada por profesionales realmente espectaculares, a muchos de ellos he tenido el gusto de conocer debido a algunos encuentros internacionales a los cuales he tenido la oportunidad de asistir. Es un honor el haber sido [...]

Una nueva traducción de Agile Spain coordinada por Ángel Medinilla quién ya tradujo el libro anterior de Kniberg y Skarin, “Scrum y XP desde las trincheras“.

Ángel resume muy bien en su anotación el libro y el por qué de esta y anteriores traducciones así que no voy a añadir ni una palabra más.

Nada más que felicitar a todos los que han tomado parte en este proyecto: Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano. Felicitaciones también, cómo no, a Ángel Medinilla.

Aquí tenéis el enlace directo al libro en español.

Lo añado también a la página de Más Información.

Uno de las objetivos que tenemos en Agile Spain es crear y traducir contenido sobre las metodologías ágiles en Español.

Por este motivo, he traducido el Juego del Valor de Negocio creado por Veera Peeters y Pascal Van Cauwenberghe, el cual es un juego de simulación sobre prioridades de funcionalidades e historias de usuario así cómo su valor de negocio. Este juego se ha jugado varias veces en diferentes conferencias como la XP o Scan Agile con muy buenos comentarios sobre él.

Podéis encontrar el juego en aquí (pagina en inglés) o bajarlo directamente desde éste enlace directo. Espero que lo encontréis de utilidad y también, cómo no, que os divirtáis y aprendáis jugando.

Muchísimas gracias a Leo Antolí (también de Agile Spain) y Thomas Wallet (de Pragma Consultores) por la revisión de la traducción y todas sus correcciones y comentarios.

Para los alicantinos que podáis acercaros, el próximo jueves día 4, expondré el seminario "Agilidad: mejores prácticas para desarrollar software" en el salón de actos de la Escuela Politécnica superior de la Universidad de Alicante.

 Será a las 12 de la mañana. La entrada es libre, con inscripción previa en esta página.

Vuelvo a hablar de libros, esta vez para presentar la traducción de un libro Henrik Kniberg y Mattias Skarin al castellano. Se trata del libro Kanban vs. Scrum publicado inicialmente a través de InfoQ. Ahora, gracias a Agile-Spain podemos disponer de este pequeño gran libro en castellano.

Ha sido un trabajo colaborativo, coordinado por Ángel Medinilla, donde han participado personas del grupo de Agile-Spain, que con ganas de contribuir a la comunidad hispano-parlante han realizado un gran trabajo. Desde aquí gracias a Angel, Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano
Ángel os dará más detalles del libro en su blog, y podeis descargarlo desde este enlace.

A esto le hay que dar publicidad. Angel Medinilla lo comenta mucho mejor en su blog. Desde hace unos días en Agile Spain estaban traduciendo el libro Kanban vs. Scrum al castellano.

El resultado de la traducción ha quedado un poco grande (74Mb), pero están en ello. Los cracks que nos permiten disfrutar del contenido traducido son Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano.

Gracias a todos ellos. El libro lo podeís descargar desde aquí.

PS: Imagen via crisp.se

Como algunos sabéis, hace ya un par de añitos traduje desde Proyectalis el magnífico libro “Scrum y XP desde las trincheras” de Henrik Kniberg, uno de mis heroes Ágiles de todos los tiempos. Las razones que me llevaron a ello fueron varias. Fundamentalmente, mi consideración sobre la estupenda calidad de la obra, el caracter abierto de la misma (podéis descargarla gratuitamente en InfoQ o en Proyectalis) y el convencimiento de que uno debe devolver algo a la comunidad de vez en cuando. Esto vale para el software libre, las presentaciones de Slideshare, los libros abiertos, los wifi sin contraseña y cualquier otra cosa de la que os estéis beneficiendo de forma gratuita: si creeis en los mecanismos de retribución Kármica, y ya sabéis que yo lo hago a pies juntillas, hay que ir compensando lo que uno recibe o se genera una deuda, y las deudas es lo que tienen, que crecen exponencialmente. Total, que la cosa fue bien, porque conseguimos bastantes enlaces, tráfico y el pagerank de Proyectalis mejoró. Karma wins again.

Ahora Kniberg ha sacado un nuevo trabajo comparando Scrum con una aproximación nueva que se está realizando a los procesos de desarrollo: Kanban. Kanban no es nuevo para nada, surge como todas estas herramientas y disciplinas en el seno del sistema de producción de Toyota, “la máquina que cambió el mundo”. Consiste en la generación de una serie de tarjetas que representan los productos que se están desarrollando y que actuan como testigos de una carrera de relevos a lo largo de la línea de producción, disparando los eventos de fabricación conforme van siendo necesarios. La ventaja que pregonan los partidarios de Kanban para el desarrollo de software es la reducción del número de reglas y obligaciones respecto a otras metodologías: nada de planificación de producto, nada de scrum diario, nada de retrospectivas; sólo flujo productivo, priorización y limitación del número de tareas en curso en un momento dado (WIP o Work In Progress).

Es un planteamiento muy positivo para equipos que ya han “disuelto la regla” de Scrum y han interiorizado muy bien el proceso, o bien para equipos de mantenimiento u operaciones en los que los “tickets” deben ir atendiéndose conforme van generándose y no es factible realizar planificaciones ni predicciones a medio o largo plazo. El problema estiba en que equipos sin experiencia previa en Ágile se vean atraidos por la simplicidad de Kanban y entonces no lleguen a interiorizar los importantes conceptos contenidos en los roles, procesos y artefactos de Scrum. Por ello este trabajo de Kniberg, en colaboración con Mattias Skarin, es tan importante para todos aquellos que quieran iniciar una experiencia con Kanban, ya que en él resumen tanto las diferencias como los parecidos y la manera de combinarlos ambos de la forma más efectiva posible.

Hay que reseñar que esta vez la traducción ha sido coordinada por Proyectalis pero realizada por el equipo de contenidos de Agile Spain. Concretamente hay que agradecer la colaboración desinteresada de Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano.

Así que aquí lo tenéis. A la fecha de redacción, y por culpa de as múltiples versiones de MS Word y el puñetero filtro PDF de Mac, la versión PDF pesa unos 74Mb (OMG!), pero procuraremos bajar esa cifra en los próximos días. Si alguien no tiene tanta paciencia, lo podéis ir bajando ya de aquí.

Actualización 29/01/10: nueva versión, con un peso mucho más razonable aunque con mayor margen… Gracias a Xavi Albaladejo y Antonio Kobashikawa por liarse con el PDF (es probable que subamos una versión con márgenes correctos pronto, ¡Beta perpétua!). Ah, por cierto, lo lamento por todos los que se han “fusilado” este artículo en sus sitios en vez de enlazar aquí, pero el enlace anterior ha dejado de funcionar… ¡Oooh, que mala suerte! . Esto os pasa por enfadar al enanito del Karma…

Compártelo

Se me pasa Enero y todavía no he escrito ningún post serio. Y esto no puede ser. En Diciembre tuve la suerte de ser invitado a las III Jornadas Java de Alicante donde hablé un poco sobre mi experiencia en el desarrollo ágil. Las transparencias de mi charla están aquí, pero como tuvimos mala suerte no hubo manera de recuperar el audio. Así que como hay una serie de diapositivas que necesitan su explicación, voy a ver si tengo la constancia para mantener una serie de posts sobre el tema.

La primera imagen que mostraba en la charla era super llamativa:



Es un cartel de la película 300. Esta es una de las cosas que he aprendido desde que soy desarrollador. Y es que un equipo pequeño puede hacer las cosas mucho mejor que un equipo 50 veces mayor. Parece una barbaridad, pero al menos a mi la experiencia me ha mostrado que es así. En mi caso personal tengo a Jobsket. No nos quiero tirar flores. Somos tres personas y hacemos lo que podemos, lo mejor que podemos. Pero todos los clientes a los que vamos se quedan alucinados con el producto y con el hecho de que seamos tres personas en el equipo. Técnicamente todo el mundo coincide en que somos mucho mejores que las alternativas. El aspecto comercial ya es otra historia, claro :)

Pero no quiero ser egocentrista aquí. En la charla hablaba de otra historia. Una historia de tres amigos que fueron capaces de hacer un producto mejor y más querido que el desarrollado por una empresa con más de cien personas dedicadas al mismo. Mis amigos tenían el software funcionando a los pocos meses, mientras que a la empresa en cuestión le llevó años ponerlo en marcha, y creo que aún están en ello. Cuando lo puso en producción causó el caos absoluto: pésimo rendimiento y consumo de memoria y recursos, falta de usabilidad, quejas de los usuarios, vamos que casi causan una huelga general.

Por el contrario todos los usuarios del software de mis amigos lo quieren con locura. ¿Cómo lo consiguieron? Pues siguiendo una serie de medidas muy simples y de mucho sentido común:

• Desarrollo iterativo.


• Despliegue de versiones cada poco tiempo.


• Implementar sólo las funcionalidades que quieren los usuarios.


• Reunirse frecuentemente con los usuarios y que sean ellos los que decidan como quieren que funcione el interfaz.


• Evitar el desarrollo en cascada. No perder el tiempo con arquitecturas mastodónticas que tardan meses en materializarse.


• No perder demasiado el tiempo en documentación. Es necesaria, pero al estar los usuarios tan metidos en el diseño del sistema, lo cierto es que todos ya sabían como se usaba la aplicación. Evitar documentar al principio.


• Trabajo. No hace falta ser los mejores para que todo funcione. Normalmente con dedicación, empeño y disciplina todo se consigue.

Son unos cracks. La gran clave por la que los usuarios querían la aplicación artesanal y no la llamémosla industrial era sin duda la involucración de los usuarios. En realidad el equipo de mis amigos no eran tres personas, sino que eran ellos tres más los cientos de usuarios que participaron en su desarrollo. Usuarios que fueron construyendo ellos mismos la aplicación. Usuarios a los que se les tuvo muy en cuenta a la hora del desarrollo. Y a la hora de la verdad, los usuarios sienten esa aplicación como suya. Es algo en lo que han participado y que se ha desarrollado tal y como a ellos les es más útil para ahorrarse trabajo. Trabajando de esta manera, es muy difícil que los usuarios prefieran otro proyecto, lo desarrollen, 3, 30 o 300 personas.

No sé si soy yo pero para mi el cartel y la película de 300 me recuerda un montón a un departamento de desarrollo. Me imagino que otros departamentos pueden pensar lo mismo del suyo, pero el hecho de que somos un tipo de trabajadores que suele estar aislado, que sufre la ira de managers y usuarios :), y ahí estamos, resistiendo, intentando ser profesionales y hacer las cosas bien mientras los comerciales nos asedian con nuevos marrones y funcionalidades. No sé como lo veis vosotros, pero a mi se me asemeja la historia bastante. Eso sí, al final los espartanos siempre pierden. mmmm, da que pensar :)

Ya está actualizado, y disponible para descargar (o comprar) el blook con los artículos más relevantes de Navegápolis hasta enero de 2010.

Con un mosaico de 120 artículos, el libro compone una visión poliédrica del escenario de las pequeñas y medianas empresas de programación. De la gestión de los proyectos y las personas en las empresas de software.

Mi opinión no puede ser objetiva, soy el autor; pero por eso mismo te lo recomiendo

• Descargar en formato PDF
• Comprar una copia impresa

 

 

 

 

 

Juan Palacio, David Alfaro y un servidor grabamos un podcast este pasado sábado sobre el papel que en Scrum juega el Propietario del Producto o Product Owner.

Cualquiera que se haya aproximado mínimamente a Scrum sabe que la labor del Propietario del Producto es representar la voz del cliente asegurando que el equipo de desarrollo se enfoca en los temas adecuados desde la perspectiva del negocio.

Evidentemente dentro de esta definición caben muchísimos matices y detalles. Precisamente esto es lo que tratamos en el podcast.

Los asuntos más relevantes que hemos tratado son:

Las labores del Propietario de Producto, todas ellas relacionadas con la gestión de los requisitos del proyecto de un modo u otro:

Mantener contento al cliente.
Realizar la captura de requisitos.
Priorizar los requisitos.
Digerir esos requisitos antes de que lleguen al equipo de desarrollo.

También hemos hablado sobre la diferencia entre el papel que juega el Propietario del Producto comparándolo con roles como el de Product Manager que aparece en otras metodologías. Hemos comentado sobre este punto como la principal diferencia es el uso de determinados artefactos (product backlog, historias de usuario) y liturgias (scrum planning meeting, scrum review) y como la labor del Propietario del Producto esta en todo momento guiada por la búsqueda de valor para el cliente.

Hemos hablado también de como la priorización de requisitos es la técnica que lleva a lograr ese retorno de la inversión.

Hemos hecho mucho hincapié en la importancia de tener este rol perfectamente detectado entre los participantes en el proyecto y que su voz debe ser única y respetada en todo lo relativo a que se debe hacer en el proyecto.

Sirva este post de introducción al tema y de invitación a que escuchéis el podcast.

Si os a gustado este postcast no os perdáis otros muchos relacionados con Scrum y la agilidad en el canal Open Knowledge Scrum Manager.

¡Espero vuestros comentarios!

 

En estos encuentros ágiles se elaboró un diagrama de prácticas y se hizo una priorización considerando un proyecto sin evolución posterior y de corta duración.   La priorización de las prácticas ágiles a aplicar en un proyecto puede depender de diferentes factores:

• El tipo de proyecto, respecto a si no va a tener evolución posterior, o bien si se trata del desarrollo de un producto.
• Su tamaño (esfuerzo necesario a realizar), su complejidad, el número de personas implicadas.
• El conocimiento de la tecnología y del dominio (tipo de negocio) por parte del equipo.
• El conocimiento del proceso de trabajo.
• El conocimiento entre los miembros del equipo, si han trabajado anteriormente juntos.
• El tipo de aspecto a mejorar dentro del proyecto (calidad, tiempos de entrega, productividad, etc.).

  Hacer clic en la imagen para ampliarla           Comentarios sobre las prácticas   A continuación se enumeran algunos de los comentarios que se hicieron en el encuentro:

• Visión compartida. Es muy importante que el equipo tengo una visión compartida de los objetivos (mediante el Product Backlog) y de las tareas a realizar (mediante el Sprint Backlog).
• Propiedad colectiva del código. Hay que erradicar la costumbre de que “esta tarea la tendrá que hacer esta persona por que fue él quien hizo esta parte del producto”. Cuanto más se tarde en erradicar, peor será. Para dar soporte a esto, existen prácticas que definen los estándares de trabajo del equipo (estándares de codificación, patrones de diseño) y prácticas de transferencia de información y conocimiento (peer reviews, pair programming, etc.).
• La inversión en Unit Testing se recupera pronto, a partir de los 2 meses.
• Aunque el cliente tenga poca disponibilidad para asistir a demostraciones (por ejemplo sólo puede hacerlo 1 vez al mes al mes), es importante hacer demostraciones internas (por ejemplo cada 15 días) para cerrar objetivos y tener estabilizado el producto.
• El Scrum Master debe detectar quienes trabajan de manera más solitaria y no son suficientemente transparentes con el trabajo que están realizando. En esta línea, se pueden fomentar las peer reviews.
• Es más barato y produce un mejor resultado hacer pruebas unitarias automatizadas que funcionales.
• En el tipo de proyecto que se trató en el encuentro (sin evolución posterior y de corta duración, no desarrollo de producto), puede no ser necesario hacer diseño funcional ni diseño técnico. Puede ser suficiente la propia documentación del código y la que proporcionan automáticamente las herramientas de desarrollo (esquema de base de datos, etc.).
• Se comentó que la calidad interna debería ser siempre alta (aunque se tratase de un proyecto sin evolución posterior y de corta duración), ya que esto facilita desarrollar incrementalmente, encima de código ya escrito, y el equipo también tiene que estar a gusto con lo que se está haciendo.
• Hubo una propuesta de no utilizar una gestión de defectos (bugs) formal. Para que no fuese necesaria, se planteó el resolverlos lo antes posible y/o gestionarlos directamente en el sprint backlog.

  Para saber más

• Agile Adoption Patters - Amr Elssamadisy
• Patterns of agile development adoption – The technical cluster – Amr Elssamadisy

  Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas. Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles:http://agile-spain.wikidot.com/quedadas-barcelona         Nota del system administrator de ProyectosAgiles.org:   Si estás viendo este artículo mediante el RSS de ProyectosAgiles.org, asegúrate de estar accediendo a través de la siguiente URL: http://www.proyectosagiles.org/rss.xml    Se ha detectado que (por razones históricas) también se está accediendo desde: http://www.proyectosagiles.org/taxonomy/term/11/0/feed, que sólo muestra un conjunto muy reducido de artículos.  

 

He subido a Slideshare un pequeño extracto de nuestro seminario de gestión del portfolio de proyectos aliñado con unas pocas slides de nuestro curso de introducción al PMBOK desde una perspectiva Ágil, en el que introducimos el concepto de Earn Value Managemente aplicado a proyectos Ágiles y Scrum Multiproyectos (oh yeah!). No se, ayer en la ducha (suele ser mi momento más creativo e inspirado del día, qué cosas… ) se me ocurrió que tenía sentido reordenar este conjunto de slides en esta forma y dar un poco de vidilla a un concepto que está poco trabajado tanto en la literatura como en el material disponible on-line: que pasa cuando salimos del típico ejemplo de libro de “un cliente, un equipo, un proyecto” (Ein Volk, ein Reich, ein Führer! ), al auténtico carajal que vivimos todos en las trincheras reales: múltiples clientes, múltiples proyectos en distintos momentos del ciclo de vida (unos cerrándo, otros en preventa, etc.) y múltiples equipos, a veces compartiendo proyectos (relaciones “muchos a muchos” y esas cosas). Y nada, que aquí lo dejo. Ya sabéis que estoy disponible para montar saraos y hablar de estas cosas si os ape

100115 Proyectalis Multiproject Scrum View more documents from proyectalis.

Nota: que pasada como abuso de los paréntesis… Y de los puntos suspensivos . Propósito de año nuevo al saco.

Compártelo

Dos extensiones ágiles para Google Wave desarrolladas por Mastering Wave: Scrumpoker y taskboard, para compartir en Google Wave planificaciones de póquer, o un tablero Kanban. Son muy recientes y están las dos en beta.No he tenido tiempo ni oportunidad de probarlas, pero parecen interesantes.

• Scrum Task board gadget
• Vídeo demo en youtube
• Scrumpoker
• Vídeo demo en youtube

 

Hoy me he encontrado con una página del señor Alistair Cockburn (autor de “Crystal Clear” o “Writing Effective Use Cases” entre otros) dónde se discute una extensión del “Manifiesto Ágil” para mostrar la visión del usuario, lo cual me parece una gran idea.

El manifesto que está ahora mismo bajo discusión (puedes dar tu verisión u opinión en la página -en inglés-) dice más o menos lo siguiente (hay cuatro versiónes que se diferencian en cómo están escritas, no en las ideas, así que traduzco, malamente, sólo la primera):

Queremos equipos de producto que entreguen productos
… que no sólo “funcionen” o concuerden con una lista, sino que resuelvan mis problemas,
… que no sólo encajen con mis necesidades de momento, sino que evolucionen con mis necesidades,
… que no funcionen de la forma que los diseñadores piensan que deberían funcionar, sino que funcionen de la manera que yo trabajo,
… que no sólo los vea como herramientas, sino que lleven a cabo el trabajo que hago,
… que no sólo los use, sino que disfrute usándolos.

Bastante razonables aunque no veo la última del todo. No creo que en muchos casos un usuario quiera “disfrutar” con el producto. Estaría muy bien, claro que sí, pero dudo que sea la palabra correcta para alguien que usa una aplicación durante todo el día para calcular lo que sea, por ejemplo. Yo me decantaría por algo como “sino que sean fáciles de usar”, “sino que hagan mi vida más fácil”, “sino que hagan mi trabajo más placentero”… algo así.

¿Qué pensáis vosotros que debería contener el manifesto?

Nota: No tengo muy claro cual es la traducción correcta de “see through to the work I’m getting done”. Lo he traducido como “llevar a cabo el trabajo que hago” pero quizá debería ser “ayudarme con el trabajo que hago” o alguna otra cosa.

El primer libro sobre Desarrollo Guiado por las Pruebas (TDD) en castellano acaba de ver la luz. Carlos Ble junto a algunos colaboradores ha editado un libro más que recomendable para cualquiera que esté interesado en esta metodología de desarrollo, o en las metodologías ágiles en general.
Es un libro que además aporta conocimientos generales de diseño basado en objetos, o metodologías ágiles. Hace un repaso con ejemplos de cómo desarrollar con TDD, e introduce el desarrollo guiado por las pruebas de aceptación (ATDD).
Sin duda un libro que debes descargar, es de libre distribución, y estudiar con profundidad. Seguro que aún mejor si se lo compras o le haces una pequeña donación :), que merece la pena. Yo he tenido el placer de poder seguir el proceso de creación del libro como pequeño revisor, y el material creado por Carlos es muy bueno, espero impaciente su próximo libro ;)

• Diseño Ágil con TDD

Aprovecho para recordaros la existencia del grupo de TDD en castellano!

Últimamente va de libros, pero este tiene un sabor muy, muy especial.

Carlos Blé ha escrito este libro sobre “Diseño Orientado por Pruebas” o TDD (Test Driven Development en inglés) principalmente, aunque en general trata de desarrollo de software ágil. El libro empieza por una introducción a las metodologías ágiles y a lo que es TDD para ir, poco a poco, metiéndose más de lleno con las pruebas en sus distintos niveles (unitarias, integración, aceptación, etc.), dobles de prueba, frameworks para test unitarios y de aceptación, etc. Termina, además, con una breve introducción a la integración continua.

Sin embargo, lo mejor del libro reside en el aspecto práctico ya que su mayor parte se enfoca en enseñar cómo diseñar software usando TDD de una manera totalmente práctica. Para esto usa distintos ejemplos, en un principio, para moverse después a un desarrollo completo de una aplicación (una calculadora) usando el desarrollo orientado por pruebas. Los ejemplos, por cierto, vienen dados en C# (mayoritariamente) y Python.

No os cuento más, ¡tenéis que leerlo!

En el portal www.dirigidoportests.com podéis encontrar más información sobre el libro, descargar una versión gratuita en PDF, dejar comentarios, ayudar con la “fé de erratas”, leer más sobre TDD e, incluso, comprarlo en Lulu si os ha gustado y creéis que merece la pena (espero que así sea).

Como decía al principio de esta anotación, este libro tiene un sabor muy especial para mí ya que Carlos me brindó la oportunidad de colaborar escribiendo un capítulo del mismo. Ha sido todo un honor y un placer ayudar a Carlos con este pedazo de libro que, si no me equivoco, es el primero (o al menos de los primeros) de esta temática en español.

He de añadir que he pasado un tiempo excepcional escribiendo, revisando y, sobre todo, discutiendo con Carlos. He aprendido muchísimo con él y de él. Muchísimas gracias, Carlos, ¡eres un fenómeno!

Se agradece un montón disponer de un libro de TDD de este nivel, en español y con versión pdf libre, aunque si te lo puedes permitir, merece la pena recompensar al autor comprando una versión impresa , o enviando una donación desde la página del libro .

Imprescindible el libro que acaban de publicar Carlos Blé y colaboradores sobre TDD, la técnica de diseño y desarrollo de software que forma parte de la metodología XP.

A las razones de Ken Beck de por qué usar TDD:

• La calidad del software aumente (y veremos por qué).
• Conseguimos código muy reutilizable.
  
• El trabajo en equipo se hace más fácil, une a las personas.
• Nos permite confiar en nuestros compañeros, aunque tengan menos experiencia.
• Multiplica la comunicación entre los miembros del equipo.
• Las personas encargadas de la garantía de calidad adquieren un rol más inteligente e interesante.
• Cuando revisamos un proyecto desarrollado mediante TDD, nos damos cuenta de que los tests son la mejor documentación técnica que podemos consultar a la hora de entender qué misión cumple cada pieza del puzzle.

Carlos añade:

• Incrementa la productividad.
• Nos hace descrubrir y afrontar más casos de uso en tiempo de diseño.
• La jornada se hace mucho más amena.
• Uno se marcha a casa con la reconfortante sensación de que el trabajo está bien hecho.

Leer más...

No nos gusta aprender recetas, porque no creemos en "balas de plata". Preferimos aprender nutrición: ser cocineros y no pinches. Saber cocinar nuestras propias recetas, con el sabor, vitaminas, nutrientes y presentación, más adecuados a nuestra empresa.

Scrum Manager: Preferimos la flexibilidad a la rigidez.

 

 

Leyendo “The Pragmatic Programmer” me vino a la cabeza que este es un libro que daría a todo nuevo programador (especialmente a los que tengan poca experiencia) que fueran contratados por mi empresa. Esto, a continuación, me trajo recuerdos de uno de los mejores jefes que he tenido.

¿Qué hace de un jefe un buen jefe?. Una pregunta complicada que, seguramente, tendrá distintas respuestas dependiendo del carácter de la persona a quién preguntes. No creo que todos tengamos la misma idea de lo que es ser un buen jefe aunque, estoy seguro, habría muchas cosas en común.

En mi caso particular, esta persona era más otro miembro del equipo que un jefe típico que ve las cosas desde una perspectiva más alejada del trabajo diario del resto del equipo. Esto no quiere decir que no tuviera tareas distintas a las nuestras, que las tenía y muchas, pero siempre que podía, intentaba sacar tiempo y ayudarnos con nuestras tareas. Esta ayuda podía venir de muchas maneras: hablando sobre el tema, abriendo debate entre todos para ver cómo hacer las cosas mejor, cómo mejorar, haciendo preguntas incómodas (eso sí, dejando claro que quería saber por qué hacíamos esto y no lo otro y que no nos estaba desafiando. Decía: “I’m not challenging you, I only want to know why”), compartiendo su experiencia en temas parecidos, escuchando, mostrando apoyo, etc. Una persona que siempre estaba ahí para ayudar y sacar las cosas adelante cuando hacía falta y que marcaba cómo quería que fuese el equipo con ejemplo y hechos (no sólo con palabras).

Como os podéis imaginar, su relación con el equipo era más la de un colega (con el que salíamos a tomar cañas -por otro lado, debo mencionar que esto, en Finlandia, es bastante normal-) que la de un jefe, gerente o como lo quieras llamar y esto marca la diferencia. Algunos pensaréis que esto podría haber causado que perdiésemos nuestro respeto hacia él. Nada más lejos de la realidad. Lo que consiguió con esto fue un equipo muy cohesionado, que trabajaba muy bien junto y con un ambiente de trabajo excepcional.

También tenía las cosas muy claras y el carácter fuerte (lo que hacía que tuviese sus detractores en la empresa también, claro) pero esto, al menos para mi, no era impedimento para tener una buena discusión con él sobre cualquier tema aunque estuviese totalmente en desacuerdo conmigo. Nunca dijo, “esto se hace así porque lo digo yo” sino que intentaba convencer con razones y hechos y no con poder.

Cuando entramos en el equipo, lo primero que hizo fue regalarnos (de su bolsillo, por cierto), dos libros. Nunca he tenido una experiencia similar en ningún equipo o compañía en la que he trabajado. Fue un pequeño gesto (y esto, que quede claro, no le hace un buen jefe de por sí) pero, al menos para mi, marcó la diferencia y me causó una muy buena impresión.

P.D.: En caso de que os estéis preguntando, los libros fueron: “The fifth discipline” de Senge y “The Toyota Way” de Liker.