Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Proceso. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Proceso. Mostrar todas las entradas

jueves, abril 23, 2015

Sobre medir y controlar o de cómo Tom DeMarco admitió su equivocación

“El Control conduce al cumplimiento; la autonomía conduce al compromiso”
Daniel H. Pink (Autor de “A Whole New Mind: Why Right-Brainers Will Rule the Future”)

Imágen tomada del artículo de Computer.org
En 1982, Tom DeMarco escribió su renombrado libro “Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982). La primera frase del libro, su primerísima idea, quedó ensamblada en los anales de la industria de software durante las siguientes décadas y nos ha llegado intacta hasta esta era. Se trata de su: “No puedes controlar lo que no puedes medir”.

Este pensamiento influyó de manera certera en los modelos de calidad, procesos de producción, enfoques de mejora* y herramientas de construcción de software, quizás como ninguna otra idea de aquellos tiempos. Pero incluso Tom DeMarco cambió de opinión. En 2009 publicó este artículo en la IEEE Computer Society: “Software Engineering: An Idea Whose Time Has Come and Gone?”  (Ingeniería de Software: ¿una idea cuyo momento ha pasado?)” que pueden encontrar haciendo clic aquí.

En el artículo, DeMarco reflexiona sobre si este consejo era correcto en ese momento, sobre si todavía era relevante (al momento de escribir ese artículo en 2009) y que si todavía creía que las métricas eran un deber ser para cualquier esfuerzo exitoso de desarrollo de software. Sus propias respuestas fueron unos tajantes no, no y no.

Es bien conocida la historia de que los enfoques rígidos más tradicionalistas adhirieron completamente a este precepto y crearon áreas de proceso y de conocimiento dedicadas en su totalidad al establecimiento, gestión y control de métricas en los proyectos (de software). A partir de allí, se empezó a medir el éxito o fracaso de los proyectos, en principio, con tres de esas medidas: el tiempo, el presupuesto y la calidad, siendo esta última un poco más abstracta y más subjetiva si se quiere. Después, con muchas otras que no vale la pena mencionar aquí.
Esa institucionalización de métricas derivó a su vez en algo que con el tiempo se convirtió en uno de los mayores desincentivos para quienes trasegamos por los laberintos azarosos de la construcción de productos de software: el trabajo intensivo, esas largas jornadas de trabajo de doce, dieciséis y más horas diarias durante largos períodos de tiempo previos a la entrega del producto. Mi amigo y colega Jorge Abad dice en su blog Lecciones-Aprendidas.info que eso trajo como consecuencia la destrucción de hogares, de familias enteras y yo le creo.

Esta forma de trabajo extrema, cuya consecuencia principal, además de la citada por Jorge, era la de un bajón en productividad, acompañado de una entrega de producto con mala o malísima calidad, con el tiempo degeneró en algo mucho más grave que es de todos conocido: desmotivó a las nuevas generaciones a estudiar carreras relacionadas con la TI: Ingeniería Informática, de Sistemas, de Software y afines. El mismo Tom DeMarco (¡otra vez!) enunció en su otro libro, “Peopleware : Productive Projects and Teams” (2ª edición, 1999), que “no trabajamos horas extras en demasía para terminar el trabajo a tiempo sino para protegernos de culpa cuando inevitablemente no conseguimos hacer el trabajo a tiempo.” En efecto, lo hacíamos simplemente para cumplir, no para ser más productivos, ni para mejorar la calidad del producto. Y a eso nos llevó la fuerza ejercida por el modelo de Comando y Control y de la medición de cosas que no reflejaban la realidad del proyecto, al menos no la realidad de las personas que ejecutaban el proyecto.

La reflexión de DeMarco en el artículo que ya he citado termina también de manera asombrosa para quienes seguimos sus cánones durante casi tres décadas: “Consistencia y predictibilidad aun son deseables, pero nunca han sido las cosas más importantes. En los últimos 40 años, por ejemplo, nos hemos torturado con nuestra incapacidad de terminar proyectos de software a tiempo y en el presupuesto. Pero esta nunca ha sido la meta suprema. La meta más importante es transformación, creando software que cambie el mundo o que transforme una compañía o cómo esta hace negocios.”

