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

 

 

aportacionesDoce años antes de que Ken Schwaber presentara la metodología scrum, el "modelo de desarrollo evolutivo" definía un ciclo de vida iterativo e incremental, que concretaba los requisitos de cada iteración...

 

evol1 evol2

Alan M. Davis "Software Life Cycle Models"

 

Artículo publicado originalmente en navegapolis.net el 2 de enero de 2009

rectificarLa Ingeniería del Software cumplió 40 años el pasado 7 de octubre,(*) porque 40 son los que han pasado ya desde la conferencia de la NATO(1) en la que así se bautizó a la nueva disciplina profesional, que nacía para solucionar los desplantes del software en los proyectos militares, a los que hacía perder millones de dólares porque siempre entregaba tarde mal y nunca.

La tesis con la que comenzaba la espiral de evolución del conocimiento de esta nueva disciplina profesional, tenía como premisas: rigor y precisión en los requisitos del producto, y gestión de los proyectos basada en la planificación y el control.

25 años más tarde, la agilidad planteó su antítesis, porque esas premisas estaban resultando inadecuadas para un nuevo tipo de proyectos que no necesitan previsibilidad, sino rapidez e innovación continua. 

Si errar es humano y rectificar de sabios, Tom DeMarco es de los segundos. Su obra es una de las principales contribuciones en el desarrollo de la Ingeniería del Software.

Es autor de uno de los principales trabajos sobre métricas en la gestión de proyectos de software, referente de temarios como PMBoK: Controlling Software Projects: Management, Measurement and Estimation, publicado en 1982 y que hizo famoso su principio "no puedes controlar lo que no puedes medir". Con motivo del 40 cumpleaños de la Ingeniería del Software , el número de julio/agosto de IEE SOFTWARE publilca un artículo de Tom DeMarco del que prefiero no comentar nada, y  usando el derecho de cita, copio litaralmente sus palabras:

Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construian el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿Fué correcto el asesoramiento en métricas? ¿Sigue siendo pertinente? y ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software?. Mis respuestas son no, no y no.

Tom DeMarco, que es el autor de la afirmación que ha sido axioma en los modelos de procesos y gestión: "Usted no puede controlar lo que no puede medir", afirma ahora que el control puede no ser importante en muchos proyectos de software:

"Muchos proyectos han avanzado sin centrar la gestión en el control, sino en la creación de productos maravillosos como GoogleEarth o Wikipedia.
Para entender la verdadera función del control, es necesario distinguir de manera drástica entre dos tipos diferentes de proyectos:

Un proyecto de tipo A, con un coste estimado de un millón de dólares y un cálculo de retorno aproximado de 1,1 millones.
Un proyecto de tipo B que con un coste estimado de un millón de dólares produce un valor de más de 50 millones de dólares.

Lo inmediatamente evidente es que el control resulta importante en el proyecto A, y sin embargo su importancia es mínima en el B. Esto nos lleva a la extraña conclusión de que el control estricto es importante en los proyectos poco importantes, y viceversa.

Al seguir leyendo en el artículo el paralelismo que hace con el tipo de control de un padre sobre su hijo, me acuerdo del principio de "control sutil" identificado por Nonaka y Takeuchi en el concepto original de Scrum. 

"Al aplicar el principio 'no se puede controlar lo que no se puede medir' a la educación en la adolescencia, la mayoría de las cosas realmente importantes, honor, dignidad, disciplina, personalidad, valores, ética, ingenio, lealtad, humor, bondad... no son medibles.
Tienes que formar a tu hijo lo mejor que puedas sin tener feedback de métricas. Es difícil, porque ser padre es difícil. Tienes unas ciertas métricas del tipo de las notas del colegio, e intuyes que la nota de matemáticas es más importante que la de español y que la nota de comportamiento quizá diga más del profesor que del alumno".

Para quienes creemos que el conocimiento está en continua evolución, y en la gestión de proyectos TIC hay mucho que cuestionar sobre lo enseñado en métricas, planificación y control, leer estas afirmaciones de Tom DeMarco reconforta, y da gusto ver que hay personas que con honestidad cuestionan depuran y mejoran de forma continua(2). Que a fin de cuentas, mejoran con los años de experiencia. 

