archivo

Archivos Mensuales: abril 2011

La teoría de las ventanas rotas tuvo su origen en un artículo escrito por George L. Kelling y James Q. Wilson que apareció en prensa en el año 1982.

¿En qué consiste?. Lo describen de la siguiente forma:

“Consideren un edificio con una ventana rota. Si la ventana no se repara, los vándalos tenderán a romper unas cuantas ventanas más. Finalmente, quizás hasta irrumpan en el edificio, y si está abandonado, es posible que sea ocupado por ellos o que prendan fuegos adentro.

O consideren una acera. Se acumula algo de basura. Pronto, más basura se va acumulando. Eventualmente, la gente comienza a dejar bolsas de basura de restaurantes de comida rápida o a asaltar coches.”

Básicamente lo que vienen a decir es que elementos contaminantes en cualquier ámbito favorecen la aparición de nuevos elementos contaminantes.

Si nos llevamos esta teoría al funcionamiento de los equipos de trabajo en las organizaciones, estaríamos ante el caso de que personas no productivas tienden a hacer menos productivas a las personas que tienen a su alrededor y a todos aquellos que se vayan incorporando a la organización.

A los primeros porque salvo que estén muy motivados, terminarán por cansarse de ser ellos los que se implican y los que se preocupan y a los segundos porque se encuentran ya con esa situación, no tienen un buen ejemplo, es decir, si llegan a un departamento donde la mayoría pasa un 25% de su jornada laboral navegando por Internet, participando en redes sociales o escribiendo/contestando correos personales, probablemente terminen adquiriendo esos hábitos, al fin y al cabo es la situación normal en ese entorno laboral (lo anormal, es precisamente no hacer eso), otro posible ejemplo es que si en un departamento no se toman medidas contra aquellos empleados que no cumplan objetivos (por ejemplo que pese a ello se les siga promocionando), lo que vendrá a continuación es que cada vez sean más los que los incumplan porque al fin y al cabo no pasa nada.

Desde mi punto de vista, en cada organización es necesario mantener un orden y para ello es necesario que los trabajadores tengan unas condiciones laborales basadas en hechos objetivos, esto no es lo mismo que condiciones rígidas. Quien las incumpla, debe ser advertido, si las sigue incumpliendo lo mejor es que salga de la organización, tanto por el hecho de no estar respetando las condiciones que se le hayan planteado como para evitar que su conducta contamine a más personas.

Anuncios

Ralph E. Johnson es profesor universitario y especialista en la utilización de patrones de diseño y de la programación orientada a objetos.

Precisamente por ser esa su especialidad, resulta llamativa su siguiente cita (traducción libre): “Antes de que el software sea reutilizable primero debe ser utilizable”.

Y es verdad, de nada sirve un software técnicamente perfecto si después no hace lo que el usuario quiere. Si bien todo no es ni blanco ni negro, ya que no solo se debe buscar el cumplimiento de objetivos funcionales sino que también hay que pensar que el producto software va a requerir de sucesivas evoluciones y las mismas serán tan costosas como malo haya sido el diseño y la codificación (la deuda técnica).

Hace poco asistí a un curso de SGSI. Decidí asistir al mismo ya que al estar centrado en la gestión de proyectos de desarrollo de software, existen determinados aspectos como la seguridad de la información sobre los cuales no tengo excesivos conocimientos y además necesitaba una cierta actualización de los que ya tenía.

En el curso se planteaba la problemática de que costaba implantar medidas efectivas de gestión de la seguridad de la información ya que por mucho que se trabajase y por mucho que se invirtiese, siempre se rompía la cadena por el eslabón más débil que no es otro que las personas.

El problema es la falta de conciencia de la importancia que tienen la seguridad de los activos de una entidad, la cual llega hasta los niveles más altos de la organización que no terminan de priorizar adecuadamente estas tareas integrándolas como un proceso más.

A esto hay que sumarle el hecho de que exista una creencia generalizada de que la seguridad de la información se considera algo que es función del Departamento de Informática y como tal el resto de Departamentos suelen descargarse de responsabilidad.

