Saber estar

En ocasiones he visto como un jefe de proyecto pregunta a todos los programadores: “tu parte ¿ya esta?” y cada programador decir:”si”. Vuelve al día siguiente, muy cabreado, los reúne a todos y les dice: “Ayer me dijisteis todos que habíais terminado. Por la tarde le enseñe la aplicación al cliente y ni arrancaba”.

Otros casos que he visto es de proyectos donde hay una jerarquía perfectamente definida por puestos. Hay jefe, responsable, comercial, arquitecto, analista técnico, analista funcional, desarrolladores, técnicos de sistema, etc.. Todo un bosque de títulos. Pero el proyecto falla y es que cuando falla la aplicación el jefe de proyecto va a por el analista técnico que dice que ha hecho lo que le pidió el analista funcional. El analista funcional dice que fue esta bien en los casos de uso y el analista técnico lo interpreto mal. El analista técnico dice que cierto que está mal en los casos de uso. El jefe los reúne y en la reunión no queda nada claro y se decide consultar con un programador que conoce a más bajo nivel el problema. El jefe llama al programador …. Y podría seguir… (¿A que te suena este lio?)

Para cada proyecto (todo depende de las características del proyecto) necesitare situar una persona para esto y otro para aquello. Me debe dar igual que sea analista, arquitecto, responsable de cliente, … como si es un conde.

Si quiero saber si el desarrollo está listo y no me sirve la respuesta de un programador entonces colocare a un responsable de que todo esté bien. Le diré que es exactamente lo que quiero y que cada vez que le pregunte:”ya están todas las partes” entonces el me diga:”si”, o “falta esto”.

No le digas a un miembro de proyecto que cargo es porque sino el va a hacer lo que cree que se ajusta a su rol. Dile lo que quieres que haga y sobre todo de lo que es responsable.

YAGNI

La programación extrema, y en general todos los métodos ágiles, sugieren que si algo no lo vas a utilizar no lo piques. Es decir, por ejemplo si se solicita una aplicación Java que sea una calculadora que sume y reste y todas las operaciones están en la clase Funciones.java entonces no se ha de implementar una función “multiplicar” en la clase Funciones.java porque no se ha pedido. Si en un futuro se necesita o lo solicita el cliente entonces ya se picara.

Esta filosofía se extrapola a componentes y frameworks. Se da a entender que al desarrollar componentes y frameworks se desarrolla más funcionalidad de la que se necesita.

Estoy de acuerdo que en algo tan simple como una “función“ no merece la pena y así se ahorra tiempo y dinero pero en algo como tan genérico como componentes y frameworks no lo estoy. El uso de componentes y frameworks, si se hacen correctamente, puede orientar la forma de programar y hacer más parecido el código de los distintos programadores que lo usen (mas mantenible) y orientado correctamente (evita que “lo mejor que le parezca al programador en ese momento” no sea la tónica de la programación). Lo que hay que hacer es que si realmente se quiere apostar por el uso de componentes y frameworks hay que molestarse un poco en leer la documentación asociada, seguir la guía de los desarrolladores, etc… Es decir, si se va a utilizar componentes y frameworks hay que hacerlo bien, siguiendo las recomendaciones de los fabricantes y leyendo documentación y no cogiendo el componentes o frameworks de cualquier manera y cuando no se comporta como se espera decir: “Este frameworks es una mierda ” (te suena, ¿verdad?)

A base de ejemplos

La mayoría de veces cuando se le pide a un programador, arquitecto, responsable, etc.. que resuelva un problema técnico lo primero que se hacer es ir a Google y buscar un ejemplo. Esta práctica es como “un secreto de familia” (nadie quiere menciona que se resuelve de esta manera pero todo el mundo lo hace) y no debería ser así, buscar ejemplos por Internet y customizarlos a las necesidades de un proyecto es una forma como cualquier otra de empaparse del conocimiento de una tecnología que tienen otros. Además, este conocimiento está adaptado a las necesidades reales del mercado ya que los ejemplos son soluciones a problemas que una persona se encontró en su día y ha compartido como lo solucionó. No es que los manuales estén mal pero no se ajustan al día a día de un desarrollo de software.

Por lo que si rompemos las “barreras morales” porque no inventar una técnica de diseño nuevo “DISEÑO BASADO EN EJEMPLOS”.

La técnica es sencilla:
1 º Ante un requerimiento buscar una serie de ejemplos.

2º Para cada ejemplo buscado seleccionar uno basándonos en:

• El ejemplo que se ajuste mejor al problema.
  
• El ejemplo que se compatibilice mejor con lo que ya esta implementado.
  
• El ejemplo que mejor se lleve con la infraestructura software.
  
• El ejemplo que requiera menos esfuerzo para su aprendizaje.
  
• El ejemplo que ofrezca un mejor rendimiento.
  
• El ejemplo que ofrezca un menor riesgo.

3º Si un ejemplo es solución entonces lo integramos en el software. Si varios ejemplos son solución por igual o ninguno lo es pero se acercan mucho entonces se puede optar por fusionar ejemplos y obtener un Ejemplo Compuesto que de la solución.

4º Si quedan requerimientos entonces volver al paso 1.

Ayuda con tecnologías JAVA y para propuestas.

Si teneis que desarrollar un proyecto con tecnologias Java o simplemente teneis que elaborar una propuesta para un cliente os recomiendo la pagina
http://java-source.net. Contiene una clasificación muy completa de los Frameworks que hay y que van apareciendo en el mundo para cualquier aspecto que se pueda resolver con Java.

Una ayuda con TDD

En esta página podéis encontrar un libro en castellano sobre TDD gracias a Carlos Bl´e Jurado.

