• Author / Uploaded
• Michael Silva

Citation preview

AGILE INCEPCION MANIFIESTO ÁGIL

Individuos e interacciones es lo más importantes para lograr la SINERGIA: acción conjunta de varios componentes para lograr una acción. Colaboración con el cliente genera mayor satisfacción comparado con otras metodologías. Un Webinar es un vídeo-seminario o vídeo-conferencia Online que se realiza a través de un Software y que te permite impartir una clase a través de Internet. Antes de desarrollar el a.i, es necesario haber recopilado requisitos, y haber generado una idea clara de lo que vamos a entregar (enunciado del alcance), donde solo participó el DP en ayuda de alguien experto del tema.

AGILE INCEPTION (SPRINT 0) Prolijo: con mucho detalle Ejmp: Mike es PM y su jefe le manda a estudiar scrum por su jefe. Decide hacer proyecto piloto. Está en pánico por que no sabe muchos términos y ya convocó a reunión de su primer sprint. Sensei le dice que hay mucho que hacer antes de hacer el primer sprint. Nos permitirá tener un equipo bien alineado y un BACKLOG inicial. Todo empieza por un WHY. ¿Por qué estoy en este proyecto?

El éxito o fracaso del proyecto es esfuerzo de TODOS, peo responsabilidad es del dp.

1. ¿Para qué estoy acá? Juntarse con el equipo para entender el porqué del proyecto. Ejm: ayudar a reducir el índice de criminalidad de la ciudad. Cada uno escribe el por qué, y agrupamos los que son similares y debatimos los disímiles. Objetivo es tener claro el problema que queremos resolver. ¿Por qué hacer este proyecto?

2. Generar una visión del proyecto (elevator pitch). Usamos el

product

vision board. Por qué, para quién, y qué valor aportamos desde el inicio. a. Codename: ejmp: el panda (itnerfaz blanco y negro), la chela (camping), el XVIDEO, el PACK.

b. Frase rep. Ejmp: “Buscamos bajar el índide ce criminalidad de la ciudad” Algo que nos relacione con el proyecto y por qué se está haciendo. “Buscamos desnudar nuestra casa matriz para que todo el mundo nos conozca” c. Grupos de usuario (las que usarán el producto): para quién estamos haciendo el proyecto? A quién le llegará. Ejmp: personas que les interesa la dirección de proyectos, empresas, grupos estudiantles. d. Necesidades. Las que posean los grupos de usuario. Ejmp: No nos conocen., no saben lo que hacemos. AQUÍ SE ENCUENTRAN LAS RAZONES DE SER DEL PROYECTO. e. Producto: ¿Qué características de mi producto satisfacen las necesidades de los usuarios? f. Valor: ¿Qué valor le genera a la organización la satisfacción de la necesidad del grupo de usuarios a través del producto?

Lo mismo también para el codename.

Hacer el elevator pitch es opcional: Es nuestra carta de presentación que se dice en 20 segundos. Se hace luego del product vision board.

HAY QUE ENTREGAR EXPERIENCIAS (a todos, al jefe, usuario, equipo de trabajo). “Oye yo tengo una aplicación que es genial” vs “Tengo una aplicación que me hace genial”.

3. In/Out (cosas que no se van a hacer) Lo que sí vamos a hacer (lo que vamos a resolver con nuestro producto), lo que no vamos a hacer (lo que no vamos a resolver con el producto).

No se podrá pagar por medio de nuestra app.

4. Conoce a tu vecindario Todo está centrado en personas, en experiencias.

No ofrecer cosas que el proyecto no tendrá. Hacer que participen. Nadie nos estorba. Todos son importantes. Viable, deseable, factible: triángulo del design thinking. No tener miedo a equivocarnos! Aprender de ello.

5. Conceptualizar la solución No es avance, sino son diagramas, maquetas, estructuras; identificando riesgos (tecnológicos, humanos).

6. Los riesgos ¿Qué nos mantiene despiertos en las noches? Cosas que no me dejan dormir: riesgos potenciales. No pasa nada decir nuestros miedos, cosas que pienso que puedan salir mal. “Ese proyecto está genial, pero no creo que sea algo que a la gente le gusto por A, B C”. Aterrizar todo. Colocamos nuestros riesgos favoritos y priorizamos (tipo PRE BACKLOG, pero en riesgos).

7. Elaborar estimaciones iniciales No hay proyecto que se ajuste 100% al plan. Las cosas cambian! Cada persona es un sistema, y trabajar con personas complejos es muy difícil. Tener un inicio de proyecto adecuado. 8. Trade on/off

