cerrar-sesion editar-perfil marker video calendario monitor periodico fax rss twitter facebook google-plus linkedin alarma circulo-derecha abajo derecha izquierda mover-vertical candado usuario email lupa exito mapa email2 telefono etiqueta

400390104. Ya está bien de procesos: Hagamos prácticas

Escrito por Redacción en Secciones
no hay comentarios Haz tu comentario
Imagen de logotipo de facebook Imagen de logotipo de Twitter Imagen de Logotipo de Google+ Imagen de logotipo de Linkedin

Como ya hemos visto en la primera de las partes que componen el total del artículo, hay muchos problemas con la generación actual de procesos de desarrollo de software – se niega la cualidad de ser común, no se completan, procesos con falta de sincronización, necesidad de adquirir conocimientos o, simple y llanamente, procesos estúpidos, para nombrar unos cuantos. No es de sorprender, por tanto, que a los desarrolladores no les gusten los procesos.

Pero la buena noticia es que hay una alternativa – las prácticas, y hay centenares de ellas. Algunas están bien aceptadas, otras son exclusivas para una metodología concreta. Pero todas ellas tienen algo que ofrecer, incluso aunque puedan ser difíciles de mezclar y de hallar correspondencia entre ellas, o de usar juntas. En nuestro método, al que llamamos “EssWork,” esas prácticas se pueden definir de forma separada, y después se pueden componer en una sencilla forma de funcionar en la que se aplican juntas. Ello permite que los equipos seleccionen las prácticas que desean, que son ensambladas a continuación para describir su forma de funcionar a nivel individual.

En esta parte, examinamos lo que hace que una práctica sea buena e identificamos las ventajas de adoptar un enfoque basado en prácticas.

¿Qué es una práctica?

Una “práctica” nos proporciona una forma de enfocar, de forma sistemática y verificándolo, un aspecto concreto del proyecto.

Es importante observar que:

– Una práctica no pretende abordar el problema en su totalidad. Más bien, una práctica ataca un aspecto concreto del problema.
– Una práctica es sistemática en el sentido de que alguien lo puede articular. No es magia negra. Una práctica tiene un comienzo claro y un final, y nos proporciona una historia completa en trozos utilizables.
– Una práctica incluye su propia verificación, a la que da un objetivo claro, y una forma de medir su éxito en el logro de ese objetivo. Sin verificación, la práctica no está completa.
Por estas cualidades, las prácticas pueden desarrollarse, aprenderse y adoptarse de forma separada, y pueden usarse en conjunción con otras prácticas para crear formas de funcionar coherentes y fáciles de entender.

Para resumir, una práctica es una forma demostrada de abordar o dar respuesta a un problema. Es algo que se ha hecho antes, puede transmitirse con éxito a otras personas y puede aplicarse repetidamente para producir resultados consistentes.

¿De dónde proceden las prácticas?

La idea de las prácticas no es nueva. Las prácticas han existido siempre en el desarrollo del software y, según parece, todas las empresas de desarrollo de software del mundo fomentan su propio conjunto de “buenas prácticas”. Sin embargo, nadie se ha tomado el tiempo de definir exactamente qué son las prácticas o cómo describirlas de forma sensata y reutilizable. La realidad es que hay cientos de prácticas disponibles para que elijamos entre ellas, si es que podemos separar unas de otras, entender las ventajas que ofrecen y saber cuándo utilizarlas.

En la comunidad del desarrollo del software, las prácticas — al igual que los procesos— normalmente proceden de uno de los tres campos destacados:

– Ingeniería del Software, que incluye el Proceso Unificado, Booch, OMT, Diseño Dirigido a la Responsabilidad, Shlaer/Mellor, Diseño Centrado en el Usuario, Abierto, y Desarrollo Dirigido a las Prestaciones, entre otros.
– Garantía del Proceso, que incluye CMMI, SPICE, Six Sigma, y TSP/PSP.
– Ágil, que incluye XP, Scrum, Crystal Clear, Desarrollo Adaptativo del Software, y Patrones para la Organización de Desarrollo Ágil del Software.
Muchos de ellos enredan juntas una serie de prácticas que a veces comparten. Por ejemplo, Scrum es una práctica que se presenta ya de forma separada y reutilizable – como una práctica de gestión para la planificación y ejecución de proyectos iterativos. Es totalmente independiente de la ingeniería y de otras prácticas que pueda usar un equipo. Esta separación y la posibilidad de mezclar y hacer coincidir Scrum con otras prácticas es una de las razones por las que ha demostrado ser tan popular y estar tan ampliamente adoptado.

Comparemos esto con lo iterativo que se ha presentado siempre la gestión de proyectos en el Proceso Racional Unificado – como una parte estrechamente emparejada e inseparable de un proceso mucho más grande que no parece ser utilizable sin el ciclo de vida del Proceso Unificado, ni usar casos, componentes o un gran enfoque en la arquitectura. Esto ha hecho que siempre les haya sido casi imposible a los clientes adoptar las prácticas que desean sin tener que adoptar también todas las otras prácticas.

Así, hay muchos sitios en los que ya podemos encontrar prácticas: Hay muchas prácticas bien formadas que ya se encuentran disponibles, hay muchas prácticas insertadas en procesos ya existentes, y hay muchas prácticas tácticas que profesionales con experiencia comunican mediante la instrucción y el ejemplo.

Un buen sitio para buscar prácticas bien formadas es en la manera en que se presenta la formación y se distribuyen los procesos. La manera normal de formar a la gente es mediante una práctica cada vez. Así es también como se acometen las distribuciones de procesos de mayor éxito.

Las prácticas surgen a partir de gente que está realizando su trabajo y que comparten sus experiencias. Lo que necesitamos es una manera mejor de capturar y compartir esas prácticas, una que evite la “religión” y la auto-promoción, y que permita la independencia de cada una de las prácticas.

De manera que, en el futuro, en vez de tener expertos que contribuyan a otro proceso más, contribuirán a prácticas distintas y separadas. Cada práctica estará completa y contribuirá a que los equipos puedan avanzar en sus proyectos.

¿Qué tipo de prácticas hay?

Como cabe esperar, hay prácticas para abordar todas las distintas áreas del desarrollo del software y del funcionamiento de los equipos y que incluyen:

– Prácticas de ingeniería del software. Prácticas para desarrollar componentes, diseñar interfaces de usuario, establecer una arquitectura, planificar y evaluar las iteraciones o calcular los esfuerzos.
– Prácticas de ingeniería social. Prácticas de trabajo en equipo, colaboración o comunicación.
– Prácticas organizativas. Prácticas en hitos del proyecto, análisis de pasarelas, o controles financieros.
Con el tiempo, todas estas prácticas estarán disponibles, además de muchas más. La figura 1 ilustra una selección de las prácticas que cabe esperar que estén disponibles en el futuro. Algunas de las prácticas serán complementarias, como por ejemplo Scrum, programación en pareja y casos de uso. Otras competirán entre sí, tales como los casos de uso y las historias de los usuarios.

Figura 1: Distintos tipos de prácticas.

La figura 1 muestra también que hay prácticas técnicas y transversales. Las prácticas técnicas tratan directamente sobre la producción del software y los otros artefactos (como los requisitos) necesarios para dar soporte al desarrollo del software.

Las prácticas transversales son sutilmente distintas. Más que centrarse en el método que usamos para producir el software (como las iteraciones, casos de uso y los componentes), estas prácticas abordan el lado más suave del desarrollo del software (como la programación en pareja, el trabajo en equipo y la comunicación). No describen directamente cómo producir software, sino que afectan fundamentalmente a cómo trabaja el equipo y cómo se aplican las otras prácticas.

Muchas prácticas populares de desarrollo del software, especialmente el tipo de prácticas de ingeniería social que promueve la comunidad ágil, son transversales de esa forma. La capacidad de capturar y componer tanto las prácticas técnicas como las transversales nos permite abordar todos los aspectos del desarrollo del software de forma sencilla, escalable y extensible.

