Skip to content
Ingeniería de Software de Élite podcast artwork

PODCAST · education

Ingeniería de Software de Élite

by Edgar Fernández

Soluciones a problemas comunes en equipos de desarrollo de software

Publisher-supplied feed metadata · PodParley refreshed Apr 26, 2024 · Source feed

Episodes

  1. Te han mentido: Agile no es una metodología, es una forma de ser

    Te han mentido. No existe tal cosa como “la metodología ágil” porque la agilidad no se puede prescribir. No es una píldora que tomas una vez y resuelve tus problemas de un día para otro. Pero muchos siguen convencidos que sí lo es.

  2. Cosas que te enseñaron mal sobre agilidad

    En esta nueva serie de artículos quiero hablarte de muchos de los conceptos que se entienden mal sobre la agilidad y, por lo tanto, se aplican erróneamente en las formas de trabajo (por ejemplo, que “Agile” es una metodología y se adopta como tal). Quiero hablarte de cómo es que esto ocurre y…

    more
  3. Optimiza el flujo de trabajo sin detener al equipo

    Una estrategia de aseguramiento de la calidad mal diseñada entorpecerá el flujo de trabajo y generará retrasos. Veamos algunas maneras de optimizar el flujo del equipo, asegurando una alta calidad.

  4. Elimina al equipo de testing

    Esta es la historia de un conflicto ríspido entre Testers y Devs, y de cómo lo podemos eliminar

  5. ¿El aseguramiento de la calidad es una pérdida de tiempo?

    Es común creer que empezar a probar antes garantiza la calidad y ocurre lo opuesto ¿Por qué? Vamos a encontrar la respuesta a esta cuestión

  6. ¿Puedes predecir si el software fallará antes de probarlo?

    Más allá aún: ser capaz de predecir la cantidad de defectos y fallas que tendrá el software antes de iniciar testing

  7. Esto es lo que te hará un mejor desarrollador de software

    En el primer episodio de esta serie, te compartí que hubo un cambio en mi forma de trabajo y mi actitud al desarrollar software, que me hizo un mejor desarrollador

  8. Este es el primer paso para establecer una cultura de la calidad

    En el desarrollo iterativo, suele pensarse que parte de iterar sobre el MVP incluye arreglar los bugs y fallas. No es lo más adecuado, porque si tu MVP ya es suficiente para ir a producción, no lo podrías enviar inmediatamente porque tiene fallas, lo cual impide la agilidad. La calidad debe ser…

    more
  9. La gestión de la calidad cambió mi vida

    Un tema que tuvo un alto impacto profesional en mí fue el de Gestión de la Calidad en el desarrollo de software. Literalmente cambió mi vida para bien y para siempre. Hoy, es algo que difundo y comparto (a nivel de evangelizador) a donde voy, pues lo considero fundamental para el desarrollo de...

  10. 5 pecados de la Administración de Proyectos de software

    La mala gestión ocurre en software. Una serie de decisiones y acciones conducen a esta situación. A lo largo del tiempo, he identificado cinco que siempre están presentes y te las describo

  11. Solo esforzarte más nunca mejorará tus resultados

    Medir es un proceso disciplinado, el cual es utilizado para comprender las razones de un desempeño actual y emprender acciones de mejora asertivas

  12. ¿Cómo evitar el “Es que en mi computadora sí funciona”?

    Los procesos de gestión de la configuración son críticos y muchos equipos suelen ignorar definirlos, pero si nombramos a un responsable, el Líder de Gestión de Configuración correremos menos riesgos.

  13. Cuando la presión por entregar entra por la puerta, la calidad salta por la ventana

    Dos de los roles, que hemos mencionado en esta serie, son responsables directos del aseguramiento de la calidad en el desarrollo del software: el Líder de Calidad y el Líder de Pruebas.

  14. ¿Quieres un equipo autodirigido y de alto rendimiento? Déjalo definir su forma de trabajo

    Es más fácil gestionar un trabajo que conoces bien. Si tú lo definiste, entonces eliminamos la curva de aprendizaje de un proceso organizacional.

  15. Equipos tradicionales vs. Equipos autodirigidos, ¿cuál te dará mejores resultados en desarrollo de software?

    Un equipo tradicional tiene un solo tomador de decisiones, mientras que uno autodirigido decide todo en consenso y en comité

  16. La gestión del trabajo es una responsabilidad compartida en desarrollo de software

    Hacer software es un trabajo complejo. Involucra múltiples tareas y habilidades diferentes. Lo mejor es que la gestión del trabajo se haga por varios roles en el equipo

  17. No necesitas un Project Manager para hacer software

    ¡No necesitas un #PM para hacer #software! Pero debes administrar el trabajo de desarrollo si quieres que se haga bien. Es muy difícil que una sola persona administre una actividad tan compleja como la creación de software, así que es mejor que el equipo se autogestione. Sin embargo, deben…

    more
  18. ¿Quieres lograr empatía con tus usuarios? Fíjate en cuatro cosas

    ¿Qué debo hacer, en el contexto del desarrollo de software, para poder lograr empatía con mis usuarios? Debes fijarte en cuatro cosas. Acompáñame a conocerlas.

  19. Análisis de negocio o de sistemas 101

    Las habilidades de análisis de negocio y de sistemas son importantes para todo ingeniero de software y debes trabajar en ellas. Abordemos lo que es esta disciplina

  20. ¿Qué es necesario para hacer la mejor solución de software?

    La mejor solución de software se consigue haciendo algo muy simple, que te describo a continuación.

  21. El mejor ciclo de vida para tu desarrollo

    No existe un solo ciclo de vida que sea efectivo para todos los productos y todos los desarrollos de software. En este artículo te hablo de cómo elegir el ciclo adecuado para tu próximo desarrollo

  22. ¿Cómo se hace el software? Ciclos de vida

    El ciclo de vida del software es una de las decisiones importantes que toma todo equipo de desarrollo, pues una mala elección entorpece la obtención de los objetivos del producto

  23. La idea que ha perjudicado a tres generaciones de ingenieros de software

    Hasta hace poco, no comprendía por qué la mayoría de la gente en el mundo del software es renuente a practicar la Ingeniería del Software. Hablando con algunas personas lo entendí

  24. Conviértete en un excelente receptor de retroalimentación

    Puedo decir, con seguridad, que el saber recibir y manejar la retroalimentación es más relevante que saber emitirla. Podemos aprender y convertirnos en mejores receptores de esta información

  25. No sabes recibir y manejar la retroalimentación

    En general, el entrenamiento se enfoca en enseñar cómo dar la retroalimentación. Pero esto solo es la mitad del proceso. La otra, es la recepción y manejo, que suele ser algo que pocos saben hacer.

  26. ✏️ La documentación es necesaria en el desarrollo de software

    Los Ingenieros de Software debemos ser conscientes de que esta actividad es importante y no debemos omitirla. Tres ideas clave: por qué documentar, lo que no es documentación y cómo hacerlo

  27. ¿La documentación es necesaria en el desarrollo de software?

    Esto es algo que escucho con frecuencia: yo no hago documentación en el software que desarrollo. Aquí te digo por qué esta idea es errónea y dañina

  28. ¿Usas el criterio adecuado para priorizar el trabajo?

    ¿Cómo ordenarías estos criterios para priorizar el trabajo? - Urgencia del cliente / usuario - Riesgo potencial y Valor para el cliente / usuario - Valor para el cliente / usuario - Estabilidad del requerimiento Te comparto mi lista y mis razones

  29. Hagamos a la ingeniería Sexy otra vez

    La Ingeniería de Software es mucho más que “un montón de páginas y diagramas”. Es el camino que conduce a producir un resultado que deleita a los usuarios lo más rápido. Como decía Watts Humphrey: la forma más rápida de hacer el software, es hacerlo bien a la primera. Eso solo se logra con la...

  30. El software es tan necesario, que le perdonamos que sea malo

    Parece que la calidad es un tabú en el gremio o algo que se puede postergar e incluir después; basta ver la lista de actualizaciones de apps en tu teléfono móvil para darnos cuenta que, en su mayoría, se trata de “soluciones de errores (bug fixes)”. Esto tiene varias causas; las que yo veo, como...

  31. El “God complex” de los desarrolladores de software

    Muchos desarrolladores de software padecemos el “God Complex”: creemos que todas nuestras decisiones son acertadas y sabemos más que todos. También, que podemos resolver los problemas con poca o nada de ayuda. Ágil parte de un hecho: empezamos a implementar la solución sobre un problema que ya...

  32. 5 elementos para una retrospectiva de alto valor

    En nuestras observaciones, hemos encontrado que dan mejores resultados si los equipos se concentran en uno o dos temas a la vez y los atienden respondiendo cinco preguntas.

  33. Lo que NUNCA debes hacer en una retrospectiva

    La retrospectiva es una práctica que aporta valor en la mejora continua, sin embargo he visto que muchos equipos evitan la práctica, los ingenieros prefieren ausentarse a la reunión porque la ven como pérdida de tiempo o, simplemente, le temen. Esto ocurre porque la actividad se ha distorsionado…

    more
  34. ¿Cuál es el mejor método ágil? La respuesta no es lo que crees

    Mi respuesta, desde hace algunos años, ha sido esta: todos y ninguno. Aunque escuches y leas de los casos de éxito que ha tenido Scrum, de lo fantásticas que son los métodos de Netflix y Spotify, de lo terrible que es Waterfall (cascada) y de que solo Ágil puede funcionar, es una mala idea…

    more
  35. ¿Cuáles son los resultados producidos por un trabajo de desarrollo efectivo?

    En esta ocasión te hablaré de lo que ocurre cuando los miembros del equipo colaboran activamente en establecer acuerdos, que les permiten obtener buenos resultados consistentemente. Recuerda que el trabajo de software depende, en gran medida, de las interacciones entre las personas. Cuando los...

  36. Síntomas de un mal trabajo de desarrollo

    El Driver de la agilidad "Organización del equipo" procura la autonomía y la autodirección de los equipos de software. Es decir, que los equipos acuerden una forma de trabajo que les sirva. Si esto no se realiza adecuadamente, veremos algunos síntomas de un mal trabajo de desarrollo, como los...

  37. Hard skills vs. Soft Skills: ¿cuáles te hacen mejor desarrollador?

    ¿Qué es más importante para un ingeniero de software, programar bien en el lenguaje de programación o saber ortografía y redacción en su idioma? Aquí te comparto algunos de los aprendizajes que he obtenido al respecto a lo largo de mi carrera, que te ayudarán a conseguir equilibrio. No aprendas a...

  38. Cinco drivers para el alto desempeño

    La influencia en los resultados proviene de cinco aspectos y en la capacidad de desempeñarlos bien o la ausencia de estos. Los llamamos "Drivers para el alto desempeño" y te cuento cuáles son.

  39. La capacidad de tus equipos no depende del número de personas que lo integran

    Un equipo de trabajo con el que colaboré, estaba conformado por 7 personas (6 desarrolladores y 1 líder). El equipo comentaba que estaban muy ocupados y no podían iniciar trabajo con clientes nuevos con rapidez. También, se quejaban de que no les autorizaban contratar más personas, que pudiesen...

  40. Perderás oportunidades de negocio si haces esto

    Una vez, un director de empresa me dijo que su producto de software estrella se estaba quedando rezagado: Tenía varias funciones, pero estaban especializadas en un nicho del mercado. No podía ofrecerlo a nuevos clientes u otros giros. No tenían a un encargado, que pudiese identificar nuevas...

  41. ¿Quieres que tu equipo se ponga la camiseta? Deja de hacer esto

    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…

    more
  42. 65% al 85% del tiempo del equipo es improductivo. La causa: se dedica a apagar fuegos

    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...

  43. Entregas demasiado lentas: las razones por las que tu tiempo de desarrollo es muy largo

    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...

  44. Cinco red flags en organizaciones de desarrollo de software

    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...

  45. Cómo deleitar a tus usuarios: aprende la validación de requerimientos

    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 ha consumido mucho del presupuesto, puede causar daños irreparables para el cliente, hasta la quiebra de la compañía....

  46. Cómo deleitar a tus usuarios: aprende la especificación de requerimientos

    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á suposiciones y ocurrirán otras situaciones que causarán que haya un entendimiento diferente...

  47. Cómo deleitar a tus usuarios: Análisis de requerimientos

    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 a nuestro sistema: — El contexto en el que se desempeña — La información que pertenece al…

    more
  48. Cómo deleitar a tus usuarios: aprende a recolectar los requerimientos

    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?",...

  49. Cómo deleitar a tus usuarios: aprende a priorizar los requerimientos

    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?...

  50. Cómo deleitar a tus usuarios – ¿Qué son los requerimientos?

    ¡Hola! Bienvenido a la serie "Cómo deleitar a tus usuarios". En esta serie de videos 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 videos. En este primer...

