subscripción
Blog de Julio César Pérez Arques
Esquema de un Sistema de Gestión de Desarrollo Software
Julio 31st, 2009 - [Enlace local]
UPDATE 090731: Se mejora la imagen del esquema y se subraya la importancia de la automatización de la alimentación del Sistema.
Me encuentro sumido en un proyecto de consultoría para definir un Sistema de Gestión de Desarrollo de Proyectos o Ecosistema Software. Así que aprovecho para compartir una primera versión del esquema lógico sobre el que estoy trabajando.
Wiki
Es el punto de entrada principal al Sistema.Contiene la información básica de cada proyecto y la organización.
Redirige al resto de aplicaciones del Sistema.
Permite la creación de documentación de forma colaborativa.
Control de cambios automático.
Documentación exportable a formato pdf.
Cms
Sistema de Gestión Documental para los documentos binarios, como word, powerpoint, etc.No toda la documentación puede estar en el Wiki.
Project Management
Visión de alto nivel de la gestión de proyectos.Cuadro de mandos ágil para directivos.
Gestiona resto de estados de un proyecto que no son Desarrollo.
Issue Management
Gestión del desarrollo de cada proyecto con sus versiones, tareas, equipo, trazabilidad, etc.Scm
Sistema de Gestión de Control de Fuentes (CVS, Subversion, Git,... etc.)Continuous Integration Server
Descarga, construye, prueba, analiza el código, crea informes de estado y despliega en el Demos Server los proyectos de forma automática y periódica.Demos Server
Servidor de demos del estado actual de cada proyecto.Otros
Notificaciones vía RSS y e-mail.Single Sign On.
Privacidad.
Integración con el IDE del equipo de desarrollo para automatizar la alimentación del Sistema y garantizar la trazabilidad.
Ahora toca analizar alternativas y seleccionar la que más se ajuste a las necesidades del cliente.
Los mayores problemas están en (1) el análisis del Wiki y el Cms por la cantidad de alternativas disponibles y (2) en la herramienta de Project Management porque cada organización tiene un punto de vista muy personal sobre la gestión de proyectos, lo que interesa y lo que no. Así que no descarto que haya que desarrollar una aplicación a medida como suelen tener todas las organizaciones.
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Cuanto vale un experto en programacion (ii)
Julio 9th, 2009 - [Enlace local]
Empezamos nuestra vida profesional programando. A muchos nos encanta. Va más allá de una obligación o un mal menor y temporal en un camino mezquino. Es una pasión. Disfrutamos construyendo buen software y cúanto mejor lo hacemos, más nos gusta. Por eso nos cuesta abandonar la rama técnica de nuestro sector. Aunque es una rama corta, torcida y con un techo salarial injusto.
Hace unos dias os contaba que Kent Beck ofrecía sus servicios durante 2 horas de forma remota a través de ebay. Me pareció una buena prueba para saber dónde está este techo ahora. Para saber cúanto vale un experto en programación y animarme a no cambiar de rama.
Finalmente la puja se cerró en 405 dolares americanos. No llega a 300 euros al cambio actual. Más o menos lo que cualquier consultora cobra por una jornada de un perfil técnico medio aquí en España. No sé a vosotros, pero a mi me parece poco. Me cuesta creer que haya faltado repercusión o que la cuestión del remoto haya sido un impedimento. Sinceramente me esperaba más dinero. Sobretodo teniendo en cuenta que por casi cualquier curso o seminario con un profesor anónimo ya se está facturando eso o incluso más. Y no es lo mismo un formador que un experto.
La conclusión es tan clara como desmotivadora. Un experto en programación vale poco en comparación con otros expertos.
Por qué
Por un lado es un problema de actitud. Nos quejamos mucho en nuestros circulos internos pero reivindicamos poco o nada en comparación con otros colectivos de trabajadores.Pero principalmente pienso que es un problema de no saber reconocer la calidad ni importancia del trabajo de un programador. Me explico. Reconocer la calidad del trabajo de un diseñador gráfico es sencillo (gustos aparte). Reconocer la calidad del trabajo de un experto en usabilidad es sencillo. Reconocer la calidad del trabajo de un tester es factible con métricas sobre el número de bugs detectados. Reconocer la calidad del trabajo de un formador también es sencillo. Calcular la comisión del trabajo de un comercial se hace todos los dias.
Sin embargo, reconocer la calidad del trabajo de un programador no es fácil para alguien que no sea también programador. Características como la eficacia, estabilidad y escalabilidad del código de una aplicación no son fácilmente medibles a primera vista. Ni siquiera para un programador. Ya sea sobre el código o sobre la aplicación funcionando. ¿Es culpa del análisis, del código propio de la aplicación, de alguna librería externa, del servidor, del proxy, de la base de datos,...?
Mucho más dificil es responsabilizar de cualquier mérito o demérito a un programador concreto dentro de todo un equipo de desarrollo. ¿Trazabiliqué? Todos somos de excusa rápida para nuestros fallos y muy poco comprensivos para los de los demás.
La complejidad se multiplica para el caso de aplicaciones enterprise donde existen numerosas fuentes de datos, cuya integridad y fiabilidad no dependen directamente del programador pero si pueden afectar a la aparente calidad de su trabajo. ¿A quién no le han abierto una incidencia que realmente era por un bug en un servicio externo, por inconsistencia de datos o simplemente porque estaba caido algún sistema externo?
Al final el cliente termina por aceptar y convivir con que sus aplicaciones fallan y necesitan de grandes contratos en mantenimiento correctivo y funcional. Los comerciales hacen su trabajo. La empresa gana dinero. Y nosotros terminamos parcheando dinosaurios. Todo puede seguir como estaba.
Aún así, nosotros, los que programamos, sabemos que un buen programador no es que valga x2 o x3. Vale mucho más. Mientras que un mal programador ya no es que sume poco, es que llega a restar. Lo sabemos porque lo vivimos a diario, pero comunicar esta lección a otros niveles no es fácil.
Un futuro mejor pasa irremediablemente por medir la calidad de un proyecto, y por tanto medir la calidad de sus programadores. Con números delante, todo el mundo es capaz de medir y comparar. Para ello se puede (1) medir la calidad del código mediante métricas de análisis estático, (2) medir la cobertura de tests unitarios del código y (3) definir tests de aceptación funcionales y de esfuerzo sobre la aplicación. Con lo primero medimos mantenibilidad, con lo segundo fiabilidad y con lo tercero eficacia, estabilidad y escalabilidad.
» Leer más, comentarios, etc...
más que código - Articulo - Programación
No a las patentes de Software
Julio 6th, 2009 - [Enlace local]
Ya he hablado muchas veces de las patentes de software.
A través de ATI he sabido de una campaña de información y recogida de firmas
En la petición se insta a los legisladores a:
- decretar leyes nacionales que clarifiquen la exclusión de las patentes de software de lo que puede ser patentable;
- en las patentes concedidas anular todas las partes que puedan ser infringidas ejecutando software en aparatos programables;
- también un esfuerzo por propagar estas normas a nivel europeo, incluido el Convenio sobre la Patentes Europeas.
Se incluyen referencias a artículos y estudios que muestran lo perjudiciales que son estas patentes. Yo ya he firmado. ¿Por qué no lo haces tú? :-)
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Cuanto vale un experto en programacion
Julio 2nd, 2009 - [Enlace local]
Estamos acostumbrados a enfrentarnos a nuevos problemas por nosotros solos a diario. No nos queda otra. El aprendizaje a base de ostias investigación, prueba y error es una realidad por la que todos pasamos y que viene a cubrir las carencias de los sistemas de formación profesionales.
Pero muchas veces podemos dedicar días y días, incluso semanas, para dar con la solución. Se soluciona sí. Se aprende también. Pero no es eficiente. Por un lado, tiene un coste psicológico en la persona o equipo en forma de stress, desmotivación y quemado. Por otro, tiene también un coste económico en las cuentas del proyecto. Y hasta puede tener un coste en imagen si el cliente se entera o simplemente por entregar con retraso.
Contar con un experto podría resolver el problema de forma eficiente a la vez que mejoraría la formación del equipo. Por problema no sólo me refiero a un marrón, puede ser un conjunto de tareas importantes sobre las que el equipo no tiene aptitudes ni experiencia.
Conozco algunas compañías donde se cuenta con esa figura de experto al más puro estilo Señor Lobo de Pulp Fiction. Aunque son muy pocas y a veces el experto no es tan experto. Pero siempre está la opción de subcontratar a un verdadero experto para resolver el problema. En España no se lleva. Una pena.
Y todo este rollo al hilo de un sorprendente anuncio de Kent Beck en ebay, donde ofrece una sesión remota de programación en pareja de 2 horas. La sesión se hará mediante VNC para compartir la pantalla y Skype para comunicarse. Aunque puede ser para revisar código, las dos horas se pueden emplear en temas de diseño, testing o lo que se quiera. Va por 305 dolares pero aún faltan días para que se cierre la puja. Veremos como termina la cosa.
» Leer más, comentarios, etc...
más que código - Articulo - Programación
PragPub
Julio 1st, 2009 - [Enlace local]
La gente de The Pragmatic Programmer han lazado una revista digital: PragPub.
Sólo he leído el índice así que no es que pueda decir si está bien o no, pero viniendo de quien viene, merece la pena echarle un vistazo.
Como curiosidad: Aparte del PDF, lo proporcionan en formatos de “libro electrónico” como epub y mobi. Los tiempos están cambiando.
» Leer más, comentarios, etc...
más que código - Articulo - Programación
Libro: Founders at Work
Julio 1st, 2009 - [Enlace local]
Leyendo hoy la entrada sobre una entrevista al fundador de HOTorNOT en Pensamientos ágiles he recordado un libro de entrevistas a fundadores de empresa de tecnología que ley hace algún tiempo: Founders at Work
Es un libro que me gustó mucho y que recomiendo a cualquiera interesado en estos temas. En él se entrevista a muchísimos emprendedores, los fundadores de empresas como flickr, delicious, paypal, 37signals y así 33 entrevistas a cual más interesante.
Una cosa que me gustó mucho fue las distintas perspectivas que te ofrece toda esta gente: Ideas, escalabilidad, momentos bajos y altos, …
Se puede leer una buena parte del mismo en Google Books.
Eso sí, es un libro infeccioso. Leerlo y querer montarnos nuestra propia empresa, es todo uno :-)