Devoogle tiene indexados actualmente 18019 recursos relacionados con el desarrollo de software.
Have you ever wondered how large software companies with an engineering culture make sure they are able to deliver software over and over to production? How do you coordinate 100+ software engineers so that there are no bottlenecks and quality is not compromised?
In this talk you will see how a Continuous Delivery system was implemented at Criteo, the fastest growing IT company in EMEA 2012. Before starting the project there were 160+ code repositories with dependency hell. They were being built independently and releases to production were error prone and painful. You will see the technical architecture behind a successful implementation of a Continuous Delivery system. The system was made up of a Gerrit code review tool connected to a Jenkins build pipeline, building 160 repositories with over 7M lines of code.
We will explore different architectural choices such as branching system, hot fixes, sandbox and pre-production environments, and how these were developed and used by the large R&D department.
Authors: Adrian Perreau de Pinninck, Manu Cupcic
¿Por qué la adopción de Agile en tu empresa no está funcionando como te gustaría? ¿Qué es lo importante a tener en cuenta antes de empezar?
En esta sesión veremos factores críticos de éxito en una adopción Agile a nivel corporativo (es decir, empresas con centenares o miles de personas), fruto de la experiencia en diversos rollouts de Agile.
Empezaremos explicando Agile muy brevemente desde una perspectiva de impacto Corporate, de manera que nos ayude a entender por qué encontramos difícil su adopción en estos entornos, cuáles son los cambios que implica.
Seguiremos con una identificación de los aspectos a considerar ANTES de empezar en una adopción de Agile en la gran empresa. Hablaremos de la gestión del cambio, de cómo alinear a la gente, de cómo promover el cambio cultural y de las responsabilidades necesarias.
Valoraremos con la audiencia cuáles pueden ser nuestras posibilidades de éxito si no cubrimos esos factores críticos.
Finalizaremos recomendando cómo empezar esa transformación.
Esta es tu sesión si: (1) Eres el responsable de la adopción de Agile en tu empresa. (2) Eres CIO, CEO o Agile Coach. (3) Quieres entender cuáles son las dificultades en la adopción de Agile y cómo intentar abordarlas con éxito.
Autor: Xavier Albaladejo
Hace dos años, en la CAS 2012 en Cáceres, presenté junto a dos compañeros diseñadores una charla que se llamaba “Agile En Equipos Mixtos: Diseño Y Desarrollo – Amainando Tempestades”. Era un gran momento en el que empezábamos a trabajar de una manera que permitía sentirnos todos un mismo equipo.
Os quiero contar qué ha pasado desde entonces, con muchos proyectos juntos, mucha más experiencia y muchas más información. Es verdad que la tempestad se amainó, pero se crearon otras incluso aún más fuertes.
Porque el Diseño, tanto UX como Visual, son muy importantes en los desarrollos de hoy en día.
Es habitual que estas tareas del proyecto se gestionen con ‘waterfall’, como una fase previa y completa anterior al desarrollo.
Pero cuando se quiere realizar un cambio hacia formas de trabajo más ágiles, sea porque leímos LeanUX o porque creemos en la ‘Reducción del desperdicio’ nos encontramos muchos impedimentos e incluso puede que lleguemos a un punto de optimización máxima antes de lo que nos esperamos.
En esta charla veremos cómo podemos hacer esa transición, los pasos a dar y los diferentes problemas que nos podemos encontrar.
Destacaremos aspectos importantes, como el control del conocimiento del proyecto, las historias de usuario o la coordinación de tareas que son paralelizables.
Y por supuesto examinaremos cómo funcionan Scrum y Kanban en estos equipos y proyectos.
Autor: Antonio de La Torre
Presentación del Diagrama WaGI como herramienta para contextualizar y marcar las acciones requeridas por los diferentes actores involucrados para lograr una implantación exitosa de Agile en vuestra organización.
Autor: Raúl Herranz
Desde que hace año y medio comenzásemos a trabajar como una empresa de Desarrollo apps/web para Startups y emprendedores, aplicando metodología Lean Startup, nuestro primer problema fue transmitir a los clientes el valor del método y en qué consistía.
Tras muchos “enfrentamientos” con ellos, finalmente, nos dimos cuenta de que la estrategia Lean Startup y el método científico, en teoría, es muy fácil de entender, si nos basamos en la Ciencia y el Aprendizaje natural.
Por eso, desarrollamos una charla y una representación gráfica denominada LeanPanal, a través del cual intentamos evangelizar sobre lo que significa Lean Startup y cómo se implementa.
—
La charla propuesta se formará por 3 partes:
Introducción a Lean Startup
Aprendizaje
Crear – medir – aprender (ilustrado con Lean Panal)
Autor: Fernando Hidalgo Becerra
-
Si quieres hacer un producto que encante a tus usuarios y clientes, ¿para que te sirve un método de diseño y marketing de servicios?
Empecemos por ver qué entendemos por servicio y qué entendemos por producto. Ya te avanzamos que en diseño y marketing de servicios tenemos la teoría de que todo es servicio (aunque a veces se preste a través de productos). Se llama service-dominant logic. Y, estés o no de acuerdo, seguro que te interesa saber porqué para dar un buen servicio hay que dejar de trabajar en silos. ¿verdad que esto suena más familiar?
Pues el service blueprint es una herramienta que sirve para plantear cómo deberían coordinarse los distintos silos para proporcionar al usuario esa experiencia que le va a encantar y hacer volver. Pone en relación la experiencia del usuario con los recursos de la empresa. Y esto añade una profundidad muy interesante: entender qué implica proporcionar esa experiencia. Así que, como mínimo, el service blueprint te ayudará a tener conversaciones más significativas con tus clientes o con el resto de la empresa.
En esta sesión, hablaremos un poco del origen y el mindset del service blueprint, pero sobre todo lo pondremos en práctica. ¿Quieres hacer tu primer blueprint? Te esperamos.
Autores: Itziar Pobes, Marc García
-
Muchas veces hablamos del flujo de trabajo del equipo centrándonos en los Sprints, sus Daily stand-up, la importancia de la Demo, las sesiones de retrospectiva del equipo para seguir mejorando su trabajo, pero mucho antes que todas éstas hay una labor previa que lleva a cabo el Product Owner (PO), con el objetivo de que la visión del producto esté alineada con los Stakeholders (SHs), Management y así sea trasladada al equipo.
A medida que el equipo está desarrollando, en paralelo siguen apareciendo nuevas peticiones para el producto, que acaban en un backlog. En las sesiones de Backlog Review, el PO hace transparente el trabajo del equipo, el trabajo que él esta haciendo en ese momento, las necesidades que él tiene de los SHs y revisa las prioridades del actual backlog a las necesidades que todos los SH tienen en ese momento, solucionando conflictos de intereses y transmitiendo qué aporta más valor al producto en el que todos están involucrados.
En esta sesión quiero hablaros de cómo transcurre esta ceremonia, cómo facilitar la sesión, cómo elaborar un panel de visual management sobre el que trabajar las prioridades, cuáles son los pasos que hacen de esa ceremonia un éxito en el flujo de trabajo del equipo y principalmente, del PO.
Autora: Vanesa Tejada
-
Sin descripción.
I would like to present my experience introducing agile biz dev methodologies and design thinking in Telefonica Spain. I want to demonstrate that even in a big corporation with a clear focus in the short term and in optimization, these methodologies can have a place and can help business teams to design and develop products that customers want to buy.
I would also like to present our process and the keys to introduce these methods in a big company with real cases and examples of each phase (exploration, ideation, prototype/validation, execution)
Autor: José Manuel Pérez Prado