La Nueva Metodología

No es fácil ejecutar un proceso adaptable. En particular requiere un equipo muy eficaz de desarrolladores. El equipo necesita ser eficaz tanto en la calidad de los individuos como en la manera en que funcionan juntos en equipo. Hay también una sinergia interesante: no sólo la adaptabilidad requiere un equipo fuerte, la mayoría de los buenos desarrolladores prefieren un proceso adaptable.

. Juntar Unidades de Programación Compatibles

Uno de los objetivos de las metodologías tradicionales es desarrollar un proceso donde las personas involucradas sean partes reemplazables. Con tal proceso se puede tratar a las personas como recursos que están disponibles en varios tipos. Se tienen un analista, algunos programadores, algunos verificadores, un gerente. Los individuos no son tan importantes, sólo los roles lo son. De esa manera si usted planea un proyecto no importa qué analista y qué verificadores consiga, sólo hay que saber cuántos son para saber cómo afecta su plan el número de recursos.

Pero esto plantea una pregunta clave: ¿son las personas involucradas en el desarrollo de software partes reemplazables? Uno de los rasgos importantes de los métodos ágiles es el rechazo a esta afirmación.

Quizás el rechazo más explícito a las personas como recursos lo hace Alistair Cockburn. En su artículo Caracterización de las Personas como Componentes No Lineales de Primer Orden en el Desarrollo de Software, apunta a que los procesos predecibles requieren componentes que se comporten de manera predecible. Sin embargo las personas no son componentes predecibles. Además sus estudios de proyectos de software lo han llevado a concluir que la gente es el factor más importante en el desarrollo de software.

En el título, [de su artículo] me refiero a las personas como "componentes". Así es como se trata a la gente en la literatura de diseño de procesos / metodologías. El error de este enfoque es que las "personas" son altamente inconstantes y no lineales, con modos únicos de éxito y fracaso. Esos factores son de primer orden, factores no despreciables. El fracaso de los diseñadores de procesos y metodologías para responder a esto contribuye a la clase de trayectorias de proyectos no planeados que vemos a menudo.
[Cockburn, non-linear]

Uno se pregunta si la naturaleza del desarrollo de software funciona contra uno aquí. Cuando programamos una computadora, controlamos un dispositivo inherentemente predecible. Como estamos en este negocio porque somos buenos en hacerlo, estamos idealmente hechos para perturbarnos cuando nos enfrentamos con seres humanos.

Aunque Cockburn es el más explícito en su visión centrada en la gente del desarrollo de software, la noción de que la gente es primero es un tema común para muchos pensadores del software. El problema, demasiado a menudo, es que la metodología se ha opuesto a la noción de las personas como el factor de primer orden en el éxito del proyecto.

Esto crea un fuerte efecto de retroalimentación positiva. Si usted espera que todos sus desarrolladores se junten en unidades de programación compatibles, no intentará tratarlos como individuos. Esto baja la moral (y la productividad). Las personas capaces se buscarán un lugar mejor donde estar, y usted acabará con lo que usted deseaba: unidades de programación compatibles.

Decidir que las personas son primero es una gran decisión, que requiere mucha determinación. La noción de la gente como recursos es profundamente inculcado en el pensamiento de negocios, teniendo sus raíces en el impacto del enfoque de La Dirección Científica de Frederick Taylor. En la administración de una fábrica, este enfoque Taylorista tiene sentido. Pero para un trabajo altamente creativo y profesional, como creo es el desarrollo de software, esto no se sostiene. (Y de hecho la fabricación moderna también se está saliendo del modelo Taylorista.)

. Los Programadores son Profesionales Responsables

Una parte clave de la noción Taylorista es que la gente que hace el trabajo no es la mejor gente para entender la mejor manera de hacer el trabajo. En una fábrica esto puede ser verdad por varias razones. En parte porque la mayoría de los obreros no son las personas más inteligentes o creativas, en parte porque hay una tensión entre la gerencia y los obreros en que la gerencia gana más dinero y los obreros menos.

La historia reciente nos demuestra cada vez más lo falso que es esto en el desarrollo de software. A las personas brillantes y capaces les atrae cada vez más el desarrollo de software, tanto por su ostentación como por ganancias potencialmente mayores. (Ambas razones me tentaron a salir de la ingeniería electrónica.) Cosas tales como opciones accionarias afirman el interés de los programadores en la compañía.

(Aquí bien puede haber un efecto generacional. Una evidencia anecdótica me hace preguntarme si más gente brillante se han aventurado en el desarrollo de software en los últimos diez años. En ese caso ésta sería una razón para ese culto a la juventud en el negocio de la computación, como en la mayoría de los cultos se necesita un grano de verdad en él.)

Cuando se quiere contratar y retener a gente capaz, hay que reconocer que son profesionales competentes. Como tales son los mejores para decidir cómo dirigir su trabajo técnico. La noción Taylorista de un departamento de planificación separado que decide cómo hacer las cosas sólo funciona si los planificadores entienden mejor cómo hacer bien el trabajo que aquéllos que lo hacen. Si usted tiene personas brillantes, motivadas que hacen bien el trabajo entonces eso no se sostiene.