El Departamento de Informática se encuentra con un problema ya que ahí sí que existe conciencia de la necesidad de aplicar una serie de medidas de seguridad que no es otro que tener que liderar las distintas acciones que se tomen al respecto, sin tener el apoyo del resto de departamentos y en muchos casos sin ser considerado algo prioritario desde arriba.

Al final, mucho esfuerzo que conseguirá determinados objetivos pero sin poder llegar a las personas y con la sensación de que se está luchando solo contra molinos de viento.

En los Departamentos de Desarrollo sucede algo parecido, ¿en cuántos proyectos los usuarios no han hecho adecuadamente su labor, teniendo que suplir el equipo de proyecto muchas de las funcionalidades que no han sido correctamente definidas?, ¿en cuántos proyectos los usuarios han cambiado, incluso radicalmente, los requisitos en etapas tardías de la construcción?, pero en los Departamentos de Seguridad es incluso peor, porque los sistemas y sus resultados se pueden ver, pero la seguridad no (solo se ve cuando hay un problema, que suele ser importante y del que por supuesto se hecha la culpa a Informática).

Lo he comentado en muchas ocasiones. En una negociación el cliente tiene todas las de ganar frente al proveedor, sobre todo si todavía no ha pagado. Por tanto y a las malas, el cliente puede forzar en una negociación y conseguir unas condiciones beneficiosas.

Los proveedores existen más allá del proyecto y las personas que trabajan en ellos mañana pueden estar en otras empresas, por ese motivo soy de la opinión de que no se debe forzar más allá de lo que se considera justo en función de cómo ha evolucionado el proyecto, cómo se ha comportado el proveedor en el mismo y cuál es presupuesto disponible.

Si abres un abismo con un proveedor o con una serie de personas después resulta muy complicado trabajar, por muy profesional que se sea, ya que la desconfianza impide que se cierren las heridas y no es cuestión de rencor. Puedes estar enfadado, muy enfadado, pero eso se supera si la confianza no se ha roto por completo (y no es nada difícil que se haga añicos).

Si el proyecto ha ido conforme a lo pactado y el proveedor ha realizado su trabajo de manera adecuada hay que ser justos en una negociación, lo cual no quiere decir que no intentemos defender la postura de nuestra organización e intentar conseguir un acuerdo favorable. Eso es lícito y entran en juego las habilidades de las personas que intervienen, pero no se debe abusar de la posición de poder (una cosa es utilizarla a tu favor y otra golpear con ella).

A veces se termina mal, muy mal, a veces será culpa del cliente, otras del proveedor y otras de las dos partes y esto sucederá porque no siempre se puede tener todo bajo control, porque existirán presiones externas que harán todo más difícil o porque no se ha querido ver que tras el proyecto vendrán otros más.

En el anterior artículo se describieron los principios en los que se sustenta esta metodología. Ahora toca analizar las distintas fases que conforman su ciclo de vida.

1) Exploración

Se realiza la toma de contacto con el proceso o procesos de negocio que se van a informatizar así como con la arquitectura y tecnología de desarrollo. Básicamente se realizan las siguientes tareas:

Historias de usuario: Suponen una de las principales novedades de la metodología y no por el producto en sí, sino por cómo se elabora. Se trata de especificaciones de funcionalidades deseadas del sistema (podrían ser comparables a descripciones de casos de uso) que realizan los mismos usuarios (el mismo cliente), por lo que sus contenidos están en el mismo lenguaje que los usuarios manejan.

Se trata de especificaciones iniciales cuyo nivel de detalle dependerá de la información que precisen los programadores para realizar una estimación del tiempo que requerirá su implementación. Más adelante, cuando se vaya a abordar el proceso de construcción, los programadores recabarán todo el detalle que necesiten para el desarrollo de la funcionalidad mediante el diálogo directo con el cliente.

