Otra entrevista más. Si tenemos suerte no se alargará más de la cuenta. Si tenemos aun más suerte no divagaremos demasiado y hasta seremos capaces de entender los requisitos o aquello que sea que nos pide el entrevistado. Y, si ya somos enormemente afortunados, encontraremos la forma de transmitir todo aquello a lo que llamamos requisitos de usuario en algo comprensible para el equipo de desarrollo.
Detrás de esa suerte, por supuesto, se encuentra el talento. Y, un poco más atrás (habitualmente al fondo a la derecha), los recursos metodológicos habituales. Hoy vamos a centrarnos precisamente en esta última parte...
Puedes ver el contenido de este artículo pinchando aquí...
miércoles, 24 de junio de 2009
sábado, 28 de marzo de 2009
Trazabilidad por "generación espontánea"
Hablemos de trazabilidad, uno de los argumentos más usados en los departamentos de calidad para justificar muchas de las normativas impuestas.
Después de mucho tiempo, hay un consenso generalizado y casi todo el mundo tiene claros los beneficios de mantener la trazabilidad entre los requisitos y el resto de artefactos del ciclo de vida del software. Y, sin embargo, existen aun muchas dudas sobre cómo gestionar la trazabilidad de manera eficaz.
Fijémonos en uno de los tipos de trazabilidad más controvertida. La que nos lleva de los requisitos del producto al código fuente que lo implementa. Si nos marcamos como referencia el modelo CMMI, y consideramos el código del producto como un work product, queda claro que hay que mantener esa trazabilidad. La pregunta es cómo, momento en el que CMMI nos deja solos ante el peligro…
Lo primero, y a efectos prácticos, es saber hasta qué nivel de granularidad es necesario definir y mantener la trazabilidad. En lo que respecta al código, y por su propia naturaleza, se establecen relaciones de trazabilidad muy especiales de las que nos podemos aprovechar. Siendo realistas, reconozcamos que es muy difícil mantener la relación entre cada requisito y cada pieza de código que los implementa. El nivel de cambios al que está expuesto el código fuente es altísimo, por tanto consideremos cuidadosamente qué ganamos trazando a muy bajo nivel.
Creo que lo más práctico es identificar las partes del código más abstractas, más relevantes a nivel funcional y a partir de las cuales se pueda navegar fácilmente a componentes de más bajo nivel. Estos puntos de entrada al código dependen de cada tecnología, obviamente, pero en general son componentes de tipo fachada muy habituales en todos los diseños que se precien. Y es ahí exactamente donde deberían apuntar las trazas. Además, estos puntos de entrada tienen otras características realmente interesantes. Su relativa estabilidad ante los cambios, su gran protagonismo en la fase de pruebas de integración y, de cara a realizar análisis de impacto (si nos cambian un requisito), son más que suficientes.
De manera que siendo capaces de identificar esos puntos de entrada al código tendremos mucho ganado. El modelo de trazabilidad sería similar a este:
NECESIDAD
--> ESPECIFICACION REQUISITO(s)
--> CASO(s) DE USO
--> PUNTO(s) de ENTRADA AL CODIGO
--> RESTO DEL CÓDIGO
Lo bueno de esto es que la última flecha, el último nivel de traza, se mantiene solo y de manera natural. Casi por… "generación espontánea".
LUIS REYES
Después de mucho tiempo, hay un consenso generalizado y casi todo el mundo tiene claros los beneficios de mantener la trazabilidad entre los requisitos y el resto de artefactos del ciclo de vida del software. Y, sin embargo, existen aun muchas dudas sobre cómo gestionar la trazabilidad de manera eficaz.
Fijémonos en uno de los tipos de trazabilidad más controvertida. La que nos lleva de los requisitos del producto al código fuente que lo implementa. Si nos marcamos como referencia el modelo CMMI, y consideramos el código del producto como un work product, queda claro que hay que mantener esa trazabilidad. La pregunta es cómo, momento en el que CMMI nos deja solos ante el peligro…
Lo primero, y a efectos prácticos, es saber hasta qué nivel de granularidad es necesario definir y mantener la trazabilidad. En lo que respecta al código, y por su propia naturaleza, se establecen relaciones de trazabilidad muy especiales de las que nos podemos aprovechar. Siendo realistas, reconozcamos que es muy difícil mantener la relación entre cada requisito y cada pieza de código que los implementa. El nivel de cambios al que está expuesto el código fuente es altísimo, por tanto consideremos cuidadosamente qué ganamos trazando a muy bajo nivel.
Creo que lo más práctico es identificar las partes del código más abstractas, más relevantes a nivel funcional y a partir de las cuales se pueda navegar fácilmente a componentes de más bajo nivel. Estos puntos de entrada al código dependen de cada tecnología, obviamente, pero en general son componentes de tipo fachada muy habituales en todos los diseños que se precien. Y es ahí exactamente donde deberían apuntar las trazas. Además, estos puntos de entrada tienen otras características realmente interesantes. Su relativa estabilidad ante los cambios, su gran protagonismo en la fase de pruebas de integración y, de cara a realizar análisis de impacto (si nos cambian un requisito), son más que suficientes.
De manera que siendo capaces de identificar esos puntos de entrada al código tendremos mucho ganado. El modelo de trazabilidad sería similar a este:
NECESIDAD
--> ESPECIFICACION REQUISITO(s)
--> CASO(s) DE USO
--> PUNTO(s) de ENTRADA AL CODIGO
--> RESTO DEL CÓDIGO
Lo bueno de esto es que la última flecha, el último nivel de traza, se mantiene solo y de manera natural. Casi por… "generación espontánea".
LUIS REYES
martes, 15 de mayo de 2007
Requisitos y especificaciones
Existe una confusión generalizada entre requisitos y especificaciones de un producto. Si bien, éstas pueden considerarse como requisitos, la inversa no aplica en muchas ocasiones.
Esto se produce sobre todo en contextos donde tenemos que evolucionar un producto, del cual exisiten diversas especificaciones y nuevos 'requisitos' cada cierto tiempo, que implican ampliar, actualizar o incluso rebajar dichas especificaciones.
Confundir ambos conceptos es muy peligroso, no solo en términos de redundancia de información sino en terminos de planificación, gestión de trazas, gestión de cambios, etc.
Los requisitos son inestables, ambiguos, cambiantes, volátiles; lo bueno es que no hay nada de malo en ello, siempre y cuando estos requisitos sean derivados (mediante múltiples técnicas en las que no entraré ahora) y estabilizados en especificaciones sólidas y consistentes para el desarrollo posterior.
Esto se produce sobre todo en contextos donde tenemos que evolucionar un producto, del cual exisiten diversas especificaciones y nuevos 'requisitos' cada cierto tiempo, que implican ampliar, actualizar o incluso rebajar dichas especificaciones.
Confundir ambos conceptos es muy peligroso, no solo en términos de redundancia de información sino en terminos de planificación, gestión de trazas, gestión de cambios, etc.
Los requisitos son inestables, ambiguos, cambiantes, volátiles; lo bueno es que no hay nada de malo en ello, siempre y cuando estos requisitos sean derivados (mediante múltiples técnicas en las que no entraré ahora) y estabilizados en especificaciones sólidas y consistentes para el desarrollo posterior.
miércoles, 21 de marzo de 2007
La estratosfera y los consultores galácticos
La estratosfera es coto privado de algunos pocos afortunados.
Existen grandes consultoras e integradoras, de sobra conocidas, que han hecho un arte de la ambigüedad, la falta de concrección y la abstracción ilimitada de las soluciones que ofrecen, hasta llevarlas a un punto cercano a la idiotez.
Presentaciones, documentos de consultoría, artículos, opiniones,... muchas de ellas están infectadas por ese virus. Podemos llamarle virus aunque pienso que es una estrategia bien orquestada para cubrir dos objetivos fundamentales:
- Reutilizar trabajos anteriores para trabajar menos. Mientras mas abstracta sea la solución, más se puede reutilizar.
- Evitar entrar en conflictos (véase el temor al conflicto). Cuanto mayor sea el nivel 'estratosférico', menor es la posibilidad de desacuerdo, por tanto, conflicto. Claro, no conviene enfangarse en discusiones para las que pueden quedar al descubierto las vergüenzas de los consultores y consultoras 'galácticos'.
Hay que reconocer que han sido capaces de 'estandarizar' ese nivel 'estratosférico' como adecuado para las soluciones que ofrecen. Así, tenemos un monton de 'expertos de whitepaper'. Aquellos que leyendo un whitepaper conocen todo lo necesario para permanecer cómodos y, hasta parecer expertos en ese nivel 'estratosférico'
He ahí el verdadero consultor galactico, aquel que es capaz de parecer experto en múltiples tecnologías, soluciones o métodos de trabajo. Un ser capaz de devorar panfletos escritos por sus semejantes, con los que se entiende y a los que admira. Aquel que habrá recomendado en las más importantes compañias cual debía ser la solución que 'otros' (pobres seres terrícolas) han tenido que implementar.
sábado, 17 de febrero de 2007
Repetibilidad
Supongamos que somos los responsables en una organización de que se lleven a cabo un conjunto de tareas. Lo más probable es que nos interese que se realicen bien. Existen dos métodos simples para que las cosas se hagan bien: el primero es hacerlas nosotros mismos y el segundo es encargárselas a personas de nuestra confianza. A posteriori, tenemos las mismas dos opciones para asegurarnos de que las cosas realmente se hicieron bien: revisarlas nosotros mismos o que lo haga alguien de nuestra confianza.
¿Pero qué pasa si no tenemos tiempo o conocimientos para revisar la ejecución de las tareas o el resultado de las mismas? ¿Y si tampoco conocemos a alguien de confianza para que lo haga por nosotros? Siempre está la posibilidad de contratar a alguien, pero pagar a alguien es un poco como pagar a una prostituta: nos va a dar lo que queremos, si gastamos mucho dinero podremos presumir de con quién hemos estado... pero lo más probable es que todo sea fingido. Siguiendo con el símil, existe la alternativa de la boda: ofrecer una posición permanente, seguridad y buenas condiciones. Pero como en los matrimonios, la rutina, la desgana y las recriminaciones están a la vuelta de la esquina.
Y eso es porque la revisión de la calidad del trabajo no es el la labor más excitante ni la más reconocido. Sobretodo porque es un montón de trabajo que requiere un montón de personas. Y cuando una tarea -que, seamos francos, proporciona un valor tan discutible a la organización por no hablar a corto plazo- requiere muchas personas altamente cualificadas lo que se suele hacer es contratar a unos pocos, menos preparados y con la finalidad de explotarlos.
Así, en el mejor de los casos, nos encontramos con un grupo de revisores de la calidad descontentos, mal pagados y con demasiado trabajo. En tales condiciones, lo único que se puede pedir es que al menos su trabajo sea sencillo. Idealmente la revisión de la calidad estaría totalmente automatizada pero no siendo así es imprescindible que las tareas manuales sean repetitivas: no sé le puede pedir a una persona que revise hoy el ensamblado del SEAT Panda y mañana la traducción al japonés de su manual de usuario.
Es decir, para que una persona que no esté especialmente preparada y motivada sea capaz de controlar la calidad es necesario que los productos y actividades sean siempre iguales. Una gran variedad en los procesos de desarrollos o las tecnologías de desarrollo que utilizamos nos condena a utilizar controles de calidad genéricos -incapaces de tratar gran parte de los problemas en su origen.
Así, la introducción de una nueva tecnología supone un cambio en el proceso de desarrollo y una merma de nuestra capacidad para controlarlo. El coste que de esto se deriva ha de ser tenido en cuenta antes de introducir nuevas herramientas (o utilizar nuevos proveedores).
Tendencias:
1) Metodologías OpenSource como instancias de los estándares de calidad. Basta de pagar a las grandes consultoras por procesos propietarios cuya calidad queda fuera de nuestro control.
2) Extensiones asfixiantemente específicas de 1) para soluciones tecnológicas concretas. Basta de pagar a nuestros empleados por el "tuning" de arquitecturas y metodologías, y
3) Automatización de 1) y 2).
¿Pero qué pasa si no tenemos tiempo o conocimientos para revisar la ejecución de las tareas o el resultado de las mismas? ¿Y si tampoco conocemos a alguien de confianza para que lo haga por nosotros? Siempre está la posibilidad de contratar a alguien, pero pagar a alguien es un poco como pagar a una prostituta: nos va a dar lo que queremos, si gastamos mucho dinero podremos presumir de con quién hemos estado... pero lo más probable es que todo sea fingido. Siguiendo con el símil, existe la alternativa de la boda: ofrecer una posición permanente, seguridad y buenas condiciones. Pero como en los matrimonios, la rutina, la desgana y las recriminaciones están a la vuelta de la esquina.
Y eso es porque la revisión de la calidad del trabajo no es el la labor más excitante ni la más reconocido. Sobretodo porque es un montón de trabajo que requiere un montón de personas. Y cuando una tarea -que, seamos francos, proporciona un valor tan discutible a la organización por no hablar a corto plazo- requiere muchas personas altamente cualificadas lo que se suele hacer es contratar a unos pocos, menos preparados y con la finalidad de explotarlos.
Así, en el mejor de los casos, nos encontramos con un grupo de revisores de la calidad descontentos, mal pagados y con demasiado trabajo. En tales condiciones, lo único que se puede pedir es que al menos su trabajo sea sencillo. Idealmente la revisión de la calidad estaría totalmente automatizada pero no siendo así es imprescindible que las tareas manuales sean repetitivas: no sé le puede pedir a una persona que revise hoy el ensamblado del SEAT Panda y mañana la traducción al japonés de su manual de usuario.
Es decir, para que una persona que no esté especialmente preparada y motivada sea capaz de controlar la calidad es necesario que los productos y actividades sean siempre iguales. Una gran variedad en los procesos de desarrollos o las tecnologías de desarrollo que utilizamos nos condena a utilizar controles de calidad genéricos -incapaces de tratar gran parte de los problemas en su origen.
Así, la introducción de una nueva tecnología supone un cambio en el proceso de desarrollo y una merma de nuestra capacidad para controlarlo. El coste que de esto se deriva ha de ser tenido en cuenta antes de introducir nuevas herramientas (o utilizar nuevos proveedores).
Tendencias:
1) Metodologías OpenSource como instancias de los estándares de calidad. Basta de pagar a las grandes consultoras por procesos propietarios cuya calidad queda fuera de nuestro control.
2) Extensiones asfixiantemente específicas de 1) para soluciones tecnológicas concretas. Basta de pagar a nuestros empleados por el "tuning" de arquitecturas y metodologías, y
3) Automatización de 1) y 2).
martes, 12 de diciembre de 2006
El temor al conflicto
Existe una raza muy especial de responsables de IT o areas subordinadas. Realmente esa raza se ha extendido a múltiples departamentos y unidades de negocio de diferentes empresas.
Se trata en general de personas que no suelen tener mucha idea de lo que hablan, pero lo hacen de una manera autoritaria, agresiva, vehemente... en fin, variables que superan con creces a otras como conocimiento, sentido común, respeto a las opiniones, etc.
En un entorno inmaduro como en el que nos movemos, en el que habitualmente hay bastante rechazo al conflicto, triunfan los mentirosos y los despotas.
Los mentirosos triunfan porque el mar de ambigüedad y desconocimiento que muchas veces rodea las cuetiones tecnológicas o metodológicas no da pie a discusiones serias, en las que se puedan defender o atacar argumentos de manera relativamente sólida. Ahí ganan los mentirosos sutiles, los que no parece que mienten, o si lo parece, mejor creerse lo que dicen por evitar un conflicto absolutamente esteril.
Al igual que los mentirosos, los despotas triunfan porque son capaces de imponer sus ideas u opiniones a fuerza de agresividad y rudeza. Ahí, por evitar conflictos en este caso más desagradables, también ganan ellos.
Normalmente, los mentirosos suelen estar en la trinchera del proveedor, en forma de comerciales o consultores 'galácticos'. Por el contrario, despotas los solemos encontrar en clientes finales, tomando forma de directores de area, unidades de negocio, responsables de factorías de software y un largo etcétera.
Lo peor es cuando se juntan mentirosos y despotas; en ese momento, el espéctáculo está asegurado. Habitualmente, suelen juntarse en el proceso de venta o en el proceso de cierre de los proyectos, es decir, cuando nadie quiere conflictos, es más, cuando todo el mundo los teme.
Así, los mentirosos venden proyectos a base de falsedades, las cuales son matizadas (normalemente para mal) por parte de los despotas, porque si no, no hay trato.
Se trata en general de personas que no suelen tener mucha idea de lo que hablan, pero lo hacen de una manera autoritaria, agresiva, vehemente... en fin, variables que superan con creces a otras como conocimiento, sentido común, respeto a las opiniones, etc.
En un entorno inmaduro como en el que nos movemos, en el que habitualmente hay bastante rechazo al conflicto, triunfan los mentirosos y los despotas.
Los mentirosos triunfan porque el mar de ambigüedad y desconocimiento que muchas veces rodea las cuetiones tecnológicas o metodológicas no da pie a discusiones serias, en las que se puedan defender o atacar argumentos de manera relativamente sólida. Ahí ganan los mentirosos sutiles, los que no parece que mienten, o si lo parece, mejor creerse lo que dicen por evitar un conflicto absolutamente esteril.
Al igual que los mentirosos, los despotas triunfan porque son capaces de imponer sus ideas u opiniones a fuerza de agresividad y rudeza. Ahí, por evitar conflictos en este caso más desagradables, también ganan ellos.
Normalmente, los mentirosos suelen estar en la trinchera del proveedor, en forma de comerciales o consultores 'galácticos'. Por el contrario, despotas los solemos encontrar en clientes finales, tomando forma de directores de area, unidades de negocio, responsables de factorías de software y un largo etcétera.
Lo peor es cuando se juntan mentirosos y despotas; en ese momento, el espéctáculo está asegurado. Habitualmente, suelen juntarse en el proceso de venta o en el proceso de cierre de los proyectos, es decir, cuando nadie quiere conflictos, es más, cuando todo el mundo los teme.
Así, los mentirosos venden proyectos a base de falsedades, las cuales son matizadas (normalemente para mal) por parte de los despotas, porque si no, no hay trato.
Calidad y urgencia
Las cosas se pueden hacer bien o mal. Para hacer las cosas bien hay que hacerlas con cuidado, sin urgencia. En general hacer las cosas con cuidado tiene ciertas ventajas, ya que se supone que mejora la calidad del resultado final y disminuye los problemas y las culpas.
El problema de hacer las cosas con cuidado es que es incompatible con las urgencias. Y hacer las cosas con prisas tiene al menos dos ventajas cuya importancia no hemos de minusvalorar:
(Corolario: se puede presionar a un programador para que trabaje acabando una aplicación durante el fin de semana, pero luego no se le puede pedir que documente las pruebas unitarias)
El problema de hacer las cosas con cuidado es que es incompatible con las urgencias. Y hacer las cosas con prisas tiene al menos dos ventajas cuya importancia no hemos de minusvalorar:
- Cuando hacemos las cosas con prisas, podemos culpar a las prisas de la mala calidad del resultado, con lo que se reduce nuestra responsabilidad. Esto es una gestión sencilla de las culpas a la que no hay que renunciar sin considerar los riesgos.
- Cuando tenemos prisa, podemos presionar a nuestros subordinados para que trabajen más horas. Esto simplifica nuestra gestión, ya que evitamos la responsabilidad de la planificación y el seguimiento de los proyectos.
(Corolario: se puede presionar a un programador para que trabaje acabando una aplicación durante el fin de semana, pero luego no se le puede pedir que documente las pruebas unitarias)
Suscribirse a:
Comentarios (Atom)