Desarrollo de Software: Del absurdo absoluto a la validez de lo relativo

Hace un tiempo mientras estudiaba mi especialización en desarrollo de software (mal entendida por muchos como solo programación), encontré entre mis docentes alguien realmente valioso, para mi lástima, tan solo nos dió una sesión pues justo para esa cohorte no podría ser docente, sin embargo 2 horas escuchándolo lo dejaron clavado en mi mente y desde entonces llevo sus enseñanzas en cada clase a mis estudiantes. Después de conocer a Luis Fernando Londoño considero que aprendí la gran diferencia de marcar la vida de alguien siendo docente, hoy no recuerdo muchos de los nombres de docentes que vi por 4 meses, sin embargo a él no lo olvido, ahora menos, después de conocer parte de historia. Una de las frases que más uso para mencionarlo es acerca de los procesos en la ingeniería de software:

"El tema que tiene que ver con procesos es como el habito de comer, uno puede comer de dos maneras, bien o mal en ultima instancia el fin para muchas personas es llenarse… Uno puede comer comida sana o comida chatarra y vive, puede vivir con mas dificultades pero vive,… Sin embargo el que se alimenta bien tiene más posibilidades de sobrevivir"

Hoy después de 4 años tengo la oportunidad de darle a mi comunidad el regalo de escuchar de su voz y experienciencia, en carne propia como lo llamo yo, a un hombre que tiene mucho que decir, desde el conocimiento, la razón, la lucha y el corazón. Les comparto el resumen de su conferencia que será el regalo de aniversario de un sueño que lleva 4 años creciendo y siendo, Avanet.

Desarrollo de Software: Del absurdo absoluto a la validez de lo relativo
Por Luis Fernando Londoño 

No es afortunado concebir el cómo desarrollar software como un absoluto, no podemos permitir que los intereses de falsos evangelizadores, nos conviertan en débiles seguidores. 
no se puede guiar una industria en proceso de evolución a través del establecimiento de dogmas que se van haciendo paganos y toman una dinámica mercantilista que termina en establecer formas inadecuadas de hacer de lo complejo algo simple y de una disciplina como es la ingeniería de software un objeto de burla para los que ignoran su verdadera esencia,

Las múltiples alternativas de cómo hacer buen software, están basadas en precisamente que existen múltiples variables que hacen relativo ese cómo hacerlo bien, como hacer que un problema complejo se resuelva con un método simple, que no es precisamente la prueba y el error, requiere formas dinámicas y adaptables al entorno en el ‘que’ y el ‘para que’ se va a dar solución a un problema o aprovechar una oportunidad que implica desarrollar software.

Más allá de debatir que es mejor y querer imponer posiciones dogmáticas que confunden a los ilusos, les hacen creer que todo lo que brilla es oro y que solo existe una única forma de hacerlo bien, necesitamos precisar que no hay tal principio absoluto de lo ágil o lo robusto, el único principio cierto es que se requiere capacidades de adaptabilidad de nuestros equipos de trabajo que desarrollan software: “Vacía tu mente, se amorfo, moldeable, como el agua. Si pones agua en una taza se convierte en la taza. Si pones agua en una botella se convierte en la botella. Si la pones en una tetera se convierte en la tetera. El agua puede fluir o puede golpear. Sé agua amigo mío” (Bruce Lee) 

No queremos debatir, solo compartir conceptos soportados por la evidencia que se ha venido desarrollando a partir de la experimentación en ingeniería de software, no pretendemos evangelizar solo aportar con el máximo respeto por los que en silencio aportan.

El evento se realizó el 25 de Junio de 2013 a las 8 P.M., te invitamos a ver el Hangout de Aniversario de la Comunidad Avanet y escuchar ideas que te ayudarán a poner los pies en la tierra y a formar tu propio criterio.

Sorey García

Movimiento de Responsabilidad Social Universitaria

Hace unos días después de recibir la invitación de nuestros amigos Ricardo Colusso y Fernando Claverino a realizar esta actividad, empezamos a invitar a las personas a asistir al primer encuentro del Movimiento RSU en Medellín.

Imaginar la actividad era bueno pero vivirla aun mejor, la cantidad de aprendizajes alrededor de ella, te enseñan cosas a nivel individual y dibujan frente a ti el por que del camino que ha llevado por tanto tiempo nuestra sociedad, y nos enfrenta al hecho de ¿qué estamos haciendo para que todo esto sea diferente?

