Tuenti - de la idea a la web

1,142 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,142
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Decir que cada equipo se encarga del desarrollo de varios productos dentro de la web. Como por ejemplo apps de juegos, core del feed, interactive de fotos.
  • Se hacen más o menos un brainstorming cada Quarter, cada tres meses. En esta reunión participa el equipo al completo y la esta dirigida por el PM. Se suele dividir en dos partes: en la primera se buscan ideas para mejorar los productos en los que trabaja el propio equipo y otra con ideas a nivel general del sitio. Como se ve en la foto se van escribiendo las ideas en post-its se vean agrupando y se vota para ver las más relevantes. El PM ya es quien se encarga de gestionar y decidir cuales son las mejores y más importantes.
  • Una vez que se decide que idea o producto se quiere desarrollar el PM comienza a definirlo. Así que el PM en pieza a esbozar los requisitos del producto en el PID. Una vez que este documento se aprueba es cuando se empieza ya a definir con más de el producto que se va a desarrollar. Comienza a escribirse el PRD.
  • El PRD es un documento donde se define toda la funcionalidad del producto, como va a funcionar. El PM es el encargado de escribirlo y es asesorado por el equipo técnico. Ya que son los encargados de decir si una funcionalidad concreta es técnicamente viable. Una vez escrito es documento, comienza el proyecto.
  •   Product Owner  representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuarios, las prioriza, y las coloca en el Product Backlog. El  Scrum  es facilitado por un  ScrumMaster , cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El  ScrumMaster  no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan. ScrumTeam: El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc). Usuarios: Los usuarios son el destinatario final del producto. Stakeholders : Serefiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint.
  • El objetivo de esta reunión es definir el scope del sprint (sprint backlog), es decir, que vamos a hacer durante las siguientes dos semanas. Esta reunión está dirigida por el Scrum Master y se involucra a todo el equipo. Del product backlog se extraen las user stories (pedazos de funcionalidad, una user storie podría ser “como usuario quiero ver una lista de los últimos juegos a los que he jugado”. Las user stories se ordenan por prioridad dentro del product backlog. Según la velocidad de desarrollo del equipo se pueden incluir más user stories o menos.
  • Una reunión que se realiza todas las mañanas junto a la pizarra de scrum y que debe duran entre 5-10 minutos. Cada miembro de equipo explica las tareas que hizo el día anterior y el trabajo que va a hacer ese día. Además de comentar si se ha encontrado con algún impedimento. Si existe algún impedimento, el scrummaster es el encargado de eliminarlo. Además se actualiza la gráfica del burndow para tener un feedback rápido del estado del sprint.
  • Scrum es un proceso que se retroalimenta
  • ¿Por qué martes y jueves? Porque son los mejores días ya que los lunes es demasiado temprano y los viernes demasiado arriesgado debido a que el sábado no se trabaja.
  • Si después de cerrar la release se encuentra algún bug en el site se haría un hotfix. Si el problema es realmente gordo. Explicar q es un hotfix.
  • Tuenti - de la idea a la web

    1. 1. De la Idea a la Web Pedro Álvarez [email_address] Diana López [email_address]
    2. 2. Agenda <ul><li>Equipos de Producto </li></ul><ul><li>Flujo de Trabajo </li></ul><ul><li>Brainstorming </li></ul><ul><li>PID (Project Initiation Document) </li></ul><ul><li>PRD (Project Requirements Document) </li></ul><ul><li>Desarrollo </li></ul><ul><li>Release </li></ul><ul><li>Dudas y Preguntas </li></ul>
    3. 3. Equipos de Producto <ul><li>1 Product Manager </li></ul><ul><li>1 Team Lead </li></ul><ul><li>5 Ingenieros </li></ul><ul><li>1 Diseñador </li></ul><ul><li>1 Ingeniero de QA </li></ul>
    4. 4. Flujo de Trabajo
    5. 5. Brainstorming <ul><li>Todos participamos aportando ideas </li></ul>
    6. 6. PID (Project Initiation Document) <ul><li>“ Descripción a grandes rasgos del alcance del proyecto” </li></ul><ul><li>Responsables </li></ul><ul><ul><li>Product Manager </li></ul></ul><ul><ul><li>Team Lead </li></ul></ul><ul><li>Resultado </li></ul><ul><ul><li>Aprobación > PRD </li></ul></ul>
    7. 7. PRD (Project Requirements Document) <ul><li>“ Definición de los requisitos finales del producto” </li></ul><ul><li>Responsables </li></ul><ul><ul><li>Product Manager </li></ul></ul><ul><ul><li>Todo el Equipo Técnico </li></ul></ul><ul><li>Resultado </li></ul><ul><ul><li>Inicio del Proyecto </li></ul></ul>
    8. 8. Scrum “ Marco de trabajo para la gestión de proyectos basada en un proceso iterativo utilizado entornos basados en el desarrollo ágil de software ”
    9. 9. Scrum > El Equipo <ul><li>Product Owner (PM) </li></ul><ul><ul><li>Responsable del producto y de las prioridades </li></ul></ul><ul><ul><li>Accepta o rechaza el resultado </li></ul></ul><ul><li>ScrumMaster (TL o Ingeniero) </li></ul><ul><ul><li>Gestiona el Sprint </li></ul></ul><ul><ul><li>Se encarga de los impedimentos </li></ul></ul><ul><li>Scrum Team (Ingenieros, Diseñadores, QA...) </li></ul><ul><ul><li>Tamaño 6-8 </li></ul></ul><ul><ul><li>Habilidades transversales </li></ul></ul><ul><ul><li>Responsables del Sprint </li></ul></ul><ul><li>Usuarios / Stakeholders </li></ul>
    10. 10. Scrum > El Sprint Planning <ul><li>ScrumMaster, Product Owner y Scrum Team </li></ul><ul><li>Revisión de las User Stories del Product Backlog </li></ul><ul><li>Definición del Sprint Backlog </li></ul><ul><ul><li>2 Semanas </li></ul></ul><ul><li>Scope según la Sprint Velocity del Equipo </li></ul>
    11. 11. Scrum > Daily Scrum <ul><li>ScrumMaster y Scrum Team </li></ul><ul><li>Reunión de 5-10 minutos </li></ul><ul><li>Cada miembro del Equipo debe responder </li></ul><ul><ul><li>¿Qué hizo ayer? </li></ul></ul><ul><ul><li>¿Qué va hacer hoy? </li></ul></ul><ul><ul><li>¿Ha encontrado con algún impedimento? </li></ul></ul><ul><li>Actualización del Burndown </li></ul>
    12. 12. Scrum > Daily Scrum
    13. 13. Scrum > Demo <ul><li>Product Owner, ScrumMaster y Scrum Team </li></ul><ul><li>Se muestra al Product Owner el resultado. </li></ul><ul><li>Product Owner acepta o rechaza los resultados. </li></ul><ul><li>Resultado </li></ul><ul><ul><li>Nuevas User Stories </li></ul></ul><ul><ul><li>Sprint Retrospective </li></ul></ul>
    14. 14. Scrum > Sprint Retrospective <ul><li>ScrumMaster y Scrum Team </li></ul><ul><li>Revisón del Sprint </li></ul><ul><ul><li>Cosas Mejorables </li></ul></ul><ul><ul><li>Cosas Buenas </li></ul></ul><ul><ul><li>Ideas </li></ul></ul><ul><li>Resultado se aplica en los siguientes Sprints </li></ul>
    15. 15. Pair Programming “ Técnica usada, en Agile Development, cuando dos desarolladores trabajan en el mismo ordenador Un miembro escribe el código mientras el otro revisa el trabajo. El teclado va cambiando de manos con frecuencia.”
    16. 16. Testing <ul><li>Unit Test </li></ul><ul><ul><li>“ Forma de probar el correcto funcionamiento de un módulo de código por separado” </li></ul></ul><ul><li>Integration Test </li></ul><ul><ul><li>“ Forma de probar que todas los componentes funcionan de forma combinada” </li></ul></ul><ul><li>Acceptance Test </li></ul><ul><ul><li>“ Forma de validar que el producto cumple el funcionanmiento esperado” </li></ul></ul><ul><li>Code Coverage </li></ul><ul><ul><li>“ Forma de saber la cantidad de código que está sometido a nuestras pruebas” </li></ul></ul>
    17. 17. Control de Versiones “ Gestión de los diversos cambios que se realizan sobre el código fuente de algún producto”
    18. 18. Integración Continua “ Ejecuciones de test automatizadas que permiten  detectar fallos lo antes posible”
    19. 19. Code Review <ul><li>¿Por qué? </li></ul><ul><ul><li>Menor número de bugs </li></ul></ul><ul><ul><li>Más calidad de código </li></ul></ul><ul><li>¿Cómo? </li></ul><ul><ul><li>Por Changeset </li></ul></ul><ul><ul><li>Pair Programming </li></ul></ul><ul><ul><li>Proyecto Completo </li></ul></ul>
    20. 20. Quality Assurance <ul><li>Pruebas manuales (Test Cases) en diferentes browsers </li></ul><ul><li>Pruebas de Regresión </li></ul>
    21. 21. Release <ul><li>Todos los Martes y Jueves a las 8:00 </li></ul><ul><li>Asistentes: </li></ul><ul><ul><li>Todos los ingenieros con código </li></ul></ul><ul><ul><li>Responsable(s) de QA </li></ul></ul><ul><ul><li>Release Manager </li></ul></ul><ul><ul><li>Responsable de sistemas </li></ul></ul><ul><li>Canal de chat con todos los implicados </li></ul>
    22. 22. Release <ul><li>&quot;Live bugfixing&quot; hasta ~11:30 AM </li></ul><ul><ul><li>Errors spreadsheet </li></ul></ul><ul><li>Cierre de la release </li></ul>
    23. 23. ¿Te Animas? <ul><li>Proyectos de Fin de Carrera </li></ul><ul><li>Becas </li></ul><ul><ul><li>Part Time </li></ul></ul><ul><ul><li>Full Time </li></ul></ul><ul><li>Associate Programs </li></ul>[email_address]

    ×