Cómo ven que a los productos de software desarrollado por un equipo Agile sean probado (testeado) por un equipo no Agile (tradicional)?

No es una locura, pasa bastante seguido. Piensen en un cliente que contrata una empresa de desarrollo Agile o varias de ellas para distintos productos y los pre-releases son enviados a otra organización diferente para el testing de sistema donde se corren exaustivamente distintos tipos de pruebas, como usabilidad, bases de datos, performance, seguridad (autenticación/ autentificación), etc.

Esta discusión la abrí hace 20 días en el grupo ScrumMaster de Linkedin y aún tiene una interesante participación, con variadas opiniones expuestas por los distintos miembros del grupo.

Lo primero que pude notar es que este planteo del testing realizado por un equipo NO AGILE a un producto desarrollado por un equipo AGILE, es algo que en realidad no viene a ser muy común en el mundo del desarrollo del software. Al menos puedo tomar esta deducción en base a que no muchos se animaron (en relación con otros debates) a participar y a su vez, los que participaron, no ofrecieron muchas variantes, desde el punto de vista de experiencias reales con este formato que propuse.

Desde una perspectiva defensiva hacia el equipo Scrum pareciera ser importante evitar a toda costa la irrupción de parte del equipo de testing al equipo de desarrollo y es entonces cuando el verdadero desafío tiene que ver en como resolver situaciones en la que se detectan errores de severidad alta, que tienen estrecha relación con el trabajo “ya finalizado” y requiere modificaciones importantes o cambios en las características originales desarrolladas en Sprints anteriores.

Dicho de manera gráfica, si el equipo independiente de testing detecta issues debe tener en claro que bajo Agile, lo que el equipo de desarrollo ya liberó, no puede ser modificado y cualquier mejora o cambio, requerirá de la introducción de nuevos elementos al backlog del producto y la gestión correspondiente.
Entonces una solución podría ser que el pre-release existente se transforma en un pre-release con issues conocidos y se refleja en las notas del incremento.

Pero que sucede en escenarios en los que el cliente entrega la potestad al equipo de testing independiente, de determinar si el producto se puede liberar o no.

Es sabido que hay organizaciones que exigen que sus productos críticos sean evaluados para la superación de ciertos criterios de calidad a los cuales llaman “Portales de Calidad”, los cuales solo pueden ser superados por el equipo de testing siguiendo los tradicionales planes de calidad y testing de proyectos también tradicionales. Esta situación sin duda pone en una posición precaria al equipo de desarrollo Agile, políticamente hablando.

Desde el punto de vista de Agile, se podría plantear también que mientras el equipo de testing se concentra en registrar issues de iteraciones pasadas, el equipo de desarrollo se concentra en generar un nuevo incremento funcional de valor para el cliente y cabe la posibilidad de que la resolución de la mayoría de los issues detectados por testing, carezcan de algún valor para cliente en Sprint posteriores.

Diferencias metodológicas

Un punto muy importante a considerar es la gran diferencia metodológica del proceso de testing entre un equipo de Testing-Agile y un equipo de Testing-Tradicional. Mientras que los primeros cobran vida y sentido en las mismas fases del desarrollo del producto (para este ejemplo en particular) los segundos tienen sentido cuando el producto ya existe y debe ser evaluado.
Metodológicamente hablando, el Testing-Agile no sería tan exigente en cuanto a la documentación requerida para realizar las pruebas de software, no exigiría un plan detallado, ni evidencias basadas en casos de pruebas del tipo script ejecutadas en determinados ciclos, ni pedirá métricas del testing.
En contraposición, el Testing-Tradicional sería exigente en todos esos aspectos y muchos más para determinar la cobertura de pruebas y calidad para el productos. También habría un plan detallado y varios puntos de control a respetar exaustivamente.

Variaciones de esta naturaleza, exige la comunicación entre ambos equipos y la consiguiente negociación para facilitar los hitos de liberación.
Dicho de otra forma, la colaboración del equipo Agile puede no ser una responsabilidad contractual, pero si es una necesidad imperiosa que el equipo Agile proporciones principalmente su know-how del dominio.

Y por otro lado considero una gran responsabilidad para con el mismo equipo de desarrollo, favorecer que sus creaciones sean correctamente interpretadas y evaluadas. No cabe la posibilidad de un desentendimiento o el mismo trabajo ya “hecho” fracasará por la sola falta de colaboración entre equipos.

Advertisements

QA-Testing en SCRUM

Estimado tester del mundo,

Dando vueltas por “la red” veo repetidamente tus preguntas que reniegan de las metodologías Ágile, principalmente de  SCRUM:

“¿Cómo es posible que me digas que las iteraciones deben ser tan cortas? ¿si una iteración dura cuatro(4) semanas, tres (3), o dos (1), serán mitad de desarrollo y mitad de testing? ¿como se gestionan los defectos en tiempos tan acotados? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuar codificando los próximos incrementos, cuando corrigen los defectos? ¿cuando se los verifica?

NO ME QUEDAN CLARO LOS CICLOS!!!”

 

 

 

 

 

 

 

 

Como te habrás dado cuenta no obtuviste respuestas concretas ni en los mejores foros en tantos años de vida de Agile. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y te aseguro que en SCRUM no está estipulado como es el proceso de testing y calidad. Pero eso está bien por cuanto Scrum no es prescriptivo hasta el punto de definir “cómo hacer el trabajo” del equipo.

Leí varios libros sobre agilísmo y en todos ellos dicen “la calidad no se negocia”, pero en ninguno de ellos explican como evitan la merma de calidad con iteraciones tan cortas, o dicho de otra manera, como la obtienen y garantizan.

Alguna respuesta lógica podría ser:

  1. la intervención temprana del equipo de testing en el ámbito del proyecto.
    Esto quiere decir que hay que apartarse de la idea de esperar a que los requisitos estén maduros para tomar el documento de requerimientos y realizar el diseño de casos de pruebas por adelantado. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos (la cual es mayormente deseada en los negocios actuales), como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos (inclusive dentro del Sprint en curso).
    Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando la historia del usuario es expuesta al equipo. Nuestra fase de análisis comienza al mismo tiempo que para el equipo de desarrollo.
    Prontamente estaremos en la fase de diseño de las pruebas, donde también es extremadamente dificultoso ser veloces y preciso con iteraciones tan cortas. Es debido a ello que verás muy pocas propuestas serias para trabajar, aunque hoy en día se están abriendo paso…
  2. …herramientas colaborativas donde los encargados de indicar criterios de calidad, criterios de aceptación, modos de fallos, modos de prueba y demás, son todos los miembros del equipo e interesados.
    Esto es así dado a que la industria se dió cuenta que las mejores pruebas las hacen nuestros clientes y en todo el ciclo de vida de un requisito, los distintos tipos de analistas (negocios, requerimientos, sistemas, soporte, pruebas) representan algún aspecto de los clientes, aunque no todos.
    Estas herramientas ayudan a…
  3. … automatizar el proceso de desarrollo, donde la generación del requisito es el inicio natural, pero está acompañada su evolución por aspectos de la gestión de proyectos, tales como criticidad y priorización, estimaciones, asignaciones, control de cambios, control de estados, gestión de recursos, desvíos, replanificación y métricas. Todos elementos para sostener un curso razonable de la calidad del proceso y del proyecto.

