Etiquetas: otro, desarrollo, ide
Me parece muy interesante la propuesta, GreenEyed. En cuanto tenga un ratillo mañana o el lunes cuento mi proceso. O quizá mis procesos, porque he vivido unos cuantos, variados, dependientes sobretodo de la empresa en la que estaba. No daré nombres, pero en las empresas grandes los procesos suelen ser bastante desastrosos.
Para cada tarea:
Todo en local si es posible, y haciendo las cosas lo más simples posibles, pero no más de lo necesario. Por detrás con un servidor de integración continua (bitten) y test, muchos test. Test Driven Development mola :)
Buenas a todos!
Siempre empezamos subdiviendo el trabajo entre presentación y modelo (lógica de negocio). La tendencia, es que haya al menos dos personas trabajando simultaneamente en la medida de lo posible. La idea es crear una dependencia (jar) que contenga la lógica de negocio, y periodicamente se añada al proyecto de presentación. Para la gestionar estas dependencias snapshot, es muy util maven 2. Existe un plugin para eclipse genial, eclipse maven q, que solo cambiando un xml cambia las dependencias de un proyecto.
Se requiere un repositorio (un ftp) local, al que todos tengan acceso, para compartir cada uno de los desarrollos de la empresa, al principio es complicado por lo tedioso de "migrar" proyectos antiguos, pero luego se agradece. La ventaja que tiene de subdividir una aplicación en varios proyectos eclipse, es que luego se puede reutilizar más facilmente cada una de las partes (dependencias) al estar desacoplado, con lo que luego se puede realizar servicios web, aplicaciones de escritorio.. reutilizando componentes.
Concretando más el proceso de desarrollo, pues creo que no difiere mucho del que dice greeneye, utilizar un plugin de eclipse para las clases de hibernate, utilizar el wtp de eclipse para presentación,y para presentación pues struts,jsf según el proyecto. Ah y aliñar el firefox con distintos plugin para desarrolladores, venkman javascript debugger, firebug, w3c validator...
1. Casos de uso + modelo de dominio. Muchas reuniones hasta tener el modelo de dominio completo. Al contrario de lo que proponen las metodologías ágiles, tratamos de tenerlo totalmente acabado antes de empezar a programar. Hasta ahora siempre ha dado resultado.
2. Diagrama de actividad para reflejar las páginas / estados de la aplicación
3. Paso de los folios con los borradores del modelo al RSA. En la parte de comentarios de RSA (una mierda) introducimos los doclets (XDoclet 2) para la generación de los xmls de mapeo de Hibernate.
4. Generación de código con las transformaciones de RSA.
5. Script en ANT para generar los archivos de mapeo a partir de los doclets y el DDL a partir de estos archivos. Todas las clases se generan en una base de datos de desarrollo de Oracle. Nadie tiene base de datos en local. Sí que se tiene en cambio una instancia local de WebSphere.
6. Implementación del modelo de dominio. Va antes de cualquier otra cosa. Si algo cruje (conceptos que no encajan, cosas que suenan mal al decirlas en voz alta, términos que nosotros empleamos de forma diferente al usuario) volvemos a la mesa para revisarlo todo. Podemos revisarlo un auténtico montón de veces antes de darlo por bueno, cuando ya todo suena natural. En nuestra experiencia es el tiempo mejor invertido en la aplicación.
6. Identificación de componentes que pueden ser reutilizados. Por ejemplo ¿necesitamos algún componente de faces que pudiese ser reutilizado en otras aplicaciones? ¿La seguridad tiene algún elemento especial? ¿Alguno para pillar datos via ldap de Notes, del Active directory, etc? Si es así, cada uno se anota como tarea separada y van a los jars compartidos (lo típico: nombre-del-cliente-comun.jar, nombre-del-cliente-seguridad.jar, etc)
7. Se escriben primero los componentes compartidos. Se escriben clases de prueba para las clases (/ métodos críticos con JUnit (no, no escribimos tests para todas las clases)
8. Desarrollo de las pantallas de interface con Firefox con los plugins web developer y sobre todo el increíble firebug
9. Para las secuencias CRUD puras tenemos nuestra librería a la que sólo hay que pasar un XML con la descripción de las pantallas que generará. Creo que casi todo el mundo ha programado alguna librería de este tipo para hacer los mantenimientos en 10 minutos.
10. Para las secuencias largas (con búsquedas, selección, etc) usamos otra herramienta hecha en la casa ("Triki", en honor al monstruo de las galletas). Con esto tenemos hecha casi toda la fontanería y una parte importante de las tareas repetitivas. Triki genera también el esqueleto de los xmls de Spring, de Hibernate, de seguridad (acegi), del faces-config, de la configuración base de hibernate, etc, en función de las clases que va detectando.
11. En relación a los CSS's, nos ceñimos totalmente a los que tenemos hechos como estándar como si no hubiese un mañana. Todos odiamos tener trabajar en la parte gráfica y cuando tenemos que cambiar / mejorar algo a nivel de estilos perdemos muchísimo tiempo.
12. Desarrollamos la partes de la aplicación que son dependientes de este proyecto.
13. Escribimos los archivos de localización que se apoyan sobre todo en el sistema de JSF (aunque pasan a través de una librería nuestra que los hace un poco más versátiles)
14. Desarrollo puro con ya todos los elementos importantes ya hechos. Siempre aparecen los típicos problemas derivados de que cuanto más te alejas de como se supone que se deben usar las librerías y frameworks que usas y sus limitaciones (sobre todo JSF) más lo pagas en tiempo.
15. Pruebas de integración y paso a explotación.
A partir de ahora habrá cambios importantes:
De Spring a Seam (se mantiene Spring a nivel interno en los componentes)
De Hibernate a JPA
De JSP's a Facelets
De Velocity a JET para todas las plantillas de emails, generación de código, etc, etc. Es bastante más rápido.
Pasamos a gestionar la lógica pura del comportamiento de la vista de JSF a Javascript apoyándonos en JQuery sobre todo. En la última aplicación ya se ha hecho apoyándose en el envoltorio de JQuery que aporta RichFaces y va de vicio. No sólo el código va en donde debe ir, es realmente mantenible y nos ahorra bastante tiempo.
No se usará XDoclet en el futuro. Por un lado introducir comentarios en el RSA no era muy eficiente en tiempo, y ahora, gracias a las anotaciones de JPA, ya no es necesario.
Se quitarán los DAO's. Todos. Ya ni siquiera existirá ese concepto. Pasamos a usar repositorios tal como se entiende en DDD.
Se quitarán los servicios de Spring (alguna gente los llama managers. Los típicos transaction scripts tal como los llama Martin Fowler, herencia de los EJB's 2) que tanto se usan con Spring. Pasamos a meter *toda* la lógica en el modelo. Los servicios como tales irán en el modelo. Los de aplicación e infraestructura, fuera. De hecho estamos creando un modelo de estructura que refleja los recursos disponibles en el cliente. Este ha sido uno de los mayores aciertos hasta ahora. Todo se simplifica muchísimo frente a andar cableando componentes con Spring.
En fin, esto da una visión a vuelo de pájaro de nuestro proceso de desarrollo, de las herramientas que usamos y hacia donde vamos.
[Cuña publicitaria]
Estoy buscando activamente una posición en Saigon (Vietnam) -no, no es broma- Si por un casual alguien estuviese en una empresa con presencia allí o con la oportunidad de trabajar en remoto, le estaría realmente agradecido (juan.medin en gmail.com)
Me paso un año buscando el lenguaje ideal para hacerlo, cuando he tomado la decisión, aparece uno nuevo. ;-)
dos opciones anonimo.
1) Evalua mas rapido
2) Fija un dominio y no te salgas porque seguro que el nuevo que saquen despues no es la panacea. Ninguno lo esl
Nosotros estamos en un momento de cambio, el proceso actual ha demostrado tener muchos problemas que estamos intentado solucionar. Nuestro caso es un poco diferente a los que habeis comentado porque no hacemos proyectos, hacemos producto, es decir nuestro desarrollo es medio/grande a largo plazo (más de 15 desarrolladores y llevamos más de 3 años con el mismo producto, y lo que queda...). Hacemos una plataforma sobre la que posteriormente se sustentan otros desarrollos de proyecto dentro de la empresa, y cuando esta plataforma deje de dar verguenza ajena se podra licenciar a terceros.... (esa es la idea...). Y para más jodienda tiene partes en C++, java y .net, lo que complica las cosas bastante.
ahoa mismo:
- Los requisitos no llegan de cliente, llegan desde dentro, es la propia empresa la que decide hacia donde va su producto. Esto facilita una relación "cercana" con el cliente jeje. Aún así usamos gestion predictiva y a veces parece que el cliente más lejos que algunos que tenemos en sudamerica.
- El comite de producto decide que caracteristicas se incluiran en la nueva versión, a partir de eso los tecnicos evaluamos el tiempo que se tarda y se hace una planificación de desarrollo con diagramas de gantt y estas mierdas (que si es para seis meses a las dos semanas ya ha quedado obsoleto el diagrama, pero no se actualiza y se utiliza como "arma arrojadiza" cuando las cosas pintan mal).
- Cada uno desarrolla sus cambios en local, si son gordos se establecio que habría que crear un branch y luego mezclarlo cuando estuviera completo, nadie lo hace y la linea principal (trunk) suele estar en un estado desastroso durante meses.
- Las pruebas se hacen en local, tenemos bd's y servidores de aplicaciones en local cada uno para sus pruebas, una vez hecho esto se suben los cambios al svn, tenemos un hook que obliga a poner comentarios con un determinado formato para luego autogenerar listas de cambios.
- Una vez subidos los cambios se compila todo el producto incluyendo esas modificacions y se generá una nueva versión. Esto en nuestro caso se complica mucho, más de 2 horas dura una compilción completa... tenemos un algoritmillo que se encarga de evaluar las dependencias entre los distintos modulos (librerias, ejecutables, dll's, jars, wars...) y sólo compila los necesarios, esto reduce el tiempo de compilación y disminuye el tamaño de los paquetes de actualización claro que sólo incluyen los nuevos componentes.
- una vez se cuenta con una nueva versión se pública y el dpto de documentación hace la documentación de usuario con las nuevas caracteristicas añadidas. En teoría existe un departamente de homologación/QA que hace las pruebas, pero sólo las hacen cuando se esta a punto de entregar algo y las iteraciones son muy largas (de 5 meses y pico la ultima). Conclusión, que al final las planificiones iniciales no se cumplen nunca pq es sólo al final cuando surjen todos los problemas gordos.
- Nuestro producto es más bien un SDK que luego usan otros departamentos de la empresa, así que las fases de entrega a cliente, instalación no forman parte de nuestro proceso.
Cosas que queremos cambiar:
- Iteracions cortas, esto es fundamental, iteraciones de unas 3 semanas cuatro a lo sumo entregando como resultado una versión funcional del producto.
- Eliminar el concepto de planificación predictiva de nuestro desarrollo, sencillamente no funciona en nuestro caso, en ocasions tenemos que evaluar el uso de distintas tecnologias para resolver un problema. Por ejemplo teniamos que construir un entorno de configuración sobre netbeans o eclipse, no es posble decir que voy a tardar 245'2 horas antes de empezar. Se van entregando versiones funcionales cada poco tiempo y se evalua la velocidad de desarrollo para establecer fechas de entrega más realistas (y sólo se toman como fechas aproximadas).
- Montar un sistema de integración continua o al menos de daily builds.
- Mejorar la cultura de pruebas, tanto prubas unitarias como de integración, evaluar como hacer pruebas de regresión (herramientas etc), montar entornos de pruebas en distintos contextos (distintos so's, distintas bd's, distintos servidores de aplicaciones) y automatizar esto con vmware en lo posible. Hacer pruebas de stress y carga.
- Mejorar la calidad del desarrollo, con cosas como checkstyle, pmd, findbugs y estableciendo protocolos de revisión de código.
- Propiedad colectiva del código (a lo XP), evitar que la gente tenga una "etiqueta" con el módulo que mantiene y que cuando no esten frenen el ritmo del desarrollo completo. (el del producto completo avanza al ritmo que marca el desarrollador o grupo más lento)
- Documentación como parte del desarrollo, tanto documentación interna para quien venga a trabajar dentro del equipo y tenga que mantener cosas como la propia documentación del producto. Simplemente con un wiki y algunas normas. La cosa es tomarse la documentación más en serio...
bueno y mil más, estamos en un proceso de cambio gordo y intentando resolver todos los errores cometidos en el pasado, claro que para más jodienda ahora la empresa quiere implantar CMMI lo que choca bastante con muchas de nuestras ideas (orientadas más a SCRUM+XP), a ver por donde salimos jeje.
Lo que yo hago normalmente es que grupos de desarrollo en otros lenguajes se muevan a Java por lo que empiezo conociendo que les gusta del lenguaje antiguo y que no, he intento montar un sistema que tenga lo bueno de uno y no tenga lo malo, si consigo esto la gente esta "a gusto" con el nuevo sistema y me paso a hacerlo a otro grupo, proyecto ...
No doy nada por sentado, ni me caso con ninguna tecnologia, hoy puede ser bueno java, o ruby mañana, goovy lo importante es modernizar el desarrollo.
Por supuesto ahora esta de moda el SOA.
Sobre todo Swing
El usuario tiene una idea de lo q quiere, y donde realmente se termina de completar son con los informes
Luego diseño BD
Luego resto
un cordial saludo
infoeduardo
El proceso que sigue la empresa donde laboro es bastante similar a la de remoh, es decir, trabajamos en conjunto con el cliente (el cliente tiene su propio equipo de IT) en donde por cada proyecto el Project Manager, Process Engineer, Business Analyst y el Tech Lead se reunen con los pesos pesados de cierta division de la compania para planear el proyecto y determinar los requerimientos de negocio. El Business Analyst redacta el documento de requerimientos (BRD) y las especificaciones funcionales, se vuelven a revisar con el negocio y si todo va bien, los presidentes de las divisiones firman esos documentos como aprobados. Inmediatamente despues el Tech Lead prepara un documento con las especificaciones tecnicas que despues hace llegar a un Team Lead y con esto inicia la etapa de desarrollo. Cada determinados dias de la semana hay un "Test Release" por lo que cuando se termina los dias planeados para el desarrollo el proyecto se manda al ambiente de pruebas; estando ahi un equipo de QA analiza los requerimientos uno a uno y cuando no se "levanta" un defecto para el proyecto que el equipo de desarrollo tiene que solucionar antes del proximo "Text Release", cuando se termina el tiempo en el ambiente "Test" se hace un relase al ambiente de Prueba de Aceptacion del Usuario, donde se escojen cierto usuarios de cada division, se les entrena y realizan pruebas funcionales con el proyecto, cuando encuentran un defecto o desean algun cambio funcional se levanta el "defecto" pertinente y de nuevo el equipo de desarrollo trabajo sobre eso. Obviamente esos cambios o correcciones vuelven a pasar por las mismas etapas, primero se manda a Test y despues de que QA apruebe los cambios se mandan a UAT donde el usuario tiene que probar de nuevo ese cambio especifico para aprovarlo. Despues de que se termina la etapa de pruebas de usuario, los presidentes de las distintas divisiones aprueban el proyecto (o NO en el peor de los casos) y el proyecto esta practicamente listo para ir a Produccion. Antes de que eso suceda se hace un Pre-Production release con la copia mas reciente de la bd y de la aplicacion de produccion en donde el equipo de QA de nuevo tiene que verificar el proyecto (obvio de manera mas rapido) y tambien se hace un Regression Testing para asegurar que funcionalidad existente no haya sido afectada. Para finalizar se hace el tan esperado Production Release y nada mas se comprueba que las versiones en Produccion despues del release correspondad a los cambios hechos sobre la aplicacion. Despues de tantas etapas se espera que el proyecto tenga pocos o ningun defecto, si se detecta alguno los cambios otra vez tienen que pasar por todas las etapas antes de llegar a produccion de nuevo (y el fix tiene que esperar o no al siguiente Production release dependiendo de la gravedad de este), despues de un determinado tiempo de soporte a produccion el proyecto se cierra y subsecuentes cambios se facturan aparte. Y basicamente asi son todos los proyectos, es tienen aproximadamente unos 400 proyectos, el equipo de desarrollo es de aproximadamente 200 personas. La aplicacion como ya habran pensado es un pequeno monstruo con 6000 objetos de base de datos.
Una disculpa por no accesar a la zona de usuarios pero tenia que salirme antes de escribir esto por motivos de confidencialidad.
Hola a todos.
Muy buena idea G, en estos tiempos de tanta nueva herramienta, framework, testing, agil, integracion continua,... etc. siempre quieres probarlo todo pero no hay tiempo material ni en casa ni mucho menos en el curro. Al menos es mi sensacion.
Por volver un poco al hilo del post inicial de G, creo que algunos os habeis ido a describir el ciclo de vida del proyecto cuando deberia ser un debate mas tecnico, voy a contar muy resumido mi caso, al que acabo de llegar, y sobretodo a donde quiero llevarlo, porque reconozco que ahora mismo estamos un poco retrasados.
* Gestion de releases y tareas: JIRA.
* Control de fuentes: CVS.
* IDE: Eclipse + wtp. Intentamos que sea lo más I posible, es decir servidor, ant, junit, checkstyle,... todo lo que podemos lo lanzamos desde el propio eclipse haciendo hot-deploy para acelerar el desarrollo en local.
* Entornos: uno local por desarrollador mas un servidor comun de desarrollo para demos.
* Testing: Junit + selenium.
* Build, testing, reports, deploy, distribucion, etc.: ANT.
* El mejor amigo de Struts e Hibernate: Xdoclet 1.2.3.
* JSTL y un poco de ajax con DWR.
Futuro:
* Integrar ext-js en nuestro Struts 1.3 (de momento no queremos casarnos con ninguno de los nuevos sustitutos de Struts, vamos a dejar pasar el año a ver que pasa con Seam, GWT y Struts2).
* Más junit y selenium, añadir covertura, usar RC para nuestros tests en selenium
* Evaluar PMD, Checkstyle, JDpend para code reviews
* Spring 2.5
* Integracion continua. Estamos probando cruise-control. Qué tal es ese bitten?
Si quereis que detalle algo en concreto, solo teneis que pedirlo.
Un saludo.
César.
Vaya (Por no decir "guuaauuu").
A muchos nos falta mucho por aprender.
los que deseamos hacerlos, donde nos podemos documentar bastante.?
Da envidia de la buena.
Despues de estar alejado del desarrollo web por una temporada larga, no tiene mucho sentido compartir mi modo de trabajo en estos momentos (desarrollando una app con NB RCP, en la que la tecnología/modelo de datos/build...etc ya te viene marcado).
Solo una recomendación: Trac (http://trac.edgewall.org/) Cuanto más lo uso más me gusta, y a todo aquel programador al que se lo recomiendo, tambien le gusta. De hecho tengo algunas ideas.... y si alguien se animara, alguna idea de proyecto clon de trac en groovy.
Salu2
PD: ¿Por que un clon en groovy si me gusta tanto?
- Su instalación a una versión "interesante" suele ser un dolor de muelas.
- Con svn va de cine. Con otros SCV.... ummm... o no hay soporte o es muy alpha.
- En las ultimas versiones hay plugins para sitios multi-proyecto, pero de nuevo, la instalación es farragosa.
- Me gusta groovy y estoy deseando hacer algo mediano-grande con él. Y no, lo siento, no me gusta python, que le vamos a hacer.
Si alguien se anima, contacto a través de mi perfil de usuario jH (sólo usuarios registrados)
Hola ibon.
Probe trac el otro dia, pero no me gusto tanto como a ti y no esta mal... pero prefiero JIRA con diferencia. Es mucho mas usable, mejor pensado, mas y mejores opciones, mas bonito, etc, etc... aunque si, es de pago :(
La buena noticia es que a raiz de esto tambien pense en lo interesante que seria crear un proyecto open-source para crear una aplicacion de gestion agil de proyectos.
La mala es que no se groovy y no tengo tiempo para siquiera plantearme empezar a aprenderlo :-(
Un saludo.
César.
Hola César,
Yo es que soy un perro verde, y lo que no me gusta es JIRA: cada vez que he consultado el JIRA de un proyecto no me quedaba claro ni siquiera el orden en el que estaban los comentarios de los tickets. Siempre me ha parecido un mastodonte, y no estoy muy de acuerdo en un sistema de gestión de tickets que tengas que "estudiar" para empezar a usar. Y de trac lo que me gusta es su sencillez de uso.
Supongo que JIRA tiene mucho sentido en proyectos mastodonticos... pero es que creo que hay demasiada sobreingeniería en la gestión de proyectos (humilde opinión).
Respecto a groovy, sabiendo Java ya tienes el 50% del camino realizado. Respecto al tiempo, ya no puedo hacer nada ;-)
Salu2
En serio Ibon? Nosotros usamos la version 3.6 de JIRA, actualmente va por la 3.12, aunque si te digo la verdad no se que diferencias habra. El caso es que estuvieron media horita enseñandome a moverme y cuando fui a ver trac me parecio mucho mas lioso y dificil de usar y seguir trac que JIRA. No se si sera cosa de gustos o si seria totalmente diferente si alguien que controlara trac me hiciera un tour de media hora como hicieron con JIRA. Aunque la experiencia de los nuevos tambien es muy positiva con el (tras previo tour claro). En fin, que colores...
Sobretodo lo que no me gusta de trac es que no divide la pantalla en columnas o sidebar, lo ponen todo de arriba a abajo y lo encuentro cansino.
La verdad que es una pena pero, como comentaba mas arriba, estoy intentando sacar tiempo de donde sea para hacer una minirevolucion en nuestro proceso de desarrollo y, aunque me gustaria, no me atrevo a comprometerme. Mi roadmap pasa primero por Spring y ext-js. Pero tendre presente tu ofrecimiento y a lo mejor dentro de un par de meses te doy un toque.
Yo (venkman) he pasado por empresas variadas y he visto procesos variados.
Una de las conclusiones que he sacado es que hay muchas cosas del proceso que realmente no importan demasiado para el resultado final. También, pero eso es más fácil de intuir a priori, que la calidad de los procesos no suele estar relacionada con la supuesta calidad de la empresa.
He pasado por procesos que consistían en...
Caso 1 (La chapuza): Me llama por teléfono un gerente y me dice que para la próxima semana quiere que le presente una aplicación web para hacer un cierto datamining de una tabla de 10 millones de registros y unos 400 campos. Que use, me dice, alguna cosa que ya hayamos hecho antes para algún portal o que si necesito algún gráfico que lo pida por ahí. Que no quiere nada sólido, sólo para poder enseñar la idea y eso. Hago (con ayuda de SciTE, unas macros en Lua, una plantilla y trozos de otros proyectos, Struts... todo mezclado, agitado, no mareado) algo que no puede pasar de considerarse una maqueta-prototipo que se tiene con palillos ya que no sé ni qué es lo que realmente quieren y van y... se lo venden al cliente como si fuera algo real. Contratan a un pobre ingénuo y le ponen a "mantenerlo".
Caso 2 (The Coolness, en la misma empresa): Hacemos un estudio de viabilidad, elaboramos un plan, definimos una arquitectura preciosa (bueno, exagero, pero estaba bien)... Montamos todo bastante bien. Seguimiento del proyecto semanal y diario (5 minutos a primera y última hora y 30 minutos un día a la semana). Nuestro repositorio de Subversion sincronizado con el de otra empresa que hace otra parte del proyecto. Montamos entornos de trabajo con Eclipse. Un buen script de Ant para construir la aplicación. Cogemos a un diseñador que nos hace una maqueta general, plantillas y gráficos, y a otro que nos asistirá durante todo el proyecto para lo que necesitemos. Montamos una instalación de una herramienta (propia de la empresa) de seguimiento de errores e incidencias. Hacemos un desarrollo inicial de un par de librerías genéricas que luego reutilizaremos. Nos ponemos nuestro equipo (éramos 3) a trabajar. Hacemos un proyecto limpio y bonito y, lo más increíble, antes de tiempo. La jefa de proyecto hace la demo al cliente que queda encantado. Los comerciales no saben vender el proyecto y ponerse de acuerdo con la otra empresa y queda "en espera de ver qué pasa". La jefa de proyecto se va. Yo me voy. Varios años después, que yo sepa, el proyecto sigue olvidado.
Caso 3 (Las cosas bien hechas): Empezamos por diseñar la arquitectura de clases del dominio de la aplicación. Un experto del tema, otra persona con experiencia y yo. Una pizarra y rotuladores de diferentes colores. Luego pasamos 'a limpio' usando MagicDraw (si no recuerdo mal, que ahora no estoy seguro). Tras un par de iteraciones llegamos a algo que nos gusta. Mientras, un diseñador va extrayendo una serie de componentes visuales que vamos a necesitar (es una aplicación web, por cierto).
Va a ser una arquitectura modular por abajo y por arriba, pudiendo cambiar a placer los orígenes de datos (Hibernate, Axis, JDBC, RMI...) y la salida (básicamente HTML o XML). Nos ponemos a hacer componentes con Velocity.
En esta fase, es donde suelo hacerme (o reutilizo si se parecen suficiente) algunas macros (normalmente en Lua, a veces en Javascript) y en algún caso alguna herramientilla algo más consistente, para ayudarme en las tareas mundanas. En este caso, creo que mayormente fueron macros en Lua. Primero generamos un primer modelo básico con todo lo que conocemos de antemano. Después desarrollamos en paralelo 3 personas. Una hace componentes visuales (Velocity y un plugin simplón para Eclipse, Gimp, Pixia o algún otro más específico para las imágenes), otra amplía el modelo según necesidad y trabaja sobretodo a su alrededor para enlazarlo a los origenes de de datos o para ofrecer servicio a la presentación. La tercera se ocupa de consumir lo que le dan los otros dos para montar la aplicación (Eclipse, Firefox+Firebug+WebDeveloper+alguna otra, Spring). Nos vamos rotando en cada posición para que todos conozcamos todo el proyecto. Compartimos con Subversion. Usamos Maven para gestionar un número de dependencias que prefiero no recordar. En Eclipse los únicos plugins que tenemos son para poco más que resalte de sintáxis. Alguno genera código pero procuramos pasar eso siempre a algún tipo de script externo. Cada uno tiene un servidor localmente, pero existen origenes de datos que se comparten (algún Oracle, algún webservice externo).
Tenemos también un servidor "de certificación" para luego. Tenemos también tests e informes sobre los tests. Cuando ya vamos teniendo algo razonablemente usable, lo va probando el experto y sacándonos problemas, detalles, sugerencias. Sabemos que es su trabajo pero en el fondo de nuestro corazón le odiamos un poco xD
Se va uno de los desarrolladores, pero por suerte habíamos incorporado una cuarta persona unos días antes, y como todos conocemos el proyecto entero y todo está bastante ordenado, no hay mucho problema.
Durante todo el proceso, trabajamos juntos, en la misma oficina. Hablamos continuamente y nos reunimos una vez por semana. Acabamos a tiempo y todo bastante va bien. Debido a esto, utilizamos Cerveza (diversas marcas según la preferencia de cada uno) y algunos Pinchos (no puedo recordar qué modelos).
Caso 4 (el proyecto laaaaaaaaaaargo): Empezamos unos 3 o 4 meses de investigación. Es poco tiempo, considerando que el proyecto va ya para 8 años y que yo sepa sigue aún. De hecho es muy poco tiempo, como se demostraría más adelante, pero bueno, eso es otra historia.
Empezamos probando diferentes soluciones que involucran pruebas de concepto de Plugins para Netscape (era la época del 4.x, quizá incluso antes), de servidores y protocolos a medida, de módulos de Apache, de herramientas de dibujo vectorial, controles ActiveX, applets de Java y algunas ideas (más) alocadas. Nos dedicamos sobretodo a construir prototipos y probar sus limitaciones.
No hay proceso aquí. Es un proyecto de 8 años, que lleva ya 10 en otra plataforma. No se rige por procesos sino por costumbres. Así que nosotros (el equipo de la nueva plataforma) nos adaptamos no utilizando procesos sino adoptando costumbres. Es sucio, torpe y enorme y funciona. De hecho, que yo sepa, si tenéis ADSL en casa, en buena medida es porque esto funciona, lo que hace pasar un poco por alto el hecho de carecer de proceso.
Las costumbres? Pues... algunas herramientas hechas por nosotros mismos, algunas plantillas, el uso de CVS, el uso de CVS para marcar cada fichero que se entrega para poder saber con precisión qué versión hay en cada entorno (son unos cuantos y el proceso de entrega e instalación es lento y confuso) y si han instalado correctamente... Poco más.
En fin, me he ido por los Cerros de Úbeda. Actualmente he llegado a un sitio del que no puedo decir mucho, pero parecen tener unos procesos bastante establecidos. Y algunos parecen buenos. Otros tengo claro que lo son, pero como digo no puedo contar aún mucho de ello.
Veréis. Donde yo estoy no programo. Hace mucho tiempo que nadie programa. De hecho, toda la programación está externalizada en una consultora de esas que tienen miles de empleados. Así que de la parte "técnica" se ocupan ellos. Ahora viene lo bueno, tenemos procesos para todo, tantos y tan farragosos que todo el mundo intenta seguirlos, pero que inevitablemente consumen una cantidad de tiempo tal que el único resultado que tiene tener tantos procesos es... que nunca se hace nada. Además, todos esos procesos tienen una serie de pasos donde los plazos para cumplirlos, como mínimo, ya exigen 20 días para un cambio simple.
Los únicos desarrollos que se hacen son aquéllos que son urgentes, pero urgentes de verdad. Del tipo nos jugamos una multa de 10MM de euros, del tipo una oficina de 500 personas está parada, etc. En estos casos, nos saltamos todos los procesos y tiramos palante.
La consultora que lleva la parte "técnica" (por así decirlo) no conoce ni ha oído hablar del control de versiones, de las pruebas unitarias o las pruebas de integración. Las pruebas consisten en un programador (probablemente en Manila, Bangalore o dios sabe dónde) que se supone que "prueba" y un usuario que se supone que "prueba" Adivinad qué, ninguno de ellos sabe probar, no hay departamento de QA. Estos "técnicos" tienen la cualificación mínima imprescindible para que puedan hacer algo que pase las pruebas. La documentación no existe.
Como consecuencia de esta forma de trabajo, el resultado práctico es que NUNCA se modifica nada. Siempre se hace nuevo, ya que nadie tiene las narices como para modificar algo de otro debido a que en primer lugar no está cualificado (no son capaces ni de leer el código y mucho menos entender el de otro) y en segundo lugar porque al no existir ninguna documentación no se puede saber si algo es un bug o es que debería funcionar así.
Y aún así, entre algún que otro usuario heroico y entre que los pretendidos "Jefes de Proyecto" acaban siendo analistas de negocio, arquitectos, programadores, etc, a nadie le importa.
Para aquellos que como yo les resulten raros algunos de estos nombres vean un Panorama de Java, o busquen en Google cada definicion :). Saludos
Escribe tu comentario