¿Hace falta que un Tester sepa programar?

Esta es otra afirmación que me ha sorprendido y mucho, y que he oido mucho hablar de ella durante mis muchos años de práctica. A ver. La técnica que suelen usar los bloggers normalmente es plantearlo como una pregunta. Pero en realidad, muchas veces ya se tiene la respuesta, y el post se limita a dar una avalancha de argumentos a favor de su postura. Vamos a intentar dar una vuelta a los argumentos a favor y en contra. Pero ¿porqué programar? ¿porqué no hablamos de otros conocimientos como: UML, arquitectura, lenguajes de programación, herramientas de desarrollo,  herramientas de testing, sistemas, análisis...? Me da la sensación de que esta afirmación viene siempre de gente con un fondo importante en programación, y que por  tanto da mucho valor a este rol (y no digo que no lo tenga), y que sin querer desprecia el resto de roles en el ámbito del desarrollo software.

Dando una vuelta por internet, me encuentro con argumentos a favor y en contra. Pero sorprendentemente, muchos más a favor. Vayamos viéndolos:

A favor:

• ¿Porqué no? He encontrado este argumento, y bueno...no se han roto la cabeza.
• Depende. Vale. Otro argumento bien fundamentado. No en serio, vamos a intentar profundizar sobre éste, ya que soy partidario de él parcialmente. Lo haremos durante el post.
• Todo ayuda. Ahí estoy de acuerdo. Cuanta más formación, mejor. Pero más bien la duda sería: ¿qué es mejor? ¿Que esté formado en programación y desarrollo (específico en lenguaje, en plataforma, en arquitectura...)? ¿O que esté formado en el negocio del cliente, que conozca su forma de trabajo, sus necesidades, su lenguaje específico? ¿Qué debe hacer realmente un tester?
• Para poderle explicar al programador dónde está el fallo, ya que el conocimiento de programación le puede hacer inferir qué problema tiene, y así le ayuda a corregirlos antes. Este argumento me sorprende y mucho. Salvo que el tester sea uno de los programadores, y conozca la arquitectura en detalle, es difícil (por no decir imposible), que el tester sepa qué y porqué falla algo. Estoy de acuerdo, que cuando con nuestra experiencia, los que hemos programado hacemos pruebas, podemos tener sospechas de porqué falla algo. Pero de ahí, a que realmente sea útil esa sospecha, es concedernos un criterio excesivo.
• Para poderle aportar al programador experiencia sobre cómo corregir sus fallos, de forma que su código sea más seguro y fiable. Esta también me ha sorprendido. Entonces qué queremos ¿testers o formadores? Esta es la visión típica de la persona que ha probado mucho, pero también ha programado mucho. Pues claro que tendrás experiencia en fallos/soluciones típicas. Pero es mucho más complicado que eso. Si estamos en un mantenimiento, no vamos a tener tiempo de tonterías: hay que resolver la incidencia para cumplir el ANS (Acuerdo de Nivel de Servicio). Y si no es un mantenimiento, si de verdad tenemos tiempo de ponernos a hablar y discutir con el programador todos y cada uno de los fallos encontrados....yo quiero trabajar en ese proyecto, y lo quiero YA. Aquí se mezclan churras con merinas. De acuerdo que programadores que han hecho mucho testing, son los más adecuados para transferir ese conocimiento. Pero eso no significa que el tester deba hacerlo, porque la forma de corregir los defectos puede depender de la arquitectura específica, y el tester no tiene porqué conocerla. De hecho, en la mayoría de los casos, lo que interesa es presentar un informe de resultados de defectos al cliente y/o al jefe de proyecto. La solución de los problemas, su prioridad, etc., dependerá de muchos factores (y no tiene porqué ser el criterio del tester, y mucho menos del programador).

En contra:

• No debe condicionarse al tester con el conocimiento interno de la aplicación. Las pruebas deben realizarse siguiendo las indicaciones del plan de pruebas. Ahora bien, si no hay plan de pruebas, no hay casos de pruebas, ni datos de prueba, ni resultados esperados…no necesitamos un tester que sepa programar. Necesitamos a Dios.
• El conocimiento de la aplicación (léase documentación, arquitectura, análisis, etc), puede estar obsoleto. Si defendemos las metodologías ágiles, es posible que el tester no cuente con documentación actualizada de “qué hay dentro”. Si aceptamos que esto sea así, ¿cómo vamos a exigirle que entienda algo que seguramente no le sirve? Dejémosle que pruebe lo que debe probar, y que no esté pensando en "lo que hay detrás".
• ¿Debe alguien que se prueba la ropa saber coser? ¿o hacer pantalones, o cortar telas…? ¿Deben los inspectores de calidad de un edificio saber poner ladrillos, etc? ¿Debe un técnico de ITV saber construir un coche? (puede que ni siquiera le haga falta saber conducir)
• Un tester debe ser objetivo. Su resultado es un informe de pruebas. Si su resultado son consejos a los programadores, tendremos a un arquitecto, analista o programador “power”, cuyo tiempo estaría mucho más aprovechado revisando la arquitectura y el código (o formando al equipo), que probando.
• A un programador difícilmente le puede aportar un resultado de pruebas del estilo: "yo creo que te falla la punta de la trócola cuando el cimborrio izquierdo recibe un valor trambostático". Si la conclusión del tester no es objetiva, acabaremos creando una cadena de opiniones que finalmente perviertan el resultado de la prueba, y por tanto, la invaliden. Al programador hay que darle algo objetivo: se da el fallo x cuando en la situación y meto el valor z. Esto es algo repetible y objetivo. Por ejemplo: no le puedo decir: "me parece que en algunos ordenadores el color de fondo es más claro". Sino que si soy un tester debo decir: "en las pruebas X, en el ordenador Z, el color de fondo se ve más claro".  

Yo creo que la conclusión sería ésta:

• Si el equipo y el proyecto son pequeños, no te queda otra: no es operativo tener un señor sólo para probar, a no ser que sea un recurso compartido entre proyectos. Aquí normalmente no es que haga falta, es que simplemente este tester tiene también otros roles.
• Si el proyecto es mediano o grande, se hace necesario un tester especializado en esa tarea. Y aquí es cuando es menos significativo que el tester sepa hacer otras tareas.
• Si sólo llevamos un proyecto en la empresa: aquí la visión es otra: necesitas alguien que haga el testing, pero que también te de soporte a más tareas. Además, es más fácil que el tester esté versado en el negocio del cliente, la arquitectura, etc, porque sólo hay 1.
• Si llevamos varios proyectos en la empresa: si el tester se comparte entre varios proyectos, es más difícil que esté puesto en el negocio, en la programación, la arquitectura...ya que pueden ser muy diferentes. Si el tester no se comparte entre varios proyectos, sino que hay uno por proyecto, entonces sí que es posible que aporte algo más.

Defectos de Scrum (I)

Recientemente se habla mucho de las ventajas de las metodologías ágiles, y en concreto de SCRUM. Sin embargo, aunque todos tenemos claro que no existen "balas de plata" que nos permitan solucionar las cosas como si cual varita mágica se tratasen, no se oye hablar apenas de los defectos de SCRUM.

¿Ah, pero es que tiene defectos? 
Pues claro. No existen metodologías todoterreno al 100% Vayamos viendo algunos. No con ánimo de decir: "mirad lo malo que es SCRUM" sino más bien "tened en cuenta esto en caso de que aplique a vuestros proyectos". Al final, lo importante es saber detectar los riesgos y mitigarlos adecuadamente.

