domingo, agosto 31, 2014

Software funcionando sobre....¿pruebas exhaustivas e intensivas?

Siempre me he mantenido en algo que aprendí de tantas conversaciones con mis amigos y compañeros haciendo software, y de la experiencia:

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y NO AL CONTRARIO

igual se podría leer en el contexto organizacional

LA CALIDAD 
Y/O PROCESOS DEBEN TRABAJAR PARA LA ORGANIZACIÓN Y NO AL CONTRARIO 


En Agile damos prioridad a software funcionando, pero es necesario hacer pruebas, ¿cuántas?¿cuáles?, la repuesta es: todas y cada una que le permitan entregar un software funcional y de valor, de modo que usted no pierda la tranquilidad y el sueño luego de terminar su jornada laboral, léase entonces:

  • pruebas par
  • pruebas unitarias
  • pruebas funcionales
  • pruebas de integración
  • pruebas de seguridad
  • pruebas de compatibilidad
  • pruebas de adaptabilidad 
  • pruebas de instalabilidad..
  • pruebas de stress
  • etc
  • etc
  • etc
Pero cuantas y cuales..vuelvo y lo repito  LAS NECESARIAS ni una más, ni una menos.

A que se refiere esto, por ejemplo dentro de las prácticas ágiles se encuentran:
  •  TDD : Test driven development - desarrollo dirigido por las pruebas
  • ATDD: Aceptance test driven development - desarrollo dirigido por las pruebas de aceptación
Y hablamos de cobertura (cuantas pruebas aseguran nuestro código).

Sobre lo que quiero llamar la atención es:
  • NO ES NECESARIO cubrir todo el código con pruebas unitarias (ejemplos los POJO, DTO, o VO no lo requieren), solo objetos que tengan lógica de negocio (es mi humilde recomendación, ahora si a tu equipo esto le agrega valor, lo acepto y difiero respetuosamente).
  • Ni es estratégico  volcarse a una cobertura de 100% de pruebas sobre el código.

Nuestro objetivo es proveer software funcional, las pruebas nos ayudan a hacer software funcional pero como tal:
  • Las pruebas no son un entregable que agregue valor al cliente, me explico, si hacemos pruebas o no al cliente no le interesa, a el solo le interesa que funcione y no falle..
  • Las pruebas codificadas se convierten en una pieza de código más para mantener
    • incluir en el servidor de integración continua
    • hacerle refactor
    • corregir,
    • adaptar,
    • etc
Por lo tanto,  hagamos las pruebas suficientes para estar tranquilos y que nos aseguren ENTREGAR SOFTWARE DE CALIDAD.


LA CALIDAD NO ES NEGOCIABLE...

Pero 

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y el no software para cumplir con tdd del 100%, atdd del 100%, etc, etc.



Saludos ágiles
Jorge Abad

domingo, agosto 24, 2014

Inspección y adaptación: Claves para las Personas, Producto y Proceso

Como lo dice la guía de Scrum para resolver problemas adaptativos complejos (como lo es la construcción de un producto software) es necesario el uso del empirismo (teoría de control de procesos empírica), o sea que el conocimiento procede de la experiencia y se debe tomar decisiones basándose en lo que se conoce.

El empirismo tiene tres pilares:

  • Transparencia: Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado
  • Inspección: revisar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo, para detectar variaciones y Adaptación
  • Adaptación: Corregir desviaciones lo antes posible para que el resultado obtenido sea el esperado
Por lo general tomamos la inspección y adaptación (también reflejada en el ciclo de Demming de PHVA - planear, hacer, verificar y actuar - de mejora continua) solo para la construcción  iterativa e incremental del producto, mas lo que quiero enfatizar en este post es que se debe hacer Inspección y Adaptación para :
  • el Proceso 
    • como se esta construyendo el producto
    • las herramientas usadas
    • el nivel de documentación (adecuado, inadecuado, excesivo)
    • estado y corrección de la deuda técnica
    • la forma e intensidad como hacen prácticas técnicas
      • programación por pares
      • integración continua
      • BDD
      • TDD
      • ATDD
      • entre otras
    • Proceso de despliegue
    • Efectividad de las reuniones de Scrum
    • Timebox de las reuniones
    • la transparencia del proceso
    • etc
  • las Personas
    • Las relaciones
    • el funcionamiento del equipo
    • el trabajo en equipo
    • la felicidad del equipo
    • el funcionamiento de las personas en las roles encomendados
    • la comunicación
    • la liberación de tensiones
    • la sobrecarga de alguien
    • la falta de compromiso de alguien
    • la falta de compromiso del equipo
    • la falta de foco
    • la rigidez de algun miembro del Equipo Scrum (ya sea: Scrum Master, Product Owner, o Team Developer)
    • la transparencia en las relaciones
    • etc
  • y obviamente el Producto y su forma en como esta siendo construido
    • estamos realmente construyendo lo que le da valor al negocio (el 20% de las funcionalidades que apoyan el 80% del negocio)
    • el producto esta cumpliendo la definition of done
    • Cuando es el proximo realease
    • entre muchos otros aspectos