Bien sabemos ya que lo más importante en los proyectos de software es la entrega continua y frecuente de Valor al negocio, desde el inicio del proyecto. Y que nunca más apostaremos o usaremos artes adivinatorias para establecer la fecha de entrega, ni qué parte del producto entregaremos en ese momento, ni cuánto será su costo. En cambio, empezaremos con planes y alcance iniciales y nos enfocaremos en la revisión continua de esas restricciones a medida que vamos avanzando. Finalmente, nuestra meta será siempre entregar el mejor producto posible, teniendo presente que ningún método con el enfoque de receta de cocina (léase métodos tradicionalistas) hará mejor lo que es mejor. Esta es la filosofía ágil.

Coletilla

Aquella aciaga prescripción de DeMarco sobre lo que se puede medir y controlar derivó en procesos rígidos, tradicionalistas, que dieron poder solo a algunas personas en la organización; pero lo realmente hermoso, lo humanamente divino, es que los métodos y las prácticas ágiles dan poder a todo el mundo… o a nadie.



--------------------------------------------------
* Por ejemplo, H. James Harrington, reconocido autor de libros sobre mejora de procesos, calidad, desempeño y gestión del conocimiento, y fundador del laureado Instituto Harrington, extendió el pensamiento de DeMarco, diciendo: “Medir es el primer paso hacia el control y eventualmente hacia la mejora. Si no puedes medir algo, no puedes entenderlo. Si no puedes entenderlo, no puedes controlarlo. Si no puedes controlarlo, no puedes mejorarlo.”

martes, julio 01, 2014

Respuesta al cambio sobre seguir un plan: ¡no planearás!

“El plan no es nada, la planificación lo es todo”. Eisenhower
Imagen cortesía de Vichaya Kiatying-Angs / FreeDigitalPhotos.net
Basado en hechos históricos

Natalia es gerente de proyectos de una importante compañía proveedora de servicios de tecnología. Es la encargada de la operación en uno de los clientes más grandes de la empresa: un conglomerado de telefonía móvil. Hacia el final de esta mañana la llamó el director de mercadeo de esa organización bastante alarmado:

         - Natalia, hablas con Juan Pérez de Móviles del Sur* - ¿tienes un momento?
         - Hola Juan, ¿en qué te puedo ayudar?

Lo que siguió fue toda una perorata que inquietó a Natalia. El cliente le contó cómo durante la mañana se enteró de la Promoción Rumbo al Mundial Brasil 2014 que su más encarnizado competidor sacaría a la luz la noche de ese día. Pérez sabía que de no responder efectiva y rápidamente no solo dejaría de ganar cientos o miles de clientes, sino que perdería muchos otros, lo que podría golpear severamente sus márgenes de ganancia durante el primer semestre del año. Para suerte de Natalia, el señor Pérez había hecho su tarea, ya sabía que debía actualizar las herramientas de software de mercadeo y ventas para soportar una promoción agresiva que debería estar al aire en la TV y en las redes sociales dos horas antes que la de su competidor.

Mientras Pérez hablaba, Natalia revisaba rápidamente el proceso de control de cambio de la compañía y concluyó que podría entregarle una propuesta de trabajo que incluyera el impacto de la actualización del software en costo y presupuesto a su cliente pero solo hasta el día siguiente. Era inaudito, mientras Juan Pérez estaba buscando una respuesta ágil y eficiente que concluyera con un resultado de valor en las próximas 8 horas, Natalia se enfrentaba a la disyuntiva de seguir un proceso clásico de estimación a priori y modificación del plan de trabajo, previo análisis de impacto y de costos, que redundaría en una pérdida tanto para su compañía como para la de su cliente, o simplemente responderle firme y positivamente que cumpliría la meta establecida para las siguientes horas.

El Manifiesto por el Desarrollo Ágil de Software (aka: la solución del proveedor)

Por suerte para Natalia, ella también había hecho su tarea. En los últimos tiempos había empezado un proceso de transformación en sus equipos que incluía una forma de ver el mundo de manera distinta a como lo venían haciendo en la compañía. Se trataba de todo un ecosistema basado en una cadena de valores y principios que rompían con los esquemas tradicionales de hacer software. Todo empezaba con el así llamado Manifiesto por el Desarrollo Ágil de Software o, simplemente, Manifiesto Ágil, el cual le daría la clave para ganar ese día:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
El Manifiesto Ágil por el Desarrollo de Software. Fuente: http://www.agilemanifesto.org/iso/es.

