He venido en avión desde los EEUU, desde Seattle Washington
Si esto fuera un mapa de los EEUU sería la esquina superior izquierda, ahí arriba.
Soy un consultor de procesos de negocio allí.
Después del trabajo construyo coches con un grupo llamado Wikispeed
Construimos un coche de pasajeros ultraeficiente y seguro. El primer prototipo fue construído en sólo 3 meses.
¿Cómo es posible esto si los fabricantes actuales realizan modificaciones de manera tan lenta?
Aquí vemos un coche sedan híbrido muy popular. Vemos como en un período de 6 años
ganó 2 millas por galón, o 0.3 litros por cada 100 km usando el sistema germánico de medida
Tiene un orificio de ventilación en la parte delantera, luego dos y luego uno de nuevo
y esto son la mayoría de los cambios. Este es el ritmo de cambios que hemos visto en los automóviles
Los fabricantes actuales realizan cambios de manera lenta porque el coste de hacer cambios es altísimo
Mañana, Román que esta sentado aquí con nosotros, dará una charla acerca de porqué resulta tan caro
realizar cambios en la industria del automóvil, y como ello ralentiza la innovación.
En este caso tenemos una plancha de aluminio que esta siendo convertida en una puerta
esta pertence al nuevo modelo de Tesla en la fábrica de California. Acaban de construir esta fábrica.
Y la máquina que hace presión se llama troquel de hierro. Este troquel tiene un coste de 10 millones de USD
Esto implica que si mañana un ingeniero quiere hacer una puerta más económica, segura o ergonómica la compañia no le dejaría
Le harán esperar hasta que hayan vendido suficientes productos como para pagar el troquel existente antes de hacer uno nuevo
Este el el modo en que los equipos de software solían trabajar.
Siguiendo el modelo anterior se recopilan los requisitos, luego se realiza el diseño
que se implementa y luego se verifica el diseño y se mantiene la "release".
Esta es la única parte donde se vende algo y hay beneficios.
Así en la manufactura y los equipos de software tradicionales intentaran alargar al máximo posible esta fase
No quieren desarrollar nada nuevo ya que sólo obtienen beneficios en esa fase.
Los nuevos productos se desarrollan acorde a lo que los ingenieros pensaron que sería mejor para el cliente hace 10 años al inicio de este ciclo
Los nuevos equipos de software hacen lo mismo pero repiten el ciclo cada 7 días
Esto se llama Agile.
Se realizan estos procesos en un ciclo rápido y hablaremos más acerca de las prácticas que hacen que esto suceda
Desarrollo rápido iterativo. Esto es lo que el Team Wikispeed hace
En vez de cambiar nuestros coches con modificaciones menores cada 2.5 años
y un cambio significativo cada 5 o 7 años
nosotros reinventamos nuestro coche cada 7 días
La única manera en que esto es posible es si tratamos al coche como si fuera software
Lo hacemos modular
Dividimos el coche en 8 piezas
que se pueden separar de manera rápida
Tenemos que reducir el coste de hacer cambios.
Cada parte del coche puede ser cambiada en lo que se tarda en poner un neumático.
Así podemos cambiar el módulo del motor de gasolina a eléctrico como si cambiáramos una rueda
Podemos cambiar el "chasis" de un deportivo a una furgoneta. Esto nos permite hacer cambios y pruebas muy rápidamente
y nuestros clientes una flexibilidad que no conocían con los coches. Si necesitan cambiar su vehículo cambia con ellos.
Esto nos permite iterar el coche entero en pocas horas. Podemos separarlo en sus 8 piezas
cambiarlas y volver a montarlas en cuestión de horas.
Lo llamamos Extreme Manufacturing (Manufactura Extrema) o XM
XM es lo que ocurre cuando tratamos a los objectos físicos como si fueran software
y seguimos las mejores técnicas que se conocen en el software
Desarrollo Agile haciendo cambios iterativos cada 7 días.
Modularidad: el coche esta compuesto por 8 partes basado en la programación orientada a objetos
donde el programa se genera a base de objetos en vez de como un único módulo.
Usamos menos material siempre que podemos. Aquí hay una placa de Arduino que estamos prototipando
para poder remplazar toda la electrónica del coche. Si uno piensa en un coche actual y el número de microcontroladores
que hay dentro del coche: para el airbag, para el aire acondicionado, para recopilar información de incidencias,...
para la gestión del motor, para el sistema de entretenimiento, ... es muy complejo
Hay muchas oportunidades para que el coste de realizar cambios sea alto y altos costes de mantenimiento
Lo hemos simplificado para usar microcontroladores de código abierto y muy económicos.
En un tour con Tomás del FabLab, me ha mostrado donde hacen sus propias placas Arduino.
Estas placas que nosotros usamos en el coche se pueden fabricar en la habitación de al lado.
por la gente que viene a experimentar y crear en el FabLab
Esto está en desarrollo y aún no está hecho para el Team Wikispeed. Estamos de hecho buscando a gente interesada en Arduino
para trabajar con nosotros y desarrollar estos módulos para ser usados en el coche.
Usamos Agile para reducir el coste de hacer cambios. Si fueramos Agile por cualquier otra razón
sería una cosa limpia y divertida que ayudaría a la moral del equipo. Pero el valor de Agile para nosotros
es que lo usamos para reducir el coste de hacer cambios y podemos tener iteraciones de 7 días en vez de 2.5 a 7 años
que es lo habitual en la industria del automóvil. Por ejemplo Porsche ha dicho públicamente
que la generación actual del Porsche 911 no va a sufrir grandes cambios en los próximos 14 años
Algunas partes de ese coche fueron diseñadas en los últimos 3 años, otras en los últimos 11 años.
Si vas a un concesionario Porsche podrás comprar un Porsche 911 nuevo que incluirá partes pensadas hace 25 años.
Trabajamos en equipos colaborativos y distribuidos porqué nos dan resultados de manera más rápida.
Con ello quiero decir que la gente trabajanda a la vez en la misma solución y ayudándose se vuelven multifuncionales
Para ello hay una metodología llamada SCRUM, que también viene del mundo software y empieza a aplicarse fuera del software
SCRUM es la manera más rápida y limpia de organizar equipos colaborativos
SCRUM define roles y responsabilidades, de los que hablaremos durante el workshop tras esta charla
Hacemos todo nuestro trabajo en parejas, siempre hay como mínimo dos personas haciendo una tarea.
Lo que permite el intercambio de conocimiento en todo momento. Si alguien tiene gemelos y no pueden trabajar
con el equipo durante algunas semanas o meses, la información que llevaron al equipo no se pierde porque siempre trabajaron en pareja
Y la gente de la pareja rota entre las tareas. Aqui tenemos Martin Bell y Curt Roy construyendo uno de nuestros motores
Esto implica que al acabar de fabricar un nuevo motor tenemos al menos una persona más que sabe como construirlos
No tenemos formación en cómo construir un motor, no tenemos que documentarlo y mantener la documentación.
De hecho tenemos muy poca documentación porque hacemos nuestro trabajo en parejas
Esto ayuda a eliminar tiempo de formación que de hecho no es productivo. En este caso toda la formación se hace mientras se construyen productos que vamos a usar.
Esto viene de Extreme Programming (XP) del mundo software donde se formalizó el concepto de parejas y enjambres
Nada de esto es nuevo. Trabajar en parejas ya lo hacían los aprendices, pero Extreme Programming formalizó el mínimo necesario para obtener el valor de emparejarse
y lo hace de una manera muy simple y ligera.
- Mary Poppendieck, comentarios?
- Guau! [risas]
Algo que hemos observado en Team Wikispeed es que la moral es un multiplicador de la velocidad
Y no sólo porque hace que el equipo vaya más rápido. Lo que hemos observado es que es un multiplcador para nuestros resultados
Nos focalizamos en la moral del equipo como si el equipo fuera el cliente. Para cada persona del equipo tenemos tareas en el "backlog" para hacerlos contentos
Si alguien quiere aprender gestión de proyectos, como moldear aluminio o trabajar con fibra de carbono y trabajar con gente en otros paises
Tenemos tareas en el "backlog" para ello, para deleitar a nuestro equipo. Con ello mantenemos la velocidad que nos permite tener una mayor productividad
Ellos son Mary y Tom Poppendieck, autores de "Lean Software Development" y otros famosos libros
"Lean Software Development" fue el primer libro que yo leí en gestión de proyectos con Agile. Ellos fueron los que me metieron en esto.
y son mis héroes. Tuve la suerte que visitaran el garaje de Wikispeed donde yo trabajo y que fueran a dar una vuelta en el coche
Es como encontrarte con tus héroes, maravilloso para mí.
Visualizamos todo nuestro trabajo para evitar perder tiempo en nada que no sea resolver problemas de manera creativa
Cuando no estamos solucionado problemas de manera creativa estamos tirando tiempo a la basura.
Para visualizar nuestro flujo de trabajo y estar seguros que estamos optimizando la solución creativa a los problemas
usamos una herramienta llamada KANBAN. Kanban es la palabra japonesa para "pequeño tiquet" o "pequeña carta"
KANBAN es una metodología para visualizar tu trabajo con múltiples tarjetas. Literalmente usamos post-its y rotuladores
, si se escribe en lápiz resulta complicado de leer desde lejos, y vemos nuestro flujo de trabajo delante de nosotros
KANBAN tiene muchas prácticas y herramientas associadas para optimizar el flujo, como de rápido se consigue hacer avanzar el trabajo
KANBAN esta siendo adoptado por las compañías de software con mayores beneficios. Los equipos de software que usan KANBAN reportan mayor flujo
por trabajador que otros equipos. Dramáticamente superior. Ahora lo usamos fuera del software y Team Wikispeed esta proponiendo la idea de
ver que ocurre cuando tratas el hardware como software y estamos teniendo éxitos importantes con ello.
Este es el primer prototipo de Wikispeed que cumple las normas para circular. No es muy bonito.
Pero tiene bocina, luces frontales, intermitentes, estructura para absorber choques (cumpliendo con todas las normativas relativas a choques)
tiene un habitáculo, luces traseras en la esquina, aire acondicionado, calefación, anticongelante y un sistema de audio.
Es la versión más simple que pudimos pensar que nos permitiera realizar tests en la carretera de manera legal.
Lo hicimos sin ninguna planificación. Otras compañías empezarían con un plan: ¿cuánto va a costar? ¿dónde lo voy a construir? ¿quién lo va a construir?
y qué materiales voy a usar? Nosotros no hicimos nada de eso
Mientras ellos aún estaban haciendo eso nosotros creamos un conjunto de tests para saber si cumplíamos con la regulación
Creamos test para el impacto lateral, frontal, el volcado, simulación para la ergonomía
y los describimos como historias de usuario: como conductor puedo ir al trabajo con un consumo de 100 millas por galón
o 2.5l por 100 km en función de los ciclos de test. Este era el ciclo germánico.
Y luego en vez de planificar como pasar esos tests corrimos para construir la cosa que fuera más barata y veloz
en que pudiéramos pensar y que pasara esos tests. El resultado fue poco convencional pero lo teníamos rodando en la calle en sólo 3 meses
Wikispeed SGT01 se aleja del stop en el exterior del edificio en Michigan.
conducido por Bryan Ford con Joe Justice. Joder! ha desaparecido!
Ocurrió algo más. Descubrimos que eramos capaces de fabricar un coche muy eficiente y rápido.
Y lo pudimos verlo muy temprano así que pudimos quedarnos con las partes que lo hacían veloz.
También pudimos satisfacer a los clientes y accionistas antes. Cuando sólo teníamos partes de un coche
ya podíamos tener a gente conduciéndolo y recibir sus reacciones y comentarios para mejorar en el próximo ciclo
[Risas] Si señor! ¿Qué piensas tras conducir el coche? Muy probablemente el coche más rápido que he conducido. Increíble!
Es como una roca, sobretodo con la segunda marcha parece que las ruedas delanteras se levantan del suelo
No tengo palabras. Es asombrosamente rápido!
No está mal por un coche que fue diseñado para ser eficiente.
No entra en la cabeza! La eficiencia no tiene porqué ser aburrida. Esto está claro y este coche es un cohete.
No se si oyó claramente. Una de las cosas que dijo fue "probablemente el coche más rápido en el que he estado".
Eso fueron comentarios fantásticos y desde ese momento ha trabajo centenares de horas con el equipo.
Al tener un producto muy rápidamente podemos hacer pre-venta, pedir inversiones y construir nuestro equipo de voluntarios.
El es Rob Beresford, que vive en Washington y ha abierto su propio taller Wikispeed.
Esta es la versión final del coche que se construyó en 3 meses y con el que participamos en una carrera de coches ultraeficientes: "Progressive insurance automotive X Prize"
Había 136 coches, en total, de alrededor de todo el mundo. Al final no ganamos.
Quedamos décimos en la categoría principal, superando compañías muy reconocidas como Tata Motors en India,
MIT en EEUU, Tesla Motors en EEUU. Pudimos competir con compañías y universidades globales con muy buena financiación
aunque sólo eramos voluntarios trabajando por la noche y los fines de semana con un presupuesto muy limitado.
El coche, de nuevo, no es bonito. Lo llamamos "La caja naranja de zapatos"
Pero tiene un perfil aerodinámico. Esto es una forma aerodinámica naca, como predecesor de nasa.
Luego sube con la dorsal y acaba con otra forma naca en la parte trasera, aunque por el ángulo de la cámara no se puede apreciar.
Nos preocupamos mucho del perfil aerodinámico. La mayor parte del coche no hace más de 2 pies de alto, unos 70 cm
Así que no hay mucha área frontal dónde el aire pueda impactar.
Pero queríamos algo más bonito. Al año siguiente, alguien con quien no me había visto antes, creó un nuevo diseño
que encajaría encima de la misma mecánica con la que hemos construido varios coche.
Fue Robert Mohrbacher quien dibujó el cuerpo del coche en CAD, modelado 3D, con un software fantástico que cuesta 149$ USD
y podemos hacer ingeniería automotriz con él. Luego Bryan Ford con quien no me había encontrado hasta poco antes ese mismo año
construyó este coche en otro estado sin mí. Ellos clonaron e hicieron el proyecto en código abierto ubicándose en Hillsdale Michigan.
Luego obtuvimos este otro diseño, otra vez de Rob Mohrbacher, aunque recibimos muchos otros de gente alrededor del mundo.
Nos encantó y lo construimos. La primicia fue hace 3 meses en el evento Agile 2012 en Texas en los EEUU.
Este fue el primer Wikispeed "roadster". Allí estoy yo muy contento por ello.
El Wikispeed "roadster" fue construido en 3 horas por un grupo de voluntarios que no habían hecho nada con el equipo antes
En la conferencia preguntamos: ¿Quién quiere usar Agile para construir un coche muy rápidamente?
Unas 23 personas se interesaron. [pregunta del público]. Para el workshop de después pedí un pieza de aluminio para que podamos construir un coche?
pero dijeron que no era posible... pero lo que haremos es simular el proceso. Al final del workshop tendréis suficiente
información como para construir vuestro propio coche Wikispeed
Si es lo que queréis hacer, y lo hacéis.
Así que estas gente sin experiencia previa se aparejaron con nosotros que si teníamos experiencia.
A ver si me puedo ver en la imagen. Aquí hay Emre Aras de Turquía. Él había construido partes del coche antes y se emparejó con 3 personas que no sabían
No les dio ningún manual ni les mostró ningún vídeo. Aprendieron haciéndolo.
Ni tan sólo les dice lo que deben hacer. Simplemente lo hace y les dice, "hacedlo conmigo"
¿Quién más era parte del equipo? Esta cabeza parece de Tom Taber o puede que no... Clay está aquí
y yo estoy allí. Al menos hay 4 personas que habían construido coches antes.
¿Tom Taber está en la imagen? Si allí está con este grupo.
Y en 3 horas tuvieron lo que llamamos un "chasis rodante". Un chasis completo con cuatro suspensiones y un cuerpo.
En 3 horas no construyeron un módulo motor o el interior pero si un "chasis rodante"
Esa gente pueden ahora construir su propio coche Wikispeed porque se emparejaron con el equipo
Y sólo estuvieron 3 horas con nosotros. Si pensáis lo rápido que podemos absorber nueva información con la metodología Agile
es un ritmo muy elevado para hacer cambios. En software fue revolucionario. Grandes proyectos se completaban más rápido de lo nunca se había hecho
Eran más cercanos a lo que el cliente quería porqué el cliente colaboró durante todo el proceso y también eran más baratos.
Pero era difícil de ver lo importante que era si no eras un desarrollador de software no podías comprender la complejidad y el tamaño de manera inmediata.
Cuando lo hicimos con un coche empezó a ganar atención fuera del software porqué la gente podía ver cosas muy complejas como, coches
se pueden construir, actualizar e iterados muy rápidamente. El coche es a prueba de futuro porqué el módulo del motor se puede cambiar
no se si la nueva tecnología para el transporte será con células de hidrógeno, electricidad, biodiesel o metanol
o si seguirá siendo gasolina. Pero no tengo que preocuparme por ello ya que puede intercambiar el motor sin tocar el resto del coche.
Es la mejor manera de reciclar. Deseo que más productos, edificios y aparatos electrónicos adopten esta idea de plataforma y modularidad.
para impedir escasez artificial e impedir tener que tirar objetos aún utilizables sólo porqué una parte se ha quedado obsoleta
Tenemos equipos Wikispeed en 18 países. Hay más de 150 miembros en el equipo y aquí en la sala tenemos a Saket y Román del equipo de Team Wikispeed Barcelona
Ello significa que son voluntarios, al menos 2 horas a la semana. Esto es lo que significa ser voluntario de Team Wikispeed.
Al menos 2 horas a la semana estaré haciendo trabajo para Wikispeed. Miran al "backlog" de lo que se tiene que hacer
y buscan algo que les apetezca hacer o que ya saben hacer. ¿Hay alguien mas que ya sea Team Wikispeed Member?
¿Alguien que quiera serlo en el futuro? Muy bien! Veremos como va durante el workshop. Sería fantástico.
Nuestra oficina más nueva era Nueva Zelanda liderado por Stephan Sohnchen en Christchurch y hay otro grupo en Wellington pero no tienen un local
para construir el coche. Pero creo que nuestro nuevo espacio será aquí mismo. Hablando con Tomás del FabLab antes de la charla. ¿Podríamos poner un coche aquí si la gente quiere construir uno?
Él dijo que depende de quién lo va a conducir, qué tipo de motor va a usar por tema de regulación,...
y yo dije: ¿pero, hay espacio? Si resolvemos esas cosas, ¿hay espacio? Él dijo que sí.
Así que ya estoy imaginando el backlog de tareas para seguir las regulaciones del FabLab como qué tipo de tren motriz debemos usar.
Esos tests se mueven, del mismo modo que tareas para construir el chasis, diseñar el próximo molde, saber que tipo de interior es mejor para la gente de Barcelona
así puede reflejar donde se construye.
Las herramientas que el Team Wikispeed usa son gratuitas y ninguna existía hace 10 años.
Hubiera sido difícil o imposible hacer lo que hacemos del modo en que lo hacemos sólo 5 años atrás. Ahora es posible porqué estas herramientas son muy
poderosas para la colaboración distribuida. También usamos paquetes de CAD. Mucho del trabajo se hace con Google Sketchup que es gratis
Parte del trabajo se hace con Alibre Design. Un paquete de CAD cuestan entre 10.000 y 14.000 USD o más. CATIA cuesta más de 100.000 USD por usuario
Alibre cuesta 149 USD por usuario. Estandarizamos en soluciones económicas si tenemos que pagar.
John Deere es un grupo de ingeniería mecánica, con base en Moline Illinois EEUU
Es uno de los mayores fabricantes de maquinaria agrícola del mundo. John Deere vio Wikispeed en una revista
y me invitó a sus oficinas. Cuando estaba allí hablé del mito de la predictibilidad. John Deere ha hecho tractores
por más de 175 años. Lo saben todo acerca de como construir tractores. Recientemente se ha publicado
un estudio sobre lo que se tarda en fabricar un tractor. Ni John Deere es capaz de saber cuanto se tarda
aunque llevan 175 años haciéndolo. Algunos hablando de Agile pregunta: ¿cómo sabéis cuando vais a terminar?
Nosotros estimamos con ciertos métodos. En la gestión tradicional de proyectos sabemos que tenemos una fase de requisitos, la fase de diseño, la fabricación y el mantenimiento.
Y sabemos lo que duran esas fases así que no hay adivinación o estimación, pero resulta que siempre se equivocan.
E incluso compañías que llevan 175 años haciéndolo tampoco son más precisas que las estimaciones en Agile.
Hablamos de productos Open Source como este tractor Open Source del proyecto Open Source Ecology.
OSE están fabricando un conjunto de 50 máquinas para poder construir y mantener el nivel actual de civilización.
Todo Open Source. Si lo consiguen la gente podrá construir si tractor open source, horno de pan, máquina de circuitos,
colector lineal de energía solar y más. Han prototipado 13 de las 50 máquinas y las están mejorando todas.
Este tractor modular cuesta mucho menos de lo que cuesta un tractor de John Deere. John Deere conoce a OSE
y están intentado entender cómo es posible. ¿Cómo se hace un tractor modular? ¿Cómo se hace colaborar a gente de todo el mundo en un único producto?
John Deere lo hace pero es muy caro. Se preguntan ¿cómo se hace tan económico y rápido?
Ahora estan trabajando en ese tipo de proyectos con Team Wikispeed.
Boeing, en Mulkiteo Washington en los EEUU es uno de los mayores fabricantes de aviones del mundo.
Hicieron un tour al Team Wikispeed en la línea de fabricación del nuevo 787 Dreamliner.
También construyen el 777, aviones de largo alcance en la línea adjunta y el 767. También contamos con representantes de la división de aviones militares.
Este es el edificio cerrado más grande del mundo donde se han llegado a crear nubes en su interior.
Nos dijeron que había llovido dentro del edificio. Hablamos con ellos acerca de MakerPlane, un grupo de gente
que construyen un avión ligero de pasajeros con metodologías Agile. Dicen que se inspiraron en Wikispeed.
Y parece que lo están haciendo usando Agile para resolver de manera rápida los problemas de fabricar aviones ligeros
Boeing está fascinado por este desarrollo rápido y trabajo colaborativo. Una persona con dos doctorados y 15 ejecutivos vinieron
al taller de Wikispeed y nos invitaron a una cena en el garaje, que no es mucho mayor que este espacio.
y mucho más pequeño que su edificio. Su doctor en dinámica de fluidos computacional y análisis de elementos finitos dijo
"las herramientas que Boeing usa son más complejas pero Wikispeed está años luz por delante en términos de cultura"
Las herramientas que Team Wikispeed usa y las que usa Boeing o John Deere no son tan diferentes.
Wikispeed usa versiones más pequeñas y económicas. Pero las herramientas de prototipado rápido, como las que hay aquí en el FabLab, existen y la gente las conoce.
Aún con todo el tiempo para desarrollar nuevos productos se ha alargado en muchos casos y el rendimiento de los activos,
el dinero que las compañias obtienen de sus herramientas, va para abajo año a año.
Hacen menos dinero por cada activo que en el pasado. Están observando plataformas como esta con mucho interés
y viéndolo como el futuro del comercio y el desarrollo de nuevos productos.
Tait Radio en Christchuch, Nueva Zelanda hace esto: estaciones base de radio, para poner en racks de servidores
Encriptan las señales de radio y las retransmiten a mayor distancia para la policía, los militares, las ambulancias, los bomberos y servicios sociales.
Un colega mio, Tim Myer y yo, fuimos llevados a Nueva Zelanda con la tarea de montar un equipo como Team Wikispeed allí.
Pusimos a todos aquellos involucrados en la fabricación de las radios en una sala: marketing, gestión de producto, ingeniería de hardware, software de aplicaciones,
software embebido y fabricantes de varios chips y placas base. Llevaron todas sus herramientas.
Hay piezas de estaciones base, simuladores para las estaciones, para los circuitos, equipo de diagnóstico... en la misma sala.
Luego pusimos, haciendo la mejor estimación, todas las tareas necesarias para fabricar una radio.
Se asumió que se aprendería haciendo camino aunque lleven más de 60 años haciendo radios.
Habrías nuevas cosas, pero la lista inicial en notas post-it para moverlas de izquierda a derecha usando KANBAN.
El equipo empezó el lunes y el cliente de prueba uso el primer prototipo el viernes.
No habían hecho nada así antes. Fue el ritmo de desarrollo más rápido experimentado jamás ya que usaron Agile, como en software, para el hardware.
Tait Radio ya hacía muchas cosas bien. En esta sala tienen una prueba de fijación y está justo al lado de la línea de montaje.
Así que construyen las radios y otros equipos. Esta máquina sostiene circuito de modo que puede tocar dos cables al mismo tiempo y tener una luz roja o verde
para saber si funciona o no. Hacen varios tests y tienen configuraciones diferentes para sostener el circuito en la posición correcta.
Para los tests usaron un primer modelo hecho en cartón y papel de aluminio, lo mismo que hace Team Wikispeed.
Empezamos con algo simple y fácil de cambiar y luego. Una vez saben el tamaño y la forma que quieren lo hacen en aluminio y
están al lado de la línea de montaje por lo que pueden hablar y ver al cliente al mismo tiempo que lo hacen.
Para más información sobre Agile, SCRUM, Lean y Extreme Manufacturing podéis contactor con mi trabajo diurno: Solution IQ
Esta es la parte comercial de la presentación.
Durante el día vuelo a esas compañías y organizo este tipo de equipos. Más información en SolutionsIQ.com
Si conocéis alguna compañía interesada en este tipo de servicios, es por lo que me pagan.
Por la noche y los fines de semana, cuando hago de voluntario en Team Wikispeed, esto es lo que ocurre.
Hemos hablado de modo teórico sobre la metodología Agile y la modularidad, pero pasemos a ser concretos.
Aquí tenemos una iteración de seguridad para hacer el coche seguro. Primero escogemos el test que vamos a pasar.
En este caso es el Test de la NHTSA para impactos laterales. Primero hacemos un modelo del test.
Este modelo muestra la barra de impacto, en azul, chocando con un modelo de nuestro chasis
Los colores muestran donde habrá estrés y la deflexión en el chasis cuando ocurre el impacto.
Veréis que no hay penetración en la cabina en el impacto lateral, no se tuerce para nada pudiendo tocar al conductor o al pasajero
También veréis que, en rojo que muestra la máxima absorción de energía, hay rojo en un lado pero también en el opuesto.
Es capaz de comunicar la carga y es lo que podemos simular. Incluso con una estructura ligera, toda la estructura absorbe el golpe.
Luego hacemos un test físico. Este test nos cuesta 10.000 USD cada vez que lo hacemos, más el coste del coche y el coste de transportar el coche al centro de test
No podemos hacer esto cada semana pero hacemos sprints de 7 días ¿Cómo podemos comprobar que somos seguros?
Usamos este test para hacer nuestras simulaciones más precisas y luego confiamos en nuestras simulaciones cada semana.
Cuando nos lo podemos permitir hacemos el test, pero este test no es nuestro camino al éxito.
Las simulaciones si que lo son y usamos el test para hacer nuestro test económica más preciso. En este test tuvimos penetración lateral
nuestra simulación no era del todo precisa. Tuvimos 10 cm de penetración lateral y pudimos pasar el test
pero no nos dio la máxima puntuación que es lo que queríamos. A las pocas horas de mandar el vídeo al equipo
un padre e hijo voluntarios habían construido un nuevo modelo para el impacto lateral y lo habían montado en uno de los coches
Como los coches son modulares podemos montar ese la estructura lateral a cualquiera de los coches que hemos construido.
En pocas horas teníamos una actualización del diseño. La primera vez que hicimos esta iteración consumieron varios meses
ahora lo hacemos en una semana. Aquí tenemos una iteración de la estética para hacer el coche más bonito.
Ya hemos visto que la seguridad con ciencia compleja se puede cambiar rápidamente. Pero ¿podemos hacerlo bonito?
Primero empezamos con un dibujo 3D, CAD. Aquí hay una de las vistas del diseño de Rob Mohrbacher que llamamos el "Coche de carrera de Lemans"
Muy aerodinámico y con mucho en común con la "caja naranja de zapatos" que hemos visto antes.
Nunca le había encontrado en vivo. Diseño este cuerpo para encajar con nuestro bastidor y mecánica actuales.
Nos gustó y lo cortamos en espuma con una máquina controlada por computador (CNC) en un día.
En un día teníamos una versión a escala real y podíamos dar vueltas alrededor y explorarlo.
Al día siguiente pusimos fibra de carbono. Luego fuimos a la mayor feria de automóviles del mundo
y estábamos aterrorizados. No sabíamos como la industria automovilística reaccionaría a algo que se había hecho tan rápido en los garajes de la gente
con un prepuesto casi nulo. Fuimos a la feria del automóvil más importante del mundo en enero de 2011 y por suerte el coche era precioso.
Nos pusieron en la parte principal, entre Ford y Chevrolet.
Luego nos filmó Discovery Channel. E hicieron un mini-documental acerca de Wikispeed prototipando de manera rápida los coches.
Luego usamos ese vídeo de Discovery Channel para lanzar una iniciativa de crowdfunding para financiar la próxima iteración del desarrollo
La primera vez tardamos meses, ahora lo hacemos cada 7 días.
Este coche hace 100 millas con un galón
Este coche es completamente modular, desde el cuerpo hasta el motor.
Se puede convertir en un biplaza descapotable, un familiar con 4 plazas o una furgoneta.
Hemos liberado online todos los planos para poder fabricar el coche.
Este coche es rápido
100 millas por galón y es asombroso como corre!
Presentamos el primer coche deportiva que hace 100 millas con un galón de gasolina y que está en código abierto para el público.
Soy Joe Justice, el team lead de Team Wikispeed.
Este super coche de fibra de carbono, tracción trasera con chasis de aluminio extruido
cuesta 25.000 USD. Es un coche de carreras y muy básico.
Ahora queremos que toda esta tecnología responsable de ese rendimiento en carrera y aún más importante, en bajo consumo
esté disponible de manera más económica en formato de coche urbano para que la gente pueda disfrutarlo camino al trabajo
Queremos llevar esta tecnología increíble a la entrada de tu casa. Nuestro objetivo es hacer el próximo modelo del coche Wikispeed
una opción realista para poder ahorrarte mucho dinero en la gasolinera.
El Team Wikispeed consume materiales, maquinas y horas de la gente. Con la financiación podemos incrementar esos recursos
y hacer hasta 10 tests de impacto y test de consumo de combustible certificados por la EPA.
Nuestro proyecto se financia para la gente y por la gente. Vuestro apoyo va a llegar la revolución de la 100 millas por galón a la puerta de tu casa y alrededor del mundo.
Te invitamos a ser parte de esta acción y ayudar a hacer el mundo más impresionante.
Conduzcamos Wikispeed!
Esto es una foto de un oso polar chocándola con un robot enfrente de una supernova.
Team Wikispeed no hace sólo coches. Nuestra misión está escrita aquí: "resolver de manera veloz problemas para el beneficio social"
El primer proyecto en el que usé Agile fuera del software fue con Rotary International para entregar la vacuna de la polio
en las áreas del mundo donde más se necesitaba. Team Wikispeed tiene acciones en el backlog para entregar
la vacuna contra el rotavirus allá donde afecta a más gente. Tenemos items en el backlog para entregar centros médicos low-cost a comunidades en desarrollo.
Tenemos items en el backlog para desarrollar aplicaciones de banca e inversión para áreas donde no tiene acceso a ellas ahora.
La banca y la inversión se piensa como un privilegio del primer mundo pero muchas naciones del tercer mundo tienen
teléfonos móviles y planes de datos. Si las aplicaciones y las instituciones existen tiene acceso a esos mismos privilegios
Si os unís al Team Wikispeed podríais tener un impacto en el mundo que os rodea, mejorar vuestras habilidades Agile y aprender el conjunto de herramientas Agile
Sin embargo no tenéis que uniros a Team Wikispeed para hacer esto. La mayoría de los miembros de Team Wikispeed usan de 2 a 4 horas por semana
resolviendo rápidamente problemas para el bien social. Si tu usas de 2 a 4 horas semanales resolviendo rápidamente problemas para el bien social
podrías tener un impacto real en el mundo. En el mismo tiempo que ahora usas para ver tu programa favorito de TV
podrías desarrollar una primera versión de una aplicación de banca móvil para comunidades en desarrollo,
o v1 de un paquete químico de refrigeración para poder mandar las vacunas contra el rotavirus allá donde se necesitan y que aún sea usable al llegar
No se necesita mucho tiempo. Si usarais 2 o más horas por semana enfocados a problemas sociales os recomendaría usar metodologías Agile
porqué permite obtener resultados más rápido y con menor coste, y cuando hablamos de trabajo que merece la pena hacer, eso es muy importante
Si todos los de esta sala usara sólo 2 horas por semana para resolver rápidamente problemas sociales sería tan impresionante!
Sería como la ciencia chocándola con la naturaleza enfrente de una supernova!!!
Muchas gracias