domingo, julio 27, 2014

La metodología garantiza el proceso mas no el producto

Existe una falsa ilusión en las empresas y en los ingenieros de software al adoptar (o idolatrar) una determinada metodología de desarrollo de software, esta falsa ilusión es soportada por esta famosa frase de Watts Humphey:


 "La calidad de un producto la determina el proceso usado para desarrollarlo."

Leamos en este caso proceso como METODOLOGÍA,  por lo tanto re-editando quedaría:



 "La calidad de un producto la determina LA METODOLOGÍA usada para desarrollarlo."



Y dicen:  wow si, encontramos la bala de plata  para la solución de todos nuestros problemas.

Lo cierto es que solo lograron resolver uno de los vértices de mejora de la calidad[1], resolvieron el vértice de los procesos , quedando pendientes las personas y las herramientas.



Por lo tanto si solo nos enfocamos en el proceso, quedan las siguientes preguntas sin resolver:

  • Respecto a las personas:
    • Equipo proveedor
      • ¿Son el equipo adecuado?
      • ¿tienen los conocimientos adecuados?
      • ¿saben trabajar en equipo?
      • ¿saben usar las herramientas?
      • ¿saben usar el proceso y lo tienen interiorizado?
      • ¿el líder del equipo es "un buen lider"?
      • ¿existen relaciones tóxicas que los van a afectar en el desarrollo?
      • ¿se entienden con el cliente y su equipo?
      • ¿existe alguien con liderazgo negativo en el equipo?
    • Equipo cliente
      • ¿El equipo del cliente es el adecuado? ¿son los correctos?
      • ¿tienen el conocimiento?
      • ¿saben que es lo que quieren?¿o fueron encargados de hacer el software de otra área?
      • ¿manejan bien el proceso?
      • ¿saben como interactuar con el proveedor?
      • ¿existen intereses de este cliente que compiten con los intereses con los de los proyectos?
  • Respecto a las herramientas
    • ¿las herramientas son las adecuadas para el proyecto?
      • Hardware
      • Software
      • IDE´s
      • etc
    • ¿se tiene el correcto manejo de ellas por parte de los involucrados?



Por lo tanto, podemos afirmar como el título de este artículo (cuya frase no es de mi autoría -  aclaro busqué el referente y no lo encontré - ):


"La metodología garantiza el proceso mas no el producto"

Bienvenida la discusión


Saludos ágiles

Jorge Abad.








[1]    CHRISSIS, Mary Beth, KONRAD, Mike and SHRUM, Sandy; (2007). CMMI: Guidelines for Process Integration and Product Improvement. Second Edition. Pearson Education, Inc., Boston, MA, USA, 676 p.

viernes, julio 18, 2014

Unas citas que me encontré y me gustaron

Les comparto unas citas que encontré, muchas tomadas de http://jummp.wordpress.com/ (este es uno de los blogs que tengo pendiente por recorrer)

Watts Humphrey
  • "For a new software system, the requirements will not be completely known until after the users have used it" / "Para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después de que los usuarios hayan usado el sistema" (Es la frase que más me gusta y es conocida como "el principio de Incertidumbre de los requisitos de Humphrey" )
  • La calidad solo la producen profesionales motivados orgullosos de su trabajo.
  • Para gestionar la calidad los desarrolladores deben medirla
  • Si el cliente no demanda calidad, probablemente no la conseguirá
  • Para obtener calidad de manera constante los desarrolladores deben gestionarla en su trabajo.
  •  La calidad de un producto la determina el proceso usado para desarrollarlo.

Peter Drucker
  • “Lo que se puede medir se puede mejorar" (se infiere también lo contrario: "Lo que NO se puede medir NO se puede mejorar")
  • Lo mas importante de la comunicación es escuchar lo que no se dice
  • La mejor manera de predecir el futuro es crearlo
  • Emprender no es ni una ciencia, ni un arte, es una práctica.
  • Gestión es hacer las cosas bien, liderazgo es hacer lo correcto.
  • A los elefantes les cuesta mucho adaptarse, las cucarachas sobreviven a todo.
  • Lo que motiva a trabajadores del conocimiento es lo mismo que motiva a voluntarios… necesitan, sobre todo, retos.
  • Planes sólo son buenas intenciones, excepto si inmediatamente devienen en trabajo duro.
  • La persona de quien desconfiar es la que nunca ha cometido errores; o es farsante o sólo sigue el camino seguro y trivial. Entre más buena sea una persona, más errores cometerá.
  • Donde hay una empresa de éxito, alguien tomó alguna vez una decisión valiente.
  • La mejor estructura no garantizará los resultados ni el rendimiento. Pero la estructura equivocada es una garantía de fracaso.