Y los momentos de Inspección y Adaptación para estos tres elementos claves de Scrum son:
  • Review para el producto
  • Retrospectiva para el proceso y las personas
Espero que los equipos ágiles ( Scrum Masters, Product Owners y Team Members) aprovechen estos espacios y ciclos para la mejora continua (kaizen) de estos tres aspectos fundamentales en sus proyectos y logren llevar sus productos, procesos y relaciones a niveles de gran valor para todos los involucrados.


Saludos ágiles


Jorge Abad


martes, julio 29, 2014

Pékerman, el CEO del año

Tomado de: http://www.dinero.com/edicion-impresa/caratula/articulo/jose-nestor-pekerman-lecciones-liderzgo-para-colombia/198378



Una visión que nos deja demasiados elementos tanto de la gerencia del proyectos, como el liderazgo de equipos, como la conformación de los mismos

Me tomaré el atrevimiento de marcar lo que me impactó.
_______________

Pékerman, el CEO del año

El mayor éxito futbolístico en la historia de Colombia es el resultado de un trabajo de largo plazo. Ocho lecciones de liderazgo y gestión para los empresarios colombianos.
José Néstor Pékerman y su equipo de trabajo acaban de alcanzar el mayor de los logros en la historia del fútbol colombiano: poner a Colombia como la quinta mejor selección en un Mundial de Fútbol. De paso, le enseñaron a este país que sí es posible pensar en metas grandes y ambiciosas y que los colombianos no estamos condenados a ser siempre perdedores dignos. Podemos ganar.

La Selección Colombia no solamente jugó bien, sino que deslumbró al mundo entero. Comentaristas de Europa y Estados Unidos destacaron su estilo y el altísimo nivel del equipo. El comentario de Sally Jenkins, columnista del Washington Post, lo resume todo: “Una cosa es tener un equipo del cual estar orgulloso por su valiente actuación, y otra tener un equipo que todo el planeta quiere ver”, dijo al ubicar a Colombia entre las mejores selecciones del mundo.

Además, Pékerman logró algo que en Colombia es extraordinario. Construyó un proyecto colectivo, donde los egos y los protagonismos quedaron en segundo plano. Aunque el mundo reconoce hoy que Colombia tiene figuras de primera línea, Pékerman no permitió que nadie pusiera en duda que el protagonista de esta historia fuera la Selección. Como lo dice él mismo en un video que se ha vuelto viral en redes sociales, “es fácil jugar al individualismo, pero hacer equipo es a otro precio”.

La aspiración es que la Selección sea cada día más fuerte, aunque las figuras pasen. Que no sea flor de un día. “La gran diferencia de este equipo con el del 94 –que le ganó 5-0 a Argentina y clasificó al Mundial de Estados Unidos, pero que salió en la primera ronda– es su consistencia”, afirma Duarte Ramos, managing director de la firma cazatalentos Hays. Aunque tenemos ‘genios’ del fútbol para mostrar, lo más importante es que se tiene un equipo sólido.

La historia de esta Selección deja lecciones muy importantes desde una perspectiva empresarial. El reto que asumió Pékerman no es muy diferente a los desafíos que día a día deben resolver los empresarios de este país. Como Pékerman, muchos de ellos tienen un material básico muy bueno y necesitan convertirlo en un producto capaz de triunfar en los más exigentes escenarios internacionales ¿Cómo lograr que el potencial se materialice en resultados extraordinarios? ¿Cómo hacer realidad la visión?

