Software Industry Coach

Existen dos frases, que he escuchado decir a muchos Líderes de equipo y Gerentes, quizás las has escuchado también: - "Quiero un equipo con la camiseta bien puesta" - "Todos los miembros del equipo deben ser más comprometidos" Son una arenga, que busca motivar al equipo para que obtenga resultados extraordinarios o sea capaz de solucionar problemas activa y rápidamente. A veces, cuando existe la urgencia de liberar una función o un fix, la escucho en esta forma: "comprométete más con la empresa". Sin embargo, solemos ver un efecto opuesto al que buscan estas frases: un equipo desmoralizado y resultados alejados de las expectativas de los líderes. Los miembros del equipo están comprometidos; dice Watts Humphrey: "todos los participantes quieren hacer un gran trabajo y dar lo mejor de sí, siempre", y es verdad; no conozco un solo desarrollador de software que se levante en las mañanas pensando "hoy haré el peor trabajo que pueda"; es solo que, en su estado actual, tiene poco margen para participar.

A lo largo de mi carrera profesional he escuchado lo siguiente en diferentes ámbitos: “Es normal que el software tenga defectos” o su variante “El software siempre tendrá defectos” No es normal. Ustedes no andarían por un puente vehicular, del que saben que tiene defectos. No aceptarían un coche defectuoso o aceptarían una casa con múltiples defectos. Sin embargo, como decía mi profesor Carlos Montes de Oca “el software es tan necesario que le perdonamos que sea malo”. Se vuelve el cuento de nunca acabar. En general, las organizaciones con este problema dedican entre 65% y 85% del tiempo solo a esta actividad en lugar de producir funciones nuevas, o dedican equipos completos solamente a esto. Algunas organizaciones, con algo de cinismo, la incluyen en los contratos como “fase de estabilización”, que solo es trasladarle el costo al cliente por la mala calidad del desarrollo. A continuación te presento razones por las que se presenta este comportamiento en organizaciones de software. No hay cultura de la calid

En las cinco red flags de las organizaciones de software, que les detiene para lograr resultados de élite, tenemos el tiempo de desarrollo muy largo; esto es, la incapacidad del equipo para entregar software funcionando en intervalos cortos, regulares y frecuentes. Algunas empresas se distinguen por su innovación, la cual notamos porque brindan funciones nuevas en sus productos constantemente. Hablamos de compañías como Amazon, Netflix o Facebook (ahora, Meta), quienes crearon una forma de trabajo capaz de hacer varios deploys al día, completamente funcionales. Amazon lo hace a una tasa de 30,000 al día; Netflix, 500 y Facebook 2 veces diariamente. ¿La tuya es capaz de hacer esto? Tal vez te encuentras en la circunstancia normal de muchas organizaciones: solo hacen una o dos entregas (deploys funcionales) AL AÑO. ¿Cuáles son las razones de esto? Te presento las más importantes. Pasan muchos días entre el fin de un ciclo (sprint) y el inicio del siguiente Los frameworks de la filosofía ágil, basados en cic

Una organización de software es una persona o grupo, que tiene como fin crear y entregar soluciones basadas en software, las cuales deleitan a sus usuarios y dan valor financiero a los patrocinadores de su desarrollo. Estas organizaciones pueden ser vendedoras del servicio de software a clientes finales o estar dentro de otra empresa, creando el software que se usa en las operaciones diarias. Mientras más rápido consigan la entrega, más rápido se obtienen también los beneficios e inician más oportunidades de desarrollo. Es lo que, hoy en día, se llama Agilidad y es un resultado que todas las organizaciones deben procurar. Sin embargo, muchas de ellas descuidan factores importantes, que les impiden obtener los mejores resultados. Estas carencias se observan en sus prácticas de Ingeniería de Software. A continuación te presento cinco red flags en los grupos de desarrollo de software y las razones por las que detienen al equipo para lograr los resultados de elite: El tiempo de desarrollo es muy largo La ma

Muchas veces ocurre que no comprendimos bien los requerimientos de un sistema y ponemos el producto incorrecto en las manos del cliente. Esto, si ya ha pasado mucho tiempo y se haLeer

Hablemos de la Especificación de Requerimientos Es imposible que el equipo de desarrollo memorice toda la información del producto. A lo largo del proyecto, los miembros del equipo tendrán preguntas, habrá suposicionesLeer

La información que obtienes durante el levantamiento de requerimientos es un conjunto de datos muy grande, que en su estado natural es poco útil. Debemos analizarla para entender cuatro cosas respecto aLeer

Los ingenieros de software solemos cometer el error de esperar que los usuarios nos den sus requerimientos; ellos nunca lo podrán hacer, porque no están entrenados en desarrollo de software, pero insistimos en hacer preguntas como “¿Qué es lo que quieres?”, “¿Usamos tal herramienta o tal otra?”, “¿Será en plataforma móvil, web o de escritorio?”, […]

Hay tres cosas que debes entender para tener buenas prácticas en tus requerimientos: Qué son los Stakeholders Los niveles de requerimientos Los tipos de requerimientos Comprender bien esto, te permitirá responder fácilmente a la pregunta: ¿Cuáles son las siguientes user stories a desarrollar?  Identifica a tus Stakeholders Un sistema de software impacta a diferentes personas […]

¡Hola! Bienvenido a la serie "Cómo deleitar a tus usuarios". En ésta hablaremos de Ingeniería de Requerimientos, un conjunto de actividades muy importantes, que nos permiten construir soluciones que deleitan a nuestros usuarios.  Esta es una serie de siete artículos. En éste primero te hablaré de qué son y en qué consisten las actividades de requerimientos, de su importancia y el propósito que tiene hacerlo. En siguientes artículos, conocerás: Lost Tipos y niveles de requerimientosCómo obtener y recolectar requerimientosCómo analizar y comprender los requerimientosCómo especificar requerimientosCómo validar los requerimientosCómo funciona el proceso de requerimientos en diferentes tipos de proyectos ¿Qué son los requerimientos? Es una definición de lo que un sistema de software debe hacer, y una especificación de las restricciones en su operación e implementación. Los requerimientos son la guía para comprender las necesidades de los usuarios con respecto al software y especifican las funci