S . McConnell
  • “No tenemos tiempo para mejorar y como no mejoramos no tenemos tiempo” 


Publio Sirio, siglo I a.C.
  • “Es un mal plan aquel que no admite modificación”


Eisenhower
  • “El plan no es nada, la planificación lo es todo”. 


Churchill
  • "Los planes tienen poca importancia, pero la planificación es esencial" 


Lucho Salazar - @luchosalazarchttp://www.gazafatonarioit.com/
  • "ser ágil quiere decir reemplazar la predictibilidad falsa, por la eficiencia"


Lewis Carroll (del libro "Alicia en el País de las Maravillas")
     Alicia preguntó al gato:
     -¿Podrías decirme, por favor, qué camino he de tomar para salir de aquí?
     -Depende mucho del punto adonde quieras ir- contestó el Gato.
     -Me da casi igual dónde- dijo Alicia.
     -Entonces no importa qué camino sigas- dijo el Gato".




__

lunes, julio 14, 2014

Tabla comparativa entre Metodologías Tradicionales y Ágiles

Hola a todos

Aunque hace algún tiempo había recopilado una comparación gráfica entre metodologías ágiles y tradicionales (clic aquí para ver -> ), quiero compartir hoy un cuadro comparativo que realicé. Espero les sirva de ayuda.

Aspecto
Robusta o tradicional
Ágiles
Requisitos
Requieren los requisitos detallados desde el inicio del proyecto. 

Los requisitos no pueden cambiar
Los requisitos son muy cambiantes.

La verdad es que en software los requisitos cambian continuamente, y se requiere de un feedback sobre un resultado obtenido para determinar si es lo requerido o no.

Requisitos (funcionalidades innecesarias)
Debido a la recolección inicial de requisitos es frecuente que se soliciten funcionalidades innecesarias
El enfoque continuo en el valor para el negocio no permite que se incluyan funcionalidades innecesarias

Cambios
Hacer un cambio al alcance requiere de un proceso formal de control de cambios
El cambio es bienvenido en cualquier momento del proyecto
Tiempo
Existe un compromiso respecto al tiempo de entrega del proyecto 

(no siempre se cumple esta meta)
Existe incertidumbre respecto al tiempo de entrega de todo el producto.

Lo cierto es que máximo cada 2 meses (máximo un mes en scrum) hay entrega de producto de valor para el cliente
Costo
El costo del proyecto es definido para el proyecto
Existe incertidumbre respecto al costo del proyecto.

Se invierte en las funcionalidades que más valor le dan al cliente y ciclicamente se avanza hasta que se logre, ya sea:

  • el producto deseado
  • se acabe el presupuesto
Documentación
Atención exhaustiva a la documentación.
Solo se genera la documentación que genera valor al cliente y al proyecto
El cliente
El cliente apoya el desarrollo del producto mediante la participación en reuniones.
Involucración directa del cliente en el desarrollo del producto

El cliente es parte de equipo.
Iteraciones
Pocas iteraciones que generan gran volumen de información y software para construcción del producto.
Utilización de múltiples iteraciones de desarrollo para aprender y evolucionar el producto
Riesgos
Los riesgos son asumidos por el proveedor

Voluntad del cliente para compartir la responsabilidad en las decisiones y riesgos[1]


Se valora más
El proceso
El individuo y las interacciones de los mismos
La planeación
Requieren un plan detallado desde el inicio del proyecto
Se va planeando a medida que se avanza en el proyecto. Planeación gradual y constante.
El éxito del proyecto
Es dado por el seguimiento del plan
Es dado por la entrega continua de valor y funcionalidad al cliente
Elaboración de entregables
Se generan entregables que requieren mucho tiempo de elaboración.
Se centran en hacer entregables en tiempos cortos con alta calidad inmersa
La retroalimentación del cliente
Es conocida al final, pudiendo generar insatisfacción.
Es constante a lo largo del proyecto
Participación del equipo
Empodera al Gerente de proyecto para el éxito del mismo, este decide si participa de este poder o no al equipo o no.
Empodera al equipo para trabajar de forma creativa e innovadora.
Proceso(Plantillas)
Innumerables plantillas y artefactos para cumplir con el proceso
Pocas plantillas y artefactos 

