00
¿Quién soy yo?
Iwan van der Kleijn
I work and live in Valencia, Spain and have been here
with my family since 2005.
Now working for more ...
Academia vs Business
01
¿Quiénes somos?
Nuestra forma de pensar

Somos una consultora especializada en tecnología y productos Microsoft,
que ofrece mejoras de com...
Nuestros valores

Es la responsabilidad profunda que nos
vincula a nuestros clientes, a nuestros
proyectos, a nuestros com...
Pensar en colores
Es la actitud fresca, optimista y
comprometida que utiliza el
ingenio y la creatividad para
encontrar so...
02
¿Qué hacemos?
¿Qué hacemos?

Soluciones de Colaboración,
Conocimiento e inteligencia
de negocio.

Soluciones CRM
y enterprise Mobility

...
13 años construyendo soluciones brillantes
Microsoft Partner del año Pyme 2013
Tagcloud de nuestro mundo tecnológico
Porqué somos buenos en SharePoint
• 

• 

• 

Estamos certificados en las competencias de Portals & Collaboration (Gold), ...
Cosas que hemos hecho con SharePoint
ü  Como intranet y gestión del conocimiento de la empresa.
ü  Como sistema de colab...
SharePoint
Everyware mediante
interfaces adaptativos /
Responsive
Logramos de SharePoint o cualquier otro sistema
web un i...
Tecnologías SharePoint Everyware
• 

Para ENCAMINA, extender SharePoint y otros aplicativos empresariales a la movilidad
i...
Arquitectura de la solución SharePoint Everyware
Servicios web ágiles y enfocados a las
necesidades y aprovechando las cap...
Ejemplo típico SharePoint Everyware:
HelpingHand sobre HelpShare
HelpingHand es la aplicación multidispositivo que
permite...
Algunas soluciones de empresa
ECM

BPM

CRM

WEB

BI

Intranet

Gestión calidad ISO9000 y
seguridad

Fuerza de Ventas y
Ge...
Pensar en colores: Pensar en personas
Pensar en colores: Pensar en participación con el
cliente
Pensar en colores: Pensar en UX & Business &
Tecnología integrado

UX
Pensar en colores: Pensar en diseño integrado
Pensar en colores: Pensar en un equipo
multidisciplinario
03
Lo que no hablamos (y tampoco vamos a hablar) en ICT
No hablamos de él
Aunque deberíamos hablar de ellos
Metáforas equivocadas: no trabajamos así
Y tampoco trabajamos así
Aunque es posible que trabajamos en el “Code
mine”
Seguro que no somos
Aunque podríamos ser

