Archivo de la categoría: Desarrollo de Software

Explorando la metodología DWDP+1 parte I

Introducción

Más de alguno se estará preguntando ¡que diablos es la metodología DWDP+1 en inglés o DRDP en español!, pues la siglas vienen de Draw – Write – Draw – Prototype o en español Dibuja – Redacta/Escribe – Dibuja – Prototipa, posteriormente en el detalle explicaré de dónde viene el +1.

Esta metodología nace de la necesidad de poder llegar a una forma de trabajo que sea sencilla y práctica de poder levantar y detallar las primeras etapas de construcción de un software, sin complejizar demasiado el proceso.  Principalmente aquellas etapas que tienen que ver con la Ingeniería de Requerimientos o Requisitos, antes de entrar de lleno al diseño y construcción del software, lo anterior mirado desde una perspectiva ágil de desarrollo del software.

Hagamos un poco de historia

Con el transcurso de los años se han desarrollado recursos que conforman la ingeniería del software, es decir, herramientas y técnicas de especificación, diseño e implementación del software: la programación estructurada, la programación orientada a objetos, las herramientas CASE, la documentación, los estándares, CORBA, los servicios web, el lenguaje UML, etc.

En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los productos software hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.

En general la ingeniería del software consiste en:

  • Proceso de desarrollo de software (especificación, implementación y diseño, etc…).
  • Metodologías para el desarrollo de software (RUP, patrones, framework…).
  • Herramientas de desarrollo de software.

Hay cuatro actividades fundamentales comunes a todo proceso software:

  • Especificación: usuarios e ingenieros definen el software a producir y las restricciones en su funcionalidad.
  • Desarrollo: fase en la cual el software se diseña y se programa.
  • Validación: el software debe ser probado para asegurar que cumple con las necesidades del cliente.
  • Evolución: el software debe poder ser modificado para adaptarse a cambios en el mercado y en las necesidades de los usuarios.

A mi me gustaría centrarme en la primera actividad fundamental: la especificación, pero con un enfoque más holístico que incorpore algunas técnicas de la Ingeniería de Requerimientos, no perdiendo el foco ágil.

Las metodologías actuales y el auge de la agilidad

Todas las metodologías ágiles coinciden en que un producto debe construirse de forma evolutiva en pequeñas entregas. Y aunque esto no es suficiente, sino que debemos hacerlo de forma criteriosa para que cada entrega pueda aportar valor suficiente a los usuarios finales. Esos grupos de características se denominan MMF: Minimum Marketable Features, y pueden definirse como “el conjunto más pequeño posible de funcionalidad que, por si misma, tiene valor en el mercado”.

Cuando nosotros nos acercamos al cliente, asumimos que él sabe exactamente qué quiere hacer (What?)  y nosotros le damos el cómo (How?). Sin embargo, esto no es así y nuestro trabajo se convierte en algo así como adivinar el futuro con una bola de cristal.

Todas las metodologías ágiles que he consultado e intentado aplicar (Scrum, xP), se basan en el hecho de que los implicados son “relativamente profesionales” y están muy orientados a resultados, con altas capacitaciones en sus campos. Cuando intentas llevar esto a la realidad práctica, los clientes no saben qué quieren, no están dispuestos a formalizar sus peticiones en algo parecido a un informe de requerimientos (porque el tiempo apremia), los programadores que trabajan para ti pueden ser lentos y tener una capacidad de adaptación baja, con lo cual los temas se eternizan (aunque no en todos los casos, no quiero generalizar).

En resumen, al final cada uno debe resolver el problema con lo que tenga a su alcance (quizá un buen analista funcional o un comercial especialmente preparado para “adivinar” las necesidades de los clientes).  Creo que muchos al leer esto se sentirán identificados con parte del problema.

El auge de las metodologías ágiles y las herramientas nuevas que aparecen (con mucha frecuencia) creo que tienden un poco a nublar la visión de los gestores de proyecto, porque a veces no consultan la fuente de la información y se arma un lío gigante que es complicado de desenmarañar, campo que ha sido cultivo para que muchos “coaches” vean esto como una oportunidad de negocio para emprender (lo que encuentro genial!).  Cuando la base de todo esto se encuentra en la filosofía especificada en el Manifiesto Ágil, y que creo muchas personas debiésemos retomar de vez en cuando.  En resumen el manifiesto ágil dice:

  1. Las personas (individuos) e interacciones entre los individuos están POR SOBRE los procesos y las herramientas

  2. Software funcionando POR SOBRE documentación extensiva

  3. Colaboración con el cliente POR SOBRE la negociación de un contrato

  4. Responder a los cambios ANTES que seguir un plan (punto cuestionable de acuerdo a algunos dinosaurios del PMP)

