Buscar en Gazafatonario IT

domingo, junio 22, 2014

Ecos del SEPG Latino América 2014

Manizales, en los alrededores de la sede de la SEPG LA
Para quienes no están familiarizados, SEPG es la serie de conferencias premier en gestión de procesos de software y sistemas. Cada conferencia brinda desarrollo profesional en mejoramiento de procesos a través de sesiones técnicas enfocadas en tecnologías como CMMI, People CMM, PSP, TSP, Agile, ISO y Six Sigma; también aborda los enfoques para implementar alta madurez, técnicas efectivas de adquisición, desarrollo y entrega de servicios, entre otros temas de relevancia para la industria.
En Latinoamérica este año la edición de la conferencia, SEPG LA, se llevó a cabo en Manizales, en un ambiente natural, rodeado de montañas y termales de aguas que provienen directamente de las entrañas de la tierra, nos reunimos 2 o 3 centenares de personas que llegamos de latitudes tan diversas como España, USA, Chile, México y Colombia. Como era de esperarse, el programa de la Conferencia se combinó con un ambiente de networking entre los asistentes, condición sine qua non el evento no hubiese colmado las expectativas de quienes acudimos a la cita.
El Programa
Cuando me enteré que el llamado de artículos incluía entre sus temas principales la combinación de disciplina con métodos ágiles pensé que era una forma peyorativa de nombrar los métodos y prácticas con enfoque ágil. Eso me motivó a participar. Involucrado como he estado en los últimos años con la agilidad y lo que yo llamo la Cultura Ágil, liderando el proceso de transformación de una compañía con un alto nivel de madurez, he aprendido que los dos ecosistemas, el de procesos prescriptivos tipo CMMI, y el de procesos generativos tipo Scrum, se pueden “aprovechar” uno del otro. Con ello en mente, preparé mi ponencia “Ágil es algo que eres, CMMI es algo que usas”, pero eso es algo a lo que llegaré más adelante.
  • El resto del programa incluía temas como:
  • Competitividad y supervivencia en un mercado globalizado (Visión estratégica del sector TI)
  • Mejora de procesos en entornos diversos (pequeños, pymes y grandes empresas)
  • Alcanzando y trabajando en entornos de alta madurez
  • Mejorando la capacidad de la prestación de servicios TI
  • Industrializando la producción de Software
  • Retos en las arquitecturas y nuevos modelos de negocio TI (Arquitectura Empresarial, Cloud, Big Data, Movilidad, Seguridad, entre otros), y
  • Marca y normatividad sectorial de Software
