Software Industry Coach

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

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

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í

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

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.

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 mayoría hacen a un lado la Ingeniería (se llama Ingeniería de Software, ¿recuerdan?). ¿Por qué ocurre así, qué es lo que ocasiona y qué podemos hacer? Vamos a explorar un poco.

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 recomendaciones de lo que debes entender bien antes de comenzar el desarrollo de un producto de software.

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, aquí te hablo de algunos.

¿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ía antes de entender el problema a resolver Asume roles activamente dentro del equipo

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 integrante que se fue a otro empleo y no fue reemplazado. Muchas organizaciones entrarían en una crisis en ese escenario con los proyectos actuales. Sin embargo, el equipo del que les hablo tuvo un mejor resultado: incrementó su capacidad de atender nuevos clientes en 53% en un año, con 6 personas solamente. El equipo creció sin aumentar la cantidad de integrantes. Otros equipos, en otras organizaciones, crecen en personal, pero no en capacidad en la misma proporción; incluso, algunos la reducen conforme más personas llegan. Hay varias razones para esto, aquí te expongo algunas.

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 varias cosas. Entre otras dificultades de gestión de la configuración, de las que no hablaré el día de hoy. Varias organizaciones, que desarrollan software para terceros o internamente, enfrentan esta dificultad: la brecha tecnológica (aprovechar al máximo la tecnología) se ensancha en lugar de cerrarse. Por esta razón, todas pierden oportunidades de negocio, pues no pueden vender un producto nuevo o sus operaciones internas se ralentizan porque la tecnología no está ahí para apoyarlas. A continuación te presento algunas de las razones por las que las organizaciones de software pierden oportunidades de negocio.