Pékerman, quien ha actuado como un auténtico CEO en este proyecto, podrá compartir sus buenas lecciones con las empresas de nuestro país. El análisis de la experiencia de la Selección permite entender las claves del éxito de su gestión. El resultado no se obtuvo de la noche a la mañana, salió de un trabajo cuidadoso y de largo plazo. Fue necesario invertir y tomar riesgos, sabiendo que los frutos solo se verían con el tiempo. El líder se dedicó a consolidar una visión y atender todo lo necesario para hacerla realidad, sin desgastarse en discusiones, ni especulaciones, ni altercados de poca monta.

Pékerman logró sacar lo mejor de su gente y demostró un don que caracteriza a los buenos presidentes de empresa: enseñó a través del ejemplo, –la única manera de enseñar–. 

Estas claves del éxito se pueden resumir en ocho puntos fundamentales.


1| No nos podemos  equivocar al escoger al líder

Hay muchas razones que llevan a las organizaciones a escoger malos líderes y a persistir en la equivocación. También hay muchas formas de equivocarse en este tema tan crítico.

En Colombia llevábamos años dando bandazos en la escogencia de un director técnico para la Selección. Por el puesto pasaron Jorge Luis Pinto, Eduardo Lara, Reinaldo Rueda, Hernán Darío Gómez y Leonel Álvarez. Unos muy exigentes, otros sin carácter y uno con escándalos. Cuando se presentó la vacante para reemplazar a Álvarez hubo varios entrenadores internacionales en la baraja, incluyendo al extécnico del Barcelona, Gerardo ‘El Tata’ Martino, quien estuvo listo para firmar contrato. Sin embargo, esa negociación fracasó.

Finalmente, José Néstor Pékerman, quien estuvo entre los nombres considerados inicialmente, apareció de nuevo y fue el elegido. “Contratar al profesor Pékerman es la mejor decisión que he tomado en mi vida”, explicó el presidente de la Federación de Fútbol, Luis Bedoya. Pékerman no solo es uno de los mejores técnicos del mundo hoy, sino que es una excelente persona.

Pékerman se concentró siempre en lo que tenía que hacer. Nunca tuvo frases destempladas, ni dio declaraciones explosivas, ni buscó fuera de la cancha resultados que solamente se podían dar en el terreno de juego. Anunció sus prioridades y las siguió, construyendo el camino paso a paso. Dio ejemplo de consistencia y trabajo sistemático. Nunca permitió que se pusiera en duda quién estaba a la cabeza de este proyecto.

2| El objetivo no es jugar, el objetivo es ganar

Muchos equipos salen a la cancha con la meta de jugar fútbol, pocos llegan a ganar un Mundial. Colombia jugó cada partido con la meta de ganarlo y Pékerman ajustó todo para ese objetivo. 

Nunca más en Colombia perder será ‘ganar un poco’. Si se prepara un proyecto como este y se invierten recursos sustanciales en su ejecución, el objetivo focal de todos los miembros del equipo debe ser ganar. Esa es quizás la mayor enseñanza que nos deja esta Selección. Todos los miembros del equipo deben estar enfocados en afinar las habilidades distintivas que permitirán alcanzar el objetivo. Todos deben aportar a construir un verdadero juego de equipo que permita entregar el resultado. La serenidad, la preparación, la creciente confianza mutua se desarrollan a la luz de una meta compartida, nítida en la mente de todos: ganar. 

Lo bueno de esto es que ganar genera costumbre y crea nuevos retos. Colombia no va a volver a un Mundial pensando que debería aspirar a nada menos que llegar a cuartos de final. Eso es lo que esperamos en Rusia 2018. Se han roto las barreras de pensamiento y ahora la discusión comienza allí: ¿Qué tenemos que hacer para no quedarnos en cuartos de final? ¿Cómo llegar a ser campeones? 

.3| El talento es la base de todo

El lado más fuerte de Pékerman es su capacidad para administrar el talento. Logra que cada jugador se convenza de que tiene un gran potencial por desarrollar y que el mejor entorno para lograrlo es el equipo. Todos saben que si la Selección, como un todo, no está en su mejor nivel, ninguno de ellos podrá brillar individualmente. Pékerman sabe cómo sacar lo mejor de cada uno de sus jugadores, no solo con entrenamiento físico, sino también con el trabajo mental (que es uno de los frentes donde esta Selección mostró sus mayores logros). La selección nunca estuvo dividida y todas las tensiones se manejaron en su momento. 

