A leer de CMMI

CMMI es un conjunto de buenas practicas por lo que para comprenderlo bien lo primero es leer, leer y leer mas. La primera lectura es la documentación que proporciona el propio SEI.

1º Para la adquisición del producto.
2º Para el desarrollo de proucto.
3º Para los servicios que proporciona el producto.

La programación heroica

Esta metodología consiste en la ausencia total de planificación, seguimiento y autoridad en un proyecto de desarrollo software pero si mucha presión por parte de los responsables del proyecto para que las cosas salgan y se desarrollen las peticiones del cliente con prioridad total una vez que el cliente las comunica.

Al final el éxito o el fracaso del proyecto depende de la habilidad de los programadores y de su buen entendimiento.

Esta metodología, si se puede llamar así, da como resultado un proyecto completamente dividido en partes incomprensibles que hacen imposible su mantenimiento. Además, todos los miembros del equipo acaban quemadísimos.

¿A alguien le resulta familiar?

Debate. ¿SCRUM vale para todas las fases del proyecto?

Yo:
En mi humilde opinión, SCRUM es una buena metodología para el seguimiento y el desarrollo de software pero no es una metodología para empezar el proyecto. Se ha de implantar una vez ya se está en una etapa del desarrollado en el que se puede decir que se tiene una primera versión de la o las aplicaciones del proyecto.

Contertulio:
No entiendo porqué dices que no es una buena metodología para empezar el proyecto. Que sea una metodología ágil, que no se fomente el upfront design, etc, no quiere decir que empieces a codificar a lo loco sin pensar un poco. En muchos proyectos se hace la famosa iteración 0, en la que precisamente se piensa en todo esto. Lo que si que no se puede hacer es pasarte tres meses diseñando la aplicación.

Yo:
No quería decir hay que empezar a codificar sin más. SCRUM tiene una dinámica en la que cada sprint tiene valor por lo que ya es una ?release? de la aplicación o casi; por ese principio, si no tienes nada (acabas de empezar) ¿el primer y único spirnt debería ser el producto entero?.
Bueno, he sido un poco filósofo en el párrafo anterior. Perdón. Pero lo que quiero decir es que al empezar hay muchas tareas que en realidad no añaden valor directo como indica SCRUM por lo que la tendencia, en mi opinión claro, es amoldar SCRUM para poder hacer sprints que no tienen valor para el cliente, pero entonces ya no es SCRUM seria SCRUM versión beta 1.0.
Cuando digo amoldar me refiero a que si el sprint no genera una ?release? entonces genera una parte que habrá que integrar con otra parte que saldrá de otro sprint. No he visto nada en SCRUM que hable sobre cómo integrar partes. En este enlace esta mi opinión sobre subestimar los costes de integración
http://rumberomelo.blogspot.com/2010/12/la-excesiva-simplicidad.html

Contertulio:
Al finalizar cada sprint lo que entregas es producto potencialmente entregable, es decir, una o varias historias de usuario acabadas. Esto, obviamente, no quiere decir que esté todo lo que pide el cliente. En Scrum tienes una pila de producto y en cada sprint implementas lo que puedas por orden de prioridad. Por lo tanto, por ejemplo, en tu primer sprint podrias tener implementado el sistema de loguin de tu aplicación. Y esa história estará totalmente acabada, con sus tests de aceptación pasados, etc. El cliente la podrá evaluar y darla por buena o no. A partir de esto, se implementa otra(s) história(s) de usuario(s) que se integran con esta y que implementan otras cosas que requiere el usuario. No se implementan n historias en paralelo y después se integra, sinó justo al contrario, estás integrando continuamente.

Por otra part, es normal que Scrum no te hable de como integrar partes explicitamente. Scrum es un marco metodológico para la gestión del proyecto y se debe apoyar en buenas prácticas técnicas como la que se describen en XP. Si te fijas un poco en XP junto con Scrum, verás que la integración se hace continuamente, sprint a sprint, dia a dia, commit a commit.

Yo:
Siguiendo tú ejemplo. Supongamos que tenemos el modulo de login que estará totalmente acabado, se le presentará al cliente, le gusta y todo correcto. Otro sprint me va a dar el modulo de menú principal pero al empezar el desarrollarlo nos damos cuenta que tenemos que cambiar el modulo de login porque no se integran bien (modulo de login con modulo de menú principal) y el cambio es mejor hacerlo en el modulo de login. Por lo que tengo que parar el modulo de menú principal (sprint parado) y empezar un nuevo sprint que es modificación de modulo de login.
Me surgen varios problemas según he podido leer de SCRUM:
- No he visto como se tratan los sprint parados. ¿Cómo va eso? ¿Se para y se retoma desde donde se dejo?¿Se empieza de nuevo?
- Los sprint se generan siempre un día concreto de la semana o del mes, al tener que generarlos de urgencia se está rompiendo el ciclo normal de trabajo por lo que se asume un riesgo: ?como lo asimilará un cambio drástico en el ritmo de trabajo el equipo de desarrollo?.