Claro que esto es lo que me parece a mi. También habrá a quien le parezca que vaya pena con  Tom DeMarco. Con las buenas ideas que tenía, y al final se ha echado a perder. :-)

 

 

(1) Conference on Software Engineering. 1968 Garmisch, Alemania.
Informe de la conferencia   

(2) Desde sus Ideas iniciales en la línea de "No puedes controlar lo que no puedes medir" a las conclusiones actuales sobre métricas y gestión de proyectos (ágil, por qué no decirlo), pasando por las que a finales de los 80 resumía en su afirmación "La mayoría de los problemas de nuestro trabajo no son tecnológicos sino sociológicos" (Peopleware: Productive Projects and Teams 1987)

(*) Artículo publicado originalmente en navegapolis.net el 22 de julio de 2009

certificacionSi queremos cobrar estas cantidades empezamos mal si llamamos a las cosas por su nombre: ¿cursillo?

¿Cómo que cursillo? ¡Eso es cosa de academias!. Llamémosle curso de certificación profesional, y concedamos a los asistentes un título rimbombante, cual título nobiliario. Algo que impresione. Por ejemplo "Certified ScrumMaster" 


En Argentina se anuncia un cursillo curso de certificación profesional ScrumMaster por el que los asistentes deben pagar el equivalente a dos meses de sueldo por dos días de clase. ¿Es abusivo, o sólo me lo parece a mi?

Además resulta sorprendente que las víctimas del atropello, quienes deben hipotecar el salario de dos meses por este abuso, sean los que sustentan con su apostolado, y a veces veneración, el mantenimiento de estos modelos de formación.

No se si decir que "el emperador está desnudo" es valentía, inconscienca o sencillamente compartir con sinceridad lo que pienso. 

Y... no nos confundamos:  Scrum es una buena práctica de gestión sobre principios de desarrollo ágil, y todo gestor de proyectos TIC lo debería conocer.

No me gusta mucho (nada) alardear de experiencia, pero seguramente serán mas de 200 los proyectos de desarrollo de software los que he gestionado en los últimos 10 años, bien directamente o bien a través de gestores de mi equipo. Algunos de un par de meses de duración, y otros de más de dos años. En ese tiempo he asistido también a no sé cuántos cursillos seminarios y certificaciones (ISOs, CMM, EFQM, CMMI, gestión de proyectos, calidad, agilidad, métricas, dirección...), y esta vergonzante descripción os la hago sólo para que comprendáis mi escepticismo sobre las "balas de plata", porque tras 10 años de ver, estudiar y pasión por mi profesión, confieso mi condición de aprendiz y lo que me falta por aprender. De ahí mi escepticismo a las formaciones mágicas de 2 días.

Si además sumamos que hay que pagar un potosí, y que a todo el mundo le dan un título que "certifica" su conocimiento, aunque el conferenciante hable en inglés, y el asistente sólo sepa español... la desconfianza aumenta, ante un sistema de formación que anuncia y "garantiza" que en dos días podría hacer a mi madre "Certified ScrumMaster".

Esta es mi opinión, y seguro que algunos la compartiréis y otros, seguramente por esa sorprendente actitud que comento de veneración hacia estos cursos, os sentiréis en desacuerdo, o incluso ofendidos. 
De verdad, ninguna intención de ofender, sino de cuestionar: Estamos descubriendo la necesidad de cambiar los antiguos modelos de distribución y acceso a la información, el conocimiento y la cultura. Las ventajas del acceso y el intercambio libre. ¿Por qué al mismo tiempo mantenemos y apoyamos modelos de formación que van en la línea contraria?

Para mejorar el conocimiento y la calidad en los modos de desarrollar software, ¿no sería más lógico ir hacia modelos para ofrecer el conocimiento y la formación de Scrum, de CMMI o de lo que sea, que consigan la difusión al mayor número de personas al menor coste posible?; porque el modelo de seminario reducido de hotel es justo lo contrario.

Una cosa es desplazar a una autoridad en el tema para un día o dos a un hotel y oir su serminario, y otra la formación de profesionales;  y además si quien imparte estos cursos, que no lo son, lo hace porque también recibió un cursillo de dos días... ¿no es un sistema antieconómico, perverso y hueco?.
¿No es necesario cuestionar lo que no nos parece lógico, para que no se perpetuen mitos sin sentido?.

 