1. En general, dificultad de aplicación en grandes proyectos.
2. Se requiere de un “agile champion”, experto en la metodología que monitorice su cumplimiento.
3. Parte del paradigma consiste en usar el método “tal cual”, evitando adaptarlo a la empresa (supuestamente esto saca a la luz problemas en la metodología de desarrollo existente). Claro, si por otro lado arrancamos con el método ya adaptado a la empresa, es posible que no estemos aprovechando las ventajas de la metodología ágil.
4. Plantea un problema si el desarrollo está restringido por una fecha de entrega y un precio de entrega cerrados por contrato
5. Presupone que los requerimientos cambian, pero no de forma que el cliente acepte un diseño funcional/técnico.
6. Presupone que el equipo está muy formado y motivado
7. Presupone que el cliente está muy involucrado en el desarrollo, participa de forma activa y continua, y revisa frecuentemente el avance de la funcionalidad conforme salen a la luz los sprints. Esto sin embargo no parece producirse en la mayoría de nuestros proyectos: el cliente participa, pero no hasta el punto de dedicar tiempo y recursos para revisar pequeños avances en el desarrollo.
8. Presupone que el cliente no exige ni necesita toda la documentación que manejan actualmente las empresas y que las diversas normativas internacionales requieren.

Parece que hay muchas, y así es. Pero esto no deja de ser una visión general de riesgos como en cualquier otro proyecto, pero esta vez desde el punto de vista de la metodología.

Para ver la segunda parte de este post, puedes hacer clic en este link.

Más de 1000 visitas

Pues vaya, ya hemos superado en este blog las 1000 visitas (quién lo iba a decir). La verdad es que un blog dedicado a guardar mis memorias y experiencias, tiene más de un seguidor. Parece que ya es algo más que una bitácora personal.

Bueno, vale, he tenido que dar dinero a la gente por leer mi blog, y he llegado a usar anuncios de páginas eróticas desviadas a este blog para conseguir visitas. ¡Eh, que no, que era broma! A ver si la voy a liar por hacer la gracia...

Pues me alegro mucho. Si de verdad sirve de algo, estará bien que la gente tenga en cuenta mis opiniones (ojo, he dicho en cuenta: como siempre, y como dirían en aquella serie "expediente X"...la verdad está ahí fuera...).

Yo lo seguiré disfrutando mientras lo escribo. Espero que tú, amigo lector, disfrutes también (estés de acuerdo, o en contra de mis reflexiones). Saludos.

¿Cómo se mide la calidad?

... O más bien debería ser más específico: ¿cómo se mide la calidad del software?

Parece ser que la calidad es el atributo favorito a la hora de ser incluído en propuestas y propaganda variada de los productos software, pero nunca nos hemos preguntado ¿qué es la calidad? ¿cuánta calidad tiene? ¿Si no puedo medir la calidad de un producto para qué me sirve que lo pongan en un folleto o hablen de él los comerciales? (si hasta los terremotos tienen una medida universal gracias al señor Richter).

Hace poco leía un blog y me sorprendía la frase: "no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no calidad". Por desgracia para el mundo del desarrollo de software, no es así. Claro que se puede ahorrar calidad. Simplemente, eliminando las actividades que le aportan y aseguran esa calidad.

¿Dónde está la calidad?:

• En arquitecturas conocidas, probadas y para las que se han obtenido datos de experiencias (buenas prácticas, problemas a evitar, cómo mejorar en el futuro, etc.) Es lo que se conoce como mejora continua.
• En las metodologías de trabajo conocidas y probadas. Y no sólo hablo de desarrollo. También de repositorios de documentos, tener claro quién es el responsable de qué...El tener el control de qué hay, dónde está, cómo acceder a ello, y cómo usarlo.
• En las pruebas del software antes de la entrega al cliente.
• En las pruebas del software en la implantación.
• En las auditorías de calidad.
• En las auditorías internas del equipo de desarrollo.
• En las revisiones entre pares (sí, sí, las Peer Review famosas).

