Ingeniería de Software de Élite

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

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

¿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

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 Discilina de la Ingeniería.

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 principales, son: que los desarrolladores creen que todo se soluciona con tecnología solamente y que la...

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 comprendimos en su mayoría y lo que se descubre es el cómo resolverlo mejor. Por eso, aquí te dejo tres r...

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.

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 y ya no sirve para su propósito. Esto es lo que nunca debes hacer en una retrospectiva.

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 intentar copiar la forma de trabajo definida por otros y aplicarla así en nuestro equipo.

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 integrantes del grupo trabajan, saludablemente, en crear acuerdos, observarás que ocurre lo siguiente.

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

¿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 usar el framework haciendo el sistema No apliques religiosamente una metodología No elijas la tecnolog...

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.

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 ayudarles a crecer su capacidad de producción. El equipo, en los tres meses que colaboramos, perdió un i...

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 tendencias y necesidades para incorporarlas. Además, estaban retrasados en el mantenimiento correctivo de va...

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

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

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

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

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. Entender mal los requerimientos es algo completamente normal y a todos nos va a pasar. Lo importante es q...

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 de lo que debe y no debe hacer el software. No resolver rápidamente las dudas o que haya esa comprensi...

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 dominio del sistema — Cómo y dónde se procesa la información — El comportamiento que debe tener el sistema an...

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?", "¿Lo quieres responsivo?".  Ya que estamos en eso, t...

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 y grupos. Entre esos i...

¡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 video, te hablaré de qué son y en qué consisten las actividades de requerimientos, de su importancia y el...