Agradecemos a Fernando y Ricardo por sus enseñanzas y esperamos seguir difundiendo este mensaje en la ciudad y les invitamos a convertirse en facilitadores del movimiento tambien en su ciudad.

Sorey

Diagramas de despliegue en las paredes

Continuando con mis post sobre los Workshops de Ingeniería de Software basados en el modelo 4 + 1 vista, veamos uno de los posibles diagramas de la Vista Fisica, el diagrama de despligue.

Este es uno de los diagramas más fáciles de realizar, la razón es sencilla, a todos nos es más fácil mapear el universo fisico con las ideas. En este caso la vista física pretende mostrar cuales con las máquinas, vías de comunicación, protocolos y principales componentes involucrados en un sistema, sea por que nos comunicamos con o través de ellos o por que dependemos de ellos en alguna forma.

Es importante como ya les habia nombrado definir una notación con los elementos existentes.

Para un diagrama de despliegue básico se esperan algunos materiales básicos, (Recuerden que sean elementos que no arruinen las paredes). Estos puede ser:

Servidores, maquinas y dispositivos se pueden hacer con papeles de colores grandes, esto por que dentro de ellos se colocarán más elementos. Para dar gráficamente un orden, se pueden hacer los servidores de un color, lo mismo las maquinas y otro más para los dispositivos moviles.

En ocasiones cuando no se conoce como es el despliegue de un lugar desde el que se consume datos, se pueden recortar un papel en forma de nube, esta fue una idea de uno de los grupos con que trabajé y fue una buena forma de ver como los equipos se autogestionaban para comprender mejor el entorno del problema y explicarlo a los demás.

Ahora bien, dentro de las máquinas fisicas se despliegan 2 tipos de elementos, componentes que representan las aplicaciones instaladas y los servicios o tareas en background. Como sabemos muchas veces algunos componentes para poder ser usados estan instalados dentro de contenedores o aplicaciones que les sirven como entornos, es el caso de las aplicaciones web que necesitan de IIS, Tomcat y otros servidores de aplicaciones para poder ser servidas, o incluso de las bases de datos que necesitan un motor donde ser instaladas. Esto es conocido como los entornos de ejecución, para reflejar esto se pueden usar fichas bibligráficas o cortar los papeles de colores para que tengan un tamaño intermedio, dentro de los ambientes de ejecución colocamos los componentes que necesitamos usar o que vamos a construir en nuestro proyecto.

Otro elemento son las cintas de enmascarar de al menos 2 colores, una de ella se usa para las vias de comunicación entre los servidores y otra se usa para crear los boundaries, limites o fronteras (LAN, WAN etc). En la cinta que define las visas de comunicación se deben pegar el protocolo que usa la comunicación y se debe definir claramente la cardinalidad para establecer, quien consume datos de quien.

Estar atento de que se respeten las notaciones es importante, también tener conocimientos técnicos de algunas cosas para saber representar las diferentes técnologías. El ejercicio puede ser apoyado por quienes más conocen sobre infraestructura en el taller, sin embargo otro de los retos importantes como en todo el workshop es lograr que quienes definen esta vista esten en comunicación y validación constante con las Vistas de Procesos y las Vistas de Implementación. Recuerden que para este punto, todos los integrantes del workshop deben estar girando cada 15 minutos y llevando sus ideas de un grupo a otro.

Los resultados son muy bonitos, lo más bonito es como se encariñan con este diagrama al ser uno de los que más bien queda.

Les repito como antes, si bien el ejercicio no es absolutamente ortodoxo con respecto a las notaciones y de hecho no pretende reemplazar en nada a UML por ejemplo, es una manera de introducir a las personas en la experiencia de elegir una infraestructura, generar un diálogo acerca no solo de los temas técnicos si no de cuando se define algo cual es el impacto económico, un ejemplo de esto es cuando se definen servidores de backup, que son bastante fáciles de poner en un diagrama pero que implican gran cantidad de costos adicionales, de esto se debe encargar quien dirige el Workshop.

Por supuesto siempre quedará la idea de cual es la manera formal de hacerlo y uno de ellos es estudiar las notaciones propuestas en UML.

Espero que esta idea les resulte de utilidad. Hasta la próxima vista.

