El libro "El ágil brillante. Gestión de proyectos flexible con Agile, Scrum y Kanban »

¿Qué es la gestión flexible de proyectos?

¿Tu proyecto lo necesita?

¿Habrá algún beneficio de esto?

¿Desea comprender cómo funciona la gestión flexible de proyectos y adoptar este poderoso enfoque? Entonces has elegido el libro correcto.

"Brilliant Agile" no es solo otra historia sobre métodos y procesos, sino que se centra en ejemplos de la vida real del uso de Agile en entornos empresariales.

Aquí encontrará consejos prácticos y técnicas específicas de implementación ágil para que su proyecto sea un éxito e implementar una administración flexible en su organización.

Sobre los autores

Rob Cole es consultor de gestión de proyectos con más de 20 años de experiencia. Se especializa en proyectos de resolución de problemas y tutoría. Rob ha estado involucrado en la comunidad Agile desde los primeros días y es un Scrum Master practicante.

Edward Scotcher es Gerente de Producto, Gerente de Proyecto, Entrenador y Coach Agile. Se especializa en ayudar a organizaciones, equipos e individuos a adaptar Agile para un uso práctico y a largo plazo.

PRÓLOGO DEL EDITOR CIENTÍFICO

Cuando me ofrecieron revisar este libro, me sentí muy feliz porque siempre me alegraba cualquier oportunidad de apoyar el desarrollo de Agile fuera de una aplicación de TI. Y esto es exactamente lo que hace este libro.

Ella:

• sobre el muy ágil del que todos hablan;
• Necesidad de aquellos que no saben nada acerca de Agile y realmente quieren familiarizarse con estos enfoques;
• escrito por adherentes absolutos de enfoques flexibles;
• escrito en el estilo ágil (los autores usan imágenes, ejemplos e ilustraciones muy interesantes, que rara vez se encuentran en la literatura académica);
• adecuado para lectura y aplicación universal;
• No contiene el lenguaje y la terminología que nos asusta en la literatura técnica de TI, y es fácil de leer.

Recibirá respuestas a una serie de preguntas:

• ¿Qué es la gestión flexible de proyectos y le beneficiará?
• ¿Cómo beneficiarse del uso de Agile?
• ¿Qué métodos y procesos se ejecutan en Agile?
• ¿Su organización o proyecto es adecuado para usar Agile?
• ¿Cómo resolver los problemas más comunes asociados con Agile?

¿Y cómo, al final, implementarlo en cualquier proyecto?
Recomiendo sinceramente Brilliant Agile para leer y usar. Es una pena que no tuviera ese libro en mis manos hace unos cinco años, cuando comencé a usarlo todo en mi trabajo ...

Funtov Valery Nikolaevich
e. N., PMP, entrenador y entrenador ágil

PASAJE PROYECTO FORMACIÓN DE EQUIPO

Muchas personas reúnen diligentemente a las mejores personas que pueden encontrar en un equipo, profesionales con experiencia relevante, expertos en su campo, y luego estropean todo sin proporcionar una comprensión adecuada de los negocios y el liderazgo. ¡No pongas el carro delante del caballo! Es importante lograr el nivel adecuado de participación empresarial en el proyecto: incluir a una persona que comprenda la visión del negocio. Esto no solo es práctico y pragmático, sino también lógico desde el punto de vista del sentido común.

En Agile, a esta persona generalmente se le llama el "Propietario del producto", pero hay variaciones del nombre. Por supuesto, en este brillante libro debería llamarse el "gerente de producto", pero para empezar nos detenemos en una definición simple. El propietario del producto representa los intereses de la empresa y el usuario final. El propietario del producto vive, respira y sueña con el producto y cómo debería ser. Estas personas saben exactamente lo que quieren, incluso si no saben cómo lograrlo. Son líderes que pueden tomar decisiones rápidamente y defenderlas.

Un equipo ágil es un grupo diverso y multifuncional de personas capaces de traducir una visión en nombre de una empresa. En pocas palabras, tienen todo para hacer el trabajo correctamente. El propietario del producto indica el camino solo en términos de visión empresarial, pero esta es una gran contribución al trabajo del equipo. El equipo está formado por personas con pensamiento flexible, sin miedo al cambio y sin creer que la burocracia es la solución a todos los problemas. Los tomadores de decisiones seguros, las personas activas proactivas funcionarán mejor.

Todo el equipo debe participar en la definición de la visión y todos los aspectos relacionados con el lanzamiento del producto. Si no lo hace, surgirán dificultades.

CREANDO UNA REVISTA DE REQUERIMIENTOS

Cuando se define la visión y los beneficios que debe aportar el proyecto, el siguiente paso para el equipo del proyecto es anotar los requisitos en posibles detalles. En el centro de cada proyecto hay una lista de requisitos, que en Agile se denomina registro de requisitos del producto, o backlog (Product Backlog). Reemplaza los términos de referencia tradicionales y detallados y es una lista de ideas de negocios importantes. Los elementos de la revista siempre se centran en el usuario final del producto, incluso cuando se trata de la parte técnica del proyecto. Deberían ser claros para cualquiera.

Es importante que desde el principio el equipo del proyecto desarrolle una visión colectiva para asegurarse de que todos entiendan los objetivos, el contenido del proyecto y cómo conceptualizarlos. Asegúrese de que todo esté en la misma longitud de onda desde el principio, es más fácil que tratar de arreglar un producto listo para dos tercios más tarde. La diversidad del equipo también es importante porque es importante poder ver el problema desde diferentes ángulos. Si es necesario, los especialistas se ayudarán mutuamente.

Cómo hacer que las cosas salgan mal desde el principio

