Navegápolis 2009. Blook: www.navegapolis.net

Juan Palacio Bañeres

TÍTULO

Navegápolis 2009.

AUTOR

Juan Palacio Bañeres

FOTOGRAFÍA DE PORTADA

Mario Alberto Magallanes Trejo

FOTOGRAFÍAS

Stock.xchng®

EDICIÓN

Navegápolis®

IMPRESIÓN Y DISTRIBUCIÓN

Edición impresa disponible en www.lulu.com http://www.lulu.com/content/1987035 Edición Febrero 2009

DERECHOS

Las formas en las que se puede copiar y distribuir este libro

están registradas en Safe Creative y se pueden consultar en el

enlace http://www.safecreative.org/work/0901312500304 o en www.safecreative.org/work con el código de registro 0901312500304

A los lectores de Navegápolis

Índice Índice ................................................................................ 7 Prólogo ............................................................................. 11 Personas ........................................................................... 13

¿Gestores o domadores? ................................................ 15 Todo por la empresa ..................................................... 16 ¿Cómo motivar a los programadores? .............................. 19 Organizaciones que castigan la comunicación honesta ....... 23 El mito de las evaluaciones de desempeño ....................... 24 Profesionalidad ............................................................. 27 Las interrupciones en el trabajo ...................................... 29 Costes laborales ........................................................... 30 Cultura de cumplimiento y evaluación de desempeño ........ 31 El software se desarrolla con talento ............................... 33 Obediencia y docilidad ................................................... 35 ¿El proceso? De formación ............................................. 38 ¿Listo, cumplidor o motivado? ........................................ 39 La difícil combinación de talento y sencillez ...................... 41 ¿Quod natura non dat Salamantica non praestat? ............. 42 Cerrar el departamento de recursos humanos .................. 43 Errores en la selección de personal ................................. 48 Vivir para trabajar, y trabajar para morir ......................... 52 Por Favor, no motive a los programadores ....................... 53 ¿Es bueno medir el valor de las personas? ....................... 54 Los ocho estereotipos de programador ............................ 56 Proyectos, gestión, gestores y programadores .................. 58 Totalitarismo profesional ................................................ 60 A ver cuando me ascienden para dejar de programar ........ 61 Equipos auto-gestionados .............................................. 62 Trabajo, talento, procesos y agilidad ............................... 63

Procesos ........................................................................... 65 El manifiesto ágil se quita la chaqueta de pana y CMMI se vuelve ágil. .................................................................. 67 Métrica 3: ¿Reinventando la rueda? ................................ 70 Modelos de procesos y calidad: no auto-medicarse ........... 72 Del origen de Scrum ..................................................... 74 Procesos: incompatibilidades y efectos secundarios ........... 75 Los cuatro principios del manifiesto ágil ........................... 79 Métricas en equipos auto-gestionados ............................. 83 Las historias de terror de CMMI ...................................... 85 Si nos han vendido una moto… nos van a dar una moto .... 87 El error de los modelos CMM .......................................... 90 La caja del producto ...................................................... 92

ISO reconoce que los actuales modelos de software son inadecuados para pymes ............................................... 94 Síntesis ....................................................................... 96 Good Agile, Bad Agile y otros fundamentalismos ............. 101 Cultura de cumplimiento .............................................. 104 Flexibilidad = síntesis + gestión sistémica ...................... 106 ¿Por qué 5 niveles de madurez? ................................... 108 La forma y el fondo de la agilidad son cosas diferentes .... 111 Método ágil de estimación: Planificación de póquer ......... 113 Síntesis entre agilidad y disciplina ................................. 116 Factorías y talleres de software .................................... 120 Homo homini lupus ..................................................... 121 La certificación ScrumMaster es una amenaza para la gestión ágil ........................................................................... 122 Fundamentalismo ....................................................... 125 Scrum con el culo, y dinero por nada ............................ 126 La lista definitiva de modelos y buenas prácticas para proyectos de software ................................................. 129 Café o tila ¿Por qué no los dos a la vez? ........................ 141

Proyectos ........................................................................ 145 ¿Cómo se estima el precio de los proyectos de software? . 147 El software es así ........................................................ 148 Preguntas sobre el diseño ............................................ 149 ¿Métodos de desarrollo ágil con contratos de fecha y precio cerrados? ................................................................... 154 Necesitaré 3 recursos Java ........................................... 158 ¿Cómo se decide la compra de software? ....................... 160 ¿Cómo es la estrella de tu proyecto? ............................. 162 PSP (Personal Software Process) o cómo pasarse de rosca midiendo ................................................................... 164 Hay dos formas de viajar ............................................. 167 El escenario TIC necesita otro modelo de gestión de

proyectos .................................................................. 170 ¿Requisitos cerrados o evolutivos? ................................ 171 ¿Cuánto he trabajado?, o¿cuánto me queda? ................. 174 Calcular la fecha de fin de proyecto ............................... 177 Los requisitos del sistema y el product backlog ............... 178 Scrum: reunión de planificación del sprint ...................... 182 El “Gantt” ágil ............................................................ 187 Clientes y gestores hablando idiomas diferentes ............. 189 9 Bloques: rutina para obtener requisitos con Scrum ....... 191 Niveles de zoom de los requisitos ágiles ........................ 196 Agilidad Kanban .......................................................... 198 Midiendo velocidad, trabajo y tiempo en gestión ágil ....... 201 Los gestores de proyectos ágiles no existen ................... 206 Coordinación de varios equipos en un mismo proyecto .... 207

Empresa y mercado .......................................................... 209 La incompetencia calificada de los comités ..................... 210 ¿Cuál es la finalidad de las empresas? ........................... 212 Problemas divergentes ................................................ 214 Gestores “PHB” ........................................................... 215 Ética empresarial ........................................................ 216 Adquisición de sistemas de software:Intuición ................ 217 ¿Es más importante la venta o el producto? ................... 222 Benchmarking y best practices en manos de aprendices de brujo ......................................................................... 223 Nuestros clientes no quieren programas ........................ 225 Empresas que optan por procesos. Empresas que optan por

agilidad ..................................................................... 229 Moros y cristianos ....................................................... 230 Algunas majaderías sobre el código abierto .................... 232 ¿El poder político debe intervenir en el sector del software? ................................................................................ 234 Gestión y procesos en empresas de software ................. 235 Estrategias empresariales ágiles ................................... 279 Indicador de la calidad técnica de una empresa de software ................................................................................ 282 Programadores que no están orientados a la rentabilidad. 283 Hubo un tiempo en el que la gestión de los procesos valía más que la gestión del talento ...................................... 285 Scrum en toda la empresa ........................................... 286 Los buenos directivos también son difíciles de encontrar .. 293 Scrum management: de modelo de negocio a modelo de valor ......................................................................... 295 Factor de escala y agilidad ........................................... 296 Lo mejor de CMMI y Scrum .......................................... 297 Culturas tóxicas para la agilidad ................................... 301 Las tres responsabilidades (mejor que roles) para Scrum. 304 ¿Qué tal resultará la implantación de una metodología ágil? ................................................................................ 306 Scrum: ¿de remedio a enfermedad? .............................. 308 ¿Las empresas deben enorgullecerse de su madurez? ..... 310 ¿Cuál es la personalidad de tu empresa? ....................... 312 5 niveles de agilidad ................................................... 315 Gestión de blanco y negro............................................ 317 Empresas con visión .................................................... 319 La teoría de gestión no sirve para los proyectos importantes ................................................................................ 321

Índice ............................................................................. 327

Prólogo En este libro recopilo una selección de los artículos publicados en

Navegápolis (http://www.navegapolis.net) hasta 2009, que comprenden conceptos relevantes para la gestión de empresas y proyectos de software. Ofrecen, en conjunto, una visión práctica e independiente sobre

productividad, gestión de personas, desarrollo ágil, compor-tamiento organizacional, modelos de procesos CMMI…

Son apuntes escritos, porque me gusta aprender y compartir experiencia y criterios, porque la práctica de bloguear me libera de la rutina diaria, y como afirma Brooks, por el placer de desarrollar cosas que puedan usar y ser útiles a otras personas.

Ojalá sea así.

Juan Palacio.

http://www.navegapolis.net

Personas

Personas 15

¿Gestores o domadores?

10.03.2005

Las técnicas de gestión basadas en principios de conductismo pavloviano, que premian a quien lo hace bien, y castigan a los que no hacen lo que se desea, son técnicas apropiadas para los animales, y los domadores las vienen utilizando con muy buenos

resultados, siglos antes de que Pavlov descubriera su base científica.

Con las personas también funcionan, porque todos buscamos lo que nos gusta, y evitamos lo que nos desagrada, pero emplearlas para obtener talento y motivación es como pensar que con la violación se obtienen los mismos resultados que con la seducción.

Personas 16

Todo por la empresa

27.04.2005

Me envían (mejor no mentar a los remitentes, vista la cultura de su empresa) me envían, digo, un documento con la relación de los principios y valores del cuerpo de los marines de EE.UU.

(?) Resulta que el directivo de una empresa de desarrollo y

mantenimiento de software les ha entregado este documento a los mandos intermedios de la compañía, para que transmitan que esos son los valores, la actitud y la entrega que espera la empresa de todo el personal. Algunos de estos mandos intermedios se han quedado a cuadros. Otros simplemente han comenzado a impartir disciplina; pero,

bueno..., otro día prometo comentar las implicaciones de los experimentos de Milgram (pág. 79)

Es cierto que hay una corriente, en muchos foros aceptada, que basa las relaciones laborales de las empresas en principios de entrega y disciplina ciegas. Comparar las relaciones de disciplina y acatamiento en una

empresa con las del ejército, algo que parece aberrante en la cultura europea, resulta bastante habitual en EE.UU., donde muchos gestores leen libros como: "Semper Fi" (Carrison & Walsh, 2004) "Corps Business "The 30 Management Principles of the U.S. Marines" (Freedman, 2001)

O como el escrito por Zell Miller (sargento militar que ha llegado aGobernador deGeorgia) que confiesa que todo lo que debe

saber un gestor de empresas se enseña en el cuerpo de marines. Sin comentarios. Respeto todas las teorías y prácticas de gestión, y a sus autores; aunque muchas no las comparto, y algunas incluso me dejan a

cuadros.

Personas 17

Aunque hay autores que afirman que todo lo que debe saber un director de empresa se enseña en los marines, reconforta mucho más leer libros como el de Reinhard K. Sprenger "El mito de la motivación", que tiene mucho más clara la diferencia entre motivación y manipulación.

Algunos fragmentos de "El mito de la Motivación"

Suele intentarse tal cosa con promesas de este calibre: 'Somos

el número uno en el mercado, y tú también serás el más grande

si te identificas con nosotros'. O bien: 'Nuestro producto es fantástico, y tú serás fantástico si lo vendes'. Un sistema así ofrece posibilidad de identificarse con algo grande a un yo débil,

(...) Se exige veneración. Y no es precisamente raro que, bajo la máscara mágica de la progresista corporate identity, lo que se desee en realidad sean trabajadores dispuestos, como adolescentes, a tatuarse para siempre en el brazo el logotipo de la empresa.

Pero esta cultura del fan usada por la estrategia 'seducción' será inefectiva cuando la prometida grandeza resulte vana y se rompa en pedazos; por ejemplo, cuando los productos resulten un fiasco, cuando se critique a la empresa en la opinión pública o, simplemente, cuando la conducta de la discreción no merezca crédito ("¡Por sus hechos los conoceréis!"). El sistema 'por la

seducción' es esencialmente incapaz de aprender: comete errores, sin duda, pero no los reconoce, ya que podrían perjudicar la identificación con la entidad. Resulta ejemplar comprobar cómo de numerosas quiebras empresariales se deduce que allí se negaron a ver los errores hasta que ya fue inevitable percibirlos. En la cultura del fan, cualquier crítica se

vive como un insulto a la propia familia.

Particular interés ofrece el comportamiento de estas organizaciones frente a 'desertores' e 'inadaptados'. (...) En tales empresas, los inadaptados tienen la vida difícil. Y eso que el sistema los crea necesariamente. Pues la sensación de 'ser mejor que la competencia' es muy difícil de mantener a la

larga. El espejismo termina por disolverse. Un globo de aire caliente necesita en todo momento más aire caliente. O, dicho de otro modo: aire cálido. Y, en esta lógica, cualquier interrupción en su marcha significa una 'crisis de identificación' del

Personas 18

colaborador. Y cuando, a pesar de todo, el colaborador deja de andar a trompicones ciego de entusiasmo tras los colores de su equipo -e incluso aunque siga implicándose en su trabajo-, surge el conflicto. En un primer momento, aumenta la presión sobre ese 'excéntrico', 'cabezota' o 'listillo' para que se adapte. Si se

resiste, se formará una burbuja a su alrededor, se le aislará y se le rechazará una vez tras otra. Podrá salvarse despidiéndose. Pero si permanece 'fiel', terminará abandonándose al cinismo -en mi opinión, la actitud predominante en la actual generación de managers.

(...)

El colaborador se convierte en 'adepto'. La 'identificación' estimula una cultura de 'fans' de rasgos profundamente adolescentes, un tentador '¡Hazte mío! ¡Serás grandioso!', que difícilmente podrá despertar una 'lealtad' adulta (que es la que yo preferiría por definición

Personas 19

¿Cómo motivar a los programadores?

05.06.2005

Son muchos los directivos y responsables de RR.HH. en empresas de software que no terminan de encontrar respuesta a la pregunta de cómo motivar a los empleados. Son muchos, porque la preguntita es un estereotipo desgastado

en ámbitos de management y de gestión de personal. Esta piedra, en la que tropiezan repetidamente tantos gestores no es exclusiva de empresas de software; y es posible que en

determinadas industrias haya trabajos en los que pueda resultar complicado contar con personas o equipos motivados; pero en el desarrollo de software lo realmente extraño es justo lo contrario: tener programadores desmotivados.

-¡Vaya! ¿Conque te han castigado?

Tom no se dignó a contestar. Seguía pintando entusiasmado, separándose de vez en cuando de la valla y observándola con

mirada de artista. Ben, que tenía en la mano una manzana muy apetitosa, se

quedó con la boca abierta, pues no acertaba a comprender nada. -Oye, Tom, me voy a nadar, ¿no quieres venir? ¿O es que tienes que trabajar? -¡Hola, Ben! Estaba tan entusiasmado pintando la valla que ni siquiera te había visto. -¡No dirás que prefieres trabajar a ir a nadar! -Depende de lo que tú llames trabajo. A mi me encanta pintar la

valla.

Mark Twain. Las aventuras de Tom Sawyer

¿Por qué es divertido programar? ¿Qué beneficios esperan obtener los programadores? Primero, por el placer de construir cosas. Al construir cosas, los

adultos experimentan el mismo placer que los niños al jugar con el barro, especialmente si construyen cosas que ellos mismos han diseñado. Segundo, por el placer de hacer cosas que puedan resultar útiles a otras personas. En realidad lo que persiguen es que otros usen su trabajo y lo encuentren útil. Tercero, por la fascinación de ver trabajar sistemas complejos,

que asemejan rompecabezas en los que se integran diferentes

Personas 20

piezas y partes móviles, que interactúan entre sí para llevar a cabo las funciones que inicialmente se han previsto. Cuarto, por el placer de estar siempre aprendiendo al trabajar cada vez en proyectos de características diferentes. Y por último, por el placer de construir con un material tan

maleable y tan etéreo. El trabajo del programador, como el del poeta, se construye de forma sutil desde la materia pura de su pensamiento. Puede construir castillos en el aire, sólo con el esfuerzo de su imaginación. Pocos medios de creación son tan flexibles, tan limpios y fáciles de remodelar, para desarrollar complejas estructuras conceptuales.

Frederick P. Brooks. The Mythical Man-Month (Phillips Brooks, 1975)

Sourceforge.org: Un millón de programadores trabajando en más de cien mil proyectos, con la única motivación de realizar el trabajo.

¿Cuál es la cuestión?

¿Cómo motivar a los programadores?....

¿O cómo no desmotivarlos?

Cada día un anciano recibía insultos y burlas de los niños del

vecindario. Un día, recurrió a una treta, ofreciéndoles un dólar si volvían al día siguiente para repetir los insultos. Los niños acudieron, le hicieron rabiar y a cambio se ganaron su dinero.

El anciano les prometió de nuevo. "Si volvéis mañana, os daré cincuenta centavos". Y acudieron otra vez y, tras insultarle, recibieron su paga. El anciano les animó para que le siguieran haciendo enfadar al día siguiente, aunque esta vez a cambio de 20 centavos. Los niños se indignaron: no iban a insultarle por tan poco dinero. Desde entonces el anciano vivió tranquilo.

No se ha publicado en ninguna parte del mundo estudio alguno que haya demostrado un aumento duradero del rendimiento por medio de sistemas de incentivos

Alfie Kohn. Punished by Rewards (Kohn, 1999)

Personas 21

Algunas empresas diseñan sistemas de incentivos vinculando retribución extra a los resultados, cumplimiento de fechas, etc.

¿Los incentivos aumentan la motivación?

¿Los incentivos matan la motivación?

La cultura de la organización, el estilo y las torpezas de gestión pueden ser fuentes importantes de desmotivación

Trate a las personas como cosas o como animales. Pero antes de

que nos precipitemos en nuestro juicio y pensemos que sólo monstruos stalinianos o hitlerianos son capaces de una cosa así,

veamos primero en qué consiste eso. Empecemos por darnos cuenta de que "tratar mal" a las cosas o a los animales no es, en general, lo que suele hacer el ser humano. Bien al contrario es mucho más frecuente que las trate incluso mejor de lo que sería lógico esperar. Fijémonos, por ejemplo, cómo trata normalmente la gente a un coche de la

gama alta, o a un traje, o a un animal de una cierta entidad como un caballo o un perro de raza... ... Tratar a un ser humano como una "cosa", entonces consiste en cuidarle para que dure, no ocuparse en absoluto de lo que

piensa y darle la cantidad de dinero que "el mercado" dice que hay que darle. Esto es "mantenimiento". No hacerlo es "dejadez o caradura"...

...Pero si de lo que se trata es de trabajar con animales, uno suele tener en cuenta (a menos de que sea muy lerdo) que una cierta relación hay que establecer, que hay cosas que quieren y que hay cosas que no quieren, y que se puede tratar de condicionarles para obtener los resultados que se desean... ... Para un animal, un azucarillo hoy puede ser únicamente una

golosina, y mañana pasar a ser el desencadenante de un determinado movimiento. Los animales no tienen "opinión" y por

tanto no hay ninguna necesidad de escucharla ni de tenerla en cuenta.... ...Ignorar las opiniones de las personas, sus puntos de vista, sus soluciones a problemas reales, es tratarles como animales. Y usted destroza la organización, porque ellos lo notan. Si se

resisten, usted siempre puede argumentar que "les falta información", o les falta "visión de conjunto"... le hará sentirse maravilloso a usted mismo, porque usted sí tiene información, visión de conjunto, y sabe de técnicas empresariales... ...Pero es tratarles como a animales, porque las personas tienen otras cosas que aportar además del esfuerzo físico (la "mano de

Personas 22

obra") y/o mental elemental. De hecho, y para ser precisos, es tratarlos como si en lugar de pertenecer a la especie Homo sapiens pertenecieran a la Homo faber, un antepasado del hombre actual sólo útil para trabajos manuales o de segundo orden.

Josep M. Rosanas Martí. Cómo destrozar la propia empresa y creerse maravilloso (Rosanas Martí, 2003)

Usted ha escuchado mucho acerca de la escasez de talento. Lo

que debe recordar es que, para los lugares de trabajo atractivos, no hay escasez de talento. Las compañías que carecen de

talento, ¡probablemente se lo merecen! Cualquier persona que sea lo suficientemente inteligente como para trabajar en una

compañía de alta tecnología, debe también ser tan listo como para no estar en un lugar de trabajo tóxico. Y si trabaja en uno, tan pronto como pueda se irá.

Alan M. Webber. Danger: Toxic Company (Webber, 2005)

...Luego me ocurrió lo mismo cuando, como director de seminarios, tuve que enfrentarme constantemente a la pregunta de los directivos: "Qué debo hacer para motivar a mi gente?".

Me contenía para no contestarles con otra pregunta: "¿Qué es lo

que ha hecho usted para des-motivarla?". Pronto comprobé que quienes no dejaban de preguntar por nuevas fórmulas de motivación eran sobre todo los malos directivos: los que ni querían dirigir ni eran capaces de ello.

Reinhard K. Sprenger. El Mito de la Motivación. (Sprenger, 2002)

Personas 23

Organizaciones que castigan la comunicación honesta

11.07.2005

Transcribo un par de ideas del post "Honest Comunication: The Quote" publicado en "Software As She's Developped", que

suscribo por completo, porque la experiencia me ha enseñado la diferencia entre organizaciones que permiten la comunicación honesta, y las que reclaman silencio servil.

Si tu organización castiga la comunicación honesta y tu te

comunicas honestamente, acabarás destrozado.

(Beck K. , IBM, 2003) Esta es una cita de Kent Beck, fundador de eXtreme Programming, e impulsor del Manifiesto ágil.

La comunicación deshonesta no te destruirá si escondes la

cabeza bajo la arena. Es algo habitual, incluso en empresas multinacionales que continúan en pie tras décadas de supervivencia a sus espaldas.

Un colega me comentaba que estuvo en un proyecto financiero que perdía como un millón de dólares cada mes, y en el que terminó lógicamente condenado. Tuvo la oportunidad (osadía) de pedir a un directivo la explicación de por qué se seguía manteniendo a flote esa nave que se hundía. La respuesta: "Dejarla ir sería políticamente incorrecto". ¡Ah!, y por esta razón todos esos empleados, contratistas y

consultores continúan cobrando de usted y de sus accionistas.

Incluso en proyectos pequeños sobrevive este tipo de auto-mutilación, especialmente si hay en ella gente con talento (probablemente bien compensados) que trabajan de forma heroica.

Personas 24

El mito de las evaluaciones de desempeño

21.08.2005

Hace 15 ó 20 años, la medicina suprimía de la dieta de las personas con problemas de colesterol, los alimentos grasos; y

recomendaba, por ejemplo, ensaladas con muy poquito aceite, prefiriendo el de girasol al de oliva. También prohibía pescados

grasos, como las sardinas, etc. Toda la doctrina cardiológica respaldaba estas prescripciones, y si alguien las hubiera cuestionado probablemente hubiera sido anatemizado.

En muchas ocasiones las soluciones simples crean mitos, que por la lógica y simplicidad de su razonamiento resultan fáciles de aprehender y difíciles de cuestionar: "Si el enfermo presenta

exceso de grasa en la sangre, reduzcamos la ingesta de grasa".

Para todo problema complejo hay siempre una solución simple,

que es errónea

George Bernard Shaw

Cuando estamos convencidos de la realidad de un mito, resulta más fácil dudar de la razón e incluso de las intenciones de quien lo cuestiona, que de aquellos principios que consideramos reales e incuestionables. Por esta razón los mitos son muy resistentes al cambio, y a pesar de su dudosa o nula eficiencia se suelen perpetuar durante

bastante tiempo. Ojalá que esta introducción me conceda al menos el beneficio de la duda al afirmar que: "las evaluaciones de desempeño son un mito, y suelen empeorar aquello que pretenden mejorar: la motivación y eficiencia de las personas".

Hace ya algunos años, transmití esta opinión al responsable de RR.HH. que prescribió para el departamento de producción que yo dirigía un proceso formal de evaluación de desempeño. Afirmar que este tipo de evaluaciones son un mito, no es políticamente correcto, porque cuestiona la realidad que muchos

Personas 25

profesionales de recursos humanos tienen por axiomática en el ejercicio de su trabajo o, que en el peor de los casos, emplean como medio para ganar dinero. Por supuesto que el entorno de trabajo debe proporcionar retro-

información a las personas sobre qué tal lo hacen, cuales son sus puntos fuertes y cuáles las áreas de mejora. Por supuesto que se trata de conseguir un sistema de beneficio muto en el que las personas que trabajan en él crezcan y mejoren profesionalmente, y en consecuencia la organización logre mejorar la calidad y la eficiencia.

Por supuesto que el exceso de grasa en sangre es malo. La cuestión es: ¿Las evaluaciones de desempeño ayudan o perjudican? Porque lo cierto es que al no haber ninguna prueba objetiva de sus bondades, resulta dialécticamente perverso defenderlas,

presentando una premisa cierta: "vamos a mejorar a los profesionales y a la organización", y dando por obvia una consecuencia que en realidad no está demostrada: "lo conseguiremos con las evaluaciones de desempeño".

El 80% de las empresas hacen evaluaciones de desempeño, sin

embargo, el 90% de las que hacen evaluaciones, y un porcentaje similar de quienes evalúan y son evaluados están insatisfechos con este procedimiento

"Abolishing Performance Appraisals" (Coens, 2002)

Ningún estudio controlado ha hallado jamás un mejoramiento de

largo plazo en la calidad del trabajo de las personas que resulte de ningún tipo de programas de recompensas o incentivos

Alfie Kohn, Punished by Rewards (Kohn, 1999)

Los problemas de motivación y eficiencia, se suelen abordar de forma errónea, especialmente en industrias como la del software, que se basan en el talento de las personas, y no en su capacidad de trabajo mecánico; y emplear las evaluaciones de desempeño como medio de motivación (v. ¿Cómo motivar a los

programadores? Pág. 19) es uno de los errores típicos. Las empresas, y sus departamentos de RR.HH. deben cuestionarse la forma y el fin real de las evaluaciones que realizan, porque lo cierto es que en algunos textos de management y de RR.HH. se puede leer:

Personas 26

Las evaluaciones por escrito deben proporcionar efectivamente una documentación objetiva e imparcial, necesaria o útil en las

decisiones disciplinarias o en los despidos".

"Abolishing Performance Appraisals" (Coens, 2002)

Y tienen formas poco alineadas con los fines que deberían

perseguir:

Son un procedimiento obligatorio.

Se documentan por escrito.

Las administra el jefe.

Hacen a las personas responsables de metas y medidas pasadas.

Exigen a los individuos comprometerse por escrito con metas y acciones futuras.

Se sitúan y conservan durante años en el expediente

oficial de personal del empleado.

Se ordena que el empleado la firme.

Se utilizan para tomar importantes decisiones relativas al salario, el avance, la promición y las suspensiones.

Están vinculadas a la disciplina o el despido, o se utilizan

en conjunto con éstos

¿De verdad es tan aberrante pensar que no son un buen método para conseguir equipos de trabajadores del conocimiento motivados y comprometidos?

Personas 27

Profesionalidad

16.11.2005

A muchas personas los libros de historia les parecen aburridos. A los historiadores no. No me preocupa haber leído muy poco (nada) sobre cálculo de

estructuras, pero sí que me preocuparía si el arquitecto que diseñó mi casa compartiera este mismo desinterés.

La materia prima del software es el talento. Y para que la materia prima (el talento) se transforme en producto elaborado (el software) tan importante como tenerlo es que habite en una persona motivada: que tenga interés por realizar el trabajo. El talento de Einstein nadie lo pone en duda, pero su carrera profesional en la oficina de patentes de Berna no fue muy

diferente de la de sus compañeros. Había talento, pero escasa motivación por realizar ese trabajo.

1.- El interés es un factor clave para disparar los resultados de las personas que producen a través de su talento. 2.- Es el mismo interés el que marca la diferencia entre desear o

eludir la lectura y el aprendizaje continuo. Con estas simples reflexiones se puede llegar a conclusiones no sólo interesantes, sino inquietantes en muchos casos. No es extraño que un médico se resista a leer el texto de la versión continua del CMMI, o la ISO 12207. No sería extraño que

los tildase de “ladrillo” o de “rollo”. Yo pienso lo mismo de sus textos de histología. Sin embargo resulta inquietante encontrar tantos consultores, gestores de proyectos o de empresas de software que expresan los mismos tópicos de ladrillo o rollo. Personas con las que uno no será considerado como colega de profesión, sino como

pedante, o pretencioso si les propone enviarles o recibir el SRS con el formato del estándar IEEE 830 (por ejemplo). La motivación, el talento y, en definitiva, la profesionalidad son difíciles de medir. Pero sin embargo puede resultar muy revelador el número y estado de uso de libros y documentos

Personas 28

técnicos que se tienen en las mesas y estanterías de trabajo. ¿Por qué en nuestro oficio hay personas que viven “devorando” información técnica, y otras que “desconectaron” hace tiempo? ¿Por qué los lustres de los currículos no mantienen una

correlación con el interés por la profesión? Que mi madre crea que hablo de estropajos cuando digo AJAX, y de joyas al hablar de Ruby, es normal. Que a estas alturas piensen lo mismo programadores

“profesionales”, debería inquietar a sus empresas.

Que un consultor “profesional” de calidad ofrezca sus servicios a una empresa de informática asegurando que en el fondo CMMI e ISO9001 son la misma cosa, y que si se cumple ISO9001, por una extraña propiedad transitiva que sólo el conoce, también se “cumple CMMI.”...

¿A todos sus niveles, en todas sus áreas de proceso? Mejor no preguntarlo, pensarían que somos unos pedantes.

Personas 29

Las interrupciones en el trabajo

11.01.2006

Un estudio reciente realizado por Basex sobre el trabajo de 1.000 personas, entre oficinistas, ejecutivos y directivos; ha concluido que las interrupciones consumen por término medio el 28% de la jornada laboral (2.1 horas / día).

Este tiempo comprende la propia interrupción y el de despiste hasta que se retoma el trabajo en el punto en el que se encontraba, y con el ritmo de implicación que se tenía.

El estudio afirma que, como media, transcurren 11 minutos desde que comenzamos una tarea, hasta que nos interrumpe el teléfono, la campana de notificación de un e-mail, la visita de un compañero, etc. y una vez interrumpidos tardamos una media de 25 minutos en volver a estar trabajando en el punto que lo dejamos con el ritmo que teníamos.

No se han considerado por igual a todas las interrupciones. Las hay más o menos perturbadoras; unas son relativas al trabajo, y

otras completamente ajenas... Un dato: el 62% de las interrupciones son de temas ajenos al trabajo.

Mary Czerwinski, vicepresidenta de SIGCHI está llevando un proyecto de investigación de Microsoft sobre la base de que la tecnología puede reducir estos tiempos, diseñando sistemas de comunicación inteligentes capaces de determinar cuándo resulta oportuno o inoportuno interrumpir al destinatario.

Personas 30

Costes laborales

24.05.2006

Un mito endémico que lleva a muchos directivos a tomar decisiones erróneas es creer que salarios y costes laborales son la misma cosa. Si se trabaja con la fórmula "costes laborales = salarios" es

normal estar convencido de que rebajar los salarios implica rebajar los costes laborales, y es normal también ver al personal como gasto.

Sin embargo, trabajar con la fórmula "Coste laboral = salarios / valor que generan" proporciona una visión de gestión más amplia, sobre todo trabajando en sectores en los que las diferencias de valor entre personas pueden multiplicar al denominador de la fórmula x10 o x100

Cuando mayor pueda ser la diferencia de valor del denominador, más fácil será que la empresa considere al personal como

inversión y no como gasto.

Personas 31

Cultura de cumplimiento y evaluación de desempeño

05.10.2006

Tas publicar el artículo Cultura del cumplimiento (pág. 104) , tomaba café con un jefe de equipo que se lamentaba de que

dentro de poco más de un mes tendrá que pasar la evaluación de desempeño a su equipo; de lo poco que le convence esta

práctica y de las disparidades de criterios en función del "estilo" del jefe que la pasa. Al hablar sobre los "estilos de jefes": de los que miran las formas y encajan bien en las culturas de cumplimiento, y de los que chirrian en ellas, lo que decíamos me sonaba a "déjà vu"... era

algo ya leído... pero no me acordaba dónde. Pues bien, al final lo encontré. Esta es la cita tal cual aparece en "El principio de Peter " del Dr. Laurence J. Peter :

La competencia de un empleado es determinada no por los

extraños, sino por su superior en la jerarquía. Si el superior se encuentra todavía en un nivel de competencia, puede valorar a sus subordinados en atención a la realización de trabajo útil; por ejemplo, el suministro de servicios médicos o de información, la

producción de salchichas o patas de mesa, o el logro de los objetivos declarados de la jerarquía. Es decir, valora el resultado. Pero si el superior ha alcanzado su nivel de incompetencia, probablemente evaluará a sus subordinados con arreglo a valores institucionales: considerará la competencia como el

comportamiento que secunda las reglas, rituales y formas del statu quo. La diligencia, la pulcritud, la cortesía con los

superiores, el papeleo interno serán tenidos en gran estima. En resumen, un funcionario de este tipo valora el trámite.

(Peter, 1969)

Los que me conocéis recordaréis sin duda el caso de aquella programadora web que hacía unos trabajos que daban pánico: bases de datos de diseño horripilante, webs que se podían "hackear" siguiendo el manual de hacker para dummies... y la diferencia de valoración de sus dos superiores. Uno que decía que no se le debía renovar contrato, y otro que era una

Personas 32

trabajadora ejemplar por el horario, su buena disposición y la cantidad de código que podía escribir en un día; y la quería proponer para un premio.

Personas 33

El software se desarrolla con talento

01.12.2006

Aunque pueda parecer erróneo, en el desarrollo de software poco importa el trabajo, en comparación con su "primo lejano" el talento. La intervención humana en la programación no se puede

simplificar como el "uso" de personas a través de la contratación de tiempos de trabajo. Los humanos, vistos como máquinas, somos bastante completos

y complejos. Por supuesto nos podríamos catalogar como los mejores robots, o lo que es lo mismo, como las mejores máquinas, porque podemos operar en casi todos los trabajos, pero esta es sólo la faceta mecánica o física del concepto "trabajar". La Academia define "trabajar" como la ocupación en actividades

físicas o mentales. Las máquinas y los animales tienen capacidad de trabajo, pero

se trata siempre de capacidad de trabajo físico. Podríamos enmendar a la Academia e incluir también el trabajo lógico por aquello de que hay máquinas que pueden procesar información, pero de momento, los únicos con capacidad de

trabajo mental o intelectual somos las personas. Los trabajos físicos e intelectuales tienen valores diferentes, y en función de la tarea que se quiera desarrollar serán necesarios unos u otros en mayor o menor medida. Los humanos además de poder hacer trabajos muy diferentes,

tenemos un "interfaz de operación" bastante complejo. Las palancas de control que nos ponen en marcha en actividades físicas no sirven para motivar respuestas más elevadas como la creatividad, genialidad, innovación, pasión, etc. Estas respuestas pertenecen a la faceta humana, y para ellas no hay "palancas de mando directo" del tipo impulso - respuesta.

Las empresas que necesitan capacidad de trabajo, más como mano de obra que como trabajo intelectual pueden emplear estímulos de control directo, porque tienen cierta razón al gestionar a las personas con criterios mecanicistas.

Personas 34

Estos sistemas de producción fueron la base de los principios de la administración científica del trabajo, que desarrollaron conceptos y base teórica para la medición de la eficiencia de los métodos, de tiempos, demoras, movimientos, operaciones, etc. Aunque la simple consideración mecanicista de las personas, sin

tener en consideración su componente humano es un error, no deja de ser cierto que para muchas actividades puede valer, y de hecho muchos gestores lo emplean, quizá porque resulta fácil fijar y medir parámetros de productividad, y porque las personas sí disponen de "palancas de control" directas para que generen trabajo físico.

La capacidad en estos trabajos se puede medir sin excesivos problemas en términos tales como: palabras traducidas por hora, metros cuadrados de suelo pulido, o expedientes escaneados; y para activar y mantener la "maquinaria" se dispone de la retribución económica, y las regulaciones de la normativa laboral.

Cuando de lo que se trata es de conseguir trabajo, se pueden conseguir resultados gestionando a las personas tanto con patrones "científicos" como "humanistas", así que allá cada uno

según su convencimiento, gusto o personalidad. Pero cuando de lo que se trata es de conseguir talento, no se puede elegir.

Personas 35

Obediencia y docilidad

21.12.2005

"¡Cuanto ha cambiado Fulanito!. Desde que en el nuevo puesto le han dado más poder, vaya lo que se ha crecido. Ahora es un brazo ejecutor fiel de la dirección. ¡Parece otra persona!."

En las organizaciones en cuya cultura están la obediencia y la docilidad como valores "per se", esta es una conversación de café relativamente frecuente.

Para unos, los "fulanitos" son unos pelotas, o... cosas peores; y para otros unos buenos profesionales, rectos y empleados ejemplares. Con el cambio a la nueva personalidad ganan unas cosas y pierden otras. Las circunstancias moldean la personalidad, y en palabras de

Ortega y Gasset: "yo soy yo y mi circunstancia"; pero ¿porqué son más maleables unas personas que otras?

¿Por qué hay mandos intermedios que dejan a un lado su criterio, el de sus colaboradores y adoptan y ejecutan el de sus superiores sin cuestionarlo, ni permitir disensiones? Seguramente será difícil, y quizá poco conveniente, juzgar las

razones que impulsan estos cambios de personalidad: ¿peloteo, erótica de poder, profesionalidad, escalas de valores diferentes, simplicidad...? Cada caso es diferente, y cada persona también, pero como semillas para pensar me parecen interesantes estas dos definiciones, y el experimento de Milgram:

Poder: capacidad para hacer que las cosas sucedan en la forma que se desea. Control sobre el comportamiento de otros.

Dogmatismo: Presunción de quienes quieren que su doctrina o aseveraciones sean tenidas por verdades inconcusas.

Personas 36

Experimentos de Milgram acerca de la obediencia: Milgran diseño experimentos para determinar el punto hasta el cual las personas obedecen las órdenes de una figura de autoridad, incluso aunque ellos no estén de acuerdo con

aquellas, pudiendo llegar al extremo de poner en peligro la vida de otra persona. Los sujetos del experimento iban de los 20 a los 50 años de edad y representaban un conjunto diverso de ocupaciones (ingenieros, vendedores, maestros, obreros, etc). Se informó erróneamente a los sujetos que el propósito del

estudio era determinar los efectos del castigo sobre el

aprendizaje. Los sujetos iban a ser los "maestros". El "alumno" era un aliado de Milgram, que estaba atado a una silla en un cuarto contiguo con un electrodo sujeto a la muñeca. El "experimentador", otro aliado de Milgram, vestido con una bata de laboratorio, y con apariencia impasible y severa, le ordenaba al "maestro" que leyera al alumno series de palabras

emparejadas, y que posteriormente volviera a leer la primera palabra junto con otros cuatro términos. Se suponía que el alumno indicaría cuál de ellos se encontraba en la pareja original presionando un interruptor que marcaba su elección en el panel

de respuestas. El maestro tenía instrucciones de administrar una descarga

eléctrica al alumno cada vez que éste respondiera de forma incorrecta. El choque aumentaba un nivel de intensidad cada vez que el alumno cometía un error. El maestro controlaba los interruptores que administraban las descargas desde 15 hasta 450 voltios. En realidad no había corriente eléctrica en el aparato, pero los alumnos "erraban" a propósito y respondían a cada "nivel de

choque" en formas progresivamente angustiantes. Si un "maestro" (sujeto) demostraba no estar dispuesto a administrar

el choque, el experimentador utilizaba estímulos secuenciales para hacer que se comportara según lo requerido: 1.- Por favor siga, 2.- El experimento requiere que usted prosiga, 3.- Es absolutamente esencial que usted prosiga y 4.- No tiene opción,

usted debe continuar. El experimento se suspendía solamente si el "maestro" se negaba a continuar después de haberle repetido estas cuatro instrucciones.

Personas 37

¿Cuántos maestros se negaron a continuar? Milgran hizo esta misma pregunta a sus alumnos y colegas. La mayoría consideró que muy pocas o ninguna de las personas llegaría a suministrar descargas muy fuertes.

En realidad el 65% continuó hasta el final del experimento, administrando choques a los "alumnos" hasta el máximo. Ninguno se detuvo antes de 300 voltios, punto en el cual el alumno se golpeaba contra la pared.

Inquietante ¿verdad?, la cultura de poder, obediencia y

sumisión.

Personas 38

¿El proceso? De formación

23.08.2006

Si, conectada al ánodo de la fuente de alimentación, sumergimos una tuerca de acero en un baño electrolítico con un cátodo de cinc, obtendremos una tuerca galvanizada. Es un proceso. Si lo hacemos bien, tendremos tuercas

relucientes. Si "sumergimos" a una persona durante x días en un seminario

de formación; al terminar ¿Quedará "galvanizada" de conocimiento? Todas las personas que asisten al curso de 3 días de CMMI (por ejemplo), reciben un certificado oficial de SEI que les acredita como profesionalmente válidos para participar en las evaluaciones oficiales SCAMPI.

No es cuestión de anatematizar a CMMI; que lo mismo ocurre, sin ir mas lejos en el extremo opuesto con las certificaciones de

ScrumMaster o con postgrados y masters de especialización profesional. El título se otorga sin verificar si la persona ha adquirido los conocimientos, habilidades o conceptos que vayan al caso.

Yo tengo algunos y son muy bonitos. Y si a alguno os pareciera extraño; adquirir capacidad, habili-dades o conocimientos profesionales, según hagan al caso, es así de simple y funciona a las mil maravillas. La mejor prueba es que nunca, ningún cliente ni proveedor (educandos y educadores en este caso) se han quejado, y antes

al contrario todos afirman la excelencia y validez de la formación dada y recibida. No quisiera ser yo una excepción.

Personas 39

¿Listo, cumplidor o motivado?

26.09.2006

Dicen las empresas que son las personas su componente más valioso. Algunas lo creen sinceramente, y otras no tanto. Las primeras valoran la capacidad y las segundas la dedicación. Unas buscan "gurús" y otras "currantes".

Estas expresiones son estereotipos muy gráficos de tres estilos diferentes de gestión de personal:

"Dame gente trabajadora y currante, y no de los que están pendientes del reloj para salir a la hora."

"No quiero gente para calentar las sillas. Producimos con

brain time, no con body time"

"Quiero gente que sienta los colores. Que sienta a la

empresa, al producto y al proyecto en el que trabaja, como suyo".

Algunas organizaciones tienen predilección por, gurús, techies y

similares; otras por quienes trabajan denodadamente; y otras por los que "se sienten empresa". Simplificar la ecuación a un elemento: capacidad, trabajo o compromiso es demasiado simplificar, y cuando se hace es frecuente acompañarlo de otro mito: suponer que la aportación de capacidad, trabajo y compromiso es responsabilidad de las

personas. 1.- ¿Capacidad, trabajo o compromiso?

El mejor valor para las empresas del conocimiento no está en uno o en otro, sino la combinación de los tres. Una persona capaz, desmotivada y sin compromiso es un lujo

improductivo. El trabajo sin capacidad ni compromiso es ineficaz; y un entusiasta que no trabaja y sin capacidad es un pelota.

Personas 40

También están las posibilidades en las que a cada estereotipo en

lugar de faltarles los otros dos componentes sólo les falta uno: El capaz, comprometido pero que no actúa, o el capaz que actúa pero no está comprometido, y el comprometido que trabaja pero no tiene capacidad. La realidad no suele ofrecer tipos en estado puro, sino mezclas

más o menos equilibradas, y las más valiosas son las personas con el grado necesario en los tres componentes.

2.- Trabajo, capacidad y el compromiso no lo "dan" las personas, lo "obtiene" la empresa.

El talento no da resultados sin motivación, y sin formación continua la capacidad queda obsoleta en poco tiempo. Cuando se incorporan a la empresa las personas deben ser capaces y estar motivadas, pero a partir de ese momento el mantenimiento y desarrollo es más responsabilidad de la organización que de ellas.

Para evitar a empleados desmotivados y desfasados hay estilos de gestión de personal diferentes, y las organizaciones tienden hacia unas u otras líneas según crean que la motivación y conocimientos del personal lo deben cultivar las propias personas, o que la organización también es responsable, y en

qué medida.

Personas 41

La difícil combinación de talento y sencillez

13.12.2006

La relaciones entre técnicos y gestores pueden echar chispas; y en los blogs y foros técnicos es relativamente frecuente que las

risas y los razonamientos se hagan para "evidenciar" lo torpes que son los gestores y consecuentemente lo listos, trabajadores

y abnegados que son los programadores Seguramente torpes somos todos, y sin embargo tolerantes hay muy pocos. Para tomar un poco de perspectiva, este es el comentario que Slavik (apodo de un ingeniero de software de Microsoft) hace en su blog:

Aquí los desarrolladores son niños mimados, y los buenos son como dioses. En honor a la verdad el nivel técnico medio es muy alto, pero el nivel de esnobismo, en especial entre los mejores es

también muy alto. Realmente apesta, porque podrían ofrecer

mucha ayuda, formación y consejo a los demás, pero parece ser que la mayoría sólo se preocupan por ellos mismos, de hecho disfrutan por saber más que los demás y no tienen la menor intención de compartir el conocimiento. No todos son así, pero sí la mayoría...

La gente critica de forma constante la mediocridad de los mandos intermedios, crítica que se evidencia a través de muchos blogs. Pero uno siente lástima por los pobres mandos intermedios que son los que tienen que pastorear al rebaño de "gatos" intolerantes (programadores). Que la fuerza les

acompañe."

Personas 42

¿Quod natura non dat Salamantica non praestat?

18.01.2007

En el año 2001 la dirección de recursos humanos de Microsoft Corporation adoptó como criterio global para todos los países no poner como requisito titulaciones académicas en los procesos de

selección de personal técnico.

Desde que en las TechEd de ese año expuso la decisión y las razones el responsable de recursos humanos de la corporación, de vez en cuando pincho por las áreas de "Trabaja con nosotros" de los sitios de Microsoft, tanto americanos como españoles o de cualquier país y mantienen el criterio: en las ofertas para puestos administrativos, de marketing, ventas... es habitual que

al final requieran formaciones del tipo: "Graduate degree required" , "MBA preferred"...

Sin embargo en las ofertas de técnicos e ingenieros de software no mencionan títulos. Piden "pasión", experiencia demostrable en las plataformas o técnicas del puesto requerido, capacidad..

Personas 43

Cerrar el departamento de recursos humanos

04.01.2007

Es una de las ideas radicales de Julen : suprimir la dirección de

recursos humanos (Iturbe-Ormaetxe, 2006)

Leído en seco puede parecer un titular de iconoclasia facilona, pero... si el principal valor de nuestra empresa no es el trabajo, sino el talento, ¿por qué todas las empresas del sector que conozco tienen un departamento de RR.HH. y ninguna tiene uno de gestión del conocimiento?

Que en nuestro sector, el capital humano, y más concretamente el talento es más importante que el capital estructural es ya un estereotipo, y seguro que ningún gestor se atreve a negarlo (al

menos en público), pero aunque la mayoría de las empresas afirman que su mayor activo son las personas, la realidad no siempre es así.

En ocasiones es distinto lo que reflejan las comunicaciones corporativas y las manifestaciones de los coordinadores de recursos humanos de la realidad de su gestión diaria. Afirmar que las personas son el auténtico motor de la empresa y su principal valor vende muy bien, y, ¡qué caray!, debería animar y motivar a trabajar más duro, que a fin de cuentas es lo que interesa.

La realidad del valor del capital humano es una cuestión de cultura, y se necesita un cambio cultural en todos los niveles de la organización, más que un cambio en los mensajes corporativos. Hay dos cuestiones relevantes:

Cuáles son las expectativas de la organización y cuales las de las personas.

¿Cuál es el peso de las personas en el capital de la

organización?

Personas 44

Expectativas de la organización, y expectativas de las personas. Dicho de otra forma: ¿Qué espera la organización de las personas? ¿Qué esperan las personas de la organización?. Normalmente la empresa sí que sabe lo que desea de las personas. Suelen ser listas del tipo: dedicación, espíritu

emprendedor, capacidad innovadora, talento, iniciativa, originalidad, ingenio, espíritu de sacrificio, etc. pero también es habitual que sientan poca curiosidad por conocer las expectativas de las personas. ¿Cuál es el peso de las personas en el capital de la organización?

El capital estructural está formado por los bienes que quedan en la organización cuando las personas se van a sus casas: patentes, licencias, cartera de clientes, equipos, maquinaria, inmuebles, etc. El capital humano es el compuesto por el valor que la empresa

emplea en su negocio y que resulta inseparable de las personas. En función de la naturaleza del negocio y de la estrategia empresarial, cada organización tiene un esquema particular de capitales; y así por ejemplo los pesos y relevancia del capital

estructural y humano son diferentes entre una empresa de extracción minera y otra de consultoría de sistemas informáticos. Cuanto menos peso tenga el capital estructural en el valor de

una empresa, más suicida resultará aplicar criterios de "gestión científica del trabajo". En la visión, misión y estrategia de su empresa, ¿cuál es el peso de los capitales no estructurales?:"Conocimiento tácito de las personas."Valores humanos: fidelidad, talento, compromiso…¿Es un negocio más próximo a la cadena de producción de Chaplin

en "Tiempos Modernos", o de la empresa del conocimiento de Peter Druker?.

Los mejores lo hacen mucho mejor que los mediocres "En el

mundo del diseño informático, los mejores lo hacen entre 50 y 100 veces mejor que el promedio, y la cifra aumenta, conforme se incrementa la complejidad de la tecnología"

Pilar Jericó. La Gestión del Talento. Pearson Educación

La diferencia entre los promedios y los mejores ya no es de 1:2,

como en el pasado. Es 1:100 o incluso 1:1000.

Nathan Myhvold (Ex-director de I+D de Microsoft)

Personas 45

En los trabajos más o menos mecánicos, la productividad y la calidad se puede medir con relativa facilidad y objetividad .El número de piezas ensambladas, o de palabras traducidas o de metros cuadrados pintados por unidad de tiempo son algunos ejemplos. Algo parecido ocurre con la calidad, contando el

número de unidades producidas que quedan dentro o fuera de los márgenes de tolerancia permitidos. Sin embargo, medir el valor que produce una persona a través su talento es más difícil, y al mismo tiempo las diferencias entre personas son enormes. Si las afirmaciones de Pilar Jericó o de Nathan Myhvold parecen

exageradas, veamos algunos ejemplos:

Hace algún tiempo, un programador estaba desarrollando un sistema "web-mail" para la gestión de cuentas de correo desde Internet. Había comenzado la programación de bandejas de entrada, salida, borrador, etc. creando un diseño en la base de datos donde almacenar los correos en tablas que correspondían

con las citadas bandejas. Al ver el desarrollo, un compañero le apuntó:¿Y por qué no trabajas con protocolo IMAP en lugar de con POP3.?. IMAP incorpora de forma nativa la gestión de las carpetas.

El diseño inicial hubiera supuesto unas dos semanas de programación para la gestión de las carpetas. El uso directo de la

gestión de carpetas del protocolo IMAP no supuso ninguna programación para gestionarlas. Este sistema tenía previsto un uso intensivo y un número elevado de usuarios. La gestión de carpetas de IMAP es un sistema ya contrastado, y se ahorraron también los tiempos previstos para pruebas y verificación de esa parte.

La robustez del sistema de IMAP es mayor en cualquier caso que la que se hubiera obtenido, así que también se ahorraron los

posibles tiempos de mantenimiento perfectivo que el desliz de algún error hubiera generado. Al escribir este post, el sistema de correo lleva 6 años trabajando

sin haber generado ningún error. Otro ejemplo: En el desarrollo del espacio web de un ayuntamiento, el programador debía incorporar un plano del municipio. Se trataba de un sistema similar a los ya desarrollados por la empresa para otros pueblos. En estos casos el mapa consistía en una imagen preparada a

partir de los planos facilitados por el ayuntamiento.

Personas 46

El programador asignado, no se limitó a incorporar la imagen. Con ActionScript programó un mapa dinámico para Macromedia Flash.El sistema permitía al cliente configurar las capas y sub-capas que deseara: calles, equipamientos (deportivos, culturales,

sanitarios…), servicios (restaurantes, alojamientos, gasolineras…), etc. La administración del plano permitía crear o modificar los elementos en cualquier momento y registrar información de cada uno. La presentación en el web incluía visualización y ocultación

de cada capa, zoom, deslizamiento, impresión, etc.

Este trabajo lo realizó motu proprio, empleando incluso su tiempo libre para no trastocar agendas ni costes. La empresa no sólo obtuvo un desarrollo de calidad muy superior a la prevista, además incorporó un componente que permitiría integrar en sistemas futuros un sistema de mapas dinámico que a partir de

entonces empleó como argumento para cerrar muchos desarrollos web, ofreciendo un valor superior a la competencia. ¿Cuál es la diferencia de valor entre los promedio y los mejores? ¿Por qué las personas se ven impulsadas a trabajar más allá de

lo que se espera de ellos, dedicando todo su talento y motivación, prácticamente como si se tratara de su propio negocio?

Cuando el valor de las personas no es el trabajo, sino el talento, se debe cerrar el departamento de recursos humanos y abrir el de gestión del conocimiento. No se trata de regular una prestación de trabajo sino de desplegar un interés sincero por los colaboradores. Considerar sus opiniones, expectativas y valores. Contar con los mejores, y cambiar la gestión de recursos de trabajo por la gestión de personas para que aporten el mayor

valor para una empresa del conocimiento: desde la motivación, todo su talento.

La relación con las personas no puede pretender obtener valor en un solo sentido: de las personas hacia la empresa. En este tipo de relaciones, aunque se puede conseguir tiempo de

trabajo, el deterioro de la motivación reduce paulatinamente el valor de los resultados. Si trabajar en la empresa enriquece a la persona, ésta devolverá valor por partida doble. Por un lado cada vez dispondrá de mayor valía profesional; y por otro, de mayor motivación, ingrediente clave para poder aportar talento.

Personas 47

Las personas son listas, y saben perfectamente cuando están integrados en un equipo interesado por sus necesidades, opiniones y desarrollo personal, y cuándo están siendo tratados como "recursos"

Personas 48

Errores en la selección de personal

13.02.2007

Joel Spolsky1 afirma que "una empresa de software debe pensar que la contratación de la gente adecuada es su problema número uno".

Los esfuerzos que dedican algunas como Microsoft o Google en los procesos de selección hace sospechar que a pesar de que a los

anuncios de selección respondan cientos de candidatos, no es un problema de cantidad sino de calidad, y como expone Lawrence Bernstein en Trustworthy Systems Through Quantitative Software

Engineering (Bernstein & C.M., 2005)

Los mejores programadores pueden ser 20 veces más

productivos que los medios... el 50% de los programadores se consideran a si mismos que están en la categoría de los mejores,

pero en realidad sólo está el 1%.

La experiencia es fácil de evaluar, pero la capacidad no; y al no ir más allá del curriculum y la entrevista es fácil errar por exceso y valorar como "crack" o promesa a quien no pasa de la media, o

incluso no llega; o por defecto y descartar a candidatos de capacidad elevada. Los errores por exceso los evidencia el tiempo mostrando que el esperado pura sangre no pasa de trotón. Los cometidos por defecto pasan desapercibidos sin darnos cuenta de que entre los cristales hemos tirado a la basura algún diamante en bruto.

El mejor consejo es rascar más allá de los curriculums y actuar sin prejuicios. Los curriculums contienen, por un lado información de estudios certificaciones y títulos, y por otro trayectoria profesional; y si bien la experiencia se refleja en esta segunda, no ocurre lo mismo con la capacidad y las certificaciones académicas.

1 http://www.joelonsoftware.com

Personas 49

Este es el principal prejuicio para descartar a personas de gran capacidad. Winston Churchill, por ejemplo, no pasaría este filtro como candidato para un puesto de gestión. En mi experiencia profesional he seleccionado a profesionales

que sin más currículo que la pasión por su trabao, encerraban mayor talento y conocimiento de su profesión que compañeros con brillantes expedientes académicos, o sonoras listas de cursos y seminarios en sus espaldas; y en mi experiencia docente he tenido alumnos que han conseguido títulos técnicos de grado, a los que sin embargo no contrataría.

La posesión de diplomas y títulos ni garantiza ni descarta el talento, y puede ser un síntoma de personas más interesadas por la forma que por el fondo; por el lustre de su currículo que por el conocimiento y el ejercicio de su profesión. Para evitar prejuicios, en la medida de lo posible, es útil

considerar las siguientes afirmaciones:

No todas las personas con talento tienen títulos.

No todas las personas con títulos tienen talento.

Todas las personas interesadas en aparentar talento

lucen currículums brillantes. Otro error frecuente es no contrastar la información. Tom de Marco y Timothy Lister caricaturizan esta costumbre al contratar personal técnico, escenificando en su libro Peopleware, (DeMarco, 1987) una entrevista de selección entre un director de

circo y un malabarista: Director de circo: ¿Cuánto hace que usted es malabarista? Candidato: Oh, unos seis años. Director: ¿Puede manipular tres bolas, cuatro bolas y cinco

bolas?

Candidato: Sí, sí, y sí. Director: ¿Trabaja con objetos en llamas? Candidato: Por supuesto Director: …¿cuchillos, hachas, cajas de cigarros abiertas, pamelas?

Candidato: Puedo hacer malabarismos con cualquier cosa. Director: ¿Tiene un guión divertido la actuación?

Candidato: Es divertida.

Personas 50

Director: Conforme, suena bien. Voy a contratarle. Candidato: Ummm… ¿Antes no quiere verme actuar?. Director: Nunca lo había pensado.

La realización de pruebas, la evaluación de programas o diseños realizados por los candidatos, o la contrastación de la información reflejada en el currículo es necesaria para no incorporar en el equipo a un farsante, algo que por experiencia sé que nos puede pasar.

El objetivo del proceso de selección no debe ser conseguir la

mejor relación títulos/retribución, o experiencia/retribución entre los currículos recibidos. La ventaja sobre nuestra competencia no se logra por reducir un par de euros en el coste de la hora de programación. En el área de Recursos Humanos indicadores del tipo:

Precio medio por persona incorporada (Costes de los recursos empleados: anuncios, horas invertidas en la criba de currículos y realización de entrevistas / personas incorporadas).

Tiempo de respuesta (tiempo transcurrido desde que un departamento pide una persona, hasta que ésta se incorpora a la empresa) para medir la satisfacción del

cliente interno. Transmiten a los gestores de personal como objetivos para su trabajo: "satisfacción del cliente interno" y "eficiencia". De forma que éstos intentan realizar su trabajo a la perfección para alcanzar las metas que se les exigen:

Responder con rapidez a las demandas de personal de

los diferentes departamentos.

Eficiencia medida como buenos resultados a bajo coste,

para lo que se esmeran en seleccionar a las personas con los currículos más lustrosos, y en conseguir que los indicadores de sus departamentos reflejen costes reducidos por persona contratada.

Quizá la organización tenga más tarde problemas por la baja innovación o calidad técnica de sus sistemas, o por producir con costes más elevados o con mayor lentitud que su competencia. Pero sin duda serán problemas de los gestores de proyectos, o de los programadores que siempre acaban apoltronados, desmotivados y sin alinearse con el espíritu de trabajo de la

organización.

Personas 51

O también puede ocurrir que sea cuestión de mala suerte, o de que el "software es así de desagradecido", y no de ineficiencia de las personas, porque tanto los indicadores de RR.HH. como los de los programadores demostrarán que cumplen con sus

expectativas de eficiencia, o de nº de líneas programadas por hora o de horas de trabajo efectivo... Se produce de esta forma una situación bastante frecuente: obtención de resultados por debajo de lo esperado, en entornos en los que las personas realizan "eficientemente" su trabajo.

Personas 52

Vivir para trabajar, y trabajar para morir

18.03.2007

Siete de cada diez profesionales del sector tecnológico chino morirá de infarto o derrame cerebral por exceso de

trabajo(Karoshi) ; y hoy la media de vida de los intelectuales que trabajan en el parque de la ciencia de Zhongguancun es de 54

años. Según el artículo de Chinanews “70% of intellectuals might die of karoshi” (Chinanews.cn, 2007)los profesionales más expuestos son los informáticos y los jóvenes ejecutivos (lógico que sean los jóvenes: parece ser que senior ya no les quedan).

"Por no querer perder el tiempo pierdes el tiempo y el alma. Estás perdiendo la vida

de tanto querer ganarla."

José Bergamín

Personas 53

Por Favor, no motive a los programadores

01.05.2007

Este es el ruego que le hacía al responsable de recursos

humanos: bastará con que no los desmotive con sus programas de

"motivación", desempeño, medición de horas de trabajo, premios y castigos. Es un error de gestores bien intencionados, pero mal orientados: quieren motivar a sus trabajadores. En otras profesiones no se, pero cuando se trata de programadores profesionales, a los que

les gusta su trabajo, no se preocupe por motivarles: a estas personas les motiva la tarea y el trabajo mucho más que a usted mismo.

Quieren hacer bien su trabajo y que éste resulte útil. Son gente inteligente, y los modelos al uso de motivación sacados del manual del enterado de Recursos humanos les resultan pueriles

y denigrantes y lejos de motivarles, todas estas martingalas son gotas que horadan la motivación con la que ingresaron en la empresa el primer día. Estamos hablando de programadores profesionales; o sea que les gusta su profesión. Son un porcentaje escaso. Son gente que cuando dejan el ordenador de la oficina se ponen

con el de su casa, les gustan los retos intelectuales y estar

constantemente aprendiendo. Si los de su empresa no son de este tipo, si cuanto terminan de trabajar el viernes ya no cogen el correo, o consultan una página web hasta el lunes y no sienten ansiedad por no hacerlo... posiblemente el consejo de este artículo no sea bueno, y sí que

necesite las prácticas del manual del enterado de recursos humanos para motivarles.

Personas 54

¿Es bueno medir el valor de las personas?

03.05.2007

El valor de las personas, o mejor dicho, de su trabajo es un

factor clave para los resultados de las empresas, y por aquello de que no es posible gestionar lo que no se puede medir (?), a

los cuadros de indicadores de RR.HH. no les suelen faltar evaluaciones y métricas de este elemento tan valioso. Medir no es malo, lo malo es gestionar con indicadores erróneos. Normalmente se gestiona el valor de las personas midiendo su

trabajo, aplicando la simplificación valor = trabajo; y en ocasiones se llega a simplificar aún más, con registros o culturas que presuponen que trabajo = tiempo trabajado.

Supongamos una métrica que no sea tan ingenua como para suponer que el valor de la persona está en relación con el nº de horas que permanece en la oficina, y que considera valor =

trabajo, midiendo el resultado producido por unidad de tiempo. Un indicador que mida el número de piezas torneadas, de palabras traducidas o de azulejos puestos puede ser válido para determinar la productividad de torneros, traductores o alicatadores. Pero aún así, medirá productividad, pero no exactamente el valor del trabajo.

Combinándolo con otro indicador de calidad del tipo porcentaje de piezas o palabras erróneas se puede obtener una métrica de valor mucho más fiable. ¿Pero, y para medir el valor de un texto literario?, ¿de una

estrategia de marketing?, ¿de un programa de software o de la arquitectura de un sistema?... ¿Medimos el nº de líneas o de páginas del informe?. ¿El tiempo que le ha costado a la persona producirlo?. ¿Qué equipo diseñó el mando de la Wii?. ¿Cómo puede medir Nintendo el valor del trabajo de esas personas?, o lo que quizá es más importante: ¿Necesita medirlo para gestionarlo?

Personas 55

El valor de las personas para las empresas es una combinación de tres factores (v. pág. 39): trabajo - aptitud y motivación; y para cada tipo de trabajo el peso de cada elemento es diferente. La simplificación hace métricas más sencillas y de ahí la

tendencia a reducciones del tipo valor = trabajo, con márgenes de error tolerables para la gestión, por ejemplo, del trabajo mecánico de una cadena. Cuando el trabajo es prácticamente el único valor. Cuando las variables son complejas, intangibles o ambas cosas, mejor que fabricar procedimientos de gestión sobre métricas

resbaladizas, ¿por qué no considerar que sí se puede gestionar lo

que no se puede medir?; aunque entonces haya que contar con gestores capaces de trabajar por su conocimiento tácito de gestión, y no el explícito del procedimiento de gestión. Gestores cuyo valor no dependa tanto de su trabajo como de su motivación y aptitud.

Personas 56

Los ocho estereotipos de programador

29.08.2007

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

El pesimista: es el 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. Me ha llamado la atención esta clasificación que planteó Aaron Ruhnow en la exposición de Agile 2007: Conciously Evolving an Agile Team (Ruhnow, 2007); y si, es cierto, son tipos frecuentes, 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.

Personas 57

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

Personas 58

Proyectos, gestión, gestores y programadores

24.03.2008

Algunos proyectos necesitan previsión de fechas y costes, y

otros, valor constante, y ser vanguardia continua en un mercado muy rápido.

Hay una gestión de proyectos que vela por el cumplimiento de fechas y costes: que mide el trabajo, lo trocea, reparte tareas a los programadores, coordina el trabajo, vigila riesgos y controla y actúa para que se cumpla el plan.

Hay otra gestión de proyectos que vela por el valor del producto, por que los programadores sean un equipo que dé al producto lo mejor de su conocimiento, a través de la motivación, la

comunicación e interacción directa. Hay gestores que tratan a los programadores con la teoría X(1): que piensan que no les gusta su trabajo y que es necesario el control, el palo y la zanahoria para conseguir que se apliquen.

Personas 59

Hay otros gestores que tratan a los programadores con la teoría Y(1): que piensan que a les gusta dar lo mejor de ellos en su trabajo, establecer metas y lograrlas, que el compromiso individual y de equipo es la forma, antes que el palo y la zanahoria.

Y para algunos programadores, su trabajo es un "modus vivendi" y para otros una afición.

Si la realidad fuera en blanco y negro, si los proyectos

necesitaran sólo valor, o sólo previsibilidad; si las personalidades fueran, o todo "X" o todo "Y"... esta sería la simplificación del escenario: Como todo tiene un grado, y son raros los blancos o negros absolutos, el escenario real no es tan sencillo, pero tener este

esquema presente ayuda.

(1) Teoría X y Teoría Y de Doulas McGregor

Personas 60

Totalitarismo profesional

24.03.2008

-¡Qué coordinación la tuya, para caminar con tantas patas, y no tropezar nunca! -dijo la hormiga al ciempiés-. Este, que nunca lo había pensado, descubrió sorprendido que, a partir de entonces,

cuanto más lo analizaba, más se tropezaba. Hay artistas que tienen el brujo en el cuerpo. Actores que se han

hecho solos, pisando tablas, y no escuelas de interpretación; músicos que han aprendido de los instrumentos, y no de los métodos; bailarines que parecen entrar en resonancia con el ritmo de forma natural. A otros, han sido las clases de solfeo, interpretación o danza las que los han forjado artistas.

Quizá los primeros piensen que para ser artista hay que "nacer";

quizá los segundos duden que pueda considerarse músico a quien no sabe escribir en una partitura lo que compone. Quizá artistas lo sean todos, y totalitarios sólo los que no

permiten formas diferentes. ¿Qué hacer cuando el departamento de calidad suspende en procesos al gestor que tiene sobresaliente en resultados? ¿Cuando las "incidencias de calidad" le desmotivan y le sugieren que coordine mejor los pies al andar?

Personas 61

A ver cuando me ascienden para dejar de programar

12.06.2008

En una entrevista para selección de programadores el candidato admitía que su objetivo era ascender en la compañía... ascender

para dejar de programar y pasar a comercial o a consultoría. Según sus palabras "a puestos con más proyección".

No sé, entre arquitectos, médicos o astrónomos (por decir algo), no es una aspiración generalizada ascender para llegar a áreas administrativas de empresas constructoras, hospitales o centros astrofísicos; ¿o sí?, porque a mí no me gustaría que me atendiera un médico que espera con ansiedad cuándo dejar de

ver pacientes, o que hiciera mi casa un arquitecto que no quiere hacer casas.

Pero sin embargo sí que es frecuente embarcarse en ingenierías técnicas para "hacerse jefe". Claro, así son luego algunos directivos.

Personas 62

Equipos auto-gestionados

19.06.2008

"Equipos auto-gestionados" es un valor de fondo del desarrollo ágil, más trascendental que la forma que adopta a través de prácticas de trabajo; y comprende dos conceptos: equipo y auto-

gestión. Nonaka y Takeuchi (Ikujiro & Takeuchi, 1986) identificaron en

los "campos de scrum" a un único equipo, no a un único grupo de trabajo. Detrás de esta diferencia hay valores culturales diferentes. En la cultura occidental los valores son el individualismo, la iniciativa individual, el esfuerzo individual y la recompensa individual. En la cultura japonesa, al contrario, el individuo se subordina al

esfuerzo colectivo. El trabajo en equipo y la dedicación desinteresada son la forma de alcanzar las metas colectivamente

establecidas. Es mucho más que una cuestión de técnica de gestión. Y para la que la auto-gestión sea real se necesitan dos factores:

delegación y autonomía y no es fácil que se produzcan de forma real, porque transformar a las personas en equipos auto-gestionados no consiste en dar un toque de varita mágica o un espaldarazo cada persona y decirle: ya tienes autonomía. La autonomía uno no puede darla; es la persona la que

tiene que tomarla.

Personas 63

Trabajo, talento, procesos y agilidad

23.11.2008

Algunas combinaciones y los resultados más probables, trabajando con gestión de recursos humanos o gestión del talento, en cadenas basadas en procesos o en campos de scrum.

Personas 65

Procesos

Procesos 67

El manifiesto ágil se quita la chaqueta de pana y CMMI se vuelve ágil.

05.07.2005

Los métodos ágiles nacieron con espíritu de respuesta revolucionaria a la rigidez y el engolamiento de los modelos de

procesos de SEI e ISO (CMM - CMMI - 15504). Algunas de las cosas que han escrito sus autores y defensores reflejan bastante

bien el descaro, la frescura y la rebeldía:

La diferencia entre un atracador de bancos y un teórico de CMM

es que con el atracador se puede negociar ... La evaluación en CMM depende más de una buena presentación en papel que de la calidad real del producto de software. Tiene que ver más con el seguimiento a ciegas de una metodología que

con el desarrollo y puesta en producción de un sistema en el

panorama tecnológico.

Ken Orr, CMM versus Agile Development: Religious wars and software development.

Si uno pregunta a un ingeniero de software típico si cree que CMM se puede aplicar a los métodos ágiles, responderá o con una mirada de sorpresa o con una carcajada histérica

Richard Turner y Apurva Jain, Agile meets CMMI: Culture Clash or Common Cause.

Sin embargo algo parece estar cambiando, porque la semana pasada se podía leer en La Red:

1.- A partidarios de los modelos basados en procesos, afirmar que es un mito eso de que CMMI sea un modelo pesado.

La creencia de que CMMI es un proceso pesado, basado en la

desconfianza y en un excesivo control es un mito, basado más en la inexperiencia de los que "venden" los procesos ágiles. Algunos de los críticos más ardientes no han trabajado nunca en un negocio basado en CMMI, o en un proceso de evaluación. Mantienen con firmeza que CMMI es un proceso malvado, sin

Procesos 68

comprender que CMMI es un proceso de EVALUACIÓN DE MADUREZ, no una metodología para desarrollo de software.

Herding Cats

2.- En el programa de conferencias del primer día de EuroSTAR 2005, David J. Anderson explicará en una ponencia que MSF para CMMI es un nuevo método ágil (?)

3.- En Yahoo Groups: Agile Management el post, "CMMI and Declaration of Interdependence", también de David Anderson en

el que afirma sin miradas de sorpresa ni carcajadas histéricas que CMMI y los modelos ágiles son compatibles. Sobre el post de Herding Cats, sencillamente no coincido con lo

que afirma:

Los propios textos de los modelos CMMI en sus versiones

continuas y escalonadas afirman en el capítulo de introducción que no se trata sólo de modelos para evaluación, sino que también son guías para prescribir a

las organizaciones la mejora de los procesos de desarrollo de software.

Hace pocos meses pude conocer de cerca la evaluación

del nivel 2 de CMM en ATCA, y me reafirmó la opinión de que no es un modelo ágil, es un modelo formal. Precisamente el manifiesto ágil es su antítesis.

En cuanto a las otras dos, los puntos que resultan chocantes son: El autor: David J. Anderson es defensor de los modelos ágiles.

Fue miembro del grupo de desarrollo de la metodología FDD (1997-1999) y autor del libro "Agile Management for Software

Engineering".

Que afirme sin rubor no haber leído ni haberse

interesado por los modelos CMM hasta hace 6 meses.

Que su interés por CMM coincida con el anuncio de Microsoft de su producto Team System for CMMI.

Que Anderson trabaja en Microsoft, concretamente en

Team System for CMMI.

Procesos 69

Extraer conclusiones es arriesgado, pero no hacerlo resulta aburrido, así que por mi parte las que me atrevo a aportar son:

CMM - CMMI es una cosa, y los métodos ágiles son otra

bastante diferente. CMMI cubre 25 áreas de proceso que en mayor o menor medida intervienen, o deberían intervenir, en el desarrollo, mantenimiento y operación

del software. Ninguno de los modelos ágiles tiene un ámbito de cobertura similar.

El modelo ágil que más áreas comprende es DSDM, y según afirma el propio DSDM Consortium, su aplicación

equivaldría a un nivel 2 de CMM, dejando por tanto fuera de su ámbito los objetivos y práctica de los niveles 3, 4 y 5.

En muchas organizaciones, por las características de su

tamaño, expectativas, tipo de proyectos o incluso por no tener previamente asentados aspectos básicos estratégicos u organizativos, la aplicación de un modelo CMMI puede suponer un lastre con más problemas que ventajas.

En muchos casos centrar la mejora sólo en las áreas de

procesos más relevantes con prácticas de los modelos ágiles puede aportar niveles de mejoría más que suficientes para su estrategia.

CMMI incorpora una representación continua, que permite que una organización pueda seleccionar sólo aquellas áreas de proceso que le interesen. Dependiendo de las características de la organización y con el criterio

de un experto, es una opción interesante.

Procesos 70

Métrica 3: ¿Reinventando la rueda?

25.09.2005

Métrica 3 se autodefine como una "metodología para la sistematización de las actividades que dan soporte al ciclo de vida del software". Es un trabajo de distribución y uso libre,

realizado por el Ministerio de Administraciones Públicas español (MAP). Las normalizaciones facilitan la comunicación, compatibilidad y

calidad en actividades y procesos comerciales e industriales. Los modelos y estándares proporcionan lenguaje y criterios comunes, y pautas con las que guardar conformidad para garantizar compatibilidad o niveles de calidad. Métrica 3 es un instrumento que la Administración española pone a disposición de la industria del software para que las

organizaciones puedan emplearlo en la mejora de sus procesos,

o como norma de conformidad en la adquisición y suministro de sistemas de software. De hecho, la propia Administración Pública lo emplea con esta finalidad en algunos concursos públicos para la adquisición de sistemas de software.

Los modelos son útiles para la industria, siempre que su cantidad y calidad sean adecuadas, y en el software ocurre que hace pocas décadas carecíamos de ellos, y ahora quizá tenemos demasiados, y algunos no muy buenos. A las personas nos gusta hacer cosas que resulten útiles para los demás, pero en este afán investigador e inventor se puede caer

en la tentación de "reinventar la rueda" y producir creaciones o versiones de mejora que en realidad no son tales, y que como no aportan beneficios sobre lo anterior crean confusión o despistan a quienes pretendían ayudar. Es una tentación que recuerda la actitud de algunos programadores de "me voy a programar mi propio botón, o mi

propia cola de mensajes, porque la que incorpora la plataforma no me convence." Esta es una opción muy arriesgada que lleva implícitas dos suposiciones. Primera: el botón, la cola de mensajes, o lo que

Procesos 71

sea, es mejorable... (casi seguro que sí). Segunda: yo lo voy hacer mejor... (casi seguro que no). Sin entrar en consideraciones de eficiencia que para el proyecto pueda suponer.

En este sentido hay que ser más que cautos, porque si no fuera por personas capaces de cuestionar y mejorar lo conocido, aún viviríamos en cavernas; pero al mismo tiempo también es cierto que: Los avances significativos no son consecuencia tanto de las

mejoras como de las innovaciones.

Modificación, revisión o versión no son sinónimos de mejora. Ahora que el software ya dispone de un abanico aceptable de estándares, modelos, marcos, metodologías, etc. conviene mantener cierto espíritu crítico para identificar duplicidades y apartar a los de mediocre solvencia, para que el escenario no

crezca más en número que en calidad. Analizando con este criterio a Métrica 3 puede dar la sensación, o al menos a mi me la da, de modelo ambiguo que pretende ser a la vez "modelo" e "implementación". O lo que es lo mismo

determinar tanto el "QUÉ" como el "COMO" ("qué" tareas y procesos deben hacerse, y "cómo" deben llevarse a cabo"). Desde este punto de vista, resulta como una mezcla de modelo

de procesos tipo ISO 12207, 15504 ó CMMI, y de prácticas o implementaciones para diseño, seguridad, gestión de la configuración... (UML, Puntos de función Albrecht, MAGERIT, etc.) Para la primera faceta, personalmente me quedo con ISO 12207 como modelo de procesos, actividades y tareas del ciclo de vida;

y con 15504 o CMMI como modelos para mejorar o evaluar su aplicación y capacidad. Modelos sobre los que Métrica 3 dice

estar inspirada y mantener correlación, aunque lo cierto es que los parecidos, si los hay, son poco evidentes. En su segunda faceta, Métrica 3 resulta útil como texto de

referencia o material de formación de UML, prácticas de gestión de proyectos formal, etc., pero en este caso la cuestión es ¿qué hace esto dentro de un modelo de procesos?

Procesos 72

Modelos de procesos y calidad: no auto-medicarse

08.11.2005

Los modelos de calidad deberían incorporar en su primera página alguna advertencia del tipo: "Antes de suministrar este modelo a

su empresa consulte con un experto", para evitar que algunos desorientados se empeñen en combatir el dolor de cabeza con

antibióticos, o las infecciones con antigripales. En algunos países de Sudamérica está haciendo furor la moda del CMMI. Pequeñas start-up de poco más de 10 empleados se empeñan en implantar este modelo, por supuesto mucho más preocupados

por la "fotografía" que por la "radiografía" de su empresa, por emular a sus grandes competidores que por mejorar sus procesos.

A su vez, para muchos de esos grandes, CMMI no es tanto el modelo de procesos que les ayuda a mejorar, sino un medio para exclusivizar relaciones políticas entre consultores y clientes; y para cerrar más el coto, perdón, el cluster en el que se agrupan.

En otros casos la desorientación es del calibre de la de aquel recién nombrado director general de una empresa de desarrollo de software que a su llegada dio una lección al despistado departamento de calidad, haciéndole ver que eso de CMMI era un modelo desconocido en la industria y que el modelo que más prestigio da a las empresas es ISO 9000. (?)

Por favor, si a su empresa le "duele" algo, no consulte a la vecina, ni aplique el medicamento más anunciado en las revistas de management, o el de la caja más grande. Si dispone de un departamento de calidad, contrate a los mejores ingenieros de software que pueda localizar y si trabaja

con asesores externos, huya de los "vendedores de crecepelo". Estos dos consejos tienen una cosa buena y una mala. La buena es que funcionan. La mala es que no es fácil encontrar a las personas adecuadas en cada caso.

Procesos 73

Laurence J. Peter, el autor del famoso "principio de Peter" afirmaba:

El director de empresa que necesitara la ayuda de un experto

debía evaluar las cualificaciones y competencia del consultor antes de contratarle. Un director que tiene problemas en un sector determinado de su esfera de actividad, es probablemente el menos cualificado para valorar la competencia de un experto

en esa esfera determinada.

Laurence J. Peter, "Las fórmulas de Peter

Procesos 74

Del origen de Scrum

07.03.2006

"Las reglas del juego de desarrollo de nuevos productos han cambiado. Muchas empresas han descubierto que para alcanzar la excelencia es necesario algo más que las bases actuales de alta calidad, bajo coste y diferenciación. También se necesita

velocidad y flexibilidad... ...Este énfasis por la velocidad y la flexibilidad necesita un enfoque distinto en la gestión del desarrollo de nuevos productos. El ciclo tradicional o de "carrera de relevos" ejemplificado por la Administración Nacional Aeronáutica y

Espacial: Phased Program Planning (PPP) puede crear conflictos con los objetivos de máxima velocidad y flexibilidad. Sin embargo, un enfoque holístico como un equipo de rugby, donde el equipo intenta avanzar como un todo, pasando el balón atrás y adelante, puede responder mejor a los requisitos de

competencia actuales...

...Con el enfoque de rugby, el desarrollo del producto surge de la iteración constante de un equipo cuidadosamente seleccionado, multidisciplinar, cuyos miembros trabajan juntos de principio a fin."

Extractos del artículo "The New New Product Development Game." de Hirotaka Takeuchi e Ikujiro Nonaka que identificaron en 1986 la metodología de desarrollo iterativo e incremental basada en la formación scrum de los equipos de rugby

Procesos 75

Procesos: incompatibilidades y efectos secundarios

19.04.2006

La teoría de los textos de administración de empresas sobre "procesos" y "organización centrada en procesos" debería

incorporar una advertencia, que a modo de prospecto dijera algo así:

Incompatibilidades: La administración en empresas del conocimiento debe realizarse bajo la supervisión de un experto. Efectos secundarios: En estas empresas, la administración en dosis o forma errónea puede producir mediocridad. Las empresas de programación son el mejor ejemplo que

conozco de empresas del conocimiento, y aplicar en ellas teoría de procesos porque "es lo que se lleva", o lo que me dijeron en el master es una barbaridad.

Los modelos industriales emplean a personas, procesos y

tecnología para inyectar valor en la materia prima y transformarla en producto. Los objetivos para este cometido son: conseguir la mayor cantidad de producto, con el mayor nivel de calidad posible de la forma más eficiente (con el menor coste).

Desde que en los 80 Michael Hammer levantara la liebre de los procesos, las tres últimas décadas han enseñado a las fábricas que el factor más eficiente para dar calidad de forma homogénea, predecible y escalable son los procesos; y que la

Procesos 76

mejor forma de aumentar la eficiencia es basando la producción en procesos, y mejorando la capacidad de éstos. Si el proceso y la maquinaria pueden llegar a comprender todo el know-how necesario, la persona queda como un operador de baja capacitación, barato y fácil de remplazar.

Políticamente no es correcto decir que el principal factor de la empresa son sus procesos, luego las máquinas, ordenadores o robots, y por último las personas. En las presentaciones corporativas se mencionará justo lo contrario; pero se puede hacer una prueba curiosa: teclear en Google la cadena

entrecomillada "organización centrada en procesos" = 625

páginas. "organización basada en personas" = 4 páginas. La Ingeniería de procesos y la producción basada en procesos han tomado el protagonismo. Su diseño, medición y mejora en ciclos tipo "PDCA" se han revelado como la clave para mejorar de forma continua eficiencia y calidad; dibujando una ecuación en la

que, las personas ayudadas por la tecnología actúan como recursos para ejecutar los procesos. Aunque seguramente contra corriente de muchas opiniones,

insisto que aplicar la teoría de este modelo en empresas del conocimiento es una barbaridad, porque trabajan con materias primas muy diferentes.

¿Cuál es la materia prima del software?

Esta cuestión es la razón de la diferencia y de la barbaridad. La mediocridad en el desarrollo de software es el resultado que se obtiene al gestionar a las personas como los recursos que ejecutan los procesos, ayudados por la tecnología, y al

considerar axiomático que:

Procesos 77

Los procesos son el elemento de mayor palanca para garantizar la eficiencia y la calidad.

En lo relativo a las personas, la fórmula de la eficiencia es conseguir el mayor tiempo de trabajo por el menor coste posible.

La materia prima del software es el talento, y por esta razón la teoría industrial aplicada a nuestro sector da empresas de productos mediocres, porque:

Suministra una materia prima de baja calidad.

Su sistema "personas - procesos - tecnología"

incorpora al producto una mínima parte del valor que se le podría transferir.

Administrando a las personas que desarrollan software como un recurso de producción industrial se puede estar en el mercado,

conseguir el volumen de trabajo que el marketing y el capital relacional propio sean capaces de lograr, pero el producto será mediocre. Este modelo de empresa no es capaz de desarrollar software innovador ni valioso.

Algunas consideraciones

En el desarrollo de software el protagonista para dar valor al producto es el talento muy por encima de los procesos o la tecnología.

Las diferencias de valor, calidad o eficiencia que pueden aportar unas personas u otras no es como en los trabajos mecánicos de 1,5 ó 2. Pueden ser x10 o x100.

En la ecuación Personas - Procesos - Tecnología, falta un cuarto elemento: el Entorno. La cultura y el comportamiento organizacional. Los procesos y la

tecnología, principales protagonistas de los entornos

Procesos 78

industriales son insensibles al entorno. Las máquinas y los procesos no producen más o menos según sea la cultura de la empresa. Por eso el cuarto elemento no se suele considerar. Sin embargo el talento es muy sensible. Huye de las empresas tóxicas; y las personas,

aunque lo tengan, no lo pueden expresar si no están motivadas.

La clave no es la "gestión de los recursos humanos" sino la

"gestión del talento".

Empresas de producción industrial

Empresas del conocimiento

Valor Valor

Como respuesta a la crisis del software surgieron hace un par de décadas, en medio del auge y protagonismo de los procesos, marcos de modelos como solución para nuestra industria: ISO 12207, CMM, CMMI, ISO 15504, PSP, TSP...

Son una gran ayuda que identifican las áreas de conocimiento de la producción y mantenimiento del software, y desarrollan pautas de ingeniería para trabajar con sistemas que tienen niveles de integridad elevados, pero también pueden hacer estragos cuando

se administran con modos trasplantados de entornos industriales

a entornos del conocimiento, cuando no se equilibran adecuadamente en función de las características de cada empresa y de cada sistema de software. Las pautas que en los entornos industriales logran eficiencia, en el software producen mediocridad. Gestionar empresas del conocimiento con teoría de management

industrial genera productos mediocres y técnicos desmotivados.

Procesos 79

Los cuatro principios del manifiesto ágil

1.06.2006

En marzo de 2001, 17 críticos de los modelos de mejora basados en procesos, convocados por Kent Beck, que había publicado un

par de años antes el libro "Extreme Programming Explained" en el que exponía una nueva metodología denominada Extreme

Programming, se reunieron en Salt Lake City para discutir sobre el desarrollo de software. En la reunión se acuñó el término “Métodos Ágiles” para definir a los que estaban surgiendo como alternativa a las metodologías formales, (CMM-SW, PMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y

fuerte dependencia de planificaciones detalladas, previas al desarrollo.

Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto Ágil”, que son los principios sobre los que se basan estos métodos. Hasta 2005, entre los defensores de los modelos de procesos y

los de modelos ágiles han sido frecuentes las posturas radicales, quizá más ocupadas en descalificar al otro que en estudiar sus métodos y conocerlos para mejorar los propios. Manifiesto Ágil (http://www.agilemanifesto.org)

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo

hagan. Con este trabajo hemos llegado a valorar: A los individuos y su interacción, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentación exhaustiva. La colaboración con el cliente, por encima de la

negociación contractual. La respuesta al cambio, por encima del seguimietno de un plan.

Procesos 80

Aunque hay valor en los elementos de la derecha, valoramos

más los de la izquierda

Firmado por:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

Valoramos más a los individuos y su interacción que a los procesos y las herramientas. Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero en

trabajos que requieren conocimiento tácito, sin personas con conocimiento técnico y actitud adecuada, no producen resultados. Las empresas suelen predicar muy alto que sus empleados son lo

más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas

que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan. Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos

lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este

principio es peligroso cuando los trabajos necesitan creatividad e innovación.

Valoramos más el software que funciona que la documentación exhaustiva. Poder ver anticipadamente como se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un "feedback" muy estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un primer momento, y difícilmente se

Procesos 81

podrían incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto. El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la transferencia del

conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto. Los documentos no pueden sustituir, ni pueden ofrecer la riqueza

y generación de valor que se logra con la comunicación directa

entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto. Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción

con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.

Valoramos más la colaboración con el cliente que la negociación contractual. Las prácticas ágiles están especialmente indicadas para

productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información continua durante el desarrollo. También para los casos también en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.

Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de

haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los

referentes para posibles disputas contractuales entre cliente y proveedor. En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.

Procesos 82

Valoramos más la respuesta al cambio que el seguimiento de un plan Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente el cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta

que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.

Procesos 83

Métricas en equipos auto-gestionados

23.06.2006

Nonaka y Takeuchi analizando las prácticas de trabajo de las empresas de tecnología más eficientes y vanguardistas, las empresas del "campo del Scrum", identificaron un elemento común: equipos multi-disciplinares, auto-gestionados operando

como mini start-up's. Los modelos de gestión ágil no parten de una planificación

detallada, y no pretenden monitorizar y gestionar la ejecución de ese plan inexistente, por eso es un error aplicar métricas propias de las actividades de la gestión de proyectos clásica. Determinar indicadores, métricas y procesos de medición no es fácil, y ante la duda suele perjudicar menos quedarse corto que pasarse.

Los directivos de las empresas que adoptan modelos ágiles

suelen quedar desconcertados al sugerirles la conveniencia de que sean los mismos equipos quienes diseñen las métricas con las que van a trabajar. Las dudas y objeciones que argumentan apuntan el

contrasentido de sean los propios trabajadores quienes decidan los criterios con los que se les va a medir... porque en el fondo sigue pesando mucho la base y la inercia de la gestión clásica de proyectos. Los siguientes son fragmentos del artículo de Christopher Meyer “How the right measures help teams excel”.

La finalidad crucial de un sistema de medida debe ser ayudar al

equipo a estimar su progreso. El sistema de medición de un equipo tendría que ser esencialmente una herramienta para que el equipo supiera cuándo debe tomar medidas correctoras. Asimismo, el sistema de medida tiene que proporcionar medios a la alta dirección para intervenir en el caso de que el equipo esté inmerso en problemas que no puede resolver por sí solo. Pero incluso si un equipo dispone de un buen sistema de medidas,

será de poca utilidad si los altos directivos lo utilizan para controlar al equipo.

Procesos 84

Un equipo en el que se ha delegado autoridad de verdad debe

desempeñar un papel fundamental en el diseño de su propio sistema de medidas. Un equipo sabrá mejor que nadie qué clase de sistema de medidas necesita, pero no sólo el equipo debe diseñar el sistema. La dirección de la empresa debe asegurarse de que el sistema de medidas es coherente con la estrategia de la empresa.

Dado que el equipo es responsable del proceso completo de entrega de valor, tiene que crear medidas para su seguimiento.

En una organización funcional tradicional, no hay una única función que sea responsable de un proceso completo de entrega de valor.

Procesos 85

Las historias de terror de CMMI

26.06.2006

¿CMMI es una garantía de calidad para los clientes? ¿Por qué hay empresas que a pesar de tener niveles CMMI elevados, cosechan fracasos en sus proyectos? ¿Qué garantiza CMMI?

Rick Hefner, director de iniciativas de procesos de Northrop Grumman y uno de los autores del modelo CMMI ha presentado en el SEPG americano de este año la conferencia "CMMI Horror

Stories: When Good Projects go Bad" con las conclusiones de su estudio sobre los casos de fracaso de CMMI. Los modelos de CMM se desarrollaron para cubrir dos finalidades, y pueden emplearse para cualquiera de ellas:

Guía de ayuda para mejorar los procesos de desarrollo de

software. Baremo de medida para determinar el nivel de madurez de la empresa, o de capacidad de sus procesos.

Pero lógicamente bajo el supuesto de la buena voluntad, porque de nada sirve que nos receten el mejor régimen, que lo colguemos por las paredes de la cocina, que digamos al médico y a los amigos que lo seguimos a rajatabla; mientras a escondidas seguimos comiendo lo de siempre. El médico es médico. No policía; y sería absurdo culparlo a él, y no al paciente.

Y ocurre que cuando las empresas trabajan para la apariencia, construyendo fachadas de cartón-piedra y vendiendo la imagen de lo que no son, los problemas están a la vuelta de la esquina. Hasta hace unos años las siglas CMM eran desconocidas para los profanos, y como suele coincidir que las empresas de software que se preocupan mucho en el marketing y poco en la sala de

máquinas suelen estar gestionadas por profanos, no había problema; pero durante los 15 años de trabajo, CMM se ha ganado un valor de marca merecido, que es ahora precisamente un peligro, porque atrae a los que sólo quieren vestirse con ese valor, sin cambiarse de muda.

Procesos 86

Rick Hefner identifica que el principal problema son las empresas que sólo se esfuerzan en conseguir pasar la evaluación, por lo que sólo aplican la metodología en los proyectos que analizan los evaluadores al buscar las evidencias; y la aplican sin

comprenderla ni interesarse por su institucionalización para todos los proyectos futuros. Una evaluación CMMI indica que la organización ha demostrado la capacidad en los proyectos evaluados. CMMI asume que la empresa propagará esos procesos al resto de proyectos, pero no

lo garantiza.

Hefner da consejos para evitar estos fiascos, haciendo hincapié en las prácticas genéricas del modelo, en permitir que sea el evaluador quien seleccione los proyectos, etc. Creo que el mejor consejo es "no se engañe, mejore de verdad,

no sólo de apariencia", y añadiría: "antes de calzarse un CMMI asegúrese de que es un modelo adecuado para las características de su organización y de sus proyectos. v ("Modelos de procesos y calidad: no auto-medicarse", pág. 72).

Procesos 87

Si nos han vendido una moto… nos van a dar una moto

28.07.2006

La familia de CMM's anunciaba un futuro CMMI-ACQ para el proceso de adquisición, y como lo prometido es deuda... vamos a

charlar de eso del "proceso de adquisición".

Un ejemplo: Un centro de formación, pagó no hace mucho un potosí por un sistema de "e-learning" desarrollado a medida; adquiriendo una plataforma que se le ha quedado "coja" antes de empezar. Su proveedor, que tiene como negocio la programación a medida y no la integración de software libre, no analizó el problema ni consideró por ejemplo la integración de un

sistema como Moodle. Software gratuito con todas las funcionalidades que necesita el cliente (y tropecientas más).

Si nos han vendido una moto, nos van a dar una moto. El proveedor podrá tener la certificación ISO tal, o varios CMM'ies, premios a la excelencia, etc. en cuyo caso, y si no los

ha "comprado" sólo por attrezzo, lo más probable es que la "moto" sea buena, funcione bien y nos la entregue en fechas. Si no, es posible que la tengamos tarde, mal y nunca. Pero lo que no nos quita nadie es que nos han vendido una moto: algo que no se sabe si nos hace falta, o si nos solucionará el problema, o si es la mejor opción para nuestras necesidades...

Ocurre en muchas ventas de sistemas de software, porque los

departamentos comerciales de las empresas de soft suelen acudir a los clientes azuzados para cubrir cifras de ventas, no para solucionar sus problemas. Quizá soy algo ingenuo, pero me siento molesto, incómodo, con

una especie de vergüenza ajena cuando veo festejar con risas y alharacas situaciones del tipo "Vaya moto le he vendido... ¡Un web en chino! y el tío no sabe ni para qué lo quiere. ¡por tropecientas mil!!". (Exclamaciones literal y lamentablemente reales). Sin entrar en si esto es un comportamiento profesional o simplemente mercantil, lo cierto es que el vendedor cuenta las

Procesos 88

excelencias de lo que le conviene vender: si su negocio es software libre afirmará que lo mejor es el CRM tal open source. Si es un integrador de "SuperSoft" dará la casualidad de que los productos de esa casa son precisamente lo que necesitamos y si se dedica a programar, nos va ha hacer un apaño o un sistema

nuevo para que tengamos la mejor solución. Y en el fondo, es que conocer el problema, analizar las soluciones posibles y seleccionar al proveedor más adecuado no es responsabilidad del suministrador, sino del adquiriente. Es el

proceso de adquisición.

Es mejor que sea el cliente quien elija al proveedor (basándose en conocimiento y razones objetivas), y no dejar que ocurra lo contrario.

Los diplomas de calidad del vendedor en el mejor de los casos dan garantía de que su trabajo lo sabe hacer bien, pero NO que vaya a hacer el nuestro. Adquisición es un módulo aparte del CMMI, y en el futuro será un modelo independiente, porque no es un proceso para fabricantes sino para compradores.

Procesos 89

Los proyectos de software pueden ser un fiasco por problemas en el desarrollo, mantenimiento y operación, pero también por problemas en la adquisición.

La mejor solución para adquirientes con infraestructuras TIC importantes es contar para las adquisiciones con un departamento de ingeniería propio y experto en Ingeniería de Software y en procesos de adquisición.

Para los más pequeños, un tipo de consultoría TIC difícil y que no abunda: asesoría (profesional e independiente) para la adquisición: servicios de análisis de requisitos del sistema, arquitectura, evaluación de proveedores, gestión y seguimiento del proyecto, validación y verificación. Lo más difícil de estas consultoras es la independencia de marcas, productos o

empresas amigas de desarrollo o integración, y el nivel técnico y profesional necesario; pero bueno, aunque pocas, alguna hay. Ojalá aumente la demanda y cada vez haya más consultores y arquitectos de software trabajando por los intereses del cliente

Procesos 90

El error de los modelos CMM

02.08.2006

CMMI se ha desarrollado sobre la base: " La calidad de un sistema o producto depende principalmente de la calidad de los procesos empleados en su desarrollo y mantenimiento".

Tomando por axiomático este principio, el modelo identifica a 25 áreas de procesos como factores clave para desarrollar software de calidad de forma eficiente, repetible, y cada vez mejor.

Así, por ejemplo, garantizar la integridad de los fuentes, y controlar adecuadamente las versiones de todos los documentos, librerías y demás elementos de la configuración es una de las 25 áreas de procesos. Sin duda, para garantizar resultados de calidad en este punto,

mucho mejor que contratar sólo a personas ordenadas de trabajo sistemático y buena memoria es apostar por los

procesos; disponer de los procesos más adecuados y capaces para la gestión de la configuración es el modelo más adecuado para conseguir calidad y eficiencia en la gestión y control de las versiones.

Pero, ¿para conseguir innovación, diseños de arquitecturas ingeniosos e implementaciones inteligentes, que puedan suponer mejoras de valor en el producto capaces de despeinar a la competencia. ¿Para multiplicar la eficiencia, no en la línea de producir más

líneas de código en menos tiempo, sino diseñando arquitecturas que requieren la cuarta parte de trabajo y ofrezcan el doble de robustez? Para conseguir esto CMMI no ofrece una estrategia diferente: "A través de los procesos se logra más valor y eficiencia que con las personas". Da "cosa" contradecir a SEI, pero creo que es un error.

Procesos 91

La innovación, los diseños de las arquitecturas y las estrategias

de solución deben su valor a las personas, no a los procesos. Las organizaciones que desarrollan software para sistemas novedosos o para sectores de mercado de cambios rápidos o bases tecnológicas inestables pueden mejorar su valor y eficiencia a través de los procesos en el porcentaje que sea, pero

a través de las personas pueden disparar esos mismos valores. Las organizaciones de software que dan soluciones a entornos de

problemas bien conocidos, que necesitan poca innovación, que desarrollan sistemas con niveles altos de integridad, que trabajan en sistemas que pueden definirse con detalle desde el primer día, y sobre bases tecnológicas más contrastadas y

estables, pueden aprovechar mucho mejor las ventajas de mejora, repetibilidad y escalabilidad que dan los modelos de mejora basados en procesos.

Procesos 92

La caja del producto

17.08.2006

Los proyectos ágiles parten de la visión del producto, y no de una especificación detallada de requisitos. Comentando en el blog de Unkasoft que el propietario del

producto debe tener muy claros dos puntos: la visión del producto y el alcance del proyecto; apunto en este artículo la práctica que suelo recomendar de la "caja del producto" porque

resulta muy útil: para explicar qué es la "visión"; para transmitirla y compartirla con todo el equipo; y para que la comunicación enriquezca el concepto inicial. El concepto de visión suele resultar ambiguo porque no es fácil de definir: tener clara la idea de producto o servicio, aunque no se conozca o no se sea capaz de explicar el detalle; porque de

hecho se espera que el propio proceso ágil trabaje e investigue para desarrollarlo y para dar al producto el mayor valor posible,

dentro de las restricciones del proyecto (alcance). El desarrollo creativo y la innovación que irá aportando harán surgir aspectos que no pueden predecirse y que requieren un proceso evolutivo para analizarlos e incorporarlos.

La visión del producto se mantendrá (si es buena y acertada), mientras las circunstancias y los requisitos cambiarán y evolucionarán para aportar más valor. Tan importante como disponer de una visión es que todo el equipo la conozca y comparta, y para garantizarlo suelo

recomendar que todos los implicados en el proyecto realicen, al menos al comienzo la práctica de "la caja del producto". Se trata de describir cómo sería la caja del producto que se va a realizar. La que tomarán en sus manos los clientes en la tienda para echar un vistazo y descubrir de qué se trata lo que hay dentro.

Este concepto de "caja" resulta apropiado para productos pequeños o determinados programas de software. Si se trata de un servicio, o de un producto grande, basta con cambiarlo por el folleto publicitario o la página web que lo describirá.

Procesos 93

En una sesión de trabajo, el equipo en conjunto, debe diseñar, según sea el caso:

La caja con las imágenes y textos de todas sus caras.

Un folleto publicitario, en formato A4 por las dos caras, o

tríptico.

La dos página que describirían el producto en el sitio web.

El resultado forma parte de la documentación del proyecto,

porque junto con el alcance (objetivo y restricciones de negocio) es el centro de la diana a la que apunta todo el equipo.

Procesos 94

ISO reconoce que los actuales modelos de software son inadecuados para pymes

28.08.2006

Si en su empresa o en sus proyectos no trabajan más de 25 personas, y está pensando implantar modelos de procesos tipo CMMI o ISO 15504, le interesa mucho conocer las conclusiones a las que está llegando el comité ISO de estandarización para la Ingeniería del software (ISO/IEC JTC1 SC7): "La industria del software reconoce la valiosa contribución de los

productos y servicios aportados por las pequeñas empresas. Los estándares internacionales ISO no se han escrito para pequeños proyectos, organizaciones o empresas con menos de 25 personas".

En la actualidad el sub-comité SCT7 está trabajando para proporcionar a este tipo de proyectos y de empresas, versiones

equivalentes adecuadas para ellos con los principios de los cuatro estándares actuales más importantes: ISO12207, ISO15288, ISO15504 (compatible con el modelo de mejora CMMI), ISO 9000-3. El proyecto tiene como objetivo desarrollar normas que

requieran poco esfuerzo de formación y adaptación y resulten adecuadas a los proyectos y empresas pequeñas, para hacer accesibles en ellas los estándares de la Ingeniería del Software.

Los desarrollos serán armónicos y estarán alineados con los principales estándares ya definidos, así como con los principios de madurez de las normas ISO 15504 o CMMI. La agenda del comité ISO prevé tener la propuesta de ciclo de

vida del software para pequeñas empresas, preparada para pasar a la fase de aprobación como estándar internacional en noviembre de 2007. Hace ya algún tiempo empecé a guiarme por mis propias conclusiones sobre los modelos de calidad, las técnicas ágiles, la gestión de los proyectos; y viendo por un lado las tendencias

ágiles en busca del equilibrio entre agilidad y disciplina; y por

Procesos 95

otro que ISO trabaja en proyectos como este, creo que no estoy tan loco. Lo que uno nunca sabe es si a las organizaciones como ISO o SEI, o a las firmas de consultoría no les pasará lo que a las

malas empresas de software, que quizá no trabajan por la supervivencia de sus clientes, sino por la suya propia; porque ninguna empresa de software quiere estándares, sino calidad, eficiencia y valor. (Art. Rel. nuestros clientes no quieren programas, pág. 225).

Procesos 96

Síntesis

10.09.2006

Cuestionar lo conocido genera la contradicción, la tensión entre contrarios que actúa de motor en la evolución del conocimiento. No es nuevo. Lo afirmó Platón. En filosofía ha creado la escuela dialéctica , y Nonaka y Takeuchi, en su último líbro Hitotsubashi

on Knowledge Management afirman también estar convencidos de que este patrón dialéctico de tesis, antítesis y síntesis dirige la evolución del conocimiento: antítesis que se oponen y

cuestionan las tesis anteriores, y dan como resultado nuevas posturas de síntesis que a su vez harán el papel de tesis en el siguiente ciclo evolutivo; formando así una espiral de evolución y perfeccionamiento continuo.

Estoy convencido de que los modelos basados en procesos han sido la "tesis" que inicia el conocimiento para desarrollar sistemas de software. Que la agilidad es su antítesis, y que

estamos generando en estos años la síntesis; un resultado enriquecido de ambos, depurado y con mayor valor de conocimiento.

Procesos 97

En 1968 la NATO organizó un congreso para ver qué pasaba con eso del software, porque en todos los proyectos siempre eran los subsistemas de software los que llegaban tarde, mal y nunca. Allí se etiquetó al fenómeno como "crisis del software" y se habló

por primera vez de la necesidad de crear un conocimiento, una "Ingeniería del Software" para darle solución. Los ordenadores comenzaban a no ser excesivamente extraños, y la demanda de programas y programadores empezó a crecer, pero los héroes que se ponían a ello contaban con una base de conocimiento inexistente para ayudarles. Tan sólo disponían de

los manuales de usuario de los sistemas operativos y de los

lenguajes de programación. Unas referencias que ayudan a comprender la situación del conocimiento de aquellos años: En 1968 Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered Harmful".

La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens. El primer libro sobre métrica de software fue publicado en 1977

por Tom Gilb El primero sobre análisis de requisitos apareció en 1979

El nacimiento de la Ingeniería del Software como respuesta a la crisis bautizada en el congreso de la NATO ha sido la primera tesis, el inicio del conocimiento para el desarrollo de sistemas de software. Esta "tesis" se construyó sobre las prácticas coetáneas, más o menos veteranas y más o menos contrastadas en otras ingenierías y en otros ámbitos:

Desarrollo basado en procesos como garantes de calidad repetible y escalable. Principios de calidad de Juran (la calidad resultante depende de la calidad de los procesos empleados)

Pautas de gestión de proyectos predictivas para garantizar la eficiencia y el cumplimiento de plazos y presupuestos. En los 80 y 90 comienza a cristalizar su base de conocimiento: Modelos de procesos específicos para software: ISO9000-3 CMM's SPICE-ISO 15504 , Bootstrap, etc. Aplicación al software del patrón de gestión de proyectos

predictivo aplicado en otras ingenierías: PMI , IPMA .

Procesos 98

Primer borrador de consenso sobre el cuerpo de conocimiento de la Ingeniería del Software: SWEBOK . En los 90 comienza la difusión y aplicación de este conocimiento. En algunos ámbitos da buenos resultados, y en otros genera una

réplica "dialéctica"; la antítesis de la conferencia de la OTAN: El Manifiesto Ágil, (pág. 79) que cuestiona la validez de los modelos basados en procesos y la gestión predictiva para el desarrollo de software. Se radicalizan las posturas entre ambas líneas y se genera (y se está generando) la tensión entre contrarios que es el motor para

el avance dialéctico del conocimiento.

Algunos ejemplos de esta tensión: "La diferencia entre un atracador de bancos y un teórico de CMM

es que con el atracador se puede negociar"

... "La evaluación en CMM depende más de una buena presentación en papel que da la calidad real del producto de software. Tiene que ver más con el seguimiento a ciegas de una metodología que con el desarrollo y puesta en producción de un sistema en el panorama tecnológico".

Ken Orr , CMM versus Agile Development: Religious wars and software development .

Procesos 99

Si uno pregunta a un ingeniero de software típico si cree que

CMM se puede aplicar a los métodos ágiles, responderá o con una mirada de sorpresa o con una carcajada histérica.

Richard Turner y Apurva Jain, Agile meets CMMI: Culture Clash or Common Cause .

Sin duda estamos en la resolución dialéctica de los extremos hacia una síntesis:

En estos momentos autoridades de la Ingeniería del Software

como Barry Boehm y Richard Turner hablan de balancear la agilidad y la disciplina y proponen un patrón de 5 factores discriminadores (pág. 163). ISO comprueba y anuncia que los modelos desarrollados funcionan en unos entornos, pero no en otros, y ha creado ya comités para desarrollar versiones más ligeras. Surgen iniciativas de normalización como MoProSoft que buscan

puntos intermedios entre ambos extremos. Muchos profesionales plantean dudas sobre ambos extremos, y

prueban con mayor o menor tiento y acierto soluciones híbridas . Estamos determinando la primera oposición en la espiral dialéctica del conocimiento de la Ingeniería del software. Es un momento más confuso, durante el que ya no está tan claro el norte y es mas difícil orientarse. Resultaba mucho más cómodo

1995 por ejemplo. Con la tesis desarrollada, y sin haber despertado aún su antítesis ágil, sentíamos que habíamos alcanzado la verdad. Que ya sabíamos cómo desarrollar software. Que todo era cuestión aplicar pautas de ingeniería en fases secuenciales, con gestión predictiva... Ahora estamos a mitad de resolución entre esa tesis y la

antítesis ágil.

La contradicción es el motor del avance, pero produce confusión, y además la velocidad de difusión que ha imprimido la generalización de internet en la segunda mitad de los 90 y el apresuramiento general del entorno, hace que se solapen las tres tendencias del ciclo.

ISO 15504, CMMI, Scrum, DSDM, Extreme Programming, etc. son grandes aportaciones y es mucho lo que se puede aprender de ellos, pero es iluso pensar de cualquiera que es la solución. El conocimiento va a estar evolucionando siempre y no tardarán mucho en quedar superados o mejorados por su propia

Procesos 100

evolución. Los libros sobre CMMI o Scrum de hoy, cuando los leamos dentro de pocos años serán ya libros de conocimiento desfasado. La evolución la movemos todos, cuestionando y sugiriendo mejoras.

Procesos 101

Good Agile, Bad Agile y otros fundamentalismos

30.09.2006

Good Agile, Bad Agile es el título del artículo en el que Steve Yegge, programador de Google, cuestiona aspectos y prácticas

de los modelos ágiles, y que estos días ha causado cierto revuelo entre blogs y foros del mundillo.

Este tipo de situaciones: de críticas entre posturas diferentes, mejor o peor argumentadas son de un análisis muy rico tanto para aprender sobre el tema que tratan, como por la miga sociológica que revelan. Los humanos necesitamos conocer el porqué de las cosas,

aprehender la realidad del entorno en el que trabajamos; pero la realidad no es lineal y plana, es multidimensional. No se trata de la melodía simple de una flauta dulce sino del concierto de un

una orquesta sinfónica. Trabajamos y nos movemos en sistemas complejos de múltiples dimensiones en las que operan muchas variables que actúan de forma relacionada y coordinada.

En la construcción de conocimiento que vamos desarrollando y mejorando de forma continua para explicar porqué determinada realidad se comporta así, vamos revelando algunas variables, sus relaciones y parte de alguna dimensión. Con ellas elaboramos hipótesis, y desarrollamos modelos de la realidad que nos muestran un poco la explicación que andamos

buscando.

Pero un modelo es sólo el boceto de una visión parcial de la realidad. El desarrollo de software, como cualquier realidad, es muy rica y compleja, y además cada empresa debe operar con esas

variables y dimensiones para adecuarla a sus circunstancias y entorno e interpretar su propio concierto. Por supuesto que en la realidad del desarrollo de software interviene la "dimensión" de procesos, por supuesto que también interviene la de las personas; también la tecnología, la cultura organizacional...

Procesos 102

Y si miramos los entornos posibles... Hay quien desarrolla software para guiar misiles balísticos, para gestionar los saldos bancarios de sus clientes, para crear juegos en videoconsolas, para retocar fotografías, etc.

En este escenario es en el que un buen día Steve Yegge se da cuenta de lo bien que funciona en "su realidad" de trabajo de Google: el que los programadores no tengan directrices pre-fijadas, que dediquen un buen porcentaje del tiempo de trabajo a mirar e investigar cosas diferentes al proyecto que tienen entre manos, que los gestores dediquen la mitad de su tiempo a

programación, etc.

Y todo lo que ve es cierto, funciona bien y le da valor a Google. Tiene razón. Podría sintetizar un modelo, una metodología de trabajo, etiquetarla como "Google-Agile" y difundirla. Jeff Sutherland hizo algo parecido hace 10 años, sintetizó el

conocimiento de una metodología de trabajo que empleaba en su empresa: Easel Corporation. Lo etiquetó como Scrum y junto con Ken Schweber lo presentó como metodología de desarrollo.

Profesores de universidades, investigadores y expertos de nuestra industria han descubierto también mecanismos e interacciones de variables y dimensiones que funcionan bien:

CMMI, ISO, ITIL... El problema surge al decir: "¡Eh chicos, no le déis más vueltas!. Este es el modelo bueno, y no el vuestro!. ¡Pero dónde váis, madre mía que tonterías decís!. Y ya metido en harina, el artículo de Steve, aunque peca de esta

tendencia fundamentalista, tiene también algunas incorrecciones políticas interesantes al cuestionarse el tema de los "$eminario$

de formación" que, si bien por su enfoque anti-agilidad sólo ve los abusos en un lado, en realidad se producen en todas las líneas que enseñan forman y asesoran sobre "su" modelo de la realidad.

Se puede llegar a entender que merezca la pena pagar bien por oir hablar a Watts Humphrey sobre CMMI o a Jeff Sutherland sobre Scrum, pero en esta realidad tan compleja resulta que al final, estos enseñaron a otros, que hicieron un modelo en el que mantienen su negocio enseñando a otros que llevan gráficos y textos en proyectores y leen los guiones.

Procesos 103

Si la corrección no me lo impidiera os diría detalles y anécdotas sobre el nivel del seminario de 3 días de introducción a CMMI que me costó 2.000 eurazos que harían sonrojar (espero) al formador y la firma de consultoría que lo impartió, o las dudas que me plantean los conocimientos que pese al diploma de

"ScrumMaster", puede tener alguien que no sabe inglés, tras haber estado 2 días en un curso de scrum impartido en inglés por un formador de menos experiencia en programación que los propios asistentes. Pero claro, es que también hay otra realidad compleja: la de la

formación consultoría y asesoría que se generan alrededor de los

diferentes modelos de conocimiento, en el que se da con frecuencia que personas con muy poca experiencia y preparación, muestran a empresas que no tienen nada que ver con Easel Corporation lo bien que les va a ir aplicar Scrum "a calcetín", o que nada más entrar por la puerta, sin diagnosticar ni observar la realidad de esa empresa saben que lo mejor va a

ser que implanten CMMI o incluso, como me ocurrió a mi personalmente me dijera una firma de asesoría que, bueno, nunca habían trabajado con empresas de software, pero que eso no tenía nada que ver, que ellos eran expertos en implantar

ISO9001 y que seguro que si mi departamento era conforme con ISO 9001 lo sería con esa ISO 12207 o 15504 que yo decía (¿?¿?¿?).

Procesos 104

Cultura de cumplimiento

05.10.2006

Dar prioridad “1” a los procesos, en las empresas que la deberían dar a las personas, crea “culturas de cumplimiento” que truecan los medios por los fines; y hace que, inexplicablemente y aunque trabajen bien… seguramente por la mala suerte, o por la

competencia, o por la coyuntura o por causas contra las que es imposible luchar, los resultados no acompañen.

Cuando los resultados dependen de la capacidad de las personas y se actúa mirando sólo a los procesos, se crean ecosistemas que camuflan la ineficiencia, porque por mimetismo copian para entornos de conocimiento un principio de calidad válido para entornos industriales: “La calidad obtenida es el resultado de la calidad de los procesos

empleados”

La causa de la calidad de la arquitectura de un sistema (por ejemplo) no hay que buscarla tanto en el proceso o en las herramientas empleadas, como en las neuronas de sus autores.

Por ejemplo, en la gestión de proyectos, la base de conocimiento disponible ofrece a los gestores técnicas y herramientas para ayudarles a ordenar y estructurar las ideas; registrar, consultar y analizar la información:

1 Diagramas de Gantt

2 Ruta crítica

3 Plan de comunicación

4 Plan de riesgos

5 Plan de calidad

6 Plan de recursos

7 Matriz de responsabilidades

8 Actas de reuniones

9 Etc. Pero esto son las herramientas, y no su trabajo.

Procesos 105

La misión del gestor no es: hacer el gantt, el presupuesto, el plan de comunicación, el plan de riesgos, moderar las reuniones… Cuando esto pasa a ser el trabajo de su cargo; se termina por considerar que quien hace las obligaciones de su puesto, hace su

trabajo. De esta forma hay ingenieros, consultores o gestores que realizan perfectamente su labor, pero… tienen mala suerte y los resultados no les acompañan.

Los directivos son los responsables de la cultura de la

organización, y los más indicados para evitar la “cultura del cumplimiento” en actividades para las que el “cumplimiento” no garantiza los resultados, y hace olvidar que el fin de un diseño, de un plan, de una gestión… no es realizarlos según las normas, sino ayudar al ingeniero o al gestor a concebir el mejor plan, diseño o gestión (según los casos).

Si la herramienta es el fin, y los procesos los responsables de los resultados, da igual que las personas sean más o menos aptas o ineptas. Serán estupendos trabajadores si cumplen con su

jornada laboral, o mejor aún, si la exceden y “cumplen con el trabajo de su puesto”.

Procesos 106

Flexibilidad = síntesis + gestión sistémica

30.10.2006

SÍNTESIS ¿Qué es mejor, el yin o el yang? ¿La tesis o la antítesis? ¿Los

procesos o la agilidad?

Los gestores y modelos ágiles que dan la espalda a la gestión predictiva, emplean en su trabajo un fondo de conocimiento incompleto; y lo mismo ocurre con la gestión predictiva que ignora los valores y prácticas de los modelos ágiles. GESTIÓN SISTÉMICA

Las empresas son sistemas inter-relacionados, y no departamentos separados conectados por procesos de negocio. Desde esta realidad sistémica, un gestor de proyectos

trabajando con técnicas ágiles en una empresa cuyo departamento de personal, programadores, departamento comercial y directivos trabajan sobre supuestos predictivos, acabará con sensación de impotencia y ganas de tirar la toalla.

FLEXIBILIDAD Cada proyecto tiene sus propias circunstancias: estabilidad del entorno, componente de innovación, grado de criticidad del producto que debe construir, cultura de la organización que lo desarrolla, etc. No hay dos proyectos iguales, ni dos empresas iguales; ni por

tanto una "talla única" para gestión de proyectos. La cuestión no

es determinar si el modelo de gestión bueno para el software es PMI o Scrum, CMMI o Extreme Programming. En los dos extremos: en la tesis y en la antítesis hay conocimiento y prácticas valiosas. La gestión flexible los conoce y los emplea de la forma más adecuada a las circunstancias de cada proyecto o

de cada empresa. Estas son las razones por las que desconfío de los métodos y cursos de formación milagrosos. Desde mi punto de vista crean mitos porque:

Procesos 107

Un gestor de proyectos de software no se puede hacer en dos días.

La incorporación de una metodología en una empresa tiene repercusiones en todo el sistema y no sólo implica al gestor de proyectos.

Por tanto, para evitar gestores de proyectos con formación coja, y empresas fraccionadas la estrategia debe tener presente:

Un gestor de proyectos completo se forma con una visión

sintética de la tesis y la antítesis de la gestión, y con experiencia. Y cuanto mayores sean ambos, mejor gestor será.

Implantar o mejorar modelos y procesos de desarrollo no

es algo que solo ataña al gestor de proyectos.

Procesos 108

¿Por qué 5 niveles de madurez?

06.11.2006

Watts Humphrey, cuando acometió el desarrollo del original modelo CMM for Software, tomó el concepto de madurez para los procesos, de la "Quality Management Maturity Grid (QMMG) desarrollada por Philip B. Crosby en su libro Quality is Free

(1979), y que según el autor establece un criterio de para determinar el grado de desarrollo y asentamiento de los procesos en una organización, en cinco escalones que denominó:

1 Incertidumbre

2 Despertar

3 Aclaración

4 Sabiduría

5 Certeza

CMM-SW es por tanto un modelo escalonado, y otros modelos de la familia CMM también tienen una representación "escalonada" y comparten el concepto básico de por qué esos 5 escalones para medir la madurez de la organización.

Procesos 109

Una premisa fundamental e inherente al concepto de madurez de procesos es que una práctica no puede implementarse si no es posible su repetición. En las organizaciones con escaso nivel de madurez las prácticas de alto rendimiento son sólo esporádicas.

Las áreas de procesos clave que forman los niveles 2 de los modelos CMM ayudan a las organizaciones a eliminar los elementos que les impiden repetir de forma estable resultados satisfactorios. En el caso del software las causas más comunes son las agendas, la consolidación de recursos y con un peso

generalmente muy importante los cambios incontrolados de

requisitos que arrasan la planificación inicial. Bajo la presión de satisfacer objetivos irracionales, la dirección de los proyectos comienza a trabajar omitiendo procesos de ingeniería y cometiendo errores que cuando se detecten producirán tiempos y costes excesivos para su reparación. Como

consecuencia los proyectos pierden el control de las agendas, presupuestos y nivel de calidad esperados. Cuando se sacrifican las prácticas de ingeniería de software, el personal técnico pierde las posibilidades de mejorar su rendimiento o de implementar

ideas innovadoras. El objetivo principal del nivel repetible es inculcar un proceso disciplinado en un entorno que garantice las prácticas básicas necesarias para estabiliza un escenario que

permite unas bases de rendimiento repetibles. Obtenido un entorno de desarrollo estable y de condiciones repetibles, la organización puede centrarse en transferir las prácticas a través de toda su estructura. A pesar de que la organización puede realizar prácticas satisfactorias de forma estable al alcanzar el nivel repetible, los niveles de rendimiento

varían entre personas y equipos diferentes.

El nivel de madurez 3 (generalmente denominado "Definido") centra la atención en los procesos que obtienen mejores resultados para identificar aquellas técnicas que mejor han funcionado en proyectos diferentes y las integra en los procesos

generales de desarrollo.

Procesos 110

Una vez que la organización es capaz de modelar su proceso de desarrollo de forma consistente, puede procesar la información obtenida para eliminar sistemáticamente las causas de las diferencias de rendimiento. El objetivo del nivel 4 ("gestionado") es establecer objetivos cuantitativos de rendimiento y calidad,

reducir las variaciones en los procesos para estabilizar la capacidad de la organización para conseguir sus objetivos. En el quinto nivel ("optimizado"), la organización se centra en un proceso de mejora continua. Identifica tecnologías y procedimientos innovadores que pueden mejorar de forma

indefinida su rendimiento y posición competitiva. Las causas de

los defectos se eliminan de forma sistemática. Para mejorar la capacidad de desarrollo, el patrón CMM ayuda a establecer un entorno de aprendizaje en el que la organización aprovecha la experiencia acumulada para retroalimentar el proceso de mejora.

De forma genérica el entorno de maduración crea un entorno en el que Las prácticas pueden repetirse. Las mejores prácticas pueden transferirse rápidamente a través

de los diferentes grupos. Se reducen las diferencias de rendimiento. Las prácticas se mejoran de forma continua para aumentar la

capacidad.

Procesos 111

La forma y el fondo de la agilidad son cosas diferentes

12.11.2006

Enamoramiento: Proceso bioquímico propio de los seres humanos que se inicia en

determinadas ocasiones por la presencia o la comunicación entre dos miembros de la especie, generalmente de sexos diferentes.

El proceso comienza con la producción en el cerebro del neurotransmisor feniletilamina; compuesto orgánico de la familia de las anfetaminas. Esta producción genera a su vez la secreción de otros neurotransmisores: dopamina, norepinefrina y oxiticina. Sus efectos en el sistema nervioso de la persona generan sensaciones plancenteras y mecanismos de refuerzo y resistencia

al cansancio. Esta es una explicación correcta y objetiva del proceso

neurológico del enamoramiento; pero el enamoramiento es mucho más, y en realidad no dice nada de su auténtica esencia y trasfondo.

Scrum: Ciclo de vida del desarrollo que aplicado al software se caracteriza por un modelo de construcción iterativo e incremental. Cada iteración de desarrollo suele durar 30 días, pero puede ser desde 10 hasta 90; y produce un incremento del producto completamente funcional. Tras cada iteración se analizan y revisan los resultados y los

requisitos globales del producto para detallar los que se

programarán en la próxima iteración. Esta definición me recuerda a la anterior. El desarrollo ágil es mucho más, y esta descripción sólo revela la

forma exterior pero no muestra nada de la auténtica esencia y del trasfondo.

Procesos 112

La agilidad es una actitud frente al desarrollo, una cultura organizacional. Las formas (DSDM, Scrum, FDD, XP...) son diferentes carrocerías más o menos acertadas para soportar y distribuir las prácticas ágiles, pero sin el motor no funcionan.

Procesos 113

Método ágil de estimación: Planificación de póquer

02.01.2007

En las metodologías ágiles es habitual desarrollar dos niveles de planificación: una general, planificación de la versión, y otra más

detallada, planificación de la iteración.

El objetivo de la planificación de la versión es calcular la dimensión del proyecto. Saber si estamos hablando de 10 o de 100, y tanto en Extreme Programming (Release planning) como en Scrum (estimación del product backlog) se realiza en una reunión en la que participa todo el equipo.

En ella el cliente, o el propietario de producto expone una a una las historias o funcionalidades que necesita y el equipo determina el tiempo que llevará su desarrollo.

Este proceso no es ajeno a los problemas típicos de dinámica de reuniones, y aunque tiene un guión concreto y conocido por todos los participantes, es habitual entrar en atascos de

"parálisis por análisis", en los que los minutos van pasando sin que los participantes terminen de decidir entre las posibles soluciones para una determinada funcionalidad y fijen una estimación; y el moderador ve con impotencia cómo ha consumido ya 15 ó 20 minutos sin poder cerrar la primera funcionalidad, y la lista de las que aún están pendientes de valorar.

Una aportación muy valiosa de las prácticas ágiles es la

tendencia a definir protocolos concretos para conducir las reuniones; y para las que tienen como objetivo obtener valoraciones cuantitativas consensuadas por un grupo de personas, el protocolo definido por James Grenning para las planificaciones de versión de extreme programming, y que

denomina "Planificación de póquer" (Planning Poker), es el mejor que conozco.

Procesos 114

Planificación de póquer (Descripción para planificaciones de versión de extreme programming, en las que la "granularidad" del esfuerzo

requerido para cada historia de usuario debe estar comprendida entre 1/2 día y 10 días de trabajo. El mismo protocolo resulta muy útil para estimaciones en rangos de horas en lugar de días, modificando los valores de las cartas; o incluso para otro tipo de estimaciones y acuerdos).

Cada participante de la reunión tiene un juego con las 8

cartas de la figura.

Para cada historia de usuario o funcionalidad de la pila

del producto (product backlog) el cliente, moderador o

propietario del producto (según sea) lee o expone la descripción empleando un tiempo máximo (No son aconsejables más de 2 minutos).

Se da un tiempo para que el cliente o propietario del producto responda a las preguntas que puedan tener los estimadores.

Terminadas las preguntas, cada participante selecciona, sin mostrarlas, una o dos cartas que suman el nº de días

de trabajo necesarios. Si se estima que la funcionalidad

Procesos 115

necesita más de 10 días, se selecciona la carta "infinito". Cuando todos han hecho ya su elección, se ponen boca arriba en la mesa.

Si no hay gran diferencia entre las estimaciones de cada

participante, se toma como resultado la media.

Si la estimación resulta "infinito", la funcionalidad debe

dividirse para ajustarla a los criterios de tamaño de la metodología que se esté empleando (en este supuesto

10 días).

Si las estimaciones resultan muy dispares el moderador con su criterio de gestión y basándose en las características del proyecto, equipo, reunión, nº de

funcionalidades a evaluar. puede optar por:

Preguntar a las personas de estimaciones extremas: ¿Por qué crees que es necesario tanto

tiempo?, y ¿Por qué crees que es necesario tan poco tiempo?. Tras oir las razones, repetir la estimación.

Dejar a un lado la estimación de esa funcionalidad

y retomar al final o en otro momento las funcionalidades que no alcanzan consenso.

Pedir al cliente o propietario del producto que

descomponga la funcionalidad y valorar cada una de las nuevas funcionalidades resultantes.

Tomar la estimación menor, mayor o la media.

Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el

cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos

sin discusiones, y además... resulta divertido y dinamiza la reunión.

Procesos 116

Síntesis entre agilidad y disciplina

10.01.2007

No todo lo que etiquetamos como procesos es la misma cosa. En algunos las personas ayudan al proceso, y en otros son los procesos los que ayudan a las personas.

En el primer caso el proceso es el protagonista, el que sabe cómo hacer el trabajo y la persona se integra en el sistema como

instrumento, como operario de apoyo. En el segundo el artífice es la persona y el proceso una ayuda, una herramienta que simplifica aspectos rutinarios para que pueda lograr más eficiencia y no diluir el esfuerzo en rutinas mecánicas. La principal diferencia entre unos y otros es el tipo de conocimiento con el que trabajan. La clasificación de Nonaka y

Takeuchi entre explícito (contenido en los procesos y la tecnología), y tácito (contenido en la persona).

Por eso prefiero abrir una distinción, y llamar "procesos" a los que operan en sistemas de conocimiento explícito, y "rutinas" a los que apoyan a las personas en sistemas de conocimiento

tácito. Esta es una de las conclusiones de la síntesis entre procesos y disciplina (tesis) por un lado, y agilidad (antítesis) por otro. Ambas construyen sobre la premisa de tres elementos: personas, procesos y tecnología. Para los primeros, el valor de

los resultados es consecuencia principalmente de los procesos empleados.

Procesos 117

Para los segundos, la variable más influyente en el valor del resultado son las personas.

¿Quién tiene razón la tesis (CMM, ISO 15504, PMI...) o la antítesis (XP, Scrum, DSDM...)?. Ambos la tienen, y lo que su síntesis revela es que los procesos y las personas, que cada uno gestiona de forma diferente, encierran dos aspectos diferentes en cada caso, y no uno sólo.

Procesos 118

Los procesos pueden ser procesos o rutinas. El valor que el sistema espera de la persona puede ser trabajo o conocimiento. Con este plano aparecen conclusiones y bases de gestión con más sentido. Lo adecuado que resultan los modelos formales en

los sistemas que combinan procesos con trabajo, y lo inadecuado de los modelos ágiles en estos casos; y viceversa.

Los chirridos que se producen al componer sistemas combinando rutinas con trabajo, o procesos con conocimiento. Y esta es una simplificación en blanco y negro de una realidad en

color. Son raros los sistemas que encierran todo el conocimiento sólo en procesos y tecnología, o sólo en las personas, pero por eso mismo también son minoría los entornos de producción en los que puede encajar como solución de talla única un modelo basado en procesos o un modelo ágil "tal cual".

Procesos 119

Procesos 120

Factorías y talleres de software

23.01.2008

Esta definición me recuerda a la anterior.

Los modelos de calidad basados en el principio TQM (la

calidad del software desarrollado se rige por la del proceso usado) son adecuados para las "factorías de software".

Los principios ágiles funcionan en los "talleres de

software".

En las primeras, el valor de los resultados depende sobre todo de los procesos y la tecnología; en los segundos, de

las personas.

Algunos productos o servicios de software necesitan eficiencia, resultados homogéneos y repetibles.

Otros, valor innovador continuo.

Factoría es a operario, lo que taller a artesano; y proceso

es a factoría, lo que talento a taller.

Procesos 121

Homo homini lupus

23.05.2008

El Manifiesto Ágil (Beck y otros, 2001)comienza así: "Estamos poniendo al descubierto mejores métodos para desarrollar software... "

Podían haber dicho "nuevos" pero no, dijeron "mejores", con la suposición implícita por tanto de que los demás son "peores". No que sean diferentes, o quizá más apropiados para según qué

proyectos o equipos... no: los modelos ágiles son mejores, y los otros son peores. La base de conocimiento del PSP, (Humphrey, Pomeroy-Huff, Julia Mullaney, Robert Cannon, & Sebern, 2005) el que posiblemente sea el método menos ágil para gestionar el trabajo de programación, dice en su introducción que hay muchos

modelos para mejorar el desarrollo de software, que todos prometen ser los mejores, pero que el único que lo puede

demostrar es PSP. "There is no such consensus in software engineering: Everyone promotes their own methods, claiming huge benefits in

productivity, usually not backed up by any scientific, unbiased evidence” [Wikipedia 05]. A powerful counter to this criticism is the widespread adoption of the Personal Software process (PSP) methodology..." The Personal Software Process (PSP) Body of Knowledge

Lupus est homo homini, non homo, quom qualis sit non novit

Procesos 122

La certificación ScrumMaster es una amenaza para la gestión ágil

14.05.2008

Es la opinión Sharon Cichelli, que esta semana volvía a cuestionar el valor real de la certificación ScrumMaster:

"Basta con asistir a dos días de clase. Esto es todo. Suena realmente peligroso...

...Pregúntale a un directivo a quién preferiría contratar, si a alguien con tres años de experiencia trabajando en equipos scrum, o a un Scrum Master Certificado (trompetas y fanfarrias). Los que conocen Scrum saben que ScrumMaster es el nombre de un rol, pero a los que no saben de Scrum les suena a dos

palabras, con un espacio en medio: Srum Master, el experto del proceso"

Agile Open Space: On Certifications (Cichelli, 2008)

Opino lo mismo, y la argumentación, para mi, tiene bastante sentido:

A Sharon le asusta esta certificación, y la considera una amenaza para la agilidad, porque, como dice: ella quiere permanecer en el juego del desarrollo ágil. Le encantan los proyectos ágiles, pero la sombra de advenedizos y encumbrados "enterados", colocados a gestionar equipos o

departamentos de programación ágiles, por empresarios

despistados, producirá, con nombre de agilidad, un nuevo modelo de gestión errónea y tediosa, y sembrará PHB's en un campo en el que aún no estaban creciendo. La certificación ScrumMaster tiene bastante de "nuevo traje del

emperador". Los conocedores de desarrollo ágil y de scrum lo saben, y como apunta Sharon, tomando una cerveza con Mike Cohn es cuando puedes ver cómo bromea sobre la certificación; pero por una peligrosa y poco ética camaradería o corporativismo mal entendido, en público se mantiene y agranda el mito.

Procesos 123

Las certificaciones profesionales son una cosa, y el networking otra. Ambos valiosos y necesarios en su medida, según cada caso. En cada profesión la utilidad de las certificaciones profesionales

es directamente proporcional a la rapidez de evolución de su cuerpo de conocimiento. Si me dan a elegir como administrador de sistemas a fulanito, con credenciales de Ingeniería Informática, por la Universidad de XX en 1990; o a menganito, con certificación profesional de experto CISCO (CCIE). Me quedo con el segundo.

Si fulanito no ha seguido una formación continua ya no estará "en el juego". Se habrá quedado en los "análisis funcionales y orgánicos", en las plantillas y formatos de codificación COBOL, y en la comunicación a través de puertos RS232 Nuestra profesión trabaja en un escenario muy rápido: el

conocimiento de un médico (por ejemplo) de hace diez años, aún me puede valer; el de un programador, no. Las certificaciones profesionales facilitan la formación continua,

mantienen al día a quienes trabajan en escenarios rápidos, y les ayudan a reflejar su actualización en los currículums.

Y otra cosa es el networking: concepto poíticamente correcto, porque tiene la ambigüedad suficiente para abarcar desde relación o colaboración, hasta variantes de más dudosa ética como amiguismo, recomendación o incluso enchufe. Qué duda cabe que se trata de un valor importante; que una organización de buenos técnicos, pero sin "capital relacional"

(otro maravilloso eufemismo) lo tiene duro para transformar su valor en beneficio económico; y que, sin embargo, una

organización con buen "networking" y "capital relacional", se puede hacer millonaria. Las ferias y congresos son el campo de cultivo del networking,

donde éste suele ser el principal, si no el único, atractivo para sus asistentes. Los cursos, o la enseñanza reglada, son los modelos tradicionales de formación profesional; y, en tercer lugar, los Master, tipo MBA, son un modelo con la combinación de ambos valores profesionales: actualización y networking. A las cosas conviene llamarlas por su nombre; a dos jornadas de charlas y ejercicios de simulación se le debería llamar congreso:

sitio en el que te dan información, pero no un título, y en el que

Procesos 124

vas a conocer a gente del mundillo (o a "hacer networking"); porque al no llamar a las cosas por su nombre, y ponerle el disfraz de Master de vanguardia en la gestión de proyectos: se despista, o incluso engaña a los profanos, y se fuerzan complicidades de dudosa ética entre los expertos, a quienes en

pro de las buenas formas y de las obligadas sonrisas del networking se les fuerza a mirar a otro lado cuando los emperadores desnudos presumen de su nuevo trajes.

Procesos 125

Fundamentalismo

29.06.2008

Entre la lista de posts pendientes de leer, encuentro otro :"Are you really using Scrum" (Duncan, 2008) de ayuda para saber si avanzamos por el camino recto, o andamos descarriados y

apartados de la doctrina; para lo que prescribe, como suele ser habitual en estos casos, algunos mandamientos: ¿Las iteraciones son de menos de 4 semanas?, ¿Probamos el software al final de

cada iteración?... Dejando a un lado cuál pueda ser el porcentaje de conocimiento, y cual el de majadería o de "post-copio - post-pego" con el que se ha elaborado la lista; hacer afirmaciones del tipo "esta es la verdad" no ayuda mucho a la evolución dialéctica (pág. 96) del conocimiento, ni a la riqueza que supone el mestizaje desde el

convencimiento de que ninguna verdad es absoluta, comenzando por la de uno mismo; y puede ser algo pretencioso, sobre todo

en escenarios dialécticos rápidos de conocimientos adolescentes como el de la ingenieria de software. Scrum, DSDM, Extreme Programming, CMMI, ISO 15504,

Crystal, FDD, Prince2 PMI, ... son algunos de los modelos de procesos, métodologías o conjuntos de prácticas para mejorar el desarrollo de software y aportan un conocimiento muy importante, pero resultan mezquinos cuando afiman ser la doctrina verdadera, y empobrecen a los profesionales que se lo creen, anclándolos en sus convicciones, mientras el entorno sigue avanzando.

Fundamentalismo (RAE): Exigencia intransigente de sometimiento a una doctrina o práctica establecida.

Procesos 126

Scrum con el culo, y dinero por nada

06.09.2008

Por la exposición "Money for Nothing" que junto a Boris Gloger, Jeff Sutherland presentó en Viena a finales de marzo, y por la presentación en Agile2008, los análisis de Jeff Sutherland de los

últimos meses sobre scrum se han centrado en dos líneas de propuestas para mejorar el valor que scrum entrega al cliente: la forma de contrato y los puntos clave que potencian la

productividad de scrum. Para la primera propone introducir en los contratos una cláusula que denomina "dinero por nada", y para la segunda, una escala que identificaría cómo de productiva es la forma en la que se está usando scrum, y que va desde el nivel más bajo al que llama "scrum con el culo" al más alto: "scrum magnífico".

Se le podría quitar el look informal y rebelde que se le ha dado,

si a la cláusula en lugar de llamarla "de dinero por nada" se le hubiera llamado "de cancelación"; o si la lista fuera una "scrum Checklist", en lugar de una "scrumButt Checklist"... pero la primera perdería el disfraz de innovadora, y la lista daría menos

que hablar . "Dinero por nada" (Money for Nothing). La propuesta consiste en:

Emplear un contrato típico de funcionalidades y precio

cerrado.

Incluir una cláusula "dinero por nada".

Sólo se podrá aplicar si el cliente sigue las normas

scrum.

De mutuo acuerdo se estiman los costes de todas las funcionalidades incluidas en el contrato.

El cliente puede decidir en cualquier momento cancelar el contrato.

En ese momento se determinaría el coste de las

funcionalidades restantes y se resuelve el contrato por el 20% del valor que quedaba.

Procesos 127

El proveedor asume la inclusión de trabajos posteriores acordados de mutuo acuerdo.

Lista de comprobación para determinar el nivel de productividad de Scrum (ScrumButt Checklist): Categoría iteraciones

No se hacen iteraciones: 0 puntos

Se hacen iteraciones de más de 6 semanas: 1 punto

Se hacen iteraciones de longitud variable y de menos de 6 semanas: 2 puntos

Se hacen iteraciones de 6 semanas: 3 puntos

Se hacen iteraciones de 5 semanas: 4 puntos

Se hacen iteraciones de 4 semanas o menos: 10 puntos.

Categoría pruebas

No se hacen pruebas: 0 puntos

Se hacen pruebas unitarias: 1 punto

Se hacen pruebas funcionales: 5 puntos

Se hacen pruebas funcionales inmediatas: 7 puntos

Se lleva a cabo un proceso de verificación: 8 puntos

Se hacen procesos de "deploy": 10 puntos

Categoría especificación de requisitos

No se hace nada: 0 puntos

Se emplean documentos formales de requisitos

Se usan historias de usuario deficientes: 4 puntos

Se trabaja con buenos requisitos (?): 5 puntos

Se usan buenas historias de usuario: 7 puntos

Se emplea una especificación ágil: 8 puntos

Se emplean historias de usuario, y especificaciones ágiles cuando se necesitan (10)

Categoría propietario de producto:

No hay propietario de producto: 0 puntos

El propietario de producto no sabe o no entiende Scrum: 1 punto

El propietario de producto interrumpe al equipo: 2

puntos

El propietario de producto no está integrado con el

equipo: 2 puntos

Procesos 128

Hay propietario de producto con product backlog: 5 puntos

Hay propietario de producto con plan de versiones fechadas según la velocidad del equipo: 8 puntos

El propietario de producto motiva al equipo: 10 puntos

Categoría pila de producto

No hay pila de producto: 0 puntos

Hay varias pilas de producto: 1 punto

Hay una única pila de producto: 3 puntos

Hay una pila de producto priorizada por ROI: 5 puntos

El plan de versiones que tiene el propietario de producto

está basado en la pila de producto

El propietario de producto puede medir el ROI en coste por puntos de historia, o por otra métrica: 10 puntos.

Categoría: estimaciones

La pila de producto no está estimada: 0 puntos.

La estimación no la hace el equipo: 1 punto

La estimación no se hace con planificación de póker: 5

puntos

La estimación se ha hecho el equipo con planificación de poker: 8 puntos.

Se estima con error inferior al 10%: 10 puntos.

Procesos 129

La lista definitiva de modelos y buenas prácticas para proyectos de software

29.10.2008

Escribir "lista definitiva", de "buenas prácticas...", y más, en un blog, puede sonar como los "requisitos definitivos" de un proyecto ágil: ¿Estos son? ¿No van a cambiar? Este artículo es un backlog, o pila, si empleamos en nuestro idioma: una lista en continuo cambio, para ir completando y

mejorando entre todos, vuelta tras vuelta.

CRITERIO DE CLASIFICACIÓN

Prácticas Dicen "CÓMO" hacer las cosas: cómo describir y gestionar los

requisitos (historias de usuario, elementos de backlog...), cómo estimarlos, cómo realizar las reuniones para validar con el cliente, cómo realizar el mantenimiento del código, las pruebas, la integración... Prácticas listadas:

Ágiles: eXtreme Programming, Scrum, FDD, CDT, EVO, TDD Predictivas: ITIL

Procesos 130

Modelos No definen "CÓMO" hacer las cosas, sino "QUÉ" cosas se deben hacer para conseguir los mejores resultados: se debe hacer gestión de la configuración, gestión de proyecto, medición y análisis, desarrollo de requisitos, validación, etc. Unos se centran en un área de conocimiento (generalmente

gestión de proyecto). Modelos centrados en un área (gestión de proyecto) Ágiles: Crystal, DSDM, Lean, Unified Process (RUP, Open UP, OUM, AUP, EssUP), MSF Predictivos: PMBOK, PRINCE2

Y otros abarcan todas las áreas de la organización implicadas en el desarrollo de software Los modelos más conocidos son CMMI ISO 15504. Tienen dos finalidades:

1.- Para mejorar: Como guión en los procesos de mejora, que

indica cuáles son las áreas que se deben ir abordando. 2.- Para evaluar: Como criterio para medir a una organización cómo de bien lo hace, según cuántas de las cosas que dice el modelo, está cubriendo adecuadamente. Relación de modelos con carácter glogal:

Basados en procesos: CMMI, ISO 15504 Ágiles: Scrum Manager (aparte de ser el único, es el que mejor conozco :-) y, of course... en fase inicial de desarrollo

Procesos 131

Para situar en un escenario las prácticas y modelos, empleo el mismo criterio que en el proyecto ScrmManager: Hay prácticas

orientadas a la gestión del proyecto, otras al desarrollo de la solución técnica y aunque muy pocas (o ninguna), también las debería haber preocupadas por la gestión de la empresa, porque las tres son necesarias para obtener el mejor resultado de un modelo, tanto sea de perfil ágil, o de procesos.

Procesos 132

CRITERIO DE CLASIFICACIÓN Agile Unified Process (AUP)

Es otra versión simplificada y ágil de RUP, desarrollada por Scott W. Ambler: aplica las siete disciplinas de RUP (modelado, implementación, prueba, desarrollo, gestión de la configuración, gestión de proyecto y entorno), pero dentro de ejecuciones iterativas, y sobre una base de cultura de desarrollo ágil.

Enlaces:

Página del modelo: http://www.ambysoft.com/unifiedprocess/agileUP.html CDT Context Driven Testing define un contexto de desarrollo y depuración de programas basado en las pruebas, que el equipo

determina analizando el entorno del cliente, y determinando cuáles son las funcionalidades que éste necesita para su negocio, basándose en el principio de que un programa puede ser una solución válida en un entorno cliente, pero no en otro.

Enlaces:

Libro de los autores del patrón: "Lessons Learned in Software Testing " (Kaner, Bach, & Pettichord, 2001) Página del modelo: http://www.context-driven-testing.com/ CMMI

El Departamento de Defensa Americano, a través de su fundación SEI (Software Engineering Institute), ha desarrollado una línea de trabajo para mejorar y medir el grado de fiabilidad

de una organización que desarrolla software, basada en el concepto de "madurez". Por madurez se entiende la capacidad que tiene la organización

para asegurar la calidad de sus proyectos de forma continua y homogénea; así como la capacidad de aprendizaje de su propia experiencia y aplicación en un proceso de mejora continua. En 1990 SEI publicó el modelo de madurez de la capacidad para el desarrollo de software (CMM-SW), que tras casi dos décadas

de existencia ha demostrado su eficacia en algunas organizaciones.

Procesos 133

Este modelo crea una escala de cinco niveles para determinar la madurez de una organización. En 2000 el modelo SW-CMM se actualizó en otro que facilitaba su implantación de forma conjunta y simultánea con otros modelos:

fue el modelo CMMI (Capability Maturity Model Integration) En la actualidad hay varios modelos CMMI, en función de las áreas que integran: CMMI-SE/SW/IPPD/SS (Systems Engineering, Software, Engineering, Integrated Product and Process Development, Supplier Sourcing). CMMI-SE/SW/IPPD

(Systems Engineering Software Engineering, Integrated Product

and Process Development). CMMI-SE/SE (Systems Engineering, Software Engineering). Enlaces: Página del modelo en SEI http://www.sei.cmu.edu/cmmi/

Artículo en Navegápolis http://www.navegapolis.net/content/view/330/60/

Crystal La familia de metodologías Crystal ofrece diferentes métodos

para seleccionar las prácticas más apropiadas para cada proyecto, en función de su tamaño y criticidad; de forma que los de mayor tamaño, o aquellos en los que la presencia de errores implique consecuencias de mayor gravedad, deben adoptar mayor "peso" de procesos en su gestión. Enlaces:

Sitio de Alistair Cockburn , desarrollador del modelo. http://alistair.cockburn.us/

Libro Crystal Clear , de Alistair Cookburn (Cockburn, 2004)

DSDM Es la más veterana de las metodologías ágiles, y la más próxima a los métodos formales; de hecho, la implantación de un modelo DSDM en una organización, la lleva a alcanzar lo que en CMM (modelo no ágil) sería un nivel 2 de madurez. Surgió en 1994 de los trabajos de Jennifer Stapleton, la actual directora del DSDM Consortium.

Procesos 134

Su desarrollo se inspira en los principios RAD (Rapid Application Development), y le reprocha a CMM: - Aunque es cierto que CMM ayuda al éxito a algunas organizaciones, lo que funciona bien en un entorno, no tiene por que servir para todos.

- CMM no le da al diseño la importancia que debería tener. - CMM plantea un foco excesivo en los procesos, olvidando la importancia que en nuestra industria tienen las personas. - Tener procesos claramente definidos no es sinónimo de tener buenos procesos.

En común con los métodos ágiles, DSDM considera

imprescindible la implicación y relación estrecha con el cliente durante el desarrollo, así como la necesidad de trabajar con métodos de desarrollo incrementar y entregas evolutivas. Enlaces: DSDM Consortium

http://www.dsdm.org/ Artículo en Navegápolis http://www.navegapolis.net/content/view/361/59/

Enterprise Unified Process

Es una extensión de RUP diseñada por Scott W. Ambler, que incluye dos fases adicionales: producción y retirada del sistema, y nueve disciplinas: operaciones, soporte, modelado de negocio, gestión de portfolio, arquitectura de empresa, reutilización, gestión de personas, administración de la empresa, y mejora del proceso de software. Página del modelo:

http://www.enterpriseunifiedprocess.com/

EssUP Essential Unified Process es un modelo diseñado por Ivar Hjalmar Jacobson, co-autor de lenguaje de modelado UML y de

RUP (Rational Unified Process). Vió la luz en Noviembre de 2005, y según su autor se trata de una orientación super ligera y ágil de RUP.

Procesos 135

Evo Evolutionary Project Management es un modelo de gestión de proyectos ágil diseñado por Tom Gilb y Kai Gilb, que divide los proyectos en ciclos independientes y evolutivos; y sin llegar a la

rigidez de la gestión predictiva, acuerda los requisitos con el ciente con mayor rigidez que otros modelos ágiles, para conseguir de esta forma cuantificar el valor que representan para el cliente y decidir la mejor estrategia de solución sobre tablas de estimación de impacto. Enlaces:

Página de los autores

http://www.gilb.com/ Libro del modelo: Evolutionary Project Management & Product Development. (Gilb, 2007)

Extreme Programming Es el conjunto de prácticas ágiles para el desarrollo de la solución técnica que más popularidad ha alcanzado entre las metodologías ágiles. Su creador Ken Beck fue el alma mater del

Manifiesto Ágil. Extreme Programming (XP) se irgue sobre la suposición de que es posible desarrollar software de gran calidad, a pesar, o incluso

como consecuencia del cambio continuo. Su principal asunción es que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde, o construir partes que nunca se utilizarán.

Cuatro son los valores que lo inspiran: simplicidad, feedback, coraje y comunicación.

XP es un conjunto de 12 prácticas que se complementan unas a otras: De codificación: Simplicidad de código - Reingeniería continua - Estándares de codificación - Vocabulario común.

De desarrollo: Desrrollo basado en pruebas - Programación por parejas - Propiedad colectiva del código - Integración continua De negocio: Implicación del cliente - Juego de planificación - Entregas regulares - Ritmo de trabajo sostenible. Enlaces:

Procesos 136

El "libro blanco" de XP: Extreme Programming explained Embrace Change (Beck K. , 2000) Lista de correo de Yahoo http://tech.groups.yahoo.com/group/extremeprogramming/

FDD Desarrollo basado en funcionalidades (Feature Driven Development) es nombre de otro conjunto de prácticas ágiles para desarrollo iterativo e incremental que no hace tanto

hincapié en la fase de requisitos, como en las de diseño y

construcción. Diseñado inicialmente en 1997 por Jeff De Luca, partiendo de las prácticas que él mismo empleaba en su trabajo en un proyecto para un banco de Singapur. Enlaces:

Sitio de la consultora de Jeff De Luca http://www.nebulon.com/ Sitio de la comunidad FDD :

http://www.featuredrivendevelopment.com/

ISO15504 En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo para el desarrollo de un modelo que fuera la base de un futuro estándar internacional para la evaluación de los procesos del ciclo de vida del software. Este trabajo recibió el nombre de proyecto SPICE (Software Process Improvement and Capability dEtermination) y en junio de 1995 publicó su primer

borrador. En 1998, pasada la fase de proyecto, pasó a la fase de informe

técnico con la denominación ISO/IEC TR 15504, y en la actualidad es ya un estándar ISO. Aunque ISO comenzó, con el proyecto SPICE algo más tarde que SEI con CMM, durante su evolución han ido convergiendo, y

ambas instituciones vienen trabajando de forma continua desde 1998 para lograr la compatibilidad que en la actualidad ya está acordada, entre ambos modelos (CMMI e ISO 15504) ISO/IEC 15504, al igual que CMMI, es un modelo para evaluar los procesos de una organización y determinar si resultan efectivos para conseguir los objetivos. También es un modelo

para guiar las acciones de mejora de dichos procesos.

Procesos 137

ITIL La Biblioteca de Infraestructura de Tecnologías de Informción (Information Technology Infraestructure Library - ITIL) comprende documentación con las mejores prácticas para administrar y entregar servicios de tecnologías de la información.

La primera versión fué desarrollada y publicada en 1980 por la Central Computer and Telecommunications Agency (CCTA), como un conjunto de manuales, especializado cada uno en un área de la gestión de tecnologías de la información. En la actualidad es marca registrada de la OGC británica (Office of Government Commerce)

Página oficial

http://www.itil.co.uk/ Lean Software Development Metodología ágil centrada en la gestión y seguimiento ágil de proyectos que adapta al desarrollo de software los principios

"fabricación lean" (lean manufacturing), basada en el sistema japonés del fabricante de automóviles Toyota. Para saber más:

Sitio de Mary y Tom Poppendieck , principales desarrolladores y difusores del modelo. http://www.poppendieck.com/

Libros: Lean Software Development An Agile Toolkit (Poppendieck, 2003) Implementing Lean Software Development (Poppendieck, Poppendieck, & Poppendieck, 2006)

MSF MSF es la metodología empleada por Microsoft para el desarrollo de software. Hasta su versión 3 (principios de 2005), se definía como un

marco flexible para adaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodología prescriptiva, porque parte de la base de que no hay una estructura óptima para las necesidades de todos los entornos de desarrollo posibles. Los principios fundamentales del marco MSF son: Comunicación abierta - Trabajo en torno a la visión compartida

del sistema - Autonomía del equipo - Responsabilidades claras y

Procesos 138

compartidas - El objetivo es la entrega de valor para el negocio - Esperar el cambio - Invertir en calidad - Aprender de la experiencia. MSF aplica estos principios en los procesos y en las personas,

desarrollando un modelo de equipo y un modelo de procesos, que cubren tres disciplinas: gestión de proyecto, gestión de riesgos y gestión de la mejora del talento. El marco incluye: conceptos clave, prácticas contrastadas y recomendaciones.

En 2005, el desarrollo del nuevo producto de Microsoft "Visual Studio Team System" generó la evolución de MSF hacia la versión 4.0, con dos líneas paralelas: MSF for Agile Software Development y MSF for CMMI. Para sabe más: Página MSF de Microsoft

http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx

OpenUP El proceso de gestión OpenUP (Open Unified Process) es una parte del marco de desarrollo Eclipse (open source, y

desarrollado por la fundación Eclipse). Mantiene las característcas esenciales de RUP (Rational Unified Process), y las características de la gestión ágil: desarrollo iterativo e incremental. Enlaces: OpenUP en eclipse.org

http://epf.eclipse.org/wikis/openup/index.htm

PMBOK Project Management Body of Knowledge es un modelo de gestión de proyectos, desarrollado por el Project Management Institute (PMI) en 1987 para documentar información y prácticas para la

gestión de proyectos. PMBOK identifica 5 procesos básicos y 9 áreas de conocimiento comunes a todos los proyectos. Desarrolla un modelo de gestión de proyectos predictivo, y ha tomado el rango de estándar: IEEE Std 1490-2003 Enlaces:

PMI

Procesos 139

http://www.pmi.org/ PRINCE y PRINCE2 PRojects IN Controlled Environments (PRINCE) es un modelo de

gestión de proyectos desarrollado en 1989 por la Central Computer and Telecommunications Agency (CCTA) como estándar para la gestión de proyectos de tecnologías de la información. PRINCE2 fue el resultado de la revisión realizada en 1996 sobre PRINCE, que pasa a ser un desarrollo de la Office Government

Commerce (OGC), dependiente de la administración británica, y

amplía su ámbito para proyectos de cualquier tipo, más allá de las tecnologías de la información Desarrolla un modelo de gestión de proyectos predictivo, adaptable a las características del proyecto en cuanto al conjunto de prácticas que deben contemplarse.

Prince 2 http://www.ogc.gov.uk/methods_prince_2.asp

Scrum Metodología ágil centrada en la gestión y seguimiento ágil de proyectos, a través de ciclos cortos de desarrollo. Es uma

implementación realizada por Ken Schwaber, Mike Beedle y Jeff Shuterland de los principios empleados por los equipos de trabajo "Scrum" definidos por Nonaka y Takeuchi en 1986 (Ikujiro & Takeuchi, 1986) Los principios de Scrum son: equipos auto-gestionados - Un avez

dimensionadas las tareas no es posible agregar trabajo extra - reuniones de seguimiento diarias - ciclos de desarrollo de

frecuencia inferior a un mes (propuesta original dos meses), que entregan una parte del producto completamente terminada. Enlaces:

Libro: Agile Project Management with Scrum (Schwaber & Beedle, Agile Software Development with Scrum, 2001) (Schwaber, Agile project management with Scrum, 2004) Scrum alliance http://www.scrumalliance.org/

Flexibilidad con Scrum

Procesos 140

Scrum Manager Es unodelo de evaluación y mejora desarrollado de forma abierta y libre por la comunidad profesional de gestores e ingenieros de software.

Enlaces: Página del modelo http://www.scrummanager.net/

Wiki

http://www.scrummanager.net/wiki TDD Desarrollo guiado por pruebas (Test-driven developmetn - TDD) es una técnica de programación definica por Kent Beck cuyas

prácticas comienzan por elaborar primero el código que probará una funcionalidad, antes de programar la funcionalildad, y a continuación desarrollar y refactorizar el código hasta que se pasan satisfactoriamente. Estas prácticas eliminan los aspectos

negativos que implican las pruebas en los procesos secuenciales de programación.

Unified Process Marco de desarrollo ágil, iterativo e incremental, que solapa las tres fases de desarrollo (elaboración, construcción y transición) en iteraciones breves de tiempo cerrado. En determinados proyectos también puede solaparse la fase previa de inicio.

Unified Software Development Process, comprende la definición general de este tipo de ciclo ágil: iterativo e incremental, pero no

la concreción en procedimientos o prácticas determinadas, y son varios los autores y organizaciones que han desarrollado variaciones y concreciones sobre este patrón UP genérico:

- RUP - Rational Unified Process, por IBM / Rational. - OpenUP Open Unified Process, por Eclipse como evolución del previo Basic Unified Process (BUP) - OUM Oracle Unified Method - AUP Agile Unified Process, por Scott W. Ambler - EssUP Essential Unified Process, por Ivar Jacobson

Procesos 141

Café o tila ¿Por qué no los dos a la vez?

17.11.2008

Los empresarios del café y de la tila han descubierto la solución

perfecta: que tomemos café y tila a la vez... algo que sin duda tiene que ser bueno tanto para somnolientos, como para

insomnes, e incluso para los que puedan andar por ahí despistados, tomando otras cosas. Estoy convencido de que no es posible aplicar en un proyecto: gestión ágil, con CMMI; y sobre todo de que cuando se mezclan ambos, las razones no son técnicas, sino "administrativo-

consultoriales", que anteponen cuestiones de marketing, a criterios sobre el tipo de gestión se necesita, y los resultados que se desean obtener.

También creo que estar convencido, nada tiene que ver con estar en lo cierto, por mucho que al convicto se lo pueda parecer: que tan segura como para el ateo es su razón, lo es para el creyente

su fé; y por eso quiero estar abierto, con los menores prejuicios posibles, a todas las opiniones y cuestionar si no estaré confundido; que todos los razonamientos honestos enriquecen, pero siempre que sean honestos, y no tretas burlonas, que lo único que prueban sin ninguna duda, es la doblez de los autores y sus razones.

Falsear la historia, y fabularla a la medida del razonamiento que

se quiere sostener, descalifica, a quien lo hace, y por eso me quedo a cuadros al leer en el informe panfleto de SEI "CMMI or Agile, Why not Embrace Both!: (Glazer, Dalton, Anderson, Konrad, & Shrum, 2008)

Que esto de las metodologías ágiles tiene muy poco de vanguardista. Que en realidad, y aunque no lo supiéramos ninguno (mas que ellos), la agilidad, que ahora hace furor es un viejo modelo de ingeniería más viejo que la tos, con nada menos que 75 años (8 años antes de que se construyera el Eniac!!!) y que se llama IIDD (Iterative and Incremental Design and Development). Que el Ministerio de Defensa Americano DoD

Procesos 142

(Patrón de SEI), estaba ya cansado de usarlo en los 50, y que para complementarlo y evitar las áreas de fallos que tiene, se desarrolló precisamente el CMM y luego el CMMI. "This cornerstone is iterative and incremental design and

development (IIDD), a method adopted by engineers over 75 years ago. Early adopters of IIDD included Department of Defense (DoD) engineers who engaged in propulsion- related research and development, which included engineering activities tied to hardware not software... ...proliferated with names such as Scrum, Crystal, FDD, and

others. With the proliferation of IIDD methods..."

¡Alucinante!, y al mismo tiempo curioso. Porque se trata de un organismo tan reputado como SEI, que si no uno pensaría que este IIDD Iterative and Incremental Design and Development, tan misterioso como supuestamente antiguo, es una mentira que se sacan de la manga, porque ni Google ha leído una sóla página

en la que se le mencione (Supongo que enseguida tendrá al menos dos: la de su panfleto técnico, y ésta) Viendo que SEI recurre a la estrategia infantil de inventar lo que

sea para "vender" la excelencia de su modelo, en lugar de convencerme de ella, me refuerza más la sospecha de que su objetivo cada vez es menos la mejora del negocio de las

empresas de software, y más la del suyo propio de consultoría, aunque sea a pesar de las primeras. Todo el rigor del informe panfleto, cuyo título podría despertar la ilusión de algún argumento interesante, se reduce a: Repetir que no se debe ver a CMMI y a la Agilidad como agua y

aceite. Que este es un error que se ha venido cometiendo por dificultades en la terminología, porque la revisión 2 de CMM, que

se publicó en 1997 no la revisó nadie, y luego fue una de las bases de CMMI, y por malentendidos... vamos, de hecho DoD usa agilidad desde 1950 (IIDD), y en los 90 empezó a desarrollar CMM y luego CMMI para complementarla.

Creo que, como el mismo informe afirma, hasta hace poco, los agilistas hablaban y conocían CMMI, pero los practicantes de CMMI no sabían de la agilidad, pero esto está cambiando.... y esto precisamente les puede hacer perder (les está haciendo perder parroquia), y la solución que adoptan es dejar bien claro que: ¡Oigan no se vayan, que en realidad lo bueno bueno,

Procesos 143

bueno, buenísimo, mejor que aplicar sólo CMMI o sólo Agilidad, es aplicar los dos a la vez. ¡Toma ya!

Procesos 145

Proyectos

Desarrollo de proyectos 147

¿Cómo se estima el precio de los proyectos de software?

06.03.2005

Los proyectos con estimaciones limitadas terminan con

desbordamiento de horas y costes, calidad deficiente y clientes satisfechos.

¿Cómo estiman las organizaciones de software el precio al cerrar los presupuestos con sus clientes? Los métodos empleados en muchas compañías de software son:

Averiguar cuál es el precio máximo que está dispuesto a pagar el cliente, o el presupuesto del que puede

disponer, y emplearlos como base para calcular el

importe del proyecto.

Conocer las ofertas de la competencia para basar el precio en ese rango.

Conjeturas, presentimientos, intuición... Si el proyecto es grande, se cuenta con los presentimientos de varias personas y se calcula una media.

Basar el precio en el importe que se necesita vender

para cerrar las previsiones trimestrales de la compañía.

Para los proyectos que no interesan a la empresa se

ofrecen precios desorbitados.

Desarrollo de proyectos 148

El software es así

Michel A. Cusumano comienza su último libro (The Business of

Software) reflexionando sobre las peculiaridades del negocio del software. Es un negocio diferente a todos los hasta ahora conocidos, de productos o servicios; y trasplantar técnicas de gestión "prêt à

porter" puede resultar peligroso.

¿En cuántos negocios tiene un coste similar la producción de una unidad que la de un millón? ¿Cuántos negocios tienen un 99% de margen de beneficio en la venta de sus productos? ¿En cuántos negocios las empresas que desarrollan productos

terminan incluyendo prestación de servicios, tanto si les gusta como si no? (proporcionando cierta configuración del producto, y

servicios técnicos como integración del sistema y mantenimiento). ¿En cuántos negocios los mejores empleados son diez o veinte veces más productivos que los peores?

¿Cuántos negocios toleran como habitual que el 75 o el 80% de los proyectos de desarrollo de productos terminen tarde o desbordando el presupuesto? ¿En cuántas empresas, quienes desarrollan los productos se

auto-consideran artistas, y no científicos o ingenieros, y

presentan temperamentos difíciles e inestables? ¿En cuántos negocios los clientes terminan siendo cautivos de un determinado proveedor a raíz de las decisiones que alguien tomó diez años antes y que no se pueden eliminar fácilmente?

Desarrollo de proyectos 149

Preguntas sobre el diseño

23.05.2005

Un ingeniero puede concebir el diseño de un sistema, de un componente o de una clase sentado en un sofá mirando al techo, o analizando y descomponiendo el problema con la ayuda de diagramas UML o tarjetas CRC.

Hay quien emplea herramientas CAD y quien trabaja con libreta y papel.

La documentación del diseño, o los diagramas que lo representan, NO SON EL DISEÑO. Son herramientas que pueden resultar útiles para concebirlo y para comunicarlo. El diseño es una actividad intelectual. No se produce a través de procesos que emplean diagramas UML o programas de representación. El diseño lo produce el talento

de su creador o de sus creadores.

Por esta razón, los modelos de calidad que cubren procesos de diseño, pueden garantizar que éste se documenta de determinada manera, que se comunica a las personas implicadas, que se mantiene actualizado durante el ciclo de vida

del sistema, y que se verifica la adecuación del código al diseño. Pero no pueden garantizar que éste sea bueno. Al desarrollar software no hay que perder nunca de vista que el fin último es aportar soluciones a las necesidades o limitaciones de un sistema. Y como los problemas nunca tienen una única solución, dar con la más conveniente es la finalidad del buen

diseño. El diseño es la estrategia de la solución, y la codificación la táctica. Por eso, dar respuesta a la pregunta de cómo identificar un mal diseño, que apunta un comentario del artículo Comprobación de

la arquitectura no es fácil. Afirmaciones como la que en alguna ocasión he oido, del tipo "Ha realizado un análisis magnífico: más de 500 folios", son resultado de confundir los medios por el fin.

Desarrollo de proyectos 150

Sin duda un trabajo extenso puede calificarse de magnífico, pero sólo por lo de "magno". Es posible que además sea una documentación rigurosa, y fiel en su organización y contenidos a normas y estándares. Pero ¿la estrategia de solución que propone es la más adecuada?

Al ser el diseño un plan de solución, sin realidad física, y el resultado del talento de su creador, no resulta posible establecer unas pautas absolutas que a modo de lista de comprobación permitan evaluar y "poner nota" a la calidad de un diseño. En este aspecto, el criterio definitivo para determinarla es

observando el comportamiento de la solución.

Evaluar el diseño del sistema estudiando su funcionamiento, es un método de análisis dinámico cuya práctica analiza con dos casos de estudio el trabajo comentado en el artículo anterior2. De todas formas, aunque no resulta posible determinar criterios

objetivos, que con rigor científico puedan evaluar a través del análisis estático de la documentación del diseño y del código producido la calidad de la arquitectura, sí que la experiencia y el sentido común pueden establecer criterios útiles a modo de

"alertas" para identificar las probabilidades y los riesgos de encontrarnos ante un mal diseño; y por su puesto para poder "calar" con un primer vistazo errores de bulto.

El análisis estático y predictivo de la solvencia de un diseño es más una cuestión más de intuición y de juicio experto, y en esta línea es recomendable la comparación con el "olfato" que hace Robert C. Martin en su libro Agile Software Development, al definir 7 características para identificar lo que él denomina "software podrido":

1.- Rigidez.

Dificultad para modificar el software. Incluso con cambios pequeños. Un diseño es rígido si un cambio simple genera una cascada de modificaciones sucesivas en módulos dependientes. Cuantos más módulos deben cambiarse, más rígido resulta el

diseño. 2.- Fragilidad Tendencia del sistema a romperse en sitios diferentes al implementar un cambio. A menudo los nuevos problemas surgen en áreas que no tienen una relación conceptual con la que se ha

2 http://www.navegapolis.net – comprobación de la arquitectura-

Desarrollo de proyectos 151

cambiado; y al solucionarlos se generan otros nuevos, haciendo que el equipo de programación termine por parecerse a un perro que persigue su propia cola. 3.- Inmovilidad

Un diseño es inamovible si contiene partes que aunque podrían resultar útiles en otros sistemas, el coste y los riesgos de su extracción y migración son tan elevados que no compensan. 4.- Viscosidad La viscosidad puede presentarse en el software y en el entorno.

Normalmente una modificación puede implementarse de varias

formas posibles. Algunas preservando el diseño original, y otras no (introduciendo parches). Cuando las formas que mantienen el diseño son más costosas que las que lo degradan, se trata de un diseño "viscoso". Entornos viscosos son los que hacen lento e ineficiente el

desarrollo. Si los cambios requieren largos procesos de re-compilación, o implican horas de comprobación o bloqueo sobre otros ficheros para mantener el control del código fuente, los programadores tenderán a realizar modificaciones que no

requieran tanto trabajo, aunque con ellas no se respete el diseño.

5.- Complejidad innecesaria Un diseño contiene complejidad innecesaria si las soluciones que plantea resultan complicadas o laberínticas. El talento y oficio del diseñador es el factor fundamental para evitarlo, pero en muchas ocasiones la complejidad innecesaria se produce por anticiparse a posibles cambios futuros de requisitos, implementando características en el software que teóricamente las facilitarán.

Desafortunadamente el efecto suele ser el contrario, y el diseño acaba incorporando construcciones que nunca se emplearán y

que puede implicar peso complejidad que harán un software más complejo y difícil de comprender. 6.- Repeticiones innecesarias.

La técnica de "copy-paste" es útil para la edición de textos, pero puede resultar nefasta en la edición de código. Con demasiada frecuencia los sistemas de software se construyen repitiendo docenas o cientos de veces fragmentos de código idénticos. 7.- Opacidad O grado de incomprensibilidad del código, que puede producirse

ya en la codificación inicial, o a través de la evolución a través de

Desarrollo de proyectos 152

las sucesivas modificaciones. Para evitarla, los desarrolladores deben ponerse en el papel de un futuro "lector", y las tareas de modificación cubrir la refactorización del código siempre que sea necesario.

Esta lista de posibles "sospechosos" o "culpables" del mal diseño, refleja también la idea que Jack Reeves expuso en 1992 en su artículo What is Software Design?, y que sigue manteniendo en 2005: el diseño es el código. En realidad la idea subyacente a la afirmación de Reeves no es

que el código sea el diseño, sino que es en el código donde éste

queda plasmado y a través del que produce los resultados esperados. Por esta razón para identificar un mal diseño no hay que detener el análisis en su concepción inicial, y es necesario extenderlo hasta el resultado final. Problemas como la opacidad, repeticiones o complejidad innecesaria, viscosidad, etc. pueden

introducirse en las fases de codificación y mantenimiento. A modo de conclusión, para dar respuesta a las preguntas de ¿qué es el diseño?, ¿cómo se evalúa su calidad?, ¿es el código?,

¿son los diagramas?, etc. propongo las siguientes conclusiones:

El diseño es la estrategia de solución.

Las tareas de codificación, integración y mantenimiento del sistema son la táctica.

La estrategia debe ser adecuada a las necesidades de los usuarios (requisitos y atributos de calidad esperados). No surge de procesos, herramientas o lenguajes de modelado. Surge del talento de su creador.

Los procesos, las herramientas y los lenguajes de modelado

pueden resultar útiles como ayuda para descomponer la complejidad, y para comunicar el diseño a los participantes del proyecto. El talento de algunos profesionales les puede permitir manejar niveles de complejidad elevados sin necesitar apoyo de procesos, herramientas o lenguajes de modelado.

A través del código es posible ver el diseño y la arquitectura del sistema.

Desarrollo de proyectos 153

La documentación del código resulta útil para comunicar su diseño a través del espacio en sistemas en los que intervienen

muchos desarrolladores, y del tiempo para facilitar su mantenimiento. Al emplear documentación para la comunicación del diseño es necesario trabajar con procesos suficientes para garantizar su integridad y actualidad a través de los cambios.

El diseño no cumple su finalidad hasta que no queda plasmado en el código.

El resultado del diseño puede fallar tanto errores en su estrategia como por distorsiones introducidas en la codificación, integración y mantenimiento.

Desarrollo de proyectos 154

¿Métodos de desarrollo ágil con contratos de fecha y precio cerrados?

26.07.2005

De momento es una combinación peligrosa. Jamer World, Randy Miller, Andrew Cheeseman y Roy Osherove

la trataron en la mesa redonda "Agile Development" que se celebró el 7 de julio en la Tech-Ed de este año, sin dar con más

solución que el transmitir al cliente las ventajas y razones del desarrollo ágil, para que comprenda que al ser un modelo sin una planificación inicial cerrada, y estar abierto al cambio continuo, no permite cerrar fechas y precios. El mismo Ken Schwaber, en su libro "Agile Project Management

with Scrum", dedica el apéndice D a esta cuestión, en el que afirma "I didn’t know how to use Scrum to address his business. Scrum’s principle is “the art of the possible,” not “you give me

what I paid for, when you said that you’d deliver it." Pero por desgracia los clientes tienen la mala costumbre de querer saber cuándo tendrán programada la solución para su

problema, y cúanto les va a costar; y algunos son tan suspicaces que no se fían si no lo firman en un contrato. ¿Puede una empresa de software comprometerse contrac-tualmente en fechas y costes con sus clientes, y al mismo tiempo emplear un modelo de gestión de proyectos que no se los puede garantizar?

A grandes rasgos las dos líneas generales de gestión de proyectos son: el marco ortodoxo, con CMMI y PMI como máximos exponentes, y el marco ágil, del que scrum posiblemente sea el representante más significativo.

En la primera son aspectos clave:

Obtención y análisis de los requisitos previos a la planificación y estimación del proyecto.

Planificación y estimación objetiva basada en los requisitos.

Desarrollo de proyectos 155

Gestión de requisitos durante todo el ciclo de desarrollo con procesos rigurosos para aceptar los cambios y

modificaciones, evaluando su impacto (que puede conllevar revisiones del contrato) y recabando la conformidad del cliente.

Procesos objetivos de validación y verificación contra

requisitos. Y en el segundo:

Desarrollo iterativo en ciclos breves (sprints).

Apertura al replanteamiento de los requisitos en el inicio

de cada ciclo (backlog).

Incorporación del cliente (product owner) al equipo del proyecto.

La gestión de proyectos ortodoxa sí que está preparada para afrontar los compromisos de fecha y coste, pero pagando el precio de mayor rigidez en los procesos para aceptar cambios. La gestión de proyectos ágil no puede afrontar los mismos compromisos, y por contra resulta muy flexible para incorporar modificaciones de requisitos.

Volviendo a la pregunta de si se pueden emplear modelos ágiles y firmar contratos con fechas y costes cerrados, lo cierto es que sí. De hecho algunas empresas firman fechas sin contar con modelos de gestión de proyectos. Ni ortodoxos, ni ágiles; pero estas aventuras no dejan de ser bastante temerarias.

Las empresas son entornos sistémicos con múltiples relaciones internas, y esta es una de ellas: los modelos de contrato, con los modelos de procesos para el desarrollo.

Los marcos legales que delimitan las modalidades contractuales posibles son diferentes en cada país, pero en cualquier caso, no

está de mas conocer cuáles son las opciones jurídicas, para no mezclar modelos de producción y de contratación incompatibles. La legislación española establece en el artículo 1544 del Código Civil, que en los contratos de "obra o servicios" una de las partes se obliga a ejecutar una obra o a prestar a la otra un servicio por un precio cierto. Lo cierto es que nuestra legislación enturbia un poco el asunto al

definir conjuntamente el arrendamiento de obras y el de servicios sin aportar los criterios para distinguir cuando estamos ante uno u otro, porque sería de gran ayuda poder contar con

Desarrollo de proyectos 156

dos modelos diferentes para diferenciar sin ambages si el objeto es una obra cierta en una fecha cierta, o el realizar trabajo de programación según las indicaciones continuas del cliente. Los criterios que deben emplearse para poder diferenciar en el

contrato cuál es la figura que recoge (si obra o servicio), por ser los que ha manejado nuestra doctrina y jurisprudencia son:

En el contrato de prestación de servicios se debe una

actividad, sin tener directamente en cuenta el resultado del servicio, mientras que en el de ejecución de obra el

objeto de la prestación debida es el resultado final, con independencia del trabajo necesario para lograrlo.

En el contrato de servicios la remuneración acostum-

brada debe ser proporcional al tiempo de duración de los servicios contratados, por contra en el contrato de obra es normal fijar la retribución en proporción al número o medida de la obra.

En el contrato de servicios la prestación de éstos se realiza en situación de dependencia de quien los recibe, en tanto que en el de obra la actividad dirigida a lograr el resultado es realizada por un contratista o empresa

independiente. Algunos fragmentos de sentencias del tribunal supremo que recogen la diferencia entre ambas figuras:

"Como de obra o empresa en cuanto el profesional se obliga a

prestar al comitente, más que una actividad, el resultado de la misma,"

"la jurisprudencia viene manteniendo que nos hallamos en

presencia de un arrendamiento- de obra cuando su objeto viene

constituido por el resultado concreto prometido por el profesional; y no la prestación de unos servicios, además el precio era cierto y determinado"

En consecuencia, un desarrollo guiado con un marco de gestión ágil, puede garantizar al cliente que cada mes se le hará entrega de nuevas funcionalidades operativas, que habrán sido las acordadas en las reuniones de trabajo en las que él participará. El contrato debería ser por tanto un contrato de servicio en el

que nos comprometiéramos a realizar los trabajos que se indiquen en las actas de cada reunión mensual (backlog), y que

Desarrollo de proyectos 157

el cliente adquiere también una obligación de colaboración en el proyecto. Un desarrollo conducido por un modelo de gestión ortodoxo puede cerrar fechas, precios y funcionalidades, pero no debería

hacerse antes de disponer de las funcionalidades del sistema. Para sistemas complejos, una forma de trabajo adecuada consiste en la firma de un contrato previo de consultoría para realizar la obtención y análisis de requisitos, y otro posterior de fecha y precio cerrado, siendo el documento de requisitos parte contractual de la definición de la obra y criterio para validar el

resultado final.

Este tipo de contratos deben fijar también con claridad los procedimientos para introducir modificaciones de requisitos durante el desarrollo, que pueden suponer revisiones del contrato inicial.

Desarrollo de proyectos 158

Necesitaré 3 recursos Java

14.08.2005

A lo peor estoy equivocado, pero no me encaja que un gestor de proyectos tome una lista de requisitos, la descomponga en un

WBS, genere un gráfico de Gantt y tras analizarlo le diga al responsable de personal: "necesitaré 3 recursos java". Primero, un aspecto de forma: ¿Por qué "recursos"? ¿Por qué no tratar a las personas como personas? Programadores, analistas, ingenieros... Si, es posible que sea un poco maniático, pero es que no

comprendo esta suerte de eufemismo. Puedo entender que para evitar posibles connotaciones peyorativas se hable de invidente y no de ciego; pero que se emplee un tropo similar para no llamar

a una persona persona, y preferir "recurso" ¿? Segundo, ¿se puede tratar un proyecto de software, como el de

construcción de un edificio? Una excavadora extrae x m3 de tierra en cada jornada de trabajo, las estadísticas de días de lluvia y de averías de maquinaria son también datos objetivos para una previsión de riesgos. Pero, ¿los modelos formales de gestión de proyectos resultarían válidos si la producción de las excavadoras no fuera

homogénea, y entre ellas hubiera diferencias de "por 10", o

mas? O si la motivación de los palistas, perdón de los "recursos", fuera un factor de primera relevancia en la eficiencia y la calidad del resultado? Hay una gestión de proyectos de corte mecanicista, que mira los proyectos con las gafas de ver tareas, actividades, tiempos que

consumen, recursos necesarios, Gantt, ruta crítica, riesgos, presupuesto, ROI, etc. Es la escuela "formal" que se basa en la premisa de que el conocimiento y las prácticas de gestión para los proyectos son comunes para todas las industrias: farmacéutica, construcción, software... (premisa fundacional de PMI. PMBOK, edición 2000,

Desarrollo de proyectos 159

pág. 167.) Pero también hay modelos ágiles para la gestión de proyectos que no emplean diagramas de Gantt, o en las que el gestor no asume las responsabilidades de gestión y organización de los

"recursos", porque los cambian por equipos de personas auto-gestionados y auto-organizados. ¿Es posible un modelo único de gestión de proyectos? ¿Una talla única para todo?

Desarrollo de proyectos 160

¿Cómo se decide la compra de software?

28.08.2005

Hace algún tiempo, el director general de la filial de un importante grupo empresarial español, acudió a la industria del

software para encargar el desarrollo de un sistema que gestionara la práctica totalidad de los procesos de una nueva

línea de negocio. Esta persona estaba preocupada, porque disponía de un presupuesto cerrado, se encontraba ya en junio y el nuevo sistema debía estar desarrollado y en funcionamiento en enero del año siguiente. Pero afortunadamente... Tuvo suerte. O al menos eso creyó tras

entrevistarse con el representante comercial de una importante empresa de desarrollo de software.

La fortuna había puesto en su camino la solución ideal, y a las personas capaces de realizarla. La empresa de soft, tras escuchar sus necesidades, restricciones de fechas y presupuesto; le sorprendió gratamente con la

solución a su problema: podían desarrollar un programa sin exceder ni el presupuesto, ni las felchas. El presupuesto pareció algo ajustado, pero el proveedor consideró que podía estrechar su margen comercial, porque la relación que iniciaba con tan importante cliente lo compensaría en operaciones posteriores; y en cuanto al cronograma, había

dimensionado un equipo con las personas para llevar a cabo el

plan necesario: En julio se llevaría a cabo el análisis de requisitos. De agosto a noviembre, el desarrollo de la aplicación, y en diciembre la instalación y pruebas del sistema. Aunque el director de la empresa cliente sabía que las agendas

estaban muy ajustadas, en el fondo no le importaba si al final la entrega se demoraba algunas semanas. A poca experiencia que se tenga en el negocio del software, uno se puede imaginar cuál fue el futuro de este proyecto, y de la prometedora relación comercial que iniciaba.

Desarrollo de proyectos 161

Después de un año de retrasos (en enero, pero del año siguiente) el sistema seguía programándose, y sin funcionar. Cliente y proveedor se amenazaban con los tribunales... El director general de la empresa cliente fue cesado por decisión del grupo empresarial matriz. La empresa de software perdió

una importante suma en esta operación, y lo más importante: prestigio y credibilidad profesional. Una cosa que siempre me ha sorprendido de nuestra industria es la ligereza con la que muchos de nuestros clientes llegan a cerrar importantes operaciones comerciales, aunque estoy convencido

de que una parte importante de culpa la tenemos nosotros, al

construir departamentos comerciales “nacidos para vender", no "para solucionar problemas". Los dos párrafos siguientes, extraídos de "La Agenda" de Michel Hammer definen muy bien una situación bastante frecuente de nuestra industria:

"Vender" esos sistemas, implica mucho más que una comida que paga el vendedor al responsable de compras. Es necesario analizar y determinar las necesidades del cliente. Habrá que

diseñar un sistema que cubra esas necesidades, calcular su coste, y evaluar su viabilidad, rentabilidad y coherencia con la estrategia empresarial del fabricante... Tal como lo percibía otro de los departamentos, la sección de ventas "nunca veía un negocio que no le gustase". Por poco claro que estuviese el resultado, o por incierto que fuese el beneficio,

perseguían el posible pedido hasta su más amargo final. Ansiosos por superar a los competidores, los representantes de ventas a menudo ofertaban al cliente un precio, antes de que alguien tuviese la más mínima idea de lo que iba a costar el sistema. (En esta empresa, el lamento común era que lo que se decía en los cinco primeros minutos de la primera visita de venta

comprometía a la empresa durante los tres años siguientes).

Desarrollo de proyectos 162

¿Cómo es la estrella de tu proyecto?

28.12.2005

Ni todos los proyectos, ni todas las organizaciones son iguales, y en algunos casos sienta mejor estar más cerca de la agilidad que de la formalidad de los procesos, y viceversa.

Las preguntas clave son:

¿Cuál es el nivel de inestabilidad de los requisitos?

¿Cambia el 1% cada mes, o el 50%? [...]

¿Cuál es el nivel de criticidad del proyecto? ¿Qué clases

de pérdidas pueden producir los errores en su desarrollo: vidas, bienes materiales o funcionalidad para los usuarios? ¿Se trata del sistema de software para regular el núcleo de una central atómica, o para gestionar una

agenda infantil?

¿Cuál es el tamaño del equipo de desarrollo: 3 ó 300

personas?

¿Cuál el porcentaje de técnicos competentes y expertos frente al de principiantes y menos hábiles?

¿Cuál es la cultura de la organización? ¿Cada uno tiene detalladamente definidas sus tareas y responsabilidades,

lo que tiene y lo que no tiene que hacer?, o por el contrario ¿se trata de una cultura de autonomía y

empowerment sin una delimitación pormenorizada de tareas?

Desarrollo de proyectos 163

Estas son las 5 puntas del gráfico que proponen dos que no necesitan presentación: Barry Boehm y Richard Turner. Si la estrella no te sale muy simétrica, si quizá se trata de

desarrollar el sistema de asistencia al pilotaje de un avión, con un equipo de tres programadores junior.... mira no estés buscando la cuadratura del círculo, y ni los modelos ágiles ni los basados en procesos puedan ser de gran ayuda.

Desarrollo de proyectos 164

PSP (Personal Software Process) o cómo pasarse de rosca midiendo

18.05.2006

¿No estará perdiendo el norte la línea "CMM'ista" en su afán de ver que todo está en los procesos? Estas son algunas de las métricas que PSP define para "ayudar a los ingenieros en su trabajo":

LOC(B) Líneas de código del programa antes de empezar

a modificarlo.

LOC(D) Líneas de código del programa una vez

terminado.

LOC(M)Líneas cambiadas en el programa base.

LOC(A) Líneas añadidas durante la programación del

proyecto (A=T-B+D-R)

LOC(R) Líneas de código desarrolladas para otros

programas que se han incluido sin ninguna modificación.

LOC(N) Líneas de código añadidas o modificadas

(N=A+D)

LOC/Hora Líneas nuevas y modificadas divididas por el número de horas empleadas

Tiempo de interrupción: Tiempo dedicado por el programador a actividades ajenas al proyecto (charlas, teléfono, interrupciones, café...).

Tiempo delta: Tiempo de la jornada de trabajo - Tiempo

de interrupción.

Defectos eliminados / hora

etc, etc, etc. La implantación de PSP ha demostrado incrementos importantes

en el "task time". En el tiempo que los programadores están efectivamente sentados produciendo líneas de código. Consigue por tanto incrementos igualmente importantes de eficiencia; considerando eficiencia como número de líneas de código por unidad de tiempo...

Desarrollo de proyectos 165

Pero una cosa es task time o "body time" y otra "brain time". Las líneas de código se pueden medir, pero no ocurre lo mismo con la capacidad, la creatividad, el talento... Se puede medir o valorar el trabajo de un traductor por el

número de palabras que traduce en una hora... pero no debería ser una métrica válida para determinar el valor de un novelista. Seguramente con ese criterio situaríamos a Corín Tellado por delante de Cela. Un caso práctico

(Basado en un caso real y cotidiano):

Miguel forma parte del equipo de programación de un sistema en entorno Visual Basic .NET. Ha trabajado durante dos días en el desarrollo de una función (ValidDate), de 130 líneas de código, capaz de comprobar la validez de una cadena como fecha. La función contiene dos bugs:

* Considera como fechas válidas las cadenas vacías. * El cálculo de los años bisiestos no es correcto.

¿Cómo analizaría y gestionaría el trabajo de Miguel una empresa que desarrollara software desde la perspectiva de los procesos?

Estas empresas trabajan con la premisa de producción industrial de que el valor del producto es resultado, en su mayor parte, de los procesos que siguen las personas que lo desarrollan. El modelo más destacado sobre esta premisa, para medir y mejorar estos procesos es PSP (Personal Software Process), desarrollado por SEI en el marco de los modelos CMM - CMMI. PSP mira el tiempo, el tamaño del trabajo y el nº de errores.

Estos modelos permiten medir con parámetros objetivos la eficiencia y calidad de las personas y de los equipos.

Para determinar la eficiencia de Miguel, la información objetiva no engaña: 130 líneas de código en x horas. Lo mismo ocurre con la calidad de su trabajo:2 errores en 130 líneas de código.

Con estas informaciones los gestores de la empresa determinan si Miguel es más o menos eficiente que la media, si la calidad de su trabajo está en los parámetros admisibles, etc. Lo que no pueden descubrir con ellos es que Visual Basic incorpora de forma nativa la función IsDate(), y que si Miguel lo hubiera sabido, en lugar de 2 días hubiera tardado 1 minuto en

realizar el mismo trabajo, que además no contendría ningún

Desarrollo de proyectos 166

error. Este es un caso real, casos con el mismo fondo son muy frecuentes, y esconden diferencias de eficiencia y calidad enormes entre las personas, que pasan desapercibidas y

tergiversadas al aplicar métricas que no son apropiadas. Administrando a las personas que desarrollan software con criterios de producción industrial se puede estar en el mercado, conseguir el volumen de trabajo que el marketing y el capital relacional propio sean capaces de lograr, pero el producto será

mediocre. Este modelo de empresa no es capaz de desarrollar

software innovador ni valioso (Procesos: incompatibilides y efectos secundarios pág. 75). De hecho la empresa que desarrolló este proyecto facturaba 250$ por hora de trabajo, por lo que programar esta función mediocre le aportó una facturación de más de 2.000 dólares. No

cabe la menor duda de que este es un modelo de empresa de negocio atractivo, y razón más que suficiente para que se perpetúe.

Desarrollo de proyectos 167

Hay dos formas de viajar

19.06.2006

Vamos de vacaciones 15 días a Túnez. Salimos el sábado. Con el AVE de las 12 vamos a Madrid, y desde allá en avión hasta el aeropuerto de Túnez. Un autocar nos lleva al hotel en Hammamet. El domingo día de playa. El

lunes empezamos una ruta turística por el desierto de 3 días... Forma 2:

Quiero pasar las vacaciones por Italia. La idea es salir en la primera semana de junio y estar entre 15 y 20 días allá. Tengo un presupuesto de 3.500 Euros. Quiero comenzar en Roma, pero luego no sé si ir hacia el norte e intentar abarcar Florencia, Bolonia y Venecia; o hacia el sur para conocer Nápoles y dar una vuelta por Sicilia. Bueno, lo decidiré sobre la marcha.

El primer viajero elabora un plan detallado; cuando todo lo tiene encajado y conoce el coste, la duración, etc... empieza el viaje. Si durante el mismo algo se tuerce, pierde un vuelo... tomará medidas para intentar mantener el plan inicial, y si no es posible

trazará un nuevo plan. El segundo viajero comienza el viaje sin un desarrollo detallado. Tiene una visión general del objetivo. El devenir de los acontecimientos y la información de cada momento irán escribiendo los detalles del viaje.

¿Una es la forma buena y otra la mala?

Desarrollo de proyectos 168

Hay dos formas de gestionar proyectos: una predictiva o clásica y otra adaptativa o ágil. La gestión predictiva parte de un plan detallado. Sabe exactamente qué es lo que va a hacer y conoce fechas y costes.

Durante el desarrollo gestiona riesgos, evalúa el impacto que cada modificación supone sobre el plan inicial, toma decisiones frente a los imprevistos para seguir su cumplimiento; y si no queda más remedio, para replantearlo. La gestión adaptativa parte desde una visión general del objetivo

y va dando pequeños pasos hacia él a través de un ciclo de

construcción incremental, y de forma evolutiva contrasta y va descubriendo el detalle que resulta más adecuado para el producto con los usuarios y demás participantes, que pueden "tocar" o usar las partes construidas. Hay un modelo que quiere conseguir previsibilidad: construir lo

previsto, en el tiempo previsto y con el coste previsto. Hay un modelo que quiere conseguir valor competitivo en entornos rápidos de la economía actual: innovación y agilidad.

Hay gestores que sólo trabajan de forma predictiva por la

creencia fundamentalista de que es "la buena", y descalifican a los enfoques ágiles o adaptativos. Hay gestores que sólo trabajan de forma adaptativa por la creencia fundamentalista de que es "la buena", y descalifican a los enfoques clásicos o predictivos.

El viaje de negocios de un ejecutivo necesita ajuste y previsión de agendas. Se debe gestionar con un patrón predictivo. Un viaje de turismo innovador para descubrir rutas poco

frecuentes, capaz de cambiar rápidamente si empeora el tiempo en la zona, o sacar ventaja de la pérdida de un avion se debe

gestionar con un patrón adaptativo. Si se sabe perfectamente lo que se desea construir, si no se necesita un componente innovador importante, si se trabaja con

estabilidad suficiente en los requisitos y la tecnología; Humphrey tiene razón: "Lo más eficiente es hacerlo bien a la primera". Pero esto no siempre es así.

Desarrollo de proyectos 169

¿Cómo de innovador es el producto que se quiere desarrollar? ¿Dará solución a un entorno muy conocido como un programa de contabilidad, o a un nuevo concepto o servicio del que aún no se sabe muy bien el impacto, uso y utilidades que podrán encontrar los usuarios? ¿Durante los meses de desarrollo será estable la

plataforma de hardware y software empleada? Una vez lanzado el producto, ¿Cuánto tiempo podrá mantenerse sin quedar obsoleto sin necesidad de cambios y nuevas versiones?

Desarrollo de proyectos 170

El escenario TIC necesita otro modelo de gestión de proyectos

20.07.2006

En los años 50, 60 y 70, cuando se desarrollaban las bases de una gestión de proyectos basada en la planificación, los

productos tardaban años en quedar obsoletos. Las empresas los concebían y diseñaban en un entorno relativamente estable, y

luego se dedicaban a producirlos de forma constante durante años, introduciendo quizá algunas variaciones mínimas. Apple ha desarrollado 6 generaciones de su popular iPod, en sólo 6 años.

Los productos hoy están en constante evolución. La presión del mercado y la velocidad de avance del entorno tecnológico obliga a desarrollarlos en el menor tiempo posible, o mejor dicho, a

salir al mercado con un valor mínimo suficiente en el menor tiempo posible, y una vez allí, en un continuo estado beta seguir el desarrollo a lo largo de versiones y aplicaciones, guiando la evolución según se tercie.

En este sector las diferencias de liderazgo entre empresas no radican en la eficiencia y previsibilidad de costes y fechas con la que se gestiona el desarrollo de los nuevos productos, sino en la

capacidad de agilidad y cambio durante el desarrollo; y el verdadero valor competitivo para ocupar puestos de cabeza es el valor y la innovación del producto.

Desarrollo de proyectos 171

¿Requisitos cerrados o evolutivos?

03.10.2006

Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha analizado y especificado pobremente,

decepcionará al usuario y desprestigiará al que lo ha desarrollado

Roger S. Pressman. Ingeniería del Software. Mc Graw Hill 1995.

Parece lógico suponer que antes de empezar a construir algo, lo

mejor es conocer con detalle qué es lo que vamos a hacer. Una constructora, por ejemplo, podría levantar el edificio que espera su cliente, de forma evolutiva e incremental, a través de ciclos sucesivos de: “construcción – validación con el cliente – demolición de lo erróneo”. Pero contar con un proyecto detallado antes de empezar la construcción es un modelo de desarrollo

mucho más adecuado.

En el desarrollo de software, el razonamiento que implica esta comparación es un punto de discordia importante entre defensores de modelos procesos, y de modelos ágiles. Para los modelos de procesos (CMMI, ISO15504...) y para el

marco de gestión de proyectos predictivo (PMI, IPMA...) es obvio y axiomático que:

Para saber el tiempo y el precio que costará el

proyecto, hay que tener una planificación detallada.

Para elaborar un plan detallado hay que saber con precisión, qué es lo que se va a construir.

La gestión de proyectos es la profesión que comprende las áreas de conocimiento necesarias para planificar, gestionar la ejecución del trabajo

planificado, detectar y corregir las desviaciones. Sin embargo para la gestión de proyectos adaptable o ágil, las fases no son fases, sino actividades que se desarrollan durante todo el ciclo de vida, a demanda según las circunstancias. El diseño, por ejemplo no es la fase que se realiza después de los

requisitos. El diseño, como el descubrimiento de los requisitos, o

Desarrollo de proyectos 172

la codificación y pruebas son actividades que se ejecutan según se van necesitando, a lo largo de iteraciones cortas. Los requisitos no se conocen de forma detallada al comenzar. La comunicación con el cliente, el análisis y la interacción con los resultados de cada iteración los irán descubriendo.

Las fechas no son resultado de una planificación, sino restricciones de negocio. La garantía del resultado no se confía a los procesos sino a la excelencia técnica y a la responsabilidad del equipo. La existencia de estos dos enfoques para la gestión de proyectos

ocasiona:

Discusiones de carácter fundamentalista entre defensores de ambos "bandos".

Despistes y desaguisados al aplicarlos en las organizaciones y en los proyectos que por simpatías, corazonadas o asesoramientos poco objetivos adoptan

tal cual modelos poco apropiados. Algunas cuestiones que ayudan a dar una perspectiva objetiva sobre la utilidad, y ámbito de cada marco:

El software no resulta comparable a la materia prima de otras ingenierías. El software no es físico, y los sistemas de soft, a diferencia de los

artefactos físicos son muy maleables. Por eso es tendencioso presuponer una "talla única" de gestión válida para cualquier sistema y establecer un paralelismo transitivo de métodos que por ser apropiados para la construcción de edificios o aviones, también lo son para desarrollar software. A nadie se le ocurre comenzar la construcción de un edificio sin

saber cuál será exactamente el nº de plantas, o la superficie de éstas; o desarrollar una embarcación básica, e ir ampliando y

modificando sus características, a medida que por el uso las van descubriendo los usuarios. Sin embargo con el software esto es posible.

La capacidad de fertilización que sobre el concepto inicial del producto da el ver, tocar y jugar con un prototipo, con un fragmento de la obra, descubre posibilidades valiosas para el producto, que de otra forma difícilmente podrían haber sido incluidas en una descripción inicial. La cuestión es: ¿cómo de caro resulta construir poco a poco, realizando "prototipos" que retro-enriquecen la visión del

producto?

Desarrollo de proyectos 173

Si puedo:

Poner en contacto directo a desarrolladores y usuarios.

Conseguir que formen un equipo excelente y motivado.

Conseguir que toquen, interactúen y vean partes

operativas del producto en fases tempranas, y enriquezcan el concepto y valor del producto.

Entonces puedo lograr productos con mayor innovación y con un valor superior al que el que habría conseguido a través de una

obtención detallada de requisitos inicial y cerrada. "Preferimos el software que funciona a la documentación exhaustiva" (agilemanifesto.org)

La cuestión no es decidir cuál es el mejor modelo para los sistemas de software, sino para "este" sistema de software, con sus características determinadas:

Grado de incertidumbre del escenario tecnológico sobre

el que se desarrolla.

Grado de inestabilidad del entorno de mercado del

cliente.

Nitidez de la visión del producto.

Nivel de valor que por innovación necesita el cliente.

Estructura y factores sociales de las organizaciones

adquirientes y suministradora.

etc.

Si de lo que se trata es del programa para la gestión de un producto bancario, archiconocido, del que se pueden saber extraer y analizar todos sus requisitos al comenzar el proyecto, y para el que el cliente no espera un valor de innovación, sino

eficiencia y predecibilidad de desarrollo; por muy software que

sea, lo más acertado será conducir el proyecto con un modelo de gestión clásico predictivo.

Desarrollo de proyectos 174

¿Cuánto he trabajado?, o¿cuánto me queda?

07.03.2007

Esta es la diferencia en la medición de tiempos entre la gestión de proyectos predictiva y la ágil. Justo ayer Richard, de Medellín,

consultaba una duda frecuente al ver por primera vez la hoja de registro de un sprint: ¿Qué quieren decir las cifras de las horas

trabajadas?. Hoy mismo Jeff Sutherland afirma en su blog que “medir el tiempo trabajado es anti-scrum” . Estamos tan acostumbrados a medir las horas invertidas, que al ver la hoja de scrum creemos que es un registro de tiempo trabajado, cuando en realidad se trata de: tiempo que falta para

terminar.

Un ejemplo es mucho más ilustrativo: La primera tarea de

"Elena" (en la figura): En la reunión diaria del 1 de febrero dice que va a trabajar en esa tarea y que estima que le quedan 40 horas para terminarla. Al día siguiente Elena dice que va a seguir trabajando en esa

tarea y que le quedan 35 (?). ¿Qué pasó? ¿Sólo trabajó ayer 5 horas?. Esa no es la cuestión. Pudo trabajar 5, 8 ó 10. Seguramente surgió algo que no esperaba, y lo que parecía fácil no lo es tanto.

En la tarea de Antonio, el primer día estima que le quedan 30

horas de trabajo, y el segundo sólo 15.

Desarrollo de proyectos 175

La cuestión no es cuánto tiempo trabajó, sino que hoy estima que le quedan 15. Que la tarea en la que está trabajando progresa, y lo hace a un ritmo mayor del previsto ayer.

En el primer caso había una infra-estimación, y en el segundo una sobre-estimación.

El síntoma del problema es un gráfico de avance del ciclo o sprint de desarrollo que se aleja en una u otra dirección de la diagonal

ideal. Al desarrollo ágil no le gusta medir conformidades o magnitudes que no tienen que ver con el avance del proyecto. No le interesa cuánto se ha trabajado, sino cuánto queda. Sé que estoy avanzando si disminuye el nº de horas de trabajo

que me faltan; y no si aumentan las horas que llevo trabajadas. La gestión ágil verifica el avance del proyecto midiendo el tiempo que le queda para terminar, mientras que la gestión tradicional

Desarrollo de proyectos 176

lo hace midiendo el tiempo que ya ha trabajado. La razón es que la gestión tradicional parte de un plan que debe cumplir, y la ágil no.

De todas formas suele pasar lo que me comentaba Marta. Por razones de gestión, medimos lo que nos falta. Por razones administrativas los departamentos financieros de la empresa necesitan métricas del trabajo invertido (sobre todo si el

proyecto en los libros contables representa una inversión). Así que al final medimos ambas cosas :-)

Desarrollo de proyectos 177

Calcular la fecha de fin de proyecto

11.04.2007

Algunos procedimientos para calcular la fecha de llegada a puerto: 1.- Comparar los días transcurridos con los planificados.

(Método del directivo) Si el viaje tiene una duración prevista de 30 días y llevamos 20 de navegación, se puede responder que faltan 10 días.

2.- Comparar las horas de trabajo realizadas con las planificadas. (Método del consultor) No estaría de más comprobar que los motores no están parados, y trabajan al ritmo previsto usando una métrica del tipo: ¿Cuantos litros de combustible habíamos previsto gastar?, ¿Cuántos hemos gastado?

3.- Comparar el trabajo realizado con el planificado. No

cuántas horas se han trabajado sino cuánto se ha producido. (Método del gestor de proyectos clásico) ¿Cuántas millas hemos recorrido desde el puerto de salida? Las dos primeras no parecen muy fiables. La tercera sí que lo es

cuando el plan del viaje conoce con precisión el destino, la ruta y la distancia. 4.- No medir lo que ya se ha hecho, sino lo que falta por hacer. (Método del gestor de proyectos ágil) La gestión ágil no mide ni el trabajo recorrido, ni el esfuerzo realizado, sino la distancia que queda y la velocidad de avance

tomando el sextante a diario para comparar cuánto más cerca que ayer está hoy del destino. Si se puede definir con precisión el producto final, y trazar un plan fiable de ejecución, es más eficiente emplear gestión clásica que gestión ágil. Si no se puede precisar el objetivo ni la ruta, ¿por qué hacer un

plan y medir sobre él? Las métricas de la gestión predictiva no son fiables en la gestión ágil.

Desarrollo de proyectos 178

Los requisitos del sistema y el product backlog

21.05.2007

La ingeniería del software clásica diferencia dos áreas de requisitos: requisitos del sistema, y requisitos del software.

A los primeros los sitúa en el proceso de adquisición, haciendo por tanto al cliente responsable de definir cuál es su problema y

qué funcionalidades tiene que aportar la solución. No importa que sea gestión tradicional o ágil. Esta sigue siendo la responsabilidad del cliente, aunque por supuesto las formas son diferentes.

Los requisitos del sistema suelen especificarse en

documentos formales; y el product backlog, o pila del

producto toma la forma de una lista de historias de

usuario.

Los requisitos del sistema formales se especifican

completamente en el inicio del ciclo de desarrollo, el

product backlog es un documento vivo que se va

Desarrollo de proyectos 179

desarrollando durante todo el ciclo de desarrollo de

forma concurrente con el resto de actividades.

Los requisitos del sistema los desarrolla una persona o

equipo especializado en ingeniería de requisitos a

través del proceso de obtención con el cliente. En

Scrum la visión del cliente es conocida por todo el

equipo y el product backlog se realiza y evoluciona de

forma continua con las aportaciones de todo el

equipo.

Pero la responsabilidad es del cliente, en el caso de scrum

"propietario del producto", que tiene la responsabilidad de

decidir lo que se incluye en la lista, y el orden de prioridad.

El product backlog es la relación de las funcionalidades,

mejoras, tecnología y corrección de errores que deben

incorporarse al producto a través de las sucesivas iteraciones

de desarrollo.

Representa todo aquello que esperan los clientes, usuarios, y

en general todos los interesados en el producto.Todo lo que

suponga un trabajo que debe realizar el equipo tiene que estar

reflejado en el backlog.

Estos son algunos ejemplos de posibles entradas de un

backlog:

Permitir a los usuarios la consulta de las obras publicadas por

un determinado autor.

Reducir el tiempo de instalación del programa.

Mejorar la escalabilidad del sistema.

Permitir la consulta de obra a través de un API web.

A diferencia de un documento de requisitos del sistema, el

product backlog nunca se da por completo; está en continuo

crecimiento y evolución.

Habitualmente se comienza a elaborar con el resultado de una

reunión de "fertilización cruzada" o brainstorming en la que

Desarrollo de proyectos 180

colabora todo el equipo partiendo de la visión del propietario

del producto.

El formato de la visión no es relevante. Según los casos,

puede ser una presentación informal del responsable del

producto, un informe de requisitos del departamento de

marketing, etc.

Sí que es importante sin embargo disponer de una visión real,

comprendida y compartida por todo el equipo.

La pila del producto evolucionará de forma continua mientras

el producto esté en el mercado, para proporcionarle

constantemente el mayor valor posible, y que resulte en todo

momento útil y competitivo.

Lo necesario para comenzar a desarrollar el producto es

disponer de una visión comprendida y conocida por todo el

equipo, y elementos suficientes en la pila del producto para

llevar a cabo el primer sprint.

Formato de la pila del producto

El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. La pila del producto no es un documento

de requisitos, sino una herramienta de referencia para el equipo. El formato debe ser el de una lista que incluya al menos la siguiente información para cada línea:

Identificador único de la tarea.

Descripción de la tarea.

Criterio de validación

Desarrollo de proyectos 181

Campo o sistema de priorización.

Dependiendo del tipo de proyecto y funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:

Observaciones

Estimación

Persona asignada

Nº de Sprint en el que se realiza

Módulo del sistema al que pertenece

Etc.

Scrum no debe tomarse como un protocolo rígido. El formato del product backlog no es cerrado. Los resultados de scrum no dependen de la rigidez en la

aplicación del protocolo, sino de la institucionalización de sus principios y la implementación en un "formato" adecuado a las características de la empresa y del proyecto.

Desarrollo de proyectos 182

Scrum: reunión de planificación del sprint

31.05.2007

Descripción general En esta reunión, tomando como base las prioridades y

necesidades de negocio del cliente, se determinan cuáles y cómo van a ser las funcionalidades que se van a aportar al producto durante el próximo sprint. En realidad esta reunión consiste en dos: En la primera, que puede tener una duración de una a cuatro horas, se decide qué elementos de la pila del producto (product backlog) se van a desarrollar.

En la segunda se desglosan estos elementos para determinar todas las tareas necesarias, se estiman y asignan a las personas del equipo.

La planificación del sprint no debe durar más de un día.

Desarrollo de proyectos 183

Las características de la reunión son:

Pre-condiciones La organización tiene determinados los recursos posibles

para llevar a cabo el sprint.

El propietario del producto tiene preparada la pila del

producto: priorizada y con elementos suficientes para desarrollar el sprint.

Siempre que sea posible el propietario del producto debe

haber trabajado previamente con el equipo. De esta

forma la estimación de cuántos elementos de la pila se pueden desarrollar en el sprint será bastante ajustada.

El equipo tiene un conocimiento de las tecnologías

empleadas, y del negocio del producto suficiente para realizar estimaciones basadas en "juicio de expertos", y para comprender los conceptos del negocio que expone el propietario del producto.

Entradas La pila del producto.

El producto desarrollado hasta la fecha a través de los

sucesivos incrementos (excepto si se trata del primer sprint)

Circunstancias de las condiciones de negocio del cliente y

del escenario tecnológico empleado.

Resultados

Pila del sprint.

Duración del sprint y fecha de la reunión de revisión.

Objetivo del sprint.

Es una reunión conducida por el scrum manager, a la que deben

asistir el propietario del producto y el equipo al completo, y a la que también pueden asistir otros implicados en el proyecto (gallinas).

La reunión comienza con la presentación del propietario del producto del product backlog, en la que expone los resultados que, por orden de prioridad, necesita; especialmente los que prevé que se podrán desarrollar en el siguiente sprint. Si el product backlog ha tenido cambios significativos desde la

anterior reunión; explica también las causas que los han ocasionado.

Desarrollo de proyectos 184

El objetivo es que todo el equipo conozca las razones y los detalles con el nivel necesario para determinar el trabajo necesario y poder estimarlo.

Formato de la reunión Esta reunión marca el inicio de cada sprint. El Scrum Manager es el responsable de su organización y gestión. Duración máxima: un día. Deben asistir: el propietario del producto, el equipo y el scrum

manager.

Pueden asistir: es una reunión abierta a todos los que puedan aportar información útil. Consta de dos partes separadas por una pausa de café o comida, según la duración. Primera parte

Duración de 1 a 4 horas Propietario del producto

Presenta las las funcionalidades de la pila del producto de mayor

prioridad que él desea y estima que es posible realizar en el sprint. La presentación se hace con un nivel de detalle suficiente para transmitir al equipo toda la información necesaria para realizar el trabajo.

El equipo Realiza las preguntas y solicita las aclaraciones necesarias.

Propone sugerencias, modificaciones y soluciones alternativas. Las aportaciones del equipo pueden suponer modificaciones en la pila del producto. De hecho no es que "puedan" es que "deben"

suponerlas. Esta reunión es un punto caliente del protocolo de Scrum para favorecer la fertilización cruzada de ideas en equipo y añadir valor a la visión del producto. Tras reordenar y replantear las funcionalidades de la pila del producto, el equipo define el "objetivo del sprint" o frase que

define de forma sintética cuál es el valor que se le aportará al producto.

Desarrollo de proyectos 185

Exceptuando sprints dedicados exclusivamente a re-factorización o a colecciones de tareas deslavazadas (que deberían ser los menos), la elaboración de este lema de forma conjunta en la reunión es una garantía de que todo el equipo comprende y comparte la finalidad del trabajo; y durante el sprint sirve de

criterio de referencia en las decisiones que auto-gestiona el equipo. Segunda parte En la segunda parte, que puede alargarse hasta el final de la

jornada

El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas, determinando de esta forma los elementos de la pila del producto que se van a desarrollar. En este desglose el equipo tiene en cuenta los elementos de diseño y arquitectura que deberá incorporar el sistema. Los miembros del equipo se auto-asignan las diferentes tareas

teniendo como criterios sus conocimientos, intereses y distribución homogénea del trabajo. Con esta información el equipo elabora el sprint backlog, o pila del sprint.

Esta segunda parte debe considerarse como una "reunión del equipo", en la que deben estar todos sus miembros y ser ellos quienes descomponen el trabajo en tareas, las asignan y

estiman. El papel del propietario del producto en esta parte es atender a dudas y comprobar que el equipo comprende y comparte su objetivo. El scrum manager actúa de conductor o moderador de la

reunión.

Funciones del Scrum Manager El scrum manager es el responsable y garante de: 1.- Se realiza esta reunión antes de cada sprint.

2.- Que antes de la reunión que el propietario del producto disponga de una pila de producto adecuada y suficiente para realizar el sprint. 3.- Que el diálogo principal de la reunión se realice entre el propietario del producto y el equipo. Otros asistentes pueden participar, pero su colaboración no puede implicar toma de

decisiones ni limitar el diálogo principal.

Desarrollo de proyectos 186

4.- Que la reunión sea un trabajo de colaboración activa entre los dos protagonistas: cliente y equipo, y concluyen con un acuerdo sobre el incremento de producto que van a realizar en el sprint. 5.- Que el equipo comprende la visión y necesidades de negocio

del cliente. 6.- Que el equipo ha realizado una descomposición y estimación del trabajo realistas y ha considerado las posibles tareas necesarias de análisis, investigación o apoyo. 7.- Que al final de la reunión están objetivamente determinados:

los elementos de la pila del producto que se van a

ejecutar.

el objetivo del sprint.

La pila de sprint con todas las tareas estimadas y asignadas.

La duración del sprint y la fecha de la reunión de revisión.

El Scrum Manager Modera la reunión para que no dure más de

un día. Debe evitar que el equipo comience a profundizar en trabajos de análisis o arquitectura que son propios del sprint.

Desarrollo de proyectos 187

El “Gantt” ágil

27.09.2007

En la gestión predictiva, la "bola de cristal" con visión global de proyecto es el diagrama de Gantt. ¿Y en la gestión ágil?. El modelo ortodoxo de Scrum trabaja con el Gráfico Burn-Down, pero es una bola de cristal que alumbra con "cortas": sólo al

sprint actual. Para vaticinar el proyecto "con largas", apuntando más lejos en la dirección de la visión del cliente, es muy útil el gráfico Burn-Up.

Es una herramienta de planificación y seguimiento del propietario del producto, que muestra en un gráfico muy simple el plan general de desarrollo del producto, y la traza de su evolución. Se confecciona con:

La estimación de esfuerzo prevista en el product backlog.

La velocidad del equipo.

El eje X representa el tiempo de desarrollo con las fechas de los sprints previstos.En el área del gráfico se proyecta la línea que

representa la velocidad de desarrollo del equipo.

Desarrollo de proyectos 188

Este dato se obtiene sobre el histórico de velocidad desarrollada por el mismo equipo en proyectos o sprints anteriores. Si no se tiene información histórica, un buen dato para comenzar es utilizar “tiempo real” como unidad para el esfuerzo y la

velocidad (horas o días reales) y suponer como velocidad del equipo un tercio del tiempo disponible de trabajo. Ejemplo: Par un equipo de 3 personas y sprints de 20 días laborables, el tiempo disponible es de: 3 * 20 = 60 días disponibles.

Velocidad previsible: 20 (60/3).

La intersección de los hitos en Y del esfuerzo previsto para una versión, con la línea de velocidad prevista, proyecta sobre X la fecha en la que previsiblemente estarán desarrolla la versión. Si las estimaciones se realizan considerando valores optimistas y

pesimistas de velocidad, o de esfuerzo necesario, se obtienen rangos de fechas de probabilidad.

Desarrollo de proyectos 189

Clientes y gestores hablando idiomas diferentes

18.10.2007

El nuevo escenario de negocio de muchos sectores necesita modelos diferentes para desarrollar sus productos.

Las circunstancias de los mercados y de las empresas no se pueden cambiar, y es la gestión de proyectos la que debe

adaptarse y responder a las nuevas necesidades. Las empresas acuden a los expertos en procesos de desarrollo con descripciones abiertas, solicitando adaptación continua y valor, y éstos les piden descripciones cerradas y les ofrecen garantías de cumplimiento de un plan.

Ahora es necesario desarrollar y construir el producto a la par de la investigación y del descubrimiento de los requisitos, y hacerlo

con la capacidad de adaptarse a los cambios dictados por el entorno.

Desarrollo de proyectos 190

El cliente conoce la visión de su producto pero por la novedad, el valor de innovación que necesita y la velocidad a la que se va a mover el escenario tecnológico y de negocio durante el desarrollo no puede detallar cómo será el producto final. ¡Ah!. Pero, ¿existe el producto final?

Quizá ya no hay “productos finales”, sino productos en evolución, revisión mejora o incremento continuo a partir de la versión beta

Desarrollo de proyectos 191

9 Bloques: rutina para obtener requisitos con Scrum

18.12.2007

"La 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 comunicación cliente-equipo de desarrollo. La mejor solución para el tercer punto es resolverlo vía proceso: integrando en el proceso de desarrollo la participación y

comunicación del cliente. Si se trabaja con Scrum, se tiene resuelto, porque el propio modelo implica al cliente en el proyecto como "product owner", responsable de la visión del producto ("product backlog"), y define prácticas para la comunicación con el equipo y la monitorización del proyecto (reuniones de inicio y revisión de

sprint)

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 conocimiento tácito de las personas, que por el explícito del procedimiento de obtención y análisis de requisitos. Si el equipo está formado por el tipo de personas que Keith M. Eades denomina "Águilas", en su libro The New Solution Selling, (Eades, 2003)

Desarrollo de proyectos 192

contará con la suficiente intuición y conocimiento tácito 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.

En el primer es una rutina útil para el responsable del funcionamiento de Scrum, cuando se encuentra con un cliente que tiene dificultades para definir la visión y priorizar un backlog; y en segundo, para el equipo, cuando en una reunión de principio e sprint se topa con algún punto de backlog,

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".

Desarrollo de proyectos 193

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

Desarrollo de proyectos 194

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 pre-concebidas.

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án 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?

Desarrollo de proyectos 195

¿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, 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.

Desarrollo de proyectos 196

Niveles de zoom de los requisitos ágiles

28.01.2008

Al tratar los requisitos en un proyecto ágil, me viene bien

considerar que entre la visión del cliente, y las tareas de trabajo diarias, hay 3 niveles de "zoom"

El nivel es un punto de referencia sobre la forma de gestionar los

requisitos, y las implicaciones o información que pueden suministrar en otros estratos. Niveles “de gestión del equipo” PRODUCTO: Ámbito del sistema: descripción de las áreas o módulos o

funcionalidades. En la ingeniería del software ortodoxa

equivaldría a los requisitos del sistema o ConOps. En un proyecto ágil, este es un "backlog" con la lista de funcionalidades generales del producto. Descritas de forma general, pero con las características de un backlog: priorizadas según los criterios de negocio, y con una estimación previa.

Reflejaría el eje Y del gráfico Burn Up, en el que el cliente proyecta la previsión de desarrollo del producto a través de futuras versiones. VERSIÓN: Próximo objetivo de producto al que apunta. Lo que Scrum estricto considera el "product backlog", aunque desde esta

Desarrollo de proyectos 197

perspectiva de tres niveles de trabajo para requisitos, los podamos considerar "release backlog". Se trata de la lista de funcionalidades con la que trabaja el equipo en las reuniones de inicio de sprint.

SPRINT: El sprint backlog: la lista de tareas que se van a realizar en el sprint, que el equipo ha estimado y asignado, descomponiendo los puntos del "release backlog" que va desarrollar. TAREAS DIARIAS:

Los tareas diarias que el equipo lleva a cabo y auto-gestiona

durante el sprint.

Los cuatro "niveles de gesión de proyecto" se completan con VISIÓN: La descripción general del sitio al que el cliente quiere llegar, de lo que quiere conseguir. Normalmente el autor y responsable de este objetivo final no suele ser el propietario del producto, sino alguna instancia en la

dirección de producto de su empresa.

A partir de esa visión concebida por su organización, la persona que trabajará integrada en el equipo del producto con el rol de "propietario del producto", empieza con la elaboración del plan del producto: product backlog + gráfico Burn Up . Por esta razón, aunque resulta necesaria, su origen y

responsabilidad no suele estar dentro del día a día de la gestión del proyecto.

Desarrollo de proyectos 198

Agilidad Kanban

25.02.2008

Según el producto, o incluso el momento de evolución en el que está, puede resultar más dinamizador para el equipo cambiar como criterio base de "time box" el sprint backlog, por el de

"mínima funcionalidad integrable". Gestionar estas "MFI" al estilo que el modelo de Producción de Toyota consideraría cada unidad Kanban.

Tiene la ventaja de seguir lo más cerca posible las prioridades del cliente. La versión del Just in Time de la programación. También tiene el riesgo de que el equipo pierda la visión general del producto, y el concepto de "objetivo del sprint". Para evitarlo se deben mantener tres niveles de zoom de los requisitos del proyecto (v. pág. 196): funcionalildades de producto, de versión

y tareas; y es muy útil trabajar con pizarras Kanban:

De funcionalidades Representan el trabajo, previsión y estado de las funcionalidades del sistema. Cada tarjeta kanban, o elemento de información representa una funcionalidad general de sistema. La dimensión

horizontal de la pizarra representa el tiempo, de forma que en

Desarrollo de proyectos 199

columnas temporales se van apilando las tarjetas con las funcionalidades que se irán cerrando en cada "versión".

De historias de usuarios Representan el trabajo, previsión y estado de avance de la

versión que se está programando. Una pizarra de historias, descompone en historias de usuario, las funcionalidades de una

columna de la pizarra anterior. Representa por tanto un nivel de detalle mayor sobre los requisitos del sistema. La dimensión horizontal de la pizarra representa las diversas funcionalidades separadas por columnas, y en cada una de ellas las historias de usuario en las que se descompone. De tareas

Representan el trabajo y el estado de avance de la iteración en desarrollo. Las tarjetas Kanban o elementos de información

representan las tareas de programación en que se descomponen las diferentes historias de usuario.Divide el espacio en 3 tres columnas. En la primera de ellas están todas las tareas

pendientes de realizar. La segunda contiene las tarjetas de las tareas que actualemnte se están programando, y en la tercera la de aquellas tareas completamente terminadas. Para no perder en el equipo la visión y los intereses del producto, la que con sprints sería reunión de planificación del sprint es

ahora una reunión periódica (¿mensual?), de características

similares en la que el product owner y el equipo revisan las

Desarrollo de proyectos 200

funcionalidades y su prioridad, y las transforman en historias de usuario y tareas.

Desarrollo de proyectos 201

Midiendo velocidad, trabajo y tiempo en gestión ágil

07.05.2008

Velocidad, trabajo y tiempo son las tres magnitudes que mide la

gestión de proyectos ágil. Las tres componen la fórmula de la velocidad, definiéndola como cantidad de trabajo realizada en

por unidad de tiempo.

Velocidad = Trabajo / Tiempo

Tiempo

En las métricas ágiles el tiempo se puede considerar de dos formas diferentes: como real o como ideal. Ambas son válidas, y cada organización opta por la que

considera más adecuada para ella. Sea cual sea criterio, éste debe mantenerse de forma homogénea en todas las métricas y estimaciones.

Tiempo real Tiempo efectivo de trabajo. Es equivalente a la jornada laboral. Para un equipo de cuatro personas con jornada laboral de ocho horas el tiempo real en una semana (cinco días laborables) es: 4 * 8 * 5 = 160 horas

El tiempo real de ese equipo en un sprint de 12 días de trabajo

es: 4 * 8 * 12 = 384 horas Tiempo ideal

Tiempo de trabajo en “condiciones ideales”, esto es, sin ninguna interrupción, pausa, distracción o atención a tareas ajenas a la tarea del sprint que se tiene asignada. Es el concepto similar al que PSP denomina “Delta Time”.

Desarrollo de proyectos 202

Trabajo Medir el trabajo puede ser necesario por dos razones: para registrar el ya realizado, o para estimar anticipadamente, el que será necesario realizar.En ambos casos se necesita una unidad, y

un criterio de cuantificación objetivo. Trabajo ya realizado Medir el trabajo ya realizado no entraña especial dificultad. Se puede hacer con unidades relativas al producto (p. ej. líneas de código) o a los recursos empleados (coste, tiempo de trabajo…)

Para medirlo basta con contabilizar las unidades que se empleen: líneas de código, horas trabajadas (reales o ideales)...

Medir el trabajo realizado NO es una métrica Ágil.

LA GESTIÓN ÁGIL NO DETERMINA EL GRADO DE AVANCE DEL PROYECTO POR EL TRABAJO YA REALIZADO, SINO

POR EL PENDIENTE DE REALIZAR Es posible que otros procesos de la organización necesiten

registrarlo y medirlo, pero no la gestión ágil de proyectos. Trabajo pendiente de realizar Scrum mide el trabajo pendiente para:

Estimar el esfuerzo y la duración prevista para cada tarea.

Determinar el avance del proyecto, y en especial de cada sprint.

Para Scrum Management, estimar con precisión, de forma

cuantitativa y objetiva el trabajo que necesitará la construcción de un requisito, es un empeño más que cuestionable. El trabajo de un requisito no se puede cuantificar de forma absoluta, porque las funcionalidades no son realidades de solución única.

La “cantidad de trabajo” que consumirá cada funcionalidad o cada historia de usuario no se puede calcular de forma absoluta y objetiva; y en el caso de que se pudiera, la complejidad de la medición haría que la métrica resultante fuera demasiado pesada para la gestión ágil.

Desarrollo de proyectos 203

Y si no resulta posible estimar con precisión la cantidad de trabajo que hay en un requisito, tampoco se puede saber cuánto tiempo costará, porque además de la incertidumbre del trabajo, se suman las inherentes al “tiempo”:

No es realista hablar de de la cantidad o de la calidad del trabajo que realiza una persona al día, o a la hora, porque hay diferencias muy grandes de estos resultados,

según las personas.

Un misma tarea, realizada por las mismas personas

consumirá diferentes tiempos reales en entornos de trabajo diferentes

Sobre estas tres premisas:

No es posible estimar con precisión, ni el trabajo de un

requisito, ni el tiempo necesario para desarrollarlo.

La complejidad de las técnicas de estimación crece exponencialmente en la medida que:

Intentan incrementar la fiabilidad y precisión de los resultados.

Aumenta el tamaño de la tarea estimada. La estrategia empleada por la gestión ágil es:

No empeñarse en estimaciones precisas.

Estimar con la técnica “juicio de expertos”

Descomponer las tareas de los sprints en sub-tareas más

pequeñas, si las estimaciones superan los rangos de las 16-20 horas de de trabajo.

Unidades de trabajo

Las unidades para medir el trabajo pueden estar directamente relacionadas con el producto, como los tradicionales puntos de función de COCOMO, o a través del tiempo necesario para

realizarlo. La gestión ágil suele llamar a las unidades que emplea para medir el trabajo “puntos”, “puntos de funcionalidad” “puntos de historia”… pero se trata siempre de medición a través del tiempo, no del producto.

Así por ejemplo la unidad de medida “Story Point” de Extreme Programming define: la cantidad de trabajo que se realiza en un

día de trabajo ideal.

Desarrollo de proyectos 204

Cada organización, según sus circunstancias y su criterio institucionaliza su métrica de trabajo definiendo el nombre y la definición de las unidades teniendo en cuenta que se basan en el tiempo necesario para ejecutarlo.

Pueden ser: puntos, puntos de función, puntos de historia, días, horas… y referirse a tiempo real o tiempo teórico. Lo importante no es si emplea uno u otro nombre, si se refiere al trabajo realizado en cuatro o en ocho horas, o si éstas son reales

o teóricas.

Lo importante es que la métrica empleada, su significado y la forma de aplicación sea consistente en todas las mediciones, en todos los proyectos de la organización y conocida por todas las personas: Que se trate de un procedimiento de trabajo

institucionalizado. ¿Velocidad, o eficiencia?

Los equipos que miden el trabajo con tiempo ideal, hablan de “Velocidad”.

En los que usan tiempo real se dice que es “eficiencia”. Al decir, por ejemplo, que la velocidad del sprint ha sido de 23, se refieren a que han completado tareas que medían en toral 23 story points.

Si en el sprint siguiente consiguen una velocidad mayor, querrá decir que han logrado programar más story points en el mismo

tiempo, o lo que es lo mismo que han conseguido aumentar el porcentaje de tiempo ideal en la jornada de trabajo: han reducido los tiempos de interrupciones, distracciones o dedicados a otras tareas.

Para los equipos que miden el trabajo con tiempo real, la fórmula de la velocidad, como concepto “velocidad” pierde sentido.

Velocidad = trabajo / tiempo Como el trabajo en tiempo real, numerador y denominador

emplean la misma cifra:

Desarrollo de proyectos 205

Velocidad = Trabajo que se puede realizar en la unidad de

tiempo / tiempo Estos equipos no incrementan la velocidad por dedicar más

tiempo efectivo, puesto que no diferencian entre tiempo ideal y tiempo total. Para incrementar la velocidad, lo que deben hacer es conseguir realizar más trabajo en el mismo tiempo. En realidad es el mismo perro con distinto collar

El objetivo en el primer caso es aumentar el porcentaje de

tiempo ideal, y en el segundo aumentar los story points que se pueden realizar. Se le puede llamar velocidad o eficiencia, lo importante no son los nombres, ni merece la pena entrar en cuestiones bizantinas. Quizá sea más consecuente hablar de “velocidad” su se trabaja con tiempo ideal, y eficiencia si se hace con tiempo real.

Desarrollo de proyectos 206

Los gestores de proyectos ágiles no existen

30.11.2008

Un gestor de proyectos, gestiona proyectos: mide el trabajo, lo

descompone, asigna y planifica tareas, sigue la ejecución...

Un equipo ágil se auto-gestiona: mide el trabajo, lo descompone, se asigna las tareas, monitoriza el avance... Y como una cosa no puede ser ella misma y su contraria, no es posible gestionar el proyecto de un equipo auto-gestionado. En este caso lo que corresponde es gestionar el sistema (eco-

sistema) que hace posible la agilidad: un entorno capaz de obtener el valor del talento, más que el trabajo de los recursos; porque con el software se puede trabajar de forma mecánica o

creativa; que el soft es sólo la materia prima: "las palabras", y con ellas lo mismo construye el mecanógrafo, que crea el novelista o el poeta.

Desarrollo de proyectos 207

Coordinación de varios equipos en un mismo proyecto

07.12.2008

El marco de trabajo ágil óptimo es un equipo único de no más de 6 ó 7 personas. La pérdida de eficiencia por el crecimiento de la

estructura afecta también a un modelo ágil, y toma mayor dimensión si los equipos están físicamente separados.

Teniendo esto en cuenta, si el proyecto lo requiere, es posible emplear equipos de sincronización para coordinar en el mismo a varios equipos. Se debe poner como primer elemento en la pila del producto (backlog), la construcción de la línea base de la arquitectura. Lo

que Andy Hunt en "The Pragmatic Programmer" (Hunt &

Thomas, 1999) denomina como "bala trazadora".

Las mesas de coorinación deben conseguir que las historias de cada equipo tengan la mayor coherencia funcional posible, y a la

vez, la menor dependencia con las de otros equipos.

Desarrollo de proyectos 208

Las mesas de coordinación de primer nivel se reunen diariamente, o día sin otro, después de haber realizado todos los equipos que la forman, la reunión diaria de seguimiento. Las mesas de coordinación de segundo nivel pueden reunirse una o dos veces por semana, en función del nivel de

independencia de las historias de backlog distribuidas.

Recomendaciones:

La mayor prioridad de la pila de producto es construir la

base de arquitectura y alguna funcionalidad que demuestre su funcionamiento.

El desarrollo comienza con un sólo equipo, encargado de

armar la infraestructura y la arquitectura base, que permita trabajar de forma simultánea a varios equipos.

Los miembros de este primer equipo se distribuyen entre

el resto de equipos cuando se van incorporando.

Las historias de la pila de producto se agrupan (normalmente a través de una columna adicional) en

"relatos" (epics), que representen sub-sistemas funcionales completos, de forma que cada grupo tiene la mayor cohesión funcional posible.

Las mesas de coordinación procuran asignar los relatos a

los mismos equipos.

Empresa y mercado 209

Empresa y mercado

Empresa y mercado 210

La incompetencia calificada de los comités

20.01.2005

Los comités de dirección son un buen invento. En ellos se integra a un grupo escogido de managers para lidiar con los problemas

de la organización. Para conducir proyectos interdisciplinares o resolver bretes que implican a diferentes departamentos también los comités resultan una solución muy socorrida, pero... ¿en su organización se dan los dos factores necesarios para que los comités resulten realmente eficientes?

1.- ¿Su empresa está cohesionada o fragmentada? 2.- ¿Su empresa tiene asumida una cultura de aprendizaje? 1.- ¿Su empresa está cohesionada o fragmentada? Frecuentemente los equipos administrativos, simulan respaldar la estrategia común de la organización, para mantener la

apariencia de un equipo cohesionado, cuando en realidad

emplean la dirección de sus estrategias en la defensa de su "territorio", evitando todo aquello que pudiera dañarles. Para mantener esta simulación callan sus desacuerdos y sus reservas. Estos comités terminan emitiendo o bien tibias mezclas aritméticas de intereses, reflejo de lo que es aceptable para todos, o la decisión del miembro predominante del grupo.

2.- ¿Su empresa tiene asumida una cultura de aprendizaje? Este segundo factor es el que Argyris denomina "incompetencia

calificada" en su libro Overcoming Organizational Defenses. Nuestra cultura nos impide reconocer que desconocemos la

respuesta, y son muchas las empresas que refuerzan esta cultura premiando a quienes defienden sus puntos de vista sin entrar en los jardines de cuestionar la complejidad de los problemas. Las empresas premian a los gestores que se afanan en resolver los problemas con urgencia, más que a quienes ejercen de "abogados del diablo", cuestionando problemas en las políticas

de la compañía.

Empresa y mercado 211

Hemos aprendido a defendernos del dolor de manifestar ignorancia o incertidumbre, bloqueando de esta forma la comprensión de lo que nos amenaza.

Y este tipo de equipos son los que Argyris denomina de "incompetencia calificada": equipos de gente increíblemente apta para cerrarse al aprendizaje. ¿Los comités de su empresa están formados por personas defensoras de sus intereses, cerradas al aprendizaje?

Empresa y mercado 212

¿Cuál es la finalidad de las empresas?

31.03.2005

Veo la presentación que el coordinador de un grupo de gestores de proyectos está preparando para exponer a su equipo la necesidad de ser rentables en los proyectos y ganar dinero. La primera diapositiva presenta un rótulo que reza así "¿para

qué existen las empresas? A continuación aparece la respuesta que tantas veces sirve de arranque en estos foros: para ganar dinero. Algo que por evidente parece incuestionable, y que sin embargo es el lema para conseguir profesionales con dislexia funcional;

quizá el error más grave de los malos gestores, que les lleva a confundir la forma por el fondo, el medio por el fin y el efecto por la causa

Para esta diapositiva se me plantean algunas dudas: Si en el mercado hay millones de empresas, la pregunta de cuál

es la razón de su existencia ¿sólo tiene una respuesta? ¿Todos los emprendedores, comparten la misma razón cuando crean una empresa?, y si es así, ¿cómo ha llegado a esa certeza quien lo afirma? Sentar toda una teoría sobre una premisa que no es cierta me recuerda al modo expositivo de las sectas.

Seguro que hay muchas empresas que tienen como finalidad ganar dinero, pero yo prefiero pensar en las que ganar dinero no es una finalidad, sino una consecuencia.

Creo que lo contrario es confundir el fin con los medios, y padecer la dislexia funcional que apuntaba. Hace poco me comentaba el director de negocio de una relevante empresa de software:

"El cliente no sabe lo que quiere. Copia y pega este informe que hice yo hace unos meses para Fulanitez, cambia los datos y ya tenemos facturado el estudio". ?¿?¿?¿?¿? No lo entendía, y sin duda el aludido director comercial no entendería por qué yo no lo entendía.

Uno de los dos tiene dislexia.

Empresa y mercado 213

Si el fin de la empresa es ganar dinero, el disléxico sin duda soy yo. Si el fin de la empresa es dar soluciones a los clientes el disléxico es él.

Vemos cosas diferentes. Se me ocurre comparar la pregunta sobre la existencia de las empresas con otra: ¿Porqué algunas personas quieren ser médicos? Si alguien me planteara esta cuestión, le respondería de igual

forma: son muchos los médicos y seguramente la pregunta no tiene una respuesta única.

Sin duda muchos lo son para ganar dinero, pero a mi me gustan más los que tienen como finalidad curar enfermos. Los primeros tienen que curar pacientes para ganar dinero, los segundos ganan dinero porque curan pacientes. Los primeros centran su atención en figurar en las listas de los

congresos, tener un bonito chalé... al fin y al cabo quieren ganar dinero, y el ser médico es algo accidental, es el medio, no el fin. Los segundos son reclamados por los pacientes, y por los organizadores de los congresos médicos. Para éstos el lucro es la consecuencia de su trabajo, no el fin. Pues bien, yo prefiero a éstos, y los clientes, perdón, los pacientes también.

Mañana, un grupo de gestores de proyectos escucharan cómo su coordinador les trasmite cuál es la verdadera finalidad de sus proyectos: ganar dinero.

Empresa y mercado 214

Problemas divergentes

03.08.2005

A veces no entendemos por qué otras personas tratan algunos problemas de formas tan raras. También es frecuente tropezar con situaciones a las que cuantas más vueltas les damos, más difícil se vuelve su solución. Hace poco descubrí y me paraeció muy interesante la idea que

desarrolla E.F. Schumaker en su libro "A Guide for the Perplexed", en el que afirma que de forma general hay dos tipos de problemas: los convergentes y los divergentes. Son convergentes aquellos que tienen una solución, de forma que cuanto más inteligentes o talentosas sean las propuestas que se hagan, más convergerán entre sí.

Sin embargo para los problemas divergentes no hay una solución "correcta", y cuanto más esfuerzo e inteligencia se dedica a su estudio, surgen más respuestas, incluso contradictorias

El tipo de pruebas empleadas en los test de inteligencia son un ejemplo de problemas convergentes, sin embargo no son

convergentes cuestiones del tipo ¿cuál es la mejor política comercial para el nuevo producto?

Empresa y mercado 215

Gestores “PHB”

13.10.2005

La semana pasada publicaba Ask Metafilter el post de un programador que afirmaba tener un "jefe pelo-pincho". Las tiras cómicas de Dilbert han acuñado el término "pointy-haired boss" (comúnmente PHB) para designar a jefes y directores con las características de este estereotipo de gestor

que con tanto acierto reflejan las historietas de Scott Adams. PHB cuenta con entradas propias en Wikipedia o en Dehumanizer que merece la pena leer. Como se menciona en ellas, una de sus características es no comprender la tecnología de su propio sector, ni el trabajo que realizan sus empleados, así que son un tipo de gestor

relativamente habitual en empresas de las tecnologías de la información. Algunas de los rasgos que emplean en sus definiciones estas

fuentes:

Les encantan las reuniones. No entienden nada de tecnología (o del campo de su trabajo). Les encantan los títulos ("Doctor", "Ingeniero", etc.) los diplomas universitarios... Te respetan si tardas 3 meses en realizar un trabajo, pero no si haces exactamente lo mismo en 5 minutos. Sus decisiones parecen aleatorias o caprichosas

etc, etc..

Empresa y mercado 216

Ética empresarial

25.10.2005

La expresión "ética empresarial" puede parecer un oxímoron, y efectivamente lo es en empresas cuyos accionistas o propietarios imprimen como objetivo la obtención del mayor beneficio en sus operaciones.

Por corrección política ninguna empresa puede afirmar en público su indiferencia sobre la "ética" y la "responsabilidad social"; y muchas, con culturas y actuaciones de dudosa moral se barnizan, justifican o incluso se defienden con ejercicios dialécticos más o menos convincentes.

Puedo estar confundido, pero... la ética de mis comportamientos no la descubriré mirando los beneficios que me producen, sino lo que producen en los demás.

La ética de las empresas, igual que la de las personas no se demuestra con argumentos, sino mirando los beneficios que

producen en los demás. Los empresarios, los accionistas que presuman de éticos no deberían actuar por egoísmo, sino por altruismo. La ética es esencialmente altruista. Para una empresa con comportamiento ético, su beneficio no es un fin, sino una consecuencia. Su fin no es actuar en su propio beneficio sino en

el de sus clientes, sus trabajadores y la sociedad en general. Quizá este sea un buen criterio para determinar la ética con la

que una empresa tratará internamente las operaciones: ¿Los empresarios o accionistas tienen como fin: Beneficio propio (Ganar dinero, prestigio, poder...) Beneficiar a clientes, empleados y a la sociedad en general.

¿El beneficio es un fin o una consecuencia?

Empresa y mercado 217

Adquisición de sistemas de software:Intuición

04.11.2005

Las empresas de sistemas de software dan, o deberían dar, un cierto miedo a sus clientes porque trabajan con probabilidades

muy altas de fracaso. Las estadísticas y los gráficos de los informes anuales de nuestro sector están resultando tan tozudos como contundentes, y a pesar de los conocimientos teóricos sobre procesos y calidad, se resisten a cambiar.

Como los sistemas de software rezuman técnica, lo normal es que los clientes no sea expertos, y de no ser empresas de cierta envergadura con departamentos informáticos propios, o de no contar con un servicio de asesoría especializado en procesos de adquisición de soft (que son muy difíciles de identificar), suelen

gestionar la selección del proveedor, y demás tareas del proceso

de adquisición (ISO/IEC 12207 5.1) con una mezcla de suerte e intuición.

Empresa y mercado 218

Para afrontar la adquisición de un sistema de software los clientes se suelen apoyar en tres estrategias:

1. Asesoría profesional para la adquisición de software. 2. Currículum del proveedor (certificaciones oficiales,

experiencia…). 3. La mencionada intuición.

Y aunque esta última pudiera parecer la menos rigurosa o

profesional, bien guiada puede ser la más útil de las tres.

Los proyectos problemáticos son una manifestación más del Principio de Pareto: la mayor parte de sus problemas proceden directa o indirectamente de un número muy reducido de causas, y con un poco de olfato o de intuición se pueden detectar con bastante puntería.

Las otras dos estrategias también son efectivas, aunque convendría observar algunos consejos para esquivar los errores comunes, que las pueden mudar en ineficaces o contra-producentes; pero por ser limitada la extensión que se espera de un artículo, será más provechoso dedicar este a la intuición, empezando así por el factor fuerte de Pareto; y dejando a las

otras dos como temas para posteriores artículos, que podrían cerrarlo a modo de trilogía. INTUICIÓN Las primeras respuestas que busco en cada nuevo proyecto son:

¿El cliente sabe realmente qué es lo que quiere conseguir o mejorar? ¿Sabe lo que necesita?, o en caso contrario ¿Sabe que no lo sabe, y que ésta es su principal

prioridad?

Los presupuestos, estimaciones, charlas, reuniones y en

general las conversaciones que se han mantenido con él ¿estaban encaminadas a medir la profundidad del futuro sistema, a conocer el ámbito del problema que tiene que solucionar el software, y el nivel de análisis que ya ha realizado el cliente?; o por el contrario su objetivo ha sido no “dejarle enfriar” y conseguir que firme en un contrato una operación de la que no se tiene claro su

alcance. ¿El cliente va a colaborar con el equipo durante el

proyecto?, o ha hecho el pedido y se ha quedado a

Empresa y mercado 219

esperar el día de la entrega.

En mi experiencia estos son los factores clave o los que

podríamos llamar “factores de Pareto”. Cuando se gestionan bien, los proyectos no suelen fracasar. Por el contrario, cuando surgen problemas, la mayor parte tienen origen directa o indirectamente en una de estas tres causas:

1. Clientes que buscan programas.

2. Proveedores que buscan dinero. 3. Clientes que no se implican en el proyecto.

1.- Clientes que buscan programas. Los clientes que buscan programas dan una orientación a las tareas de adquisición que atrae factores de riesgo hacia el proyecto.

Sin duda los clientes no necesitan programas. Necesitan soluciones. Aunque a primera vista esto pueda parecer un simple juego dialéctico, lo cierto es que esta diferencia de enfoque transmite implicaciones importantes al proyecto.

Si lo que el cliente quiere es una página web, es posible que su proveedor le entregue una más o menos bonita, pero lo que no sabemos es si con ella mejorará la calidad en la atención a sus clientes, o se reducirán las llamadas al centro de soporte telefónico, o recibirá feed-back del mercado, o…

¿Cuántas empresas han “comprado” un CRM o un ERP que funciona, pero que no han conseguido las mejoras que se esperaban? En los proyectos de clientes que quieren programas se suelen

descuidar actividades clave como el análisis del problema, de los

requisitos del sistema, el estudio y comparación de las posibles opciones de solución, o de los criterios que se emplearán para la validación y verificación del producto generado. La Ingeniería del Software y la experiencia conocen muy bien las consecuencias de estos descuidos.

Empresa y mercado 220

2.- Proveedores que buscan dinero. Hay empresas (no sólo de software) que tienen como objetivo aportar beneficios o valor a los clientes a través de sus sistemas,

y la consecuencia de ese trabajo es una facturación directamente proporcional al número de clientes y a la cantidad de valor proporcionado. Otras tienen como objetivo ganar dinero, y para conseguirlo venden productos o servicios a sus clientes.

También aquí puede parecer que se trata de una misma cosa,

vista desde ángulos diferentes; pero no es así. Quizá en otros negocios las consecuencias de uno u otro enfoque no sean muy significativas, pero en el nuestro cada una de estas visiones transmite implicaciones muy importantes a los proyectos, y los puede predisponer al fracaso.

El primer tipo de empresa forma a su personal, mide sus resultados, elabora su estrategia y su táctica para conseguir que los negocios de sus clientes triunfen, sabiendo que de esta forma cada vez ganará más dinero. En el segundo tipo de empresa la estrategia, la medición de sus

procesos y sus esfuerzos se dirigen a aumentar las cifras de ventas, pero no a solucionar los problemas de los clientes. Las consecuencias de trabajar con la segunda estrategia suelen ser:

Las estimaciones de precio y agendas responden a

razones estratégicas, no a la realidad del sistema.

El análisis y la gestión de los requisitos se realizan de

forma inadecuada.

Se acaban desbordando agendas y presupuestos.

Se inyecta presión al proyecto.

Se generan sistemas de baja calidad: tasas de errores

altos, arquitecturas parcheadas o diseños para salir del paso

Las deficiencias de los requisitos hacen difícil validar y

verificar los productos obtenidos 3.- Clientes que no se implican en el proyecto. El descubrimiento temprano de desviaciones sobre la planificación, de modificaciones o sugerencias no descubiertas en

los requisitos iniciales es la mejor estrategia para evitar el re-trabajo y conseguir una eficiencia alta en el proyecto.

Empresa y mercado 221

Por muy bien que se haya realizado el análisis de requisitos del sistema y del software, cuando el cliente vea el resultado descubrirá atributos o funcionalidades que no se han

implementado como él esperaba, o que necesitan algunas ampliaciones que no se consideraron al principio. Como resultado se terminan descubriendo en el momento más caro del ciclo de desarrollo: en la validación del sistema. Los desencuentros en ese momento suelen generar recelos entre

cliente y proveedor, de mayor o menor calado, que en ocasiones terminan como el rosario de la Aurora.

Empresa y mercado 222

¿Es más importante la venta o el producto?

29.11.2005

Para las empresas de las tecnologías de la información, ¿Qué es más importante, vender o producir? Si sólo fuera posible elegir una opción, ¿cuál preferiríamos?:

Una empresa con excelentes técnicos y vendedores ineficientes.

Una empresa con grandes vendedores y técnicos

chapuceros. No hace falta decir cuál de las dos que faltan es la buena. Se suele decir que la empresa es un equipo. Que todo el mundo

está en el mismo barco, y que tan importante es la venta como el producto. Que de poco sirve hacer los mejores programas, si no se ponen en el mercado. Y que al contrario, vender software con problemas sólo consigue desprestigiar a la compañía. Esta suele ser la postura políticamente correcta, que ante la difícil pregunta de ¿a quién quieres más mi hermanito o a mi?,

responde que a los dos igual.

Sin embargo suele ocurrir que el hermanito recibe mejores juguetes, más sonrisas y menos broncas. Vía Barrapunto he leído el siguiente párrafo, sacado del artículo de Dirson, "buscando dinero en Google"

Por último, este interesante artículo hace mención a lo que se ha

llamado un 'sistema de castas' dentro de Google. Este hipotético sistema relegaría a una segunda posición a los comerciales y personal relacionado con las finanzas, en favor de los ingenieros,

programadores y responsables de producto, los cuales tienen mayor influencia. Incluso se afirma que existen ciertos prejuicios contra los hombres de negocios.

Desde Google niegan este extremo, afirmando que han contratado a diversas personas con títulos de MBA, aunque en Slashdot se felicitan de que por fin una compañía diga bien claro que los ingenieros hacen que el mundo funcione." ¿Será esta una de las razones del fenómeno Google?

Empresa y mercado 223

Benchmarking y best practices en manos de aprendices de brujo

18.01.2006

"Tu departamento gasta más del 5% de su presupuesto en formación, cuando la media de nuestro sector es del 3%".

Esta fue la razón por la que la prestigiosa y cara firma consultora que nos ayudaba a ser más eficientes, redujo los "gastos" del departamento de programación, consiguiendo así un coste de producción más acorde con la "media de nuestro sector". La consultoría de "expansión y mejora" hizo un análisis

exhaustivo de la empresa y las medidas que finalmente arbitró fueron tan acertadas como esta, basadas nada menos que en benchmarking y buenas prácticas. Callados, impresionados y contentos quedamos todos en la reunión de comité por tener a nuestro alcance tanta sabiduría

para mejorar nuestra empresa.

Pero la desdicha quiso que las medidas que aplicó esta consultora, inspiradas en prácticas tan incuestionables no pudieran llegar a dar resultados, porque un cúmulo de mala suerte se cernió sobre la empresa, tal y como ocurre en los dibujos animados con la nube gris sobre el coyote.

El departamento de RR.HH. comenzó a ser más eficiente. Se le aplicaron métricas, porque antes... éramos un desastre, no medíamos nuestra eficiencia, y claro así... cómo íbamos a mejorar.

Ahora sabíamos cuál era el coste de contratar a una persona: precio de la difusión en los medios, nº de personas

entrevistadas, tiempos dedicados por RR.HH. Así, sí. ¡Alucinante!. En los consejos de dirección podíamos ver en gráficos que contratar un programador nos "costaba" xxx€, y los consultores eran tan listos que habían incluido en la retribución de la plantilla unas cantidades variables en función de objetivos.

¡Anda, qué genial!. RR.HH. sólo podía mejorar. Si hoy costaba tanto contratar a una persona, ya verías como se las ingeniaba

Empresa y mercado 224

para que al año que viene saliera más barato... ¡En ello le iba el sueldo!. Y así con todos los departamentos. El nuevo modelo de procesos métricas y eficiencia obligaría lo

quisiéramos o no a mejorar en todos ellos. Eso sí, ahora lo cuento muy deprisa, pero esto no es fácil. Costó semanas... qué digo semanas, meses de reuniones que duraban mañanas y tardes enteras para poder encontrar la fórmula de cálculo de retribución variable adecuada para cada

puesto. En el caso de los programadores: ¿Líneas de código?, ¿Incumplimiento de fechas?, ¿Errores encontrados?, valoración

de los superiores, etc, etc... Habría que poner algunos sistemas de registro... Por supuesto, tantas horas de trabajo con la inestimable ayuda de los consultores terminaron por dar las fórmulas, así que las pudimos implantar...

Pero, lo que decía... vino una racha de mala suerte y no pudimos obtener los resultados de tantas medidas de mejora. La casualidad quiso que técnicos y gestores veteranos abandonaran la empresa. Con los nuevos que se contrataban no tuvimos la misma suerte que antaño, y los que encontrábamos eran mas "junior". La competencia es muy mala, y tiró por tierra

la fama que hasta entonces habíamos tenido de técnicamente buenos y solventes, y quedamos como técnicamente del montón, el clima laboral se hizo irrespirable, la gente que antes se olvidaba de mirar al reloj, ahora se había vuelto maniática y quería salir a la hora en punto... y así un largo etcétera de cosas, todas de mala suerte,

Claro con este cúmulo de desdichas, ni la mejor consultoría hubiera podido hacer nada. Qué rabia ¿verdad? Haber descubierto como mejorar y no poder disfrutarlo por la mala suerte; y por otro lado empresas a las que

les va tan bien sin tan siquiera haberse dado cuenta de que son

diferentes a los demás, que podrían ahorrar un montón en formación o I+D+I, o en tantas cosas que seguro hacen diferente a la media de nuestro sector, o peor que los mejores.

"El 75% de las empresas que conozco no tienen estrategia y se

limitan a imitar a sus competidores"

Michel Porter

Empresa y mercado 225

Nuestros clientes no quieren programas

02.03.2006

Dicen que durante una reunión del consejo de administración de Black & Decker, su presidente interrumpió la exposición del

departamento de marketing, diciendo con gravedad: “Señores, han confundido el objetivo: Nuestros clientes no quieren taladros…. Nuestros clientes quieren agujeros”. Muchas empresas de software creen que los clientes quieren

programas. Hacer soft no es un fin en sí mismo, es un medio; y ganar dinero tampoco debería ser un fin, sino una consecuencia. A mayor número de clientes satisfechos, y con mayor nivel de calidad en sus soluciones, mayor volumen de negocio y mayores

expectativas de crecimiento.

El objetivo de la empresa no debería ser crear software, sino soluciones; y no debería hacer programas para ganar dinero, sino ganar dinero porque hace programas. Las empresas que truecan las consecuencias por el fin, construyen culturas con mensajes erróneos.

Sus departamentos se alinean con un fin: ganar dinero, y cumplen los objetivos de facturación vendiendo “programas” (o lo que sea) sin pararse a analizar los problemas de los clientes. Los gestores de los proyectos se centran en cumplir las fechas de

entrega, asignando todos los programadores posibles a los proyectos retrasados.

Normalmente las fechas no encajan con las previsiones, y los programas no terminan de contentar a clientes que piden cambios por no tener lo que necesitan. Al analizar la rentabilidad se ve que los retrasos aumentan los costes, y merman el beneficio esperado. Los departamentos comerciales ponen a los programadores

como culpables de estos retrasos, y ellos se defienden diciendo que negocio cierra agendas sin saber si se podrán cumplir.

Empresa y mercado 226

Hace algunos meses fui testigo de cómo una empresa de software cerraba, tras muchos problemas, un proyecto con una desviación de agenda y presupuesto de un 400%.

Inicialmente se vendió como un sistema de gestión integral que debía estar funcionando en 6 meses. Era una operación con la que el departamento comercial conseguía dos objetivos: el de facturación trimestral, y la incorporación de un cliente importante a la cartera de la compañía.

Por eso, cuando el cliente dijo de cuándo dinero disponía, y la fecha en la que el sistema debía estar funcionando, la empresa

de software le hizo un presupuesto con un cronograma que encajaba como un guante. En 6 meses estaría todo terminado. En julio y agosto: obtención, análisis y especificación de requisitos, de septiembre a noviembre desarrollo, y en diciembre instalación y pruebas.

El 1 de enero funcionando. ¡Justo lo que el cliente quería!. El departamento de ventas, con su mejor criterio consideró:

Se trata de una operación importante, y aunque es

seguro que cuando los ingenieros vean las fechas se quejarán, bien merece la pena poner a los mejores

programadores, y el número que sea necesario, para que esté en enero.

El presupuesto es posible que se quede algo estrecho,

pero con esta operación, conseguiremos el contrato de las dos fases siguientes, y una buena cuenta.

En enero el programa no estuvo disponible, y lo que fue aún

peor, el cliente, al iniciar su nuevo negocio descubrió que necesitaba funcionalidades que no se habían contemplado. Las tareas de requisitos no se habían realizado para conocer las necesidades del negocio del cliente, sino para hacer el documento de requisitos, obligatorio según los procesos del

departamento de desarrollo.

Las deficiencias de los requisitos, y las modificaciones introducidas llevaron, en enero, a tirar todo el código y comenzar con un nuevo diseño de arquitectura y datos. Tras un rosario de vicisitudes y trabajo en constante presión de fechas, el cliente, disgustado y cansado, validó finalmente el trabajo en abril ¡del año siguiente!.

Lo que inicialmente debía haber durado 6 meses se prolongó durante 22, y en la misma proporción, los costes del proyecto.

Empresa y mercado 227

Tras los casi dos años de retrasos, el cliente quedó muy descontento con la empresa de software, cuya falta de profesionalidad le había obligado a demorar sus planes de

negocio, y a introducir medidas de contingencia de última hora para realizar operaciones mensuales y otros procesos previstos en el sistema que constantemente retrasaba su fecha de implantación. Las tensiones entre el departamento comercial, gestión de

proyectos y programación tampoco resultaron agradables.

El único beneficio que se puede extraer de estas experiencias es emplearlas para aprender. Aunque en la realidad, las tiranteces que generan y las tensiones personales hacen difíciles los análisis objetivos, y frecuentemente no se llega más allá de achacar a las circunstancias y a la culpa de otros la

responsabilidad. Analizando este caso, y tantos otros similares… ¿dónde diríamos que se encuentra la responsabilidad?

¿En el departamento comercial?

¿En la falta de comunicación entre desarrolladores y

vendedores durante la estimación de proyecto?

¿En el trabajo deficiente o lento de los ingenieros?

¿En la gestión del proyecto?...

Estas suelen ser las líneas de análisis tras los fracasos de los proyectos; pero lo cierto es que los aludidos consideran que cumplieron bien su trabajo y alcanzaron sus objetivos.

El departamento comercial cerró el presupuesto del año satisfactoriamente y aumentó la cartera de clientes, y los programadores trabajaron denodadamente, alargando sus

jornadas diarias de trabajo a fines de semana y horas extras. Por estas razones, el equipo, e incluso los gestores de la

empresa, que saben del interés y dedicación de su personal, concluyen reafirmándose una vez más en el convencimiento de que son “gajes” de nuestra profesión. Las cosas en este negocio suelen ser así y poco se puede hacer. Pero… ¿Quién pensó en el cliente?. ¿Quién tenía como objetivo su éxito. ¿Conocer y analizar las

necesidades de su negocio, y trabajar con él en el diseño e implantación de las soluciones?

Empresa y mercado 228

La conclusión no es compleja: todo el personal hizo lo que debía hacer, y si hubiera que buscar un responsable, habría que dirigir la mirada hacia las instancias altas de dirección.

Los objetivos de los departamentos no estaban alineados entre sí, ni respondían a una estrategia coherente. Ninguno de ellos tenía como fin solucionar los problemas del cliente. Orientación al cliente no es amabilidad, cortesía, o incluso servilismo.

Por supuesto que debe dispensar amabilidad y cortesía a su cliente, pero lo que además se espera de una empresa

profesional de software es que haga suyo el problema del cliente. Más allá incluso de lograr clientes satisfechos, se trata de conseguir clientes con éxito. Que nuestro trabajo sea una de las razones del éxito de su

negocio.

Empresa y mercado 229

Empresas que optan por procesos. Empresas que optan por agilidad

27.05.2006

Revisando noticias de la semana, leo que Acer implanta modelos ágiles en el ciclo de desarrollo y mantenimiento de sus productos. Son habituales las notas de prensa anunciando que la empresa tal ha adoptado un modelo ágil, o que que la empresa cual ha

alcanzado el nivel x de madurez CMM o CMMI. Una muestra de empresas que han optado por modelos ágiles (adaptativos) o formales(predictivos), de los que yo tengo constancia son:

Modelos formales Modelos ágiles

Accenture - DB Systems GambH - General Motors - Harris Corporation - JP Morgan - Reuters - Motorola - NCR -

TATA - Ebix...

Acer - Honda - NEC - Epson - 3M - Microsoft - Yahoo - Hewllet Packard - Brother - Sun - Phillips.

A los modelos formales se puede acudir buscando mejoras o buscando apariencia (o ambas cosas). Trabajan sobre los procesos para mejorar la calidad y la eficiencia, y dan diplomas de certificación.

A los modelos ágiles se puede acudir buscando adaptabilidad,

innovación o reducción de tiempo de salida al mercado. Trabajan sobre las personas, el talento y la motivación. Hay empresas que desarrollan y mantienen sistemas con niveles

de integridad muy elevados (banca, medicina, ejército, aviación, etc.). Otras viven de la innovación, del desarrollo constante de nuevos productos, de la reducción del tiempo de salida al mercado...; y otras tienen diplomas, certificaciones y reconocimientos de eficiencia, calidad, innovación, atención al cliente, etc, etc, etc.

Empresa y mercado 230

Moros y cristianos

19.10.2006

Hay oficios y profesiones que toman como criterio de especialización áreas específicas de problemas o de soluciones. Los médicos por ejemplo se especializan en ginecología, urología, cardiología, pediatría... Otros emplean como criterio tecnologías, o incluso proveedores.

En programación son bastante frecuentes profesionales y empresas especializadas en software libre, o a través de las figuras de partner, en tecnologías y plataformas como Microsoft u Oracle... Con los primeros es más fácil dar con el profesional o la empresa adecuada. Afortunadamente decidir si lo que nos hace falta es un

ginecólogo, un cardiólogo o un pediatra es más fácil así que si tuviéramos que decidir entre un especialista en Bayer, Johnson & Johnson o Menarini.

En el segundo caso el "proceso de adquisición" sería más difícil y debería estar guiado por un experto para evitar que algún

"profesional" sin escrúpulos nos "garantizara" que lo mejor para nuestra dolencia es el último descubrimiento de Medical Reunidas del que casualmente él es partner. En algunos procesos gripales la aspirina puede bastar, y en otros puede ser necesario el ingreso en un hospital.

Algunas intranets y espacios colaborativos pueden tener la mejor solución con herramientas como Drupal o Joomla... y otras con Sharepoint Portal Server o Documentum.

Es posible que la intranet sea para una asociación empresarial o recreativa; una empresa con dos delegaciones o doscientas, con trabajadores dispersos, que necesite control de versiones de

documentos o no... etc. Si buscando una intranet (por ejemplo) acudimos a unos especialistas en software libre, estaremos de suerte, porque seguro que lo que nos hacía falta era una solución libre, que son mucho mejores que las propietarias.

Si acudimos a un partner de Microsoft, estaremos de suerte,

Empresa y mercado 231

porque seguro que lo que nos hacía falta era Sharepoint o Portal Server que es mucho mejores que esas soluciones libres.

Además en los profesionales que se especializan por tecnologías o marcas es frecuente la radicalización pasional:o eres de Linux o de Windows, de Java o de C#, de CMMI o de Extreme Programming, etc, etc. Hay áreas (quizá la religión, o el fútbol) donde las preferencias

racionalmente injustificables pueden tener sentido. Ser del Betis o del Sevilla, del Madrid o del Barcelona; o la aversión de un

católico a leer el Corán, o la de un musulmán hacia la Biblia. Pero esa misma tendencia al aislamiento en "religiones tecnológicas" e impermeabilización frente al conocimiento de las otras tendencias no parece tener mucho sentido, porque las

actitudes fundamentalisas o sectarias empobrecen, aíslan y crean recelos y enconos infundados. Las visiones objetivas y amplias dan perspectiva, criterio y enriquecimiento profesional.

Empresa y mercado 232

Algunas majaderías sobre el código abierto

21.11.2006

Vía Sergio Hernando leía hace unos días:

Con el código abierto, no hay propiedad intelectual. Cualquiera puede usarlo, y tus ideas pasan al dominio público. Si nadie puede hacer dinero con eso, no habrá desarrollo y los programas

de código abierto rápidamente se vuelven obsoletos. Si soy programador, caso de poder escribir buen código, ¿por qué regalarlo? Tailandia puede hacer buen código sin necesidad de código abierto.

Son declaraciones del ministro tailandés de tecnologías de la información y las comunicaciones. Es lo que tiene la libertad de expresión, que cada uno puede decir lo que quiera, y se puede llegar a extremos como los de este señor.

Se pueden afirmar majaderías como que con el código abierto no hay propiedad intelectual. ¿Cómo se dirá en tailandés: "qué tiene que ver el culo con las témporas"?. ¿Por qué le parece mal que cualquiera pueda usarlo y que las obras pasen al dominio público? Una de las principales motivaciones que apunta Brooks por las que los buenos

profesionales trabajan es porque mantienen la ilusión del niño: hacer algo útil y que sea usado por los demás. Cualquier programador quiere que los demás usen sus inventos, así que lo de que "cualquiera pueda usarlo" no es malo, sino todo lo

contrario (por lo menos para los profesionales que no consideran su trabajo como un castigo).

¿Es malo para el autor que su obra pase al dominio público, si el autor así lo desea? La frase "Si nadie puede hacer dinero con eso, no habrá desarrollo" tiene un fondo interesantísimo: "La motivación por la que el hombre construye artilugios es el dinero".

Pobre señor, no puede comprender el placer de hacer algo por el simple gusto de hacerlo, de ver la obra hecha, de poderla

compartir, regalarla a quien pueda resultar ÚTIL, y en especial

Empresa y mercado 233

en todo aquello en lo que el valor de las copias es 0 y por tanto la capacidad de regalar y compartir resulta infinita.

Eso de que los programas de código abierto se vuelven obsoletos, debe ser porque los programas propietarios tienen el elixir de la eterna juventud. En fin, no merece la pena ni comentarlo. Antes de terminar vuelve a demostrar su pobreza de espíritu

cuando afirma no comprender "Si soy programador, caso de poder escribir buen código, ¿por qué regalarlo?".

Y por fin, una frase con cierta lógica: "Tailandia puede hacer buen código sin necesidad de código abierto". Sí señor, totalmente de acuerdo. Pero lo que no vale es cerrar un discurso de majaderías con una

frase cierta, como dando a entender que es la conclusión de lo dicho. Esto es así porque es así. Tailandia puede hacer buen código sin necesidad de que sea abierto. Hay software cerrado y comercial estupendo, y los que lo

fabrican no son demonios. Y también hay iniciativas de artífices que dibujan, escriben, programan, investigan... porque son curiosos. Porque les gusta, porque pertenecen a esta rara especie humana de actividad y curiosidad insaciable, y siguen manteniendo una cierta inocencia infantil, por la que comparten, regalan y les preocupa más que

guste lo que han hecho, a que se lo paguen.

Empresa y mercado 234

¿El poder político debe intervenir en el sector del software?

14.12.2006

Hace pocos días era el ministerio de tecnología de Tailandia el que a través de argumentos majaderos se cubría de razones y

razonamientos por los que debía favorecer los modelos de negocio de software propietario, y vetar a los modelos de negocio de software libre. Bueno, como es Tailandia y está tan lejos. Ya se sabe, en esos países tan remotos los dirigentes son así...

Pero anteayer leía en el País: "El Congreso insta al Gobierno a promover el software libre ". ¡Anda, ahora es el estado de mi país el que cree que entre sus obligaciones está la de mediar en la industria del software!. ¿Por qué hay gobiernos de economías capitalistas que se interesan en

beneficiar a uno u otro modelo de negocio de este sector?

¿No son dos modelos de negocio son perfectamente válidos y caben y tienen su lugar en un sistema de libre competencia? Por eso sinceramente, lo pregunto con perplejidad: ¿Esto no es intervencionismo tendencioso? .

Empresa y mercado 235

Gestión y procesos en empresas de software

11.12.2005

Las empresas que desarrollan software no pueden ignorar que su negocio

es un negocio de software, y que el modelo que cada una adopte para las

actividades de desarrollo y mantenimiento tiene implicaciones relevantes

en la eficiencia general del negocio.

El problema que pueden encontrar quienes deciden implantar métodos

más eficientes, es caer en la desorientación ante el abanico de modelos

de calidad, de procesos y de técnicas de trabajo desplegado en la última

década; o abrazar al primero que se presenta en la puerta de la

organización como “solución” de eficiencia y calidad

Este artículo dibuja un mapa de situación general como orientación para

directores técnicos, responsables de departamentos informáticos y

personal directivo de organizaciones de software.

La visión general que ofrece, muestra cómo en su totalidad un entorno de

producción es un entorno sistémico, en cuyo diseño global los

componentes tienen que encajar y funcionar armónicamente, alineados

con las características, cultura y estrategia de la organización.

Amenaza u oportunidad Según como afrontan las organizaciones el desarrollo del

software, éste puede comportarse como factor de riesgo o amenaza para el negocio; o por el contrario como una poderosa

oportunidad de negocio. Todas las empresas quieren producir más rápido, mejor y con menores costes, y sin duda esto es posible porque la naturaleza del software no es origen de riesgos y problemas, sino una

fuente de oportunidades. Cada vez más directivos están comprendiendo que la forma de gestión del desarrollo de software, puede hacer de la materia prima de su negocio un material arisco de resultados impredecibles, o una ventaja competitiva.

Empresa y mercado 236

La evolución hacia entornos de ingeniería del software requiere cambios severos en la organización, así como el convencimiento, implicación y empuje de la dirección. Pero sobre todo el diseño

de un modelo de producción propio que sepa aprovechar la personalidad de la organización, y responder a las particu-laridades de su negocio. El software ha estado generando los mismos problemas en los últimos 40 años, y quien no cambia la forma de hacer las cosas,

sigue tropezando en ellos.

El problema que pueden encontrar quienes deciden implantar métodos más eficientes es caer en la desorientación ante el abanico de modelos de calidad, de procesos y de técnicas de trabajo desplegado en la última década, o abrazar al primero que se presenta en la puerta de la organización como “solución” de

eficiencia y calidad. Trabajar sin ningún método es una opción, pero no una metodología. Las organizaciones que desarrollan o mantienen software pueden optar por trabajar "a la buena de Dios", o por seguir una

metodología. Hacerlo a la buena de Dios no es tan raro. Es la primera forma que se empleó para desarrollar programas: "Aquí tenemos unos ordenadores, aquí unos señores a los que les encanta leer los manuales de programación, y se trata sencillamente de conseguir que estas máquinas terminen imprimiendo facturas (o haciendo lo que sea)".

En realidad, cuando en la segunda mitad del siglo pasado la industria del hardware puso en la calle máquinas que se podían programar, poco más se podía hacer; y los pioneros de nuestra profesión, atraídos por el encanto de diseñar y construir artefactos útiles, y verlos funcionar, fueron los primeros en

remangarse frente al teclado y decir a su cliente con una

sonrisa:"en un par de meses esto estará funcionando". Fueron también los primeros en pasar noches en vela programando, prometiendo una y otra vez que "tan sólo es cuestión de un par de días más." Aunque las cinco décadas de vida del software ya han sido suficientes para experimentar los excesos y los errores de la

infancia y la juventud, la resistencia al cambio es el mejor aliado de la inercia, y por eso se produce una cierta impermeabilidad a la experiencia.

Empresa y mercado 237

En cualquier caso es una opción: trabajar sin ninguna metodología.

SEI, (Software Engineering Institute) por el rigor de su documentación y la circunspección de su imagen no puede llamar a esta forma de producir como "a la buena de Dios", y en su lugar afirma que es la forma propia de organizaciones "poco maduras". En la escala que de 1 a 5 emplea para determinar el grado de

madurez de una organización, y en consecuencia el nivel de garantía que ofrece en cuanto a calidad, predictibilidad en los

resultados y eficiencia en el desarrollo de software, este tipo de organi-zaciones se quedan, lógicamente, en el 1. Que, ¡ojo cuidado! no quiere decir que necesariamente van a producir mal software, de forma ineficiente y con retraso, sino que las probabilidades de cumplir las tres facetas es baja.

Hay equipos que lo consiguen, pero son pocos. La razón es sencilla, los resultados en estos casos son tan buenos como las personas que los desarrollan, y lo cierto es que los buenos programadores escasean. A este modo de producción se le ha venido a llamar "programación heroica", porque todo el peso del resultado descansa sobre el "saber hacer" de los programadores.

El éxito o fracaso de las organizaciones que trabajan sin metodologías depende del conocimiento tácito de su personal, pero teniendo en cuenta que se trata del conocimiento que cada uno traía ya de la calle, o del que adquiere motu proprio, porque estamos hablando de "ninguna metodología", lo que implica que como mucho los procesos de formación de la empresa llegan al

"ahí tienes manuales y libros, por si hubiera algo que no sabes". Este es sin duda el modelo con el que empiezan muchas empresas "start-up": un equipo de emprendedores con talento, capaces de construir sistemas de software con calidad. Los resultados serán tan buenos como ellos los sepan hacer. El

cumplimiento de agendas dependerá de su capacidad de

previsión y organización. Pero no hay que engañarse; en este caso no se trata de empresas que saben hacer software, sino de personas que saben hacer software. Y esta situación dibuja el guión común a todas las pequeñas empresas de desarrollo de soft que surgen de cero, impulsadas tan sólo por el empuje de sus emprendedores: pueden llegar todo lo lejos que la combinación del talento y de la capacidad de

marketing de sus creadores les permitan. O sea, en ocasiones acabarán cerrando, y en otras alcanzarán un nivel de estabilidad tan mediocre o tan brillante como dicha combinación les permita. Y si una vez logrado ese nivel de

Empresa y mercado 238

equilibrio desean proyectar mayor crecimiento a su organización se enfrentan a un reto importante:

Pasar de personas que saben hacer software a empresa que sabe hacer software.

Salto que supone que no van a ser ya ellos, sino su empresa quien deberá producir de forma eficiente y repetible en todos sus proyectos, resultados de calidad. Y esta es otra aventura en la

que muchos fracasan teniendo que regresar a la casilla de salida, o si el "roto" del intento ha sido muy grave, terminar cerrando, o

como mal menor dejándose adquirir por algún competidor más o menos grande del sector. La teoría de la gestión empresarial recomienda para esta travesía tomar como medio de transporte la gestión por

procesos. Sí, no es nada nuevo, y leerlo a estas alturas puede dar la sensación de estar desayunando con el periódico del día anterior. Aparte de las excelencias recogidas en el manual del consultor sobre la transversalidad de los procesos, que atravesando a toda la organización dibuja modelos organizacionales sin rigideces departamentales, y alinea con sus flujogramas a toda la empresa

en el mismo sentido con visión centrada en el cliente, y bla, bla, bla. Lo cierto es que la gestión por procesos encierra cuatro factores que hacen posible pasar de grupo de emprendedores a empresa:

Repetibilidad de resultados. Al conseguir que la calidad

del resultado sea consecuencia del proceso, producir aplicando el mismo proceso garantiza la homogeneidad de los resultados.

Escalabilidad. Es una consecuencia de la repe-tibilidad. No sólo un equipo consigue resultados homogéneos en todos los

proyectos, sino que los obtienen todos los equipos.

Mejora continua. Al aplicar meta-procesos que trabajan

sobre los propios procesos de producción, midiendo y analizando los resultados se obtienen los criterios de gestión necesarios para aplicar medidas que mejoran de forma continua la eficiencia y calidad de los procesos base, y por tanto de los resultados.

Un know-how propio, consiguiendo finalmente una empresa que sabe hacer, porque su modelo de procesos

termina conteniendo un activo valioso de la organización: la

Empresa y mercado 239

clave para hacer las cosas bien, con eficiencia y de forma homogénea.

No sólo son procesos Los procesos marcan pautas para realizar el trabajo, pero sin las personas y las herramientas (tecnología) necesarias, lo que se puede producir con ellos es más bien poco. Las únicas combinaciones válidas para formar sistemas capaces

de producir resultados son:

Personas + tecnología Producción heroica

Personas + procesos + tecnología

Producción basada en procesos

Un ejemplo que seguro todos hemos realizado alguna ves, y que

ilustra las diferencias entre ambos sistemas de producción es el montaje de un mueble en kit. Para enfrentarnos a esta tarea tenemos, por un lado a las personas: nosotros. Y por otro la tecnología: el destornillador

(manual o eléctrico), los tornillos, pasadores, la cola de montaje,

etc. Y si dejamos el proceso a un lado (el manual con las instrucciones de cómo proceder) tendremos un sistema perfecto de producción heroica: personas + tecnología; del que cabrá esperar los resultados propios de estos entornos. La productividad y la calidad no son homogéneas. Hay quien ensambla la estantería o el mueble, en cuestión de minutos, y

quien necesita toda una tarde. Algunos obtienen estanterías robustas y perfectas, y otros terminan el montaje con peor fortuna, afirmando que la

estantería está bien montada pero que las piezas venían mal

Empresa y mercado 240

cortadas de fábrica, o que quien diseñó ese mueble era un perfecto inútil, o que los tornillos son de mala calidad, o quizá sin ni siquiera percatarse de los defectos con los que ha dejado el

mueble. En definitiva esta forma de trabajo produce resultados, y puede resultar más o menos apropiada para realizar hobbys o bricolajes domésticos, pero para una empresa de montaje de muebles no resultaría viable un sistema de producción que no pudiera

garantizar eficiencia en los costes, y resultados con una calidad homogénea.

Hay dos formas de evitar estos problemas:

Introducir un tercer elemento en el sistema de producción: los procesos.

Trabajar sólo con personas y tecnología, pero empleando sólo a los mejores ebanistas, y proporcionándoles las mejores herramientas.

Como veremos a continuación generalmente la mejor solución no suele consistir en adoptar una u otra opción, sino una mezcla de

ambas, con mayor o menor peso específico en una u otra, en función de las características del negocio. Al añadir procesos al sistema se consigue que todas las personas ejecuten el trabajo siguiendo las mismas pautas, y que los parámetros de ejecución y los resultados puedan ser medidos de forma homogénea en toda la organización.

De esta forma se reduce drásticamente la heterogeneidad de los resultados, tanto en la eficiencia de los tiempos invertidos, como en la calidad obtenida, que empieza a ser proporcional a la capacidad de los procesos que se hayan diseñado.

Pero no hay que dejarse deslumbrar por los procesos y olvidarse

de los otros componentes. Basar una empresa sobre un sistema de producción de dos elementos: personas y tecnología plantea limitaciones; pero basarlo en un entorno exclusivo de procesos, o de procesos y tecnología, simplemente no es posible. La realidad de los procesos es cierta, pero en el triángulo

personas - procesos - tecnología cada elemento actúa con un peso específico, diferente en función del tipo de producción, e incluso de las características de personalidad de cada empresa.

Por eso, llegados a este punto, el ámbito de la teoría generalista

Empresa y mercado 241

se acaba, y cada sector y cada empresa, más que importar una metodología estándar sacada del manual del perfecto consultor, debe comenzar por el gnosce te ipsum, y a partir de ahí analizar

y descubrir la potencia de cada uno de los tres elementos de la producción para componer el diseño de un sistema de producción a su medida. Los gestores o consultores "estándar" no existen; bueno, perdón, sí que existen, pero obtienen los resultados estándar que todos conocemos.

Relevancia del capital estructural y del capital humano

El capital estructural está formado por los bienes que quedan en la empresa cuando las personas se van a sus casas: patentes, licencias, cartera de clientes, equipos, maquinaria, vehículos, etc.

El capital humano es el compuesto por el valor que la empresa emplea en su negocio y que resulta inseparable de las personas. Todas las industrias necesitan ambos tipos de capitales para elaborar los productos o servicios de su negocio, pero la relevancia con la que cada uno de ellos puede influir en el resultado final es muy diferente de unas empresas a otras.

Es frecuente que para las empresas dedicadas a la fabricación de productos el componente estructural sea más crítico que para las dedicadas a los servicios, en las que el elemento humano tiene más relevancia. Pero este no es un principio universal, y dentro de la misma industria o del mismo sector, la estrategia y la táctica de cada

empresa también influyen en los niveles de relevancia que van a tener el capital humano y el estructural. Veámoslo con un ejemplo, comparando la relevancia de ambos en dos empresas del mismo sector: hostelería. Por un lado pensemos en un exquisito restaurante de cocina

vasca (por ejemplo), y por el otro en un establecimiento de

PhonoPizza (también por ejemplo). Al margen de consideraciones gastronómicas, ambos negocios tienen perfectamente claros su identidad, personalidad y segmento; ambos tienen también su propio patrón de atributos de calidad sobre el que medirse. En el segundo modelo la empresa tiene una serie de

procedimientos para garantizar de forma continua la calidad de sus resultados (calidad y repetibilidad), por lo que éstos dependen mucho menos del conocimiento tácito de sus cocineros, y en su mayor parte se deben a los procesos y la

Empresa y mercado 242

tecnología empleada. Los hornos regulan automáticamente el tiempo y la temperatura,

los ingredientes se producen también en base a unos procesos, y se distribuyen de forma masiva a todos los establecimientos en estuches, ambientes frigoríficos y medios de transporte en base a unos procesos que son los principales responsables de los resultados.

Por esta razón resulta mucho más fácil, o en lenguaje empresarial, menos costoso, reemplazar al personal de cocina de

un establecimiento de PhonoPizza que al de un restaurante de cocina vasca.

Las barras de color azul de la figura 2 representan de forma gráfica el valor, que para una empresa determinada, aporta cada

elemento a su sistema de producción.

Las combinaciones posibles para cada negocio son muchas, y factores como la innovación en la tecnología, en los procesos o la formación del personal pueden abrir la horquilla de potencial de cada elemento. La homogeneidad y calidad de los resultados, y la eficiencia del sistema en su conjunto serán consecuencia del equilibrio logrado.

Por supuesto una franquicia de hamburguesas y comida rápida podría incluir, además de tecnología y procesos eficientes, la

Empresa y mercado 243

contratación o formación de gourmets de alta cocina.; pero de esta forma su sistema de producción no estaría aprovechando la naturaleza de su producto como ventaja competitiva.

La obsesión por la excelencia mal entendida, o la desorientación sobre las funciones del propio puesto lleva a muchos gestores a centrar sus esfuerzos en la incorporación de modelos o técnicas, bien de procesos, bien de recursos humanos o de innovación tecnológica; o de todos a la vez, por razones como que “es lo

último en gestión”, o lo estudiado en el último seminario, o lo que con tanta vehemencia le ha “vendido” el último pseudo-

consultor que visitó su empresa, o lo leído en ese libro de gestión tan interesante. Esta es al fin y al cabo, la razón del escepticismo y las críticas que finalmente verterán sobre modelos, métodos o técnicas

contrastadas y eficaces; cuya debilidad no radica en ellas sino en una interpretación incorrecta, o en una implementación en un grado incorrecto, o sobre sistemas para los que no resultan apropiadas.

Conseguir que el sistema de procesos, tecnología y personas

formen una ventaja competitiva frente a la competencia, y no un reto más del negocio, no es fácil, ni puede importarse con la implantación “prêt-à porter” de un modelo estándar.

Empresa y mercado 244

Como refleja la figura 3, la clave del éxito radica en conseguir que cada factor pueda aportar el mayor valor hasta el límite de su mejor relación eficiencia / calidad.

En esta tarea nunca está dicha la última palabra, y la labor de innovación constante en procesos y tecnología puede ir ampliando los límites de valor a un factor para conseguir un nuevo equilibrio con mejores parámetros de eficiencia y calidad en el sistema.

Gnosce te ipsum

“No hay mayor inmoralidad que ejercer un oficio que no se

conoce” Napoleón

Lo cierto es que un gestor o un directivo necesita combinar los conocimientos de management con los del propio negocio, sector e industria en la que se mueve. Quien se sienta en el puente de mando de una embarcación, por su puesto debe ser un buen “gestor” y contar con las habilidades y conocimientos para gobernar una nave, pero para realizar la travesía necesitará conocer las características de la propia nave,

de la ruta y de las condiciones de la mar. Muchas veces los problemas que desde los puestos directivos se transmiten a la organización tienen su origen en la carencia de alguna de estas habilidades:

Decisiones más o menos fundadas en principios de gestión, que han ignorado las características de la empresa, o las particularidades del sector.

Decisiones de conocedores del negocio sin experiencia en management.

En cierto modo es como poner a los mandos de una embarcación

a un capitán que desconoce cómo es el barco que tripula y las características de la ruta que va a seguir; o como apostar al timón a un tripulante veterano del navío, sin conocimientos de pilotaje. Según las características y dimensiones de la embarcación, y las vicisitudes que presente la travesía, alcanzar puerto puede ser

un reto sin solución. Conocer la empresa

Empresa y mercado 245

Los aspectos de la empresa que se deben conocer son, en general, comunes en todos los sectores, y poco puede aportar

este artículo a un gestor, que él no conozca ya: Para conseguir eficiencia en su estrategia de producción esta deberá ser consecuente y estar alineada Con: La visión: Qué quiere llegar a ser la organización y cuál es su

meta. Estrategia:, foco y plan de negocio, contemplando el mercado,

las fortalezas y debilidades propias, etc. Cuál es la ruta que se ha perfilado para alcanzar esa meta. Sin saber adónde se va, difícilmente se puede diseñar la estrategia para lograr el objetivo, y sin estrategia también es difícil que un gestor pueda ejecutar la táctica adecuada, que es

la que deberá incluir, entre otras cosas, el modelo de producción empleado. Por supuesto se puede zarpar y navegar a la deriva para ver en qué puerto se acaba, pero si no se es amante de las emociones fuertes; y si se siente respeto por el capital de los accionistas, y el trabajo de toda la tripulación, es mejor considerar que la

lotería no es una inversión, sino un juego de azar. Industria del software Para todas las industrias hay marcos de trabajo compuestos por normativas y estándares más o menos estables y consensuados,

que en forma de modelos ayudan a mejora o evaluar la calidad de sus sistemas de producción. Al mismo tiempo cada ingeniería tiene delimitadas sus áreas de conocimiento, y reguladas las técnicas de trabajo para ofrecer las garantías necesarias en la construcción de sus respectivos artefactos.

Así por ejemplo, una empresa de arquitectura, o de ingeniería

aero-espacial, naval o nuclear . tiene estándares y conocimientos estables, que si aplica sistemáticamente aportan garantías contrastadas a la robustez de las estructuras de sus edificios o de las naves que construye. Estos conocimientos, que sirven de referencia y ayuda a los entornos de desarrollo, provienen de dos áreas:

1.- Currículo de técnicas y conocimientos de las respectivas ingenierías. 2.- Modelos, normas y estándares de calidad y procesos aplicables a cada industria.

Empresa y mercado 246

Una diferencia importante entre la industria del software y otras industrias de ingeniería es la falta de consenso o inmadurez en

los dos puntos anteriores, que deja a las empresas de nuestro sector en un cierto grado de orfandad a la hora de buscar ayuda en modelos, técnicas o patrones de referencia. Por la relativa juventud del software en nuestra industria no hay un consenso acerca de cómo éste debe ser producido. El

siguiente texto extraído del artículo “Criticism of software engineering” de wikipedia expone con acierto la situación actual:

En la ingeniería tradicional hay un claro consenso de cómo deben

construirse las cosas, cuáles son los estándares que deben seguirse y qué riesgos deben tratarse: si un ingeniero no sigue estas prácticas y algo falla, puede ser demandado. Sin embargo no hay un consenso similar en la ingeniería del software. Cada uno promueve sus propios métodos, proclamando grandes beneficios en la productividad, que generalmente no respalda

con evidencias científicas imparciales.

El problema en este momento no es la falta de estándares, modelos o técnicas, sino la abundancia de ellos, por lo que

resulta aconsejable tomar un apunte del plano general para saber por dónde nos movemos.

Modelos y estándares de calidad

La figura 4 es un mapa de situación simplificado con la foto de los principales marcos y modelos de procesos que pueden servir de referencia a las organizaciones de software; y las principales referencias de sus orígenes y evolución. Los procesos de fabricación de los años 50 hicieron necesaria la

normalización de los procesos de producción para garantizar la

Empresa y mercado 247

consistencia de los resultados sobre unos parámetros o requisitos previamente determinados. La norma que se considera como punto de arranque de los

posteriores estándares, marcos y modelos que se han extendido a todas las industrias es la desarrollada por EE.UU. en 1959: “Quality Program Requirements” MIL-Q-9858, que, inicialmente diseñada para el ámbito militar, estableció un esquema auditable (a través de la norma de inspección MIL-I.45208) de los requisitos que los proveedores debían cumplir.

El uso de esta norma se fue generalizando, pero de forma paralela diferentes países y organizaciones comenzaron a

desarrollar las suyas propias. Así por ejemplo la OTAN en 1968 adoptó las especificaciones AQAP “Allied Quality Assurance Procedures”). El estándar británico BS5750, adoptado en el Reino Unido en

1979 fue el siguiente hito relevante en el camino de las normalizaciones, al lograr gran reconocimiento en varios países. Esta normativa fue en realidad la precursora de ISO 9000. Las normas y estándares que fueron surgiendo de los años 60 a los 90 dieron respuesta a las garantías de homogeneidad, calidad y predectibilidad que los entornos de fabricación, y

especialmente el desarrollo de sistemas complejos requería al agrupar en proyectos la construcción de artefactos que imbricaban tecnologías e ingenierías diferentes: mecánica, aero-espacial, naval, atómica, etc. En estos sistemas se requería la integración, cada vez con mayor protagonismo, de una ingeniería que en base al conocimiento

que había desplegado en esos años, no podía considerarse aún ni asentada ni consensuada: la ingeniería del software. Algunos de los fiascos que se produjeron en determinados sistemas por la introducción del software sin que éste pudiera dar garantías de resultados a la altura de ingenierías más maduras, son ya parte de la historia de nuestra profesión.

Esbozar este marco histórico resulta necesario, porque es la causa de la actual sopa de letras capaz de marear al gestor más dispuesto con sólo ennumerarla: ISO 900-3, TicIT, ISO 12207, CMM-SW, ISO 15504, CMMI, ASD, XP, SCRUM, DSDM, PP, MSF… Tomando un poco de perspectiva (tan sólo 3 décadas), al software se le ha juntado la necesidad de encajar en marcos de

calidad para ofrecer garantías de perfección, eficiencia y consistencia en los resultados; con la creación de su propia base de conocimientos técnicos para desarrollar y mantener software (requisitos, codificación, pruebas, diseño, etc.)

Empresa y mercado 248

En este punto es interesante diferenciar entre marco o modelo de procesos y técnica o base de conocimiento técnico.

La primera línea tiene como objetivo fijar qué es lo que hay que hacer para ofrecer garantías en los proyectos, y la segunda cómo debe realizarse. Un marco de procesos determinará, por ejemplo, la necesidad de gestionar adecuadamente las modificaciones de requisitos, o de realizar un diseño detallado antes de comenzar la codificación. El

valor de los modelos de procesos radica en el conocimiento que aportan al señalar las actividades cuya omisión incrementa las

posibilidades de fracaso en los proyectos. Sin embargo el marco de procesos no dirá, por ejemplo, que deba emplearse un sistema basado en documentos o en base de datos para la gestión de los requisitos; o si el diseño debe realizarse con diagramas IDEF o UML.

Este es el campo de la técnica de la ingeniería del software. En la línea de los modelos de procesos (qué cosas hay que hacer) a partir de finales de los 80 se comenzaron a desarrollar marcos específicos para el software, para dar la cobertura necesaria a las particularidades de nuestro producto, donde las normas generales se quedaban cortas.

En esta línea ISO 9000 desarrolló una norma específica para el software: ISO 9000-3, y la BSI (British Standards Institution) hizo lo propio desarrollando TickIT. En esta primera aparición de estándares surgieron también,

aunque con menor repercusión: Trillium y Bootstrap. El primero desarrollado por la empresa Bell Canadá, que liberó sus derechos, haciéndolo de dominio público. Bootstrap es una metodología para la evaluación, medición y mejora de los procesos de software. Su desarrollo lo llevó a cabo una comisión del ESPRIT (European Strategic Program for

Research).

Sin embargo las dos líneas que surgieron a principios de los 90 y que continúan como referentes en la actualidad son. CMM, y las normalizaciones de ISO 12207 y 15504.

CMM

SEI (Software Engineering Institute), un auténtico peso pesado

en la normalización de los procesos del software, desarrolló su línea de trabajo sobre el concepto de “madurez” de las organizaciones para producir software.

Empresa y mercado 249

Por madurez se entiende la capacidad que tiene la organización para asegurar la calidad de sus proyectos (fecha, coste y funcionalidad), la homogeneidad (siempre y en todos sus

proyectos) y la capacidad de aprendizaje de sus propia experiencia y su aplicación en la mejora continua. Como resultado de estas líneas de trabajo, en 1990 publicó el modelo de madurez de la capacidad para el desarrollo de software (CMM-SW), que tras más de una década de existencia

ha demostrado que en muchas organizaciones ha resultado eficaz.

Este modelo crea una escala de cinco niveles para determinar la madurez de una organización.

Nivel 1.- INICIAL Pertenecen a él las empresas que no basan el desarrollo en

procesos definidos, y no aplican técnicas de gestión de proyectos. El modelo se refiere a entornos de producción caóticos con técnicas de programación heroica cuyos resultados no son predecibles y dependen exclusivamente de la valía de las personas.

Nivel 2.- REPETIBLE.

Define a las organizaciones que aplican técnicas de gestión de proyectos, aunque no dispongan de procesos definidos.

Nivel 3.- DEFINIDO Pertenecen a él las organizaciones que disponen de procesos definidos con precisión y ejecutados de forma regular. Las empresas con este nivel de madurez examinan la experiencia

de los proyectos que realizan y emplean las lecciones aprendidas para mejorar sus procesos.

Nivel 4.- GESTIONADO En el cuarto nivel de madurez se sitúan las organizaciones

que han depurado el análisis de los proyectos realizados, hasta institucionalizarlo como procesos que miden cuantitativamente la capacidad de los procesos de desarrollo,

de forma que pueden predecir de forma cuantificable los resultados, y evaluar las mejoras con mediciones objetivas.

Nivel 5.- OPTIMIZADO Las organizaciones con un nivel 5 de madurez tienen definidos, y practican de forma institucionalizada, procesos de mejora continua que se nutren con la información cuantificada de los procesos del nivel 4.

Empresa y mercado 250

Tras el desarrollo del modelo SW-CMM, surgieron otros para la medición y mejora de la capacidad de los procesos, todos ellos centrados en áreas relacionadas con el foco original del SW-

CMM: el desarrollo de software:

Systems Engineering Capability Maturity Model (SE-CMM)

Integrated Product Development Capability Maturity Model (IPD-CMM)

People Capability Maturity Model (P-CMM)

Software Acquisition Capability Maturity Model (SA-CMM)

En 2000 el modelo SW-CMM se actualizó en otro que facilitaba su implantación de forma conjunta y simultánea con otros modelos (SE-CMM o IPD-CMM). Fue el nuevo modelo CMMI (Capability Maturity Model Integration). En la actualidad hay varios modelos CMMI, en función de las

áreas que integran

CMMI-SE/SW/IPPD/SS (Systems Engineering, Software Engineering, Integrated Product and Process Development, Supplier Sourcing).

CMMI-SE/SW/IPPD (Systems Engineering, Software Engineering, Integrated Product and Process Development).

CMMI-SE/SE (Systems Engineering, Software Engineering)

Además de la integración de varias disciplinas, los modelos CMMI introdujeron otra novedad que afectaba a su implantación: CMMI al igual que CMM tiene dos utilidades. Puede servir tanto como guía para la mejora en una organización, o como criterio para evaluar su nivel; pero mientras CMM centraba estas dos

finalidades en la dimensión de la madurez de la organización, CMMI introduce una segunda dimensión, también válida para

guiar las actividades de mejora y para evaluar a las organizaciones: la capacidad de los procesos. CMMI establece 6 niveles para determinar la capacidad de un proceso:

Nivel 0.- INCOMPLETO El proceso no se realiza.

Nivel 1.- REALIZADO Se lleva a cabo el proceso, consiguiendo transformar elementos de entrada identificados, en productos de salida.

Empresa y mercado 251

Nivel 2.- GESTIONADO El proceso se ejecuta siempre de la misma manera, de una forma gestionada.

Nivel 3.- DEFINIDO El proceso está definido en la organización y se ejecuta siempre.

Nivel 4 CUANTIFICADAMENTE GESTIONADO La ejecución del proceso tiene institucionalizado en la

organización un sistema de medición objetivo y cuantificable

de su capacidad.

Nivel 5.- OPTIMIZADO El proceso, que se ejecuta siempre, está definido en la organización, se mide y está integrado en un plan, también institucionalizado, de mejora continua basada en las mediciones de los procesos.

De esta forma los modelos CMMI presentan 2 versiones:

Versión escalonada. Guía a la organización sobre las áreas de procesos que debe ir abordando, las prácticas que debe implantar y los objetivos que debe alcanzar para ir

consiguiendo los sucesivos niveles de madurez.

Versión continua. Permite cierta libertad a la organización

sobre las áreas de proceso que desea mejorar, y le orienta para ir elevando su nivel de capacidad.

Consecuentemente al evaluar a una organización se puede hacer sobre la dimensión de su madurez, estableciendo cuál es el nivel que ha alcanzado, o sobre la dimensión de la capacidad,

reflejando cuál es el nivel de cada una de las áreas de proceso contempladas por el modelo.

Mientras SEI publicaba y comenzaba a definir su modelo

CMM, ISO emprendía los otros dos proyectos que hoy forman los principales puntos de referencia en el ámbito de la calidad para nuestra industria: ISO 12207 e ISO 15504.

ISO/IEC 12207

Es el estándar internacional que ha determinado cuál es el ciclo de vida de un proyecto de software, y cuáles los procesos y tareas que intervienen en cada una de sus fases.

Empresa y mercado 252

A grandes rasgos, 12207 concluyó considerando que el ciclo de vida de un sistema de software comienza en el momento que se concibe su idea o necesidad. Momento en el que ya es necesario comenzar a actuar de manera ortodoxa para describir el ámbito del problema, las

soluciones posibles, etc.

El ciclo de vida comprende también el desarrollo, mantenimiento y operación y no concluye hasta que el sistema deja de utilizarse y es definitivamente retirado.

SPICE – ISO/IEC STD. 15504.

En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo para el desarrollo de un modelo que fuera la base de un futuro estándar internacional para la evaluación de los procesos del ciclo de vida del software.

Empresa y mercado 253

Este trabajo recibió el nombre de proyecto SPICE (Software Process Improvement and Capability dEtermination), y en junio de 1995, con la publicación de su primer borrador, desde ISO

fueron invitadas diferentes organizaciones para aplicarlo y valorar sus resultados. En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pasó a la fase de informe técnico con la denominación ISO/IEC TR 15504. La instrucción técnica consta de 9 apartados, recogidos en

volúmenes independientes, que se han ido publicando como redacción definitiva del estándar internacional ISO/IEC 15504

durante el periodo 2003-2005. Aunque ISO comenzó con el proyecto SPICE algo más tarde que SEI con el modelo CMM, durante su evolución han ido convergiendo, y ambas instituciones vienen trabajando de forma

conjunta desde 1998 para lograr la compatibilidad que finalmente han garantizado entre el modelo CMMI y el estándar 15504, de forma que la conformidad con uno de ellos implica la también conformidad con el otro. El estándar está recogido en 9 documentos.

1.- (informativo) Conceptos y guía de introducción.

2.- (normativo) Modelo de referencia de los procesos y de su capacidad. 3.- (normativo) Ejecución de las auditorías. 4.- (informativo) Guía para la realización de auditorías. 5.- (informativo) Modelo de asesoría e indicadores. 6.- (informativo) Guía de formación de consultores.

7.- (informativo) Guía para usar en los procesos de mejora. 8.- (informativo) Guía para determinar la capacidad de los procesos del proveedor. 9.- (normativo) Vocabulario.

ISO/IEC 15504, al igual que CMMI es un modelo para evaluar los

procesos de la organización y determinar si resultan efectivos

para conseguir los objetivos. También es un modelo para guiar las acciones de mejora de los procesos. 15504 tiene gran similitud con la representación continua de CMMI. Al igual que este último centra el foco en la capacidad de los procesos, y permite trabajar sólo con una parte de ellos en lugar de hacerlo con todos los de la organización.

ISO 15504 agrupa los procesos de las organizaciones de software en cinco categorías:

Empresa y mercado 254

Cliente – proveedor

Ingeniería

Soporte

Gestión

Organización Y para la medición de cada proceso define una escala de 6 niveles

0 Proceso incompleto

1 Proceso realizado

2 Proceso gestionado

3 Proceso establecido

4 Proceso predecible

5 Proceso optimizado.

ISO 15504 y CMMI son los referentes de las metodologías formales. Para ambos el centro de su desarrollo son los

procesos, no sólo para el desarrollo, mantenimiento y operación de los sistemas de software, sino también para mejorar la capacidad de los propios procesos y la madurez de las organizaciones.

Empresa y mercado 255

Modelos nuevos sobre una profesión recién estrenada El uso de modelos de procesos y calidad para asegurar la

eficiencia, aptitud y consistencia en los resultados, y para asentar pautas de mejora continua, es relativamente novedoso, y lo habitual es aplicar estos marcos sobre entornos de fabricación, con conocimientos profesionales ya maduros. El software, sin embargo, es una industria que trabaja con un

conocimiento profesional escasamente asentado. Y a la aparición de marcos y modelos de calidad se suma el movimiento paralelo

de propuestas de currículos profesionales. La profesionalización exige:

Disponer de una base de conocimiento, desarrollada con metodología científica, y contrastada con la experiencia.

Consenso y aceptación por la comunidad que ejerce la profesión.

Desarrollo de de currículos profesionales, que gracias al consenso resulten homogéneos sobre centros de formación, universidades y países diferentes.

Desarrollo de las organizaciones académicas y profesionales de autorregulación.

Con este esquema se podrá estar más o menos de acuerdo, pero es el que emplea la sociedad para dar el rango de profesión a los trabajos no regulados. Para cambiar el título de curandero por el de médico, el de sacamuelas por odontólogo, o el de alquimista por el de químico.

Empresa y mercado 256

(Gary Ford y Norman Gibbs 1996)

En esta línea han estado trabajando un buen número de organizaciones profesionales, agrupados en el proyecto SWEBOK (Software Engineering Body Of Knowledge http://www.swebok.org)

Su objetivo ha sido asentar de forma consensuada la base de conocimiento necesaria para el currículo de un ingeniero de software. Primer paso para lograr un entorno profesional,

socialmente reconocido. El trabajo de este proyecto comenzó en 1998, y la publicación de la primera versión, consensuada por todos los participantes, se produjo en Febrero de 2004.

Esto da una idea de lo tierna que está la profesión. O mejor dicho, de que se trata de una profesión no asentada.

La heterodoxia: métodos ágiles Ya hemos visto que a la relativa novedad de gestión por procesos, en nuestra industria se suma como dificultad adicional

el producirse de forma simultánea al asentamiento de la profesión. Y para conseguir el “más difícil todavía”, hay que contar con una tercera tendencia de normalización. O, quizá habría que llamarla de des-normalización:

Empresa y mercado 257

Los métodos ágiles.

A finales de los 90, reputados profesionales con renombre y eco

en diferentes foros técnicos, comenzaron a cuestionar las metodologías formales, que representadas por CMM e ISO 15504, y respaldadas por la autoridad y los medios de sus respectivas organizaciones, estaban configurando una ingeniería del software basada en los procesos.

En marzo de 2001, 17 críticos de estos modelos, convocados por Kent Beck, que acababa de definir una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake

City para discutir sobre los modelos de desarrollo de software. En la reunión se acuñó el término “Métodos Ágiles” para definir a aquellos que estaban surgiendo como alternativa a las metodologías formales, a las que consideraban excesivamente

“pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo. Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto Ágil”, que compendia el espíritu en el que se basan estos métodos:

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

A los individuos y su interacción por encima de los procesos y las herramientas El software que funciona, por encima de la documentación exhaustiva. La colaboración con el cliente, por encima de la negociación contractual.

La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Manifiesto ágil Los firmantes afirman que los puntos de su manifiesto se sustentan en 12 principios:

1. Nuestra principal prioridad es satisfacer al cliente a

través de la entrega temprana y continua de software de valor.

2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se

Empresa y mercado 258

doblegan al cambio como ventaja competitiva para el cliente.

3. Entregar con frecuencia software que funcione, en

periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.

4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.

5. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que

necesitan y procurándoles confianza para que realicen la tarea.

6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.

7. El software que funciona es la principal medida del progreso.

8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica enaltece la agilidad.

10. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.

12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

El manifiesto ágil surgió con espíritu de respuesta desafiante y beligerante contra los métodos basados en procesos. Los propios integrantes del manifiesto se auto-califican como

“anarquistas organizacionales”, y en estos años, desde uno y

Empresa y mercado 259

otro lado se han lanzado argumentos punzantes buscando más la descalificación ajena que la justificación propia.

Los principales métodos ágiles son

DSDM (Dynamic Systems Development Method)

Es la metodología más veterana de las auto-denominadas ágiles. Surgió en 1994 de los trabajos de Jennifer Stapleton, la actual

directora del DSDM Consortium.

DSDM es la metodología ágil más próxima a los métodos formales, de hecho la implantación de un modelo DSDM en una organización la lleva a alcanzar lo que CMM consideraría un nivel 2 de madurez. Sin embargo los aspectos que DSDM reprocha a CMM son:

Aunque es cierto que se ha desarrollado con éxito en algunas organizaciones, lo que funciona bien en unos entornos no tiene por qué servir para todos.

CMM no le da al diseño la importancia que debería tener.

CMM plantea un foco excesivo en los procesos, olvidando la

importancia que en nuestra industria tiene el talento de las personas.

El tener procesos claramente definidos no es sinónimo de tener buenos procesos.

En común con los métodos ágiles, DSDM considera imprescindible una implicación y una relación estrecha con el cliente durante el desarrollo, así como la necesidad de trabajar

con métodos de desarrollo incremental y entregas evolutivas. DSDM cubre los aspectos de gestión de proyectos, desarrollo de los sistemas, soporte y mantenimiento y se autodefine como un

marco de trabajo para desarrollo rápido más que como un método específico para el desarrollo de sistemas.

Empresa y mercado 260

Extreme Programming

Este es el método que más popularidad ha alcanzado entre las

metodologías ágiles, y posiblemente sea también el más transgresor de la ortodoxia basada en procesos. Su creador, Kent Beck fue el alma mater del Manifiesto Ágil. Extreme Programming (XP) se irgue sobre la suposición de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asunción es

que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha

atrás demasiado tarde. Cuatro son los valores que lo inspiran: simplicidad, feedback, coraje y comunicación.

XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12 prácticas que se complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en los cuatro valores citados: Comunicación XP pone en comunicación directa y continua a clientes y

desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la agenda y las funcionalidades de forma consecuente. Feedback rápido y continuo

Una metodología basada en el desarrollo incremental de pequeñas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones. De esta forma fallos se localizan muy pronto. La planificación no puede evitar algunos errores, que sólo se

evidencian al desarrollar el sistema.

La retro-información es la herramienta que permite reajustar la agenda y los planes. Simplicidad La simplicidad consiste en desarrollar sólo el sistema que realmente se necesita. Implica resolver en cada momento sólo las necesidades actuales.

“Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro.” Con este principio de simplicidad, junto con la comunicación y el feedback resulta más fácil conocer las necesidades reales.

Empresa y mercado 261

Coraje El coraje implica saber tomar decisiones difíciles. Reparar un

error cuando se detecta. Mejorar el código siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora. Tratar rápidamente con el cliente los desajustes de agendas para decidir qué partes y cuándo se van a entregar.

Las 12 prácticas que aplicadas sobre esta cultura conforman Extreme Programming son:

PRÁCTICAS DE CODIFICACIÓN 1.- Simplicidad de código y de diseño para producir software fácil de modificar. 2.- Reingeniería continua para lograr que el código tenga un

diseño óptimo. 3.- Desarrollar estándares de codificación, para comunicar ideas con claridad a través del código. 4.- Desarrollar un vocabulario común, para comunicar las ideas sobre el código con claridad. PRÁCTICAS DE DESARROLLO

1.- Adoptar un método de desarrollo basado en las pruebas para asegurar que el código se comporta según lo esperado. 2.- Programación por parejas, para incrementar el conocimiento, la experiencia y las ideas. 3.- Asumir la propiedad colectiva del código, para que todo el equipo sea responsable de él.

4.- Integración continua, para reducir el impacto de la incorporación de nuevas funcionalidades. PRÁCTICAS DE NEGOCIO 1.- Integración de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del sistema de forma directa,

sin retrasos o pérdidas por intermediación.

2.- Adoptar el juego de la planificación para centrar en la agenda el trabajo más importante. 3.- Entregas regulares y frecuentes para satisfacer la inversión del cliente. 4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.

SCRUM

Empresa y mercado 262

No es propiamente un método o metodología de desarrollo, e implantarlo como tal resulta insuficiente. Scrum define métodos de gestión y control para complementar la

aplicación de otros métodos ágiles como XP que, centrados en prácticas de tipo técnico, carecen de ellas. Los principios de Scrum son:

Equipos autogestionados.

Una vez dimensionadas las tareas no es posible agregarles

trabajo extra.

Reuniones diarias en las que los miembros del equipo se plantean 3 cuestiones:

¿Qué has hecho desde la última revisión?

¿Qué obstáculos te impiden cumplir la meta?

¿Qué vas a hacer antes de la próxima reunión?

Iteraciones de desarrollo de frecuencia inferior a un mes, al

final de las cuales se presenta el resultado a los externos del equipo de desarrollo, y se realiza una planificación de la siguiente iteración, guiada por cliente.

OTROS MÉTODOS ÁGILES

Familia de métodos Crystal

La familia de metodologías Crystal ofrece diferentes métodos para seleccionar el más apropiado para cada proyecto. Crystal identifica con colores diferentes cada método, y su elección debe ser consecuencia del tamaño y criticidad del proyecto, de forma que los de mayor tamaño, o aquellos en los

que la presencia de errores o desbordamiento de agendas implique consecuencias graves, deben adoptar metodologías más pesadas. Los métodos Crystal no prescriben prácticas concretas, y se pueden combinar con técnicas como XP.

ASD (Adaptative Software Development)

Método que como alternativa a los procedimientos formales, aborda el desarrollo de grandes sistemas con el uso de técnicas propias de las metodologías ágiles.

Empresa y mercado 263

No se trata de una metodología, sino de la implantación de una cultura en la empresa, basada en la adaptabilidad.

PP (Pragmatic Programming)

Pragmatic Programming es la colección de 70 prácticas de programación, comunes a otros métodos ágiles, cuya aplicación resulta útil para solucionar los problemas cotidianos.

AM (Agile Modeling)

Agile Modeling es la presentación de un nuevo enfoque para realizar el modelado de sistemas,(diseño) y basado en los principios de los métodos ágiles remarca la conveniencia de reducir el volumen de la documentación.

ISD (Internet-Speed Development)

Es el más reciente de los métodos ágiles, surgido como respuesta para las situaciones que requieren ciclos de desarrollo muy breves con entregas rápidas. Se centra en el talento de las personas sobre los procesos. ISD es un entorno de gestión orientado al negocio.

FDD (Feature Driven Development)

Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas. El punto de referencia son las características que debe reunir el software, y se centra en las fases de diseño e implementación del sistema.

Empresa y mercado 264

MÉTODOS DE PROPIEDAD COMERCIAL

MSF (Microsoft Solutions Framework)

MSF es la metodología empleada por Microsoft para el desarrollo de software. Hasta su versión 3 (principios de 2005) MSF se definía como un marco de desarrollo flexible para adaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodología prescriptiva; porque parte de la base de que no hay una

estructura de procesos óptima para las necesidades de todos los entornos de desarrollo posibles.

El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entorno de desarrollo:

Fomento de la comunicación abierta.

Trabajo en torno a una visión compartida.

Apoderar a los integrantes del equipo (“empowerment”)

Establecimiento de responsabilidades claras y compartidas.

Centrar el objetivo en la entrega de valor para el negocio.

Permanecer ágiles y esperar e cambio.

Invertir en calidad.

Aprender de la experiencia.

Para la aplicación de estos principios en los procesos y en las personas, MSF define un Modelo de Equipo y un Modelo de Procesos. Sobre los Modelos, y trabajando con la cultura de sus Principios Fundamentales, las Disciplinas que establece para

el desarrollo del software son:

Gestión de proyectos.

Gestión de riesgos.

Gestión de la mejora del talento. Si bien, MSF despliega la gestión de proyectos y la gestión de riesgos con algunas diferencias sobre las visiones clásicas de

estas áreas.

Empresa y mercado 265

El marco de desarrollo incluye también Conceptos Clave, Prácticas Contrastadas y Recomendaciones para la ejecución de las tareas concretas en el desarrollo de software.

En 2005, el desarrollo del nuevo producto de Microsoft “Visual Studio 2005 Team System” ha generado la evolución de MSF hacia la nueva versión 4.0 con dos líneas paralelas:

Microsoft Solutions Framework (MSF) for Agile Software Development.

Microsoft Solutions Framework (MSF) for CMMI Process

Improvement.

RUP (Rational Unified Process)

Es un proceso de Ingeniería del Software que proporciona una visión disciplinada para la asignación de tareas y responsabilidades en las organizaciones de desarrollo de

software. RUP es un “modelo-producto” desarrollado y mantenido por Racional Software, integrado en su conjunto de herramientas de desarrollo, y distribuido por IBM. RUP integra un conjunto de “buenas prácticas” para el desarrollo

de software en un marco de procesos válido para un rango amplio de tipos de proyectos y organizaciones.

Las principales buenas prácticas cubiertas son:

Desarrollo iterativo.

Gestión de requisitos.

Uso de arquitecturas basadas en componentes.

Uso de técnicas de modelado visual.

Verificación continua de la calidad.

Gestión y control de cambios.

En su visión estática, el modelo RUP está compuesto por:

Roles: analista de sistemas, diseñador, diseñador de pruebas, roles de gestión y roles de administración.

Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto debe tener un

propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de horas o de algunos días; y son elementos base de planificación y progreso.

Empresa y mercado 266

Artefactos: Son los elementos de entrada y salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto

final (modelos, documentos, código, ejecutables…)

Disciplinas: son “contenedores” empleados para organizar las actividades del proceso. RUP comprende 6 disciplinas técnicas y 3 de soporte. Técnicas: modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo.

Soprte: gestión de proyecto, gestión de configuración y cambio, y entorno.

Flujos de trabajo: son el “pegamento”de los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.

En su visión dinámica, la visión de la estructura del ciclo de vida

RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo. Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP:

1.- Inicio. Es la fase de la idea, de la visión inicial de producto,

su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el “hito de objetivo”. 2.- Elaboración. Comprende la planificación de las actividades y del equipo necesario. La especificación de las necesidades y el diseño de la arquitectura. Termina con el “hito de Arquitectura”.

3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el “hito del inicio de la capacidad operativa”.

4.- Transición. Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el mantenimiento

hasta lograr la satisfacción de los usuarios. Termina con el “hito de entrega del producto”.

Empresa y mercado 267

Métodos ortodoxos y métodos ágiles Se dice que hay dos formas de abordar los proyectos:

1.- Dedicar escaso tiempo a la preparación y planificación, e invertir la mayor parte del tiempo en el desarrollo, probando y rectificando hasta conseguir el resultado adecuado. 2.- Invertir mucho tiempo y esfuerzo en la preparación y planificación para conseguir que el desarrollo se ejecute en el menor tiempo y con los menores incidentes posibles.

Aunque sin duda esta es una visión simplificada, refleja las

diferencias entre los modelos ortodoxos, o basados en procesos, y las metodologías ágiles; así como las razones de su desencuentro. Los métodos formales (CMMI, ISO15504) abogan por el segundo

modelo y basan el éxito del proyecto en la planificación y el rigor normativo en los procesos de su desarrollo. Hacen especial hincapié en la importancia de los requisitos para conocer con el mayor detalle el sistema antes de comenzar a construirlo, y en las prácticas formales de la gestión de proyectos, para trabajar sobre una planificación previa, y controlar su seguimiento.

Para estos modelos, se alcanza mayor nivel de madurez, cuantas más actividades del ciclo de vida del sistema de software se realicen según los procesos previamente diseñados e implantados en la organización. Por otra parte, y con mayor o menor proximidad al extremo

contrario, se encuentran las denominadas metodologías ágiles, que tienen como común denominador un modelo de desarrollo incremental para producir tempranamente pequeñas entregas en ciclos rápidos, y predisposición para el cambio y la adaptación continua; según sea la conformidad o no de lo producido, y las modificaciones propuestas por los usuarios.

Aparte de esta base común, también comparten menor rigidez

en los procesos, aunque las diferencias en este punto son significativas entre cada método. Considerar que hay dos formas de realizar los proyectos es una visión simplificada, pero refleja el hecho de que en la realidad, cada técnica se define en uno u otro bando, y con mayor o menor proximidad del extremo.

Los métodos formales llevados hasta su máximo nivel de madurez se situarían en el extremo de la ortodoxia, (lado izquierdo de la fig.) si bien es cierto que las representaciones

Empresa y mercado 268

continuas de estos modelos permiten adoptar sólo las prácticas para determinadas áreas de procesos, y llevarlos hasta el nivel de capacidad que se estime oportuno, por lo que un conocedor

del modelo puede emplearlo como guía para realizar una implantación relativamente ágil, más o menos adecuada a las características de la organización.

Los métodos ágiles se sitúan más o menos cerca del extremo opuesto. Los más extremistas (quizá PP o XP) por la no utilización o incluso aversión a los procesos, se encuentran más en la categoría de prácticas de programación, o técnicas de

trabajo (cómo hacer las cosas) que en la de modelos de procesos

(qué cosas hay que hacer) La circunstancia más o menos marcada en cada caso de “oposición” entre métodos ágiles y métodos formales, puede inducir al error de considerar a todos ágiles como similares o equivalentes.

En el lado opuesto sí que ocurre, y las similitudes entre CMMI e ISO 15504 son notables, pero con los ágiles ocurre sin embargo que los niveles de reconocimiento y rigor alcanzan diferencias notables entre ellos, así como la cobertura que llegan a alcanzar

sobre determinadas áreas de procesos.

Empresa y mercado 269

El oficio del gestor Con lo visto hasta ahora tenemos ya el mapa de situación.

No es que sea importante conocerlo. Es necesario para no andar desorientados entre los árboles, y tener la visión del bosque en su conjunto. Ya solo queda trazar la ruta y guiar el camino. ¡Casi nada!. Pero nadie ha dicho que la gestión de entornos de desarrollo de

software sea fácil. Basta con echar un vistazo a nuestro alrededor.

El mayor o menor grado de éxito en la calidad y eficiencia en el desarrollo de software depende del equilibrio que se consiga al conjugar los siguientes factores:

Características de los proyectos de software gestionados.

Visión de la organización.

Cultura de la organización.

Diseño y gestión del equilibrio productivo personas-procesos-tecnología.

Características de los proyectos de software.

El concepto sistema de software es muy amplio, y tan sistema de software es el integrado en un teléfono celular, como el desarrollado en un proyecto Open Source por iniciativa del propio grupo de desarrolladores; o el diseñado para asistir el pilotaje de un avión comercial.

En algunos casos se tratará de gestionar una normativa contable u otro negocio o entorno suficientemente conocido en el que un proceso formal de requisitos inicial puede capturar con bastante

detalle todas las funcionalidades esperadas. En otros, la novedad o complejidad del entorno en el que se integrará el sistema, hacen difícil, si no imposible descubrir qué debe hacer el software si no es a través de prototipado o

desarrollo evolutivo. El tamaño también importa. Un sistema puede requerir el esfuerzo de un programador durante un par de meses, o de un equipo de varias decenas de personas durante un par de años. Por las características del proyecto quizá la funcionalidad

alcanzada en cada versión, así como la precisión en el

Empresa y mercado 270

cumplimiento de las fechas puede ser poco trascendente o vital para el negocio del cliente. En este aspecto, la diferencia de criticidad entre el desarrollo de

un sistema open source sin ánimo de lucro, o de un sistema de gestión para una empresa que depende de él para abrir su negocio, es muy diferente. El nivel de integridad del sistema, o daño que pueden producir los fallos del sistema, también determina el rigor de los procesos

que deben aplicarse en su desarrollo. Un error en el aplicativo de una entidad bancaria puede suponer pérdidas económicas o de

imagen que comprometan la continuidad de su negocio. Errores en otros sistemas pueden producir pérdidas humanas. La presencia de errores en la página web de un pequeño comercio tiene repercusiones de menor alcance.

Visión, misión y negocio de la organización.

Las preguntas relativas a la organización que ayudan a diseñar el aludido equilibrio son: ¿Para qué desarrolla software la organización? ¿Es una empresa con un producto definido que debe dar

beneficios?

¿Es el departamento de sistemas de una entidad bancaria que centra su misión en la seguridad? ¿Es una asociación de ingenieros para el desarrollo de un proyecto open source? Para alcanzar su misión, ¿Qué papel juega la innovación y

vanguardia tecnológica? ¿Se dedican a mantener operativos sistemas ya desarrollados? ¿Programan sistemas poco innovadores, sobre plataformas contrastadas, para negocios y entornos conocidos? ¿Apuesta por la innovación, implementación sobre dispositivos

nuevos, o diseñan soluciones para entornos novedosos?

Cultura de la organización

¿Se trata de una organización con niveles jerárquicos y funciones claramente definidos? ¿Cuáles son los niveles de confianza, delegación, empowerment y responsabilidad?

¿Clima laboral, motivación?

Empresa y mercado 271

Diseño y gestión del equilibrio productivo personas-procesos-tecnología

La estrategia productiva. ¿Qué tecnología emplea para el desarrollo? Equipos, red,

sistemas de pruebas, plataformas operativas, plataformas de desarrollo, pruebas, herramientas CAD…? ¿Qué porcentaje o peso del conocimiento necesario para la ejecución de los proyectos lo garantizan la ejecución de los procesos, y cuánto las personas?

¿Son coherentes las políticas o procesos de formación,

contratación, planes de carrera, diseño del modelo de procesos, calidad y mejora…? El éxito: ¿Gestión o azar?

“Para todo problema complejo hay siempre una solución simple,

que es errónea”

George Bernard Shaw

Cuando se desconocen las variables que actúan sobre un sistema, y su influencia, se habla de que presenta un comportamiento aleatorio (“caótico”).

Por definición, no es posible predecir cuáles serán los resultados al actuar sobre un entorno caótico. La acción externa modificará algunas variables, pero al no saber

cuántas más están actuando, y cuál es su repercusión, no se pueden predecir los resultados. Cuantas más variables se conocen, éste se va tornando más predecible y menos caótico, como ha ido ocurriendo, por ejemplo, en las últimas décadas con la predicción meteorológica. La diferencia entre un sistema caótico y un sistema complejo es

que en el primero son tantas las fuerzas que actúan que resulta materialmente imposible predecir su resultado (Ej: comportamiento de las bolas en un bombo).

En sistemas complejos, aunque son varias las fuerzas, sí que resulta posible su conocimiento, o el conocimiento de las más relevantes, y actuar con probabilidades de certidumbre muy

altas sobre las consecuencias. Desde este punto de vista, un entorno de desarrollo de software es un sistema complejo en el que se pueden combinar y poner en interacción múltiples elementos, y con diferentes pesos y formas de gestión (Véanse en el artículo los modelos y técnicas que pueden conjugarse, y los factores que apuntan las preguntas del apartado anterior).

Empresa y mercado 272

Aunque sobre los sistemas complejos, a diferencia de los aleatorios, sí es posible actuar con factores de predecibilidad elevados, si desconocemos su ecuación de fuerzas, se presentan

de comportamiento tan aleatorio como los sistemas caóticos. Para ser más exactos en esta apreciación, lo cierto es que un sistema complejo parece caótico, a quien desconoce cuáles son sus variables y su relación, pero esto no es muy frecuente que ocurra, ya que si alguien sabe que hay variables aprehensibles y que conociéndolas podrá actuar con mayor seguridad, no es

normal que continúe jugando al azar. El hombre, por su naturaleza necesita seguridad, y si sabe que

las reacciones de un sistema responden a un mecanismo más o menos complejo, no es normal que prefiera ignorarlo. Por eso el error más habitual consiste en actuar bajo el fenómeno de la “superstición”, tomando como referencia

variables falsas, o creyendo que son tan sólo una o dos las fuerzas que deciden el comportamiento del sistema. De esta forma, al igual que el jugador de ruleta supersticioso se aferra a su camisa de la suerte, por la razón de que le dio un par de noches afortunadas, un gestor se puede aferrar a determinadas prácticas de gestión, porque una vez funcionaron con éxito, o porque el último libro de management las considera

“mano de santo”. Por este camino también puede acabarse maldiciendo la ruleta, perdón, la gestión; cayendo en el escepticismo sobre los consultores, las teorías de management, de comportamiento organizacional, los modelos de calidad, etc.

Porque claro, uno siempre hace las cosas bien. Por eso si los resultados salen mal el problema está fuera de él.

Empresa y mercado 273

Conclusiones Para diseñar y gestionar entornos de producción eficientes se

debe trabajar con pensamiento sistémico, comprendiendo que todos los factores implicados en la producción de software componen un sistema interrelacionado, imbricado y alineado con la misión de la organización. Lo contrario, y probablemente más habitual consiste en actuar

desde una visión fáctica e inmediata, buscando relaciones lineales causa–efecto, sin apreciar la relación y armonía del

sistema, que las integra y les da sentido (y que no se ciñe al área de desarrollo, sino a la organización en su conjunto). No se trata por tanto de conocer cuál es la mejor metodología para el diseño de bases de datos, cuál el mejor modelo de

procesos o cuáles las mejores técnicas de gestión de recursos humanos. La multiplicidad de técnicas, modelos, herramientas, modos de gestión, es consecuencia de la diversidad de organizaciones y tipos de proyectos posibles.

Evitar la gestión lineal El error habitual es trabajar con gestión lineal y a-sistémica, administrando soluciones sintomáticas para cada situación.

La gestión lineal, carece de la perspectiva necesaria, y responde de forma azuzada a la presión del día a día. Sin esa perspectiva no se ve el sistema, y el marco de trabajo se presenta como un campo de batalla desordenado que requiere actuaciones en cada uno de los frentes que presenta.

Si los proyectos se retrasan será preciso sugerir, animar o

presionar a las personas (allá cada cual con el estilo de gestión que aplique) para que alarguen sus jornadas de trabajo, o restrinjan los tiempos de café… Si programamos con mayores costes que nuestra competencia, habrá que contener los salarios, o contratar más barato, o aplicar procesos de calidad para reducir los tiempos, o…

(también aquí cada cual sintonizará mejor con unas u otras decisiones.). Etcétera.

Empresa y mercado 274

Para cada necesidad se abre el botiquín, y se busca un apaciguador de síntomas.

Las soluciones obvias no funcionan. En el mejor de los casos introducen mejoras en el corto plazo que terminarán por empeorar la situación. La presión del día a día ofrece dos atajos muy tentadores que se

deben evitar:

Aplicar soluciones enfocadas en resultados en el corto plazo.

Obtener mediciones y datos que demuestren un buen comportamiento.

Con carácter general, las soluciones a corto, hipotecan el futuro. son sintomáticas, y generan resistencia, de forma que la próxima vez que se vuelva a generar un problema similar, el remedio sintomático tendrá menos eficacia. Cerrar rápido un proyecto, hará más duro su mantenimiento (sistema peor diseñado, mayor densidad de errores…).

Presionar a los programadores para cumplir fechas es también una solución a corto, que no ofrece soluciones a largo. Si se mantiene la presión como una norma, generará desmotivación y degradación en la calidad de lo producido. Las mediciones sobre los procesos son una herramienta útil para

comprender el funcionamiento general del sistema y trabajar en su mejora. Emplearlas como justificación ante instancias superiores, es también una búsqueda de la solución a corto, interesada en que las cosas pinten bien. De esta forma las organizaciones pueden llegar a agonizar con una apariencia de salud envidiable.

Gestión sistémica La eficiencia es el resultado de la idoneidad y equilibrio de todos los componentes de la producción. ¿Cuál es el mejor modelo de procesos para el desarrollo de

software? ¿La cultura de empresa más adecuada? ¿Las mejores técnicas de gestión de RR.HH:? ¿Las mejores plataformas de programación?

Empresa y mercado 275

Para la gestión de las personas, los procesos y la tecnología, no hay métodos simples, absolutos con resultados inmediatos.

Un modelo de procesos CMMI con nivel 5 de madurez puede garantizar resultados en línea con la misión de una gran empresa integradora de grandes sistemas críticos, pero resulta excesivamente pesado para una “Start-up” de diseño web.

El modelo “bueno” no es Scrum, o CMMI o XP, sino el que mejor encaje en su sistema.

Las técnicas empleadas, los modelos de calidad, la tecnología, la cultura de la empresa, la gestión de las personas… deben guardar coherencia, de forma que se potencien, y no se contrarresten.

Un “know-how” adecuado, basado en el conocimiento tácito de las personas, compaginado con equipos desmotivados no es una buena combinación. Un método ágil puede resultar idóneo para el tamaño de equipos y de empresa, pero si sus procesos no cubren las facetas contractuales de la adquisición, generará problemas en la

validación del producto. A modo de síntesis, las claves para conseguir organizaciones eficientes de desarrollo de software son:

Personalidad de la organización.

Esta es la referencia final con la que deben alinearse y sincronizarse todas las variables que operan juntas para lograr los objetivos. Cuanto más nítida sea la visión, misión, estrategia, segmento y objetivos de la organización, con mayor atino y precisión se podrán imbricar los componentes

del sistema y orientar la gestión de su funcionamiento.

Conocimiento de la propia empresa.

Sus objetivos, debilidades y fortalezas. Relevancia del capital estructural y del capital humano. Cuál es su configuración actual y cuál la óptima para la personalidad de la organización. Este es el conocimiento que orientará el diseño y la gestión del sistema de desarrollo (en realidad de todos los subsistemas de la organización).

Empresa y mercado 276

Conocimiento de la industria. Características del producto del negocio: el software. Las áreas de conocimiento implicadas en su desarrollo, las

técnicas de construcción, los métodos y procesos posibles para su desarrollo y mantenimiento (ISO, CMM, Métodos Ágiles…) Es la información de referencia, con el conocimiento acumulado por nuestra industria. Su comprensión y visión general ayuda a seleccionar las prácticas más adecuadas

para la organización, o da el conocimiento de causa necesario para el diseño de modelos híbridos propios.

Gestión sistémica. Guiar las decisiones de gestión desde la perspectiva general del sistema que compone la organización. Huir de las soluciones sintomáticas, y evaluar sus idoneidad más allá del corto plazo, y su coherencia con el sistema en

su conjunto.

Revisión y adaptación. El mercado, el entorno tecnológico, la misma base de conocimiento de nuestra industria, están en continua evolución. Es necesaria una tarea de vigilancia del entorno para

investigar, desarrollar e innovar, tanto en productos como en

los propios procesos y formas de trabajo. Modelos y prácticas de producción o de calidad hay muchos: EFQM, Six Sigma, CMMI, ISO 15504, ISO 9000, DSDM, MSF, XP, PP, etc.

Teorías y técnicas para la gestión de las personas hay muchas: evaluaciones de desempeño, gestión por competencias, coaching, Maslow, Taylorismo, Herzberg, Mc Gregor, Vroom, Shein, etc.

La tecnología ofrece múltiples herramientas CAD de ayuda en la ingeniería del software (Requisite Pro, Visio, Subversión, CVS,

MSTS, Racional Rose, etc) así como plataformas de desarrollo, operativas, lenguajes, compiladores.... Aquí hay de todo, como en botica; pero con el mismo criterio que las medicinas, hay que considerar que aunque todos los remedios son buenos, ni todos sirven para todos, ni deben combinarse al azar.

El conocimiento general de la naturaleza del software y del marco de nuestra industria son ingredientes necesarios tanto

Empresa y mercado 277

para abordar el diseño de procesos con recursos propios, como para evaluar con acierto a una asesoría externa que pueda ofrecer una orientación objetiva; porque a la consultoría le

ocurre lo que a nuestra profesión, que no está normalizada, y en el peor de los casos uno puede terminar con un curandero o un traumatólogo, cuando lo que necesita, a lo mejor es un alergólogo.

Bibliografía

JENNIFER STAPLETON, DSDM Business Focused Development, DSDM Consortium, 2003 KEN SCHWABER y MIKE BEEDLE, Agile Software Development with

Scrum, Prentice Hall, 2002 JIM HIGHSMITH, Agile Project Management, Addison Wesley, 2004. KEN SCHABER, Agile Project Management with Scrum, Microsoft, 2004

GARY POLLICE, LIZ AUGUSTINE, CHRIS LOWE y JAS MADHUR, Software Development for Small Teams a RUP-Centric Approach, Addison Wesley, 2004 BARRY BOEHM y RICHARD TURNER, Balancing Agility and Discipline, Addison Wesley, 2004

GARY FORD y NORMAN GIBBS, Mature Profession of Software Engineering, SEI, 1996 ROBERT L. GLASS, Facts and Fallacies of Software Engineering, Addison Wesley, 2002

CARNEGIE-MELLON UNIVERSITY CMMI for Software Engineering, 1.1, 2002 IEEE COMPUTER SOCIETY Guide to the Software Engineering Body of Knowledge, 2004 DENNIS M. AHERN, AARON CLOUSE y RICHARD TURNER, CMMI Distilled:

A Practical Introduction to Integrated Process Improvement, Addison Wesley, 2003

Empresa y mercado 278

MARY BETH CHRISSIS, MIKE KONRAD y SANDY SHRUMI, CMMI Guidelines for Process Integration and Product, Addison Wesley, 2003

HAN VAN LOON, Process Assessment and ISO/IEC 15504 A Reference Book, Springer, 2004

Empresa y mercado 279

Estrategias empresariales ágiles

23.02.2007

4 proyectos innovadores a los que no les ha ido muy mal: 1.- Google 1996 Comienza como proyecto de investigación Universidad (Larry Page y Sergey Brin) - Como empresa en Sept. 1998 en un garaje en Menlo Park (California) - En 2000 empieza a vender

publicidad por palabras a 0.05$ el click, copiando la idea de goto.com 2- Skype 2002 Los autores del sistema P2P de ficheros Kazaa (Niklas Zennstrom y Janus Friis) idean un proyecto de telefonía IP sobre el concepto P2P - En Sep. 2002 Inversión de Capital Riesgo

DraperInvestment Compani (cifra no pública) - Octubre 2005. Ebay compra Skype. 3.- YouTube

Feb. 2005 3 empleados de PyPal publican un servicio con Flash para mostrar videos - Sobre la idea, Sequoia Capital invierte 3,5

millones de dólares y en abril de 2006 pone 8 millones más - Octubre 2006 Google anuncia su compra por 1.650$ millones 4.- Flickr Ludicorp desarrolla en 2002 un web de herramientas para su proyecto de juego masivo Neverending - La sala de chat llamada LickerLive incluía posibilidadde publicación en tiempo real de

fotos - Los usuarios lo empezaron a emplear tanto, que el proyecto original de un juego masivo quedó desterrado y surgió un servicio para compartir fotos.

Marzo 2005. Yahoo compra flickr

En los proyectos de este tipo el resultado obtenido se parecería a un hipotético plan de negocio que se hubiera trazado en el principio bastante menos que un huevo a una castaña. Son aventuras empresariales que no han llegado a su situación actual

siguiendo un modelo de gestión predictiva que vela por el

Empresa y mercado 280

cumplimiento del plan inicial; sino por conducirse un patrón ágil. Por avanzar en iteraciones cortas, tomar información constante del entorno inestable y rápido en el que crecen para adaptarse y

adquirir valor de forma continua. Hace algunos años, empresas líderes de tecnología comenzaron a dar la espalda a la gestión predictiva, creando nuevas formas de desarrollo de proyectos. La agilidad no surgió desde los foros de teoría, sino desde la práctica en los entornos de trabajo que

Nonaka y Takeuchi etiquetaron como "campos de scrum". Y desde ese recorrido de ingeniería inversa, desde la práctica

hacia la teoría y de abajo arriba, la gestión de proyectos ha sido (o está siendo) la primera en considerar sus principios y su utilidad. Pero ¿y el denominado management?. Empresas líderes de tecnología se dieron cuenta hace unos años

que dejando de lado las técnicas de gestión de proyectos predictiva y adoptando técnicas ágiles podían trabajar mucho más alineados con las nuevas características del entorno: inestabilidad y rapidez. Pero resulta que el desarrollo de productos y servicios es siempre parte de un sistema mayor.

La gestión de proyectos se ha dado cuenta (o se está dando) de que necesita patrones ágiles , y ¿el management?. (uso el término inglés para diferenciar gestión empresarial de gestión de proyectos). Los desarrollos ágiles en sistemas de management tradicional

chirrían. Hace poco tiempo evaluaba un posible proyecto para la empresa de inversión y venture-capital en la que trabajo, y la situación tenía su gracia:

Los creativos, padres de la idea tenían muy asumida la actitud

ágil para su desarrollo. Una visión muy clara del producto y un modelo iterativo e incremental, no sólo para adaptarse a los cambios durante el crecimiento, sino que los espera y los necesita como feedback continuo de lo que va haciendo para moldear cada paso siguiente, para re-definir, modificar y mejorar también de forma continua los indicadores que le informen del valor que va dando al producto.

El capital por su parte pedía el plan de negocio tradicional y correcto para un desarrollo predictivo: desglose de

Empresa y mercado 281

funcionalidades de ese producto visión, estimación del esfuerzo y el tiempo de salida. Indicadores de valor, cálculos de ROI, etc.

Por un lado la orientación de partir con incertidumbre y tomar

durante el camino las rutas más valiosas, y por otra la partir con

la planificación detallada de la ruta, fechas tiempos y costes de cada punto del recorrido (v. pág. 167: hay dos formas de viajar)

Empresa y mercado 282

Indicador de la calidad técnica de una empresa de software

09.03.2007

Hay empresas con buena estrella que casi no tienen que gastar tiempo ni recursos para incorporar a nuevos programadores. Les

basta con poner un anuncio y en un "plis-plas" ya han incorporado a la plantilla el nº de personas que necesitaban. A otras, con peor suerte, les cuesta sudor dar con los técnicos que necesitan. Se me ocurre proponer a consideración un indicador indirecto de la calidad técnica de una empresa de software: el coste de

incorporación de personal.

Empresa y mercado 283

Programadores que no están orientados a la rentabilidad

19.03.2007

El trabajo de consultoría diagnosticó, no sin dedicar muchas horas de trabajo, que la empresa de software no obtenía

beneficios por la "falta de orientación a la rentabilidad de los trabajadores", especialmente de los programadores (?). ¡Claro! dijo el director general. Así como voy a dar resultados con los que poner contentos a los accionistas. ¡Los trabajadores pasan de la rentabilidad, y por su culpa lo tengo que pasar mal

en los consejos de administración! Menos mal que hay consultores, y se puede demostrar que la culpa no es de uno; a ver si encima los socios la van a tomar conmigo: "Que lo ha dicho una consultoría, y de las buenas; qué de las

buenas, de las mejores; vamos no hay más que ver lo que ha

cobrado: es que los trabajadores no son rentables. La hora de programación media del mercado es de x€ y nosotros estamos un 20% por encima". No sé. Me puedo creer que en las tareas del tipo apretar tornillos, tirar de la rienda de las nóminas y predicar culturas de "echar horas" pueda ser una estrategia adecuada para dibujar sonrisas en los

accionistas. También es cierto que algunos productos tienen factores de escala reducidos, y no pueden fabricarse una vez, y venderse

infinitas; o que hay industrias en las que la innovación puede aportar valor diferencial, pero con un margen relativamente

limitado. Pero en las empresas que se dedican al diseño y desarrollo de nuevos productos y trabajan con algo tan maleable y escalable como el software: salarios y costes laborales no son la misma cosa (Costes laborales, pág. 30); y un director general puede obtener rentabilidades astronómicas o pérdidas, en función de

las decisiones estratégicas, de producto, innovación y marketing que él tome y gestione. Puede hacer muchas cosas, pero ninguna menos útil como tomar el mensaje del consejo de

Empresa y mercado 284

administración: "señores hay que ser rentables", y pasarlo en cadena al siguiente de la jerarquía, con cara de niño enfadado.

Empresa y mercado 285

Hubo un tiempo en el que la gestión de los procesos valía más que la gestión del talento

17.04.2007

Hubo un tiempo en el cual a los catálogos de productos bastaba con media docena de artículos, que se mantenían durante años. En esa época las empresas aprendieron que el cómo era la clave: cómo hacerlos con mejores costes y garantías de calidad.

Época en la que aprendieron que eficiencia y calidad continua son las especialidades de los procesos; los grandes protagonistas de aquella película. Ahora los catálogos se han saturado de productos que no duran en sus páginas mas que algunos meses, y en ocasiones, antes de salir a la calle ya están desfasados.

Y ahora, cuando hay que correr a toda velocidad para permanecer en el mismo sitio, la razón ya no es el cómo si no el qué. El éxito de las empresas que hacen "ipod's" o "wii's" no se debe a cómo los hacen, sino a qué hacen.

Hubo un tiempo en el que la gestión de los procesos valía más que la gestión del talento.

Empresa y mercado 286

Scrum en toda la empresa

06.05.2007

¿Por qué no aplicar Scrum en toda la empresa considerando a la organización en su conjunto, como un todo sistémicamente relacionado? ¿Por qué acomodar la empresa a la "forma" del modelo?: Sea la

forma de Scrum o de DSDM o de CMMI. ¿Por qué no considerar a las formas como lo que son, y emplear los fondos de conocimiento que hay tras ellas para componer un modo de trabajo apropiado a las características de la empresa y de sus proyectos? Scrum puede "implantarse" (forma) o "institucionalizarse"

(fondo); y proporciona mayores cotas de agilidad cuanto más ágil es la empresa en su conjunto. Poner un ScrumMaster en el departamento de programación de

una empresa con visión y cultura apuntando en otra dirección, o sencillamente sin visión; con un área de RR.HH. no alineada

hacia una gestión de personal ágil (gestión del conocimiento); con un departamento de marketing o de producto sin implicación en roles de propietario de producto; con áreas administrativas y comerciales trabajando sobre patrones de contratos de planificaciones cerradas... es una combinación peligrosa que suele producir empresas fragmentadas. Más que aplicar una "forma" para el área de desarrollo se trata

de gestionar la empresa en su conjunto desde los principios de agilidad. Es más una tarea de "Scrum Manager" que de "Scrum Master".

¿Por qué no trabaja el departamento de marketing en un campo de scrum?. ¿Por qué los directivos de la empresa no tratan la estrategia de la organización en un campo de scrum?. ¿Por qué

no es ágil toda la empresa? Las siguientes son las líneas directrices de esta visión de "gestión scrum" en cuyo desarrollo colaboro con Claudia (buena amiga y consultora de procesos de software) y que compartimos aquí con todos a los que os puedan resultar útiles.

Empresa y mercado 287

El fondo de esta gestión scrum es la síntesis (pág. 96) de conocimiento producida por la resolución dialéctica de las iniciativas de procesos (CMMI, ISO, PMI) y de agilidad. De ésta

toma el modelo de Campo de Scrum como entorno para el desarrollo de los proyectos. No emplea prácticas de áreas de procesos o patrones ágiles de forma cerrada.

sobre la base de los entornos de trabajo definidos a finales de los 80 como Campos de Scrum, plantea principios que ayudan a la

gestión para determinar la forma más apropiada a su organización y su proyecto.

Bases de la gestión Scrum:

"Campo de Scrum" como entorno de trabajo

Reconsideración del concepto de "personas" y

"procesos".

Flexibilidad para determinar el grado de previsibilidad y

valor óptimo para el proyecto, y las posibilidades de la organización.

Gestión sistémica.

1.- “Campo de Scrum” como entorno de trabajo. Campos de Scrum es el término acuñado por Nonaka y Takeuchi a finales de los 80 para definir nuevas formas de gestión en el

desarrollo de productos.

Empresa y mercado 288

En 1996 Jeff Sutherland y Ken Schwaber definieron un modelo de trabajo que aplica estos principios ágiles de Nonaka y

Takeuchi en el desarrollo de software. Este modelo formal para software definido por Jeff Sutherland y Ken Schwaber marca un protocolo de trabajo para desarrollar software de forma iterativa e incremental, en un formato de “Campo de Scrum”: solapamiento de fases, único equipo

multidisciplinar, auto-organización.

Este es también el patrón base de Scrum Management, aunque añadiendo algunas consideraciones: 2.- Visión propia de los procesos y las personas

Tanto la visión de procesos como la de agilidad se desarrollan sobre la premisa de tres elementos: personas - procesos y tecnología. Para los primeros, el valor de los resultados es consecuencia principalmente de los procesos empleados. Para los segundos, la variable más influyente en el valor del

resultado son las personas. ¿Quien tiene razón la tesis (CMM, ISO 15504, PMI...) o la antítesis (XP, Scrum, DSDM...)?. ambos la tienen, y lo que su síntesis revela es que los procesos y

las personas, que cada uno gestiona de forma diferente, encierran dos aspectos diferentes en cada caso, y no uno sólo. Para nosotros todo lo que se etiqueta como “procesos” no es la misma cosa. En algunos casos las personas ayudan al proceso, y en otros son los procesos los que ayudan a las personas.

Empresa y mercado 289

En el primer caso el proceso es el protagonista, el que sabe cómo hacer el trabajo y la persona se integra en el sistema como instrumento: como operario de apoyo. En el segundo el artífice es la persona y el proceso una ayuda, una herramienta que simplifica aspectos rutinarios para que

pueda lograr más eficiencia y no diluir el esfuerzo en rutinas

mecánicas. La principal diferencia entre unos y otros es el tipo de conocimiento con el que trabajan. La clasificación de Nonaka y Takeuchi entre explícito (contenido en los procesos y la tecnología), y tácito (contenido en la persona).

Otro elemento de producción necesario para desarrollar los productos o servicios son las personas, y la tensión entre los procesos y la agilidad revela que ambos tienen razón. Los primeros tienen razón al verlas como mano de obra para asistir a

los procesos, y los segundos también al verlas como talento. El error es considerar cuál es el modelo de gestión adecuado para este elemento, porque no es uno, sino dos.

Los procesos pueden ser procesos o rutinas. El valor que el sistema necesita de la persona puede ser trabajo o conocimiento. 3.- Flexibilidad entre agilidad y procesos

Considerar que una persona puede intervenir en un entorno de producción como trabajo o como conocimiento; o que un un

Empresa y mercado 290

procedimiento puede ser “proceso” o “rutina” es una simplificación en blanco y negro de una realidad en color. Son raros los sistemas que encierran todo el conocimiento sólo en

procesos y tecnología, o sólo en las personas, y por eso mismo también son minoría los entornos de producción en los que puede encajar como solución de talla única la forma de un modelo de procesos o ágil "tal cual".

4.- Considera a la gestión con visión sistémica

Las organizaciones son sistemas inter-relacionados e inter-dependientes.

¿Cuál es el mejor modelo de procesos para el desarrollo de software?. ¿La cultura de empresa más adecuada? ¿Las mejores técnicas de gestión de RR.HH:? ¿Las mejores plataformas de progrmación? ¿La mejor estrategia de marketing?

Gestionar de forma independiente y aislada cada parcela produce tensiones y empresas fragmentadas. La implantación de un sistema de producción Scrum, Extreme Programming o CMMI no es una cuestión del responsable de programación ajena al resto de la empresa.

Empresa y mercado 291

Las técnicas empleadas, los modelos de calidad, la tecnología, la cultura de la empresa, la gestión de las personas… deben ser

coherentes, de forma que se potencien, y no se contrarresten. Un “know-how” adecuado, basado en el conocimiento tácito de las personas, compaginado con equipos desmotivados o implantado en organizaciones verticales no es una buena combinación.

Un método ágil puede resultar idóneo para el tamaño de equipos y de empresa, pero si sus procesos no cubren las facetas contractuales de la adquisición, generará problemas en la validación del producto. A modo de síntesis, algunas claves para conseguir

organizaciones eficientes de desarrollo de software son:

- Personalidad de la organización. El primer punto de atención es conocer la visión y misión de la empresa y el tipo de proyectos que realiza. Esta es la principal

referencia con la que deben alinearse y sincronizarse todas las

Cuanto más nítida sea la visión, misión, estrategia segmento de mercado y objetivos de la organización, con mayor atino y precisión se podrán combinar los componentes del sistema y orientar la gestión de su funcionamiento.

- Conocimiento de la organización. Sus objetivos, debilidades y fortalezas. Relevancia del capital estructural y del capital humano para el tipo de proyectos que realiza, y valores actuales de cada uno.

Empresa y mercado 292

- Conocimiento y visión objetiva de modelos de procesos y prácticas de la industria del software :

ISO, CMMI, Métodos ágiles...

- Gestión sistémica. Huir de soluciones de "receta" basadas en aplicar formas o protocolos de procesos. Trascender al fondo de cada modelo, diseñar acciones estratégicas para la organización evaluando su

idoneidad más allá del corto plazo y su coherencia con la organización en su conjunto.

- Revisión y adaptación. Análisis continuo de los propios métodos y vigilancia del entorno para investigar, desarrollar e innovar tanto en productos como

en los propios procesos y formas de trabajo.

Empresa y mercado 293

Los buenos directivos también son difíciles de encontrar

14.05.2007

El 30% de los directivos de nuestras empresas no tienen ni la energía ni la concentración necesaria para desepeñar su trabajo.

Se limitan a cumplir las tareas rutinarias: asisten a reuniones, escriben memorándums, hacen llamadas telefónicas... Pero no toman iniciativa para nada ni elevan el nivel de actuación, ni se ocupan de la estrategia. Siempre lo dejan para mañana.

El 20% son personas que aunque sí disponen de capacidad de concentración, no tienen la energía para trabajar. Se suelen sentir "quemados", tienden a estar rodeados de sentimientos de ansiedad, y reaccionan echándose atrás y cumpliendo el mínimo exigible.

Un porcentaje elevado, el 40% tiene energía para trabajar, pero tienen poca concentración. Son los continuamente distraidos. Por la presión de su trabajo, estos directivos sienten la imperiosa necesidad de hacer algo, lo que sea; por lo que pueden ser tan peligrosos como un elefante en una cacharería.

Empresa y mercado 294

Sólo el 10% de los directivos aportan trabajo y motivación en su trabajo.

A estas conclusiones llegan Heike Bruch y Sumantra Ghoshal tras diez años de colaboración y análisis del comportamiento de directivos ocupados en empresas como Sony, LG Electronics o Lufthansa, y que exponen en su artículo: "Beware the Busy

Manager " (Bruch & Ghoshal, 2002) en el que, sin abusar del derecho de cita, dicen:

"Si escuchamos a los directivos, nos dirán que el recurso que

menos tienen es tiempo. Dedican cada minuto de su tiempo a considerar problemas estratégicos, a reducir costes, a pensar en enfoques creativos para los nuevos mercados en ganarle la competencia a la competencia... ... piensan que están prestando atención a cuestiones urgentes,

pero en realidad simplemente están dando vueltas... ...Lo que descubrimos sobre el comportamiento directivo asusta: el 90 por ciento de ellos desperdician el tiempo en todo tipo de actividades ineficaces. En otras palabras, apenas el 10 por ciento de los directivos dedican su tiempo a trabajar de forma reflexiva".

Pero esto no quiere decir que el porcentaje de directivos con niveles altos de eficiencia sea el 10%, porque este estudio deja fuera el tercer factor (v. ¿Listo, cumplidor o motivado?, pág. 39): el nivel de capacitación. De esos diez de cada cien que tienen niveles altos de trabajo y

motivación, ¿cuántos también tienen niveles altos de capacitación?.

Empresa y mercado 295

Scrum management: de modelo de negocio a modelo de valor

04.06.2007

¿Que cuál es el modelo de negocio?. No, no hay modelo de negocio. Es muy pronto para definirlo. No trabajamos con un

modelo de negocio, sino con un modelo de valor. En cierto modo a la estrategia de negocio le ocurre lo que a la gestión de proyectos. Nos hemos acostumbrado a un modelo predictivo:

1.- Defino el producto. 2.- Hago un plan de proyecto (de negocio en este caso) 3.- Gestiono su cumplimiento. Cuando el entorno es rápido e incierto, los planes no sirven, y la capacidad de cambio continuo es necesaria y bienvenida para no

quedarnos atrás.

Una estrategia de "Scrum management" trabaja sobre un modelo de valor (no de negocio), alumbrándolo con cortas: con detalle sobre el trabajo inmediato (próxima iteración), y manteniendo en el backlog la visión a medio y largo en constante revisión, análisis y contraste continuo con la evolución del entorno.

Empresa y mercado 296

Factor de escala y agilidad

02.09.2007

Algunos productos tienen factores de escala escasos: aumentar el número de unidades realizadas, supone incrementos de proporciones similares en el coste de fabricación. El software tiene un factor de escala prácticamente infinito:

cuesta lo mismo producir uno que mil. Si mi tratador de textos, o mi solución de correo, o… es lo mejor del mercado, venderé, cien, mil o diez mil veces más programas, con la misma inversión de desarrollo; algo que sin duda no le ocurre, por ejemplo, a una empresa de construcción, o a una joyería.

Cómo afecta esta característica a la ratio coste de prototipado / valor del producto. Si el producto necesita el máximo valor posible, un modelo de

plan y requisitos cerrados, para hacerlo bien a la primera, y evitar costes de modificaciones; puede ser un ahorro miope. El

feedback continuo, los requisitos siembre abiertos, la apertura al cambio, y la inyección de valor continuo durante todo el desarrollo es una gran inversión.

Empresa y mercado 297

Lo mejor de CMMI y Scrum

19.09.2007

La tesis (ISO 12207, 15504, CMMI…) ha identificado y definido las cosas QUE hay que hacer. La antítesis (XP, Scrum, FDD...) ha mostrado formas de trabajar que funcionan bien: CÓMO hacer determinados "qués". Posiblemente la síntesis , la moraleja de ambos sea cuestionar los

"POR QUÉs"

¿Qué hacer para que los proyectos de software salgan bien?

LA TESIS: "Bueno..., tenga en cuenta que no sólo se trata de programar de forma adecuada. Hay que hacer de forma adecuada otras muchas tareas que tienen lugar desde que se le ocurre la idea de hacer algo, hasta que finalmente lo deja de usar."

Esto es lo que dice ISO con su estándar internacional ISO/IEC

12207 : Las cosas QUE intervienen en el desarrollo de un proyecto de software. QUÉ tareas tiene que hacer el cliente al adquirir el sistema (5.1 Acquisition), QUÉ tareas debe hacer el suminstrador para responder a la adsuisición (5.2 Suply), QUÉ tareas para desarrollar el sistema (5.3 Development) etc. ISO 12207, o CMMI o ISO 15504 son modelos. Los modelos

dicen el QUÉ hay qué hacer, pero no CÓMO. Los modelos le dicen: hay que hacer un contrato, hay que mirar

las opciones del mercado, hay que hacer requisitos, plan de proyecto, análisis, codificar, probar, etc... Ni CMMI ni ISO prescriben CÓMO hacer la gestión de la configuración, la

planificación del proyecto o la gestión de los requisitos. CMMI dice: hágalo como usted quiera, siempre y cuando alcance el fin del área de proceso que venga al caso. O sea, siempre y cuando usted tenga control de las versiones, sepa cuál es el plan de proyecto, o los requisitos de lo que debe hacer. Que usa gráficos de Gantt, o post-it en pizarras… allá usted. Que si documentos Word con el estándar de requisitos de IEEE 830, o historias de

usuario... Usted sabrá. Usted lo hará bien, si consigue el objetivo del área de proceso. Bueno, otra cosa será si quiere que

Empresa y mercado 298

yo lo certifique, porque entonces me lo tendrá que demostrar, y eso le complicará un poco la vida, pero... bueno, allá usted.

LA ANTÍTESIS: "Bueno... tiene que hacer las cosas de esta manera: ponga a los programadores por parejas, desarrolle trozos pequeños en 2 ó 4 semanas cada uno. Haga una reunión de una jornada antes de empezar a programar cada trozo, y organícela en dos partes: en la primera cierre los requisitos con todo el equipo, en la

segunda... Todos los días el equipo debe reunirse durante 5 minutos y responder a tres preguntas..."

Este es el tipo de respuesta de la antítesis: de los modelos ágiles, que en rigor no serían "modelos" sino "prácticas", porque no dicen QUÉ hay que hacer, sino CÓMO hay que hacer.

Y posiblemente la síntesis está en el PORQUÉ: ¿Por qué la descripción del sistema o ConOps con el estándar IEEE 1362 ? o, ¿por qué en un Product Backlog?.

LA SÍNTESIS: La talla única no resulta válida, y las prácticas más indicadas para unos, pueden resultar bien demasiado pesadas, bien insuficientes para otros. Los responsables de la gestión en cada empresa adoptan las decisiones para cada área de proceso sobre

el conocimiento del grado y formas que necesita su empresa en tres áreas:

Equilibrio agilidad - procesos

Formas y modos de institucionalización.

Empresa y mercado 299

Formas y modos de ingeniería de procesos.

Y este conocimiento es consecuencia del análisis del tipo de trabajo, y de las características de la organización.

Además de determinar un nivel de equilibrio entre agilidad y procesos, adecuado al tipo de trabajo que se realiza, hay otros dos factores importantes en el diseño y gestión del marco de

trabajo de la empresa: la institucionalización y la ingeniería de procesos. Los modelos para la mejora de procesos como CMMI tienen una fortaleza importante, que a la vez es debilidad de las prácticas ágiles: se trata de las prácticas genéricas, que están presentes en todas las áreas de procesos para que en todas se consiga:

"Institucionalizar" las formas de trabajo

Implantar prácticas de ingeniería de procesos.

Tal y como lo define CMMI en el glosario, institucionalizar las prácticas de trabajo es incrustarlas en la cultura corporativa de

la empresa de manera que se realicen de forma rutinaria. La institucionalización se refiere a las ventajas de documentar los procedimientos que emplea la empresa, y disponerlos de forma accesible a todos los interesados; a la necesidad de formar al personal para que las conozca y sepa emplearlas en el trabajo.

Empresa y mercado 300

Claro que CMMI se refiere a la institucionalización de sus prácticas, pero lo cierto es que resulta útil tanto para los procesos como para las rutinas de trabajo ágiles.

Los criterios de rigor de documentación, comunicación, formación y ámbito dependen de las características de la organización y no de agilidad o procesos. Para un pequeño grupo de emprendedores, que desarrollan en una "start-up"un innovador producto de software, aplicar

procesos pesados para la institucionalización, les aporta más problemas que ventajas.

Una gran empresa, o una pequeña que quiere asentar principios para dar el salto: de personas que saben programar a empresa que sabe programar, debe incluir procesos para explicitar e institucionalizar su saber hacer, independientemente de que se trate de procesos o de agilildad.

Y, en segundo lugar, las prácticas de ingeniería de procesos, son las relacionadas con la medición y mejora de las propias prácticas y procesos empleados en el trabajo. Igual que para la institucionalización, es irrelevante que se trate de agilidad o de procesos. Las características de la organización

determinarán para cada área "por qué" resulta conveniente o no, emplear modelos tipo PDCA , IDEAL , las métricas, los criterios y las formas apropiadas

Empresa y mercado 301

Culturas tóxicas para la agilidad

23.09.2007

Algunas empresas deben a los procesos y la tecnología su "saber hacer": las máquinas y los procedimientos se encargan de elaborar los productos con el menor número de humanos posible, y que aquellos sean de buena calidad, a pesar de estos.

En ellas la cultura de la empresa no es especialmente relevante, porque a los procedimientos y a las máquinas les da igual como sea; y como de las personas sólo interesa que las atiendan siguiendo los procedimientos, basta con que no genere huelgas o sabotajes. Otras, sin embargo, deben su "saber hacer" a las personas. En

ellas las máquinas y los procedimientos ayudan a los humanos, y no al revés, y como las personas son complicadas, resulta que el talento, aunque lo tengan, no lo pueden desarrollar si no están motivados. En estas empresas la cultura es una variable muy

relevante, porque las culturas tóxicas atrofian o espantan al talento.

Empresa y mercado 302

Resulta muy visual y acertada la simplificación de las culturas de empresa posibles del artículo What Holds the Modern Company Toghether? (Rob & Gareth, 1996) . Desde su perspectiva, éstas

son el resultado de la mezcla de dos dimensiones: sociabilidad y solidaridad. Tomando a la sociabilidad como el grado de relación emocional y no insturmental (que no es un simple medio de satisfacer las propias necesidades) que existe entre las personas. Las

relaciones de amistad son relaciones de sociabilidad elevada. Y tomando por solidaridad a la actitud del equipo en el que

prima el enfoque estratégico, la reacción contra la amenaza de los competidores y la intolerancia al bajo rendimiento. La combinación ideal, sin duda es la cultura comunal, que combina dosis elevadas de ambas; porque aunque podría

parecer que con dosis elevadas de sociabilidad bastaría, o incluso sería mejor, porque habría mejor "rollito". Pero la sociabilidad alta, con ausencia de solidaridad tiene inconvenientes, porque el predominio de la amistad puede tolerar rendimientos bajos. Cuando el nivel de sociabilidad es mucho mayor que el de solidaridad, el trabajo se resuelve con el mejor "compromiso" no

con la mejor "solución"; y también es frecuente el desarrollo de camarillas y redes informales que burlan y pueden socavar la institucionalización de procedimientos en la empresa.

Empresa y mercado 303

"Estamos poniendo al descubierto mejores métodos para desarrollar software, haciendo y ayudando a otros a que lo

hagan. Con este trabajo hemos llegado a valorar: A los individuos y su interacción, por encima de los procesos y las herramientas." Manifiesto Ágil , 2001.

Empresa y mercado 304

Las tres responsabilidades (mejor que roles) para Scrum

16.10.2007

El grado de funcionamiento de Scrum en la organización depende directamente de estas tres condiciones:

Características del entorno (organización y proyecto) adecuadas para desarrollo ágil.

Conocimiento de la metodología de trabajo en todas las personas de la organización y las implicadas del cliente.

Asignación de responsabilidades:

Del producto.

Del desarrollo.

Del funcionamiento de Scrum.

Responsabilidad del producto: El propietario del producto En el proyecto hay una persona, y sólo una, conocedora del entorno de negocio del cliente y de la visión del producto. Representa a todos los interesados en el producto final y es el responsable del Product Backlog. Se le suele denominar "propietario del producto" y es el responsable de obtener el resultado de mayor valor posible para los usuarios o clientes.

Es responsable de la financiación necesaria para el proyecto, de decidir cómo debe ser el resultado final, del lanzamiento y del retorno de la inversión.

En desarrollos internos puede ser el product manager, o responsable de marketing, o… quien asume este rol. En desarrollos para clientes externos lo más aconsejable es que sea el responsable del proceso de adquisición del cliente.

Responsabilidad del desarrollo: El equipo Todo el equipo de desarrollo, incluido el propietario del producto conoce la metodología Scrum, y son los auténticos responsables del resultado.

Es un equipo multidisciplinar que cubre todas las habilidades necesarias para generar el resultado.

Empresa y mercado 305

Se auto-gestiona y auto-organiza, y dispone de atribuciones suficientes en la organización para tomar decisiones sobre cómo realizar su trabajo.

Responsabilidad del funcionamiento de Scrum La organización debe garantizar el funcionamiento de los procesos y metodologías que emplea, y en este aspecto Scrum no es una excepción. En el modelo de Scrum definido por Jeff Sutherland, esta

responsabilidad se garantiza integrando en el equipo una persona con el rol de ScrumMaster.

Considerando que las realidades de unas y otras empresas pueden ser muy diferentes, y que siempre que sea posible es mejor optar por adaptar las prácticas de trabajo a la empresa, y no al revés, en ocasiones puede resultar más aconsejable:

Que en lugar de una persona con la función de "ScrumMaster", sean las personas y puestos más adecuados en cada organización los que reciban la

formación adecuada y asuman las funciones correspondientes para cubrir esta responsabilidad.

Que al compromiso de funcionamiento del proceso se

sume también la dirección de la empresa, con el

conocimiento de gestión y desarrollo ágil; y facilitando los recursos necesarios.

Empresa y mercado 306

¿Qué tal resultará la implantación de una metodología ágil?

05.11.2007

Esta podría ser una lista de comprobación con los principales factores que condicionan los resultados de la gestión ágil de

proyectos. Desde luego tenerlos todos es complicado, pero

¿quién dijo que la gestión ágil fuera fácil?

ADQUISICIÓN El propietario del producto tiene definida la visión de lo

que necesita.

El propietario del producto está comprometido y se

implica con el equipo.

El propietario del producto conoce los principios del

desarrollo ágil.

De forma previa, o incluido en el primer sprint, se realiza

un análisis de adquisición.

El modelo de adquisición del cliente permite un patrón de desarrollo ágil

La prioridad para el negocio del cliente es el valor innovador, por encima del plan de un producto cerrado.

SUMINISTRO

La forma contractual es adecuada para un patrón de

desarrollo iterativo e incremental.

El equipo dispone de personas expertas en las áreas de conocimiento necesarias para desarrollar el producto o

servicio.

El propietario del producto monitoriza la información de retro-alimentación (entorno de negocio, feedback de las reuniones Scrum, etc.)

El responsable de la coordinación del equipo conoce y tiene experiencia en desarrollo ágil.

Empresa y mercado 307

DESARROLLO El equipo conoce el modelo de desarrollo Scrum.

El equipo tiene experiencia en el desarrollo con Scrum.

El equipo tiene experiencia en la estimación de tareas.

El equipo tiene experiencia en la tecnología y plataforma

tecnológica con la que va a trabajar.

El nivel técnico del equipo es alto.

Se trata de un equipo cooperativo y cohesionado.

Se realizan de forma institucionalizada las rutinas

organizativas de Scrum.

SOPORTE El equipo dispone de un medio adecuado para dar

soporte al product backlog.

El equipo de dispone de un medio adecuado para dar soporte al sprint backlog y a la monitorización de la evolución del sprint.

El propietario del producto dispone de un medio de

previsión y monitorización de la evolución del producto.

ORGANIZACIONALES El equipo dispone de las infraestructuras adecuadas:

espacios de reuniones, equipos y herramientas de

desarrollo

La organización considera a la selección e incorporación de personas como un proceso clave para la calidad de sus resultados.

La organización considera a la formación de las personas como un proceso clave para la calidad de sus resultados.

La dirección de la empresa conoce los principios de

desarrollo ágil, y está comprometida en s

Empresa y mercado 308

Scrum: ¿de remedio a enfermedad?

29.01.2008

Esta es la comparación que Jason Gorman hace entre la propagación de los virus y los consultores de Scrum. Jason es un consultor inglés, beligerante y sarcástico con quienes, con mayor o menor conocimiento de los principios de la agilidad, dogmatizan anclados en ella.

Se me ocurren tres posibles razones en el fondo esta crítica.

1.- En la espiral de conocimiento, de tendencia pendular, ¿es una muestra de tensión para no pararnos en la agilidad y evolucionar hacia la síntesis? ¿La crítica está cambiando por tanto el objetivo, de los dogmáticos de la ingeniería, a los dogmáticos de la agilidad?. 2.- ¿Es una crítica a los oportunistas, o a la agilidad del todo a

100? 3.- Jason ofrece y publicita sus propios servicios de consultoría. ¿Es una estrategia de marketing para sus servicios de asesoría y

formación, basada en troll y descalificación de otros consultores?

Empresa y mercado 309

Puede ser una o varias de estas las razones, vaya usted a saber en qué proporciones.

Empresa y mercado 310

¿Las empresas deben enorgullecerse de su madurez?

19.03.2009

Dos textos en los que se habla de la madurez de las empresas: CMMI y El Principio de Peter. El primero la vende como

admirable, y sin embargo el segundo la anatematiza. Para CMMI, menos mal que las jóvenes empresas alocadas, a través del aprendizaje de su modelo, adoptan procesos-adolescentes, que con el tiempo, tras sucesivos ciclos IDEAL(1), desarrollan la capacidad que dará a la empresa la deseable

madurez: Llegará a ser sabia, y tendrá respuestas predecibles y de calidad. Laurence J. Peter, en su famoso libro del que todos conocemos aquello de que "las personas en las empresas ascienden hasta alcanzar su nivel de incompetencia", habla también de cómo las organizaciones se van haciendo maduras: De cómo se van

oxidando, perdiendo flexibilidad, y acumulando grasa:

"se van sobrecargando de incompetentes que no pueden realizar su trabajo, no pueden ser ascendidos, pero no pueden ser excluidos ... cualquier empresa caerá cuando su jerarquía alcance un intolerable estado de madurez". "La eficiencia de una jerarquía es inversamente proporcional a su cociente de madurez, CM

La madurez en las empresas, ¿actúa como en los seres vivos?. ¿El lote de la madurez y la sensatez, incluye también oxidación y esclerosis?.

Las que, ignorando sus achaques, "juegan" a la agilidad, ¿son frustrados carrozas con síndrome de Peter Pan? ¿Y las que envejecen sin madurar? Las empresas adolescentes que se "calzan" un CMMI, ¿son niños vistiendo de etiqueta?. ¿Para las primeras son más aconsejables los negocios estables y seguros, y para las segundas los rápidos

y de mayor riesgo?.

Empresa y mercado 311

Las organizaciones pueden conseguir la eterna juventud "institucionalizando" medias periódicas de liposucción, ejercicio y elmininación de toxinas? ¿serían así eternamente maduras?.

¿Estas pregunas tienen sentido? (1)IDEAL: modelo de mejora continua de procesos de CMMI

Empresa y mercado 312

¿Cuál es la personalidad de tu empresa?

19.03.2008

Todos somos únicos, y diferentes a los demás.

Dice una teoría sicológica (1) que la personalidad es el resultado que produce en nosotros la mezcla de un conjunto de factores (afectotimia, inteligencia, ego, sumisión...) que cada uno combinamos en nuestro propio espectrograma. Y con las empresas de soft me parece que pasa como con las

personas: que cada una es diferente. Que de unas te puedes fiar más que de otras y que una cosa son las apariencias y otra la realidad. Por eso las primeras impresiones pueden terminar fiasco, y tras los vaqueros y el aspecto de descuidado gurú puede haber menos talento del que se aparenta, o también puede ser que el lustre de trajes y diplomas no sea el reflejo del

fondo, sino la tapa que lo oculta.

Se me ocurre que igual que en los individuos, en las ermpresas la "personalidad" debe ser resultado de combinar múltiples factores, cada uno en su propio grado. Un sistema sin duda caótico, tanto por el número de éstos, como por los muchos grados posibles; pero supongo que la personalidad empresarial no será ajena al principio de pareto, y que aunque puedan ser

muchos los factores influyentes, sólo unos pocos trazan los rasgos relevantes. Me atrevo a apuntar cuatro como "factores primarios de la

personalidad conductual de las empresas"

1.- Tecnosofía 2.- Gestión 3.- Marketing 4.- Identidad Y parafraseando a los cuestionarios factoriales de personalidad

de R.B. Cattell la exposición de cada uno podría ser algo así:

Empresa y mercado 313

FACTOR A: TECNOSOFÍA

Empresa tecnósofa Empresa tecnoignorante

En la empresa tecnósofa el

personal con capacidad de decisión está al tanto, comprende y gusta de la vanguardia tecnológica de su sector. Su principal

preocupación es el avance, el

nivel y la formación continua de las personas para evitar el desfase.

Las personas clave de las

empresas tecnoignorantes creen que conceptos básicos como "criptografía asimétrica", o vanguardistas como "cloud computing" no son cosa de la

que ellos deban estar al tanto.

Que se trata de asuntos de programadores, no de gestores.

FACTOR B: MANAGEMENT

Management alto Management bajo

Las empresas con capacidad de gestión algo están guiadas

por gestores competentes

Las empresas con capacidad de gestión baja están guiadas por

patanes

FACTOR C: MARKETING

Mercadotecnia alta Mercadotecnia baja

Las empresas con buena capacidad mercadotecnica tienen personal comercial capaz de atraer la atención y

confianza de los clientes.

En las empresas con baja capacidad de mercadotecnia, el personal comercial no logra atraer ni la atención ni la

confianza de los clientes.

Empresa y mercado 314

FACTOR D: ORIENTACIÓN

Empresa orientada Empresa desorientada

Las empresas "orientadas" tienen una visión nítidamente definida. Tienen definido su producto, conocen el mercado y disponen de una estrategia.

Las empresas desorientadas carecen de visión. Venden todo lo que se les pone por delante, sin una estrategia de producto clara.

A partir de aquí las combinaciones y los grados son muchos: desde las personalidades desequilibradas de los chalanes de burras viejas, los técnicos torpes en marketing, los consultores de grandes formas y fondos simples, o los desorientados que disparan a todo lo que supone facturación; hasta las más

equilibradas en sus componentes; en ocasiones con potenciales mínimos, y en las más escasas, sobresalientes.

Empresa y mercado 315

5 niveles de agilidad

14.05.2008

B. Crosby (Crosby, 1996) definió la Quality Management Maturity

Grid" (QMMG) para determinar el grado de desarrollo y asentamiento de los procesos de una organización en un rango de cinco escalones que denominó:

1.- Incertidumbre 2.- Despertar 3.- Aclaración 4.- Sabiduría 5.- Certeza Es el concepto que tomó CMM / CMMI para definir sus cinco

niveles de madurez, y que empleado para representar, no la dimensión de la organización en madurez de procesos, sino la dimensión en agilidad se podría esbozar como algo así:

1.- Inicial (o Incertidumbre)(1)

Empresa y mercado 316

No es posible establecer garantías de agilidad porque ni de forma institucionalizada, ni a través de pilotos experimentales se llevan a cabo prácticas ágiles en la organización

2.- Gestionada (o Despertar) Surgido de abajo hacia arriba, o gestionado desde arriba hacia abajo, hay algún grupo o experiencia piloto aprendiendo y probando prácticas ágiles.

3.- Definida (o Aclaración) La organización aplica prácticas ágiles en el desarrollo de sus

productos o servicios de forma "institucionalizada" y "asumida en la cultura": esto es, los principios ágiles forman parte de la cultura de la organización, y las prácticas son conocidas y realizadas de forma homogénea por todas las personas

4.- Gestionada cuantitativamente (o Sabiduría) La organización mide y analiza las prácticas ágiles en un sistema institucionalizado de adecuación y flexibilización de las prácticas ágiles a sus propias circunstancias de identidad. 5.- Optimizada (o certeza) La agilidad se aplica en todas las áreas y dimensiones de la

empresa de forma personalizada y guiada por la revisión continua del modelo. Como en la aplicación para calidad o para procesos de software, esta sería la trayectoria natural para mejorar en la organización la dimensión de madurez, aunque no conozco a nadie que

pudiera estár más allá del nivel 3, por lo que 4 y 5 son puras elucubraciones sobre el hipotético nirvana de una organización ágil. (1) según denominación original de B. Crosby o denominación

adaptada por CMMI

Empresa y mercado 317

Gestión de blanco y negro

27.07.2008

Dos estereotipos: uno pontifica el comportamiento de los jefes, y otro, el de los trabajadores: Dos son los tipos de jefes: los orientados a resultados, y los orientados a personas. A los primeros se les etiqueta de

autoritarios, y a los segundos de democráticos. Con los primeros salen ganando las empresas, y con los segundos, las personas. Dos son los comportamientos de los trabajadores: X o Y. Los trabajadores con comportamiento X estigmatizan al trabajo como la obligación a la que hay que acudir todos los días; mientras que los de comportamiento Y lo viven como un modo

de realización personal. Y un dogma que cuenta con numerosa parroquia tanto entre empresarios (orientados a resultados) como entre trabajadores

(mayormente escorados hacia comportamientos X): Los procesos. El marco por el que la calidad del resultado depende

de éstos, y no de las personas. Por el que no hacen falta buenos cocineros para cocinar buenas hamburguesas, o buenos mecánicos para fabricar buenos coches. A los empresarios orientados a los resultados les gusta eso de que el conocimiento, el saber hacer, sea parte del capital estructural de su empresa, y no del capital humano: poder tener

una o veinte factorías, emplear personas poco cualificadas y rotarlas como les plazca; y que independientemente de esto, los coches, las hamburguesas, o lo que fabriquen salgan siempre

bien. ¡Gran invento, sin duda que los procesos sean los responsables del producto! . Los empleados X también son buenos parroquianos de este

dogma, porque ven trabajos simples, cómodos, con una buena definición de lo que hay que hacer. Perfectos para fichar todos los días sin complicaciones. Pero hacer las cosas siempre de la misma manera produce algunos efectos secundarios, y uno, importante si se trata de

empresas de conocimiento: inhibe el talento y refuerza la

Empresa y mercado 318

resistencia al cambio, de modo que se reduce la fertilización del conocimiento y la creatividad.

A lo mejor no tiene mucha relación, pero al escribir esto me acuerdo de algunos párrafos inquietantes del libro "Elogio del imbécil" del periodista italiano Pino Aprile: "La extremada subdivisión de las tareas es la vía de salvación de las estructuras sociales porque, a base de desmenuzarlas, se

llegará al punto en que, a cualquier nivel, se exija a los individuos atenerse a unos comportamientos y reglas tan simples

que cualquiera estará capacitado para observarlos" "Los animales que escapan a nuestra poda cerebral en general son considerados "malos" y sufren el exterminio. Como el lobo, que está en vías de extinción...." los animales domesticados

"piensan menos" que sus semejantes salvajes." "Cuando un ejemplar de nuestra especie particularmente inteligente pone su talento al servicio de la comunidad, la hace más estúpida, produce imbecilidad, porque los demás se limitan a copiarlo, a explotar sus intuiciones imitándolas servilmente, y no se seinten impulsados a ejercitar sus propias facultades

mentales". Pino Aprile "Elogio del imbécil" (Aprile, 2002) Es posible que gestionar con simplificaciones binarias de o blanco o negro, resultados o personas, X o Y, procesos o personas, no

componga visiones realistas de la gama de colores de la realidad, y termine atrofiando las partes del sistema (personas - procesos - tecnología) que no emplea. ¿Sólo son posibles los jefes en blanco y negro? ¿Los que hacen ganar a la empresa o a las personas? ¿Los creyentes o de

procesos o de agilidad, o de CMMI o de XP...?

Relacionado: Visión propia de procesos y personas - flexibilidad entre agilida y procesos: en el artículo "Scrum en toda la empresa" (pág 286)

Empresa y mercado 319

Empresas con visión

28.08.2008

Qué risa al acordarme con unos amigos, de la cara del Director General cuando le preguntaron por la visión de su empresa, y se vio en el brete de definirla. ¿Visión?. ¡Vaya cosas tienen estos consultores encorbatados!,

debió pensar. ¡Pues qué visión vamos a tener: ganar dinero! Se trataba de la "empresa de informática" especialista en disparar a todo lo que se mueve. Igual daba que se hablara de telefonía IP, seguridad, modificar un programa de contabilidad en Visual Basic, hacer una página web o una animación tridimensional...

"Somos profesionales, especializados en dar las mejores soluciones a nuestros clientes". Vamos, que si usted tiene dinero, siéntase como en su casa, que ahora mismo firmamos el

contrato: le haremos lo que usted quiera y en el tiempo que necesite.

Nada menos que un año estuvo la plana mayor de la empresa buscando musa para la frase lapidaria, capaz de cautivar a cualquier cliente; que transmitiera aplomo al afirmar que su visión era ser muy buenos y hacerlo todo muy bien. Recordando la anécdota, me ha entrado el gusanillo de echar un vistazo a "visiones" de empresas, y gracias a la magia de

Internet para esto de buscar información, aquí hay algunas perlas similares... que quizá sean de verdad empresas con visión muy clara y profesionales excelentes, pero es que diciendo estas

cosas... uno no sabe que pensar:

Ser los mejores en conseguir el éxito a través de las personas

Aportar valor a trabajadores y a empresas clientes a

través de un servicio de gran calidad que satisfaga sus necesidades y supere sus expectativas, que nos sientan

muy cerca

Ser una empresa reconocida por nuestra excelencia en los negocios que participemos

Empresa y mercado 320

Satisfacer las necesidades del cliente, brindando

soluciones integrales y presencia en sus mercados, con

alta capacidad, profesionalismo y un fuerte compromiso de proporcionar los más altos estándares de calidad junto

a una atención personalizada.

Queremos ser LOS profesionales en los que confian LOS clientes, que nuestras soluciones sean LA referencia en el

mercado, disfrutando, creciendo y mejorando día a día.

Empresa y mercado 321

La teoría de gestión no sirve para los proyectos importantes

27.07.2008

El conocimiento de gestión, es para lo poco importante. Para "las canicas y la arena", que diría Claudia (1).

Me ha dejado pensando lo que me acaba de decir Juancho, de las dos actividades principales de los gestores: medir y decidir. "Las cosas realmente importantes de la vida, ni se pueden elegir, ni se pueden medir".

(1) MAYONESA Y CAFÉ Cuando las cosas en la vida parecen demasiado, Cuando 24 horas al día no son suficientes... Recuerda el frasco de mayonesa y el café.

Un profesor delante de su clase de Filosofía, sin decir palabra,

tomo un frasco grande y vacío de mayonesa y procedió a llenarlo con pelotas de golf. Luego le preguntó a sus estudiantes si el frasco estaba lleno. Los estudiantes Estuvieron de acuerdo en decir que sí. Así que el profesor tomo una caja llena de canicas y la vació dentro del frasco. Las canicas llenaron los espacios vacíos entre

las pelotas de golf. El profesor volvió a preguntar a los estudiantes si el frasco estaba lleno, ellos volvieron a decir que sí.

Luego...el profesor tomo una caja con arena y la vació dentro

del frasco. Por supuesto, la arena lleno todos los espacios vacíos, así que el profesor pregunto nuevamente si el frasco estaba lleno. En esta ocasión los estudiantes respondieron Con un 'sí' unánime. El profesor enseguida agrego 2 tazas de café Al contenido del frasco y efectivamente llenó Todos los espacios vacíos entre la arena. Los estudiantes reían en esta ocasión. Cuando la risa se apagaba, el profesor dijo:

'Quiero que se den cuenta que este frasco representa la vida, las pelotas de golf son las cosas Importantes, como la espiritualidad,

Empresa y mercado 322

la familia, los hijos, la salud, Los amigos, todo lo que te apasiona. Son cosas, que aún si todo lo demás lo perdiéramos y solo éstas quedaran, nuestras vidas aún estarían llenas. Las

canicas son Las otras cosas que importan, como el trabajo, la casa, el auto, etc. La arena es todo Lo demás, las pequeñas cosas. Si ponemos la arena primero en el frasco, no habría espacio para las canicas ni para las pelotas de golf. Lo mismo ocurre con la vida. Si gastamos todo nuestro tiempo y energía en las cosas pequeñas, nunca tendremos lugar para las cosas

realmente importantes.

Presta atención a las cosas que son cruciales Para tu felicidad. Cuida tu relacion con Dios, juega con tus hijos, tómate tiempo para asistir al doctor, ve con tu pareja a cenar, practica tu deporte o afición favorita. Siempre habrá tiempo para limpiar la casa y reparar la llave del agua. Ocúpate de las pelotas de golf

primero, de las cosas que realmente importan. Establece tus prioridades, el resto es solo arena...' Uno de los estudiantes levantó la mano y pregunto que representaba el café. El profesor sonrió y dijo:

'Qué bueno que lo preguntas... Sólo es para demostrarles, que no importa cuán ocupada tu vida pueda parecer, siempre hay lugar para un par de tazas de café con un amigo.' Gracias Claudia.

Índice 323

Trabajos citados

Aprile, P. (2002). Elogio del imbécil. Temas de hoy. Beck, K. (2000). Extreme Programming Explained. Addison-Wesley. Beck, K. (17 de 6 de 2003). IBM. Recuperado el 1 de 07 de 2005, de Working smarter, not harder: An interview with Kent

Beck: http://www-128.ibm.com/developerworks/java/library/j-beck/ Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Fowler, M., y otros. (2001). Agile Manifesto. Recuperado el 2005, de http://www.agilemanifesto.org

Bernstein, L., & C.M., Y. (2005). Trustworthy Systems Through Quantitative Software Engineering. New Jersey: Wiley. Bruch, H., & Ghoshal, S. (2002). Beware The Busy Manager.

Harvard Business Review .

Carrison, D., & Walsh, R. (2004). Semper Fi. AMACOM. Chinanews.cn. (15 de 03 de 2007). Chinanews. Recuperado el 18 de 03 de 2007, de http://www.chinanews.cn/news/2005/2007-03-15/34231.html Cichelli, S. (5 de 30 de 2008). Girl Writes Code. Recuperado el 8

de 6 de 2008, de Agile Open Space: On Certifications: http://www.invisible-city.com/sharon/2008/05/agile-open-space-on-certifications.html

CMMI Models, Modules, and Reports. (s.f.). Obtenido de http://www.sei.cmu.edu/cmmi/models

Cockburn, A. (2004). Crystal Clear. Addison-Wesley. Coens, T. (2002). Abolishing Performance Appraisals: Why They Backfire and What to Do Instead. Berrett-Koehler Publishers. Crosby, P. B. (1996). Quality is Free. McGraw-Hill.

DeMarco, T. (1987). Peopleware. New York: Dorset House Pub.

Índice 324

Duncan, G. (21 de Junio de 2008). Are you "really" using Scrum". Recuperado el 29 de Junio de 2008, de Greg's Cool of the Day: http://coolthingoftheday.blogspot.com/2008/06/are-you-really-using-scrum.html

Eades, K. M. (2003). The New Solution Selling. Mc Graw Hill Professional. Freedman, D. H. (2001). Corps Business. HarperCollins Publishers.

Gilb, K. (2007). Evolutionary Project Management & Product Development. www.gilb.com. Glazer, H., Dalton, J., Anderson, D., Konrad, M., & Shrum, S. (2008). CMMI or Agile: Why Not Embrace Both! Software Engineering Institute.

Gorman, J. (28 de 01 de 2008). parlez uml/blog. Recuperado el 29 de 01 de 2008, de http://parlezuml.com/blog/?postid=566 Humphrey, W. S., Pomeroy-Huff, M., Mullaney, J., Cannon, R., &

Sebern, M. (2005). The Personal Software Process (PSP). Software Engineering Institute.

Hunt, A., & Thomas, D. (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley. Ikujiro, N., & Takeuchi, H. (1986). The New New Product Development Game. Harvard Business Review . Iturbe-Ormaetxe, J. (13 de 01 de 2006). Consultoría artesana en

la red. Recuperado el 04 de 01 de 2007, de http://artesaniaenred.blogspot.com/2006/01/idea-radical-no-

hay-direccin-de.html Kaner, C., Bach, J., & Pettichord, B. (2001). Lessons Learned in Software Testing. Wiley.

Kohn, A. (1999). Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes. Houghton Mifflin Co. Peter, L. J. (1969). The Peter Principle. William Morrow.

Índice 325

Phillips Brooks, F. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.

Poppendieck, M., Poppendieck, T., & Poppendieck, T. D. (2006).

Implementing Lean Software Development. Addison-Wesley. Poppendieck, T. (2003). Lean Software Development. Addison-Wesley. Rob, G., & Gareth, J. (1996). What Holds the Modern Company Together? Harvard Business Review .

Rosanas Martí, J. M. (2003). Cómo destrozar la propia empresa y creerse maravilloso. Granica. Ruhnow, A. (13 de Agosto de 2007). Agile2007. Recuperado el 08 de 2007, de

http://www.agile2007.org/index.php?page=sub/&id=671 Schwaber, K. (2004). Agile project management with Scrum. Microsoft Press.

Schwaber, K., & Beedle, M. (2001). Agile Software Development with Scrum. Prentice Hall.

Sprenger, R. K. (2002). El Mito de la Motivación. Cómo escapar de un callejón sin salida. Díaz de Santos. Webber, A. M. (2005). Danger: Toxic Company. Recuperado el 01 de 05 de 2005, de Fast Company: http://www.fastcompany.com/magazine/19/toxic.html

Índice

9 bloques, 191 adquisición, 87, 160, 217,

226 Agile Modeling, 263

agilidad, 63, 92, 111, 162, 229, 256, 315

contratos, 154 crítica, 67, 101 estrategia de producto,

279, 285, 295 manifiesto ágil, 79 métricas, 83, 113, 177

requisitos, 92, 178, 191 síntesis, 297

agilidad - disciplina enfrentamiento, 67, 98,

229 síntesis, 96, 106

agilidad – disciplina

síntesis, 116 ASD, 262 AUP, 129, 132 autogestión, 62 Bootstrap, 97 Burn Up, 196 CDT, 129, 132

CMM, 248 CMMI, 67, 71, 108, 129,

132, 141, 229, 250, 297 crítica, 72, 85, 90, 94 formación, 38, 102

CMMI-ACQ, 87

ConOps, 196 contrato, 154 coste laboral, 30, 283 crisis del software, 97 Crystal, 129, 133, 262 diseño, 149 documentación, 80

DSDM, 133, 259

eficiencia, 25, 29, 34, 164, 283

empresa, 229 calidad, 282

cultura, 16, 23, 31, 35, 104, 112, 210, 225,

270, 301 ética, 216 finalidad, 212, 225 gestión, 223, 235, 244,

269, 286 personalidad, 312

Enterprise Unified Process, 129, 134

equipo, 62 EssUp, 129

EssUP, 134 estimación, 113, 158, 174,

177

evaluación de desempeño, 24, 31

Evo, 129, 135 eXtreme Programming, 260 Extreme Programming, 129,

135 factor de escala, 296

FDD, 129, 136 Feature Driven

Development, 263 formación

crítica, 38, 102, 106 fundamentalismo, 125

gestión lineal, 273 personas, 24, 35, 39, 41,

42, 43, 48, 54, 58 sistémica, 274, 291

gestión de proyectos, 104, 162, 189

ágil, 167, 170

predictiva, 158, 167 gestión sistémica, 286 gestores, 293

incompetencia, 210, 215 gráfico burn-down, 175

gráfico burn-up, 187 incentivos, 25 ingeniería de procesos, 299 innovación, 91 Internet-Speed

Development, 263

intolerancia, 60

ISO 12207, 71, 88, 251, 297

ISO 15504, 71, 97, 129, 252, 297 crítica, 94

ISO15504, 136

ISO9000-3, 97 ITIL, 129, 137 Kanban, 198 Lean Software

Development, 129, 137 madurez, 310 Métrica 3, 70

métricas, 83, 164, 201 Microsoft Solutions

Framework, 264 Milgram, experimento de,

36 MoProSoft, 99 motivación, 15, 19, 40, 53,

294 destructores, 16

MSF, 129, 137 open source, 230, 232, 234 Open UP, 129 OpenUP, 138

personas, 288 carácter, 41, 56 valor, 27, 40, 43, 48, 77,

78, 80, 90, 118, 120, 241

PMBOK, 129, 138

Pragmatic Programming, 263

presupuesto, 147, 160 Prince, 129, 139 Prince2, 129, 139

procedimientos, 118, 289 procesos, 63, 94, 120, 238,

246 crítica, 72, 75 madurez, 108

product backlog, 178

Profesionalidad, 27

PSP, 164 requisitos, 171, 178, 196 reunión de planificación del

sprint, 182 RUP, 265 rutinas, 118

scrum, 261 crítica, 308 implantación, 306 origen, 74

roles, 305 Scrum, 126, 129, 139 Scrum Manager, 129, 140

ScrumMaster formación, 38, 103

selección de personal, 48 software

características, 148 software podrido, 150 SPICE, 97, 252

sprint backlog, 174 SWEBOK, 98

talento, 33, 40, 41, 42, 63 como materia prima, 77

TDD, 129, 140 tiempo, 201

tiempo ideal, 201 Unified Process, 129, 140 venta, 160, 222 visión, 92

empresa, 319