|
Lima Agile Day 2009 fue un éxito gracias a ustedes |
|
Escrito por Deusdit Correa
|
|
Domingo 19 de Abril de 2009 13:56 |
|
La comunidad Agile Perú agradece a todas las personas que asistieron el día de ayer al Lima Agile Day 2009 pues con su asistencia y participación lograron que este nuestro primer evento haya sido un éxito.
Aquí hay un reportaje muy interesante del evento, cortesía de Christian Palomares: Lima Agile Day 2009 En los próximos días estaremos comunicando la publicación de las presentaciones, las respuestas a todas las preguntas asi como el resultado del Retrospective Meeting... esten atentos!
|
|
Ultima actualizació Viernes 19 de Junio de 2009 05:06 |
|
Escrito por Gustavo Quiroz
|
|
Jueves 05 de Febrero de 2009 01:55 |
|
[ACTUALIZACIÓN: La fecha confirmada del evento es el Sábado 18 de Abril de 2009] La comunidad Agile Perú los invita al Lima Agile Day 2009. Este evento está dirigido a todos aquellos interesados en conocer y entender cómo aplicar las llamadas Metodologías Ágiles de Desarrollo de Software (tales como Scrum y Extreme Programming) de boca de algunos de sus más fervientes practicantes en nuestro país. Acompáñanos a intercambiar conceptos, experiencias y buenas prácticas relacionadas a esta nueva manera de desarrollar software que tanta conmoción está causando en el mundo entero por los beneficios obtenidos mediante su aplicación: mejoras drásticas en tiempos de entrega, calidad, trabajo en equipo y satisfacción de los usuarios. Fecha: Sábado 18 de Abril de 2009
Hora: 8:30 am a 1:00 pm
Lugar: Auditorio Cibertec, Av Salaverry 2255, San Isidro Agenda: - 8:30 - Registro
- 9:00 - Presentación del Evento
- 9:20 - Scrum, una nueva forma de desarrollar software (Deusdit Correa)
- 10:05 - ¿Qué es y qué no? Scrum Master y Product Owner (Raúl Uribe y Gustavo Véliz)
- 11:00 - Fundamentos de la Agilidad: Gente y Colaboración (Gustavo Quiroz)
- 11:45 - ¿Por dónde comenzar? - Primeros pasos aplicando técnicas ágiles (Abner Ballardo)
- 12:25 - Retrospectiva y Cierre del Evento
INGRESO LIBRE (capacidad 150 personas)
IMPORTANTE: Aquellos que no alcanzaron cupo en el registro, asistan lo más temprano posible porque tendrán que registrarse en la entrada y la capacidad es limitada. Aquellos que sí alcanzaron registro, ingresarán directamente al evento. Esperamos contar con tu participación! Auspiciado por:  
|
|
Ultima actualizació Viernes 19 de Junio de 2009 05:06 |
|
Experiencias con Scrum: Requerimientos |
|
Escrito por Gustavo Quiroz
|
|
Lunes 26 de Enero de 2009 23:54 |
Algunos piensan que ser ágil quiere decir que no se tienen requerimientos escritos, que toda la comunicación entre usuarios/clientes y desarrolladores es verbal y que si no están usando User Stories, no se puede hablar de desarrollo ágil. Bueno, tengo que discrepar de estas tres creencias.
Hablaré en el contexto de un proyecto que desarrollamos, el cual consistía en construir una aplicación para una entidad del sector financiero. Esta entidad, como muchas otras similares, tiene procesos un tanto rígidos (por no decir burocráticos ni pesados) que guían sus proyectos de desarrollo.
Cuando iniciamos el proyecto, nos fue entregado un documento de casi 150 páginas en donde se describían en detalle requerimientos, mediante especificaciones de casos de uso y pantallazos de un prototipo previamente construido. ¿Qué hacer en estos casos?
El principio básico en todo esto es algo que les sonará familiar a muchos: LA COMUNICACIÓN. Es decir, debe existir un entendimiento común entre aquéllos que desean resolver un problema (usuarios) y aquellos que pueden resolver el problema (desarrolladores).
Para lograr ese entendimiento debe existir un canal amigable entre ambos frentes. En nuestro caso, lo que hicimos fue acordar reuniones dos veces por semana entre nuestro equipo y los analistas del cliente para conversar acerca del documento de requerimientos. Teníamos como objetivos:
- Compredener de qué diablos trataba la lógica de negocio a un nivel suficiente para que uno de nosotros actuara como Proxy del Product Owner en nuestras reuniones de planeamiento.
- Poder definir un Product Backlog en base a este documento.
- Priorizar el Product Backlog con los representantes del cliente.
El Analista Funcional del cliente se convirtió, casi sin darse en cuenta, en nuestro Product Owner y acompañó a nuestro equipo a lo largo de todo el proyecto, estando siempre dispuesto a absolver dudas y repriorizar ítems, cuando fuera necesario.
Aquí un punto clave es descomponer los casos de uso para poder llegar a un nivel de granularidad suficiente que permita planificar los ítems del Product Backlog dentro de cada iteración o sprint. La técnica que usamos fue considerar a cada escenario como un requerimiento o ítem distinto. Por ejemplo, si hablamos de un mantenimiento de países, los ítems (o stories) serían:
- Consultar países por nombre
- Consultar países por código internacional
- Crear país
- Modificar país
- Inactivar País
- Reactivar País
Otro punto importante son las demos o reviews del producto que se realizan al finalizar cada iteración. En nuestro caso, además de los analistas del cliente y de nuestro equipo, participaban los usuarios finales de la entidad financiera. Como es normal, al interactuar o apreciar el incremento de funcionalidad que se está presentando, a un usuario se le van a ocurrir muchas ideas de cómo mejorar o cambiar el producto. Es básico el poder manejar su expectativa y guiarlo sobre cuáles se van a poder incorporar y cuáles no (por razones de tiempo, costo y/o complejidad).
Lo que hicimos nosotros fue recoger todas las sugerencias e ideas, para posteriormente (o a veces durante la reunión misma) conversarlas con nuestro Product Owner. Aquellas que el equipo consideraba sencillas las incorporamos sin ningún problema. Pero aquéllas que se estimaba iban a tomar más tiempo, quedaron en el tintero para futuras versiones del producto. |
|
Ultima actualizació Martes 27 de Enero de 2009 00:06 |
|
|
|
|
|
JPAGE_CURRENT_OF_TOTAL |