Al mismo tiempo, el talento necesita recursos. El presidente de la Federación Colombiana de Fútbol, Luis Bedoya, asegura que se les han ofrecido las mejores condiciones a los jugadores. Pékerman sabía lo que necesitaba y la Federación lo puso todo a su disposición. Especialistas para recuperación después de los partidos, infraestructura deportiva para los entrenamientos, comodidad durante los viajes, alojamiento, aditamentos deportivos. Estos no son lujos, sino condiciones necesarias para que una selección nacional de fútbol llegue a los más exigentes escenarios. A Pékerman le han dado todo lo que ha pedido. Bedoya asegura que la inversión más importante fue la sede de la Selección Colombia en Bogotá, donde se invirtieron más de $15.000 millones. Es prácticamente una sede cinco estrellas para las concentraciones de las selecciones. 

Finalmente, Pékerman demuestra que se puede ser un jefe exigente sin tratar mal a la gente. Cuando le pide a un jugador que dé más de sí mismo, su mensaje es contundente. Sin embargo, no hacen falta insultos ni pataletas. Su autoridad es contundente porque sabe de qué habla y sabe llegarles a sus jugadores, no ha permitido que se relaje la disciplina ni que florezcan los gestos individuales. Después de todo esto, le queda tiempo para tratar bien a la gente.

4| Se necesita fogueo internacional 

Buena parte de los logros se debe a que numerosos jugadores de la Selección han hecho sus armas en los grandes clubes del mundo. Si queremos ganar en el medio internacional, necesitamos jugadores que lo conozcan y se sientan cómodos allí. En este equipo había 16 jugadores que trabajan para ligas tan competitivas como las de Italia, España, Portugal, Inglaterra, Alemania y Holanda; cuatro juegan en Argentina y los otros tres en equipos colombianos. Cuando entraban a la cancha y veían a sus contrincantes, reconocían las mismas caras con las que se encuentran habitualmente en competiciones en Europa. Hay un “estado del arte” internacional en materia de fútbol y los jugadores colombianos lo conocen, no les inspira temor. 

Esta es una lección de oro para los empresarios colombianos: si queremos tener equipos competitivos internacionalmente, asegurémonos de tener personas que se muevan bien en ese medio. No debemos tener temor a contratar gente bien fogueada; al contrario, esa es la que se necesita para subirle el nivel a toda la empresa.

5| Perderle el miedo a la curva de aprendizaje

Buena parte de los resultados que vemos hoy se dieron porque la Federación se dio cuenta de que estaba metida en un problema de largo plazo, que necesitaba una solución de largo plazo. 

“Cuando fuimos eliminados del Mundial de 2010, comenzamos a hacer reuniones con todos los actores del fútbol. Empezamos a mirar cómo definir objetivos y planes estratégicos”, cuenta Bedoya. Hasta ese momento, la estrategia había estado enfocada en el corto plazo y en apagar incendios. Por ejemplo, no había sido diseñada una estrategia para definir la generación de relevo que reemplazaría a los jugadores que hicieron historia en los años noventa. Esto explica en buena parte los fracasos del fútbol colombiano en los últimos 16 años.

“Hay que perderle el miedo a la curva de aprendizaje”, dice Duarte Ramos, de Hays. Es necesario apostar a largo plazo y tener persistencia. 

Hacia adelante, hay que cuidar el proceso con Pékerman, que ya dio resultados. Es necesario movilizar una estrategia que siga estos mismos lineamientos para generar una generación de relevo que esté lista a reemplazar a James, Falcao, Yepes, Quintero, Cuadrado y los demás, cuando llegue el momento. En dos mundiales más, Colombia ya debe tener los jugadores que van a reemplazar a las figuras actuales. Si no lo logramos, las posibilidades de fracasar serán muy altas.

6| La plata manda

Con esta selección quedó claro que la calidad cuesta. La Federación entendió eso y gracias a la gestión comercial logró recaudar más de US$47 millones (entre dinero en efectivo y pagos en especie como uniformes y dotación). “Cuando llegué a la Federación hace 8 años, había dos patrocinadores y cada uno ponía US$4 millones”, recuerda Luis Bedoya. Hoy, el equipo cuenta con muchos más patrocinadores y el aporte promedio supera los US$4 millones.