Este artículo se publicó originalmente en navegapolis.net el 22 de octubre de 2006 

Certified Scrum Master" suena bien. Suena muy bien. Tiene "Certified" y tiene "Master", y con estos términos tan pomposos uno supone que se debe tratar de una certificación de conocimiento o reconocimiento profesional, aunque no es mas que un engaño que cada vez despista a más personas.

Decir que el emperador está desnudo quizá no es muy inteligente, porque uno no gana simpatías ni de los emperadores que han pagado un buen dinero por un traje inexistente, ni de los sastres que hacen tantos trajes y entregan tan poca tela, pero alabar el traje que no se termina de ver no es profesionalmente honesto.

En su día ya hice de poco inteligente y me gané un puesto en la lista negra de la Scrum Alliance por dar mi opinión sobre los cursos de certificación ScrumMaster , por eso estas semanas pasadas me he sentido menos tonto al leer los comentarios de algunos "sastres" que empiezan a cuestionar la honestidad de vender estos trajes:

 

diplomascsm1

 

En grupo Industrial XP el pasado 15 de marzo, Joshua Kerievsky, fundador de Industrial XP abría una caja de truenos al atreverse a escribir "Actual Evidence of CSM Deception ". (la lectura de mensajes es solo para usuarios suscritos) en el que explica cómo el director de una empresa afirmaba con orgullo que ahora su proveedor de software contaba con personal "certified ScrumMaster".
Joshua afirma que este director ya había caído en el engaño, que al oir las palabras "certifided" y "master" daba por supuesto de que se trataba de una formación más o menos larga con una evaluación final, y que lo que no podía suponer es que para Certified ScrumMaster no va más allá del típico seminario de charla y comida en un hotel.

"Estoy muy disgustado con la comunidad Certified ScrumMaster y la gente que está empujando este engaño flagrante a todo el mundo."

En este grupo de noticias, que mueve una media de 15 mensajes al mes, esta afirmación ha generado más de 330 y el propio Ken Schweber (iniciador de la "certificación" Scrum Master) ha entrado a opinar.

También la semana pasada, en el grupo Latin America Agile Software Development se cuestionaba tener que pagar 1.200 dólares por dos días de formación, y al hilo de la discusión, Tobías Mayer, formador autorizado por la Scrum Alliance y que anteriormente había dado estos seminarios en Buenos Aires, afirmaba estar en desacuerdo con la filosofía de la formación centrada en la "certificación" y su decisión de no dar más estos cursos.

Kripanidhi hace el siguiente cálculo en su post "Credibility Crisis ": La Scrum Alliance ha certificado hasta la fecha a unos 10.000 ScrumMaster * 1.500 dólares cada certificación = Ha facturado 15 millones de dólares.
Afirma también que en los dos últimos años ha preguntado a 42 ScrumMaster la finalidad del curso, y el 95% confiesa que lo han realizado para dar lustre a sus currículums.

 Otro ScrumMaster "Certificado" afirma "Esta certificación no se basa en nada: no hay pre-requisitos antes del curso, y no hay ningún control después. Es posible que una persona que jamás haya practicado scrum sea un ScrumMaster certificado".

 

Este artículo fue publicado originalmente en navegapolis.net el 29 de marzo de 2007

 

 

colegioConfiar en los procesos, cuando habría que hacerlo en las personas, asienta una cultura de cumplimiento que hace a creer que el medio es el fin, y que puede haber gente competente con mala suerte, que realizan bien su trabajo pero a quienes los resultados no les acompañan.

La calidad de la arquitectura de un sistema (por ejemplo) no depende del proceso o de las herramientas con las que se ha desarrollado, sino del talento de sus autores, por eso en empresas del conocimiento, el principio "la calidad del resultado depende de la calidad de los procesos empleados", camufla la incompetencia. 

También es un error asentar una cultura de cumplimiento para gestores de sistemas complejos, que acaban convencidos de que su desempeño consiste en hacer bien su trabajo: el gantt, el presupuesto, etc.

Si la herramienta es el fin, y los procesos los responsables de los resultados, no importa mucho la aptitud de las personas. Los resultados serán buenos si cumplen con su jornada laboral, o mejor aún, si la exceden y “cumplen con el trabajo de su puesto”.

¿Si?.

(*) Este post fue publicado originalmente el 5 de octubre de 2016 en navegapolis.net

 