. Manejando un Proceso Orientado a la Gente

La orientación a la gente se manifiesta de varias maneras diferentes en los procesos ágiles, lo que lleva a efectos diferentes, no todos consistentes.

Uno de los elementos clave es la aceptación de un proceso en lugar de la imposición de un proceso. A menudo los procesos de software se imponen desde la gerencia. Como tales se les resiste a menudo, particularmente cuando la gerencia ha estado fuera del desarrollo activo un buen tiempo. Aceptar un proceso requiere compromiso, y como tal se necesita el involucramiento activo de todo el equipo.

Esto termina con el resultado interesante de que sólo los desarrolladores puede escoger seguir un proceso adaptable. Esto es particularmente cierto para la XP, que requiere mucha disciplina para ejecutarse. Aquí es donde Cristal es un complemento efectivo ya que apunta a una disciplina mínima.

Otro punto es que los desarrolladores deben poder tomar todas las decisiones técnicas. XP llega al corazón de esto cuando en su proceso de planeación establece que sólo los desarrolladores pueden estimar cuánto tiempo tomará hacer un trabajo.

Tal liderazgo técnico es un gran cambio para muchas personas en posiciones gerenciales. Tal acercamiento requiere compartir una responsabilidad donde desarrolladores y gerencia tienen un mismo lugar en la dirección del proyecto. Nótese que dije igual. La gerencia aun juega un papel, pero reconoce la pericia de los desarrolladores.

Una razón importante para esto es el ritmo del cambio de tecnología en nuestra industria. Después de unos años el conocimiento técnico se vuelve obsoleto. Esta vida media de habilidades técnicas no tiene parangón en cualquier otra industria. Incluso los técnicos tienen que reconocer que entrar a la gerencia significa que sus habilidades técnicas se marchitarán rápidamente. Los exdesarrolladores necesitan reconocer que sus habilidades técnicas desaparecerán rápidamente y necesitan confiar y depender en los desarrolladores actuales.

. La Dificultad de Medir

Si usted tiene un proceso dónde las personas que dicen cómo hacer el trabajo son distintas de las personas que realmente lo hacen, los líderes necesitan alguna manera de medir cuán eficaces son los que lo hacen. En la Dirección Científica había un impulso fuerte a desarrollar formas objectivas de medir el rendimiento de las personas.

Esto es particularmente pertinente al software debido a la dificultad de aplicar medidas al software. A pesar de nuestros mejores esfuerzos somos incapaces de medir las cosas más simples sobre el software, como la productividad. Sin buenas medidas para estas cosas, cualquier clase de control externo está condenado.

La introducción de gestión medida sin buenas medidas tiene sus propios problemas. Robert Austin hizo una discusión excelente sobre esto. Él señala que cuando se mide el rendimiento usted tienen que conseguir todos los factores importantes bajo medida. Cualquier cosa que se olvide tiene el resultado inevitable que los hacedores alterarán lo que hacen para producir las mejores medidas, incluso si eso claramente reduce la verdadera efectividad de lo que hacen. Este trastorno de la medida es el talón de Aquiles de la gestión basada en medidas.

La conclusión de Austin es que usted tiene que escoger entre la gestión basada en métricas y la gestión delegatoria (donde los hacedores deciden cómo hacer el trabajo). La gestión basada en métricas es más adecuada para el trabajo simple repetitivo, con bajos requisitos de conocimiento y rendimientos fácilmente medibles - exactamente lo contrario al desarrollo de software.

El punto de todo esto es que los métodos tradicionales han operado bajo la asunción de que la gestión basada en métricas es la manera más eficaz de administrar. La comunidad ágil reconoce que las características del desarrollo de software son tales que la gestión basada en métricas lleva el trastorno de la medida a niveles muy altos. Es realmente más eficaz usar un estilo delegatorio de administración, que es el tipo de acercamiento central del punto de vista agilista.

. El Papel del Liderazgo de Negocio

Pero los técnicos no pueden hacer el proceso entero ellos solos. Necesitan una guía en las necesidades comerciales. Esto lleva a otro aspecto importante de los procesos adaptables: necesitan un contacto muy íntimo con los expertos del negocio.

Esto va más allá del compromiso de negocios en la mayoría de los proyectos. Los equipos ágiles no pueden existir con una comunicación ocasional. Necesitan un acceso continuo a los expertos del negocio. Además este acceso no es algo que se maneje a nivel gerencial, es algo que está presente para cada desarrollador. Como los desarrolladores son profesionales capaces en su propia disciplina, necesitan poder trabajar como iguales con otros profesionales de otras disciplinas.

Gran parte de esto, claro está, se debe a la naturaleza del desarrollo adaptable. Como la premisa entera del desarrollo adaptable es que las cosas cambian rápidamente, se necesita un contacto constante para avisar a todos de los cambios.

No hay nada más frustrante para un desarrollador que ver desperdiciarse su duro trabajo. Así que es importante asegurar que hay pericia de negocios de buena calidad que está disponible al desarrollador y de calidad suficiente para que el desarrollador pueda confiar en ella.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
ARTÍCULO ANTERIOR

SIGUIENTE ARTÍCULO

¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.