¿Cómo medir la calidad? Pues midiendo la calidad de nuestro proceso de desarrollo:

• Calidad del análisis: ¿cuántos requisitos se han modificado? ¿cuántos se han añadido? ¿cuántos se han eliminado?
• Calidad del diseño: ¿cuántos cambios se han producido en el diseño técnico?
• Calidad de la arquitectura: ¿cuántos cambios de arquitectura se han producido?
• Calidad del desarrollo: ¿cuántos defectos se han detectado en pruebas unitarias?
• Calidad de las pruebas: ¿cuántos defectos ha detectado el cliente en producción vs defectos encontrados en pruebas en general? ¿cuál es el ratio nº defectos encontrados vs horas invertidas en pruebas?

¿Y la calidad del producto? Pues aunque está relacionado, tendríamos otros factores:

• Tiempo que lleva el cliente usando el producto. En mi opinión no es significativo. Por razones varias, el cliente puede verse obligado a usar un pésimo software. Realmente el problema está en la competencia y en el precio. Si es suficientemente barato un software alternativo, poco importará la calidad de nuestro software, es probable que el cliente acabe actualizándolo por otro distinto, si los costes encajan.
• Satisfacción del cliente. Bueno, volvemos a la cruda realidad. ¿Quién es el cliente? ¿El director general? ¿el que compró el software? ¿El jefe de departamento que lo usa? ¿Los usuarios finales? Al final, la satisfacción es difícil de medir. Bueno, para eso podéis leer mi anterior blog sobre encuestas de satisfacción.
• Número de fallos en producción. Realmente no sólo es una medida de calidad del software, sino de su proceso de desarrollo.
• Número de clientes. Pues ahora mismo se me ocurren unos cuantos ejemplos de software vendido por millares (por no decir millones), y de calidad pésima. Al final, el número de clientes lo deciden una serie de factores ajenos a la calidad: precio, esfuerzo comercial, renombre de la marca comercial, etc.
• Número de años en uso. Uf. Por esa regla de 3, tendríamos que el software hecho en cobol en los años 80 debía de ser de calidad asombrosa, porque se ha usado hasta hace muy poco, o sigue en uso. A la hora de la verdad, este factor no depende de la calidad, sino de la competencia, de la facilidad de actualizar el producto. Si encontramos repuestos de ruedas, las cambiaremos fácilmente. Si no encontramos repuestos, pues...habrá que fastidiarse y seguirlos usando (independientemente de su calidad).

Lo importante es destacar que no tendremos calidad del producto basándonos únicamente en tener equipos de personas buenas y maravillosas, todos senior y super-motivados, y blah, blah. La calidad se consigue a través de un método, proceso y control. Quien confunde el control con desconfianza en el equipo, tiene un problema (y más vale que se lo haga mirar).

El siguiente link está en la línea de lo que digo, aunque hay varios argumentos en los que no estoy 100% de acuerdo (ojo, no digo que él esté equivocado):
http://geeks.ms/blogs/msierra/archive/2008/08/25/_BF00_C_F300_mo-se-mide-la-calidad-en-el-software_3F00_.aspx

Los 7 secretos del éxito.

Tras este pretencioso titular, encontramos siete recomendaciones para ayudarnos a establecer el éxito en nuestro trabajo, proyectos, etc. Aviso a navegantes de que si os parece rayante, os animo a leer el artículo original (url al final), y entonces me decís. Ale, ahí vamos.

Ya es hora de enterrar la idea de que el éxito, en cualquier profesión, es el resultado de suerte, oportunidad y esfuerzo. No hay nada más equivocado que esto. Pensad en ello. ¿cuántos profesionales conocéis que trabajen increíblemente duro, dedicando jornadas interminables, y no consiguen el éxito? El esfuerzo, tiene un papel en el éxito, pero el esfuerzo por sí solo no te va a hacer destacar. ¿Dónde se encuentra pues el catalizador del éxito?