En esta ocasión te presento las razones por qué hablo de lo que hablo en este canal. Visita mi web: https://www.edgarfernandez.com https://www.aprend-is.net Aprende a estimar proyectos de software: http://bit.ly/estimacionpromo Videos mencionados: Mi experiencia con Rambo: https://www.youtube.com/watch?v=qllc56_uR6c ¿Qué hace un Ing. de Software?: https://www.youtube.com/watch?v=uRiXseiYOUQ ¿Cómo quebré mi empresa? https://www.youtube.com/watch?v=LjZYZbVKJMQ Música De fondo: "Hard Boiled", por Kevin MacLeod (https://incompetech.com) Intro: Virus, por Dzynek

Watts S. Humphrey es el padre de la calidad del software. Él tenía un compromiso inquebrantable con la disciplina y la calidad. Emprendió una misión, con la que inspiró a muchos; entre ellos, a mí. Quiero hablarles de las razones por las que es mi role model profesional. Mi curso en Udemy: http://bit.ly/estimacion Contacto Web: https://www.edgarfernandez.com Facebook: https://www.facebook.com/SoftwareEngineeringCoach/ Twitter: https://twitter.com/edfrz1 LinkedIn: https://www.linkedin.com/in/edgarfernandezr/

Todo trabajo que se haga en un período de tiempo y que tenga un objetivo debe ser monitoreado regularmente, para asegurar que se camina en rumbo a ese objetivo y tomar decisiones para corregir desviaciones. Entender el estatus de tu proyecto requiere que reunas información que te permita contestar estas seis preguntas. Mi curso en Udemy: https://www.udemy.com/estimacion-de-proyectos-de-software-d… Envíame un mensaje, y si eres de los primeros, gánate un cupón de descuento. Contáctame: Web: https://www.edgarfernandez.com Twitter: https://twitter.com/edfrz1 Facebook: https://www.facebook.com/SoftwareEngineeringCoach/

Varias personas me han pedido que les diga cómo crear una startup o empresa exitosa. He sido emprendedor, y mi empresa más grande quebró. Quiero compartirte esa experiencia y los errores que nos condujeron al fracaso, esperando que puedas aprender de ellos, y lo que te recomendaría hicieras en lugar de lo que nosotros hicimos esa vez. Recuerda suscribirte al canal para recibir las notificaciones cuando publicamos nuevos videos y compartirlo con quien creas necesite ver este video. Visita mis redes: Web: www.edgarfernandez.com FB: https://www.facebook.com/SoftwareEngineeringCoach/ Twitter: https://twitter.com/edfrz1 LinkedIn: https://www.linkedin.com/in/edgarfernandezr/ Créditos de imágenes y recursos: Photo by Tyler Nix on Unsplash (Cochera) Photo by Hack Capital on Unsplash Photo by Stefan Steinbauer on Unsplash Photo by rawpixel on Unsplash Photo by Tim Gouw on Unsplash Photo by Ambreen Hasan on Unsplash "Designed by kues1 / Freepik"

Quienes hemos tenido la oportunidad de liderar equipos de trabajo nos hemos encontrado, en ocasiones, a un personaje conflictivo. Hay varios tipos de ellos: el Rockstar, la Diva, el Inconforme, pero en este video trato de uno muy peculiar. Yo le llamo "Rambo". Sugerencias de Libros: Willet, Alan. Leading the Unleadable: How to Manage Mavericks, Cynics, Divas, and Other Difficult People. Amacom, 2016 Patterson, Kerry. Crucial Conversations Tools for Talking When Stakes Are High. McGraw-Hill Education; Edición: 2nd ed. (9 de septiembre de 2011) Visita mi sitio web para conocer mi experiencia: https://www.edgarfernandez.com Sígueme en Facebook: https://facebook.com/SoftwareEngineeringCoach

Modelar el sistema pemite una mejor visualización de la situación que se quiere resolver y encontrar la solución más adecuada. Además de que nos evita problemas comunes en el desarrollo de software.

En este video te digo qué es System Testing, los tipos de pruebas de sistema y qué buscar en cada una. Libros de consulta: Lewis, William E. “Software Testing and Continuous Quality Improvement”. Third Edition. Taylor & Francis Groupi, 2009 The art of software testing / Glenford J. Myers, Corey Sandler, Tom Badgett. — 3rd ed. Herramientas WAPT: https://www.loadtestingtool.com/ Metasploit: https://www.metasploit.com/get-started

La forma en que se desarrolla software en la segunda década del siglo XXI es diferente a como se hacía cuando nació la industria de software. Esto debido a que la base de usuarios creció y las características de ellos son muy distintas a los usuarios iniciales; por tanto, sus demandas y necesidades requieren una atención adecuada a este entorno de entendimiento cambiante. Es por esto que han surgido prácticas y propuestas para organizar equipos e individuos que hacen software, que están enfocadas en manejar esos cambios: ciclos de desarrollo más cortos, adaptación al cambio, comunicación e interacción constantes y una desaparición, por así decirlo, de un gestor que toma las decisiones importantes. Se dice que el enfoque "tradicional" de gestión de proyectos es inapropiado para las prácticas actuales. La "administración tradicional" de proyectos El enfoque que llaman "tradicional" se caracteriza por buscar el control y la predicción del trabajo: se hacen planes detallados para la totalidad del proyecto, aun c