Ante soluciones RESTRICCIONES

Ya que no parece haber una técnica, tendencia, disciplina… que de una solución a la gestión del desarrollo de software; lo que se puede hacer es dar otra perspectiva al asunto: “No te voy a decir cómo hacer las cosas, voy a ver qué haces para desarrollar el software y te diré que veo bien y que veo mal”.

Esta idea se puede seguir estrictamente como hacen técnicas como CMMI que (resumiendo) consiste en catalogar del 1 al 5 como se está planteando el proyecto de desarrollo de un software. O también se puede ser más constructivo como ITIL que más que catalogar la corrección de un proyecto trata de aportar buenas prácticas que se pueden seguir en un proyecto de desarrollo de software.

Seguimiento de Tareas

El seguimiento de las tareas es un gran problema. Al asignar una tarea a un desarrollador aparecen muchas incertidumbres:

• ¿Seguirá la arquitectura que estamos utilizando?
  
• ¿Controla bien la tecnología?
  
• ¿A tocado partes comunes? Y si lo ha hecho ¿ha comprobado el impacto?
  
• Al terminar, ¿lo ha probado lo suficiente?

Hay que hacer algo para que estas “incertidumbres” no se conviertan en una nube oscura que da la sensación de poco control. Esta nube seguro que crecerá al desarrollar mas y mas y al final la sensación general en el equipo de desarrollo será de que el proyecto está mal hecho.
Una forma de evitarlo es hacer un seguimiento completo de las tareas. Completo consiste en seguir las siguientes fases:

1º El responsable de la tarea debe especificar bien en qué consiste la tarea al desarrollador y asegurarse de que la comprende bien.

2º El desarrollador debe explicar brevemente como va a implementar la tarea. Esta explicación debe de ser muy práctica, hasta es recomendable que el desarrollador escriba algunas líneas de código para explicar al responsable como va a implementar la tarea.

3º Una vez terminada, el desarrollador debe escribir en el documento de “soluciones técnicas” como ha resuelto la tarea.

4º Una vez integrada la tarea en el sistema completo (o al menos en una parte que se pueda probar), el responsable debe indicar al responsable de pruebas (que debe de ser una persona distinta del desarrollador y del responsable de la tarea) que debe probar, como y que se entiende por correcto y por fallido.

Estudio de clientes. Indecisión

Un gran problema que presentan los clientes es que no saben lo que quieren. No solo me refiero al hecho de que no puedan expresar bien el producto que quieren, sino que cuando tienen el producto que definieron (o no definieron pero el desarrollador de software les hizo y ellos aprobaron) se dan cuenta al ponerlo en funcionamiento de que no cumple sus espectativas porque los usuarios finales no saben utilizarlos o les cuesta mucho hacerlo.

La definición global del software (su concepto general, su apariencia, su navegacionalidad, sus requerimientos de uso, etc..) no deberia definirlos ni el cliente ni el desarrollador si no un tercer participante en el proyecto que sea INDEPENDIENTE a ambas partes.

Mi SCRUM

SCRUM esta bien definido y es facil de aprender pero yo aplicaria algunas variantes.

En lo primero en que yo me centraria es en la arquitectura y en la forma de trabajar. Esto es crucial. Lo que haria seria definir una arquitectura lo mas compleja posible y una forma de trabajar lo mas restrictiva posible (1).

A medida que se vaya produciendo el desarrollo puede suceder que la arquitectura y/o la forma de trabajar sea muy rigida. Si esto sucede entonces podemos empezar a "relajar la forma de trabajar".

Ejemplo: Para desarrollar un proyecto se estableció desde el principio que diariamente cada miembro del equipo enviará un correo al responsable al final del día indicando que había hecho y además cada vez que se solucione una tarea se debe escribir en un “documento de soluciones técnicas” que tarea se resolvió y como se resolvió a muy bajo nivel técnico. El proyecto “se aprieta” y se ve claramente que se necesita agilizar la solución de tareas, además al equipo no le gusta el documento de soluciones técnicas. Una solución podría ser dejar de completar el documento de soluciones técnicas pero seguir con los correos. De esta experiencia se puede deducir que el documento no aplica para este proyecto pero tenemos dos ganancias: 1º El documento es un perfecto manual para un desarrollador que acaba de incorporarse al proyecto. 2º El equipo ve como normal enviar correos al final del día.

Hay una premisa que siempre hay que tener en cuenta: “Es más fácil introducir restricciones y pautas para el equipo de desarrollo al principio del proyecto que una vez que ya se ha empezado con el desarrollo”

La manera de establecer la duración de los sprints debe ser a partir de pruebas de desarrollo previas al desarrollo verdadero que establezcan unas medidas fiables de lo que se tarda en hacer el trabajo. Propongo lo siguiente:

1º Definir un subconjunto de muestra. El responsable coge una serie de requisitos que solucionan una parte del proyecto representativa e incluso que puede generar un entregable.

2º División de tareas. Se establecen tareas que son repartidas entre los distintos miembros del proyecto atendiendo a sus roles.

