ALLSOFT - Blog Allsoft , Agilidad

Propósito de la Reunión Diaria (daily scrum)

Thu, 04 Jul 2024 11:34:00 -0600

La reunión diaria de Scrum no es solo una reunión para dar el estado de las cosas hacia la gerencia, es algo más que eso, es para ponernos de acuerdo, ver que todos estamos en el mismo canal, interesarnos en lo que los demás están haciendo, ver que rumbo tomamos.

Es importante recordar que debemos trabajar como un equipo. Para que la reunión sea efectiva, debe ser breve, por eso se realiza de pie. No debemos centrarnos en una sola persona para mostrar nuestro trabajo; nuestros comentarios son para todo el equipo. Esto puede ser difícil, ya que la tendencia ha sido siempre "reportar" a alguien y que "alguien" nos diga lo que debemos hacer. Este es un punto crucial que debemos superar para empezar a funcionar como un equipo autoorganizado.

El propósito de la reunión diaria o "daily scrum" en Scrum es asegurar que el equipo esté alineado y trabajando de manera coordinada hacia el objetivo del sprint. Es una reunión breve, de no más de 15 minutos, que se realiza todos los días y en la cual cada miembro del equipo responde a tres preguntas clave:

1. ¿Qué hice ayer para ayudar al equipo a alcanzar el objetivo del sprint?
2. ¿Qué haré hoy para ayudar al equipo a alcanzar el objetivo del sprint?
3. ¿Hay algún impedimento que me impida avanzar?

Los objetivos principales del daily scrum son:

1. Facilitar la comunicación: Permitir que todos los miembros del equipo estén informados sobre el progreso de los demás y fomentar la colaboración.

2. Identificar y resolver obstáculos: Detectar rápidamente cualquier problema o impedimento que pueda estar bloqueando el progreso y buscar soluciones de manera proactiva.

3. Promover la transparencia y la responsabilidad: Mantener a todos responsables de sus compromisos diarios y asegurar que todos estén trabajando hacia el mismo objetivo.

4. Ajustar el plan de trabajo diario: Adaptar y ajustar las tareas diarias según las necesidades actuales del proyecto, garantizando que el equipo esté enfocado y alineado.

La daily scrum no es una reunión de status para los gerentes, sino una oportunidad para que el equipo de desarrollo se sincronice y se autoorganice.

Foto de Jason Goodman en Unsplash

Atendiendo con Kanban

Wed, 12 Jul 2023 10:27:00 -0600

La utilización de la gestión visual con Kanban tiene muchas aplicaciones y es fácil de implementar en nuestro entorno laboral o personal. Diseñando los tableros de acuerdo a las propias necesidades, del tipo de trabajo a resolver, y del equipo con el que contamos, podemos establecer una buena dinámica en los niveles de atención y en el flujo de trabajo.

Un caso práctico de una implementación, a raíz de haber tomando nuestro curso, fue mejorar la atención de alumnos que desean entrar a la Universidad.

Necesidad: Se quiere tener visibilidad del proceso de inscripción de cada alumno, y la atención que se le da a cada uno de ellos. El proceso de inscripción inicia del interés o solicitud del alumno, de la recepción de documentación, cumplimiento de requisitos, pagos, y generación de matricula. Se bien, se cuenta con las herramientas para llevar el proceso, no se ve con facilidad todo el panorama.

Solución: Se diseñó un tablero en donde se incluyeron las fases por las que el alumno pasa para quedar inscrito, así como la gente que participa activamente en cada una de estas fases. La columna final del tablero están los alumnos que han terminado el proceso y ya han sido inscritos.

Mejora: En el tablero se podían ver las fases en las que se estaba acumulando trabajo para apoyar a las personas involucradas y dar fluidez. Departamentos involucrados en la captación y otros, podían ver en el tablero el flujo de las solicitudes sin necesidad de interrumpir constantemente el trabajo de las personas. Se logró la identificación de asuntos críticos que causaban cuellos de botella, mejoró el flujo de trabajo, así como la comunicación interna y hacia los alumnos. Se mide el tiempo de atención entre que se recibe la solicitud hasta que el alumno queda inscrito.

La retroalimentación de está aplicación fue que los diferentes departamentos involucrados y gerencias tenían visibilidad de lo que estaba sucediendo rápidamente, en tiempo real, de como el trabajo fluye. Tomar acciones para mantener el flujo, así como retroalimentar sobre el proceso de atención. El trabajo lo hacía más divertido con la actividad de ir a mover las notas, ver el trabajo que viene en camino, y el trabajo que se estaba terminando.

Consulta la información de nuestro taller de Kanban