(solo los estrictamente necesarios para construir el producto)
Roles
Muchos roles para ejecutar el proyecto
Pocos roles
Arquitectura
Es un ejercicio que se realiza al inicio o en una etapa del proyecto.
Es un ejercicio constante durante el proyecto




-[1] Software Engineering Institute. CMMI®  para Desarrollo, Versión 1.3 . [en línea] Disponible en:

viernes, junio 27, 2014

El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo

Existe una corriente dentro de Scrum que argumenta que cuando el equipo es maduro no es necesario el SM, es una postura respetable, pero en el artículo copiado al final, expone una serie de razones por las cuales el SM es necesario para el equipo, aunque este se encuentre maduro o en un alto grado de madurez.

En mi opinión, coincido con el autor, pues por más auto-gestionado que sea el equipo, alguien que este enfocado en facilitar y apoyar al equipo, y a la organización, tendrá más habilidades y disposición que alguien que esta enfocado en la calidad del producto que esta construyendo.


queda abierta la discusión...







Ver más...


jueves, junio 12, 2014

Ser ágil es y no es...

Tal vez de las principales discusiones que hay en el inconsciente colectivo de los ingenieros de software es ¿qué significa ser ágil?, algunos creen que es:

  • no planear
  • no cumplir horarios
  • no cumplir compromisos
  • no hacer ni ingeniería, ni arquitectura
  • no documentar
  • desarrollar a "la maldita sea", (como caiga el código con tal de entregar rápido).
  • no tener un proceso ordenado
  • y creer que la propiedad colectiva del código les solucionará sus malas prácticas.


Para mí ser ágil completamente diferente, :
  • es estar centrado en las personas y los equipos, su motivación y capacidad de auto-critica para buscar la mejora en todos los aspectos (personas, software, procesos y herramientas).
  • es ser disciplinado
  • es enfocarse en entregar software funcionando, de forma temprana, rápida, frecuente y de valor para el cliente
  • es trabajar de forma colaborativa y transparente con nuestros clientes
  • es planear constantemente (no solo al inicio), para lograr el objetivo (visión) y estar afinando y mejorando la estrategia. Es tener un plan adaptable centrado en el valor.
  • es cumplir los compromisos
  • es tener en el centro una buena arquitectura, pero tener el valor para cuestionarla y reemplazarla si es necesario.
  • es tener buenas prácticas de ingeniería (integración continua, tdd, atdd, refactoring, etc)
  • es respetar los procesos, pero estar repensando cada retrospectiva como hacerlos mejor o como hacerlos más livianos de forma que sea más fácil convivir con ellos, entreguen más valor al software y a nuestros clientes.
  • es poner a disposición de nuestros clientes nuestra capacidad y equipos que le permita enfocarse en sus prioridades de negocio.
  • es tener un equipo que no le tiene aversión al cambio, y que recibe el cambio con facilidad y lo plasma fácilmente en el software
  • es tener la capacidad de moverse con flexibilidad y rapidez para responder de forma efectiva a las necesidades del cliente

  • es hacer solo la documentación que agrega valor
  • es buscar ser liviano, práctico y excelente en todos los aspectos que tocamos o involucramos para construir software de valor en nuestros clientes.
  • es tener capacidad de responder al cambio y liberarnos de la sicorigidez de los planes, cascada y RUP. 
  • ser ágil es trabajar con foco y coraje, buscando en hacer cada vez más con los recursos que tenemos pero sin llevar nuestras fuerzas al límite.
  • es estar trabajando en la inspección y adaptación del equipo, proceso y producto, cuestionando de forma transparente para mejorar el ecosistema en el que construimos las soluciones de software.
  • es estar enfocado en la felicidad y motivación del equipo para lograr resultados sorprendentes.
  • es estar abiertos a que la mejora emerja de cualquiera, no solo de los proclamados líderes: gerentes de proyecto, o analista líder, o líder de procesos.
  • ser ágil es estar abierto a intentar, a fallar rápido para aprender, pero no es una alabanza al error, pero es ver en los errores que se cometen una oportunidad de oro corregir el camino, para hacerlo mejor
  • Ser ágil es una forma de vida más comprometida, que no es sico-rigida, es organizada, más consciente , y tiene claro que hacer software es complejo y no es predecible (según nuestro actual estado del arte), por lo que se deben proporcionar entornos donde se logre la mayor eficacia y eficiencia.

