scrum distribuidoEl documento "Scrum Distribuido" es el resultado del primer taller de investigación (beta) de Open Knowledge Scrum

El estudio ha estado dirigido por José Miguel Vera y Sergio Yazyi, en el que han colaborado como autores junto a  Raúl HerranzNoel Mamoghli,  Edgar GonzálezDaniel MatulisVictor RatónMiguel SalasSalvador ArauzoFelipe Muñoz y Luis Farias . 

 El objetivo del documento es ofrrecer una primera información de las implicaciones de Scrum en un contexto distribuido. Para ello parte de las definiciones base, e identifica los retos más relevantes para un equipo distribuido, recopilandoy analizando la información para cada uno, con la propia experiencia profesional,  así como la del trabajo  realizado para la ejecución del estudio, que es precisamente el trabajo de un equipo distribuido.


 Safe Creative #1106149463894

Este artículo fue publicado originalmente en navegapolis.net el 21 de junio de 2011

 

hippieLa agilidad no es cosa de pegar post-it's en las paredes, o hacer de las estimaciones juegos de adivinanzas o partidas de póquer.

No se trata de convertir a equipos de programación, en grupos de boy-scouts, o en comunas de socialización.

La agilidad no nace de las formas sino del fondo: personas, motivación y cultura; y a diferencia de la producción basada en procesos, es muy sensible a la capacidad de las personas y al entorno de la organización.

Por razones de imagen, ninguna empresa admite en público problemas en su organización, pero este estilo se sostiene en personas con competencias muy altas, y como tan escasos son los buenos programadores como los buenos directivos, los campos de scrum que realmente funcionan son pocos.

Si me das de gestor a Ken Schwaber y de programadores a Kent Beck, Erich Gamma y Ron Jeffries ya verás que bien me sale Scrum, y dará igual que siga al pie de la letra el marco de Scrum técnico, o que empleemos las técnicas ágiles con las qeu nos sintamos más cómodos.

Si me das a un jefe "Pointy-haired" o un gestor "cuadriculado" y de programadores a media docena de aprendices... acabaré cansado de modificar el modelo de trabajo, y culpando a éste y al equipo por los resultados. 

No nos engañemos. Estamos hablando de agilidad. El origen de los problemas no hay que buscarlo en los procesos, los más importantes estarán localizados en alguno de estos elementos: toxicidad de la empresamotivación  o competencia de las personas; pero sea cual sea, ese no es el origen real. El real se encuentra en un nivel más profundo, porque... alguien dirige la empresa, contrata y gestiona a las personas, y está tropezando en las asignaturas pendientes de la gestión ágil:  motivación, organizaciones basadas en equipos y  gestión del talento  (que no de los recursos humanos).

Este artículo fue publicado originalmente el 29 de enero de 2009 en navegapolis.net

 

equipoAl aumentar el tamaño del equipo del proyecto, disminuye la productividad individual. Esta es una percepción recurrente, o al menos a mi me da esa impresión, y por eso me ha llamado la atención este consejo(*)del consultor de EE Times, Jack Ganssle:

Ponga a los mejores en los proyectos pequeños.
Los mejores desarrolladores son seis veces más productivos que el más flojo del equipo, pero sólo cuando se mide a ambos en proyectos pequeños.
A medida que el proyecto crece el mejor y el peor son igual de improductivos. Los grandes proyectos tienen grandes cantidades de ruido, reuniones, informes, e-mail...
Un espabilado atiende en las reuniones a la misma velocidad que un torpe.
 

(*) Este post se publicó originalmente el 4 de septiembre de 2007 en navegapolis.net. El artículo enlazado ya no está disponible. Otra referencia de Jack Ganssle a la misma idea se encuentra en The Embedded Muse 102, - copia local en navegapolis-

 

foto

La de arena

Las afirmaciones de Alistarir Maughan (Asesor jurídico para la Administración Pública británica de Morrison Foerster):

Estoy dispuesto a aceptar que si todo va bien la agilidad puede reducir el riesgo de fracaso del proyecto. Pero la agilidad simplemente no funciona en el mundo real de proyectos TIC para la Administración. Necesitamos un Richard Dawkins para reventar el mito del evangelio ágil