Image by Freepik

SalesIQ en tu móvil

Wed, 12 Jul 2023 10:27:00 -0600

Zoho SalesIQ se encuentra disponible para utilizarlo en tu celular.

Con la aplicación puedes dar seguimiento a los visitantes directo desde el celular para no perder ninguno. Gran parte de la funcionalidad de la aplicación web la tienes en la aplicación para el celular. En el celular puedes recibir notificaciones cuando alguien esté en tu sitio web, e iniciar un chat en vivo con el visitante.

Convierte más visitantes en clientes. Descarga la aplicación desde la tienda de Google Play o de Apple Store.

¿Qué es DevOps?

Wed, 19 Apr 2023 08:39:59 -0600

DevOps es una metodología de desarrollo de software que se enfoca en la colaboración y la comunicación entre los equipos de desarrollo de software y operaciones de tecnología de la información (TI). Se trata de una cultura que tiene como objetivo mejorar la calidad del software, la eficiencia de los procesos y la satisfacción de los usuarios.

La palabra "DevOps" es una combinación de las palabras "desarrollo" (development) y "operaciones" (operations). Esta metodología fue desarrollada en respuesta a la necesidad de una mayor integración y colaboración entre los equipos de desarrollo de software y operaciones de TI.

La metodología DevOps se centra en la automatización de procesos, la integración continua y la entrega continua (CI/CD). Con la automatización de procesos, los equipos de desarrollo y operaciones pueden trabajar juntos de manera más eficiente para llevar a cabo las tareas repetitivas y tediosas, lo que les permite concentrarse en tareas más importantes.

La integración continua (CI) es un proceso que permite a los equipos de desarrollo integrar su trabajo de forma regular y automatizada en un repositorio común. Esto permite la detección temprana de errores y una mayor transparencia en el proceso de desarrollo. La entrega continua (CD) implica la entrega automatizada y continua de software a los usuarios finales.

Los equipos de DevOps utilizan herramientas de automatización, como sistemas de control de versiones, herramientas de prueba de software, herramientas de integración continua y entrega continua, y herramientas de monitoreo y análisis para mejorar la eficiencia y la calidad del software.

Image by pressfoto on Freepik

¿Cómo garantizar que el equipo entregue la funcionalidad?

Fri, 24 Mar 2023 12:51:58 -0600

Lo que el usuario espera de su producto, está reflejado o plasmado en las historias de usuario definidas. ¿Cómo aseguramos que hemos entendido y estamos entregando lo que se espera?. Definiendo lo que debemos de tener como resultado esperado al implementar cada una de las historías de usuario a través de los criterios de aceptación de la historia.

Los criterios de aceptación son una lista de condiciones o requisitos que deben cumplirse para que se considere que una historia de usuario se ha completado correctamente. Estos criterios se utilizan para definir el alcance y los límites de una tarea, así como para asegurar que el trabajo realizado cumple con las expectativas y necesidades del cliente o usuario final.

Los criterios de aceptación se pueden incluir en una historia de usuario como parte de la descripción o se pueden separar en un documento aparte. Por lo general, estos criterios se definen durante la fase de planificación del proyecto, antes de que comience el trabajo de las tareas relacionadas con la historia de usuario..

Un par de ejemplos de criterios de aceptación para una historia de usuario podrían ser:

"El usuario debe ser capaz de agregar un artículo al carrito de compras y completar la compra con éxito, recibiendo un correo electrónico de confirmación de la transacción en un plazo máximo de 5 minutos."

"Al terminar el registro de la tarea el usuario deberá recibir un correo con la información de la tarea asignada y la tarea deberá de aparecer en el listado de tareas por completar."

En este ejemplo, se establece claramente lo que se espera que el usuario pueda hacer y se establece un plazo límite para que el sistema realice una acción específica. Estos criterios pueden ser revisados y ajustados a lo largo del proceso de desarrollo y pueden ser utilizados para realizar pruebas de calidad y asegurar que el trabajo realizado cumple con las expectativas del usuario final.

Es importante recalcar que los criterios de aceptación No son actividades adicionales a realizar, sino, cosas que deben de suceder resultado de la implementación de una historia de usuario determinada. Los criterios de aceptación deben ser específicos, medibles y verificables.

Cómo conclusión, los criterios de aceptación nos ayudarán a garantizar que el equipo de desarrollo está entregando lo que el usuario espera como solución.

Los Story Points o Puntos de Historia

Mon, 31 Jan 2022 21:39:30 -0600