El plato estaba servido, mi artículo había sido aceptado en la Conferencia, así es que viajamos a Manizales en compañía de algunos colegas y amigos de la industria. Al ver la fascinación que representaban las cordilleras colombianas, mientras repasaba lo que había escrito para la ponencia sobre lo que significa ser ágil, recordé a uno grande de la industria, Steve Jobs, diciendo que ese precisamente había sido uno de sus mantras – foco y simplicidad.
Tenía razón Jobs, lo simple puede ser más difícil que lo complejo. Tienes que trabajar duro para lograr que tus pensamientos sean limpios y poder alcanzar así la simplicidad. Pero vale la pena, porque una vez allí, puedes mover montañas. En ágil, la simplicidad el arte de maximizar el trabajo no realizado, es esencial. O así lo invoca el Manifiesto Ágil.
El Evento
El Ministro TIC de Colombia, Dr. Diego Molano Vega
El inicio del evento supuso un acto protocolario algo extenso para mi gusto – qué le vamos a hacer, ¡tenía que decirlo! –, que incluyó al Ministro de las TIC en Colombia, Dr. Diego Molano, y al alcalde de Manizales, con presentaciones bastante enérgicas, lo mismo que a la Dra. Elena Schaeidt Ayarza, Directora de Desarrollo Corporativo e Internacional de TECNALIA y al Dr. Albeiro Cuesta Mesa, Director de Políticas y Desarrollo TI hablando sobre cómo se está transformando la industria TI en Colombia.
A continuación, el Dr. Kirk Botula, CEO del CMMI Institute, rama recién desprendida del SEI, nos habló de cómo hacer para que la industria de TI latinoamericana trabaje mejor. En su presentación, el Dr. Botula hablaba de como la misión del CMMI Institute era hacer que el mundo trabaje mejor, hacer que el mundo del trabajo, funcione mejor. La razón por la que la gente adopta CMMI, decía Botula, o de preocuparse por esos marcos de trabajo o las evaluaciones CMMI o el entrenamiento en esas áreas, es debido a los buenos resultados que todo eso lleva a las organizaciones e instituciones que lo usan.
Pero el Dr. Botula también le abrió las puertas a la filosofía ágil. Afirmó que con técnicas ágiles ganamos el 5% más de velocidad que con CMMI y 2% más que con TSP, aunque dijo también que los costos de desarrollo son los mismos. ¿Qué si ágil es la dirección correcta? No, según Botula todavía no, pero igual pensé que el haberlo mencionado ya era un hito.
Al día siguiente, la contraparte de Botula, el Dr. Paul Nielsen, CEO del SEI, habló de la calidad del software y de su impacto en la ciberseguridad. Mostró datos nada nuevos para quienes estamos involucrados en el tema: que el 70% de los defectos del software se introducen en las primeras etapas del desarrollo y que solo se encuentran el 3,5% de los errores en esas mismas etapas (requisitos, diseño, arquitectura y diseño de componentes). El mensaje de Nielsen es que sigamos adoptando un enfoque centrado en la arquitectura, nada que no hayamos estado haciendo hará ya una década y media con la guía de procesos como el Unified Process.
Además hubo una mesa redonda moderada por la Viceministra de TI de Colombia, la señora María Isabel Mejía, con un panel compuesto por los directores de los clusters de empresas de TI en Colombia, como Lina Taborda, Directora de Intersoftware, y María Victoria Gara, Directora de CaribeTIC, entre otras personas. El panel versó sobre la oferta y la demanda de las TIC en Colombia en el que se dijo que necesitamos más talento calificado, más programas específicos de desarrollo de las TIC para las regiones, etcétera.
La Viceministra de TI, María Isabel Mejía
A propósito de la Viceministra, tuve la oportunidad de almorzar con ella y con Lina Taborda de Intersoftware (por invitación de esta última). El objetivo inicial era presentarle las VII Jornadas Latinoamericanas de Metodologías Ágiles que serán en octubre en la ciudad de Medellín y de cuyo equipo organizador hago parte, pero el almuerzo se extendió gratamente y tuvimos la oportunidad de hablar largamente de métodos y prácticas ágiles y de la presentación que yo haría un par de horas más tarde sobre la cultura ágil, al cierre del evento.
Las Conferencias
El resto de ponencias transcurrieron en un ambiente ponderado. Algunas de buena calidad, otras no tanto o, al menos, esas fueron las notan predominantes durante los 2 días del evento. La lista de conferencias la encuentran en:
http://www.sepgla.com.co/programa/
Y finalmente, al cierre, mi presentación, “Ágil es algo que eres, CMMI es algo que usas”. Pero antes de ir a ese punto específico, quisiera hacer mención de una de las conferencias, no porque las demás no lo merezcan, sino porque no hay espacio para mucho más. Me llamó la atención el tema que presentó Luz Adriana Sepúlveda sobre los significados acerca del proceso de implementación de un modelo de mejoramiento de procesos.
Luz Adriana nos habló de los resultados obtenidos durante una investigación que condujo. Algunos de sus planteamientos vienen de Deming y de Crosby, entre otros. Dejó asomar lemas como el de Tomas Gilb que señalan que el personal que no está motivado no avanza, ofrece resistencia y niega el cambio. Algunos datos interesantes como que más de la mitad de 100 esfuerzos de transformación corporativa no sobrevivieron el arranque inicial, o así se desprende de un estudio de John Kotter de Harvard. Sepúlveda nos mostró algunas de las causas de todo esto:
  • Falta de compromiso de la Alta Dirección
  • Falta de continuidad por no contar con estructura de soporte
  • No tomar en cuenta las limitantes que pueden afectar el proceso.
  • Cambio en los sistemas sin cambio en el operador (no existe cambio en la manera de pensar)
Sobre su estudio, Luz Adriana enfatiza en los factores motivantes de rechazo a un Sistema de Gestión de Calidad:
  • Miedo a lo desconocido
  • Resistencia a experimentar
  • Aumento /Disminución de las responsabilidades laborales
  • Falta de información – Desinformación
  • Amenazas al pago y otros beneficios
  • Factores históricos
  • Amenazas al estatus
  • Miedo al fracaso
  • Temor a no poder aprender las nuevas destrezas requeridas
Y señala algunos elementos que contrarrestan esas aprehensiones:
  • Sensibilización/Capacitación/Información
  • Participación en el proceso
  • Construcción colectiva del sistema
  • Experiencia adquirida
  • Acompañamiento por parte de los líderes
  • Planeación del proceso
  • Conceder tiempo al personal para participar activamente en el sistema.
Los dejo con los datos de Luz Adriana por si quieren contactarla. 
Ágil es algo que eres, CMMI es algo que usas
Algunos momentos de mi conferencia. Foto de María Clara López.
En este SEPG LA Se habló mucho de calidad, pero no se habló de las personas. Y mucho menos de sus interacciones. Pensé entonces que el enfoque de mi discurso era precisamente el que quería. Mi asunto principal era que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deberían trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos como CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

A esta altura de mi coloquio, la suerte estaba echada. Decir eso en una Conferencia dedicada a adorar a los procesos y a modelos tipo CMMI podría tomarse como sacrilegio. Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada de lo que no haya hablado en algunos de mis artículos citados más abajo en las referencias.

Pero contrario a mi desazón, la reacción de mis oyentes fue bastante positiva. Era el final del evento, todos estábamos cansados, pero muchos quisieron ir más allá y tuve la oportunidad de compartir experiencias luego de mi charla con muchos de los presentes. La misión, la mía, estaba cumplida: sembrar una semilla, una llama que motive a los colegas a mirar en otra dirección. Por supuesto que dije que ágil no era la solución, pero sí una muy buena alternativa, una que nos está permitiendo volver a amar la profesión, volver a querer que sea lunes en el trabajo, para seguir innovando con cada interacción.

Referencias

Las diapositivas de la conferencia la pueden descargar de:


lunes, junio 02, 2014

Libro: Asuntos de la Ingeniería del Software- volumen II

Portada del libro
Portada del libro
Este no es el primer libro sobre temas de la Ingeniería de Software y está lejos de ser el último; acaso sea el primero en español escrito sobre las bases de nuestra propia práctica de campo, en nuestra propia economía, con nuestra propia idiosincrasia, aunque con el suficiente equipaje teórico proveniente de la academia y de los expertos en los temas citados.
Escribí el libro originalmente como una serie de artículos en mi Gazafatonario IT y cada artículo siempre tuvo su fuente precisamente en tres aspectos primordiales: la industria del software (y por Industria quiero decir Intergrupo), la academia (léase la Universidad) y los especialistas en distintas áreas de la ingeniería de software.
El libro cubre algunos de los temas fundamentales que sirven de base al trabajo diario de los profesionales del software y que son de vital importancia para los desarrolladores actuales: el lenguaje de modelado unificado o UML, los procesos de software, la orientación a objetos y la ingeniería de requisitos con casos de uso, principalmente.
Los conceptos de ingeniería provienen necesariamente de la teoría formal de los lenguajes de modelado de sistemas, las técnicas orientadas a objetos de modelado de software, los métodos de construcción de software y la identificación, especificación y administración de requisitos de software con casos de uso, entre algunos otros. Desarrollé esos conceptos a través de cada capítulo en un estilo riguroso pero informal, más bien práctico, siempre pensando en poner de manifiesto lo que me ha funcionado a mí y a mis colegas, principalmente de Intergrupo, pero también de otras compañías del medio.
Parte 1 – Algunos Aspectos Esenciales de la Ingeniería de Software
El libro está dividido en dos secciones mayores. La primera parte del libro la dedico a explicar algunos de los asuntos que acusan recibo en la comunidad de ingenieros de software: UML, la notación estándar para modelar sistemas de software y otros sistemas que no son software; En lo que se constituye como los prolegómenos del libro, de manera sucinta describo la gran mayoría de los diagramas del lenguaje, con ejemplos breves pero suficientemente explicativos y desmitifico algunas de las creencias sobre la herramienta.
En el capítulo 2, hago una presentación general de los procesos de software y de cómo estos son usados por los practicantes de la industria, es decir, nosotros. Aquí empiezo a develar las prácticas más recurrentes para adoptar y adaptar procesos de software en una organización, tal y como lo hicimos en Intergrupo en una serie de incrementos que llevaron a convertirnos en una compañía CMMI nivel 5.
En los capítulos 3, 4 y 5 del libro, hago una vasta exposición del Proceso Unificado de Software, desde su marco general en el capítulo 3, hasta los detalles de la fase de Inicio o Concepción en los capítulos 4 y 5. En el primero de los apartados presento los conceptos inherentes al proceso y sus características: las fases y las disciplinas, las iteraciones, los roles y responsabilidades, las actividades y los artefactos. En los dos capítulos restantes, ya con miras a la segunda parte del libro, hablo profusamente de la etapa de inicio del proceso, sus principales hitos y el resultado esperado. Es aquí donde comienzo a hablar de la disciplina de ingeniería de requisitos y de casos de uso, asuntos que ocupan toda la segunda sección del libro.
Luego, en el capítulo 6, concluyo este primer segmento del libro con un tema que verdaderamente me apasiona, la orientación a objetos. Tardé muchos años en encontrar el enfoque justo para esta pieza, teórico-práctico, pero actualizado a las necesidades incesantes de los desarrolladores profesionales de este siglo 21. El capítulo contiene una serie extensa de conceptos aplicables al análisis, diseño y desarrollo de sistemas de software, incluso me atrevo a hacer una analogía en lo que he dado en llamar la Biología Informática, para que todos entendamos mejor y de una vez por todas y para siempre lo que es una clase (objetualmente hablando) y su enorme utilidad durante el ciclo de vida de construcción de software. Sobre objetos, siempre recuerdo lo que decía Edward Yourdon sobre ello: “las metodologías de la ingeniería de software orientada a objetos son la cosa más grande desde el pan tajado. En términos relacionados con computación, las técnicas orientadas a objetos son el desarrollo más importante desde la invención de las técnicas estructuradas durante las décadas de 1970 y 1980.”[1] Hoy lo siguen siendo.
Parte 2 – Ingeniería de Requisitos con Casos de Uso: Volumen 1
La segunda parte está dedicada completamente al asunto de los casos de uso como mecanismo de primera categoría para identificar, capturar, organizar, documentar y gestionar requisitos de sistemas de software. En el capítulo 7 hago una presentación concisa del tema, defino qué es un caso de uso y además establezco las diferencias sutiles que existen con los escenarios de uso de un sistema; también explico de qué se tratan los así llamados casos de uso esenciales como noción capital en la especificación de requisitos y también los distingo de los casos de uso descompuestos funcionalmente. El capítulo finaliza con el ejemplo de caso de uso más simple de todo, el caso de uso “¡Hola, Mundo!”.
En el capítulo 8 abordo el tema de los casos de uso del negocio y sus actores del negocio relacionados. También hablo de la fuente de los casos de uso, de donde provienen y hacia donde van a lo largo del ciclo de vida del software, para terminar con un ejemplo del cual luego hago un análisis exhaustivo.
En el capítulo 9 hago una descomposición de la estructura de un caso de uso y exhibo cada una de sus partes principales: la descripción breve, las precondiciones y poscondiciones del caso de uso, la secuencia básica y las alternativas y los requisitos especiales. Ya en los capítulos previos había tratado el tema del nombre y el actor del caso de uso.
Más adelante, en el capítulo 10, bajo el manto de un ejemplo representativo, enuncio mi Ley de la Terminación de un Caso de Uso, que me sirve para explicar uno por uno los puntos de una lista de verificación para saber si un caso de uso cuenta con los atributos mínimos requeridos para ser considerado un buen caso de uso. Las listas de verificación deben verse como instrumentos o herramientas de apoyo en el proceso de administración de la calidad de los productos que construimos, nunca como un documento que se debe “diligenciar”. También sirven para disminuir el nivel de subjetividad con que se revisa un producto de software o parte de este, o un artefacto relacionado con el software. Al menos, este es el mensaje que llevo implícito en esta sección del libro.
El capítulo 10 sirve como entrada al tema que abordo en el capítulo 11, este del análisis y diseño de los casos de uso, mejor conocido en el ámbito de los diseñadores de software como realización de casos de uso. Aquí evidencio la necesidad de contar con el conocimiento de conceptos tan importantes como las técnicas orientadas a objeto, que trato al final de la primera parte del libro, y donde hago un uso extenso del lenguaje de modelado unificado que trato en detalle en los prolegómenos del libro (capítulo 1). En este capítulo empiezo con una disertación sobre los problemas de comunicación existentes entre los miembros de un equipo de desarrollo de software y que son inherentes a la naturaleza humana. A continuación, con un ejemplo característico y práctico, hago una exposición detallada de los diagramas de interacción de UML, en general, y de los diagramas de secuencia, en particular, que sirven como mecanismos fundamentales para llevar a cabo estas realizaciones de casos de uso.
En el capítulo 12 cierro uno de los ciclos del libro sobre modelado de casos de uso y presento el no menos espinoso asunto de las relaciones entre actores y casos de uso y entre casos de uso. La generalización entre actores, una práctica poco usada entre los analistas de software, o muchas veces mal usadas, inicia este apartado. Luego continúo con la típica relación de inclusión de casos de uso, donde hablo de factorización de requisitos y de reusabilidad de requisitos; más adelante hago una disertación sobre la relación de extensión y sus diferencias principales con la anterior. Al final también hablo de la generalización entre casos de uso, aunque no la recomiendo mucho. Este capítulo aporta el enfoque sistémico de toda la segunda parte del libro y hace énfasis en cuando debemos usar una u otra relación, o todas ellas.
El capítulo 13 entra en el terreno de las buenas prácticas mostrando los errores más comunes que se cometen a la hora de usar casos de uso, algo que he dado en llamar “los casos de abuso”, es un juego de palabras pero ilustra a la perfección el punto al que quiero llegar. Enumero y explico una serie de dieciséis casos frecuentes de mal uso de los casos de uso, desde la mala práctica de usarlos en todo momento y en cualquier contexto, pasando por los errores habituales de documentar detalles técnicos o de la interfaz de usuario en el caso de uso, hasta la costumbre perfeccionista de solo presentar el caso de uso cuando está “felizmente” terminado, solo cuando contiene todos los detalles que se han acordado con el usuario. ¿Quién diría que lo perfecto siempre es mejor que lo bueno? Pues bien, aquí sucede exactamente lo contrario: lo acabado, lo ideal, lo absoluto es enemigo acérrimo de lo bueno, de lo que proporciona valor. Es una de las conclusiones que obtendremos al final del capítulo. Incluso muchos de nosotros hemos llegado a pensar que el analista de requisitos y otros miembros del equipo de desarrollo son síquicos y que pueden leer nuestros pensamientos y saber lo que queremos sin habérselos dicho. De todo esto se trata este estudio al que clasifico de patológico y de forense, fueron situaciones que discutí mucho con algunos de mis colegas en Intergrupo.
El último capítulo del libro fue otro de los que siempre quise escribir en mi Gazafatonario: se trata de diez más uno consejos útiles y simples para escribir efectivamente casos de uso efectivos. La aliteración en el título me sirve para abordar dos asuntos importantes: el problema de la comunicación efectiva entre las personas y el problema de la calidad y utilidad de los artefactos de software, en este caso, de los casos de uso. Me parecía razonable, después de la descripción sintomática que hago en el capítulo anterior, sobre los errores más pronunciados que cometemos a la hora de modelar sistemas de software con casos de uso, traerles algunas propuestas para remediar nuestro trabajo, hacerlo más productivo y de mejor calidad. De eso se tratan estos consejos.
Dónde conseguir el libro
El libro lo pueden conseguir en:



[1] Yourdon, Edward. Object-Oriented System Design, an integrated approach. Prentice Hall. 1994.

jueves, mayo 08, 2014

Cultura Ágil, ese oscuro objeto del deseo

“El ingeniero de software aficionado siempre está a la búsqueda de algo mágico, algún método o herramienta sensacional que prometa convertir el desarrollo de software en algo trivial. Está en el ingeniero de software profesional saber que no existe tal panacea”.

[Grady Booch, Object-Oriented Analysis and Design]
Cultura Ágil, ese oscuro objeto del deseo
Este artículo fue publicado inicialmente en http://goo.gl/IuJIlY
Vivimos en una era de ofertas pero también de riesgo. ¿Qué tipo de productos queremos que usen nuestros clientes? La filosofía ágil está modificando a pasos aumentados el statu quo del desarrollo del software, con nosotros a bordo o sin nuestra participación. El interrogante es cómo y hasta qué punto seremos capaces de dar el salto hacia lo que ya está aquí: la cultura ágil.

El pronóstico que genera más suspicacia alrededor de la transformación hacia ágil es que va a dividir la comunidad de desarrolladores entre quienes tendremos éxito y quienes no lo tendrán, entre personas felices y personas desventuradas, y entre personas que tendrán una vida (o que volverán a tenerla) y personas que no; y que también fragmentará la gama de usuarios del software entre personas satisfechas y personas insatisfechas: será una segregación ágil. Este movimiento ágil que vive la ingeniería de software brinda la promesa de mejorar las vidas de quienes trasegamos por sus laberintos, pero también entraña la amenaza de segregarnos.
¿Pero a qué viene esta evolución hacia ágil? Primero, se trata de abandonar esa visión microscópica ampliamente difundida de la gestión de proyectos clásica de “comando y control”, enfocada en el cumplimiento de tiempos e hitos intermedios que muchas veces no tienen nada que ver con el producto y mucho menos con el cliente, de proyectos que solo son “vistos” a través de herramientas y procesos predictivos, y comenzar a mirarlos con los ojos del cliente, con el lente del Valor del producto para el negocio, y de las entregas continuas de producto con calidad.
Quienes llevamos ya algún tiempo construyendo software, cargamos en nuestro ADN aquel precepto de Deming de que la calidad de los productos depende en gran medida de la calidad de los procesos que se usan para crear y mantener esos productos. También llevamos a cuesta modelos de gestión de proyectos tipo “Comando y Control” y modelos de ejecución de procesos prescriptivos como CMMI, PMI, COBIT y los incontables ISO numeral.
Ninguno de estos modelos habla de las personas y sus interacciones ni de la trama del producto, ni del impacto que el producto debe generar en quien lo usa y de lo confortable y apoyado que debe sentirse este usuario con ese producto; y tampoco habla de la calidad y de la naturaleza del comportamiento de las personas que construimos el producto. De esto también se trata la cultura ágil.
En la práctica, es posible combinar métodos ágiles con Arquitecturas Orientadas a Objeto o Patrones de Diseño y con Principios de Ingeniería como Historias de Usuario o Casos de Uso 2.0 y Test Driven Development (TDD) o Behavior Driven Development (BDD), para crear productos grandiosos, que tengan “alma”, que tengan argumento, es decir, que sean significativos para el usuario, que le digan algo y que en algún momento del tiempo cambien su estilo de vida.
Ahora bien, estos métodos ágiles, con Scrum a la cabeza, no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deberían trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.
Esto se puede lograr poniendo en práctica algunos de los principios de Lean Software Development, o simplemente Lean. Estos principios, originados en el enfoque de manufactura lean de Toyota, constituyen una filosofía de gestión de procesos ampliamente aceptada en la comunidad ágil y buscan eliminar las entregas tardías tan comunes hoy en los proyectos de software, lo mismo que eliminar cualquier desperdicio, como código y funcionalidad innecesarios, requisitos poco claros, pruebas insuficientes que conducen a una repetición del proceso, al igual que la burocracia y la lentitud en la comunicación interna.
Ser ágil también es aceptar que los proyectos complejos (léase proyectos de TI) están sujetos a cambios, a redefinición de alcance y a oscilaciones en la priorización de los requisitos. Para ser ágiles debemos planificar para el cambio, trabajando a la sombra de un proceso que entienda esto. Ágil también nos puede proporcionar “estimaciones” de costo, o “estimaciones” de tiempo, pero los métodos ágiles son más honestos y nos abastecen con entregables de mejor y mayor valor mucho antes que un proceso “No-ágil”. En breve, ser ágil quiere decir reemplazar la predictibilidad falsa por la eficiencia.
Ser ágil también es acerca del equipo. Los equipos ágiles nos enfocamos en validar continuamente nuestras hipótesis y generar valor lo antes posible. Sabemos que esta es la base para equipos de alto rendimiento que enfrentan alta incertidumbre, como la presente en los proyectos de software. En estos equipos cambiamos la planificación basada en especialidades por un enfoque en la propagación de conocimientos, de experiencia. Además, en los equipos ágiles invocamos continuamente energías innovadoras para encontrar formas mejores de aumentar la productividad y el entusiasmo de los participantes.
Más allá de todo esto es importante entender que los procesos ágiles como Scrum se basan en el empirismo, lo que quiere decir que durante el proyecto aprendemos por Observación en vez de por predicción, es decir, de la experiencia y constantemente nos estamos adaptando para reencausar el proyecto si detectamos variaciones que pueden obstaculizar la consecución de los objetivos trazados.
Finalmente, en el camino hacia ágil hemos aprendido que el compromiso de cambio debe ser colectivo, que la meta de una organización ágil no es el uso del método sino el resultado: mejores equipos, individuos motivados, mayor valor de negocio entregado, moral más elevada, clientes felices, más que satisfechos, y mejores productos.
Esa es nuestra naturaleza, esa es la razón por la que estamos aquí. 
¿Quieres saber más?
Para saber más sobre Lean Software Development, visita el sitio de Mary & Tom Poppendieck: http://www.poppendieck.com/
Para saber más sobre Ágil y Scrum puedes leer estos artículos en mi Gazafatonario:



La Presentación

En este enlace puedes descargar la presentación basada en el artículo:



domingo, marzo 30, 2014

Lanzamiento de Agiles 2014: “Lo mítico, lo estético, lo simbólico”

La imagen es de Jorge Johnson.
La imagen es de Jorge Johnson.
El 27 de marzo ocurrió un hecho histórico para quienes hacemos parte del ecosistema ágil, se trata del lanzamiento de las 7as jornadas latinoamericanas de metodologías ágiles, Ágiles 2014.
En la Universidad EAFIT de Medellín nos reunimos representantes de la Industria, de la Academia, de las organizaciones sin ánimo de lucro del sector productivo (de software) y los entusiastas de las metodologías ágiles, miembros de la Comunidad Ágiles Colombia. En el ciberespacio, nos acompañaban desde distintos puntos, participantes de las distintas comunidades latinoamericanas con quienes llevamos adelante este proyecto.
Bajo el lema de “Sea protagonista del cambio en el mundo del trabajo”, Luis Mulato, presidente de la Conferencia, nos empezaba explicando cómo “narradores, protagonistas y testigos de historias de cambio nos han transmitido sus vivencias y ahora somos responsables de difundir su legado: Sí podemos cambiar el mundo”.
Me vino a la mente aquel fabuloso ensayo de Tobias Mayer en su libro The People’s Scrum, donde relata una imagen, la de “una oficina donde reina la risa y la pasión. Donde todos, inspirados por un espíritu de camaradería, habitados por un clima de entusiasmo, propósito común y esperanza, trabajan en un ambiente que fomenta la escucha, la comunicación abierta y la colaboración a mansalva.” Tobias se refería a un ambiente parecido al de una plaza o al del patio de la escuela, “donde la innovación y las ideas disruptivas eran una parte natural de cada interacción”.
Mulato nos contó la historia de Ágiles, desde la Pampa argentina hasta el café colombiano, hoy, y nos explicó como nuestra visión es la de “fortalecer a Colombia como un país comprometido con el uso de metodologías ágiles e integrar a la región, expandiendo los conocimientos y experiencias de las comunidades predecesoras en Centroamérica y México.”
La imagen es de Claudia Sandoval.
La imagen es de Claudia Sandoval.

