Ingeniería de Software de Élite

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 con duraciones de años, y se pretende seguir rigurosamente ese plan para cumplir con los objetivos y evitar las desviaciones. Generalmente existe la figura del Project Manager, quien mantiene y controla el avance en el proyecto, y los trabajadores pocas o nulas veces se ven involucrados en la definición o corrección de ese plan.

Se ve como una estructura rígida, en la que el objetivo es seguir el plan en vez de buscar la satisfacción del cliente, y usualmente se asocia con la entrega de un producto inadecuado para las necesidades del usuario, que cambiaron significativamente desde que se elaboró el plan la primera vez.

El enfoque "nuevo" para administrar proyectos de software

Algunos dicen que el "enfoque tradicional" no funciona para la ingeniería de software porque el trabajo es distinto al que se hace con las manos o en líneas de producción. En una línea de productos se puede predecir y pronosticar con claridad porque el trabajo y las necesidades están bien comprendidas, algo que rara vez pasa en software.

Además, el desarrollo de software entra en la categoría de "trabajo intelectual", donde los resultados se obtienen a través del esfuerzo mental en lugar del trabajo manual, y es muy difícil gestionar ideas, particularmente si dejamos que solo una persona lo haga.

La filosofía ágil, que se ha adoptado como el estándar actual en desarrollo de software, se enfoca en generar valor para el negocio y adaptarse al cambio: aprendizaje rápido y una respuesta al entorno cambiante también rápida. Los planes largos y detallados son imposibles porque no se puede predecir el futuro, y el equipo debe estar concentrado en entregar valor en ciclos cortos, no en seguir un plan.

Adiós a los diagramas Gantt, las listas de tareas, los reportes con gráficas del avance frecuentes y otras prácticas llamadas burocráticas. En ocasiones, también significa un "adiós" al Project Manager.

Y en otras ocasiones, también significa lanzar la gestión del proyecto por la ventana.

Ahora, cada ingeniero debe saber administrar proyectos

Detrás de la filosofía ágil y de otros marcos de trabajo para software existe un principio fundamental para que las cosas funcionen:

El equipo debe ser capaz de autoadministrarse

Tom Demarco los llama "jelled teams", y son equipos que se caracterizan porque todos son partícipes y dueños de las decisiones, y suelen ser altamente efectivos porque cada integrante se hace responsable de su trabajo y sus compromisos.

Esto implica que cada uno es capaz de administrar correctamente un proyecto, que tiene el tamaño de una persona, es decir:

Puede estimar el esfuerzo que requiere hacer el trabajo, para saber a qué se puede comprometer.

Lleva un seguimiento de su trabajo, para identificar causas concretas de problemas y buenos resultados.

Toma decisiones y acciones correctivas con base en mediciones y análisis comparativos entre sus expectativas y resultados.

Comunica su estatus continuamente y sabe cuándo levantar alertas oportunamente para evitar problemas

La razón por la cual un equipo no requiere un Project Manager es porque cada ingeniero es su propio Project Manager.

Gestionar proyectos es seguir principios, no llenar documentos

La idea de administración de proyectos se puede asociar con la idea de métodos, procesos y artefactos rígidos: Aplicar algo dogmáticamente (como el PMBOK) al pie de la letra, pero es algo muy distinto.

Gestionar el proyecto significa guiar el proyecto hacia conseguir los objetivos y optimizar los recursos, no llenar documentos y ser el policía del cumplimiento del plan.

Administración de proyectos, antes que un método, es un conjunto de principios. Es muy importante que un Ingeniero de Software actual los conozca y sea capaz de aplicarlos, pues en la práctica actual es imposible que solo una persona lo haga, y si el ingeniero mismo no administra su trabajo, entonces nadie estará haciéndolo.

[siteorigin_widget class="SiteOrigin_Widget_Cta_Widget"][/siteorigin_widget]