Los puntos de historia son unidad de trabajo empleada habitualmente en Extreme Programming y metodologías ágiles, definida por la cantidad de trabajo a realizar en un día de trabajo ideal (tiempo ideal). Expresa una estimación que se requerirá para implementar completamente un elemento de la pila de producto. En lugar de medir el trabajo en horas o días, se utiliza una escala relativa para comparar la complejidad entre diferentes tareas.

Una de las ventajas de utilizar los Puntos de Historia en lugar de medidas más precisas de tiempo es que permite al equipo enfocarse en la complejidad de la tarea en lugar de en el tiempo que tardará en completarse. Esto ayuda a evitar subestimar o sobreestimar el tiempo que llevará completar una tarea y permite una planificación más precisa.

A cada uno de los elementos de la pila de producto le asignamos un valor en puntos. Al final, lo importante son los valores relativos, una historia de 2 puntos debe ser el doble de trabajo que una historia que tiene asignado 1 punto.

¿Qué debemos considerar en un punto de historia?

El punto de historia representa todo el trabajo que se tiene que hacer para implementar por completo un elemento de trabajo. Para determinar la cantidad de puntos debemos de considerar:

La cantidad de trabajo por hacer
Qué tan complejo es
Riesgos involucrados

Es posible que la tarea es sí pueda ser sencilla, pero el contexto en el que tenemos que implementarla la vuelve compleja.

Cantidad de trabajo por hacer

Al definir la cantidad de puntos hay que tomar en cuenta la cantidad de trabajo por hacer. Si por ejemplo hay que actualizar el tamaño de un campo en su cantidad de caracteres que acepta. Antes de asignar los puntos deberemos tener en cuenta todas las partes en las que tenemos que hacer ese ajuste. Actualizar el campo en una forma, no involucra el mismo trabajo que actualizarlo en 20 formas.

La cantidad de trabajo por hacer o el esfuerzo para hacerla, no se deberá relacionar con la cantidad de puntos. Un punto no representa 1 hora o 2 horas, es una medida relativa que el equipo asigna para identificar que un elemento con más puntos requiere más esfuerzo que otro con menos puntos.

¿Qué tan complejo es?

Si consideramos hacer un reporte que involucra listar los campos de una sola fuente debe resultar más fácil, y por lo tanto, menos puntos, que hacer un reporte que involucra una sola fuente pero que incluye columnas calculadas, subtotales y totales.

Para el segundo reporte que lista campos nos requerirá más tiempo generar las columnas calculadas, así como desplegar los subtotales y totales. También puede ser más complejo de acuerdo los tipos de cálculos que involucran las columnas calculadas.

Riesgos involucrados

En la asignación de puntos no podemos dejar de lado considerar si hay algún riesgo involucrado al implementar el elemento de trabajo. En el caso de reporte que tiene columnas calculadas puede ser que la fuente sea una fuente externa lo que puede implicar que dicha fuente este disponible, que nos podamos conectar o que los datos sean correctos. Lo anterior nos puede conducir a que se requiera mas tiempo en la implementación.

Al momento de estimar debemos de resumir el esfuerzo que involucra hacer cada elemento de trabajo considerando los 3 factores de esfuerzo, complejidad y riesgos involucrados. Debemos tener en cuenta también las proporciones de las estimaciones que estamos haciendo, los elementos con menos puntos involucran menos esfuerzo, son menos complejos y tienen menor riesgo, que los elementos que tiene mayor cantidad de puntos.

Recordemos también que los puntos de historia son una medida relativa al equipo de trabajo, por lo que, otro equipo puede asignar diferente cantidad de puntos de historia a algún elemento de trabajo similar al nuestro

6 Responsabilidades del Dueño de Producto

Tue, 25 Jan 2022 14:47:12 -0600

Para mejorar las posibilidades de éxito del proyecto cada uno de los participantes debe de tener claro su participación y lo que se espera de él. El rol de Dueño de Producto es fundamental en la agilidad porqué marcará la pauta del desarrollo del producto. Es por ello que debe de tener claro lo que se espera de él y de sus responsabilidades hacia el proyecto y hacia el equipo.

Aquí te dejamos algunas de las responsabilidades de un Dueño de Producto.

1. Definir la visión

El Dueño de Producto es una persona clave en el equipo que tiene el conocimiento del producto para definir los objetivos y la visión para el proyecto. El Dueño debe de comunicar a todas las partes involucradas dichos objetivos y la visión para asegurarse que estén alineados a los objetivos del negocio.

Uno de los propósitos de la visión es mantener al equipo motivado y enfocado ante un proceso de desarrollo que es flexible y a veces incierto.

¿Su equipo tiene definida una visión?, ¿Su equipo conoce la visión?, ¿Durante la ejecución del proyecto validan las necesidades contra la visión del producto?

