¿WaterScrumFall? El enfoque mixto da malos resultados

¿Qué metodología es la más usada y eficiente, ágiles, cascada o híbrida?

Hace unos meses atrás, Hewlett Packard Enterprise (HPE), realizó una encuesta llevada por YouGov acerca de las metodologías usadas para el desarrollo de proyectos de software. La encuesta se realizó a 403 profesionales, entre ellos desarrolladores, testers, project managers y operaciones de TI.

La encuesta reveló que solo un pequeño grupo usa cascada en su forma pura, un 50% utiliza ágil de forma pura y un 82% utiliza ágil de forma pura o híbrida.

Además, la encuesta mide el éxito de los proyectos a través de 6 indicadores, calidad y rendimiento, time to market, velocidad de entrega, alcance, seguridad, and costo/uso de recursos. Como era de esperarse, el resultado es satisfactorio para ágil de forma pura, demostrando que los proyectos desarrollados de esta forma, son más exitosos.

Según la encuesta, los proyectos ágiles dan mejores resultados que los proyectos híbridos, las compañías que tienen estas prácticas deberían de reconsiderarlo.

Si quieres descargar el reporte completo, haz clic aquí.

¿WaterScrumFall? El enfoque mixto da malos resultados

¿Cómo nos ayuda BDD en el desarrollo de un proyecto?

Antes de empezar primero aclaremos ¿qué es BDD?. BDD es un conjunto de prácticas de ingeniería que están basadas en prácticas ágiles, específicamente TDD y DDD, para ayudar a desarrollar y entregar software de calidad y con mayor valor para el cliente. BDD otorga un lenguaje común, basado en oraciones estructuradas que permite la fácil comunicación entre los miembros del equipo y los stakeholders.

El flujo que BDD promueve consta en:

  1. Identificar las metas del negocio.
  2. Identificar las características a desarrollar que contribuyen a las metas del negocio.
  3. Creación de ejemplos para las características definidas y planteamiento de escenarios utilizando un lenguaje común (Given, When, Then).
  4. Codificación a nivel de pruebas de los escenarios.
  5. Codificación de características de bajo nivel.
  6. Codificación del código de la aplicación.

BDD está orientado al comportamiento (Behaviour driven development) ya que de esa forma las pruebas reflejan las características esperadas por el cliente.

En la práctica, cada característica del software puede ser descrita en un formato de una historia de usuario si el equipo lo desea y de cada una de ellas se identifican por medio de ejemplos los escenarios que se deben de probar y estos escenarios cumplen la función de criterios de aceptación para las posibles historias que creemos de nuestras características.

Ejemplo:

Primero definimos una característica

Feature: Disposición de efectivo de un cajero

(As [role], I want [feature], So that [benefit])

Como [titular de la cuenta]
Quiero [disponer de efectivo desde un cajero]
Para [obtener dinero cuando el banco está cerrado]

Luego encontramos los escenarios

(Given [context], And [more context…], When [event], Then [outcome], And [another outcome])

Escenario: La cuenta no tiene fondos suficientes

Dado que el balance de la cuenta es S/.100
Y la cuenta es válida
Y el cajero tiene suficiente dinero
Cuando el titular de la cuenta solicita S/. 20
Entonces el cajero debe otorgar S/. 20
Y el balance de la cuenta debe ser S/. 80
Y la tarjeta debe ser devuelta

(Ejemplo adaptado en español de la página de Dan North & Associates. Dan North es el creador de BDD)

Como se puede apreciar en el ejemplo, de esta forma se pueden definir los escenarios que se deben cubrir para que una caracteristica (feature) sea aceptada como completa (criterios de aceptación). Uno de los puntos más importantes a resaltar es que el lenguaje que expresa los escenarios es fácil de entender tanto para personas con habilidades técnicas como para los que no, de esta forma todos los miembros del equipo están alineados y además las pruebas pueden servir de documentación.

A continuación veremos un ejemplo de una implementación en BDD del escenario visto en lineas anteriores, para eso usaremos Cucumber para Scala.

(Código en español para que sea fácil de entender, se puede usar ES en vez de EN para usar Cuando en vez de Given por ejemplo)

Como se puede ver, tanto la especificación como el código son exactamente iguales. Cucumber lee las especificaciones en texto plano y realiza un comparación con el código para capturar los valores que sean necesarios (en este caso los valores numéricos).

Al ejecutar las pruebas se puede ver el resultado detallado.

bdd_example

Además, las pruebas se pueden exportar como html para que puedan ser compartidas con el cliente.

De esta forma podemos mejorar el flujo de trabajo teniendo mejores definiciones con el cliente, orientadas al comportamiento y que aportan valor al negocio, además están reflejadas directamente en el trabajo realizado en el código y se pueden usar como documentación.

El código utilizado para la demostración puede ser descargado desde GitHub.

https://github.com/evolbit/cucumber-play

¿Cómo nos ayuda BDD en el desarrollo de un proyecto?

Así que sigues usando cascada…

Hace varios años el Dr. Winston Royce presentó una propuesta para el manejo de proyectos de gran escala. Por varios años esa propuesta ha sido usada por muchas empresas pero no muchos saben una pequeña verdad acerca de ella, el mismo autor (Winston Royce) cree que es riesgosa y que invita a fallar.

Managing The Development of Large Software Systems

I believe in this concept, but the implementation described above is risky and invites failure. (Creo en este concepto, pero la implementación descrita anteriormente es riesgosa e invita a fallar)

Este pequeño detalle ha resaltado mucho en la práctica. Los proyectos manejados con cascada sufren muchos conflictos por diferentes razones, una de las razones más importantes es intentar diseñar el sistema y analizar todos los requerimientos intentando manejar una verdad única, rígida y desde un único punto de vista. Sabemos por experiencia que los sistemas cambian durante el desarrollo por muchas razones (cliente, tecnologías, otros) y por esa razón, mucho del tiempo invertido en la etapa de análisis perderá sentido.

Por la razón expuesta anteriormente y muchas otras, en Evolbit usamos Scrum como marco de desarrollo. Es usado a nivel mundial por grandes empresas que ya han comprobado su efectividad. Scrum sigue los principios del manifiesto ágil (http://www.agilemanifesto.org/) y promueve lo siguiente:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Scrum-overview

Si tu o tu empresa aún siguen usando cascada te recomendamos que revises más sobre Scrum (u otra metodología ágil), a continuación te dejamos una página con muy buenos videos que te ayudarán a introducirte en las metodologías ágiles.

http://scrummethodology.com/

 

Así que sigues usando cascada…