Sobre la base de este manifiesto se crearon los 12 principios de agilidad para el desarrollo de software.  Sin embargo no deseo entrar tanto en detalle para concentrarme de lleno en explicar el problema y el porqué creo que esta metodología que he credo puede aportar en la “etapa de análisis” de las metodologías ágiles u otras más tradicionales.

El problema

“Cuando nosotros nos acercamos al cliente, asumimos que él sabe exactamente qué quiere hacer y nosotros le damos el cómo. Sin embargo, esto no es así y nuestro trabajo se convierte en algo así como adivinar el futuro con una bola de cristal.”.

¿Cómo enfrentar desde la perspectiva ágil el hecho de que sigue siendo importante poder obtener con antelación una validación de los requerimientos del cliente antes de que el producto salga al mercado? teniendo en mente que el objetivo es evitar por todos los frentes posibles que nos transformemos en verdaderos adivinos con una bola de cristal.

Sabemos por ejemplo que de acuerdo a SCRUM, la validación que hace el cliente (product owner) de la pila de requisitos (backlog desde ahora en adelante) no la podrá obtener sino hasta que se construya el primer incremento (potentially shippable product), es decir, hasta que pueda obtener una versión funcional del producto (testeable).  Sin embargo también sabemos que el Product Owner (PO desde ahora en adelante) es un agente partícipe activo del Sprint Planning, área que puede usarse para obtener con antelación una validación de este mismo stakeholder (involucrado).

Desde las primeras etapas del proceso de SCRUM cuando se comienza a recopilar la pila del producto (backlog), la única inferencia que el PO tiene en dicha pila es: para ordenar las historias de usuario.

Luego de armar las características de las historias especificadas con el comportamiento deseado desde la perspectiva del usuario, el PO no tiene inferencia hasta la etapa de planificación del sprint, donde básicamente se define:

  1. el What?
  2. el How?

y con lo anterior se genera el Sprint Backlog.

Luego durante 10 o 15 días (configurable de acuerdo al proyecto y las necesidades del PO), se comienza el desarrollo del primer sprint, y ya nos desconectamos completamente de la validación que podría hacer el PO sino hasta la entrega del incremento funcional.  De acuerdo a mi perspectiva la pregunta inicial planteada a modo de hipótesis sigue siendo:

¿Cómo enfrentar desde la perspectiva ágil el hecho de que sigue siendo importante poder obtener con antelación una validación de los requerimientos del cliente (PO) antes de que el producto salga al mercado?

Para poner más claro el problema me gustaría compartir con ustedes una discusión entre Zach Bonaker, agile coach de Willis Towers Watson y Jaya Shrivastava, coach de AGILE++ Engineering.  Obviamente personas que saben mucho más que yo.

Destaqué en rojo los temas que creo relevantes para el problema en cuestión.  Fuente: https://www.scrumalliance.org/community/articles/2014/august/why-definition-of-minimum-marketable-feature%E2%80%9D-is-a

La traducción es:

Zack:

Un equipo que desarrolla historias que resultan en un software que no se puede usar o que no tiene utilidad no es un fallo de una “definición de característica comercial mínima” (MMF). Es debido a un backlog muy pobre, probablemente el resultado de prácticas ágiles fallidas en las etapas iniciales donde el equipo planeó realmente el sprint.

Jaya:

Sí, cada iteración produce algo valioso, pero ¿los clientes lo usan?

En el mundo real, la respuesta es un rotundo NO. Los clientes no están dispuestos a asignar recursos para probar o liberar lo que se produce al final de los sprints.

En su lugar, los clientes están dispuestos a tomar incrementos que creen que pueden ser liberados al mercado.

Esto falta ya que no trabajamos lo necesario para poder liberar una característica mínima que sea comercializable.

Vaya problema…

El asunto importante es que si llegásemos a poder tener una validación inicial antes de la entrega del incremento funcional, podríamos disminuir un riesgo importante: que es justamente que el producto llegue defectuoso al mercado.

En una próxima entrega iré desmenuzando la solución (de acuerdo a mi visión) que adopté a través de la creación de esta metodología DWDP+1, que busca ir en apoyo de una definición más concreta y sencilla de requerimientos antes de entrar a las etapas de construcción.

Cualquier aporte es siempre bienvenido, sobre todo para corregir algunos temas principalmente relacionados con el mundo ágil.

Nos vemos en la siguiente entrega y buena lectura!

Anuncios

Deja un comentario

Archivado bajo CMMI, Desarrollo de Software, Ingeniería de Software