Hay razones claras por las que la agilidad no puede funcionar en la contratación con la Administración:

  • En el marco ágil se paga por un esfuerzo, pero no por un resultado concreto. Esto no puede funcionar en la Administración. 
  • Los departamentos se gestionan con presupuestos aprobados y cerrados para obtener resultados concretos.
  • La Administración está obligada por ley a seguir reglas de contratación abierta, lo que significa comparar diferentes licitadores sobre una base de igual a igual y decidir la mejor relación calidad-precio. La agilidad no da por adelanteado ni una descripción detallada del resultado, ni un precio cerrado. ¿Cómo cumplir con el requisito legal de que los contratos públicos son justos y abiertos?.
  • La administración opera con un modelo de toma de decisiones centralizado hacia arriba, mientras que la agilildad se basa en la autonomía y la delegación de decisiones hacia abajo. Esta es la clave para que pequeños equipos descentralizados puedan reaccionar con rapidez y adaptarse a nuevos escenarios.

Las decisiones en los proyectos ágiles se basan en la confianza mutua, por tanto son muy adecuados para proyectos internos y al mismo tiempo resultan inadecuados para contrataciones externas.

La de cal

El departamento de trabajo y pensiones brítánico (DWP) ha modificado los contratos que rigen el suministro  del sistema de crédito universal, por dos mil millones de libras añadiendo cláusulas para alentar a los proveedores a usarmetodologías ágiles en su desarrollo.
Estas modificaciones intentan asegurar que los proveedores abandonan los métodos convencionales de desarrollo de sistemas, acusados del fracaso de los grandes proyectos TIC.

Las cláusulas incentivan a los integradores de grandes sistemas a adoptar metodologías ágiles con lo que el DWP espera garantizar el buen fin del proyecto en la fecha comprometida de 2013.

vía: ComputerWeekly.com

¿Cuál es tu opinión? 

¿Estás de acuerdo con la afirmación de Alistarir Maughan: "Las decisiones en los proyectos ágiles se basan en la confianza mutua, por tanto son muy adecuados para proyectos internos y al mismo tiempo resultan inadecuados para contrataciones externas."

 

Publicado originalmente en navegapolis.net el 3 de julio de 2011

 

brujula En los 80 se nos decía:"Cuanto antes empecéis a programar, más tarde terminaréis. ¿Cómo os ponéis a programar, sin analizar antes el problema, diseñar la solución y planificar el trabajo? ¿Os imagináis que un arquitecto hiciera lo mismo?"

10 08 01

Aprendimos a redactar antes requisitos del sistema, la especificación de requitisos del software, el plan de proyecto, gestión de riesgos, matrices de trazabilidad... y entonces nuestros clientes no dijeron que no podían definir el producto desde el principio, que empezáramos cuanto antes, aunque no tuviéramos una descripción completa, y que ya nos irían diciendo.

Aprendimos a basar la calidad de nuestros programas en los procesos de nuestra empresa, y al hacerlo descubrimos sus limitaciones frente al talento de las personas.

10 08 02

A falta de una, aprendimos dos formas de abordar los problemas: desde la planificación y la ingeniería de procesos, y desde la agilidad y las personas; y cuando ya sabemos hacer las cosas "blancas" o "negras", descubrimos que los proyectos reales son de tonos grises más o menos claros. 

10 08 05

 

Y en este aprendizaje hemos creado dos bandos: planificación y agilidad, y hemos perdido la cabeza creando y etiquetando metodologías en cada bando: Scrum, XP, Kanban, Lean, Scrumban... 

10 08 03

 

El consejo es huir del "etiquetalismo metodológico, y ser prágmáticos.  Conocer las diferencias de base y enfoque entre planificación y agilidad: las fortalezas y debilidades de cada una y a partir de ahí, los "artefactos" de las diferentes doctrinas son simples prácticas, no "metodologías". Unos útiles para construir planes, otros para mantener requisitos cambiantes. Con sprints podemos iterar el producto en pulsos de tiempo prefijado (sprints),  con técnicas kanban iteraremos el producto en un flujo continuo de crecimiento. 

Cuanto mayor sea el inventario de prácticas que conozcamos, las fortalezas y debilidades de cada una, más recursos tendremos como gestores y más flexible será nuestro trabajo, y nuestra capacidad de adaptarlo a las característcas de cada proyecto. 

 