Este pedazo de esfuerzo mental, fruto de la colaboración de 17 personajes reconocidos en la industria del software en 2001, serviría a Natalia como pilar fundamental para encontrar una solución de valor para su cliente. Los Valores y Principios Ágiles enfatizan en la importancia de colaboración e interacción en el desarrollo de software y, de otro lado, el trabajo creativo involucra comúnmente alguna forma de colaboración y puede entenderse como una interacción entre un individuo y un contexto sociocultural.

Los proyectos tradicionales están plagados de equipos conducidos-por-gerentes, organizados en una estructura jerárquica con múltiples capas de autoridad. Esta gerencia es del estilo de “comando y control” y los roles se basan en tareas funcionales que, en el caso del software, son los programadores, los diseñadores, los analistas, etc. El trabajo se delega a los miembros del equipo por sus jefes. Las prácticas en estos equipos incluyen copiosa documentación, especificaciones previas y planeación detallada. Las líneas de comunicación son indirectas entre las distintas capas de la jerarquía organizacional y el empoderamiento es algo invisible para la mayoría de los participantes, lo mismo que el estado general del proyecto.
Imagen cortesía de Salvatore Vuono / FreeDigitalPhotos.net
El primero de los valores “Individuos y sus interacciones”, le indicaba a Natalia que necesitaba un equipo cooperativo, multi-funcional y auto-suficiente, experto, altamente productivo y creativo que se comunicara con su cliente y trabajara con él el resto de la tarde, no solo en la extracción de conocimiento típica de los proyectos actuales, sino en todo el ciclo de producción que le permitiera a Móviles del Sur poner en funcionamiento una solución automatizada que soportara su ambicioso programa de retención y captura de clientes con motivo del evento mundialista de los próximos meses. Recordó así uno de los Principios que acompañaban a esos valores ágiles:

Principio Ágil # 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Natalia sabía que la filosofía ágil tiene la habilidad de amplificar la productividad de los equipos de software hasta una escala de gran magnitud, a través del empoderamiento de las personas, fomentando un entorno orientado-al-equipo y enfocándose en la transparencia del proyecto y en los resultados. Estos proyectos pasaron de ser dirigidos-por-el-plan a estar enfocados en el producto, uno priorizado por y de valor para el cliente. Estos equipos se identifican a sí mismos como una unidad social dentro de la organización de la cual hacen parte y a quienes se les confía la ejecución del trabajo y se les proporciona el entorno y el apoyo que necesitan, para mantenerlos motivados, como invoca otro de los principios del Manifiesto Ágil, y para aumentar su apego emocional a la empresa.

Si bien se trata de un conjunto de Valores, el último de estos, pero no por eso menos importante, no devalúa la planificación, en la práctica solo se adhiere al plan. La planificación es valiosa en sí misma; y dado que el plan nos asiste en la tarea de reconocer cuándo las cosas han cambiado, también nos ayuda a entender las implicaciones del cambio, cómo tenemos que ajustarnos y cuál es el costo probable. Lo importante es que, a medida que hacemos planes, entendamos que el plan puede cambiar. La planificación es una actividad continua que incluye:
  • Reuniones de planificación de iteración
  • Reuniones diarias
  • Reuniones de revisión
  • Retrospectivas
  • Evaluación de riesgos

Planificación clásica versus planificación ágil y un mito que se niega a desaparecer
Imagen cortesía de hin255 / FreeDigitalPhotos.net
Cada una de esas ceremonias sirve para no solo para planear sino también para inspeccionar el estado del proyecto y crear mecanismos de adaptación en caso de ser necesario. El grueso de los practicantes de la industria y quienes la miran desde los tejados, cree que los equipos ágiles son desorganizados, informales, que no documentan y sobre todo que no planean. Todo eso se debe en parte a la mala lectura que le dan al mismísimo Manifiesto Ágil. Pero no es así. Contrario a lo que ocurre en los modelos tradicionales de planificación, donde se planea al comienzo, se elaboran planes de 2, 3 o más niveles, y se hace seguimiento a ese plan durante el resto del proyecto, un seguimiento que raya en el acoso, los equipos ágiles planean todos los días.

