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.