SCRUM, como tú dices, intenta que si el cliente no puede ver la aplicación hecha que al menos vea algo que le guste; pero es que eso es imposible en una aplicación medio grande, hay demasiados factores y, además, en la mayoría de proyectos el cliente necesita una interfaz para ver el valor de la aplicación y esa interfaz puede que no exista porque no es parte de los requisitos.

SCRUM me parece buena metodologia pero cuando ya te has quitado de encima "los pequeños factores".

Contertulio:
Lo normal es que en la reunión de inicio de sprint, el equipo se dé cuenta que la nueva história que le pide el cliente requiere de la modificación de un elemento ya existente. No hay problema, se pone como tarea, se hace y listos. Que una história un dia determinado se dé por acabada no quiere decir que nunca más se toque lo que se ha implementado. Scrum abraza el cambio y lo vé como algo positivo, ya que acerca la aplicación a lo deseado por el cliente.

Por ejemplo, para empezar el cliente podría haber pedido una versión básica de login, y más adelante quiere añadir más funcionalidad. Cap problema, se hace y ya está.

Para para un sprint, se tiene que dar una cosa realmente excepcional, como por ejemplo una repriorización brutal a mitad de sprint. En general, no se rompen los sprints.

Yo:
El cambio al que me refiero no es una petición de cliente. Me refiero a que hay un problema de integración. Si, como creo que quieres decir, abrazo ese cambio en el login como una tarea del modulo de menú principal ¿no estoy perdiendo ese valor que se consigue al decir que con el primer sprint tengo algo con valor del que siempre podría partir?. Ten en cuenta que al desarrollar el modulo de menú principal te has dado cuenta que en verdad el modulo de login no es correcto pero para el cliente ya tiene valor porque lo ha visto.

¿No crees que SCRUM subestima el coste de codificación (cosa que no hace XP) e integración?

Y en otro orden de cosas, dar la posibilidad de asimilar en cualquier momento un requisito o modificación del cliente no sé si es buena idea. Teóricamente es perfecto, pero en la práctica puede que tu proyecto fuera para construir un coche y terminar con un avión.

Contertulio:
Empezemos por la primera. En un proyecto gestionado con Scrum, en cada sprint tenemos que tener implementado aquello que dá más valor al cliente. El cliente decidió que el loguin tal como lo definió aquel dia era lo más importante para él. Si n sprints después resulta que hay que modificarlo un poco para adaptarlo a otra historia, no pasa nada. Una história acabada es una história acabada para ese sprint. Si después se tiene que crear otra história que modifique la codificación de la primera, es que tiene mucho valor por el cliente y él estará encantado que la modifiques. Recuerda que el cliente en Scrum ve la aplicación al final de cada sprint, y la tiene que ver toda, no sólo lo nuevo. Por tanto, para él la nueva história tiene valor, y mucho.

Lo segundo. Scrum no subestima el coste de codificación. Recuerda que quien estima en Scrum es el equipo, és decir, quien lo va a codificar todo y a quien se va a exigir tener el producto funcionando a final de sprint, con lo que ya se cuidará de estimar todos los detalles que comporte la programación de la tarea.

Tercero, si acabas hacieno un avión, es que en el fondo el cliente queria hacer un avión y a principio de proyecto no lo sabía. Por eso es muy bueno no hacer un gran upfront design suponiendo que el tio queria hacer un coche pq vamos a sufrir mucho. Si vamos implementando história a história, poco a poco y nos vamos adaptando poco a poco a los cambios del cliente, esta transición será mucho más llevadera.

Yo:
Si teóricamente no te quito razón. Pero en la práctica, desde el punto de vista de estar allí en el proyecto, veo tantas cosas que no van a ser así. Las estimaciones hechas por el equipo teóricamente deben ser exactas (es la gente que lo va a implementar) pero en la práctica... ¿me vas a decir que TODOS los programadores asimilan y aceptan las pautas marcadas para el desarrollo y van a seguir el diseño?.

Lo del símil del avión no lo he concretado bien, quería decir ?puede que tu proyecto fuera para construir un coche y terminar con un avión. Y te han pagado por un coche?.