1. Empieza por conocer con detalle lo que quieres.
Las personas de éxito, tienen muy claro en qué consiste el éxito que desean conseguir. Es la única forma de poder enfocar sus esfuerzos en su consecución.

2. Visualízate consiguiendo los resultados deseados
Los grandes ganadores se ven a sí mismo ganando cada día. Visualizar, es el camino a materializar lo deseado.

3. El éxito viene a través de una confianza férrea en tí y en tus capacidades
Los ganadores creen en su éxito, y esto acaba volviéndose realidad. Un error típico suele ser el creer que si se van obteniendo suficientes capacidades durnate nuestra carrera profesional, llegará el éxito. Sin embargo, la formación y la adquisición de capacidades no garantiza el éxito. Lo lo que lo garantiza está en el hecho de creer en él.

4. Los top-performes hacen las cosas como si ya hubieran alcanzado los objetivos que realmente quieren.
Los ganadores piensan, trabajan, hablan, juegan y hacen todo como la persona que quieren ser. Eso significa en enfocarse en las tareas como si ya hubiéramos estado donde queremos estar.

5. Toma la total responsabilidad de tu destino
¡Los ganadores obtienen resultados! No se trata de dar respuestas, de ofrecer EXCUSAS. Los ganadores no pierden de vista sus objetivos, y simplemente los cumplen.

6. Construye asociaciones de alta dependencia
Nadie en el mundo actual logra el éxito por sí solo. Simplemente hay mucho que entender y las situaciones cambian constantemente. Las personas de éxito siempre dedican más tiempo a otras personas de éxito. Se atraen. Van a los mismos eventos,  comen en los mismos restaurantes, juegan juntos al mismo deporte... Elige tus relaciones sabiamente.

7. Aporta valor por encima del que solicites
Hazte la pregunta: “¿Cómo puedo aportar más calidad? ¿Qué puedo hacer para hacerlo mejor?" Los ganadores siempre aportan un valor mkuy superior del que piden a cambio.

Fuente: http://build-business.info/seven-secrets-of-top-performers/

Personal Brand Online

Como respuesta a toda la fiebre de estar conectados y crear una "marca personal" online, Dilbert ataca de nuevo como sólo él puede hacerlo. Nuestra tira cómica favorita se sigue superando. Podéis seguirla como siempre en www.Dilbert.com

Hay otro problema que vengo observando recientemente, y es que en la práctica, hoy en día hay mucho más interés en aparentar, y tener una "marca personal", que realmente realizar ningún tipo de aporte. Es por eso que encontramos tantos blogs, twitters y facebooks repetitivos y amiguismos por doquier.

De ingeniería y programación

Leo un artículo, que me recuerda un antiguo mito, que sigue siendo una poderosa lacra en nuestra vida de desarrolladores de software...¿o debería decir ingenieros de software?

El problema es que se quiere evitar el uso de técnicas de ingeniería, el uso de la aproximación científica y el acopio metodológico tradicionalmente asociados al término ingeniería. Sin embargo, no son pocos los que se apuntan al carro de usar la coletilla "ingeniero" en su título o en su actividad, y defienden lo que una ingeniería debe ser (o al menos lo que ellos quieren que sea, acorde con sus expectativas).

Vemos habitualmente en blogs y artículos, la defensa de frases como "construir software no es como fabricar coches o casas". Normalmente los argumentos ofrecidos intentan separar el mundo de la ingeniería tradicional, con el de la construcción del software (aquí he evitado explícitamente el uso del término ingeniería del software). Lo peor de todo, lo que resulta más flagrante, es que se pretende apoyar el uso y efectividad de las metodologías ágiles como resultado de todo esto. Las técnicas ágiles están ahí, y son tan buenas como adecuadas en la situación concreta en que de buenos resultados. Pero eso no convierte en ciertos los argumentos.

Veamos algunos argumentos:

•  Los coches se fabrican en serie. Son todos iguales. El software es siempre distinto. Falso: realmente, al construir coches, es exactamente igual que en el software. Tenemos máquinas, robots y técnicas de ingeniería para tratar de que todos los coches salgan parecidos, pero es inevitable que todos salgan realmente distintos. Donde entra la ingeniería, es en tratar de que todos sean razonablemente parecidos, dentro de unos márgenes.
• La ingeniería es para fabricar "en serie", "como churros", al contrario que el software, que es siempre distinto. Falso: la mayoría de creaciones en el mundo de la ingeniería son únicas: puentes, pasos elevados, máquinas, mecanismos, etc. La visión de la ingeniería enfocada a la producción en serie es una manipulación enfocada única y exclusivamente a crear la ilusión de que la ingeniería y el software son radicalmente distintos.
• Las ingenierías clásicas precisan mucho de un diseño previo a la construcción, el disponer de los planos del arquitecto siempre antes de empezar el edificio. Falso: ¿es innecesario el tener las especificaciones de lo que hay que construir? Por supuesto que podemos construir casas sin planos, sin cimientos, etc. Eso no significa que la experiencia recomiende lo contrario.
• Los planos para construir son precisos. Falso. Existe una cosa en ingeniería llamada tolerancias. Significa simplemente que como las cosas se construyen de forma más o menos artesana, existen unos límites razonables entre lo que el ingeniero o proyectista desea, y los resultados reales obtenidos por la persona que realiza la tarea. Esto significa que el ingeniero desea un resultado, pero es consciente que al llevarlo a la práctica habrá desviaciones. Los planos pretenden que estas desviaciones, estén "contenidas". Además, los planos no son siempre tan precisos, puesto que muchas veces se deja en manos de quien fabrica, algunas tomas de decisiones, siempre que no se altere el resultado deseado.
• En el software, al contrario de la ingeniería, es casi imposible que no cambie el diseño. Falso al compararlo con la ingeniería. En ésta, incluso al fabricar coches (que nos parecen todos iguales aunque esto no sea así), las especificaciones cambian durante la creación de las máquinas que van a servir para construir los coches, durante la instalación de esas máquinas, pero es que también durante la vida del modelo de coche. Esto se ve incluso en las casas: los planos cambian durante la construcción (e incluso después).
• El sueño de construir software como en una cadena de montaje no es realista. Inexacto: no tiene nada que ver la fabricación en serie con el tema a tratar. Una cadena de montaje es un resultado de aplicar prácticas de ingeniería, pero no es la ingeniería. Realmente una cadena de montaje sería un software de creación de software (como puede ser Genexus). Alguien ha construído la cadena de montaje, que esa sí es el fruto del trabajo de ingeniería. Existen aplicaciones que son "fábricas de software", y que sí que tienen siempre el mismo resultado para los mismos datos y situaciones de entrada (de hecho mucho más que los coches en el caso de la fábrica, que como hemos visto, no son nunca iguales).

¿Qué ocurre entonces? ¿Estamos diciendo pues que son exactamente iguales la construcción del software y la ingeniería tradicional? Pues va a ser que no. Lo que significa es que la construcción del software no debe prescindir de una herramienta fundamental como son las técnicas de ingeniería, la planificación, etc. Por supuesto que podemos hacerlo. Como es posible hacer cualquier cosa. Pero vivimos en un mundo en el que no es despreciable el obtener resultados predecibles y controlados (dentro de unos márgenes, claro. Todo tiene su tolerancia). Las empresas necesitan prever los gastos que van a tener, porque normalmente (y digo normalmente), los empleados no estamos construyendo software sólo por amor al arte, sino que exigimos una remuneración a cambio. Y una remuneración fija. A ver si ahora vamos a inventar el cobro del sueldo "iterativo", basado en las funcionalidades que hemos completado.

