El documento describe varias metodologías para el desarrollo de proyectos de software, incluyendo metodologías ágiles y tradicionales. Explica que las metodologías ágiles valoran la interacción entre individuos, entregas funcionales rápidas y respuesta al cambio, mientras que las metodologías tradicionales se enfocan más en la planificación y documentación. También describe dos metodologías ágiles específicas: Scrum, la cual se basa en iteraciones cortas llamadas sprints, y eXtreme Programming, c
Se describen las ventajas, desventajas características de los métodos ágiles, así como los métodos ágiles más utilizados en la actualidad según fuentes consultadas
Se describen las ventajas, desventajas características de los métodos ágiles, así como los métodos ágiles más utilizados en la actualidad según fuentes consultadas
Metodología, roles, actividades y artefactos que componen el modelo de proceso ágil SCRUM en el desarrollo de software y cómo lleva a maximizar el retorno de la inversión en la empresa (ROI).
Presenta las diferentes entre Desarrollo Cascada versus Desarrollo Agile-Scrum, mostrando la manera en la que participa el Testing, más algunos de los procedimientos, prácticas y conceptos principales.
Para mayor información, visitar: http://testingbaires.com/
A continuación, parte del contenido de la presentación.
#Planteo formulado dentro de un grupo de discusión
Generalidades
¿Qué tipo de actividades llevas a cabo bajo este modelo?
¿Qué ceremonias: Daily Scrum Meetings, Sprint Reviews, Retrospectives?
¿Participan con el Product Owner en la User Story?
¿Qué tratamiento le dan al Product Backlog y Sprint Backlog?
¿Participan del Sprint Planning?
¿Tienen un Scrum Master que lo elabora?
¿Estiman el esfuerzo de trabajo?
¿Qué documentan?
¿Elaboran Indicadores y Métricas?
Herramientas
¿Usan herramientas aranceladas? JIRA Agile, JIRA Bamboo, JIRA Zephyt, TFS
¿Usan herramientas open source? Redmine, Testlink, Mantis, Selenium WebDriver, Cucumber, SonarQube
Automatización
¿Ejecutan Automation Testing?
¿Bajo qué tipo de modelo: BDD y/o ATDD, pej?
¿Ejecutan Testing contra Código?
¿Ejecutan Testing contra Servicios?
¿Ejecutan Testing contra Front End?
¿Estiman, documentan, elaboran Indicadores y Métricas?
Planteo por parte de un miembro
En mi trabajo es difícil aún introducir los procesos de Testing en Scrum.
Acá se practica la metodología estrictamente, los sprint son de dos semanas y la documentación es casi nula (no existen los casos de uso, y los documentos de requerimientos son escasos), el tiempo para crear casos de prueba es muy poco por lo que decidimos solo crear los de regresión y dedicar mas tiempo a los Criterios de Aceptación (Definition of Done). Utilizamos Jira pero no solo como bugtracker sino también como pizarra de Scrum donde se encuentran las Historias de Usuario (User Story) creadas entre todo el equipo de Scrum en el Sprint Planning. Por el momento las estimaciones de los desarrolladores para bugfixing nunca alcanzaron, y la verificación de bugs de un Sprint se realizan en el próximo. Para nuevos proyectos vamos a probar con Sprints de 3 semanas: 2 de desarrollo, 1 de Testing y bugfixing, así los desarrolladores podrían liberar funcionalidades mas completas (y testeables), estimar mejor el tiempo de testing (somos abiertos al testing exploratorio) y quedaría tiempo para realizar bugfixing. La verificación de bugs seguiría quedando para el próximo sprint.
Devolución ofrecida
No están siendo ágiles.
Si están realizando el testing fuera de la sprint, no están entregando un producto de calidad.
La idea es entregar un incremento TERMINADO: diseñado, desarrollado, probado.
Lamentablemente, así funcionan muchos equipos actualmente.
Es necesario incorporar el Testing dentro de las iteraciones.
Una experiencia práctica de Scrum a través del aprendizaje basado en proyecto...Sergio Yazyi
Scrum es un marco de trabajo para la gestión ágil de proyectos de creciente interés en distintos campos de aplicación. Para asimilar sus principios y prácticas no basta una formación conceptual sino que es necesario utilizar un enfoque práctico que permita ejercitarlo a través del “aprender haciendo”.
En el presente trabajo se analiza una experiencia de taller en línea, donde se simula la aplicación de Scrum en un proyecto de alcance limitado mediado por TIC con un equipo distribuido. Se fundamentan conceptualmente los distintos elementos que convergen en la misma: la metodología de aprendizaje basado en proyectos, el trabajo en equipo distribuido y el marco de trabajo Scrum. Seguidamente, se presenta el estudio de caso de la experiencia desarrollada extrayendo de la misma un patrón pedagógico en el que se identifican los elementos clave que determinaron su éxito con el fin de facilitar su reproducción.
El resultado de este análisis permitirá apreciar el potencial para trasladar esta modalidad de aprendizaje a otras situaciones con objetivos diferentes pero con igual necesidad de interacción grupal y contexto distribuido, al mismo tiempo que percibir el potencial de Scrum para ser incorporado dentro de una estrategia didáctica de aprendizaje basado en proyectos, por su simplicidad y sus importantes efectos para el aprendizaje en equipo y desarrollo de competencias transversales.
Laboratorio de estrategias creativas.
Una experiencia de metodologías activas de aprendizaje en Bellas Artes. Teresa Marín García.
Poster presentado en: I Jornadas estatales de Aprendizaje Basado en Proyectos – PBL y Metodologías Activas. Donostia-San Sebastián, 11 y 12 de julio de 2011
Metodología, roles, actividades y artefactos que componen el modelo de proceso ágil SCRUM en el desarrollo de software y cómo lleva a maximizar el retorno de la inversión en la empresa (ROI).
Presenta las diferentes entre Desarrollo Cascada versus Desarrollo Agile-Scrum, mostrando la manera en la que participa el Testing, más algunos de los procedimientos, prácticas y conceptos principales.
Para mayor información, visitar: http://testingbaires.com/
A continuación, parte del contenido de la presentación.
#Planteo formulado dentro de un grupo de discusión
Generalidades
¿Qué tipo de actividades llevas a cabo bajo este modelo?
¿Qué ceremonias: Daily Scrum Meetings, Sprint Reviews, Retrospectives?
¿Participan con el Product Owner en la User Story?
¿Qué tratamiento le dan al Product Backlog y Sprint Backlog?
¿Participan del Sprint Planning?
¿Tienen un Scrum Master que lo elabora?
¿Estiman el esfuerzo de trabajo?
¿Qué documentan?
¿Elaboran Indicadores y Métricas?
Herramientas
¿Usan herramientas aranceladas? JIRA Agile, JIRA Bamboo, JIRA Zephyt, TFS
¿Usan herramientas open source? Redmine, Testlink, Mantis, Selenium WebDriver, Cucumber, SonarQube
Automatización
¿Ejecutan Automation Testing?
¿Bajo qué tipo de modelo: BDD y/o ATDD, pej?
¿Ejecutan Testing contra Código?
¿Ejecutan Testing contra Servicios?
¿Ejecutan Testing contra Front End?
¿Estiman, documentan, elaboran Indicadores y Métricas?
Planteo por parte de un miembro
En mi trabajo es difícil aún introducir los procesos de Testing en Scrum.
Acá se practica la metodología estrictamente, los sprint son de dos semanas y la documentación es casi nula (no existen los casos de uso, y los documentos de requerimientos son escasos), el tiempo para crear casos de prueba es muy poco por lo que decidimos solo crear los de regresión y dedicar mas tiempo a los Criterios de Aceptación (Definition of Done). Utilizamos Jira pero no solo como bugtracker sino también como pizarra de Scrum donde se encuentran las Historias de Usuario (User Story) creadas entre todo el equipo de Scrum en el Sprint Planning. Por el momento las estimaciones de los desarrolladores para bugfixing nunca alcanzaron, y la verificación de bugs de un Sprint se realizan en el próximo. Para nuevos proyectos vamos a probar con Sprints de 3 semanas: 2 de desarrollo, 1 de Testing y bugfixing, así los desarrolladores podrían liberar funcionalidades mas completas (y testeables), estimar mejor el tiempo de testing (somos abiertos al testing exploratorio) y quedaría tiempo para realizar bugfixing. La verificación de bugs seguiría quedando para el próximo sprint.
Devolución ofrecida
No están siendo ágiles.
Si están realizando el testing fuera de la sprint, no están entregando un producto de calidad.
La idea es entregar un incremento TERMINADO: diseñado, desarrollado, probado.
Lamentablemente, así funcionan muchos equipos actualmente.
Es necesario incorporar el Testing dentro de las iteraciones.
Una experiencia práctica de Scrum a través del aprendizaje basado en proyecto...Sergio Yazyi
Scrum es un marco de trabajo para la gestión ágil de proyectos de creciente interés en distintos campos de aplicación. Para asimilar sus principios y prácticas no basta una formación conceptual sino que es necesario utilizar un enfoque práctico que permita ejercitarlo a través del “aprender haciendo”.
En el presente trabajo se analiza una experiencia de taller en línea, donde se simula la aplicación de Scrum en un proyecto de alcance limitado mediado por TIC con un equipo distribuido. Se fundamentan conceptualmente los distintos elementos que convergen en la misma: la metodología de aprendizaje basado en proyectos, el trabajo en equipo distribuido y el marco de trabajo Scrum. Seguidamente, se presenta el estudio de caso de la experiencia desarrollada extrayendo de la misma un patrón pedagógico en el que se identifican los elementos clave que determinaron su éxito con el fin de facilitar su reproducción.
El resultado de este análisis permitirá apreciar el potencial para trasladar esta modalidad de aprendizaje a otras situaciones con objetivos diferentes pero con igual necesidad de interacción grupal y contexto distribuido, al mismo tiempo que percibir el potencial de Scrum para ser incorporado dentro de una estrategia didáctica de aprendizaje basado en proyectos, por su simplicidad y sus importantes efectos para el aprendizaje en equipo y desarrollo de competencias transversales.
Laboratorio de estrategias creativas.
Una experiencia de metodologías activas de aprendizaje en Bellas Artes. Teresa Marín García.
Poster presentado en: I Jornadas estatales de Aprendizaje Basado en Proyectos – PBL y Metodologías Activas. Donostia-San Sebastián, 11 y 12 de julio de 2011
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Extreme Programming es una metodología ágil de desarrollo que propone un plan de desarrollo de software de corto plazo permitiendo una mayor interacción con el usuario.
Metodologías de desarrollo ágiles: Scrum, XPejordi
Metodologías de desarrollo ágiles: Scrum y eXtreme Programming.
Treball de l'assignatura Gestió de Sistemes d'Informació (GESI) de la Universitat Politècnica de Catalunya (UPC). Professor: Jordi Esteve. Gener 2009. Vilanova i la Geltrú. Barcelona. Catalunya.
2. ¿Podré cumplir con los
plazos?
¿Estaré dentro de lo
presupuestado?
¿El cliente quedará
satisfecho?
Las Metodologías pueden ser la ayuda que
necesitamos, si podemos usarlas
correctamente !!
4. ¿Qué es una Metodología ...
Las metodologías imponen un proceso
disciplinado sobre el desarrollo de
software con el fin de hacerlo más
predecible y eficiente.
5. Metodología Tradicional
Existen hace mucho tiempo, no han sido exitosas
porque son muy burócratas, se han orientado al
documento más que a los resultados.
6. Metodología Ágil
Son la justa medida entre “ningún proceso” y
“demasiado proceso”, proporcionando simplemente
“suficiente proceso” para que el esfuerzo valga la
pena !!!
8. Las Metodologías Ágiles (AMs) valoran:
Al individuo y las interacciones en el equipo de
desarrollo más que a las actividades y las
herramientas
Desarrollar software que funciona más que conseguir
una buena documentación Minimalismo respecto
del modelado y la documentación del sistema
La colaboración con el cliente más que la negociación
de un contrato
Responder a los cambios más que seguir
estrictamente una planificación
9. Dificultad para implantar metodologías tradicionales.
Una solución a medida para un segmento importante
de proyectos de desarrollo de software
“Aceptar el cambio” ...
10. Tradicionales
Grandes
Con requerimientos estables
Aplicaciones críticas
Grandes equipos de desarrollo
Equipo de desarrollo distribuidos geográficamente
Agiles
Ambientes dinámicos, con equipos de trabajo pequeños y
produciendo aplicaciones no críticas
Requerimientos desconocidos o inestables, garantizando
un menor riesgo ante la posibilidad de cambio en los
requerimientos
12. Principios:
1. La prioridad principal es satisfacer al cliente
mediante tempranas y continuas entregas de
software que le reporte un valor
2. Dar la bienvenida a los cambios. Los AMs capturan
los cambios para que el cliente tenga una ventaja
competitiva
3. Entregar frecuentemente software que funcione,
desde un par de semanas a un par de meses, con el
menor intervalo de tiempo posible entre una
entrega y la siguiente
13. 8. Los procesos ágiles promueven un desarrollo
sostenible. Los promotores, desarrolladores y
usuarios deberían ser capaces de mantener una paz
constante
9. La atención continua a la calidad técnica y al buen
diseño mejora la agilidad
10. La simplicidad es esencial
11. Las mejores arquitecturas, requisitos y diseños
surgen de los equipos organizados por sí mismos
12. En intervalos regulares, el equipo reflexiona respecto
de cómo llegar a ser más efectivo, y según esto
ajusta su comportamiento
14. Metodología Ágil Metodología No Ágil
Pocos Artefactos Más Artefactos
Pocos Roles Más Roles
No existe un contrato tradicional
o al menos es bastante flexible
Existe un contrato prefijado
Cliente es parte del equipo de
desarrollo (además in-situ)
El cliente interactúa con el
equipo de desarrollo mediante
reuniones
Grupos pequeños (< 10
integrantes) y trabajando en el
mismo sitio
Grupos grandes
Menos énfasis en la arquitectura La arquitectura es esencial
15. Crystal Methodologies, Alistarir Cockburn,
www.crystalmethodologies.org
SCRUM, Ken Schwaber & Jeff Sutherland,
www.controlchaos.com
DSDM (Dynamic Systems Development Method),
www.dsdm.org
Lean Programming, Mary Poppendieck, www.poppendieck.com
FDD (Feature-Driven Development), Peter Coad & Jeff De Luca,
www.nebulon.com/fdd, www.coad.com/peter/#fdd
Extreme Programming, Kent Beck
www.extremeprogramming.org, www.xprogramming.com
Adaptative Software Development, Jim Highsmith
www.adaptivesd.com
18. Metodología liviana de desarrollo de software
Conjunto de practicas y reglas empleadas para
desarrollar software
Basada en diferentes ideas acerca de cómo
enfrentar ambientes muy cambiantes
Originada en el proyecto C3 para Chrysler
En vez de planificar, analizar y diseñar para el
futuro distante, hacer todo esto un poco cada
vez, a través de todo el proceso de desarrollo
19.
20. “Haz la cosa mas simple posible que
funcione”
“Mantén el sistema en la condición mas
simple posible”
21. El cliente es parte del equipo de desarrollo
Comunicación entre gestión y desarrollo
Comunicación entre desarrolladores
22. Velocidad, pero además calidad
Testeo continuo a través de todo el proceso
Testeo como herramienta de especificación y
desarrollo
Testeo como garantía de integridad del
código frente a cambios
27. Corrección de
bugs
Reunión
de pie
Manejo colectivo
del software
Próxima tarea o test
de aceptación fallido
Plan de
iteración
Día a día
tareas
Tests de
aceptación
fallados
Tests de unidad
pasados al 100%
Test de
aceptación
aprobado
Tareas sin terminar
Demasiado por
hacer
Nueva
funcionalidad
Aprender y
comunicar
Programación en pares
Reconstrucción de código
28. Próxima tarea
o test de
aceptación
Creación de
unidad de
testeo
Programación
en pares
100% de
unidades de
testeo pasados
Pares
Unidad de
testeo fallida
Mover Gente
Se necesita
ayuda
Cambio
de par
Unidad de
testeo
aprobada
Código
simple
Código
complejo
Reconstrucción
despiadada
Ejecutar
todas las
unidades
de testeo
Test de
aceptación
aprobado
Ejecutar
test de
aceptación
fallados
29. Proceso de
planificación
Entregas pequeñas
Metáfora del sistema
Diseño simple
Testeo
Reconstrucción
Programación en
pares
Propiedad colectiva
Integración continua
Semana de 40 horas
Cliente siempre
disponible
31. Scrum es una metodología ágil de desarrollo de
software.
Ken Schwaber y Jeff Sutherland fueron los
precursores de este método demostrando
ampliamente su valía en proyectos de gran
envergadura con un alto número de personal
involucrado es su consecución.
32. Desarrollo de software por medio de iteraciones (Sprints).
Indicado para proyectos con un rápido cambio de
requerimientos.
Gran protagonismo de reuniones a lo largo del proyecto.
33. Product Backlog.
Sprint Backlog.
Spring Planning meeting.
Revisión de Sprint.
34. Propietario del producto.
Usuarios del producto.
Scrum master.
Equipo scrum.
35.
36. Base del desarrollo en Scrum.
Periodo mensual donde se llevan a cabo una serie de
tareas previamente establecidas.
37. Lista de las tareas a realizar durante todo el proyecto.
No es una lista fija se puede eliminar o añadir tareas
conforme avance el proyecto.
Se prioriza las tareas según los requisitos de los usuarios
o del propietario de la aplicación.
38. Reunión que se realiza antes de cada Sprint.
Se hace conjuntamente con el Propietario del producto el
Scrum Master y el equipo Scrum.
Enfocar la reunión hacia los requisitos mas prioritarios.
39. Después de solventar cualquier tipo de duda sobre los
requisitos se pasa a decidir las tareas a desarrollar en el
Sprint.
40. Lista elaborada por el equipo Scrum.
Se especifican las tareas que se van a desarrollar a lo
largo del Sprint.
Tiene gran importancia ser realista en la elaboración del
Sprint Backlog para poder finalizar las tareas acordadas.
41. Se realiza al final de cada Sprint.
Se deben reunir el propietario de la aplicación los
usuarios así como el Scrum Master y su equipo , además
también es recomendable que acudan ingenieros de otros
proyectos para dar su punto de vista.
42.
43.
44. VENTAJAS:
Programación organizada
Menor taza de errores
Satisfacción del programador
DESVENTAJAS:
Es recomendable emplearlo solo en
proyectos a corto plazo
45. SEMEJANZAS
Es un Agile Manifiesto.
Existen una Interacción de Usuario a Usuario.
Realizan los Proyectos en un Corto Periodo de
Tiempo.
Trabajan en Equipo.
46. SCRUM XP (EXTREME PROGRAMMING)
Las iteraciones de entregas son de 2 a 4
semanas.
Las iteraciones de entrega son a 1 a 3
semanas.
Lo que se termina, funciona y este bien, se
aparta y ya no se toca.
Las tareas q se van entregando a los
diferentes clientes son susceptibles a las
modificaciones.
Cada miembro del Scrum Team trabaja de
forma individual.
Los miembros programan en pareja en un
proyecto XP.
El Scrum Team trata de seguir el orden de
prioridad que marca el Product Owner, en
el Sprint Backlog pueden ser modificadas.
El equipo de desarrollo sigue estrictamente
el orden de prioridad de las tareas definidas
por el cliente.
Esta basada en la administración del
proyecto.
Se centra mas en la propia programación o
creación del producto.
47.
48. HISTORIA DE USUARIOS - EJEMPLOS
Historia de Usuario
Número: 1 Nombre :Ingreso de Calificaciones
Modificación de Historia de Usuario (Nro. y Nombre):
Usuario/Rol: Secretaria Iteración/Sprint Asignada: 1
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo: Alta
(Alto / Medio / Bajo)
Descripción: Permite el ingreso de las calificaciones de cada parcial de los estudiantes
que se encuentran matriculados tanto en la modalidad semestral como anual
Observaciones: Actualmente la información es llevada de maneja semi automática en
hojas de cálculo.
49. Historia de usuario
Numero:2 Nombre: Operaciones de corte
Usuario/Rol: Jefe de producción
Modificación de historia numero: Iteración asignada: 2
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo: Medio
(Alto / Medio / Bajo)
Descripción: El jefe de producción tendrá la tarea de marcar el producto al ser finalizado
en esta área, para que pueda ser pasado por el horno de templado, es necesario llevar el
control porque una vez templado el vidrio no puede ser modificado
Observaciones:
HISTORIA DE USUARIOS - EJEMPLOS
50. HISTORIA DE USUARIOS - EJEMPLOS
Historia de usuario
Numero:3 Nombre: Generación de reportes
Usuario/Rol: Ingeniero de templado
Modificación de historia numero: Iteración/Sprint asignada: 2
Prioridad en Negocio: Alta
(Alta / Media / Baja)
Riesgo en Desarrollo: Medio
(Alto / Medio / Bajo)
Descripción: El ingeniero de templado tendrá la opción de marcar los vidrios una vez
hayan sido procesados por el horno de templado para dar orden de culminación y
entrega del producto.
Observaciones: