path to agility 2012Para asistir en diferido a las sesiones sobre agilidad de la conferencia  "The Path to Agility 2012" que se celebró en mayo de este año organizada por The Central Ohio Agile Association: "Craftsmanship", "Clean Architecture and Design", "Reality in Software Development", "Scrum and Continuous Improvement", "Driving Real Business Value Thrugh Agile", etc.

  

Craftsmanship
Chet Hendrickson & Ron Jeffries
Clean Architecture and Design
Robert C Martin (Uncle Bob)

 

desenfocadoVanidad, culto al método o la tecnología, y aislamiento del cliente son actitudes que restan valor profesional a los programadores(1).

Vanidad.

Cuando importa más ser conocido y relevante en las redes sociales que diseñar y construir software para solucionar problemas... se está perdiendo el foco y valor profesional. Se puede estar mejorando la apariencia, pero cada vez será más sólo apariencia.

Por supuesto que hay quien no cae en la vanidad, sino que ha nacido con ella porque no tiene otra cosa que exhibir, pero este no es el caso de los buenos programadores ;-)  que al ver tanta actividad social de otros programadores, entran en el juego por conformidad con su grupo social profesional, o hartos ya de leer ramplonerías.

tres actitudes que minan buenos programadores

 

Culto al método o a la técnica.

Cuando el objetivo profesional pasa de diseñar y construir software para solucionar problemas a ser un experto practicante del métdodo para cumplirlo ortodoxamente, y además cumplir con el "método bueno", y no con los otros que son peores (sea CMMI o Scrum o TDD o Kanban o XP o Scrumdoro o Scrumban o...)

Cuando se defiende (o critica) fanáticamente Java o C# o PHP o Ruby o...

También estamos perdiendo el foco y autolimitándonos, dando más valor (y responsabilidad del resultado) al método que a la persona (a nosotros). 

Aislamiento del cliente.

Cuando uno no está para hablar con  aguantar al cliente y cree que para eso están los comerciales, o los gestores de proyectos, porque los clientes no saben lo que quieren y siempre están pidiendo la última ocurrencia para mañana.

Uno puede valer para programar, pero en factorías de software; no en equipos capaces de trabajar con el cliente para conocer su visión como él mismo y diseñar la mejor solución. 

 

(1) De producción artesanal de software, no ingenieros u operarios de producción industrial de software.

trioEl éxito de los proyectos TIC depende mucho más de la capacidad e interacción de los miembros del equipo, que de las prácticas y la teoría sobre gestión de proyectos. En este tipo de proyectos los buenos gestores no son tanto los expertos en técnicas de planificación, gestión de riesgos, contingencias etc, sino los que son capaces de aunar al equipo adecuado y ayudarle a sacar lo mejor de todos sus miembros.
Este artículo está inspirado en los tres tipos de personalidades que se combinan en cada programador,  identificados por Clark A. Campbell y descritos en el capítulo 3 de su libro "The One-page Project Manager for IT Projects" de Clark A. Campbell.
Tras años de experiencia y muchos proyectos gestionados he reflexionado mucho sobre los distintos patrones de personalidad que encuentras en los miembros de cada equipo, y he llegado a la conclusión de que hay tres tipos diferentes. Es habitual que las personas presenten uno de forma muy acusada, o una combinación de dos.

 tipos personalidad

craig larman"La principal recomendación para elegir un proveedor externo de programación ágil es no prestar atención a lo que digan sobre la calidad de su personal, o su nivel de certificación CMMI. Todo eso es sólo 'bla bla bla´. Mira su código"

 

 

Craig Larman en esta entrevista (Durante el pasado QCon 2011).

(the first think that I recommend when you choose an outsourcing partner for an agile engagement is pay no attention what the sales people in the outsourcing group say about the quality of the people, pay no attention to the claims of the CMMI certification level. That all is "bla bla bla". Look at their code.)

NDC2012Para asistir en diferido a las 20 sesiones sobre agilidad del NDC 2012: "Advanced Agile Planning, Programmer Anarchy, Scaling Agile Teams, What is a Self-Organizing Team? etc.

 

 

Developpers: The Prima Donnas of the 21st Century
Hadi Hariri
Agile, Lean and the Space Between
Barry Hawkins

 

dibujandoHace poco más de 10 años teníamos que documentar los requisitos con un ConOps, un SRS... Volvernos locos con una matriz de trazabilidad, validarlos, verificarlos... y a lo mejor todo eso para hacer la página web de una ferretería. Era duro. No sabíamos si era necesario, y si el proyecto en lugar se salir mal saldría desastroso si no lo hacíamos; pero si lo hacíamos podíamos conseguir la medalla CMMI :-P

Hoy el mantra son el epic y la historia de usuario. Lo mismo para el web de la ferretería que para el sistema de software de un reactor nuclear. Para un equipo de 3 que de 30, en la misma oficina o en oficinas distintas :-P

  

 

 

Safe Creative #1208182136343

asombroCMMI y PMI (organizaciones sin ánimo de lucro) están dando un volantazo hacia la agilidad que cuestiona cuál es su misión: el negocio de la consultoría o la difusión y mejora del conocimiento profesional de ingeniería de procesos y dirección de proyectos, respectivamente.

Este vender también respuesta a la demanda de agilidad y olvido de lo mucho que podrían deberían aportar en la evolución de la ingeniería secuencial (cascada) a la ingeniería concurrente, y su aplicación en proyectos TIC, nos deja, como afirma Sandra Valle, sin referentes de información para las empresas TIC que quieren evolucionar de la ingeniería secuencial a la ingeniería concurrente, y no a la agilidad; y además nos confunde con los papers "mezcla-todo" con los que justificar porqué antes eran digo y ahora Diego.

"Aunque muchas empresas ya han adoptado la ingeniería concurrente con éxito, logrando construir una ventaja competitiva al ser capaces de desarrollar nuevos productos bajo condiciones particularmente buenas en términos de tiempo de desarrollo y coste, otras tienen grandes dificultades para hacerlo.
Las barreras a la puesta en práctica de la ingeniería concurrente parecen proceder de dos frentes principales: por un lado, la resistencia natural de la organización a cambiar y, por otro, la falta de información disponible para asistir la puesta en práctica de ese cambio (Brookes y Backhouse, 1998)." 
(Valle Álvarez, S. Uso de ingeniería concurrente como metodología de puesta en práctica del proceso de desarrollo de nuevos productos)

pmi cmmi cambian de principios 600

 

 

Artículos relacionados:

Safe Creative #1207181990376