Nos mostró cómo personalidades de la talla de Mary y Tom Poppendieck, Janeth Gregory y Jurgen Appelo, James Patton y Diana Larsen, entre otros, han participado en ediciones anteriores y que esperábamos contar con reconocidos expertos de la misma talla que ellos. Y hablamos de los beneficios de que la industria se sumara a la Conferencia:
  • Conocer las tendencias
  • Conocer experiencias en el medio
  • Ver la aplicabilidad del modelo
  • Compartir los resultados
  • Experimentar la felicidad de las personas
  • Percibir y dejarse contagiar de la energía renovadora que trae la cultura ágil, volver a amar los lunes en la oficina

Después, un momento especial, bueno, una suma de momentos, las charlas ignite, las conferencias relámpago, donde en solo 5 minutos, con 20 diapositivas que avanzan automáticamente, diversos conferencistas nos deleitaron con temas tan diversos como las de Jorge Johnson con sus “Girasoles, falanges y estimación relativa” en la que nos decía que todos somos geómetras y que nuestro cerebro “necesita buscar una cohesión o patrón geométrico”, nos habló de la filotaxis, naturaleza autoorganizada y la proporción dorada y cómo todo esto tiene relación con la estimación de proyectos ágiles de software. Al final, nos lanzó su hipótesis, la está estudiando a fondo me dijo, obteniendo las bases teóricas: “Nuestro cerebro tiene grandes habilidades para hacer estimación relativa con la secuencia Fibonacci.” Siendo fan de la archipopular progresión, yo no lo dudo. Esperaremos con ansias los resultados de su investigación.
Jaime García nos habló de la necesidad de un “Agilector 4000” en su “Selección Ágil de la Tecnología” y nos dejó a todos con la expectativa hasta octubre, fecha en la que ocurrirá el evento. Adrian Moya nos habló de “Desarrollo Guiado por Comportamiento” o BDD. Entre otros. La lista completa de participantes y temas y presentaciones la pueden encontrar aquí. Desde el exterior, vía Internet, nos acompañaron Diego Fontdevila con su “Arquitecturas y Organizaciones”, Martín Salias con su “Como escala la naturaleza” y Ricardo Colusso, entrevistando a Carlos Churba sobre “Principios para Estimular la Creatividad”. Al final, Verónica Vera nos deleitó con su “Futuro netamente humano”. En ese instante, el ambiente era mágico y quienes fuimos artífices y probablemente los participantes de esta fiesta de apertura nos dejamos contagiar de la felicidad, esa que tanto hemos vuelto a buscar y que estamos encontrando vía la cultura ágil.
En el cierre de la velada hablé de cómo es que seguimos viviendo en un momento histórico, pleno de ciencia y tecnología, pero también lleno de dilemas y conflictos humanos. Mientras lo decía, pensaba de nuevo en ese ensayo de Tobias, en su imagen renovada de la oficina del futuro, y en el mecanismo que teníamos para lograrlo. Tobias dice que “ese mecanismo no se llama Scrum. No hay framework, proceso o metodología que por sí solo permita alcanzar esta visión.” Más adelante expone finalmente que “hay solo una persona, un método, una cosa que puede hacer realidad esta visión. .” Por eso el gran reto, dije entonces, el nuestro, es que junto al cálculo y a la técnica, junto al método y a la teoría, hagamos convivir lo mítico, lo estético, lo simbólico.”
¡Nos vemos en octubre!