Las 4 primeras son las más interesantes/furiosas. La más azotada es la calidad, siendo la más importante en un proyecto. Tiene que haber restricciones, sino gastamos nuestros recursos :/ Tiempo: Tienes 4 semanas para entregarme un PMV!

8. Demuestra lo que implica Determinar costos, personas, tiempo empleado.

Es un estimado. No está firmado con sangre. No existe plan de trabajo, estimado, que se cumpla.

Diez pasos para definir claramente el proyecto. Libros: Agile Samurai.

Ahora ¿CÓMO DEFINIR EL BACKLOG? Usamos técnica PERSONAS (usuarios)

Hacemos cuadro Nombre y foto: la creamos nosotros.

Ejmp de software d seguridad: por qué zona vive, qué transporte toma, es estudiante, etc. Puede haber varios tipos de personas. Necesidades: Que tiene esa persona que haría usar (comprar) nuestro producto. Es más específico que el product visión board. Son personas que existen en la realidad. Estereotiparlos. Ahora seguimos con la siguiente técnica colaborativa (para generación del backlog):

STORY MAPPING Requiere un espacio muy amplio. Se puede hacer en pared y conservarlo allí, o generar un tablero froan board portátil. User Story Map es una herramienta que permite generar una representación visual de la sistema completo. Ofrece una vista general de todas las funcionalidades que lo componen (the big picture) de punta a punta. ¿Cómo se construye? Para la construcción resulta fundamental pensar todo el proceso desde el punto de vista del usuario y sus objetivos con nuestro sistema; nunca desde el lugar de Product Owner o de quienes construimos el producto u ofrecemos el servicio. 1. Backbone: Identificar las grandes etapas en las que se divide nuestro sistema/proyecto/servicio/producto. Por ejemplo, en un sistema de venta

online, podría ser: llegada al website, búsqueda de producto, compra/pago y entrega.

Recepción, dictar ponencia/taller, break, cierre. 2. Activities: Identificar todas las actividades que debe o puede realizar el usuario en nuestro sistema, desde que llega al mismo hasta que finaliza su proceso. Ordenarlas de manera secuencial de manera horizontal. Esta secuencia conforma la cadena de valor de nuestro sistema (Value Stream). Llegar a auditorio, registrarse, ubicarse en lugar, escuchar ponencia, comer break, reanudar ponencia, tomar foto final, obtener certificado. Se puede confundir backbone con activities (lo que usuario hará), es más fácil definir las activities y luego las clasificamos por semejanza (backbone). 3. User Stories: Identificar las distintas maneras que nuestro sistema puede ofrecer para que el usuario realice cada una de las actividades identificadas. Por ejemplo, para la actividad "encontrar producto" podría ser: navegar el catálogo, usar el cuadro de búsqueda, sugerencias de productos, etc. 4. Priorización: Cada columna debajo de cada Activity funciona como un backlog que debe estar priorizado por relevancia. Para la priorización debemos utilizar el criterio de MoSCoW (Must Have, Should Have, Could Have). De manera que la funcionalidad más elemental (user story), que no puede faltar debe estar primera. Es para un usuario en específico. En este caso es para el más importante. The Walking Skeleton Con las activities y la primera fila de User Stories obtenemos lo que Jeff Patton denomina "The Walking Skeleton" (el esqueleto que camina) porque está completo y funciona, aunque sea en su forma más elemental. Nuestro producto en este estado puede ser identificado como la versión MVP (Minimum Viable Product). O como él lo llama, MMF (Minimum Marketable Feature).

Múltiples Usuarios Qué sucede cuando nuestro producto hay más de un usuario? Es muy probable que cada tipo de usuario tenga su propia secuencia de actividades. Un Story Map debe representar a un solo flujo de usuario. Únicamente en el caso donde la diferencia es muy leve y no se justifique crear otro Story Map, se podría identificar con código de colores las actividades del usuario secundario.

Solo actividades! Incluimos personas ¿Qué personas se involucran en qué actividades (ejmp ponencia: entrar a UNT, caminar a auditorio, registrar asistencia, ubicarse en lugar, escuchar ponencia, comer break, reanudar ponencia, cerrar ponencia, tomar foto final, entregar certificado, llenar encuesta) y qué funcionalidades (opciones que ofreceré en mi producto/servcio) les vamos a proveer a esas personas para que las puedan cumplir? Priorizamos personas.

Formas alternativas de hacer las cosas: travesía.

Ejmp: 3° actividad es: HACER PAGO

Primera funcionalidad de P1: pago por visa. Travesía de la misma persona para misma actividad: pago por paypal.

Son esas tareas de las personas las que serán transformadas en una o varias funcionalidades del backlog. Podemos identificar nuestro Producto Minimo Viable.