Agile Methodology

Metodología ágil de desarrollo de software (definición y principio de ágil) – Yodiz Project Management Blog


 Metodología ágil de desarrollo de software (definición y principio de ágil)

Cuando se trata del desarrollo de software (SW), existen muchos marcos y metodologías para la gestión inteligente. Algunos de estos marcos son scrum, kanban, XP, TDD, FDD DDD, etc.
Cada uno de estos marcos y metodologías tienen sus propios pros y contras en función de la naturaleza del proyecto al que se aplican. Sin embargo, la gestión ágil de proyectos es una metodología relativamente nueva que se centra en la transparencia, la priorización, el ciclo de retroalimentación breve, la inspección y la adaptación. Las otras metodologías conocidas son la cascada, prototipos, desarrollo iterativo e incremental, desarrollo en espiral, programación extrema, etc.

El significado común de Agile es "capaz de moverse rápida y fácilmente". Es una metodología de programación para hacer el trabajo de manera fácil y conveniente. Es muy útil para completar proyectos de mayor alcance. Es un proceso serializado de entrega de producto al propietario en lugar de entregarlo después de su finalización.

2.1 ¿Qué es Agile Really?

Agile puede considerarse una metodología de desarrollo SW, conjunto de procesos, principios o modelo para promover una mejor planificación , evaluación del desarrollo, entrega puntual, mejora continua y respuesta temprana al cambio. Agile simplemente proporciona un marco de trabajo originalmente nunca estableció métodos para lograr esto, pero con el tiempo muchos framework o agentes de cambio se desarrollan en la forma en Scrum, XP, Kanban, Scrumban, etc.

Agile es un método repetitivo y adicional para administrar el diseñar y desarrollar Su objetivo es ofrecer los nuevos servicios o desarrollo de productos de una manera altamente flexible y común.

2.2 Orgánica de Agile y su manifiesto

El origen de Agile se remonta a Agile Manifesto, mientras que Agile comenzó como proceso de desarrollo de SW. Sin embargo, ahora se adopta en otras industrias como marketing, ventas, soporte, banca y producción. Los marcos conocidos de la metodología ágil son Scrum, Kanban, XP, etc.
El manifiesto ágil describe 4 valores importantes que son relevantes en todos los proyectos de cualquier tamaño y tipo. Consulte nuestra ágil infografía de manifiesto en su 15 aniversario, que estaba en curso. 11 de febrero de 2016.

  • Individuos e interacciones sobre procesos y herramientas.
  • Software de trabajo sobre documentación completa.
  • Colaboración con clientes sobre negociación de contratos.
  • Respondiendo al cambio sobre seguir un plan.

2.3 Por qué ágil ?

  • Identificar las dificultades, las hace visibles
  • Adoptar el cambio
  • Planificar, pero siempre tenga en cuenta que los planes detallados siempre son incorrectos
  • Mejorar los ciclos de retroalimentación
  • En caso de falla, el impacto ser muy leve, es decir, el impacto será solo en ese segmento específico del proyecto.

2.4 Historia Agile

  • 1993: Primer equipo Scrum creado por Jeff Sutherland
  • 1995: Scrum formalizado por Jeff Sutherland y Ken Schwaber
  • 2001: Primer libro de Scrum de Ken Schwaber y Mike Beedle (Desarrollo de software ágil con SCRUM)
  • El manifiesto ágil fue presentado por 17 desarrolladores de software reunidos en Snowbird Resort en Utah en febrero de 2001.

3.1 ¿Qué es? scrum?

Scrum es un proceso iterativo e incremental para desarrollar cualquier producto o administrar cualquier trabajo. Produce un conjunto de funciones potencialmente realizables al final de cada iteración.

Scrum es uno de los marcos para implementar Agile. En el scrum, todo el equipo de desarrollo trabaja como jugadores de rugby "juegan con el entendimiento mutuo". El equipo de desarrollo de software toma decisiones mutuas para resolver errores y otros problemas en desarrollo.

