While Agile and DevOps software methods are hardly new concepts, their application in specialized contexts may in fact require new thinking and innovative methods of tailoring. Moving organizations to adopt Agile methods for the acquisition of systems with safety- and/or security-critical constraints can be an exciting but daunting undertaking, requiring significant effort on both technical issues as well as organizational change ones. An important goal is to obtain the desired benefits of new approaches (e.g. speed to delivery) along with existing aspects that can’t be left behind (e.g. the engineering rigor needed to develop safe and secure software with confidence). In this talk, I draw from experiences in this area to explore questions related to the interplay of research and practice. How much can prior software research work influence large-scale decisions related to software practice? “Do we trust or do we know” regarding the effects of decisions that have to be made and will have significant practical repercussions? And, can new research help fill in gaps in our knowledge, at the right speed to be relevant?

Los equipos Scrum deben ser win-win para clientes y desarrolladores. Pero desde un tiempo a esta parte hay una tendencia a equipos Scrum lose-lose. Algunos fueron equipos “vivos” del primer grupo y se convirtieron en zombies… perdiendo agilidad con el paso del tiempo; los más maléficos, los orcos, fueron creados sin alma, con fines viles y oscuros. Con humor, analizaremos ambos tipos de equipos, encontrando en el público quiénes se identifiquen con uno u otro grupo.

Cuando un equipo de desarrollo es maduro, se refleja en la calidad del software. Pero qué es un equipo maduro? Esta charla trata de como con menos podemos hacer más, no es necesario tener 50 personas en un proyecto para que este sea exitoso. Al contrario, mientras más contenido sea, mayor va a ser el alcance y valor que le vas a poder entregar a tus usuarios. Un equipo maduro no significa tener 8 Senior full stack developers, es tener un equipo y no importa que roles lo componen que tengan al usuario en el centro. Que entiendan sus necesidades y velen por solucionar sus problemas.

No cabe duda que, a 18 años de la publicación del Manifiesto Ágil, esta escuela de pensamiento ha alcanzado su mayoría de edad. La magia es obvia: clientes más satisfechos, resultados iniciales más tempranos, rápida reacción ante los cambios, mayor autonomía y satisfacción personal, pero ¿cómo es esto posible? ¿cómo se puede desarrollar software sin tener todos los requerimientos definidos? ¿cómo se puede reducir o eliminar la documentación? ¿cómo se puede prescindir de un jefe de proyecto? ¿Quién ordena y controla la ejecución de las tareas? En esta charla discutiremos las elecciones y mecanismos que anteceden y hacen posible que los métodos agiles funcionen y cuáles son las consecuencias de no conformarnos a ellos. Esta conversación es especialmente relevante dado que pocas organizaciones usan los métodos tal cual son recomendados por sus creadores y, si por el contexto del negocio o idiosincrasia, nos alejamos de sus premisas sin reemplazarlas con medios adecuados, nos exponemos al fracaso.

Esta charla tiene como principal objetivo compartir la experiencia de un proyecto gestionado con metodologías Ágiles en el Banco de Previsión Social del Uruguay y cómo durante ese proyecto se fueron resolviendo las siguientes interrogantes: ¿Cómo se relevaron los requerimientos? ¿Cómo se hizo la planificación de este proyecto? ¿Cómo se organizó el equipo? ¿Qué se hizo para lograr entregar de software funcionando cada 15 días? ¿Se alcanzó la fecha planificada? ¿Los diferentes stakeholders quedaron satisfechos? ¿Fue beneficiosa la aplicación de una metodología ágil en este contexto?

La construcción de software es un proceso colectivo, donde intervienen múltiples actores que negocian sus expectativas, logran éxitos y cometen errores. El testing procura mitigar el riesgo de que en producción se manifiesten fallas, tanto por los errores como por divergencias en la negociación de expectativas. Por lo tanto, a quién, cómo, y qué enseñamos de testing es un desafío “de calidad” para esta comunidad de actores. Los invitamos a compartir los quince años de experiencia del CES enseñando testing a informáticos y no informáticos.

Nuevamente aparece un nuevo nombre para técnicas de ingeniería de software dirigidas por modelos. Plataformas Low Code / No Code como forma de construir sistemas de software complejos. Plataformas Low Code proveen ambientes para que programadores u otros perfiles puedan construir sistemas utilizando técnicas alejadas de las tradicionales formas de construcción de software. Cuál es la relación con los existentes conceptos en ingeniería de software, que oportunidades existen para el Uruguay alrededor de estas plataformas.