El ABC de la ingeniería de software: modelos de desarrollo y programación Agile

1. Introducción: Hola a todos. Y bienvenidos a este curso. Vamos a estar hablando de modelos de desarrollo de software en este curso, y dijo así que a lo que eso sólo va a llegar es a algunos de los modelos realmente populares que hemos estado usando desde hace mucho tiempo en ingeniería de software, también como hablar de esta nueva idea de scrum ágil y combine, que está impulsando forma más flexible de desarrollar software. Entonces lo harán en este curso sólo vamos a estar repasando diferentes modelos y cómo se relacionan con el mundo real y cómo puedes usarlos para desarrollar mejor el software. Ahora, una nota rápida. Se trata de una clase 102. Puedes tomarlo de forma independiente por sí mismo, y la mayor parte va a tener perfecto sentido. No obstante, en la clase uno a uno, hablamos de una especie de lo básico de todo esto. Entonces si algunas de estas cosas no sonan al 100% digamos claro para ti. A lo mejor suena un poco confuso. Consulta el curso 101. Tendrá una especie muy grande de introducción a todo este material antes de que realmente te metes en los modelos ellos auto, Así que solo quiero dar esa rápida descargo de responsabilidad. También está en mi canal. Si quieres revisar el que está en uno sale de video también. Pero todos, bienvenidos a compartir habilidades. Si tienes alguna pregunta déjalas en los comentarios del curso y con gusto te ayudaré en cualquiera de las áreas, y no puedo esperar para empezar. 2. Modelo de acuarela de 1 a 1: El primer modelo mayor que vamos a estar cubriendo es el del modelo de cascada. Entonces con modelo de cascada, lo que estamos haciendo es básicamente que el agua cayendo de paso a paso dos pasos. Entonces iniciamos los requisitos, y luego una vez que estamos seguros de que los requisitos son perfectos, pasamos al diseño que pasamos de ahí a la implementación una vez que estamos seguros de que eso es perfecto hasta probar abajo el despliegue hasta mantenimiento. Ahora esto no tiene por qué serlo. Ya sabes, estos pasos. Podría ser cualquier Siris de pasos que nos lleve a esta conclusión final. Pero la importancia del agua para el método o el modelo de cascada es que nos estamos moviendo de paso a paso dos, y es una especie de lo que hemos estado cubriendo todo el curso, cómo estamos hablando como si todo estuviera en un flujo lineal y siempre sigues. Sigue esos pasos. No obstante, el problema con el modelo de cascada es que no es muy adaptativo. Es muy, muy predictivo. Recuerda esas dos palabras que usamos en la última conferencia, y como es muy, muy predictiva, significa que si encontramos errores, digamos en la fase de pruebas, eso significa que vamos a tener que ir al revés. Entonces si, por ejemplo, lo encontramos en las pruebas, vamos a cambiar el color aquí mismo, entonces realmente vamos a tener que volver a la implementación y luego de la implementación de nuevo al diseño y luego requisitos y básicamente, lo que vamos a tener que hacer digamos que encontramos un aire aquí dentro un error realmente grave con la forma en que hemos programado son nuestro software. Vamos a tener que ir a cambiar los requisitos, arreglar los requisitos. Entonces vamos a ir a arreglar el diseño, hemos llegado con nuevos diseños de subsistemas, nuevos diseños de módulos, etcétera. Entonces vamos a volver a la implementación, tendremos que recodificarla, y luego vamos a tener que volver a probarla. Y si las cosas ya desplegadas, tenemos que ir aún más lejos. Tenemos que seguir retrocediendo y reelaborando todo desde ahí. Y una vez que lleguemos a la fase de mantenimiento, es algo así como justo en un círculo aquí abajo, va a seguir adelante. No obstante, si estamos haciendo grandes cambios en la fase de mantenimiento, aún tenemos que hacer exactamente lo mismo o aún calor gráfico yendo todo el camino de regreso y rehacer todo para asegurarnos de que la toda la documentación todo es apoyado dentro del modelo de cascada. Entonces el modelo de cascada es uno que es muy, muy como dije, predictivo. Es algo donde tu equipo debe haber codificado esto antes para que tenga éxito. Ahora con esto, también es muy eficiente y es muy sencillo de usar. Por lo que hay muchos gastos generales. Entonces otra vez, si estás creando múltiples sitios web o algo así, entonces este modelo probablemente sea algo que va a ser un buen equipo de miedo, porque no tengo que pasar mucho tiempo realmente pensando en el diseño del software proceso. Pueden usar un proceso que ya ha sido diseñado con todo un montón de pasos, y podrían simplemente trabajar con eso ahora con el modelo de cascada. También tenemos este tema de este costo a lo largo del tiempo para arreglar. Entonces digamos cada uno de estos de los diferentes pasos, para que sepas que esto es una vez terminados los requisitos. Una vez terminado el diseño, una vez finalizada la implementación, una vez que todas las pruebas están terminadas, qué es el despliegue está terminado y así sucesivamente de nuevo, podría ser diferentes pasos. Pero la importancia de esta gráfica es mostrarte que a medida que vas más lejos, no es solo un costo lineal en el tiempo, lo que significa que Oh, si lo arreglamos, si tenemos que hacer algo aquí, es solo todo esto combinados para volver a este punto. Es este tipo de cosas exponenciales donde si cometemos un error y lo averiguamos, tal vez en la implementación o cerca de la fase de despliegue, va a tardar mucho más tiempo que si lo arreglamos en la fase de requerimientos tal vez hasta 50 veces la cantidad de tiempo para volver atrás y cambiar todo para que vuelva a funcionar. Y por eso, el modelo de cascada no es flexible en absoluto. Cada paso debe estar extremadamente bien planeado. Básicamente debemos asegurarnos de que todo sea perfecto, y algunas corporaciones lo harán, y en realidad es muy, muy especie de. Muchos programadores se sentarán y girarán los pulgares, esperando que se pasen los requisitos o algo por un montón de comités diferentes para asegurarse de que sea perfecto y así los que haya alguna pérdida de tiempo en ahí también. Pero tiene que estar extremadamente bien planeado. Y va a tardar un tiempo en conseguir el producto en el mercado. Si hacemos algo de lo que vamos a hablar más adelante, algo más, más iterativo donde creamos una especie de V uno que sea realmente básico, y empezamos a sumar características con el tres y la versión para inversión cinco. Entonces sacamos el producto realmente, muy pronto. Y luego de eso, podemos, ya sabes, empezar a construir sobre él, y no sé por qué, pero un muñeco de nieve me vino a la mente aquí, y en realidad podemos sacar un producto que, ya sabes, una especie de empezar a trabajar para eso. Podemos obtener retroalimentación de esa prueba beta debilitada para la que podemos conseguir dinero, pero con esto lo estábamos haciendo todo en una sola toma. Probablemente la primera versión del producto va a ser la versión final del producto, y debido a que en realidad podríamos perdernos nuestra oportunidad de mercado, Tal vez si hubiéramos salido, ya sabes, medio asado muchos cuenta con tres meses antes, habría sido mucho más exitoso que llegar tres meses tarde con todas las características, y algo que es muy importante es que la tecnología se mueve rápido y ¿qué esto? No podremos adaptarnos a las nuevas tecnologías. Entonces, si estamos en un campo de rápido desarrollo, como, como, por ejemplo, autos donde sabes que el software de autos está realmente desarrollando bastante rápidamente las cosas mismas con, como, como, software de Internet de las cosas, ya sabes, como relojes inteligentes o como camisas inteligentes o lo que sea. Todo ese mercado se está desarrollando realmente rápido. Y las nuevas tecnologías están saliendo 68 tal vez un año a la vez. Y así por este tipo de iteración rápida, por, ya sabes, sabes, la iteración anual o tal vez incluso como mensual de la tecnología, si estamos construyendo una pieza de software que tarda dos años en construirse, y no vamos a sacar nada entre esos dos años, cuando saquemos nuestro software, la tecnología puede haber pasado y todo nuestro proyecto está obsoleto, por lo que necesitamos tener eso en cuenta también. Pero el modelo de cascada. Por todo esto, es decentemente malo en muchas áreas, pero no debe ser cancelado de inmediato. Sí tiene sus beneficios en estructuras y lugares más organizados donde los equipos están creando las mismas cosas una y otra vez, y sí tiene esa eficiente, bajo costo para correr una especie de idea con ella. Pero este es el primer modelo, el agua para modelo. Es muy importante y muchas cosas se basan en ello. 3. Modelo de 1 a 2 V: Entonces el siguiente modelo del que estamos hablando va a ser el del modelo. Y el modelo V es una especie de mejora en el modelo de cascada. O al menos se encarga de un problema que la gente notó con el modelo de cascada. Y este modelo V básicamente toma la caída del agua. Entonces la cascada siendo, ya sabes, el abajo, que abajo, abajo y abajo y lo toma y lo dobla en este tipo de implementación aquí abajo, y trae las pruebas al lado derecho, y luego el despliegue es una especie de tal vez el siguiente paso a la derecha aquí una vez que todo esto esté completo. Pero lo que hace este modelo es que funciona de esta manera. Entonces no creas que vamos así y luego retrocede por el lado derecho. Lo que estamos haciendo es que estamos trabajando básicamente en estas capas aquí mismo. Por lo que tenemos esta capa superior, que es esta conexión entre requisitos y pruebas de aceptación que pruebas de diseño y sistema , integración arquitectónica y pruebas de módulos y unidades. Y la razón por la que hacemos esto es porque recuerdan en la última conferencia, estamos hablando de cómo hubo un problema con esto en que las pruebas es la situación donde encontramos bichos, ¿no? Bueno, si encontramos un bug grande, tenemos que ir todo el camino de vuelta para arreglar esos bichos. Entonces tenemos que irnos. Todos los entornos activos diseñaron la implementación para corregir esos errores. Bueno, alguien murió. Bueno, si lo fuera, si este es el paso donde encontramos más bichos no tendría sentido no ponerlo al final , sino cerca del principio y hacerlo a cada paso conforme bajamos. Y eso es lo que hace el modelo V. Entonces con esto, tenemos cada paso, y luego tenemos pruebas para verificar ese paso. Entonces hay lado derecho por aquí es básicamente verificación de verificación. Entonces el estilo correcto vamos a ser nosotros verificando que cada uno de estos pasos sea realmente bueno antes de seguir adelante. Y este lado derecho es justo lo que hemos estado haciendo. Que el diseño ahora con este modelo, tomamos esta porción de diseño y en realidad lo dividimos en sus sub componentes. ¿ Recuerdas cómo hablamos de arquitectura y ellos diferentes módulos para luego diseñar en su conjunto ? Entonces eso es lo que estamos haciendo aquí. Estamos asumiendo esto en realidad lo estaban rompiendo para que podamos tener diferentes partes para probar. Por lo que el 1er 1 es requisitos con requisitos. Lo que tenemos es que tenemos esta idea de aceptación. Pruebas, aceptación. Las pruebas son pruebas para asegurarnos de que los requisitos sean exactamente lo que queremos. Un ejemplo de esto sería simplemente llegar a los requisitos y tratar de casi crear simulaciones o potencialmente llegar a documentos que detallaran cada caso de uso. Entonces, ¿cómo estamos planeando exactamente que el usuario utilice el sistema? Y entonces básicamente estamos intentando casi simular lo que haría un usuario y ver si va a cumplir esas tareas. Por lo que nos fijamos en los requisitos. Intentamos crear un usuario que lo usara y ver si hay algo que nos perdimos, algo que no estamos entendiendo. Esto generalmente se hace con el cliente para asegurarse de que de nuevo sea aceptable, estuvimos haciendo lo que queremos hacer y por lo tanto será una solución aceptable. El siguiente paso es el diseño, y cuando hablamos de diseño así, estamos hablando de todo el sistema diseñado, así que estamos hablando de ese nivel realmente superior o decimos que vamos a tener esta sección, esta sección, esta sección en esta sección y tal vez sólo un poquito, como, tal vez comunicación aquí y comunicación así. Y esto va a ser el todo piensa Este es el diseño de todo el sistema en su conjunto. Y la vez que tengamos eso, vamos a hacer algunas pruebas del sistema, tal vez inventar un par de casos de prueba un poco de código solo para ver y asegurarnos de que este diseño funcione correctamente. Entonces vamos un paso más lejos. En realidad nos metemos en estos. Empezamos a diseñar arquitecturas, resolvemos todo esto, funciona y luego hacemos integración, pruebas, pruebas, asegurándonos de que todo esto funcione en conjunto y luego que funcione en conjunto, aún con el otro unos. Y luego hacemos todo el camino hasta las pruebas de módulos, que es donde los dividimos en los diminutos módulos, los bits de código que en realidad se están comunicando entre sí. Hacemos esa idea de las pruebas unitarias, que hablamos, y luego una especie de ir tal vez de vuelta a la cadena para asegurarnos de que el resto funcione con todo lo demás por todo esto porque hemos hecho todas las pruebas en este fase. Una vez que llegamos a la implementación y lo cubrimos, terminamos porque las pruebas se hicieron a lo largo de toda la parte de la misma. Y ahora estamos en cierta forma de garantizar que no nos topemos con esto, esta gran área donde vamos a tener un montón de bichos que los van a encontrar antes y por lo tanto va a reducir el costo porque en lugar de encontrarlos tal vez aquí arriba en el línea de tiempo de costo, los encontramos aquí abajo. Y estamos tratando de asegurarnos de que los encontremos antes de este punto, y no terminan en cascada hasta ese punto. Y así de eso se trata el modelo V. Es una especie de siguiente paso en la botella de cascada. Ahora la única estafa con esto es que hay más trabajo inicial en eso. Cada paso que damos, tenemos que llegar con algoritmos de prueba completos. Recuerda, estamos hablando de pruebas. Las pruebas son difíciles. Es algo que no es muy fácil de pensar y tampoco muy fácil de implementar. Entonces con eso en mente, tenemos que entender que por la forma en que estamos haciendo esto, tenemos que probar que cada sección de la SEC aquí, y eso significa que vamos a tener más costos por anticipado. Va a ser más difícil. Va a ser un poco más complejo administrar este software. Pero es genial si tal vez no estamos 100% seguros, tenemos una especie de idea de la forma en que queremos ir, pero no estamos 100% seguros sobre el sobre cómo llegar en esa situación. Queremos utilizar el modelo V para que podamos dar pasos para seguir probándolo para asegurarnos de que estamos caminando por el camino correcto. 4. Modelo de Sashimi de 1 a 3: el siguiente modelo del que vamos a hablar es esta una modelo Sheemie? Y esta especie de modelo se construyó a partir de una idea en la que tal vez no pensábamos al principio. Pero cuando lo piensas, es muy práctico, y es que en cada una de estas fases, no necesariamente tenemos exactamente los mismos ingenieros. Entonces muchas veces estamos bajo la suposición de que tal vez tenemos uno o dos ingenieros y ellos van a hacer los requisitos y luego diseñar y luego la implementación en las pruebas y despliegue en el mantenimiento. Pero normalmente lo que tenemos es, sobre todo en empresas más grandes, es que tenemos ingenieros específicos que hacen cosas como los requisitos que hacen cosas como el diseño, ya sea el back end o el front end, que tenemos ingenieros de implantación. Contamos con ingenieros de pruebas, contamos con ingenieros de despliegue y mantenimiento. Y por todo esto, tenemos este tema donde si lo hacemos paso a paso, como en los ejemplos anteriores con el modelo E V y el modelo de cascada, todos estos ingenieros, aquí abajo hay que esperar hasta el anterior se completa el paso, y luego una vez que se completa el paso anterior, todos los ingenieros y la parte superior están esperando una vez más. Por lo que obtienes este tipo de área donde mucha de tu fuerza laboral está sentada esperando que otra fuerza laboral complete sus tareas. Y así el modelo sashimi, tenemos la capacidad de dibujar estas líneas hacia abajo. Entonces básicamente lo cortamos. Entonces es el modelo sashimi. Si alguna vez tuviste sashimi, es un, uh, un plato de pescado básicamente crudo cortado, y por lo general se coloca uno encima del otro, como por lo general el uno sobre el otro. Y por eso es así. Ella me modelo es porque tienes estas piezas todas puestas una encima de la otra, y luego básicamente cortas dos categorías diferentes aquí. Entonces si seguimos adelante, no podríamos dibujar estas rodajas básicamente aquí y qué es esto. Estas son las diferentes fases del desarrollo, y nosotros,por supuesto, tal vez haríamos por supuesto, estas fases como tal vez tengamos objetivos de un mes o objetivos de dos meses. Pero esencialmente lo que estamos haciendo es estar haciendo un poco de todo en cada una de estas fases. Entonces con los requisitos y esta gráfica vamos por aquí. Por lo que el tiempo a medida que pasamos por el tiempo, nos dirigimos por este camino. Entonces como cuando empezamos, ya sabes, comenzamos con los requisitos, el diseño y tal vez un poco de implementación, tal vez un poco de pruebas aquí y luego la siguiente fase. Seguimos trabajando en los requisitos y el diseño y ahora mucha de la implementación . Pero también estamos recibiendo nuestras pruebas y nuestro despliegue son mantenimiento. Ingenieros involucraron el despliegue. Ingenieros están averiguando la mejor manera de jugarlo el mantenimiento o tal vez creando sistemas. A lo mejor había sacando modelos de prueba o betas. Que estos chicos estén trabajando está bien, y seguimos haciendo esto con cada paso. Entonces en el siguiente paso por aquí, lo que sí tenemos es que ahora estamos haciendo todo. Lo estamos cortando todo al mismo tiempo. Y luego aquí abajo, lentamente nos apagamos hasta que apenas estamos en la fase de mantenimiento. Y de nuevo, esto nos ayuda porque permite que diferentes disciplinas comiencen a trabajar más rápido y también acorta el tiempo de desarrollo en lugar de tener que esperar. Digamos, si fue, ya sabes, aparecen dos semanas. Por lo que esta es cantidad de semanas 23456 y siete semanas para cada una de estas. Después de que esta tarea es de siete semanas para completarse, esta tarea tardaría cinco semanas. Imagínese si hiciéramos estos uno a la vez eso serían dos más tres más cuatro más cinco más seis más siete. O lo que podemos hacer es trabajar un poco en ellos todos, y básicamente todos los estamos iniciando casi dentro de la misma semana. Por lo que probablemente el tiempo total saldrá a alguien alrededor de siete u ocho semanas en lugar de sumar todas estas juntas. Y eso es mucho del tiempo seguro ahí. Ahora, el tema que podríamos tener con esto es que puede resultar en aire y rediseño. ¿ Qué significa esto es igual que qué? El modelo de cascada. Si encontramos un aire, ATT es algún punto, vamos a tener que ir todo el camino atrás, y el error es mawr prevalente en esta situación, y eso es porque no hemos terminado los requisitos ni el diseño. Y aún. cuando estamos implementando y probando, lo que significa que por aquí podríamos encontrar algo que necesita ser reelaborado por completo y todo el dedo del pie atrás, tal vez así por aquí necesita ser reelaborado. Y por eso, todo el trabajo que no Onley sólo tenemos que reelaborar los requisitos. Ahora tenemos que reelaborar todo lo que tocaban los requisitos. Entonces todo aquí abajo, vamos a tener que volver a trabajar. Entonces como que nos abre a esto, este potencial donde si no pensamos en esto y si somos un poco descuidados y teniendo aire tarde, vamos a tener que hacer un montón de reelaboración y en realidad puede resultar que lo hará que sea más lento desarrollarse de esta manera si tenemos esos aires. Pero si no tenemos esas flechas, tenemos un gran trabajo por su utilización y eficiencia y realmente hemos acortado el tiempo de desarrollo. 5. de 1 -4 Incremental mental en Incremental vs. con: Por lo que para el próximo par de modelos, necesitamos entender un par de términos. Entonces eso tiene sentido. Y esta va a ser esta idea de verso incremental. Iterativos e incrementales e iterativos son bastante similares, excepto que tienen una especie de forma diferente de tener el en producto. Y lo que queremos decir con esto es que ambos avanzan y avanzan hacia el objetivo final construyendo sobre un producto original. Entonces hay algo con lo que empezamos y estamos construyendo sobre ello. No obstante, con incremental fueron construyendo a lo largo del tiempo. Piensa en como una línea de montaje donde nunca vamos a llegar al producto final hasta que estemos en el producto final y una iterativa donde realmente construimos muchos productos finales y seguimos haciendo otros nuevos que estén un poco más cerca de nuestro producto final. Pero eso funciona casi completamente. Entonces vamos a repasar el para escuchar un poco más en profundidad. Por lo que de nuevo, nuestro 1er 1 es incremental. Construir pasos a lo largo del tiempo, línea de montaje , ya sabes, tenemos, ya sabes,empezamos con un auto y empezó como un marco, y luego se mueve a, ya sabes, el lado exterior del interior de quizá el motor, etcétera, etcétera. A lo mejor estábamos hablando de construir una computadora. Entonces empezamos con, ya sabes, el caso, y luego el siguiente paso, se lo mandamos a la gente que metió las placas base. Entonces tenemos una pizarra madre ahí dentro, y luego el siguiente paso, se la enviamos a la gente que va a meter la CPU. Por lo que ahora tenemos un tablero madre en la CPU y el siguiente paso. Ahora tenemos una CPU de placa madre, y luego le ponemos un poco de ram, y así sucesivamente y así sucesivamente hasta que tengamos una computadora finlandesa. Pero ten en cuenta que en ningún momento durante esto tenemos una computadora que pueda operar. No hay nada donde realmente vamos a tener básicamente algo que podamos darle a un cliente para ver cómo va. Estamos construyendo a lo largo del tiempo. Estamos dándole un paso a otro al siguiente. Y eso es lo que es el modelo incremental. Nos fijamos en estos pasos, estas metas que queremos lograr, y básicamente construimos hasta ese objetivo y tenemos estos, como casi muchos proyectos para construirlo desde este estado hasta este estado. Entonces digamos ST 123 y cuatro. Entonces lo estamos construyendo desde el estado uno para tratar de llegar al inicio del estado para luego vamos del estado para tratar de llegar al principio. Estate tres y nos movemos, como así ahora con el modelo iterativo estaban construyendo prototipos, y lo estamos ajustando con nuevos prototipos. Esto sería como si construyéramos un auto y construyéramos una versión realmente, realmente mala. A lo mejor con, como casi, ya sabes, robar asientos dentro. Por lo que ni siquiera hay como relleno en el interior. Es solo este asiento de acero dentro de esto. Este auto, tiene un par de ruedas encima, y eso es más o menos ahí. Sigue siendo una cuadra para Ni siquiera hemos diseñado esa parte. Pero el siguiente, en realidad empezamos a refinarlo un poco. A lo mejor le agregamos un poco de forma. Entonces, en lugar de este tipo de apariencia bloque ahora, en realidad tenemos ah mejor parte de la aerodinámica en ella. Teníamos, ya sabes, mejores ruedas a ella. Teníamos mejor siembra, y luego la siguiente parte tuvimos las características de lujo. A lo mejor teníamos algo más y así sucesivamente y así sucesivamente. Pero cada uno de estos productos va a cumplir todas las tareas a la mano, lo que significa que si tenemos esta tasa de producto aquí, debería poder hacer básicamente todo lo que el producto final debería poder dio. No obstante, este producto aquí mismo va a ser una versión peor de eso. Va a estar usando parte más barata. Va a ser donde el diseño no esté totalmente implementado. A lo mejor algunas cosas son experimentales en esto. Estamos probando algunas cosas. Estamos probando las ruedas en esto, por ejemplo, pero aún deberíamos poder operarlo. Deberíamos seguir siendo capaces de mostrárselo a un cliente. Si este es, ah, software en cada uno de estos lados, este, nunca podríamos mostrarle a un cliente hasta esta porción de aquí, quizá podríamos mostrarlo una vez que casi se haga. Pero definitivamente no al principio. Si bien esta tasa después de terminar el primer prototipo, deberíamos poder mostrarle esto al cliente y decir, Aquí es donde estamos ahora mismo, ¿sabes? Vamos, tomemos un chofer de prueba déjame mostrarte cómo funciona este programa. Déjame mostrarte algunos de los pequeños detalles del programa. Y luego la próxima vez, tal vez van a dar retroalimentación y eso va a entrar en nuestra próxima generación. Vamos a hacer algunos ajustes y mostrarlo hasta el principio y otra vez. Y esa es la diferencia entre incremental e iterativo. Es una diferencia importante. Suenan mucho como, y son muy fáciles de confundir, pero entender eso es importante para algunos de los siguientes pasos. 6. Modelo incremental de 1 a 5: por lo que el modelo incremental utiliza ese término del que acabamos de hablar, que es incremental, estaban implementando algo pasado. Entonces con modelo incremental, lo que hacemos es básicamente completar el proceso de desarrollo de software varias veces lo largo del curso del desarrollo. No obstante, con cada proceso, tenemos una determinada meta en mente. Entonces tenemos, por ejemplo, el oro para, ya sabes, construir el backend o construir el front end o construir un for mount. Construye una página fuera y vamos adelante. Creamos los requisitos para diseñar la implementación, las pruebas y luego desplegamos en lo que va a ser nuestro producto final. Entonces, básicamente entramos en el primer incremento. Una vez que eso haya terminado, entraremos en la segunda o no tiene que serlo. Además, no tenemos que terminar esto para llegar al segundo. Muchas veces pasarán a los pasos y luego una vez que hayamos pasado, por ejemplo, comenzará la implementación que pasemos a probar el desempleo. El siguiente incremento iniciará la siguiente fase de desarrollo, y esto nos permite especie de tener este poco de solapamiento aquí, lo que de nuevo nos permite seguir trabajando a un ritmo eficiente, y a lo largo de este proceso, lentamente estamos construyendo hacia el producto final. Los incrementos de los mismos también nos permiten lucir partes finales del diseño. Entonces si esto por ejemplo, fue la portada y un par de formularios, podríamos mandar eso al cliente y decir: ¿Esta parte de ella se ve bien otra vez? Este no es un producto terminado. No podemos hacer que prueben todo el asunto y nos den retroalimentación para cambiar todo el asunto . lo que podemos hacer, sin embargo, se le da un poco de retroalimentación sobre las piezas y piezas actuales que construimos y ver cómo, exactamente les gustan esas partes y piezas. Entonces construimos la portada y un par de granjas en un par de páginas, y ese es nuestro primer incremento. Una vez hecho eso, podemos enviar al cliente para su retroalimentación y luego pasar a la siguiente fase, uh, con cualquiera de esos cambios, o hemos creado nueva fase sobre cambiar realmente cualquier cosa que el cliente tuviera problemas con, y con esto tenemos esta idea de poder especie de poner estas puertas a lo largo del proceso donde podamos seguir adelante. Podemos seguir produciendo, pero también podemos seguir recibiendo retroalimentación para ver si el producto y el proyecto va en la dirección que queremos que vaya. Agrega un poco de adaptación al proceso. Recuerda predictivo y adaptativo. Esto nos permite llegar un poco más lejos en ese lado adaptativo donde realmente podemos movernos y adaptarnos con lo que el cliente está pensando y con la forma en que va la producción . Esto también agrega capas de esos comentarios lo que nos ayuda a salir también. Un lado negativo de esto es de nuevo las reobras. Si sí necesitamos hacer reobras Mayores aquí, tal vez ya empezamos a desarrollarnos con esto en mente aquí arriba por lo que tal vez tengamos que cambiar algunos de los desarrollos futuros. Cambie los requisitos solo aquí pero aquí y aquí, lo que cambiaría todo el montón de procesos más adelante también. Tenemos que ir hacia atrás y reconstruir cosas diferentes. Otra cosa es el costo. El costo de ejecutar todo un montón de incrementos diferentes va a ser mucho mayor. No sólo vamos a tener que tener esta sobrecarga de manejar esta cosa, también vamos a tener que tener múltiples equipos dedo del pie trabajando en diferentes incrementos porque el mismo equipo que está trabajando en este incremento para terminar este fuera podría no ser el mismo equipo que pueda trabajar en esto. De lo contrario, como que entramos en esta cosa lineal o simplemente nos estamos moviendo de uno a otro al siguiente, y eso puede ser un proceso. Podemos hacer un proceso incremental donde lo hacemos simplemente pasar de uno a otro. Pero perdemos un poco del beneficio cuando hacemos eso, porque perdemos un poco de esta velocidad y esas cosas. Ganamos a través de esto, pero ese es el modelo incremental. Es una gran forma de empaquetar diferentes procesos de diseño. Y lo que es ordenado de esto es que en cada uno de estos procesos, realidad podemos usar un modelo completamente diferente. Por lo que este podría ser el modelo incremental, y podríamos usar la cascada para este modelo. Podríamos usar el modelo aquí abajo, y nos vendría bien una ella yo aquí abajo. Realmente no importa porque todos son pequeños productos individuales. Pero el modelo incremental es importante, y es un bloque de construcción muy bueno para otros modelos en el futuro. 7. Marco de procesos unificado de 1 a 6: Entonces el siguiente modelo del que vamos a hablar en realidad no es un modelo, sino más de un que llamamos marco, y la razón de esto es que en realidad podemos usar modelos dentro de este modelo. Por lo que a lo largo de este proceso, podemos utilizar diferentes modelos como el modelo de cascada o modelo de TV. ¿ Eso me ve a lo largo de todo este cada paso con aquí? Y así no estamos una especie de restricción a un solo modelo, fueron básicamente tener un plan de juego o una visión general de lo que estamos tratando de hacer. Y luego a partir de esto usamos modelos para lograr esas tareas. Por lo que este es el marco de proceso unificado. Y hay muchas desviaciones de esto probablemente arriba de 20 desviaciones diferentes de personas que han mirado esto y tratado de llegar a una que resuelva un problema específico . Por ejemplo, hay uno llamado el modelo Racional, Proceso Unificado. Ahí hay uno que es muy ligero. Hay uno que está específicamente diseñado para más cosas como Agile. Hay muchas iteraciones diferentes porque esta es una muy buena manera de captar la idea del desarrollo de software y luego una especie de dar una visión realmente Ni de ello. Entonces esta es una especie de gráfica aquí a la izquierda de donde pasamos nuestro tiempo. Tenemos estas diferentes fases llamadas inicio, elaboración, construcción y transición. Y estos de aquí son una especie de básicamente marcador de posición. Si estás en una empresa, crearías tus propios ojos o facilidad o ve a Ortiz y cada uno de estos tendría un objetivo al final de la misma. Por lo que en cada fase de construcción, pondrías un gol al final de la fase. Y así es como lo sabes, si has pasado a la siguiente fase de una vez, esas cosas se han completado, y esto es sólo tratar de darte una idea de cómo funciona este proceso. Está en la fase de inicio. Estamos determinando la viabilidad del proyecto. ¿ Puede ser algo que podamos construir esto incluso posible? Nos fijamos en el horario y costo del proyecto potencial. Trata de estimar, ya sabes, ¿cuánto tiempo va a tardar? ¿ Cuánto le vas a costar a la empresa? ¿ Cuál es el retorno de la inversión? Entonces decidimos. ¿ Queremos comprarlo o construirlo? A lo mejor hay una solución ahí fuera. A lo mejor hay una solución parcial por ahí que podamos comprar la solución parcial y construir a partir de ahí. Tenemos que mirar eso también en la fase inicial. Y entonces la entrega ble o la meta para esto es tratar de conseguir algunas metas del ciclo de vida, tratar de descifrar el plan, averiguar hacia dónde nos dirigimos, cuál es el costo, quién Necesitamos una cosa más alta como esa. Y eso es en esta fase de inicio, y verás que tenemos este tipo de lo que hemos estado hablando todo este tiempo por el lado izquierdo. Aquí tenemos los requisitos para diseñar la implementación y las pruebas y el despliegue aquí y luego esta idea de modelado de negocios, que es solo esa idea, ya sabes, costos y gente a contratar y cosas por el estilo. Y así notarás que en la fase de inicio, lo que estamos haciendo es que estamos haciendo un poco de requisitos, especie de tal vez dando un boceto áspero de lo que estamos tratando de crear. Pero realmente modelado de negocios, estamos averiguando es esto algo que nuestra empresa quiere dedicar el tiempo y el recurso es construir, y eso es importante porque no queremos construir algo que no nos va a hacer dinero a la larga. Y esta es una gran manera para la gestión de riesgos. En lugar de saltar a un proyecto y gastar mucho dinero, gastamos una pequeña cantidad de dinero exploratorio por adelantado y averiguamos si esto es bueno para nosotros una vez que estemos fuera de esta fase. Una vez que tenemos una idea, tenemos algunas marcas de cheques que dicen, Sí, sigamos adelante con ello. Bajamos a la fase de elaboración, las fases de elaboración donde tomamos esta idea. Esta y esta idea de que tuvimos un inicio y lo construimos, se nos ocurrió sus requerimientos. Por lo que aquí es donde los requisitos vienen en pesado. Aquí abordamos los factores de riesgo conocidos. Verificamos y validamos las arquitecturas del sistema. Entonces en ese caso, realidad vamos a construir potencialmente el código prototipo muy básico para las pruebas. Entonces vamos a construir una idea de código muy, muy suelta que se va a hablar entre sí. Es como que va a hacer lo que sí tenemos, pero básicamente nos va a mostrar que es posible. Básicamente, prueba de conceptos es lo que llamamos a estos. Entonces vamos a escribir algún código, a ver si funciona de la manera en que creemos que va a funcionar. Y a partir de ahí realmente podemos empezar, ya sabes, elaborándolo sobre él en la construcción. Pero en esta fase, estamos haciendo sólo un poquito de eso. Y por eso se puede ver que la implementación sube aquí. Estamos empezando un poco la implementación otra vez para tratar de descifrar ¿Se puede hacer? Y si es así, ¿ de qué manera? Estamos haciendo un poco de pruebas porque necesitamos ver si está haciendo lo que pensamos que debería ser y luego desplegando. Lo estamos desplegando a otras personas se lo estaban dando a los probadores estaban mostrando a la gente que, oye, esta prueba de concepto en realidad sí funciona. Y entonces esto es pesado y el análisis y diseño también. Entonces estamos construyendo diagramas de casos de uso y diagramas de clase y diagramas de arquitectura, etcétera en construcción con la construcción. Lo que estamos haciendo es que estamos construyendo la cosa. Por lo que en realidad estamos trabajando fuertemente en la implementación aquí. Vamos a poner todo nuestro recurso en esto, y esta es la fase más larga y más grande del proyecto. Se puede ver por esto que elaboraron con múltiples ver valores aquí, múltiples fases diferentes y tipo de formas de pasar por esto. Este sistema se construye sobre la base trazada por la elaboración. Por lo que hemos construido este tipo de arquitectura, este modelo muy pequeño o tal vez incluso un pequeño proyecto. Y a partir de eso vamos a construir a partir de ahí. Características se implementan en iteraciones de caja de tiempo corto. Esto es importante. Esto significa que estamos construyendo básicamente trabajando plenamente en productos sin características. Entonces tenemos, por supuesto que ya sabes, empieza con la caja, y más tarde agregamos las características como es un auto que teníamos las ruedas y más tarde agregamos, ya sabes, el parabrisas, etcétera, etcétera. Pero lo que estamos haciendo es empezar con una unidad factible. Entonces aquí, ya sabes, me refiero al mal. Dejar de fumar. Podríamos poner, ya sabes, cuadras cuadradas aquí. Sigue siendo un auto. Todavía es capaz de ser impulsado, pero con el tiempo lo estamos haciendo mejor y mejor y mejor. Estamos agregando más características estaban recibiendo un poco de retroalimentación, y estamos agregando más características debido a esa retroalimentación y haciendo mejores y mejores iteraciones. Y esto se está llevando bien esa idea de la aireación. Recuerda, intuitivo e incremental Will esto realmente logra un poco de ambos en las diminutas partes aquí. Lo que estamos haciendo es incriminar. Entonces estamos haciendo uno haciendo pequeños incrementos hasta hacer una iteración real. Una vez que terminamos la generación, la desplegamos, obtenemos algunos comentarios de ella, y empezamos de nuevo en pequeños incrementos hasta llegar a esa iteración y así sucesivamente y así sucesivamente y así sucesivamente. Y la entrega ¿Qué? Aquí hay un flujo continuo de software de mejora. Entonces vamos a tener, ya sabes, aquí es donde tenemos la versión. Ya sabes, yo creo que por lo general empieza con, como, 0.1, que obtenemos 0.20 punto tres etcétera, donde en realidad empezamos a llegar con estas etiquetas de versión a medida que nos ponemos mejor y mejor. Y finalmente tenemos esta idea de la transición. En la transición se despliega el sistema a los usuarios objetivo. Se recibe retroalimentación, se hacen refinamientos y el toro de entrega es una vez que esto está completo, el producto final también está completo. Por lo que en la fase de transición, la mayor parte de nuestro diseño está prácticamente hecho se estaban acabando. despliegue se estaba refinando y asegurándose de que el modelado de negocios y los requisitos sean completamente encontrados. Aquí arranca la fase de pruebas, y realmente comenzamos la fase de despliegue donde se la damos a la gente y vemos qué piensan al respecto. A ver si necesita haber algún cambio si necesitamos hacer un par de iteraciones más sobre el proyecto final. Y así, con ese tipo de ideas con esta idea, tenemos un marco sobre el cual podríamos crear nuestro plan. Entonces esto no es algo que sepas que puedes mirar. Y va a haber una guía 123 sobre cómo crear un marco de procesos unificado para tu proyecto. Todo lo que es es solo estos grupos y este tipo de esbozo de lo que debes hacer. Y luego a partir de eso, tienes que desarrollar un plan completo para tu proyecto. Debido a esto, tenemos ciertos pros y contras asociados a esto. Los pros son que es adaptativo. Su enfoque de calidad y reutilización. Está enfocado en la gestión de riesgos en cada paso. Estamos una especie de re evaluando los requisitos, averigúle si sí necesitamos seguir continuando o si debemos abandonar el proyecto flexible haciendo corporativo. Otros modelos podemos, como dije, incluir otros modelos y áreas en cada uno de los pasos cada incremento. Podemos cambiar el modelo por completo y trabajar a partir de ahí. El contras O r Si mirabas esto y decías: Bueno, Bueno, ¿cómo implementamos realmente eso? Bueno, la forma en que lo haces es que necesitas un montón de buenos gerentes y gente calificada para llegar a este plan desde el principio. No es fácil. No es algo donde podamos simplemente mirarlo e ir, Sí, OK, déjame solo sacar un pedazo de papel y anotar esto muy rápido. Tiene mucho overhead, y eso lo hace muy complicado. Va a tener demasiados gastos generales para proyectos a pequeña escala si vas a hacerlo. Y a pequeña escala es algo incluso tan, uh, tan grande como, como, una aplicación como una aplicación en la tienda APP que justo como una sola tarea, digamos tal vez es un juego en la tienda APP. Eso podría ser demasiado pequeña de una escala para que esto realmente sea ah marco factible de usar. Y entonces Eso significa que tienes esta cosa realmente grande donde no tienes muchos proyectos que encajen en esto. Estamos hablando realmente, realmente grandes proyectos o proyectos que tienen muchas disciplinas diferentes involucradas. Ya sabes, cosas que contactan a los servidores y diferentes ojos AP y cosas que se construyen en el front end y el back end y todas estas cosas diferentes. Ahí es donde podría justificarse esto. Pero para muchos proyectos, esto es demasiado complicado y también por la forma en que está diseñado por esta forma de donde estamos haciendo todas las fases a la vez, y potencialmente estamos trabajando en diferentes modelos y oraciones todo al mismo tiempo, va a necesitar más. El recurso se está ejecutando. Cuantos más programadores, más gerentes, más probadores. Mawr Uh, básicamente todo más dinero para hacer esto, y la línea de tiempo también probablemente va a ser bastante rápido, pero va a costar mucho, así que tenemos el camino. Esa es la velocidad de la misma importante debido a este costo. Pero ese es el marco de proceso unificado. Definitivamente voy a buscar esto en Google o algo en, y lo miro un poco más porque hay mucha variación diferente de esto, y todos son bastante carne y carne y bueno para entender cada vez que estás aprendiendo sobre ingeniería de software. Pero esto es algo muy importante, y este es en realidad uno de los marcos más utilizados dentro de la industria hoy en día. 8. Modelo espiral de 1 a 7: Por lo que ahora tenemos el modelo espiral. El modelo espiral es justo que es una espiral. Lo que estamos haciendo aquí es que constantemente vamos sobre el mismo tipo de áreas de desarrollo una y otra vez para asegurar que ambos estamos hiper analizando los riesgos o analizando a cada paso. Y nos estamos asegurando de que vamos y validando lo que estamos haciendo a medida que avanzamos, hay un muy orientado al riesgo. Estamos tratando de avanzar con pasos muy pequeños y asegurándonos de que tenemos esta idea de ir o no ir. Significado. ¿ Queremos continuar con el proyecto, o queremos desechar aquí? Es muy bueno para ideas experimentales, ideas que crees que podrían ser posibles, pero aún no sabes realmente, así que como damos estos pequeños pasos adelante y nos aseguramos de que no entramos todo en punto inédito. Simplemente queremos asegurarnos de que estamos analizando la situación, analizando lo que hemos hecho y procediendo si aún es factible y una buena idea proceder . Entonces, ¿qué? El modelo espiral? Lo que hacemos es empezar en estos cuadrantes y pasamos por ellos continuamente. Entonces este es el cuadrante 123 y luego cuatro. Y lo que hacemos es ir. 123412341234 Así y lo que estamos haciendo mientras seguimos saliendo cada vez más lejos es que estamos ampliando el alcance, el costo, el nous en profundidad de cada paso, el tiempo general que dedicamos en ello. Por lo que al principio mismo, estamos creando prototipos rápidos. Y luego a medida que salimos, se vuelve más lento. Nosotros lo miramos más. Ponemos un poco más de análisis en lo que hacemos. Más pruebas hasta llegar a un producto final en algún momento. Entonces digamos que empezamos aquí tasa en esta parte, que es que vamos a determinar objetivos, alternativas y restricciones. Entonces aquí estamos determinados estos objetivos, las alternativas que las restricciones estaban determinando todo lo que es el proyecto, básicamente estamos llegando con un plan. A partir de ahí nos movemos e identificamos y resolvemos riesgos. En este punto, simplemente estamos identificando riesgos más o menos. No hay nada que resolver realmente ya que no hemos codificado nada y se nos ocurre un prototipo que en esta situación es sólo un plan. Entonces realmente empezamos a ejecutar ese plan, el concepto de operación. Entonces aquí podemos tener en lugar de codificar realmente en esta primera fase inicial, tal vez creamos, ya sabes, modelos de clase. O tal vez se nos ocurre una especie de idea general sobre cómo va el concepto el trabajo del dedo del pie. Y por eso se trata de una validación de concepto. Ni siquiera lo hemos hecho en los requisitos y cosas así. Entonces creamos el o lo miramos. Por lo que jugamos en la próxima generación. Por lo que se nos ocurrió este concepto que viene con esta idea general de cómo debe funcionar un prototipo , analizar el riesgo. Ahora, vamos a llegar con el plan de requerimientos y el plan de ciclo de vida. ¿ Cómo vamos a desarrollar esto en realidad? Cómo vamos a llegar a un sólido conjunto de requisitos y luego lo planeamos, y eso es en exploración. Entonces ahora estamos viniendo por esto aquí, hacer otro conjunto de análisis de riesgos es que sigue siendo algo que parece factible con nuestros costos y nuestro presupuesto y nuestra mano de obra. Si es así, volvemos a construir ese próximo prototipo. Esto podría ser sólo una iteración en el plan. En general, no tiene que ser un prototipo de trabajo real. Es sólo una especie de tal vez la documentación es un poco más gruesa aquí. Seguidamente pasamos a las simulaciones. Eso están en esta situación particular. Estamos haciendo modelos de simulación o puntos de referencia. Esa es toda su área. Entonces estamos una especie de solo aquí extendiendo lo que estamos haciendo. Entonces en este bucle en particular probablemente estaban haciendo requisitos de software, validación de requisitos, cosas como esas, acabamos de llegar con el plan general del mismo. Entonces en realidad se nos ocurre un plan para la siguiente fase, que es el desarrollo. Pasar por aquí, hacer el desarrollo de la verificación, Hacer el análisis de riesgos al movimiento de integración. La siguiente fase Hacer análisis de riesgos, Mira un prototipos operativos de algo que realmente podemos dar a alguien condenación o pruebas de puntos de referencia y luego liberar. Y este es un modelo muy, muy especie de modelo básico. Podría haber ah, muchos bucles, y entre éstos, sobre todo durante la fase de desarrollo, podemos hacer de este tipo de modelo iterativo en ese sentido. Entonces aquí acabamos de tener un solo bucle donde básicamente recubrimos todo el asunto, y siguió adelante, pero podría haber una tonelada de bucles, y podría haber, ya sabes, 100 poco diferentes. Oraciones dentro de ese proceso de desarrollo donde constantemente estamos comprobando el riesgo y planeando nuestra siguiente fase, constantemente repasando los objetivos y restricciones y moviéndonos hacia afuera desde ahí. Y este es un modelo muy, muy poderoso porque eso enfocado al riesgo es muy bueno si estamos, ya sabes, dando pasos adelante en un área desconocida, y es muy, muy adaptativo. Entonces otra vez es que está a lo largo de esa idea de. En lugar de ir en línea recta, podríamos tener que movernos para llegar a nuestro objetivo. Este es un gran modelo. Haz eso porque constantemente estamos reevaluando lo que estamos haciendo, mirando lo que hemos hecho en el último ciclo y llegando a una nueva idea para el siguiente ciclo. Ahora esto parece complicado, y eso se debe a que es complicado, sobre todo en diseñar esto para un proyecto riel. Se pone muy complicado, y cuesta más manejarlo. Necesitas tener una muy buena idea de lo que estás haciendo para mantener todo en el camino para que no, ya sabes, empieces con una espiral y ellos simplemente como, Vale, solo vamos a cubrirlo y ya sabes, en realidad no pasar por las pruebas y la implementación y el constante análisis de riesgos. Y también se necesita un compromiso más constante de las partes interesadas. Lo que esto es el Stakeholder es como el cliente, la persona que está pagando por el software. Necesitas su compromiso constante en esto. Si vas a ir con las opciones para ir o no ir, lo que significa que continuamos, ¿ o abandonamos el proyecto? Vas a necesitar su opinión cada bucle sencillo. Si estos bucles lo son, digamos cada cinco días, tal vez ahí cada dos semanas. Incluso vas a necesitar a ese interesado cada dos semanas para venir a una reunión, sentarse, aprender sobre lo que hiciste esta semana anterior y luego decidir si quieren continuar o no. Y esto podría ponerse un poco tedioso para ellos. Por lo que se necesitan interesados que sean propensos a aquello que quieran comprometerse con el proyecto . Muchas veces no lo hacen. Simplemente quieren pagar a la persona tenerla construida, no quieren realmente estar involucrados en el proceso día a día de la misma. Pero si tienes todo ese modelo de aguja es un gran modelo para ese riesgo. La administración es un gran modelo para construir cosas que necesitan descubrimiento, donde estás tratando de dar pequeños pasos hacia adelante. 9. Introducción agilidad: Ahora hemos repasado un par de las zonas más tradicionales. Yo quería repasar algo que es muy nuevo. Es decir, cuando digo nuevo, es dentro de los últimos 20 años. Pero es algo a lo que muchas empresas han cambiado, y esa es esta idea de la metodología ágil o lo ágil. En general, Agile es una forma de pensar. Es una especie de conjunto de principios que aplicas. Y luego vamos a repasar un montón de modelos diferentes que funcionan con la metodología ágil , cosas como Scrum y Kon Bon y otros términos que podrías haber escuchado porque son más prevalentes en la industria actual. Los viejos, no estaban mal. Es sólo que Había lentas. Estábamos desarrollando productos del punto A al punto B. Así que empezamos. Cruzamos directamente y lo hicimos ahí. Ahora, a veces , ya sabes, tal vez nos desviamos un poco. Teníamos que volver a bajar y encontramos nuestro objetivo final. Pero eso es todo lo que podíamos hacer con los viejos. En el mercado actual en movimiento, las cosas cambian. formas de desarrollar tecnología están cambiando cada día, y debido a esto. Tenemos que asegurarnos de que estamos desarrollando el software que soluciona el problema. El problema en sí podría cambiar. Y por esto tenemos esta idea de este tipo ágil de manifiesto y de este conjunto de principios que nos permiten ser realmente, realmente fluidos y flexibles en nuestro proceso de desarrollo. Entonces eso significa que podemos llegar a ideas que nos hagan ir en direcciones completamente diferentes y seguirán desarrollándose con el cliente hasta que encontremos exactamente lo que buscaban . Y con el modelo típico, sería muy difícil para nosotros seguir moviendo esto. Perderíamos mucho dinero, pero con esto realmente lo tomamos en pequeños incrementos y podemos seguir moviéndonos en cada incremento en la dirección correcta y con el tiempo comenzamos a desarrollar el software correcto. Por lo que cada decisión que tomamos, poco a poco llegamos a ponernos. El cliente está contento o constantemente comunicándose con ellos para construir su producto final y al método de cascada o la cascada tipo de conjunto de ideas, que es una especie de todo en el ejemplo anterior que ese conjunto de, ya sabes, primero hacemos diseño y luego o primero hacemos requerimientos y luego hacemos diseño y luego empezamos a implementar y luego empezamos a probar ese tipo de idea. Donde vamos uno a otro tiene temas. Uno de ellos es durante la verificación. muchos problemas inesperados. Nosotros, por ejemplo, si codificamos un error en la arquitectura y estamos en la verificación antes de averiguarlo , realmente no hay ninguno donde podamos ir con eso. O si llegamos a una verificación, se la mostramos a nuestros clientes. Y dicen: Oh, Oh, no, eso no es exactamente lo que queríamos Pero hubo un poco de mala comunicación. Esto es lo que queríamos. Bueno, no hay forma de volver atrás y realmente no tuvimos oportunidad de arreglar eso de antemano con Agile. Tiene algunas soluciones de eso. Los sistemas de software son complejos y no se pueden predecir al 100%. Esto es algo que es muy, muy cierto es que si estamos contratando a alguien para que cree una siesta, tal vez no sepamos exactamente lo que queremos. El app a dio. Queremos comunicarnos con ellos a lo largo del tiempo para construir lentamente esta aplicación para construirla. De la forma en que queremos, y queremos que nos ayuden a averiguar qué queremos en una app, porque ellos son los que saben programar. Ellos son los que saben crear las cosas, nosotros como la idea. La gente no sabe exactamente lo que queremos que haga la app y lo que es capaz. Entonces queremos trabajar con alguien muy, muy inteligente. Una empresa de tecnología que en realidad desarrolla apt para llegar a la idea final y una metodología ágil te ayuda con eso. Al final, algún software no cumplía de nuevo con los requisitos originales o modificados. Si no es muy flexible, los requisitos pueden haber cambiado con el tiempo, y queremos ser flexibles para poder cambiar con ellos y luego los mercados se mueven con el tiempo. El producto podría estar anticuado para cuando terminemos. Ah, muchos de los modelos ágiles en realidad tienen esta idea de llegar con un M V P o un producto mínimo viable, algo que podemos sacar al mercado, ya sabes, dentro de cuatro meses algo que nosotros puede tirar por ahí que tiene sólo las características básicas pero nada más. Y en realidad podemos empezar a obtener comentarios de los usuarios y podemos empezar a resolver el problema. A lo mejor no al 100% pero al menos lo estamos resolviendo un poco con esto. Con la cascada, típicamente no sacamos un producto hasta que esté completamente terminado al 100%. Y por esto tenemos este problema realmente grande de ello podría estar anticuado. Digamos que lleva dos años desarrollar este software completamente bien. El problema ya podría haber sido resuelto por otra empresa en ese tiempo. El problema podría haber cambiado a lo largo de ese tiempo. Ah, pueden pasar muchas cosas diferentes donde podríamos quedar anticuados para cuando terminemos y luego todo ese dinero se desperdicia. Por lo que queremos asegurarnos de que podamos ser flexibles en situaciones en las que sabemos que los mercados se mueven constantemente. Y el manifiesto ágil era una especie de esto. Es un grupo de ingenieros se juntaron y decidieron que se necesitaba un cambio. conjunto se les ocurrió el manifiesto ágil que vamos a discutir a detalle en la próxima conferencia es un conjunto de ideas para desarrollar un software mejor, más rápido y más ágil. Se supone que debo mejorar el sistema en general, y muchas empresas han encontrado que hace justamente eso 10. Manifesto Agile: Entonces ahora hablemos realmente del manifiesto ágil. Lo mencionamos en la última conferencia, pero repasémoslo un poco más a fondo. Lo importante a entender sobre esto es ágil es un conjunto de lineamientos que conjunto de ideas con las que luego desarrollamos modelos. Por lo que no hay un modelo ágil ahí fuera. No hay un proceso de desarrollo ágil. Ahí está la pauta ágil, y luego creamos modelos basados en las directrices ágiles. Algo así como Scrum, por ejemplo, es un modelo que se basa en estos lineamientos. Entonces scrum es el modelo que desarrollaríamos en scrum. Pero scrum es un modelo ágil, y eso es sólo algo importante causa que mucha gente se confunde esto. Dicen, Ya sabes, estamos desarrollando una ágil cuando eso técnicamente no es cierto. Lo que están haciendo es que están usando un modelo que se basa en ágil, tan ágil de nuevo es este manifiesto. Es esta idea. Es su conjunto de pautas que utilizamos para desarrollar software, y en realidad podemos, si queremos, podemos poner estos números aquí mismo y son diferentes tipos de inquilinos o diferentes ideas y pautas. En lugar de ingenieros, ellos Básicamente, la historia dice que básicamente se juntaron y se les ocurrió esto. Creo que fue en algún lugar de los primeros dos miles. Todos se reunieron y decidieron que la ingeniería de software en general tenía un problema. Había un conjunto de problemas, y fue principalmente porque la ingeniería de software provenía de la ingeniería regular. Fue diseñado como una transición casi directa desde, ya sabes, como construir un puente y la gente pensó: OK, OK, construiremos software igual que construimos un puente. No obstante, software es un poco diferente, y hay requisitos ligeramente diferentes y formas de hacer las cosas cuando se habla de software. Entonces se juntaron y pensaron Vamos a llegar a una manera que mejoraría a toda la industria del desarrollo de software Y juntos se les ocurrió a estos cuatro inquilinos y muchas empresas las usan para inquilinos hoy en día porque básicamente son una muy, muy buena manera de hacer negocios. Aumentan la productividad, aumentan las relaciones con los clientes y en general aumentan las ganancias, que es a lo que las empresas del aire van. Por lo que el 1er 1 son los individuos y la interacción sobre el proceso y las herramientas. Entonces este se está enfocando en los individuos y los ingenieros y todos los involucrados en la construcción del software sobre el uso de alguna herramienta o algún proceso que hemos utilizado en el pasado y muchas empresas. Siempre que tipo de desarrollo o van de alguna manera, obtienen un conjunto de procesos y un conjunto de herramientas que utilizan. Y si un equipo de ingenieros llega a una ventaja y les dicen, ya sabes, pensamos que estas herramientas y procesos serían mejores. Muchas veces esas ideas derribaron el aire porque es la forma en que siempre se ha hecho. Esos viejos procesos y herramientas ya están en su lugar, así que por qué cambiarlo en esto intentaban decir que el individuo debería tener más control sobre la forma en que desarrollaron el software. Si el conjunto de individuos se unen y deciden que un nuevo conjunto de procesos, se debe implementar un nuevo conjunto de herramientas para mejorar básicamente la situación de lo que deberían tener mayor prioridad sobre la antigua forma de hacer las cosas, y queremos especie de trabajo también en este sentido, diciendo que el individuo es más importante que el proceso en las propias herramientas, queremos tratar a los individuos con respeto. Queremos tratar las interacciones que tienen con respeto. Queremos tratar de crear un buen ambiente de trabajo. No queremos, ya sabes, poner a sabes, la gente abajo porque quieren usar nuevo software y herramientas porque se están desviando ligeramente de los procesos y herramientas actuales. Queremos elevar a nuestros ingenieros, y queremos darles el mayor respeto posible. número dos está trabajando software sobre documentación integral, y esto es una desviación bastante lejana de las ideas anteriores de que hemos repasado las metodologías de cascada y los modelos de sashimi y todo por el estilo. Y esto se debe a que sabe que estaba muy enfocado en documentar y dejar todo cuadrado Antes de empezar a desarrollarnos aquí, aunque algo así lo volteamos de cabeza. Y queremos un software de trabajo antes o al menos como prioridad superior a la documentación integral . La documentación siempre es importante porque permite que nuestro software sea mantenible. No obstante, hay un límite donde si tenemos 15 libros sobre cómo debe funcionar nuestro software y cómo se va a construir, probablemente no vamos a poder demostrárselo a nadie y en realidad obtener alguna retroalimentación real respecto. Queremos crear un software de trabajo con un poco de documentación. A , ya sabes, una cantidad media de documentación, algo que podamos dar a los clientes o a dos probadores o a los usuarios y obtener retroalimentación real sobre eso para que podamos realizar cambios en tiempo real. No queremos esperar hasta el final para empezar a obtener retroalimentación, darnos cuenta de que algo anda mal, tenemos que cambiar todo el software y luego tenemos que reescribir toda nuestra documentación. No tiene sentido. Por lo que queremos enfocarnos en conseguir que el software funcione, conseguir que el software sea diseñado, correctamente, construido correctamente sobre documentar todo el proceso. De nuevo, no estamos diciendo que estamos renunciando a la documentación. Solo estamos diciendo que queremos dar un poco más enfocados a conseguir que el software realmente construido, luego trabajando en que quede perfectamente documentado. Número tres Colaboración con el cliente sobre la negociación de contratos. Queremos tener una buena relación con nuestros clientes y nuestros clientes. No queremos tener que apuntar a un contrato cada vez que se quiere un cambio o cada vez que algo necesita básicamente simplemente moverse un poco un montón de veces con los negocios. Obtienen este contrato y apuntarán al contrato. En cualquier momento sale algo y dice: ¿Qué dice el contrato? De acuerdo, no estamos haciendo nada diferente. Estamos tratando de decir es que la colaboración con el cliente es lo que nos va a conseguir ese buen producto final. Si entra el cliente y dicen Ok, me encanta adónde va el software Pero hay esta cosa nueva que recientemente salió y va a ser, ya sabes, tal vez este software necesita un poco de además aquí. A lo mejor necesita ser un poco reelaborado ahí. Queremos hacer feliz al cliente para que a nos den buenas críticas. Nos pagan apropiadamente todas esas cosas. Queremos que el cliente se sienta apreciado. Queremos que el proceso sea realmente, realmente agradable para ellos. Si cada vez que entran y piden cambios de vuelo, decimos: Bueno, Bueno, vamos a reelaborar el contrato. Terminamos entrando en conseguir que los equipos legales se involucren, reajustando los precios y pasando por todo esto. Va a ser un dolor y nadie va a querer trabajar con nosotros. Entonces lo que estamos tratando de decir es que queremos que esa colaboración sea primordial para Oh, fue, fue, al menos sobre los contratos de negociación de contratos. De nuevo, siguen siendo importantes. No estamos tirando todas estas cosas. Sólo estamos diciendo, Hablemos con el cliente Mawr. Hagamos una relación realmente fuerte para vamos y acabamos de seguir. Lee trabajó con contratos para responder al cambio por seguir un plan. Queremos poder ser flexibles. No queremos estar encerrados en un determinado plan, y cada vez que surge un tema, decimos, Bueno, Bueno, ¿cuál es el plan dicen que nos vamos a quedar con el plan si no podemos responder al cambio que estamos no en y de su ent o en y por sí mismo, ágil, que la palabra ágil no estuviera siendo que no estamos siendo flexibles con nuestro proceso de diseño, Y eso es lo que Agile está tratando de hacer es intentar crear un empoderamiento de la gente, realmente construir el software y hacer software que cambie con los tiempos porque tecnología cambia rápidamente. No queremos procesos que no nos permitan cambiar rápido con la tecnología, así que queremos dar de nuevo. Queremos un plan, pero queremos permitir cambiar ese plan. No vamos a permitir que seamos flexibles para mover el software de esta manera. De esa manera, siempre que colaboremos con el cliente, vamos a construir software de trabajo para que el cliente pueda ver lo que está pasando, y nos puedan dar ideas para que podamos responder al cambio. Queremos tener estos individuos e interacción tanto con el cliente como con nuestros ingenieros para que se presenten nuevas ideas, mejores ideas. Podemos cambiar nuestras herramientas alrededor, podemos construir software de trabajo, podemos mostrárselo a nuestro cliente, y podemos responder al cambio. Y así en general, ese es el manifiesto ágil que estamos tratando de crear. Este conjunto de lineamientos que nos permiten cambiar y movernos con el dedo del pie del Times nos permiten desarrollar software de una manera más óptima. Y ágil ha hecho una gran manera de clasificar que en las próximas conferencias vamos a empezar realmente a hablar de los modelos que se basan en ágil, y se puede ver que se podrán ver cómo se trata de formas más rápidas y rápidas de desarrollo de lo que hemos hablado anteriormente. 11. 2 -3 Scrum: Entonces el primer modelo ágil del que vamos a estar hablando es el modelo scrum, así que scrum que quizá hayas escuchado antes porque es una forma muy popular de desarrollar software y Scrum se enfoca en estos intervalos de 1 a 4 semanas diferentes. Entonces básicamente se les llama sprints y scram. Se trata de un sprint scrum y el sprint es esta idea de desarrollo rápido, agregando en las características de máxima prioridad, luego yendo al cliente, los stakeholders, todos los que estén involucrados, presumiendo ante ellos, tomando retroalimentación y rehaciendo el ciclo. Es su idea de planear, construir, aprender, repetir. Entonces vamos a hacer todo nuestro diseño definido, construir y probar dentro de este tipo de sprint scrum aquí. Y aquí es donde entran en juego las ideas de como back to back testing porque debilitar usado back to back testing para asegurarnos de que entre sprints, que no estamos rompiendo algo de la anterior y para asegurar que las nuevas características sean funcionando adecuadamente también. Entonces con cada sprint, vamos a estar creando un producto que sea un poco mejor que el sprint anterior . Es a su idea de básicamente prototiparlo. Entonces cada prototipo solo va a ser un poco mejor que el prototipo anterior y muchas veces tal vez después del tercer o cuarto sprint tenemos un producto que realmente podemos lanzar al mercado y luego empezamos. Seguimos desarrollándonos , agrega. Se estrena en el mercado para que podamos sacar un producto en, Ya sabes, tres meses, tal vez cuatro meses desde los que el cliente puede empezar a ganar dinero puede empezar a tomar estas ideas sobre cómo arreglarlo y hacerlo mejor. Y podemos seguir desarrollándolo en base a la interacción del usuario. Y así el scrum es muy popular por eso, es muy rápido de desarrollarse muy rápido para que el cliente empiece a ganar dinero, y también permite una flexibilidad extrema en el proceso de desarrollo. Por lo que son un par de personas diferentes involucradas en el proceso scrum. Tenemos al dueño del producto y básicamente son los stakeholders, todos los que están involucrados en querer esta pieza de software, por lo que de ellos obtenemos insumos de los ejecutivos, del equipo, los stakeholders, clientes y usuarios y luego el dueño del producto mira todo este tipo de entrada y ayudaron a priorizar la lista de los siguientes pasos, lo que debemos hacer para nuestro próximo sprint. Por lo que necesitamos comunicación constante con el propietario del producto y esto es una especie de desventaja porque tal vez tenemos un propietario de producto al que no le gusta pasar el tiempo priorizando lo que sigue. Ellos sólo quieren que hagamos todo. Y si ese es el caso, los inquilinos de la corte de Scrum se desmoronan porque se supone que básicamente estamos creando este diseño flexible que funciona con el dueño del producto. Si sale sale, él o ella sale. No tenemos ese insumo y empezamos a desarrollarnos en direcciones potencialmente erróneas. El maestro scrum. Ellos sostienen al equipo responsable de scrum ideas y facilitan reuniones y hacen resolución de conflictos a un poco de planeación a un lado. Y así la reunión scrum es básicamente la persona principal arriba para el modelo scrum ahí. Otro podría ser un ingeniero de software líder también. Eso es, ya sabes, trabajar con más el código pero el maestro de scrum está sosteniendo el equipo responsable del dedo del pie, asegúrate de que están siguiendo a todos los inquilinos de scrum y están haciendo todo de la manera adecuada y a la moda porque si nos desmoronamos y nos detenemos, ya sabes, apegándonos a nuestros sprints. Y nosotros no, ya sabes, golpeamos nuestros goles durante nuestros sprints. Entonces todo el proceso nuevamente se va a desmoronar porque no vamos a tener productos terminados para mostrarle a nuestro cliente. No vamos a obtener esa retroalimentación, y no vamos a ser muy flexibles. Y luego finalmente, tenemos al equipo, y ese es el equipo realmente construyendo el software. Y esto no son solo ingenieros de software. Podríamos tener ingenieros liderando ingenieros. Podríamos tener diseñadores. Podríamos tener solo codificadores básicos que no saben mucho de ingeniería, pero son bastante buenos en un solo idioma, haciendo una sola cosa. Ah, muchas veces esto podría ser ayuda contratada fuera para una tarea específica. A lo mejor vamos a buscar en un sitio Web freelance. Contratamos a alguien solo por este sprint para que nos construya un módulo, pague a la persona, y luego se va para el próximo sprint. A medida que obtenemos más y más personas, así está el equipo puede especie de cambio. Pero hay gente central en el equipo, y hay roles, y todos se unen para crear el en producto. Esta es una especie típica de forma que el scrum funciona es que tenemos esta idea del rezago del producto . Este es un conjunto de, ah, lista básicamente cosas que hay que hacer. Entonces tenemos, ya sabes, esta lista de ideas y cosas que hay que hacer, el problema. No sabemos priorizar esa lista. Por lo que muchas veces traeremos bien a los interesados para la reunión de planeación de sprint. Entonces les preguntaremos. ¿ Qué quieren ustedes a continuación en este proceso? ¿ Qué te ayudaría o qué Te gustaría ver? ¿ Qué es más importante para sacar este producto? Una vez que tengamos configurada esa idea, creamos un rezago de sprint donde este es esencialmente el conjunto de ideas en las que vamos a estar trabajando para este sprint actual. Establecemos un plazo. Si lo vamos a hacer en tres semanas, justo en dos semanas, lo haremos en 15 días. Vimos algún tipo de plazo para ello, tenemos nuestra lista de objetivos y luego iniciamos el proceso de creación. Entonces empezamos a tener estas reuniones diarias de scrum, que es esencialmente que son típicamente menos de 20 minutos. El equipo de scrum se reúne hablan de lo que hicieron ayer, lo que planean hacer hoy y con qué bloqueos de carretera están tratando y potencialmente qué pasos van a usar para arreglar esos bloqueos de carretera. Y esta comunicación es importante porque tal vez cierto usuario o cierto ingeniero habla de cómo están lidiando con esto este bloqueo de carretera con la integración de base de datos o algo así. Bueno, otro ingeniero, si te gusta Bueno, en realidad, lo he hecho en el pasado. Yo sé cómo arreglar esto. Reunámonos hoy y les mostraré cómo arreglar esto y superar ese bloqueo de carretera. Por lo que esta comunicación permite que diferentes ingenieros introduzcan en diferentes proyectos o diferentes partes del proyecto, y que se ayuden unos a otros. Completan toda su labor al día siguiente. Tienen la reunión diaria de scrum, y siguen avanzando. Esto también permite a todos hacer un seguimiento de lo cerca que están de terminar su sprint y mantener o asegurarse de que están a tiempo para su sprint. Una vez hecho el sprint, entra en Sprint Review. Típicamente traer de vuelta a los interesados en demostrar el Sprint toma algunas sugerencias, le preguntaron a un interesado, Es de esto de lo que estabas hablando. Dicen que sí. Excepto que estábamos pensando que esta área debería hacer esto y aquello. Marcamos eso hacia abajo, hacemos esas notas, y típicamente, esto tal vez volvería a entrar en el rezago del producto. Si bien tenemos a los interesados aquí. Nosotros les preguntamos. De acuerdo, ¿ Qué quieres en la próxima primavera? Nos dicen lo que buscan en el siguiente. Ellos priorizan nuestra lista. Empezamos el proceso de nuevo. Ahora, la cosa es que también hacemos una retrospectiva de sprint. Entonces después de que hemos hecho la vista de velocistas con las partes interesadas, los dueños de productos, todo el que sea, ya sabes, básicamente no ha visto este producto en las dos últimas son de 1 a 4 semanas. Después entramos en una retrospectiva de Sprint, que es sólo el propio equipo de software. Hablamos del proceso sobre cómo han ido las últimas 1 a 4 semanas y vemos si sus formas de hacerlo mejor lo que sabes, nos retuvieron en una especie de ambiente de equipo. Y lo que nos retuvo individualmente son maneras en que podemos arreglar que después de una retrospectiva de Sprint , comenzamos la siguiente planeación de Sprint. Obtén todas esas listas y repetimos el proceso una y otra vez hasta que el producto esté completo. Entonces scrum es genial por su flexibilidad porque tenemos tanta revisión, tanta retroalimentación de nuestros grupos de interés constantemente estaban consiguiendo orientación sobre lo que deberíamos hacer a continuación. No estamos más de comprometernos con algo donde nosotros, ya sabes, creamos este proyecto gigante y para cuando se desarrolla el producto, está completamente equivocado. Estábamos asegurándonos de que estamos haciendo estos pequeños sprints, caminando hacia adelante, paso a paso y tomando retroalimentación, Así que creamos el producto que el cliente nos está contratando para crear. 12. 2 -4 Kanban: nuestro siguiente modelo ágil es el de combine. Entonces si sabes algo sobre el idioma japonés, esta es una palabra muy japonesa, y la razón de esto es que en realidad se desarrolló en Japón. Sus orígenes podrían remontarse al Reino Unido en el desarrollo de Spitfire. Esos son realmente bonitos aviones que desarrollaron En aquel entonces, sin embargo, fue popularizado, refinado y realmente implementado en el mercado de consumo con Toyota y Toyota es una empresa japonesa. Básicamente echaron un vistazo al proceso actual de fabricación de autos, y querían hacerlo más situado. Por lo que todo estaba disponible que los fabricantes de automóviles de la fábrica podían conseguir. Todo estaba disponible como si no fuera un supermercado y podías subir y agarrar lo que necesitara para completar tu proceso. Básicamente, querían que todo para una persona, hacer su trabajo estuviera al alcance del brazo, y querían una tabla para rastrear el progreso, mirar el flujo actual y seguir mejorando el flujo para que pudieran hacer más y cada vez más autos, y se hizo muy popular. Hizo del inodoro un convento muy, muy exitoso ha sido desde entonces adaptado al mundo del software y es el mismo tipo de técnica que queremos mentir popular o quieres refinar nuestro flujo. Yo quiero tomar el flujo de tarjetas de bugs de características, y queremos saber dónde están los cuellos de botella y seguir mejorando continuamente en ello. Y aquí hay un pequeño ejemplo de ello. Ah, muchas empresas de software usan algo como esto, así que tendrás tarjetas. El rezago es uso del que más se llena, por lo que tienes un montón de cartas en el rezago, y luego cuando queremos iniciar un proyecto, queremos iniciar una de las cartas. Simplemente lo movemos. Entonces digamos que tenemos una pareja en la fase de análisis uno en la fase desarrollada, y entonces tal vez tengamos cuatro en la fase de prueba y luego dos en la fase de lanzamiento. Apenas de mirar esto, vemos dos cosas que vemos. Tenemos un montón de cosas que ir. Todavía queda mucho en este proyecto, y vemos que tenemos un poco de cuello de botella en la fase de pruebas. Aquí hay un problema. A lo mejor no tenemos suficientes ingenieros en las pruebas. A lo mejor nuestras pruebas actuales o nuestras metodologías actuales con las pruebas son lentas o no están funcionando correctamente. A lo mejor hay muchos errores o errores que están sucediendo dentro de las pruebas debido a un análisis deficiente . Sabemos solo por mirar esto que hay un problema con la fase de prueba y que queremos mejorar la fase de prueba y tratamos de hacerlo de manera lenta, incremental. Hacemos un pequeño cambio. Volvemos a pasar por ello y vemos si estamos mejorando esto. Estábamos tratando de agarrar estos grandes números aquí. Estamos viendo qué porcentajes en la columna de pruebas. A lo mejor ahora mismo es algo así como el 25% de todas las cartas están sentadas aquí, y así tratamos de hacer algunos cambios. echamos un vistazo en dos o tres meses, y tratamos de tal vez bajarlo a un 15% mejor tipo de distribución en lugar de, ya sabes, están siendo este bulto grande y luego abajo y en este gran bulto y luego retrocede. Estamos tratando de, ya sabes, hacerlo para que esté perfectamente nivelado para que el desarrollo se mueva perfectamente a través , y con todo esto, tenemos un par de inquilinos centrales. Aquí tenemos las Propiedades Con Bon y los principios CONVEN, las propiedades aire, sólo una especie de ideas y cosas que podríamos querer seguir. Si bien los principios están prácticamente encerrados en piedra, estas son cosas que cada vez que miras hacia arriba, combinan principios. Vas a conseguir este set por aquí, y así vamos a repasar estos primero. Por lo que el número uno es empezar con. ¿ Qué sabes? Esto es importante porque el sistema Kon Bon podría implementarse sobre su sistema actual . Es una forma de rastrear el progreso y mejorar el flujo de ese progreso para que técnicamente puedas ponerlo en cualquier cosa y seguir mejorando el flujo. Podrías incluso adjuntar esto a como un método de cascada de la manera correcta y ver qué te está reteniendo durante ese método con Khan Bun la primera de nuevo, Vamos a empezar con ¿qué sabes? No queremos tirar todo y empezar completamente desde cero. Lo que queremos hacer es que queremos poner esto, implementar un pequeño cambio. A lo mejor nuestros cambios fueron implementando una junta como esta para que en realidad podamos empezar a rastrear el progreso y luego nos movemos de ahí. A partir de ahí, acordamos perseguir un cambio evolutivo incremental. Lo que esto significa es que no estamos tratando de cambiar todo a la vez. No vamos a mirar esto e ir lo que las pruebas es obviamente donde está el cuello de botella. Contratemos a cinco ingenieros de pruebas más. Ese es un cambio importante. Y podría causar otros problemas en el camino. Um, o tal vez un mejor tipo de cambio que podríamos hacer es podríamos decir, Hey, Hey, quien sea que esté trabajando en desarrollo, tal vez podamos tener a uno de esos tipos cada dos o tres semanas, pasar un par de semanas y probar y saltar de ida y vuelta. Es un pequeño cambio cada vez que los ingenieros solo van a mover rollos solo por un poco de ingenio de ida y vuelta durante un par de semanas cada mes. ¿ Y que entonces nos disputamos es eso de ayudar? Es eso doler y hará más cambios en base a eso. Entonces queremos un cambio evolutivo incremental, no saltos gigantes. Queremos respetar el proceso actual, roles, las responsabilidades y los títulos, y esto es importante porque no queremos tirar por completo un sistema sólo porque pensamos que podría estar mal. Queremos volver a hacer esos pequeños cambios por lo que Queremos respetar el proceso actual. Queremos respetar todo lo que está pasando con nuestra configuración actual. Queríamos echarles un vistazo muy serio y solo hacer pequeños cambios. No queremos empezar a despedir a la gente y a mover a la gente por todas partes. Crea este miedo a la inestabilidad dentro del proyecto que nos ralentizará aún más por lo que queremos mirar el problema, ver cómo podemos hacerlo mejor y hacer esos pequeños cambios. Y por último, éste a veces se agrega, a veces no. Pero creo que es importante fomentar actos de liderazgo en todos los niveles. Lo que esto significa es que queremos incentivar a nuestro más bajo de trabajadores la misma cantidad que nuestro más alto de trabajadores, el más bajo de los trabajadores, lo que significa que solo están codificando. No están haciendo mucho del proceso de diseño. Sólo están haciendo cambios. Queremos asegurarnos de que haya ser honestos y estén siendo francamente en la forma que están codificando. Queremos que tomen realmente buenas decisiones. Si bien los recubrimientos alentarían esos actos, y el liderazgo aquí no tiene que significar que en realidad estaban liderando a otras personas, puede significar simplemente que están inspirando a otros porque ahí trabajando muy duro y están creando muy código sólido y muy libre de errores. Entonces, ¿qué? Animo que en todos los niveles y en algunas de las propiedades, algunas de las formas que podemos llegar a estos principios es una. Visualizar la obra completa. Es muy importante con combine. Queremos ponerlo en una pared gigante o en una página web, o donde todos puedan acceder a ella para que podamos ver el flujo de trabajo. ¿ Y cuál es el problema con esto? Obviamente vemos que tenemos el problema en las pruebas y necesitamos trabajar con ello. Limitar el trabajo en curso. Esta es una de las principales claves en esto es que queremos limitar la cantidad de trabajo que seguimos pasando . No queremos que el dedo del pie tenga todo este trabajo en progreso porque en ese momento todo el mundo se ha extendido demasiado delgado y no estamos haciendo mucho progreso. No estamos siendo capaces de ver el flujo porque no hay ningún flujo. Todo el mundo se detuvo y Onley dando pasos muy, muy diminutos hacia el producto final. Seguimos intentando que esto sea un poco ágil. Todavía estamos tratando de acelerar el proceso de desarrollo. Entonces cada vez que vemos algo como esto, queremos detener cualquier inclusión de rezago e intentar trabajar a través de los bugs actuales antes introducir más en el proceso. Gestionar nuevamente el flujo. Queremos mirar el flujo y queremos gestionarlo. Queremos ver dónde están los problemas y cuál es el cambio Esos problemas no se romperían. Políticas de proceso, Reunión explícita. No queremos sólo una especie de explicarle a alguien, ya sabes, así es como se hace. Así es como lo hacemos, algo así. Queremos tener un pedazo de papel con todas nuestras políticas, detalle que podemos dar a las personas que queremos que sean más fáciles de acceder y explícitamente escritas . Ya no queremos ninguna zona gris. Queremos algo que sea muy, muy explícito, muy fácil de encontrar y muy fácil de seguir eso otra vez. Hace para que todos nuestros ingenieros siguieran el proceso y si sabemos que todos están siguiendo perfectamente el proceso, sabemos cómo cambiar el proceso porque de todos los ingenieros no están siguiendo nuestra política , no importa cómo hagamos cambios a la política, todavía no la va a seguir y en realidad no se va a producir ningún cambio, por lo que necesitamos asegurarnos de que la están siguiendo. El único modo de hacerlo es hacerlo muy explícito, asegurándose de que lo puedan leer y de que lo hagan cumplir. Entonces podemos hacer cambios en base a ello y finalmente mejorar la colaboración colaborativa. A lo que nos referimos con esto es que queremos mejorar ya que un grupo mejoraría colaborativamente ayuda mal ahí mismo. Queremos mejorar juntos. No queremos hacer solo pequeños cambios de arriba hacia abajo, lo que significa que el líder mira en absoluto. Dice que estamos haciendo este cambio. Queremos mejorar como grupo. Entonces quieres tener reuniones de grupo, Quieres tener temas planteados, queremos tener, tal vez trayendo también a las partes interesadas. Y queremos tener estas pequeñas reuniones thes colaboraciones sobre cómo vamos a mejorar. Todos deberían estar involucrados para que podamos seguir mejorando el proceso porque tal vez nosotros como digamos, nosotros como gerente de programa, no entendemos los problemas por aquí y probando. Entonces tratamos de implementarlo, ya sabes, cambios en las pruebas por lo que creemos que las pruebas están bien, eso no nos va a ayudar realmente, porque si trajimos a algunos de los ingenieros de pruebas, están nos va a explicar mejor por qué hay un cuello de botella ahí. A lo mejor están diciendo que estamos sentados demasiado por el oleoducto y no estamos teniendo suficiente gente para lidiar con ello. A lo mejor hay procesos está al final del estado de análisis, donde en realidad se está llegando con el diseño. A lo mejor son errores en el desarrollo. Los desarrolladores son solo su lápiz azotando todo, y no están haciendo buen código. Queremos platicar con los ingenieros de pruebas y hablaremos con todos los ingenieros para resolver ese problema. Y así mejorar de manera colaborativa es una parte muy importante. Pero común es una forma realmente, realmente ordenada de desarrollar código. Y es una divertida espera hasta mirar todos los visuales y para seguir mejorando cada día básicamente 13. de de 2 a 5 Lean: Hablemos de la startup lean, que es otro modelo ágil. El lean startup es muy, muy interesante, y es algo que es relativamente nuevo y algo que realmente sólo se puede hacer con la tecnología. El lean startup es este tipo de forma experimental de construir productos. Por experimental, me refiero a eso literalmente. Estás haciendo experimentos para ver si tu producto realmente puede ganar dinero en el mercado. Entonces lo que hacemos es ir a esta idea de aprender, construir medida. Toma esas medidas que aprendimos construir, etcétera, y estamos tratando de crear un producto lo más rápido posible y lo mínimo posible para ver si hay un mercado por ahí. Entonces lo que hacemos es hacer algún tipo de suposición. Hacemos una hipótesis si te gusta el método científico, y estamos tratando de averiguar si esta hipótesis o suposición es cierta. Entonces lo que hacemos es construir un experimento. Construimos un sitio web, construimos un servicio y vemos si la gente está interesada en ello. Entonces usamos ese interés como métrica, y ajustamos en base a esas métricas. muy, Ejemplomuy, muy popular de esto es de la empresa Zappos, Zappos fue fundada básicamente en 1999 cuando Internet apenas comenzaba a tomar algo de vapor. Muchas compras en línea aún no eran muy populares. aquel entonces, sin embargo, el Fundador acudió a un centro comercial local tratando de encontrar unos zapatos, y no pudo encontrar los zapatos que quería. Y eso fue básicamente. Había o compraba zapatos en ese centro comercial o no compraba zapatos. Así fue como estaba de vuelta en el día. Entonces pensó: Hey, Hey, construyamos un sitio web que podamos poner zapatos de todo el lugar para que siempre podamos encontrar el par de zapatos que queremos. Entonces fuimos a la cámara gráfica del centro comercial, tomamos un montón de fotos y posamos ante todos en la página web. Ahora, en lugar de comprar un inventario por adelantado, lo que hizo fue construir el sitio web, por lo que hizo la suposición de que la gente compraría zapatos por internet. Construyó el sitio web y luego apenas midió cuántas personas obtendrían ventas. Y en lugar de comprar el inventario y construir todo el producto, lo que haría es que si alguien básicamente hiciera un pedido miraría el pedido. ¿ Averiguar qué deberían querer? Conduce al balón local junto a ese zapato, póngalo en una caja y luego envíalo a esa persona. Así es este proceso muy manual. No hubo mantenimiento de inventarios. No había nada más que él siendo toda la lógica empresarial él mismo. Se volvió muy, muy, muy popular. Se dio cuenta de que tenía algo realmente grande en sus manos. Se confirmó su métrica que esto iba a hacer mucho dinero, y por eso, por el interés que entonces estaba abierto a las inversiones. Estaba abierto a cambiar su proceso para convertirlo en un sitio web real para ganar dinero. Y terminó siendo uno de los negocios de todas las líneas más exitosos a partir de los primeros dos miles. Por lo que a través de este proceso, este proceso de inicio magra, fue capaz de invertir un riesgo mínimo para ver si una proposición o una idea de negocio era viable. Y por eso es muy popular, porque podemos usar esta startup magra para hacer exactamente eso es averiguar si nuestras ideas pena y van a hacer dinero. Entonces esa es la startup magra. Básicamente no hay nada más con éste. El modo en que lo construyes es Usarías otro como un estilo scrum. O podrías usar algunos básicamente solo codificar y hackear forma de empezar algo y luego solo lo mides. Y después de que descubras que es ah, ve. Entonces tenemos esta idea de ir y no ir significado ¿Continuamos? Adore, detente! Si es hace, desarrollamos el software. Estamos usando uno de los otros métodos. Si es un no go ¿Qué? Acabamos de detener el producto ahí y esperemos llegar a ideas más adelante. Pero lean startup realmente interesante para aprender.