Saludos, Sorey.

El modelo 4 + 1 vistas como guía de los workshops de ingeniería de software

[Post Anterior: Re-aprendiendo como enseñar ingeniería de software]

Antes de iniciar con las reseñas de cada una de las actividades, es necesario que quienes quieren ser instructores de este tipo de actividades tengan en cuenta que deben prepararse al menos de manera básica en algunos aspectos. Yo personalmente uso estos Workshops para enseñar Arquitectura de Software a principiantes, existen otros tipos de Workshop más enfocados a Ingeniería de Requisitos y que no cubriré en mis post.

Ahora bien, independiente de las metodologías que usemos es importante recordar que hay algunos principios básicos y hasta sencillos que ayudarían a muchos proyectos y a muchas personas en proceso de aprendizaje, a involucrarse más coherentemente en las actividades que se desarrollan durante el proceso de desarrollo de software. Algunos de esos principios en la Arquitectura de Software se explican de forma genérica en el Modelo 4+1 vistas.

Dando una idea corta de lo que el significa, es un conjunto de perspectivas para afrontar un proceso de desarrollo, esas perspectivas entendidas en sus conceptos generales, pueden ser usadas para expresar y modelar los aspectos principales de nuestros proyectos, dirigiéndonos en cada vista especificamente a algunos participantes en el proceso (ver imagen). Hay otras aproximaciones  esta es una de las más fáciles de comunicar y que les recomiendo leer, tengan en cuenta que el Modelo 4+1 no define que UML es la forma de modelar las distintas vistas, sin embargo, al hacer el símil con los diferentes diagramas es posible materializarlas usando diagramas UML específicos.

Los workshops, no están enfocados a cubrir UML, lo que hago es usar algunos conceptos principales, pero es importante no olvidar que las sesiones buscan crear la sensibilización y ayudar a despertar las habilidades a los asistentes con respecto a los temas a considerar en las diferentes vistas o perspectivas. El trabajo más teórico y detallado de UML requiere de las sesiones de teoría y práctica que no son el objetivo ni de estos post ni de los workshops.

Antes de empezar con el workshop, es necesario socializar con todo el equipo el alcance del problema a resolver, claramente al no partir desde requisitos detallados la actividad no buscará un alto nivel de precisión, sin embargo si cumplir con lo que se pacte en la socialización, para que el producto final pueda ser revisado en el proceso y al terminar la actividad. De acuerdo al Modelo 4+1 lo que se converse en este tiempo serían los escenarios que todos van a cumplir en las 4 vistas adicionales.

Una de mis recomendaciones es que si hace este ejercicio en una empresa, no lo haga con una aplicación real, las personas terminan disipándose en sus problemas del día a día, elija algo sencillo, y que permita usar altas dosis de sentido común para ser resuelto.

Para la etapa de socialización he usado 3 técnicas distintas:

1. Enunciado detallado: Se entrega a todos los participantes un enunciado detallado del software que se va a construir y se hace una sesión de dudas para que todos puedan preguntar y aclarar inquietudes. Es muy importante que si se llegan a pactos o se hacen observaciones en la sesión de dudas el instructor las tenga presentes para asegurarse que en las diferentes vistas todos estuvieron pendientes no solo del enunciado si no de los acuerdos realizados. Confieso que en la parte de preguntas justamente intento introducir algún criterio de alto valor, con el ánimo de llamar la atención sobre que el cliente pidió algo y nadie estuvo atento a lo que pidió, en caso de que olviden implementarlo.

2. Historias de usuario: El instructor prepara las historias de usuario que cubren todos los escenarios de la aplicación a realizar. Esto me pareció muy adecuado y creo que es la que más repetiría en escenarios fuera de un salón de clase, la razón es que te ayuda a llegar más rápidamente al Worskhop de Arquitectura, y las historias de usuario se convierten en la herramientas que todos usan como referencia.

Con ellas se puede realizar una actividad de identificar metas, restricciones y supuestos arquitectónicos. Además en uno de los equipos hicimos la identificación de las calidades sistemicas de ISO 9126, esto depende más del nivel de los participantes. En un salón de clase de primer nivel de ingeniería recomiendo más el enunciado inicial, a menos que ya se cuente con requisitos detallados abordados en la materia o por que no, historias de usuario detalladas.

