Your SlideShare is downloading. ×
Solo Requisitos 2008 - 11 Ncapas
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Solo Requisitos 2008 - 11 Ncapas

163
views

Published on

Presentación de Ncapas en Solo Requisitos 2008

Presentación de Ncapas en Solo Requisitos 2008

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
163
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Los procesos de requisitos y las metodologías ágiles Pablo Schmittner Consultor IT nCapas Software S.L. 20/06/2008 Un caso basado en SCRUM
  • 2. Agenda
    • Gestión de Proyectos
      • Metodologías predictivas vs. metodologías ágiles
    • Scrum en la teoría
      • Los orígenes
      • Aproximación a Scrum
      • Los elementos del Scrum
      • Los roles
    • Scrum en la práctica
      • Los requisitos
      • El equipo
      • Las reuniones
  • 3. Agenda
    • Compass Mobile: un caso basado en Scrum
      • La problemática de los requisitos
      • Los retos del Scrum Master
      • Scrum desde las trincheras
    • Conclusiones
      • Comparativa
      • Las dificultades del Scrum
  • 4. Gestión de Proyectos
    • Un proyecto de software se considera exitoso cuando se consigue la finalidad prevista en tiempo y forma.
    • La gestión de proyectos tradicional (predictiva) nació para ofrecer previsibilidad en la construcción de sistemas, con garantías de que el producto final se obtendrá en el tiempo y con el coste previamente estimados.
    • Se analiza el trabajo a realizar, se descompone en tareas y se controla el cumplimiento de las mismas.
    • Se desarrolla un plan apropiado que se adapte a recursos y tiempos.
    • Se sigue de cerca la ejecución para evitar desviaciones.
  • 5. Gestión de Proyectos
    • El gestor tiene tareas como:
      • Gestión de la integración del proyecto.
      • Gestión de costes.
      • Gestión de la calidad.
      • Gestión de tiempos y agendas.
      • Gestión del alcance del proyecto.
      • Gestión de la comunicación en el proyecto.
      • Gestión de los riesgos.
      • Gestión de proveedores.
  • 6. Gestión de Proyectos
    • El gestor utiliza técnicas y herramientas para ordenar ideas, registrar, consultar y analizar información:
      • Diagramas de Gantt.
      • Ruta crítica.
      • Plan de comunicación.
      • Plan de riesgos.
      • Plan de calidad.
      • Plan de recursos.
      • Matriz de responsabilidades.
      • Actas de reuniones.
      • Etc.
  • 7. Gestión de Proyectos
    • El resultado de todo esto:
      • El gestor “hace deberes” (planificación, informes, registros, etc).
      • El gestor “manda hacer deberes”.
      • El gestor controla el equipo.
      • El equipo se siente presionado.
      • El equipo arrastra todos los días con la necesidad de cumplir con normas y con horas imputadas en vez de preocuparse por la eficiencia y calidad.
      • Gestión predictiva del proyecto
  • 8. Las metodologías predictivas
    • Las fases se desarrollan como una carrera de relevos.
      • Toma de requisitos, análisis, diseño, programación, testing…y vuelve a comenzar.
      • Se termina una y se comienza otra.
      • Se pueden comenzar algunas fases antes de que hayan finalizado las anteriores. Ej: comienza el desarrollo antes de tener finalizado la totalidad del análisis.
      • Existe poco solapamiento entre fases.
  • 9. Las metodologías predictivas
    • Los productos de software evolucionan cada vez más rápido, entonces…
      • ¿Qué sucede con este modelo cuando se requiere mayor velocidad?
    • Los productos de software son el resultado de estrategias comerciales más cambiantes, entonces…
    • ¿Qué sucede con este modelo cuando se requiere mayor flexibilidad?
  • 10. El Manifiesto Ágil
    • 03-2001: Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
      • A los individuos y su interacción , por encima de los procesos y las herramientas.
      • El software que funciona , por encima de la documentación exhaustiva.
      • La colaboración con el cliente , por encima de la negociación contractual.
      • La respuesta al cambio , por encima del seguimiento de un plan.
  • 11. Los principios de Manifiesto
    • Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
    • Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
    • Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
    • Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
    • Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
  • 12. Los principios de Manifiesto
    • La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
    • El software que funciona es la principal medida del progreso. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
    • La atención continua a la excelencia técnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial.
    • Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
    • En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
  • 13. Orígenes de SCRUM
    • Es una metodología de las clasificadas como ágiles.
    • Surgió en 1986 (Takeuchi and Nonaka) como un estilo de dirección de proyectos para la industria automovilística y de productos de consumo.
    • El por qué de esta metodología fue:
      • El mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.
      • Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.
      • El mercado exige ciclos de desarrollo más cortos.
  • 14. Orígenes de SCRUM
    • La aproximación como “carrera de relevos” para desarrollar software se encuentra en conflicto con la meta de máxima velocidad y flexibilidad.
    • Scrum es, metafóricamente hablando, como el juego de Rugby . En el Rugby un equipo trata de avanzar como una unidad, pasando el balón de acá para allá.
  • 15. Orígenes de SCRUM
    • Rugby:
      • 15 jugadores por equipo
      • Existe la variante de 7
      • Dos tiempos de 40m
      • Tercer Tiempo: equipo local invita al rival
      • Deporte duro pero NO violento
      • Respeto absoluto a la figura del árbitro
  • 16. Orígenes de SCRUM
    • Rugby, Reglas Básicas:
      • No se permite pasar el balón hacia adelante. Tampoco se permite que el balón caiga adelante (knock-on).
      • El balón solo puede avanzar cargándolo con las manos o pateándolo hacia adelante.
      • Un jugador tackleado debe soltar o pasar inmediatamente el balón y el jugador que tacklea debe soltar al jugador tackleado.
      • Después de convertir un try o un penal, el balón es pateado hacia el equipo anotador.
  • 17. Orígenes de SCRUM
    • Rugby, Formaciones:
      • Mauls: Si el balón se encuentra en posesión de un jugador y este a su vez está siendo sujetado por uno o mas jugadores del equipo contrario.
  • 18. Orígenes de SCRUM
    • Rugby, Formaciones:
      • Ruck: Si el balón está en el piso, y jugadores de ambos equipos están sujetándose en busca de la posesión del balón.
  • 19. Orígenes de SCRUM
    • Rugby, Formaciones:
      • Line: El balón sale por un lateral y el equipo contrario saca lanzando el balón al pasillo formado por los dos equipos con la ventaja que el equipo que saca, según una clave, sabe a que jugador va el balón.
  • 20. Orígenes de SCRUM
    • Rugby, Formaciones:
      • Scrum: El balón es introducido entre las primeras líneas de cada equipo donde existe un jugador, especializado en dar una patada hacia atrás, hasta los pies de quien ha introducido el balón, para que otra vez decida que hacer con el mismo.
  • 21. Orígenes de SCRUM ¿La clave?…EL EQUIPO
  • 22. Orígenes de SCRUM
    • La clave del Rugby, el Equipo
      • El equipo es la pieza fundamental
      • No hay un jugador “prima donna”, todo el mundo depende de sus compañeros
      • El balón fluye constantemente entre jugadores
      • Los jugadores buscan la perfección en la sincronización y el acoplamiento entre ellos
      • Todos los jugadores conocen la forma de jugar y pueden realizar una u otra tarea
      • Cada jugador es una pieza del engranaje
      • Es imposible ganar un partido “en solitario”
  • 23. Orígenes de SCRUM
    • La clave del Rugby, el Equipo
      • El equipo se concentra en hacer su jugada: atacar o defender
      • La visibilidad de los resultados es constante
      • El equipo es capaz de reaccionar ante cambios en el transcurso del partido
      • Un equipo de Rugby ganador, SIEMPRE debe estar motivado
      • La excelencia técnica individual es un objetivo interno de cada jugador
      • La simplicidad en el juego como arte de maximizar la cantidad de resultados que se obtienen, es esencial.
  • 24. Aproximación a SCRUM
    • Nonaka y Takeuchi extraen las bases de Scrum de las prácticas que observan en las empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard; y son:
      • Inestabilidad consustancial al entorno de desarrollo.
      • Equipos auto-organizados.
      • Solapamiento de las fases del desarrollo.
      • Multi-aprendizaje.
      • Control sutil.
      • Transferencia de aprendizaje a nivel organizacional.
  • 25. SCRUM en la práctica
    • El desarrollo se inicia desde la visión general de producto, dando detalle solo a las funcionalidades que, por ser las de mayor prioridad para el negocio, se van a desarrollar en primer lugar , y pueden llevarse a cabo en un periodo de tiempo breve (entre 15 y 30 días).
    • Cada uno de los ciclos de desarrollo es una iteración ( Sprint ) que produce un incremento terminado y operativo del producto.
    • Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones breves de seguimiento en las que todo el equipo revisa el trabajo realizado desde la reunión anterior y el previsto hasta la reunión siguiente.
  • 26. Los elementos del SCRUM
    • Product Backlog : Requisitos del sistema. Se parte de la visión del resultado que se desea obtener; y evoluciona durante el desarrollo.
      • Es el inventario de características que el propietario del producto desea obtener, ordenado por orden de prioridad.
      • Es un documento “vivo” , en constante evolución.
      • Es accesible a todas las personas que intervienen en el desarrollo.
      • Todos pueden contribuir y aportar sugerencias.
      • El responsable del Product Backlog es una única persona y se le denomina: propietario del producto.
  • 27. Los elementos del SCRUM
  • 28. Los elementos del SCRUM Estimación inicial Complejidad Estim. ajustada ID Elemento 1 Nuevo formulario para peticiones de clientes 2 0.2 2,4 2 Configuración de respuestas automáticas 3 0.2 3,6 3 Envío automático de respuestas 1 0.2 1,2 4 Consulta para los clientes de peticiones enviadas 1 0.2 1,2 5 Modificación del cliente de sus peticiones enviadas 2 0.2 2,4 6 Acceso a peticiones sólo para clientes del portal jurídico 5 0.2 6 7 Consulta de peticiones por parte del staff 1 0.2 1,2 8 Inserción de comentarios y reasignación a peticiones (staff) 2 0.2 1,2 9 Consultas por clientes, fechas y temas 3 0,2 3,6 Product Backlog 1 2,4 3,6 1,2 1,2 2,4 6 1,2 1,2 3,6 2 0 0 0 0 0 0 0 1,2 3,6 3 0 0 0 0 0 6 0 0 0 4 0 0 0 0 0 0 0 0 0 Trabajo pendiente Sprint 10 [Continúa]…. SPRINT 1 15 18 18 0 0 0
  • 29. Los elementos del SCRUM
    • Sprint Backlog: Lista de los trabajos que realizará el equipo durante el Sprint para generar el incremento previsto.
      • El equipo asume el compromiso de la ejecución. Las tareas están asignadas a personas, y tienen estimados el tiempo y los recursos necesarios.
  • 30. Los elementos del SCRUM
  • 31. Los elementos del SCRUM
    • Incremento : Resultado de cada Sprint.
      • Se trata de un resultado completamente terminado y en condiciones de ser usado.
  • 32. Los elementos del SCRUM
  • 33. Los roles del SCRUM
    • Scrum tiene una estructura muy simple. Todas las responsabilidades del proyecto se reparten en 3 roles:
      • Propietario del producto (Product Owner)
      • Equipo (Team)
      • Gestor de Scrum (Scrum Master)
  • 34. Trabajando con SCRUM
    • El Sprint , es el periodo de tiempo durante el cual se desarrolla un incremento de funcionalidad.
    • Duración máxima: 30 días.
    • Durante el Sprint no se puede modificar el trabajo que se ha acordado en el Product Backlog .
    • Sólo es posible cambiar el curso de un Sprint, abortándolo, y sólo lo puede hacer el Scrum Master si decide que no es viable por alguna de las razones siguientes:
      • La tecnología acordada no funciona.
      • Las circunstancias del negocio han cambiado.
      • El equipo ha tenido interferencias.
  • 35. Trabajando con SCRUM
    • Al iniciar cada iteración (Sprint), el equipo revisa el trabajo pendiente del proyecto y selecciona la parte que terminará, como un incremento de funcionalidad, incorporado al software al finalizar la iteración.
    • Al final de la iteración el equipo presenta el incremento de funcionalidad a las partes implicadas en el proyecto.
    • El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus conocimientos, y de forma colectiva determina cómo implementar la funcionalidad.
  • 36. Los requisitos = Backlogs
    • Es una lista con los requisitos del sistema.
    • El dueño del producto se responsabiliza de:
        • Contenido
        • Priorizar
        • Disponibilidad
    • Nunca llega a ser una lista completa y definitiva.
    • Es empleado para planificar el proyecto y es sólo una estimación inicial de requisitos.
    • Es un documento dinámico que incorpora constantemente las necesidades del sistema.
    • Se mantiene durante todo el ciclo de vida (hasta la retirada del sistema).
  • 37. Las tareas = Sprint Backlogs
    • Trabajo o tareas determinadas por el equipo para realizar en un Sprint y lograr al final del mismo un incremento de la funcionalidad.
    • Se recomienda que las tareas reflejadas tengan una duración comprendida entre las 4 y las 16 horas de trabajo .
    • Las de mayor duración deben intentar descomponerse en sub-tareas de ese rango de tiempo.
  • 38. Las reuniones
  • 39. Planificación del Sprint
    • Sprint Planning Meeting ; tomando como base las prioridades y necesidades de negocio del cliente, se determinan cuáles y cómo van a ser las funcionalidades que se van a incorporar al producto con el próximo Sprint.
    • Se decide qué elementos del Product Backlog se van a desarrollar.
    • Se desglosan éstos para determinar las tareas necesarias, estimar el esfuerzo que necesita cada una y asignarlas a las personas del equipo.
    • La planificación del Sprint no debe durar más de un día.
  • 40. SCRUM Diario
    • Daily Scrum, reunión del equipo con duración máxima de 15 minutos.
    • Todos los días en el mismo sitio y a la misma hora.
    • Se recomienda que sea la primera actividad del día.
    • Moderada por el Scrum Master , que pregunta a todos los asistentes:
      • ¿Cuál ha sido el trabajo realizado desde la última revisión diaria?
      • ¿Cuál es el trabajo previsto para hoy?
      • ¿Hay algo que necesitas, o que te impide realizar el trabajo previsto?
  • 41. SCRUM Diario
    • No se permite entrar en divagaciones o salirse del guión.
    • Sólo habla la persona que informa de su trabajo, el resto escucha y no hay lugar para otras conversaciones.
    • Cuando un miembro informa de algo de interés para otros, o necesita ayuda de otros, estos se reúnen al terminar la revisión diaria.
  • 42. Revisión de Sprint
    • Sprint Review Meeting , reunión del equipo, el Scrum Master, y el propietario del producto con todas las personas implicadas en el proyecto.
    • Finalidad: presentar al propietario del producto y al equipo las nuevas funcionalidades implementadas.
    • En la reunión, los miembros del equipo muestran las nuevas funcionalidades.
    • Al final de la reunión se interroga individualmente a todos los asistentes para recabar impresiones, sugerencias de cambio y mejora, y su relevancia.
    • El propietario del producto trata con los asistentes y con el equipo las posibles modificaciones en la pila de producto.
  • 43. Evaluación de Sprint
    • Sprint Restrospective Meeting , reunión del equipo, el Scrum Master, opcionalmente el propietario del producto.
    • Todos los miembros del equipo responden a dos preguntas:
      • ¿Qué cosas fueron bien en el último Sprint?
      • ¿Qué cosas se podrían mejorar?
    • El Scrum Manager anota todas las respuestas.
    • El equipo prioriza las mejoras posibles.
    • El Scrum Manager no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor forma de trabajar con Scrum.
    • Las acciones de mejora localizadas que se puedan implementar en el próximo Sprint deben introducirse en la pila de producto como elementos no funcionales.
  • 44. Un caso práctico: Compass Mobile
    • Aplicativo para el sector Turismo Receptivo
    • Gran cantidad de requisitos
    • Muchos requisitos cambiantes
    • Versionado continuo
    • Time to market
    • Necesidad de feedback continuo
    • Equipos deslocalizados
    • Dos y tres husos horarios (España, Uruguay, Rep. Dominicana)
  • 45. Compass Mobile: La metodología
    • Product Backlog y Sprint Backlogs
    • Sprints de 30 días aprox.
    • Se realizan Sprints cortos en determinados momentos
    • Sprint Planning Meetings
    • Daily Scrums
    • Sprint Review Meetings
  • 46. Compass Mobile: Las herramientas
    • Share Point 2007 como herramienta de colaboración:
      • Plantillas modificadas para contemplar el Product Backlog y los distintos Sprint Backlogs
      • Alertas en la asignación de tareas
      • Alertas en la completitud de las tareas
      • Configuración de vistas
    • Skype como herramienta de comunicación
    • Alternativamente, dispositivos Cisco y servidor de VoIP
    • VS 2008 y SQL Server 2005
    • Tortoise para la gestión del versionado de código
  • 47. Los retos del Scrum Master
    • Necesidad de contar con un equipo multidisciplinar
    • Comunicación de la visión del producto
    • Agilidad en los desarrollos
    • Gestión de los requisitos cambiantes
    • Capacidad de advertir rápidamente las desviaciones
    • Coaching del equipo
    • Resultados palpables
    • Transmitir la “esencia” del Scrum
  • 48. Scrum desde las trincheras
    • El equipo…Scrumtime!!
  • 49. Conclusiones - Comparativa
    • Desarrollo Tradicional
    • Especialización
    • Fases
    • Requisitos Detallados
    • Seguimiento del Plan
    • Desarrollo con Scrum
    • Equipo Multidisciplinar
    • Solapamiento
    • Visión del producto
    • Adaptación a los cambios
    VS
  • 50. Las dificultades del SCRUM
    • Los detalles ‘asesinan’ el proceso si no se gestionan
    • Entender y formar el equipo multidisciplinar
    • Crear un Product Backlog
    • Recursos no dedicados
    • Integración de las tareas de soporte
    • Estimación / Métricas
    • Descomposición del trabajo
    • Planeamiento a largo plazo
    • Tiempo para investigación / ‘relax’
  • 51. Más información
    • www.controlchaos.com
    • www.scrumforteamsystem.com
    • www.agilealliance.com
    • www.agile - spain.com
    • www.geeks.ms / blogs / rcorral
    • www.navegapolis.net
  • 52.
      • www.ncapas.com
      • [email_address] Anabel Segura Nº 11 - Edificio A
      • 2a. Planta
      • 28108 – Alcobendas – Madrid +(34) 91 184 64 39