En relación a tus preguntas te diría que:

  • Tres semana de desarrollo y uno de testing es posible, pero es mejor dejar de pensar en fases tan marcadas. Que opinas de colaborar todo el tiempo con lo que sabes, con lo que entiendes? Seguramente será más beneficioso para todos en términos de “descubrimiento de la feature” y/o “descubrimiento del product”, si te involucras y con tus opiniones generas mínimamente dudas.
    No considerarías a esto mismo TESTING?
  • ¿Tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional. Lo que puedes hacer sabiendo que cuentas con los recursos necesarios y adecuados (interación plena, coordinación y colaboración, pero principalmente la involucración), es gestionar de un modo colaborativo, es decir con la opinión de todos a tus sugerencias y propuestas de planificación, así probablemente ya no existirán más los clásicos problemas de “responsabilidad de un rol”, porque el resultado será algo funcional a todos y generado por todos.
  • Mientras se hace testing los desarrolladores codifican y mientras reportas fallos, ellos corrigen, al rato lo verificas. Para eso está el trabajo en equipo, solo hay que consensuarlo y organizarlo.
    Aunque está mal visto en los paradígmas tradicionales, los desarrolladores serán eventualmente los mejores testers; puedo asegurar que visto que es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo en general, no solo a QAs.
    En el mismo iterín, los desarrolladores también adoptan perspectivas diferentes que le ayudan en sus próximos enfoques para el desarrollo de las soluciones.
    Tiene sus aspectos negativos que se pueden ir puliendo. Por ejemplo un desarrollador que eventualmente pasa a testing, al detectar un defecto lo analizará desde el aspecto que más conoce. Querrá acceder a la base de datos y debaguear el código, y si fuera posible corregir y recompilar inmediatamente.
    Bueno, eso también lo hemos hecho, pero en otras situaciones, por ejemplo cuando se hace la verificación de las correcciones de defectos.
  • Particularmente yo me salto “el aparato comunicacional” y  digo al desarrollador: “master, tengo un defecto persistente. Que te parece mirarlo juntos y resolverlo de buenas a primera?”
  • La herramienta de gestión de defectos es como cualquier otra o como una planilla Excel si lo quisieras llevar a extremos precarios (habrá quienes me discutan lo de precario por Excel) y en ocaciones suele ser una importante barrera comunicacional burocrática, puesto a que nuestros defectos deben “atravezar el espacio-tiempo” mientras esperan ser atendidos.
  • Yo prefiero la interacción y la proactividad, inicialmente hablar con quien lidera el proyecto mostrando los defectos detectados, dándole información precisa y concisa, ayudándole a priorizar su resolución y a medir los impactos.
    También interactuo con los desarrolladores planteándoles un modo de uso, uno modo de fallo, un modo de prueba y ayudando a desarrollar una mejor solución.
  • Al respecto de cuando se solucionan los defectos, opino que no es buena cosa pasar a un próximo ciclo de desarrollo si no se cerró el anterior. De manera tal que decir que tenemos un incremento, va ligado de la frase “está hecho!!!”.
    Sin embargo en la vida real, notarás que es común iniciar la próxima iteración antes de corregir todos los defectos. Esto será válido si el incremento desarrollado fue aceptado por el cliente (Product Owner) aún a sabiendas de los defectos de la entrega.

Como elemento QA debes ser lo suficientemente analítico para iniciar el ciclo de vida de los proyectos, estudiando los requerimientos, detectando sus falencias, investigando modos de pruebas y modos de fallos. Mientras tanto deberás ir generando los criterios de aceptación funcional, generando un modelo de pruebas y si tuvieras el tiempo, los casos de pruebas.

También será menester gestionar los ambientes de pruebas netamente funcionales, aislados de accesos a bases de datos e IDEs de desarrollo, ya que lo que se pretende al menos en las pruebas de funcionalidad, es utilizar el sistema como lo haría nuestro cliente final, pero con mucho más rigor.

Entonces, como verás hay muchísima tela para cortar al respecto. Solo hemos “tocado por encima” algunos aspectos QA & Testing. Imagina si tenemos que hablar de pruebas unitarias, de componentes, de integración, métodos y técnicas…. en fin.

Lo cierto es que SCRUM es solo una metodología de gestión de proyectos, bien sinérgica, orientada a equipos maduros, autogestionados, con altísimos conocimientos técnicos, con gran dominio del negocio que genera los requerimientos y no pretende indicar como se hará el arte de desarrollar ni de probar, mucho menos se hará de conceptos para el mundo QA & Testing.

Para que esto no quede con un amargo sabor, te paso este enlace que podrá al menos darte una idea de como iniciar, pero te repito, aprende por tu cuenta pues no hay recetas.

Agile. La evolución de las metodologías tradicionales?

“Agile se ha vuelto tan popular entre los profesionales del software, que muchos se abstienen de criticarlo por miedo a ser etiquetados como “retrazados”, “de la vieja escuela”, o incluso “estúpido”.
Afortunadamente los profesionales IT con experiencia saben mejor y reconocen las limitaciones de Agile”

Así rezan las las declaraciones en un blog de Project Management, bastante conocido TheProjectManagmenteHut

Agile fue creado en gran parte en reacción al modelo predominante, WATERFALL, y en menor medida al resto de las tradicionales metodologías y aunque está en boca de todos y en manos de muchos, Agile hasta el día de hoy no ha demostrado ser superior a estas metodologías que le dieron razón y motivo para su existencia.
De hecho existe amplia y variada información que puede avalar tanto el éxito como el fracaso de las metodologías tradicionales, más su acoplamiento con los modelos y estándares de calidad reconocidos mundialmente y las culturas organizacionales más importantes del mundo, inclusive hablando de la industria del software.