Type above to search every episode's transcript for a word or phrase. Matches are scoped to this podcast.

Searching…

We're indexing this podcast's transcripts for the first time — this can take a minute or two. We'll show results as soon as they're ready.

No matches for "" in this podcast's transcripts.

Showing of matches

No topics indexed yet for this podcast.

Loading reviews...

ABOUT THIS SHOW

Soluciones a problemas comunes en equipos de desarrollo de software

HOSTED BY

Edgar Fernández

Frequently Asked Questions

How many episodes does Ingeniería de Software de Élite have?

Ingeniería de Software de Élite currently has 64 episodes available on PodParley. New episodes are automatically indexed when they're published to the podcast feed.

What is Ingeniería de Software de Élite about?

Soluciones a problemas comunes en equipos de desarrollo de software

How often does Ingeniería de Software de Élite release new episodes?

Ingeniería de Software de Élite has 64 episodes. Check the episode list to see recent publication dates and frequency.

Where can I listen to Ingeniería de Software de Élite?

You can listen to Ingeniería de Software de Élite on PodParley by clicking any episode. We provide an embedded audio player for direct listening, and you can also subscribe via your preferred podcast app using the RSS feed.

Who hosts Ingeniería de Software de Élite?

Ingeniería de Software de Élite is created and hosted by Edgar Fernández.
URL copied to clipboard!