manzanaSrum, en su concepción original, definida por Nonaka y Takeuchi, es posiblemente el marco natural para el desarrollo de la agilidad.

El "Scrum" de la ScrumAlliance  y de los ScrumMaster: el  "Scrum" rígido y dgmatizado, donde nada se puede cambiar, además de ser un modelo de negocio piramidal sin escrúpulos para quienes lo definen, es una amenaza para SCRUM.

Esto no es muy nuevo en Navegápolis, por eso me ha parecido muy valiente el artículo, nada menos que de Scott Ambler.

Me he sentido menos solo al leer a alguien de su talla, decir también sin ambages queel emperador está desnudo

Scott, jugando con las palabras en Inglés: cambiando Scrum por Scum (escoria) y derivando de SCAM (Scum Certified Agile Master) a Scammer (estafadores) para referirse a los que toman esta certificación; se ha despachado a gusto en suartículo sobre la certificación ScrumMaster diciendo cosas como estas:

Puede conseguir el título de Maestro Certificado de la Escoria Ágil, o más coloquialmente Estafador, pasando dos días en nuestro curso de certificación. Queremos ser claros, lo que estamos certificando es la asistencia al curso (guiño, guiño, guiño, guiño). Usted decide si desea presentarse como un Estafador profesional. Si el 99,8% de los asistentes lo hacen. ¿Por qué va a asistir usted con otra intención?.

...

Este curso sólo lo puede impartir un Artista de la Escoria Ágil  Certificado. Para consultar un listado de los certificados como  Artistas de la Escoria, consulte nuestra lista.

El costo del curso de certificación de Escoria Ágil varía en función de cada Artista de la Escoria, pero normalmente oscila entre 1.395 y 1.995 dólares USA.

En primer lugar obtendrá un certificado que indica que asistió al curso, y también una estupenda carpeta de la Alianza de la Escoria con el material del curso... 
Pero ¡aún hay más! Terminado el curso le enviaremos por correo los logos y gráficos que podrá inclir en sus correos y tarjetas para indicar que es un Estafador...

Proximamente: Pruebas de Certificación.

A partir del 1 de julio de 2009 todos los "falsos" (?) tendrán que cumplimentar un test on-line, que ha sido cuidadosamente diseñado por los miembros del círculo de la Escoria... esperamos que haya un 98 o 99% de aprobados, siempre y cuando no hayan sido tan estúpidos de cuestionar a esta cofradía en un foro público como el de yahoo (controlado y administrado por la Alianza de la Escoria), o sean miembros de la facción disidente.

FAQ.

¿Estoy cualificado?... Si su cheque tiene fondos, usted será una Escoria Ágil Certificada.

¿Qué piensan los líderes ágiles de esto?. Varios de ellos no han podido resistir la tentación del dinero fácil y decidido certificarse como Artistas de la Escoria Ágil, por lo que ahora no pueden decir públicamente lo que piensan, por miedo a matar la gallina de los huevos de oro. El resto casi no tienen la integridad de levantarse y decir cualquier cosa. En lugar de eso albergan la esperanza privada de que la Alianza de la Escoria se autodestruirá a consecuencia de su codicia y su falta de ética. Pero creo que 7 años de funcionamiento que han demostrado que están equivodados.

 Actualización: Sept-2010

 Un año más tarde de la fecha de publicación de este post, Ken Schwaber, fundador del modelo de certificación ScrumMaster y de la Scrum Alliance, la abandona reconociendo que su foco es su propio negocio antes que la difusión y mejora de Scrum:

An organization can either be mission driven or money driven. Not both. When I started the Scrum Alliance, our mission was to improve the profession of software development. That later became “to transform the world of work.” By 2007, I believe that the quest for money had made the mission secondary at Scrum Alliance. I failed to see the effects that my initiatives would have on the money-making of the Scrum Alliance and its members. If I had mapped the money-making activities of the Scrum Alliance to these initiatives, it would have been obvious to me that the community would resist them. In 2008, Scrum Alliance revenues came largely from three sources (see Table 1). Individual CSTs taught an average of 200 students a year. Course fees ranged from $1,000 to $2,000 per student. This meant that the average trainer earned $300,000 per year just from training. 

 

Este artículo se publicó originalmente en navegapolis.net el 15 de agosto de 2009