Etiqueta: desarrollo

  • El Tamaño del Equipo Scrum

    El Tamaño del Equipo Scrum

    Mucho se ha hablado sobre el tamaño del equipo Scrum, Agile y casi cada cliente, jefe y colaborador con los que he trabajado hacen esta pregunta en algún momento ¿cuántas personas incluimos en los equipos?. La Guía Scrum ofrece muy poco luz al respecto, sugiriendo 10 o menos miembros por equipo en su última actualización, pero sin darnos contexto o razones para estos números.

    El Tamaño del Equipo Scrum no es Sólo un Número

    La verdad es que no existe un número universalmente correcto para asegurar un óptimo rendimiento en un equipo, pero sí sabemos que un equipo Scrum debe considerar ciertos factores que debería incluir, más allá de lo números:

    • Equipo multifuncional. Habilidades y capacidades suficientes para construir el producto,
    • Miembros dedicados al equipo. Miembros dedicados a uno, y sólo un, equipo,
    • Miembros estables. Membresía consistente y de largo plazo dentro del equipo[1],
    • Diversidad de pensamiento. Un suficientemente amplio rango de actitudes, creencias, generos y patrones de pensamiento[2].

    Ahora bien, los puntos anteriores ya por sí mismos representan reto para algunas organizaciones, pero al menos gozan de un consenso importante, sin embargo, no son las únicos. Una vez que el equipo está formado, hay otros factores importantes que deben atacar los equipos de alto rendimiento, entre otros se pueden mencionar:

    • Seguridad psicológica. Ambiente seguro para compartir ideas y tomar riesgos[3].
    • Comunicación igualitaria. El miembro más expresivo no debería comunicar más del doble de información que el más callado[4].
    • Mente abierta y disponibilidad para aprender[5].
    • Visión compartida. Todos conocen y acuerdan objetivos[6].
    • Roles claros. Todos conocen sus responsabilidades y las espectativas de su labor[7].
    • Asesoramiento externo (coaching). En Scrum esto lo lleva a cabo el Scrum Master[8].

    ¿Y todo esto que tiene que ver con el tamaño de los equipos? Bueno, estos factores no viven aislados en el vacío y sólo porque yo lo digo, así que exploremos la evidencia para que juntos descubramos que es lo más importante para su equipo. Después de todo, no hay una respuesta universal 🙂

    Muchos Números por Todos Lados

    Cuando hablamos del tamaño de los equipos a los adentros de varias organizaciones, el tema parece mucho más controversial y poco acotado por decir lo menos. En el peor de los casos, los líderez encargados de asignación de personal responden armando equipos guiados por supuestos e incluso en función del agobio causado por fechas y presupuestos poco realistas y de horizontes inadecuados, perjudicando así al rendimiento de equipos y la misma organización a mediano y largo plazo.

    En lo días tempranos del agilismo, los textos XP y Scrum sugerían que el tamaño óptimo de miembros era 7±2, aplicando el número de George A. Miller, posteriormente se ajustó a 6±3, hoy en dia el número sugeridos es 10 o menos de acuerdo con la Guía Scrum.

    El sustento original para la postura de siete personas, más o menos dos (7±2), proviene de una investigación de psicología muy nombrada del psicólogo investigador George A. Miller publicada en los años 50s, donde según los resultados de este estudio, hay límites en la cantidad de información que podemos procesar y retener en nuestras cabezas.

    Más recientemente en 2010, Nelson Cowan afirmó que Miller era demasiado ambicioso y que el límite ideal era solo de cuatro y no de de siete[9].

    También, Ikujiro Nonaka y Hirotaka Takeuchi estaban formulando el tamaño ideal del equipo después de realizar investigaciones y crear nuevos productos en compañías de tecnología como Fuji-Xerox, Canon, Honda, Epson, Brother, 3M y Hewlett-Packard[10] .

    Muchos otros citan ejemplos históricos que se remontan al ejército romano, que utilizaba pequeñas unidades militares de alrededor de 8 personas. Otros observan a los bonobos, uno de los parientes genéticos más cercanos a los humanos, a menudo divididos en grupos de 6 a 7 para buscar alimento durante un día. Ambos admiten convenientemente el número 7±2, pero dado que ninguno de los ejemplos se trata de equipos que realizan trabajo de conocimiento, la relevancia de esto para el agilismo es limitada.

    Como puede ver el tema ya tiene tiempo discutiéndose y puede ser algo confuso, pero gracias a ello tenemos algunas pistas, pero vale la pena tener más fuentes que nos ayuden a sustentar nuestra desición.

    ¿Qué Pasa a las Relaciones Cuando los Equipos Crecen?

    A los adentros de un equipo, cada individuo tendrá conexión con otro individuo creando con ello un relación única; entre más grande el equipo, más relaciones. La ecuación que describe esto es N(N-1)/2; pero ¿qué significa esto? y ¿cómo puede ayudarnos? para averiguarlo recordemos problemas de matémáticas de escuela y convirtámoslo en algo que podamos usar en la vida real.

    La ecuación anterior nos dice cuántas relaciones diferentes existirán dentro de un equipo de cierto tamaño, siendo N = el número de personas en el equipo. Entonces, en el primer gráfico ejemplo de un equipo de 5 personas, donde N=5 tenemos 10 relaciones: 10 combinaciones diferentes de miembros del equipo que se relacionan con otros miembros del mismo equipo.

    En el segundo ejemplo, donde N=7, tiene 21 relaciones y en donde N=9 en el tercer gráfico tienen 36 relaciones. Cada par de personas representa una relación, y esa relación define la forma en que colaboran. Los equipos de alto rendimiento, por su naturaleza, deben tener relaciones sólidas entre cada uno de los miembros del equipo para colaborar de manera efectiva.

    Saber esto es importantes para usted y su equipo, porque es cierto que cada nueva persona agrega algo de productividad individual al equipo, pero también aumenta los gastos generales de comunicación en forma de un número de relaciones que crece exponencialmente. Para aumentar un equipo de 5 a 7 personas, hay que duplicar con creces el número de relaciones. Para pasar de 7 a 9, no se duplica del todo, pero el salto sigue siendo grande.

    ¿Qué tan costoso es mantener estas relaciones? Como anécdota, después de haber estudiado las interacciones de los miembros de varios de mis equipos, puedo decir que en equipos de 7 u 8 personas, cada día se dedican más de 90 minutos por persona a interactuar con otros miembros del equipo[11]. Esto excluye el tiempo dedicado a técnicas como pair programming. Parte de la interacción es hablar sobre el trabajo, pero también se dedica a socializar. Esto es bueno e importante porque es la combinación de trabajo y socialización lo que desarrolla la resiliencia y la capacidad de un equipo para manejar los desafíos de manera efectiva.

    Una regla general sugiere que las personas suelen tener de 3½ a 5 horas de tiempo productivo en el trabajo cada día. A medida que un equipo crece, perdemos productividad o, más a menudo, comenzamos a retraernos socialmente en lugar de sacrificar tiempo productivo para interactuar con nuestros compañeros porque los costos de comunicación para cada miembro del equipo se están volviendo demasiado altos. Necesitamos relaciones sólidas para convertirnos en un equipo de alto rendimiento pero, a medida que crece el tamaño del grupo, comenzamos a evitar las interacciones que construyen esas relaciones.

    Por lo tanto, la cantidad de relaciones entre los miembros del equipo y la inversión de tiempo que requieren deben ser un factor considerado al elegir el tamaño del equipo porque influirá en la productividad.

    Más Personas Hacen el Trabajo Más Ligero… Pero Solo Hasta Cierto Punto

    Lo que todos quieren creer es que si vamos de 1 persona a 2 personas, o de 2 personas a 4 personas, obtendremos el doble de trabajo realizado, incluso altos directivos de organizaciones transnacionales me lo han planteado. Pero incluso así, intuitivamente sabemos que esto no es verdad, pero ¿por qué?

    En 1967 se presentó por primera vez la Ley de Amdahl, que para los que no sean ingenieros en sistemas o electrónica, trata de estimar cuanta ganancia de velocidad se puede obtener ejecutando tareas de computo corriédolas en partes de manera paralela. Esto significa que a veces hay programas de cómputo que son viables de trabajarse por múltiples procesadores al mismo tiempo (ej. procesamiento paralelo), pero otras partes deben ser atendidas una por una (ej. programación serial).

    La fórmula que se deriva de la Ley de Amdahl pude parecer intimidante, pero es mucho más simple de lo que parece:

    Esta imagen plantea trabajo realizado por un procesador el cual le toma 5 unidades de tiempo para completar.

    Si tomamos las 5 unidades de trabajo y aplicamos 3 procesadores a las partes que se pueden hacer concurrentemente (en paralelo), no se necesitan 1 y 2/3 unidades de tiempo (5 dividido por 3) para completarse. En cambio, se necesitan 3 unidades porque 2 de las unidades de trabajo solo pueden ser realizadas por un procesador (serie). Ciertamente es una mejora en el tiempo, pero no tanto como cabría esperar al primer vistazo.

    El trabajo en equipos funciona de manera muy similar. De hecho, si con convertimos todo a un gráfico podemos darnos idea de que tan eficiente puede ser el incremento en miembros de un equipo:

    Enfoquémonos por ahora en la línea del 80% (la azul, en la parte superior) del gráfico. Seamos optimistas (y poco realistas) y supongamos que el 80% del trabajo se puede hacer trabajando en paralelo. Esto sugiere que cuanta más gente lo haga, más rápido se terminará, ¿cierto? Ah, pero espera. Si pasamos de 1 persona a 2 personas, no hacemos el doble de trabajo. Para obtener una mejora de 2 veces el trabajo completado, en realidad necesitamos 3 personas. 7 personas sólo crean una mejora de 3.2 veces sobre 1 persona. Para hacer 4 veces más trabajo del que hace 1 persona, ¡necesitaríamos 16 personas!

    ¿Qué sucede si se puede hacer incluso menos trabajo al mismo tiempo (paralelo)? ¿Qué pasa si el 50% del trabajo debe hacerse en serie (línea verde en el gráfico)? Luego, con 9 personas, todavía tenemos solo una aceleración de 1.8 veces.

    ¿Cual es la solución? No hay una solución fácil, pero hay cosas que puede hacer para mitigar el efecto de la Ley de Amdahl:

    • Haga que la mayor parte del trabajo posible se pueda hacer en paralelo. Esto puede significar aumentar las habilidades cruzadas y la colaboración.
    • Reduzca las dependencias entre equipos, para que no haya cuellos de botella ni retrasos.
    • Aumente la velocidad del proceso de trabajo en general mejorando la calidad y las prácticas.

    La velocidad no proviene de enviar a más personas al trabajo y formar equipos más grandes. Se trata de construir un equipo de alto rendimiento que tenga un tamaño óptimo para la eficacia, la comunicación y la calidad.

    Evidencia respaldada por investigaciones

    American Sociological Association

    La American Sociological Association publicó un estudio de Hackman JR, Vidmar NJ llamado “Effects of size and task type on group performance and member reactions.” algó así como “Efectos del tamaño y el tipo de tarea en el desempeño del grupo y las reacciones de sus miembros[12].

    En este estudio, hicieron que los participantes completaran una serie de tareas: una combinación de producción (escritura), discusión y resolución de problemas. Los participantes se colocaron en diferentes grupos de 2 a 7. Después de completar cada tarea, se les hizo una serie de preguntas a los voluntarios, incluidas dos que se muestran en este gráfico: “¿su grupo era demasiado pequeño?”, “¿su grupo era demasiado grande?”. Como puede ver en el gráfico, los grupos de alrededor de 4-5 de tamaño parecían tener la reacción menos negativa. El número frecuentemente tocado es 4.6. Los participantes eran estudiantes universitarios, las tareas tenían una carga cognitiva pero no estaban relacionadas con tennología, desarrollo, etc., y los grupos no estuvieron juntos el tiempo suficiente para que se formara un verdadero “sentido de equipo”. No obstante, es un dato interesante.

    Por aquellos días Hackman escribió el libro Leading Teams, su regla general para el tamaño del equipo era 6[13].

    Social and Developmental Psychology Researcher Jennifer S. Mueller

    La Psicóloga-Invetigadora Jennifer S. Mueller académica, autora y colaboradora de varias investigaciones fue citada en el artículo “Is Your Team Too Big? Too Small? What’s the Right Number?:”

    Si las empresas están lidiando con tareas de coordinación y problemas de motivación, y usted pregunta: “¿Cuál es el tamaño de su equipo y cuál es el óptimo?”, eso corresponde a un equipo de seis. “Más allá de los cinco, comienzas a ver una disminución de la motivación”, dice Mueller. “Después de la quinta persona, buscas camarillas. ¿Y el número de personas que hablan en un momento dado? Eso es más difícil de manejar en un grupo de cinco o más”.

    De Los creadores de Scrum…ni más ni menos

    A partir de los estudios de George A. Miller, y trabajos posteriores, lo creadores de Scrum Jeff Sutherland y Ken Schwaber mostraron los siguientes niveles de productividad basados ​​en su propia investigación sobre el tamaño del equipo:

    Equipo AgileProductividadEquipo NO AgileProductividad
    < 7 miembros300 / 400 %< 7 miembros100% max
    > 7 miembros400 %> 7 miembros< 90%

    Y agregaron:

    Un pequeño equipo de tres a cuatro personas puede ser muy autónomo cuando sigue pautas, tiene un enfoque bien definido, y todos están físicamente en el mismo espacio. Su trabajo es a menudo consistente, responsable, alineado y bien dirigido, y la comunicación es fluida. Las cosas son relativamente fáciles cuando solo hay unas pocas personas en el equipo. Los problemas parecen aumentar junto con el número de miembros del equipo.

    Ley de Brooks y Lawrence Putnam

    El mítico Frederick Brooks al cual se le debe la famosa “La Ley de Brooks” establece que “agregar mano de obra a un proyecto de software tardío lo hace incluso más tardío”. Esto es debido a la curva de aprendezaje, es decir, debe capacitar a cada persona nueva en el producto o tecnología, y debe aprender todo el conocimiento no técnico relacionado, incluidas las estrategias comerciales que aborda el producto o el software [14].

    Según importantes estudios realizados por investigadores de renombre como Lawrence Putnam:

    MiembrosEsfuerzo
    < 9 miembros25% menos esfuerzo
    > 9 miembros25% más esfuerzo

    Con un Equipo Agile:

    MiembrosProductividad
    125% más
    5125% más
    9225% más

    En resumen, si tenemos un equipo óptimo, podemos llegar a tener una productividad del 300 al 400%.

    Datos duros de Putman y Mayers

    Más allá de nuestras opiniones personales, las de los clientes, jefes, miembros del equipo, también tenemos estadísticas objetivas. Putnam y Myers examinaron datos de 491 proyectos de software en una gran corporación como publicaron en su aritículo “Familiar Metric Management: Small is Beautiful Once Again“. Estos fueron proyectos con 35,000 – 90,000 líneas fuente de código. Dividieron los proyectos en grupos que llamaron buckets según la cantidad de personas involucradas en el proyecto: 1.5-3, 3-5, 5-7, 9-11 y 15-20. En promedio, los grupos más pequeños (3-5, 5-7) tardaron mucho menos tiempo (11.9 y 11.6 meses, respectivamente) que los grupos más grandes (17.1 y 16.29 meses) para completar proyectos de tamaño similar.

    Cuando multiplicas el número de miembros del equipo por el número de meses, obtienes un gráfico que es aún más impactante:

    Un equipo de 9 a 11 personas tardó entre 2.5 y 3.5 veces más tiempo que los equipos de 5 a 7 y de 3 a 5 para completar proyectos de un tamaño similar. Eso sugiere que los equipos de más de siete en este conjunto de datos eran solo una forma de gastar dinero más rápido debido al aumento del tamaño del equipo pero con rendimiento neto reducido.

    Evidencia de proyectos Agile

    Larry Maccherone, en su trabajo a través de Rally, Tasktop y AgileCraft expuestos en “Impact of Agile Quantified” a finales del 2014″, ha ayudado a construir grandes conjuntos de datos sobre prácticas en equipos Agile . Sus datos muestran:

    Según los datos de Larry, parecería que los equipos de 1-3 son más productivos pero tienen menor calidad. Los equipos de 3-5 son marginalmente más productivos que los de 5-9, aunque aún pueden tener una calidad ligeramente inferior: la diferencia es pequeña. Las notas de Larry sugieren que piensa que todo el rango de 3 a 9 está bien[16]. La razón de la menor calidad en los equipos más pequeños no es evidente. ¿Quizás por falta de estabilidad? ¿Falta de diversidad de pensamiento y experiencia? ¿Funcionalidad cruzada reducida? No podemos saberlo, pero merece consideración.

    Mi Experiencia

    Cuando los clientes, jefes, etc., me preguntan qué tamaño deberían tener los equipos Scrum, no tengo una respuesta “correcta”. Pero trato de compartir los datos anteriores, mis opiniones personales y sugerencias basadas en años de experiencia. Y no les mentiré, hay organizaciones donde los malos hábitos está tan arraigados que cuesta trabajo permear de manera práctica esa información (no la escuchan, lo toman suficientemente en cuenta, etc.). Pero sin lugar a dudas procuro que mis sugerencia se basen en la evidencia, en la lógica simple y el sentido común.

    Por ejemplo, los equipos más grandes pasan más tiempo formándose, más tiempo normalizándose y, por lo tanto, más tiempo para alcanzar un alto rendimiento. ¿Por qué? Porque hay más relaciones que negociar. Como vimos antes, en un equipo de 5, hay 10 relaciones que deben formarse, un equipo de 7 tiene 21 relaciones, y así sucesivamente. Más relaciones toman más tiempo para construir y establecer la confianza, por lo que debe tenerse en cuenta a la hora de decidir el tamaño del equipo.

    Suponiendo que todo lo demás sea igual (las habilidades necesarias para realizar el trabajo, la diversidad de pensamiento, etc.), la evidencia existente respalda la idea de que los equipos de 4 a 6 funcionan bien en la mayoría de las situaciones. Toman menos tiempo para formarse y son tan productivos como los equipos más grandes. Además, los equipos de 5-7 normalmente pueden combinar habilidades lo suficiente como para cubrir la pérdida de un miembro del equipo.

    Personalmente, solo elegiría un equipo de 8 si otras presiones, como la amplitud de habilidades requerida, lo obligaran a suceder. No recomiendo equipos de más miembros, porque los gastos generales superan el valor de la persona adicional.

    Con equipos de 10 o más, recomiendo dividirse en 2 equipos. Mi propia experiencia y la de otros colegas agilistas con experiencia en escalamiento: los equipos separados de 4 y 5 hacen más que su numeroso equipo original.

    Con equipos de 9 o más, recomiendo dividirse en 2 equipos. Mi propia experiencia refleja la de otros agilistas utilizando Scrum: los equipos separados de 4 y 5 hacen más que su gran equipo original.

    ¿Por qué no 3 o menos? Porque daría como resultado muy poca diversidad de pensamiento y probablemente sería muy difícil encontrar 3 personas con suficientes habilidades para hacer el trabajo en un proyecto complejo. También habrá muy poca colaboración, lo que se correlaciona con la reducción en la calidad que muestra la Figura n.º 2 (datos de “Impact of Agile Quantified”). Y no olvide los problemas obvios de energía 2 contra 1 que pueden hacer que el viaje sea más desafiante para un miembro del equipo.

    Todo el enfoque se ha centrado en la cantidad de personas en el equipo, pero la pregunta más importante debería ser esta: ¿tiene el equipo la capacidad de llegar a “Done” o “Terminado” al final de cada Sprint? Si no es así, querrá volver a examinar y reconfigurar para lograr un tamaño de equipo más efectivo y hacer muy probablemente un re-análisis al desglose de trabajo en requerimientos, historias de usario o similares.


    [1] “The Impact of Lean and Agile Quantified” – Larry Maccherone demostró que miembros dedicados a un sólo equipo duplicaron la productividad y los equipos estables (sin rotación) mejoraron la productividad en un 60%. https://www.infoq.com/presentations/agile-quantify

    [2] Wilkinson, David. Group decision-making. Lo que dice la última investigación. The Oxford Review, Diciembre 2019

    [3] “What Google Learned From Its Quest to Build the Perfect Team”: https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

    [4] “The New Science of Building Great Teams” – Alex “Sandy” Pentland https://hbr.org/2012/04/the-new-science-of-building-great-teams/ar/pr y también “Evidence for a Collective Intelligence Factor in the Performance of Human Groups

    [5] The Wisdom of Teams: Creating the High-Performance Organization – Jon Katzenbach and Douglas Smith – indica que las habilidades potenciales son tan importantes como las habilidades que la gente tiene actualmente para predecir efectividad.

    [6] [7] [8] Wilkinson, David. Group decision-making. Lo que dice la última investigación, The Oxford Review, Diciembre 2019

    [9] “The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?” – Nelson Cowan – https://www.psychologicalscience.org/journals/cd/19_1_inpress/Cowan_final.pdf?q=the-recall-of-information-from-working-memory

    [10] Knowledge management https://en.wikipedia.org/wiki/Knowledge_management

    [11] Estas son observaciones informales que cualquiera puede hacer, pero una de las investigaciones más conocidas la hizo la revista inglesa Nature Human Behavior en 2017.

    [12] Stable reference: https://www.jstor.org/stable/2786271

    [13] Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam y Ware Myers https://hbswk.hbs.edu/archive/2996.html

    [14] The Mythical Man-Month: Essays on Software Engineering – Frederick Brooks https://en.wikipedia.org/wiki/The_Mythical_Man-Month

    Enlaces de interés:

    El Enfoque Agile De La Planeacion
    Planeación, Cono de Incertidumbre y Estimaciones en IT
    ¿Qué Certificación Elegir como Scrum Master

    Estos son alguno libros recomendables para saber más:

    2 Comments
  • Eligiendo Una Estrategia

    Eligiendo Una Estrategia

    Probablemente usted o su organización ya tienen muy claro la Meta y los Objetivos que desea para su proyecto, si es así déjeme felicitarlo porque no siempre es fácil, si por el contrario aún no ha dedicado tiempo a esa tarea o sigue luchando para definir sus metas y objetivos quizá quiere echar un vistazo a nuestro video anterior Definiendo Metas y Objetivos.

    Ahora bien, suponiendo que sus metas y objetivos están establecidos, es probable que usted tenga algunas ideas para poder cumplirlos, aquí es donde la participación de los miembros del equipo con el cual usted trabaja se vuelve importante, ya que las perspectivas de diferentes integrantes llega a la creación, fusión o discriminacón de ideas. Todas esta interacción que puede ser impulsado por prácticas de design thinking provoca una lluvia de ideas que se convertirán eventualmente en estrategias de ejecución.

    Cuando obtenga muchas ideas y/o estrategias el siguiente paso consistirá en evaluar cuales respaldan de mejor manera a sus objetivos, en el video de este post, llamado Eligiendo Una Estrategia, puede obtner una referancia rápida de como evaluar el grado de cumplimiento de sus ideas y estrategias a los objetivos que persigue:

    • Lluvia de ideas
    • Matriz de evaluación
    • ¿La estrategia satisface los objetivos?
    • ¿La estrategia es factible?
    • ¿Los riesgos de la estrategia son aceptables?
    • ¿La estrategia es compatible con la cultura de la organización?

    Recuerde que este video es parte del segundo capítulos del curso en videos de Introducción a la Administración de Proyectos, si desea puede ver los videos anteriores para comprender mejor el tema tratado.

    Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.

    YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden.

    También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica (sólo los videos que lo ameriten).

    Video Eligiendo Una Estrategia:

     

    Algunas publicaciones recomendables para saber más:

    No Comment
  • Definiendo Metas Y Objetivos (Video Curso)

    Puede pensar que la principal responsabilidad de alguien a cargo de un proyecto es entregarlo a tiempo y dentro del presupuesto, de hecho, es una manera muy común de pensar de organizacione, pero estan equivocados. Como parte de un cuerpo estratégico de alto nivel o como un independiente, los responsables de la administración de proyectos, en primer lugar, ayudan a impulsar, guiar y ejecutar acciones para lograr los objetivos de valor agregado identificados de cualquier organización.

    Cuando las organizaciones maduran eventualmente crean cosas como las oficinas de gestión de proyectos (PMO) y las buenas prácticas de gestión de proyectos tienen más probabilidades de ser bien recibidas por los ejecutivos y partes interesadas de la organización como elementos tácticos indispensables una vez que reconocen su verdadero valor estratégico.

    Muchas organizaciones hoy ya saben que contratado y capacitado a los pensadores estratégicos, aumenta la probabilidad de ejecutar proyectos de alto impacto. Este alto impacto, entre otras cosas, se logra identificando metas y objetivos de largo, mediano y corto plazo con el que los posteriores esfuerzos se deben alinear. Cada involucrado en un proyecto debe poder tener una comprensión clara de la línea directa desde las tareas de un proyecto hasta la visión estratégica de alto nivel.

    En el video de este post, llamado Definiendo Metas Y Objetivos, puede aprender las bases para poder crear metas y objetivos apropiados para sus proyectos. En este video se hablamos de :

    • Definición de una meta
    • Definición de objetivo
    • Tipos de objetivos
    • Elementos a tomar en cuenta para crear y redactar objetivos

    Recuerde que este video es parte del segundo capítulos del curso en videos de Introducción a la Administración de Proyectos, si desea puede ver los videos anteriores para comprender mejor el tema tratado.

    Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.

    YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden.

    También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica (sólo los videos que lo ameriten).

    Video Definiendo Metas Y Objetivos:

    Algunas publicaciones recomendables para saber más:

    No Comment
  • Historias de Usuario Dilbert

    El tamaño importa, Historias de Usuario (User Stories)

    ¿El tamaño importa?

    Esta es una pregunta muy vieja, pero en este blog solo contestaremos a esa interrogante desde el punto de vista de la administración de proyectos (descepcionad@s dirigirse a blogs de otro tipo). En esta ocasión veremos que son y cuál es el propósito de las famosas historias de usario o user stories y en que se diferencían con los requerimientos tradicionales en un proyecto.

    Cuando era niño pasé mucho tiempo jugando en la playa con mis primas y primos, y en algunos de esos juegos, me encontré escarbando, transportando y apilando arena de un punto a otro (mis herramientas eran una pala y una cubeta de plástico) después de unos 10 minutos mi primo más pequeño me preguntó cuanto me había tardado en juntar toda esa arena, a lo cual contesté: “como unas 30 vueltas”. Después de eso tanto mi primo y como yo supusimos que con su propia cubeta podría duplicar la cantidad de arena en otras 30 vueltas. No fue así, mi primo pequeño todavía, se tardó bastante más debido a ambos fallamos en evaluar la capacidad de su cubeta y en apreciar que Gabriel (mi primo) al ser muy pequeñito (quizá 6 años) aún tenía que esforzarse para cargar una cubeta de diferente tamaño completamente llena y terminar en sólo 30 vueltas.

    Por simple y obvia que parezca esta anécdota, la realidad sorprende, ya que muchos equipos de trabajo encargados de proyectos de todos tamaños siguen cayendo en este mismo error. Aún no están completamente al tanto de su capacidad o su velocidad, tampoco tienen claro la diferencia entre tamaño y distancia en un proyecto, y por lo tanto, fallan desde el principio en sus estimaciones.

    No ocuparse de tratar de medir el tamaño de lo que se va a hacer es un error, por lo tanto el tamaño, SÍ importa, y antes de medir tiempos y distancias usted debe saber la respuesta a preguntas como ¿cuál es el tamaño de su cubeta y su pala? ¿cuántas cubetas y palas tiene? ¿existe la cantidad de personas suficiente para cada pala y cubeta?

    ¿Que son las historias de usuario?

    Por facilidad muchas veces se sobre simplifica, diciendo que las historias de usuario o user stories son los requerimientos de un sistema o un producto, pero tienen serias diferencias con otras aproximaciones comunes como son los casos de uso, especificaciones de requisitos de software IEEE 830 y escenarios de diseño e interacción.

    Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva funcionalidad, generalmente un usuario o cliente del producto que se desea crear. Por lo general, siguen una plantilla simple:

    Como <tipo de usuario>, quiero <algún objetivo> para que <algún motivo>.

    Las historias de usuario a menudo se escriben en fichas o notas adhesivas, se almacenan en una caja y se organizan en paredes, pizarrones o mesas para facilitar la planificación y el debate. Como tales, cambian fuertemente el enfoque de escribir sobre las características, a discutirlas. De hecho, estas discusiones son más importantes que cualquier texto que se escriba.

    Esta es una definición simple de que es una historia de usuario, pero créame, hay mucho más detrás, redactar buenas historias de usuario puede ser un reto, y para lograr hacer buenas historias hay que entender más acerca de su propósito.

    Asigna Valor (puntos) a las historias de usuario

    Eventualmente, cuando me involucré en la gestión de proyectos y más tarde Agile, descubrí que una manera de estimar el tamaño de lo que se necesita es utilizar las historias de usuario. Para explicar lo que son seguiré echando mano de las analogías.

    ¿Cuándo fue la última vez que fue a un restaurante y pidió una sopa o una bebida en mililitros?…..así es, normalmente no hacemos eso, solemos pedir una sopa o una bebida con una medida relativa como “chica, mediana o grande”. Las historias de usuario son relativas también, se usan para expresar tamaño, no cuentan con un valor estandarizado, pero los valores deben ser relativos uno de otro, es decir, una historia de usuario que tenga valor 2 es del doble de tamaña de una que vale 1.

    Para asignar valores o puntos a diferentes tamaños hay quienes usan tallas de camisa, razas de perros, valores Fibonacci (mis valores favoritos) u otras representaciones, no importa que prefiera, eventualmente debe usar valores relativos. Tome como ejemplo la siguiente tabla, con una posible asignación de puntos:

    Tamaño Camisa Puntos
    XS 1
    S 2
    M 3
    L 5
    XL 8
    XLL 12

    En un proyecto Agile no es raro comenzar una iteración con requisitos que NO son completamente especificados, los detalles se descubrirán más tarde durante la iteración. Sin embargo, debemos asociar un estimado con cada historia que podamos visualizar en el momento, incluso a aquellas que no están completamente definidas.

    ¿Y en dónde están los detalles?

    Aquellos acostumbrado a el detalle que se agrega de antemano a los requerimientos tradicionales, de inmediato les surgirá esta pregunta. El detalle se puede agregar a las historias de usuario de dos maneras:

    • Dividiendo una historia de usuario en múltiples historias de usuarios y más pequeñas.
    • Agregando “condiciones de satisfacción”.

    Cuando una historia relativamente grande se divide en historias de usuarios ágiles y múltiples, es natural suponer que se han agregado detalles. Después de todo, se ha escrito más.

    Las condiciones de satisfacción son simplemente pruebas de aceptación de alto nivel que deberán cumplirse después de que se complete la historia del usuario. Considere lo siguiente como otro ejemplo de historia de usuario ágil:

    Como director de marketing, quiero seleccionar un periodo de tiempo para que yo pueda revisar el rendimiento pasado de campañas publicitarias en ese periodo.

    El detalle podría agregarse a este ejemplo de historia de usuario al agregar las siguientes condiciones de satisfacción:

    • Asegúrese de que funcione con los datos de los principales minoristas: Oxxo, Seven Eleven, Extra.
    • Debe soportar los datos de los últimos tres años.
    • Los periodos se eligen en intervalos de meses (no días, ni semanas).

    ¿Quién escribe historias de usuarios?

    Cualquiera puede escribir historias de usuario. Sin embargo, es responsabilidad del propietario del producto o product owner asegurarse de que exista un retraso acumulado de productos de historias de usuario ágiles, pero eso no significa necesariamente que el propietario del producto es quien los escribe. En el transcurso de un buen proyecto Agile, debe contar con ejemplos de historia de usuario escritos por cada miembro del equipo.

    Además, tenga en cuenta que quién escribe una historia de usuario es mucho menos importante que quién está involucrado en las discusiones de la misma.

    ¿Cuándo se escriben las historias de los usuarios?

    Las historias de usuario se escriben a lo largo de un proyecto ágil. Por lo general, se lleva a cabo un taller de redacción de historias cerca del inicio del proyecto ágil, de cada relese y/o al inicio de cada iteración (personalmente tomo algunas de las primeras opciones, según la longitud del proyecto, y solo hago grooming en cada iteración). Todos en el equipo participan con el objetivo de crear una “lista de pedidos” o Product Backlog que describa por completo la funcionalidad que se agregará durante el transcurso del proyecto o en un ciclo de lanzamiento o release de tres a seis meses.

    Algunas de estas historias de usuarios ágiles serán, sin duda, épicas o epics (no se llaman épicas por que se dramáticas 😄). Las épicas son historias muy grandes que por su tamaño se descompondrán más tarde en historias más pequeñas que quepan más fácilmente en una sola iteración. Además, las historias nuevas se pueden escribir y agregar a la “lista de pedidos” del producto en cualquier momento y por cualquier persona.

    Velocidad (Velocity)

    No profundizaré tanto en este tema porque da para escribir otra entrada dedicada por completo a ello, pero para comprender cómo puede funcionar la estimación con puntos de historia que asignamos en la tabla que mostramos anteriormente, es necesario introducir un nuevo concepto: Velocidad o Velocity. La velocidad es una medida de la tasa de progreso de un equipo. Se calcula sumando la cantidad de puntos de historia asignados a cada historia de usuario que el equipo completó durante la iteración.

    Si el equipo completa tres historias, cada una estimada en cinco puntos de historia, su velocidad es de quince. Si el equipo completa dos historias de cinco puntos, su velocidad es diez.

    Si un equipo completó diez puntos de trabajo la última iteración, nuestro mejor cálculo es que completarán diez puntos esta iteración. Debido a que los puntos de la historia son estimaciones del tamaño relativo, esto será cierto ya sea que trabajen en dos historias de cinco puntos o cinco historias de dos puntos.

    Cómo puede ver esto es muy importante para hacer una estimacion y despúes de conocer el tamaño, para después proceder a calcular una estimación para el final del proyecto o de un release (la distancia).

    ¿Las historias de usuario reemplazan un documento de requisitos?

    Los proyectos ágiles, especialmente los de Scrum, usan un product backlog, que es una lista priorizada de las funcionalidades que se desarrollarán en un producto o servicio. Aunque los product backlog items pueden ser lo que el equipo desee, las historias de usuario han surgido como la mejor y más popular forma de product backlog items.

    Si bien un product backlog, puede considerarse como un reemplazo de el documento de requisitos de un proyecto tradicional e incluso quizá de un WBS, es importante recordar que la parte escrita de una historia de usuario ágil (“Como usuario, quiero …”) está incompleta hasta que las discusiones sobre esa historia tienen lugar.

    A menudo es mejor pensar en la parte escrita como un indicador del requisito real. Las historias de usuario pueden apuntar a un diagrama que representa un flujo de trabajo, una hoja de cálculo que muestra cómo realizar un cálculo o cualquier otro artefacto que el propietario del producto o equipo deseen.

    Hasta aquí dejo las user stories, déjeme saber si quiere saber más 😉.

    Enlaces de interés:

    El Enfoque Agile De La Planeacion
    Planeación, Cono de Incertidumbre y Estimaciones en IT
    Introduction to User Stories

    Estos son alguno libros recomendables para saber más:

    No Comment
  • Enunciado de Problema en el Inicio de un Proyecto (Video Curso)

    ¿Cuántos proyectos que se alejan de su objetivo? ¿cuántos malos entendidos sobre lo debe hacer su sistema ha tenido? ¿cómo comenzar a priorizar sus tareas? Saber definir el problema que estamos resolviendo con suficiente claridad desde el principio puede ser un factor muy importante.

    Continuando con el curso en videos de Introducción a la Administración de Proyectos, Internet80.com y @ManuGekko han comenzado con el segundo capítulo de este curso, el cual estará dedicado el grupo de procesos de Inicio en un proyecto. Es aquí donde comenzaremos a aprender cómo establecer la visión inicial de proyecto y a obtener buy-in de los involucrados en el mismo.

    Este segundo capítulo comienza con un video de introducción en dónde hablamos del Inicio de un Proyecto como proceso esto abarca de manera introductoria los conceptos de:

    • Grupo de procesos de inicio
    • Acta de constitución del proyecto

    Enseguida tenemos el siguiente video donde se aborda el tema de la definición del Enunciado de Problema, por qué es importante y como crearlo, para ellos se cubren los temas:

    • Concepto de enunciado de problema
    • Diferencia con una solución
    • La importancia de preguntar por qué

    Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.

    Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica (sólo los videos que lo ameriten).

    Video Iniciando un Proyecto:

    Iniciando Un Proyecto

    Enunciado De Problema:

    Enunciado De Problema

    Algunas publicaciones recomendables para saber más:

    No Comment
  • Opciones Software Para La Administración de Proyectos

    Opciones Software Para La Administración de Proyectos (Video Curso)

    Finalmente este es el último video del primer capítulo Explorando La Administracion De Proyectos que forma parte del curso gratuito en video de Introducción a la Administración de Proyectos, así que ahora tocó el turno de hablar de algunas de las opciones que están diponibles en el mercado de software que le pueden ayudar en su labor como responsable de un proyecto.

    Siguiendo la tradición del curso, los videos abordan el tema de manera breve, pero buscando siempre ponerlo a usted en la pista correcta para averigüe más y llegue a sus propias conclusiones. En este video se aborda las características esenciales de:

    • Software especializado en gestión de proyectos
    • Procesadores documentos
    • Hojas de cálculo
    • Software para presentaciones
    • Consideraciones generales

    Todos los videos previos están disponibles en YouTube o si prefiere, en los siguientes enlaces:

    1. Definición de Proyecto
    2. Definición de Gestión de Proyectos
    3. Lo Necesario Para Ser Un Administrador de Proyectos
    4. Los Cinco Procesos De La Administración de Proyectos
    5. Cascada VS Agile

    Estos videos forman parte del primer capítulo del curso Explorando La Administracion De Proyectos. La estructura del curso puede verla aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.

    Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica (sólo los videos que lo ameriten).

    Con usted el último video de este capítulo Opciones Software Para La Administración de Proyectos:

    Algunas publicaciones recomendables para saber más:

    No Comment
  • Cascada VS Agile

    Cascada VS Agile (Video Curso)

     

    Este es un video que no pensé incluir cuando estaba diseñando el curso gratuito en video de Introducción a la Administración de Proyectos, pero recordé que hay muchas personas que aun siguen discutiendo y enfrentado los modelos ágiles y los modelos tradicionales de gestión de proyectos, cual si fueran personajes de Street Fighter. Me imagino las pantallas arcade de mi infancia mostrando Cascada Vs Agile, RUP VS Scrum, PSP VS XP, cuando en realidad se trata comprender el contexto de su proyecto para aplicar el enfoque más adecuado.

    Finalmente he creado para usted el quinto video de este curso en donde se explica en que situaciones en las cuales debería de aplicar estas aproximaciones de administración de proyectos y cual es su relación con los cinco grupos de procesos del Project Manament Institute o PMI independientemente de pasiones mal ubicadas por marcos de trabajo o técnicas específcas. En este video encontrará:

    • Modelo de Cascada, Tradicional o Waterfall
    • Modelo Ágil o Agile
    • Su relación con los grupos de procesos

    Todos los videos previos están disponibles en YouTube o si prefiere, en los siguientes enlaces:

    1. Definición de Proyecto
    2. Definición de Gestión de Proyectos
    3. Lo Necesario Para Ser Un Administrador de Proyectos
    4. Los Cinco Procesos De La Administración de Proyectos

    Estos videos forman parte del primer capítulo del curso Explorando La Administracion De Proyectos. La estructura del curso puede verla aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.

    Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica (sólo los videos que lo ameriten).

    Sin más el quinto video Cascada VS Agile del curso de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos:

    Algunas publicaciones recomendables para saber más:

    No Comment
  • The Agile Team / El Equipo Agile

    El Enfoque del Equipo Agile

    Antes de continuar

    Si usted no conoce las cuatro Declaraciones de Valor Agile, lo invito a que antes de continuar le eche un vistazo a la entrada El Origen Y Los Valores De Agile, si ya lo hizo o bien ya conoce estos valores, ahora puede enfocar su atención en como es el enfoque del equipo Agile en la práctica. Las cuatro Declaraciones de Valor Agile juntas suman un proceso altamente iterativo e incremental y entregan código probado al final de cada iteración. Los siguientes puntos cubren en lo general la manera en que un equipo Agile lleva un proyecto:

    • Trabaja en unidad
    • Trabaja en iteraciones cortas
    • Libera algo en cada iteración
    • Se enfoca en las prioridades de negocio
    • Inspecciona y se adapta

    El equipo Agile trabaja en unidad

    Desafortunadamente es común ver que analistas de negocios y de sistemas arrojan procesos o requerimientos a diseñadores y programadores cual pelota sobre la barda y sin más continúan con su vida, también hay diseñadores y arquitectos que elaboran sus atractivos diseños sin la más mínima consulta a sus compañeros programadores, o bien programadores talentosos que terminan la parte del sistema que les toca y acto seguido se sacuden las manos y desaparecen; y así podemos seguir con historias tristes. Un equipo Agile exitoso debe tener una mentalidad de “todos estamos en esto juntos”.

    Me gusta mucho usar analogías de juegos online, porque son una gran manera de ilustrar lo que sucede en la vida real. Muchos juegos en línea se juegan en equipo, donde cada miembro de dicho equipo tiene un rol. En esos equipos de jugadores existen roles como el healer que cura a sus compañeros, el tank que recibe golpes haciendo de escudo para que el resto ataque más eficientemente, los DPS que se encargan de hacer daño al enemigo y la clase especial que hace algun tipo de daño. Cuando algún jugador no cumple con su rol pone al resto del equipo en desventaja considerable, a veces esto quiebra al resto del equipo por completo. ¡Todos deben trabajar como uno!

    Así como sucede en estos juegos los equipo ágiles también tienen roles, y vale la pena identificarlos de manera general:

    Product Owner

    Las responsabilidades principales del product owner incluyen el asegurarse de que todo el equipo comparte la misma visión para el proyecto, estableciendo prioridades de manera que las funcionalidades que aportan mayor valor al negocio sean siempre en las que se trabaja. Tomar decisiones que lleven al mejor retorno de inversión del proyecto y la satisfacción de usuarios finales es la máxima prioridad.

    El cliente

    El cliente es la persona que tomó la decisión de financiar el proyecto, usualmente representa a un grupo o división. En estos casos es común que este rol se combine con el de product owner. En otros proyectos puede ser que el cliente sea un usuario.

    Desarrollador

    En el contexto de equipos agile un desarrollador se usa en un contexto amplio, esto es que un desarrollador puede ser un programador, un diseñador gráfico, un ingeniero de base de datos, expertos en experiencia de usuario, arquitectos, etc.

    Project manager

    Hay que tomar esto con algo de cuidado, porque un agile project manager se enfoca más en el liderazgo que en el management o (gestión tradicional del proyecto). En algunos proyectos y marcos de trabajo ágiles la persona encargada de este rol comparte las responsabilidades de un project manager tradicional con otros roles como el de product owner. También puede hacerse cargo de asesorar en la adopción y comprensión del enfoque agile. En proyectos muy pequeños puede incluso tener un rol como desarrollador, pero esta práctica no recomendable.

    Un equipo Agile trabaja en iteraciones cortas

    Ya lo mencionaba anteriormente, en proyectos ágiles no hay una delineación de fases demasiado marcada. No hay un establecimiento exhaustivo de requerimientos al comienzo del proyecto seguido de un análisis, no hay fase de diseño de arquitectura para todo el proyecto. Una vez que el proyecto inicia de verdad, todo el trabajo (análisis, diseño codificación, testing, etc.) ocurre junto dentro de una iteración.

    Las iteraciones se hacen dentro de espacio de tiempo delimitado previamente (timeboxed). Esto significa que cada iteración se termina en el tiempo acordado sin excusas, incluso aunque las funcionalidades previstas no se terminen. Las iteraciones son a menudo muy cortas. La mayoría de los equipos ágiles utilizan iteraciones de entre una semana y cuatro semanas.

    Un equipo Agile libera algo en cada iteración

    Algo crucial en cada iteración es que dentro de su espacio de tiempo uno o más requerimientos se transformen en software codificado, probado y potencialmente empaquetable. En la realidad esto no significa que algo se les entregue a los usuarios finales, pero se debe estar en posibilidades de hacerlo. Las iteraciones una a una van sumando la construcción de solo algunas funcionalidades, de esta manera se va obteniendo un desarrollo incremental al ir de una iteración a la siguiente.

    Debido a que una sola iteración usualmente no provee tiempo suficiente para desarrollar todas las funcionalidades que el cliente desea, se creó el concepto de release. Un release comprende una o más (casi siempre más) iteraciones. Los releases pueden ocurrir en una gran variedad de intervalos, pero es común que los releases duren entre 2 y 6 meses. Al terminar un release a este le puede seguir otro release y a su vez a este le puede seguir otro, así hasta terminar el proyecto.

    Un equipo Agile se enfoca en las prioridades del negocio

    Los equipos ágiles demuestran un compromiso con las prioridades comerciales de dos maneras. Primero, entregan funcionalidades en el orden especificado por el product owner, de quien se espera priorice y combine características en un release que optimiza el retorno de inversión de la organización en el proyecto. Para lograr esto, se crea un plan para el release basado en las capacidades del equipo y en una lista priorizada de las nuevas funcionalidades deseadas. Para que el product owner tenga mayor flexibilidad en la priorización, las características deben ser escritas minimizando las dependencias técnicas entre ellas.

    En segundo lugar, los equipos ágiles se centran en completar y entregar funcionalidades valoradas por el usuario en lugar de completar tareas aisladas.

    Un equipo Agile inspecciona y adapta

    Siempre es bueno crear un plan, pero el plan creado al inicio no garantiza lo que ocurrirá en el futuro. De hecho un plan es solo una suposición en un punto del tiempo. Si usted vive perseguido por la Ley de Murphy como yo 😀, habrá muchas cosas que conspirarán contra el plan. El personal del proyecto puede ir o venir, las tecnologías funcionarán mejor o peor de lo esperado, los usuarios cambiarán de opinión, los competidores pueden obligarnos a responder de manera diferente o más rápida, y así sucesivamente. Los equipos ágiles ven que cada cambio representa tanto una oportunidad como la necesidad de actualizar el plan para mejorar y reflejar la realidad de la situación actual.

    Al comienzo de cada nueva iteración, un equipo agile incorpora todo el nuevo conocimiento obtenido en la iteración anterior y se adapta en consecuencia. Si un equipo aprendió algo que probablemente afecte la precisión o el valor del plan, hay que actualizar el plan. Esto es, que quizá el quipo descubrió que han sobreestimado o subestimado su capacidad de progreso (capacity) y que un cierto tipo de trabajo consume más tiempo del que se pensó anteriormente.

    De la misma forma el plan se puede ver afectado por el conocimiento que el product owner ha ganado de los usuarios. Quizá por la retroalimentación obtenida de una iteración previa el product owner ha aprendido que los usuarios quieren ver más de algún tipo de funcionalidad y ya no valoran tanto otra que havían considerado. Este tipo de situaciones pueden alterar el plan, de manera que hay que adaptar el mismo para mejorar su valor.

    Enlaces relacionados:

    Roles on Agile Teams: From Small to Large Teams
    El Origen Y Los Valores De Agile
    What Is Agile?
    Planeación, Cono de Incertidumbre y Estimaciones en IT

    Estos son alguno libros recomendables para saber más:

    ¡Caulquier ayuda en bienvenida para mantener este esfuerzo vivo! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF

    No Comment
  • Flash VS HTML5

    Flash VS HTML5 Parte 5 (ahora sí la última parte….creo)

     

    Flash VS HTML5

    Historia

    Hace ya 3 años inicié una serie de entradas en este blog, en donde comparaba las tecnologías Flash y la entonces emergente HTML5, en aquel entonces atestigüé acalorados debates en diferentes foros y medios sobre las bondades y retos que estas dos tecnologías tenían enfrente, sin embargo hoy en día parece que tenemos claro para donde van las cosas, y aunque Flash se niega a morir y aun se puede encontrar a uno que otro nostálgico pero aguerrido defensor de esta tecnología (yo mismo fui entusiasta de Flash durante sus años de gloria), en este primer cuarto del 2015 se han colocado algunos de los clavos más firmes en el ataúd de Flash. Las malas noticias para Flash provenientes en esta ocasión de YouTube, Mozilla y de las mismas fallas de rendimiento y seguridad del plug-in Flash Player.

    Si es que alguien no lo sabe, Flash se propago ámpliamente hace más de década y media permitiendo a los desarrolladores web y multimedia crear gráficos, animación, video  y otras interacciones con el usuario que eran difíciles o imposibles para el navegador. Para que las creaciones en Flash pudieran ser visualizadas en los navegadores, tanto entones como ahora, se requiere de un plug-in llamado Flash Player, y es aquí donde comienzan los problemas para Flash (¿barbas a remojar para el plug-in de Java?).

    Con el poder de los navegadores incrementándose, la evolución de las capacidades de HTML5, la búsqueda del ahorro de recursos  y las nuevas propuestas que se suman en el camino, tenemos que los plug-in van de salida. El primer gran golpe para Flash fue el que dio el todavía vivo Steve Jobs desterrando a Flash del ecosistema del iPhone por ahí del 2010. Pero ahora tenemos tres nuevos golpes, aunque uno de ellos es engañoso y paradójicamente quizá le ofrezca un último asidero a Flash, veamos:

    Problemas de seguridad del Flash Player.

    Comenzando el año 2015 el Flash Player tuvo muchos problemas de seguridad, y la verdad sea dicha es el plug-in favorito de los black hat hackers lo que ha llevado incluso a sugerir a algunos expertos el que no se instale el plug-in a menos que sea totalmente necesario, el problema es que en poco mas de dos semanas Adobe tuvo que hacer tres parches de emergencia para peligrosos bugs, lo cual ha sido en realidad un problema constante durante la vida de Flash. Esto llevó a Adobe a tener que trabajar rápidamente con sus socios distribuidores iniciando el año, dígase Google y Microsoft, para corregir el problema tanto en Chrome como en Internet Explorer de primera mano, pero al final los usuarios tenia que hacer varias actualizaciones del plug-in dependiendo de los navegadores que utilizasen; el problema fue tan grave que incluso Mozilla Firefox desactivo definitivamente el plug-in hasta que hubiera una solución final.

    YouTube abandona el uso de Flash por default en sus videos.

    YouTube, el mayor proveedor de videos en Flash de la historia, anunció que dejaría de servir videos utilizando el plug-in para todos los usuarios que consumen su contenido en un navegador moderno, haciendo por default el uso de HTML5 y su tag . Richard Leider en el blog de la gerencia de ingeniería de YouTube hace una interesante referencia a las razones por las cuales no habían podido hacer de HTML5 su plataforma favorita de entrega de video hasta el momento y de como las cosas han ido evolucionando para HTML5 hasta el punto de poder cerrar brechas técnicas. Esto sin duda marcará la tendencia para otros sitios de video.

    Mozilla y su proyecto Shumway

    En febrero Mozilla y sus programadores activaron Shumway para la reproducción de videos Flash en la plataforma Amazon SIN el uso del Flash Player. El proyecto Shumway ha estado en desarrollo desde hace algunos años y lo que intenta, en pocas palabras, es poder reproducir contenido SWF y FLV sin utilizar el Flash Player, si esto se lograra de forma completamente eficaz y eficiente significaría (desde mi punto de vista) la muerte absoluta e inmediata del Flash Player, sin embargo, el proyecto Shumway no está terminado y aun requiere mucho trabajo, pero lo que ha logrado es bastante prometedor.

    Aquí es donde entra la paradoja y la esperanza para Flash, si bien algo como Shumway al final representaría la muerte inmediata del Flash Player, también significaría darle nueva vida al Flash Professional, la herramienta de creación de Adobe y probablemente a algunas otras que también crean contenido SWF y FLV. La herramienta de diseño y animación Flash Professional per se, sigue siendo bastante buena, trata de ir adaptándose a los nuevos estándares web mientras se mantiene relativamente más accesible que otras herramientas de animación y hoy por hoy aun no existe una herramienta tan buena como el Flash Professional dirigida a el HTML5 puro, el mismo Adobe lo intenta con su Adobe Edge Animate desde hace tiempo pero creo que aun no lo logran.

    Enlaces a las posts previos:

    Flash VS HTML5 Parte 4

    Flash VS HTML5 Parte 3

    Flash VS HTML5 Parte 2

    Flash VS HTML5 Parte 1

    2 Comments
  • Arrastrar y Soltar

    Arrastrar y Soltar HTML5

    Arrastrar y Soltar

    Arrastrar y Soltar en HTML5

    Sin duda la posibilidad que introdujo HTML5 para Arrastrar y Soltar de manera nativa representó un avance, esto sin duda fue una novedad ya que en la era pre-HTML5, la única manera de lograr esto era con la utilización de complejas operaciones con JavaScript, por lo que la mayoría de los desarrolladores terminábamos utilizando alguna librería como JQuery, MooTools u otras para contar con la funcionalidad de Arrastrar y Soltar (Drag and Drop), o si la situación requería de mucha interactividad y gráficos la utilización de Flash era casi imperiosa. La clase nativa para Arrastrar y Soltar de HTML5 lleva un tiempo existiendo pero tenía varios problemas que se han ido solucionando poco a poco. El principal problema quizá era que los ejemplos que se podía encontrar por ahí, continuamente solo funcionaban en un navegador y no en los demás, pero los fabricantes han ido homologando cada vez más la clase aunque no todos todavía. La clase aún no es totalmente perfecta y tiene aún varios detractores y críticos muy enfáticos, sin embargo, posee varias ventajas sobre otras opciones. En esta entrada abordaré lo que necesita saber para comenzar a utilizar la clases Arrastrar y Soltar de HTML5 explicando sus puntos más básicos e importantes. Puede ver el ejemplo que a continuación explicaré en este enlace, comencemos…

    Ventajas sobre otras implementaciones Arrastrar y Soltar

    Como mencioné, he podido encontrar que en varios blogs aseguran que el Arrastrar y Soltar de HTML5 no debería ser utilizado, a lo cual me gustaría contra argumentar, sobre todo porque la clase me ha sido de gran ayuda últimamente:

    • Interacción con otras aplicaciones o aplicacion de derivadas. La implementación del Arrastrar y Soltar de HTML5 permite la interacción entre iframes e incluso entre ventanas de navegadores. Si me permiten ser un poco entusiasta en este punto, invito a quien sea a que intente implementar un Arrastrar y Soltar entre iframes y/o ventanas utilizando librerías JavaScript…¡el horror!….
    • El framework nativo es independiente de terceros. Tener una clase nativa siempre tiene la ventaja de independencia en cuanto a las situaciones que pueden rodear y afectar al desarrollo de un tercero, lo que evidentemente no sucede con las alternativas que presentan JQuery, MooTools, Dojo, etc., ahí la dependencia es total.
    • Interacción con aplicaciones que no son web. Un ejemplo de esto es que ahora es posible arrastrar un archivo del escritorio a una aplicación en el navegador.

    Las bases, paso a paso

    Para facilitar un poco las cosas he organizado esta entrada en pasos, cada paso describe un concepto o varios que iré ejemplificando.

    1. Especificando los elementos arrastrables (draggable object)

    Lo primero que necesita hacer es definir que nodo o nodos del documento HTML5 serán susceptibles de ser arrastrados, en HTML5 casi cualquier elemento visible puede ser arrastrado, como son imágenes, divs, links, etc., para lograr esto se utiliza el atributo draggable=”true”. Por ahora no aplica el manejo de valores falso o verdadero a  la manera clásica de XHTML en los navegadores que he probado, es decir, al atributo no funciona si lo escribimos como draggable=”draggable” incluso dentro de un archivo xhtml. También hay elementos que son arrastrables por default para algunos navegadores, como lo son imágenes y selecciones de texto. En el sigiente ejemplo se muestran algunos cuadros que serán los elementos arrastrables para este ejemplo:

    <div id="squares">
        <div class="square" draggable="true">
            <h1>1</h1>
        </div>
        <div class="square" draggable="true">
            <h1>2</h1>
        </div>
        <div class="square" draggable="true">
            <h1>3</h1>
        </div>
    </div>

    Acompañando este código colocamos los siguientes estilos CSS:

    .square {
    height: 100px;
    width: 100px;
    border: 1px solid #000;
    float: left;
    background-color: #eee;
    margin: 5px;
    -webkit-box-shadow: inset -1px -1px 3px #000;
    -ms-box-shadow: inset -1px -1px 3px #000;
    box-shadow: inset -1px -1px 3px #000;
    text-align: center;
    cursor: move;
    }
    
    h1 {
    font-size: 75px;
    }
    
    .target {
    height: auto;
    min-height: 150px;
    width: 320px;
    float: left;
    border: 1px solid #000;
    margin: 5px;
    background-color: #ccc;
    -webkit-box-shadow: inset -1px -1px 3px #000;
    -ms-box-shadow: inset -1px -1px 3px #000;
    box-shadow: inset -1px -1px 3px #000;
    text-align: center;
    cursor: move;
    }

    En navegadores webkit (Chrome, Safari) y Firefox el código anterior nos presenta una serie de cuadrados que originarán una especie de “fantasma” si intenta arrastrarlos, ahora hay que agregar los eventos apropiados. Resultado:

    2. Asignando eventos a los elementos arrastrables (Drag Objects)

    Ahora que tenemos los objetos que deseamos se puedan arrastrar, debemos asignarles algunos eventos utilizando JavaScript, estos objetos pueden disparar lo siguientes tres eventos:

    • dragstart. Se dispara cuando el usuario comienza a arrastrar el objeto.
    • drag. Se dispara cada vez que el puntero del mouse se mueve mientras que un objeto está siendo arrastrado.
    • dragend. Se dispara cuando el usuario suelta el botón mientras un objetos está siendo arrastrado. Estos eventos se asignan como lo hace normalmente JavaScript o la librería de su preferencia. Vamos a agregar unos cuantos elementos al código HTML:
    <div id="squares">
        <div class="square" draggable="true">
            <h1>1</h1>
        </div>
        <div class="square" draggable="true">
            <h1>2</h1>
        </div>
        <div class="square" draggable="true">
           <h1>3</h1>
        </div>
    </div>
    <p id="event"></p>
    <p id="status_drag"></p>
    <p id="status_over"></p>
    <p id="status_drop"></p>

    Agreguemos el siguiente código JavaScript para asignar los eventos descritos a nuestros cuadros:

    /*
    * En el evento dragstart se coloca un mensaje que se verá muy brevemente
    * o quizá no se note, cuando el usuario inicia el arrastre
    */
    function dragStartEvent(e) {
        eventStatus.innerHTML = "evento  dragStart"
    }
    
    /*
    * El evento drag reporta al usario cuando inicia y que un arrastre
    * está actualmente en progreso
    */
    function dragEvent(e) {
        eventStatus.innerHTML = "evento drag."
        dragStatus.innerHTML = "Arrastrando en este momento.";
    }
    
    /*
    * El evento dragover despliega un mensaje cuando es llamado y otro que
    * que indica que el arrastre ha terminado
    */
    function dragEndEvent(e) {
       eventStatus.innerHTML = "evento dragend."
       dragStatus.innerHTML = "Arrastre terminado."
    }
    
    //variables para elementos informativos
    var eventStatus = document.getElementById('event');
    var dragStatus = document.getElementById('status_drag');
    //variable para alamacenar todos los divs que usan la clase square
    var squareItems = document.querySelectorAll('.square');
    
    //ciclo para asignar los eventos a cada cuadro (div square)
    [].forEach.call(squareItems , function(squareItem) {
        squareItem.addEventListener('dragstart',dragStartEvent, false);
        squareItem.addEventListener('drag',dragEvent, false);
        squareItem.addEventListener('dragend',dragEndEvent, false);
    });

    Este código deber ser llamado cuando el documento HTML está cargado, note como simplemente se asignaron los eventos y estos despliegan mensajes cuando son disparados.

    3. Asignando eventos al elemento objetivo (Drop Object)

    Hasta ahora hemos logrado arrastrar elementos por la ventana, pero tenemos que asignar algún objeto en donde los elementos arrastrables puedan ser soltados, a este elemento lo llamaremos objetivo o drop target. Al elemento objetivo o drop target le podemos asignar los siguientes eventos:

    • dragenter. Se dispara cuando un objeto arrastrable es el primero en arrastrase dentro de un objeto.
    • dragover. Se dispara cuando un objeto arrastrable es arrastrado dentro de un objeto. Hay que tener presente que si se desea que el objeto que está siendo arrastrado pueda ser soltado dentro de otro, debe cancelar el comportamiento por default de este.
    • dragleave. Se dispara cuando un objeto arrastrable es arrastrado fuera de un nodo objetivo.
    • drop. Se dispara cuando un objeto arrastrable es soltado dentro de un nodo objetivo. Si desea convertir un objeto en un elemento o nodo objetivo que permita soltar elementos arrastrables, debe de asignar los eventos dragover y drop de manera obligatoria, es fácil entender porque el evento drop debe ser usado, pero quizá no sea tan claro porque dragover también, la razón es porque el elemento que se está arrastrando puede tener otro funcionamiento que no se desea cuando se suelta, por ejemplo, si está arrastrando un enlace y no previene el comportamiento por default, cuando suelte este elemento el navegador se direccionará a la URL del enlace como si usted hubiera hecho un clic normal, lo que no es deseable mientras se arrastra y se suelta el elemento. Al código que tiene actualmente, agregue al final el elemento objetivos para soltar el elemento:
    <div id="target1" class="target">Suelte elementos aquí</div>

    Agregaremos dos variables solo para alertar cuando se disparan los nuevos eventos y tener mejor idea de que el elemento objetivo está siendo efectivamente afectado.

    var overStatus = document.getElementById('status_over');
    var dropStatus = document.getElementById('status_drop');

    Y claro el código para asignar los nuevos elementos:

    dropItem.addEventListener('dragover', dragOverEvent, false);
    dropItem.addEventListener('drop', dropEvent, false);

    Los otros ventos que no incluí no son indispensables (dragenter y dragleave) pero son útiles, por ejemplo, para ofrecer más indicadores visuales al usuario y hacer una experiecia más intuitiva, pero por ahora lo omito para mayor claridad, si desea más ejemplos incluyendo estos eventos, recuerde que en el pedir está el dar 😉 Resultado:

    4. Transferecia de datos del elemento arrastrable al elemento objetivo (Datratrasfer object).

    En este punto está casi todo listo, pero donde culmina todo lo que hemos hecho es en la transferencia de datos del elemento que estamos arrastrando. Por ahora, aunque nuestro elemento parace estar haciendo todo bien, aún no lo logra ser “soltado” dentro del elemento objetivo como esperaríamos, es aquí donde la transferencia de datos hace su magia. Lo que se necesita es la propiedad dataTransfer y sus métodos setData() y getData(). Lo primero es utilizar el método setData() dentro de uno de los eventos asignados al elemento que se arrastra, usualmente se utiliza el evento dragstart, por parte de los eventos del elemento objetivo, estos pueden recibir los datos transferidos en algunos de sus eventos asignados, es ahí de donde se utiliza getData(), entonces: setData(format, data). Establece la información que se intercambia entre el nodo que se arrastra y y el nodo objetivo. El parámetro format establece el tipo de dato que se va a intercambiar, hasta ahorita los únicos tipos de dato que existan son “text” y “url” (se usa el formato de mimetype). El parámetro data es el información persé que sera intercambiada, lo cual es una cadena de texto, comunmente se utiliza innerHTML. getData(format). Recupera la información que fue previamente asignada por setData(), el setData puede estar incluso en otra página, incluso en otro navegador. El parámetro format es el tipo de dato asociado con lo que se espera, los tipos de dato pueden ser “text” y “url” (se usa el formato de mimetype). Ahora utilicemos lo que hemos aprendido en nuestro código. Dentro del evento dragstart coloquemos la siguiente línea:

    e.dataTransfer.setData('text/html', this.innerHTML);

    Con la línea anterior ha preparado la información que se va a transferir en el arrastre, ahora toca el turno de indicarle al nodo objetivo cual es información que va a recibir cuando el usuario suelte el elemento que está arrastrando, sin más agreguemos las siguientes líneas de código al evento drop:

    var dropedelement = document.createElement('span');
    dropedelement.innerHTML = e.dataTransfer.getData('text/html');
    this.appendChild(dropedelement);

    Para terminar.

    El código JavaScript completo debería lucir aproximadamente de la siguiente manera:

    /*
    * En el evento dragstart se coloca un mensaje que se verá muy brevemente
    * o quizá no se note, cuando el usuario inicia el arrastre
    */
    function dragStartEvent(e) {
        eventStatus.innerHTML = "evento  dragStart.";
        overStatus.innerHTML = "";
        dropStatus.innerHTML = "";
        e.dataTransfer.setData('text/html', this.innerHTML);
    }
    
    /*
    * El evento drag reporta al usario cuando inicia y que un arrastre
    * está actualmente en progreso
    */
    function dragEvent(e) {
        eventStatus.innerHTML = "evento drag.";
        dragStatus.innerHTML = "Arrastrando en este momento.";
    }
    
    /*
    * El evento dragover despliega un mensaje cuando es llamado y otro que
    * que indica que el arrastre ha terminado
    */
    function dragEndEvent(e) {
        eventStatus.innerHTML = "evento dragend.";
        dragStatus.innerHTML = "Arrastre terminado.";
    }
    
    /*
    * El evento dragend despliega un mensaje cuando es llamado y otro que
    * que indica sobre que elemento objetivo se arratra actualemte, si es
    * el caso
    */
    function dragOverEvent(e) {
        if (e.preventDefault) {
            e.preventDefault(); // Necesario para permitir soltar.
        }
        eventStatus.innerHTML = "evento over.";
        overStatus.innerHTML = "Elemento arrastrable sobre " + this.id;
    }
    
    /*
    * El evento drop despliega un mensaje cuando es llamado y otro que
    * que indica en que elemento objetivo se ha soltado el elemento
    */
    function dropEvent(e) {
        eventStatus.innerHTML = "evento drop";
        dropStatus.innerHTML = "Se ha soltado un elemento dentro de " + this.id;
        var dropedelement = document.createElement('span');
        dropedelement.innerHTML = e.dataTransfer.getData('text/html');
        this.appendChild(dropedelement);
    }
    
    //variables para elementos informativos
    var eventStatus = document.getElementById('event');
    var dragStatus = document.getElementById('status_drag');
    //variables para elementos informativos
    var overStatus = document.getElementById('status_over');
    var dropStatus = document.getElementById('status_drop')
    //variable para alamacenar todos los divs que usan la clase square
    var squareItems = document.querySelectorAll('.square');
    var dropItem = document.getElementById('target1');
    
    //ciclo para asignar los eventos a cada cuador (div square)
    [].forEach.call(squareItems , function(squareItem) {
        squareItem.addEventListener('dragstart',dragStartEvent, false);
        squareItem.addEventListener('drag',dragEvent, false);
        squareItem.addEventListener('dragend',dragEndEvent, false);
    });
    
    dropItem.addEventListener('dragover', dragOverEvent, false);
    dropItem.addEventListener('drop', dropEvent, false);

    Lo que obtenemos tiene este aspecto después de arrastrar todos los elementos:

    Note que este ejemplo copia los elementos en lugar de moverlos (no elimina el elemento original) pero usted puede hacerlo si lo desea. Por supuesto se pueden hacer implementaciones un tanto más sofisticadas, pero por ahora usted ha cubierto las bases para posteriormente hacer un uso más interesante e intenso de la la clase Arrastrar y Soltar de HTML5.  Si usted tiene alguna opinión, crítica, aportación o cualquier otra cosa, deje un comentario en esta entrada, o bien envíelo a @ManuGekko o @RealInernet80 en Twitter.

    Otros enlaces de interés:

    Arrancar con HTML5 Curso de Programación

    Subir un archivo con HTML5

    Transiciones y Transformaciones en Botones (CSS3 y HTML5)

     

     

    1 Comment