Un equipo de informáticos especialista en implantaciones CRM y desarrollos a medida.

Nuestro equipo es especialista en desarrollos con un objetivo principal: Localizar y desarrollar la mejor solución según las necesidades de cada cliente.
Surge como línea de negocio en 2005 tras la necesidad de nuestros clientes de completar su suite de herramientas de gestión para poder disponer de toda su información de forma centralizada.

Trabajamos principalmente en tecnologías web: .net, jsp y php.

Nuestra metodlogía habitual es XP (Extreme programming). La Programación Extrema es una metodología ligera de desarrollo de software que se basa en la simplicidad, la comunicación y la realimentación o reutilización del código desarrollado. Fué desarrollada por Kent Beck.

«Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.» Kent Beck

Las actividades son las siguientes:

Planificacion

Se escriben user stories, cuya idea principal es describir un caso de uso en dos o tres líneas con terminología del cliente (de hecho, se supone que deben ser escritos por el mismo), de tal manera que se creen test de aceptación para el user storie y permita hacer una estimación de tiempo de desarrollo del mismo.
Se crea un plan de lanzamiento (release planning), que debe servir para crear un calendario que todos puedan cumplir y en cuyo desarrollo hayn participado todas las personas involucradas en el proyecto. Se usará como base los user stories, participando el cliente en la elección de los que se desarrollarán, y según las estimaciones de tiempo de los mismos se crearán las iteraciones del proyecto.
Se hacen pequeños lanzamientos con mucha frecuencia.
El desarrollo se divide en iteraciones, cada una de las cuales comienza con un plan de iteración para el que se eligen las user stories a desarrollar y las tareas de desarrollo.
Las personas cambian de área para evitar cuellos de botella y fomentar la propiedad colectiva del código.
Se cambia el proceso lo que sea necesario para adaptarlo a tu proyecto.

Diseño

Se eligen los diseños más simples que funcionen.
Se elige una metáfora del sistema para que el nombrado de clases, etcétera, siga una misma línea, facilitando la reutilización y la comprensión del código.
Se escriben tarjetas CRC (class-responsabilities-collaboration) de clase-responsabilidades-colaboración para cada objeto, que permiten abstraerse el pensamiento estructurado y que el equipo de desarrollo al completo participe en el diseño.
Se “refactoriza sin piedad”. Basicamente, consiste en no tener miedo de cambiar un diseño o eliminar un código que ya no sirve, o al menos que ya no es claramente la mejor solución.

Codificación

El cliente está siempre disponible, a ser posible cara a cara. La idea es que forme parte del equipo de desarrollo, y esté presente en todas las fases de XP (escribe los user stories con la ayuda de los desarrolladores, participa en la elección de los que entrarán en el plan de lanzamientos, prueba pequeños lanzamientos, participa en las pruebas de funcionalidad…). La idea es usar el tiempo del cliente para estas tareas en vez de para que cree una detalladísima especificación de requisitos, y evitar la entrega de un producto peor que le hará perder tiempo.
El código se ajustará a unos estándares de codificación, asegurando la consistencia y facilitando la comprensión y refactorización del código.
Las pruebas unitarias se codifican antes que el código en sí, haciendo que la codificación de este último sea más rápida, y que cuando se afronte la misma se tenga más claro qué objetivos tiene que cumplir lo que se va a codificar.
La programación del código se realizará en parejas, para aumentar la calidad del mismo. En cada momento, sólo habrá una pareja de programadores integrando código.
Se integra código y se lanza dicha integración de manera frecuente, evitando divergencias en el desarrollo y permitiendo que todo el mundo trabaje con la última versión del desarrollo. De esta manera, se evitará pasar grandes periodos de tiempo integrando el código al final del desarrollo, ya que las incompatibilidades habrán sido detectadas enseguida.
Se usa la propiedad colectiva del código, lo que se traduce en que cualquier programador puede cambiar cualquier parte del código. El objetivo es fomentar la contribución de ideas por parte de todo el equipo de desarrollo
Se deja la optimización para el final
No se hacen horas extra de trabajo

Pruebas

Todo el código debe tener pruebas unitarias, y debe pasarlas antes de ser lanzado.
Cuando se encuentra un error de codificación o bug, se desarrollan pruebas para evitar volver a caer en el mismo.
Se realizan pruebas de aceptación frecuentemente, publicando los resultados de las mismas. Estas pruebas son generadas a partir de las user stories elegidas para la iteración, y son “pruebas de caja negra”, en las que el cliente verifica el correcto funcionamiento de lo que se está probando. Cuando se pasa la prueba de aceptación, se considera que el correspondiente user storie se ha completado