3º Realizar el trabajo y tomar muestras. Se realizan las tareas y se toma muestras del impacto temporal de todos los aspectos que se consideren relevantes:

• Tiempo de desarrollo
  
• Tiempo de gestión
  
• Integración de las distintas partes
  
• Comunicación en el equipo
  
• Etc..

Este proceso debe durar muy poco en relación con la duración establecida para el proyecto general. Con estas medidas ya se debe poder establecer una mejor división de tareas y una duración justa y equilibrada de cada tarea. Además, se conoce las prestaciones de cada uno de los miembros del equipo.



(1) Cuando digo posible me refiero a que tiene que ser lo mas complejo posible dentro de la suposicion de que todos los miembros del equipo puedan entenderlo o puedan llegar a entenderlo.

SCRUM. Que me gusta y que no

La mayoria de proyectos de desarrollo software (por no decir todos) no siguen ninguna tecnica, metodologia, convenio, ni nada que se pueda regir o ni medir o a lo que agarrarse. Eso implica que la mayoria de los desarrolladores estan acostumbrados a trabajar casi como "artistas". El software es una obra de arte y ya estará cuando este, y si no te gusta lo que tengo hasta el momento la culpa es tuya por no darme mas tiempo.

SCRUM es una metodologia para la gestión del desarrollo de software que intenta poner orden en un caos y de una manera simple. En general me gusta pero tiene varios problemas como:

• No plantea como diseñar la arquitectura y cual sera la forma de trabajar.
• Si un desarrollador esta acostumbrado a no tener metodologia entonces no parece muy lógico que no solo tenga que aceptar una ahora sino que encima se le pida resposabilidades por no tener su sprint a tiempo o con la calidad requerida.
• Esta bien suponer desde el prinicipio que los requerimientos van a ir cambiando y que puedes generar versiones rapidamente pero una cosa es suponer que van cambiar otra es suponer que no se conocen y se debe empezar con lo que mas o menos se tenga. Dile al cliente que puede cambiar los requerimientos cuando quiera y te hara hacer tantas versiones que al final no avanzaras nunca del primer requisito.

El tiempo de duración de los sprint “no se puede establecer a ojo” ni en debate entre miembros del equipo. Esta forma simple y rápida de establecer la duración desembocará seguro en una falta clamorosa de calidad en el trabajo realizado (tanto por parte del desarrollador como del responsable) y en crear en los responsables la tendencia de intentar “pillar” al desarrollador en que el trabajo no completo; cuando en realidad lo que está pasando es el proyecto está empezando a ir mal, se nota, se sabe pero NO SE SABE BIEN EL MOTIVO.

SCRUM. Interpretación

SCRUM es una metodología de gestión y seguimiento del proceso de desarrollo de software. Consiste en plantear el trabajo en tareas, llamas sprints, que tienen una duración concreta y son asignados a un desarrollador. Este desarrollador es el responsable de terminar el sprint a tiempo y de forma correcta. A medida que se van desarrollando sprints, el software va tomando forma y se cada ciero tiempo se puede ir generando entregas al cliente.

Existen 3 fases en la metodologia:

1. Inicio: Donde se plantea la arquitectura, la forma de trabajar y en función de estos factores el Scrum Master generá los sprints del proyecto.
2. Desarrollo: Se entrega los sprints a los desarrolladores para que los hagan.
3. Cierre: Generar un entregable.

Todas estas fases se suceden en este orden pero de forma no rígida, de tal manera que aunque se encuentre en la fase de desarrollo siempre se puede volver al inicio para redefinir la arquitectura y obtener nuevos sprints. De igual manera, en el cierre siempre se puede volver la desarrollo para hacer mas pruebas y eliminar bugs.

Paralelismo

La forma de apoyarme en otra disciplina no debe de ser buscando paralelismos con aspectos actuales de esa disciplina (o más bien, paralelismo con la interpretación subjetiva que hace un desarrollador con los aspectos actuales de esa disciplina) sino interpretando subjetivamente como fue la evolución desde la nada de esa disciplina hasta su estado actual que no conozco (no puedo hacer tengo una interpretación real) pero es evidente que es más madura que el estado de la disciplina de desarrollo de proyectos software que sí conozco.

Uso una interpretación subjetiva y no una histórica porque me interesa más mostrar como interpreto yo (un desarrollador) otra disciplina (la construcción de edificios) más que una recopilación histórica que se basará en la interpretación de otros profesionales (historiadores, arquitectos, empresarios, etc..)

La evolución de la construcción de edificios

El punto de partida de todo es la necesidad. ¿Qué necesidad tenían los seres humanos en construir edificios? Los motivos pueden ser varios:

• No habían suficientes cuevas (o donde sea que vivieran) para todos.Necesidad de resguardarse (mejor de donde sea que vivieran).
• Necesidad de intimidad.
• Poder decidir donde habitar. (Por ejemplo, puede que vivieran en cuevas pero les sería más útil vivir a 3 km de distancia donde está el agua)
• Decidir la estructura de su vivienda.
• Etc..