jueves, abril 17, 2014

Una versión inicial de Definition of Done (Definición de Hecho / Terminado / Realizado)

La  Definition of Done -  DoD - (Definición de Hecho / Terminado / Realizado) es el estándar de calidad que debe cumplir el equipo Scrum, es aquello que les garantiza que han cumplido lo que se han comprometido y que el "Incremento"  de funcionalidad es realmente "potencialmente entregable"

La mejor definición de "done" la leí de Alan Cyment:
 "ALGO ESTA HECHO CUANDO NO TENGO QUE VOLVER A PREOCUPARME DE ELLO"

Si el equipo de desarrollo o alguien del equipo siente que no esta totalmente hecho y ejemplo:

  • falta un despliegue
  • falta una validación
  • duda si se realizaron toda la documentación comprometida
  • o le da "susto" salir a producción con el desarrollo realizado (el incremento de software) por que sabe que tiene unos "pendientes" o cree que le van a reventar en producción muchos bugs
entonces no esta realmente "Done"

La DoD debe estar publica y disponible para el equipo, debe ser un acuerdo entre todos:
  • Product Owner
  • Teaam Developer
  • Scrum Master
Este acuerdo se realiza inicialmente en el sprint cero y se va revisando en cada sprint planning (como fruto de nuevas necesidades o resultado de las retrospectivas), Si hay cambios en la DoD,  es casi seguro que impliquen nuevas tareas en cada sprint.

Aunque el Team Developer (Equipo de Desarrollo) debe ser responsable de cumplir la DoD, el que debe velar por que se logre este compromiso es el Scrum Master.

A continuación les comparto una versión inicial que puede ser evolucionada, corregida, mejorada o aumentada por cada equipo Scrum:

DEFINICIÓN DE HECHO
  • Cada historia de usuario/funcionalidad este codificada, compilada, desplegada por el servidor de integración continúa.
  • Las historias de usuario/funcionalidades cumplan todos los criterios de aceptación acordados con calidad(QA), el Product Owner al inicio del sprint.
  • Las historias de usuario/ funcionalidades construidas no afecten a las funcionalidades ya entregadas, por lo que las pruebas de regresión deben ser satisfactorias.
  • Las funcionalidades/historias de usuario comprometidas funcionen en todos los ambientes comprometidos, ej:
    • Laboratorio
    • Pruebas
    • Preproducción
  • Las funcionalidades/historias de usuario cuentan con pruebas funcionales automatizadas y despues de correr estas el resultado es exitoso.
  • No se tienen advertencias en Rojo en la verificación de código del servidor de integración continua (Sonar) - en caso que estemos trabajando con Jenkins y Sonar - .
  • Las clases de negocio cuentan con pruebas unitarias que verifican su correcto funcionamiento.
  • El Código desarrollado se comentado y estandarizado.
  • Código en el repositorio de control de versiones.
  • El porcentaje de cobertura de pruebas unitarias al código es >= a un XX%
  • El porcentaje de cobertura de pruebas funcionales automatizadas a las funcionalidades/historias de usuario es >= a un XX%
  • Se genere y/o actualice la documentación comprometida para el Sprint
    • Documento de arquitectura
    • Documento de diseño
    • Manual de Usuario
    • Plan de pruebas
    • u otro documento del proceso de desarrollo que le agregue valor al proyecto o que contractualmente estemos comprometidos a entregar
  • [nuevo] Se cumpla con los requisitos no funcionales, por ejemplo:
    • Estándares gráficos
    • Estándares de usabilidad y UX
    • Navegadores y versión de los mismos sobre los que debe funcionar
    • Servidores de base de datos y de aplicaciones sobre los que funcionará
    • Tipo de servicios a emplear
    • etc.