3.2 Scrum se basa en los siguientes principios

  • Transparencia
  • Priorización estricta
  • Breve retroalimentación
  • Publicaciones frecuentes y regulares [19659010] Mejora continua
  • Equipo autoorganizado
  • Timeboxing
  • Comunicación cara a cara
  • 4.1 El producto o proyecto se divide en pequeños casos de uso denominados historias de usuarios.
  • 4.2 La ​​acumulación de Producto es una colección de historias de usuarios. El propietario del producto es el propietario y responsable de priorizar la historia del usuario según el valor comercial o la solicitud del cliente.
  • 4.3 Scrummaster es responsable de las reuniones de planificación de sprints.
  • 4.4 Durante Sprint planning product owner explica la historia del usuario junto con los criterios de aceptación para el equipo, una vez entendido y estimado por el equipo, se mueve al backog sprint. El propietario del producto sigue proponiendo la historia del usuario para esprintar, durante la planificación del sprint, hasta que el equipo se agote su capacidad.
  • 4.5 Cuando las historias de los usuarios se mueven al sprint, se llama acumulación de sprint. [19659010] 4.6 Tres son cuatro roles principales en el equipo de scrum. El equipo es idealmente funcional
  • Propietario del producto
    Scrum master
    Scrum Team.
    Stakeholder.

  • 4.7 El equipo de Scrum inicia sprints en el time-box, que dura de semanas a un mes, dependiendo de la duración del sprint. El equipo de Scrum se compromete con las historias de los usuarios durante el sprint, que se basa en la velocidad promedio del equipo
  • 4.8 El equipo comienza a trabajar en las historias de los usuarios y las divide en tareas.
  • 4.9 Las funciones del propietario del producto es interactuar con el cliente y decide qué trabajo se debe hacer primero.
  • 4.10 Scrum Master es responsable de ejecutar el sprint y entregar un producto de calidad.
  • 4.11 Scrum Master es responsable de la reunión diaria standup, que dura de 5 a 15 minutos todos los días de pie (scrum meeting).
  • 4.12 Al final de Sprint, demo está organizado, para mostrar lo que se ha logrado durante el sprint, el propietario del producto o el cliente están invitados a esta ceremonia
  • 4.13 La ​​reunión retrospectiva se lleva a cabo al final del sprint para evaluar el rendimiento del sprint completado para identificar brechas El equipo discute qué fue bien, qué práctica continuar y qué mejorar.
  • 4.14 Scrum se enfoca en la colaboración pero no necesariamente significa que más reuniones, reuniones o ceremonias en el scrum se mantienen al mínimo. Hay siguientes reuniones en scrum, que son: planificación de Sprint, scrum diario, demo de sprint y retrospectiva.
  • 4.15 Luego, todo esto vuelve a empezar desde el backlog: Prioritization => Sprint Planning => Running Sprint in Time- box => Daily Scrum => Sprint Demo => Retrospectiva.
  • 5. Terminología de Agile Scrum y sus definiciones

    5.1 Historia de usuario

    La historia de usuario es un requisito simple y descriptivo del cliente. la historia del usuario es el artefacto más importante, este es el artefacto con el que su equipo pasó la mayor parte del tiempo, esto también es algo que su equipo analizará para la estimación del esfuerzo. Así que trata de ser lo más detallado posible. Dos y tres líneas de historias de usuarios no tienen mucho sentido.

    Una historia de usuario tiene tres partes, describa su requisito funcional a lo largo de esas líneas.
    Como Quiero
    para que

    5.1.1 Características de una buena historia de usuario en ágil

    Una buena historia de usuario en Agile es una Bien definida, detallada y completa. A veces, una buena historia de usuario también tiene ejemplos y archivos adjuntos como audio, video, imágenes, documentos y diapositivas, etc. Si la historia de un usuario está bien definida, el equipo puede ejecutarla de una mejor manera.

    5.4 Roles en Agile Scrum [19659060] 5.4.1 Propietario del producto

    El propietario del producto es responsable del retraso acumulado del producto y de maximizar el ROI (retorno de la inversión) del producto. Se asegura de que las características correctas lo incluyan en la acumulación de productos y en el sprint. Representa al cliente, describe los elementos atrasados ​​con claridad, mantiene los registros atrasados ​​en buen orden de prioridad y establece la dirección del producto.

    5.4.2 Funciones de Scrum Master

    El maestro de Scrum es responsable de supervisar los procesos de scrum y scrum meetings . Su trabajo es asegurarse de que el sprint entregue los entregables de calidad a tiempo y se resuelvan todos los impedimentos.

    5.4.3 Scrum Team

    El equipo de Scrum es responsable de una salida de software de trabajo mejor y más económica. Es un equipo autoorganizado, multifuncional, de 5-7 personas. El equipo de Scrum tiene desarrolladores, programadores, Scrum Master, diseñador de UI / UX, analista, DBA e ingenieros de control de calidad.
    Desarrolladores desarrollan el programa, scrum master supervisa el programa, diseñador de UI / UX diseña interferencia del usuario, programa de análisis de analistas y probadores pruebe el programa para asegurarse de que el producto de salida funcione correctamente.

    5.4.4 Stakeholder

    El Stakeholder es un cliente o un patrocinador del proyecto.

    5.5 Sprint Planning Meeting

    Los participantes de Sprint Planning Meeting son el maestro de Scrum, el propietario del producto y el equipo de scrum. Scrum master ejecuta la reunión, la duración promedio de la reunión de planificación de sprints es de 2 a 4 horas.

    5.6 Product Backlog

    La cartera de pedidos del Producto es una lista de deseos que el propietario del proyecto desea incluir. Es una lista simple de todas las cosas que se necesitan para completar un proyecto.

    5.7 Priorización de backlog

    Historias de usuarios organizadas en una secuencia especial que se denomina priorización de backlog. El trabajo más importante se encuentra en la parte superior de la lista, y el trabajo menos importante se ubica al final de la lista. El propietario del producto agrega el nuevo trabajo en la posición adecuada. Usando este método, el equipo sabe qué trabajo necesita atención inmediata.

    5.9 Puntos de historia

    Puntos de historia representados por el número de Fibonacci. Indica la complejidad relativa de una historia de usuario. No es un esfuerzo estimado en horas. El número en el punto del argumento representa la complejidad.

    5.12 Velocidad promedio

    La velocidad promedio del equipo en el scrum, indica la cantidad de historia del usuario que se puede completar con un scrum durante el sprint. La velocidad promedio es la cantidad que se realiza durante un sprint, el equipo debe completar al menos tres sprints y tomar el promedio de puntos de historia realizados en esos sprints, lo que dará la velocidad promedio del equipo.

    5.15 Burndown Chart

    Burndown chart es lo más importante en scrum. Proporciona una medición día a día de la cantidad de trabajo que queda en un sprint o lanzamiento determinado. Es un gráfico de día por día para verificar el rendimiento del equipo.

    5.16 Levantamiento diario

    La resistencia diaria es un evento de 15 minutos enmarcado en un recuadro. Esta reunión se lleva a cabo todas las mañanas y todos los miembros del equipo se unen a esta reunión todos los días estrictamente. El propósito de esta única reunión de 15 minutos es hacer que el equipo esté activo, pero necesariamente es relevante con el tema. En esta reunión diaria, cada persona es responsable de dar tres respuestas siguientes.

    ¿Qué hice ayer?
    ¿Qué haré hoy?
    ¿Qué es lo que me está frenando, impedimentos?

    5.17 Sprint Demo

    Al final de cada carrera de sprint, se celebra una reunión de revisión de sprint . En esta reunión, el equipo demuestra lo que han logrado durante este sprint.

    5.18 Retrospectiva

    Una retrospectiva ágil es una reunión que se celebra al final del sprint. En esta reunión, el equipo analiza, qué fue bien y qué se debe mejorar.

You Might Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Powered by themekiller.com