- Planificación. Escuchar las necesidades del Cliente, hacerlo parte del equipo, pero explicar lo que es fácil de obtener y lo que no
- Diseño. Es importante usar patrones de diseño.
- Desarrollo. Hacer que el propio código comunique lo que está haciendo.
- Pruebas. Realizar pruebas unitarias, puedes usar frameworks muy conocidos como JUnit y DBUnit.
Ventajas:
- Es un diseño simple
- Obliga a que funcionen todas las pruebas unitarias, todo el tiempo.
- Muchos comentan que no tiene, pero yo creo que solo se reduce la lógica duplicada.
- Suele tener menor número de clases y métodos. Aunque esto depende de la modularidad de la aplicación y que el desarrollador realice un diseño claro, simple y use patrones.
- La documentación suele ser pobre.
- Realizar un diseño simple
- Pequeñas versiones. Hacer entregas constantes para que el Cliente perciba el avance y retroalimente las necesidades de negocio que afinen la funcionalidad efectiva de la aplicación.
- Pruebas. Cada funcionalidad en la aplicacion (front, back, web-services, DAOs, VOs, Utilerías, etc.) debe ser probada.
- Recodificar. Siempre que veamos código al que se puede aplicar un refactoring, aunque no sea nuestro, es conveniente avisar al equipo y planear su reestructuración a medida que la propia aplicación lo pida.
- Programar en parejas. Un solo teclado, un solo ratón, una persona codifica, ambos piensan, se logran ideas más estratégicas (es importante que ambos estén abiertos a escuchar las ideas del otro con el fin de mejorar las propuestas planteadas y por consiguiente la aplicación).
- Integrar una vez al día. Obviamente antes de integrar implica ejecutar las pruebas para validar que todo siga funcionando como lo esperan las pruebas unitarias.
- 40 hrs por semana máximo permiten estar fresco, descansar 2 días para pensar en nuevas ideas y aplicarlas al inico de semana. Estaría bien disponer de un tiempo a medio día para descansar (siesta, break, tomar un pequeño postre) o despejar la mente realizando otras actividades (juegos de mesa, videojuegos, salas de lectura, reuniones de convivencia). Es parte del modelo laboral japonés y les funciona.
- Establecer estándares de codificación. Usar un checkstyle y practicar revisiones en parejas del código de otros resulta bastante bueno para la aplicación pues ayuda a detectar posibles errores de estilo e incluso de lógica, de forma que cualquier nuevo integrante que llegue al equipo se familiarice más rápido con el código.
No hay comentarios:
Publicar un comentario
Que opinas sobre esta publicación?