archivo

Archivos diarios: noviembre 19, 2011

Es el siguiente escalón en los niveles de madurez de CMMI. Del caos del nivel 1, se pasa al nivel 2 en un modelo donde se administran/gestionan procesos orientados a proyectos y de ahí al nivel 3 donde los procesos tienen una orientación a nivel del departamento o de la organización. El siguiente nivel de CMMI pretende la gestión cuantitativa de los procesos que se han definido de manera que los mismos puedan ser predecibles (hacia dónde vamos) y analizables de manera cuantitativa (dando una mayor objetividad a su análisis).

Si en el nivel 2 teníamos un área de proceso de medición y análisis, en este caso se trata de aplicar un concepto similar pero un amplio abanico de procesos, interdependientes muchos de ellos y que se aplican al conjunto de proyectos de desarrollo en los que participa la organización.

El propio control del correcto desempeño de las áreas de proceso de nivel 3 se podría considerar suficiente, sin embargo es en este nivel donde se le da carta de naturaleza a la administración y gestión de las mismas.

Por tanto, en este nivel se utilizarán estrategias y herramientas que permitan obtener el desempeño/rendimiento real (presente) de las áreas de proceso implantadas y los productos y servicios que ofrece la organización, así como su comportamiento futuro.

Si los usuarios no toman responsabilidad sobre los requisitos que solicitan y sobre los cambios que piden, si el equipo de proyecto decide explotar su creatividad cuando no conviene o cuando no interesa y si los responsables técnicos y funcionales no imponen racionalidad a la hora de desarrollar o mantener el software tendremos al final un sistema de información similar a un mando a distancia: lleno de funcionalidades, pero de las cuales solo se utilizarán un 20%.

El objetivo no es llenar un sistema de utilidades que no se van a usar nunca o que su uso vaya a ser residual, el objetivo debe ser que el sistema cuente con las funcionalidades precisas para realizar su actividad, todo lo demás ha sido una pérdida de dinero, de tiempo, que probablemente ha impactado, además, en la calidad de lo que sí resulta necesario y en el coste de la propia evolución del sistema de inforamación.

Que te cambien los requisitos en fases avanzadas del desarrollo hace daño al proyecto si no se ha utilizado una metodología adecuada, si el producto que se está realizando tiene una deuda técnica inapropiada y si los stakeholders no están educados no solo en la propia realidad del desarrollo de software sino en la propia realidad de los cambios en la organizaciones y en consecuencia de sus personas y procesos.

Son muchos factores como para no hacer daño y precisamente por eso el efecto es tan negativo. Sin embargo si el enfoque del desarrollo de software y el contexto en que se realiza el mismo tiene en cuenta que las condiciones pueden cambiar, el cambio se puede convertir en ventaja. Por ejemplo, la adecuación de un proceso a un cambio normativo y en consecuencia del sistema de información que lo soporta o que lo va a soportar, si se realiza antes que los competidores, de una manera efectiva, proporciona una ventaja respecto a los mismos.

Mary Poppendieck, es la introductora junto a Tom Poppendieck de la aplicación de los conceptos de fabricación Lean en el proceso de desarrollo de software, basada en su experiencia en el campo de sistemas de control de procesos y en la jefatura de Departamentos IT en plantas de manufactura. Su experiencia en el sector y su aportación al desarrollo de software, hace que debamos tener muy en cuenta su siguiente reflexión: “Los cambios tardíos de los requisitos en el ciclo de vida son una ventaja competitiva… ¡si se puede actuar sobre ellos!”.

Taiichi Ohno fue el ingeniero creador de sistema de producción Just in time (JIT) de Toyota. Este sistema tiene como objetivo que los materiales y productos intermedios que se necesitan para el proceso de montaje de un producto lleguen a la línea de producción en el momento adecuado y en la cantidad requerida, de manera que se consiga mediante este método tender hacia un inventario cero de productos sin romper el proceso de producción.

Un experto en procesos como él, con decenas de años de experiencia en Toyota, realiza la siguiente reflexión: “Los pedidos deben cambiar rápidamente en respuesta al cambio de circunstancias. Si nos atenemos a la idea de que una vez establecido, un plan no debe ser cambiado, un negocio no puede existir por mucho tiempo.”

Es decir, las organizaciones deben adaptarse a los cambios de contexto y esa adaptación puede afectar incluso a los propios cimientos de la misma. Este proceso de cambio siempre está latente, a veces, los mismos pueden ser pequeños, en ocasiones, dar la sensación de estabilidad y otras sí que resultan sensibles.

