Clements, Paul, Bachmann, Felix, Bass, Len, Garlan, David, Ivers, James, Little, Reed, Nord, Robert, Stafford, Judith, Documenting Software Architecture: Views and
Beyond, SEI Series in Software Engineering, Addison-Wesley, 2003.

Bass, Len, Clements, Paul, Kazman, Rick, Software Architecture in Practice,
SEI Series in Software Engineering, 1998.

Evans, Eric, Domain-Driven Design, Tackling Complexity in the Heart of Software, Addison-Wesley, 2004

Fowler, Martin, Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2003.

Gamma, Eric, Helm, Richard, Johnson, Ralf, Vlissides, John, Design Patterns,
Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

Garlan, David, Shaw, Mary, “Software Architecture: Perspectives on an
Emerging Discipline”, Prentice Hall, 1996.

Meyer, Bertrand, Object-Oriented Software Construction,
Prentice-Hall, 1985, 2da. Edición 1997.

Artículos

Garland, David, Allen, Robert, Ockerbloom, John, ”Architectural Mismatch, or
Why it’s hard to build systems out of existing parts”, Computer Science
Department, Carnegie Mellon University, Pittsburgh, 1995.

Kruchten, Philippe, “Architectural Blueprints- The “4+1″ View Model of
Software Architecture”, IEEE Software 12 (6), 1995.

It was an amazing experience for me, in particular because I had never run a scrum training outside the software development community, and both the differences and similarities I found, between the work they do and the work we software developers do, turned out to be fascinating.

We worked mostly around physical activities oriented towards understanding the ways of collaboration and complexity, mixed with some short talks to present the Artful Making and Scrum frameworks. The challenges I expected were:

* The group usually facilitates workshop on communication, human and children’s rights, community radio shows and the like, so I considered they might already be familiar with some of the activities I usually use, so I tried to choose activities they would find new and attractive.

* That the group might not share many terms we take for granted in software development, and some terms we share tend to have slightly different meanings (e.g. goals).

* That the role of the Product Owner, or the presence of the business leader might not appeal to them.

I could not have been more mistaken. Most of my preconceptions where dead wrong, and I imagine now that even what I considered engineering oriented activities like the Pajarraco Rasti/Lego building game would work perfectly (I have since learned that Alan Cyment, Astrid Astiz and Veronica Sack have used the game with non software development teams). The group enjoyed both the discussions and the activities, including some techniques I had to use to keep the workshop in track (for instance, I had to teach them to use the talking stick because they would interrupt each other frequently and some discussions seemed never-ending). It was for me a great opportunity for joined reflection on facilitation, the responsibilities of preparing yourself for each activity and the ways in which we try for valuable results in our group dynamics.

Here is a picture of the beautiful natural setting in which the workshop took place:

I would like to hear of your own experiences, thanks,

Diego

Books
More about requirements, by Karl Weigers

This book is a great sum of requirements engineering best practices. It takes an ecumenical look at the subject matter, trying to avoid a specific viewpoint.

Advanced Use Case Modeling

A good compendium of use case modeling techniques, although advanced users might not find many new perspectives or techniques.

The Social Life of Information:

A critique of the value that society places in huge volumes of undigested information, this book is a breath of fresh air for us working with information technology. It endeavors to tear down the myths of the home office, the value of information by itself, process vs. practice and learning.

Contextual Design

Psychology meets system’s engineering. This is an eye opener for engineers because it is focused on describing and understanding the work that people do rather than the systems they use to do it. A great tool to try out when interviewing your future users to decide what to design.

The design of everyday things

Again we have psychology to learn design from, in a very interesting and insightful book that explains why the world of common objects around us is usually designed against rather than for people. Of special interest are the feedback principle and the design for error considerations.

The Mythical Man-Month

An absolute classic, the necessary and precise justification of the complexity that we perceive when we work with software. I think “No Silver Bullet” is specially important for those of us who believe that what we do will remain a complex endeavor and a constant surprise.
Hope this will tempt you to do some reading,

Diego

Termina el primer día, mañana veremos.

(Ya hubo una charla con este tenor en el Agile Open Buenos Aires.)

Scrum para proyectos de software con artistas (tal vez ni contestan los mails).

Ariel destaca el encuentro de la mejora de exportar hacia otras disciplinnas
Artful Making: Lo que podemos tomar del arte sobre cómo aprender: Por ejemplo, la repetición. La iteración te permite tomar ritmo, pero no debe ser exacta, hay que aceptar la variedad y aceptarla con gusto, porque permite innovar.

Miedo al error, debe cambiarse la cultura. El programa de 12 pasos de AA inicia con aceptar el problema, y reconocer los errores.

El proceso iterativo puede ser raro para organizaciones que no hacen software.

Ariel cuenta cómo el lenguaje técnico de software, con términos como “validación” resultan muy extrañas fuera del ambiente del software. También pasa con la terminología en inglés o mal traducida.

Ariel destaca los valores humanos en las metodologías ágiles, como aporte desde otras áreas de conocimiento. Ejemplos: Colaboración, Comunicación, Innovación.

Ariel, los ingenieros de software necesitan tener exposición a las artes y otros estímulos. Diego, el desarrollo de un lenguaje rico es necesario para construir software, conceptualizar las ideas básicas.

Etnografía para requerimientos de software, sociólogos trabajando.

Experiencias
Ariel, Open Space en vista en fábricas recuperadas. Tienen problemas porque los mandos medios se fueron y las asambleas no funcionan.

