Metodologías de Desarrollo

Equipo QA – El recurso oculto

Posted on 4 marzo 2009. Filed under: Calidad del Software, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Procesos Ágile, Recursos Humanos, Roles, Trabajo en Equipo, Waterfall |

¿Que es lo primero que viene a mente cuando mencionamos Ingeniero QA o Tester?

Hay quienes piensan y asumen que las actividades típicas del Tester, las puede llevar a cabo cualquiera, ya sea utilizando procesos de desarrollos tradicionales o Agiles.

La razón puede estar fundada en el concepto erróneo de que cualquier persona puede determinar si una aplicación funciona o no. Sin embargo con este pensamiento se deja de lado la naturaleza destructiva de las actividades de Testing y el no centrarse en el funcionamiento correcto, sino en los aspectos fallidos del software.

También se está asumiendo que el aseguramiento de calidad es solo cumplir con actividades de Testing. Nada más lejos de la realidad.

En las metodologías tradicionales de desarrollo de software, se tiene especial cuidado con la planificación de las pruebas, de modo tal que esta sea acorde a la definición temprana de los requerimientos (obviando las verificaciones y validaciones QA) y en base a un aprendizaje oportuno de como debería funcionar el sistema, de modo tal que según lo planificado, en ciclos de pruebas de sistemas se valide la completitud y correctitud del sistema en base a tales requisitos.

Como contrapartida, se supone un Plan de Pruebas rígido, con muy baja adaptabilidad al cambios de requerimientos y a aparición de nuevos requisitos.

En la vereda del frente estarían las metodologías Agiles, donde la planificación del Testing debe ser adaptativa, acorde a la velocidad de cambios en los requerimientos del sistema, lo cual puede presumir una mayor participación de los miembros QA en etapas tempranas del proceso de desarrollo, inclusive en la misma formación de los requisitos, su analisis y estimaciones, lo cual comprensiblemente podría ser deseable.

Esto es en resumen como se comporta el Testing en metodologías no Agiles.

De este modo, conceptualmente la participación del QA cambia de un rol de “full-control” a “full-partner” del resto de los miembros del equipo.

Esta concepción permite revalorizar los roles QA debido al uso petenciado de los mismos, aportando un valor más estratégico para las necesidades de los negocios que atienden los sistemas que se construyen.

Los Testers, podrían ser utilizados a su máxima potencia, con actividades operativas que ayudan a los desarrolladores a promover la generación de soluciones más eficientes y en instancias tempranas.

A su vez los miembros del equipo QA podrían ser fuentes de información constante referido al comportamiento del sistema en construcción, permitiendo adelantarnos a cambios en los requerimientos, requerimientos mal concebidos o desarrollados en modo no deseado, promover mejoras y una lista larga de etcs. que en definitiva orientan a traves de todo el ciclo de vida del proyecto.

Pero no confundamos esta revalorización del personal QA tratando de abarrotarla detrás de las metodologías Agiles, ya que el concepto puede ser aplicado a cualquier proceso de desarrollo. De hecho, las metodologías Agiles no han planteado este paradigma ni es algo que les pertenece, aún cuando se utilice la terminología “Testing Agile”. Inclusive muchos “pseudoagilístas” consideran a un Tester como a cualquier otro recurso QA, un recurso de menos rango y hasta despreciable para la organización.

QA se da cuenta de la evolución por la misma adaptación que debió sufrir acorde a la velocidad de respuesta que requieren los procesos de desarrollos actuales.

Asumamos que un cambio de paradigma QA es posible aún dentro de procesos tradicionales. Aún así, el cambio no puede gestarse por si solo, debe surgir de un cambio en el paradígma organizacional.

Fuentes de inspiración:
Testers: The hidden resource

Anuncios
Leer entrada completa | Make a Comment ( Comentarios desactivados en Equipo QA – El recurso oculto )

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

Posted on 9 febrero 2009. Filed under: Empresa, Gestión de Equipos, Gestión de Proyectos de Software, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Procesos Ágile, Project Management, Trabajo en Equipo, Uncategorized, Waterfall | Etiquetas: , , , , , , , , , , |