El día en que la premisa fundamental sea tener un producto en el mercado a toda costa...habremos perdido una parte esencial de nuestra profesión.

Procrastinación (III): la multitarea

(fuente de la imagen: DevianArt)
Y no hay dos sin tres. Tras el éxito de los dos primeros artículos sobre la procrastinación, me he animado a un tercero, a ver si dejamos el tema cerrado de una vez.

Actualmente encontramos una tendencia de hacer muchas cosas a la vez. Nos gusta ser "multitarea", y nos sentimos orgullosos de ello. Pero...¿esto es realmente así?

Hay muchos detractores de esta supuesta multitarea, y entre ellos, existen muchas personas que aseguran que las personas que realmente se sienten multitarea, realmente se encuentran en uno de estos dos escenarios:

• Una tarea real y muchas distracciones
• Varias tareas, cuyo nivel de prioridad y atención cambian a lo largo del día.

En el fondo, cuando estamos haciendo varias cosas a la vez, lo que en realidad ocurre es que estamos procrastinando. Estamos restando la atención de una tarea principal, quizá la que realmente es prioritaria y la que tenemos que resolver.

Para realmente ser multitarea, el truco está en hacer una sola cosa a la vez, enfocando adecuadamente nuestro tiempo y esfuerzo en ella. Una adecuada planificación de las tareas durante el día, será la única forma en que realmente podamos invertir adecuadamente nuestro tiempo, y llevar a cabo varias tareas "a la vez".

Por ejemplo, actividades paralelas habituales como atender facebook, el correo, twitter, linkedin, etc., no son más que ladrones de tiempo, y fuentes de procrastinación. Lo mejor es establecer horarios específicos para atender estas tareas. Eso de estar permanentemente encima de la casilla de actualizar el email es una locura.

¿Que queremos seguir llamándonos multitarea? Adelante. Después de todo, nos engañamos con cosas peores en esta vida.

PMO: Introducción

Uno de mis últimos proyectos está siendo mi participación en una PMO. Vamos a ver qué es.

Una PMO es una Oficina de Gestión de Proyectos (las siglas vienen del inglés Project Management Office).

Este es el primero de una serie de artículos sobre PMO:
PMO I - Introducción
PMO II - Descripción
PMO III - Ventajas de una PMO
PMO IV - Inconvenientes de una PMO

Para qué sirve una PMO
Si ya tenemos un jefe de proyectos, ¿para qué podemos querer una PMO? ¿Acaso supone más burocracia y simplemente es otro nivel por encima del jefe de proyecto?
Las responsabilidades de una PMO y de un jefe de proyecto son muy diferentes. Una PMO da respuesta a una serie de cuestiones que se plantean en las empresas y que un jefe de proyecto no proporciona:

• ¿Cómo alinear los proyectos con los objetivos de la organización?
• ¿Cómo medir de forma uniforme los proyectos en mi organización? ¿Cómo mido su valor, su coste, su rendimiento en términos homogéneos?
• ¿Cómo controlo los riesgos de alto nivel, o los riesgos que afectan a varios proyectos?
• ¿Cómo controlo las dependencias entre proyectos?
• ¿Cómo priorizo los proyectos conforme a los objetivos organizativos?
• ¿Cómo gestionar la capacidad y el cambio en los diversos proyectos?
• ¿Cómo detectar los proyectos con mejor y peor desempeño? ¿Cómo reaprovechar las mejores prácticas de los proyectos con mejor desempeño? ¿Cómo evitar los problemas de los proyectos con peor desempeño?

Lo normal es que si vamos a implantar una PMO, pensemos en los siguientes grupos de procesos:

• Seguimiento de proyectos
• Comunicación
• Gestión del conocimiento
• Gestión de proyectos y recursos

Hasta aquí una breve introducción. Dejemos para otro día el detallar las actividades y procesos de una PMO. Nos vemos.

Nueva Dotnetmania