La figura 1 muestra también una selección de prácticas equivalentes y de prácticas de extensión. Las prácticas equivalentes son unas prácticas maduras que se pueden aplicar de forma separada y ofrecen un valor directo a los equipos y a sus clientes.

Las prácticas de extensión se compilan sobre las prácticas equivalentes para hacerlas más escalables al abordar riesgos específicos o al añadir técnicas complementarias. Los equipos empezarán seleccionando las prácticas equivalentes que necesitan para conducir su trabajo y luego añadirán cualquier otra práctica equivalente o de extensión según las vayan necesitando para escalar su forma de funcionar.

El mejor tipo de prácticas equivalentes son las que se centran en los elementos esenciales de la práctica y dejan que los casos patológicos y las especializaciones sean gestionados por otras prácticas de extensión. Eso mantiene ligeras y ágiles las prácticas equivalentes, y evita que los equipos adopten inadvertidamente prácticas que son más complejas de lo que tienen que ser.

Lo estupendo es que sólo tenemos que usar las prácticas que queremos. Si consideramos que las prácticas de gestión son una pérdida de tiempo, no las incluimos. Al sólo extraer las prácticas que necesitamos, podemos ensamblar la forma correcta de funcionar para nuestro equipo, proyecto y organización.

¿Qué hace que una práctica sea buena?

Una práctica bien formada aborda aspectos específicos del desarrollo del software o del trabajo en equipo. Una práctica ofrece orientaciones para caracterizar el problema, la estrategia a seguir para solucionar el problema e instrucciones para verificar que el problema se ha resuelto realmente. Además, describe qué evidencia de apoyo – si se requiere alguna- es necesaria y cómo hacer que la estrategia funcione en la vida real.

En palabras sencillas, las prácticas describen lo que producir, cómo producirlo y las competencias necesarias para realizar la práctica. Las prácticas ofrecen además patrones para diseñar a medida y afinar su uso. El empleo de patrones permite que las prácticas describan cosas como los patrones adecuados de trabajo (por ejemplo, equipos colocados, equipos distribuidos o equipos virtuales) y patrones de propiedad (propiedad común o propiedad por componente). La aplicación de los patrones le permite fácilmente a un equipo adaptar las prácticas a sus necesidades específicas.

Para que sea una práctica bien formada – una que se pueda aplicar con seguridad y de forma consistente- ésta ha de verificarse a sí misma. Así, si una práctica describe cómo escribir código, ha de describir también cómo comprobarlo. O si una práctica describe cómo capturar los requisitos, ha de describir también como verificar que el sistema producido cumple con esos requisitos. Si las prácticas no hacen esto, en ese caso su capacidad de ser aplicadas con éxito se ve comprometida. Esta necesidad de que las prácticas incluyan su propia verificación puede verse en el conjunto inicial de prácticas que hemos desarrollado para demostrar y probar nuestro método.

Si examinamos el conjunto de práctica de la figura 2, veremos que no hay práctica de comprobación. Ello es debido a que la comprobación es una parte integral de todas las prácticas técnicas. Por ejemplo, la práctica de componentes adopta un enfoque de “comprobar primero”, desarrollando comprobaciones de unidades antes de desarrollar los componentes.

Figura 2: Prácticas en el Proceso Esencial Unificado

En conjunto, estas ocho prácticas forman el Proceso Esencial Unificado (EssUP, por sus siglas en inglés), versión ligera del Proceso Unificado. EssUP incluye cinco prácticas técnicas que se encuentran en todos los Procesos Unificados, y algunas nuevas prácticas transversales que se basan en otras áreas de experiencia como CMMI y métodos ágiles. (Para más información sobre EssUP, véase nuestro artículo «The Essential Unified Process,» Versión americana de DDJ, Septiembre 2006; www.ddj.com/dept/architect/191601687.)

