The latest articles on Forem by Omar Carpinteyro (@omarcarpinteyro). https://forem.com/omarcarpinteyro https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F223921%2Fbbf9549c-764b-47ef-86ee-9abcd6ca5504.jpg https://forem.com/omarcarpinteyro en Omar Carpinteyro Tue, 17 Sep 2019 22:05:41 +0000 https://forem.com/omarcarpinteyro/borrado-de-cache-en-desarrollo-web-5g2a https://forem.com/omarcarpinteyro/borrado-de-cache-en-desarrollo-web-5g2a <h2> Opciones de borrado de caché en los diferentes servidores y servicios de Internet, desde el origen hasta el cliente o navegador del usuario final. </h2> <p>En el <a href="https://dev.to/omarcarpinteyro/cache-para-dummies-inception-229b">artículo anterior</a> de esta serie, aprendimos los principales cachés que podemos citar como básicos en internet.</p> <p>Ahora, daremos respuesta a una de las preguntas más relevantes y su respuesta es aun más importante: <strong>¿Cómo se ejecuta el borrado de caché?</strong></p> <p>Primero entendamos el origen de esta pregunta, para ello, debemos saber que el tiempo de vida de caché, no es constante, tenemos el poder de colocar el valor de tiempo que queremos mantener en memoria cierta información, el tiempo de caché.</p> <blockquote> <p><em>El tiempo en que la información se guarda en caché lo tenemos que configurar.</em></p> </blockquote> <p>Podrían existir valores configurados por default, pero al final, es un valor que se configura sí o sí.</p> <blockquote> <p><em>Una vez configurado el tiempo en caché que vivirá una información en memoria, en disco duro, no podrá ser borrada hasta que se cumplan ciertas condiciones.</em></p> </blockquote> <h2> ¿Cómo es el borrado del caché? </h2> <p>Veamos de manera simple y básica las opciones que tenemos para borrar el caché:</p> <p><strong>Forzado.</strong> Para borrar el caché de CDN o Egde, existe el Purge, que es un término que se usa para hacer referencia al borrado de caché de uno o varios elementos. Básicamente consiste en indicar las URLs o Paths que quieres que el CDN borre de su caché, de su disco duro. Una vez ejecutado el Purge el CDN irá a sus diferentes zonas y borrará los archivos indicados. Algunos CDNs incorporan el Fast Purge, que asegura el borrado de caché a nivel mundial en tiempos record.</p> <p>Desde el Cliente (el Browser), la única manera de borrar el caché es hacerlo desde las mismas configuraciones del navegador. Por ejemplo, para conocer cómo se borra el caché de Google Chrome, podemos ir aquí. Para usuario más creativos y avanzados podrían ir directamente al disco duro de su computadora y borrar los archivos temporales o de caché.</p> <p><strong>Por tiempo o automático.</strong> Tanto para Caché de Cliente o CDN, podemos programar el borrado por tiempo. Por ejemplo, si configuramos el caché a 3600 segundos para que viva nuestra información en memoria, comenzará una cuenta regresiva en el navegador o en el CDN y una vez que este conteo llegue a cero, la información se borrará de caché automáticamente.</p> <p>Otra manera de usar el tiempo automático a nuestro favor, es configurar una fecha futura para borrado de caché. La fecha es configurada en formato Fecha y Hora exacta en la que queremos que la información sea borrada. Cuando se valide la fecha y hora indicada y dicha fecha es cumplida, el caché es borrado.</p> <h2> Hacks </h2> <p>Te dejo un truco para borrar el caché del cliente, y para ello nos ayuda de manera oportuna el Algoritmo de Eviction, el cual vive por default en los navegadores. Y nos ayuda a validar si un recurso en caché sigue siendo “llamado” o “referido” desde el mismo origen en que nació. Por ejemplo, si guardamos la imagen <em>hola.jpg</em> en caché por medio de la página <em><a href="http://www.hola.com">www.hola.com</a></em>, si en la siguiente visita que hagamos a la misma página ya no existe el llamado a la imagen <em>hola.jpg</em>, el navegador la borrará de su caché automáticamente.</p> <p><strong>Precaución:</strong> si no se configura un caché correctamente en nuestra arquitectura, podríamos dejar a nuestros usuarios cachados por largos tiempos y no verán nunca nuestros cambios futuros.</p> <h6> <em>Foto por <a href="https://unsplash.com/@markusspiske">Markus Spiske</a> de <a href="https://unsplash.com/search/photos/hard-disc">Unsplash</a></em> </h6> cache webdev architecture distributedsystems Omar Carpinteyro Tue, 10 Sep 2019 17:27:55 +0000 https://forem.com/omarcarpinteyro/cache-para-dummies-inception-229b https://forem.com/omarcarpinteyro/cache-para-dummies-inception-229b <p>El tema del cache es un fuerte dolor de cabeza. Es un bosque tenebroso en donde si no vas preparado, te perderás y el costo puede ser fatal para tu negocio y tus usuarios. Es por eso que haremos un <strong>Cache Inception</strong>.</p> <p>Aprenderemos desde cero las definiciones básicas. De una manera fácil y rápida. Explicaré el cache con una analogía a la cual queremos que hagas referencia para que no olvides los conceptos.</p> <h2> Analogía </h2> <p>Imaginemos un <strong>restaurante</strong>, en donde tenemos una <strong>cocina</strong> y en ella hay un <strong>cocinero</strong>. El restaurante comienza a dar servicio. Comenzarán a entrar los <strong>clientes</strong>.</p> <p>El cliente entrará al restaurante e irá a la cocina para preguntar directamente al cocinero: <em>¿Cuál es el menú? ¿Qué ingredientes tienen los platillos? ¿Cuánto cuestan? ¿Qué hay de beber?</em> Etc. Una vez que el cliente tiene toda la información, hará su pedido a nuestro cocinero, el cual trabajará en el platillo solicitado y una vez listo, lo servirá.</p> <p>El cliente termina su platillo y ahora quiere un postre. Entonces irá de nuevo a la cocina a buscar al cocinero, hará las preguntas pertinentes para pedir su postre: <em>¿Qué postres tiene? ¿Qué sabores hay? ¿Cuánto cuestan?</em> Etc. Una vez que el cliente tiene toda la información, pedirá su postre al cocinero, el cual de nuevo trabajará en el postre solicitado y una vez listo, lo entregará.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--Fo-gGs7C--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/dz3unugtqvxern73dgcr.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--Fo-gGs7C--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/dz3unugtqvxern73dgcr.gif" alt="Primer escenario del Restaurante"></a></p> Primer escenario del Restaurante <p>Este escenario funciona bien, ambas partes obtienen lo que quieren y el proceso fluye de manera natural.</p> <p>¿Pero qué pasa cuando hay más de un cliente? De pronto tenemos cinco clientes. Cada uno de ellos hablando con el cocinero y haciendo las mismas preguntas: <em>¿Cuál es el menú? ¿Qué ingredientes tienen los platillos? ¿Cuánto cuestan? ¿Qué hay de beber? ¿Qué postres hay?</em> Etc.</p> <p>En este punto, el escenario ya no es rentable, pues el cocinero no se dará abasto, los platillos saldrán mal, estarán fríos, tardarán mucho y los clientes se disgustarán.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--Ol9Cw1w7--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/rcm2f3b71dgef2x0ur1z.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--Ol9Cw1w7--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/rcm2f3b71dgef2x0ur1z.gif" alt="Escenario complicado, no rentable."></a></p> Escenario complicado, no rentable. <p>Para solucionar este escenario incorporamos un servicio de <strong>meseros</strong>. Ahora, los clientes preguntarán al mesero todo aquello que necesitan saber para ordenar un platillo. En este nuevo proceso, el mesero recibe la orden y la ingresa a la cocina, en donde el cocinero toma la orden y se dedica tener el platillo listo para servir.</p> <p>En cuanto vayan estando listas las órdenes, el mesero la recogerá y las llevará con el cliente.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--Jpjqv8hq--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/teekoiccwlthqcc1mg3n.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--Jpjqv8hq--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/teekoiccwlthqcc1mg3n.gif" alt="Incorporación de Mesero"></a></p> Incorporación de Mesero <blockquote> <p><em>Queremos que notes que con este nuevo proceso, el cliente no se enterará del número de cocineros que tenemos, y nosotros podemos agregar tantos meseros como necesitemos para cubrir la demanda, al igual que el número de cocineros.</em></p> </blockquote> <h2> Arquitectura Web </h2> <p>Ahora pasemos a darle un poco de sentido a nuestra analogía, llevando a la parte técnica con una <strong>arquitectura web</strong>.</p> <p>La cocina, será nuestro <strong>Servidor Web</strong>, el cocinero es representado por los <strong>procesos y capacidades de computo</strong> de nuestra instancia, y los clientes, serán nuestros <strong>usuarios finales</strong>, que comenzarán a hacer peticiones (<em>requests</em>) a nuestro servidor.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--UIXLyyIu--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/nnyocs0cmiio8fcn4zoh.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--UIXLyyIu--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/nnyocs0cmiio8fcn4zoh.gif" alt="Arquitectura Web"></a></p> Arquitectura Web <p>El flujo funciona al igual que nuestro restaurante, el usuario hace solicitudes a nuestro servidor, nuestro servidor procesa la solicitud de <em>páginas web, assets,</em> etc. y devuelve la información al cliente: el browser.</p> <p>De igual forma, cuando las peticiones de nuestros usuarios son demasiados, incorporamos un servicio de CDN (<em>Content Delivery Network</em>) que es representado por nuestro mesero. El CDN se encargará de recibir las peticiones y dirigirlos a nuestros servidores, que son el origen de los datos entregados.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--YGf_2TtB--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/3xgnnvhyj3vftk7il9ud.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--YGf_2TtB--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/3xgnnvhyj3vftk7il9ud.gif" alt="Origen, CDN, Cliente (Browser)"></a></p> Origen, CDN, Cliente (Browser) <p>Podemos tener tantos servidores balanceados como sean necesarios para soportar la carga.</p> <h2> Incorporación de Cache </h2> <p>Integramos nuestro concepto de cache. Haremos nuestro <strong>Cache Inception</strong> y entenderemos por cache como <strong>una memoria que guarda la información que nos entregó un origen como respuesta a una solicitud que hicimos</strong>.</p> <p>En nuestro restaurante, vamos a incorporar dos tipos de memoria, que nos ayudarán a recordar la información que nos da el origen, en este caso, el cocinero. A esta le llamaremos <strong>menú</strong>. El menú nos servirá para tener la información de lo que produce el cocinero, recetas, precios, ingredientes, etc.</p> <p>Le daremos el menú al mesero y él ya no tendrá que ir con el cocinero, si no tendrá que consultar el menú. Cuando los clientes pregunten sobre los platillos, el mesero podrá responder rápidamente.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--tin53ijr--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/nwalgrzg47vj704zobsc.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--tin53ijr--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/nwalgrzg47vj704zobsc.gif" alt="Incorporación de un menú"></a></p> Incorporación de un menú <p>En nuestra arquitectura web, a lo anterior se le denomina <strong>Cache Edge</strong> o <strong>Cache de CDN</strong>, que es la encargada de memorizar la información que otorga nuestros servidores.</p> <p>Entonces, si el servidor nos entrega un HTML o un asset tipo JPG o CSS, el CDN se encargará de guardarlo en su cache y cuando un cliente pida dicho recurso, el CDN lo servirá sin tener que ir a solicitarlo de nuevo al servidor.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s---MnHcdbV--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/sypunfvmn8gwbiyy7s82.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s---MnHcdbV--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/sypunfvmn8gwbiyy7s82.gif" alt="Incorporación del Cache Edge o Cache de CDN"></a></p> Incorporación del Cache Edge o Cache de CDN <p>Vamos a llevarlo a otro nivel, ya que los clientes aún tienen que ir al mesero a pedir la información siempre que requieran algún platillo o servicio.</p> <p>Para mejorar este proceso, vamos a incluir un nuevo menú que será entregado al cliente cada que llegué al restaurante. En este menú, el cliente podrá ver la información indispensable para que pueda ordenar sus alimentos. Podrá ver los ingredientes, precios, etc. Esto representa una mejora importante para que nuestros meseros puedan relajarse un poco.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--SPeW294M--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/f0x0icdgrd7e8qyn9kil.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--SPeW294M--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/f0x0icdgrd7e8qyn9kil.gif" alt="Incorporación del menú para el cliente"></a></p> Incorporación del menú para el cliente <p>En nuestra arquitectura web a esto le llamamos <strong>Cache del Cliente</strong>, es decir, la memoria que usará el navegador (<em>browser</em>) para recordar los resultados que le entregó el origen y guardarlos en disco para tenerlos disponibles cada vez que se requieran.</p> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--pMIRSCg8--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/dolifnd98nr8y53qiorf.gif" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--pMIRSCg8--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/dolifnd98nr8y53qiorf.gif" alt="Incorporación de Cache de Cliente o de Browser"></a></p> Incorporación de Cache de Cliente o de Browser <p>Por lo tanto, si nuestro CDN ya entregó un recurso, el browser lo guarda en cache y cuando el navegador pida el mismo recurso, no tendrá que ir al CDN, sino a su cache, a tu disco duro.</p> <p>Así pues, existen los dos caches: de <strong>CDN</strong> y de <strong>Cliente</strong>.</p> <h2> Conclusión </h2> <p>Ahora podrás hacer preguntas válidas como las siguientes:<br> <em>¿Qué sucede si cambian los precios? ¿Cómo actualizo los platillos en los menús? ¿Cómo le hago para abrir otro restaurante? ¿Qué pasa cuando no va un mesero a trabajar? ¿Y si el cocinero no está disponible?</em></p> <p>Las pasadas preguntas podrían ser equivalentes a:</p> <p><em>¿Cómo actualizo un CSS o JS que esta cache en del Cliente (Browser)? ¿Cómo le digo al usuario que existe una página nueva? ¿Cómo le hago para estar disponible en el cache de Europa u otro continente? ¿Qué pasa si el CDN o mi servidor origen no responde?</em></p> <p>Daremos respuesta a estas preguntas en otros artículos.</p> <p>Confiamos que este <strong>Cache Inception</strong> lo tengas presente cada que te enfrentes con este tema.</p> <h6> Foto por <a href="https://unsplash.com/@freeche">Kvistholt</a> de <a href="https://unsplash.com/photos/oZPwn40zCK4">Unsplash</a> </h6> cache architecture webdev distributedsystems Omar Carpinteyro Fri, 06 Sep 2019 03:41:23 +0000 https://forem.com/omarcarpinteyro/los-keywords-del-spanglish-en-los-corporativos-14je https://forem.com/omarcarpinteyro/los-keywords-del-spanglish-en-los-corporativos-14je <h4> Keywords básicas para entender el spanglish de las conversaciones diarias que se dan durante nuestras reuniones de trabajo. </h4> <p>En los ambientes de trabajo dentro de los corporativos, nos encontramos con personas de nacionalidades y culturas distintas a las nuestras. Sin duda es algo bueno para la empresa y para los colaboradores, pues ofrece la oportunidad de crecer tanto personal como profesionalmente, ya que extiende tus habilidades.</p> <p>Durante las reuniones que se tienen con los equipos de trabajo, se dan conversaciones multinacionales y por ende, multilenguaje. Una combinación sería Español — Inglés, conocida coloquialmente como Espanglish o Spanglish.</p> <p>Para hacernos la vida más fácil, listo algunas palabras clave (keywords del spanglish) que son básicas manejar durante nuestras reuniones:</p> <ol> <li> <strong>On-site.</strong> Usada para especificar que “algo” será presencial, se hará en la oficina. Ej. La capacitación será on-site.</li> <li> <strong>Delivery.</strong> Se usa para especificar las “entregas” que se harán. Ej. ¿Cuándo es el delivery del sitio web?</li> <li> <strong>Happy Path.</strong> Se utiliza para hacer referencia a los casos de uso de un sistema. Indica cómo se debería de usar correctamente. Ej. Con el Happy Path funciona, pero debemos considerar otros escenarios.</li> <li> <strong>Rocket Science.</strong> Se usa para insinuar que no estás construyendo o desarrollando algo infinitamente complejo. Ej. El desarrollo estuvo listo antes de lo previsto, no tiene nada de Rocket Science lo que se hizo.</li> <li> <strong>Low-Profile.</strong> Esta se usa para decir que literalmente “algo” o “alguien” se mantiene en un perfil bajo. Ej. John está low-profile para no llamar la atención.</li> <li> <strong>Always On.</strong> Usada para asegurar que un sistema esta funcionando todo el tiempo. Ej. El servidor web esta configurado para estar always on.</li> <li> <strong>Fun Fact.</strong> Esta se usa para indicar alguna otra funcionalidad curiosa y de mucho valor sobre un “algo”. Ej. Un Fun Fact de Netflix, es que puedes elegir imágenes para tu perfil.</li> <li> <strong>Highlights.</strong> Es usada para indicar los puntos más sobresalientes e importantes de un “algo” en especial. Ej. ¿Cuáles son los highlights de la reunión?.</li> <li> <strong>In the meantime.</strong> Utilizada para decir qué ocurrirá mientras “algo” se desarrolla o se concluye. Ej. In the meantime vamos a tomar una certificación en Amazon.</li> <li> <strong>End-to-end.</strong> Se usa para declarar todas las implicaciones y etapas de desarrollo de un sistema, producto o servicio. Ej. Microsoft otorgará una solución End-to-end para nuestro problema con los clientes.</li> </ol> <p>¿Y tú qué keywords del spanglish usas y qué otras agregarías?</p> <h6> <em>Foto de cover por <a href="https://unsplash.com/@wildlittlethingsphoto">Helena Lopes</a> de <a href="https://unsplash.com/photos/1m2LQEonm2A">Unsplash</a></em> </h6> management spanglish social friendship Omar Carpinteyro Wed, 04 Sep 2019 20:05:38 +0000 https://forem.com/omarcarpinteyro/guia-para-estimar-el-tiempo-y-esfuerzo-del-software-396a https://forem.com/omarcarpinteyro/guia-para-estimar-el-tiempo-y-esfuerzo-del-software-396a <p>En el desarrollo de software siempre habrá que estimar el tiempo en que nuestro equipo o un colaborador tarda en entregar un requerimiento. Este dato tiene sentido porque básicamente ayuda al negocio a hacer presupuestos y a evaluar ganancias. Es decir, a mayor tiempo de desarrollo, mayor gasto o inversión para pagar al desarrollador o equipo que desempeña la tarea. Recordemos que cada hora de programación, cuesta.</p> <p>Otro punto a favor de estimar el tiempo de desarrollo, es para ayudar al negocio a saber cuándo se harán entregas que aporten valor al producto, y así poder plantear un pipeline congruente al beneficio del negocio mismo.</p> <p>Por lo tanto, cada que te pidan una estimación de tarea, nos vemos obligados a mencionar el dato.</p> <h2> El problema </h2> <p>Sin embargo, aunque ya vimos que hace sentido estimar, es una realidad que cuesta trabajo calcular este valor. ¿Un día? ¿Una hora? ¿Un sprint? “Mañana queda”, “déjame ver”, “lo voy a evaluar” son frases que usan frecuentemente ante el cuestionamiento de tiempos de entrega.</p> <h2> Causa del problema </h2> <p>Hay demasiadas variables que hacen que sea difícil estimar el tiempo de desarrollo, además de que cada proceso laboral es distinto entre sí. Algunas de las causas más comunes son:</p> <ul> <li> <strong>Falta de definición del requerimiento.</strong> El requerimiento esta incompleto o hay ambigüedades. No existen todos los casos de uso o criterios de aceptación.</li> <li> <strong>Dependencias de equipos terceros.</strong> Es común que para que un requerimiento se cumpla, participen diferentes equipos, y estos trabajos en serie vuelven la estimación más complicada.</li> <li> <strong>Desconocimiento de la solución.</strong> Algunas veces, el requerimiento es tal que no se tiene certeza completa de cómo dar una solución, lo que hace complicada la estimación por que implica análisis y en algunos casos capacitaciones (comúnmente autodidacta) para poder entender e integrar la solución.</li> </ul> <h2> Solución </h2> <p>Por lo tanto, para evitar que la estimación sea de dedazo, presentamos una gráfica para dar visibilidad al equipo, a todos, en dónde se encuentra el requerimiento y no dejar que su solución sea un acto de fe. A continuación la gráfica:</p> <p><a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Frtonevtns96kmx05mcee.png" class="article-body-image-wrapper"><img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Frtonevtns96kmx05mcee.png" alt="Gráfica de Nivel de Esfuerzo y Tiempo en Software"></a></p> Gráfica de Nivel de Esfuerzo y Tiempo en Software <h2> Gráfica: Nivel de Esfuerzo y Tiempo en Software </h2> <p>La gráfica es una herramienta para tener una visión rápida de la estimación de tiempo y esfuerzo de un desarrollo. Éstos básicamente pueden ser:</p> <ul> <li>Nuevo requerimiento</li> <li>Mantenimiento de software</li> </ul> <p>El <strong>Eje Y</strong> (lado izquierdo) nos indica <strong>qué tan cercano o alejado está el nuevo requerimiento o mantenimiento de su funcionalidad inicial</strong>. Mientras más cercano este al <strong>Eje X</strong> (hacia abajo) será más cercano a lo que inicialmente se desarrolló.</p> <p>El <strong>Eje X</strong> (parte de abajo) nos indica <strong>qué tanto conocemos de la solución, tanto en la tecnología que usamos, como el conocimiento requerido para dar soluciones</strong>. Mientras más cercano este al <strong>Eje Y</strong> (hacia la izquierda) nos dará más certeza de la solución que debemos emplear.</p> <h2> Ejemplos </h2> <p>Pensemos en un auto. Tenemos un vehículo color rojo, que usa gasolina, que tiene sus cuatro llantas, motor, puertas, etc. Un auto común y corriente. Ahora pensemos en un requerimiento en forma de Historia de Usuario:</p> <blockquote> <p><strong><em>Como usuario quiero que el auto sea de color negro para que cumpla con mi colección de autos oscuros.</em></strong></p> </blockquote> <p>En este caso podemos suponer que cambiar el color del auto no cuesta tanto trabajo y además sabemos hacerlo. Por lo tanto el nivel de estimación de tiempo y esfuerzo podría estar ubicado así:</p> <p><a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Fm8n8qfe7l9iy6w1gpjpm.png" class="article-body-image-wrapper"><img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Fm8n8qfe7l9iy6w1gpjpm.png" alt="La estrella representa el nivel de esfuerzo y tiempo&lt;br&gt; "></a></p> La estrella representa el nivel de esfuerzo y tiempo <p>Vamos con otro ejemplo, citado de igual manera en Historia de Usuario:</p> <blockquote> <p><strong><em>Como usuario quiero que el auto sea convertible para poder disfrutar del aire y la vista cuando vaya manejando.</em></strong></p> </blockquote> <p>¡Wow! ¿Cambiar el auto para que sea convertible? Esto suena algo muy distinto al requerimiento inicial ¿no es así? Pero supongamos que vamos a asignar a nuestro mejor personal para hacer el cambio. Entonces nuestra requerimiento quedaría ubicado de la siguiente manera:</p> <p><a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Flaxfz4qhyhz7hbw0lhvn.png" class="article-body-image-wrapper"><img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Flaxfz4qhyhz7hbw0lhvn.png" alt="La estrella representa el nivel de esfuerzo y tiempo&lt;br&gt; "></a></p> La estrella representa el nivel de esfuerzo y tiempo <p>¿Por qué esta ubicada de esa manera? Podemos argumentar que aunque asignamos a nuestro mejor personal y sabe cómo hacer el cambio, este requerimiento esta muy alejado del funcionamiento actual, eso hace que el tiempo de desarrollo sea más tardado. ¿Imaginan cómo quedaría la estimación de tiempo y esfuerzo si nos ayudara un equipo sin experiencia en hacer un auto convertible?</p> <p>Veamos un ejemplo más que complementa la idea:</p> <blockquote> <p><strong><em>Como usuario quiero que el auto sea híbrido para poderlo usar sin gasolina.</em></strong></p> </blockquote> <p>Aquí tenemos todo un reto. Cambiar el auto de uso de gasolina a híbrido. </p> <p>Definitivamente algo nuevo. Podemos decir rápidamente que no esta cerca de la especificación inicial y además no tenemos personal que conozca cómo hacer este ajuste, por lo tanto, nuestra gráfica luciría así:</p> <p><a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2F50eveiamgp2fkgi1wgh9.png" class="article-body-image-wrapper"><img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2F50eveiamgp2fkgi1wgh9.png" alt="La estrella representa el nivel de esfuerzo y tiempo&lt;br&gt; "></a></p> La estrella representa el nivel de esfuerzo y tiempo <p>Ahora todos estamos de acuerdo en que el requerimiento llevará mucho tiempo de desarrollo, y queda claro en dónde ubicamos el esfuerzo.</p> <h2> Conclusión </h2> <p>Contar con una herramienta que nos apoye a comunicar el por qué de nuestras estimaciones y nos ayude a dar visibilidad a los equipos, es imprescindible en nuestra credibilidad como desarrolladores.</p> <p>¿Y tú qué herramienta usas para estimar tus tiempos y esfuerzo de desarrollo?</p> <h6> (<em>Foto de Cover por <a href="https://unsplash.com/@neonbrand" rel="noopener noreferrer">NeONBRAND</a> de <a href="https://unsplash.com/search/photos/project-planning" rel="noopener noreferrer">Unsplash</a></em>) </h6> productivity management agile