A nivel documental, una historia de usuario será como una ficha, a la que se le asigna una numeración (sería como el ID de la ficha), un nombre, un autor, un número de versión (una historia de usuario puede retocarse todas las veces que sean necesarias), una prioridad, un nivel de riesgo, una estimación de tiempo de desarrollo, el número de iteración que se le asigna, una descripción y unas observaciones.

Como es puede apreciar, existen diversos aspectos que cumplimentan los técnicos del proyecto (o el mismo usuario si el técnico le facilita la información), pero la mayor parte de la ficha es responsabilidad del cliente.

– Definición de la arquitectura del sistema.

– Posibilidad de realizar algún prototipo, si fuera necesario, para determinar la viabilidad de determinadas soluciones técnicas o tecnológicas.

2) Planificación:

Los programadores realizan la estimación del tiempo necesario para implementar cada historia de usuario. En algunos casos será necesario complementarlas con spikes, que pueden ser desde simples bosquejos a mano alzada, prototipos estáticos, prototipos dinámicos, etc…, estos, en función de su complejidad, podrán ser elaborados por usuarios, técnicos o de forma colaborativa. El objetivo es intentar disminuir en lo posible el margen de error en la estimación.

Las historias de usuario pueden contener especificaciones de funcionalidades simples o complejas (composición de funcionalidades). Dado que se considera que cada historia de usuario debe ser programada entre una y tres semanas, es necesario realizar ajustes en las mismas para que entren en ese período de tiempo, de manera que si se estima que se desarrollan en menos de una semana es necesario agrupar historias de usuario y si tardan más de tres semanas, dividirlas en partes.

Una vez que las tareas de estimación han terminado, el siguiente producto a obtener es el plan o cronograma de entregas (Release Plan), en el que participan todos los actores del proyecto. En él se definen las historias de usuario que se implementan en cada iteración.

Como estamos ante un proceso de desarrollo iterativo e incremental, resulta conveniente la revisión de este Release Plan cada cierto número de iteraciones, con el objeto de ajustarlo en cada momento a la realidad del proyecto (en el desarrollo de las iteraciones pueden aparecer nuevas historias de usuario o modificaciones de las ya existentes) y de corregir aspectos de la planificación que no se hayan estimado convenientemente, como por ejemplo la velocidad del proyecto (número de historias de usuario que se pueden implementar por iteración), ya que lo mismo se ha sido demasiado optimista o pesimista.

Se considera que cada iteración debe llevar a lo sumo dos o tres semanas (hay autores que sitúan el margen entre una y cuatro semanas) y que una entrega completa (el resultado de varias iteraciones disponible para su paso a producción) no debería tardar más de tres meses.

3) Iteraciones

Se desarrolla en cada iteración el conjunto de historias de usuario que se han seleccionado para la misma. Cada una de ellas se clasifica en tareas de ingeniería que vendrían a considerarse como las entradas de trabajo para cada equipo de programadores.

A nivel documental, como sucede con las historias de usuario, las tareas de ingeniería vendrían a ser como una ficha que contendría el número identificador de la tarea, el identificador de la historia de usuario con la que está relacionada, el nombre de la tarea, el tipo (nuevo desarrollo, corrección, mejora, etc…), la fecha de inicio, su fecha de fin, el equipo responsable y la descripción.

Como se comentó anteriormente los detalles que necesite el equipo de trabajo para realizar la tarea de ingeniería los tratará directamente con el usuario.

Cuando se construye se tienen en cuenta todas las prácticas especificadas en el primer artículo: construcción de pruebas unitarias, refactorización, pruebas unitarias, pruebas de integración, etc…

Para cada historia de usuario se definen pruebas de aceptación que deben ser realizadas (como mínimo) al final de cada iteración, donde también se realizan pruebas de regresión (comprobando que se verifican adecuadamente las pruebas de aceptación de iteraciones anteriores).

4) Producción:

Se realizan pruebas adicionales y de rendimiento antes de la puesta en producción efectiva de la versión de la aplicación con la que se ha estado trabajando.

