El recuerdo del dotProject viene a mi, a partir de un artículo que leí BarraPunto , y que me pareció interesante citar pues cita características como definiciones de proyectos (OpenUP, Scrum, XP), integración con SVN, etc.

“Complutense de Madrid ha desarrollado una extensión de dotProject, el gestor de proyectos con interfaz web, con varias características interesantes para la comunidad: un asistente para la importación de definiciones de proyectos (OpenUP, Scrum, XP y algún otro); la gestión de control de versiones con subversion (dotproject sólo permite etiquetar a mano los ficheros); el concepto de rol como responsable de tareas; y la posibilidad de definir dependencias de tipo produce/consume entre tareas y productos del proceso de desarrollo. El software se distribuye bajo GPLv3 y se puede descargar. En esa dirección se podrán encontrar demos (vídeos + software) y manuales de instalación y uso.”

Vía: BarraPunto

En esta ocasión, quiero compartir un breve resumen de un texto acerca de Extreme Programming. Exceptuando la parte histórica, XP se basa en llevar al extremo las buenas prácticas de desarrollo de software, y así bajar el riesgo, permitir cambios de especificaciones durante el desarrollo y favorecer la comunicación con el cliente.

Lo más interesante radica en la enumeración de las prácticas que son llevadas a un extremo:

• Como probar programas es bueno, entonces se hacen pruebas unitarias y funcionales todo el tiempo.
• Como hacer pruebas de integración es importante, la integración sigue inmediatamente después de las pruebas unitarias
• Como revisar la calidad del código es recomendable, se revisa código todo el tiempo y se hacen refactorizaciones, que implican cambios de diseño para hacerlo más simple, pero que no afectan la funcionalidad.
• Como los estándares de codificación permiten una mejor comunicación y reducen los errores, se fijan estándares precisos y estrictos.
• Como es bueno que el sistema sea simple, se busca la simplicidad siempre, diseñando solo lo que se necesita en el momento.
• Como los requerimientos de la arquitectura pueden ser cambiantes, se van refinando constantemente.
• Como el desarrollo incremental es positivo, se hacen iteraciones lo más cortas posibles: se diseña una pequeña porción, se la codifica y se la prueba.
• Como suele suceder que un proyecto se suspenda en un momento determinado (por ejemplo por falta de presupuesto) se implementa primero lo que tiene mayor valor para el cliente.
• Como es importante tener una comunicación frecuente con el cliente, siempre debe haber un cliente acompañando el desarrollo. Además éste es fundamental para escribir pruebas funcionales y establecer prioridades.
• Como dos cabezas piensan mejor que una, y cómo refuerzo a las prácticas anteriores, los programadores trabaja de a dos: uno escribe y el otro piensa en mayor escala, buscando simplicidad, errores y formas alternativas de solución del problema. Estas parejas pueden intercambiarse a lo largo del desarrollo, de todas formas cada pareja es responsable de una tarea, y hasta no terminar esta no hay intercambio.

Extraído de: Orientación a objetos con Java y UML, de Carlos Fontela.

En esta publicación vamos a instalar, configurar y probar CVS en Linux, especificamente sobre la distribución de Ubuntu 8.04:

• Descargar el cliente y servidor CVS, cvs y cvsd:

• Entre otras cosas, la instalación crea una estructura de directorios en /var/lib y crea los usuarios y grupos cvsd:

• Dentro del directorio /var/lib/cvsd crearemos el directorio para nuestro repositorio (se pueden crear tantos directorios como repositorios querramos utilizar).

• Cambiamos el propietario y grupo del directorio creado, con el usuario y grupo creado durante la instalación por el cvs:

• Ejecutamos cvsd-buildroot para que se creen los directorios y archivos administrativos del sistema y se actualicen los binarios (cada vez que se actualicen los binarios del CVS deberíamos ejecutarlo)

• Para finalizar, inicializamos el repositorio y creamos un usuario para acceder al mismo:

• En esta instancia, nuestro repositorio ya está creado y ya podemos empezar a trabajar con el mismo. Para probar si es así, podemos conectarnos por línea de comandos o a través de algún IDE (por ejemplo, Eclipse o NetBeans incluyen integración con repositorios):

Vía: Emilio

En esta ocasión, sin entrar en detalles técnicos ni prácticos, me limitaré a citar algunas características de Bazaar. Espero en una futura publicación poder decir "Como instalar Bazaar".

• Bazaar es una herramienta de control de versiones distribuidas
• Es patrocinada por Canonical Ltd. ¿te suena? Canonical es el sponsor comercial de Ubuntu
• Se centra en la facilidad de uso y puede ser utilizado por un único o en conjunto con equipos de desarrollo
• Está escrito en Python, publicado bajo licencia GNU/GPL y disponible para plataformas Windows, Linux y Max OS X.
• Comandos similares a otros sistemas de control de versiones (CVS, SVN)

Para finalizar, una presentación de la herramienta, realizada por Martín Albisetti:

• ODP
• PPT

Vía: El CoDiGo K

Scrum es una metodología para el desarrollo de software que, como ninguna, se ha ganado muy rápido el visto bueno de los usuarios y cada vez más el de las empresas de la industria del software.

Ken Schwaber y Jeff Sutherland han sido los responsables de desarrollar una nueva manera de gestionar proyectos de construcción de software. Para el nacimiento de Scrum, los autores comparan la tradicional aproximación secuencial de desarrollo de productos en el que consecutivas fases del desarrollo son llevadas a cabo por diferentes grupos de especialistas (similar al desarrollo en cascada) con un enfoque más iterativo, en el que, usando una metáfora basada en el rugby, solo una persona corre en cada momento y el equipo pasa el balón al siguiente corredor. El liderazgo del proyecto va cambiando y todos trabajan como un equipo.

Scrum asume que los requerimientos cambiaran durante el proyecto. Scrum toma el cambio como una forma de entregar al final del desarrollo algo mas cercano a la verdadera necesidad del cliente.

El mercado actual exige ciclos de desarrollo cada vez más cortos. Para lograrlo se utiliza el "sprint de requisitos", una lista en la que se detalla de cómo se van a construir los diferentes requisitos del producto. Cada sprint suele realizarse en un plazo de entre 2 y 4 semanas. Al final, el objetivo es entregar algo que funcione, para el usuario pueda probarlo y se puedan introducir los cambios necesarios antes de que sea demasiado tarde. Esto es lo que nos permitirá ser flexibles.

Schwaber y Sutherland se basaron en el trabajo de la década del 80 de los japoneses Takeuchi y Nonaka, quienes estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, 3M o Hewlett-Packard. De ahí extrajeron la base de la metodología SCRUM que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.

Vía: La masa, el ladrillo, la bota, el bocadillo... , PymeCrunch