Aunque no prentendo ser defensor de lo indefendible, ni “abogado del diablo” de Agile, es conveniente hacernos las siguientes preguntas:

  • cuando Agile es comparable con metodologías tradicionales?
  • cómo podemos combinar Agile con procesos tradicionales para abordar mejor una situación concreta?

Para responder a estas preguntas, es mejor reconocer las limitaciones de Agile

Un equipo de estrellas

Agile ha sido diseñado por experimentados y para experimentados.
Este es un aspecto a considerarse si se ha de intentar una incursión en las metodologías Agile, no como regla general, sino como un ítem de peso, sobre todo si se debe sostener el concepto de “equipo autogestionado”.

En lo personal y por la experiencia de participación en equipos Waterfall y en equipos en búsqueda de la agilidad, puedo decir que es mucho más dificil adaptarse a procesos Agile que a los procesos Waterfall, inclusive si se sigue un modelo de calidad como CMMI.

En los procesos Waterfall, el atributo de “equipos autogestionado” no es remarcable y aunque puede existir mucho trabajo individual, se hace bajo las premisas estrictas de la planificación, siguiendo los métodos y técnicas sugeridas y aceptadas por la organización. No se hace de otro modo o no lo estarías haciendo correctamente.

En estos procesos tradicionales, es cierto que existe también una gran carga administrativa pero en realidad no todos están afectados por ella y solo lleva una porción pequeña de tiempo y a muy baja complejidad realizarlas, principalmente para quienes no lideran los proyectos y solo rinden su progreso del día.

En los equipos Ágile, es un tanto más complicado la adaptación de las personas, siempre hablando de aquellas que no tienen la experiencia suficiente y el tren de trabajo disciplinado sin controles estrictos.
Aquí las entradas de algunos son fuertemente dependiente de las salidas de otros, no existe un trabajo individual o “individualista”, o no debería existir.

Las técnicas de gestión de tareas tradicionales pueden perder por completo su sentido y también debe existir una readaptación del mecanismo de estimación, de equilibrio de carga y del seguimiento. Los controles aunque parecieran ser menores, en realidad se incrementan por que el ciclo de vida en si mismo es mucho más corto y los cambios se presentan con mayor velocidad, pero parecieran ser de otra naturaleza y los resultados deben ser inmediatos, como también deben ser inmediatas las correcciones y a gran velocidad para que en la misma jornada laboral se tenga una aproximación del resultado, cuando no el resultado en si mismo.

El cáos está siempre al acecho…pero en que proyecto no lo está? La diferencia es la velocidad de detección de los inconvenientes, el análisis del problema y las soluciones, más su implementación, verificación y/o validación.
Entonces, preguntas simples pueden ser:

  • Tiene tu equipo el potencial para Agile?
  • Tienes el potencial para Agile?
  • Tienes la materia prima en las personas, para formar un equipo Agile?

Si la respuesta es “no” a algunas de estas preguntas, no significa que no puede transformase en Agile, solo quiere decir que puede haber algunos pasos intermedios a tomar antes de llegar allí.

Estos pasos suelen incluir la adaptación de la cultura del trabajo por equipos y la progresiva potenciación de los individuos, la formación y la contratación de las personas adecuadas.

Encaje con la cultura organizacional (los procesos son secundarios a la gente)

Habilitar el comportamiento Agile requiere de una gran dosis de libertad individual (no individualismo) y de equipo, que se traduce en una cruz funcional en constante adaptación del trabajo y funciones de conmutación, según sea necesario.

Se trata también de ajustar continuamente los procesos a fin de reflejar la situación actual. Más que nada, significa que los procesos son secundarios a la gente.

Otras organizaciones hacen incapié con estrechéz en los roles y responsabilidades, políticas y procesos, y han sido la clave de la supervivencia las mismas.

Aunque estas empresas estén bastante alejada de las dogmas de la agilidad, no es imposible que algunas unidades puedan realizar un trabajo diferenciado para experimentar, conocer y adaptar el nuevo paradigma.

Dado que la innovación es parte de la cultura de cualquier organización exitosa, entonces las personas que la integran tienen buenas habilidades y potencial para realizar “adaptaciones situacionales” y saltar de un modelo a otro.