Respecto a modificar el login, dices: ?Si después se tiene que crear otra história que modifique la codificación de la primera, es que tiene mucho valor por el cliente y él estará encantado que la modifiques?. Él estará encantado si te ha pedido una modificación. Pero la modificación no te la ha pedido él, en el ejemplo quería decir que, al desarrollar, el equipo se ha dado cuenta que hay que modificarlo por lo que el cliente seguramente te dirá:?¿Pero eso no estaba ya??

Contertulio:
Las estimaciones son, por definición, inexactas. Eso si, serán mucho más exactas las que haga el equipo después de una buena reflexión en la reunión de inicio de sprint que no la de un analista o jefe de proyecto que haga al vuelo.

Que todos los programadores asimilen y acepten las pautas marcadas para el desarrollo y sigan el diseño, es tan ""fácil"" como hacer unas buenas revisiones de código a final del sprint.

El tema de la presupuestación es otro tema aparte. Si haces Scrum con proyectos de presupuesto cerrado, tendrás que empezar a negociar con él cliente. Si él pidió un coche y ahora te pide un avión, pués o lo quitas features a implementar del avión, o le cobras más. Pero este problema lo tendrás con Scrum y con todas las metodologías. Aunque bien gestionado, con Scrum lo harás mucho mejor :D

Y lo tercero, todo es comunicación. Esto se habla en la reunión de inicio de sprint. El cliente te cuenta lo que quiere hacer, tu le cuentas las implicaciones y él decide si tirar para adelante o no. La comunicación entre el equipo y el cliente ( o el Prodcut Owner ) es vital.

Reglas de XP

Una pagina donde se puede encontrar las reglas a seguir en cada aspecto de un proyecto software según la programación extrema (XP).

http://www.extremeprogramming.org/rules.html

La excesiva simplicidad

Una creencia muy arraigada en todas las metodologías (XP, SCRUM, RUP, etc..) es pensar que al SIMPLIFICAR una tarea siempre se obtiene valor y se minimizan riesgos. Es decir, si hay que hacer una tarea entonces mejor hacer dos más sencillas o si hay que hacer un algoritmo mejor dividirlo en trozos.
Es obvio que es mejor hacer dos tareas que cuesten “20” que una que cueste “40” si tengo dos miembros de mi equipo que pueden llevar a cabo una tarea, además que es mejor asumir el riesgo de dos procesos que de uno ya que si tengo dos procesos y falla uno entonces el proceso total esta al 50% pero si solo tengo una tarea y ha fallado entonces el proceso total esta al 0%. Pero al pensar en la simplificación de una tarea, en dividirla, siempre se olvidan dos cosas o no se les da el impacto real que tienen:

• Integración: Si divides una tarea en subtareas luego hay que integrarlas para obtener la funcionalidad deseada y en muchos casos los costes de integración superan con creces la mejora que se consiguió al dividir la tarea.


• Penalización en rendimiento: La integración puede ser sencilla debido a que las fronteras entre subtareas esta clara y es muy flexible pero en cualquier aplicación medio compleja tanta modularidad y flexibilidad de comunicación suele traducir en que a la hora de probar la aplicación esta tiene un rendimiento pésimo.

Entorno de pruebas para aplicaciones JAVA

Se tienen que hacer siempre pruebas de caja negra y de caja blanca.

Las pruebas de caja negra deben estar definidas por los analistas. Los analistas pueden definir las pruebas a su elección pero es responsabilidad del jefe de proyecto decidir si se cubren todos los aspectos necesarios y para ello es IMPRESCINDIBLE mirar algo de código y ejecutarlo. Las pruebas de caja negra se pueden definir como se crea más oportuna pero debe cumplir que al compilar una versión TODAS las pruebas de testeo de la aplicación deben de ser correctas, utilidades como MAVEN ofrecen esa posibilidad. Las pruebas se pueden definir a 3 niveles:

• Interfaz: Son pruebas a los accesos de los usuario a la aplicación. Requieren que la aplicación este funcionando.


• Lógica: Son pruebas sobre clases a las que accede la interfaz y tiene significado dentro del contexto de la aplicación. No requieren que la aplicación este funcionando.


• Servicios: Son pruebas sobre clases a las que accede la lógica y son unidades de trabajo que al combinar de una manera (llamadas desde clases de lógica) tiene significado dentro del contexto de la aplicación. No requieren que la aplicación este funcionando.

