Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
El Manual de la Calidad Software
Segunda edición
En esta segunda edición del Manual de la Calidad Software de Panel Sistem...
INTRODUCCIÓN: SQA, una cuestión de Cultura, Procesos y Herramientas
PARTE I- Cultura y SQA
Capítulo #1 - Lean Management: ...
2015 Panel Sistemas. Página 4
SQA, una cuestión de Cultura, Procesos y
Herramientas
La fabricación de Software ha cambiado. Hemos evolucionado desde un ...
espera tu Cliente, es el objetivo principal. Aplicando prácticas saludables sobre escenarios
como Devops, Integración Cont...
Cuando hablamos de cambiar la Cultura en la construcción de software, es necesario que
en el nuevo modelo las personas ado...
En definitiva, como decíamos al principio, los modelos de
fabricación de software han cambiado, y las organizaciones
deben...
PARTE I
CULTURA Y SQA
"Las personas deben adoptar los cambios, asumir los objetivos y
entender su nueva función"
PARTE I -...
Capítulo #1
Lean Management: Cultura, cambio y liderazgo
Hace unas semanas tuvimos la oportunidad de escuchar durante unas...
MÁS, con MENOS. No obstante ya nos lo
avisaron: Lean requiere paciencia, y para lograr
los objetivos es necesario aplicar ...
Y en la práctica, ¿en qué creo que puedo aplicar
lo que hemos aprendido? Pues creo que
empezaré con pequeños cambios. El p...
Capítulo #2
Calidad y más Calidad…pero ¿y la entrega de
Valor?
(Reflexiones de lo que Marketing es a la Calidad, y vicever...
trata: la calidad técnica, la calidad objetiva, es la que se puede medir, y la que responde a
las especificaciones de prod...
control de la deuda técnica, de aseguramiento del uso futuro del software…O un
producto/servicio perfectamente alineado co...
Es fundamental asegurarse de que la aplicación de estas
metodologías y procesos añaden valor percibido al cliente,
porque ...
Capítulo #3
#SQA: Navegar y disfrutar en equipo
Conclusión: sin trabajo en equipo, respeto, rutina, información y algo de ...
Nuestro barco, Le Magnificat
Como buenos novatos pedimos explicaciones sobre el manejo de la embarcación, la
normativa de ...
sobre unas bases adecuadas. También en la construcción de software. Así, perseverando
en interiorizar que “la Calidad es u...
Esta experiencia también ayuda a establecer claramente la diferencia entre marinero de
agua dulce y lobo de mar (con respe...
Capítulo #4
#one2change – El cambio está en cada uno de
nosotros
A principios de diciembre se celebró la Conferencia Agile...
Manifiesto ágil CAS2015 #one2change
En cuanto a los contenidos, el espacio web creado para la ocasión – CAS2015 en Agile-
...
Centrándome en mi CAS2015
Acudí con idea de aplicar como criterio de priorización los contenidos del track
“Entregando pro...
Sigamos, ponte cómodo y, por favor, recuerda que “Entregando Producto” era mi
mantra.
Apertura Entregando Productos – Arit...
Se trata de una llamada de reflexión sobre el nivel de abstracción a aplicar en el
diseño de un producto. Equilibrar entre...
tiene”, “si no lo hacemos, lo hará otro”, “el jefe lo quiere”, “esta es LA
funcionalidad”.
En conclusión, Carlos nos señal...
¿Cómo conectar con la esencia de un problema? ¿Cómo dinamizar la
innovación en producto? Mariana nos cuenta que su particu...
Hablamos de p_e_r_s_e_v_e_r_a_n_c_i_a, solo te diré que James Dyson (el de
las aspiradoras sin bolsa) realizó 5.127 protot...
para establecer los criterios de aceptación, consiguiendo una mejora
espectacular al aplicarlo a las historias de usuario....
Y con esto se terminó mi asistencia a charlas del track “Entregando Producto”. Muy
intenso, con una clara línea que lleva ...
PARTE II
PROCESOS Y SQA
"La metodología, los procedimientos y las buenas prácticas en
tus proyectos deberían de trabajar p...
Capítulo #5
Algo pasa con CMMi
Agilismo, Conocimiento, Seguridad, Innovación… ¡Lo quiero TODO! ¿Qué le está pasando
a CMMi...
Nuevo logo CMMi-DEV para Panel Sistemas
Una conclusión que quedó perfectamente reforzada en cada una de las ponencias que
...
Pasarela de Holzarte
Alrededor de este tema también destacamos la intervención de Theodora Bozheva
(Berriprocess) y su pon...
colaborativas. Al hilo de esto, también es interesante la colaboración que nos presentó
Ramiro entre el SEI y el EDM (Ente...
Pero en muchos casos, Scrum y su delimitación en temas como QA, arquitectura,
seguridad, requisitos o gestión de la contra...
Capítulo #6
Entre anomalía, defecto o fallo anda el juego
¿Cual es la diferencia entre un defecto y un fallo en un sistema...
componente para realizar las funciones solicitadas dentro de unos márgenes de
rendimiento requeridos. Vamos, que el sistem...
El sueño de E.T.
Entonces, ¿Qué es un <defecto>?
Volviendo a tirar de formalismo ISTQB, un defecto es una “imperfección en...
Igual no te lo imaginas, el ISTQB establece que un error es una “acción humana que
produce un resultado incorrecto. [Según...
Panel Servicios SQA
Referencias
Artículo original: http://blog.panel.es/index.php/softwareqa-entre-anomalia-defecto-o-
fal...
2015 Panel Sistemas. Página 42
Capítulo #7
Los 7 ejes de la calidad del código fuente
Analizar sistemáticamente la salud de nuestros desarrollos software...
Unas líneas de trabajo (de análisis) que arrancan desde la versión 2.0 de sonar, allá por los
albores del año 2010. Con el...
Antes de lanzarnos a una irracional caza de brujas
es preciso estudiar qué ejes son más relevantes
para nosotros y en qué ...
Efectivamente, además de la valiosa aportación funcional del producto SonarQube™
consideramos relevante que el modelo de n...
Capítulo #8
¿Cuáles son los tipos de pruebas software?
Un conjunto de actividades de pruebas suele orientase a comprobar d...
Se consideran Pruebas de Caja Negra (“black-box testing”) puesto que valoramos el
comportamiento externo del sistema. Las ...
Componentes (por ejemplo, trazando la jerarquía de llamadas entre elementos). Puesto
que indagamos en el comportamiento in...
Ahora que ya tenemos una buena imagen de los
tipos de pruebas que podemos incorporar para
asegurar la Calidad del Software...
Capítulo #9
Software testing levels onion model
Según avanzamos por el proceso de fabricación de software, nos apoyaremos ...
Así en un ciclo de vida del tipo modelo en V o
secuencial, típicamente buscaremos relacionar
los niveles de construcción c...
componentes del software interactúan correctamente, entre sí y con otras partes del
sistema (como sistemas operativos, sis...
materializarlas: pruebas de aceptación de usuario, pruebas de aceptación operativa o
pruebas de cumplimiento regulatorio s...
Referencias
1. Innovación rentable – Masa K Maeda (blog.panel.es)
2. Syllabus del ISTQB (2011, International Software Test...
2015 Panel Sistemas. Página 56
Capítulo #10
¿Cuánto nos pica un bug?
En aquellos negocios en los que las Tecnologías de la Información son críticas para ...
Escala Scoville SHU
En la actualidad se recurre a medir con precisión la cantidad de capsaicina (componente
químico culpab...
diluida como para ser indetectable. Si lo queremos ver en términos de dinero, equivale a
compensar el picor reconociendo u...
2015 Panel Sistemas. Página 60
Capítulo #11
Aplicar Agile Testing en proyectos grandes y
complejos
En este artículo compartimos nuestras conclusiones par...
Los cambios en los requerimientos no son excepcionales.
Entrega temprana y continua de Software con valor.
La comunicación...
En cualquier caso, antes de incorporar prácticas de Agile Testing en nuestro proyecto, hay
que cuidar algunos aspectos hab...
Agile Testing Quadrants
Sin embargo, no todo es tan fácil. En @PanelSistemas sabemos por
experiencia que existen algunos f...
Testing.
Valor de los Planes de Prueba. Si llegaran a combinarse los riesgos de requisitos
(tanto en anatomía como en esta...
llamen a un profesional.”
En cualquier caso, como señala Rubén González en el blog Think Big, “...en otros casos,
los méto...
Capítulo #12
Razones para practicar la Integración Continua
El objetivo de los equipos de desarrollo actuales es planifica...
El servidor de Integración Continua automatiza diversos pasos en el ciclo de vida del
software. No puede ayudarnos con los...
Jenkins, Team Foundation Server o Solano por ejemplo.
Sin embargo, aplicar Integración Continua (IC) es un proceso doloros...
Integración Continua en el Antiguo Egipto
La Integración Continua es un medio, no un fin.
El objetivo sigue siendo maximiz...
corrección de anomalías.
3. Calidad desde el inicio y adaptación al cambio. Como es posible disponer de un
entorno de demo...
2015 Panel Sistemas. Página 72
Capítulo #13
Software QA - DevOps: hacia la calidad continua
del software
DevOps representa un avance para la ingeniería d...
(centrados en la construcción) y de equipos de operaciones (centrados en la explotación
de los sistemas informáticos en pr...
En el lado práctico de la vida, DevOps va de conectar personas,
productos y procesos.
En definitiva, estamos hablando de c...
Vale, vale … también la entrada en inglés de la Wikipedia para DevOps[11] (justita, pero
su “DevOps (a portmanteau of deve...
Capítulo #14
¿Qué es DevOps 101?
Tras el enigmático título de “DevOps 101“, Antonio Peña del grupo de Madrid DevOps
nos mo...
Todavía la comunidad interesada es informal, sin líderes claros, metodologías o credos.
Como dice Baron Schwartz en la ent...
Entonces, ¿qué es DevOps? ¿Y tú me lo preguntas? DevOps … eres tú … y tú, y tú.
Hablamos de comunicarse y colaborar por un...
2015 Panel Sistemas. Página 80
Capítulo #15
¿Cómo probar aplicando Entrega Continua?
Diseccionar las exigencias de la Entrega Continua de software utiliz...
MadridQA_Continuous_Delivery_Start_n
¿Qué retos plantea para el testing la Entrega Continua?
La velocidad en la entrega. ¿...
requisitos, ¡y así para 9 fases!
La configuración en cada entorno de pruebas era diferente.
Los gestores del equipo de pru...
entrega.
Incluyendo en cada entrega (“build process”) tantas pruebas como sea posible.
Sacando a los probadores (“tester”)...
distribuidos por la organización.
Los números cantan: software en producción cada 4 semanas, mayor productividad del
equip...
tiene que ser alcanzable en el ciclo. Hemos usado muy diversos ciclos.
Tener equipos multidisciplinares (“crossfunctional”...
Capítulo #16
Estrategias de integración entre productos
software
Pain or Gain?
La integración entre productos o aplicacion...
Multitud de conexiones
Dado el estado de cambio permanente que caracteriza a los
sistemas informáticos, las actividades de...
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015
Próxima SlideShare
Cargando en…5
×

El manual de la calidad software - Panel Ssistemas - 2ªedicion2015

1.641 visualizaciones

Publicado el

Publicado en: Ingeniería

El manual de la calidad software - Panel Ssistemas - 2ªedicion2015

  1. 1. El Manual de la Calidad Software Segunda edición En esta segunda edición del Manual de la Calidad Software de Panel Sistemas, hemos querido de nuevo recopilar nuestro mejor conocimiento sobre las buenas prácticas en la actividad de SQA. Para ello, hemos escogido los mejores artículos y opiniones que nuestros expertos han compartido a través del blog de Panel, blog.panel.es, a lo largo de este año 2015. Es muy recomendable complementar esta edición 2015 con la anterior de 2014: contará así con el más amplio repositorio documental sobre Aseguramiento de la Calidad de Software del mercado. Esperamos que lo disfrute y se convierta en su “segundo” libro de cabecera sobre SQA. 2015 - 2016. Panel Sistemas Informáticos. Todos los derechos reservados. 2015 Panel Sistemas. Página 2
  2. 2. INTRODUCCIÓN: SQA, una cuestión de Cultura, Procesos y Herramientas PARTE I- Cultura y SQA Capítulo #1 - Lean Management: Cultura, cambio y liderazgo Capítulo #2 - Calidad y más Calidad...pero ¿y la entrega de Valor? Capítulo #3 - Navegar y disfrutar en equipo Capítulo #4 - One2change, el cambio está en cada uno de nosotros PARTE II - Procesos y SQA Capítulo #5 - Algo pasa con CMMi Capítulo #6 - Entre anomalía, defecto o fallo anda el juego Capítulo #7 - Los 7 ejes de la calidad del código fuente Capítulo #8 - ¿Cuáles son los tipos de pruebas software? Capítulo #9 - El modelo de Testing en capas de cebolla Capítulo #10 - ¿Cuánto nos pica un bug? Capítulo #11 - Agile Testing en proyectos grandes y complejos Capítulo #12 - Razones para practicar la Integración Continua Capítulo #13 - DevOps, hacia la Calidad Continua del software Capítulo #14 - ¿Qué es DevOps 101? Capítulo #15 - ¿Cómo probar aplicando Entrega Continua? Capitulo #16 - Estrategias de integración entre productos software PARTE III - Herramientas y SQA Capítulo #17 - Gestión del Ciclo de Vida con Apache Maven Capítulo #18 - Nexus, gestión de artefactos y otras especies. Capítulo #19 - Git, Control de Versiones Capítulo #20 - ¿Qué es Ansible, y por qué? Capítulo #21 - Testing automático para websites responsive Capítulo #22 - DevOps en las nubes y con Contenedores AGRADECIMIENTOS Índice 2015 Panel Sistemas. Página 3 ÍNDICE
  3. 3. 2015 Panel Sistemas. Página 4
  4. 4. SQA, una cuestión de Cultura, Procesos y Herramientas La fabricación de Software ha cambiado. Hemos evolucionado desde un proceso de creación de software basado en modelos de ciclo de vida secuenciales hacia ciclos de vida ágiles en los que hay una presentación rápida, iterativa e incremental de producto terminado, con numerosos beneficios directos para el proyecto y para el usuario final. En este nuevo escenario, asegurar la Calidad del producto final y entregar el Valor que Introducción: SQA, una cuestión de Cultura, Procesos y Herramientas 2015 Panel Sistemas. Página 5
  5. 5. espera tu Cliente, es el objetivo principal. Aplicando prácticas saludables sobre escenarios como Devops, Integración Continua o Automatización, es posible favorecer el aseguramiento de la Calidad del producto desde el inicio, y maximizar el valor de lo que entregamos. Pero para ello, es necesario cambiar la Cultura, los Procesos y las Herramientas en la construcción de software, hacia un modelo que en Panel Sistemas llamamos fabricación ecoLÓGICA de software. En otras palabras, es necesario revitalizar el Ciclo de Vida en la creación de software, por este orden: Cultura, Proceso y Herramienta. Cambios en la Cultura producen avances más rápidamente en la organización, que solamente cambios en los procesos o las herramientas. 2015 Panel Sistemas. Página 6
  6. 6. Cuando hablamos de cambiar la Cultura en la construcción de software, es necesario que en el nuevo modelo las personas adopten los cambios, asuman los objetivos, y entiendan su nueva función. Por tanto, es muy importante una buena estrategia de Comunicación y Formación, de difusión de conocimientos y buenas prácticas, y de medidas de avance y mejora continua. Así en la primera Parte de este Manual, recopilamos algunos interesantes artículos sobre técnicas de facilitación, acompañamiento y mentoring en la integración y adaptación de modelos Scrum, Kanban o Lean Management en equipos y organizaciones, facilitando el cambio Cultural que requiere el nuevo modelo de fabricación ecoLÓGICA de software. En segundo lugar, la metodología, los procedimientos y las buenas prácticas en tus proyectos deberían de trabajar para ti, y no tú para ellos. Por esta razón, los procesos de Creación de Software deben adoptar un enfoque global e integrado, con una visión completa del proceso, cercano al negocio e involucrando a todas las personas de la Organización. La Parte II de este Manual la dedicamos precisamente a entender algunas metodologías más globales como CMMi, otras más específicas sobre modelos y tipos de pruebas software, y otras buenas prácticas como DevOps, Agile Testing o Integración Continua. Todas ellas mejoran sin duda los resultados y ofrecen mayores garantías de calidad en el producto entregado. Por último, las herramientas sustentan el Ciclo de Vida del software a lo largo de todas sus etapas. Cambiar nuestra Cultura y nuestros Procesos obliga necesariamente a cambiar las herramientas, y para ello es recomendable realizar una selección estratégica de las mismas, alineándolas con nuestra metodología y nuestra cultura, e integrando cada área del proceso de creación de software con una inversión equilibrada en tiempo y coste. La tercera parte de este Manual recopila nuestro análisis de algunas reconocidas herramientas que, bajo nuestra propia experiencia, pueden aportar mucho valor en el nuevo modelo de fabricación ecoLÓGICA de software. Introducción: SQA, una cuestión de Cultura, Procesos y Herramientas 2015 Panel Sistemas. Página 7
  7. 7. En definitiva, como decíamos al principio, los modelos de fabricación de software han cambiado, y las organizaciones deben estar preparadas para ofrecer a sus clientes soluciones realistas y adaptadas a pequeños y grandes proyectos, que buscan obtener de forma satisfactoria el Valor que esperan y rentabilizar su Inversión lo antes posible. 2015 Panel Sistemas. Página 8
  8. 8. PARTE I CULTURA Y SQA "Las personas deben adoptar los cambios, asumir los objetivos y entender su nueva función" PARTE I - Cultura y SQA 2015 Panel Sistemas. Página 9
  9. 9. Capítulo #1 Lean Management: Cultura, cambio y liderazgo Hace unas semanas tuvimos la oportunidad de escuchar durante unas sesiones formativas en Panel Sistemas a nuestros compañeros de Thinking with You (@_twy_) en un curso sobre Lean Management, que yo definiría como una experiencia “religiosa” :-), enriquecedora, motivadora y ¡aguijoneadora de conciencias! Para empezar, Lean no es una metodología de trabajo, sino una filosofía, una forma de pensar focalizada en un objetivo claro: aumentar la productividad y producción, con CALIDAD. Pero lo que a veces olvidamos (con mucha frecuencia) es tener bien identificado el pilar básico para el que hacemos las cosas, que no es otro que el CLIENTE. “Los objetivos de negocio se centran en lo que los clientes quieren, no en lo que nosotros pensamos que necesitan” (sic). Esta tarea de análisis es imprescindible para que nuestras actividades estén orientadas a un fin concreto y encarriladas al máximo rendimiento, con el mínimo desperdicio: hacer 2015 Panel Sistemas. Página 10
  10. 10. MÁS, con MENOS. No obstante ya nos lo avisaron: Lean requiere paciencia, y para lograr los objetivos es necesario aplicar cambios que nos ayuden a estar cada día un poco más cerca de nuestro objetivo. ¡Bienvenido a la calle de los cambios! Y este cambio de mentalidad requiere dedicación y tiempo de una serie de “actores” que han de evidenciar, analizar, comunicar y ejecutar cada uno de los cambios identificados a realizar (El cambio Kotter)… y sin un apoyo expreso de la dirección, es imposible llevarlo a efecto. Parece obvio, pero evidenciar algo que no funciona y que requiere materia gris y acción para cambiar, debe ir más allá de las “sensaciones” y se debe constatar mediante cuadros de mando o mediciones que nos señalen dónde no funcionan las cosas y dónde se ha de aplicar un proceso iterativo para obtener una mejora continua hacia el camino de la perfección. ¿Qué me llevo personalmente del curso? Muchas cosas Por ejemplo, fue muy revelador que, en uno de los ejercicios durante el curso, la gente que participábamos teníamos distintas visiones (y muy enriquecedoras!) de Panel como compañía. Nos dimos cuenta de que unificar una Cultura en la organización es muy necesario, pero también complicado, y de nuevo se requiere del liderazgo de la Dirección para conseguirlo, poco a poco. Para mí, cursos como éste ya suponen de por sí un cambio cultural. También me llevo mucho enriquecimiento personal y profesional. Te das cuenta de que todo suma, de que hay ser más reflexivo y escuchar al de al lado. Y que hay que estar más abierto al cambio, pues por pequeño que éste sea puedes conseguir resultados objetivos y medibles. ¿Y si empezamos cambiando ésto … por esto otro? Capítulo #1 - Lean Management: Cultura, cambio y liderazgo 2015 Panel Sistemas. Página 11
  11. 11. Y en la práctica, ¿en qué creo que puedo aplicar lo que hemos aprendido? Pues creo que empezaré con pequeños cambios. El primero de ellos, poner más foco en el Cliente: escucharle, establecer una relación de mayor confianza y darle realmente el valor que necesita de manera continua y permanente, eliminando el desperdicio. Aportar valor al cliente debería ser nuestro único objetivo. El segundo: Gemba Walk, una pieza clave en el proceso de mejora continua que consiste en “pasear” por nuestras líneas de trabajo, y de nuestros usuarios (el Cliente), para tomar contacto con la realidad de la producción, conocer de primera mano sus problemas y comprenderlos en profundidad. En definitiva, todo esto es posible si existe un apoyo expreso de la dirección como decíamos, si la cultura de la empresa facilita estas tareas (gracias al curso @PanelSistemas) y si existe un equipo motivado detrás que juegue los roles adecuados. El “chapuzón Lean” que nos han dado, ha servido para despejar unas cuantas dudas y desperezarnos. Entre todos, haremos el camino. Como reza kanban: “Comienza donde estés“. Referencias Artículo original: http://blog.panel.es/index.php/lean-management-cultura-cambio-y- liderazgo/ 2015 Panel Sistemas. Página 12
  12. 12. Capítulo #2 Calidad y más Calidad…pero ¿y la entrega de Valor? (Reflexiones de lo que Marketing es a la Calidad, y viceversa.) Aunque parezcan actividades antagónicas, las disciplinas de Marketing y Calidad están más vinculadas de lo que parece. Doy fe de ello. De hecho deberíamos aplicar muchos de los principios del Marketing a la Calidad. Por ejemplo: entendemos por calidad cumplir con los requisitos del cliente, cumplir con sus expectativas. Y para ello, los instrumentos que nos proporcionan las metodologías de Calidad nos permiten “verificar” que se cumple con la calidad esperada. Pero los que trabajamos en Marketing sabemos que cumplir con la satisfacción del cliente es algo más subjetivo, y menos medible. Realmente es una ecuación entre la percepción del cliente con el producto que le entregamos y lo que él esperaba. “Calidad es la entrega satisfactoria del valor esperado” decía nuestro compañero Miguel Ángel Nicolao en este post sobre Innovación Rentable – Masa K. Maeda. Y de eso se Capítulo #2 - Calidad y más Calidad...pero ¿y la entrega de Valor? 2015 Panel Sistemas. Página 13
  13. 13. trata: la calidad técnica, la calidad objetiva, es la que se puede medir, y la que responde a las especificaciones de producción. Pero la verdadera dimensión de la “calidad” es la subjetiva, la percibida. Y esto, sinceramente, es mucho más que el mero cumplimiento estricto de los requisitos del cliente. La calidad debe ser algo más: es precisamente “no cumplir” con las expectativas del cliente, sino ir más allá. Es ofrecerle un valor adicional que no ha pedido, pero que una vez obtenido lo reconoce como esperado. Realmente, la principal diferencia entre ambas disciplinas, Calidad y Marketing, es la PERSPECTIVA. Como decíamos, en la primera la calidad se define desde una perspectiva de la producción. En la segunda, desde una perspectiva de valor. Ambas son indispensables para asegurar la satisfacción final del cliente. Sin embargo, parece obvio que la calidad técnica debe siempre estar implícita a nuestra marca, sea cual sea el segmento al que nos dirigimos y sea lo que sea lo que vendemos. Por ejemplo, el Sr. Masa K Maeda afirma que la calidad es una propiedad intrínseca que se debe trabajar desde el principio porque no se puede añadir al final, ni siquiera con un proceso de inspección QA final. Cumplir con los requisitos del producto que nos pide el cliente SE DA POR HECHO en Marketing. Es la única garantía para mantener nuestra credibilidad y reputación en el mercado. Y por cierto: recuerda que tu competencia tiene los mismos “sellos” de Calidad que tú. En definitiva, hay que convencer a los equipos de que trabajar con calidad consiste en proporcionar al cliente “algo más” que él perciba como beneficio adicional. En software podríamos hablar de seguridad, de procesos de bajo consumo, de mantenibilidad, de 2015 Panel Sistemas. Página 14
  14. 14. control de la deuda técnica, de aseguramiento del uso futuro del software…O un producto/servicio perfectamente alineado con sus objetivos de negocio. ¡Piensa cuál podría ser ese beneficio tangible o intangible para tu cliente, y persíguelo! Imagen del blog: http://www.consultorinternet.com/ El arte está en conseguir primero identificar ese valor que quiere el cliente (aunque él no lo sepa), asegurarte de que es el valor que espera, y desarrollarlo generando ese valor con un beneficio para la Organización. Esta es al final la función del Marketing. No es tan difícil. Pero desde luego hay que cambiar nuestra Cultura, y mejorar nuestras formas de trabajar, nuestros métodos, nuestros procesos. Por este orden. Al menos en IT nos es muy útil apoyarnos en estándares o buenas prácticas que facilitan la entrega satisfactoria de ese valor: CMMi, Scrum, Kanban… De hecho, la combinación de estas nuevas prácticas en nuestros proyectos está siendo para nosotros “EL CAMINO HACIA LA EXCELENCIA” con mayúsculas y su explicación bien merecería otro post. Capítulo #2 - Calidad y más Calidad...pero ¿y la entrega de Valor? 2015 Panel Sistemas. Página 15
  15. 15. Es fundamental asegurarse de que la aplicación de estas metodologías y procesos añaden valor percibido al cliente, porque si no, sólo suponen costes que no implican Valor. Y esto sí es alinear la calidad con tu negocio. En definitiva, ciertos procesos (¿de Calidad?) que se desarrollan de forma rutinaria en muchas empresas no aportan valor al cliente y pueden ser eliminados. El juicio sobre la calidad del servicio/producto lo hace el cliente, no nuestros procesos internos. Por eso, mis procesos de calidad deben estar continuamente adaptándose a las expectativas de mi cliente, de mi negocio. Quizá mi cliente valore otros “servicios” adicionales que yo antes no tenía en cuenta, y no valore los que me empeño en prestar. ¿Os suena? es la famosa Cadena de Valor de Michael Porter, y su aplicación gráfica en Lean Manufacturing a través del método Stream Value Mapping, un modelo que no parece fácil de aplicar pero que permite identificar fuentes de ventaja competitiva en aquellas actividades de la empresa generadoras de valor, eliminando desperdicios. Gracias a un “amigo” por esta referencia. Referencias Artículo original: http://blog.panel.es/index.php/calidad-y-mas-calidad-pero-y-la- entrega-de-valor/ 2015 Panel Sistemas. Página 16
  16. 16. Capítulo #3 #SQA: Navegar y disfrutar en equipo Conclusión: sin trabajo en equipo, respeto, rutina, información y algo de alegría es muy difícil que un barco llegue a puerto, incluso en un “caso de uso” tan benévolo como la navegación fluvial. Un destino cercano puede resultar inalcanzable si no es también un objetivo común, al igual que en el desarrollo de software. Comprobado de primera mano. Así, tras alquilar con cierta ligereza un crucero fluvial en Francia, nos encontramos con que todo un barco de 13,5 metros de eslora era nuestro durante una semana. Nuestro, nuestro. Es decir, nosotros éramos patrón, tripulación y pasaje a la vez. Capítulo #3 - Navegar y disfrutar en equipo 2015 Panel Sistemas. Página 17
  17. 17. Nuestro barco, Le Magnificat Como buenos novatos pedimos explicaciones sobre el manejo de la embarcación, la normativa de navegación pero, sobre todo, que nos expliquen cómo se pasan las exclusas. Las escuetas explicaciones estuvieron a la altura del típico arranque (“kick off”) de los proyectos software. Bien, lo primero hay que organizarse: Provisiones y equipo de emergencia – (Infraestructura). Reparto de tareas. Todos queremos ser el piloto, pero hay muchas más cosas que hacer – (Roles). Libro y ruta de navegación – (Plan, “backlog”). Cultura ¿cornamusa?, maniobras (atracar, soltar amarras y no quedarse en tierra, etc.) y rutinas – (Aseguramiento). En un par de horas ya nos sentimos cómodos. El resto de la semana nos dedicaremos a navegar por los ríos Mayenne y Oudon. Tendremos nuestros momentos de tensión (¿riesgo?), trabajo en equipo, turismo, convivencia y mucho disfrute e incluso, reflexión. Una gran experiencia. De entre mis reflexiones quiero compartir con vosotros lo rentable que resulta construir 2015 Panel Sistemas. Página 18
  18. 18. sobre unas bases adecuadas. También en la construcción de software. Así, perseverando en interiorizar que “la Calidad es una propiedad intrínseca que sucede antes de terminar el producto“, pondremos rumbo hacia maximizar resultados, hasta conseguir que un crucero fluvial sea una experiencia memorable. Collage crucero fluvial Francia ¿Cómo podemos orientarnos hacia maximizar resultados? Pensando a nivel de sistema, ecualizado, integrando. Podemos aplicar diversas técnicas o metodologías, pero la clave es pensar en el conjunto y buscar el equilibrio: ecualizar. Todos llegamos a ser patrón, tripulante y pasajero con el objetivo común de disfrutar cada segundo. Las exclusas hay que pasarlas con cuidado, poniendo atención y en equipo, pero son muy reconfortantes. En la construcción de software las denominamos “Quality Gates” y una forma de visualizarlas es mediante el cuadro de mandos de SonarQube. Una auténtica medida de avance y cumplimiento. Capítulo #3 - Navegar y disfrutar en equipo 2015 Panel Sistemas. Página 19
  19. 19. Esta experiencia también ayuda a establecer claramente la diferencia entre marinero de agua dulce y lobo de mar (con respeto y a mucha honra ;-). Ciertamente, hay diversos grados de complejidad pero comparten los fundamentos y valores. ¡Enrólate en el equipo de Calidad Software intrínseca! Será una experiencia memorable y … puede que también salgáis en el periódico Referencias Artículo original: http://blog.panel.es/index.php/sqa-navegar-y-disfrutar-en-equipo/ 2015 Panel Sistemas. Página 20
  20. 20. Capítulo #4 #one2change – El cambio está en cada uno de nosotros A principios de diciembre se celebró la Conferencia Agile Spain (CAS). Hablamos de una emblemática conferencia apta todos los interesados en el desarrollo de productos software que habilita un sináptico punto de encuentro. Si quieres, el descubrimiento personal y profesional está garantizado. En este artículo quiero contaros mis impresiones en esta mi primera CAS. Se ha tratado de una conferencia grande, rica, con una organización notable y muy buen ambiente. La agenda estaba divida en 6 “tracks” (desarrollando personas, mejorando software, creando equipos, entregando producto, transformando organizaciones y una serie de talleres), además, cada día empezaba y acababa con una “keynote”. Mucha tela. También se habilitó un panel gigante con los valores y principios del Manifiesto Ágil. Una interesante iniciativa que en su parte central ofrecía un espacio para firmas, de forma que nos ayude a recordar su importancia como cimientos del agilismo. Capítulo #4 - One2change, el cambio está en cada uno de nosotros 2015 Panel Sistemas. Página 21
  21. 21. Manifiesto ágil CAS2015 #one2change En cuanto a los contenidos, el espacio web creado para la ocasión – CAS2015 en Agile- spain.org – sigue enriqueciéndose cada día. Resulta un sitio de visita obligada por sus referencias a los contenidos de las distintas charlas, incluidas las grabaciones gracias a la cortesía de los ponentes y la inestimable labor técnica de Autentia. Es una valiosa mina. Mi recomendación es: aprovechad la oportunidad asomaos a todas estas ventanas. cotillead todas las charlas CAS2015. ¡Qué decir de las personas! Como bien señalan en este mismo espacio web, la CAS “es un punto de encuentro con amigos, compañeros y otros profesionales para compartir aprendizajes y encontrar sinergias de colaboración que nos permitan avanzar juntos y continuar evolucionando.” Confirmado. Si todavía no has podido experimentarlo de primera mano, no intentes imaginártelo, acude al próximo evento, meetup, open space, café … lo que sea. Superará todas tus expectativas. 2015 Panel Sistemas. Página 22
  22. 22. Centrándome en mi CAS2015 Acudí con idea de aplicar como criterio de priorización los contenidos del track “Entregando producto” (me debo de estar haciendo mayor) y las charlas en las que no conociera al ponente. Os cuento. Eugenio Moliní asumió el reto de la “keynote” inaugural titulada “Vocación y Vulnerabilidad de un Agente de Transformación”. En la presentación de Eugenio, Vanesa Tejada señaló que pensó en él por el impacto personal que le había causado en un taller anterior y el efecto que tuvieron estas palabras en mi caso fue: escudos abajo, atención al máximo. Como resultado, la charla de Eugenio me arrasó. Me atravesó, encendió velas en zonas profundas de mi espíritu en las que las tinieblas ya se estaban acomodando y me provocó un serio proceso de reflexión. Sinceramente, si al final de esta charla se hubiera suspendido la CAS2015, lo hubiera dado por bueno. La premisa básica en la Teoría del Cambio: “Las personas cambian cuando quieren (y punto).” Por Eugenio Moliní. CAS2015 Keynote Eugenio Molini Capítulo #4 - One2change, el cambio está en cada uno de nosotros 2015 Panel Sistemas. Página 23
  23. 23. Sigamos, ponte cómodo y, por favor, recuerda que “Entregando Producto” era mi mantra. Apertura Entregando Productos – Aritz Suescun Aritz nos plantea: “Os habéis fijado que todo empieza de forma mágica con el Product Backlog.” ¿Qué pasa antes del Product Backlog? ¿De dónde viene esa información? El descubrimiento llama a nuestra puerta. Además, nos muestra su admiración por los responsables de producto (Product owners), “unos auténticos superhéroes”. ¿Serán como Superman?, con superpoderes desde la cuna, o ¿Serán como Batman?, gente normal que con entrenamiento y herramientas consigue destacar como superhéroe. Para los que no somos Superman, nos presenta su kit de herramientas para los responsables de producto (que irá repitiéndose en otras charlas … buena señal). Herramientas para el Product Owner superhéroe – CAS2015 El Síndrome de Niggle, la orientación a Objetos y la Familia de Juan Carlos I – Jorge Uriarte 2015 Panel Sistemas. Página 24
  24. 24. Se trata de una llamada de reflexión sobre el nivel de abstracción a aplicar en el diseño de un producto. Equilibrar entre el nivel de detalle y el avance del producto, diseñar de forma iterativa. Para ilustrar su punto de vista, se apoyó en el síndrome de Niggle y en el trabajo del pintor Antonio López. ¿Eterno dilema? How to bet in Montecarlo and end up with some money in your pocket – Pablo Domingo de la Orden. Buenas noticias, es posible trabajar en la predictibilidad, afinar nuestra respuesta a cuándo terminaremos un producto o cuánto costará … aunque … “todos los modelos fallan porque la realidad es mucho más compleja, el valor está en las conversaciones”. Una sesión muy interesante, densa por obligación pero que nos presenta el método Monte Carlo, la entrada a la madriguera del país de la simulación. "Plans based on averages are wrong on average" No es posible esconder la complejidad de los datos en la media Si la grabación llega a estar disponible, os la recomiendo porque es una buena forma de bautizarse. En todo caso, es necesario trabajarse la predictivilidad para sacarle rendimiento. El arte de decir que no [pdf] – Carlos Hernández (Quaderno.io) Me gustó -mucho- la claridad y convicción con la que Carlos nos transmitió su mensaje. Fue reventando una a una todas las tentaciones que los constructores de producto van a ir encontrándose en su camino: “con esta funcionalidad se disparará el interés de los usuarios”, “solo os llevará una jornada”, “este cliente está a punto de abandonar”, “podemos hacer que sea opcional”, “no tenemos nada más planificado”, “todo el mundo lo quiere”, “nuestro competidor ya lo Capítulo #4 - One2change, el cambio está en cada uno de nosotros 2015 Panel Sistemas. Página 25
  25. 25. tiene”, “si no lo hacemos, lo hará otro”, “el jefe lo quiere”, “esta es LA funcionalidad”. En conclusión, Carlos nos señala que decir “no” es un ejercicio de responsabilidad para con el futuro de nuestro producto. Su propuesta: “Es mejor que el cliente se adapte al usuario antes que el producto se adapte a los clientes”. En el resumen de su charla nos lo indica: En esta pequeña charla te contaré porqué el desarrollo de un buen producto está ligado a la frecuencia de uso de la palabra “no”. No un “quizás”. No un “más adelante”. Un simple “no”. El Big Data también es ágil (o debería) – Juan Tomás García En sesión corta, Juan Tomás nos puso al día en Big Data y nos contagió su entusiasmo por las posibilidades de esta disciplina. Inicialmente nos recordó que los procesos de analítica de datos tradicionales siguen metodologías secuenciales que resultan demasiado lentas entregando resultados y demasiado pesadas para modificarlas y adaptarlas a las cambiantes necesidades de negocio. Afortunadamente, gracias a los marcos ágiles, la filosofía Lean y las nuevas tecnologías en Big Data se han podido implementar nuevas formas de hacer análisis que permiten un diálogo productivo entre datos y negocio. El foco está en contener el “Time to answer”, trabajando el Big Data con Productos Mínimos Viables (MVP), midiendo y pivotando. Para terminar, un viaje relámpago por las tecnologías Big Data, desde MapReduce y Apache Hadoop hasta su todopoderoso equipo fantástico: la arquitectura Kappa, formada por Kafka + Spark + NOSql + Scala. Design Thinking: the power to accept every challenge – Mariana Ivanova (SAP) 2015 Panel Sistemas. Página 26
  26. 26. ¿Cómo conectar con la esencia de un problema? ¿Cómo dinamizar la innovación en producto? Mariana nos cuenta que su particular periplo en búsqueda de respuestas se ha consolidado en la aplicación de la metodología Design Thinking en equipos multidisciplinares. Dedicamos la sesión a recorrer las cinco etapas de este proceso no lineal: Empatiza, Define, Idea, Prototipa, Testea. Estas son algunas de las píldoras que nos regaló: Empatiza: ponte en los zapatos de los demás, pregunta 5 veces ¿por qué? – Libro: Interviewing Users de Steve Portigal Define: buscamos establer el Punto de Vista (POV – Point-of-View). Un punto de vista bien definido se enfoca en un problema específico. “Storytelling” es una interesante herramienta para ello, nos señala. “Before start working hard, make sure you are working on the right thing”. by Marvin Liao Idea: Empezamos a buscar soluciones, numerosas y variadas. Nos detalla la “tormenta de ideas inversa” como una técnica particularmente interesante. – Pista: Artículo sobre "The power of bad ideas by Steve Portigal". Prototipa: “Lo mejor para adquirir experiencia es experimentar”, por ello, hagamos prototipos de forma rápida y barata, que nos permita fallar de forma temprana y frecuente (pero no mortal, ni siempre). Pisamos territorio ya visitado en este blog: Pretotipa y prueba. - Caso práctico: "Dark horse prototype" (Stanford Univ.). Prototipamos sin descartar ninguna opción, así incluso el peor caballo (“the dark horse”) tiene opciones de ganar. Capítulo #4 - One2change, el cambio está en cada uno de nosotros 2015 Panel Sistemas. Página 27
  27. 27. Hablamos de p_e_r_s_e_v_e_r_a_n_c_i_a, solo te diré que James Dyson (el de las aspiradoras sin bolsa) realizó 5.127 prototipos. Prueba: No te conviertas en un vendedor de tu idea, busca y escucha opiniones. – Libro: The Mom test de Rob Fitzpatrick, buscando el “product market fit”. Estamos ante un proceso iterativo e incremental. Como deberemos pasar varias veces por estas etapas y superar grandes dosis de frustración, mejor que busquemos el niño que todos llevamos dentro “Do not fall in love with the process, fall in love with the problem and no power can stop you from changing the world” by Mariana Ivanova Persuading the business guys – Gerardo Ponte Una valiosa sesión en la que Gerardo nos comparte la experiencia que han vivido en el banco BBVA para conseguir la inmersión de los equipos de negocio en las dinámicas propias de los marcos de trabajo ágiles (Scrum en su caso). El recorrido fue exhaustivo y clarificador: por qué los modelos en cascada son confortables para los “chicos de negocio” y qué aspectos de los marcos ágiles ofrecen oportunidades para reducir fricción y potenciar el sentido de propiedad del producto. La importancia de buscar contextos de trabajo comunes, cuidar los miedos y trabajar – intensamente- en el descubrimiento (han aplicado Design Thinking, Story Mapping, Storytelling, Productos mínimos viables, etc). El punto en el que han visto más problemas y resistencias es formalizando la etapa de Definición. En su caso, el intento de utilizar el lenguaje Gherkin fue un absoluto fracaso. En consecuencia el equipo se reorganizó y definió un proceso 2015 Panel Sistemas. Página 28
  28. 28. para establecer los criterios de aceptación, consiguiendo una mejora espectacular al aplicarlo a las historias de usuario. Pista: Inspirarse en el The three amigos de la Scrum Alliance. Economía del Software y dependencias: dilemas del software desacoplado – Luis Artola y Guillermo Gutiérrez Considero que esta fue mi charla estrella, al margen de la “keynote” de Eugenio Moliní. La parte técnica de la charla fue una reflexión sobre el impacto de las dependencias del software en su rentabilidad, relevante. Destacado: la Inversión de Control como contramedida a las dependencias, las arquitecturas hexagonales y recordar los seis principios olvidados del diseño Orientado a Objetos, extended S.O.L.I.D. El premio gordo vino de la necesidad de esta fantástico descubrimiento (Luis y Guillermo) de tener su suelo bajo control. Su trabajo de cimentación intelectual produjo una introducción de oro puro sobre Economía del Software para torpes. En cuestiones de economía no es necesario inventarnos nada, aprendamos este contexto (“business mindset”), es necesario para entablar conversaciones productivas con las áreas de negocio y construir relaciones de confianza. Economics of Software economics (collage) La gente de negocio se centra en los costes visibles, pero los costes son menos importantes que el valor, el riesgo o la deuda. Todo se acaba Capítulo #4 - One2change, el cambio está en cada uno de nosotros 2015 Panel Sistemas. Página 29
  29. 29. Y con esto se terminó mi asistencia a charlas del track “Entregando Producto”. Muy intenso, con una clara línea que lleva a trabajar en el acercamiento hacia las áreas de negocio (“Business mindset”) y a avanzar juntos en el descubrimiento del mercado. Se quedan en el tintero tres “keynotes”, otras charlas y talleres (gracias Diego Rojas por reconducirme al taller con Tim Ingarfield). Eso sí, me ratifico en que todo el que quiera, con el conjunto de contenidos generados por la CAS2015 puede estar muy ocupado hasta que llegue la CAS2016. Sin duda Para terminar, una vez más quiero agradecer a @JTuregano por animarme a asistir y a @Danipise los buenos ratos que pasamos. La CAS volvió a Madrid por suerte para mi y ha sido una inolvidable experiencia ¡un novato felíz! El slogan de la CAS2015 ha sido #one2change y expresa el mensaje fundamental: – El cambio está en cada uno de nosotros – Referencias Artículo original: http://blog.panel.es/index.php/one2change-una-de-cas-2015-madrid/ 2015 Panel Sistemas. Página 30
  30. 30. PARTE II PROCESOS Y SQA "La metodología, los procedimientos y las buenas prácticas en tus proyectos deberían de trabajar para ti, y no tú para ellos". PARTE II - Procesos y SQA 2015 Panel Sistemas. Página 31
  31. 31. Capítulo #5 Algo pasa con CMMi Agilismo, Conocimiento, Seguridad, Innovación… ¡Lo quiero TODO! ¿Qué le está pasando a CMMi? La respuesta a esta pregunta la encontramos el pasado día 2 de Diciembre, en la IX Semana del CMMi y la Mejora de la Calidad TIC, un evento que se celebra anualmente en Madrid organizado por Caelum y dirigido por Ramiro Carballo, y en el cual tuvimos el placer de participar. Sí, sí…. tenía pendiente de redactar este post. El resumen de lo que se presentó en esta Jornada lo dice muy claramente Caelum en la agenda del programa: “Un modelo con más de 20 años que se diseñó para cubrir la necesidad del Departamento de Defensa de los Estados Unidos en materia de software, se adapta a los nuevos tiempos.” 2015 Panel Sistemas. Página 32
  32. 32. Nuevo logo CMMi-DEV para Panel Sistemas Una conclusión que quedó perfectamente reforzada en cada una de las ponencias que escuchamos durante la mañana, incluida la nuestra, y que está enmarcada en la iniciativa CMMi NeXT Gen, toda una declaración de intenciones. Empecemos por la gran importancia que se le está dando a la CiberSeguridad en el modelo CMMi. En este sentido, hay en marcha varias iniciativas como la incorporación de prácticas de codificación segura del software, en colaboración con Siemens y Oracle. Recomiendan 4 nuevas áreas de proceso para el modelo CMMi-DEV e incluyen guías de codificación en Java teniendo en cuenta aspectos seguros. También nos presentaron el nuevo modelo CERT- RMM (Resilience Management Model), para gestionar la capacidad de la organización a la hora de asumir situaciones límites (disrupciones) y continuar operando el negocio. Nada menos que 26 áreas de proceso en 4 categorías (Ingeniería, Gestión de Empresa, Gestión de la Operación, Gestión de los Procesos). Agilismo y CMMi. Qué gran tema :-). Pues bien, aunque al principio ambas metodologías pueden parecer incompatibles, no lo son. Ambas persiguen un objetivo común, aunque basan sus esfuerzos en competencias distintas para alcanzarlo. Por eso realmente creo que el éxito está en integrarlas, no en combinarlas, creando así un mayor valor añadido al proyecto. La clave está en ser realistas y ofrecer soluciones pragmáticas que realmente funcionen – para el producto y para el cliente. Sobre ello precisamente giró el contenido de nuestra ponencia. Miguel Ángel Nicolao, CIO en @PanelSistemas, contó muy entretenida y brillantemente cómo en Panel (una empresa CMMi-DEV nivel 3 y CMMi -SVC nivel 2) hemos cruzado el precipicio hacia el Agilismo. Hablamos de muchas historias de éxito, y “algunas” de fracaso, pero sobre todo compartimos muchas reflexiones y lecciones aprendidas en el día a día de los equipos y de los proyectos, que dan para escribir otro post!. Capítulo #5 - Algo pasa con CMMi 2015 Panel Sistemas. Página 33
  33. 33. Pasarela de Holzarte Alrededor de este tema también destacamos la intervención de Theodora Bozheva (Berriprocess) y su ponencia ¿Cómo aligerar CMMI con KANBAN?. Se trata de cómo obtener la esencia de CMMI a través de Kanban, construyendo procesos sostenibles que permitan conseguir el objetivo del proyecto: aumento de la visibilidad y de la comunicación, creación de valor, eliminación del desperdicio, motivación del equipo. Fundamental. Y cerramos este capítulo de Agilismo con la aplicación práctica que Ramiro nos ofreció de las métricas para monitorizar proyectos ágiles subcontratados (adquisición de software): Bar chart of velocity, para medir la velocidad de entrega por puntos de historia; Sprint burn-down; Story points entregados por sprint; Defectos entregados acumulados; Trabajo en progreso, etc. Sobre la Gestión del Conocimiento, fue muy interesante la experiencia de Babel Sistemas con su Centro de Mantenimiento de Aplicaciones, en el que uno de sus pilares básicos es la Gestión del Conocimiento aplicada, basada en los modelos de Nonaka y Takeuchi: cómo pasar del conocimiento tácito al conocimiento explícito. Todo ello en un ambiente de conocimiento accesible y medible a través de herramientas como un CM welcome package, wikis, base de datos de lecciones aprendidas y compartidas, y herramientas 2015 Panel Sistemas. Página 34
  34. 34. colaborativas. Al hilo de esto, también es interesante la colaboración que nos presentó Ramiro entre el SEI y el EDM (Enterprise Data Management Council): el nuevo modelo DMM – Data Management Maturity, para mejorar la gestión de activos de información críticos. Y por último, Innovación. En esta categoría incluyo otras cosas que me parecieron interesantes, ¿innovadoras?, del modelo. La primera, el aprovechamiento de las sinergias en procesos comunes de la Gestión de Servicios ISO 20000 y CMMI-SVC, y la experiencia de “aprender a remar al unísono” que nos contó Unisys usando CMMI-DEV y CMMI-SVC para afrontar la diversidad de proyectos que abordan. Y por último, otras novedades curiosas en el modelo CMMi: la generación de un entorno de innovación durante el proceso Scampi; la iniciativa formativa CMMi Master (300 horas de formación), y la posibilidad para las empresas de un Action Plan Reappraisal (APR) en el proceso Scampi, que suscitó un intenso debate con opiniones encontradas. En definitiva: creo que esta Jornada reflejó claramente lo que nos viene sucediendo a las organizaciones acreditadas en este modelo en los últimos años. Las tripulaciones están cansadas, y en algunos casos frustradas, de la disciplina marinera :-). Aparece la fascinación con las experiencias ágiles, y también inquietudes sobre otros aspectos a considerar en el desarrollo de software, como es la ciberseguridad. Capítulo #5 - Algo pasa con CMMi 2015 Panel Sistemas. Página 35
  35. 35. Pero en muchos casos, Scrum y su delimitación en temas como QA, arquitectura, seguridad, requisitos o gestión de la contratación hace que los clientes no quieran ni oír hablar de ello. Por eso tras un satisfactorio recorrido por el mundo CMMi, algunas organizaciones necesitamos encontrar una pasarela similar a la de Holzarte. ¿Qué hacer? Bueno, ya lo dice el propio CMMI Institute: Adáptate. Evoluciona. Acelera. Quedarse quieto no es una opción. Referencias Artículo original: http://blog.panel.es/index.php/algo-pasa-con-cmmi/ 2015 Panel Sistemas. Página 36
  36. 36. Capítulo #6 Entre anomalía, defecto o fallo anda el juego ¿Cual es la diferencia entre un defecto y un fallo en un sistema informático? Para la mayor parte de nosotros (como usuarios), no hay ninguna diferencia: “Apunta este fallo, esto no hace lo que yo quería”. Sin embargo, si estamos utilizando un software garantizado no debemos colocar todas nuestras decepciones en la bandeja de “un fallo: me lo deben”. No hay garantía que lo resista. Por ello, es necesario diseccionar la situación para poder catalogar correctamente sus causas y consecuencias. Ya empezamos. Bien, ¿Qué es un <fallo> en un sistema software? Puesto que tenemos todo un instituto internacional especializado en la certificación de profesionales de Pruebas Software, el “ISTQB”, veamos cómo lo definen: fallo es la “desviación del componente o del sistema respecto de prestación, servicio o resultado esperado.” Es decir, nos señalan que un fallo es la incapacidad de un sistema software o de un Capítulo #6 - Entre anomalía, defecto o fallo anda el juego 2015 Panel Sistemas. Página 37
  37. 37. componente para realizar las funciones solicitadas dentro de unos márgenes de rendimiento requeridos. Vamos, que el sistema software tiene un comportamiento decepcionante. Como el sistema software ha fallado, ¡Que lo arreglen!. En primera instancia, cualquier decepción en el comportamiento del sistema la catalogamos como anomalía. Debemos tomarlo como el punto de entrada para cualquier forma de gestión de la Calidad del Software que utilicemos. Entonces, ¿Qué es una <anomalía>? Formalmente, anomalía es “cualquier condición que se desvíe de las expectativas basadas en las especificaciones de requisitos, documentos de diseño, documentos de usuario, estándares, etc., o de la percepción o experiencia de alguien. Las anomalías pueden ser encontradas durante, aunque no se limitan sólo a, revisiones, proceso de pruebas, análisis, compilación, o uso de productos de software o documentación aplicable. [IEEE 1044]” [Según el instituto internacional dedicado a la certificación de profesionales de Pruebas Software (ISTQB)]. Anomalía: Cualquier condición del sistema software que se desvíe de nuestras expectativas. Nada más y nada menos. Tranquilidad. Es cierto que estamos decepcionados y la calidad del producto se resiente, pero todavía no sabemos en qué momento la construcción del producto software y nuestras expectativas se desconectaron. Aunque es claro que la detección temprana de anomalías ahorra dinero y decepciones, la caza de brujas tiene que esperar. Habitualmente las anomalías son tratadas como incidentes. Su tratamiento nos llevará hacia catalogar la causa de nuestra decepción como defecto, nueva funcionalidad o como un sueño imposible. 2015 Panel Sistemas. Página 38
  38. 38. El sueño de E.T. Entonces, ¿Qué es un <defecto>? Volviendo a tirar de formalismo ISTQB, un defecto es una “imperfección en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas, por ejemplo una sentencia o una definición de datos incorrectas. Si se localiza un defecto durante una ejecución puede causar un fallo en el componente o sistema.” [Según el instituto internacional dedicado a la certificación de profesionales de Pruebas Software (ISTQB)]. Atentos, hablan de que se “falle en desempeñar las funciones requeridas”. En los defectos, nos quedamos sin espacio para nuestros sueños y empieza a funcionar la garantía de la garantía. Un defecto es lo mismo que una falta (“fault”), problema o “bug”. Catalogando los tipos de defectos podremos elaborar la Taxonomia de “bugs” sobre la que apoyar nuestro sistema de gestión de incidentes (“defect management tool”). Cada defecto que se introduce en el software es como resultado de un error. ¡Ajá, mi garantía! Entonces, ¿Qué es un <error> en el software? Capítulo #6 - Entre anomalía, defecto o fallo anda el juego 2015 Panel Sistemas. Página 39
  39. 39. Igual no te lo imaginas, el ISTQB establece que un error es una “acción humana que produce un resultado incorrecto. [Según IEEE 610]”. Centrándolo en la construcción de software, un error es un fallo, mala concepción (“misconception”) o mala compresión (“misunderstanding”) por parte del desarrollador de software. Nota: Léase desarrollador software en sentido de involucrado en el proceso de construcción software, es decir, incluye ingenieros software, programadores, analistas, ingenieros de pruebas, etc. Ya tenemos la secuencia de los hechos: el error humano cometido inyecta un defecto en el software que, ocasionalmente, se observa como una anomalía a causa de un comportamiento incorrecto, no acorde a lo especificado, que finalmente provoca el fallo del sistema software. En esta secuencia hemos dejado al margen el conjunto de anomalías motivadas porque el sistema no satisface las expectativas -no expresadas- del cliente. Su gestión requiere de una absoluta vocación por el descubrimiento y la detección temprana, de forma que la adaptación a las expectativas del cliente se haga con el menor desperdicio posible. Si queréis profundizar en cómo coordinar estas actividades en vuestro ciclo de contrucción de software, te invitamos a ponerte en contacto con nosotros para conversar sobre cómo desde el Aseguramiento de la Calidad Software (SQA) se puede impulsar la “entrega satisfactoria del valor esperado”, como máxima expresión de la Calidad adecuada al propósito. 2015 Panel Sistemas. Página 40
  40. 40. Panel Servicios SQA Referencias Artículo original: http://blog.panel.es/index.php/softwareqa-entre-anomalia-defecto-o- fallo-anda-el-juego/ Capítulo #6 - Entre anomalía, defecto o fallo anda el juego 2015 Panel Sistemas. Página 41
  41. 41. 2015 Panel Sistemas. Página 42
  42. 42. Capítulo #7 Los 7 ejes de la calidad del código fuente Analizar sistemáticamente la salud de nuestros desarrollos software y sintetizarla en los 7 ejes de la Calidad Software es el leitmotiv del producto SonarQube™, proyecto de código abierto distribuido bajo licencia LGPL v3. La silueta de su cuadro de mandos (“dashboard”) es ya imborrrable en las retinas de muchos equipos de desarrollo. ¿Cuales son los 7 ejes sonar de la Calidad Software? el Código duplicado, la adherencia a Estándares de codificación, las Pruebas Unitarias, la Complejidad del código, las Evidencias de Fallos Potenciales, el nivel de Comentarios, y la valoración sobre Diseño y Arquitectura. Capítulo #7 - Los 7 ejes de la calidad del código fuente 2015 Panel Sistemas. Página 43
  43. 43. Unas líneas de trabajo (de análisis) que arrancan desde la versión 2.0 de sonar, allá por los albores del año 2010. Con el tiempo este enfoque ha ganado en cuerpo, aromas y matices – como los buenos vinos – hasta consolidar un excelente maridaje con el método SQALE (“Software Quality Assessment based on Lifecycle Expectations”), reconocido archienemigo de la deuda técnica. En este artículo no vamos a desarrollar los detalles del conocido método SQALE, pero al menos queremos reseñar que está pensado para ser automatizado, construido alrededor del control de la deuda técnica (lo que supuso un valioso cambio de paradigma) e impulsado por Jean-Louis Letouzey, al hilo de una investigación interna realizada en la empresa inspearit. Volveremos, es una valiosa píldora cultural. Siguiendo con los cuadros de mando (“dashboards”) para gestionar la calidad del software conforme a los siete ejes técnicos citados, el punto fuerte de SonarQube™ es su capacidad para integrar la gestión de diversas herramientas de análisis de código fuente. Si cambiamos de perspectiva, a la gente de SonarSource les gusta llamarlos “los siete pecados del desarrollador”: 1. Tener líneas de código duplicado (“Duplicated code”). 2. No respetar los estándares de codificación y las mejores prácticas establecidas (“Coding standards”). 3. Tener una cobertura baja (o nula) de pruebas unitarias, especialmente en partes complejas del programa (“Unit tests”). 4. Tener componentes complejos y/o una mala distribución de la complejidad entre los componentes (“Complex code”). 5. Dejar fallos potenciales sin analizar (“Potential bugs”). 6. Falta de comentarios en el código fuente, especialmente en las APIs públicas (“Comments”). 7. Tener el temido diseño spaghetti, con multitud de dependencias cíclicas (“Design and architecture”). ¡Cuidado! No emocionarse, por favor mantengan en todo momento los brazos dentro del vagón… ni utilizen “selfie-sticks”. 2015 Panel Sistemas. Página 44
  44. 44. Antes de lanzarnos a una irracional caza de brujas es preciso estudiar qué ejes son más relevantes para nosotros y en qué medida. Por ejemplo, deberemos evitar hipocresías como lipotimias por una baja adherencia a estándares de codificación que nadie ha definido. Todo tiene un coste, tanto hacer algo como no hacerlo, así que lo más sensato (y rentable) es estudiar la situación, establecer un objetivo y un plan de trabajo paulatino. Como explicamos durante el evento organizado por @PanelSistemas sobre fabricación ecoLÓGICA de software, integrando acciones de mejora continua en los ciclos de desarrollo se obtienen unos elevados Retornos de Inversión (ROI). El resultado merece el esfuerzo. Para que lo podáis valorar vosotros mismos os incluimos la refencia a un par de instancias SonarQube™ (enjoyadas a tope): Dashboard Sonar EXOplatform Sonar: Un producto exhaustivo y gratuito. ¿No será otro unicornio más? Capítulo #7 - Los 7 ejes de la calidad del código fuente 2015 Panel Sistemas. Página 45
  45. 45. Efectivamente, además de la valiosa aportación funcional del producto SonarQube™ consideramos relevante que el modelo de negocio de su fabricante (SonarSource) debe ser compatible con vuestros umbrales de rentabilidad. La descripción del producto que realizan nos parece de por sí reveladora de su estrategia “™”: SonarQube™ software (previously known as “Sonar”) is an open source project hosted at Codehaus. Download and install your own copy. Version: 5.1.1 (Jun 5, 2015) distributed under license LGPL v3. El modelo de negocio se basa en recortar funcionalidades de la versión gratuita (“Community”) e incorporarlas en forma de extensiones (“plug-in”) en las diversas ediciones comerciales. Es bastante fácil plantarse en los 50.000 EUR anuales, perfectamente razonables en un proyecto de 50 personas que quieran disponer de estos cuadros de mando “para currar”. Por último, como bien señalaba Allard Buijze: Sin perder de vista que las métricas son una excelente ayuda, sigue siendo necesario que los equipos de trabajo analicen, entiendan y ponderen los resultados. Por desgracia, ni siquiera unas métricas excelentes garantizan un proyecto software exitoso. Siempre será necesario combinar un buen proceso de trabajo, una adecuada gestión del proyecto, arquitectos centrados y un equipo de interesados implicado para asegurar la debida entrega de valor a nuestros clientes. En todo caso, nada que no pueda arreglar un experto como bien se explican en este divertido vídeo (7 minutos, en inglés con subtítulos): “The expert”. (Gracias Cosme) Referencias Artículo original: http://blog.panel.es/index.php/softwareqa-los-7-ejes-de-la-calidad-del- codigo-fuente/ 2015 Panel Sistemas. Página 46
  46. 46. Capítulo #8 ¿Cuáles son los tipos de pruebas software? Un conjunto de actividades de pruebas suele orientase a comprobar determinados aspectos de un sistema software (o de una parte del mismo). Continuando así con nuestro anterior artículo sobre el modelo de cebolla para los Niveles de Pruebas Software, y siguiendo las directrices del ISTQB, acotaremos los Tipos de Pruebas Software en función del objetivo en que se centran. En primer lugar tenemos las Pruebas Funcionales. Típicamente encontraremos el comportamiento del sistema, subsistema o componente software descrito en especificaciones de requisitos o casos de uso, aunque también puede no estar documentado (“que funcione como el sistema al que sustituye”) . Es decir, con las funciones establecemos “lo que el sistema hace”. Estas pruebas se definen a partir de funciones o características (como decimos, bien descritas en documentos o bien interpretadas por los probadores) y su interoperabilidad con sistemas específicos, pudiendo ejecutarse en todos los niveles de pruebas (componentes, integración, sistema, etc). Capítulo #8 - ¿Cuáles son los tipos de pruebas software? 2015 Panel Sistemas. Página 47
  47. 47. Se consideran Pruebas de Caja Negra (“black-box testing”) puesto que valoramos el comportamiento externo del sistema. Las Pruebas de Seguridad o las Pruebas de Interoperabilidad entre sistemas o componentes son casos especializados de las pruebas funcionales. En segundo lugar figuran las Pruebas no Funcionales que incluyen las pruebas de: Rendimiento, Carga, Estrés, Usabilidad, Mantenibilidad, Fiabilidad o Portabilidad, entre otras. Por tanto se centran en características del software que establecen “cómo trabaja el sistema“. Estas pruebas también pueden ejecutarse en todos los niveles de pruebas. Las características no funcionales del software se pueden medir de diversas maneras, por ejemplo, por medio de tiempos de respuesta en el caso de pruebas de rendimiento o por número máximo de sesiones en pruebas de estrés. Puesto que las Pruebas no Funcionales normalmente consideran el comportamiento externo del sistema, en la mayoría de los casos se utilizan técnicas de Pruebas de Caja Negra. A continuación, en tercer lugar, tenemos las Pruebas Estructurales. Nuevamente pueden ejecutarse en todos los niveles de pruebas (ya sabéis: componentes, integración, sistema, etc.) y encajan muy bien si hemos utilizado técnicas de especificación de la estructura o arquitectura del Software. Es posible aplicar técnicas estáticas de análisis de código. Para expresar el alcance con un conjunto de pruebas (“test suite”) que ha cubierto la estructura o arquitectura en cuestión, se utiliza el concepto de Cobertura (“Coverage”), normalmente en forma de porcentaje. Es especialmente habitual utilizar herramientas de apoyo para calcular la cobertura del código en el caso de Pruebas de Componentes o en Pruebas de Integración de 2015 Panel Sistemas. Página 48
  48. 48. Componentes (por ejemplo, trazando la jerarquía de llamadas entre elementos). Puesto que indagamos en el comportamiento interno, estas pruebas se denominan también Pruebas de Caja Blanca (“white-box testing”). Finalmente, el cuarto tipo de pruebas que nos presenta el ISTQB son las pruebas derivadas de la realización de cambios: las Pruebas de Regresión y las Re-pruebas. Una vez que un defecto ha sido corregido, toca volver a probar el software para confirmar que el defecto ha sido eliminado. Son pruebas repetidas o Re-Pruebas. Las Pruebas de Regresión consisten en volver a probar un componente, tras haber sido modificado, para descubrir cualquier defecto introducido, o no cubierto previamente, como consecuencia de los cambios. Los defectos pueden encontrarse tanto en el software que se ha cambiado como en algún otro componente. Se ejecutan cuando se cambia el software o su entorno. El criterio para decidir la extensión de estas Pruebas de Regresión está basado en el riesgo de no encontrar defectos en el software que anteriormente estaba funcionando correctamente. Las Pruebas de Regresión se realizan sobre un componente ya probado, para verificar que no presenta nuevos defectos cuando se realiza una modificación después de dichas pruebas. Este tipo de pruebas deben ser repetibles si han de usarse para pruebas de confirmación (o aseguramiento) y regresión (como Sondas de Disponibilidad, por ejemplo). Los conjuntos de pruebas de regresión (“Regression test suites“) suelen ser bastante estables por lo que son muy buenos candidatos para actividades de automatización de pruebas. Quizá ya no os sorprenda que estas pruebas también puedan ejecutarse en todos los niveles de pruebas e incluyen casos de prueba de los tipos vistos anteriormente: Pruebas Funcionales, No Funcionales y Estructurales. Capítulo #8 - ¿Cuáles son los tipos de pruebas software? 2015 Panel Sistemas. Página 49
  49. 49. Ahora que ya tenemos una buena imagen de los tipos de pruebas que podemos incorporar para asegurar la Calidad del Software (SQA), es más fácil que entendamos que se trata de una actividad que requiere una elevada capacidad de adaptación de las cargas de trabajo, así como de una suficiente especialización. Por ello, en @PanelSistemas hemos consolidado nuestra orientación hacia modelos de factoría, os lo contamos en nuestro artículo: “el Testing bajo modelos de factoría“. ¿Echas en falta algún tipo de prueba software? ¡Pruébanos! Referencias Algunas referencias sobre este tema que os proponemos son: Descarga del Syllabus del ISTQB (2011, International Software Testing Qualification Boards). Espacio web para estudio de la certificación ISTQB. Artículo sobre Niveles de Pruebas representados visualmente con un Modelo de Capas de Cebolla: Software Testing Levels Onion Mode Artículo original: http://blog.panel.es/index.php/software-qa-cuales-son-los-tipos-de- pruebas-software/ 2015 Panel Sistemas. Página 50
  50. 50. Capítulo #9 Software testing levels onion model Según avanzamos por el proceso de fabricación de software, nos apoyaremos en pruebas a diversos niveles para mantener la confianza en el producto final. A continuación os presentamos estos Niveles de Pruebas Software utilizando un modelo de representación en capas, porque … Las cebollas están hechas de capas sucesivas, siendo cada capa más potente e intensa que la anterior. Además, las cebollas -a veces- nos hacen llorar. Las actividades de construcción de software y las de pruebas deben de convivir armoniosamente. Una concepción aislada del “Testing” no es productiva. Por tanto, se requieren planteamientos de pruebas acordes a los diversos ciclos de vida de desarrollo. (Mapping SW V-model and ISTQB Testing levels) Capítulo #9 - El modelo de Testing en capas de cebolla 2015 Panel Sistemas. Página 51
  51. 51. Así en un ciclo de vida del tipo modelo en V o secuencial, típicamente buscaremos relacionar los niveles de construcción con los niveles de pruebas de componentes, integración, sistema y aceptación. Si por el contrario optamos por modelos de construcción iterativos (o incrementales), como los modelos de desarrollo ágil por ejemplo, aplicaremos al resultado de cada iteración niveles de pruebas (componentes, integración, sistema y aceptación) acordes a su tamaño y alcance. La naturaleza incremental del proceso nos llevará de forma natural a potenciar aspectos como regresión o automatización a todos los niveles (por pura supervivencia ;). El modelo de capas de cebolla para los Niveles de Pruebas (según ISTQB) que hemos elaborado para vosotros permite visualizar el volumen potencial de cada nivel, su interdependencia y su criticidad (o sabor). La capa más externa nos presenta las Pruebas Unitarias. Suelen ser unas pruebas relativamente pequeñas y numerosas. Se tiende a envolver con ellas buena parte de los objetos, clases o módulos construidos. Se pueden incluir pruebas funcionales y no funcionales, lanzándose típicamente con acceso al código en construcción y con el apoyo de entornos de desarrollo. Suele dar lugar a la detección de defectos que son corregidos rápidamente por el desarrollador. El siguiente nivel, Pruebas de Componentes, es muy similar al de Pruebas Unitarias. La complejidad de los elementos a probar nos marca si existe diferencia entre ellas y el aislamiento del resto de elementos a probar nos marca la frontera con la siguiente capa. Llegamos a una capa más sabrosa, el nivel de Pruebas de Integración. Estas pruebas suelen ser realizadas por el equipo de desarrollo y permiten comprobar que los 2015 Panel Sistemas. Página 52
  52. 52. componentes del software interactúan correctamente, entre sí y con otras partes del sistema (como sistemas operativos, sistemas de archivos o hardware). El foco de las pruebas es la interacción. Saltan las primeras chispas. Avanzamos, el nivel de Pruebas de Sistema es la siguiente capa de nuestra cebolla. Cosa seria, algunas lágrimas están casi garantizadas. El comportamiento global del producto construido hasta el momento será la referencia. que concretaremos en un Plan de Pruebas para este nivel (si queremos acabar las pruebas algún día). Cualquier aspecto de interés deberá ser retado: riesgos, requisitos, casos de uso, interacciones, configuraciones, rendimientos, comentarios del cliente en whatsapp, etc. Además, esta actividad la suele realizar un equipo de pruebas independiente que, típicamente, utiliza un entorno de pruebas que sea lo más similar posible al entorno de producción. ¡Ya tenemos un SISTEMA funcionando! Llega el momento de la verdad. Estamos en el corazón de nuestro modelo y aquí nos esperan las experiencias más intensas. Toca mirar cara a cara a los usuarios del sistema, buscamos su confianza. El nivel de Pruebas de Aceptación nos revelará si cumplimos con sus expectativas, ¿será dulce o amargo este último bocado? Las habituales implicaciones contractuales derivadas del resultado de las Pruebas de Aceptación han dado lugar a una amplia variedad de matices en la forma de Capítulo #9 - El modelo de Testing en capas de cebolla 2015 Panel Sistemas. Página 53
  53. 53. materializarlas: pruebas de aceptación de usuario, pruebas de aceptación operativa o pruebas de cumplimiento regulatorio son algunos ejemplo. Es más, si se realizan en casa del fabricante se denominan pruebas Alpha (todavía queda un atisbo de sospecha) mientras que, si son en casa del comprador, se denominan pruebas Beta (¡por fin!). Gracias al modelo de Niveles de Pruebas Software presentado, podemos visualizar cómo organizarnos para llegar hasta la esencia de toda actividad de fabricación de software, la satisfacción de las expectativas del cliente[1]. En todo caso, quizás os hayáis preguntado: PERO, ¿cómo se sabe si estamos construyendo el producto correctamente? (es decir, conforme a sus especificaciones) o ¿estamos satisfaciendo las expectativas del cliente? Estas inquietudes, que nos acompañan durante todo el ciclo de vida, nos permiten introducir un último concepto: Los Tipos de Pruebas. ¿Los conocéis? Algunas referencias interesantes sobre este tema, que hemos consultado, son: 1. Descarga del Syllabus del ISTQB [2] (2011, International Software Testing Qualification Boards). 2. Espacio web para estudio de la certificación ISTQB. [3] 3. Blog Pruebas del Software, por Javier Zapata S. [4] 4. Herramientas para pruebas software [5] (entre otros) en el blog de Javier Garzás. 5. Creating the onion model [6], artículo de Mike Clayton. 2015 Panel Sistemas. Página 54
  54. 54. Referencias 1. Innovación rentable – Masa K Maeda (blog.panel.es) 2. Syllabus del ISTQB (2011, International Software Testing Qualification Boards). 3. Estudio de la certificación ISTQB. 4. Blog Pruebas del Software, por Javier Zapata S. 5. Herramientas para pruebas software (entre otros) en el blog de Javier Garzás. 6. Creating the onion model, artículo de Mike Clayton. Artículo original: http://blog.panel.es/index.php/software-qa-software-testing-levels- onion-model/ Capítulo #9 - El modelo de Testing en capas de cebolla 2015 Panel Sistemas. Página 55
  55. 55. 2015 Panel Sistemas. Página 56
  56. 56. Capítulo #10 ¿Cuánto nos pica un bug? En aquellos negocios en los que las Tecnologías de la Información son críticas para la operación, disponer de una medida clara sobre cuánto daño nos ha hecho un problema en producción es un formidable reto. Si preguntamos a las partes interesadas (los míticos “stakeholders“), todos coinciden en su importancia pero discrepan drásticamente en su implementación. ¿Por qué es tan difícil cuantificar el efecto de los problemas software? ¿Es más difícil establecer el impacto de un error software que cuantificar cuánto pica una guindilla? Desde 1912, gracias a Wilbur Scoville y su Examen Organoléptico Scoville, tenemos una escala que nos permite saber cuánto nos va a picar una guidilla o chile. La medida se estableció en unidades … Scoville (SHU, del inglés “Scoville Heat Units”) que indicaban cuántas veces había que diluir el extracto del chile en agua azucarada hasta que era indetectable por un jurado. Capítulo #10 - ¿Cuánto nos pica un bug? 2015 Panel Sistemas. Página 57
  57. 57. Escala Scoville SHU En la actualidad se recurre a medir con precisión la cantidad de capsaicina (componente químico culpable del picor) mediante técnicas de laboratorio: mejora continua. Por cierto, la capsaicina no es soluble en agua … así que si necesitas aliviar el picor de un chile, mejor con leche. ¿Y qué pasa con el picor de una incidencia en los sistemas de información? ¿Cómo lo medimos? Para poder contestar se necesita método, deberemos obtener nuestro “extracto de chile” equivalente para medir su pungencia. Así, aplicando prácticas como la Integración Continua de software dispondremos de mecanismos para establecer relaciones de causa – efecto sobre los comportamientos de nuestros sistemas TI y podremos alinearlos con los elementos incorporados en la Gestión de Activos. Nos vamos acercando. ¿Qué nos aporta la Gestión de Activos software? Nos introduce en la dimensión “economía”. Nos cuantifica el valor aportado por los diversos elementos de configuración, de forma que podemos establecer cuándo nuestra incidencia queda suficientemente 2015 Panel Sistemas. Página 58
  58. 58. diluida como para ser indetectable. Si lo queremos ver en términos de dinero, equivale a compensar el picor reconociendo una pérdida en euros (por ejemplo). Mientras recorremos este camino, la detección temprana de anomalías es una auténtica vía rápida hacia el aseguramiento del valor esperado. Por ejemplo, si monitorizamos el “proceso de registro de nuevos clientes en la tienda online”, el valor añadido de este sensor emana del beneficio directo generado por este proceso. Os lo contamos con más detalle en nuestro artículo sobre Sondas automáticas de disponibilidad software. Estas son las bases que proponemos desde Panel Sistemas para caminar hacia un método que culmine en una escala estándar de escozor software: las SHU, del inglés “Software Hurt Units” Scoville nos demostró hace mucho tiempo que si se quiere, se puede medir. Inciativas como el proyecto europeo Iceberg, participado por Deiser, son un clara señal de que se quiere y se puede. Nuestra particular contribución en este ámbito de la Calidad Software está publicada en forma de estudio para el cálculo del retorno de la inversión en pruebas software (“ROI on Testing Investment”). Para terminar, si en vuestra empresa habéis conseguido consolidar una escala (que no sea el número de llamadas en el Centro de Atención a Usuarios o los decibelios de los gritos del área de Operaciones) os animo a compartirlo con todos nosotros, porque … … ¿Cuánto os pica un bug? Referencias Artículo original: http://blog.panel.es/index.php/softwareqa-cuanto-nos-pica-un-bug/ Capítulo #10 - ¿Cuánto nos pica un bug? 2015 Panel Sistemas. Página 59
  59. 59. 2015 Panel Sistemas. Página 60
  60. 60. Capítulo #11 Aplicar Agile Testing en proyectos grandes y complejos En este artículo compartimos nuestras conclusiones para la aplicación de prácticas Agile Testing en grandes proyectos. Agile Testing es un sabor más de los fundamentos de la filosofía Agile, en el que la esencia de las funciones de Testing no cambia; sólo los métodos y roles para lograr un mismo objetivo: contribuir a asegurar la calidad desde el inicio. Según su definición, el Agile Testing involucra a todo el equipo de desarrollo ágil de forma temprana, continua y sostenible. Se trabaja con una perspectiva de aportar calidad (valor) desde el principio, probando y analizando código (o especificaciones) desde que están disponibles y suficientemente estables. Así, nuestra interpretación de algunos de los principios del Manifiesto Ágil (“Agile Manifesto”, 2001) para escenarios de Certificación y Testing clásico es: Capítulo #11 - Agile Testing en proyectos grandes y complejos 2015 Panel Sistemas. Página 61
  61. 61. Los cambios en los requerimientos no son excepcionales. Entrega temprana y continua de Software con valor. La comunicación directa es la forma más efectiva. El Cliente está integrado en el equipo de delivery. Ciclos de vida de los entregables cortos. Aproximación al producto final por iteración. Sin embargo, una de las principales críticas que se hacen a las prácticas Agile Testing es que no son aplicables en proyectos grandes o complejos (o que no producen los mismos resultados). Por ejemplo, en entornos tradicionales, el grupo de Testing suele ser una unidad independiente dentro del ciclo de vida, tanto en función como en dependencia organizativa. Por contra, una concepción orientada a Agile Testing requiere una mayor integración de las pruebas en las fases de Desarrollo, con serios retos de cultura y organización en la composición de equipos de trabajo grandes o con roles pre- establecidos. Es por ello que para proyectos de desarrollo de software complejos y con cierto peso de los inevitables sistemas legacy, se está consolidando el recurrir a metodologías enriquecidas mediante la adaptación de prácticas Agile. En particular destacamos el esfuerzo de Ericsson AB con Streamline Development (SD) (libro, 2007), una metodología iterativa en la que los requisitos se establecen bajo un modelo de matriz de taxonomías o de anatomías, junto con la premisa de que todos los equipos tienen responsabilidad end to end en el proyecto … ambicioso sin duda. O como la que nos recomendaba Javier Garzás en este artículo del 2012: Feature Driven Development (FDD), una meta-metodología que incluye también un ciclo de vida iterativo e incremental como Scrum, pero orientada a equipos grandes, que contempla por ejemplo la figura del jefe de proyecto y una fase de arquitectura. Esta deriva quedó patente durante las sesiones de la ” IX Semana del CMMi y la Mejora de la Calidad TIC”, organizadas por Caelum y que podéis consultar en este brillante resumen: “Algo pasa con CMMi…” 2015 Panel Sistemas. Página 62
  62. 62. En cualquier caso, antes de incorporar prácticas de Agile Testing en nuestro proyecto, hay que cuidar algunos aspectos habitualmente ya delicados en un proceso de desarrollo y pruebas tradicional (secuencial): Eliminar ambigüedades y clarificar suposiciones en los requisitos, de forma recurrente y permanente. Como al volumen de requisitos sumamos la mayor velocidad en la entrega de valor, se requerirá de un gran esmero en su gestión para no alimentar la tendencia a generar deuda técnica de estos proyectos. Apoyar al usuario en la formulación de los tests de Aceptación, contribuyendo en lo posible a descubrir requerimientos nuevos, desde el conocimiento funcional de los equipos de Pruebas. (¿He oído conversación BDD?) Dar más apoyo a Desarrollo en la definición, localización y cierre de una incidencia. Cuidar los ratios de automatización, especialmente en las regresiones. Con las pruebas de regresión buscamos asegurar calidad y precisión sobre el comportamiento del sistema. En particular, recomendamos automatizar las pruebas de aceptación que aseguren al cliente las funcionalidades clave deseadas. Consideramos un factor clave de éxito en Agile Testing saber ecualizar el esfuerzo en automatización de pruebas. Visualmente podemos recurrir, por ejemplo, a los cuadrantes de Agile Testing para ayudarnos a definir nuestras estrategias de pruebas. Capítulo #11 - Agile Testing en proyectos grandes y complejos 2015 Panel Sistemas. Página 63
  63. 63. Agile Testing Quadrants Sin embargo, no todo es tan fácil. En @PanelSistemas sabemos por experiencia que existen algunos factores de riesgo que es necesario mimar en la aplicación de este tipo de metodologías sobre grandes sistemas: Gestión de la anatomía de requisitos. Conviene prestar especial cuidado a la definición detallada de la matriz de requisitos cuando se necesita establecer interdependencias entre componentes o subsistemas. Estabilidad de requisitos. Un clásico. Al manejarse un mayor volumen de requisitos es más complejo controlar el alcance de los cambios y su gestión. Además, en proyectos de larga duración (meses/años), acompasar los ciclos de requisios adquiere carácter crítico. Visión global de la Arquitectura. Aplicando ciclos iterativos debemos velar por asegurar el alineamiento con la visión global de la funcionalidad y de la arquitectura del sistema. Si se pierde la visión integrada del sistema, se incrementa el riesgo de carencias de arquitectura. Peso de los Legacy. Suele ser complejo aplicar ciertas prácticas Ágiles, como la Integración Continua (IC), en los sistemas heredados (“Legacy”) con los que deben convivir estos proyectos. Por tanto, deberemos controlar la proporción de sistemas Legacy para poder aspirar a mantener un ritmo sostenible de Agile 2015 Panel Sistemas. Página 64
  64. 64. Testing. Valor de los Planes de Prueba. Si llegaran a combinarse los riesgos de requisitos (tanto en anatomía como en estabildiad), los riesgos de visión integrada del sistema o carencias de Arquitectura y un alto peso de los sistemas Legacy, la conclusión más directa es que tendremos graves problemas en la definición de los Planes de Prueba y la predictibilidad de sus resultados. Trabajemos primero en paliar estos riesgos. “Si hay que probar, se prueba. Pero, probar ‘pa ná’ es tontería". Priorización de la actividad. Los beneficios de establecer una organización con un fuerte foco en la visión extremo a extremo (“e2e”) conllevan una intensidad equivalente en la gestión de prioridades y expectativas. En caso contrario es fácil caer en dinámicas en las que todo pasa a ser urgente, todo el mundo está muy ocupado y el valor añadido pasa a negativo (¡Sí! ¡Desperdicio!). Gestión de equipos. Al potenciar la versatilidad de los equipos, fomentando “células autogestionadas” de tamaño reducido, hemos constatado que la rotación de personas es un riesgo con un alcance potencial más delicado que en una visión tradicional. Automatizar es necesario. En automatización -en general- el riesgo principal nace de una inadecuada estrategia. Incorporar prácticas de Agile Testing conduce de forma natural a no cuestionarse la necesidad de automatizar (pruebas). Sin embargo, una estrategia de pruebas equivocada puede llevarnos a escenarios en los que el esfuerzo de mantenimiento de las pruebas sea excesivo, arriesgando así el retorno de esta inversión (ROI). Elegir adecuadamente los niveles de pruebas sobre los que se invierte en automatización de pruebas es determinante. “Por favor, no realicen esta actividad en sus casas, Capítulo #11 - Agile Testing en proyectos grandes y complejos 2015 Panel Sistemas. Página 65
  65. 65. llamen a un profesional.” En cualquier caso, como señala Rubén González en el blog Think Big, “...en otros casos, los métodos ágiles pueden servir de guía. Pero siempre que se apliquen de una forma explícita, se deberían adaptar de acuerdo a los skills y a la naturaleza del equipo, y nunca forzarlos de forma imperativa. Muchas veces se aplican métodos y prácticas ágiles religiosamente, perdiendo de vista lo que es verdaderamente importante: llevar a cabo una gestión adaptativa de la incertidumbre inherente al desarrollo de software, sea con un método o sin él.” No podemos estar más de acuerdo con esta afirmación :-). En este artículo hemos intentado compartir con vosotros conclusiones relevantes de nuestra experiencia en la aplicación de prácticas Agile Testing en grandes proyectos, aunque sabemos que el tratamiento no ha sido exhaustivo. No os quepa duda, nuestros expertos del Centro de Excelencia en SQA & Testing ya se han encargado de puntualizar: “es un tema muy extenso (toca gestión de requerimientos, gestión de incertidumbre, organización de equipos, estrategia de automatización, gestión de reporte, gestión de prioridades, visión E2E, etcétera) como para comprimirlo en tan pocas palabras”. Tenemos el compromiso de redimir esta deuda (¡a OGMA pongo por testigo…!). Para terminar, ¿no os habéis preguntado dónde estará el Agile Test Manifesto? Estar está, pero ¡en revisión! Referencias Artículo original: http://blog.panel.es/index.php/aplicar-agile-testing-en-proyectos- grandes-y-complejos/ 2015 Panel Sistemas. Página 66
  66. 66. Capítulo #12 Razones para practicar la Integración Continua El objetivo de los equipos de desarrollo actuales es planificar, codificar, probar y entregar una pieza de software utilizable cada dos o tres semanas. Para conseguirlo, automatizamos buena parte del proceso software mediante la Integración Continua (IC), de manera que el equipo pueda repetir la entrega de código de forma iterativa, pero descargando el trabajo pesado en un servidor de Integración Continua (“CI server”). Así es como conseguimos entregar los grandes proyectos de desarrollo software. Capítulo #12 - Razones para practicar la Integración Continua 2015 Panel Sistemas. Página 67
  67. 67. El servidor de Integración Continua automatiza diversos pasos en el ciclo de vida del software. No puede ayudarnos con los requistos de negocio o diseño, pero sí puede encargarse del empaquetado, despliegue, inspección y pruebas software automáticas. Y lo hace de forma incansable, sistemática, robusta y barata. Al automatizar parte del proceso de producción de software, la Integración Continua contribuye definitivamente a acelerar el tiempo para llegar al mercado (“time-to-market”) en las organizaciones basadas en Tecnologías de la Información (TI). ¿Cuáles son las organizaciones basadas en Tecnologías de la Información? Son aquellos negocios en los que las Tecnologías de la Información son críticas para la operación. Bancos, empresas de paquetería o canales de venta basados en Internet, por ejemplo, están basados en TI. Mejorar sus cañerias TI significa mejorar sus comunicaciones internas, su estrategia de marketing y sus costes de producción. Es decir, son compañías que consiguen ventajas competitivas con el uso de la tecnología, sin que sea excluyente el que vendan o no tecnología. Gracias al impulso de iniciativas como Agile o eXtreme Programming, entre otras, los servidores de Integración Continua disponibles son numerosos: Bamboo, CruiseControl, 2015 Panel Sistemas. Página 68
  68. 68. Jenkins, Team Foundation Server o Solano por ejemplo. Sin embargo, aplicar Integración Continua (IC) es un proceso doloroso y exigente que requiere un CAMBIO EN LA CULTURA de construcción de software. Con constancia finalmente conseguiremos reducir los tiempos de empaquetado, aumentar el número de versiones en paralelo y la robustez de las entregas. Bien, va a doler. Pero , ¿en qué podemos ayudarte? En primera instancia toca verificar la Cultura del equipo de desarrollo. Habitualmente es necesario generar un proceso de adaptación, de enriquecimiento, en que se minimice la resistencia al cambio gracias a un enfoque de mejora paulatina, basada en principios Lean. Aplicando definición temprana. Asegurando los canales de comunicación. También trabajaremos en definir los Procesos que permitirán maximizar el rendimiento obtenido: Estableciendo las líneas de automatización. Determinando las “causas” a controlar. Definiendo políticas de ejecución. Implementando los Radiadores de información (indicadores de medición). Por último, utilizar la suite de Herramientas más adecuada entre las distintas alternativas tecnológicas será nuestra contribución final. Capítulo #12 - Razones para practicar la Integración Continua 2015 Panel Sistemas. Página 69
  69. 69. Integración Continua en el Antiguo Egipto La Integración Continua es un medio, no un fin. El objetivo sigue siendo maximizar el valor entregado. Un espacio de reflexión interesante nos lo proporciona la frecuencia. Aunque hablamos de Integración C-o-n-t-i-n-u-a, no se trata de una práctica que fuerce a un proceso de integración diario. La frecuencia es una cuestión que está abierta y que deberá quedar definida conforme a los objetivos que se quieran alcanzar. Por ello, en la Integración Continua, el ritmo lo marcan las relaciones “Causa -> Efecto” a controlar. No podemos terminar sin recopilar las razones, en forma de beneficios, que motivan la aplicación de esta exigente práctica de la Ingeniería Software: 1. Reducción de riesgos tecnológicos gracias a un proceso de construcción predecible, retroalimentado y transparente. Así, por ejemplo, podremos predecir el tiempo de integración dado que es algo que se realiza de forma continua. 2. Minimizar las anomalías en el producto final gracias al “feedback” temprano. Al realizar pruebas automáticas frecuentes habilitamos una pronta detección y 2015 Panel Sistemas. Página 70
  70. 70. corrección de anomalías. 3. Calidad desde el inicio y adaptación al cambio. Como es posible disponer de un entorno de demostración con cualquier versión de la aplicación, es viable mostrar los últimos cambios de forma frecuente. Así, buscamos la aceptación por parte de los usuarios de las nuevas características añadidas al proyecto y devolvemos información al equipo de trabajo rápidamente. 4. Responsabilidad y visibilidad. El ciclo de vida del producto software se vuelve explícito, común, independiente y público. Así, todo el equipo dispone de información precisa sobre el estado real del proyecto, lo que aligera las tareas de seguimiento, fomenta el sentimiento de propiedad colectiva del código y garantiza la transparencia del proceso. Sin duda, un viaje intenso hacia un mundo maravilloso en el que deleitarnos observando manadas de hermosos unicornios … ¡Vaya! ¡Un Unicornio Bug! … ¿Será posible? Referencias Artículo original: http://blog.panel.es/index.php/software-qa-razones-para-practicar-la- integracion-continua/ Capítulo #12 - Razones para practicar la Integración Continua 2015 Panel Sistemas. Página 71
  71. 71. 2015 Panel Sistemas. Página 72
  72. 72. Capítulo #13 Software QA - DevOps: hacia la calidad continua del software DevOps representa un avance para la ingeniería de software equiparable a la aportación del continuo espacio-tiempo en la física. Siendo el espacio-tiempo[1] “el modelo matemático que combina el espacio y el tiempo en un único continuo como dos conceptos inseparablemente relacionados”, podemos parafrasear para DevOps: DevOps es el modelo informático que combina el desarrollo y la operación del software en un único continuo como dos conceptos inseparablemente relacionados. ¡Olé!. Este neologismo proviene de agrupar en un acrónimo los términos ingleses Development (Desarrollo) y Operations (Operaciones). Para seguir con el recorrido desde la física clásica de Newton a la física cuántica de Einstein, partiremos de la concepción clásica de equipos de desarrollo de software Capítulo #13 - DevOps, hacia la Calidad Continua del software 2015 Panel Sistemas. Página 73
  73. 73. (centrados en la construcción) y de equipos de operaciones (centrados en la explotación de los sistemas informáticos en producción) aislados entre sí. A continuación, nos plantearemos incluir el tratamiento del tiempo como una dimensión más. Así llegamos a la necesidad de considerar unificadamente la actividad de todos los equipos de trabajo y el tiempo, ya que la diferencia entre componentes informáticos (Hw/Sw) y temporales es relativa según el estado de movimiento del observador (cliente, negocio, PMO, …). DevOps = Dev + Ops² La omnipresente presión por acelerar la obtención de resultados lleva de forma natural a plantear procesos de trabajo ágiles y continuos: planificación, medición, desarrollo, pruebas, despliegue, ejecución, operación, supervisión y optimización continuos. Afortunadamente, ahora es viable plantear metodologías de desarrollo estandarizadas, procesos de comunicación y documentación claros junto con plataformas probadas y basadas en estándares, lo que contribuye a agilizar los ciclos de gestión y desarrollo de las aplicaciones. Además, con ello se sustenta una mayor disponibilidad y seguridad de la infraestructura IT. 2015 Panel Sistemas. Página 74
  74. 74. En el lado práctico de la vida, DevOps va de conectar personas, productos y procesos. En definitiva, estamos hablando de conectar tecnología, negocio y valor entregado. En resumen, mediante la aplicación de los principios “lean” y “agile”[2] en el ciclo de vida de entrega continua de producto se consigue cimentar la agilidad del negocio y el alineamiento de las Tecnologías de la Información (TI). Sobre esta base podremos acelerar el “Time-to-Market” (tiempo de comercialización), disparar nuestra capacidad de innovación y ofrecer una experiencia de cliente diferenciada. La actividad en torno a DevOps es frenética. Los fabricantes de herramientas de nicho (los creadores de VirtualBox, Puppet[3], Vagrant o Ansible[4], por ejemplo) están siendo asediados por los grandes fabricantes (IBM, HP, Oracle) en su ánimo de prevalecer como suministradores predominantes. Si queréis ampliar información, nuestras recomendaciones son: La explicación (en inglés) de la gente de NewRelic sobre DevOps [5] está bien estructurada y presentada. Participar en el notable grupo Madrid DevOps [6], didáctico, ameno y abierto a todos. La serie de artículos sobre Puppet [7] (en español) de David Fernández ofrece una rápida visión global (aunque son del 2010). NewRelic DevOps toolset [8]: Extenso compendio de herramientas categorizadas. Completo Trabajo Fin de Grado de la UNIR: (pdf) “Mejores prácticas de despliegue continuo para aplicaciones Symfony2ʺ [9] de Fernando Arconada Orostegui. Como ejemplo de la fuerte reacción de los fabricantes grandes, os propongo: IBM DevOps [10]. Capítulo #13 - DevOps, hacia la Calidad Continua del software 2015 Panel Sistemas. Página 75
  75. 75. Vale, vale … también la entrada en inglés de la Wikipedia para DevOps[11] (justita, pero su “DevOps (a portmanteau of development and operations)” es ya un clásico en internet). En @PanelSistemas seguimos pugnando por entregar productos software de calidad de forma continua, por ello creemos que DevOps es el eslabón perdido en la cadena de entrega de valor mediante la fabricación de software[12]. Referencias 1. Espacio-tiempo Einstein (es.wikipedia.org) 2. Innovación rentable – Masa K Maeda (blog.panel.es) 3. Puppet Labs (puppetlabs.com) 4. Ansible (www.ansible.com) 5. NewRelic sobre DevOps 6. Grupo Madrid DevOps 7. Serie de artículos sobre Puppet 8. NewRelic DevOps toolset 9. Mejores prácticas de despliegue continuo para aplicaciones Symfony2 10. IBM DevOps 11. DevOps Wikipedia (en.wikipedia.org) 12. Calidad software: fabricación ecoLógica (blog.panel.es) Artículo original: http://blog.panel.es/index.php/software-qa-devops-hacia-la-calidad- continua-del-software/ 2015 Panel Sistemas. Página 76
  76. 76. Capítulo #14 ¿Qué es DevOps 101? Tras el enigmático título de “DevOps 101“, Antonio Peña del grupo de Madrid DevOps nos motivó para vencer el magnetismo fácil de las herramientas, conectándonos con el mejor superconductor: la cultura. La sesión la planteó como iniciática, a imagen de los cursos introductorios americanos, los “101”. Así, buscando las bases, se hizo incidencia en la importancia de formarse una opinión propia. ¿Cómo? conociendo el punto de vista de técnicos de referencia como Seth Vargo o Katherine Daniels y probando, haciendo, compartiendo. Diversas voces alertan del riesgo que supone convertir DevOps en un “palabro de moda”, perdiendo su esencia por intentar consolidar su oportunidad de ocupar un sitio en el olimpo de la tecnología y, sobre todo, en el pastel comercial. Comparto la recomendación de Antonio por el artículo de Baron Schwartz: “The DevOps identity crisis” y por el vídeo de Katherine: “DevOps Is Dead (Long Live DevOps)” (20 min., inglés) DevOpsDays Minneapolis 2014 — Katherine Daniels, DevOps Is Dead (Long Live DevOps) from devopsdays on Vimeo. Capítulo #14 - ¿Qué es DevOps 101? 2015 Panel Sistemas. Página 77
  77. 77. Todavía la comunidad interesada es informal, sin líderes claros, metodologías o credos. Como dice Baron Schwartz en la entradilla de su artículo: “El por qué DevOps necesita un manifesto después de todo, aunque puede que nunca lo consiga”. Por ejemplo, Seth ha optado por escribir una lista con 10 mitos sobre DevOps, os copio el décimo: “Myth #10 – DevOps is just a fad like “Agile” or “mainframes” Unlike Agile or mainframes, DevOps is not a development methodology or technology; DevOps is an ideology. Is it a way to facilitate organizational prosperity and growth while increasing each individual employee’s happiness along the way. I do not know about you, but that sounds pretty sweet to me. I hope DevOps is not a fad.” Por su parte, Katherine insiste en la importancia de la empatía y la responsabilidad como motores, en la importancia de conseguir resultados y en la necesidad de subyugar las herramientas a la cultura de la Calidad Software. Aboga por la evolución antes que la revolución. Pero no hay que irse tan lejos. En el turno de preguntas, la gente de Tuenti (¡qué gran anfitrión!) nos contó su periplo hasta conseguir que la actividad de DevOps forme parte natural del proceso de creación de producto, de entrega de valor. Tras dos años y medio, ahora no necesitan “ponerse a hacer DevOps“. Lo han conseguido dando pasos pequeños, con pequeñas victorias y pequeñas derrotas. ¿Su clave? “Nuestra clave ha sido tener un equipo dedicado a crear la cultura y suministrar/facilitar las herramientas para el despliegue de su trabajo (enablers) a los equipos de producto. Que cada equipo de desarrollo afronte el despliegue por su cuenta y con sus mecanismos es muy ineficiente“. Gracias. 2015 Panel Sistemas. Página 78
  78. 78. Entonces, ¿qué es DevOps? ¿Y tú me lo preguntas? DevOps … eres tú … y tú, y tú. Hablamos de comunicarse y colaborar por un objetivo común, de compartir la cultura de primar el valor al cliente, de aplicar empatía y responsabilidad, de romper los silos funcionales (también conocidos como nidos de excusas), de preservar la rentabilidad de las compañías, de hablar sin esconder los problemas … para buscar soluciones. Finalmente, queremos agradecer a los esforzados organizadores del grupo Madrid DevOps su tenacidad y a Antonio, en particular, su firme convicción en enriquecerse compartiendo :-). Podéis consultar su presentación de apoyo en esta sesión en Madriddevops-january-2015-meeting. ¿DevOps es tu tesoro o el de todos? Referencias Artículo original: http://blog.panel.es/index.php/software-qa-que-es-devops-101/ Capítulo #14 - ¿Qué es DevOps 101? 2015 Panel Sistemas. Página 79
  79. 79. 2015 Panel Sistemas. Página 80
  80. 80. Capítulo #15 ¿Cómo probar aplicando Entrega Continua? Diseccionar las exigencias de la Entrega Continua de software utilizando el Testing como certero bisturí es el reto al que se enfrentó Peter Marshall en su sesión sobre “Continuous Delivery, Testing challenges”. Este es nuestro resumen y conclusiones, sin duda, un gran acierto del grupo de QA y Testing de software de Madrid, nuevamente. “Continuous Delivery is about building Quality in !!” La Entrega Continua es una de las prácticas de ingeniería software más exigentes, podemos decir que está situada cerca de la cúspide en la pirámide trófica del software. Capítulo #15 - ¿Cómo probar aplicando Entrega Continua? 2015 Panel Sistemas. Página 81
  81. 81. MadridQA_Continuous_Delivery_Start_n ¿Qué retos plantea para el testing la Entrega Continua? La velocidad en la entrega. ¿Cómo hacemos para probarlo todo? Enfatizamos la automatización. Tenemos procesos manuales ¿quién se encarga de toda esa automatización? ¿Cómo hacemos las pruebas de regresión? El punto de partida El punto de partida que nos presenta es el clásico gran proyecto (cientos de personas, decenas de equipos, meses de trabajo hasta La Entrega) sometido a la presión de construir un nuevo producto de referencia. Algunos de los problemas que debían resolver desde el punto de vista de las pruebas eran: La mayor parte del equipo de pruebas tenía sus bases en el desarrollo sofware tradicional. Cada equipo de pruebas, en cada fase, tenía que volver a analizar los 2015 Panel Sistemas. Página 82
  82. 82. requisitos, ¡y así para 9 fases! La configuración en cada entorno de pruebas era diferente. Los gestores del equipo de pruebas se oponían al cambio. Bucles de retroalimentación entre desarrollo y pruebas muy, muy largos. “Very long feedback loops between dev. and test” En su conjunto la organización estaba haciendo un esfuerzo enorme para cambiar de cultura: de “gestionar muchas cosas simultáneamente” a “gestionar solo unas pocas cosas a la vez“. No sin pelea (ni sangre). Durante más de un año la lucha estuvo igualada. Desde los primeros intentos de buscar ciclos de producción semanales (incluyendo Aceptación ¡guau!), finalmente se llegó al consenso en ciclos de 4 semanas, pasando primero por pruebas de Integración y Funcionales para acabar en las pruebas de Aceptación. ¡Duro con ello! Pude intuir a Peter en plena acción: “esquiva, baila, esquiva, derecha, gancho, cubre, esquiva, ¡abraza!“ ¿Cómo conseguir el cambio? Su receta para esta pelea es rocosa: enfoque en el equipo como conjunto (“Whole team approach”): Reduciendo el número de funcionalidades que se mueven por el proceso de Capítulo #15 - ¿Cómo probar aplicando Entrega Continua? 2015 Panel Sistemas. Página 83
  83. 83. entrega. Incluyendo en cada entrega (“build process”) tantas pruebas como sea posible. Sacando a los probadores (“tester”) de pensar solo en documentación y casos de prueba para elevar su perspectiva hacia el producto, siguiendo los principios del “Context driven testing“. Adelantando al máximo las fases de pruebas previstas para después de la entrega. Implicando a todo el equipo en las pruebas, todos pueden aportar ¡Organiza una buena piñata de bugs! (“Bug bash“). Invirtiendo intensamente en gestión de la configuración y provisión de entornos (en su caso: Docker). Acercando a los responsables del negocio a los equipos (¡hacer piña!). Formación y entrenamiento en pensamiento Agile e ingeniería Lean. Para convencer a los más reticentes les tocó tirar de educación, demostración y talleres con grandes refentes del sector (Mark Collin, David Farley, Steve Smith y Tony Bruce), de lujo. Pero, sobre todo, fue determinante el conseguir un firme respaldo por parte de la dirección. ¿Cuál fue el resultado? ¡Éxito! Sin duda, tras 18 meses de transformación, reajustes de equipos/procesos y “pruebas de vida”. Así nos resume el proyecto: Hemos cambiado la cultura. Hemos cambiado la percepción de lo que significa probar. Hemos minimizado las pruebas tradicionales (diseño y ejecución de casos de prueba). Con ello hemos disminuido el tamaño de los equipos de prueba, reforzando los equipos de desarrollo. Hemos implicado responsablemente en la calidad del resultado a todo el mundo. Funcionamos como un equipo, en lugar de como un conjunto de silos 2015 Panel Sistemas. Página 84
  84. 84. distribuidos por la organización. Los números cantan: software en producción cada 4 semanas, mayor productividad del equipo y un importante descenso en los errores críticos (nos dió el dato exacto). Es decir, entrega satisfactoria del valor esperado. En suma: Quality is the responsability of everybody!! Fin de fiesta La sesión se cerró con un divertido concurso, un interesante debate y un excelente “networking”. Os destaco: Nos llevó 18 meses conseguir el equilibrio y el compromiso de todos. Sigue funcionando. ¿Habéis aplicado Scrum o Kanban? De todo. Lo más importante es que todo Capítulo #15 - ¿Cómo probar aplicando Entrega Continua? 2015 Panel Sistemas. Página 85
  85. 85. tiene que ser alcanzable en el ciclo. Hemos usado muy diversos ciclos. Tener equipos multidisciplinares (“crossfunctional”) ha sido determinante para poder involucrar a todos en diversos papeles. Entrega continua es pruebas de regresión, lo lleva implícito. ¿Qué hacía el equipo de testers tras los ajustes? Hacían testing, siempre se necesita que un ser humano interactue con la aplicacion. Si queréis saber algo más sobre Peter, estas son sus coordenadas: @petemar5hall y Lean Software Servicies (cuando publique esta presentación, la incluiremos encantados). ¿Alguien da más? ¡Claro! ¡ El Blog de @PanelSistemas ! Referencias Artículo original: http://blog.panel.es/index.php/madqa-como-probar-aplicando-entrega- continua/ 2015 Panel Sistemas. Página 86
  86. 86. Capítulo #16 Estrategias de integración entre productos software Pain or Gain? La integración entre productos o aplicaciones software es un aspecto determinante sobre su futuro y utilidad. Gracias a la integración podremos extender la funcionalidad disponible, acceder a información nativa de otros sistemas e, incluso, aspirar a la eternidad (o casi :-). Las técnicas que podemos utilizar para solucionar nuestras necesidades de conexión entre aplicaciones son conocidas y numerosas, sin embargo, resulta crítico elegir adecuadamente la ESTRATEGIA de INTEGRACIÓN sobre la que apoyaremos nuestros esfuerzos. Capitulo #16 - Estrategias de integración entre productos software 2015 Panel Sistemas. Página 87
  87. 87. Multitud de conexiones Dado el estado de cambio permanente que caracteriza a los sistemas informáticos, las actividades de integración entre aplicaciones software pueden ser un auténtico pozo sin fondo. Para el análisis de esta toma de decisión (DAR en términos CMMI) encontraremos condicionantes relacionados con exigencias en cuanto a prestaciones, facilidades para nuevas integraciones o portabilidad, por ejemplo. Como orientación, a continuación resumimos las principales cuestiones a considerar: Conexiones una a una: Para cada pareja de aplicaciones defino e implemento una forma de conectarlas. Conexiones mediante servicios de mensajes: Cada aplicación se conecta a los canales de comunicación que le interesan e interactúa con ellos (lee / escribe). Los conocemos como “Bus de integración” o “Bus de servicios de empresa”. Conexiones en una sola dirección (la información solo se propaga de la aplicación Origen a la aplicación Destino) frente a conexiones bidirecciones (información de ida y vuelta). 2015 Panel Sistemas. Página 88

×