En esta fase, donde el cliente realiza la aceptación del producto que se pasa a producción pueden ser detectadas determinadas correcciones o mejoras a incorporar al sistema previo a su puesta en funcionamiento real. Sobre las mismas se puede tomar la decisión de incluirlas en esta versión o en otra sucesiva, si se decide incorporarlas, se realizarán iteraciones más cortas para llevarlas a cabo.

5) Mantenimiento:

En esta fase el equipo de proyecto debe realizar, si fuera necesario, un mantenimiento correctivo del proyecto mientras puede llevar a cabo nuevas iteraciones.

6) Muerte del proyecto:

No existen más historias de usuario que incluir en el sistema, el cual además es estable en aspectos no funcionales.

Además de la separación entre el mundo físico y el lógico, el hecho de que el software no se desgaste es a mi juicio una de las dos principales diferencias que tiene con el hardware, sobre todo teniendo en cuenta las tendencias actuales en el mundo del desarrollo orientadas a su industrialización, la reutilización de componentes, la delegación de funcionalidades en otros sistemas, etc… Si bien es cierto que el software tiene un componente de desarrollo a medida que es inherente a él mismo, ocurriendo esto incluso en la orientación al producto, donde en muchos casos hay que hacer adaptaciones para clientes concretos.

La otra diferencia es el propio proceso de obtención de un nuevo componente físico donde no es posible conseguir nada si no se disponen de los materiales necesarios, si se dispone de la materia prima la cadena de montaje empieza a funcionar hasta que se obtiene el producto. Es decir, la obtención de un nuevo producto idéntico a otro tiene un coste. Con el software no pasa eso, una vez construido obtener una copia es algo inmediato y sin coste. Lo mismo pasa con otros productos lógicos digitales como la música o el vídeo.

El software una vez desarrollado no se desgasta, no se estropea. Puedes dejar un programa diez mil años en un dispositivo y sobrevivirá tanto tiempo como el dispositivo que lo contiene y si antes lo has copiado garantizará su continuidad en otro (otra cosa distinta es que se pueda ejecutar o interpretar, este tema lo trato en el artículo: “La oscura era digital”).

Pero el software sí se deteriora, sufre mucho con los mantenimientos, ya sean correctivos, evolutivos, adaptativos o perfectivos (depende de lo que se quiera perfeccionar). El deterioro no tiene por qué ser idéntico en todos los sistemas. Dependerá de muchos factores: la calidad del producto final (a nivel de arquitectura y codificación), su tamaño, de si el equipo de mantenimiento es distinto del de desarrollo y ha existido un período de transición suficiente para poder hacerse cargo de la herramienta, de la urgencia con que sea necesario realizar los mantenimientos y de la cantidad de los mismos (si todo es prioritario y para ya, hay un problema) y de la metodología utilizada (si la misma hace hincapié en la refactorización del código con el objeto de controlar su nivel de calidad y simplicidad el deterioro será sensiblemente menor).

De manera objetiva pudimos comprobar esto en mi organización tras los primeros meses de implantación de Sonar.

Detrás de todas las metas y objetivos que nos marcamos y luchamos se encuentra el propósito que sirve de motor a las mismas.

Al cumplimiento de un objetivo, aparecerán nuevos retos a los cuales seguirán otros. El propósito permanecerá, podrá tener algunos cambios, pero es como nuestra sombra ya que nos acompaña a todos lados.

El propósito no algo a corto, medio o largo plazo, sino que es aquello a lo que se pretende llegar, pero es atemporal, ya que se encuentra dentro de nosotros mismos, como un molde esperando a ser rellenado. El cumplimiento de nuestras metas reúne los ingredientes, los mezcla de la forma adecuada y los vierte en el recipiente.

¿Cuál es nuestro propósito?, ¿qué nos mueve?, identificarlo resulta fundamental porque de lo contrario es como tener delante nuestra un mapa, un vehículo pero no saber a dónde ir. Conocer el destino no lo es todo, hay que llegar allí y ahí es donde entramos nosotros para poner los medios adecuados para llegar a él.