Principios

Me gustó esta lista de principios del libro "The People's Scrum" de @tobiasmayer.

Framework: nos comprometemos a seguir los principios ágiles utilizando Scrum.

Calidad: nos comprometemos a construir calidad en nuestros productos en todos los estados de su desarrollo. Así como también, revisar continuamente y mejorar nuestras técnicas para alcanzarla.

Personas: somos profesionales y tenemos la responsabilidad de respetar a los otros, actuar honestamente, comunicar abiertamente, y buscar y dar ayuda cuando sea necesario.

Proceso: nos comprometemos a trabajar con la organización para definir a proceso mínimo para guiar nuestras actividades durante la duración de una iteración, apoyando al equipo para lograr completar su trabajo.

Crecimiento: como individuos, nos comprometemos a mejorar y compartir nuestro conocimiento (en la compañía), cuando sea apropiado.

Germán

Read More

Primera persona del singular

Llevo un tiempo trabajando con equipos y, pensando retrospectivamente, me doy cuenta que muchas veces me encuentro/nos encontramos dialogando con compañeros o clientes, anteponiendo el pronombre 'yo' o usando verbos en primera persona singular. Este hecho marca el sentido de no pertenencia a nuestro equipo y atenta contra los ambientes colaborativos. Creo que una de las maneras de mejorar la comunicación y la colaboración, y que debería ser trabajada en retrospectivas, es la erradicación de este tipo de pronombres y verbos cuando hablamos en nombre del grupo. Potenciará el sentido de equipo, la pertenencia y el compromiso hacia él.

Germán

Read More

Tengo un problema (2)

Luego del éxito sin precedentes del post sobre el patito de goma (¿?) y de algunos de los comentarios que me llegaron, quise hacer una remasterización del algoritmo de la técnica con el feedback que obtuve.

Si tenés un problema que no podés resolver y te está bloqueando, entonces:

          Si trabajás remoto:

                1. Buscá un compañero en el chat para contárselo;

          Sino:

                2. Contáselo a un compañero en persona;

Si no tenés más remedio y no tenés un compañero a mano:
                3. Buscá un Patito de Goma y/o cualquier otro;

En otro caso:

                4. Googlealo :)

Germán

Read More

Tengo un problema

La técnica del patito de goma [1] (reformulada)

Muchas veces nos pasa que nos bloqueamos cuando tenemos que resolver un problema (en este caso, laboral). No podemos avanzar, nos volvemos menos productivos, incómodos y no disfrutamos de nuestro trabajo. Para evitar esto, lo que la técnica propone es, simplemente, contarle a alguien lo que nos pasa. Luego, en medio del proceso, nos daremos cuenta de lo que está fallando (eventualmente) y nos ayudará a resolver el tema que nos aqueja. Pero tiene un problema, hay que molestar a otra persona para que nos atienda. Es aquí dónde aparece el Patito de Goma. Cuando estés bloqueado usá el patito, contale lo que te ocurre y verás cómo, en muchas ocasiones, te ayudará.

Contado de esta manera, tiene algo que me hace ruido y que contradice el "espíritu" de este blog: atenta contra los ambientes colaborativos. Por lo tanto, mi propuesta es:

- Si tenés un problema que no podés resolver y te está bloqueando:

          1. Buscá un compañero para contárselo.

- Si no tenés más remedio y no tenés un compañero a mano:
          2. Buscá una Patito de Goma.

Germán

[1] http://developerscookbook.blogspot.com.ar/2010_11_01_archive.html

Read More

¿Por qué los testers necesitan aprender continuamente?

Últimamente estoy leyendo mucho a Lisa Crispin y Janet Gregory. Esta vez, encontré el artículo "Why Testers and QA Engineers Need to Learn Continuously?". Me parece atinado verter aquí algunos de sus conceptos ya que hacer un tiempo venimos diciendo que los testers trabajan con conocimiento.

1) Expandir tu conocimiento y tus capacidades te posibilitará incrementar tus oportunidades, tanto dentro como fuera de tu organización.

2) Testers quienes eligen aprender, abrir su mente y probar nuevas cosas, son más valiosos para sus equipos. Los buenos testers entienden tanto el negocio como los aspectos técnicos de su producto.

3) El aprendizaje reduce el stress. Invertir tiempo en adquirir nuevo conocimiento permite aumentar la confianza en cómo hacer tu trabajo y, además, hacerlo correctamente.

4) Cuando tu compartes nuevo conocimiento con tu equipo, "desafías" a tus compañeros a pensar nuevas y mejores maneras de hacer las cosas.

5) La sabiduría que da la experiencia combinada con el aprendizaje, el perfeccionamiento de tus skills y la constante actualización sobre las nuevas ideas que surgen desde la industria (y la academia), no sólo te vuelven más "vendible" sino que también te hacen más valorable dentro del equipo en el que trabajas.

6) El aprendizaje continuo te da la posibilidad de formar parte de una comunidad de pensadores que comparten experiencias e ideas que pueden crecer orgánicamente.

Más allá de todos estos puntos, debe existir una motivación intrínseca orientada a comprender las responsabilidades del tester y sus habilidades y a desafiar el status quo.

Germán

Read More

Necesitamos tener un tablero y una metodología, como sea!