La revista DotNetMania, ahora es DotNetMania+
Han migrado de web, a una nueva url: http://www.dnmplus.net/

Además, por tiempo limitado, tendrán sus contenidos abiertos, aunque ya están preparando ofertas para suscriptores.

Se trata de un portal orientado a programadores, arquitectos en tecnologías .Net, e incluyen novedades, artículos, cursos, vídeos, entrevistas, todo ello enfocado al mundo .Net.

¿Cuándo se puede dar por terminado un proyecto?

Vaya. Esta vez he dejado pasar unos cuantos días desde mi último blog. Y es que mi últimos proyectos me estaban absorbiendo por completo.

Vamos a tratar un tema que tanto en las metodologías, como en los distintos entornos de trabajo, siempre se da por supuesto, y se deja un poco al azar. Y es que ¿tenéis claro cuándo se puede cerrar un proyecto?

Parece algo trivial, ¿no? Cuando el proyecto se termine...se habrá acabado y por tanto, se cierra. Pues no.Vamos a introducir algunos conceptos para entender de qué hablamos:

• Cierre: se denomina cierre de un proyecto, al final del desarrollo. En realidad, el desarrollo no termina cuando se produce la subida al entorno de producción. Un desarrollo termina...cuando así lo determina el contrato. Y es que por contrato (y así lo suelen recoger las metodologías), se incorpora un período de soporte distinto del de mantenimiento. Se le suele llamar soporte post-implantación (aunque el nombre puede variar según la metodología que tratemos).
• Soporte: como acabamos de comentar, se llama soporte al período posterior a la puesta en producción (el Go-Live en tecnologías SAP). El soporte lo realiza el mismo equipo de desarrollo, y aunque sus actividades suelen ser similares a las de mantenimiento, existen diferencias con la fase de mantenimiento. Por ejemplo, no aplican los ANS.
• ANS: acrónimo de "Acuerdos de Nivel de Servicio". Son las condiciones de servicio que por contrato, estipulan la forma de colaboración entre el proveedor del servicio y el contratista. Suele incluir penalizaciones y/o bonificaciones en función de varios parámetros como pueden ser el tiempo de respuesta, la calidad del servicio, etc.
• Mantenimiento: es la fase del ciclo de vida del software que tiene lugar tras el cierre (no tras la puesta en producción). Tras la puesta en producción, hay un período de soporte en el que el proveedor del desarrollo software ha estabilizado la solución, se produce el hito del cierre, y después, el inicio de la fase de mantenimiento. Esta fase de mantenimiento la puede llevar a cabo un proveedor distinto del de desarrollo (otra empresa diferente).

Y tras este rodeo de explicaciones, volvamos al tema. Tras el desarrollo, hay un período de soporte, normalmente de tiempo limitado. Pero...¿debemos dejar que un software erróneo, inadecuado o inestable pase a la fase de mantenimiento? ¿Cómo sabe el cliente que el producto que ha recibido y que ya está en producción, está como para dar salida al proveedor de desarrollo? Recordemos que es en este punto cuando suele terminar de cobrar el proveedor de desarrollo. El cliente no querrá terminar de pagar por un producto hasta que este no esté correcto, pero...¿qué entendemos por correcto?

Es en esta situación, en la que un proceso de cierre entra en acción, definiendo una serie de parámetros que permitan de forma cuantitativa identificar si la solución desarrollada está Ok o no. No se trata de que no tenga errores. De eso, ya se encarga el mantenimiento que se hace tras el cierre del proyecto. Se trata de demostrar estabilidad y madurez tanto en la solución desarrollada, como en su implantación.

Normalmente, en todas las metodologías, la forma de realizar verificaciones (peer review, auditorías, milestone reviews, etc) es mediante checklists de control. Sin embargo, estas checklists de control no suelen incluir factores cuantitativos. Aquí es donde las métricas suelen venir al rescate, incorporando factores cuantitativos.