“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?
    Leer entrada completa | Make a Comment ( 3 so far )

    Agile Open Córdoba – El EVENTO que se viene en Argentina

    Posted on 6 febrero 2009. Filed under: Gestión de Equipos, Gestión de Proyectos de Software, Ingeniería del Software, Procesos Ágile, Trabajo en Equipo |

    Agile Open Córdoba 2009

    ¡Ya podés inscribirte en Agile Open Córdoba 2009!

    “¿Y por qué querrías hacerlo?”, te preguntarás.

    • Porque nos juntaremos 100 personas con muchas ganas de implementar metodologías ágiles en nuestros trabajos
    • Porque tu participación será activa, con el formato Open Space
    • Porque lo organizamos de manera tal que te permita asistir sin depender de otros (gratuito, fuera del horario laboral, en un lugar de fácil acceso)

    Fecha: 17 y 18 de abril, 2009

    Horarios (a confirmar)
    Viernes  17 de 18:30 a 21:00 Hs.
    Sábado 18 de 10:00 a 18:00 Hs.

    Tema: Implementando Metodologías Ágiles

    Sede:
    Colegio Universitario IES Siglo 21
    Buenos Aires 563
    SUM – Salón de Usos Múltiples (a confirmar)

    Contacto: por consultas o sponsoreo, comunicarse con eventos en agiles.org

    Además, y dentro del marco de este evento, se dictará por primera vez en Córdoba el curso de Certificación Scrum Master (CSM), con reconocimiento oficial de la Scrum Alliance.
    Ud. puede registrarse para realizar este curso aquí.

    Leer entrada completa | Make a Comment ( 2 so far )

    QA & Testing en SCRUM

    Posted on 24 enero 2009. Filed under: Actitudes, Aptitudes, Calidad del Software, Comunicación, Entorno de Pruebas, Gestión de Equipos, Gestión de Proyectos de Software, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Organización del Trabajo Personal, Procesos Ágile, Project Management, Soporte Colaborativo, Testing, Trabajo en Equipo | Etiquetas: , , , , , , |

    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) serán de desarrollo y una (1) de testing? ¿como se gestionan los defectos? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuan 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 estos últimos dos años. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y me arriesgo a decirte que en SCRUM no está bien estipulado como es el proceso de testing y calidad.
    Leí varios libro 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. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos, como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos.
      Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando el requerimiento es expuesto 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. Debes contar con los recursos necesarios y adecuados. El problema aquí nuevamente es la planificación del testing y la calidad.
      ¿tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional.
    • Mientras se hace testing los desarrolladores codifican. Para eso están, salvo que también sean testers, ya que aunque está mal visto en los paradígmas tradicionales, puedo asegurar que visto con un pensamiento lateral es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo QA.
      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.

    Saludos,
    Javo.

    Leer entrada completa | Make a Comment ( 2 so far )

    Predictivo contra adaptativo?

    Posted on 20 enero 2009. Filed under: CMMI, Gestión de Proyectos de Software, Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile, Project Management, Waterfall |

    CMMI indica que una organización evaluada en nivel 3, es una organización con proceso DEFINIDO, es decir que la organización cuenta con una base de conocimientos que le permite gestionar proyectos cuyas decisiones sobre alternativas de solución técnica, tiene una tendencia histórica organizacional.

    Una organización cuyo proceso está definido, indica a su vez que ese proceso esta sustentado por documentación reutilizable, prácticas repetibles y métricas objetivas para la consecución de resultados concretos.

    Poder predecir es algo que todo administrador de proyectos desea y debe hacer. Entonces, ¿por que negarnos a los elementos que facilitan y favorecen tal característica primordial de maduréz en la organización?

    PREDECIR es el primer nombre del administrador de proyectos.

    Predecir no es perder la capacidad adaptativa, no significa evitar la introducción de cambios en los requisitos, ni evitar que nuevos requisitos surgan, tampoco es ser rígido con una replanificación.

    Claro no es tan simple ser predictivo, pero mucho menos lo es ser adaptativos. De hecho, pienso que no se puede ser adaptativo sin ser predictivo o más bien serás intuitivo, pero mejor atenerse a los resultados fortuitos.

    Sin duda el esfuerzo del cambio es superior, pues la organización deberá adquirir conocimientos sobre las prácticas para los procesos que hay que implantar:

    * Desarrollo de requisitos * Solución Técnica * Integración del producto * Verificación * Validación * Desarrollo y mejora de los procesos de la organización * Definición de los procesos de la organización * Planificación de la formación * Gestión de riesgos * Análisis y resolución de toma de decisiones.

    Ahora, ¿alguno de ustedes ve un proceso de los que menciona CMMI para el nivel 3, diferente a los procesos que se utilizaría en Ágile?

    Leer entrada completa | Make a Comment ( 1 so far )

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

    Posted on 23 diciembre 2008. Filed under: Calidad del Software, CMMI, Gestión de Proyectos de Software, Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Testing, Trabajo en Equipo | Etiquetas: , , , |

    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.

    Leer entrada completa | Make a Comment ( 4 so far )

    Quien es quien – I

    Posted on 22 diciembre 2008. Filed under: Actitudes, Aptitudes, Habilidades Personales, Metodologías de Desarrollo, Opinión, Recursos Humanos, Roles | Etiquetas: , , , , , |

    Pensando los Roles y Competencias para definir nuestro proceso de trabajo

    Las metodologías de desarrollo de software suelen establecer roles y delimitar sus competencias,  remarcar sus responsabilidad, indicar interdependencias, definir elementos de entrada-salida y proponer la repetición constante de estos ítems, con variantes que le dan alguna particularidad a los distintos procesos.

    El objetivo es inicialmente presentarse de manera clara al publico usuario, como un mecanismo  estable, controlable, medible y repetible, que garantice en mayor o menor medida, el éxito de los proyectos permitiéndole llegar a su fin, con el uso de la secuencialidad propuesta.

    Suele suceder que los modelos parecieran no tener en cuenta al área QA y Testing como un área independiente dentro los proyectos de productos/servicios, que genera su propio proyecto donde conviven productos/servicios que dan soporte al proyecto matríz.

    Tal es así que las competencias QA y Testing no son tan bien definidas  y explicadas como las compentecias de otros roles, en la mayoría de los procesos. Y aunque algunos presentan detalles excesivos, quizás no encuadran correctamente a los roles QA.

    Independientemente del proceso que se intente aplicar y su definición de roles y competencias, sugiero que las organizaciones consideren la aplicación de roles, pero justificado principalmente por el enfoque y especialización que exista o se desee.

    Por ejemplo, la existencia de Líderes de Proyectos que a su vez sean verdaderos especialístas en los negocios que generan los productos que lideran.

    Los Arquitectos de Sistema los mejores diseñadores y programadores, sobre todo líder especialista en “los aspectos íntimos de los sistemas”.

    El Líder QA de perfil analítico transversal y el principal
    “entrenado” en el uso de los productos en prácticamente todos los
    niveles de los sistemas. También uno de los probadores más
    importantes de la organización, guía de pruebas en todas las fases de revisión.

    El equipo de testing  con competencias técnicas variadas y acabadas, conocedores de técnicas y métodos de pruebas, pero con grandes atributos actitudinales.

    Las principales potencias de un equipo QA bien conformado quizás son:
    capacidad analítica en el sentido transversal a lo que se supone como
    la mejora solución técnica, la obsesión por demostrar que el sistema
    tiene defectos, orientación bien marcada a las pruebas exploratorias,
    proactividad y comunicación eficiente, entrenamiento anticipado en el
    uso del sistema, énfasis en detectar debilidades en los requerimientos, énfasis en reconocer y entender por que y para que existe cada requerimiento, capacidad de proponer nuevas alternativas de uso, control del tiempo y el sentido de fin de fases.

    Creo que habilidades de esta naturaleza no solo en los roles QA, sino en otros que reciben productos de fases anteriores y las destilan a fases posteriores en los procesos de desarrollo, ayudan a definir un proceso bien limpio y delimitado para elaborar, planificar, seguir y finalizar los proyectos.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Quien es quien – I )

    …mejor utiliza los atajos.

    Posted on 22 diciembre 2008. Filed under: Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Procesos Ágile, Waterfall |

    Muchas veces critiqué falta de un proceso bien definido en las organizaciones de desarrollo de software y fui más enfático con aquellos que con más penas que gloria, se embarcan en constantes intentos de prueba y error para intentar establecer su modelo y se niegan a por lo menos conocer las distintas alternativas que existen.

    No es útil solo imaginar, utilizar ideas vagamente relacionadas, “probar para ver que pasa”, imponer sin consenso, esperar que el resultado de tu proyecto sea el feedback, hacer “borrón y cuenta nueva”, buscar culpables, castigar, ser irreflexivo, someter, monologar, confundir.

    Creo que está muy bien “no casarse” con ningún modelo en particular y perseverar en tangibilizar un proceso que bien le sirva a toda la organización y con el, obtener los mejores beneficios. Pero mejor utiliza los atajos.

    Antes de cualquier emprendimiento, quienes quieren hacer algo bien se introducen en los conceptos, desmenuzan la información que reciben, analizan los contextos de uso y sus aplicaciones, filtran lo no útil, bosquejan, proponen, discuten y buscan concenso, piensan y planifican, ejecutan y demuestran, controlan y corrigen, y así en ciclos de constante perfeccionamiento.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en …mejor utiliza los atajos. )

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

    Posted on 22 diciembre 2008. Filed under: CMMI, Gestión de Proyectos de Software, Herramientas, Métodos y Procesos, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Procesos Ágile, Project Management | Etiquetas: , , , , |

    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”.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en CMMI/Agile. Un híbrido que se viene – II )

    El desarrollo de software Ágile y la automatización

    Posted on 11 diciembre 2008. Filed under: Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile, Pruebas Unitarias | Etiquetas: , , , |

    todo lo que he leído hasta el momento da claros inidicios de que la automatización es un hecho en los entornos de desarrollo Ágiles. Tal es así que pareciera que no existe programación sin Pruebas Unitarias o sin Intengración Contínua, ni pruebas de sistemas sin automatización, inclusive si las mismas fueran manuales.
    También se está hablando a pleno de los ambientes colaborativos y automáticos para la generación de requerimientos.
    Por experiencia puedo decir que en muchas fabricas de software no se utilizan tales herramientas y se utilizan procedimientos y técnicas “artesanales”.

    Inclusive siguiendo metodologías de desarrollo Ágile para la gestión, tal como Scrum, no se ejecutan otras prácticas Ágile. 

    Cual es el límite para decir que somos verdaderamente Ágile o que no lo somos?

    Mi amigo Juan Carlos Sanchez Miralba, nos da desde XING una respuesta con un punto de vista completo y claro:
    Primero debemos diferenciar entre modelo de desarrollo y de gestión. El modelo de gestión puede ser Scrum sin desarrollar utilizando metodologías ágiles.

    Si miramos algunos Principios Ágile no forzosamente debemos automatizar todos los procesos. Por lo tanto podríamos aplicar perfectamente el manifesto agile a un proceso de desarrollo cascada iterativo en el que cada iteración sea de una o do semanas como mucho.

    No obstante la metodología de programación extrema XP involucran prácticas y herramientas de test unitario e integración continua, las cuales son excelentes para dar soporte a un verdadero proceso de desarrollo Ágile. 
    Aquí la automatización de las pruebas y la integración contínua son inobjetables.

    Otras Metodologías Ágile no hacen referencias directas a la automatización.

    Básicamente aplicando dos principios:
    1- Encontrar errores antes en el ciclo de vida es más barato –> Inspección de código y test unitario.
    2- Cuantos menos cambios antes del test fácil es la solución –> Integración continua / test automatico de integración.

    podemos decir que son dos buenos pilares en los que asentar un desarrollo ágil.

    Gracias Juan Carlos
    https://www.xing.com/app/forum?op=showarticles;id=16233872;articleid=16254918#16254918

    Leer entrada completa | Make a Comment ( Comentarios desactivados en El desarrollo de software Ágile y la automatización )

    Está hecho y lo voy a comprobar

    Posted on 18 noviembre 2008. Filed under: Comunicación, Metodologías de Desarrollo, Testing, Trabajo en Equipo |

    No confundir los hitos de pruebas

    La revisión par de componentes intenta validar la completitud y correctitud de los componentes generados, es decir marcar el hito de finalización de la construcción por componentes. De ninguna manera representa una integración de los mismos con otras unidades, esto lo sabemos por la experiencia del momento, por que cada uno supo el alcance y los límites de su caso de uso y aunque hubo cierta integración necesaria con otros componentes, los fallos imputados solo atañen al componente en revisión.

    Todos defienden sus implementaciones.

    Es por eso importante finalizar y avisar al par revisor tanto como al líder de desarrollo. Este aviso implica principalmente a los conceptos de, “está hecho” (el famoso “done”) y “lo voy a comprobar”. Pasado este hito, ya estamos asegurados para muchas cosas más como, cambios de funcionalidad, mejoras de funcionalidad, acoplamientos exitosos, seguir con otras cosas diferentes, etc. pero todo estará dentro de un “marco de generación de valor agregado”.

    Continuar sin haber validado el componente implica un riesgo importante para la integración y normalmente debemos volver atrás con un cúmulo importante de retrabajo. También implica que la prueba deja de ser de componente y presentaría un sesgo hacia pruebas de sistemas, el decir con una versión del aplicativo el cual ya sin dudas tendría N cantidad de fallos indeseados.

    Es bueno saber para que sirve cada cosa y no confundir los hitos, sabiendo que un momento se desea asegurar los componentes, en otro momento la integración modular y en otro el sistema.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Está hecho y lo voy a comprobar )

    Madurez para reconocer riesgos y trabajar con ellos

    Posted on 7 octubre 2008. Filed under: Gestión de Proyectos de Software, Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile, Project Management, Trabajo en Equipo, Waterfall | Etiquetas: , , , , |

    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.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Madurez para reconocer riesgos y trabajar con ellos )

    The Chaos Report

    Posted on 16 septiembre 2008. Filed under: Calidad del Software, Gestión de Proyectos de Software, Metodologías de Desarrollo, Project Management | Etiquetas: , , , , , , |

    “Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único, con restricciones de plazo y de costo”


    Sobre la base de los resultados de la dirección de proyectos en compañías de informática se realizo el estudio “The Chaos Report” (Standish Group) que observa de todos los proyectos estudiados, qué cantidad fueron finalizados exitosamente y cuántos no llegaron a cumplir con algunos o todos los objetivos. Y lo más interesante es que hace un análisis de los motivos que originaron esos “fracasos”, permitiéndonos poner foco en ellos al dirigir nuevos proyectos.

    Según este estudio del total de proyectos evaluados:
    El 16% son completados con el alcance esperado, en el tiempo planificado y dentro del presupuesto asignado.
    El 53% de los proyectos son completados con menor alcance, y/o sobrecosto y/o fuera de término.
    El 31% de los proyectos son cancelados antes de terminar.

    Del total de proyectos que se completan:
    El 70% de los proyectos terminan fuera de plazo.
    El 54% de los proyectos sufren sobrecostos.
    El 66% de los proyectos no son considerados exitosos.
    El 30% de los proyectos son cancelados antes de terminar

    Principales factores de éxito:
    1 – Involucramiento del usuario 15.9 %
    2 – Apoyo de la Gerencia 13.0 %
    3 – Enunciado claro de los requerimientos 9.6 %
    4 – Planeamiento adecuado 8.2 %
    5 – Expectativas realistas 7.7 %
    6 – Hitos intermedios 7.7 %
    7 – RRHH competentes 7.2 %

    Principales factores de fracaso:
    1 – Requerimientos incompletos 13.1 %
    2 – Falta de involucramiento del usuario 12.4 %
    3 – Falta de recursos 10.6 %
    4 – Expectativas no realistas 9.9 %
    5 – Expectativas realistas 9.3 %
    6 – Falta de apoyo de la Gerencia 8.7 %
    7 – Requerimientos cambiantes 8.1 %

    Leer entrada completa | Make a Comment ( 4 so far )

    Testing Exploratorio – Cuando faltan elementos en las evidencias de resolución

    Posted on 16 septiembre 2008. Filed under: Calidad del Software, Ingeniería del Software, Procesos Ágile, Pruebas de Integración, Pruebas Unitarias, Resolución de problemas, Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo |

    Las verificaciones funcionales tuvieron una tónica un poco desagradable el día de hoy, ya que para la ejecución de las pruebas de sistemas requirieron mucho esfuerzo en el levantamiento de elementos que me permitan formar un concepto de cómo realizar el Testing y que resultados esperar.

    La mayoría de las verificaciones no pudieron ser ejecutados por aspectos relacionados a elementos faltantes del despliegue, los cuales no son mencionados en ninguna de las evidencias de resolución. Sin embargo, al revisar la evidencia de cada una de las resoluciones encuentro que tales evidencias no tienen elementos que permitan formar con cierta normalidad los conceptos de Testing Funcional.

    De esta manera solo se consigue dilatar los tiempos de Testing, se tienen más rechazos de soluciones (inclusive por desentendimiento), no cumplir con la entrega planificada y el re trabajo que implica en todas las áreas involucradas. Ni hablar si se aprueba un resolución y luego la rechazan en Despliegue al detectarla como fallida.

    Creo que las evidencias tienen que tener el foco funcional que hace falta, principalmente por que en situaciones como la de hoy, se hace “testing forzado”, sin planificación, sin anticipación.
    Las evidencias no deberían simplemente tener las sentencias SQL que se usan o los valores booleanos que adoptan las variables o los nombres de formularios ocultos, entre otros elementos de bajo nivel, que muchas veces es interpretable y sirve solo en el contexto adecuado, pero fuera de el no es de utilidad.

    Tal como mencioné varias veces, estoy convencido que para ciertos artefactos, no es necesario intentar recurrir a prácticas de Pruebas Unitarias sin el framework adecuado, pero se pueden plantear juegos de pruebas de caja negra, en la cual es posible definir aspectos relacionado a las interfaces, totalizadores, los comandos de acción, etc.

    Dicho de otra manera, las pruebas del desarrollador tal vez deberían declarar el juego mínimo de pruebas de funcionales (caja negra) que indiquen un estado previo, el proceso ejecutado y el estado posterior del juego de datos.

    O en su defecto hay que darnos el tiempo para que luego de notificada la resolución, se asuma “un tiempo de estudio” para generar los conceptos de pruebas funcionales, pero así no se garantiza nada.

    Por otro lado, el día de hoy se vio una debilidad en el traspaso al darnos cuenta que falta la especificación de la corrida de agentes y también el momento de la corrida, lo cual parece ser estratégico para que no se presenten los fallos que se presentaron en Testing.

    En definitiva me doy cuenta de la debilidad que hay en los traspasos y posiblemente tenga que ver con la estrategia que se deba plantear antes de iniciar las resoluciones.

    A mi me sigue costando enterarme con anticipación de que bloques serán entregados y según la experiencia que tengo en nuestra interacción cotidiana (Desarrollo – Testing / Testing – Desarrollo), aún las correcciones más sencillas nos cuesta un esfuerzo muy importante tanto a Desarrollo como a Testing y las verificaciones se demoran de manera no convenientemente, como es lógico.

    Si estos elementos se siguen presentando con tanta dificultad, las estimaciones del esfuerzo de Testing van a quedar subestimadas por la necesidad de estudio de los Testers para cada uno de los artefactos de software, siempre que se efectúen pruebas exploratorias.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Testing Exploratorio – Cuando faltan elementos en las evidencias de resolución )

    Gestión de Proyectos

    Posted on 5 septiembre 2008. Filed under: Metodologías de Desarrollo, Procesos Ágile, Waterfall | Etiquetas: , , , , , |

    Prácticas del PMBOK relacionadas a prácticas ÁgilesRecientemente lancé el debate en LINKEDIN en el grupo IAAP sobre cuan aplicable son las prácticas de PMI a las metodologías Ágiles. El volúmen de respuesta no fue alto pero los que quisieron aportar lo hicieron bien, y de allí rescato una lectura interesante:
    Relating PMBOK Practices to Agile Practices

    Básicamente en este artículo la autora explica como se ha relacionado de manera indebida a los procesos Waterfall con las prácticas PMI, al igual que se lo ha relacionado al CMMI de manera injustificada, cuando en realidad PMBOK es solo una guía de “mejores prácticas” y debe ser utilizado con criterio organizacional cuando se implementen sus prácticas.
    Por otro lado reprende a los practicantes de metodologías agilístas al tildarlos de “promotores del Cowboy Coding” lo cual conlleva a una situación de caos indeseada para cualquier proyecto.
    Según las observaciones de la autora, si las metodologías Ágiles son seguidas con diciplina y rigor, cumplen con el modelo CMMI y las prácticas PMBOK, tal cual como lo haría una metodología Waterfall. Indica también que más allá de lo visible, la única diferencia entre proyectos bajo controles de planificación PMI y controles de equipos autogestionados, es el momento y la manera en que se ejecutan las prácticas, las cuales son símiles difiriendo más que nada en el léxico pero no en su escencia.

    Al respecto del core de cualquier proceso a ser administrado, en el gráfico de arriba puede visualizarse el mapeo entre las convenciones PMBOK y APM o Agile Project Management Framework.
    La autora explica que existen “Seis Claves de Gestión” definidas en el PMBOK y que merecen especial atención y las cuales tienen sus relaciones en las metodologías Ágiles, aunque se diferencian en su implementación:

    • Gestión de la Integración del Proyecto
    • Ámbito de Aplicación del Proyecto de Gestión de Proyecto
    • Gestión del Tiempo
    • Gestión de la Calidad
    • Gestión de Riesgos
    • Gestión de Recursos Humanos

    Los invito a ver el artículo y sus ampliaciones y a opinar en mi blog.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Gestión de Proyectos )

    La importancia de las Certificaciones y evaluaciones de los SSI

    Posted on 31 agosto 2008. Filed under: Calidad del Software, Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile | Etiquetas: , , , , |

    Desde siempre los profesionales que prestamos servicios informáticos nos vimos en la necesidad de constante evolución y así cada vez más, se presentan situaciones en las que un estudiante universitario o terciario o idóneo, logra una certificación que lo acerca a una mejor posición a la hora de prestar sus servicios, mucho antes de finalizar su educación formalista.
    En vista del auge que tienen las empresas dedicadas al SSI (Software y Servicios Informáticos) no es sorpresa que se coticen mejor aquellos RRHH que suman certificaciones y otras capacitaciones año a año. Tampoco es sorpresa que las empresas necesiten certificar sus procesos y/o productos y de esa manera acceder a mejores oportunidades de negocio en el mundo globalizado.
    Muchas empresas accedieron a importantes logros a nivel de evaluaciones CMMI o certificaciones ISO, entre otras calificaciones y debo decir que ya es notable la escalada de proyectos internacionales que recaudan sus agendas de trabajo y la cartera de cliente se globaliza aún más.
    El movimiento agilísta no a presentado ninguna restricción al respecto de que certificaciones y/o evaluaciones son requeridas para dar un formato cerrado de empresa SSI de calidad y garantías de satisfacción. Estos procesos y metodologóas propuestos por los movimientos Ágiles parecerieran ser solamente aditivos para mejorar en ciertos aspectos la productividad, sin representar necesariamente calidad certificada.
    Entonces ¿Por que los clientes deben confiar sus requisitos a empresas que no tienen interés en certificar una norma de calidad de productos finales como ISO o ser evaluados en CMMI para sus procesos de construcción y prestación de servicios informáticos?

    Leer entrada completa | Make a Comment ( Comentarios desactivados en La importancia de las Certificaciones y evaluaciones de los SSI )

    Cursos en Córdoba, Septiembre a Octubre

    Posted on 31 agosto 2008. Filed under: Gestión de Proyectos de Software, Metodologías de Desarrollo, Procesos Ágile | Etiquetas: , , |

    En Córdoba Argentina, se dictarán cursos de Adminsitración de Proyectos, Seminarios Taller de Scrum y Testing de Software Embebido.
    Los cursos son promovidos por el INTI y tiene el siguiente cronograma conocido al momento:

    Seminario Taller SCRUM: Gestión ágil de proyectos de software
    11 y 12 de septiembre de 9 a 18 horas.
    Más información: http://www.inti.gov.ar/capacitacion/software/scrum_cordoba.htm

    Administración de Proyectos de Software
    5, 6 y 7 de noviembre de 9 a 18 horas.
    Más información: http://www.inti.gov.ar/capacitacion/software/adm_cordoba.htm

    Testing de Software Embebido
    5, 6 y 7 de noviembre de 9 a 18 horas.

    Más información: http://www.inti.gov.ar/capacitacion/software/software_embebido.htm

    Leer entrada completa | Make a Comment ( 2 so far )

    Ágile resulta más económico?

    Posted on 18 agosto 2008. Filed under: Metodologías de Desarrollo, Procesos Ágile, Uncategorized | Etiquetas: , , , , , |

    En términos de rendimientos económicos puede demostrarse con relativa facilidad la diferencia entre modelos de gestión Ágiles y Waterfall.
    Basados en la idea de que todo proyecto tiene objetivos concretos que alcanzar en tiempos y costos limitados, es fácil observar que mientras los modelos Waterfall administran sus entregables a lo largo de una escala de tiempo significativamente grande, los modelos Ágile planifican entregas a una escala mucho más corta. Siendo así es entendible que el valor apreciativo de cada entrega pactada se devalúe con el paso del tiempo, por el solo hecho de los cambios naturales en los requerimientos de los negocios que dan vida a los proyectos. Entonces son estos mismos cambios la razón principal para que una solución ofrecida para una versión de software “X.Y.Z” en poco tiempo deje de ser una solución efectiva para el negocio.
    El “
    valor esperado para una solución de negocio” es cada vez menor por cada una de las nuevas versiones promovidas por tales cambios, y aunque esta situación está presente en cualquier modelo de trabajo, hay que hacer una comparativa de la “devaluación” de la solución esperada entre entregables.
    Los modelos Waterfall típicamente tienen espacios
    de tiempos muy grandes entre entrega y entrega, y la depreciación del valor tiende a ser mayor que el revalúo que promueven las próximas entregas. Entonces la línea de valor esperado para una solución de negocio termina siendo sensiblemente menor con el transcurrir de la variable tiempo.
    Los modelos Ágile promueven entregas en iteraciones mucho más pequeñas, con lo cual si bien el cliente puede tener una baja apreciación inicial, a corta data puede observar el verdadero valor de tener soluciones efectivas en mucho menor tiempo, y aún cuando las misma no representan en si mismas la solución general, si representan soluciones integrales que para cada entrega representan mayor revalúo que depreciación.
    En lo particular tengo alta estima por los modelos ágiles, más que nada por el valor agregado que implican las iteraciones recurrentes con el cliente, quien no solo redirecciona los pasos del proceso de construcción de las soluciones, sino que revaloriza el modelo de trabajo al promover mejores alternativas para ser utilizadas en cortos plazos de tiempo. Esta iteración magnifíca la percepción del
    valor esperado” para muchas soluciones del mismo negocio.
    GoogleTech presenta en forma sintética esta idea donde se explica gráficamente como Ágile permite generar valor agregado con iteraciones más cortas:

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Ágile resulta más económico? )

    Olfato e intuición amplificada

    Posted on 5 agosto 2008. Filed under: Calidad del Software, Procesos Ágile, Testing, Trabajo en Equipo | Etiquetas: , , , |

    Fortalezas y debilidades de las Pruebas Exploratorias

    Muchas veces se habla del Testing Exploratorio sin tener una verdadera conciencia de lo que se trata ni del modo en que se debe ejecutar. Los detractores de este tipo de verificaciones, opinan mostrando la práctica como informal, sin procedimiento y fuera de los cánones del Testing y por transferencia intentan establecer que no existe Calidad del Software.

    Les doy la razón únicamente en que este tipo de pruebas del software no están en los cánones del Testing, puesto a que es una actividad extremadamente compleja de interpretar y realizar si no se tienen en cuenta los elementos de soporte que finalmente avalan la práctica.

    Las pruebas exploratorias muestran sus resultados y garantías en base a los resultados y garantías de prácticas previas y del mismo modo, fallan sus resultados y garantías cuando prácticas que le anteceden son ejecutadas en forma endeble o imprecisa.

    Para este tipo de verificaciones y validaciones son necesarios ciertos elementos del lado del QA y Testing:

    • Conciencia de que todo lo que se verifica está orientado a la detección de problemas que impidan satisfacer requisitos funcionales y no funcionales
    • Capacidad de análisis elevado para entendimiento cabal de requisitos en base a la observación y análisis de la evolución de los mismos
    • Abstracción para la elaboración de circuitos de pruebas de verificación y validación
    • Capacidad de ampliación de caminos de pruebas para mejora espontánea de la cobertura
    • Conocimiento y dominio del negocio al que pertenece el problema
    • Alta proactividad y gran capacidad comunicacional para generar ambiente colaborativo
    • Conocimiento cabal del proceso que rige para reconocer las fallas que se manifiestan en los resultados no deseados
    • Gran capacidad para definir y variar las estrategias, tácticas y técnicas de validación y verificación
    • Olfato e intuición amplificada

    Este es un formato simple de ideación de prueba exploratoria y aquí les muestro un breve ejemplo:

    “Se hizo el planteo de ir cambiando fechas del servidor para que las Presentaciones venzan con la regularidad que precisamos y los avisos visuales se evidencien en cada vencimiento, según la parametrización establecida para cada Etapa del Circuito de Aprobación. Con esto tendremos la cobertura necesaria para verificar las funcionalidades relacionadas con el establecimiento de fechas luego de haberse aceptado una Presentación para que ingrese al Circuito de Aprobaciones.
    Será necesario realizar verificaciones también un paso adelante, es decir desde el Circuito de Aprobaciones, para lo cual preparamos el siguiente juego de datos sencillos:
    Se prepararon a nivel de juego de datos para Testing, 16 presentaciones vencidas donde existe al menos una presentación vencida para cada Etapa.
    Se definen seis (6) usuario donde cinco (5) tienen el rol de Aprobador de Circuito, más su rol principal y un (1) usuario tiene el rol de Administrador.
    Se define una cuenta de Test para cada aprobador y se la configura con alias en ThunderBird.
    Cada vez que se cierra una etapa se notifica vía mailing tanto al Administrador como al Aprobador de cada etapa del circuito.
    Cuando una Presentación se encuentre vencida en la Etapa Actual, según los parámetros definidos para la etapa, se notificará vía mailing al Administrador y al Aprobador”

    Hay que considerar que para el éxito de esta verificación se utilizarán las definiciones que se hacen a nivel de requerimiento (por eso es importante la completitud y correctitud del Req.) para verificar mediante pruebas exploratorias (sin script), que el sistema esté haciendo lo que se solicita y se ampliará el grafo de pruebas según criterio de SQA, para verificar que el sistema no haga lo que no debe hacer.
    Es decir que básicamente los requerimientos definidos son los Scripts de ejecución y también evidencia de funcionalidad.

    Según este tipo de proceso de verificación y validación, las evidencias de funcionamiento se deben dar en la fase de construcción e integración, más no pretender que las pruebas funcionales indiquen que el sistema funciona correctamente, sino entender que el concepto es la detección de fallos y errores.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Olfato e intuición amplificada )

    ¿Cual es la importancia de contar con un proceso bien definido?

    Posted on 28 julio 2008. Filed under: Calidad del Software, Metodologías de Desarrollo | Etiquetas: , , , |

    En la actualidad existen  cientos de Software Factory que no tienen prácticas definidas en casi ninguna área de procesos y aún sin definir puntos de control formalistas como lo demandan los procesos más conocidos (existen muchos y variados), realizan actividades que son las que en escencia la definen como una Software Factory.

    Conocen de requerimientos, análisis y diseño, implementación y testing, tienen definidos sus objetivos para cada proyecto y trabajan contra un “end line”, con un presupuesto limitado, con recursos asignados y todo esto se gestiona de alguna manera, aunque no está claro como. El no tener claro “el como” o ser variable de un proyecto a otro, puede considerarse como un proceso indefinido.

    Estoy de acuerdo que cualquier empresa que trabaja con algún tipo de organización funcional, tiene un proceso que le permite llegar desde un principio hasta un fin. Esta organización funcional no define necesariamente a un proceso.

    Sin embargo no podemos excluir a estas empresas del rubro software factory por el de no tener prácticas moderadas. Inclusive las podemos criticar y comparar pero no podemos ponderar en forma generalizada el grado de éxito o fracaso que estas entidades tienen.
    Puedo afirmar que existen organizaciones pequeñas que no conocen los verdaderos preceptos de calidad (la gran mayoría) y ni siquiera están interezados en los procedimientos formales de verificación, ni en documentación ni en el testing tradicional, ni en métricas y para cada proyecto varía el método de trabajo, el modo de comprobación y sus certificación internas y externas.

    Y aún sin definiciones formales logran entregar sus productos en muy buenos términos, pero con aspectos pocos deseados como son:

    • resultados poco predecibles
    • resultados poco repetitivos
    • alto desgaste de los recursos
    • métricas endebles o inexistentes
    • calidad dudosa o no garantizada

    Nuevamente me pregunto: ¿cual es la importancia de contar con un proceso bien definido?

    Leer entrada completa | Make a Comment ( Comentarios desactivados en ¿Cual es la importancia de contar con un proceso bien definido? )

    Aplicaciones completamente personalizables

    Posted on 23 julio 2008. Filed under: Calidad del Software, Metodologías de Desarrollo, Soporte Colaborativo, Soporte de Aplicaciones | Etiquetas: , , , , , , , , |

    Las aplicaciones WEB están marcando la tendencia inexorable de las UI (User Interface) que pronto deberán ser aplicadas en nuestras aplicaciones de escritorio.

    La riqueza de funcionalidades que actualmente se ofrece en la WEB abarca factores de total personalización desde la primera interacción del usuario con su aplicación. El LOGIN puede hacerse ni bien se abre el SITE pero es posible previamente seleccionar el idioma de preferencia, el esquema de colores y hasta alternativas de gestión basadas en perfiles que el usuario definió en ingresos previos.

    Por ejemplo un SITE puede validar solamente el “nombre de usuario” sin que el mismo haya ingresado aún su “clave privada” y en una especie de juego tienta al usuario identificado a seleccionar algunas opciones de accesibilidad y usabilidad, las cuales solo estarán disponibles si se valida la “clave privada” y en algunos casos un tercer nivel de seguridad como puede ser un “código de validación” que recibe en su cuenta de correo diariamente.

    De esta manera los propietarios de SITE pueden hacer gala de estas potencias mostrando valores agregados de diseño, arquitectura y funcionalidades, mucho antes de brindarles el servicio real para el cual el sistema fue creado. Con estos “Mock-Ups” se logra un alto factor de fidelización y atracción para potenciales nuevos usuarios y clientes.

    Una vez “adentro” continúan las opciones de personalización hasta niveles antes desconocidos:

    • El usuario puede, mediante “Drag & Drop” cambiar el orden de visualización del contenido usando la potencia de lo que se conoce como “Portlets”, mientras que puede determinar que contenidos estarán bloqueados para que no se pueda reemplazar su posición o la visualización de su información interna.
      Bajo el mismo esquema de personalización mientras el usuario mueve su contenido con “Drag & Drop” el SITE propone generar nuevas columnas o nuevas filas o ambas cosas, según disposiciones posibles de orden.
      Esto es posible mientras tiene garantizado que siempre su contenido estará activo y actualizado.
    • El usuario puede ejecutar en pasos muy sencillos “uploads inline” realizando selecciones múltiples de archivos y en el mismo proceso de carga, pausar una o varias cargas planificadas, cancelar una o varias cargas planificadas, visualizar el avance individual de cada carga y a su vez visualizar el avance general de la carga, pausar todo el lote de carga y en esa pausa quitar archivos que aún no fueron cargados y definir otros archivos de su interés y finalmente reiniciar el proceso de Upload.
    • En lo que respecta a catálogo de imágenes es posible realizar operaciones de “Drag & Drop” con el teclado mismo utilizando teclas que el mismo usuario configura para la navegación.
      El teclado pasa a ser una herramienta de uso contemporáneo en las aplicaciones WEB tanto como el mouse.
    • Los “ToolTips” están a la orden del día y es posible que el mismo usuario los genere del mismo modo que en Excel se genera un comentario en una celda.
      Hay que sumarle que los ToolTips son personalizables en color, fuente, el mismo contenido, retardo antes de mostrarse y si además de mostrar la información ingresada por el usuario también mostrará información técnicas del objeto del catálogo.
    • Los “chekboxes” no se limitan a solo permitir la selección sino que ya muestran una variedad de estilos que el mismo usuario puede definir y se combina con la nueva potencia del texto que se puede modificar “inline”. Nuevamente el teclado es fundamental para interactuar con estos elementos.
    • Los “Tabs” aumentan potencia al permitir interacción con el teclado y utilizar las teclas que el usuario mismo define, estableciendo el orden saltos, las teclas de navegación, reordenamiento y un poco más al definir los estilos de foco.
    • Las listas verticales ahora son totalmente ordenables y permiten que el usuario mueva grupos enteros de una lista desde un lugar a otro o bien redefina la posición de un único elemento de la lista, cambiándolo a un nuevo grupo.
      También se pueden mover varios grupos a una nueva posición de orden y la aplicación enumera automáticamente las posiciones según un orden establecido inicialmente o configurable también.
    • Los formularios editables muestran toda las funcionalidades ricas de aplicaciones como Word

    image

    La lista se extiende mucho más de lo que aquí pretendo mostrar y sin duda los diseñadores de aplicaciones WEB utilizan las potencias de las nuevas herramientas que ahora utilizan los estándares más populares y gestores de contenidos para separar justamente el contenido del impacto visual y lograr administraciones mucho más potentes de las aplicaciones.

    Es posible que todos esto haya sido ideado inicialmente habiéndose detectado la necesidad de fidelización de usuario y captación de nuevos, pero el desarrollo y evolución es tan acelerado y significativo que este cambio generacional del WEB, ya impacta directamente en el modo de generar la aplicaciones de escritorio.
    El contagio no se hace esperar y podremos en muy corta data, observar como los lugares donde trabajamos utilizarán la sinergia de las aplicaciones WEB y las aplicaciones de escritorios, siendo irreconocible la división, si es que la hubiera, en lo que respecta a la implementación y mantenimiento de los “acuerdos de servicios”, obteniendo mayor y mejor soporte para disponer de nuestros datos desde múltiples lugares (remotos o locales), compartirlos con seguridad en un “entorno plenamente colaborativo” y orientado a la generación de información sustancial.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Aplicaciones completamente personalizables )

    10 Mejores Prácticas para la Generación de Software

    Posted on 18 julio 2008. Filed under: Calidad del Software, Metodologías de Desarrollo, Trabajo en Equipo | Etiquetas: , , , , |

    La rapidez con que se construye un edificio es sorprendente, pero detrás de esa aparente facilidad están los siglos de experiencia de la industria de la construcción, y si quisiéremos aplicar los mismos parámetros a los proyectos de software, la desproporción será abismal. A casi tres décadas el desarrollo de software sigue buscando la manera adecuada de desarrollarse para hacerlo más rápido y sin errores.
    Anteriormente las pruebas de software se consideraban sólo una actividad que realizaba el programador para encontrar fallas en sus productos; con el paso de los años se ha determinado la importancia que tienen para garantizar el tiempo, el costo y la calidad del producto, de tal forma que actualmente son un proceso cuyo propósito principal es evaluar en todo momento la generación del software respecto de los requerimientos establecidos al inicio.

    La nueva tendencia consiste en iniciar las pruebas en etapas tempranas dentro del proyecto, y capacitar a especialistas responsables de esta actividad. El primer punto quiere decir que actualmente es una práctica casi generalizada que las especificaciones de pruebas se realicen al mismo tiempo que el diseño de software; la propuesta es iniciar el análisis del testware junto con el análisis del software. Esto habla de pruebas preventivas que ofrecen ventajas como las siguientes:

    a) Se identifica qué se quiere y cuáles son los resultados esperados (criterios de aceptación)
    b) Ejecutar las pruebas tan pronto como el software está listo.
    c) No sólo descubrir errores, sino evitarlos.

    El segundo punto habla de crear conciencia sobre la importancia de las pruebas y tener un equipo de personas dedicadas a esta actividad que puedan integrarse a un proyecto y sean responsables de su calidad. Hoy se tiene ya definida la carrera de ingeniero de pruebas y existen organismos especializados para certificar en esta disciplina.

    Entonces se puede decir que los objetivos actuales de las pruebas no sólo tienen que ver con corregir errores, sino con prevenirlos influyendo y controlando el diseño y desarrollo del software. Las pruebas deben ser empleadas como modelos de los requerimientos de software que se ha de construir; por tanto, en las especificaciones de software deben incluirse especificaciones de pruebas; ambas deberán revisarse en conjunto, y en esta revisión deberá participar un especialista en pruebas.

    La disciplina de pruebas ha evolucionado en una práctica de especialización que puede ser ofrecida como un servicio hacia clientes internos y externos, garantizado que tanto la metodología como las herramientas automatizadas son aprovechadas eficientemente para alinear el desarrollo a las expectativas del cliente.

    Se debe reconocer que las pruebas son una especie de administradores de riesgos; al igual que en los problemas de combinatorias complejas, se puede definir cuál debe considerarse buen resultado, aunque no necesariamente sea el mejor resultado; con esto quiero decir que las pruebas sólo deben obtener un producto práctico con la calidad y funcionalidad requeridas.

    A continuación se sugieren 10 mejores prácticas para la generación de software:

    1. Hacer una evaluación del trabajo de cada integrante del equipo. Concienciar al equipo de la importancia que tienen las pruebas y el valor que tienen para cada miembro del equipo y así generar cooperación y coordinación entre los miembros del mismo.
    2. Establecer un plan maestro integrado. Establecer claramente las funciones y responsabilidades de los equipos de desarrollo y pruebas
    3. Considerar las pruebas preventivas como parte de las especificaciones de trabajo. Diseñar previamente los escenarios de prueba, dentro del desarrollo de software, y realizar revisiones para asegurarse de que lo que se está construyendo cumple con los requerimientos solicitados.
    4. Usar las pruebas como puntos de control y progreso. Realizar pruebas y revisiones formales para verificar y demostrar que todos los productos claves del proyecto han sido realmente terminados.
    5. Inventario de los objetivos de pruebas y diseño para factibilidad. Revisar la factibilidad en la realización de las pruebas.
    6. Probar pronto y frecuentemente. Hay que probar lo antes y más frecuentemente posible; esto permitirá detectar los problemas tan pronto surjan, de esta manera el desarrollador será más eficiente en las correcciones.
    7. Diseñar y desarrollar el testware como el software. Esto implica planear, analizar, diseñar, supervisar, controlar los cambios, administración; en suma, desarrollar el testware con la misma disciplina con que se desarrolla el software.
    8. Proporcionar una herramienta integrada de pruebas, evaluación y de soporte de infraestructura. Proporcionar herramientas que incluyan: Base de datos o repositorio, Administración de pruebas, que permita documentar, ejecutar y clasificar pruebas, Soporte automático, Simuladores, Analizadores de software, Manejadores de pruebas, Herramientas de captura y repetición (playback) y utilerías.
    9. Medir el costo, el alcance, los resultados y la efectividad de las pruebas y evaluación. Coleccionar información que permita conocer el costo, los resultados y los beneficios así como el alcance.
    10. Entrenar y administrar al equipo. Proporcionar el liderazgo y administración al equipo con el fin de que sepa lo que se espera de él para que se tomen las pruebas seriamente. Definir los criterios de “mejores prácticas”.

    La razón principal para implementar esta práctica, es que finalmente todo el tiempo perdido, se convierte en costos que afecta los resultados de un proyecto, pues generalmente se usa más del tiempo planeado para las pruebas. Para los administradores de proyectos, la correcta administración es la que lleva a obtener buenos resultados.

    Publicado por por Elsa Ramírez, Directora de Tecnología y Calidad para Praxis el 6 de marzo de 2008 en http://www.sg.com.mx

    Leer entrada completa | Make a Comment ( Comentarios desactivados en 10 Mejores Prácticas para la Generación de Software )

    Algo de Testing Automatizado

    Posted on 1 mayo 2008. Filed under: Calidad del Software, Metodologías de Desarrollo, Procesos Ágile, Pruebas Unitarias |

    Objetivos del Testing Automatizado

    • Tests deben mejorar la calidad
    • Tests deben ayudarnos a entender el sistema bajo pruebas
    • Tests deben reducir riesgos
    • Tests deben requerir mantenimiento mínimo al mismo nivel que el sistema involucrado
    • Tests deben ser ejecutados como parte del proceso de construcción
    • Tests deben ser fácil de ejecutar

    Tipos básicos de Testing donde se puede automatizar

    • Testing Unitario a nivel del código
    • Testing de aceptación de productos/servicios (pruebas del cliente)
    • Testing de interfaces a nivel de prototipos y luego a nivel de integración o preintegración

    Que tener en cuenta para iniciarse en los Procesos Automatizados de Pruebas

    ¿Cuales son los objetivos de nuestro Testing Automatizado?  Estos deben estar alineados con todos los objetivos de Calidad.
    Algunos factores que afectarían a nuestros objetivos:

    • Deseamos automatizar las pruebas regresivas?
    • Deseamos realizar Integración Continua en nuestro Proceso de Desarrollo?
    • Estamos buscando resolver un ítem específico de Aseguramiento de Calidad?

    Comencemos a Organizarnos

    Elegir una estrategia

    Escojamos un Tipo Básico de Testing al que nos queremos aproximar con la automatización.
    Debería ser una combinación de aproximaciones basadas en:

    • Objetivos
    • Tipo de sistema que queremos probar:
      • Testabilidad: Definir la capacidad del sistema a soportar automatización de pruebas
      • Nivel de automatización actual: Si la base es cero podría ser el peor escenario
    • ¿Podemos modificar el Proceso de Desarrollo y los Requisitos del Sistema para lograr una aproximación al nuevo Ciclo de Vida que exigen las pruebas automatizadas?
    • ¿Con solo la automatización de pruebas resolvemos algún problema o debemos tener en cuenta otros ítemes?
    • Seleccionemos un tipo de Testing Automatizado: Unitario, Integración, Requerimientos, etc.
    Seleccionemos las herramientas basándonos en
    • Estrategia seleccionada
    • Orientación del Testing Automatizado (Aceptación del Cliente, de Componente, GUI)
    • ¿Open Source o Comercial?
    • ¿La aplicación seleccionada se adapta a nuestra aplicación o debemos hacer adaptaciones de la aplicación a la herramienta?
    • Definamos cuales son nuestros costos
    Puntos para facilitar el mantenimiento
    • Definamos las expectativas de la Gestión de las Pruebas
    • Definamos los estándares o patterns para implementar las pruebas automáticas

    Por ejemplo usemos Palabra Clave como patrón que puede utilizarse para reducir los costos de mantenimiento al utilizar la interfaz de usuario basada en la automatización. Algunos de los enfoques de benefician directamente con el trabajo de control de calidad.

    El enfoque que realizamos afectan las acciones

    • Los desarrolladores serán responsables de crear y mantener las Unidades de Pruebas Automatizadas, aunque puede ayudar a QA y su criterio será fundamental
    • SQA puede crear los otros tres tipos de pruebas automatizadas, como siempre lo mejor es integrar directamente en el proceso de desarrollo
    • Debemos asegurarnos de que el Testing Automatizado es realmente parte del proceso y se complementa con el Testing No Automatizado
    Revisemos el Plan de Pruebas Automatizadas

    En todos los casos se debe hacer revisiones de la efectividad del proceso y buscar la forma de mejorarlo. Las siguientes cuestiones podrían ayudarnos:

    • ¿Son lentas las automatizaciones?
    • ¿Son difíciles de mantener?
    • ¿Disminuyen la velocidad del Proceso de Desarrollo?
    • ¿Son eficaces en el logro de nuestros objetivos de calidad?

    Estas pruebas tienen como principales objetivos comprobar que el código se comporta de la manera esperada y prevenir la aparición de errores inesperados al modificar o refactorizar el código. También, en algunos casos como en el desarrollo dirigido por pruebas, las pruebas unitarias ayudan a obtener el diseño del código. Las ventajas de realizar este tipo de pruebas son: código más depurado, mayor seguridad a la hora de refactorizar y mayor velocidad de desarrollo, aparte de obtener código de mayor calidad asegurando que nada se ha roto cuando cambiamos la lógica interna del software.

    Actualmente las pruebas unitarias se desarrollan con herramientas tipo jUnit [3] y objetos mock [4]. Las herramientas tipo jUnit se aplican para comprobar que el estado de un objeto, los valores retornados por los métodos, excepciones lanzadas, etc, son los esperados. Los objetos ficticios o mocks, en cambio, permiten aislar el código a probar de las dependencias con otras clases colaboradoras mediante el desarrollo de clases ficticias que simulan el comportamiento de estas clases colaboradoras. Esto permite centrar la prueba sólo en el código que se desea probar.

    Aquí introduzco conceptos de Testing Driven Development (TDD) tomados de un blog amigo WebTrun:

    SlideShare | View | Upload your own

    Leer entrada completa | Make a Comment ( 1 so far )

    Mi rol, mi evolución, mis quedos, mi dejos

    Posted on 28 abril 2008. Filed under: Calidad del Software, Metodologías de Desarrollo, Procesos Ágile, Pruebas de Integración, Pruebas Unitarias, Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo |

     

    Como Responsable SQA y QAC, sostengo mi crecimiento permanente basándome en la vida misma de los proyectos, en las interdependencias profesionales y en la relevancia de nuestras soluciones para el usuario. 

    La formación de un proceso particular y nuestra adaptación no ha sido fácil. Principalmente nos ha sido imposible automatizar las pruebas para un entorno de desarrollo basado en la API de Lotus Note, de IBM y todo lo que pueda existir para automatizar pruebas a cualquier nivel nos resultó bastante costoso, en lo que a tiempo y esfuerzo se refiere.

    Es así que me he puesto en la tarea de mejorar todos los procesos intrínsecos, previos a cualquier desarrollo.

    La estrategia global implicó lograr alertar fallos utilizando un símil  AMFE en los requerimientos, también en fases de Análisis y Diseño. Posteriormente establecer una cadena de revisiones para las soluciones técnicas propuestas, mas estudios de viabilidad y factibilidad de Despliegues de Productos, tratando de detectar y minimizar cualquier merma de la calidad que impacten en los eslabones finales de la cadena de producción.

    Como estrategia para pruebas, generamos la cantidad de ambientes de Testing que fueran necesarios, basándonos primariamente en los ciclos que dimos de alta en el cronograma del proyecto.

    Nuestra táctica implica la formación de una alta cantidad ciclos con una gran cantidad de Pruebas de Integración, que no son coincidentes con Versiones Candidatas del producto, sino que en cada integración nos vamos acercando a dichas versiones. Al lograr integrar todos los componentes que conforman un módulo testeable a nivel de pruebas funcionales, versionamos el producto y ejecutamos el ciclo funcional correspondiente.

    Esto esta lejos de ser una Integración Continua, pero es la aproximación mínima que he podido idear para que la mayoría de los defectos se detecten con bastante antelación.

    Conformamos un equipo chico de desarrollo, con un Responsable que hace las gestiones de seguimiento de avances de los componentes y determina en base al cronograma, el hito de integración de componentes, del mismo modo la conformación de los módulos y notificaciones al LP y SQA, de los módulos que están disponibles para pruebas de funcionales.

    La envergadura del equipo exige que los mismos desarrolladores ejecuten los ciclos de pruebas integradoras y lo hacen bajo un esquema de revisiones cruzadas. SQA asigna también un equipo de Testeadores que ejecutan pruebas integrales ayudando a acelerar el proceso.

    Previo a esto, sin duda alguna tuvimos que elevar el Skill de los Desarrolladores de esta tecnología tan particular, en lo que respecta a técnicas de pruebas y detección de fallos.

    Todos los fallos, defectos y errores son registrados y puestos a consideración de SQA y el LP quienes en un solo lote hacen las derivaciones para resoluciones, en base a la severidad y prioridad determinada en un análisis exhaustivo.

    Este accionar nos ha llevado rápidamente a una disminución significativa de fallos detectados en ciclos de pruebas funcionales de versiones candidatas y a una desaparición del 100% de fallos del tipo Invalidante y del 80% de fallos del tipo Grave.

    Las actividades de Despliegue en si mejoraron y garantizaron mejores funcionamiento cuando se comenzó a utilizar el elemento "Pruebas de Campo" y finalmente nuestro equipo de Soporte cuenta con una gran biblioteca de fallos detectados los cuales alimentan su base de conocimientos a cerca de como se podría presentar un fallo y como se orienta a su rápida resolución.

    Poco a poco trataré de mostrar los procesos aunque no pueda dar demasiados detalles, lo haré genérico.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Mi rol, mi evolución, mis quedos, mi dejos )

    Modificar el "paradigma de pruebas" por el "paradigma de evidencias".

    Posted on 3 abril 2008. Filed under: Calidad del Software, Procesos Ágile, Trabajo en Equipo |

    En nuestra organización me he visto obligado a modificar el "paradigma de pruebas" por mi "paradigma de evidencias".
    Movilizado por la creciente demanda de agilidad que nos impone el ritmo de obtención de proyectos, ya sean para modificaciones de productos existentes o para construcción de nuevos, SQA trabaja fuertemente al principio de los proyectos, desde las minutas de requerimientos, pasando por la ERS, ERP, documentos de análisis, diseño y arquitectura (si es que los hubiere) para localizar los puntos débiles y fortalecerlos en base a observaciones de No Conformidad que obliguen a un enriquecimiento del proyecto antes de pasar a otras fases del mismo. Eso como primera medida.
    A partir de esos documentos, SQA comienza un análisis profundo con una alta tasa en la solicitud de consultas técnicas, investigaciones paralelas (documentación técnica, de negocios, de sistemas, modelos de datos, arquitecturas, patrones de diseño, etc.) entre otras actividades y empieza a formar el documento de calidad "Especificaciones SQA" si le quieres dar algún nombre. Este documento lo vamos formando y generando su trazabilidad en base a la descomposición de trabajo (WBS) que hicieron los analistas y líderes de proyectos en una fase de iniciación.
    Nuestros criterios de calidad son tanto para el proyecto, para el producto o sistema, como también para los servicios aledaños y son puestos "a mano" del área de desarrollo, como documento matriz para la guía de la calidad esperada.
    No generamos casos de pruebas, puestos que solicitamos EVIDENCIAS y este concepto introducido por mi, obliga al equipo de desarrollo a la generación de todos los elementos tangibles que garantizan la completitud y correctitud del componente entregable o no entregable que se construyó. Ya sea que se trate de un componente de interfase, una clase, objetos, esquemas de bases de datos, parámetros de conectividad o cualquier tipo de instanciación, debe quedar una evidencia que puede ser sujeta a una auditoría de calidad.
    De este modo, SQA no forma un equipo de testing que espera un producto final desplegado en un ambiente controlado para pruebas, ni forma juegos de pruebas de funcionalidad que puedan ser ejecutados en una fase determinada, pero si ejecuta el uso del sistema bajo un fuerte y concienzudo conocimiento del mismo, debido a que pudo generar los factores de evidencias mínimas requeridas y durante toda la fase de construcción, interactúa con el área de desarrollo haciendo un seguimiento de la formación de las evidencias a satisfacerse.
    Es posible que este proceder no reduzca el tamaño ni el esfuerzo de las pruebas, sino todo lo contrario, pero lo que si provoca, es una mejor distribución del esfuerzo para la obtención de calidad.
    Quizás no es fácil entender mi modelo, pero es una idea que puse en práctica y esta dando buenos resultados en nuestro ambiente de trabajo. Tenemos mejor adaptación a cambios hasta el punto tal de que SQA puede inclusive no enterarse de las modificaciones introducidas a ciertos requerimientos de algún proyecto en particular, pero minutos antes de recibir el entregable consolida el conocimiento con las EVIDENCIAS y reorganiza los criterios de calidad para aceptar o rechazar el componente. Puede parecer extremista, pero lo es también la exigencia de nuestras necesidades de facturación y los mercados y el volumen de pruebas sería imposible de manejar para un equipo como el nuestro, al menos.
    Así que tiro la punta del ovillo para que comencemos a debatir este modelo, si es que les parece debatible.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Modificar el "paradigma de pruebas" por el "paradigma de evidencias". )

    Evidenciar las falencias de la Integración del Código

    Posted on 27 marzo 2008. Filed under: Calidad del Software, Metodologías de Desarrollo |

    Lamentablemente el Testing de hoy fue un éxito rotundo con los módulos puestos a pruebas de verificación, los cuales dan fallo de severidad INVALIDANTE.

    Este tipo de reportes suele ser típico en la mayoría de las organizaciones dedicadas a la construcción de software y por mucho esfuerzo que se hace en introducir mejoras en los procesos a niveles de mejoras en las tomas de requerimiento, análisis, diseño y desarrollo, no se logra superar ciertas barreras que tal vez son de otra índole.

    Lo que pude ver y analizas hasta ahora, esta relacionado a una grave falencia en el proceso de integración, quizás en su método, tal vez en su ambiente o en ambos, en el área de Desarrollo. ¿Por que digo esto?

    Los desarrolladores juran que los fallos que resultan en Testing no se presentan en sus ambientes de desarrollo y no hay dudas de que ellos entregan los componentes con las pruebas ejecutadas que el entorno de diseño les permite, más las limitaciones que cada quien tiene en su PSP. Luego pasan a otro componente y lo entregan, siempre cumpliendo el mismo circuito.

    Finalmente se integra todo y se versiona el sistema para ser entregado a SQA, quien genera los ciclos de verificaciones funcionales y donde a las primeras surgen fallos.

    Esto evidencia claramente que no hay Pruebas de Integración o las mismas son muy escuetas y es por eso que el primer ciclo de “Pruebas Funcionales” que ejecuta Testing es considerado por mí como “Pruebas de Integración”.

    Lo lamentable y donde se evidencia fuertemente la falta del ambiente de integración, es cuando el defecto se hace persistente y es reportado dos o tres veces sin que realmente se solucione.

    Una solución posible según mi óptica, sería que se formen los ciclos de desarrollo lo suficientemente chicos como para ser integrados N veces cada vez que ese ciclo finaliza, es decir cada vez que los desarrolladores entregan los N componentes del ciclo. Así pues se los integra y los desarrolladores mismos puedan ejecutar las pruebas de integración (funcionales) y detectar los fallos lo antes posible sin tener que considerar su trabajo finalizado hasta que superen esa etapa.

    Esto no implica que cada ciclo de integración deba entregarse a Testing, sino el costo de las pruebas sería muy alto, sin embargo ya tendríamos predefinidos en los cronogramas del proyecto los ciclos de pruebas funcionales para integraciones más grandes, modulares y que representen una versión del sistema en si misma.

    Sin duda duda que esta referencia y análisis lo hago para ambientes de desarrollo donde existe poco y nada de automatización y no se puede trabajar con Integración Continua, siendo más primitiva la metodología de generación de versiones, aún con potentes IDES, como es el caso de Lotus Notes.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Evidenciar las falencias de la Integración del Código )

    ¡No existe el vamos a probar!

    Posted on 1 marzo 2008. Filed under: Argentina tecnológica, Calidad del Software, Gestión de Proyectos de Software, Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile, Project Management, Trabajo en Equipo | Etiquetas: , , , , , , , , , , , , , |

    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.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en ¡No existe el vamos a probar! )

    Ágile. Proceso o no?

    Posted on 25 enero 2008. Filed under: Metodologías de Desarrollo, Procesos Ágile |

    En lo personal no comparto la opinión con los que emiten comentarios que hacen emblemático a un personaje en particular y por otro lado emiten comentarios que detrimentan a otro, cuando en ambos casos hablamos de personas que administran gran cantidad de personas al rededor de múltiples proyectos concurrentes y se las han arreglado para posicionarse con sus ideas y principalmente por que las desarrollaron.
    Ahora yendo a lo concreto, creo de algún modo que Scrum no sirve más que para Gestionar un proyecto, es decir a niveles administrativos para seguimiento y control, tanto como para la estimación del tiempo y los recursos para la construcción, es decir que puede ser utilizado como modelo tremendamente útil en las PA Gerenciales, dependiendo de que grado de formalismo se requiera. Instruye en buenas prácticas pero no representa un proceso completo en si mismo. Scrum no facilita las herramientas utilizadas para el desarrollo en si, con lo cual mínimamente se debe utilizar un modelo de otro tipo como XP si prefieres seguir en lo Ágile.
    Nosotros no nos hemos apartado de los Gant por que nos dan gran visibilidad y en forma ágil podemos ver los corrimientos o reubicamos los recursos con facilidad visual.

    Por otro lado creo que la herramienta a utilizar e indistinta. Puedes tener todo tu Backlog en un Excel, en un aplicativo Access o una aplicación de construcción propia como nosotros (Lotus) y puedes tener cada uno de los Sprint en un MSProject o si prefieres el software libre en un OpenProj.

    Siguen siendo los principios ágiles abiertos a múltiples interpretaciones, y las herramientas orientadas Ágiles tienden a ser cada día más complejas por que se ha dado cuenta el mundo que con pequeñeces no es posible generar inteligencia en la industria del software. Que usan para gestionar los riesgos? o para conocer la disponibilidad de los recursos IT? o para ponderar los costos? Seguramente herramientas de cualquier tipo que servirán al propósito.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Ágile. Proceso o no? )

    Metodología Métrica V3 – Técnicas y Prácticas

    Posted on 10 enero 2008. Filed under: Métricas, Metodologías de Desarrollo |

     

    Wikipedia define: MÉTRICA es una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de información. Promovida por el Ministerio de Administraciones Públicas del gobierno español para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas.

    Es una metodología propia basada en el Modelo de Procesos del Ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology – Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination)

    Ver Definición de Métrica en Wikipedia

    • Se define con total claridad que modelo esta orientado al proceso, donde deben considerarse los Procesos Claves:
    • (PSI) Planificación de Sistemas de Información
    • (DSI) Desarrollo de Sistemas de Información, que a su vez se dividen en cinco (5) subprocesos:
    • (EVS) Estudio de Viabilidad del Sistema
    • (ASI) Análisis del Sistema de Información
    • (DSI) Diseño del Sistema de Información
    • (CSI) Construcción del Sistema de Información
    • (IAS) Implantación y Aceptación del Sistema de Información
    • (MSI) Mantenimiento del Sistema de Información

    Todos procesos genéricos en cualquier Software Factory.

    • El modelo cuenta con cuatro (4) Interfaces cuyas actividades están orientadas a la mejora y perfeccionamiento de los procesos principales, arriba mencionados:
    • (GP) Gestión de Proyectos
    • (SEG) Seguridad
    • (CAL) Aseguramiento de Calidad
    • (GC) Gestión de Configuración

     

    • Se consideran las siguiente Técnicas:

    Técnicas y prácticas

    • Introducción
    • Técnicas de desarrollo
      • Análisis coste/beneficio
      • Casos de uso
      • Diagrama de clases
      • Diagrama de componentes
      • Diagrama de descomposición
      • Diagrama de despliegue
      • Diagrama de estructura
        • Diagrama de flujo de datos (DFD)
        • Diagrama de interacción
        • Diagrama de secuencia
        • Diagrama de colaboración
        • Diagrama de paquetes
        • Diagrama de transición de estados
    • Modelado de procesos de la organización
      • SADT (Structured Analysis and Design Techniques)
      • Modelado entidad/relación extendido
      • Normalización
      • Optimización
      • Reglas de obtención del modelo físico a partir del lógico
      • Reglas de transformación
    • Técnicas matriciales
      • Técnicas de gestión de proyectos
      • Técnicas de estimación
      • Método Albretch para el análisis de los puntos de función
      • Método Mark II para el análisis de los puntos de función
      • Staffing Size (Orientación a objetos)
    • Planificación
      • Program Evaluation & Review Technique – PERT
      • Diagrama de Gantt
      • Estructura de descomposición de trabajo (WBS – Work Breakdown Structure)
      • Diagrama de extrapolación
    Leer entrada completa | Make a Comment ( Comentarios desactivados en Metodología Métrica V3 – Técnicas y Prácticas )

    Cowboy Agile

    Posted on 20 diciembre 2007. Filed under: Procesos Ágile |

    Este término, "Cowboy Agile", tiene un origen y esta claramente explicado en Codificación Cowboy, donde se expresa lo siguiente:

    "Cowboy Coding is a software development  methodology without an actual defined method – team members do whatever they feel is right."

    Básicamente se llama Cowboy Agile a toda aquella organización que toma elementos sueltos de la filosofía Ágile y en forma prácticamente inconsciente comienza a hacer adaptaciones a sus procesos de trabajo para la construcción de software y adopta sin estudio ni análisis, partes de alguno de los modelos (por ejemplo Scrum) y  utiliza su propios criterios según la necesidad de la organización.

    Este proceso que la organización consigue a modo de adaptación tiene graves falencias.
    Podemos mencionar algunas como la no repetitividad de buenas experiencias, el constante cambio de las herramientas que hacen que también se presente un factor de no adaptabilidad a una tecnología, principalmente en lo que a gestión se refiere, los resultados siguen siendo impredecible, las estimaciones mentirosas por ser generalmente subestimadas y las entregas totalmente fuera de términos establecidos.

    Por ende la ruptura de los compromisos es lógica y la carencia de calidad es altamente manifiesta, ya sea por la no existencia de  métricas, la falta de definiciones organizacionales de la calidad, la falta de mejores planes de pruebas o entre otras cosas.

    Leí un comentario muy atinado, The Nokia Test, en un blog de gran difusión, lo cual me hace pensar lo cercano que nos encontramos al término Cowboy Ágile en nuestra organización. La pregunta es: ¿cuantos de nosotros somos los John Wyne del Ágile?

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Cowboy Agile )

    « Entradas anteriores

    Liked it here?
    Why not try sites on the blogroll...