10 08 06

¿Por qué no se va a usar en un proyecto con gestión predictiva, planificación de póquer para conducir una reunión de estimación por juicio de expertos?, o un tablero de gestión visual Kanban.
¿Por qué no se pueden aplicar criterios de institucionalización de CMMI a las prácticas empleados en una empresa ágil?

10 08 07

Este artículo se publicó originalmente el 22 de agosto de 2010 en navegapolis.net

Vaya usted a saber por qué, pero sí que es frecuente encontrar entre los programadores a personas polarizadas en uno de estos tipos: 

 

  • El pesimista: Programador que siempre está advirtiendo de problemas y fallos. De carácter difícil.
  • El cowboy: Le gusta programar, y sobre todo hacerlo a su manera, y lo que a él le parece importante o necesario, lo haya pedido el cliente o no.
  • El disciplinado: es el carácter preferido de los gestores. Hace lo que le dicen sin cuestionar.
  • El rey de las reuniones: para el que todas las decisiones necesitan una buena reunión.

tipos p

Me ha llamado la atención esta clasificación que planteó Aaron Ruhnow en la exposición de Agile 2007Consciously Evolving an Agile Team, pero no coincido en que impliquen también si técnicamente son buenos o malos.

No necesariamente por ser disciplinado, por ejemplo, se es también "programador experimentado y capaz", como dice Aaron: que una cosa es la personalidad y otra la cualificación técnica.

Desde mi punto de vista los estereotipos puros serían ocho y no cuatro:

estereotipos programadores

 

Y me quedo, y por este orden, con el 2, 4, 6 y 8.

(*) Este artículo se publicó originalmente en navegapolis.net el 29 de agosto de 2007

 

9bLa parte más difícil en la construcción de sistemas de software es decidir precisamente qué construir" (Frederick P. Brooks Jr.)

El 60% de los problemas de los proyectos tienen su origen, directa o indirectamente en los requisitos; y los problemas de los requisitos surgen por alguna de estas razones:

1.- El cliente no tiene una visión clara de lo que quiere.
2.- El suministrador obtiene los requisitos superficialmente, quizá siguiendo un proceso, pero sin "sumergirse" en conocer el negocio del cliente y realizar desde ahí el análisis.
3.- Implicación y comnuicación deficiente entre el cliente y el equipo de desarrollo. 

Pero además de que el cliente esté implicado y en comunicación con el equipo, es necesario disponer de una visión clara del objetivo, y comprender y analizar el entorno del problema.

Para estos dos puntos no se puede confiar la solución a un proceso, porque ésta se alcanza más por el saber hacer de las personas, que por el seguimiento de un procedimiento de obtención y análisis de requisitos.
Si el equipo está formado por el tipo de personas que Keith M. Eades denomina "Ágilias", en su libro The New Solution Selling, contará con la suficiente intuición y talento para identificar las necesidades y la solución necesaria, sin precisar especial apoyo en los procedimientos,  pero si no es así, o si se encuentra con puntos especialmente difusos, la ayuda de una rutina puede resultar muy útil, y la que expone el mismo Keith en su libro, puede ser muy apropiada para incluirla en el inventario de recursos del equipo.

La rutina que puede emplearse para ayudar a la obtención y análisis de los requisitos se denomina de "9 bloques" y se puede echar mano de ella tanto a nivel de visión general, como a nivel de elementos concretos del baklog.
Es una rutina útil para el responsable del funcionamiento de Scrum, cuando el cliente que tiene dificultades para definir la visión y priorizar un backlog, y también para ayudar al equipo cuando en una reunión de inicio de sprint se topa con alguna historia de usuario, especialmente difuso o difícil de comprender.

Consiste en interrogar el problema con tres tipos de preguntas:
1.- Abiertas.
2.- Concretas.
3.- De confirmación.

Y hacerlo de forma secuencial a través de las tres áreas de investigación:

1.- Diagnóstico del problema o necesidad.
2.- Alcance del problema.
3.- Visualización de la solución.


La representación gráfica de esta técnica de ayuda, forma una matriz de 3x3 que le da el nombre de "9 bloques".

 