• Declare que Agile es una herramienta universal, incluso para áreas no destinadas a ella.
• Decir que todo es obvio aquí y que cualquier tonto puede manejarlo, por lo que no se necesita capacitación.
• Cree que Agile es infalible y que el fracaso se debe a fallas personales.
• Establezca objetivos y plazos poco realistas, justificando esto con el hecho de que todo es posible en el valiente mundo nuevo de Agile.

Definir funcionalidad básica

El objetivo es compilar una lista de lo que se necesita para traducir la visión del proyecto. Hay varias formas de hacer esto, y nuestro enfoque favorito es pensar en cada paso del cliente para planificar su flujo de trabajo .


Crea grupos funcionales

Una vez que el flujo de trabajo está definido o compilado, reúna todas las ideas sobre lo que debe hacerse en cada paso del camino. Tal agrupación de estos elementos proporciona una descripción de la funcionalidad del paso y puede denominarse grupos funcionales. Algunos detalles serán absolutamente necesarios, mientras que otros pueden atribuirse a la categoría de adiciones agradables. Deben ordenarse desde el principio.


Características de prioridad

Con base en la visión del proyecto y el sentido común, determine la prioridad de cada elemento en orden descendente, de lo más importante en cada lista.


Definición del primer problema

Una vez hecho lo anterior, considere cada paso importante para avanzar hacia el cliente desde el primer día hasta la implementación y cuál es la parte más valiosa de la idea en estos pasos. Tal elección puede ser difícil y, en última instancia, depender de la opinión, pero la opinión del cliente, o el que representa a su negocio, tiene un papel decisivo. El resultado final de los pasos es el mínimo aceptable para el cliente que el proyecto debe lograr en este paso. Esto generalmente se llama un producto mínimo viable (MVP) o una versión mínima viable (MVR).


Una de las grandes ventajas es la rápida recepción de comentarios importantes de los usuarios finales, sin embargo, para formarse una opinión, necesitan algo bastante sustancial. Es imposible obtener comentarios significativos sobre el proceso técnico, pero el nuevo formulario de pedido de VegBox está completo. Naturalmente, esto será parte de un producto mínimamente viable.

Vale la pena recordar que cuanto más haya en un producto mínimamente viable, más tiempo llevará obtener comentarios, mientras que si el producto es demasiado pequeño, no habrá suficiente información para recibir comentarios. Tendrá que encontrar un equilibrio entre beneficio y riesgo: aquí no existe una regla universal. Intente encontrar un punto en el que reciba comentarios útiles sobre algo que lo ayudará a tomar decisiones informadas. Esto será útil para el análisis de mercado.

También preste atención a los términos. Para algunos, la palabra "lanzamiento" significará un producto disponible para su uso, para otros, un producto destinado a ser probado por un grupo cerrado. Recuerde que siempre existe la oportunidad de presentar primero el producto a un grupo pequeño, y solo luego lanzar el producto en consecuencia. Lo más importante, ¡no asuma que todos entienden los términos de la misma manera! No hay enfoques absolutamente correctos: elija el que más le convenga.

Agregar funciones

Una vez que se determina lo que sucederá en un producto mínimo viable (MVP) o en una versión mínima viable (MVR), comienza la verdadera diversión. Se pueden agregar funcionalidades adicionales o nuevas características del producto en partes o ser parte de una versión más grande. Esto se llama entrega incremental, y los empresarios lo aman mucho. No más largos años de espera de un gran lanzamiento con todas las campanas y silbatos. El lanzamiento ágil del producto es rápido y frecuente. Y, nuevamente, es el cliente quien determina qué y cuándo lanzar. Como mínimo, un solo problema debe contener una característica que haya sido probada por la práctica.

OBTENER INFORMACIÓN

Los resultados de nuestro primer lanzamiento, nuestro MVP, son lo suficientemente efímeros y necesitamos más detalles para convertirlos en un producto completo. El beneficio de estos resultados es que en esta etapa formulamos ideas, por lo que no tendría sentido desarrollar un perfil de producto completo, que no necesariamente se utilizará. Es más que suficiente desarrollar una visión común y formular un MVP, sin darse cuenta del producto en sí. En la siguiente etapa, tenemos que descubrir los lados positivo y negativo del producto. Una herramienta clásica para resolver este problema es una historia de usuario.

Cuentame una historia

Las historias de usuario son descripciones breves y simples de las características de un producto desde el punto de vista de la persona que lo va a usar. Esto suele ser un usuario o comprador. Las historias de usuarios suelen seguir un formato simple.
Siendo <tipo de usuario>, necesito <objetivo> para <razón>.


Una historia de usuario es un concepto abstracto que proporciona suficiente información para que un equipo pueda evaluar de manera realista los recursos necesarios para implementar un proyecto. Las historias de los usuarios a menudo se graban en pegatinas o tarjetas, que luego se cuelgan en las paredes o se colocan en mesas para facilitar el proceso de planificación.

La historia del usuario le permite centrarse en la discusión de las características del producto, que es un paso importante después de desarrollar una idea básica de estas características.

Nadie te obliga a usar historias personalizadas. Sin embargo, estas historias nos recuerdan la importancia de las discusiones colectivas, y los resultados de estas discusiones colectivas son a menudo más importantes que un plan de trabajo detallado.


Durante estas discusiones, se identifican aspectos clave de las características más importantes del producto. Recuerde, las grabaciones en sí mismas no significan nada, pero la comunicación colectiva animada nos permite no solo desarrollar los detalles fundamentales, sino también mantener una nueva visión del proyecto. Ganar en todos los sentidos.

»Se puede encontrar más información sobre el libro en el sitio web del editor
» Contenidos
» Extracto

20% de descuento en cupones para Agro-Agentes - Agile