Las pruebas de caja blanca las puede definir un analista o el jefe de proyecto pero es muy importante que sea el miembro del equipo encargado de enseñar la aplicación al cliente. Los miembro del equipo responsable de ejecutar las pruebas deben de tener los suficientes conocimientos técnicos y de la aplicación para comprobar que las pruebas se realizan correctamente, es decir no basta con darle un botón y ver que la pantalla dice OK si, por ejemplo, es una operación de alta de cliente entonces hay que ver que en base de datos esta el cliente. La forma de definir las pruebas es muy subjetiva pero deben cumplir que sea CLARO y SIN LUGAR A DUDAS que cubren todos los casos de uso.

Una ayuda con SCRUM

En esta página podéis encontrar un libro en castellano sobre SCRUM gracias a Juan Palacio.

http://www.safecreative.org/work/0710210187520

El gran fallo

El gran fallo de la gestión de proyectos consiste en tratar el desarrollo como algo “terciario”. Todas las metodologías para exponer, gestionar, seguir y mantener un software que yo conozco se centran más en problemas de alto nivel como:

• Como absorber los requerimientos del cliente.


• Como dividir el trabajo en tareas.


• Como presentar “release” de la aplicación.


• Que documentación aportar.


• Como absorber cambios cuando ya ha empezado el proyecto.


• Etc..

No quiero decir que estos temas no sean importantes. SON MUY IMPORTANTES pero AUN ES MAS IMPORTANTE EL DESARROLLO DEL SOFTWARE. Por lo que si al planificar se tarda más en planificar, por ejemplo, como son los casos de uso que en planificar como se va a implementar las partes de la aplicación que hacen posible ese caso de uso entonces ya estamos cometiendo un fallo.

Una excepción es la programación extrema (XP) que si indica claramente la pautas para la codificación y el testeo.

RUP ¿Cuál es el fallo?

La metodología RUP para el desarrollo de software es el gran padre de todas las metodologías que se siguen en todos los proyectos comerciales. En realidad se intenta utilizar RUP para el desarrollo de software pero al final la degradación de esta metodología es tal que el equipo siempre llega a esa sensación de que el proyecto no tiene rumbo.

Es entonces cuando ya no es metodología RUP, es una especie de “RUP v1” o “RUP v1.3”. Lo curioso es que cuando se analizan estas “derivadas de RUP“, te das cuenta de que potencian todas las carencias de RUP y las virtudes desaparecen.

El gran fallo de RUP es que es demasiado teórico (UML, diagramas, documentación para esto, documentación para lo otro), genérico y se trata el desarrollo como un paso más (por no decir que lo trata como un apartado dentro de un paso más). Este último problema es el más grave porque, al final, el desarrollo y todo lo que conlleva (diseño, implementación, pruebas, seguimiento) es en lo que se gasta la inmensa mayoría del tiempo del proyecto.

Competencia

Al principio de un proyecto hay tiempo, hay dinero, hay gente, hay buenas intenciones, hay planes para un desarrollo correcto pero los proyectos se van degenerando con el tiempo y no solo desaparecen todos estos factores sino que aparecen preguntas como “¿Cómo se ha liado esto?”, “¿En que hemos fallado?”, “¿Como seguimos?”.

Para evitar la degeneración de un proyecto un factor clave es la competencia. La competencia es la funcionalidad de un individuo dentro de un grupo de trabajo. Para asegurarse que cada individuo comprende y sigue su competencia hay que:

• Definir que categorías estratifican a todos los miembros del proyecto y las competencias de cada categoría.


• Asegurarse de que toda categoría superior tiene que tener una impresión empírica de las categorías inferiores.

Supongamos el siguiente ejemplo, tenemos un proyecto donde definimos las categorías de jefe, analista y programador.
1º Definir que hace cada categoría:

• Jefe:
  
  • Relación con el cliente
• Seguimiento de los hitos
  
• Analista:
• Traducir hitos en tareas
• Agrupar el software desarrollado en cada tarea para obtener el producto final
  
• Programador:
• Implementar tareas

2 º Supervisión:

• Jefe:
• El código tiene la calidad deseada
• El código realiza la funcionalidad deseada
• La división en tareas es correcta
• La integración es correcta
  
• Analista:
• El código tiene la calidad deseada
• El código realiza la funcionalidad deseada
  
• Programador:
  
  • Nada

Necesidad de jerarquía

Siempre se han de establecer eslabones en la cadena de mando de un proyecto. El jefe tiene que tener la visión global del proyecto, la que tiene el cliente y además siempre está bien que revise el código, los equipos de desarrollo, haga pruebas, etc.. para tener un contacto más directo con el desarrollo y sacar sus propias conclusiones. Pero a la hora de evaluar resultados y repartir trabajo solo debe hablar con los analistas que están por debajo inmediatamente de él; y estos con los programadores que están por debajo. Si el jefe habla directamente con un programador es un síntoma de que algo está fallando.

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.