Estas prácticas se pueden aplicar de forma separada o en combinación unas con otras. Hay muchos equipos que están ya utilizando estas prácticas. Todos usan distintas combinaciones y mezclan estas prácticas con sus propias prácticas en uso. La figura 3 muestra cómo se pueden mezclar las prácticas EssUP y hacerlas coincidir con otras prácticas para dar soporte a distintos equipos y objetivos.

Figura 3: Mezcla/coincidencia de prácticas EssUP.

Este conjunto inicial de prácticas EssUP está diseñado para centrarse en lo esencial de cada práctica – garantizando así que sean ligeras y compatibles con los valores y pensamiento ágiles. Si se necesita más rigor, ceremonia o documentación se pueden añadir prácticas de extensión adicionales. Estas prácticas de extensión se compilan sobre los fundamentos para abordar problemas específicos y áreas de riesgo.

¿Y qué pasa con los “procesos”?

Todos los procesos pueden ser típicamente considerados como una colección de prácticas estrechamente emparejadas y enredadas de forma típica. Una vez se separan las prácticas existentes, los metodólogos pueden concentrarse en capturar las mejores prácticas en formato extensible y reutilizable sin repetir o sustituir las prácticas existentes.

Al tratar los procesos como colecciones de prácticas, se cambia esencialmente el papel de los procesos. Se convierten sencillamente en una forma abreviada de referirse a un conjunto conocido de prácticas que se dan soporte mutuamente, y su adopción actúa como un punto de inicio útil o un objetivo para los proyectos.

En lugar de aprender o adoptar un proceso entero, los profesionales conocen prácticas individuales y adoptan estas prácticas de forma incremental para mejorar su forma de trabajar. En primer lugar, seleccionan las prácticas más apropiadas para dar respuesta a sus necesidades y ayudarlos a enfrentarse a los retos de la situación en la que se encuentran. Después adoptan estas prácticas en la combinación y a la velocidad que más les conviene. Lo que es más importante, añaden nuevas prácticas a la forma que tienen de trabajar en ese momento, sin cambiarlo todo y sin deshacerse de las prácticas que ya conocen.

Si así lo desean, los equipos pueden empezar desde cero con una nueva forma de trabajar, pero la experiencia demuestra que es más efectivo transformar la forma de trabajar con una práctica cada vez. Cuando se trata de mejorar un proceso, el método del big-bang no funciona. Querer cambiar todo, a la vez, es una estrategia de alto riego. Incluso si queremos cambiarnos a una forma totalmente nueva de trabajar, es más fácil y seguro hacerlo con una o dos prácticas cada vez.

Eso minimiza la disrupción causada por el cambio de prácticas en funcionamiento y proporciona un enfoque a la preparación necesaria para insertar las nuevas prácticas en el equipo. Nos permite además abordar directamente las áreas problemáticas a las que nos enfrentamos sin tener que cambiar prácticas que están ya funcionando bien.

En el futuro, combinaremos prácticas de muchas fuentes para crear la forma de trabajo que necesitamos. En lugar de hablar de los procesos que seguimos, hablaremos de las prácticas que utilizamos. Si alguien nos habla de una nueva práctica, podremos probarla sin que afecte a las prácticas que ya estamos utilizando. Podremos incluso crear y desarrollar nuestras propias prácticas, mezclarlas después con prácticas estándar y crear realmente nuevas e innovadoras formas de trabajar. Y no estaremos atados a ningún campo o ideología de procesos; podremos mezclar y hacer coincidir prácticas de cualquier fuente para mejorar y afinar continuamente nuestra forma de trabajar.

Próximo mes

En la última entrega, describimos las innovaciones necesarias para hacer que realmente funcione un método basado en las prácticas, y cómo EssWork puede contribuir a que los equipos lleven a la práctica lo invertido en aprendizaje, desarrollo y documentación de buenas prácticas.

Etiquetas

Noticias relacionadas

Comentarios

No hay comentarios.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Debes haber iniciado sesión para comentar una noticia.