3. Workshop previo de Ingeniería de Requisitos: Según el foco y la disponibilidad de tiempo, antes de inicial el Workshop de arquitectura, puede realizarse una actividad de identificación de requisitos. Esto es una buena experiencia ya que se logra involucrar a las personas desde el inicio, sin embargo el instructor debe hacer además en algunos momentos escenas actuadas tratado de ser mas el cliente que el instructor, con el animo justamente de poner algunos tropiezos y llevar a los futuros arquitectos a buscar y no solo quedarse en consideraciones técnicas, si no entender realmente su rol, en el cual los objetivos de negocio son tan importantes como las buenas arquitecturas.

Aquí podría generar otra serie de post al respecto, más adelante espero animarme a hacerlo, ya que se pueden hacer bastantes actividades como generación de historias de usuario, prototipos, requisitos formales, etc, todo de una manera bastante lúdica.

Vistas estas 3 maneras de iniciar con el workshop, les dejo algunas recomendaciones generales.

Recomendaciones:

Como les aconsejaba antes es bueno que el instructor tenga una aplicación que conozca lo suficientemente bien, pero que siempre este dispuesto a dejar que propuestas diferentes salgan en el transcurso, conocer el proyecto es más una manera de dar ideas ante una situación donde los participantes no sepan que hacer.

Generalmente abordo he abordado esta actividad en grupos de 10 o más personas, la idea es que el grupo se divide el equipo en equipos y se les encarga a cada equipo de una de las vistas.

Recomiendo que minimamente antes de empezar se haga una socialización del Modelo 4+1 vistas, esta puede realizarse con las notas breves del Modelo 4+1 de Javier Garzas.

Asignación de participantes:
Si el docente o instructor conoce las personas en la actividad, es bueno que inicialmente asigne al menos una persona con conocimientos en cada vista. En la vista logica un analista funcional, en la vista fisica alguien que le guste y conozca temas de IT y redes y en las vistas de implementación y procesos a quienes sepa que son más buenos en el ámbito del desarrollo de software.

La idea consiste en hacer sesiones de 15 minutos, cada quince minutos uno de los integrantes del equipo o más en caso de ser muchos, giran a otra de las vistas, la dinámica se da hasta que todos hayan pasado por todas las vistas. Cada que alguien nuevo llega a un equipo, debe ser puesto en contexto de lo que se está trabajando. La parte genial que da la dinámica de girar es que cuando alguien gira, debe ayudar a que la otra vista sea consecuente con la vista en la que estaba participando antes, de hecho esto se da por defecto, pero si no debe ser indicado por el instructor.

El instructor debe estar pendiente además de los equipos que enfocan mal el sentido de las vistas o que no avanzan por que sienten algún bloqueo.

Espacio de trabajo: 
Trate de buscar un espacio amplio donde la gente pueda desplazarse, no permita que se usen computadoras o dispositivos moviles en el transcurso de la sesión, que todos estén involucrados trabajando.

Necesitará trabajar en las paredes, así que asegúrese de que todos los materiales que usan no maltratan las mismas. Algunos diagramas necesitan además escribir y borrar, para esos necesita un tablero para marcadores borrables o muchas hojas de papel periódico.


Estrategia:
Como preparación al Workshop, defina las reglas de cada una de las vistas. Elija un modelo para hacer en la sesión en cada una y defina una cada de herramientas, esto se convertirá en la guia de las actividades de cada uno de los equipos.

En adelante generaré 4 post con cada una de las vistas y mis aprendizajes en ellas, en cada una les diré que reglas o caja de herramientas uso, y espero recibir sus comentarios.

Los veo en la siguiente entrega.

Sorey

Re-aprendiendo como enseñar ingeniería de software

Hace algún tiempo, en mis post de ingeniería de software de este blog, en mis artículos y conferencias por ahí, vengo hablando de lo mucho que me preocupa el tema de la falta de sensibilización que se hace a los profesionales en formación respecto a la calidad y la ética profesional, pero además de eso, la preocupación un poco más común del hecho de que los jóvenes salen de las universidades vagamente preparados para enfrentarse al mundo real, que a veces no les da tiempo ni de reaccionar frente a los conocimientos que adquieren.

