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.

2. 00
¿Quién soy yo?

3. 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.

4. Academia vs Business

5. 01
¿Quiénes somos?

6. 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.

7. 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.

8. 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.

9. 02
¿Qué hacemos?

10. ¿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

11. 13 años construyendo soluciones brillantes

12. Microsoft Partner del año Pyme 2013

13. Tagcloud de nuestro mundo tecnológico

14. 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.

15. 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.

16. 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.

17. 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”

18. 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.

19. 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.

20. 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

21. Pensar en colores: Pensar en personas

22. Pensar en colores: Pensar en participación con el
cliente

23. Pensar en colores: Pensar en UX & Business &
Tecnología integrado
UX

24. Pensar en colores: Pensar en diseño integrado

25. Pensar en colores: Pensar en un equipo
multidisciplinario

26. 03
Lo que no hablamos (y tampoco vamos a hablar) en ICT

27. No hablamos de él

28. Aunque deberíamos hablar de ellos

29. Metáforas equivocadas: no trabajamos así

30. Y tampoco trabajamos así

31. Aunque es posible que trabajamos en el “Code
mine”

32. Seguro que no somos

33. Aunque podríamos ser
Pero no es muy políticamente correcto

34. O, alternativamente

35. Lea acerca de esto en este libro

36. 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

37. 04
Hacer proyectos en ICT

38. 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…..”

39. ¿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

40. ¿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

41. ¿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…”

42. 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

43. 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

44. 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"

45. 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”

46. Como un aparte
ü No hay soluciones mágicas.
ü Cualquier solución a los problemas
antes mencionados es dependiente
de la calidad de personas

47. 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(!)

48. 05
Gestión de proyectos: SCRUM

49. 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.

50. 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

51. 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”

52. 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

53. 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

54. Scrum
24 horas
Sprint
2-4 semanas
Objetivo del Sprint
Return
Gi@
wrap
Cancel
Product
Backlog
Sprint
Backlog
Incremento del producto
potencialmente entregable

55. Poniendo todo junto

56. Enfoque: Sprint

57. 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

58. 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.

59. 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

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. 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

62. 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

63. 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

64. 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

65. 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

66. 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

67. 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)

68. 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

69. 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

70. 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

71. 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

72. 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

73. 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

74. 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

75. 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

76. 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.

77. 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

78. 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

79. Hours
Un Sprint Burndown Chart

80. 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

81. 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

82. 06
Reflexión

83. No son los procesos; son las personas

84. 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

85. 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/