martes, marzo 04, 2014

Algunas Notas Sobre Gestión del Producto en Scrum

"Si puedes soñarlo, puedes hacerlo". Walt Disney.
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Quienes venimos de enfoques tradicionales de desarrollo de software caracterizados por proponer y hasta exigir una diversidad de artefactos, encontramos la Lista de Producto (Product Backlog) de Scrum como algo tan hermosamente simple que raya en lo poético. Quizás a esa simplicidad se deba su inmensa popularidad entre los practicantes ágiles.
La Lista de Producto es un inventario priorizado del trabajo pendiente necesario para traer el producto a la vida. El Dueño de Producto es el responsable de la Lista de Producto y de su contenido. Nadie tiene una visión del producto que va más allá del producto en sí, como el Dueño de Producto.

Sus elementos pueden incluir:
  • Una exploración de las necesidades del usuario
  • Opciones técnicas variadas
  • Una descripción tanto de requisitos funcionales como no funcionales
  • El trabajo necesario para lanzar el producto

También puede contener otros elementos como:
  • Configuración del entorno
  • Defectos del producto. 

La Lista de Producto reemplaza los artefactos tradicionales de requisitos, tales como las especificaciones de requisitos del software. Mientras que el Dueño de Producto se compromete a manejar la Lista de Producto, el Scrum Master, el equipo y los interesados contribuyen a esta tarea. Juntos, descubren la funcionalidad del producto. Además, la Lista de Producto es también una herramienta para proporcionar transparencia durante el proyecto.
Sobre la Priorización
La priorización de la Lista puede hacerse de muchas formas, pero es algo que siempre se hace con el Dueño de Producto a bordo, liderando la priorización. Por ejemplo, es posible crear temas que contienen una lista de historias. Cada uno de estos temas tiene un “costo de retardo” asociado. Esto permite conocer el impacto de no implementar un tema si antes implementamos otro.
En este apartado debemos tener en cuenta que si se nos dificulta la priorización de la Lista de Elementos del Producto, puede estar sucediendo que:
  1. Los elementos, por ejemplo las historias de usuario, son muy grandes para priorizar
  2. No hay ningún valor de negocio asociado al Elemento de la Lista de Producto.
En el primer caso podemos dividir las historias en historias más pequeñas y relacionadas. En el segundo caso, podemos desechar estas historias “sin valor” y encontrar otras que sí reflejen valor del negocio o Retorno de la Inversión. Recuerda, si el Dueño de Producto no es capaz de escribir estas historias, el Scrum Master está a su servicio para ayudarle. No pretendas en el primer intento que un usuario tenga las habilidades y experiencia necesarias para escribir historias de usuario que cumplan con los atributos INVEST. Además, por lo general, no es posible cambiar de Dueño de Producto, es alguien sin quien el proyecto no puede vivir.