Agile está restringido a equipos pequeños

  • Los equipos deben ser autogestionados, lo cual implica un orden eficiente emergente de un caos temporal. Este tipo de adopción del orden será mucho más prolongado en equipos grandes y perdería efectividad.
  • Los miembros del equipo de trabajo deben estar habilitados para comunicarse entre ellos espontáneamente, e inclusive con clientes y otros interesados en los proyectos.
  • La gestión diaria del equipo depende por completo de todo el equipo y no está centralizada en una sola persona. Es necesario el reconocimiento y visualización por parte de todo los miembros del equipo, de los cronogramas, tareas, cambios, impedimentos, etc.
  • Los miembros del equipo deben conocer exactamente que es lo que otros miembros están realizando, ayudar a otros que el proceso de su trabajo sea fácil, en forma colaborativa y sin un control centralizado.
  • Los miembros del equipo deben trabajar en la misma locación, facilitando el trabajo cara-a-cara y fortaleciendo los canales de comunicación inmediatos, sin tener las limitaciones típicas de las distancias, diferentes horarios e inclusive herramientas de gestión.

    Lo que se quiere expresar con estos puntos, es que equipos que superan un cierto límite en el número de integrantes (típicamente ocho) pierden eficiencia en las habilidades comunicacionales requeridas para equipos Agile. Así mismo la tarea de un Scrum Marster, se vería dificultada si tuviera que gestionar tareas, avances e inconvenientes de más cantidad de miembros y otros atributos como conocer las tareas y actividades entre todos los miembros se verían cada vez más en merma.

    Una forma de adaptación de equipos mucho más grandes, sería la división del mismo en equipos cross-funcionales más chicos y dinámicos.

    En este sentido necesariamente se deberá contar con un “nivel de gestión superior” que permita centralizar la información de todo el proyecto. Sin duda esto está lejos de ser puramente Agile, sino más bien una combinación de metodologías tradiciones y agilísmo.

    Hay que tener en cuenta también que si se divide un proyecto grande, se minimiza la dependencia arquitectónica del proyecto, para pasar de una medición del avance típicamente medido por su avances arquitectónicos, a una medición basada en la entrega de características funcionales. Esto da como resultado que la definición de “progreso” de Agile, deba ser adaptada a un nuevo contexto con un nivel de gestión superior.
    De nuevo la adaptación situacional “es un buen jugador”.

    Una gran limitación tiene que ver justamente con el especto comunicacional, dado que Agile promueve la comunicación cara-a-cara, con resoluciones dinámicas y proactivas, sin documentación más que la que oriente al desarrollo.

    El trámite comunicacional con otrás áreas es un trastorno que Agile debe aprender a dominar, puesto a que los modelos agilístas actuales exigen que otros interesados del proyecto deban siempre estar en la misma locación de trabajo, inclusive evitandose el traslado desde una oficina a otra para realizar simples consultas.

    La tecnología colaborativa y de multimedios, permiten actualmente realizar trabajos perfectamente coordinados y con esquemas de reuniones cara-a-cara, aunque virtualizadas, muy eficientes. Sin embargo esto no está bien aceptado en el mundo actual del agilísmo.

    Donde está mi metodología?

    Metodologías de desarrollo de software, tradicionalmente incluyen procesos como, Análisis, Arquitectura, Implementación, Gestión de Proyecto, Gestión de la Configuración, Gestión de Riesgos, Gestión de Cambios y una larga lista de procesos dependientes de Áreas de Procesos y Grupos de Procesos. Sin embargo, las metodologías

    Agile no promueven estos grupos de procesos y de hecho no los definen para sus marcos de trabajo, como tampoco definen un marco de gestión de proyectos.

    Esto puede verse justificado por el hecho de que las metodologías Agile tienen como insignia, que lo que demuestra y garantiza el proceso es el producto entregado y no la documentación que puedas presentarle a tu cliente.

    Las metodologías Agile delinean un marco conceptual, pero no explicitan de ninguna manera la exclusión de alguna de las prácticas tradicionales, aunque se asume que solo sobrevivirá lo estrictamente necesario para la obtención de los incrementos (entregables de software)

    Metodologías Agile completas parecen estar emergiendo y el soporte a la organización podrías ser total con adaptaciones sencillas de ambos metodologías, donde la substracción de las buenas prácticas de ambas, de como resultado el éxito y calidad total de la organización.

    Dado el contexto planteado es que me hago las siguientes preguntas para reflexionar:

    • ¿Existe la evolución de las metodologías Agiles?
    • ¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?
    • ¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?

    CMMI/Agile. Un híbrido que se viene – I

    He sido participe de certificaciones CMMI 4 en una empresa del Cluster Informático de Córdoba en Argentina y actualmente estoy como Responsable de Calidad y Mejora de Procesos en una empresa donde intentamos implantar metodologías ágiles.

    Conceptualmente son dos modelos distintos en cientos de aspectos, siendo imposible considerarse ágil al modelo CMMI.

    Quiero ser tajante en la diferenciación de esto, pues ahora se habla mucho de CMMI Agile y tal concepto no es más que un híbrido y no está formalizado. Esto es así, por que habría que decidir que parte de CMMI utilizamos y que proceso de los existentes tomaremos para recoger lo mejor de los ágiles.

    Notemos que los frameworks que la gran mayoría de las empresas ofrecen, se enfocan en uno u otro modelo.

    Pero vamos a ejemplos vivos. Bajo CMMI, siendo líder de testing, no tenía más participación que la ejecución de las pruebas, previo planning encapsulado y siguiendo una estricta ERS, no era partícipe a nivel horizontal del planning inicial y los criterios de calidad no se establecían por el líder de testing sino hasta que la documentación tuviera ya un alto grado de definición (documento maduro) e inclusive la participación de mi rol seguía siendo escueta y debía tomar los criterios establecidos por el arquitecto.

    Posteriormente, en CMMI, los cambios de requisitos no son aceptados con la amplia libertad con la que son aceptados en un proceso ágil y por lo general deben ser de bajo impacto para que ingresen en el catálogo de requisitos y siempre bajo un estricto circuito de análisis y revisiones de un comité de cambios, el cual está formado por una cantidad de personas y roles que en empresas que pueden seguir un proceso ágil, no hay.

    Las reuniones (ICE) en CMMI tienden a ser verticales y la participación de los roles transversales no es tan significativa como lo es en un proceso ágil, es decir que las decisiones normalmente pasan por una situación elitista donde desarrolladores y testers no tienen una grandilocuencia aceptada. Esto se contrapone con el precepto que indica que para ser ágil se debe tener un fuerte énfasis en las pruebas sobre la aplicación que se desarrolla y una continua integración de sus componentes.

    Con esto no pretendo decir que en CMMI no se tenga énfasis en las pruebas, pero se llega a ser tan robótico que la creatividad se destruye y proyecto tras proyecto tienes la misma documentación, los mismos estilos de pruebas, los mismos resultados y esto ya da para la desconfianza.

    En procesos ágiles debes anticiparte por eso participa todo el equipo de pruebas en las primeras reuniones donde se definen criterios de calidad, métodos de pruebas posibles, modos de fallos y otros elementos que puedan definir mejor la calidad de los productos. Recuerdo que trabajando bajo el proceso CMMI todo esto me venía llovido, y se suponía que el líder del testing era yo, un elemento SQA.

    Otro precepto que aleja CMMI de ágile (keep it simple).

    Uno más, documentar solo lo estrictamente necesario y centrarse en lo más crítico del producto, que es el código fuente.

    Por otro lado y para ir cerrando al menos este post, si un híbrido CMMI-Agile debe existir, ya sabemos que partes podemos tomar de CMMI según su nivel, pero… ¿que parte de Àgile tomamos? ¿Programación Extrema, Scrum, DSDM, Crystal Clear, …?

    Hablando de Framworks, hay algunos que ofrecen la posibilidad de trabajar con una metodología Ágile con documentación formal y que mediante un esfuerzo (considerable) se podría alcanzar un nivel CMMI-3 en el mejor de los casos, utilizando otra parte del mismo Framework. Es más complejo que eso.

    Pero aqui me acoplo a lo que algunos dicen por la red. Lo más importante que toda organización o persona debe tener en cuenta, es que no existe una metodología ideal para cualquier escenario en la que se aplique. La metodología de desarrollo que se seleccione, bien sea ágil o no, siempre dependerá directamente del equipo de trabajo, la cultura organizacional, lo cambiante del medio ambiente y la aceptación del usuario final.

    CMMI/Agile. Un híbrido que se viene – II

    Tratando de continuar con la saga CMMI/Ágile,  diré que creo que si tenemos en claro que CMMI es el modelo del proceso de desarrollo a seguir y Scrum es el modelo de gestión, entonces en teoría no habría discrepancias ni razones de frustración a la hora de intentar gestionar con Scrum mientras se siguen las prácticas sugeridas por CMMI.

    Sin embargo Scrum se plantea con un conjunto de prácticas bien definidas, que bien podrían no ser compatibles con las prácticas CMMI, las cuales desde un principio parecieron ser mejor adaptadas a RUP y las “gestiones pesadas” con prácticas al estilo PMBOOK.

    Habría que plantearse si eso de ligar a CMMI con RUP, PMI o procesos Waterfall, no es un fallo conceptual, puesto a que en realidad CMMI no plantea restricciones al respecto del modelo de gestión de los proyectos.

    En cierto aspecto, lo interesante es tratar de respetar toda la metodología de gestión Scrum y sus roles, mientras se respetan las exigencias de los roles CMMI.
    Creo que aquí es donde nos damos cuenta de la necesidad de nuevos significados para las cosas y reestructuración de los modelos, si es que los mismos debieran sostener su vigencia.

    Por ejemplo yo partiría los roles en dos capas:

    • una capa de nivel “No Operativa” o administrativa donde por ejemplo, el Product Owner sería todo el Stakeholder de capa superior de los roles exigidos por CMMI (Gerencia, Gerencia Senior, Sponsor, Representante del Cliente, y Gerente QA)
    • una capa “Operativa” donde encontraríamos por ejemplo, al Team (Líder de Proyecto, Arquitecto de Sistemas, Líder de Testing, Testers, Desarrolladores) todos gestionados con Scrum, donde Scrum Master sería necesariamente el Líder de Proyectos.

    Ahora bien, solo estamos hablando de gestionar roles, pero habría que profundizar en las similitudes y diferencias de las prácticas sugeridas o impuestas para cada rol y PA por cada modelo.

    A mi entender por más que se gestione con Scrum, el proceso ya no sería puramente Ágile ni puramente RUP sino uno de los “hibridos que se vienen”.

    Madurez para reconocer riesgos y trabajar con ellos

    Según mis experiencias en el entorno de los proyectos de software, no he vivido un solo proyecto que no haya sufrido modificaciones en el alcance del mismo. Estoy seguro que en la mayoría de las situaciones ese alcance se ve alterado por cambios en los requerimientos en si mismo, ya sea por que detectaron nuevos, se modificaron parámetros restrictivos o nuevos impactos son visibles en fases posteriores del proyecto, entre otros aspectos.
    Esto nos lleva a darnos cuenta que es posible que las estrategias de gestión deban cambiar en el transcurso del proyecto, lo que quizás no implique cambiar el estilo de gestión.
    Sin embargo para minimizar los cambios en la gestión, es que se realizan análisis de riesgos, priorizando los mismos y estimando cual es la chance de convertirse en realidad y cuales serían las estrategias que se aplicarían para aceptarlos, mitigarlos o minimizarlos.
    Es decir que cómo se enfrenta el equipo del proyecto a los cambios, tiene mucho que ver con la madurez para reconocer riesgos y trabajar con ellos.
    Actualmente se plantea mucho el uso de metodologías Ágiles, donde lo que se pretende es manejar un poco mejor la variación del alcance, definiendo entregables de menor tamaño, en tiempos relativamente chicos y donde cualquier modificación del alcance se gestiona como un “incremento” del requerimiento y eso exige la repriorización del
    entregable completo, donde es posible que se deba negociar la introducción a la iteración actual, de “algo de lo nuevo” quitando normalmente “algo de lo viejo” para pasarlo a una nueva iteración o pasándolo al final de la cola.
    Yo pude ver que este tipo de manejo se puede hacer sin que la organización necesariamente esté involucrada en modelos de gestión agilístas, pero si se debe estár insertos en un estilo flexible de gestión y negociación permanente, donde invariablemente el alcance varía y el tiempo también, posiblemente no los costos.
    Pude ver que este tipo de gestión permite generar mayor valor agregado en cada iteración (es notable con solo invocar el interés del cliente) y es posible adaptarse rápido a los cambios. Pero quiero que quede claro que sin gestión de cambio, las adaptaciones apropiadas no son posibles o representan en si mismo un riesgo mayor que los riesgos detectados.
    Quiero que tengan en cuenta algo para pensar. En las metodologías Waterfall (tradicionales) la triple restricción se presenta normalmente de la siguiente manera: 1-Requisitos (fijo), 2-Tiempo (estimado), 3-Recursos (estimado). Siguiendo ésta línea es posible que nuestras restricciones sean muy fuertes en el sentido de que los requisitos son plenamente mandatorios e inclusive el tiempo y es por eso que los PM deben a partir de allí planificar los recursos y “jugar” con las restricciones que este último punto les impone, en relación al carácter mandatorio de los otro dos.
    En las metodologías Ágile, la triple restricción se presenta de la siguiente manera: 1-Recursos (fijo), 2-Tiempo (fijo), 3-Características (estimado). Siendo imperativo conocer de antemano cuales son sus recursos, en segunda instancia cual es el tiempo de respuesta esperado y así decidir que características priorizar para cada iteración, adquiriendo compromisos solo en función de poder cumplir según las restricciones de los puntos 1 y 2. Ahora “el juego” se traslada al punto 3 nuevamente, pero el punto 3 ahora es otro.

    Saludos,
    Javo.

    ¡No existe el vamos a probar!

    Las TIC y Software Factory de Argentina y Latinoamérica en general, comenzaron a entrar en la burbuja ascendente donde los servicios son requeridos desde todo el mundo, principalmente por la calidad de los profesionales, el carácter innovador y por supuesto los menores costos operativos.
    Es por este motivo que se habrán enterado de la gran escalada de organizaciones que están en proceso de certificaciones y/o evaluaciones CMMI, ISO entre otras o que bien ya certificaron. Sin embargo estas evaluaciones y certificaciones no garantizan la productividad, solo un aspecto de la misma.
    Las necesidades de actualización del sector son muchas y permanente, pero el movimiento agilísta se ha tornado más que interesante por que ofrece beneficios directos a aquellos que aprenden a manejar sus conceptos, re definir sus estructuras organizacionales o al menos en ciertas áreas operativas, integrar herramientas de apoyo y principalmente modificar sus paradigmas de gestión.
    Los beneficios del agilísmo bien pueden ser utilizados por cualquier tipo de organización pues apunta a duplicar, triplicar, o más, la velocidad productiva. Sin embargo las metodologías Ágiles son muy difundidas en el mercado SSI (Servicios Informáticos y Software) principalmente por que las metodologías de gestión tradicionales no dieron hasta ahora respuestas a la velocidad que el mercado actual requiere.
    Pero es en extremo importante el aporte de gestores en metodologías tradicionales, principalmente por el cúmulo en años y proyectos que los mismos de seguro, tienen.
    Muchos intentan separar a la gente, dividiéndolas en Agilístas y Tradicionalistas pero yo creo que hay que apuntar a unirlas y tamizar los atributos de valor que le brindan ambos tipos de experiencia al mercado SSI y TIC.
    Jornadas Ágiles de actualización profesional, serían bien utilizadas por gerentes de sistemas, líderes de equipos, desarrolladores y probadores de software y otros líderes de áreas transversales como Marketing y Ventas, por mencionar algunas. Esto es así por que tal como te menciono líneas arriba, se trata de un paradigma que necesariamente para ser exitoso implica un compromiso de áreas sensibles de una organización y la adaptación tanto de los modelos Ágiles a los Procesos Organizacionales como de las organizaciones a los modelos, y sin eso … ¡mejor olvidarlo!. ¡No existe el vamos a probar!
    Notarán quizás que las jornadas Ágiles en Buenos Aires ofrecen la participación en seminarios de actualización, prácticas y certificaciones profesionales (en solo dos días??? muy poco serio) las cuales son dictadas por referentes de primer nivel en el mundo.
    No estoy de acuerdo en que a Córdoba se deban traer tales exponentes, ni ofrecer certificaciones profesionales sacadas de la galera, debido a que existen exponentes locales que ya están haciendo este tipo de difusiones y también podrían aportar un buen servicio.
    Si me interesan prácticas, talleres, seminarios, cursos y las pagaría. De hecho preferiría variedad a solo una o dos ópticas.
    Hay que entender que Latinoamérica en general se encuentra en pañales en lo que se refiere a este tipo de movimientos y aún cuando pudiera existir gente certificada (por ejemplo Scrum Masters) no existen profesionales con experiencia, por el solo hecho de que la experiencia la están haciendo ahora mismo. Allí veo la veta.

    Saludos,
    Javo.