sábado, abril 05, 2014

Twits sobre agilidad y scrum


jueves, abril 03, 2014

Dos twets sobre la felicidad de los equipos de scrum






Recomiendo estos post sobre la felicidad y su efecto en nuestra vida laboral. La importancia de la felicidad en el trabajo es altísima, pues allí pasamos la mayoría de nuestro tiempo y si eso nos aburre, estamos en el lugar equivocado.

http://reflexiones-divinas-y-profanas.blogspot.com/search/label/felicidad


UNA ÚLTIMA FRASE


"SI ODIAS LOS LUNES, CAMBIA DE TRABAJO"


_

martes, abril 01, 2014

Product Backlog Ejemplo - Social Restaurant Wall - SoReWa - Alejandro Arbelaez

Hola a todos

Les comparto un Product Backlog de ejemplo de un proyecto de grado que estoy dirigiendo basado en historias de usuario. El proyecto se llama   Social Restaurant Wall -  SoReWa - eleborado por  Alejandro Arbelaez Acevedo (dragon198658 (at )gmail.com ).

Los Criterios de Aceptación se encuentran en Formato BDD

SCENARIO– Escenario
GIVEN – DADO
WHEN – CUANDO
THEN – ENTONCES

Impor
tancia
Yo como
Deseo
Para
Criterios de Aceptación
en Formato BDD


 1000
Gerente
Crear un menú
Ofrecerle los productos a mis clientes
Escenario 1: No hay un menú creado.
DADO  que este en la pantalla de gerente
Y No haya un menú creado
CUANDO ingrese a gestionar menú
ENTONCES se crea un menú básico con 2 categorías comidas bebidas

-----

Escenario 2: Ya hay un menú creado.
DADO que este en la pantalla de gerente
Y ya hay un menú creado
CUANDO ingrese a gestionar menú
ENTONCES se muestra el menú que ya existe
 980
Gerente
Agregar producto al menú
Para agregar variedad o actualizar mi menú
Escenario 1: Agregar un producto
DADO que este en la pantalla de gestionar menú y llene los campos de un producto
CUANDO  de en el botón guardar
ENTONCES se agrega un producto al restaurante
 960
Gerente
Quitar producto del menú
Quitar productos poco pedidos o que den perdidas
DADO que estoy en la lista de productos
CUANDO oprima el botón eliminar de un producto
ENTONCES se quita ese producto de la lista de productos del restaurante
 940
Gerente
Crear categorías de productos
Para organizar mejor los productos que ofrezco
Escenario 1: hay Categorías.
DADO  que este en el menú del restaurante
CUANDO  llene los campo y de en el botón agregar categoría
ENTONCES se agrega un a nueva categoría al menú
 920
Gerente
Eliminar categoría de productos
Para organizar mejor los productos que ofrezco
Escenario 1:Hay categorías
DADO que este en el menú del restaurante
CUANDO  elija una categoría y de en el botón eliminar
ENTONCES se da una notificación de eliminar y si se confirma se elimina la categoría del menú del restaurante.

----

Escenario 2: No hay categorías
DADO que no hay categorías en el menú
CUANDO  se  de en el botón eliminar
ENTONCES el botón se deshabilita.


 900
Gerente
Editar categorías de productos
Para organizar mejor los productos que ofrezco
Escenario 1: hay categoría
DADO  hay categorías en el menú del restaurante Y se elija una.
Y se editen los campos de la categoría
CUANDO de en el botón guardar
ENTONCES se actualizan los datos de la categoría del menú del restaurante.
 880
Cliente
Ver el menú del restaurante
Poder elegir la comida que voy a pedir
Escenario 1: Elegir categoría
DADO que hay categorías
CUANDO elija una categoría
ENTONCES se muestran los productos de esa categoría


 860
Cliente
Ver detalles de un plato
Poder elegir la comida que voy a pedir
Escenario 1: Hay productos en categoría
DADO Que hay productos en una categoría
CUANDO este navegando la lista de productos
ENTONCES debo poder ver la información detallada del plato(nombre, precio y descripción)
 840