Ante la necesidad, los primeros individuos salen de su cueva y piensan: “Voy a construir una casa”. Lo primero seria coger cualquier cosa que tuvieran cerca y apilarla de tal manera que fuese “un motón de cosas apiladas” (piedras, madera, etc..) que tuvieran forma de cueva, que es lo que conocían. Tras repetir esta operación varias veces (más bien muchas veces y probablemente durante muchos años) los individuos se dan cuenta de cualquier cosa que encuentren no vale para construir una casa, se necesita un material que al producirlo se puede utilizar para construir la casa.

A partir de la deducción “Se necesitan primero materiales y luego se puede construir” se crean una serie de materiales que son útiles para la construcción y empiezan las innovaciones:

• Se crean los ladrillos, y al apilarlos se construyen las paredes.


• Se crea el cemento, y al ponerlo entre los ladrillos se consigue una pared solida.


• Se crean las vigas y se descubre que:
  


• Al ponerlas en la parte superior de la casa se puede construir el techo.


• Al ponerlas como apoyo de de las paredes, estas son mas solidas incluso se puede “crear dos pisos”.

Paralelismo . Una forma de evolucionar el desarrollo de proyectos

El punto de partida de todo es la necesidad. ¿Qué necesidad tenían los seres humanos en desarrollar software? Los motivos pueden ser varios:

• Poder ampliar el volumen de información. De poder tratar solo lo que cabía en los libros a poder tratar las "bibliotecas enteras" que caben en un ordenador.
• Poder compartir información en tiempo real (o casi real).
• Agilizar la gestión de cualquier faceta de cualquier negocio.
• Permitir el acceso a cuotas de mercado.
• Permitir el acceso fácil de cualquier persona a cualquier producto, tramite, evento, etc.. que necesite (desde comprar un coche por internet hasta hacer la declaración de la renta)
• Etc..

Ante la necesidad, los primeros desarrolladores piensan: “Voy a desarrollar un software que me sirva para algo práctico, como una calculadora”. Lo primero seria picar líneas de ensamblador (miles y miles) de tal manera que al ejecutar “ese primer programa ” el resultado fuera algo parecido a una suma o una multiplicación. Tras repetir esta operación varias veces (más bien muchas veces y probablemente durante muchos años) los individuos se dan cuenta de que no se puede hacer todo con ensamblador, se necesitan lenguajes de alto nivel.

A partir de la deducción “Se necesitan primero lenguajes de alto nivel y luego se puede desarrollar software” se crean una serie de lenguajes de alto nivel que son útiles para el desarrollo del software y empiezan las innovaciones:

• Se crean distintos lenguajes de alto nivel en los que un desarrollador puede crear aplicaciones para cualquier cosa.


• Se crean programas que crean entornos gráficos para otros programas y asi hacerlos más manejables.


• Se crean utilidades genéricas de todo tipo: procesadores de texto, hojas de cálculo, aplicaciones de tratamiento de imágenes, etc.

Una disciplina sin identidad

Es muy común comparar el desarrollo de una aplicación informática con la construcción de edificios y/o estructuras. Pero es interesante preguntar a un informático:

• Cuando fue la última vez que escuchaste a un arquitecto decir que plantear la construcción de una casa es como plantear el desarrollo de una aplicación web?
  
• Cuantos edificios y/o estructuras crees que se han levantado sin hacer caso o muy poco caso a los planos y en cuantos desarrollos de aplicaciones informáticas has participado en el que sigas estrictamente lo que dice el diseño?

Tras consultar a arquitectos de manera informal en foros de internet he obtenido dos conclusiones:

• Existen similitudes entre la construcción de edificios/estructuras y el desarrollo de aplicaciones como:
  o La necesidad de una planificación previa
  o Necesidad de un seguimiento constante del desarrollo
  o Obtención de un producto final
  o Etc..
  pero estas características las tiene también la aplicación de una nueva ley, crear un nuevo plato de cocina, preparar la temporada de liga de un equipo para obtener la copa de la liga, etc..
  
• Si tan parecido es el desarrollo software a la construcción de edificios/estructuras entonces un arquitecto debería ver similitudes claras con la informática pero de los arquitectos consultados se puede deducir que no tienen ni idea o muy poca idea de cómo se desarrolla una aplicación y son más propensos a comparar una casa con un programa que comparar unos planos a un diagrama UML.

Francamente, un desarrollador de software no tiene ni idea de arquitectura. Es tan fiable por parte de un informático decir que desarrollar una aplicación informática es como construir un edificio que decir que es como realizar una operación a corazón abierto.

Está bien que una disciplina nueva como el desarrollo de software (que en realidad tiene 30-40 años siendo generosos) se apoye en otras más maduras como la arquitectura (que tendrá miles de años) para definirse a si misma, pero ¿se ha perdido el norte?. No hay que olvidar que solo se ha de apoyar en otras disciplinas. Si no se empieza a pensar como desarrolladores nunca tendrá una verdadera identidad el desarrollo de software.