Sobre los defectos del producto
Si te estás preguntando como encargarte de esas anomalías que surgen o pueden surgir luego de la salida a producción del software y no sabes si decidirte por usar historias y priorizarlas en la Lista de Producto junto con las nuevas características, y si no estás buscando dogmas, puedes simplemente pensar en trabajar con el Dueño de Producto para clasificar y priorizar esos defectos en producción, luego los puedes tratar como historias de usuario a incluirlos en una entrega específica.
Al igual que en enfoques clásicos de mantenimiento de productos, si el defecto causa un alto impacto en los usuarios, este debe escalarse y resolverse como un ajuste en producción sin pasar por la cadencia normal de Scrum. Lo que sí puedes hacer es manejar la reparación del software usando un proceso Kanban, el cual permite un enfoque más liviano de gestión. Eso sí, no olvides que un error en producción representa valor negativo para el negocio así que dedica un esfuerzo mayor a evitarlos o a reducirlos al mínimo más que a corregirlos.
Cuando hagas esto piensa que:
  • Si una parte del producto tiene desperfectos, todavía no está Terminada.
  • Cualquier trabajo que necesite hacerse, necesita priorizarse.
  • Cualquier actividad que realice el equipo, toma tiempo.
  • El tiempo consumido en una cosa, no puede consumirse en otras cosas.

Los Atributos DEEP de la Lista de Producto
Dice Mike Cohn que una Lista de Producto efectiva tiene estas cuatro propiedades: detallada apropiadamente, estimada, emergente y priorizada. De allí el acrónimo DEEP.
Detallada Apropiadamente
Los Elementos de la Lista de Producto en la parte superior se describen en mayor detalle que los que están en la parte inferior de la Lista. A medida que bajamos en la lista, los elementos están menos detallados. Esto tiene sentido: son elementos que se convertirán en software apenas varias iteraciones más adelante o quizás nunca, si el usuario nota que no los necesita o si se acaba el presupuesto del proyecto. De hecho, es posible que el Dueño de Producto cambie la prioridad de alguno de estos, en cuyo caso solo debe llenar los vacíos de ese elemento para que quede “preparado” para construirse.
Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle
Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle
Esta técnica asegura que la Lista de Producto se mantenga concisa y que los elementos a implementarse en el siguiente sprint son trabajables. Una consecuencia de este enfoque es que los requisitos se descubren, se descomponen y se refinan a lo largo de todo el proyecto. Es otra de las razones por las cuales el Dueño de Producto debe trabajar con el Equipo de Desarrollo cotidianamente durante todo el proyecto, o más o menos así reza uno de los Principios Ágiles.
Estimada
La estimación de los Elementos de la Lista de Producto usualmente se expresa en puntos de historia o en “días ideales”. Conocer el tamaño de los elementos ayuda a priorizar y a planificar las entregas a producción. Recordemos que otras estimaciones más detalladas a nivel de tareas se realizan durante la Reunión de Planificación del Sprint; y también, estas tareas y sus estimados se capturan en la Lista de Pendientes del Sprint.
Un día ideal es una abstracción del número de horas diarias en las que normalmente esperas que un miembro del equipo sea productivo, restando tiempo para asistir a reuniones, ir al baño, tomar un café o simplemente hacer una pausa laboral.
Emergente
La Lista de Producto tiene una cualidad orgánica. Evoluciona y su contenido cambia frecuentemente. Nuevos elementos se descubren y adicionan a la Lista basados en retroalimentación del usuario, principalmente. Los elementos existentes se modifican, re-priorizan, refinan o se remueven permanentemente.
Priorizada
Todos los elementos en la Lista de Producto se ordenan según su valor e trascendencia para la Organización. Los elementos más importantes y de más alta prioridad se implementan primero. Estos pueden encontrarse al principio de la lista, como indico en la Figura 1. Luego de que un elemento esté “Terminado”, se elimina de la Lista de Producto.
Finalmente
La Lista de Producto existe por un propósito más grande: construir un producto que impacte a los usuarios, que haga resonancia en ellos/ellas y que cambie en algo sus estilos de vida.
El producto debe construirse de manera orgánica, es decir, tan pronto como sea posible, debemos tener una versión que los usuarios puedan usar, el producto mínimo viable. A partir de este producto parcial, coherente y de valor, se construye el producto completo.
Al construirlo, piensa que estás componiendo una pieza musical grandiosa, la sinfonía definitiva, una que será recordada por siempre. Una obra así despliega patrones, trayectorias e incita a las personas a estar a su alrededor.
¿Quieres saber más?
Te recomiendo ampliamente este artículo de Jeff Sutherland:
Enabling Specifications: The Key to Building Agile Systems
El libro de Roman Pichler, Agile Management with Scrum, Creating Products That Customers Love. Addinson-Wesley, 2010.
Sobre Historias de Usuario, mi serie de artículos:
Historias de Usuario: un nuevo orden en los requisitos del software
Historias de Usuario Altamente Efectivas, Parte 1
Historias de Usuario Altamente Efectivas, 2
Historias de Usuario Altamente Efectivas, 3
Historias de Usuario Altamente Efectivas, 4