Empresa de Diseño gráfico en los cursos de CSM. Usan sprints y retrospectivas. Los dueños forman parte del equipo, que no termina de ser de pares.
¿Cómo llegaron ahí? Fueron a ofrecer sus servicios a la empresa de diseño y fueron aceptados. También aportaron mucho entusiasmo y facilitaron incluso procesos en forma ad honorem. Están en tratativas con organizaciones piqueteras.

Diego propone la colaboración como una reconcepción de las ideas de cada uno por exponerlas a los demás.

¿Cómo implementar Scrum en el Servicio Penitenciario para hacer software?

Diego, los diseñadores gráficos que no quieren entregar versiones borrador, porque la primera impresión es muy fuerte. Es decir, se pueden tener procesos por incrementos, pero no tanto evolutivos.

Ariel, la diferencia puede estar en la menor complejidad, tal que no requiera incrementos, simplemente iteraciones donde el equipo es el resultado (Diego).

Grupos de 5 ingenieros electrónicos usando modelos iterativos (Juan).

¿Qué llevarles a los artistas? Tal vez el ritmo. Tal vez no sea lo mismo para estudiantes de arte que no tienen experiencia de trabajo en equipo.
Puede disminuir el nivel de estréss y ayudar a autoorganizarse.

El resultado fue muy positivo desde mi punto de vista, y creo que los alumnos también disfrutaron mucho la experiencia. Arranqué con una introducción a Scrum muy simple, y me resultó muy valioso recibir en la retrospectiva final muchos reflexiones enfocadas en el desarrollo de software, cosa que no siempre ocurre dado el estilo particular de la metáfora de trabajar con rastis. Tal vez tenga que ver con trabajar con un grupo de posgrado, de cualquier manera, una experiencia enriquecedora, como siempre.

Como siempre, la técnica de Open Space dio resultados excelentes, y el nivel de interacción entre la gente tanto en las sesiones como en los intervalos fue muy intenso y valioso. En particular, me resultó muy interesante la presencia de gente que no provenía del mundo del software, que terminó en un sesión que propuse sobre aplicaciones de metodologías ágiles en entornos distintos al desarrollo de software.

Nos llevamos todos, creo, el compromiso de seguir difundiendo tanto el tema del evento, como el formato, que comparten el foco en el valor de la gente.

Esperemos que sirva también para desarrollar la comunidad local a partir de este excelente resultado.

Nota: La semana próxima voy a estar agregando mis apuntes de la charla “Metodologías Agiles en proyectos que no son de software” y la presentación de la charla que presenté de “Arquitectura Agil”.
Presentación de la charla

No hay ninguna duda de que necesitamos una nueva visión del curriculum de las carreras de informática.

Por lo menos, a mi no me queda ninguna. En realidad, necesitamos una nueva visión como marco y muchos nuevos curricula para las distintas materias. No es posible quedarnos así tan tranquilos cuando encontramos que muchos docentes e instituciones siguen confundiendo cuestiones tecnológicas con conceptos centrales, o enseñando como normales prácticas que no son consideradas válidas por la comunidad académica o industrial desde hace más de 15 años. O cuando encontramos que los conceptos y herramientas se presentan con niveles de abstracción varios órdenes de magnitud por debajo del necesario para comprender la problemática real.

A pesar de lo dicho, no es sorprendente sin embargo que las cosas estén como estan. La gente tiende siempre a ser conservadora a menos que algún acontecimiento especial la sacuda. En nuestro caso, algunos de nosotros estamos aún esperando la plaga, o el meteorito, o la invasión extraterrestre que sería necesaria, pero nada. Nadie quiere cambiar. El que está mal, porque no quiere que la cosa empeore, y el que está bien, ni hablar. En fin, la cuestión es que seguimos haciendo las cosas como hace 15 años, en algunos casos, o como hace 25 años, en otros, pero de fondo pensamos en general como si viviéramos en una película de los ochenta. Es decir, antes de que existiera Internet.

Claro, trabajamos para que Internet sea lo que es, aportamos nuestro granito de arena para la construcción de la galaxia, pero seguimos pensando que lo importante es el granito de arena, que la galaxia al final apenas se ve de noche, y eso solamente si estamos en el campo. Necesitamos gente que sepa ver la galaxia. Y pasa lo que pase, tenemos que formarla.

La experiencia fue muy emocionante, los chicos y chicas se engancharon como siempre que se juega al Pajarraco, hicieron varias preguntas al principio y muy buenos comentarios al final. Para nosotros también fue muy satisfactorio, tanto el juego en sí como la recepción general entre los alumnos y docentes.

Me impactó mucho una cosa interesante que ocurrió el primer día de juego (5 min); Uno de los equipos había seleccionado 3 stories para implementar: Alas, Cabeza y Patas, creo. Cuando me acerco al grupo en mi rol de Product Owner, me dicen que ya terminaron y me muestran las 5 partes extendidas en la mesa. Rápidamente les aclaré que tenian que entregar un Pajarraco, no sus partes, y avanzaron con el ensamblaje. Es fantástico como el Pajarraco, y supongo que otros juegos de construcción con partes tangibles sirven para aprender sobre cómo producir software que aporte valor. Aunque no me guste la alegoría como figura, es genial ver como se plasman algunas cuestions que hacen a la calidad del software en el Pajarraco: integridad, robustez, integración, pruebas, etc.

En suma, una actividad para repetir, y seguir aprendiendo.

(1) El juego del Pajarraco fue inventado por Alan Cyment y está basado en el XP Velocity Game.