Cliente
Ver disponibilidad de plato
Para ver que productos no puedo pedir
Escenario 1: El plato no está disponible
DADO
hay un plato que no esté disponible y se haya marcado como no disponible
CUANDO esté viendo el menú del restaurante
ENTONCES el plato no se debe mostrar

-----


Escenario 2: El plato está disponible
 820
Cliente
Agregar uno o más productos a mi pedido
Hacer el pedido y poder comer
Escenario 1: Agregar producto a la orden
DADO que quiera agregar un producto
CUANDO oprima el botón “+” para agregar un plato (o más si se toca varias veces)
ENTONCES se agrega(n) el(los) plato(s) al pedido


----

Escena 2: agregar más de un mismo plato
DADO que ya agregue un plato
CUANDO vuelva a darle al botón “+”
ENTONCES este plato se agrega a la orden

----

Escena 3: se hizo un pedido
DADO que se haya hecho un pedido Y aun no se haya pedido la cuenta
CUANDO de al botón “+” de un producto este se agrega al pedido ENTONCES se pregunta si se desea hacer el pedido del producto agregado.


------

Escena 4: se pidió la cuenta
DADO que se pidió la cuenta
CUANDO se vaya a agregar un producto a la orden
ENTONCES La orden no permite agregar más productos
 800
Cliente
Quitar un producto del pedido
Elegir un plato diferente si cambie de parecer y luego hacer el pedido
Escena 1: No se ha despachado el pedido
DADO que estoy en la página del pedido
Y quiera quitar un plato de este Y este no haya sido ya despachado
CUANDO oprima el botón de quitar”-”
ENTONCES este plato se debe quitar del pedido

-----


Escena 2:Se ha despachado el pedido
DADO que un pedido ya ha sido pedido
Y el mesero lo haya marcado como despachado
CUANDO vaya a eliminar un producto de la orden
Desde el cliente de la mesa
ENTONCES se hace un llamado al mesero


-----

Escena 3: Se pidió la cuenta
DADO que se pidió la cuenta
CUANDO los productos ya hayan sido despachados
ENTOCES el cliente ya no puede eliminar el producto desde la terminal de cliente y se ocultan los botones de eliminar producto

 780
Cliente
Hacer pedido
Poder comer los platos que pedí
Escena 1: Hay uno o mas productos en la orden
DADO que estoy en la lista del pedido
Y
CUANDO una el botón de “ordenar”
ENTONCES se envía la notificación a los meseros del pedido con el pedido de la mesa

------


Escena 2: No hay productos en la orden
DADO que no hay productos en la orden
CUANDO se oprima el botón de hacer pedido
ENTONCES se saca un mensaje que diga que no se puede hacer un pedido porque no hay platos en la orden

-----

Escena 3: Ya se pidió la cuenta
DADO que ya se pidió la cuenta
CUANDO se de en el botón hacer pedido
ENTOCNES este botón de pedido se bloquea y se pone un mensaje diciendo que ya el pedido esta por pagarse


-----

Escena 4: hay productos sin despachar
DADO que haya uno o más productos sin despachar
CUANDO se oprima el botón de pedido
ENTONCES se notifica del pedido nuevamente a los meseros
 740
Cliente
Llamar a un mesero
pedir ayuda o asesoría en la mesa
DADO en cualquier parte de la aplicación
CUANDO unas el botón de llamar mesero
ENTONCES se muestra una notificación a los meseros avisándoles que en esta mesa en específico necesitan a un mesero
 720
Mesero
Ver el menú del restaurante
Poder ver buscar los productos que el cliente quiere adicionar a su pedido
Escena 1: No hay ordenes de mesa
DADO que no hay ordenes de mesa
CUANDO de al botón ver menú restaurante
ENTONCES se me presenta una ventana con el menú del restaurante, sin las opciones de agregar a orden

----

Escena 2: hay orden de mesa
DADO que hay una orden de mesa
Y de ver orden d mesa
CUANDO de al botón ver menú restaurante
ENTONCES se me presenta una ventana con el menú del restaurante, con la opción de agregar los platos a la orden de una mesa

Mesero
Ver detalles de un plato
Poder ver la información más detallada de los pedidos
DADO  que estoy viendo el menú del restaurante
CUANDO este navegando la lista de productos
ENTONCES este me debe mostrar sus detalles
 700