En parte eso se debe a que los equipos ágiles saben que los cambios hacen parte inherente, son constituyente primario del ADN, del ciclo de vida del software. Los cambios pueden ocurrir en cualquier momento, desde las etapas iniciales del proyecto, aun cuando apenas se están conociendo las necesidades del usuario, hasta las fases tardías del proyecto, quizás cuando estamos a punto de salir a producción. Si son bien manejados, los cambios brindan muchos beneficios a los usuarios, el primero de ellos, ventaja competitiva. Los cambios son una herramienta invaluable para crear productos inmejorables. Era precisamente lo que necesitaba Juan Pérez ese día. Otro de los principios ágiles llevó a Natalia a esa conclusión:

Principio Ágil # 2: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

En cambio, los enfoques tradicionales de gerencia de proyectos presentan los cambios como un monstruo con el que hay luchar a sangre y fuego. Los procedimientos rigurosos de control de cambio, típicos de estos enfoques, causan la pérdida de oportunidad que los clientes tienen para ganar más mercado y para crear mejores productos. En general, a medida que el tiempo avanza, la habilidad de hacer cambios disminuye y cuesta más. Esto es lo que enfrentan los procesos ágiles, aunque sin dejar de planear. Los métodos ágiles promueven planes más livianos y de alto nivel a largo plazo, mientras que atienden la elaboración de agendas bien detalladas a corto plazo, las de la iteración actual, que solo tarda unos pocos días o muy pocas semanas. En Scrum, por ejemplo, las iteraciones tardan máximo 4 semanas y con frecuencia mucho menos que eso.

Al principio de los proyectos ágiles se planean las entregas o salidas a producción tempranas, beneficio primario que nos traen los procesos ágiles. Estas salidas a producción pueden ser cada tres meses, pero hoy contamos con la tecnología y plataformas lo suficientemente maduras como para hacer continuous delivery o entregas continuas. Amazon, por ejemplo, la vendedora al detal más grande del mundo, sale a producción cada 11,6 segundos, algo absolutamente asombroso si tenemos en cuenta la cantidad de clientes recurrentes simultáneos que tiene su sitio Web cada segundo. Natalia sabía todo eso, entonces no dudó que podía tener un producto funcionando para antes de las 8 de la noche de ese día, meta principal de su cliente.

Resultado final

Mientras hacia un recorrido por los acontecimientos de la hora, Natalia convocó a un equipo idóneo, uno que sabía capaz de elaborar un producto que generara resonancia no solo en su cliente sino en sus usuarios, uno que haga que la gente experimente distintas reacciones de gozo al usarlo, sin hablar de los ingresos en que redundaría su uso. No se trataba solo de actualizar un pedazo de software existente, sino de producir algo no ordinario que tuviera la capacidad de atraer a una audiencia cada vez mayor. Otro de los principios ágiles fue el último consejo que le dio al equipo antes de despedirlo hacia lo que seguramente sería un éxito total:

Principio Ágil # 10: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

¿Quieres saber más?

Sobre otros mitos y leyendas relacionadas con los métodos ágiles puedes leer:
Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum: http://goo.gl/PIfZpx

Sobre planificación ágil, estos 2 artículos:
Planificación del Sprint: el primer paso para producir el máximo efecto: http://goo.gl/9TO7FF
Compendio Sobre el Scrum Diario: http://goo.gl/GG7id1

Sobre cultura ágil y transformación a ágil, estos 2 artículos:
Cultura ágil: ese oscuro objeto del deseo: http://goo.gl/IuJIlY
Sí, usted está listo para implementar un proyecto ágil: http://goo.gl/19Hcnz


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.

martes, mayo 21, 2013

Scrum – Lo Fundamental


Lista de Chequeo de Scrum
Si logra esto puede ignorar el resto de la lista. Su proceso está bien.
  • Entregar software funcionando y probado cada 4 semanas o menos
  • Entregar lo que el negocio necesita más
  • El proceso está mejorándose continuamente

Hablemos un poco de cada uno de estos criterios.

Entregar software funcionando y probado cada 4 semanas o menos

Scrum es un método iterativo e incremental. Pero “iterativo” e “incremental” son dos adjetivos ampliamente usados y pocas veces entendidos correctamente. Ya sabemos que una iteración es un proyecto, con todo lo que eso significa: es decir, si nos atenemos a la definición del PMI®, un proyecto tiene un inicio, una planeación, una ejecución, un seguimiento y control, y un cierre, donde se formaliza la aceptación del producto o resultado, un producto que, en nuestro caso, es precisamente software, desplegado en un ambiente del usuario, no necesariamente ambiente de producción, pero del usuario al fin y al cabo, un entorno distinto al del desarrollador.