A menudo sucede que me encuentro hablando con gente que piensa que hacer algo agile es implementar un tablero y con eso ya está (me ha pasado mucho en los últimos 3 o 4 meses). Verdaderamente, están haciendo algo: visualizando su trabajo en curso, sus lista de tareas y sus desvíos. Lo cual no es poco, pero...

El furor por las metodologías ágiles es tal que por momentos algunas organización necesitan aplicarlas a cualquier precio, cómo sea. Quizás sea un problema de "vacío metodológico" en dichas organizaciones, potenciado por el hecho de que algunos frameworks tiene pocas reglas, son "relativamente simple" y el tiempo de aplicación es corto. También, muchas veces existe una especie de "bajada de línea" de las gerencias sin permitir a sus equipo madurar y hacer crecer organicamente su necesidad de trabajar en un esquema colaborativo, iterativo y con todo lo que eso significa.

En conclusión, las metodologías ágiles son fáciles de aprender (son frameworks con pocas reglas) pero difíciles de aplicar correctamente. Sin embargo, pienso que también se han vuelto populares debido a que las organizaciones (no todas, pero bastantes) tienen este "vacío" que muchas veces atenta contra su buen uso.

Germán

Read More

Hacer testing es también capturar conocimiento - otra vuelta

El post anterior sobre este tema hizo bastante ruido. Recibí muchos comentarios/opiniones al respecto y me pareció interesante dar "otra vuelta". En realidad, esta vez es para dividir en un par de tracks los comentarios que recibí y "generar más conocimiento":

1. Testing Agile: hace un tiempo escribí sobre los principios propuestos en este libro, y efectivamente, de alguna manera, la idea expuesta en el post tiene implícitos estos principios.

2. Cualquiera puede hacer Testing: sinceramente, me cuesta creer en esto. He trabajado con gente que no es del palo y han tenido un excelente desempeño. Sin embargo, hay cuestiones técnicas, de análisis, gestión, etc. en las cuales hay una clara ventaja del informático. Seguramente en testing funcional es más factible,  pero si queremos ir en esta dirección deberíamos apuntar a gente informática, sin dudas. En otro momento, retomaré el tema.

3. El Testing no puede automatizarse completamente: No puedo estar más de acuerdo con esta afirmación. No hay dudas. Lo que sí surge aquí es, ¿qué automatizar y qué no?, ¿qué herramientas son las adecuadas?

4. Un fail como puerta de entrada hacia más conocimiento: Un bug permite a los developers explorar escenarios, situaciones, y código aún no explorado y con un fuerte impacto (potencial) en la funcionalidad de software. La forma operativa de capturar conocimiento en testing es a través de un bug.

Para terminar, no deja de sorprenderme la cantidad de comentarios y de gente que tiene las mismas inquietudes. Los lectores son como los testers que ayudan a generar más conocimiento en este blog!

Les dejo unos links a los comentarios que recibí -> 1, 2, 3, 4

Read More

No revisaré mails al inicio del día

Aquí les dejo la justificación científica de por qué es interesante tratar de implementar el lema "Stop Starting, Start Finishing". 

El video "La razón sobrevaluada", de Estanislao Bachrach en la TEDxRíoLimay del 2012 (en Septiembre de 2013 es la segunda edición), deja algunas perlitas:

1. Revisar mails al inicio del día consume mucha energía.

2. Dejar las actividades que nos consumen más energía para cuando estamos más descansados.

3. Priorizar

4. Visualizar

5. Escribir nuestros proyectos/ideas/compromisos para no tenerlos en nuestra cabeza constantemente.
6. Querer ser más productivos, nos hace improductivos.

Limitar nuestro WIP en pos de tomar mejores decisiones.

Read More

Responsabilidad, cambios y motivación: mi carrera

Buscando videos en Youtube, me encontré con un keynote de Alan Cyment en el Scrum Gathering 2012. Lo comencé a ver y la verdad que me enganche.

Cyment comienza dando un enfoque interesante sobre Scrum, cuál es su definición y su espíritu. La charla continua, y luego de contar algunas otras experiencias, hablar sobre las culturas organizacionales, Scrum fingido y otras yerbas, introduce un tema que me pareció muy importante y que me inquieta hace rato. Tiene que ver con el rol del las personas en las organizaciones y puntualmente, en los equipo de trabajo. Aquí es donde me quiero detener ya que, además, coincido bastante en lo que Cyment dice, más allá de alguna que otra postura extrema o solución propuesta. Algo al respecto ya había mencionado aquí.

Lo resumo en las siguientes tres bullets:

1. Debería ser responsable de mi laburo. Un tema que aquí se presenta es: "el problema siempre lo tiene el otro" y, si algo tiene que cambiar, ese no soy yo.

2. Debería poder gestionar mis cambios. Si algo no me gusta, trato de de cambiarlo introduciendo mejoras parciales y continuas o tratando de dar un cambio brusco para que la cosa cambie radicalmente.

3. Debería poder identificar qué me motiva. Cada uno puede tener motivaciones distintas por las cuales está en ese trabajo/empresa/equipo. En general, son casi las mismas (ambiente laboral, estabilidad, dinero, etc) aunque pueden estar en distinto orden de consideración.

Por último, y a modo de apreciación personal, creo que cada uno de nosotros comienza a crecer profesionalmente cuando se hace cargo y responsable de su propia carrera.

Read More