Pero no es muy políticamente correcto
O, alternativamente
Lea acerca de esto en este libro
Como Brooks escribió en 1975
“...Computer programming, however, creates with an
exceedingly tractable medium.
The programm...
04
Hacer proyectos en ICT
Proyectos fracasados & ICT: historia
“….In 1956, a group of computer scientists at IBM set out
to build the world's fastes...
¿Por qué fracasan los proyectos?
“Fracaso" no sólo son "fallos
catastróficos", sino también los retrasos,
las grandes cant...
¿Por qué fracasan los proyectos? Debilidades:
ü  Cualidad de equipo y forma de
trabajar
ü  Cualidad de procesos
ü  "For...
¿Por qué fracasan los proyectos? Algunas citas:
“...Qué es una prueba unitaria / un
"closure" / un interfaz ReST...”
“…¿Có...
Estado y calidad de los equipos
ü  Conocimiento es importante, pero también:
ü  la actitud profesional, tal como
ü  el ...
Debilidades en España
ü  Organización jerárquica
ü  No hay entorno estandarizado
(hay procesos(!); bastante. Este no es ...
Pero más importante

Al final del día los problemas críticos son
genéricos y comunes en todo el mundo:
ü  Incompetencia o...
Los problemas que se enfrentan al hacer proyectos

ü  La falta de un modelo, un
ejemplo, "saber qué hacer"
ü  La falta d...
Como un aparte
ü  No hay soluciones mágicas.
ü  Cualquier solución a los problemas
antes mencionados es dependiente
de l...
Scrum como metodología de proyectos
•  Scrum como posible solución
•  Muchas alternativas: Kanban, DSDM, Lean, Extreme Pro...
05
Gestión de proyectos: SCRUM
Scrum en 100 palabras
•  Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de
negocio en el...
Scrum ha sido utilizado para:
• 

Software comercial

• 

Desarrollos internos

• 

Desarrollos bajo Contrato

• 

Proyect...
Características
•  Equipos auto-organizados
•  El producto avanza en una serie de “Sprints" de dos semanas a un mes de
dur...
El Manifesto Ágil – una declaración de valores
Individuos	
  e	
  
interacciones	
  
So@ware	
  que	
  funciona	
  
Colabo...
Nivel de ruido de un proyecto
Lejos	
  de	
  	
  
Acuerdo	
  

Anarquía	
  

Simple	
  

Cerca	
  de	
  
Certeza	
  

Cerc...
Scrum

24 horas

Sprint
2-4 semanas

Objetivo del Sprint

Return	
  
Gi@	
  wrap	
  
Cancel	
  
Product
Backlog

Sprint
Ba...
Poniendo todo junto
Enfoque: Sprint
Sprints
•  En Scrum los proyectos avanzan en una serie de “Sprints”
–  Análogo a las iteraciones en XP

•  La duración típ...
Desarrollo secuencial vs. superpuesto

Requisitos	
  

Diseño	
  

Código	
  

Test	
  

En	
  lugar	
  de	
  hacer	
  tod...
No hay cambios en un sprint

Cambios

•  Planee la duración del sprint en torno a cuánto tiempo usted
puede comprometerse ...
Scrum Framework
Roles	
  

• Product	
  owner	
  
• ScrumMaster	
  
• Team	
  

Reuniones	
  

• Sprint	
  planning	
  
• ...
Scrum framework
Roles	
  

• Product	
  owner	
  
• ScrumMaster	
  
• Team	
  

Reuniones	
  

• Sprint	
  planning	
  
• ...
Product Owner
•  Define las funcionalidades del producto
•  Decide sobre las fechas y contenidos de los releases
•  Es res...
El ScrumMaster
•  Representa a la gestión del proyecto
•  Responsable de promover los valores y prácticas de
Scrum
•  Remu...
El Team
•  Típicamente de 5 a 9 personas
•  Multi-funcional:
–  Programadores, testers, analistas, diseñadores, etc.

•  L...
Scrum Framework
Roles	
  

• Product	
  owner	
  
• ScrumMaster	
  
• Team	
  

Reuniones	
  

• Sprint	
  planning	
  
• ...
Capacidad	
  del	
  
Equipo	
  
Product	
  
Backlog	
  
Condiciones	
  
del	
  	
  Negocio	
  

Sprint	
  Planning	
  mee?...
Planificación del Sprint
•  El equipo selecciona los temas a partir del Product
Backlog que pueden comprometerse a complet...
Daily Scrum
•  Parámetros
–  Diaria
–  Dura 15 minutos
–  Parados
•  No para la solución de problemas
–  Todo el mundo est...
Todos responden 3 preguntas
¿Qué hiciste ayer?

¿Qué vas a hacer hoy?

¿Hay obstáculos en tu camino?
• 

No es dar un stat...
Sprint review
•  El equipo presenta lo realizado durante el sprint
•  Normalmente adopta la forma de una demo de las nueva...
Sprint retrospective
•  Periódicamente, se echa un vistazo a lo que funciona y lo que no
•  Normalmente 15 a 30 minutos
• ...
Start / Stop / Continue
Todo el equipo se reúne y discute lo que les gustaría:

Comenzar	
  a	
  hacer	
  
Dejar	
  de	
  ...
Scrum framework
Roles	
  

• Product	
  owner	
  
• ScrumMaster	
  
• Team	
  
Reuniones	
  
• Sprint	
  planning	
  
• Sp...
Product Backlog
•  Los requisitos
•  Una lista de todos los trabajos
deseados en el proyecto
•  Idealmente cada tema tiene...
Ejemplo de Product Backlog
Backlog item

Estimación

Permitir que un invitado a hacer una reserva.
Como invitado, quiero c...
El objetivo del Sprint
Una breve declaración de cuál será el foco del trabajo durante el sprint

Ciencias	
  Biológicas	
 ...
Gestión del Sprint Backlog
•  Los individuos eligen las tareas
•  El trabajo nunca es asignado
•  La estimación del trabaj...
Ejemplo de Sprint Backlog
Tareas	
  

L	
  

M	
  

M	
  

J	
  

V	
  

8	
  

4	
  

8	
  

Codificar	
  negocio	
  

16	...
Hours	
  

Un Sprint Burndown Chart
Tareas	
  

L	
  

Codificar	
  UI	
  
Codificar	
  Negocio	
  
Testear	
  Negocio	
  
Escribir	
  ayuda	
  online	
  

M	
 ...
Escalabilidad
•  Normalmente los equipos son de 7 ± 2 personas
–  La escalabilidad proviene de equipos de equipos

•  Fact...
06
Reflexión
No son los procesos; son las personas
Contacto
Para localizar o contactar con ENCAMINA puedes:
Enviar un mail a:

Llamar al 902 196 893
962 698 064 o 917 90 67 ...
Partes de presentación basado en “Una Introducción a Scrum” de
Ernesto Grafeuille (2008)
Estas partes vienen con este avis...
ENCAMINA: ¿Quiénes somos y como trabajamos? - UPV noviembre 2013
Upcoming SlideShare
Loading in...5
×

ENCAMINA: ¿Quiénes somos y como trabajamos? - UPV noviembre 2013

1,589

Published on

Presentacion en la Universitat Politècnica de València en la asignatura del Máster Universitario en Gestión de la Información sobre ENCAMINA y como trabajamos. Se trata el “¿por qué?” de nuestra forma de trabajar inspirado por el hecho de que muchos proyectos TIC fracasan.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,589
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

ENCAMINA: ¿Quiénes somos y como trabajamos? - UPV noviembre 2013

  1. 1. 00 ¿Quién soy yo?
  2. 2. Iwan van der Kleijn I work and live in Valencia, Spain and have been here with my family since 2005. Now working for more than twenty-five years in the industry, I’ve kept myself busy as developer, analyst, IT architect, manager and Technical Director for companies like Capgemini, Sogeti, KPMG, Creyfs, Valoris and Exentric Thinking in the Benelux, United Kingdom and Spain. I am currently working as CTO at Encamina. I’ve an enduring interest in the integration of heterogeneous information systems, especially in the cross-cut between system and human interfaces. This is currently being rejuvenated by the possibilities offered and challenges posed by the integration of new client and server technologies: mobile applications, RIA, SOA & Cloud Computing.
  3. 3. Academia vs Business
  4. 4. 01 ¿Quiénes somos?
  5. 5. Nuestra forma de pensar Somos una consultora especializada en tecnología y productos Microsoft, que ofrece mejoras de competitividad a organizaciones medianas y grandes, mediante soluciones BI, ECM, CRM y BPM, a través del canal web, la nube y la movilidad empresarial. Nos apasiona trabajar desde el optimismo, con creatividad, en equipo, cuidando la experiencia de usuario y sintiendo que todos ganamos. Ser líderes en el ecosistema Microsoft para el ámbito nacional y algún día, un referente internacional en soluciones y servicios de nicho a través de la nube. Y queremos lograrlo con intensidad, desde el lugar donde más nos gusta vivir, con un equipo brillante, colaborando para clientes excelentes, y generando riqueza para nuestra sociedad, nuestros profesionales y nuestra empresa.
  6. 6. Nuestros valores Es la responsabilidad profunda que nos vincula a nuestros clientes, a nuestros proyectos, a nuestros compañeros y a ENCAMINA Trabajamos coordinadamente por intereses comunes en un ambiente de colaboración. Implica respeto mutuo, solidaridad, lealtad, amistad, generosidad, compartiendo los frutos del trabajo colectivo. es la capacidad de adaptarse con facilidad a las nuevas circunstancias o necesidades, reconduciendo las acciones oportunamente para lograr una mejor relación y entendimiento. Realizar el trabajo con vitalidad, alegría y ánimo, de forma que además nos satisfaga y nos divierta. Es enfocar los retos siempre desde el lado positivo. es la cualidad personal de anticiparse a los demás en hacer, decir o proponer algo. Es ser pro-activos, prever el futuro, proponer mejoras y encontrar soluciones. es el sentimiento que, emanando de uno mismo, nos compromete con nuestros actos y sus consecuencias. Es actuar de forma eficaz y eficiente, haciendo lo necesario para lograr los objetivos perseguidos.
  7. 7. Pensar en colores Es la actitud fresca, optimista y comprometida que utiliza el ingenio y la creatividad para encontrar soluciones de tecnología y talento que mejoren el presente de las personas, la empresa y nuestra sociedad.
  8. 8. 02 ¿Qué hacemos?
  9. 9. ¿Qué hacemos? Soluciones de Colaboración, Conocimiento e inteligencia de negocio. Soluciones CRM y enterprise Mobility ECM , BPM y BI SharePoint 2013 y Office 365 PerfornacePoint, SQL Server NINTEX workflow y AvePoint Consultoría específica MS Dynamics CRM y CRM on-line Multidispositivo-Multiplataforma HTML5 – CSS3 - JS – Sencha SharePoint EVERYWARE Marketing on-line y 2.0 Diseño web, Usabilidad / UX y AI Social Enterprise Soluciones CMS, WEB y e-commerce Arquitectura software y tecnología Arquitecturas SOA, Tecnología .Net framework AZURE Ingeniería de Sistemas Microsoft y virtualización
  10. 10. 13 años construyendo soluciones brillantes
  11. 11. Microsoft Partner del año Pyme 2013
  12. 12. Tagcloud de nuestro mundo tecnológico
  13. 13. Porqué somos buenos en SharePoint •  •  •  Estamos certificados en las competencias de Portals & Collaboration (Gold), Business Intelligence (Gold), Mobility, y Cloud. •  Desde el 2003, con la primera versión de Sharepoint, comenzamos a desarrollar soluciones de intranet y portales del empleado, portales de colaboración, portales de proveedores, gestión de contenidos, extranets, gestión de la Calidad e ISO-9000, gestión del talento, etc. Hemos utilizado MS Sharepoint 2003, los WSS3.0, MOSS2007, SP2010, SP2013 y SharePoint online/Office365 como framework de aplicaciones transaccionales e integrando otras aplicaciones en él. •  Hemos utilizado el SDK para pedirle más y lo hemos conectado a subsistemas externos como scanners, LDAPs, XML Web Services, etc. , así como aplicaciones externas (como MS Dynamics CRM, Project Server, etc.) Nuestras capacidades en arquitectura .Net, junto con el expertisse del producto, nos permiten proyectos de solución integral donde intervenga tanto la consultoría como la integración.
  14. 14. Cosas que hemos hecho con SharePoint ü  Como intranet y gestión del conocimiento de la empresa. ü  Como sistema de colaboración de grupos de trabajo. ü  Como plataforma para aplicaciones transaccionales de proveedores de la cadena de valor de la empresa. ü  Como sistema de gestión de proyectos con diversas organizaciones implicadas. ü  Como extranet de clientes donde gestionar los servicios con ellos. ü  Como sistema de gestión documental integrado con sistemas de scanner, distribución de información, etc. ü  Como help-desk de gestión de incidencias ü  Como cuadro de mando – BI de la organización. ü  Como plataforma .TV (integrada con Youtube.com) y como gestión de revistas integradas. ü  Como sistema de gestión de la Calidad (ISO) en la empresa. ü  Como portal web CMS y agenda de eventos con edición distribuida.
  15. 15. SharePoint Everyware mediante interfaces adaptativos / Responsive Logramos de SharePoint o cualquier otro sistema web un interfaz adaptativo o “responsive” mediante diseños específicos. Pero Enterprise Mobility – SharePoint EVERYWARE significa hacer que las aplicaciones, no solo sean responsive o adaptativas, sino que aprovechen todas las capacidades del dispositivo y el propio contexto del usuario cuando está en campo o bien fuera de la empresa.
  16. 16. Tecnologías SharePoint Everyware •  Para ENCAMINA, extender SharePoint y otros aplicativos empresariales a la movilidad implica desarrollar aplicaciones multidispositivo basadas en HTML5, JS y CSS3 aprovechando todas las utilidades y APIs que facilitan su arquitectura y desarrollo (como Sencha o Apache Córdoba-PhoneGap) y conectarlas, mediante SOAP, XML sobre HTTP o JSON a través de HTTP, con el ESB empresarial, o con otros servicios de la nube o nuestro típico broker facilitador de los servicios que ofrece SharePoint (o con SharePoint directamente). •  También la comunicación se da por la vía inversa mediante mensajes PUSH. Aplicación  d e   servidor Llamadas  s ervicio  web   JSON  (o  SOAP) Android Mensajes  “Push”  
  17. 17. Arquitectura de la solución SharePoint Everyware Servicios web ágiles y enfocados a las necesidades y aprovechando las capacidades de la información y servicios contenidas en SharePoint. Capa  SOA   Descarga solo la información a actualizar. Permite la interacción offline con el GPS del terminal Introduce nuevas posibilidades y servicios interactivos con los usuarios visitantes. Diferentes formatos y espacios de presentación de información en tablets y/o smartphones.
  18. 18. Ejemplo típico SharePoint Everyware: HelpingHand sobre HelpShare HelpingHand es la aplicación multidispositivo que permite trabajar autónomamente y de forma desconectada y ubicua al usuario, de cualquier role, con las incidencias y peticiones de HelpShare. HelpingHand está desarrollado en HTML5 pero el backend y master de todo el proceso y de la información central es una plataforma SharePoint en la nube pública o privada de la empresa. HelpingHand consume los servicios de SharePoint (personalizados en HelpShare) a través de un broker que simplifica el trabajo con las listas de SharePoint que se sincronizan e intercambian.
  19. 19. Algunas soluciones de empresa ECM BPM CRM WEB BI Intranet Gestión calidad ISO9000 y seguridad Fuerza de Ventas y Gestión de Campañas Portales web (CMS) PerformancePoint & PowerPivot & SQL Portal del empleado Solicitudes/autoservicio del empleado CRM para hoteles Aplicaciones web CMI hospitalario Comités y sitios de colaboración HelpDesk & Ticketing CRM para FARMA Usabilidad , diseño web y UX CMI de Operaciones Extranet clientes y proveedores Registro de Entrada CRM para asociaciones e-Commerce y TPV Plataformas de Reporting Gestión Documental Ciclo de Compras Encuestas on-line Comunicación web 2.0 Gestión de Proyectos con Project Server Hemeroteca y canal.tv Integración BPM con SAP E-mail Marketing (IMPACTO) Sistemas guía para consultoría Expedientes y proyectos con SharePoint
  20. 20. Pensar en colores: Pensar en personas
  21. 21. Pensar en colores: Pensar en participación con el cliente
  22. 22. Pensar en colores: Pensar en UX & Business & Tecnología integrado UX
  23. 23. Pensar en colores: Pensar en diseño integrado
  24. 24. Pensar en colores: Pensar en un equipo multidisciplinario
  25. 25. 03 Lo que no hablamos (y tampoco vamos a hablar) en ICT
  26. 26. No hablamos de él
  27. 27. Aunque deberíamos hablar de ellos
  28. 28. Metáforas equivocadas: no trabajamos así
  29. 29. Y tampoco trabajamos así
  30. 30. Aunque es posible que trabajamos en el “Code mine”
  31. 31. Seguro que no somos
  32. 32. Aunque podríamos ser Pero no es muy políticamente correcto
  33. 33. O, alternativamente
  34. 34. Lea acerca de esto en este libro
  35. 35. Como Brooks escribió en 1975 “...Computer programming, however, creates with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified…” “tractable” => Managable
  36. 36. 04 Hacer proyectos en ICT
  37. 37. Proyectos fracasados & ICT: historia “….In 1956, a group of computer scientists at IBM set out to build the world's fastest supercomputer. Five years later, they produced the IBM 7030 -- a.k.a. Stretch -- the company's first transistorized supercomputer, and delivered the first unit to the Los Alamos National Laboratory in 1961. Capable of handling a half-million instructions per second, Stretch was the fastest computer in the world and would remain so through 1964…… Nevertheless, the 7030 was considered a failure…..”
  38. 38. ¿Por qué fracasan los proyectos? “Fracaso" no sólo son "fallos catastróficos", sino también los retrasos, las grandes cantidades de errores, discrepancias con los requisitos de los clientes. Es decir: problemas que ponen en peligro los márgenes de los proyectos, la continuación del proyecto o incluso la continuación de la relación con el cliente
  39. 39. ¿Por qué fracasan los proyectos? Debilidades: ü  Cualidad de equipo y forma de trabajar ü  Cualidad de procesos ü  "Forma de trabajar" y "procesos" NO son sinónimos
  40. 40. ¿Por qué fracasan los proyectos? Algunas citas: “...Qué es una prueba unitaria / un "closure" / un interfaz ReST...” “…¿Cómo hacer pruebas unitarias / implementar un "closure" / diseño de una interfaz REST…” “…Yo no sabía que se suponía que debía hacer pruebas unitarias / utilizar un "closure" aquí / implementar un interfaz Resto…”
  41. 41. Estado y calidad de los equipos ü  Conocimiento es importante, pero también: ü  la actitud profesional, tal como ü  el pensamiento "out of the box" ü  En España el nivel no esta mal pero tampoco es extraordinario. ü  Contamos con equipos de programadores mas que ingenieros de software, “freakies” mas que aficionadas de tecnología
  42. 42. Debilidades en España ü  Organización jerárquica ü  No hay entorno estandarizado (hay procesos(!); bastante. Este no es problema) ü  No hay mentalidad de minimizar esfuerzo por automatización ü  No hay mentalidad de reutilizar trabajo ü  No hay visión arquitectónico / ingeniera de software ü  No hay visión "desde punta de visto de usuario" ü  No hay cultura de hacer pruebas. ü  NO solo los “managers” y “programadores”(!); es algo general y cultural
  43. 43. Pero más importante Al final del día los problemas críticos son genéricos y comunes en todo el mundo: ü  Incompetencia organizativa ü  Falta de comunicación, falta de saber "que hacer ahora"
  44. 44. Los problemas que se enfrentan al hacer proyectos ü  La falta de un modelo, un ejemplo, "saber qué hacer" ü  La falta de un léxico estándar, un vocabulario común sobre "qué hacer" ü  La falta de una manera común de entender "qué hacer”
  45. 45. Como un aparte ü  No hay soluciones mágicas. ü  Cualquier solución a los problemas antes mencionados es dependiente de la calidad de personas
  46. 46. Scrum como metodología de proyectos •  Scrum como posible solución •  Muchas alternativas: Kanban, DSDM, Lean, Extreme Programming, RUP (todavía) •  Pero Scrum es bien conocido, probada y adaptable •  Scrum no debería ser una ortodoxia, y muchas veces se convierte en uno(!)
  47. 47. 05 Gestión de proyectos: SCRUM
  48. 48. Scrum en 100 palabras •  Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo. •  Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). •  El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad. •  Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorándolo en otro sprint.
  49. 49. Scrum ha sido utilizado para: •  Software comercial •  Desarrollos internos •  Desarrollos bajo Contrato •  Proyectos Fixed-price •  Aplicaciones Financieras •  Aplicaciones certificadas ISO 9001 •  Sistemas Embebidos •  Sistemas con requisitos 7x24 y 99.999% de disponibilidad •  Joint Strike Fighter •  Desarrollo de video juegos •  Sistemas críticos de soporte vital, aprobados por laFDA •  Software de control satelital •  Sitios Web •  Software para Handheld •  Teléfonos portátiles •  Aplicaciones de Network switching •  Aplicaciones de ISV •  Algunas de las más grandes aplicaciones en uso
  50. 50. Características •  Equipos auto-organizados •  El producto avanza en una serie de “Sprints" de dos semanas a un mes de duración •  Los requisitos son capturados como elementos de una lista de “Product Backlog" •  No hay prácticas de ingeniería prescritas •  Utiliza normas generativas para crear un entorno ágil para la entrega de proyectos •  Uno de los “procesos ágiles”
  51. 51. El Manifesto Ágil – una declaración de valores Individuos  e   interacciones   So@ware  que  funciona   Colaboración     con  el  cliente   Responder     ante  el  cambio   sobre   Procesos  y   herramientas   sobre   Documentación   exhaus?va   sobre   Negociación  de   contratos     sobre   Seguimiento     de  un  plan   Fuente: www.agilemanifesto.org
  52. 52. Nivel de ruido de un proyecto Lejos  de     Acuerdo   Anarquía   Simple   Cerca  de   Certeza   Cerca  de   Acuerdo   Fuente:  Strategic  Management  and   Organiza0onal  Dynamics  by  Ralph  Stacey  in   Agile  So7ware  Development  with  Scrum  by   Ken  Schwaber  and  Mike  Beedle.   Tecnología   Lejos  de   Certeza   Requisitos   Complejo  
  53. 53. Scrum 24 horas Sprint 2-4 semanas Objetivo del Sprint Return   Gi@  wrap   Cancel   Product Backlog Sprint Backlog Incremento del producto potencialmente entregable
  54. 54. Poniendo todo junto
  55. 55. Enfoque: Sprint
  56. 56. Sprints •  En Scrum los proyectos avanzan en una serie de “Sprints” –  Análogo a las iteraciones en XP •  La duración típica es 2–4 semanas o a lo sumo un mes calendario •  La duración constante conduce a un mejor ritmo •  El product es diseñado, codificado y testeado durante el Sprint
  57. 57. Desarrollo secuencial vs. superpuesto Requisitos   Diseño   Código   Test   En  lugar  de  hacer  todo  de   una  cosa  a  la  vez  ...     ...los  equipos  Scrum  hacen  un   poco  de  todo  todo  el  ?empo   Source:  “The  New  New  Product  Development  Game”  by  Takeuchi  and   Nonaka.  Harvard  Business  Review,  January  1986.  
  58. 58. No hay cambios en un sprint Cambios •  Planee la duración del sprint en torno a cuánto tiempo usted puede comprometerse a mantener los cambios fuera del sprint
  59. 59. Scrum Framework Roles   • Product  owner   • ScrumMaster   • Team   Reuniones   • Sprint  planning   • Sprint  review   • Sprint  retrospec?ve   • Daily  scrum  mee?ng   Artefactos   • Product  backlog   • Sprint  backlog   • Burndown  charts  
  60. 60. Scrum framework Roles   • Product  owner   • ScrumMaster   • Team   Reuniones   • Sprint  planning   • Sprint  review   • Sprint  retrospec?ve   • Daily  scrum  mee?ng   Artefactos   • Product  backlog   • Sprint  backlog   • Burndown  charts  
  61. 61. Product Owner •  Define las funcionalidades del producto •  Decide sobre las fechas y contenidos de los releases •  Es responsable por la rentabilidad del producto (ROI) •  Prioriza funcionalidades de acuerdo al valor del mercado/negocio •  Ajusta funcionalidades y prioridades en cada iteración si es necesario •  Acepta o rechaza los resultados del trabajo del equipo
  62. 62. El ScrumMaster •  Representa a la gestión del proyecto •  Responsable de promover los valores y prácticas de Scrum •  Remueve impedimentos •  Se asegura de que el equipo es completamente funcional y productivo •  Permite la estrecha cooperación en todos los roles y funciones •  Escudo del equipo de interferencias externas
  63. 63. El Team •  Típicamente de 5 a 9 personas •  Multi-funcional: –  Programadores, testers, analistas, diseñadores, etc. •  Los miembros deben ser full-time –  Puede haber excepciones (Ej.: Infraestructura, SCM, etc.) •  Los equipos son auto-organizativos –  Idealmente, no existen títulos pero a veces se utilizan de acuerdo a la organización •  Solo puede haber cambio de miembros entre los sprints
  64. 64. Scrum Framework Roles   • Product  owner   • ScrumMaster   • Team   Reuniones   • Sprint  planning   • Sprint  review   • Sprint  retrospec?ve   • Daily  scrum  mee?ng   Artefactos   • Product  backlog   • Sprint  backlog   • Burndown  charts  
  65. 65. Capacidad  del   Equipo   Product   Backlog   Condiciones   del    Negocio   Sprint  Planning  mee?ng   Priorización   •  •  Tecnología   Obje?vo  del   Sprint   Planificación   •  Producto   Actual   Analizar  y  evaluar  el  Product  Backlog   Seleccionar  el  obje?vo  del  Sprint   •  •  Decidir  como  alcanzar  el  obje?vo  del   Sprint  (diseño)   Crear  el  Sprint  Backlog  (tareas)  en   base  a  los  temas  del  Product  Backlog   (user  stories  /  features)   Es?mar  Sprint  Backlog  en  horas   Sprint   Backlog  
  66. 66. Planificación del Sprint •  El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar •  Se crea el Sprint Backlog –  Se identifican tareas y cada una es estimada (1-16 horas) –  Realizado colaborativamente, no solo por el ScrumMaster •  El diseño de Alto Nivel es considerado COMO planificador de vacaciones, YO QUIERO ver fotos de los hoteles. Codificar  la  capa  intermedia  (8  hs)   Codificar  la  interfaz  de  usuario  (4)   Escribir  los  test  fixtures  (4)   Codificar  la  clase  foo  (6)   Actualizar  test  de  performance  (4)  
  67. 67. Daily Scrum •  Parámetros –  Diaria –  Dura 15 minutos –  Parados •  No para la solución de problemas –  Todo el mundo está invitado –  Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar –  Ayuda a evitar otras reuniones innecesarias
  68. 68. Todos responden 3 preguntas ¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Hay obstáculos en tu camino? •  No es dar un status report al Scrum Master •  Se trata de compromisos delante de pares 1 2 3
  69. 69. Sprint review •  El equipo presenta lo realizado durante el sprint •  Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente •  Informal –  Regla de 2 hs preparación –  No usar diapositivas •  Todo el equipo participa •  Se invita a todo el mundo
  70. 70. Sprint retrospective •  Periódicamente, se echa un vistazo a lo que funciona y lo que no •  Normalmente 15 a 30 minutos •  Se realiza luego de cada sprint •  Todo el equipo participa –  ScrumMaster –  Product owner –  Equipo –  Posiblemente clientes y otros
  71. 71. Start / Stop / Continue Todo el equipo se reúne y discute lo que les gustaría: Comenzar  a  hacer   Dejar  de  hacer   Esto es sólo una de las muchas maneras de hacer una retrospectiva. Con?nuar  haciendo  
  72. 72. Scrum framework Roles   • Product  owner   • ScrumMaster   • Team   Reuniones   • Sprint  planning   • Sprint  review   • Sprint  retrospec?ve   • Daily  scrum  mee?ng   Artefactos   • Product  backlog   • Sprint  backlog   • Burndown  charts  
  73. 73. Product Backlog •  Los requisitos •  Una lista de todos los trabajos deseados en el proyecto •  Idealmente cada tema tiene valor para el usuarios o el cliente •  Priorizada por el Product Owner •  Repriorizada al comienzo de cada Sprint Este  es  el  product   backlog  
  74. 74. Ejemplo de Product Backlog Backlog item Estimación Permitir que un invitado a hacer una reserva. Como invitado, quiero cancelar una reserva. Como invitado, quiero cambiar las fechas de una reserva. Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitación disponible Mejorar el manejo de excepciones ... ... 3 5 3 8 8 30 50
  75. 75. El objetivo del Sprint Una breve declaración de cuál será el foco del trabajo durante el sprint Ciencias  Biológicas   Aplicación  con  B.Datos   Funciones  de  apoyo  técnico   necesarios  para  estudios  de  gené?ca   de  poblaciones.   Hacer  que  la  aplicación  se  ejecute  en   SQL  Server,  además  de  Oracle.   Servicios  Financieros   Soportar  más  indicadores  técnicos  que   la  empresa  ABC  en  ?empo  real  y   streaming  de  datos.  
  76. 76. Gestión del Sprint Backlog •  Los individuos eligen las tareas •  El trabajo nunca es asignado •  La estimación del trabajo restante es actualizada diariamente •  Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog •  El trabajo para el Sprint emerge •  Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego. •  Actualizar el trabajo restante a medida de que más se conoce
  77. 77. Ejemplo de Sprint Backlog Tareas   L   M   M   J   V   8   4   8   Codificar  negocio   16   12   10   4   Testear  negocio   8   16   16   11   8   8   8   8   8   8   4   Codificar  UI   Escribir  ayuda  online   Escribir  la  clase  foo   Agregar  error  logging   12   8  
  78. 78. Hours   Un Sprint Burndown Chart
  79. 79. Tareas   L   Codificar  UI   Codificar  Negocio   Testear  Negocio   Escribir  ayuda  online   M   8   16   8   12   M   4   12   16   J   8   10   16   7   11   50   40   30   Hours   20   10   0   Mon   Tue   Wed   Thu   V   Fri   8  
  80. 80. Escalabilidad •  Normalmente los equipos son de 7 ± 2 personas –  La escalabilidad proviene de equipos de equipos •  Factores a tener cuenta –  Tipo de aplicación –  Tamaño del equipo –  Dispersión del equipo –  Duración del proyecto •  Scrum se ha utilizado en múltiples proyectos de más de 500 personas
  81. 81. 06 Reflexión
  82. 82. No son los procesos; son las personas
  83. 83. Contacto Para localizar o contactar con ENCAMINA puedes: Enviar un mail a: Llamar al 902 196 893 962 698 064 o 917 90 67 72 encamina@encamina.com info@encamina.com Visitarnos en: Enviar un fax al 962 698 063 Jerónimo Roure 49 46520 Puerto de Sagunto, Valencia. O hablar personalmente con: Paseo Castellana, 135 - 7º 28046 , Madrid, Madrid •  •  Hugo de Juan, CEO Jaime Camarasa, Técnico Desarrollo de Negocio
  84. 84. Partes de presentación basado en “Una Introducción a Scrum” de Ernesto Grafeuille (2008) Estas partes vienen con este aviso de Copyright: •  Usted es libre de: –  –  •  Compartir- copiar, distribuir y trasmitir el trabajo Modificar- adaptar el trabajo Bajo las siguientes condiciones –  Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo). •  Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor. •  Para más información ver http://creativecommons.org/licenses/by/3.0/
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×