Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Mejora de procesos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Mejora de procesos. Mostrar todas las entradas

martes, abril 26, 2016

Del triángulo de hierro al triángulo ágil (modificado)


Las empresas en período de transformación organizacional se enfrentan a la dicotomía de seguir paradas sobre el triángulo de hierro en lo que se refiere a planificación y gestión de proyectos de software o moverse a una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han transitado durante las últimas décadas.

De lo más valioso que hemos aprendido en el desarrollo de software es que muchas de las prácticas y técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo de otras áreas de la ingeniería y de otras ciencias aplicadas.

Algunas de esas prácticas influyeron directamente en la forma de realizar estimaciones y de planificar proyectos de software. Específicamente, hemos aprendido que no podemos estimar ni planificar proyectos de software como lo hacen en proyectos de la industria de la construcción… ¡a no ser que vayamos  a usar piezas de Lego® para construir ciudades!


Afortunadamente ya sabemos con certeza que la ingeniería de software tiene su propia personalidad. Se trata de un sello que la hace única y que hace que sus practicantes se distingan del resto de profesionales de la ingeniería y de otros cuerpos de conocimiento. Por ejemplo, en su libro Agile Project Management, Jim Highsmith[1] sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos los siguientes vértices:
  • Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
  • Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
  • Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.
Como dice el mismo Highsmith [2], las restricciones siguen siendo parámetros importantes de un proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la Calidad establecen la meta del proyecto y las restricciones mencionadas se ajustan a medida que el proyecto incrementa el valor para el usuario. En particular, El tiempo podría seguir siendo una restricción fija pero entonces el alcance debería ajustarse para entregar el valor más alto posible dadas las restricciones impuestas.


Como nos gusta lo visual, esta otra versión del triángulo ágil de Highsmith nos llega más:


Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!

Ahora bien, la mejora continua junto al valor y a la calidad forma otro vértice del triángulo, el del resultado. A los agilistas no nos interesa simplemente crear un producto, por más disruptivo o benéfico que este sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al próximo nivel de optimización, satisfacción y felicidad.

Pero lo más importante en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan que tenga como propósito el diseño y la construcción de productos (de software), son las personas: la comunicación cara a cara entre ellas, la motivación de todos los individuos que intervienen en el proyecto, la atención continua a la excelencia técnica, la autogestión del equipo y la confianza que la organización deposite en ellas se constituyen en las bases del éxito de cualquier iniciativa que requiera generar nuevos productos o servicios.

Las cosas así, podríamos entonces encontrarnos con esta nueva versión del triángulo ágil:



Referencias:

[1] Highsmith es uno de los 17 firmantes del Manifiesto Ágil

miércoles, octubre 07, 2015

Principios para Frameworks de Procesos de Software Efectivos

Septiembre 28 de 2015, por Scott Ambler



El framework de decisión de procesos de Disciplined Agile se guía por los siguientes principios:
  1. Elegir es bueno y tomar decisiones informadas es mejor. Cada equipo es una colección única de individuos que enfrentan situaciones únicas dentro del contexto de una organización particular. Un único proceso no sirve para todo. Para facilitar la elección, el framework DA soporta varios ciclos de vida de entrega y es un proceso dirigido por metas. Y más importante, el framework DA describe las compensaciones involucradas con una gran variedad de prácticas ágiles y no ágiles que permiten a las personas a tomar decisiones inteligentes relacionadas con prácticas para adoptar la situación actual que enfrentan.
  2. Optimizar el todo. El framework DA cubre todo el ciclo de TI, mostrando como encajan todos sus elementos. Si los equipos no entienden el entorno de los procesos, corren el riesgo de optimizar localmente sus propios procesos causando detrimento en el todo. Por ejemplo, el equipo de manejo de datos puede tener su propio proceso basado en estrategias DAMA (Gestión de Datos, por sus siglas en inglés) tradicionales, mientras que el equipo de entrega puede tener el proceso basado en los principios del Manifiesto Ágil y el equipo de operaciones puede tener su proceso basado en ITIL. Las cosas así, el proceso general se vuelve inefectivo porque estas tres estrategias individuales se contradicen y se degradan unas con otras cuando se combinan.
  3. Cada equipo es dueño de su proceso. Los equipos y las personas miembros de esos equipos deben ser libres de mejorar la forma en que trabajan basados en su aprendizaje en el tiempo. En el parloteo ágil decimos que estos equipos “son dueños de sus procesos”.
  4. Mejorar continuamente. Personas, equipos y organizaciones deben esforzarse por aprender y mejorar continuamente la forma en que trabajan. El framework DA incluye la meta de proceso Mejorar el Proceso y el Entorno del Equipo, la cual describe opciones para hacer exactamente lo que esto implica. También tiene un apartado explícito para el Mejoramiento Continuo de procesos que describe las estrategias para compartir mejoras entre equipos, incrementando de esta forma la velocidad de los esfuerzos de mejora de procesos de su organización.
  5. Promover y apoyar el cambio en el proceso. Los departamentos de TI son sistemas adaptativos complejos. Una implicación de esto es que cualquier mejora que un equipo haga puede cambiar la forma en que trabajan con otros equipos, motivando mejoras de proceso dentro de esos equipos. Estos cambios a su vez pueden motivar mejoras dentro de otros equipos y así sucesivamente. Los equipos ágiles disciplinados son conscientes de su estatus corporativo y entienden que necesitan trabajar con otros equipos para ayudarlos a entender y a adoptar nuevas innovaciones y a prepararse para que otros los ayuden a hacer lo mismo.
  6. Resultados repetibles son mucho más importantes que los procesos repetibles. Los equipos efectivos se enfocan en producir resultados repetibles, tales como entregar software de alta calidad que cubra las necesidades de los interesados de manera efectiva en tiempo y en costo. Debido a que cada equipo se encuentra así mismo en una situación única, para ser más eficientes necesitan seguir un único proceso personalizado que refleje esa situación. Ese “único proceso” puede constar de un ciclo de vida relativamente estándar y de prácticas comunes tales como la ideación de la arquitectura, pruebas de regresión de la base de datos y muchas otras (asumiendo que estas prácticas también se personalicen para reflejar esa la situación). A cada equipo en su organización se le debe permitir seguir su versión del proceso, idealmente compartiendo componentes similares del proceso, definidos por un framework común de proceso, para lograr los resultados requeridos.
  7. El empirismo es mucho más importante que la teoría. Observar qué tan bien funciona una técnica en la práctica y, más importante aun, observar el contexto de las situaciones en las que (no) funciona, es de mayor valor para los practicantes que las teorías o la prognosis sobre lo que debería funcionar. La teoría tiene su lugar, pero es una prima pobre del empirismo. El framework DA se desarrolló originalmente basado en observaciones de docenas de organizaciones en todo el mundo y ha evolucionado desde entonces basado en el aprendizaje de muchas otras. Además está siendo respaldado por investigaciones en curso de nuestra industria.


Los departamentos de TI son sistemas adaptativos complejos únicos. Cualquier persona que trabaje en un ambiente así necesita un framework de proceso que sea lo suficientemente flexible como para que aborde el amplio rango de situaciones que enfrentan sus equipos. El framework de decisión de procesos DA es liviano a la vez que lo suficientemente flexible para soportar el escalamiento tanto a nivel táctico como estratégico.

-----
Nota del traductor, o sea yo:

Este artículo se publicó originalmente en inglés por Scott Ambler, bajo el título de “Principles for Effective Software Process Frameworks” que pueden encontrar en: http://www.disciplinedagiledelivery.com/software-process-framework-principles/

Publicado con permiso del autor.