9bloques

La rutina consiste en:

1 Diagnosticar cuál es el problema o la necesidad del cliente.
1.a Partiendo de la descripción general de la situación.
1.b Acotando y resolviendo dudas y ambigüedades.
1.c Contrastando que cliente e interlocutores comparten la misma conclusión.

 

2.- Cuál es el ámbito del problema o de la necesidad.
2.a Partiendo de la descripción general de la situación.
2.b Acotando y resolviendo dudas y ambigüedades.
2.c Contrastando que cliente e interlocutores comparten la misma conclusión.

 

3.- Cuál es la solución que se desea conseguir.
3.a Partiendo de la descripción general.
3.b Acotando y resolviendo dudas y ambigüedades.
3.c Contrastando que cliente e interlocutores comparten la misma visión.

LOS TRES TIPOS DE PREGUNTAS

Preguntas abiertas
Son la primeras que se deben plantear para permitir al cliente expresar libremente desde su experiencia y conocimiento del negocio, el problema o la necesidad.
En ellas es importante mantener una escucha activa, sin ideas preconcebidas.

Son preguntas del tipo:

¿Qué es lo que no te gusta del sistema actual? ¿Qué quiere conseguir la empresa (el departamento, el ayuntamiento, el proyecto...) con este nuevo programa?, ¿Qué cosas mejorarías a la aplicación actual (a la aplicaciones de la competencia...)?

¿La mejoras son necesarias en turismo, o en todas las áreas? ¿Necesitáis mejorar las funcionalidades y el interfaz de los usuarios, o también del backoffice?

¿Qué es lo que haría feliz al usuario?, ¿Cómo deberían ser los resultados? ¿Cuáles son las soluciones o las partes de las soluciones de otros productos que más se parecen a lo que se debería conseguir?


Preguntas de control
La exposición abierta de las razones y necesidades del cliente planteará dudas, y para darles respuesta y concreción, se plantean preguntas de control que requieran respuestas concreas del tipo sí o no, o cifras y datos precisos.

Son preguntas del tipo:

¿Cuáles son, por orden de prioridad, los 3 principales objetivos que quiere cubrir la empresa con este sistema?, ¿Qué nº de nuevos usuarios se quieren alcanzar como mínimo con las mejoras de usabilidad?, ¿Se puede seguir empleando el módulo de préstamos durante 2009?...

¿Cuántos departamentos tiene la empresa? ¿Cuántos tipos de informes necesita un departamento? ¿Cuántos tipos de expedientes diferentes hay entre los tramitados en un año? 

¿Cuánto tiempo debería costar validar un informe? ¿Cuánto tiempo debería costar hacer una compra? ¿Cuáles serían algunos ejemplos de preguntas de usuario que debería resolver el sistema, sin ayuda de operadores? ¿Además del nº de socio se podría facilitar también otros datos como DNI, e-mail, firma digital...?

De confirmación
Después de entender y acotar el problema y su ámbito o la solución (según el área de investigación en la que nos encontremos), es necesario contrastar que todos estamos entendiendo lo mismo para evitar interpretaciones erróneas, o diferentes sobre algún requisito ambiguo.

Son preguntas del tipo:

Entonces ¿no se puede lanzar ninguna versión hasta que no incluya una auditoría de modificaciones?. Si el usuario necesitara más de 1 minuto para darse de alta ¿no serviría?. 
Por lo que has dicho, entiendo que el año se podría cerrar con las consultas actuales, pero sería un problema muy grave para la imagen de la marca que los clientes no hayan percibido mejoras sustanciales de usabilidad, ¿no?.

EL FONDO DE LA RUTINA

Consiste en organizar el trabajo de obtención y análisis en una secuencia de dos dimensiones:

1.- A través de tres áreas clave, que es aconsejable despejar por orden para ayudar al trabajo de análisis. En primer lugar se trata de diagnosticar las razones y los porqués del cliente. Dimensionar después el alcance de esas razones en el entorno del negocio, y finalmente visualizar las posibles soluciones.

2.- En cada una de estas áreas clave, proceder de lo genérico a lo concreto, validando la información obtenida.

 

(*) Artículo publicado originalmente en navegapolis.net el 18 de diciembre de 2007