Crear aplicaciones Node.js usando Visual Studio Code. Parte I

Node.js es una plataforma para construir aplicaciones rápidas y escalables usando Javascript.  Node.js es el entorno de ejecución (runtime) y NPM es el administrador de paquetes (Package Manager) para los módulos de Node.js.

Para comenzar, lo primero que debemos hacer es instalar Node.js en nuestro sistema, en mi caso como poseo un sistema operativo de 64 bits (Windows 7).  Por lo que debemos ir a la página de descargas de Node.js y ubicar la versión correspondiente a nuestro sistema operativo, que por lo demás funciona perfectamente en Mac y Linux.  Por cuestiones de orden, yo dejo todos estos binarios en una carpeta fuera del directorio “program files”, en mi caso la ruta es: D:\Desarrollo, ustedes pueden ubicarlos en donde mejor lo estimen conveniente.

Durante el proceso de instalación de Node.js, el sistema instala automáticamente NPM y agrega las rutas a la variable de entorno PATH

Durante el proceso de instalación de Node.js, el sistema instala automáticamente NPM y agrega las rutas a la variable de entorno PATH.

Si por algún motivo tienen problemas durante la instalación de Node.js usando el msi, tenemos la alternativa de realizar la instalación de forma manual, para esto lo que debemos hacer es:

1) Descargar archivo ZIP desde http://nodejs.org/dist/, seleccionar la versión favorita de “Node.js” o simplemente tomar la última.  Asegurarse de que descarga el zip para versión x86 o x64 (recomendada: 6.6.0).

2) Luego, vaya a http://nodejs.org/dist/npm/ para descargar archivo ZIP de su versión favorita de NPM (recomendada: 1.4.12). Extraer el archivo en el mismo lugar donde se encuentra “NODE.EXE”.

Por último, añada el directorio donde instaló “Node.js” al PATH para mayor comodidad.  En ni caso: d:\desarrollo\nodejs\

3) Comprobar la instalación de Node.js abriendo una consola y ejecutar el comando:

2016-09-16_18-47-56

4) Actualizar npm para cerciorarnos de que tenemos la última versión, para ello ejecute el comando: npm install npm -g.  Ejecutar comando estando dentro del directorio de nodejs.

5) Comprobando las versiones.  node –version y npm –version

Creando una aplicación sencilla

Por asuntos de orden me he creado un directorio dentro de la carpeta desarrollo para este proyecto de ejemplo que he llamado AppNodeJS y dentro de este directorio otro llamado HelloWorld.

Ejecutamos en una consola:

mkdir Hello

cd Hello

code .

Este último comando (code .) nos abrirá VS Code ubicados ya dentro del directorio.

Creamos un nuevo archivo

File Explorer New File

Y lo llamamos app.js

File Explorer app.js

Dentro del archivo escribimos el siguiente código

2016-09-16_19-07-30

Y guardamos los cambios (ctrl+s)

Finalmente desde una consola ejecutamos el comando node.app.js para probar nuestra aplicación.

2016-09-16_19-09-08

 

 

Depurando nuestra aplicación en VS Code

Poner un breakpoint (F9) en nuestra primera línea de código.

app.js breakpoint set

Ahora vamos a configurar el depurador para este simple espacio de trabajo.  Para esto, selecciona la vista debug:

Debug icon

Haga clic en el icono de Configurar o reparar en la parte superior de la vista de depuración para crear un archivo de configuración launch.json por defecto y seleccione Node.js como el entorno de depuración. Este archivo de configuración le permite especificar cómo iniciar la aplicación, qué argumentos para pasar en el directorio de trabajo, y algunas otras cosas. El nuevo archivo launch.json se crea en una carpeta específica .vscode en la raíz de nuestro espacio de trabajo.

hello world launch json

Con la configuración por defecto creada ya puede comenzar a depurarse la app, ahora es posible hacer clic en la barra de depuración (botón play verde) o presione F5  para poner en marcha y depurar nuestro programa “Hola Mundo”. Su punto de interrupción se verá afectado y puede ver y desplazarse por la aplicación. Tenga en cuenta que VS Code muestra una barra de estado  naranja para indicar que está en modo de depuración y además se muestra la consola de depuración.

2016-09-16_20-13-37

Con esto ya tenemos montado nuestro entorno de desarrollo para comenzar a desarrollar aplicaciones basadas en Node.js.  En un siguiente artículo explicaré como crear una app más completa usando VS Code y Node.js.

Fuente: https://code.visualstudio.com/Docs/runtimes/nodejs

Deja un comentario

Archivado bajo Desarrollo de Software