2. Gestionar la pila de Producto

Una de las responsabilidades más importantes es generar y mantener la pila de producto, que es la fuente de trabajo para el equipo durante los Sprints. La pila de producto debe ser conocida por el equipo e interesados para conocer el rumbo que toma el producto y contiene las necesidades de los clientes del dueño de producto.

Es responsabilidad del dueño de producto mantener esta lista de producto actualizada, priorizada y con el suficiente detalle para organizar el trabajo del desarrollo del producto. La actualización implica, tanto como poner nuevos elementos en la pila, como eliminar aquellos elementos que ya no aplican al producto.

3. Priorizar la pila de Producto

El dueño de producto marca la pauta del desarrollo a través de la organización de los elementos de la pila de producto a través de establecer prioridades en la misma. Los elementos de más prioridad en la pila solo los de más valor para el negocio.

4. Planificar el trabajo

El dueño de producto de acuerdo con sus necesidades y prioridades debe de planificar el trabajo para el Sprint en conjunto con el equipo tomando en cuenta sus capacidades. La planificación implica clarificar el trabajo y negociar con el equipo el trabajo a realizar.

5. Supervisar la evolución del producto

Durante todo el proyecto el dueño de producto debe ser muy participativo para supervisar, y colaborar en el desarrollo del producto atendiendo las necesidades de información del equipo. Recordemos que las historias de usuario son una conversación mas que una especificación, por lo que el aporte del dueño de producto durante el desarrollo es esencial.

6. Evaluar el progreso

En forma periódica debe de evaluar el progreso del equipo en cuanto a los avances del producto y tomar decisiones sobre que partes son aceptadas y cuales no. Retroalimentar al equipo en el trabajo realizado y replantear el producto para las siguientes iteraciones

Los 12 Principios Ágiles

Wed, 12 Jan 2022 13:24:00 -0600

En las implementaciones de Scrum siempre es necesario tener presentes los principios ágiles en el día a día, dichos principios nos ayudan a establecer si estamos o no trabajando en forma ágil. ¿Estamos entregando valor en forma continua?, ¿Nuestro software funciona?, ¿Mantenemos las cosas simples?, serían por ejemplo, algunas de las preguntas en relación a los principios ágiles. Si no estamos haciendo lo anterior no estamos trabajando en forma ágil. Recordar que parte de la riqueza de la agilidad es ir adaptándonos para ser lo mas productivos y eficientes, y es importante también que dichas transformaciones no hagan que nos alejemos de los principios, ni que nuestra forma de trabajo de “calcifique” y ya no permita adaptarnos.

Como complemento del manifiesto ágil, los principios ágiles establecen una guía para de las ideas centrales de la agilidad.

1: Nuestra principal prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor

Para ser considerados ágiles debemos de entregar software funcionando y de utilidad a las pocas semanas y así seguir haciéndolo en forma continua. El cliente tiene la oportunidad de probar y usar el software para retroalimentar y ajustar, para al final tener lo que él quiere y necesita.

2: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

La realidad es que no es posible que el usuario conozca todos los requisitos de su producto desde un inicio. Debe ser un proceso de descubrimiento al cual debemos de adaptarnos para lograr la solución deseada. La entrega temprana y constante hace que el usuario cambie la perspectiva y el conocimiento de su producto y por lo tanto surjan los cambios los cuales debemos de ir incorporando para dar forma al producto.

3: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia por periodos de tiempo lo más corto posible.

La entrega continua hace que la incertidumbre y los riesgos disminuyan ya que el usuario tiene la oportunidad de ir viendo el crecimiento del producto, se va forjando una idea de su producto final a través de las pruebas y el uso. Igual crece el riesgo de demasiados cambios y entrar en un ciclo que no se haga nada nuevo, por lo que hay que trabajar de cerca con él usuario y hacerle ver esto.

4: Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto

Dado el ritmo de trabajo, la incertidumbre y los riesgos es de suma importancia que todos trabajen en forma conjunta día a día, se tenga disponibilidad para resolver dudas, problemas y definir estrategias.

5: Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

La agilidad se basa en las personas, por lo que hay que darles el espacio y las herramientas para que generen la mejor solución para el usuario. Hay que dar el espacio y la confianza al equipo para que tomen sus decisiones.

6: El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

La más sencilla, práctica y eficiente forma de comunicación entre los integrantes del equipo (Dueño de producto incluido) es la comunicación cara a cara. Reduce los problemas y los malentendidos, la toma de decisiones es más rápida.

7: El software funcionando es la principal medida progreso.

