 picado. Desde ahora estoy usando el micrófono. Entonces, la base material para un proceso Lean en cualquier desarrollo de software es por un lado la disciplina del diseño y por otro lado el DevOps. Por esto, esto es medio raro que estamos hablando sobre el proceso en el track en la pista de DevOps. Pero la razón es que vamos a ver bien que es Lean porque hubo ya bastantes charlas como el excelente trabajo ayer del compañero, the great talk that you gave yesterday on DevOps. Entonces, yo quiero compartir unos conceptos que no puede salvar del fracaso. Todos los éxitos vienen de haber fracasado. Frajací tanto tiempo que tantas veces frajací que soy experto en proceso. Así que vamos a ver, vamos a hacer esto. Bien, lo primero que quiero hacer es necesitamos un feeling de qué es el proceso Lean. Pero primero unos conceptos. Yo soy Víctor Kain en RUPOL, está todo mi datos. Este es Barcelona 2007 que participé en Barcelona 2007. Fue mi primer RUPOLCON y trabajo con la construcción de sitios y también como mentor para formar equipos internos de empresas para que puedan producir su producto. Vamos a ver lo más rápido que podemos porque la verdad que hay mucho material acá. Entonces, va a ser medio escueto. Voy a publicar los slides y un vídeo que tengo también y tratamos de cubrir cualquier pregunta. Si necesitan interrumpir porque queda muy borroso algún concepto interrumpa a mí. Si no esperamos hasta el final para las preguntas. Vamos a hablar sobre Kanban que es una palabra que se usa mucho pero hay que entender algunas características que tiene que es una manera que puede ser usado por el Scrum pero también tiene unas características aparte. Vamos a hablar sobre visión y la inserción del proyecto, el punto de partido de los proyectos, los comienzos de la primera reunión de inicio del proyecto, el kickoff, el flujo de trabajo y todo en código. Y bueno, después hay como el provisionamiento no ya del equipo individualmente sino del servidor de testeo y de producción, la automatización del despliegue y del deployment como se habló en el otro tracer y la cuestión de validación de los usuarios que tiene bastante importancia. Estos son conceptos, esto es el enemigo de todo éxito del proyecto. A menos a algunos, yo supongo que si soy ingeniero que voy a hacer una puente, no voy a ver cómo hacemos el puente. Yo supongo que se tomaría, tal vez cascada funciona pero para eso fue no funciona. Entonces lo que hace la cascada como metodología y es por defecto el método que todo el mundo utiliza a veces inconscientemente cuando cree que está haciendo algo mucho más ágil, están haciendo waterfall y vamos a ver exactamente por qué, eso es lo que yo quiero compartir. Divide las disciplinas en varios. En análisis, diseño, implementación, testeo. Es decir, y hay otras disciplinas también, antes está la captura de requerimientos. Entonces ¿qué se hace? Primero se captura los requerimientos, después analizan los requerimientos, se hace el diseño del software, la arquitectura, se implementa y luego se testea y luego se entrega y después luego se lanza. Es enemigo esto, vamos a ver por qué. El ágil trate de mejorar, ¿cuál es el problema acá? La Fuerza Aérea Norteamericana hizo un estudio en los años 80 de por qué fracasaba, no menos de más o menos 70 por ciento de sus proyectos de software fracasaban. Entonces ¿por qué? Descubrieron que el uso del método waterfall, porque lo que si vos haces el análisis y diseño, en cualquier proyecto hay un mínimo de 40 por ciento de cambio. Entonces el waterfall no toma en cuenta los cambios y no es flexible, número uno. Y dos, hay un abismo entre las entrevistas con la captura de requerimientos y el testeo, el cliente dice eso no es lo que yo pedí. Yo no pedí eso, ¿qué es esto? ¿Cómo se hace? Porque no hay posibilidad de retroalimentación durante todo el proceso que puede ser seis meses, que puede ser un año. Esto también este punto fue cubierto en otras charlas, ¿no? También el problema es que cada disciplina es un lugar aislado y no hay comunicación entre las distintas disciplinas. Entonces, por ejemplo, si se encaja el diseño gráfico, muchas veces se hace acá, se hace captura de requerimientos y el diseñador o la diseñadora gráfica hace el diseño. Y como resultado toma un montón de decisiones de usabilidad que no le compete y toma un montón de decisiones de arquitectura también. Y hemos visto ya en otras charlas sobre DevOps el daño que hace, por ejemplo, ayer Larry Garfield dio una excelente charla que mostró cómo se puede integrar, que implicitemente es Lean, porque era como si le compete al diseñador y al diseñador participar con todo y todo el mundo tiene que participar junto. Garfield la ha demostrado si se observa la forma estructural que tiene grupo y si hace el sistema en vez de hacer la página, entonces se produce resultados mucho mejor. Si se trata de implementar una página diseñada, vamos al fracaso, porque son dos, son tres o cuatro dimensiones proyectados en dos dimensiones. Bueno, entonces después surgió, después del informe de la Fuerza Aérea, la idea de hacer una metodología incremental y iterativo. Entonces la misma cascadita, entonces cuatro, cinco cascaditas. Entonces las cascaditas nos salvan, porque por lo menos más retroalimentación, porque puede haber testeo en cada entrega y no voy a definir ágil ahora porque se consulta la lecturatura, o sea el ágil tiene principios muy importante, pero ahora queremos simplemente entenderlo y cómo se modifica para el desarrollo web, porque el ágil es la nueva cascada, agile is a new waterfall, es waterfall, porque tiene una serie de problemas que vamos a ver, porque dentro de la cascadita acá se sigue haciendo handoff, es decir, el enemigo del proceso es no trabajar en conjunto. Si se trabaja en conjunto y todo el mundo tiene una conciencia de qué estamos haciendo, entonces no va bien. Para entender de qué estoy hablando, vamos a ver juntos un extracto del libro Lean Ueques de Jeff God Health, que nos da un sabor, nos da un sabor de cómo es el asunto, de qué estamos hablando, de qué tipo de... Es el martes y Rick, Mark, Olga y Arte se paran en frente de un pizarón blanco mirando a un dibujo de un widget que han dibujado. Arte tiene el marcador en su mano, pero no están dibujando. Rick no me cabe lo que estás, dónde vas, dónde vas con esto, ¿puedes explicar el problema por favor? Rick toma el marcador, limpia una sección del pizarón, explica el reglamento, porque es una aplicación de bolsa, de la bolsa, de gestión de informidad. Hay un reglamento que tiene que estar. Entonces, Rick lo explica, después explica el reglamento otra vez y el equipo juntos, o sea, los desarrolladores, hasta de DevOps, operaciones, los diseñadores, el cliente, todos están presentes acá. El dueño del producto, o sea, que es alguien del cliente, todos están acá mirando esto juntos, ¿no? Entonces, tenemos el que conoce el dominio, que es la bolsa, si no está esa persona, va a ser de cualquier cosa y después se tira el trabajo y después se viene y se explica de vuelta, pero no se explica porque no está la persona. Tratamos de gozar de este clima. Rick toma el marcador, limpia una sección del pizarón, explica el reglamento otra vez. El equipo está diseñando una aplicación para el mercado de la bolsa y la aplicación tiene que obedecer un conjunto de reglamentos. Rick, el analista de negocios, es responsable para asegurarse que el diseño y los diseños del equipo soportan los reglamentos. Después de un momento, todo el mundo está asentando con la cabeza y empieza a entenderse y Arti toma el marcador otra vez. Ella sugiere un cambio en el diseño que está sobre el pizarón y el equipo asienta y está de acuerdo. Todo el mundo saca su iPhone, andre loco porque es iPhone. Ok, bueno, todo el mundo saca su iPhone y toma foto y se ponen de acuerdo como que se van a ver el día siguiente. Tiene toda la confianza del mundo de que lo que han acordado va a estar listo para el testeo con el usuario el jueves, o sea, en dos días. O sea, se va dos pasos atrás pero tres adelante. O sea, como Sebastián explicó en su charla, cuando se usa estos métodos, parece lento pero se gana mucho tiempo. Arti, la diseñadora vuelve a su mesa y empieza a detallar el diseño que han diseñado sobre el pizarón. Mark, el desarrollador de Frontend, empieza a construir la página. Entonces nos dice ¿Cómo empieza a construir? ¿En base de qué? ¿Por qué no fue la reunión? El sonido acá. Ok, perdóname. O sea, ¿Cómo? ¿En base de qué? ¿En base de qué vuelve? Porque el proceso lín lo que dice es que hay que hacer un estilo viviente de diseño. Entonces, cuando se diseña, no es que alguien va a diseñar, alguien va a explicar todo y después la otra persona va y toma una semana para hacer diseño y después lo trae de vuelta y acá. Sino que los diseños, como Larry Garfield explicó ayer, se hacen en componentes como a su lejos. Entonces eso permite que Mark, el desarrollador de Frontend, empieza a construir porque él utiliza los componentes hechos de antemano desde la guía de estilos viviente, o sea, que corre, que el equipo ha puesto en lugar. Entonces él no necesita esperar para arte, no necesita que recibir la entrega de arte de su diseño antes de empezar a trabajar. Rick abre el wiki del proyecto y empieza a documentar las decisiones del equipo y va a repasar estas decisiones con el dueño del producto más tarde en el día. Bueno, no está. Y Olga, la testeadora, empieza a escribir los testeos de aceptación. Entonces, ¿Qué está pasando acá? Todos trabajando en paralelo. Entonces, saboreamos eso. Eso es lo que es todo. Pero como vemos, tiene una base material, no sale del aire, como nada sale del aire, pero este tiene dos patas, tiene la pata, ¿no? del Lean UX, que es el ágil aplicado al diseño y a la usabilidad y tiene el DevOps, que sin operaciones y provisionamiento ágil de todo el mundo, ¿dónde está el estilo viviente? ¿En qué máquina está? ¿Qué revisiones? ¿Qué versionera? No. O sea, tiene que haber un proceso de DevOps fluido con gente que sabe lo que está pasando acá. Y la otra pata el diseño. Entonces, bueno, se dan cuenta cómo es esto. Hay mucho que tenemos que cubrir. Entonces, me voy a sentar acá y tratamos de seguir un poquito. Acá tenemos una sugerencia de 2007 de mejorar el ágil para que no sea la nueva cascada. Y lo que hace es así. Lamentablemente sigue con la idea de entrega. Yo hago un trabajo, te lo paso a vos, vos haces el trabajo, lo pasas a ella. Por eso es ridículo, es un derroche total. Entonces, tomando en cuenta que el ágil es una cascadita, ¿no? Lo que propone de Zirei Sai en 2007 propone que se comienza con una reunión entre todos. Entonces, se acaba eso de no hace falta contratar a diseñadores hasta más tarde o contratamos los diseñadores y después por una semana nada más que hagan el diseño y listo. Eso se acaba. Tiene que estar parte del equipo. Y se hace y también debo, obviamente. Tiene que saber qué necesitan ayudar a toda la gente. Bueno, acá se planifica y se busca todo el trabajo. Eso vamos a ver. Después, mientras desarrollo hace cosas de alto riesgo y de muy backend que no tiene nada que ver con lo que se ve, se hace el diseño para el ciclo 2. Cuando simplemente eso, mientras, los diseñadores están haciendo el trabajo del ciclo 3 y ellos implementan, ¿no? Y así sucesivamente. El track de diseño va así. Es mejor porque hay menos derroche, pero no es una solución final porque la gente igual está haciendo no está trabajando en paralelo. Ellos están en una cosa y vienen las personas de diseño y los interrumpe. Entonces, hay mucho cambio. Uno de las reglas de lean es que no se hace varias tareas a la vez. No se hace 2, 3 o 4 tareas a la vez. Bueno, aún mejor es esto. O sea, un proceso de diseño y desarrollo. Entonces, como vamos a ver después, si hay tiempo, como vamos a ver, se hace una reunión como el ciclo 0 con todos presentes para ver la visión del proyecto, hacer brainstorming, dibujar algunos esposar cómo va a ser el proyecto que necesitamos en la página principal, que necesitaba aquí, allá. Y después, en base de esto, vamos a ver en detalle cuáles son los artefactos que realmente hace falta para esto. Básicamente, bueno, vamos a ver, pero esto, en esta reunión de conjunto que puede durar unas horas o una semana, porque es posible que para llegar a fondo de validar el problema, porque vamos a hablar del problema mercado y producto, que parte de lean, porque lean trae todo el dolor de los 90% de los startups, los emprendimientos que fracasan. Entonces, todo esto es un startup, como si fuese, no es un proyecto, es un startup. Tiene que ganarse la vida. Entonces, los métodos que son, ¿cuál es el problema que queremos solucionar? Bueno, eso, el problema está que la gente necesita tal cosa. Bueno, ¿cómo sabe así? Entonces, salir y investigar a veces es cierto. Entonces, eso puede llevar tiempo. Pero la cuestión, una vez que se tiene un hipótesis y una visión de qué producto mínimo es necesario para probar ese hipótesis, entonces se puede hacer la planificación. Y ahí se baja todo a una serie de user stories. Este theme son tres corridas o sprints y usas scrum. Y la idea es que esto es un feature. Esto es un feature. Entonces, ponenle la página principal. O sea, ponenle una página de aterrizaje, un landing page para convertir que la gente deja su e-mail. Ese es un theme y se va a hacer una parte mínima, después se va a hacer otro y otro. Lo genial acá es que, por lo menos, dos veces tiene que ver a validación del usuario. Esto acá no hay nadie de handoff. En esta reunión, en estas dos reuniones, está trabajando todo el mundo. Después, como vimos en la lectura que hicimos, todo el mundo trabaja en paralelo hacia su trabajo. Se colaboran, se necesitan, trabajan junto y se van trabajando para las validaciones. Y al final de cada sprint tendría una versión alfa, beta, algo del MVP, que es el producto mínimo viable, que no es el producto mínimo viable del final del proyecto, es el producto mínimo que necesitamos para testear el hipótesis que hicimos al principio. Vamos a ver de qué se trata esto. Esto es una lista de los derroches. ¿Por qué hay que usar lean? Si no usas un método como esto, se ha comprobado que tenés un montón de trabajo dejado en ocillos. Si yo estoy trabajando sobre tres cosas, se entrega algo, no puedo concentrar en ninguno bien, entonces siempre se queda un montón de trabajo pudriéndose. ¿Por qué pudriéndose? Porque yo hice tres cosas, se entregó a eso, hay unos bugs ahí, una semana después ya se cambió todo, el trabajo que hice la semana pasada, cambió, cambió por un cambio de requerimiento, cambió porque sí. Un crecimiento en los features, sin validación o sin análisis de su impacto, va a pasar. Los compartimentos aislados, por ejemplo, si es que se implementa mucho y después se entrega, o sea, si dos imper programas y el equipo hay cuatro desarrolladores y hay dos, entonces dos tarjetas, dos user stories que se van a hacer en paralelo, los dos van a inventar lo mismo. Por ahí los dos, uno usa un módulo en Drupal para una cosa y otro usa un módulo que hace lo mismo. ¿Por qué no? Si no están hablando. Los handos, o sea, las entregas, crónicamente rompe el sujo de trabajo, muchos demoras por todo esto y también por la mezclinidad de la planificación que no hace un equipo con todos los skillsets, todos los conocimientos necesarios. Si no está, por ejemplo, el que sabe del dominio y se hace mucho trabajo sin su presencia, sin informalmente che. Mira esto, está bien. ¿Qué opinas? ¿No? O sea, algo así. Si tenemos un equipo incompleto, entonces vamos a tener problemas de mora. Después, task switching. Esto es terrible. Esto es de un enemigo porque la gente si está trabajando sobre más de una cosa a la vez tiene que ver un flujo constante de trabajo en paralelo. Y no dejo esto y hago otra cosa. Porque eso crea un ámbito de sobrecarga, conduce a errores y es un ambiente inocreativo, un ambiente que no llega a ningún lado. Después, muchos defectos por lo mismo y por falta de compartir conocimiento. O sea, hay, tiene que haber una onda, como vimos en la lectura, de compartir, ¿no? Y no de jerarquías y divas y rock stars y todo eso, sino un equipo, ¿no? Que le encanta compartir lo que, lo que ve. Entonces, por eso no se va a usar dos módulos que hacen lo mismo. Sure. Mi pregunta es ¿y qué haces en, o sea, cómo solucionar los dependencies de un proceso al otro, digamos, si no, no puede hacer el diseño, no puede hacer la programación si el diseño no está hecho a UX. O por ejemplo, un módulo de e-commerce que necesita estar primero elaborado el workflow del usuario, ¿cómo, cómo evitas que se queden parados o se queden silos para que no ocurra eso? Ok. El secreto es la reunión inicial de cada corrida y dos veces por semana o una vez por semana, por lo menos, la validación del usuario. Es decir, cada user story se planificó entre todos. No era un guru, se meten en la oficina de la esquina y planifica. Y después dice, bueno, vos haces esto, vos haces esto, vos haces esto. Sino que todo el mundo planificó todo y todo el mundo y solamente se hizo la cantidad de trabajo justo a tiempo, just in time para lo que hace falta hacer. Entonces, la otra respuesta es que hay alguien que mira como vamos a ver en un momento una arquitectura candidata que también se habla entre todos. Entonces justamente se evite ese problema que vos decís porque el grupo tiene una conciencia social común colectiva que permite que entiende todo el mundo gets it. Todo el mundo entiende qué está pasando. No sé si eso contesta, pero vamos con más detalle y por ahí se aclara. La excepción del proyecto y la visión quiere decir que tiene que haber algún punto de inicio. O sea, ¿dónde empieza un proyecto? Entonces, estas entradas que hay al principio que podría haber sido una llamada telefónica con el siguiente o podría haber sido todo un proceso RFC. Estas entradas hay que juntarlos y hacer la preparación para el kickoff. Por ejemplo, ponerle que el proyecto es un taller literario en línea. Hay que hacer una serie de pasos para que esté todo lo que necesitamos para la reunión kickoff de todo el mundo. Entonces hay que juntar todas las entradas, la documentación del frente, las conversaciones, hay que ver el sitio anterior si hay y hay que entender bien el contexto del negocio. Hay que crear un texto que se llama la visión. No es obligatorio ningún artefacto, pero por lo menos tener una visión como punto de partida para todos. ¿Y qué tiene que incluir esa visión? Tiene que detectar los puntos de dolor experimentado por los usuarios que están creando una necesidad para hacer este proyecto. Hay que listar todas las alternativas arquitectónicas, los distintos frameworks que hay que tener una visión de todo y también hay que buscar a ver si hay algunas restricciones importantes. De seguridad, militar, el proyecto, por ejemplo, no puede caer el sistema porque va a haber pérdida de vida que existe. En PDVSA, por ejemplo, el flujo del petróleo se no puede caer. Esa es una restricción muy grande. Entonces, ¿cómo lo haces? Bueno, hay que tomarlo en cuenta. Después hay que elegir el equipo, hay que ver cómo provisionar al equipo para que empiezan y hay que decidir si se va a hacer un prototipo. Acá, básicamente, quiero hablar sobre el dueño del producto que tiene que ser alguien del cliente. Tiene que definir mercado, problema y producto. Ese es el triángulo básico de Lean y es el triángulo de cualquier startup que va a tener éxito y también de un proyecto. Tiene que existir un conjunto de personas que efectivamente tiene un problema y que es un problema que duele tanto que van a pagar para un producto que sea. Tiene que ver un producto que va a ser una solución que soluciona un problema para un conjunto de personas y hay que validar la estrés. El problema se puede validar sin hacer una línea de coño. Mucho startup, voy a ser millonario, voy a hacer la plancha magnética. Se usa la plancha y se pone sobre la pared magnéticamente, sobre cualquier pared. Entonces, eso voy a ser millonario. Bueno, vos no sabes si realmente es un punto de dolor que la gente realmente tenía esa necesidad y eso se puede salir del edificio y averiguar si realmente es un problema. Eso es importante. El mercado también. Porque si vais entrevista, ¿a vos te venía bien una plancha magnética? Ok, bueno, nos ahorramos un montón de trabajo. Y hay un ejemplo. Amazon está empezando a entregar comida pedidos de supermercados en algunas ciudades. Hace 10 años, creo que era, una empresa hizo una inversión de millones y millones de dólares, compró warehouses y todo, compró todo un flete, o sea, un montón de camiones porque estaba seguro. Y por no analizar bien qué sector del mercado, qué tipo de personas realmente quería eso y todo eso, fracasó totalmente. Porque no hizo validación del mercado, problema y producto. No, esa es la cuestión. Bueno, hay que ver una lista de soluciones existentes, por ejemplo, entrevistar a alguna gente que tiene ese problema y dice, ¿cómo se está solucionando algo? Bueno, el taller literario se hace con correo y la verdad que nunca puede encontrar ningún poema, nada, una cosa así. Hay que juntar el equipo para preparar, entonces, la visión. Entonces, ahora, entonces, esto acá es una plantilla de vision. Entonces, hay dos referencias, dos libros que son muy buenos. Esto no voy a repetir porque es una definición. Están con los slides, que es mercado, la validación de mercado, problema, y escribir lo que se llama una declaración del problema, específica, objectivizar lo que es realmente. Ok, estamos siendo muy lento. Pero, este, un segundo. Vamos a ver algo del Team Kikov, rápidamente. El Team Kikov, cada sprint tiene un Kikov, no? Todo el mundo participa, los expertos del dominio se invitan y podría durar lo que tiene que durar para hacer todo. Esto acá es clave. En el Kikov, ya hablamos de los problemas. Los problemas se toman y se objectivizan y se analizan como presupuestos, conscientes y inconscientes que la gente tiene y con eso se hace una hipótesis. Después se hace un diseño colaborativo, tipo en Pizarón Blanco, todo juntos, no? Y eso es lo que habíamos visto en la lectura que hicimos antes. Y en base de esto, en base de tener un hipótesis concreto que va a decir, nosotros creemos que si construimos tal producto para tal grupo de gente que las ventas van a subir. Y vamos a saber cuando concretamente vemos un crecimiento en las ventas. Ese es el hipótesis, no? Y estos hipótesis, después, una vez que todo el mundo ha hecho brainstorming sobre el diseño que puede ser, cada uno hace un diseño y se comparte, se critica entre sí o se hace en un Pizarón, se saca foto, no? Y ya tenemos una lista de hipótesis que describe el proyecto. Estamos listos para tomar cada hipótesis y hacer uno más user stories en la próxima reunión, no? Y estamos listos para definir el producto mínimo viable que es no el proyecto final, sino el producto mínimo viable es la cantidad mínima del trabajo que podemos hacer para confirmar la lista de hipótesis. Entonces, en un sprint podríamos elegir algunos hipótesis y podemos decidir qué user stories hacemos para hacer el mínimo de trabajo para que haya algo que está corriendo, que se muestra al usuario rapidito y se recibe una retroalimentación sobre eso. Esto es el núcleo de todo. Es la liberación mínima del producto capaz de testear los hipótesis. Una vez que se define eso en la reunión de planificación también con la presencia de todo el mundo, se define el backlog de los user stories. Bueno, hay un montón de detalles acá. Hay una plantilla de cuando estás analizando los problemas, no? Entonces, estos problemas se deberían interrumpir, tal vez la reunión de Kiko, y por dos días se va afuera y se busca usuarios, tal vez usuarios actuales del sistema y se dice, ¿este es verdad que esto es un problema para vos? O decirme cuáles son los problemas del equipo, una cosita. O sea, decirme algo que te molesta del sistema. ¿Es verdad que te molesta esto? No, no, este no me molesta. Lo que me molesta es que lento. O sea, si escuchas un montón de gente quejando, entonces se valide el problema. Y no escribiste una línea de código, y eso es importante que se haga. Después tenemos el hipótesis. Esto es un ejemplo de un hipótesis. Nosotros creemos que crear un sistema de comunicación eficaz dentro de la experiencia del producto entre gente, esto es para un proyecto de job board o algo así. Nosotros creemos que si tenemos un sistema que tiene una comunicación muy fuerte entre los recruiters y los empleadores, vamos a lograr un éxito más grande y incrementar la satisfacción del producto. Vamos a saber que eso es verdad cuando vemos un aumento en la cantidad de respuestas de gente buscando empleo y vemos que aumenta la cantidad de respuestas de ellos a los recruiters. Y también un aumento numérico en la cantidad del mensaje. Entonces, esto es una cosa muy importante de que no es suficiente hacer el testeo y todo eso y que anda el software. Sino que nosotros no nos interesa entregas, sino nos interesa resultados de valor. Entonces, ¿sabe por qué? Porque lo cliente o un representante es un miembro del equipo. Es una fantasía, muchas veces. Es muy difícil. Pero si puede ser, quiere decir que estamos trabajando en el equipo para lograr valor garantizado para el cliente y por lo menos tratar de hacerlo. Es muy difícil. Muchas veces es imposible que el cliente siquiera participa porque dice que no tiene tiempo. Hay que tratar de decir que cuanto más retroalimentación hay, mejor va a ser. Una cosa muy importante de lo que vamos a hacer ahora quiero mostrar como parte de los DevOps porque hasta ahora hemos hablado mucho del proceso del diseño. Hay una cuestión de personas para identificar bien las personas. Identificar el mercado es esto, nada más, ni menos. Que perfil tiene esto y lo otro. Una vez hay que hacer un brainstorming de features que van a hacer los temas. O sea, los features son vamos a hacer un landing page, vamos a hacer un listado, vamos a hacer una sección para empleadores o lo que sea. Vamos a hacer una sección de esto. Estos son features que van a hacer dos o tres corridas o sprints si no está usando cambat. Entonces en RuPaul, para poder hacer esto hay que seguir lo que se ha hecho en los otros charlas. O sea, hay que lograr todo en código, todo en código. Yo tengo un video que explica eso. El video es un poco largo, pero el video tiene dos partes. Uno es un playbook al lado de DevOps que yo dije que es otra base material para esto. Está disponible en GitHub, y es consta de dos partes. Consta de... ¿Está en el video? Perdón. Está en GitHub.com para Durable Group y tiene un repositorio que es básicamente un playbook de Vagrant y después tiene un distro de grupo que tiene un montón de módulos. Y básicamente este video lo que muestra y lo voy a poner el link en la página el video muestra que si vos instalás Vagrant y algún VM, pero que Vagrant puede usar y instalás Ansible entonces vos haces un hit clone de este repositorio y haces un Vagrant app y ya tenés un Drupal corriendo. Entonces, vamos a ver de dónde está mi cursor. No sé qué está pasando. A ver. No puedo moverlo. No sé por qué. Bueno, esto es el repositorio de Drupal de Durable Group y después se está mostrando cómo es el distro tiene la traducción en español se puede instalar en inglés o en español. Acá ya estamos con el playbook. Perdón, este es el distro. El distro tiene un montón de dependencia de módulos en el punto de info con lo cual estos módulos se van a habilitar cuando se instala. Entonces ese perfil o distro fue creado por un módulo que se incluye en el distro. Ahora se paró, no sé. Ok. Entonces ahora vamos a mostrar el playbook muy sencillo que tiene instrucciones exactamente de cómo correrlo. Y esto es para en un laptop o en un servidor si vos tenés un servidor que va a aprovisionar a otros o instalas ahí si no lo podés instalar en cualquier laptop. Y eso tiene todas las indicaciones y después va a correr en un IP. Entonces, a este video lo que pasa es que va un poco lento pero no sé si vamos a poder ver todo pero básicamente se hace un clon de este repo se hace HitClone y el nombre del distro o sea justamente acá se copia la uera y el distro la uera y el clon entonces HitClone y eso y después cuando baja lo único que tenés que hacer es Vagrant app y ya tenés el repo ya instalado y la única que estaría ahí es editar el etc host si querés o sea etc host de tu máquina y le pones algún alias entonces lo podés correr en tu browser directamente. Entonces tenés si todo el equipo diseñadores todos tiene esto y hacen commits y todo ahí está haciendo el HitClone entonces esto mientras esto corre vamos a hacer preguntas porque no hay tiempo para presentar más pero los slides van a estar disponibles y el video también y espero que ayuda o sea trato de compartir un método que es posible para ayudarnos. Ahí ya se bajó se creó el repo localmente en el laptop y después se va a hacer Vagrant app y en cinco minutos ya tenés el grupo corriendo con ese distro. Alguien tiene una pregunta una pregunta mi pregunta en realidad respecto a este cuando contaste el proceso lín funciona con equipos distribuidos esto porque con equipos distribuidos porque la sensación que me dio a mí es que estaban dos sentados en la misma mesa tomando café excelente pregunta el libro funciona con distribuidos pero hay técnica que hay que usar entonces hay que tener o sea hay que usar algo como hang up donde todo el mundo se ven no y utilizar este por ejemplo ponerle que todo el mundo va a hacer un disenito entonces eso hay que hay que tratar de compartirlo con un método a veces se hace y se sube a google docs y se mira todo junto está explicado en ese libro pero sí este está es mejor cara a cara pero se puede usar para distribuido justamente este algún otro preguntas acá ya se ya se bajó todo el ubuntu y todo que ya está en la máquina y ahora está corriendo el playbook o sea el ánimo lo que hace es que agarra la imagen del ubuntu o de lo que sea lo que está especificado lo botea y ya está corriendo entonces después lo que va a hacer es empezar a hacer una serie de tareas y las tareas son bajar dependencias de lamp instalar el lamp bajar drash y y después crearon base de datos crearon virtual host y instalar el grupo en un lugar y después configurar los premisos del directorio para que ya está listo y lo deja corriendo vos editas eso y pones el IP que quieras y esto es el playbook que invoca y el playbook que está en el subdirectorio provisioning así toda la cosa que yo mencioné recién traduce harlin y agil todas las veces que puedo que es muy pocas veces los principales problemas que he encontrado en las metodologías son es que no es para cualquier desarrollador y no es para para cualquier desarrollador para cualquier programador y tampoco es para cualquier cliente entonces tener que vender un cliente la metodología lin que va a participar que primero vamos a empezar a hacer un plan a planes chiquitos etcétera a veces no es nada fácil sobre todo cuando lo dice necesito una cotización ahora si no pierdes el contrato esa cotización debe tener un plan detallado a un año de qué es lo que vas a hacer y después se firma un contrato con respecto a ese plan y si no lo hago no tengo el contrato no entonces ahí las cosas empiezan mal y luego en los desarrolladores que yo no controlo por ejemplo de por si son difíciles de encontrar los desarrolladores que puedan ser lin pero los que yo no controlo los que son con integración de otras empresas etcétera definitivamente no van a seguir lin no lo van a comprar entonces qué haces en ese momento yo tuve una experiencia en principio cuanto más cercano llegamos mejor va a ser el producto es tan sencillo como eso entonces se intenta dos hay que crear un clima en la cultura como se ha explicado en los otros charlas propicio al trabajo en equipo no es fácil pero cuando la empresa hace una campaña para cambiar el clima se supone que se pueda ayer en la charla hola en tu charla te vos explicaste un camino difícil dificilísimo que se comience de a poco con lo que se pueda que se trae por eso es el DevOps primero ven algo eficaz después sería mejor que la diseñadora venga la reunión o contratamos dos semanas no que queda más entonces se va evolucionando hacia eso yo tuve un proyecto con un ONG en Oakland y yo hice tres reuniones donde expliqué que va a ser lean que va a ser así y todo con mucho entusiasmo lo tomaron y empezamos a trabajar bien así y remoto también remoto entonces hicimos como reuniones día por medio compartiendo todo el trabajo hicimos hicieron un análisis de sus contenidos qué estructura qué sistema van a hacer y después en la próxima reunión en el hangout no estaba la diseñadora yo deje donde está está enferma no está haciendo el diseño y efectivamente hizo todo un diseño que no pudo interrumpir porque uno no tiene eso no es lo que decimos porque si hubiéramos hecho de a poco iterativo con dibujito va a ser mejor y efectivamente tuvimos que tirar la mitad de su trabajo pero logré eso logré evitar donde yo tuve que poner el pixel perfect design yo logré que no tuve que hacer lo que realmente seguimos trabajando bien pero la realidad se logra como se puede es una buena pregunta pero si no se hace el índice de fracasso muy alto y la productividad es muy baja así que con el tiempo con los fracasos con los problemas se sigue el ejemplo y en forma realista se trata de convencer con paciencia en la empresa o cambiar otra empresa otra cosa que yo creo de la experiencia es que si un cliente te exige un plan a un año ¿por qué no es tu cliente? pero si vos querés deberás ser ágil o ser lean no es tu cliente claramente no es tu cliente si un programador no se adapta no es tu programador esas cosas son solucionables y no te cotizo yo de esta forma no puedo trabajar el proyecto no va a salir bien pero juro que no va a salir bien no vamos a cumplir no va a ser lo que vos querés el proyecto una manera es correrse eso tiene sus riesgos porque uno tiene una empresa y a veces pero son riesgos tomables y que en mi experiencia personal funcionan tomar ese riesgo le dices no algunos clientes terminan dándose vuelta diciendo vamos a hacerlo como vos está diciendo un programador y no está mal así es la vida me parece los gobiernos y lean no es una cosa que se lleven y sin embargo son buenos contratos yo no me gustaría tirarlos a ese mismo punto un enfoque es que yo le digo a los clientes miren si usted quiere trabajar de esa manera nosotros no podemos por la ambigüedad de los requerimientos o porque no podemos definir exactamente lo que queremos hacer en el tiempo entonces yo tengo una empresa partner para darles un ejemplo y les digo que al menos ayuda a minimizar el riesgo unos requerimientos ya más detallados y no tan generales y la otra opción que les doy es compren bolsas de horas y alrededor de eso les trabajan entonces se trabaja y obviamente hay un proceso donde va a tener que explorar mejor eso y luego se entra una etapa de desarrollo pero es la única manera porque lo que tú dices hay un riesgo implícito, hay mucha ambigüedad y al final posiblemente el proyecto no va a ser exitoso un segundo está editando el ETC host gracias mi pregunta sería bueno si por supuesto no estamos predicando al convertido entre todos nosotros si estoy de acuerdo con Linus pero pronto hay un contratote con estas condiciones es lo que tienes que hacer después como pediras a través de eso bueno bueno yo un comentario para el otro lado un comentario para el otro lado el cliente es una cosa tenemos que manejarlo cada uno lo logra y clientes que no se pueden manejar pero tu equipo, tú lo construyes pues nosotros en CID yo soy el líder de equipo trabajamos con varias personas remotas en lugares donde nos imaginan Sri Lanka y consideramos que todos somos iguales hacemos charlas, hacemos conversaciones de grupo compartimos experiencias y lo que tenemos es un nivel cada vez más arriba y logramos cosas como lo que tenemos ahora por acá está Juan que trabajó con nosotros remoto mucho tiempo y pues se encariñó con el equipo y vino a trabajar con nosotros entonces tú construyes tu equipo y hay que llevarlo al nivel que necesitamos en mi experiencia es que claro tu equipo tiene que estar bien convertido a la filosofía y creo que yo concuerdo contigo que a veces no es tan fácil decirles no a un cliente cuando tienes que cumplir un payroll para tu gente y tienes que vender entonces lo que en mi experiencia lo que he hecho es construir un lean dentro de un esquema del cliente entonces el cliente es más en Nueva York hay un término que lo ocupan que ahorita no me acuerdo pero es con el cliente le manejas un poco y internamente le manejas 100% lean entonces acá se va a hacer un feature como ejemplo de todo en código se va a cambiar el theme se va a cambiar el nombre del sitio se va a hacer un feature y se va a grabar el feature en el video luego se va a habilitar el módulo feature que se ha hecho luego se va a hacer cambios y luego con rush se va a revertir osea cuando se hace cambio queden la base de datos entonces se va con rush a insistir que no se dé bolilla que no que no preste atención a la base de datos sino que preste atención al código y se compruebe que una vez que hacemos eso un feature revert de ese feature entonces cambia la característica entonces con el cliente le manejas el mismo esquema digamos si es del gobierno no puede salir de el esquema de ellos de un presupuesto y lo que haces es muy hábilmente o políticamente empiezas a vender el concepto a uno o dos personas que son los líderes del equipo que están adentro y empiezas a negociar o el concepto de lean basado en tus intereses del mínimo buyout project entonces tú le dices creemos que según nuestro equipo vamos a alcanzar a hacer esto que está dentro de tu esquema aquí tenemos una reunión quiero que revises pero si no alcanzamos y tú te das cuenta que necesites algo más o algo tiene prioridad lo conversamos y vamos cambiando el esquema dentro de eso vas creando tu propio lean con el cliente sinceramente dos a tres clientes nuestros los hemos cambiado la mentalidad al final terminan siendo 100% lean y terminan votando features que no le vieron que no era posible la consulta como haces el momento de presupuestar porque en ese momento la persona te pide definiciones de waterfall o sea te pide que le entregues un plan de trabajo de proyecto y encima tienes que cotizar algo que no está definido la psicológica le haces los entregables no lo haces tan exacto lo haces tan vivos y le dices y desde un inicio que miren el software moderno requiere un poco de apertura de usted y creando no la gente se abre y le explicas por qué la prioridad mire si usted va a poner 40 horas de construcción de este fijo pues nadie usa no le sirve de nada entonces que vas con esa mentalidad el cliente se dice ok la cotización inicial tú no le das los detalles que te pide así te piden los más detalles simplemente déjalo ambiguo déjalo suficientemente ambiguo pero suficientemente creíble para ganar el contrato es un arte pero esa es la forma en mi experiencia como lo he logrado ok hay otra charla acá hay alguien acá que está listo para empezar su charla no ah es un break ok entonces bueno pido perdón por haber puesto demasiado material y no organizado con el tiempo pero realmente quería compartir todo esto y me alegro de la discusión que se suscitó y la conclusión que hacemos no que como dijo Sebastián Lager es una revolución industrial realmente o sea por supuesto se trata de cambios dolorosos y profundos y las empresas y las organizaciones que hacen esto pero es necesario y con ruple especialmente y si no ponemos sobre las patas de dar cabida y dar cabida al lean devops que es que realmente el proficimiento la automacia o sea ahorramos tiempo y ganamos eficacia con la automatización y mejoramos el testeo, automatizamos no hemos hablado de las cosas que se habló ayer de Continuous Build Continuous Integration pero bueno es vasto me parece que puede ser que vimos un vistazo de todo esto, espero que haya servido para eso gracias