Este “incremento” de software funcionando es potencialmente distribuible, o sea, puede ponerse en producción con muy pocas o ninguna modificación, preferiblemente esto último. Y si este proyecto tarda cuatro semanas (como lo prescribe la guía orgánica de Scrum) o menos, mucho mejor. La industria del software, la nuestra, está diciendo a gritos que este lapso de tiempo sea de dos semanas. Así, podemos conseguir retroalimentación más efectiva y al día de los usuarios, mucho más de lo que hemos logrado en el pasado cuando solo entregábamos “papelware”, documentos llenos de texto (requisitos), diagramas de UML (arquitectura, análisis y diseño), casos de prueba, etcétera.

Entregar lo que el negocio necesita más

¿Quién mejor que el usuario conoce el verdadero valor de lo que necesita? Es el usuario, que en Scrum se llama Dueño del Producto, el que define y prioriza sus necesidades y las de los demás interesados, asegurándose así que los intereses de la organización queden incluidos en el producto; también es quien sabe cómo alcanzar las metas organizacionales y es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo, y es el encargado de no perder el foco en el valor de negocio. Bien sabemos que, a más involucramiento del cliente en el proyecto, este saldrá mejor y se obtendrá una mayor satisfacción al final, tanto el usuario como el equipo que lo atiende.

Con esta premisa en mente, en esas iteraciones o sprints de corta duración que mencionaba en el apartado anterior, siempre estaremos entregando el producto que todos quieren ver. Un beneficio directo de esto es la posibilidad que tiene la organización de responder a la competencia aun durante el propio proceso de desarrollo y no después de este, como ocurre en los proyectos ejecutados con métodos más tradicionales. Además, este enfoque hace que el producto vaya madurando en la medida de su exposición a los usuarios. A medida que el producto se expone y más cambios resulten de allí, más maduro llega a ser el producto. Y cuando esto ocurre, la probabilidad de obtener ROI a corto o mediano plazo es mucho mayor.

El proceso está mejorándose continuamente

Empiece con Scrum “al natural” o Scrum orgánico, o sea, el que está definido en la guía de Ken Schwaber y Jeff Sutherland: consiga un dueño de producto (un cliente), nombre un Scrum Master y establezca un equipo de desarrollo pequeño. Y ya está listo para iniciar. Haga la reunión de planeación, asegúrese vía el Scrum Master de que el equipo completo esté realizando la reunión diaria y que al final de cada sprint de 4 semanas o menos se haga una reunión de revisión y una de retrospectiva para conocer no solo el estado del proyecto sino del equipo en general y para crear un plan de mejoramiento que sea ejecutado a partir del siguiente sprint y en los demás proyectos con Scrum.

Asegúrese de que todo lo mencionado se haga como dice la guía, por ejemplo, que las reuniones diarias tarden 15 minutos flash. De lo contrario, mejore primero esos aspectos que no se están haciendo bien. El Scrum Master debería ser capaz de lograrlo. A partir de allí, vaya introduciendo nuevas prácticas, no sin antes entrenar al equipo: refactoring, desarrollo dirigido por pruebas o TDD por sus siglas en inglés, kanban, lean, historias de usuario, programación en pares, casos de uso 2.0, entre otras. Adiciónelas una a una al proyecto, haga acompañar a su equipo de expertos en cada técnica, monitoree su ejecución, mida los resultados y haga los ajustes necesarios. Repita para cada práctica.

Conclusión

La entrega constante de software probado y funcionando cada pocos días o semanas, que sea de valor para los usuarios, y el mejoramiento continuo del proceso, contribuyen trascendentalmente al éxito en los proyectos. Scrum es un marco de trabajo que hace posible todo lo anterior. Y esta lista de verificación, la cual iremos atomizando poco a poco en este Gazafatonario, es un instrumento productivo que se puede usar como suplemento de primer orden a la guía de Scrum.

Lecturas adicionales:

La lista de verificación completa de Scrum la encuentran en mi artículo:

Sobre Iteraciones pueden leer mi artículo "Gerencia de Proyectos Iterativos" en la revista de la Asociación Española de Profesionales en Dirección de Proyectos.

El libro de reglas de Scrum, la guía de Scrum, lo encuentran en:

Sobre casos de uso 2.0 y métodos ágiles pueden leer mi serie de artículos en este Gazafatonario:

Casos de Uso 2.0 y Métodos Ágiles:

Casos de Uso 2.0:

¡Quiero una Porción de Caso de Uso!

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones:

Todavía Otra Lección Más Sobre Porciones de Casos de Uso:

¿Por qué existe Casos de Uso 2.0?

Todavía Otra Lección Más Sobre Porciones de Casos de Uso:
http://www.gazafatonarioit.com/2013/02/todavia-otra-leccion-mas-sobre.html

domingo, mayo 12, 2013

Lista de Chequeo Scrum


Clic sobre la imagen para ampliar. Clic para [Descargar] la Lista de Chequeo Scrum
De las muchas listas de verificación que encontré, esta llenó mis expectativas. La lista original es de Henrik kniberg. La pueden encontrar en sueco y en otros idiomas en: www.crisp.se/scrum/checklist.
Esta es la traducción al español.

¿Qué es esto? ¿Para quién es?

La lista de chequeo Scrum es una herramienta simple para ayudarte a empezar con Scrum, o para evaluar tu actual implementación de Scrum.

Nota que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum, pero se aseguraron de que el propósito de la práctica Scrum se cumplió de otra forma. ¡Esto es lo que cuenta!

Si estás haciendo Scrum, podría ser interesante hacer que tu equipo tenga esta lista en la Retrospectiva como una herramienta de discusión, no como una herramienta de evaluación.

¿Cómo la uso?

        Joe: “Para esta retrospectiva, les he traído una pequeña y útil lista de chequeo. ¿Hay algo de esto que no estamos haciendo?”.

        Lisa: "Hmmm, veamos. Bueno, ciertamente nos hace falta la Definición de Terminado y no estamos midiendo la Velocidad”.

        Joe: “Bueno, la 'Definición de Terminado' está listada bajo 'Scrum Esencial' ¡así que parece muy importante! La Velocidad está listada bajo 'Recomendado, pero no siempre necesario' así que eso puede esperar y empecemos con lo esencial.

        Lisa: “Mira, también nos hace falta ‘Entregar producto funcionando y probado cada 4 semanas o menos'. ¡Eso está listado bajo 'Lo Fundamental'! Tiene sentido, ¡porque Mercadeo siempre se está quejando de eso!”

        Joe: “Quizás un concepto como la 'Definición de Terminado' podría ayudarnos a tomar porciones más pequeñas por sprint y liberar funcionalidades más seguido.”

        Lisa: “Buena idea, intentémoslo.”

¿Cómo NO la uso?

        Gran Jefe: “Bien, equipo, hora de ver qué tanto cumplimos con Scrum. Llenemos esta lista de chequeo, por favor.”

        Joe: “Jefe, estoy feliz de reportar que estamos haciéndolo todo. Bueno, todo excepto los gráficos de trabajo pendiente del Sprint.”

        Gran Jefe: “¡Mal, mal equipo! Aquí dice que ustedes deberían estar haciendo estas... eh...  ¡cosas pendientes del sprint! ¡Las quiero ver!”

        Lisa: “Pero nosotros hacemos sprints de 2 semanas y casi siempre entregamos lo que nos comprometemos a hacer, y los usuarios están felices. Las gráficas de trabajo pendiente del sprint no agregarían valor en este escenario”.

        Gran Jefe: “Bueno, aquí dice que deberían hacerlo, así que no dejen que los encuentre haciendo trampa otra vez, ¡o llamaré a la policía Scrum!”

¿Es esta una lista de chequeo oficial?

No. La lista de chequeo refleja mi opinión personal y subjetiva acerca de lo que realmente importa en Scrum. He pasado años ayudando a compañías a empezar con Scrum y he conocido a cientos de otros practicantes, instructores y entrenadores; y he encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.

Descargar la lista de chequeo Scrum
Puedes descargar la lista en formato PDF aquí.

Más sobre esta lista de chequeo de Scrum

Para profundizar más en los conceptos de la lista, puedes leer este artículo:

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html