El software funcionando y entregado es lo que nos indica cómo vamos en el proyecto, si no está indica problemas, retraso, conflictos, cambios o ajustes que hay que atener para obtener el software que queremos.

8: Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

El equipo debe de lograr un ritmo sostenido en el que sea capaz de entregar software funcionando, de valor, y de calidad. Ni más lento, ni más rápido. El Dueño de Producto y el SCRUM Master deben proveer al equipo del trabajo, las herramientas y las condiciones para que esto sea posible.

9: La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

El equipo debe lo más productivo posible, reducir la deuda técnica, por lo que los productos generados deben de ser de la más alta calidad posible. Cualquier problema regresará al equipo y reducirá la capacidad del mismo para entregar nueva funcionalidad.

10: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

No hay que complicarse la existencia para desarrollar buen software, ni herramientas o métricas complicadas. Hay que mantener todo simple.

11: Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

El equipo se organiza para, en conjunto, aplicando su experiencia, conocimientos y habilidades, obtener el mejor producto posible. En un equipo interdisciplinario el intercambio de ideas lleva a un análisis de la solución desde diferentes ángulos.

12: A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Una actividad muy relevante para el equipo para mantener una mejora continua iteración tras iteración. Revisar en forma periódica cómo ha sido la ejecución de las actividades, mejorar y tomar acciones, no hay que esperar a la conclusión del proyecto.

¿Qué tan ágil eres? - Participación del cliente

Sat, 20 Jun 2015 18:03:42 -0500

Como les decimos a nuestros clientes, la base de la agilidad es la participación del usuario en el equipo, y debe ser una participación activa. Nuestro equipo no debe decidir o pensar por él, ni en el mejor de los casos podemos ponernos en sus zapatos por mas buenas que sean nuestras ideas. Sabemos que tener al cliente es bastante complicado, aún y cuando, el será uno de los principales beneficiados del producto. La realidad es que no somos la única prioridad en su día, tiene una empresa, un departamento o un equipo que sacar adelante, con todos los retos que esto implica. ¿Qué hay si no podemos contar con el usuario?, ¿Cuáles son nuestras opciones? Para obtener los resultados que el cliente espera debemos de contar con alguien lo mas cercano o parecido a él, que tenga el conocimiento del negocio que necesitamos, la experiencia y el poder de decisión. ¿Por qué es importante? Razones hay muchas, entre ellas: La necesidad y los requerimientos están claros, los requerimientos son priorizados de acuerdo a las necesidades del negocio, nos puede resolver dudas en el día a día, no una semana después (comunicación cara a cara), nos mantenemos en el camino de desarrollar el producto correcto, participa en el progreso, en las reuniones y revisiones, es parte del equipo y comparte responsabilidad. Por mas experiencia que tenga nuestro equipo, que tenga las mejores ideas, las mejores intenciones, si no es nuestro producto, no podremos suplir el conocimiento y la necesidad real que tiene el cliente al querer desarrollar su producto. El tiene el conocimiento y la visión de hacia donde quiere llevar su negocio.

Garantizando la Calidad del Producto

Thu, 22 Jan 2015 00:55:52 -0600

Una de las ventajas de utilizar Scrum, es que la calidad del producto resultante mejora, ¿Porqué decimos esto?. Aún y cuando utilicemos Scrum sin el apoyo de herramientas o técnicas sofisticadas, tenemos durante el proceso de desarrollo, diferentes oportunidades de ir inspeccionando y monitoreando la calidad de los productos que vamos generando. A continuación destacamos algunas de ellas.

Planeación – A través de la interacción del equipo analizando los diferentes requerimientos y características de los productos para lograr la mejor solución, así como identificar la necesidad de información.
Reunión diaria – En esta actividad tenemos oportunidad de retroalimentar sobre el producto y de adaptarnos a lo que vamos encontrando en el día a día.
Trabajo realizado – (Work Done) cada miembro del equipo tiene la información y conocimiento para considerar que el trabajo realizado está hecho, es decir, que cumple con cada uno de los requisitos y criterios establecidos.
Retrospectiva – El equipo identifica buenas prácticas y oportunidades para mejorar en el siguiente ciclo.
Demo – Tenemos la retroalimentación de que lo que estamos construyendo es lo que él negocio necesita. Identificamos ajustes y replanteamos necesidades.

Cada una de las actividades anteriores da al equipo, y al dueño del producto, la oportunidad de ver sí están construyendo el producto correcto, de la manera correcta, desde el primer ciclo. Al final de cada iteración o Sprint, adaptarse según se vean los resultados.

Photo by John Schnobrich on Unsplash