Bavaria, Homecenter, Movistar, Pacific Rubiales, Procter & Gamble, Adidas, Caracol, Allianz, Efecty, Golty y Avianca le pusieron el alma a esta selección con grandes sumas de dinero (ver recuadro pág. 43).

Carolina Jaramillo, directora de Sports Marketing de IPG Media Brands, explica que las marcas que apostaron desde el principio hoy están recogiendo los resultados de su inversión. “Muchas de ellas se subieron a los patrocinios cuando ni siquiera Colombia estaba clasificada al Mundial. Una vez clasificados, no se sabía cómo nos iba a ir”. Para ella, es claro que invertir implica un riesgo, pero en este caso fue ampliamente recompensado, pues la exposición que obtuvieron estas marcas fue extraordinaria, a la luz de los resultados.

7| Información y análisis, las prioridades

El antídoto contra los amuletos y la superstición es un arsenal de datos e información. Pékerman cuenta con personas que le ayudan en su estrategia de tener toda la información posible sobre cada jugador y sobre el equipo que va a enfrentar. Esto es un insumo fundamental a la hora de definir estrategias en cada compromiso.
Cuando los hechos son desfavorables, Pékerman no se permite caer en fantasías. Él mismo le contó al periodista Rolando Hanglin en 2011, durante una emisión del programa Relaciones Humanas del canal C5N de la televisión argentina, por qué se había retirado del fútbol a los 28: sufrió una lesión y ante la imposibilidad de lograr nuevamente un rendimiento de 100% decidió retirarse. “Quiero tanto al fútbol que yo sé que no puedo jugar dando ventajas”, explicó. 

Aplicó ese mismo criterio cuando tuvo que tomar la decisión de no llevar a Falcao al Mundial. Lo que estaba en consideración no era si Falcao actúa como un imán de buenas energías para la selección, o si le trae buena suerte a Colombia. La cuestión era si Falcao podía aportar en esta oportunidad a las ventajas objetivas del equipo frente a los competidores. Siempre estuvo claro que un jugador lesionado no puede hacer el mejor aporte a la meta. En la medida en que no se recuperó a tiempo, la decisión estaba tomada.

8| Flexibilidad para enfrentar lo inesperado

Pékerman confía en su sistema, pero también sabe que no existen las panaceas. Llevar una fórmula exitosa a extremos conduce a cometer errores graves. En una entrevista para un medio argentino, Pékerman planteó sus reparos a la preparación física excesiva. “¿Por qué hay que preparar a los futbolistas desde tan chicos en asuntos físicos? Se vuelven duros y se pierde el feeling con la pelota”, señaló.

En el Mundial, tuvo que revisar varias veces su nómina y acomodarla a cada partido. La capacidad de reacción frente a las circunstancias inesperadas es una lección para cualquier organización.

***

Que siga Pékerman

Desde el presidente Santos en adelante, la gran mayoría de los colombianos quiere que Pékerman siga dirigiendo la Selección. Los resultados son más que satisfactorios. Quizás nadie había medido lo que podía significar para Colombia tener una selección de fútbol exitosa, después de tantos años de frustraciones y tantas experiencias dolorosas que ha vivido este país. 

Sin embargo, mantener a Pékerman y su modelo de hacer fútbol va a ser complejo. La negociación apenas comienza y el punto de partida es alto: el contrato con Pékerman fue de US$3 millones por cada año del actual proceso. 

En la Federación Colombiana de Fútbol quieren que siga, para profundizar la estrategia e incorporando objetivos en las selecciones juveniles y femeninas. Sin embargo, el esfuerzo financiero será sustancial. Los gastos no van solamente por cuenta de su salario, sino de la operación de soporte que él exige para tener una selección nacional del nivel que se desea. 

Al interior de la Federación deben estar haciendo cuentas sobre los costos de ese nuevo proceso que se inicia ahora e incluye la Copa América en Chile, en 2015, y luego el proceso de eliminatorias para el Mundial de Rusia 2018.

La negociación con los patrocinadores también va a ser clave. Muchos de los sponsors tienen contrato hasta diciembre de este año. Y de lo que la Federación renegocie para los próximos cuatro años saldrá el dinero para pagar el nuevo proceso.

Pékerman sabe que los colombianos lo queremos, pero también sabe que tiene todo en la mano para negociar. Si aspiramos a seguir el camino que él señaló, tendremos que estar dispuestos a pagar los costos.

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