Los sistemas de información son herramientas de apoyo a los procesos de una organización y son utilizados por usuarios de la misma, por tanto, si la organización tiene que adaptarse a cambios, esto puede producirse en cualquier momento y esto afectará a las aplicaciones independientemente de la fase del ciclo de vida en la que se encuentren.

Por tanto, el proceso de desarrollo de software, la mantenibilidad de los sistemas, debe ser tal que la adaptación al cambio sea posible en unos presupuestos y plazos razonables, dentro del estado actual en el que se encuentre la aplicación.

Si el cambio es inherente al desarrollo de software e inherente a la propia evolución de las organizaciones y de si contexto y entendemos el mismo como algo inevitable, la mejor estrategia es estar preparado para poder responder cuando esos cambios se produzcan en lugar de responder cuando ya se hayan producido.

Puede parecer lo mismo, pero no lo es, al menos en el desarrollo de software, donde todos sabemos que los cambios sobre lo planificado son más costosos de llevar a cabo cuanto más tarde se traten, por ese motivo, las modificaciones en el sistema deben producirse lo más cerca posible del momento en que cambian las condiciones establecidas.

Martin Fowler y Jim Highsmith tienen en cuenta esta circunstancia cuando afirman que: “Facilitar el cambio es más efectivo que intentar prevenirlo. Aprende a confiar en nuestra habilidad para responder a eventos impredecibles es más importante que confiar en nuestra habilidad de planificar ante el desastre. Los procesos ágiles aprovechan el cambio para proporcionar al cliente una ventaja competitiva”.

Es importante tener en cuenta lo que afirman Fowler y Highsmith: la rápida adaptación al cambio y la aplicación de metodologías ágiles como instrumento, proporcionan una ventaja competitiva.

El observador modifica lo observado. El observador modifica las condiciones en que se desarrolla lo observado. Ese principio cuántico llamado principio de indeterminación o incertidumbre de Heisenberg es posible llevarlo al mundo del desarrollo de software, al menos es lo que piensan Daniel McCracken y Michael Anthony Jackson cuando realizan la siguiente analogía (traducción libre): “Cualquier actividad en el desarrollo de un sistema inevitablemente cambia las condiciones del contexto/entorno en el que el sistema va a funcionar. Las metodologías de desarrollo de sistemas deben tener en cuenta que el usuario, sus necesidades y contexto, cambian durante el proceso”.

Esta reflexión, también es del año 1982 y aporta algo esencial, en el sentido de que no solo el contexto en que se desarrolla el sistema puede variar por circunstancias externas sino que el propio de desarrollo de software cambia ese contexto. Y es absolutamente razonable, ya que introduce en el problema una variable más que es el propio sistema y plantea un elemento nuevo en el entorno que modifica las condiciones en que el área usuaria puede interpretar sus procesos y la forma y herramientas que utilizan para ejecutarlos.

Sí y no. Sí, porque ya hay muchos desarrolladores y organizaciones que lo tienen en cuenta, dejando el ciclo de vida en cascada en un cajón y aplicando estrategias iterativas e incrementales en los desarrolladores. No, porque hay quienes conociendo el problema se rinden a la rutina de la cascada y al sentimiento de que el desarrollo de software es así y no tiene solución y lo que se hace es atacar a la incertidumbre y los riesgos incrementando el precio del desarrollo, desde el inicio y por supuesto también al final, para realizar ajustes a las expectativas del usuario y no es lo mismo hacerlo ahí que en etapas no tan avanzadas del desarrollo, donde se puede centrar los esfuerzos en problemas concretos.

No digo que no se tenga en cuenta el riesgo y la incertidumbre al valorar, sino que ese no debe ser el único camino ni mucho menos el más importante para combatirlo, ya que la clave está en la metodología y su adecuada ejecución en todos los ámbitos (gestión de las personas, gestión de los procesos y ejecución técnica).

La no adaptación a la naturaleza del desarrollo de software es una de las causas principales de la crisis del software y esto no solo es culpa de los desarrolladores, también lo es de los clientes y de las organizaciones de ambos (los implicados en el proyecto pueden tener muy buena voluntad, pero si sus jefes toman decisiones que no les permiten hacer su trabajo adecuadamente, los resultados del producto final se verán afectados).