Mesero
Agregar uno o más productos a al pedido de un cliente
Cambiar el pedido de los clientes en caso de ellos requerir un cambio
Escena 1: no hay productos
DADO  que no hay productos en una orden
CUANDO oprima el botón”+” agregar producto a pedido
ENTONCES se agrega el producto al pedido y se actualiza el valor total del pedido

----

Escena 2: hay productos en la orden
DADO que hay productos en una orden
Cuando de al botón “+”
ENTOCNES se agrega a la orden de mesa. se actualiza el valor total del pedido

 680
Mesero
Quitar un producto del pedido
Cambiar el pedido de los clientes en caso de ellos requerir un cambio
DADO  Que quiera quitar un producto de un pedido
CUANDO oprima el botón”-” quitar producto a pedido
ENTONCES se quita el producto al pedido y se actualiza el valor total del pedido
 660
Mesero
Ver si un cliente me llama desde su mesa
Poder ir a atenderlo
Escena 1: Cliente hunde el botón llamar mesero
DADO que estoy en la página de atención de mesas
CUANDO  un cliente oprima el botón llamar mesero
ENTONCES se mostrara una notificación de la mesa donde se hace el llamado
 640
Mesero
ver una pedido de una mesa
Enviarlo a cocina
Escena 1: llega pedido
DADO que llegue un pedido de una mesa
Y Aparezca la notificación
CUANDO toque el número de la mesa
ENTONCES debo poder ver la lista de los productos y la mesa de dónde provino el pedido


----

Escena 2: mesa con pedido
DADO que hay una mesa con un pedido
CUANDO toque el botón de la mesa
ENTONCES se muestra al orden de la mesa
 620
Cliente
Ver mi pedido
Ver el estado de este y hacerle seguimiento a lo que consumo
DADO cualquier punto de la aplicación
CUANDO oprima el botón de pedido
ENTONCES se muestra la lista de productos de la orden de la mesa
 600
Cliente
Pedir la cuenta
Pagar lo que he consumido
DADO que este en la lista del pedido
CUANDO una el botón pedir cuenta
ENTONCES se muestra una notificación a los meseros que el cliente desea pagar la cuenta
 580
Mesero
Que me alerten cuando un cliente quiere pedir la cuenta
Poder generar una factura y llevársela al cliente para que este pague su cuenta
DADO  que este en la pantalla de atención de mesas 
CUANDO  que un cliente haya hundido el botón pedir cuenta
ENTONCES se muestre la notificación de la mesa  
 560
Mesero
Atender el pedido de una mesa
Para que el cliente sepa que ya se le tomo la orden
DADO que ya se haya entregado a cocina el pedido
CUANDO oprima el botón “despachar pedido”
ENTONCES se le envía una notificación a la mesa y se marcan los productos como despachados
 520
Mesero
Saber si un cliente agrego más platos a su pedido, después de haber atendido su pedido
Enviar a cocina
DADO que un cliente agregó uno o más productos a la orden
CUANDO  de "actualizar"  pedido
ENTONCES se notificará al mesero y en la lista del pedido de verá el estado de los productos pendientes
 500
Mesero
Ver el tiempo que lleva una mesa esperando atención
Saber que clientes debo atender primero
DADO  que este en la pantalla de atención de mesas
Y haya una notificación de llamado de una mesa
CUANDO se alerte
ENTONCES se muestre un cronometro que vaya contando el tiempo desde que se generó el llamado
 500
Mesero
Ver disponibilidad de plato
Para ver que productos no puedo añadir al pedido de mi cliente
DADO  que este en el menú de restaurante
CUANDO  este navegando los productos o vaya a agregar lo y no está disponible
ENTONCES se notifica que el producto no es válido para agregar al pedido
 440
Cliente
Ver si mesero recibió mi llamado
Para saber que me van a atender pronto
DADO que haya llamado un mesero
CUANDO el mesero acepte la notificación
ENTONCES se mostrara una notificación en la mesa que dice que el mesero los atenderá pronto
 420
Gerente
Ver cantidad de veces que un producto ha sido pedido
Conocer los productos más populares
DADO  que este en la pantalla de los productos del restaurante
CUANDO  esta cargue
ENTONCES se muestra el nombre del producto con su costo y la cantidad de veces que se ha pedido