http://www.dirigidoportests.com/el-libro

Integración continua con Hudson

La integración continua consiste en automatizar el proceso de supervisión de código, pruebas y despliegue de aplicaciones.

Hay aplicaciones como Hudson te permiten aplicar la integración continua en un proyecto. Esta aplicación se baja periódicamente el código del repositorio, lo compila, ejecuta las pruebas de código y envía los resultados a los responsables y programadores. También se puede configurar la aplicación para que despliegue la aplicación y haga pruebas funcionales, estos resultados también se le pueden enviar los responsables y a los programadores. Te recomiendo este manual para empezar.

Certificación de Scrum

Existe un organismo llamado Scrum Alliance que ofrece certificaciones de Scrum a distintos niveles: Scrum Master, Scrum Product, Scrum Developer, Scrum Profesional, Scrum Trainer y Scrum Coach.

La forma de obtener una certificación es presentándote a uno de los cursos reconocidos por Scrum Alliance. Estos cursos te dan derecho a hacer un examen vía web que te concede la certificación.

Estos cursos son unas jornadas de un par de días que salen por unos 1000-2000 euros donde más vale que sepas todos los conocimientos teóricos de Scrum y tengas alguna experiencia en Scrum porque en estas jornadas no vas a ver nada de eso. Estos cursos se centran mas realizar actividades y discutir situaciones que, no de forma directa, con una mentalidad Scrum podrías resolver.

Los cursos para enseñar metodologías de gestión de equipos de trabajo deberían ser todos así.

Practica otra cosa que te hundes

En un proyecto me dijeron que el volumen de datos no iba a ser muy grande, lo suficientemente grande para no ser trivial pero no tan grande como para colapsar la memoria RAM del equipo, y los datos debían de guardarse en base de datos. El tiempo de respuesta sí que era importante. La solución más evidente era guardar datos en base de datos y en memoria y las consultas que fueran contra los datos en memoria para agilizar los procesos pero me surgieron dudas como:

• ¿Como se implementa un modelo donde la fuente de datos es la memoria y no un sistema externo como base de datos, una capa de Web Service, etc?
  
• ¿Existe alguna metodología de programación que soporte tener toda la información en memoria (Cache o algo asi)?

En otro proyecto me pidieron que no querían navegación, querían que la pagina web fuera como una aplicación de escritorio. La solución más evidente es hacer todo el entorno como siempre y cuando llegue a la interfaz (que he dejado para el final) lo hare todo con AJAX pero me surgieron dudas como:

• ¿Como se implementa un modelo no hay navegación?
  
• ¿Existe alguna metodología de programación que soporte no tener navegación (SPI o algo asi)?

Al final, la solución tomada en ambos casos (y creo que la solución que se tomaría en el 90 % de casos de cualquier proyecto) es implementarlo de forma tradicional (como si esos requerimientos no existieran porque se salen de la forma tradicional) y una vez que se tenga algo que funcione adaptarlo al requerimiento. FALLO!!!!. A la hora de afrontarlo tienes problemas de rendimiento, tienes que tocar más código del que crees, se multiplican los fallos, la coordinación del equipo desaparece al no saber como afrontar el problema, ….
Esto no debería pasar y para que no pase se debe:

• Practicar todos los framework, metodologías, etc.. que se pueda. No solo mirando la documentación y mirando el “What´s new” . Hay que picar código.
  
• EMPIEZA CON LA METODOLOGIA NUEVA DESDE EL PRINCIPIO. Desarrollar un software de una manera que no te han pedido y luego adaptarlo es como si se pide construir un barco y como los constructores no saben lo que hacen es un coche y luego intentan que flote.
  

CMMI. Resumiendo adquisición. Metas.

Una vez tomada toda la información, todas las explicaciones, todos los casos de uso, etc.. (una vez que ya se puede empezar el proyecto) se debe poder establecer todos los requerimientos. Estos deben ser fácilmente distinguible en esenciales (están si o si), requeridos (deberían estar pero siempre se puede jugar con ellos si no hay tiempo, son excesivos, etc..) e informativos (solo aportan valor, son para sacar nota).

Las metas son los objetivos del proyecto. Una vez conseguidas las metas, se han formado todos los componentes que forman un proyecto y el proyecto ha terminado. Las metas tienen que quedar encuadradas en genéricas y especificas. Una meta genérica son las que pueden aparecer en varios componentes del proyecto y las especificas las que solo aparecen en un componente en concreto. Mucho ojo al establecer o modificar en desarrollo del proyecto una meta genérica tiene mucho impacto; crea desconfianza en el cliente y da la sensación de que el proyecto va sin rumbo.

Marcar un rumbo

Un proyecto software puede empezar a quebrarse por muchos motivos. Uno de ellos es no seguir el rumbo marcado para un aspecto concreto, por ejemplo: “Se pide desde, el principio, que todo programador indique en un informe al final del día lo que ha hecho a lo largo del dia. Al segundo mes no lo envían ni la mitad y además lo pide solo algunos responsables y otros no”. Actitudes como esta son un problema, si nos hemos dado cuenta que dichos informes no son útiles entonces se debe comentar en una reunión con todo el equipo y dejar su uso, no se puede permitir la cosas desaparezcan solas. No es solo que situaciones como esta son una falta de sincronización, que lo son, es la evidente dejadez que se tiene ante aspectos del proyecto.
Una grieta no rompe una presa y la vía de agua es muy pequeña pero cuando tienes muchas el agua sale por todos los lados. Llegará un momento en el cual no sabes por donde empezar a tapar agujeros y cuando menos te lo esperas la presa se rompe y nos ahogamos todos.