Ante esta problemática, un día me cansé de hablar de mis preocupaciones e intentar llevar a mis estudiantes del salón de clase y sumergirlos en una experiencia diferente, sin dejar de lado el aprendizaje de algunos de los conceptos teóricos más importantes, pero haciendo especial enfasis en la calidad, la ética y las habilidades humanas que como individuos ayudan tanto en nuestros equipos de trabajo cuando hablamos de desarrollar software.

Es así que hoy inicio una serie de post, contándoles sobre un conjunto de aventuras que he tenido, tratando de salirme de la acartonada forma de explicar ingeniería de software únicamente descargando montones de conceptos teóricos en las personas.

Las herramientas, sencillas:

• Post it de formas y colores diferentes
• Papeles de colores tijeras
• Cintas de enmascarar de colores
• Paredes, tableros
• Marcadores borrables y permanentes pequeños

Pero sobre todo muy buena energía y una sensibilización previa sobre la importancia de la calidad y la ética en la ingeniería de software, además de dar bases y conceptos teóricos sobre ingeniería de requisitos y metodologías tradicionales y ágiles.

Los ejercicios van desde construcción manual de prototipos de acuerdo a los requisitos, hasta generación de historias de usuario, analisis de las perspectivas del modelo 4+1 vistas, y muchos más.

La ventajas que todo esto ha traido en mi salón de clase, difieren claramente de mis 6 años dictando esta materia. Todas las personas del salón están involucradas en la construcción de los diferentes diagramas, a veces se trabaja en equipos separados, a veces todos juntos.

En el camino se ve como cada persona va tomando las actividades y roles que más le gustan, casi como un entorno real, se eliminan las largas sesiones teorícas, y siempre van a compañadas de algún ejercicio práctico. Los estudiantes se distraen mucho menos con los equipos de computo, y tienen más experiencias de recordación.

Quienes son más técnicos ayudan a los demás a adquirir cierto nivel de comprensión en la solución de los problemas y quienes son más analíticos ayudan a los demás a concentrarse en no solo cosas técnicas, como es realmente la ingeniería de software. Lo muy importante es que todos ellos se enseñan entre sí mismos.

Claramente hay algunos riesgos o situaciones a tener en cuenta, es una actividad física más desgastante para todo el mundo, y el docente debe estar en capacidad de guiar coherentemente cada uno de los escenarios, mi recomendación sería que se elija una aplicación que conozca lo suficiente pero que siempre este abierto a las opiniones de mejora de los estudiantes. Con cada grupo, la interacción es distinta y a veces hasta hay resultados diferentes. Las aplicaciones móviles con background empresarial son excelentes referentes.

Para ir haciendo un seguimiento de manera ordenada y comunicarse todos, he usado Trello para llevar mis clases y ha sido un verdadero éxito. Siempre lleve mis clases a través de muchos medios, páginas web, herramientas para docentes, sin éxito alguno. Definitivamente una herramienta colaborativa fue lo mejor, les comparto una imagen de nuestro board a hoy y los invito a estar pendientes de cada uno de los post donde les contaré individualmente las dinámicas y las ventajas y desventajas o situaciones importantes que vivimos en cada una de ellas.

Creo que la repetición va a ir enseñandome cosas, de hecho he realizado varios talleres ya, con estudiantes, profesionales técnicos y clientes y cada uno de ellos me ha dejado variado aprendizaje.

Este es nuestro board de Trello en clase, espero que este primer post les de algunas ideas y por que no, que compartamos aprendizajes.

Saludos y hasta la próxima.

Sorey

Sobre el liderazgo

Por estos días miraba mi dashboard de Slideshare, muy contenta de superar las 500.000 visitas, cosa que celebro con ustedes.

Allí encontré que una de las presentaciones favoritas de la gente es la que trata sobre el Liderazgo, tiene unas 41.500 visitas y algunos embeds que me alegran mucho, sin embargo yo no la tengo publicada en mi blog y es por lo que ahora se las comparto.

Creo que esta presentación fue de las primeras veces que intente hacer una presentación que generara impacto, fue para una tarea de la especialización, y pues salió bien, encontrarla me trajo buenos recuerdos.

Como en la presentación lo dice, está basada en el libro "Hablan los gurús", pero es un sencillo compilado de las ideas principales. En fin, espero les guste y les sea de utilidad, la pueden descargar en slideshare en pdf.

El Liderazgo from Sorey Garcia