Calidad y Software

Desarrollo en cascada (I)

2012-03-17T12:48:00.001-07:00

Tenía yo este post ya desde hace tiempo atascado. Quería hablar del desarrollo en cascada desde el punto de vista de la experiencia, y compararlo con las metodologías más actuales.. Y por fin me pongo a ello. Ya había hablado de las ventajas y desventajas de las metodologías ágiles como SCRUM o XP, y me parecía injusto no ser ecuánime con el waterfall.

Este post no le va a gustar a mucha gente. Está de moda el agilismo. Admitámoslo. Así que cualquier comentario que no defienda ciegamente SCRUM y no ataque despiadadamente a CMMi, metodologías tradicionales, desarrollo en cascada...causa desasosiego en las mentes que sólo ven blanco y negro. Pero el mundo no es blanco ni negro.

En un artículo que he leído hacer poco, leo algo que yo ya hace años que vengo observando. Aproximadamente cada década surge una nueva "guerra de metodologías":

En los 70 desarrollo estructurado vs tradicional
En los 80 desarrollo dirigido por datos vs desarrollo tradicional
En los 90 desarrollo orientado a objetos vs tradicional
En los 2000 el desarrollo ágil vs tradicional (algunos prefieren enfrentarlo a CMMi)

Pero claro, para los programadores más jóvenes, que no han desarrollado en los 80 ni en los 90, para ellos sólo existe algo "anterior". Ellos no han vivido las otras metodologías ni formas de trabajar. Algunos lo han estudiado en la universidad y se atreven a hablar de ello, pero no han sido conscientes, porque no lo han usado en su día a día (hablo de técnicas y metodologías de las llamadas "tradicionales").

En un post anterior, ya hablamos de las desventajas de SCRUM y de las metodologías ágiles en general. ¿Que qué estoy diciendo? Pues que efectivamente, existen puntos débiles en estas técnicas, por el mero hecho de que se basan en suponer ciertas características y restricciones, lo cual supone a su vez un riesgo y debilidad para nuestro proyecto.

Y ahora ¿qué? ¿A defender la obsoleta y moribunda técnica de desarrollo en cascada? Pues ni obsoleta ni moribunda, pero no hay porqué defenderla, sino entenderla en su contexto. En el desarrollo de software, echo de menos dejar de usar este tipo de abjetivos subjetivos por otros más profesionales como "apropiada para esto" o "inadecuada para lo otro". Y no me refiero al "depende" que muchos listillos de turno utilizan para intentar quedar bien, aunque no tengan ni puñetera idea de lo que hablan.

¿En qué consiste la metodología en cascada?
Esta metodología propugna que cada fase del ciclo de vida (SDLC del inglés Software Development Life Cycle), no debe comenzar hasta que esté totalmente terminada la fase anterior. Por ejemplo, no empezaríamos a programar, hasta tener la fase anterior de diseño técnico completada. ¿Y cuándo estaría completada? Pues cuando esté completado el entregable final, en este caso, el documento de "Diseño Técnico".

¿Qué presupone la metodología en cascada?
Este tipo de desarrollo presupone que en cada fase debemos estar preparados para la fase siguiente, porque:

El cliente quiere ver una documentación estable (tal vez no sea el cliente, sino una PMO que quiere coordinar varios proyectos que se producen a la vez).
Otros proveedores quieren también ver una documentación estable, porque han de interactuar con nuestro desarrollo, bien consumiendo servicios, o siendo proveedores de servicios que consumimos nosotros, y por tanto, han de conocer nuestras necesidades (por escrito, claro, porque las palabras se las lleva el viento).
Tenemos equipos bien diferenciados: los analistas funcionales son expertos en ese tema, tienen un coste alto, y por tanto, han de "usarse" al máximo en las fases donde su labor tiene máxima necesidad: en la toma de requisitos y análisis. Posteriormente, pasaremos a utilizar otro tipo de perfiles diferenciados, los analistas técnicos o diseñadores técnicos, especializados en aterrizar los análisis funcionales en un documento técnico. Finalmente, los programadores, especializados en seguir un documento técnico bien preparado, construyen el código....y así hasta el final.
La metodología en cascada presupone también que los cambios son costosos, por lo que hay que definir al máximo la solución al principio. Un cambio se comporta como un bug: aleja a la solución final del objetivo deseado. Es por ello, que cuanto antes se identifiquen, mejor.

¿Cuál fue el origen de la metodología en cascada? La causa
Todo lo dicho en el apartado anterior, hizo que en los años 90 sobre todo, la forma de trabajo de las factorías de software y las consultoras, provocara que la especialización por un lado, y el hecho de contar con personal poco experimentado por otro, esta técnica fuera necesaria y efectiva. Ojo cuando digo efectiva, porque aquí de nuevo se tirarán de los pelos los que solo ven agilismo: los proyectos de software siempre han fallado. Lo que digo no es que esta técnica fuera perfecta, sino que para las condiciones existentes, era muy adecuada. El "poder", la iniciativa, no estaba en los programadores. Los programadores iban y venían en los equipos. Era normal tener equipos de 10 personas al inicio del proyecto, y que muy pocos de ellos llegaran a ver el final del proyecto. La rotación era muy alta.

Y hasta aquí la primera parte. Vemos el origen. Pero ¿qué falló? ¿Porqué la metodología waterfall nos llevó a hacer proyectos con retrasos y poca calidad? Eso lo veremos en el siguiente post.

Evento Microsoft - Aplicar DI en MVC (23-03-2012)

2012-03-14T03:54:00.002-07:00

Para los que no lo sepan, DI son las siglas en inglés de Dependency Injection (Inyección de Dependencias). El próximo 23 de Abril, tendrá lugar un interesante evento (online y gratuito), donde se explicará en detalle en qué consiste DI, y cómo usarlo en proyectos MVC.

El link de registro y más información:
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032508692&Culture=es-ES

Evento Sharepoint (14-03-2011)

2012-03-13T06:54:00.003-07:00

Este miércoles 14 de Marzo, tendrá lugar el evento online y gratuito: "CHARLA CON LOS EXPERTOS: TODO LO QUE SIEMPRE QUISISTE SABER SOBRE SHAREPOINT, PERO NO TE ATREVISTE A PREGUNTAR". Son 90 minutos, y comenzará a las 16h (GMT+1).
Es un buen momento para actualizar conocimientos en Sharepoint, o si os sentís con ánimos, lanzar dudas técnicas para que los mayores expertos en Sharepoint de habla hispana os puedan ofrecer soluciones.

Daros prisa, que se acaba el tiempo. El link de registro para este evento es:
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&eventid=1032506778&flag=1

Cómo no hacer un currículum

2012-03-12T14:07:00.001-07:00

Vemos habitualmente currículums mal escritos, con información falsa, o alterada para dar una sensación de mayor experiencia y profesionalidad, de mayores éxitos de los logrados, etc.

Seguidamente vamos a ver algunos de los "errores" más habituales en los CV. Pero antes, veamos uno de los peores:

1. Desviar la atención. Esta técnica permite, cuando no se tiene experiencia o éxitos que comentar, desviar la atención en un punto supuestamente positivo, pero que no aporta nada realmente. Por ejemplo: si no tenemos ningún logro o éxito significativo que comentar en nuestro actual empleo, pero hemos tenido una buena evaluación o hemos sido promocionados de categoría, hay quien lo pone en el currículum, lo magnifica, y oculta de este modo la atención sobre otros elementos que podrían disminuir la buena impresión global. Es normal que un recién licenciado, ante la falta de otra información adicional, diga: "saqué matrícula de honor en el proyecto de carrera", o que diga las notas o hitos principales en su titulación. Vale, es normal, no tiene otra cosa de qué hablar. Lo que no es tan normal, es que gente que promulga experiencia y saber hacer, a la hora de la verdad ponga en el currículum este tipo de frases que contradicen dicha experiencia y saber hacer.

Viendo los currículums de gente con falsa experiencia, se suele encontrar frases como:

"Experiencia multidisciplinar". Vale, la palabra suena bien, pero no me dice nada sin el matiz apropiado.

Conocimiento y ¿experiencia? en diversas tecnologías y lenguajes de programación (por supuesto, siempre tratando de dar pocos detalles al respecto, y siempre de forma vaga respecto a los proyectos y a los períodos de aplicación). A ver señores, en nuestra vida laboral, y llevo en esto más de 15 años, no manejaremos más allá de 4 o 5 lenguajes principales. El resto, por supuesto que hemos estudiado, o usado puntualmente docenas de lenguajes. Pero el uso puntual no da el conocimiento, y la experiencia en los lenguajes se pierde en pocos años.

Buenas evaluaciones de rendimiento recibidas en la empresa. ¿!!! Sí, bueno, claro que alguno de mis antiguos jefes me alabó, me subió el sueldo, o me subió de categoría (normalmente no todo a la vez)...¡pero no lo digo en el currículum! Mi profesionalidad no se mide por las subidas salariales que he recibido, sino por los retos superados (aunque es un reto que te suban el sueldo, creo que no estamos hablando de eso).

Han llevado equipos de más de 20 personas ¿? Bueno, sí, una vez llegaron a estar 20 personas contando al fontanero, la secretaria, y la de la limpieza. Quizás han contado a todos los que han pasado por el proyecto, pero nunca estuvieron todos de forma coincidente. Pero sería más exacto decir de 3 a 20 personas, o usar la media del período. Incluso he visto gente de proyectos SCRUM con jerarquía nula, hablar de que han llevado "N" personas...¿pero llevar qué de qué? ¿Pues no era SCRUM? ¿No erais todos los del proyecto "iguales"? Seguro que si revisamos el currículum de los 20 del proyecto, resultará que todos han sido los jefes de los otros 19!!

Por supuesto que todo ayuda, pero no puede este tipo de información ser nuestra principal identidad.

A mí todo esto me da una sensación horrible. Un currículum no puede estar tan vacío. Se supone que habla de nosotros. Y si lo mejor que podemos decir de nuestra profesionalidad es que nuestro jefe nos hizo una revisión anual positiva...o que nos subió muchas veces el sueldo...pues cásate con tu jefe!

En serio, debemos siempre hablar de:

Éxitos. Pero éxitos tangibles: logré "x" mediante "y". Ejemplo: puesta en el mercado de una nueva aplicación desarrollada por nosotros mismos (o explicitar nuestro papel en su desarrollo), logrando una cuota de mercado "X", o logrando como clientes a los "TOP" del sector. O: desarrollo e implantación de una solución de xxxx que logró estar en el mercado durante casi 10 años y tener más de 20 grandes clientes del sector.

Formación: certificados relativos al puesto que estamos, o al que queremos optar. Si somos analistas funcionales, a buenas horas me va a servir un certificado de programación. Claro que está bien, y aporta, pero si veo a un jefe de proyecto obteniendo certificados de programación, voy a tener serias dudas de si realmente ejerce como jefe de proyecto. Del mismo modo que si yo veo a un analista recién certificado o con cursos de ITIL, CMMi, PMBOK, etc., voy a pensar que en realidad, ejerce de jefe de proyecto (o que se prepara para dicho cargo, lo cual es loable).

Continuemos con mentiras habituales en los currículums (fuente: link):

2. Estudios no realizados. Dos de cada diez españoles han declarado que han falseado su nivel de estudios en su currículum. Se pretende con ello ganar puntos ante el seleccionador. Es una de las mentiras más fáciles de detectar, porque lo normal es que se soliciten los diplomas y certificados que correspondan a la formación declarada. Una de las más frecuentes es asegurar ser un experto en un determinado programa informático sin serlo. Se trata de un grave error ya que se quedará en evidencia al comenzar a trabajar y tener que manejar dicho programa.

3. Mentir en el dominio de idiomas. También es habitual indicar que se tienen conocimientos de idiomas que en realidad se desconocen. O bien poseer un nivel más elevado del que se tiene. En este caso, es inútil indicar tener más nivel del real, pues lo habitual es que, para chequearlo, el entrevistador se dirija al candidato hablando en el idioma que dice conocer. Además, hay que tener en cuenta que muchas empresas suelen hacer pruebas de nivel para verificar dichos conocimientos.

4. Exagerar las funciones anteriores. El 43% de los españoles añade en su currículum vítae más responsabilidades de las que ha asumido en sus anteriores empleos. Un ejemplo: alguien que ha trabajado como vendedor, pero que asegura haber sido responsable de equipo o director comercial de una determinada empresa. En este sentido, hay quien exagera también los años de experiencia ejercidos en una determinada función. Un ejemplo de ello puede ser asegurar que se ha trabajado en una empresa durante varios años cuando en realidad sólo fueron 15 días.

5. Empresas en las que nunca se ha trabajado. Un 18% de candidatos miente acerca de las empresas para las que ha trabajado. Según el estudio de CareerBuilder, se han dado casos de candidatos que han mentido diciendo haber trabajado en una determinada empresa sin saber que quien le entrevistaba fue director de la misma. También, con el fin de engordar el currículum, hay quien declara haber trabajado en empresas que no existen. Son más difíciles de detectar las mentiras cuando las empresas en las que se dice haber trabajado han desaparecido.

Si has llegado hasta aquí, te habrás dado cuenta que seguramente tú también has hecho algo de esto alguna vez. ¿Y? Pues nada. Esto son malas prácticas, pero no significa que cada cual lo vea justificado para un fin. Desde luego, que por traer el pan a sus hijos, la gente está dispuesta a todo. Y más con los tiempos que corren. Seguro que a vosotros se os ocurren, o habéis visto más malas prácticas como estas. El problema, simplemente reside en que los currículums se usan de modo comparativo. Y como tantas cosas en esta vida, los honestos, los experimentados, están en desventaja.

De todas formas, se puede dar la vuelta: se pueden usar estas ideas, de forma sutil, para destacar auténticas buenas prácticas y experiencias, auténticos hitos y logros personales, para un buen currículum. Y ese era al final, el objetivo de este post.

Top Mantra de los Arquitectos (II)

2012-03-08T00:39:00.001-08:00

Este artículo es el segundo de una serie de dos. Para ver el anterior, clic aquí.

Tenía pendiente terminar este artículo que ya inicié hace algún tiempo. Vamos a ello. Estábamos hablando del Top 10 de los Mantras de un arquitecto de software. El post anterior repasaba los mantras del 1 al 5. Vamos a los números 6 al 10.

Mantra #6: ¿No estás en la capa de datos? Entonces no pongas SQL!
Tal y como establece SoC (Separation of Concerns), intenta poner cada cosa en su sitio, sin mezclar. Pon el código de acceso a datos y los detalles como connection strings, bien lejos. Tarde o temprano, tendrás que ocuparte de ellos, pero considera por separado las lógicas de negocio y presentación de cara a la persistencia. Siempre que sea posible, delega la persistencia en una herramienta ORM.

Mantra #7: la mantenibilidad es lo primero
A pesar de que ya hablé en mi post sobre los mitos de la mantenibilidad, Dino Exposito tiene más razón que un santo al establecer que si hay que elegir un atributo para el software, como arquitectos, ha de ser la mantenibilidad, por encima de la escalabilidad, seguridad, rendimiento y testeabilidad. Si código y la arquitectura son mantenibles, el resto se puede conseguir más tarde (no así al contrario)

Mantra #8: el input del usuario es pura maldad
Tal y como comenta Dino en su libro, si existe una forma en que los usuarios hagan algo mal, encontrarán la forma de hacerlo. Si te suena esta afirmación a la ley de Murphy: SI, así es.

Mantra #9: Optimización Post-Mortem
Tal y como indica Dino (y estoy totalmente de acuerdo), empezar a diseñar un sistema con la optimización en mente es un error. Yo voy a ir un poco más allá: es un signo de inmadurez. Y me refiero a inmadurez profesional, a falta de experiencia. Tratar de que un sistema crezca siendo óptimo desde el principio es una buena forma de perder el foco de lo que realmente es importante. Es mucho más importante (ver mantra #7) que sea mantenible, ya que ante cualquier cambio, podemos optimizarlo. Un software muy optimizado desde el principio, seguramente no será mantenible y por tanto, ante cualquier cambio (que los habrá, no os preocupéis), dejará de ser óptimo. Y por desgracia, en esa situación, ya poco habrá que hacer.

Mantra #10: La seguridad y testeabilidad, han de estar "por diseño".
Aquí poco hay que decir. Es tan radicalmente cierto, que incluso hay un estándar de la International Organization for Standardization (ISO) que explícitamente, lo establece. Un sistema, por mantenible que sea, es muy complicado (y por tanto caro) que sea seguro a base de hacer cambios. Lo mismo la testeabilidad. Si no empiezas diseñando para que sea testeable, con sus pruebas unitarias, con la arquitectura adecuada...no podrás de repente implantar la testeabilidad.

Y nada más. Que os recomiendo encarecidamente este libro. Es de los pocos, junto con los del eterno Steve McConnell, que merecen la pena comprarse y leerse más de una vez. ¡Ah, y no me llevo comisión por decir esto, eh! Más info del libro:

by Dino Esposito and Andrea Saltarello
Microsoft Press. (c) 2009

Microsoft .NET: Architecting Applications for the Enterprise

SQL Server 2012 ya está aquí

2012-03-07T13:09:00.001-08:00

Im-presionante. Sencillamente impresionante. Estoy ahora mismo viendo una de las presentaciones técnicas correspondientes al evento de lanzamiento de SQL Server 2012. Ésta en concreto (hay más de 30, para no aburrirse), trata de la nueva característica de ColumnStore Index.

Se trata de una nueva técnica de almacenar los datos, facilitando la compresión, el acceso y la ejecución de consultas (incluso mediante paralelismo). Para no enrollarme (y así no perder el hilo de la señora), nos acaba de hacer una demo de una compleja Query: 1:29 segundos sin ColumnStore Index. Con esta característica activada...2 segundos!

Además, los datos de compresión (volumen real de los datos en disco), están en casos reales entorno un ratio de entre 15:1 y 4:1

¿Qué supone esto? BI más ágil. Menos esperas.

¿Cuándo son más útiles los ColumnStore Index?
a) Workload

Principalmente lectura
Principalmente incorporación de datos nuevos
Star Join Queries
Consultas de agregación de grandes volúmenes de datos

b) Workflow

Permite la partición para tratar nuevos datos
Caso típico: carga nocturna

c) Data selection

Large fact tables
Large dimension tables

El tema es que cuanto mayores son las tablas a tratar, algo especialmente cierto en entornos BI, mayor es el beneficio obtenido de esta técnica.

Best Practices: Crear un ColumnStore Index

Incluir todas las columnas en el ColumnStore Index
Convertur los datos decimal/numeric a precisión <= 18
Usar integer donde sea posible
Grandes cantidades de memoria para crar el columnStore Index
Crear el ColumnStore Index a partir de un Clustered Index

Y bueno, ya vale. Ahora a digerir toda esta información!!

Lanzamiento de SQL Server 2012

2012-03-05T06:43:00.000-08:00

En un evento multitudinario, Microsoft va a presentar el próximo 7 de Marzo de 2012 su nuevo sistema de servidor de base de datos (SQL Server), en su encarnación 2012.

Esta vez, y como ya empieza a ser habitual, Microsoft ha tirado por la ventana y ha apostado por una presentación por web:

Más de 30 eventos
Foros con expertos que darán respuestas a las dudas
Premios, que serán alcanzables mediante los puntos que se obtienen al participar en las diversas actividades que tendrán lugar.

Más información de los eventos, y página de registro, están disponibles desde cualquiera de los sitios internacionales/locales de Microsoft SQLServer. Uno de ellos (y en castellano):
http://www.sqlserverlaunch.com/LATAM/Home

AADL: un lenguaje de modelado para Arquitectos de Software

2012-03-05T05:39:00.001-08:00

Hoy voy a hablar del AADL, un lenguaje para nada nuevo, y que sin embargo es bastante poco conocido. Vamos a revisar algunas de sus características generales:

Existe como estándar internacional desde 2004.
Nació como lenguaje orientado a entornos de aviónica, pero actualmente su alcance es mucho más amplio.
Está promovido por el SEI
Pretende estandarizar en un lenguaje de modelado, el diseño de arquitecturas (hardware y software).
Nació para sistemas embebidos, por lo que admite hardware y software.
Es un lenguaje textual y gráfico.
Incluye un formato de intercambio XML/XMI que permite interoperabilidad con herramientas del mercado
Dispone de una extensión para el modelado de sistemas resistentes/tolerantes a fallos.

Puede utilizarse para modelar:

Sistemas empotrados, como arquitectura de sistema basada en componentes.
Las interacciones de los componentes mediante flujos, llamadas de servicio y de acceso compartido.
Ejecución de tareas, sincronización exacta de comunicaciones.
Plataformas de ejecución, application binding, modelos operativos y configuraciones tolerantes a fallos.

Hay muchos otros lenguajes de modelado, pero éste me ha parecido curioso y me apetecía echarle un vistazo y compartirlo.

Ejemplo.
A continuación, un ejemplo sacado de la página de AXLOG:

system system1

end system1;

system implementation system1.impl

subcomponents

p1: process process1.impl;

p2: process process2.impl;

connections

cn: data port p1.outport -> p2.inport;

end system1.impl;

process process1

features

outport: out data port;

end process1;

process implementation process1.impl

subcomponents

t1: thread thread1.impl;

connections

cn: data port t1.outport -> outport;

end process1.impl;

process process2

features

inport: in data port;

end process2; process implementation process2.impl

subcomponents

t2: thread thread2.impl;

connections

cn: data port inport -> t2.inport;

end process2.impl;

thread thread1

features

outport: out data port;

end thread1;

thread implementation thread1.impl

end thread1.impl;

thread thread2

features

inport: in data port;

end thread2;

thread implementation thread2.impl

end thread2.impl;

Os dejo con unos enlaces en los que podréis ampliar información:
http://en.wikipedia.org/wiki/Architecture_Analysis_%26_Design_Language (Nota: para ser Wikipedia, la verdad es que la información que da es bastante pobre a fecha 5 de Marzo de 2012)
http://www.sei.cmu.edu/dependability/tools/aadl/
http://www.axlog.fr/aadl/presentation_en.html (este enlace sí que tiene bastante información, ya que AXLOG es una firma miembro del comité de estandarización de AADL).

Excusitis: otra enfermedad del desarrollo de software

2012-03-04T09:18:00.002-08:00

Igual que existe la profesión más antigua del mundo, hoy hablamos de una de las más antiguas enfermedades en el desarrollo de software: la excusitis.

Parece que tenemos excusas para todo. Somos ingenieros. Tenemos la más alta formación, sin embargo, las más estúpidas excusas parecen salir una y otra vez de nuestras bocas de forma habitual. ¿Cuál es el problema? Como siempre, la causa más probable es el error humano.

Hay gente, que consigue prosperar a base de dos máximas:

Si algo sale bien, les falta tiempo para dar la cara para conseguir reconocimiento y fama.
Si algo sale mal, echan mano de la lista de culpables (que siempre tienen a mano), para conseguir su chivo expiatorio. De hecho, a veces consiguen incluso culparlos en la distancia (frases del estilo "yo no he trabajado con él, pero...<poner aquí cualquier frase que desprestigie al chivo expiatorio>")

Como ya comentaba en mi anterior artículo "¿Por qué fallan los despliegues en producción?", no debemos buscar los culpables muy lejos. Sin embargo, resulta mucho más fácil buscar culpables, que soluciones. Y las soluciones, están siempre en el mismo sitio: formación, buenas prácticas, usar tecnologías y métodos seguros y probados, y ser sobre todo, profesionales.

Veamos las excusas más habituales:

Reinicia, y si sigue pasando..vuelve a llamarme
El análisis funcional estaba mal
Es que alguien no está a la altura del resto y está haciendo que mi equipo no rinda bien.
Pero...¿y eso para qué lo quieres?
Ya se que no lo pidió nadie...¿pero te gusta?
Funciona...pero no lo he probado
ESTO...no puede ser la causa de ESO.
Es solo una desafortunada coincidencia
Pero si ese módulo no se ha tocado en meses!
Es que ese módulo está sin terminar
Esto siempre ha funcionado bien...
Yo no he tocado nada...
En mi equipo sí que funciona...
Pero si yo ya lo probé!
Pero si esto pasó todas mis pruebas unitarias!
Estás usando la última versión?
Este no es mi último código...¡alguien lo cambió!
Nunca había visto este error antes...
Ese no es mi código!
Creo que esto nunca había funcionado antes...
Creo que todavía no se han hecho los cambios en la base de datos.
Pero...¿eso estaba incluido en el diseño funcional?
Nadie me lo dijo.
Pero...¿no estarás usando el Internet Explorer?
No es un fallo...¡es una característica!
Seguramente hiciste algo mal para que fallase así.
Nadie me dijo que debía hacer pruebas unitarias.
Eso no estaba en mi plan de pruebas
Ayer funcionaba
¡Ya os dije que no me iba a dar tiempo de probarlo!

Fuente: http://whizzodev.blogspot.com/2008/02/top-13-excuses-for-software-developer.html

ASP.NET MVC (III)

2012-03-03T04:14:00.001-08:00

Este artículo forma parte de una serie. Podéis ir directamente a las partes 1 y 2.

Hoy vamos a ver MVC desde otro punto de vista. Primero, una comparación con los Web Forms tradicionales. En la figura siguiente, se ilustra bastante mejor esta significativa diferencia:

En primer lugar hacer notar que ya no tenemos los eventos, el ciclo de vida de los web forms a los que estábamos ya tan acostumbrados. Ya se rompe por fin el patrón de trabajo (artificial por otro lado), que habían impuesto estos web forms:

Procesar una petición
Entrar en el ciclo de vida del documento
Tratar el evento
Pintar los controles
Devolver el resultado

Además, el patrón de trabajo de Web Forms nos había acostumbrado a otras cosas totalmente ajenas a la realidad de la web, basándose en esa capa virtual:

RAD
Controles ricos
Modelo dirigido por eventos (lo comentado justo hace un momento)
Desarrollo parecido a Windows Forms. Sin querer, estamos creando la ilusión de que trabajamos con una especie de formularios Windows. Nada más falso, tal y como hemos visto en el ciclo de vida de los Web Forms, justo hace un momento.
Difícil implementación de TDD. No es nada imposible, pero la verdad es que con los Web Forms había que hacer auténticas piruetas para establecer un TDD en condiciones.
Páginas pesadas (por culpa del viejo conocido ViewState).

Aquí hacer un inciso. Anque MVC está muy orientado al uso extensivo de HTML5, CSS3 y Javascript, debemos ser conscientes de una serie de realidades:

HTML5 no está disponible para todos los navegadores, hay que validar las funcionalidades antes de usarlas.
CSS3 evoluciona mucho más lento que HTML5. TODAVIA NO ES UN ESTANDAR, sino un borrador. Hay que validar el soporte de sus funcionalidades en lugar de validar la versión del navegador o el tipo. No se trata de que Chrome o Firefox o X soporten CSS3...es que CSS3 aún no existe como tal, y está sujeto a cambios.
JavaScript: NO ES UN ESTANDAR! El estándar actual, es ECMA-262 (versión 5, Dic. 2009). Y a él nos tenemos que aplicar. Todo lo demás, será favorecer que nuestras páginas funcionen en un navegador y en otros no.

Estructura de una aplicación MVC

Volviendo a MVC, vamos a ver su estructura. Con MVC, trabajaremos con proyectos, no con sitios web ("web sites"). Es lo primero que observaremos, ya que al crear un sitio web con Visual Studio, lo haremos a través del cuadro de diálogo "Add New Project".

La mayoría de los contenidos son ya conocidos en un proyecto ASP.NET (como App_Data, Web.Config, scripts, etc.) Sin embargo, hay carpetas específicas de un proyecto MVC:

Content: en esta carpeta tendremos los archivos estáticos, como imágenes, hojas de estilos, y archivos html puros.
Controllers: en esta carpeta, encontraremos todas las clases controlador. En general, por cada entidad en nuestro modelo, tendremos un único controlador. Además, podemos definir otros controladores para otras acciones como: LoginController, HomeController, NavigationController...Como podéis ver, para las clases controlador, se suele utilizar la convención NombreEntidadController.
Models: Aquí se encuentra el código que representa el modelo de negocio. Este código interactúa con la base de datos y procesa las reglas de negocio. Si usamos Entity Framework, tendremos los archivos EDMX aquí. Por supuesto, podremos tener una dll separada, referenciada por el proyecto que contenga el modelo, por lo que en ese caso esta carpeta estaría vacía.
Views: Aquí encontraremos las vistas (páginas ASPX, ASCX y master pages). Normalmente, la convención indica que hagamos una carpeta separada para cada controlador. Aquí también hay una carpeta llamada Shared, que se usa para vistas comunes a varios controladores (como una master page).

Windows 8 Consumer Preview

2012-03-01T08:10:00.000-08:00

Pues ya está aquí. Y va a ser el tema de la temporada. El nuevo Windows 8 está disponible para descarga aquí en su modalidad Consumer Preview.

Una descripción detallada de novedades, la tenéis aquí.

Pues hala, a disfrutar hasta que caduque esta release, o deje de estar disponible para descarga. Recordad que como "Consumer Preview", esta versión de Windows no tiene coste, pero no deja de ser una BETA. Así que tomad todas las debidas precauciones, y leeros las notas de la release.

Hay muchísimas novedades, entre las que podemos citar:

Windows Store. Ahora será posible descargar aplicaciones como si estuvieramos en el móvil. Seleccionar, pagar (si no es gratis), descargar....y a disfrutar.
Metro Style. Nueva interfaz.
Búsquedas mejoradas.
Mayor seguridad. Tanto en navegación como en el PC.
Nuevo Internet Explorer.
Novedades para ITPros.
Charms: una nueva forma de interactura.

Saludos

Team Foundation Server gratis

2012-02-28T23:57:00.000-08:00

Pues sí, parece que vamos a tener una versión gratuita (Express) del Team Foundation Server. De esta forma, tendremos completamente cerrado el círculo de desarrollo con versiones 100% gratuitas, e integradas entre sí:
- SQL Server Express: base de datos gratuita
- TFS Express: repositorio de código y más, gratis
- Visual Studio Express: entorno de desarrollo multilenguaje gratis

Todo esto formará parte de la próxima versión de Visual Studio, reforzando la infraestructura ALM desde el punto de vista gratuito.
Más información en el link: http://blogs.msdn.com/b/bharry/archive/2012/02/23/coming-soon-tfs-express.aspx

Planning Poker

2012-02-24T03:46:00.001-08:00

Hoy me apetecía hablar del Planning Poker. Para los que no lo conozcáis, es una técnica de estimación basada en consenso. Se utiliza en muchos ámbitos, pero es especialmente defendida dentro del mundo de las metodologías ágiles. Ha estado especialmente vinculado a la metodología XP (eXtreme Programming), pero más recientemente se ha asociado casi exclusivamente a SCRUM.
Tenéis una descripción bastante acertada en Wikipedia. Aquí vamos a tratar de ir un poco más alla. Empezaremos resumiendo cómo funciona:

El grupo de estimación estará compuesto por un moderador y los estimadores (equipo de desarrollo). El Product Owner puede participar, pero no puede estimar las tareas.
Cada estimador debe tener un juego de cartas.
El moderador lee la descripción de la tarea (normalmente, la propia "Historia del Usuario"). El Product Owner puede aquí participar para aclarar alguna duda.
Cada estimador elige una carta y la coloca boca abajo en la mesa. Cuando todos los estimadores están listos, éstos darán la vuelta de forma simultánea, cada uno a su carta seleccionada.
Si las estimaciones varían mucho, los estimadores con mayor variación (más alta y más baja respecto a la media), exponen sus razones. Aquí deben participar todos, no sólo los responsables de las cartas discordantes.
Repetir el paso 4 hasta que las estimaciones convergan.

Hasta aquí todo bien. Hay mucha documentación en internet sobre cómo hacerlo, incluso algún sitio web que se ofrece para que hagas el planning online de forma gratuita (http://www.planningpoker.com/). Por cierto, que esto es especialmente útil para equipos distribuidos, aunque la paradoja aquí es que precisamente las metodologías ágiles están en teoría enfocadas a equipos no distribuidos.

Sin embargo, vamos a intentar como siempre, poner algo más...

Si has llegado leyendo hasta aquí y no tienes un montón de preguntas...anda...léelo otra vez. La cuestión es que el Planning Poker no estima en horas. Ni en días. No es una unidad habitual, es la llamada "Punto de Historia de Usuario". Es decir, después de una sesión de estimación con Planning Poker, saldrás de la reunión sin saber cuándo vas a terminar las tareas. Vale, en este momento, tengo a todos los agile-fans enviándome comentarios con amenazas. No, en serio. Lo que ocurre, es que la medida obtenida con Planning poker, es una unidad relativa. Se trata de una medida comparativa. Comparamos las tareas. es decir, una tarea será estimada con la carta del "3", si creemos que cuesta el triple de tiempo que la tarea para la que se estimó en "1". Es por eso, que las tareas estimadas con cantidades grandes, se suelen dividir en tareas pequeñas, que se vuelven a estimar.

Pero sigamos. Tenemos tareas pequeñas, todas bien estimadas, y ¿seguimos sin saber cuándo vamos a terminarlas? Sí, y No. En las metodologías ágiles, especialmente en SCRUM, existe un concepto llamado "Velocidad". Este término, viene a ser el número de "Puntos de Historia de Usuario" que según los datos históricos, somos capaces de llevar a cabo por unidad de tiempo.

Ventajas de Planning Poker

Hace divertida la estimación (después de todo, ¿quién se niega a sentarse en una mesa y jugar a las cartas en mitad del trabajo?).
Intenta evitar el sesgo que proporcionan las estimaciones de los falsos expertos.
Promueve la participación y la colaboración.
Aumenta el compromiso. Si la historia de usuario entra en el sprint, estaremos más comprometidos porque hemos participado en la estimación.
Abstrae el concepto de tiempo. Las estimaciones se hacen en puntos, y éstos son una medida proporcional a tareas simples.
Facilita la colaboración y estimación en entornos distribuidos (con las oportunas herramientas).

Desventajas de Planning Poker

No está enfocado a usuarios noveles. Una estimación basada en "puntos", es difícil que sea de utilidad a quien no tiene ya una cierta experiencia (y no sólo en ese proyecto), tanto en estimación como en desarrollo. Sin un mínimo de conocimiento, no es posible hacer la abstracción que te permita comparar la tarea estimada con otra distinta de referencia.
El llegar a un consenso, no garantiza el acierto. Así es, podemos estar de acuerdo en algo, y eso no significa que sea cierto. Aquí jugará mucho la experiencia REAL. Es decir, no sólo no hay que ser no-novatos, sino que además interesa que el equipo tenga varios expertos. Por desgracia, si está delante el usuario para ayudarnos en la estimación, o hay un jefe, es posible que nadie esté dispuesto a "dar la nota", y acabe llegándose a un consenso-porque-sí.
Es poco serio. Venga, hay muchísimos clientes que si tuvieran que asistir en una sesión de estimación, y vieran que lo primero que se hace es sacar una baraja....se echarían a temblar (justificadamente o no). Vamos, que no es exactamente la mejor imagen de seriedad.
Requiere de un histórico de información. Si no tenemos una medida de la velocidad del equipo, y no tenemos estimaciones anteriores para correlacionar esas estimaciones con las horas realmente requeridas, va a ser complicado que algún día podamos encajar puntos y horas. En relación con este concepto, he encontrado un post cuyo enfoque comparto. Y es que esto de abstraer la duración de las tareas, da miedo escénico. En dicho post, propone una aproximación inicial de basarse en datos históricos, combinada con el concepto de usar la tarea más pequeña, como "1 punto de historia de usuario". Así todo el equipo tiene un referente común de lo que cuesta hacer ese "punto".
Cultura. Requiere una cultura ágil enraigada. No veo a un manager o jefe de proyecto sin esa cultura ágil, oir hablar de que nos faltan "3 puntos" para terminar la iteración. A más de uno le entrará la histeria y soltaría frases como: "dejate de tonterías, lo tienes que terminar el viernes".
Por sí solo, no es una buena fuente de estimación. Sin embargo, esta técnica por sí sola, sí es una primera estimación, y se complementa perfectamente con otras técnicas de estimación como pueden ser WBS y las basadas en históricos, u otras técnicas basadas en parametrización.
Este método consume mucho tiempo. La idiosincrasia y el protocolo que requieren, desde mi punto de vista, parece más enfocado a acordar un resultado, que a que dicho resultado tenga algún parecido con la realidad.
Los Puntos de Historia de Usuario se enfocan en estimar el tamaño de lo que se construye, y evitan la realidad de que eso realmente no importa: de lo que se trata, es de estimar cuánto cuesta construirlo. Aquí, hay múltiples ejemplos en el mundo real: el hacer algo el doble de grande, no tiene porqué costar el doble. Quizás más, quizás menos.
El uso de Puntos, trata también de esquivar el equívoco que se produce al consumir la mitad de horas del proyecto. En este caso, un jefe de proyecto poco experimentado estará tentado de decir que estamos al 50%. Al hablar de puntos, estamos intentando que estadísticamente hablando, el error de estimación se diluya, consiguiendo que al haber transcurrido la mitad de puntos, estemos a la mitad de la iteración. Bajo mi punto de vista, esta afirmación presupone tantas cosas, que las veo prácticamente en la misma perspectiva: ambas respuestas están mal. y es que el haber completado la mitad de puntos, me dice lo mismo que en el primer caso (cambiando horas por puntos). Lo que sí es cierto, es que el avance no se debería expresar en horas, sino en funcionalidades. Por otro lado, la triste realidad que no podemos esquivar, es que al 50% de horas, hemos gastado la mitad del dinero. A ver como administramos lo que queda...

Al final, a pesar de parecer tan duras estas desventajas, es que la técnica está realmente bien. Como siempre, estas desventajas las tenemos que ver como riesgos que afectan al proyecto. Mi recomendación, que es la misma que el SEI y otras fuentes, es diversificar. No sólo el hecho de diversificar las personas que estiman, mejoran la estimación (en eso se basa esta técnica). Si además, combinamos varias técnicas, y sobre todo, nos apoyamos en datos reales históricos, tendremos la auténtica fuente de buenas estimaciones.

Y nada más, probadlo y obtened vuestras propias conclusiones. Me gustaría terminar recomendando una lectura relacionada, de un blog que suelo leer. Os lo dejo en este link.

Cuando la culpa es del usuario

2012-02-23T00:27:00.000-08:00

Muy bueno. Estoy leyendo un artículo en variablenotfound, donde el autor presenta varias situaciones históricas en que puesto que los programadores han asumido que la culpa de los fallos es del usuario, se vengan de él de alguna forma:

ID-10-T: es una forma de llamar al usuario IDIOTA (del inglés IDIOT, resultado de concatenar los caracteres el código de error "ID-10-T")
PEBCAK: Problem Exists Between Chair And Keyboard
PICNIC: Problem In Chair, Not In Computer
Layer 8 Error: en el año 1984, la organización ISO publicó el Open Standard Interconnection, donde se hablaba de 7 capas del software. La 8ª capa, como imaginaréis, corresponde al usuario.
RTFM: Read The Fucking Manual
Luser: término despectivo para usuarios poco (o nada) técnicos, y que deriva de la fusión entre USER (usuario) y LOSER (perdedor). Tiene su origen en una broma en el MIT nada menos que en 1975.

Al final, vemos que los programadores, hemos dedicado desde siempre una gran parte de su esfuerzo en criticar y ridiculizar a los usuarios. Vamos, que no os vayáis a creer que es algo de ahora. A todos nos molesta que los usuarios nos hagan consultas estúpidas. Como el tono del artículo original es de humor, dejo para más adelante otro artículo para criticar este tipo de posturas. Porque sí, el usuario tiene derecho a no compartir nuestra visión de la tecnología, y sí: el usuario tiene derecho a cometer errores. No se trata de que nos dobleguemos y aceptemos que cualquier cosa que diga el usuario es Ley. Se trata de que aceptemos que el cliente puede tener una visión diferente de la nuestra, o incluso equivocarse, y debemos:

Localizar la causa de la discrepancia.
Analizar y entender la postura del usuario
Aprovechar ese conocimiento para reenfocar nuestro servicio en un mayor beneficio mutuo

Frases célebres sobre la calidad

2012-02-22T02:24:00.000-08:00

A continuación, algunas frases célebres sobre la calidad:

"¡No me importa si funciona en tu máquina! ¡No estamos vendiendo tu máquina!" (Vidiu Platon)
"Programar es como el sexo: un único error y tienes que estar soportándolo toda la vida" (Michael Sinz)
"Hay dos formas de escribir programas sin errores; sólo la tercera funciona" (Alan J. Perlis)
"Puedes tener un software de calidad o puedes tener aritmética de punteros, pero no puedes tener ambas cosas al mismo tiempo" (Bertrand Meyer)
"Si McDonnalds funcionara como una compañía de software, uno de cada cien Big Macs te envenenarían, y la respuesta sería 'lo sentimos, aquí tiene un cupón para dos más'" (Mark Minasi)
"Codifica siempre como si la persona que finalmente mantendrá tu código fuera un psicópata violento que sabe dónde vives" (Martin Golding)
"Cometer errores es humano, pero para estropear realmente las cosas necesitas un ordenador" (Paul Ehrlich)
"Un ordenador te permite cometer más errores y más rápido que cualquier otra invención en la historia de la humanidad, con las posibles excepciones de las pistolas y el tequila" (Mitch Radcliffe)

Están extraídas de este blog de José M. Aguilar. Si os han gustado, en su blog hay muchas frases.

La carga de trabajo

2012-02-21T05:46:00.000-08:00

Este artículo está inspirado en un nuevo plugin que ha salido para JIRA, y que podéis ver en detalle en este link.

Lo interesante del tema, está en la imagen con que se muestran los distintos niveles de carga de trabajo:

Es decir, de lo que se trata es de repartir la carga de trabajo, para mantener a los dos primeros iconos ocupados (por su expresión, parece que se están durmiendo), mientras que a los dos últimos...pues eso, con verlos ya se ve que están algo agobiados y conviene quitarles faena. Esto de repartir la carga, tiene poco que ver con socializar el trabajo y conseguir el equilibrio, y mucho con el proceso ITIL de "Capacity Management".

Una reflexión interesante sobre la carga de trabajo, la podemos encontrar en este link, donde se establece la ecuación:

Productividad = Motivación - Procrastinación - Carga de Trabajo

Porqué fallan los despliegues en producción

2012-02-10T10:04:00.001-08:00

Es inevitable. Parece una ley de la naturaleza. Hemos desarrollado un software con todo nuestro cariño (vale, a veces sin tanto cariño). Hemos superado con éxito los despliegues en pruebas y pre-producción, las correspondientes pruebas en esos entornos, etc (porque...¿hacéis pruebas verdad?). Y vamos a instalarlo en el entorno de producción, llega el gran día...y el gran fracaso. ¿Qué ha pasado?

No nos engañemos, la única verdad es que algo hicimos mal. ¿Qué ocurre si vamos sin lista de la compra y nos dejamos algo? ¿A quién le echamos la culpa? Oigo excusas del estilo "es que lo planificamos bien...", "hicimos todo lo que pudimos...", "es que otras personas hicieron el despliegue...", "yo es que no estaba ahí...", "a mí nadie me avisó de que esto íba a estar así...".

Planificar un software es complejo, y exige un ejercicio de experiencia, método y disciplina, para que el resultado se acerque a la realidad. Sin embargo, en raras ocasiones el despliegue, el último esfuerzo, recibe la atención necesaria (vamos, básicamente, no aplicamos adecuadamente la experiencia, el método, y la disciplina). ¿Porqué? Analicemos un poco el tema.

Habilidades Técnicas.
Esta no parece ser la causa. Aparentemente estamos preparados para todo. Somos técnicamente competentes. No hay nada o casi nada del despliegue que se nos resista.
La verdad es otra. Aunque efectivamente, no suele ser un problema grave, las habilidades técnicas adolecen de estar sobrevaloradas por nuestra parte. Nos consideramos:

Power developers cuando apenas sabemos programar...
Arquitectos cuando apenas somos buenos programadores...
Expertos cuando no tenemos conocimiento ni experiencia ni para llamarnos arquitectos...

Esto, que merece un post aparte, tiene especial gravedad cuando usamos para nosotros la vara de medir tamaño "mini" (cualquier cosa que hagamos, nos convierte en expertos), y para medir a los demás usamos la vara "maxi" (para que alguien se gane nuestro respeto, ha de superar pruebas que ni la mitad de hackers en el mundo superaría).

Conocimiento del Entorno.
Esta ya sí que parece ser una de las principales causas. Después de todo, si falla la instalación es porque algo se ha producido en el entorno de producción, que era ajeno a nuestro conocimiento. Unas veces será porque no había algo instalado que debía de estar. Otras será porque falta una acción sobre el entorno (configuración, carga de datos, etc.). Sin embargo, no podemos echar las culpas a los demás. Somos los primeros responsables de identificar las necesidades (requisitos), obtener toda la información del entorno (hardware, software, horarios de acceso, ventanas de trabajo, etc). Cuántas veces le echamos al cliente la culpa de que su entorno esté configurado así o asá, de que su personal no haga las cosas que le pedimos...¿Hasta qué punto es realmente culpa suya?

Falta de Preparación.
Nos sobran conocimientos técnicos. Realmente nos sobran. Somos capaces de incorporar las últimas tecnologías (aún cuando realmente sean innecesarias). Pero falta preparación. Preparación de materiales, de avisar con adecuada antelación, de identificar las necesidades y sobre todo, falta experiencia y falta método.

Hace poco, conversaba con unos colegas profesionales en un foro internacional, sobre si era mejor utilizar una checklist donde lleváramos anotadas todas las acciones al detalle...o de si la experiencia y el "olfato" de perro viejo, eran lo más adecuado. Al final, pareció llegarse al consenso de que ambos son necesarios. Esta conversación, que espero rescatar para este blog algún día, podemos trasladarla a la disyuntiva entre usar: experiencia o un proceso detallado. Por desgracia, suelen faltar ambos. Veámoslo.

Falta de Experiencia.
Cuántas veces oigo de profesionales supuestamente experimentados, excusas para culpar a otros (o al aire, porqué no), de que su software no funciona tras ser instalado en producción. Enseguida la gente pone en su currículum X años de experiencia en programación, en tal o cual tecnología, en gestión de equipos, bla bla. Pero no he visto aún un currículum donde ponga: he instalado en entornos finales de cliente más de n-cientas aplicaciones, o cosas por el estilo. Y es que falta experiencia en despliegues. No sólo es haber trabajado en docenas y docenas de evolutivos en entornos de alta disponibilidad. Además, la clave es haber participado con éxito en el despliegue. Y cuando digo participación, no me refiero a mirar y esperar a que el cliente lo instale. Me refiero a DEFINIR los pasos y actividades de instalación...a prever las consecuencias y estados de cada uno de dichos pasos, y guiar al cliente por adelantado mediante un "Plan de Instalación".

Falta de Método.
Esta causa está muy relacionada con la anterior. Falta un método. Pero un método apropiado al cliente, a sus entornos, a su personal, a sus datos, a su forma de trabajar...
Es la misma situación que una toma de requisitos. En nuestra estupidez, culpamos al cliente "de no habernos sabido contar sus necesidades". Pues no. Es culpa nuestra, el no saber extraer la información adecuada. Los profesionales somos nosotros. El cliente sólo es...eso. ¿O es que tenemos nosotros la culpa cuando el médico nos pregunta los síntomas? Pues no. Si ser equivoca en el diagnóstico, le echamos siempre la culpa a él. Para eso es un profesional.
Pues cuántas veces me tengo yo que oir en esta profesión, justo la historia al revés. La culpa es del cliente. Que no ha sabido dar los datos, la información, los requisitos...
Creo que debería de haber una rama de ingeniería en excusas. Esa no la suspendería nadie.

Falta de Gestión.
Si las dos anteriores suelen fallar, no veamos ya la gestión. En nuestra prepotencia, nos presentamos en el servidor con le paquete de instalación, y no prevemos los contenidos básicos que un buen gestor ha de preparar:

Plan de trabajo
Recursos involucrados. Recursos opcionales.
Estimación
Plan de marcha atrás
Plan de contingencia
Plan de riesgos

Si has llegado a este punto, y has esbozado una sonrisa (especialmente con lo de la gestión), y estás convencido de que no es necesario nada de esto, éste artículo era para tí. Por desgracia, hay gente que es a las buenas prácticas como el agua para el aceite. Para ellos, tengo también en mente un post con un buen listado de excusas para diversas situaciones. Como decía un antiguo compañero:

"¿Para qué vas a buscar soluciones...si puedes encontrar culpables?"

Las 10 prácticas ágiles más útiles (II)

2012-01-30T03:18:00.000-08:00

Esta es la 2ª parte de una serie de artículos. Haz clic aquí para ir al post anterior.
Por fin, llega la segunda parte de este análisis de herramientas y prácticas ágiles, basado en los resultados de una encuesta sobre las 10 prácticas ágiles que los distintos votantes encontraban como más útiles.

Nos faltaban de repasar las cuatro últimas herramientas, que si bien estaban entre las 10 más útiles, la encuesta las dejaba muy por debajo de las ya mencionadas. Vamos a repasar pues las que faltan:

Digital / Analog Taskboard.
Es una herramienta de seguimiento de proyectos ágiles, donde la información se estructura como muestra la figura siguiente:

Este cuadro de mando tiene varias ventajas:

Visibilidad. Se ve de un vistazo la situación del proyecto a alto nivel, y da una visión del estado de la iteración.
Simplicidad. Es fácil planificar y replanificar. Basta con mover las hojas de tarea (tarjetas).
Disponibilidad. En el caso de equipos distribuidos, es especialmente útil la versión electrónica de este taskboard, permitiendo la visión/actualización desde cualquier punto.
Actualización del burndown chart

Release Planning
Planificación de la iteración. Es la fase de la iteración en la que se planifican las tareas de dicha iteración (se decide qué incluir en dicha iteración). Esto se hace en función de la capacidad de trabajo del equipo, y de la prioridad de las historias de usuario. Mediante técnicas como Pareto, se intenta realizar el máximo de historias de usuario, con el esfuerzo disponible para la iteración (capacidad del equipo).

Test Driven Development
(de Wikipedia): Desarrollo guiado por pruebas, o Test-driven development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requisitos se hayan implementado correctamente

Regression Testing
Las pruebas de regresión, son un tipo de pruebas orientadas a detectar nuevos fallos o fallos previamente detectados y ya corregidos, originados al realizar cambios en el sistema como pueden ser: updates, patches, cambios funcionales, etc.

Ahora que tenemos todas las herramientas identificadas, hagamos un breve análisis del resultado de la encuesta sobre utilidad, añadiendo un par de parámetros: coste de implantación y coste de uso.

	Coste implantación	Coste uso diario
Automated Builds	7	1
Continuous Integration	10	2
Daily Standup Meeting	0	1
Iteration Planning	2	2
Coding Standards	7	2
Unit Testing	8	5
Digital / Analog Taskboard.	3	1
Release Planning	2	2
Test Driven Development	10	3
Regression Testing	5	7

La tabla anterior muestra unos valores ponderados (no expresan horas ni ninguna otra unidad de medida, sino que son valores que yo he estimado a nivel comparativo, para hacer un análisis cualitativo). Usando los valores anteriores, y con un poco de matemáticas, llegaríamos a la conclusión de que si ordenamos la lista de prácticas por beneficio/coste de implantación, la lista quedaría así:

Daily Standup Meeting

Iteration Planning

Release Planning

Digital / Analog Taskboard.

Automated Builds

Regression Testing

Coding Standards

Continuous Integration

Unit Testing

Test Driven Development

Bueno, esto no es muy novedoso. Ya lo sospechábamos: la práctica que mejor resultado da, y que menor coste tiene, es el Daily Stand Up Meeting. Aquí ya, es cuando haríamos las reflexiones oportunas.
Y como vuelta de tuerca final, sería hacer los mismos cálculos, pero incorporando los costes de uso diario. Aquí ya dependería del proyecto, pero los resultados pueden ser algo de este estilo:

Daily Standup Meeting

Digital / Analog Taskboard.

Iteration Planning

Release Planning

Automated Builds

Coding Standards

Continuous Integration

Test Driven Development

Unit Testing

Regression Testing

Aquí ya vemos como se "recolocan" las prácticas, de forma que las que mejor rendimiento nos dan al proyecto, al mínimo coste, se han situado arriba, dejando relegadas algunas de las que más cuestan llevar a cabo. Por supuesto, esto ha sido un ejercicio que en la práctica habría que afinar mucho más, porque tanto las fórmulas utilizadas como los cálculos realizados han sido un tanto burdos para obtener resultados cualitativos. Os invito a todos a realizar algo similar aplicado a vuestros proyectos y costes, y ver qué prácticas son las que os da mejor ratio rendimiento/coste. Hasta la próxima.

Webcast con novedades del próximo Visual Studio ¿2012?

2012-01-11T05:30:00.000-08:00

A continuación, os presento un enlace donde podréis seguir mediante un interesantísimo webcast, las novedades del próximo Visual Studio.

Link: http://geeks.ms/blogs/gperez/archive/2012/01/04/grabaci-243-n-webcast-nuevas-caracter-237-sticas-de-visual-studio-2011-para-el-desarrollo-web.aspx

Formación gratuita sobre Dirección Ágil de Proyectos

2012-01-10T08:49:00.000-08:00

En LinkedIn he visto publicado un post interesante.

Para los interesados en la dirección ágil de proyectos, Kybele Consulting (consultora especializada en formación y métodos ágiles), ha lanzado un curso gratuito y no presencial sobre “Dirección ágil de proyectos”:

- Se enviarán las lecciones de forma semanal por correo electrónico

- Inscripciones en: http://www.cioagil.com/

- El único requisito es dar una cuenta de correo electrónico (corporativo o personal)

Nuevos Virtual Labs para SQL Server 2012

2012-01-10T02:37:00.000-08:00

Para probar las nuevas características de Microsoft SQL Server 2012, Microsoft ha dejado una serie de virtual labs disponibles para ello. Son entornos preconfigurados que facilitan el testeo de estas características.

Los tenéis disponibles haciendo clic en el siguiente enlace.

PMO (II)

2012-01-06T02:01:00.000-08:00

Continuando el post anterior sobre PMO, vamos a añadir una serie de conceptos. Una PMO se encuentra al nivel de la gestión del portafolio. Éste, estaría a un nivel superior de la gestión del programa, y finalmente, la gestión del programa estaría un nivel por encima de la gestión de proyectos. Vamos a ver sus definiciones con algo más de detalle:

Gestión de Proyectos (Project Management): la aplicación de conocimientos, capacidades, técnicas y herramientas sobre las actividades del proyecto para satisfacer sus requisitos. (Fuente: Project Management Institute)
Gestión de Programa (Program Management): la planificación coordinada, gestión y ejecución de múltiples proyectos relacionados que están dirigidos hacia los mismos objetivos estratégicos, de negocio u organizativos, para generar unos beneficios superiores a los que se hubieran obtenido mediante la ejecución individual.
Gestión del Portafolio (Portfolio Management): los procesos, el gobierno y las herramientas utilizadas para planificar, crear, asegurar, balancear y comunicar la ejecución del protafolio de proyectos IT.

La Oficina de Proyectos permite:

Gestionar de una forma integral la comunicación
Aumentar el valor de la marca
Crear capital humano
Reducir los ciclos de proceso
Atender a los clientes teniendo en cuenta los retos y oportunidades del futuro, y al mismo tiempo no perder la visión del conocimiento adquirido en el pasado.

El modelo de trabajo del Gobierno IT que realiza la PMO es el siguiente:

Investiga y capacita
Define prácticas, metodologías y herramientas
Asesora a las áreas ejecutoras
Monitoriza, controla y realiza el seguimiento
Establece y monitoriza métricas
Estima y realiza seguimiento a los beneficios
Comunica evolución de la práctica

Bajo la directriz de la PMO, las áreas ejecutoras (los proyectos):

Gestionan y ejecutan sus proyectos
Aplican métodos y usan herramientas
Crean informes de seguimiento
Siguen cronogramas
Siguen presupuesto
Evalúan la obtención de beneficios

Los Procesos definidos por una PMO, establecen un nivel de madurez DEFINIDO. Sería el equivalente al nivel 3 de madurez:

Nivel 5: Optimizado
Nivel 4: Gerenciado
Nivel 3: Definido (Procesos)
Nivel 2: Repetible
Nivel 1: Inicial
Nivel 0: ¡No Existe!

Dejaremos para un próximo post algunos temas interesantes como métricas, procesos, etc. de una PMO.

Checklists

2012-01-05T13:26:00.000-08:00

Las checklists (o listas de control, nombre con el que aparece en algunos sitios web), suponen una herramienta fundamental en el mundo del desarrollo software.

¿Que qué son?

Son como los puntos de control de un coche: una lista de verificaciones a realizar, de acciones a llevar a cabo para un fin único. Cuando llevas el coche a arreglar, sabes qué le van a hacer (o mejor aún, según cuánto pagues, sabes cuántas cosas van a comprobar). Si queremos verificar un vehículo, lo más fácil es coger una lista, y seguirla: neumáticos, aceite, etc, etc. Pueden extenderse fácilmente para cualquier cosa: lista de la compra, lista de cosas para un viaje, etc.
Ocurre lo mismo cuando queremos verificar algo en el mundo del software. ¿Cómo saber que lo hacemos bien? En el mundo del software son vitales ya que permiten aprovechar la experiencia de las personas, y resumirla en acciones concretas para tareas de control o verificación.

¿Que porqué son una ayuda fundamental?

Son sencillas de usar.
Disminuyen los errores en las cosas que hacemos.
Homogeneizan las tareas (sabes que todo el mundo van a seguir la misma secuencia de cosas)
Te permiten justificar ante el cliente u otra persona, qué has hecho exactamente. Si conforme hacemos las tareas de la checklist, rellenamos un S/N, o ponemos un comentario, quedará constancia de lo que se ha hecho y su resultado. Esto evita muchos problemas, y da una imagen de seriedad y profesionalidad.
Facilitan su uso por personal menos experimentado o junior.
Son fáciles de implementar como métricas (ejemplo: ¿cuántos puntos de control han fallado de los N de la checklist?)
Permiten hacer fácilmente comparaciones: si un software ha fallado el 20% de las pruebas de la checklist, puede usarse para compararlo con las mismas pruebas en otros productos software.
Se aplica a productos software, a sistemas, a documentación, a procesos, ... a cualquier cosa.

Las checklists son la auténtica prueba de madurez, un nivel superior de hacer bien las cosas. Ya no tenemos el conocimiento en nuestra cabeza, sino que los pasos/acciones a realizar, los compartimos en una checklist para que el resto del equipo pueda realizar las mismas tareas y llegar a conclusiones similares.

¿Y ejemplos concretos de ésto?

Pues cuando vayamos a subir algo a producción, podemos tener una checklist de pasos/pruebas a realizar. Pueden ser pasos previos (verificación de que está todo lo necesario, personas, equipos, etc.). También estarían los pasos a realizar para la propia subida a producción. Finalmente, se incluirían las tareas posteriores: verificar que todo está ok, borrar los ficheros temporales, hacer logoff con el usuario utilizado, enviar un correo de notificación de éxito, etc, etc.
También, antes de cada entrega de un documento al cliente, sería interesante tener una checklist del estilo: ¿tiene el formato adecuado (S/N)? ¿se ha utilizado la plantilla correcta (S/N)? ¿el contenido ha sido revisado (S/N)? ¿Se ha versionado correctamente (S/N)? ¿Se ha enviado a todos los destinatarios adecuados (S/N)?
Etc, etc

Así que ya sabéis. Poned más checklists en vuestra vida.

Las 10 prácticas ágiles más útiles (I)

2011-12-26T07:28:00.000-08:00

Hoy voy a hablar de un tema muy en boga: las técnicas o prácticas ágiles. De ellas, se ha hecho un estudio a expertos profesionales en la materia. El estudio ha sido conducido por Teodora Bozheva, una excelente formadora en algún curso de calidad en el que he tenido el placer de asistir. Podéis ver los datos fuente aquí.

Pero tal como estuve hablando con Teodora, los datos no son más que eso, así que me animé a pedirle permiso para a partir de sus datos, darle una vuelta de tuerca y llegar más a fondo. Vamos con ello intentar responder a varias preguntas no sólo sobre las técnicas agiles, sino también sobre nuestro propio conocimiento de dichas técnicas.

Vamos a partir de los resultados, que podemos ver en la siguiente gráfica:

Lo primero a destacar, es que no hay una diferencia abismal entre los primeros y los últimos en este grupo.
Vamos a ver un poco los más útiles:

Automated Builds: la compilación automática, forma parte tradicionalmente de los sitemas de integración continua, aunque es perfectamente válido el considerarlo de forma autónoma.
Continuous integration: el 2º clasificado, viene a confirmar que la automatización de tareas, se sigue considerando una técnica ágil muy útil.

Hagamos un breve inciso aquí para tener en cuenta que los dos primeros clasificados están muy relacionados. De hecho, habrá defensores que lo consideren como uno sólo. Los dos siguientes, están también relacionados, y sí que podrían considerarse técnicas puramente ágiles (mucho más asociadas a las metodologías ágiles que las dos primeras, por ejemplo):

Daily stand up meeting: la técnica de realizar breves reuniones de pie, diariamente, y de forma informal pero con un objetivo definido de poner en común las tareas en curso de cada uno, y los problemas encontrados o que nos atascan.
Iteration planning: tradicionalmente vinculado a la programación extrema (Extreme Programming o XP), esta práctica consiste en la ejecución de la iteración: desde el desglose y estimación de las tareas, su asignación, y posterior desarrollo, ejecución de pruebas unitarias, etc., hasta la siguiente iteración.

Algunos puntos importantes a indicar aquí sobre estas dos prácticas: la primera es extremadamente económica de implementar. Cualquier proyecto puede incorporar esta técnica, sin coste ni importantes efectos colaterales (salvo quizás el incremento de visión de los integrantes del equipo). La segunda, sin embargo, exige una involucración más profunda en las metodologías ágiles. Exige por tanto, un cambio significativo en la forma de organizar el trabajo, planificarlo, y reportarlo.

Para terminar hoy, vamos a quedarnos con dos técnicas ágiles, que a pesar de estar incluidas aquí, son en realidad técnicas habituales en cualquier desarrollo de software ("ágil" o no):

Coding Standards: Se trata de disponer de estándares de codificación o de desarrollo específicos del proyecto.
Unit Testing: consiste en la planificación, diseño, programación y ejecución de pruebas enfocadas a probar un único componente o función.

En primer lugar resulta curioso el considerarlos técnicas ágiles. En segundo lugar, son aspectos prácticamente de uso obligatorio en cualquier desarrollo moderno de hoy en día. En cuanto al coste, ambos son elementos costosos de implantar, ya que requieren de formación específica, y en algunos casos, de herramientas específicas tanto para su uso como para su verificación.

Dejaremos para otro día, la segunda parte de este artículo, revisando las técnicas que quedan.

Cuanto antes empieces a codificar más tarde terminará el proyecto

2011-12-21T10:40:00.000-08:00

Este proverbio, lo he encontrado en la web de Calidad del Software. Le he dado una leída, y me he dicho: "pero qué pedazo de tontería es ésta".

Pensándolo un poco más despacio...no deja de tener razón. Me explicaré.

En mi experiencia, han sido ya muchos proyectos durante todos estos años en los que aunque se ha hecho el debido análisis y diseño, la presión por parte de la gerencia ha acabado obligando a que "el equipo que vaya echando código, y tú en paralelo ya harás el análisis y diseño". Al final, incluso la planificación iba muy por detrás de la ejecución de actividades.

Esto tiene sus contrapartidas:

Es necesario dar una visión (funcional), que aunque incompleta, permita al equipo "saber hacia dónde va". Esto obliga a que al menos, esté completada esa visión en el análisis funcional. Es decir, no basta con solamente poner los requisitos (historias de usuario en Scrum) que vayan a empezar de forma inmediata.
Aunque creamos saber "hacia dónde va" nuestro desarrollo, no todo puede hacerse en base a "bloques independientes". Muchas veces, aceptamos que el software evoluciona en cuanto a sus requisitos (véase SCRUM). Sin embargo, estamos ciegos al pensar que la arquitectura del sistema no va a cambiar también. Y aquí es donde los desarrollos iterativos chocan con la triste realidad de tener que incorporar en cada iteración (o release), un gran esfuerzo en integrarse con lo existente, y probarlo todo otra vez.
El tamaño importa: en un desarrollo pequeño, estos comentarios pueden ser de escasa importancia. El esfuerzo en "asentar" un software sin análisis o diseño o arquitectura, puede ser despreciable. Conforme el tamaño del software aumenta (y es importante identificar muy al principio el tamaño del software), todo esto cobra importancia de forma exponencial.
Muchas veces se olvida que la documentación de análisis, diseño y arquitectura son parte de los entregables. ¿Por qué? Simplemente porque realizar el mantenimiento de una aplicación, basándose solamente en los comentarios que nos han dejado los antecesores, es un suicidio. Queda muy bien lo de "yo no necesito documentar, ya que dejo buenos comentarios". Esta frase es muy típica de la gente poco experimentada, que apenas ha hecho mantenimientos, o los ha hecho de aplicaciones con poca trayectoria.

Esta frase tampoco tiene porqué ser tomada a la inversa: si vamos retrasando la programación, llega un punto en que la definición ya está casi cerrada. Es absurdo que pretendamos tener el 100% de la documentación cerrada para empezar a programar. Hay que evaluar la madurez de lo que tenemos, y controlar los riesgos de que cambien las cosas.

A este respecto, nada mejor que contar con la experiencia de un buen analista y un buen arquitecto que cierren los puntos clave, un jefe de proyecto experimentado que coordine la aprobación y seguimiento de esta documentación inicial....y a partir de ahí, versionar esa documentación.

La desgracia, es que muchos programadores (por no decir todos), se sienten cómodos aplicando cambios al código. Pero no actualizando la documentación conforme esos mismos cambios. Además, esto se ve agravado con el hecho de que los jefes de equipo y proyecto no fomentan actualizar esa documentación. Así que dada esta escuela de comportamiento, seguimos fomentando las malas prácticas.

Y ojo, no se trata de tocar la documentación con cada línea de código. Si sabemos qué se ha tocado, bastaría juntar cada 2, 3 o 4 semanas de desarrollo, los principales cambios técnicos y funcionales, y dedicar un rato a que algunos documentos no se desfasaran. También aquí hay que ser pragmáticos, si el entregable principal es el documento funcional, apliquemos ahí el mayor esfuerzo. Si es el técnico, pues lo mismo.

Hablemos de estándares

2011-12-20T13:49:00.000-08:00

Los estándares, en el mundo del software, son uno de los facilitadores más sencillos que existen. Sin embargo, tienen muchos detractores y están muy mal vistos por colectivos que ven en el desarrollo del software un medio de expresión, un "arte", y que están en contra de las normas y directrices.

Las normas y directrices ayudan a luchar contra las diferencias que presentan los distintos componentes de un proyecto:

Diversidad cultural
Creencias
Niveles de conocimiento
Años de experiencia
Personalidad
Barrera idiomática
Jerga Profesional

¿Y qué deberían cumplir estas normas, reglas o estándares?

Simples, fáciles de entender
Si es posible, incluir ejemplos de uso, y demostración de su utilidad práctica
Los estándares no pueden ser extensos. Nadie va a recordar un documento de 200 hojas.
Los estándares pueden ser muchos. Por ejemplo, si en nuestra empresa se programa en 20 lenguajes, puede haber una mini guía o estándar por cada uno.

Recomendaciones:

Mantener vivos los estándares. Pocas cosas hay peores que dejar las cosas en el olvido. Las tecnologías evolucionan, y los estándares están muy relacionados con las tecnologías del momento. Es por eso que los documentos donde se recojan los estándares han de estar actualizados constantemente. Las actualizaciones han de estar disponibles, y la gente ha de conocer de forma clara el motivo de la actualización.
Evitar actualizaciones muy frecuentes: por ejemplo, que sólo los proyectos nuevos a partir de una fecha utilicen la última versión de los estándares. No hay peor cosa para la gente que esté en un proyecto, que la distraigan cambiando las normas. Bastante cambian ya los requisitos, los hitos, las entregas, etc., como para que encima cambie la forma en que hacemos las cosas en el día a día.
Realizar formaciones. De nada sirve dar a la gente al principio del proyecto un documento para que se lo lea. Tampoco será muy útil tratar de castigar o penalizar a quien no lo siga. Mucho más práctico será realizar cursos periódicamente, que además de sobre los estándares, puede incluir las últimas novedades de la tecnología que se use (esto suele ser mejor reclamo que los estándares en sí).
Incentivar el uso. Puede aplicarse un incentivo positivo: por ejemplo, dar premios o bonus a los desarrolladores que mejor resultados tengan en los tests relacionados con estos estándares (y mejor si son pruebas automatizadas).
Penalizar el desuso. Yo en general, estoy en contra de esta práctica, pero habrá quien la vea útil. Es la contraria de la anterior, y consistiría en penalizar a los desarrolladores con peores prácticas (desde el punto de vista de los estándares recomendados).

Pues nada, ahora que sabemos la teoría, dejaremos para un próximo post el ir aterrizando estándares "palpables" para algunas tecnologías. Nos vemos.

Por fin un estándar para las pruebas: ISO 29119

2011-12-13T01:07:00.000-08:00

Se está haciendo un importante esfuerzo desde hace ya algún tiempo para estandarizar las pruebas de software. El resultado de esto es el estándar ISO/IEC 29119 Software Testing, que todavía no está terminado, sino que se encuentra en revisión pública de la versión borrador. El portal de trabajo se encuentra en: http://softwaretestingstandard.org/, donde encontraréis información actualizada del estado y contenido.

¿Qué pretende este estándar?
Su objetivo es recopilar la terminología, procesos, documentación y técnicas para todo el ciclo de vida de pruebas del software.

¿Cuál es su contenido?
El contenido está estructurado (actualmente a fecha 12-12-2011) en cuatro partes:

Parte 1: Definiciones y Vocabulario
Parte 2: Proceso de Pruebas
Parte 3: Documentación de Pruebas
Parte 4: Técnicas de Pruebas

¿En qué se basa?
Se basa en las principales normas que actualmente son los referentes de esta área:

BSI (British Standards Institution): BS 7925-1, Software Testing: Part 1-Vocabulary y BS 7925-2, Software Testing: Part 2-Software Component Testing.
IEEE Std. 829, Software Test Documentation y IEEE Std 1008, Software Unit Testing, IEEE Std 1012-1998 Software Verification and Validation y IEEE Std 1028-1997 Software Reviews.
ISO/IEC 12207, Software Life Cycle Processes, ISO/IEC 15289, System and Software Life Cycle Process Information Products y ISO/IEC TR 19759, Guide to the Software Engineering Body of Knowledge

Sistemas de Gestión de Proyectos con Software Libre

2011-12-12T09:17:00.000-08:00

Presentado por el PMI Spain Barcelona Chapter, y presentado por el ponente José Moro, va a tener lugar una charla (webminar) con el título "Sistemas de Gestión de Proyectos con Software Libre", el próximo jueves 15 de Diciembre de 2011.

Tenéis toda la información en: link. Fuente: publicado por el propio José Moro en Linkedin.

A modo de resumen, la agenda presentada es la siguiente:
1. ¿Necesitamos un sistema de gestión de proyectos?
2. ¿Qué le pedimos a nuestro sistema de gestión de proyectos?
3. Quiero uno, ¿por dónde empiezo?
4. Aspectos a tener en cuenta a la hora de seleccionar el sistema de gestión de proyectos
5. Conclusiones

Chistes de Testers

2011-12-11T04:09:00.000-08:00

Os traigo unos chistes que me han parecido buenísimos, y que están relacionados con el mundo del testing. Los que hayáis trabajado en testing, espero que os guste. Los que no...no os vendría mal dedicar algo más de tiempo a probar vuestros propios productos! . Fuente: Link.

Optimistic Developer: The glass is half full
Pessimistic Tester: The glass is twice as big as required

Optimistic Developer: This code hasn’t yet been tested. It’s not known if it has any bugs.
Pessimistic Tester: This code hasn’t yet been tested. It’s not known if it works.

Optimistic Developer: We are 90% done.
Pessimistic Tester: We don’t know when we’ll be done, if ever

Optimistic Developer: We will refactor the code to make it better
Pessimistic Tester: They are throwing out the working code and replacing it with an unknown quantity

Optimistic Developer: I only changed one line of code
Pessimistic Tester: The entire system must be retested

Optimistic Developer: The code is the design
Pessimistic Tester: There is no design

Optimistic Developer: We’ll fix those bugs later, when we have time
Pessimistic Tester: We never have enough time to fix the bugs

Optimistic Developer: This build is feature complete
Pessimistic Tester: The features exist; some are completely broken

Optimistic Developer: Anything is possible, given enough time
Pessimistic Tester: Everything has flaws, and given enough time I can prove it

Optimistic Developer: Of course it will work
Pessimistic Tester: It might work, but probably won’t

Optimistic Developer: One last bug fix, and we can ship tomorrow
Pessimistic Tester: Fixing this one bug will likely lead to two more

Optimistic Developer: Stop finding bugs, or we’ll never be done
Pessimistic Tester: Stop creating bugs, so I can find them all

Optimistic Developer: There’s no need for more tests
Pessimistic Tester: Let’s just run a few more tests to be sure

Optimistic Developer: There is no I in TEAM
Pessimistic Tester: We can’t spell BUGS without U

Optimistic Developer: That’s an “undocumented feature”
Pessimistic Tester: That’s a bug

Optimistic Developer: I like to build things
Pessimistic Tester: I like to break things

Optimistic Developer: Sure, we can use the Beta version of this component in Production
Pessimistic Tester: We should wait until version 2.1

Top Mantra de los Arquitectos (I)

2011-12-09T02:53:00.000-08:00

Estaba leyendo uno de mis autores favoritos (Dino Esposito), con su "Microsoft .NET: Architecting Applications for the Enterprise", y entre otras muchas perlas que conviene leer y que os recomiendo encarecidamente, contiene un pequeño resumen de 10 magníficas perlas (mantras en su libro), que no por sencillas, son menos importantes en nuestro trabajo. Vamos a darles un repaso:

Mantra #1: "Depende". Ademas de ser una respuesta socorrida para aquellos que no tienen ni idea, por desgracia es también una respuesta de los más experimentados. Pues sí, depende. Depende de la situación, del contexto. Las decisiones arquitectónicas son sólo eso: decisiones basadas en la experiencia y en el conocimiento del proyecto, del cliente y del equipo de desarrollo. Basándose en los tres anteriores, hay que elaborar la lista de soluciones para cada una de las facenas de nuestra solución arquitectónica.

Mantra #2: "Los requisitos son Dios". He querido explícitamente no hablar de ellos en el mantra anterior, y es que los requisitos, aun formando parte de la especificación del proyecto, son mucho más importantes que el proyecto en sí para el arquitecto. No es fácil adaptar las cosas al equipo (si es que conseguimos un equipo estable de trabajo), como tampoco lo es adaptar la arquitectura al cliente (si es que conseguimos la colaboración del cliente, y si dicha colaboración es fructífera). Al final, los requisitos son la verdadera guía del proyecto. Cambiarán, por supuesto que cambiarán. Pero al final, es la labor inicial de análisis y el enfoque acertado de dichos requisitos, lo que marcará el éxito del proyecto. Los arquitectos sólo se limitarán a proporcionar la infraestructura tecnológica, las decisiones de comunicación, etc., para adaptarse a dichos requisitos.

Mantra #3: "Programar una interfaz". De nuevo, los requisitos (en este caso de interfaz), van a ser la directriz principal de los desarrolladores. Sin interfaces, el código no tiene forma de prosperar. Serán sólo líneas de código sin un objetivo (como echar ladrillos al aire con la esperanza de que formen la pared tal y como se proyectó).

Mantra #4: "Hazlo simple, pero no simplón". Aquí es donde un arquitecto se la juega. Las soluciones complejas, en las que el arquitecto pretende mostrar su conocimiento (cuando realmente se le ve el plumero de que le falta experiencia), nos llevan de forma inexorable al fracaso. Donde realmente se ve a los mejores profesionales brillar, es con soluciones simples y efectivas. Por desgracia, hay una débil frontera que hace que una solución simple, no se pueda simplificar más sin caer en lo absurdamente simple y escaso.

Mantra #5: "Herencia es sobre polimorfismo, no reutilización"
La herencia constituye un elemento fundamental de la programación orientada a objetos. Que la herencia permite reutilización, es correcto. Pero la reutilización como objetivo, es un gran error. Dicho de otra forma, es mejor escribir una nueva clase específica para la tarea concreta, que heredar de otra que no lo está. Es mejor reescribir de forma enfocada a la solución concreta, que tratar de reutilizar todo formando una oscura maraña de dependencias que de seguro llevará al fracaso (y complicará la vida a los pobres programadores que osen completar la aplicación, y luego mantenerla).

Y bueno, hasta aquí la primera parte de los 10 Top Mantra de los arquitectos. El próximo día...más.

Defectos de Scrum (II)

2011-12-03T01:03:00.000-08:00

En un reciente post hablaba de defectos de Scrum. Con este título, yo pretendía destacar los riesgos habituales en proyectos que por el motivo que sean, no encajan con las premisas de estas metodologías.

Vamos a ver a continuación una segunda parte con nuevos supuestos o problemas que presenta la implantación de una metodología como SCRUM, y que tendremos que considerar a la hora de implantarla.

En estas metodologías hay entregas frecuentes y estables, lo que supone probar y estabilizar un producto con un número mínimo de funcionalidades. Por desgracia, a pesar de que las metodologías ágiles se presentan como preparadas para el cambio, tienen el mismo problema que las metodologías tradicionales: las funcionalidades de una iteración pueden cambiar en la siguiente. Al final, una iteración es como un mini proyecto: tiene desarrollo, pruebas, un esfuerzo de integración con la funcionalidad existente, y despliegue. Por mucha involucración que queramos tener del usuario, nada impide que las funcionalidades cambien. Si pensáramos eso, entonces ¿porqué cambian en las metodologías tradicionales? ¿Es que allí el usuario nos ignora, no se involucra, va en contra de sí mismo? ¿Es que los analistas de las metodologías tradicionales son unos inútiles, y los de las ágiles unos hachas?
Presupone que no es necesaria la férrea gestión de recursos de otras metodologías “clásicas”. El problema está en cómo coordinar pues los desarrollos con la presencia de personal de sistemas, DBA’s, disponibilidad de recursos hardware, etc… El problema es que estas metodologías ágiles se venden desde el punto de vista del programador. Es el cliente el que debe sopesar si necesita o no un manual, una documentación exhaustiva, un seguimiento del proyecto, un control de costes y gastos...no el equipo.
Esta metodología no parece estar pensada para equipos de desarrollo dispersos en el espacio o en el tiempo. SCRUM presupone reuniones diarias cortas y presenciales. Presupone una colaboración de los equipos muy integrada. Eso no quiere decir que no se pueda trabajar en remoto. Simplemente, que en el segundo caso, puede haber dificultades adicionales que en pequeños equipos cercanos, no existen.
Se habla de que existe incompatibilidad o contradicción entre el uso de metodologías ágiles y que la empresa esté certificada CMMi. (Actualmente, con CMMi en su versión 1.3, esto ya no es cierto). Por desgracia, existen muchas administraciones públicas nacionales e internacionales que exigen a sus proveedores la certificación CMMi (entre otras). El Manifiesto Ágil en que se basan estas metodologías ágiles, habla de valorar más el individuo y el código frente a documentación (por ejemplo). Pero esto no quiere decir, que haya que hacerse lo que quiera el equipo, sino que ante la falta de otras directrices (es decir, si nadie pide documentación), se de mas importancia al código.
Los concursos públicos y muchos clientes privados exigen la certificación CMMi de la empresa, pero es raro que un cliente exija una certificación en metodologías ágiles (que por otro lado no existe tal, sino que es la persona quien se certifica ScrumMaster o equivalente). Esto es un problema para las metodologías ágiles, que chocan ante la falta de un auténtico certificado de empresa. La gente va y viene, pero es la empresa la que necesita ganar proyectos.
La falta de documentación detallada es un grave problemas en clientes de sectores legal, financiero, público,… y en general en proyectos grandes que requieran posterior mantenimiento, o en los que simplemente el cliente exige la documentación como parte del contrato.
En general, los métodos ágiles promueven la iniciativa e independencia del desarrollador (propietario del bloque funcional que está desarrollando), lo que puede derivar en que se implementen funcionalidades asociadas o paralelas NO SOLICITADAS, que terminen retrasando y complicando el desarrollo.
También existen problemas en la implantación de grandes clientes en los que varios proveedores interactúen. En estos casos, es muy importante definir documentación que permita la integración entre proveedores, tema que las metodologías ágiles (puras) suelen dificultar.

Con las que ya había en el anterior post, parece que hay muchas, y así es. ¿Estoy queriendo decir que SCRUM y en general las metodologías ágiles son problemáticas o difíciles de implantar? ¿O ineficaces? Pues no. Problemas hay en todas partes. Lo que no puede ser es que como veo constantemente en la red, vanagloriemos a las metodologías ágiles como el mantra que nos va a salvar del desastre en que nos han dejado las metodologías tradicionales. Hay que tener en cuenta las limitaciones de dichas metodologías, y saber adaptarlas a los proyectos. Si caemos en el purismo y tratamos de implantar las metodologías por ellas mismas, estaremos perdiendo de vista los objetivos de los proyectos.

Este post 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.

La eficacia de las encuestas de satisfacción

2011-12-01T14:39:00.000-08:00

Un tema que se suele dejar de lado a la hora de controlar un proyecto y tener conocimiento sobre él, son las encuestas de satisfacción.

¿Qué son?

Consisten en solicitar feedback al cliente en relación a un producto vendido o servicio prestado. Existe una normativa asociada, que es la UNE 66176, aunque esto no es muy conocido. La norma se llama “Sistemas de gestión de la calidad. Guía para la medición, seguimiento y análisis de la satisfacción del cliente”.

¿Para qué sirven?

Se utilizan para una adecuada gestión de los servicios prestados, a través de la medición de distintos parámetros de satisfacción, su registro y posterior análisis y seguimiento. Si se supone que nuestros desarrollos tienen al cliente como target, deberemos de medir de alguna forma lo bien que estamos acertando en dicho objetivo.

¿Qué deberíamos tener en cuenta?

No dejar pasar tiempo entre la prestación del servicio y la encuesta de satisfacción.
No limitarnos a preguntar al cliente por nuestros servicios, sino cruzar esos datos con las incidencias/reclamaciones recibidas.
Es posible que haya habido incidencias en el servicio que estén sólo en conocimiento de los distintos departamentos de la empresa (ventas, contabilidad, ingeniería, soporte, calidad, etc.)
Hay clientes que se resisten a rellenarlas (en concreto, en el sector público es muy complicado). Hay que buscar fórmulas de incentivación (asociar la encuesta a la activación de la garantía, o ofrecer pequeños premios, incluirlo como un entregable obligatorio más por contrato, etc.
La encuesta de satisfacción no debería hacerse en reunión “cara a cara”, ya que puede influenciar las respuestas.
Es importante el sponsorship de la dirección. Este apoyo es vital para ayudar a gestionar la resistencia de los clientes a rellenar las encuestas.
En los servicios prestados a medio-largo plazo, es importante que se haga periódicamente, para permitir la mejora del servicio. Si sólo se hace al final, estaremos actuando reactivamente en lugar de proactivamente.
Incluso en los servicios llave en mano, es importante evaluar los momentos en que se realiza, para evitar subjetividades y dar tiempo a que el servicio postventa actúe adecuadamente.
Esta información debe registrarse en los sistemas CRM para la adecuada gestión de la cartera de clientes.

¿Hace falta que un Tester sepa programar?

2011-11-30T02:28:00.000-08:00

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)

2011-11-27T08:12:00.000-08:00

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.

En general, dificultad de aplicación en grandes proyectos.
Se requiere de un “agile champion”, experto en la metodología que monitorice su cumplimiento.
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.
Plantea un problema si el desarrollo está restringido por una fecha de entrega y un precio de entrega cerrados por contrato
Presupone que los requerimientos cambian, pero no de forma que el cliente acepte un diseño funcional/técnico.
Presupone que el equipo está muy formado y motivado
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.
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

2011-11-25T12:07:00.000-08:00

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?

2011-11-23T14:34:00.000-08:00

... 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.

2011-11-17T13:39:00.000-08:00

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

2011-11-12T01:13:00.000-08:00

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

2011-11-11T09:14:00.000-08:00

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

2011-11-10T14:29:00.000-08:00

(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

2011-11-09T10:41:00.000-08:00

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).

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

2011-11-08T07:16:00.000-08:00

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?

2011-11-06T01:32:00.000-07:00

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 ralizar 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.

ASP.NET MVC (II) Ventajas

2011-10-22T11:42:00.001-07:00

Vamos a continuar con esta serie de posts sobre ASP.NET MVC. Puedes ir también a los artículos 1 y 3.

¿Qué ventajas nos ofrece este modelo MVC en ASP.NET?

Es extensible
Es amigable con SEO (las url son muy sencillas, e implementan las acciones y parámetros de forma natural, facilitando su acceso mediante buscadores) y REST
Nos da un enorme control sobre la salida
Nos da un enorme control sobre el flujo
Nos separa de forma natural las responsabilidades
Facilita la prueba de nuestras aplicaciones de formas que en el mundo WebForms no podríamos ni imaginar.
Se sigue basando en todo el framework existente ASP.Net (masterpages, membership, etc.)
Se integra con el funcionamiento natural de la web, sin metáforas que nos acaben complicando la vida en cuanto tratamos de realizar cosas más complejas
Estabilidad y fiabilidad: se basa sobre el más que probado framework asp.Net, e integra casi cualquier elemento que nos pueda hacer falta
Facilita los cambios (sí, esta vez de verdad, de forma muy superior a como se facilita en las aplicaciones N-tier)
Facilita separar el trabajo de los diseñadores, que pueden editar directamente la capa de presentación, sin tener que pasar como ocurre con Silverlight con herramientas específicas de diseño.
Se integra de forma natural con jQuery

¿Debemos migrar las aplicaciones Webform existentes?
No. Para nada. En todo caso, habría que evaluar si los problemas y cambios que nos solicitan en el mantenimiento de las aplicaciones antiguas, nos justifican el cambio.
Lo que sí es cierto, es que la migración a MVC ofrece de forma exponencial unos enormes beneficios de cara al mantenimiento.

Así no se puede trabajar

2011-10-14T01:46:00.000-07:00

Esto no es serio. Así no se puede trabajar. Hoy traigo un mensaje (cuadro de diálogo) de Microsoft Powerpoint, que me ha hecho desear asesinar a alguien. Esto no está sacado de ningún sitio web, ni na. Lo he sufrido en mis carnes. Aún sigo sin saber el motivo ni la información perdida. El mensaje es:

Para los que no estéis puestos en inglés, os traduzco lo que pone tal y como lo he sentido:

Powerpoint ha encontrado contenido en este fichero, que no entiende.
Por tanto, Powerpoint ha decidido borrar este contenido, y no se puede recuperar. Ole, ole y ole tus...pues eso.
Te interesaría revisar esta presentación POR SI ACASO detectas algo cambiado o borrado

Pero si no es mía la presentación! Pero qué narices me está contando! Pero cómo voy a saber si algo falta o no! Y ni siquiera puedo contactar con su autor!!!!!

Queridos desarrolladores de Microsoft Powerpoint: GRACIAS. Gracias por hacerme sentir idiota. Gracias por dejarme alucinado con mensajes tan retorcidamente creativos.
En fin, que así no se puede trabajar.

Chuck Norris Exception

2011-10-13T08:57:00.000-07:00

He encontrado en este link esta pequeña perla (aunque me suena, quizás sea vieja):

Instalación

$ npm install ChuckNorrisException

Uso

var ChuckNorrisException = require('ChuckNorrisException');

var imFeelingLucky = true;
try {
  if (imFeelingLucky) throw new ChuckNorrisException();
} catch (e) {
  // FAIL: You cannot catch a ChuckNorrisException
}

Si intenta lanzar una ChuckNorrisException resultará en un fallo y se cerrará su programa.
¿El motivo? Porque usted no lanza a Chuck Norris....Chuck Norris le lanza a Usted!!!
Los siguientes errores se producirán si se intenta tamaña estupidez.

Usted no lanza a Chuck Norris....Chuck Norris le lanza a Usted!!!
Chuck Norris escribió "Hola Mundo" una vez...y se llamó Unix.
Chuck Norris le pateará el culo asíncronamente

Original: http://criso.github.com/ChuckNorrisException/

Lloremos una gran pérdida

2011-10-13T08:48:00.000-07:00

Bueno, hoy 13 de Octubre, hemos de llorar una gran pérdida para el mundo del desarrollo de software. Su contribución ha sido incalculable, ya que ha influido en muchísimos aspectos técnicos que aún están en boga hoy en día, tantísimos años después.

NO, no me refiero a Steve Jobs (también, recientemente fallecido, y contra el que nada tengo).

Me refiero a Dennis Ritchie, autor que ha influido en más de una generación de universitarios (no sólo informáticos), a través de su casi obligatorio título "El lenguaje de programación C" de Kernigan & Ritchie. Algún otro título suyo, también resultó de lectura obligatoria en la universidad, como aquel sobre Unix, ya que por otra parte, este señor fue COAUTOR del sistema UNIX. Sí, sí, el que aún se sigue venerando como fuente de Linux y otros dialectos.

Descanse en Paz

Novedades en el ASP.Net Framework 4.0

2011-10-12T13:46:00.000-07:00

No sólo de MVC vive el hombre, así que antes de que llegue la siguiente versión de Visual Studio y otro nuevo Framework, vamos a repasar algunas de las novedades que llegaron en la última versión del .Net Framework 4.0 para ASP.Net.

Nuevas propiedades en controles para mejorar la gestión del ViewState. Ya no sólo se gestiona a través de la propiedad [EnableViewState].
Mejoras en la cache: opción de compresión en las caché "Out-Of-Process" y nuevas opciones de customización de caché mediante la creación de custom providers. Esto puede ser especialmente útil en entornos con poca memoria.
Nuevas opciones para renderizar el código html mediante las buenas prácticas de accesibilidad recomendadas, evitando tablas, estilos inline, etc. Para ello, los controles existentes (como el control menu), han incorporado nuevas opciones de renderizado. Entre otras, la propiedad [IncludeStyleBlock] (true/false), ahora permite habilitar o inhabilitar la inclusión del bloque de estilos inline, tal y como se hacía en el framework 3.5.
Nuevas opciones para facilitar y automatizar el nombrado de elementos HTML (los IDs), que hasta la versión del framework 3.5 eran prácticamente imposibles de predecir. Es decir, el framework los nombraba de forma que no facilitaba la inclusión de código Javascript, ya que éste necesita predecir los nombres de los elementos HTML a los que se quiere acceder.
Validación de peticiones extensible. En el framework 4.0 se validan todas las peticiones, aunque es posible configurar el comportamiento y extender el comportamiento mediante validación de cabeceras, URL, parámetros, etc.
AJAX: soporte para jQuery de serie de Microsoft, soporte para plantillas de lado cliente.
Disminución del tamaño de los web.config
Query Extenders
Expresiones HTML nuevas para codificación: <%: %>
RedirectPermanent
Despliegue automatizado de aplicaciones Web con transformación de configuraciones.

Este post es de resumen, desde luego que lo que tocaría es ahora ir tocando todos y cada uno de estos temas. Algunos, como el nuevo soporte de jQuery, son apasionantes. A ver si le puedo sacar algún ratito y podemos detallar si no todo, alguno de ellos. De todas formas, antes me gustaría irme quitando también la serie de posts sobre MVC. En fin: pasito a pasito.

El framework CLSA .Net

2011-10-10T13:22:00.000-07:00

Lleva ya mucho tiempo esto del CLSA dando vueltas por el mercado.

¿Que cómo lo descubrí? Yo andaba buscando material para frameworks que nos ayudasen a mejorar la metodología de desarrollo en mi empresa actual. El hecho de tener CMMI nivel 3 está muy bien, pero si no das a los equipos de desarrollo formas de trabajar "reales", al final corres el riesgo de convertirte en un teórico de la tecnología.

El caso es que mientras buscaba frameworks de pruebas y modelos de negocio, me encuentro una referencia a CLSA y el señor Rockford Lhotka.

Lhotka es autor de varios libros sobre desarrollo .Net, y autor del framework CLSA que está orientado al desarrollo rápido de aplicaciones. CLSA es un framework que facilita la construcción de la capa lógica de negocios para aplicaciones Windows, Web, orientadas a servicios, y de flujos de trabajo.

CLSA.Net simplifica y estandariza la creación de capas de negocio en .net

La implementación de CLSA para .Net comenzó en 1999, y sigue evolucionando todavía hoy con soporte para Visual Studio 2010, Microsoft .NET 4.0, Silverlight 4, y Windows Phone 7.

¿Porqué la desestimé? En su momento, estuve evaluando la capacidad de este framework para su uso e integración con nuestra metodología .Net, pero me pareció demasiado "customized". Efectivamente promete flexibilidad, pero a costa de hacer el desarrollo muy dependiente de este framework. En absoluto me pareció poco potente ni le encontré fallos significativos en el tiempo que le dediqué, así que os animo a los que estáis evaluando frameworks de este tipo a que le déis una oportunidad.

Esto acaba aquí. Si esperas que te detalle información sobre el uso de este framework sin haber tenido yo experiencia personal real, estás listo. Para eso ya tienes otros blogs. Cuidaros.

ASP.NET MVC (I) Introducción

2011-10-08T03:11:00.001-07:00

Introducción
Hoy vamos a ver una introducción a lo que espero sea una larga serie de artículos sobre ASP.NET MVC.
Podéis saltar directamente a las partes 2 y 3
Aquellos que vengáis del mundo Java prácticamente veréis a MVC como un estándar del día a día. Pero en el mundo .Net, no es así.

El problema es que en .Net hemos sufrido de la obsesiva directriz de Microsoft en el sentido de OCULTAR la complejidad y la esencia de las cosas, encapsulándolo todo en nuevas metáforas supuestamente más sencillas. Eso ha funcionado muy bien, consiguiendo en el modelo ASP.NET Webforms una forma relativamente simple de construir aplicaciones Web. Pero no deja de ser una abstracción, una metáfora. Cuando intentamos bajar al nivel del código Javascript es cuando realmente vemos que la metáfora de los WebForms se cae con su propio peso y nos ha estado ocultando una realidad compleja, pero que en otras tecnologías como Java, se maneja de forma natural.

Desde hace ya algún tiempo, ASP.NET MVC se ha introducido como una forma de volver a las raíces, de resolver las dos principales problemáticas que existían en los desarrollos web:

No ocultar la naturaleza de la web mediante falsas metáforas, que realmente nos complicaban mucho más la vida, como el uso de ViewState, etc.
Los flujos de las aplicaciones no están integrados de forma natural en las estructuras y arquitecturas de los webforms. Los webforms están diseñados para ser sencillos de implementar desde el punto de vista de los WinForms (pantallas de escritorio). Pero no constituyen una forma natural de implementar y separar la visualización de los datos, de lo que es el negocio.

El modelo MVC ante todo se basa en la estructura del flujo de nuestra aplicación Web. Representa de forma natural una vista por pantalla (o tipo de pantalla), e implementa acciones que no son sino las acciones de nuestras pantallas.

¿Cómo funciona MVC?
El patrón que se usa en MVC de ASP.NET es el de Front Controller.
Al controlador le llegan peticiones, que pasan por un mecanismo de enrutamiento. El enrutador decide qué controlador debe dispararse, ese controlador es el que da paso a las acciones e interactúa con el modelo, dando como resultado una vista.

El enrutamiento se encuentra dentro del espacio de nombres System.Web.Routing. Se trata de un espacio de nombres independiente de ASP.NET MVC, por lo que las personas que utilicen ASP.NET clásico (el de webforms), pueden tener también acceso a ese espacio de nombres.

Enrutado
La esencia de MVC dentro de ASP.NET se encuentra en el enrutado. Para ello, en el archivo Global.asax se define una tabla de rutas, una colección de rutas (RouteTable). Esa tabla lleva una ordenación, y el comportamiento vendrá definido por dicho orden (debe de ponerse el comportamiento más restrictivo siempre antes). Además, este enrutado permite restricciones (por ejemplo, en función de una clase específica definida por nosotros, o bien a través de expresiones globales).

Definición de rutas
La definición de rutas se hace mediante patrones. El patrón más común es:
{Controlador}/{acción}{parámetro}
Esto hace que la forma más habitual de navegar en una aplicación MVC sea mediante url's del estilo:
http://misitioweb/controlador/accion/parametro

Para definir una ruta por código sería algo así como:
var route = new Route("{controller}/{action}/{param}",new MvcRouteHandler());
class Route: RouteBase{
     //definición de la ruta
     string Url
     RouteValueDictionary Defaults //valores por defecto
     RouteValueDictionary Constraints //permite definir restricciones
     RouteValueDictionary DataTokens //permite asignar metadatos donde guardar información adicional
     IRouteHandler RouteHandler
}

Bueno, ya vale para una primera introducción.
Para saltar a la segunda parte de este post, clic aquí.

Refactoritis

2011-10-06T13:49:00.000-07:00

Hoy vamos a tratar una enfermidad muy común de los programadores "experimentados": La Refactoritis.

La refactorización se lleva haciendo durante décadas. No es algo nuevo, a pesar de que siempre se cite al bueno de Martin Fowler como referencia, en su libro "Refactoring: Improving the Design of Existing Code". Si no conocéis a Martin Fowler y os dedicáis a la informática, no sé a qué esperáis para leer este libro y saber un poco más de este autor.

La refactorización se define en la Wikipedia como "técnica de la ingeniería del software para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo". Es en estos momentos cuando muchos de vosotros estaréis asintiendo con la cabeza y pensando en frases como "pues yo refactorizo mucho o poco", "yo no lo veo una enfermedad", etc, etc.

¿Y qué sería en ese caso la Refactoritis? Pues la podríamos definir como el "trastorno compulsivo que deriva en el uso excesivo de la refactorización del código". Vamos, cuando se le va la mano al programador y no para hasta que ha llegado al final del código, y lo ha dejado todo "a su gusto".

Como hemos visto antes, la refactorización no cambia la funcionalidad. Es decir, no se aporta valor al producto desde el punto de vista de los requisitos. En la metodología SCRUM, estaríamos dedicando horas de trabajo sin implementar ninguna "historia de usuario". En realidad, sería una forma de procrastinación: no hacemos algo que se haya solicitado, sino que estamos haciendo algo que nos gusta o nos parece subjetivamente agradable o necesario. Por supuesto que habrá ocasiones en que sí se ha creado una tarea a realizar de refactorización, pero en esos casos nos deberíamos preguntar si realmente no deberíamos atajar la causa del problema: no generamos código de calidad según estándares, lo que obliga a refactorizar después.

La refactoritis deriva en múltiples problemas. Veamos primero las necesidades que nos pueden llevar a refactorizar el código, y vamos a discutirlas una a una:

Calidad. Esta suele ser una de las excusas más usadas. Estamos creando calidad, mejorando la calidad. Y como no sabemos medir la calidad, no hay límite para nuestras ansias de refactorizar. Podemos seguir refactorizando hasta que nuestra sensación subjetiva de calidad consuma el tiempo de desarrollo. Algunos autores defienden que el código de calidad es bueno, y que mientras se satisfagan las pruebas unitarias, no pasa nada. El problema, es que las pruebas unitarias no son perfectas, lo que puede derivar en que a pesar de que "todo parece ir bien" tras refactorizar, en realidad estamos introduciendo bugs en el código.
Mala planificación. En ocasiones, se planifica en exceso. Los programadores cuando se encuentran con que han terminado una tarea antes de la fecha planificada pueden hacer varias cosas. O buscan una nueva tarea, o tratan de llenar el tiempo de la tarea terminada. ¿Cómo? Pues refactorizando: mejorando comentarios, encapsulando, quitando código duplicado, etc.
Eficiencia. Supuestamente, un código refactorizado es más eficiente. Además, se supone que se entiende mejor y es más claro. Esto último es muy dudoso, ya que es muy fácil refactorizar código y dejarlo de forma que sea muy compleja de entender. En este caso, si no medimos la eficiencia, ocurriría lo mismo que con la calidad. Podemos pegarnos la vida intentando ser más eficientes, que como no se mide esa mejora en eficiencia...no hay límites a nuestra refactoritis.
Evolución. A veces, cambios en las normas de programación, en requisitos de calidad, etc., hacen que debamos refactorizar el código para que se cumplan las nuevas normas. Debemos recordar que salvo excepciones, el cliente paga por funcionalidades, no por la refactorización del código. Si no tenemos claras nuestras normas de desarrollo...mal asunto.
Evitar la reescritura de código. Es muy discutible que un código refactorizado sea mejor que un código reescrito. Deben establecerse las necesidades, y evaluar qué solución merece la pena en uno y otro caso. Si refactorizar es la alternativa a la reescritura de código, en realidad tenemos un problema mayor: el mero hecho de plantearnos reescribir el código significa que un tiempo invertido en el desarrollo "va a la basura". Los paños calientes y las vendas no van a ocultar que tenemos un problema mayor.

¿Cuáles son las prácticas que deberíamos aplicar?

No tocar el código que no se ha solicitado tocar.
No tocar el código para el que no se han definido pruebas (automatizadas o no).
No tocar el código sin antes realizar un análisis del coste (horas necesarias) para su refactorización, y definirlo como una tarea. Sólo así podremos controlar el tiempo necesario en rehacer las cosas una y otra vez. No deberíamos dedicar más horas de las estimadas a refactorizar, ni tocar más código del inicialmente identificado. Si no conocemos el alcance de nuestras acciones, no sabemos hacia dónde vamos.
El código se debe refactorizar ANTES de pasar las pruebas, en la actividad de verificación. Las pruebas son muy costosas (incluso automatizadas), por lo que deberíamos pensar dos veces antes de tocar un código que ha pasado ya las pruebas.
No tocar el código que afecte a otros desarrollos (en curso o en producción), sin antes hacer una evaluación del impacto y recibir la aprobación correspondiente. En muchas ocasiones, algo que funciona correctamente según las pruebas unitarias, al subirlo a producción ROMPE OTROS DESARROLLOS con los que interactuaba.

Gestión de equipos: la teoría del caballo muerto

2011-10-04T05:32:00.000-07:00

Hoy, a falta de algo más elaborado, tengo que echar mano de otro guiño de humor.

Para los que trabajáis en este mundillo del desarrollo de software, os arrancará algunaque otra sonrisa. Para los gestores de equipos y de proyectos que no lo hayáis entendido...manteneos alejados de mí.

Por cierto, haciendo clic en la imagen la veréis "en grande", ¿ok? pues ale.. a disfrutar

El gerente del turno de noche

2011-10-03T05:36:00.000-07:00

A continuación, adjunto una imagen, que vale por cien palabras. Yo suelo decir una frase sobre los malos gestores y jefes de proyecto que reza que "mantienen los recursos lejos de los objetivos".

Vendría a ser similar esta iniciativa, en la que nuestro gerente favorito se encarga de poner los medios más inadecuados para las necesidades del proyecto.

Que aproveche.

Cacheitis: otra enfermedad común del desarrollo software

2011-09-29T07:33:00.000-07:00

Hoy hablamos de otra enfermedad habitual en el mundo del desarrollo software. Relacionada con las enfermedades "arquitectónicas", está especialmente relacionado con desvaríos de los arquitectos de software a la hora de implantar soluciones que por su ineficiente diseño, producen un mal rendimiento. Entonces la definición de Cacheitis vendría a ser algo así: "desorden transitorio del arquitecto o diseñador de software por el cual el uso inadecuado de la caché provoca como resultado una solución ineficiente".

¿Y cuál es la primera solución que se les ocurre? Sí señoooor: más caché. Caché por todos lados. Vamos a cachear todo lo cacheable.

En otras ocasiones, es al reves. Se parte con un exceso de caché desde el inicio del diseño, y esto deriva en un mal rendimiento. Para solucionarlo: como no...más caché.

Rodrigo corral en su blog ya hablaba de este problema, y aporta algunas buenas prácticas:

Asume que no puedes cachearlo todo. Esto es viejísimo: ya es harto conocido por ejemplo, que en el mundo de las bases de datos es absurdo tratar de indexar todo en la búsqueda del rendimiento. Pues esa mala práctica, la cacheitis la extiende al uso de la cache.
El cacheo temprano no es bueno. A menudo cuando diseñamos una arquitectura establecemos mecanismos de cacheo que luego son utilizados hasta el abuso. El peligro subyacente al cacheo temprano es que comencemos a cachear sistemáticamente elementos que nos parecen costosos sin tener evidencia de que realmente son los mejores candidatos para su cacheo. De nuevo, podemos establecer la comparación con el uso excesivo de índices en las bases de datos.
Tener en cuenta las otras cachés. Hay que recordar que existen muchos niveles de caché. El motor de base de datos, el servidor web, ADO.Net, etc, etc.
Una colección estática o global no es una caché: los desarrolladores noveles, y a veces los no tan noveles, utilizan datos estáticos o globales para simular el uso de la caché. Por desgracia, esto es una burda imitación de las múltiples características que deben incluirse en un mecanismo de caché como: acceso frecuente a los datos, políticas de refresco e invalidación, liberación de recursos de uso infrecuente, etc.

¿Qué es lo que hay que hacer? Pues recordar que somos ingenieros, y tratar de aplicar el sentido común (por desgracia, no el más común de los sentidos hoy día). Para ello, hay que relajar el usar la caché en las etapas tempranas del proyecto, y dejar para las etapas de optimización un uso combinado e inteligente de:

Optimización mediante caché
Optimización del acceso a datos mediante índices, su propia caché, vistas, datos calculados, etc.
Minimizar los accesos a servicios web, WCF, y a otras capas de la aplicación, de forma que las operaciones no hagan "excesivos viajes" para obtener la misma información.

De hecho, al final, no es sino hacer uso de los más básicos principios ágiles: simplicidad desde el diseño.

5 malas prácticas en la oficina

2011-09-27T23:44:00.000-07:00

Bueno, hoy el titular es la metáfora del auténtico titular que ha inspirado este post: "The stupid things you do at work (and how to fix them)"

En este artículo, hace una magnífica reflexión de acciones que solemos llevar a cabo y son improductivas o contraproducentes. Me ha hecho gracia por dos motivos:

Vuelve a sacar el tema de la procrastinación en el trabajo. ¿Que no sabes lo que es?. ¿Es que no lees este blog? ;)
El otro motivo es que para ejemplizar la procrastinación, hace referencia a un refrán:

"y como dice el refrán español: mañana probablemente es el día más ocupado de la semana". Anónimo.

Soberbio. Sin palabras. En fin, al grano. Vamos a ver resumidas, las 5 malas prácticas en la oficina:

Ponernos nerviosos. Cuando nos enfrentamos a tareas grandes, con alto riesgo, que nunca antes hemos hecho, o para las que no nos vemos preparados, suele ocurrar esto.
Aferrarse a nuestras ideas y métodos, aunque estén mal. Hemos de aceptar que nuestros métodos o ideas no han de ser siempre los mejores. Punto. Quien lo confunde con ofrecer seguridad, tiene un grave problema. La seguridad consiste en poner los medios y medir los riesgos, para que podamos ofrecer la solución más adecuada al contexto.
Procrastinar en lugar de hacer las cosas. El no afrontar las tareas inmediatas, y relegarlas en favor de lo que nos gusta más, o nos hace sentir más seguros, es un problema.
Creerte mejor de lo que realmente eres. Tenemos una tendencia exagerada a ignorar nuestros fallos y hacer públicos nuestros éxitos. Es un mecanismo de conservación innato en nuestra especie. El miedo a qué dirán. La verguenza pública. Todo esto realmente nos limita y nos hace comportarnos muy por debajo de nuestras posibilidades. Nuestro rendimiento profesional y la calidad de nuestro trabajo, se ven afectados en consecuencia.
Traer tu orgullo a la oficina. A la hora de negociar, mucha gente cuando obtiene un beneficio muy pequeño de la negociación, hace gala de su orgullo y prefiere no llevarse nada. Si pensamos con pura lógica, no tendría sentido este resutado. Sin embargo, la realidad nos hace ver cuán afectado puede verse nuestro comportamiento si nuestro orgullo hace acto de presencia.

Gestión de Proyectos Ágil

2011-09-27T03:53:00.000-07:00

Se ha publicado recientemente el documento "Agile Project Management", que podéis descargar aquí.

El documento, resultado de la colaboración entre APMG-International y el consorcio DSDM, presenta un enfoque innovador en la gestión de proyectos. Ojo, no confundir con la gestión de equipos, que es el alcance que tienen muchas metodologías ágiles como SCRUM.

Errores a evitar en la adopción de metodologías ágiles

2011-09-26T06:04:00.000-07:00

En varias ocasiones, nos encontraremos que por muy convencidos que estemos de las bondades de las metodologías ágiles, vamos a encontrar una reacción de desconfianza o incluso de rechazo por parte de los clientes o de los responsables de proyectos cuando tratemos de que las adopten.

Incluso aunque los proyectos / clientes tengan problemas con sus metodologías actuales, el rechazo y desconfianza se mantiene, y se sigue trabajando una y otra vez manteniendo las mismas prácticas y cometiendo los mismos errores. Conclusión: los proyectos se siguen entregando tarde y mal.

El problema está en la cultura corporativa. Las ideas, los hábitos, son difíciles de cambiar. La resistencia al cambio es constante. Además, dicha resistencia debería ser inversamente proporcional a los argumentos proporcionados. Y no es así. ¿Cuál es la solución? Pues como todo en esta vida, la solución está asociada al problema, así que vamos a tratar de identificarlo.

No tenemos la razón.
La clave, está en que estamos tratando de vender una idea, un concepto: nuestra metodología es mejor. Y la percepción es precisamente ésa, de que estamos tratando vender. Y la gente no quiere comprar, quiere soluciones a sus problemas.

Es por eso que es necesario un cambio de enfoque. Hemos de conseguir que la gente sea consciente de la raiz de sus problemas, que sean capaces ellos mismos de darse cuenta de que necesitan un cambio. Los pasos serían algo así como:

Identificar los problemas
Identificar las causas
Identificar la necesidad de un cambio
Identificar alternativas
Evaluar alternativas
Encontrar una solución

Así de simple. De hecho, es posible que a pesar de creernos los poseedores de la verdad más absoluta ("que sí, que Scrum es la solución, que sí, que si 10 millones de usuarios usan Scrum, es que Scrum es bueno"), da igual. Hay que ofrecer soluciones adaptadas, no varitas mágicas. A continuación, veremos algunas técnicas útiles en la realización de los pasos comentados.

El método de la abuela
A la hora de explicar una metodología (Scrum, etc.), hemos de hacerlo con el "Método de la Abuela". ¿Qué es? Pues elegir alguien que haga de "abuela". Si puede ser, coge directamente a tu abuela. Y tratemos de explicarle, en este caso, en qué consiste la metodología que queremos implantar. Repítelo N veces, usando cada vez un lenguaje menos técnico, hasta que cualquier "abuela" pueda entenderlo.

En este método, hay que evitar hacer sentirse tonta a la gente. Una abuela puede que no tenga un fondo técnico o relacionado con las TI, pero no es tonta. Así que acostumbrémonos a evitar hacer sentirse tonta a la gente.

Escuchar
Hay que saber escuchar, incluyendo lo que no nos dicen. Si detectamos rechazo o desconfianza, hay que ver la raíz de su comportamiento.

Conseguir empatía
Es más fácil que te "compren" una idea, si la otra parte siente que das confianza. Por ejemplo, no se trata de dar nuestras experiencias (que al final pueden ser subjetivas). En lugar de eso, demos datos reales de otros proyectos y empresas, y refrendado por métricas o datos verificables.

Detectar barreras en la organización
En ocasiones, las barreras están en la propia empresa, no en nuestras habilidades comunicativas. Si la cultura organizativa es resistente al cambio (burocracia, organigrama, reinos de taifas, etc.), de poco servirán nuestros bien pulidos "interpersonal skills".

Por los expatriados

2011-09-22T12:59:00.000-07:00

Por cierto, estoy teniendo visitas al blog desde Alemania...¿será Alberto Bolsa?

Ese Albertoooo...mucha suerte, tio.

xxx Driven Development

2011-09-21T13:35:00.000-07:00

Desde hace ya tiempo, vienen desgranándose ;) diversos paradigmas de desarrollo con el nombre de "no-se-qué Driven Development".

Y aunque algunos de ellos son muy jóvenes y están aún en pleno arranque, no está de más echar a un vistazo a la evolución, no siempre lineal en el tiempo:

Database Driven Design (¿DDD?).
Es el diseño de una aplicación partiendo del modelo de datos. Durante muchos años explicado en las universidades y otros centros de enseñanza, al final es más una consecuencia de la forma de pensar que de una necesidad de arquitectura o diseño. La necesidad de establecer un modelo de datos como "base" en las fases más tempranas, conlleva que tratemos de definir al máximo los datos, su estructura y flujo. Al final, las pantallas no dejan de ser un mero reflejo de dicho modelo. Por desgracia, esta forma de trabajo con el tipo de aplicaciones actuales orientadas al usuario, donde la interfaz es el rey, y lo importante es hacer sentir cómodo al usuario.

UI Driven Design (UIDD)
He sido fan de este modelo de diseño, pero ha chocado con una realidad, y es que es relativamente sencillo definir un modelo de datos y una capa de negocio que cumplan con los objetivos. Sin embargo, las interfaces de usuario se resisten, en especial con la explosión del mundo web, que ha acabado barriendo los desarrollos de escritorio (en orden de magnitud). Ha tenido que llegar el año 2010/2011 para que tengamos que oir (otra vez) la promesa de que con nuevos estándares (esta vez HTML5 entre otros), la web será "como las aplicaciones de escritorio". Gracias por reinventar la rueda, pero seguiremos esperando. Mientras tanto, las aplicaciones (de escritorio o web), siguen fallando de forma habitual en la interfaz.

Interaction Design (Goal-Oriented Design=GOD)
Similar a la anterior, está apadrinada (entre otros) por Alan Cooper, experto en temas de interacción y usabilidad (os recomiendo su famoso "The Inmates are Running The Asylum", donde trata la metodología "Goal-Oriented Design"). Bajo mi punto de vista, es una metodología desaprovechada, y que sigue cubriendo aquello que muchas otras metodologías están buscando abordar: la satisfacción del usuario.

Test Driven Development (TDD)
Esta vez sin seguir secuencia cronológica, la TDD o metodología de desarrollo guiada por pruebas, nos invita a acelerar los desarrollos y mejorar la calidad de los productos, basándose esta vez en otra de las fases o actividades del ciclo de vida: las pruebas. De nuevo, una gran promesa, todavía sin caer en el desprecio, pero que exige por parte de los equipos de desarrollo de dos ingredientes no habituales: disciplina y mesura. Disciplina para crear con antelación los tests, y mesura para saber hasta dónde llegar con las pruebas.

Domain Driven Design (DDD)
Según el sitio web http://domaindrivendesign.org es una forma de pensar, en lugar de una metodología. Dejando aparte dogmatismos insondables, se centran en la parte del diseño de un modelo, de la capa de negocio principalmente. De esta forma, se pretende dar solución a los proyectos en los que la complejidad y el tamaño del software a construir haga inabordable la tarea. Bajo mi punto de vista, esta forma de trabajo, sigue adoleciendo de problemas similares a los que presentan otras técnicas. De hecho, si una de las causas del fracaso del software es la complejidad del software, tenemos un grave problema no metodológico, sino de análisis y de visión del producto.

[Editado]: ¡me había dejado Feature Driven Development!
Feature Driven Development (FDD)
Es una metodología de desarrollo ágil, centrada en el modelo, y en la que el desarrollo está liderado por los requisitos. Es una metodología que parece encajar muy bien en equipos y proyectos grandes. Ya le dedicaré un post con más tranquilidad otro día.

Requisitos y la importancia del diseño

2011-09-21T06:34:00.000-07:00

Revisando documentación, he encontrado esta imagen que resume la importancia de:

Los requisitos
El diseño de la solución
La coherencia en las comunicaciones hacia el cliente
La importancia del prototipo
Las carencias en la documentación, soporte e implementación

Como la considero un clásico que todos los que nos dedicamos al desarrollo de software deberíamos conocer, ahí va para los que no la conozcáis.

Los que decís que lo teníais muy visto...más os valdría recordarlo de vez en cuando (me incluyo), porque cometemos de forma constante errores como estos, y algún día habrá que dejar de echar la culpa a los demás.

Para este tipo de problemas, existen varias soluciones o técnicas que nos pueden servir:

Prototipado. El cliente puede ver con anticipación, la solución final o partes de la misma. Sin embargo, esto se queda simplemente para formación teórica, ya que en la práctica, los programas de software son mucho más complejos que lo mostrado en la figura. El cliente, hasta que no USE realmente en su día a día el producto, no será capaz de detectar lo buen o mal diseñado que estará.
Ciclos de vida iterativos en general. Prometen tener soluciones parcialmente construidas, que el cliente puede validar. Tiene los mismos problemas que el prototipado.
Metodologías ágiles. Normalmente, las metodologías ágiles incluyen entregas frecuentes y un ciclo de vida iterativo que facilita evitar estos problemas. Sin embargo, en absoluto son garantía de evitar los problemas descritos en la imagen. Tiene también problemas

Como vemos, no hay balas de plata. Al final, la mejor herramienta es la experiencia. Conocer el negocio del cliente, y conocer el negocio del desarrollo de software.

Como ejemplo, voy a dar un caso real. Para una empresa, se solicitó una aplicación para rellenar unos formularios tipo. La primera aproximación que se tomó, y que coincidía con lo que pedía literalmente el cliente, fue mostrar en pantalla "el formulario tal cual". Así se hizo, y resultó un fracaso. El trasladar a la pantalla el formulario produjo múltiples problemas, ya que la metáfora usada (el mostrar el formulario tal cual), contradecía las metáforas de usabilidad que había en el resto de aplicaciones, y a las que estaban acostumbrados los usuarios. Además, resultó que cualquier cambio en el formulario físico (el report), obligaba a cambiar la pantalla de inserción de datos.

La importancia del análisis

2011-09-19T05:46:00.000-07:00

Un análisis (funcional o técnico), es un punto importante, en el que el analista de turno "se moja" y decide implementar los requisitos de una forma implementable. El problema, como se ejemplifica a la perfección en la imagen siguiente, es que hay que tener antes la experiencia suficiente para (entre otras cosas), saber identificar si hay componentes o incluso sistemas enteros que implementan nuestra misma solución.

Fuente: http://www.nosololinux.com/2009/03/27/la-nosolotira-grandes-ideas/

TFS y las reglas de CheckIn de asociación a WorkItems

2011-09-15T12:06:00.000-07:00

Como ya sabréis lo que desarrolláis en Microsoft .Net, se pueden establecer reglas para que las operaciones de CheckIn en el repositorio de código de TFS, exijan asociar a cada subida de código uno o más WorkItems.

Esta regla, es mucho más importante de lo que parece, ya que esconde por detrás un grave problema de gestión y visibilidad del estado del desarrollo.

¿Qué ocurre si haces un CheckIn, y no asocias ningún workitem?. Pues que la tarea no está planificada, no se puede detectar a qué se han debido los cambios. Si no es un desliz, y realmente no hay tarea (workitem) planificada,

estamos haciendo algo innecesario, o bien
estamos haciendo algo necesario no planificado, o bien
estamos haciendo algo necesario, planificado, pero que está oculto.

En el primer caso, tendríamos al típico programador que dedica su tiempo a tareas agradables, que le gustan, o que simplemente está probando algo que se le ha ocurrido. Sería un caso típico de procrastinación (ver entradas anteriores en este blog sobre este tema).
En el caso 2, hay varias opciones, pero una típica sería cuando hemos dado algo por cerrado, y recordamos un requisito de diseño, una funcionalidad que se habló pero no se incluyó en los workitems, etc.
En el caso 3, por ejemplo, un ejemplo habitual es cuando queriendo o sin querer, hacemos cosas planificadas en el workitem, pero se nos olvida asociarlo. Puede ser que se nos olvidara por ejemplo las pruebas unitarias, así que las pasamos, corregimos cosas de un workitem antiguo, pero no lo indicamos.

En proyectos con metodología no iterativa, muchas veces estos casos quedan ocultos, y tienen un impacto menos apreciable en la planificación (aunque no dejan de ser importantes). Sin embargo, con metodologías iterativas, tipo Scrum, el impacto es mucho mayor. El hecho de que en una iteración de 1 o 2 semanas, tengamos tareas realizadas pero no planificadas, puede suponer una desviación importante. Si ya las tareas que se realizan encima no son necesarias, el desastre está asegurado.

¿Qué tiene que ver esto con la calidad? Pues mucho, porque como veremos en un próximo post sobre cómo medir la calidad, ésta no es sólo "nº de defectos". En el desarrollo de software, un factor clave es la trazabilidad. Si no somos capaces de saber en qué partes de nuestro programa están implementados los requisitos (o las "Historias de Usuario" en terminología Scrum), una de dos:

O alguien ha rellenado una matriz de trazabilidad (infame pero útil documento del cual algún día hablaremos)
O simplemente, no podremos identificar dónde están implementados esos requisitos. Como supuestamente estamos abiertos al cambio, cualquier cambio en los requisitos hará que tengamos que dedicar un tiempo precioso a rastrear el código para saber cuánto hay que cambiar y dónde. Y si no somos capaces de identificar el impacto de un cambio, me rio yo de las estimaciones que haremos.

Test de habilidades profesionales

2011-09-15T07:25:00.001-07:00

Aún a riesgo de caer en el exceso de blogs con la etiqueta humor, hoy traigo otro, que por otro lado hará las delicias de los profesionales (incluyendo los ajenos al mundo del desarrollo del software).

A continuación, presento un test de preguntas que utiliza Accenture para ayudar a entender tu forma de pensar. Las preguntas no son difíciles. Para ver las respuestas, basta seleccionar con el ratón el texto en el hueco que hay debajo de cada pregunta (sí, sí, es texto del color de fondo, por eso no lo ves).

1. ¿Como meterías una girafa en el frigorífico?

La respuesta correcta es: abre el frigorífico, mete la girafa y cierra la puerta.
Esta pregunta comprueba si tiendes a hacer las cosas de forma excesivamente complicada.

2. ¿Cómo meterías un elefante en el frigorífico?

Respuesta incorrecta: Abre el frigorífico, mete el elefante y cierra la puerta.
Respuesta correcta: abre el frigorífico, saca la girafa, mete el elefante y cierra la puerta.
Esta pregunta comprueba tu habilidad para ser consciente de las repercusiones de tus acciones.

3. El Rey León está en una conferencia de los animales, donde están todos menos uno. ¿Qué animal no está allí?.

Respuesta correcta: el elefante, que está el pobre aún metido en el frigorífico.
Esta pregunta comprueba tu memoria. Llegados a este punto, incluso si no respondiste correctamente las 3 preguntas anteriores, seguramente la siguiente sí lo harás.

4. Hay un río que debes cruzar, pero está habitado por cocodrilos. ¿Cómo lo harías?

Respuesta correcta: lo cruzas nadando y punto, ya que todos los cocodrilos están atendiendo la conferencia del Rey Leon!!.
Esta pregunta comprueba si puedes aprender rápidamente de tus errores.

Según Accenture, alrededor del 90% de los profesionales tuvieron todas las preguntas mal. Cuando se les hizo esta pregunta a preescolares, éstos tuvieron varias respuestas correctas.
Según Accenture, esto concluyentemente contradice la teoría de que la mayoría de los profesionales tienen el cerebro de un niño de 4 años.

Fuente: http://www.creativityatwork.com/articlesContent/creativity-quiz.html

9 maneras de lidiar con un jefe tonto

2011-09-14T14:17:00.000-07:00

Bueno, en primer lugar, y para tranquilizar a propios y extraños, diré que vamos a hablar de situaciones hipotéticas, de charlas habidas alrededor de un vaso de café, pero que en absoluto están relacionadas con situaciones reales.

Por cierto, recordad que las imágenes como la que acompaña este blog, podéis ampliarlas sin más que hacer clic sobre ellas. Además la de hoy es una tira de Dilbert que os recordará más de una ocasión en vuestra vida laboral.

En alguna ocasión, casi todo el mundo se ha encontrado con alguien que parece seguir el principio de Dilbert: alguien que ha ascendido en la escala laboral, de forma inversamente proporcional a su aptitud. Y que a pesar de esgrimir de forma evidente y constante dicha falta de aptitud, se las ingenia para seguir siendo jefe o incluso seguir ascendiendo. Si usted cree que su jefe es así, aquí van algunos consejos que quizá le hagan la vida más fácil.

Intente hacerle quedar siempre por encima. Vamos, hacerle la pelota no le irá mal, y con suerte, conseguirá aumentar la estima de su jefe lo suficiente para que desaparezca (quizá, siguiendo con el principio de Peter, sea ascendido en base a su incompetencia).
Documente su trabajo. Tome nota de qué le pide su jefe, en qué términos y condiciones, etc. Cuanto más sea lo absurdo o imposible que le pida su jefe, tómese más molestias en anotarlo, conseguir pruebas, guardar mailes, etc.
No critique a su jefe de forma abierta. Si su jefe la caga en una reunión, asuma usted el rol de jefe, haciéndole a puerta cerrada sutiles comentarios acerca de lo desacertado de su, por otra parte, magnífica exposición.
Evite saltarse a su jefe. Hágalo partícipe de todo, sobre todo de sus éxitos. Con un poco de suerte, se los atribuirá él, y al ascender, se librará de su supervisión.
No espere que su jefe cambie.
Manténgase alejado en público de su jefe. Por asociación, puede usted convertirse en "el tonto que es amigo del tonto".
Cambie de dirección. Cuando su jefe trate de darle una orden, ofrezca una lista de problemas espantosos e insolubles, y pídale su opinión.
Cambio gradual de objetivos. Consiste en diseñar una serie de objetivos en el tiempo para un proyecto que sean más fáciles de cumplir o, de hecho, que sea algo que usted ya haya realizado.
Entrene a su jefe tonto. Ofrezca a su jefe un dulce cada vez que pase cerca de su mesa y hace un comentario positivo. Si el comentario es negativo, no le de ningún dulce. Observará cómo el número de comentarios negativos que su jefe le hace, decrece con el tiempo.

Fuente: http://www.eltiempo.com/archivo/documento/MAM-1011314

Procrastinación (II)

2011-09-13T23:57:00.000-07:00

Visto el éxito de del anterior post sobre procrastinación, me he animado a ahondar algo más sobre el asunto. Si bien en un principio me hacía gracia la palabrita, si rascamos sobre la superficie, encontramos un tema actual y candente, una cruda realidad de estos tiempos que corren.

Además, la viñeta de Dilbert que acompaña este post no tiene desperdicio.

Es bien conocido que estos días se habla mucho de que la cultura de internet, twitter, facebook, blogging, etc., parece que está provocando que tengamos déficit de atención, que seamos incapaces de concentrarnos en un tema por tiempo suficiente hasta su resolución, o al menos hasta que tengamos un grado de análisis suficiente para continuarlo posteriormente. Las consecuencias, pueden ser pues:

baja productividad en nuestros proyectos y tareas
baja calidad en los resultados

¿Cuáles son las causas?

Psicológicamente, mostramos cierta resistencia a fijar objetivos, o al menos, nos cuesta afrontar la evaluación de su necesidad y la decisión de llevarlos a cabo.
Cuando lo hacemos, no ponemos los medios adecuados hasta su resolución. Como leí hace tiempo en una cita relativa a los malos managers: "el mal manager es el que mantiene los recursos alejados de los objetivos".
No somos coherentes a la hora de decidir "qué es importante" y "qué es urgente".
Usar el placer como brújula, dando satisfacción a nuestros deseos inmediatos, en lugar de realizar las tareas que por otra parte, ¡ya teníamos planificadas y priorizadas!

¿Cuáles son los resultados?

"Mañana me pongo". Vamos, fijo que me pongo. Pero segurísimo.
Uf, como evitar entrar a comentar fotos de gatitos en Facebook, cuando el informe mensual de resultados de xxxxx lo puedo hacer mañana.
Autosabotaje. Somos nuestros peores enemigos. Todos los años vuelta a los mismos objetivos de mejorar el inglés, ir al gimnasio, bla, bla, bla. Y antes de volvernos a poner los mismos objetivos, no nos paramos a analizar las causas de que no se hayan llevado a cabo.
etc, etc y etc otra vez.

¿Qué acciones podemos tomar para evitarla?

Olvida los detalles. Lo imperfecto es bueno. Utiliza la regla de Pareto: aplica el 20% de esfuerzo, para lograr el 80% del resultado. Normalmente será suficiente. En el caso del desarrollo de software, asegúrate que no estás creando requisitos artificialmente, o que el nivel de calidad es al menos el estrictamente acordado. A partir de ahí, hay que hacer un balance entre lo necesario y lo deseado.
Acepta lo planificado. No lo consideres una obligación. Acostúmbrate a disfrutar con lo que haces, ya que si no es así, el subconsciente se encargará de encontrar otra tarea que sí te haga disfrutar, y actuará de potente imán. Lo peor de todo es que llegamos al autoengaño, aceptando tareas de disfrute como planificadas, y eso no debemos permitirlo.
Asegúrate que entre tus actividades, hay actividades que te gusten. Pueden estar dentro o fuera del trabajo, pero asegúrate que están ahí. Planifica el ocio, de forma que se alterne en tu vida con el trabajo (el trabajo planificado y necesario).
Analiza las tareas que emprendas. Cada vez que emprendas una nueva acción plantéate: ¿estaba planificada? ¿la estás haciendo en el tiempo en que tenías ya algo planificado?

Libro sobre TDD gratis y en castellano

2011-09-12T23:58:00.000-07:00

Hoy tenemos un libro gratis y en castellano sobre el desarrollo según TDD en este link.

En el link, además del propio libro (descargable en varios formatos), ofrece diversos enlaces que ofrecen blogs, información adicional, formación, etc., todo ello relativo a TDD.

Para los perdidos, despistados, o los que no hayáis visto TDD en alguna de mis anteriores entradas, vamos a incluir un breve resumen.

TDD son las siglas de Test Driven Development. Hoy en día, tenemos varias metodologías XDD, sustituyendo "X" por alguna de las facetas del desarrollo. En este caso, el desarrollo está dirigido o guiado a partir de los Tests. El objetivo es definir en primera instancia un conjunto de pruebas que recojan al máximo una verificación de los requisitos. De esa forma, el código se va desarrollando posteriormente contra unos tests ya establecidos. Los tests se suelen automatizar, ofreciendo un paradigma de desarrollo bastante estable. Por desgracia, y esto enseguida gustará a sus detractores, no es en absoluto perfecto, y tiene problemas relativos a la variabilidad de los tests, ya que éstos han de cambiar de forma síncrona con los cambios en los requisitos.

Hoy en día, un gran número de metodologías ágiles incluyen esta técnica de desarrollo, aunque hay que decir que como técnica, es totalmente ajena al desarrollo ágil, y puede ser implementada en cualquier otra metodología.

Métricas: LOC

2011-09-12T05:49:00.000-07:00

LOC es un acrónimo de "Lines of Code". Se utiliza como métrica en diversas situaciones, en las que se mide el número de líneas de código. Usualmente, se utiliza la variante "KLOC", que son miles de líneas de código.

¿Que qué le pasa a esta métrica? Pues que está maldita. Sí, sí, maldita. Ni el exhorcista más aguerrido podría devolverle el honor a esta defenestrada medida. Pero en fin, como me gustan las causas perdidas...ahí vamos.

¿Porqué está maldita? Pues porque basta presentarla para que la gente ponga caras raras, empiece a generar excusas, exponga argumentos en su contra, etc. Sin embargo, esta métrica tiene cosas a su favor, al menos en apariencia:

Es fácil de medir. Pues sí, eso es cierto. Prácticamente cualquier entorno lo ofrece, y todos los plugins de métricas lo ofrecen.
Es fácil de combinar: muchas otras métricas pueden venir referidas a ella (Ejemplo: "nº de defectos por cada mil líneas de código").
Ofrece una medida aproximada del tamaño de un software, y de su complejidad. Pues vaya, esto también es cierto. Un programa de 1000 líneas no sé si será el doble de grande que otro de 500, pero más grande, sí.

Sin embargo, en este mundillo se encuentran muchos argumentos en su contra:

No es una medida fiable de productividad personal. La respuesta obvia sería: "pues claro". En este mundillo de las métricas, uno aprende que lo primero que hace un programador es ver en qué medida la métrica puede valorar su trabajo. Es el caso típico de: "pensar mal". El problema es que las métricas están siempre para conocer el proyecto, y no siempre para ver el rendimiento de las personas. Sin embargo, sí puede obtenerse (y se debe, de hecho) métricas del estilo: LOC totales por persona, LOC modificadas por persona en un período, LOC nuevas por persona en un período, etc.
Penaliza a lenguajes de alto nivel. Toma, pues claro. Los lenguajes de alto nivel están para eso. Para que con menos líneas, se hagan más cosas. Lo mismo que los frameworks y las librerías: para ahorrar líneas de código. Pero de nuevo volvemos a lo mismo: esta métrica permite comparar sólo en el caso de que se pueda comparar. No podemos comparar solamente lenguajes similares, sino proyectos en que la arquitectura sea equivalente.
La complejidad de un software no depende de su tamaño. Hay programas muy pequeños, endiabladamente retorcidos, mientras que hay otros muy grandes, pero muy simples en concepción y ejecución. De nuevo, la respuesta es "pues claro". El problema es que una métrica no es más que un número. Para obtener conclusiones, normalmente hay que usar varias métricas e indicadores de los proyectos.

La conclusión vendría a ser que esta medida es para lo que es, para apoyo, para dar una visión orientativa que por sí sola nunca puede ser concluyente (lo que no deja de ser cierto en general para prácticamente todas las métricas).

Desde luego, si no podemos medir algo, no podremos decir que esté bajo control.

El valor de lo predeterminado

2011-09-12T05:43:00.000-07:00

El encontrar nombrado a uno de mis referentes (Alan Cooper*), en un artículo de la revista MSDN, me ha hecho leerlo y recordar sus libros.

Y es que como ya Alan Cooper hablaba en su libro "About Face", el tema de los valores por defecto (los valores predeterminados), son una de las principales claves de la usabilidad, y la causa del éxito o fracaso de una gran mayoría de proyectos software.

Realmente, es un factor más importante que los propios requisitos y funcionalidades implementados, aunque esto se le resista hoy día a una gran masa de desarrolladores. Fijémonos por ejemplo en los teléfonos móviles. Se sacan constantemente modelos, pero el comentario que se oye es del estilo: "hasta la versión del firmware xxxxx, la cámara sacaba unas fotos penosas", o también: "la pantalla no respondía bien en las versiones anteriores a la xxxx".

Hemos llegado a aceptar que los productos que compramos recién salidos al mercado, simplemente "no están ajustados". Salen con la funcionalidad (requisitos) que aparece en los catálogos, pero no satisfacen realmente a los usuarios, es decir, falla la usabilidad. Y ese fallo, está originado en los valores por defecto (firmware, parametrización, etc).

Clippo, que tantos quebraderos de cabeza nos dio

Algunos veteranos todavía recordamos la presencia de "Clippo", el famoso asistente que presentaron por defecto en versiones antiguas de Office, que acabó defenestrado ante su insistencia en frases del estilo: "Parece que estás escribiendo una carta". No es tan importante la ayuda ofrecida, como el crear una buena base de configuraciones por defecto, y saber asociar a cada perfil de usuario, su configuración más acertada.

De hecho, es desproporcionadamente más importante el que las funcionalidades estén accesibles cuando se necesitan, y sea cómodo encontrarlas, que el hecho de que haya cientos de funcionalidades, pero estén tan ocultas y rebuscadas, que sólo ciertos perfiles de geeks, sepan dónde están. Una funcionalidad que introdujo Office hace ya varias versiones, es adaptar automáticamente su interfaz, para adaptarse al tipo de tarea que se está realizando, ofreciendo los botones y menús más usados, y llegando a esconder los menús y botones que con el tiempo se dejan de usar. Muchos ni nos hemos dado cuenta, y simplemente dejamos que los botones más usados o más apropiados al contexto, aparezcan ahí.

Tampoco se trata de que hagamos las aplicaciones complicadas, sino de que pensemos en quién las va a usar, pensemos en 2 o 3 tipos habituales de usuarios, y las configuremos para ellos. Después de todo, recordad que el principal usuario de nuestros programas, no solemos ser nosotros.

(*) Alan Cooper (http://www.cooper.com/) se hizo famoso por escribir varios libros sobre usabilidad, y ser el creador de una de las interfaces más usadas hoy día en los entornos de desarrollo (sí, del estilo de Visual Basic). Estigmatizado por ser "el padre de Visual Basic", hoy día es consultor y propietario de su propia empresa dedicada a las interfaces, usabilidad, etc. He tenido la suerte de disfrutar devorando sus libros:

About Face: The Essentials of User Interface Design
The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity

¿Más siglas? MDE, MDD, MDA

2011-09-10T07:38:00.000-07:00

Hoy tenemos más siglas de las que hablar:

MDA: Model-Driven Architecture.
MDD: Model-Driven Development.
MDE: Model-Driven Engineering.

En general, los tres están relacionados con el paradigma de desarrollo que utiliza o propone el uso de modelos como el principal artefacto del proceso de desarrollo. O al menos, como el artefacto que dirige y sirve de arranque al desarrollo.

Lo que se pretende, es que el código se genere de forma semi-automática, a partir de dichos modelos. Según estas metodologías, partiríamos de un modelo diseñado con un programa (por ejemplo, con Software Architect), y él solito nos crearía el código asociado. El lenguaje para el modelado, bien podría ser UML, aunque existen otras alternativas.

El proceso de preventa

2011-09-09T05:19:00.000-07:00

Pocas veces (más bien ninguna), cuando hablamos de calidad en el mundo del desarrollo software, nos acordamos de la preventa. Parece que todas las metodologías arrancan cuando está firmado el contrato, y terminan tras el despliegue (con suerte, tras el mantenimiento).

El problema es que se debe tener en cuenta también la preventa. Es decir, el proyecto realmente debemos gestionarlo desde que decidimos presentarnos a una propuesta, o cuando decidimos ir a llamar al cliente, etc.

Muchos os preguntaréis ¿pero esto de la venta también tiene que tener metodología? Pues claro. Y por varios motivos:

Como toda actividad de gestión, debe haber un procedimiento habitual de trabajo, donde se definan responsabilidades, roles, actividades y entregables.
Debe hacerse un seguimiento. Normalmente la alta dirección querrá saber periódicamente datos de: posibles acciones de preventa, acciones en marcha, acciones realizadas, nivel de éxito de dichas acciones, etc. Esto nos lleva a las inevitables métricas, informes, etc.
Y lo que es más importante: debes estimar. Y no es cualquier estimación, es la primera, y precisamente la que se hace cuando tienes menos información de lo que hay que hacer. Por eso requiere de unas herramientas y técnicas distintas de las usadas para estimar cuando estas a mitad del proyecto.

Al final, no deja de ser como un pequeño proyecto:

Tiene sus fases: por ejemplo podría hablarse de "Oportunidad", "Análisis", "Diseño y ejecución de la oferta", "Revisión y presentación de la oferta"
Tiene asociado una gestión: durante las fases anteriores, deberá haber una planificación, una estimación de esfuerzo (¿si debemos presentar una oferta antes del día x...llegamos?), etc. También habrá que registrar las horas invertidas, para controlar el tiempo dedicado.
Tiene sus entregables: el material que usemos para hacer la venta, presentación, etc. Si por ejemplo es una propuesta para un concurso público, ahí entraría toda la documentación a presentar. Otro entregable o documento a controlar podría ser el contrato, la estimación,....
Tiene sus roles y responsabilidades: alguien se responsabiliza de preparar el material, otra persona lo supervisa, otra (o la misma) presenta la oferta...etc

Lo que no hay que perder de vista, es que la labor comercial, como cualquier otra...tiene un coste. Y como todo coste, sería una irresponsabilidad no darle un seguimiento y tener un mínimo control.

Además, cuando hablamos de metodologías, parece que cuando el equipo de desarrollo comienza (bien con el análisis, diseño, o el propio código), es el PRINCIPIO DEL MUNDO. Es como el big-bang, el principio de la creación. No hay nada anterior, y si lo hay..."no queremos saberlo". Y no es así. No sólo hay que controlar esas acciones, sino que están relacionadas con el propio desarrollo:

¿Se conoce la fecha de entrega? Pues claro: anda, léete el contrato.
¿Y los requisitos me los invento? Pues tampoco: anda y léete la propuesta. A veces ahí están detallados los requisitos a un nivel impresionante.
¿Y porqué esto está estimado así? Pues revísate la plantilla de estimación.

Scrum y la motivación

2011-09-08T21:57:00.000-07:00

Parece ser que un equipo está motivado principalmente por dos factores:

Visibilidad (logros tempranos)
Reconocimiento

Pero existe un peligro a tan fantástica conclusión, y es que al contrario, podría usarse Scrum para motivar al personal, simplemente porque "parece ser que los equipos que usan Scrum están más motivados". Es decir, olvidaríamos los requisitos, premisas y dogmas de Scrum, para centrarnos en "tener contentos a los programadores".

Recientemente me he encontrado con premisas de este tipo: el seleccionar Scrum, como herramienta de motivación para los equipos de desarrollo. Después de todo, no parece una mala idea el motivar a los equipos mediante un cambio de forma de trabajo. Al final, el problema está siempre en necesidades contrapuestas. Por desgracia, al igual que tenemos un triángulo del software (calidad, tiempo, recursos), también tenemos un triángulo de actores que se relacionan con el desarrollo del software:

El cliente: tiene unas expectativas, y unos requisitos funcionales. No ve valor en el código, sino en necesidades de negocio resueltas.
La dirección (los jefes del equipo de desarrollo): la empresa no vive del aire, y para poder seguir desarrollando, hay que poder seguir emitiendo facturas. Tiene unos requisitos económicos y de negocio. Estas necesidades de la dirección está íntimamente relacionada con las labores "ingratas" o rechazadas por parte del equipo desarrollo (control, monitorización, documentación).
El equipo de desarrollo: En este caso, se trataría más bien de unos requisitos de satisfacción laboral, de bienestar social, reconocimiento, y algo que parecemos olvidar siempre: hay que cobrar todos los meses. No sólo de metodologías ágiles y buen rollito vive la gente.

Hay que tener en cuenta estas interrelaciones entre los tres, ya que podemos encontrarnos con que la implantación de Scrum u otras metodologías ágiles, no consiga la motivación deseada, o lo haga de forma temporal.

Es por eso, que en vez de buscar la mera implantación de una metodología, lo que hay que hacer es detectar las necesidades de los actores alrededor del desarrollo software, y lograr un equilibrio mediante:

Políticas de reconocimiento de logros
Metodologías que mediante técnicas ágiles obtengan logros tempranos, pero que no perjudiquen las necesidades de información de los clientes y gestores.
Sistemas de mejora continua, que satisfagan tanto a la empresa como a los desarrolladores.

Tipos de requisitos - no sólo de usuario

2011-09-07T23:46:00.000-07:00

A la hora de tomar requisitos, aunque nos enfrascamos siempre en lo que más nos gusta (recordad mi entrada sobre procrastinación), que suelen ser los requisitos que el usuario nos comunicada, es labor y responsabilidad de los buenos analistas el saber "rascar" la fachada y obtener una visión global de las necesidades a todos los niveles.

Digo esto porque hay mucho más allá de los requisitos que solemos anotar al hacer las entrevistas con los usuarios. A continuación, una lista de tipos de requisitos, obtenida del libro que estoy leyendo (*):

End-user requirements
Software requirements, or functional requirements
Operational requirements
Platform requirements
Corporate requirements
Compliance requirements

Aunque estemos tentados de quedarnos con los dos primeros, que son los más directos de obtener, es esa labor policíaca de "rascar" y obtener ese paquete de requisitos, restricciones, etc. lo que diferencia de un analista de verdad, de un señor que se limita a rellenar la ficha.

Por poner algunos ejemplos:

Corporate: los requisitos corporativos pueden ser las normas de la empresa, la forma de trabajar (formalmente establecidos, o no). A veces una empresa es una filial de otra mayor, pues cuidado, que esa otra empresa mayor, puede tener requisitos corporativos que debamos tener en cuenta, y que quizá nos cueste descubrir a primera vista.
Operational: dentro de los operativos, podemos encontrar restricciones legales del negocio (legales a nivel local, regional, estatal, etc.) Por ejemplo, un software para una constructora debería tener en cuenta las restricciones legales, como pueden ser legislaciones locales de tiempo de conservación de documentos, de normas a cumplir etc.

Acelere sus proyectos: resumen de técnicas ágiles

2011-09-06T06:49:00.000-07:00

Voy a recopilar una lista de técnicas ágiles, o que de alguna manera pueden influir en acelerar la entrega de un proyecto en cuanto a calidad y funcionalidad:

Pair Programming. Programación por parejas.
Desarrollo Iterativo e Incremental.
Entregas frecuentes
KISS (=Keep It Simple, Stupid); simplicidad del código
YAGNI (=You Ain't Gonna Need It). Simplicidad general (funcional, arquitectónica, etc.)
Refactorización del código
Feedback rápido (realimentación)
Automatización de pruebas
Integración Continua
TDD (=Test Driven Development), empezar el desarrollo escribiendo los tests
FDD (=Feature Driven Development). Como el anterior, pero el desarrollo está guiado por los requisitos.
Prototipado
Peer Review. Revisión entre pares. Alguien de igual categoría (aunque preferiblemente de mayor experiencia), revisa el entregable.
DRY (=Don't Repeat Yourself)
HOLLYWOOD. Principio que favorece la alta cohesión y e bajo acoplamiento (facilitando el debug, pruebas y mantenimiento posterior del código)

Algunas de ellas han sido absorbidas como suyas por ciertas metodologías ágiles.
Para otro día, con tiempo y ganas, daré un repaso detallado de ellas, sus beneficios, y por desgracia, también sus riesgos/problemas.

Desarrollar sin programar (II)

2011-09-06T03:16:00.000-07:00

Mira por donde, Microsoft ha sacado una herramienta llamada Visual Studio LightSwitch, que encaja con el tipo de aplicaciones que permiten crear aplicaciones "sin programar".

Básicamente, permite hacer una completa aplicación en 3 capas en unos sencillos pasos:

Conectar a una base de datos
Definir las entidades de datos
Crear pantallas para las entidades (es posible crearlas automáticamente a partir de las entidades)
Faltaría ya solamente añadir código a la capa de negocio, aunque la validación y reglas básicas, pueden configurarse en el propio editor.

Visión global de las redes sociales

2011-09-05T23:59:00.001-07:00

En la web http://www.elandroidlibre.com/, aparece una imagen que explica con un símil bastante gráfico, cómo son, y en qué se diferencian las principales redes sociales:

¿No anda muy desencaminada de la realidad?.

¿Por qué fracasa la formación en las empresas?

2011-09-05T23:59:00.000-07:00

En primer lugar, me gustaría aclarar que este post no está relacionado con mi empresa actual, ni con ninguna en particular. La información que ofrezco está basada en opiniones de diversos profesionales en diversas empresas.

El tema, bien mirado, está relacionado con los dos principales del blog: calidad y desarrollo de software.

Vamos a ver una lista de los problemas más habituales:

Una queja de los empleados, suele ser que la formación ofrecida, está pensada desde el punto de vista de las necesidades de la organización.
La formación ofrecida está obsoleta
La formación ofrecida no cubre las necesidades actuales de los proyectos
Las empresas cuentan con un presupuesto, una subvención, ...(en general, un dinero a gastar en formación), y se enfoca más en el qué (que se gaste ese dinero, se comunique y publicite, etc), que en el cómo (alineamiento de la formación, con las necesidades organizativas, de los proyectos, y de los empleados).
Las empresas, en general, no se preocupan de que el dinero en formación tenga resultados. (satisfacción de los empleados, grado de cobertura de necesidades detectadas, etc). Al no plantear objetivos medibles y no evaluar los resultados, no hay una visión global del rendimiento de la inversión en formación.
Los cursos no se asignan a los empleados que más partido pueden sacar de la formación, sino que se usan criterios subjetivos (amiguismos, etc.)
La empresa confunde el tener formación con el estar preparado para ofrecer soluciones. A veces se pretende sustituir la experiencia por formación, con escasos resultados.
En ocasiones, la alta dirección no le da la importancia que debería.
Las formaciones se contratan por precio y disponibilidad, lo que hace que a veces fracasen por ineficacia del formador, materiales, etc.
No siempre la formación está alineada con las expectativas y carrera profesional de los empleados.

11 trucos para aparentar que siempre está ocupado

2011-09-05T05:52:00.000-07:00

He visto en un blog un tema que me ha parecido muy interesante, y está sacado en última instancia de Scott Adams, creador de Dilbert y todo lo que lo acompaña (tiras cómicas, libros, películas, etc):

Quéjese constantemente de estar "abrumado". Utilice frases como "estoy hasta el cuello" o "saltando de un fuego al otro" para que su trabajo suene como sexy y peligroso.
Lleve un pedazo de papel a todas partes. Para que sus gestos y lenguaje corporal cobren urgencia, imagine que es algo increiblemente importante, como una orden de ejecución firmada por el gerente.
Nunca limpie su espacio de trabajo. Después de todo, si tuviera tiempo para malgastar, no viviría como un cerdo. De vez en cuando ordene u ojee papeles en su puesto. Simule leerlos con interés y preocupación.
Simule un lenguaje corporal como si estuviera estresado. Resople de vez en cuando. Rásquese la cabeza. Suelte alguna frase contundente del tipo “¿esto es imposible, no lo saco ni en un millón de años?". Así evitará que la gente le moleste.
Mandar e-mails parece trabajo. Mande e-mails a sus amigos y familiares con frecuencia.
Si tiene ganas de hablar, en lugar de trabajar, hable con su jefe. Eso cuenta como trabajo, sin importar de qué hablen. El tópico ideal para la conversación es el mal comportamiento laboral de sus compañeros de trabajo. Hay una variante de este último que es: "si su jefe va a tomar café, vaya y aproveche para tomar otro y hablar con él. Hay un punto extra si consigue
Si utiliza gafas, deje unas viejas en su escritorio, como si usted fuera a regresar en unos minutos. Después, váyase a casa.
Deje mensajes de voz a sus compañeros de trabajo a la 1:00 am, aún cuando sólo se haya levantado para ir al baño. Si realmente quiere despertar admiración, déjele un mensaje a su jefe con sus comentarios sobre el anticuado sistema de archivos usado en la empresa, a las 11:30 pm del 31 de Diciembre.
Asegúrese de involucrarse en proyectos incuantificables. Escoja proyectos de consultoría, asesoría y participación. Evite cualquier cosa que tenga una fecha límite fija y cercana.
Aprenda a dormir dando la espalda a la entrada de su espacio de trabajo. Tendrá que practicar evitar que su cabeza caiga de lado, pero vale la pena. Si no lo logra, cómprese un collarín del color de su piel.
Despotrique de su trabajo tanto como pueda. Esto se considera trabajo, aún cuando es divertido. Como en el punto 1, su lenguaje corporal debe acompañar a la expresión oral.

Desarrollar sin programar

2011-09-04T10:27:00.000-07:00

Imaginaos un futuro en que se pudiese crear software sin programar ni una sola línea de código (ojo, no he dicho sin saber programar, aunque tampoco quiero decir con ésto que sea obligatorio saber programar para crear este tipo de software).

Imaginaos un futuro en que con sólo conocer el proceso de negocio, la interacción con el usuario y otros sistemas/procesos/bases de datos, se pudiese crear complejas aplicaciones.

Imaginad que en ese futuro, en el desarrollo, se abstrajesen de forma totalmente transparente al usuario desarrollador:

lenguaje de programación
sistema operativo destino
arquitectura (MVC, N-tier, etc)
acceso a datos (ODBC, dataset, entidades POCO, etc).

Imaginad en ese futuro, que las aplicaciones fuesen fáciles de mantener, y estuviesen actualizadas a las últimas tecnologías del mercado.

Pues este tipo de software existe ya hoy. De hecho, existe ya desde hace muuuchos años. Además, uno de los entornos de desarrollo de los que me gustaría hablar se creó en su versión 1.0 en el año 1989! Me ha sorprendido, porque yo lo había oido hablar desde hace algo menos, los 14 o algo más de años que llevo en esta profesión. De hecho, me ha tocado trabajar con alguno de estos entornos (y ni siquiera es de los conocidos, pues es una plataforma para soluciones bancarias).

Pues nada, a ver si saco un rato, y dedico un par de entradas en el blog a este mercado de aplicaciones, y a la que más me suena y conocía desde unos añitos.

Cuando hablamos de CMMI

2011-09-03T08:37:00.000-07:00

Observo constantemente en blogs y comentarios frases como éstas:

"La metodología SCRUM es mucho más ágil que CMMI"
"CMMI es una metodología arcaica y excesivamente burocrática"
"No tengo claro qué metodología usar en mi proyecto: CMMI, SCRUM, xxx"

¿Nadie se da cuenta? El problema es que en todas las frases, se está hablando de CMMI como metodología, y no lo es. Por tanto, es absurdo compararla con cualquier otra (he usado por ejemplo SCRUM, pero podría haber puesto cualquiera).

CMMI es un modelo de referencia. Según wikipedia: "es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software". Realmente, los que hayáis estudiado CMMI más o menos a fondo, veréis que en este modelo no se dice cómo se han de hacer las cosas, sino qué cosas deben hacerse.

Os preguntaréis...¿hacerse...para qué? Pues para tener una metodología (conjunto de procesos) que cubran todos los aspectos necesarios, que cubran todas las necesidades de la gestión y el desarrollo. Es por eso que es absurdo comparar a CMMI con cualquier metodología (ya que no lo es). Es como lo de las peras y las manzanas: no se pueden comparar.

Otra forma impropia de hablar de CMMI es cuando se usa para hablar de excesiva burocracia, métodos arcaicos, poco ágiles, o como cuando se vincula con metodologías en cascada (las famosas Waterfall Methods). Aquí hay varios problemas que provocan esto:

Excesiva burocracia: evidentemente, si algo no nos apetece hacerlo, pasará a segundo plano (ver mi reciente entrada sobre procrastinacion), aunque eso no signifique es es innecesario. Por desgracia, eso también ocurre si bajo nuestro punto de vista no es necesario. Por ejemplo, yo desarrollo software. No me gusta facturar al cliente, no me gusta hacer seguimiento de cobros...pero sin ello, ya puedo ser el mejor programador del mundo: no puedo vivir del aire. Yo, mi familia, todos necesitamos el dinero que cobramos. Luego el control de horas trabajadas, el control de pagos/cobros, y muchas otras actividades, son necesarias para la empresa. Cuando hablamos de burocracia, se nos olvida que no trabajamos para nosotros. Hay metodologías que por fin han involucrado a los clientes (enhorabuena por el descubrimiento), pero siguen ignorando a la empresa en la que trabajan. Por desgracia, y es un mal endémico en nuestro sector, todavía hay quien cree que cobra por sus horas trabajadas, cuando en la mayoría de los casos, se cobra por cumplir un contrato.
Métodos arcaicos: algo es arcaico o antiguo en comparación o referencia a otra cosa. Resulta divertido ver cómo los defensores de ciertas metodologías, las consideran muy modernas para unas cosas, y luego para defender que están arraigadas y no son algo inmaduro, acreditan estar basadas en métodos, prácticas, y otras referencias de 10, 20, 30 años o más. Por desgracia, en nuestro sector se consigue que algo sea bueno o atractivo, en base a destruir la reputación de todo aquello que le pueda hacer competencia.
Agilidad: los métodos son tanto más ágiles, cuanto más rápidamente nos acercan a nuestros objetivos. Eso no significa que sean los más rápidos. Se nos olvida muchas veces, que para llegar antes, no es más importante correr mucho, sino tener claro hacia dónde debemos ir (y no desandar constantemente el camino). Esto me recuerda muchos proyectos en los que no se tienen claros los objetivos, ni qué hay que hacer, pero los jefes de proyecto insisten en "redoblar los esfuerzos". Por eso, las técnicas, prácticas y metodologías, serán sólo ágiles, cuando en las condiciones favorables, nos acerquen a nuestros objetivos de forma que se aumente el rendimiento.
Desarrollo en cascada. Esto casi lo dejo para otro post, tan grande es la confusión que observo respecto a este término, y su vinculación con CMMI y muchos otros conceptos.

CMMI es desde luego un método imperfecto a la hora de evaluar la madurez de las empresas y los procesos, pero tiene muchos puntos a su favor:

No hay muchos métodos de evaluación de la madurez
Es un método en constante evolución y mejora. Actualmente CMMI DEV está en su versión 1.3.
Se integra muy bien con prácticamente todas las metodologías de ciclo de vida.
Es un modelo extendido a nivel mundial, y está diseñado para comparar uniformemente a organizaciones de todo el mundo.
Para las empresas, es un modelo de evaluación ventajoso: proporciona prestigio, y el "sello" de calidad queda referido a la empresa, no a sus individuos. Los individuos se van o vienen, pero los beneficios se quedan en la empresa.

Bueno , hasta ahora hemos visto que usar CMMI en comparación con otras metodologías, no es adecuado, y que se desprestigia injustamente a este modelo (en la mayoría de los casos, por ignorancia o para crear prestigio por comparación), pero no pensemos que por ello, es perfecto, ni tiene defectos. Me guardo para un post el detallar los problemas y defectos de CMMI como modelo, y su mayor talón de aquiles: las pésimas implementaciones como metodología que se hacen a veces, cuando el único objetivo es "tener el sello de calidad".

Procrastinación

2011-09-02T00:29:00.000-07:00

Interesante palabrita, que últimamente se está oyendo mucho. Una definición que encuentro:

"Procrastinar: dejar para mañana lo que se puede hacer hoy."

Básicamente, es no afrontar una tarea que tenemos pendiente, y que vamos retrasando horas, días o incluso semanas. La cuestión es que esa tarea, normalmente:

No nos gusta
No nos vemos preparados para llevarla a cabo
Sentimos temor del resultado de esa tarea

Para eso no hacía falta una palabra tan rara, desde luego. Y viendo esta información, hasta parece que todos nos hemos visto alguna que otra vez en esta situación. Sin embargo, si vemos la definición en wikipedia:

"Se trata de un trastorno del comportamiento que tiene su raíz en la asociación de la acción a realizar con el cambio, el dolor o la incomodidad (estrés). Éste puede ser psicológico (en la forma de ansiedad o frustración), físico (como el que se experimenta durante actos que requieren trabajo fuerte o ejercicio vigoroso) o intelectual."

Ostras, aquí ya es algo serio. ¡Un trastorno del comportamiento! Va a ser que no es algo muy bueno (cosa que ya sospechábamos por otra parte). Lo que ya ha sido la guinda ha sido comprobar por mi parte que existe un portal http://procrastinacion.org/, dedicado exclusivamente a este innoble arte.

Un punto que no veo mencionado es que este postergamiento de las tareas, está relacionado con el mundo del desarrollo software y especialmente con la calidad. En muchas ocasiones, el personal técnico se ve tentado de no afrontar las tareas asignadas, y en su lugar realizar alguna tarea (asignada o no), pero que es más atractiva, o interesante. Cuántas veces, alguien en un equipo no ha completado un desarrollo a tiempo, pero sin embargo sí ha tenido tiempo de añadir alguna funcionalidad que no estaba planificada, o ha implementado alguna nueva tecnología, etc, etc.

Por desgracia, en el mundo del software (aunque ocurre también en general), esta "procrastinación" está asociada a la Ley de Parkinson. Básicamente, se trata de que la gente si para una tarea tiene 2 horas, si acaba en 1, se busca algo que hacer para llenar el tiempo que le sobra. Esto tiene una segunda revisión, y es que hay veces que ni siquiera han terminado la tarea en las 2 horas, y sin embargo ese tiempo no se ha dedicado íntegramente a la tarea. Más en detalle, la definición de ley de Parkinson en wikipedia extiende la ley de Parkinson a estos puntos:

"El trabajo se expande hasta llenar el tiempo de que se dispone para su realización".
"Los gastos aumentan hasta cubrir todos los ingresos".
"El tiempo dedicado a cualquier tema de la agenda es inversamente proporcional a su importancia".

El tercero, de nuevo, nos recuerda que somos proclives a hacer las cosas que nos gustan, no las que realmente importan.

En el mundo de la calidad y el desarrollo software, estas afirmaciones son destructivas: no se dedica el tiempo a lo planificado, por lo que la calidad del software resultante no siempre es predecible. Siempre se obtienen respuestas de los equipos de trabajo del estilo: "es que no hemos tenido tiempo de probar", "los plazos son muy agresivos". Estas afirmaciones, por desgracia, son ciertas en muchas ocasiones. Pero también es cierto que no se utiliza el tiempo de forma adecuada (basta ver la relajación de los equipos de desarrollo, que va disminuyendo hasta convertirse en una sobrecarga brutal de trabajo conforme nos acercamos a la fecha de entrega...¿nos suena esto de algo?).

Importancia de los requisitos

2011-09-01T03:08:00.000-07:00

En el desarrollo software, se suele hacer un énfasis enorme en metodologías, ciclos de vida, técnicas varias, frameworks, etc. Sin embargo, la realidad nos sigue diciendo que uno de los principales motivos del fracaso de los proyectos está en los requisitos (inadecuados, incompletos, etc).

Recientemente leía el libro "Optimize Quality for Business Outcomes: A Practical Approach to Software Testing" (Andreas Golze, Mark Sarbiewski, Alain Zahn; (c)2008, John Willey and Sons), que trata todo el tema de pruebas del software. Aquí encontraba un ejemplo de cómo los requisitos y su gestión, influyen en una mala solución. Como puede verse, la falta de habilidad del analista para obtener la información no proporcionada por el cliente, junto con las falsas expectativas que éste se había hecho, hacen que la solución final sea una pérdida de recursos y un cliente insatisfecho.

El mito de la mantenibilidad

2011-08-30T03:37:00.000-07:00

Parece que seguimos revisando mitos.

¿Realmente es necesario que un software sea mantenible? Si la respuesta es que sí...¿en qué grado? ¿hasta qué punto? ¿para qué usuarios/clientes? ¿Cuándo lo hacemos y a través de qué actividades?

El IEEE define mantenibilidad como: “La facilidad con la que un sistema o componente software puede ser modificado para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios en el entorno”.

En la ISO 9126-1 se define que la mantenibilidad está indicada por los siguientes subatributos:

Facilidad de análisis
Facilidad de cambio
Estabilidad
Facilidad de prueba

Desde mi punto de vista, el uso de buenas prácticas en el análisis y desarrollo nos conducen a:

Facilidad de análisis: la documentación facilita el análisis y entendimiento de la arquitectura, decisiones tomadas, etc. Una arquitectura coherente en todo el producto, facilita el análisis.
Facilidad de cambio: la documentación facilita la identificación de elementos afectados por un cambio, su trazabilidad, etc.
Estabilidad: el aislamiento entre componentes y el uso de una arquitectura coherente en sus distintos aspectos, facilita que los cambios no produzcan efectos indeseados.
Facilidad de prueba: las buenas prácticas en el diseño, desarrollo y ejecución de pruebas, facilitan llevar esta tarea a buen término.

Es decir, vemos que para conseguir la mantenibilidad, podemos hacerlo a través de todas estas vías.

En mi opinión, normalmente no es necesario hacer un esfuerzo adicional (extraordinario) para que un software sea mantenible. Lo que sí es necesario, es que se sigan ciertas pautas en todo desarrollo, independientemente de que se nos exija esa mantenibilidad. La mantenibilidad debería estar "de serie" en cualquier desarrollo. De hecho, es de las características del software que deberían ir EN PRIMER LUGAR. El resto, pueden derivarse de ella.

A continuación, vamos a revisar unas cuantas técnicas específicas enfocadas a mejorar la mantenibilidad, y que por tanto deberían estar presentes en todo desarrollo software (independiente de que la metodología sea tal o cual, ágil o no...):

Establecer políticas de diseño, codificación y pruebas enfocadas a este tema. Por ejemplo, el uso de patrones puede ayudar. Sin embargo, no debemos caer en el uso indiscriminado de patrones (la conocida "patronitis").
Facilitar la configuración del software.
Evitar cambios significativos en la arquitectura del sistema durante el desarrollo.
Coherencia (en arquitectura, en nomenclatura, en comentarios, etc). No podemos trabajar con técnicas heterogéneas, del mismo modo que no podemos ser superexigentes en la arquitectura, y relajados en los comentarios o nomenclatura).
Uso de estándares conocidos. Hacer públicos dichos estándares, manteniendo informado al equipo sobre los mismos, y sobre cualquier cambio en los mismos. Asegurar la formación del equipo en estos estándares. Realizar controles (llamadlos revisiones, auditorías, da igual), y asegurarse de que se cumplen.
Documentación (de los casos de prueba, de resultados de pruebas, de requisitos, de decisiones funcionales y técnicas, etc).
Mejora del código en base a métricas (complejidad, etc). Sin control y seguimiento, no se puede mejorar. No podremos mejorar si no sabemos como estamos.
Planificación del mantenimiento.

Scrum - Chuck Norris

2011-08-30T01:00:00.000-07:00

Para variar, un poco de humor. Este post resultará especialmente divertido para los que conozcan Scrum, y va en la línea de los chistes de Chuck Norris:

http://www.genbetadev.com/metodologias-de-programacion/scrum-norris-es-scrummaster-sin-haber-sido-certificado

El mito de la burocracia

2011-08-30T00:51:00.000-07:00

Con frecuencia me encuentro con rechazo a las tareas a realizar durante el proyecto, y en muchas ocasiones la respuesta tiene una raiz común: la gente las llama burocracia.

Si a un programador le pides que anote las horas que ha dedicado a hacer una tarea, lo tildará de burocracia. Sin embargo, si tiene que probar una nueva tecnología para la que existe la rara posibilidad de que se use en el proyecto, esas horas las considerará una inversión.

Hay una importante corriente de favor por metodologías y prácticas "ágiles", y es sorprendente la facilidad con que todo el mundo se apunta a "ser ágil" (aunque realmente hay poca gente que te sepa decir exactamente qué supone ser ágil). Muchos contestan que ser ágil, es básicamente, eliminar la burocracia.

El problema reside en que primero, esa definición de agilidad no es correcta, y además, tampoco existe un acuerdo en qué es la burocracia. En mi empresa nos hemos certificado CMMi nivel 3, y constantemente leo en internet un constante rechazo a CMMI, en muchos casos recibiendo la calificación de "burocrática".

Sorprendentemente, los equipos de trabajo que usan nuestra metodología raramente se quejan de burocracia. Las tareas que se realizan, hay que realizarlas si o si, ya que proporcionan la única forma de llegar a tener control sobre el proyecto. Además, las tareas que se realizan no se llevan a cabo por CMMI, sino por el valor que aportan al proyecto o a la organización. Las quejas surjen durante las fases de implantación de la metodología, lo que nos lleva a concluir que el problema es de formación y falta de conocimiento.

Por otro lado, la burocracia, se presenta como principal argumento de metodologías ágiles como SCRUM. Se busca en muchas ocasiones rechazar dos conceptos que en realidad tienen poco que ver entre sí, y mucho menos con SCRUM:

CMMI
Ciclo de vida en cascada

Para empezar, CMMI no es una metodología, como tampoco lo es el ciclo de vida mencionado. CMMI es un modelo de madurez. El ciclo de vida en cascada, como cualquier ciclo de vida, es un modelo más o menos teórico que presenta una forma de realizar las actividades. Normalmente lo que se busca con afirmaciones de este tipo es conseguir crear en el modelo CMMI una imagen de burocracia y antiguedad. Por confrontación, conseguiríamos obtener una imagen (ficticia como vemos), de modernidad y agilidad en SCRUM.

Vemos entonces que la burocracia, sin terminar de definirse como término (aunque está claro que es negativo), sirve como argumento positivo (por confrontación).

Mi opinión es que en la mayoría de ocasiones nos gusta escondernos en nuestro pequeño mundo, y llamamos burocracia a las actividades que no nos aportan directamente algo a nosotros mismos. En una escala comparativa, tendríamos tareas cuyo beneficio va a parar:

Al individuo
Al proyecto
A la empresa

Las actividades que producen principalmente beneficio al individuo (actividades que producen satisfacción personal, autoformación, investigación, etc), no se consideran nunca burocracia. Los integrantes del equipo se sienten cómodos con ellas.

Las actividades que aportan al proyecto, son calificadas como burocráticas por las categorías más bajas (programadores principalmente). Las necesidades de la gestión del proyecto no les importan, y la supresión de estas actividades, serían a su modo de ver, síntoma de agilidad.

Las actividades que aportan a la empresa, amplían el conjunto de individuos que las rechazan, incluyendo a las categorías medias/bajas.

Como conclusión, vemos que normalmente la definición de burocracia está asociada de forma egoísta o personal a unas actividades u otras, en función de nuestro rol. Se echa en falta pues, una visión más global de las actividades en los proyectos, y de su relación con los distintos roles. Un punto por ejemplo que no se suele tener en cuenta es el coste o beneficio en cada actividad, que suele ser percibido de forma diferente en función del rol en el proyecto.

Scrum Guide 2011

2011-07-25T03:29:00.000-07:00

Se ha publicado recientemente una actualización de la Scrum Guide. Está disponible en la ruta:
http://www.scrum.org/scrumguides/

De ganadores y perdedores

2011-07-12T09:46:00.000-07:00

Ahí va un texto, sacado del libro sobre liderazgo: "La culpa es de la vaca".

Cuando un ganador comete un error, dice: "Me equivoqué y aprendí la lección".

Cuando un perdedor comete une rror, dice: "No fue culpa mi culpa", y se la atribuye a otros.

Un ganador sabe que el infortunio es el mejor de los maestros.

Un perdedor se siente víctima de la adversidad.

Un ganador sabe que el resultado depende de él

Un perdedor cree que la mala suerte existe

Un ganador trabaja muy fuerte y se permite más tiempo para sí mismo.

Un perdedor está siempre muy ocupado, y no tiene tiempo ni para los suyos

Un ganador enfrenta los retos uno a uno.

Un perdedor les da vueltas y vueltas y no se atreve a intentarlo.

Un ganador se compromete, da su palabra y la cumple.

Un perdedor hace promesas, no asegura nada y, cuando falla, sólo se justifica.

Un ganador dice: "Soy bueno, pero voy a ser mejor".

Un perdedor dice: "No soy tan malo como mucha otra gente".

Un ganador escucha, comprende y responde.

Un perdedor sólo espera hasta que le toque su turno para hablar.

Un ganador respeta a los que saben más que él y trata de aprender de ellos.

Un perdedor se resiste ante los que saben más que él y sólo se fija en sus defectos.

Un ganador se siente responsable por algo más que su trabajo.

Un perdedor no se compromete y siempre dice: "Yo sólo hago mi trabajo".

Un ganador dice: "Debe haber una mejor forma de hacerlo".

Un perdedor dice: "Esta es la manera en que siempre lo hemos hecho".

Un ganador es parte de la solución.

Un perdedor es parte del problema.

Un ganador se fija en toda la pared.

Un perdedor se fija en el ladrillo que le corresponde poner.

Un ganador, como usted, comparte este mensaje con sus amigos.

Un perdedor, como los otros, se lo guarda para si mismo

Patronitis

2011-06-27T13:44:00.000-07:00

Al final no me he podido resistir. No podía dejarlo para mucho más adelante. Si ayer lo nombraba, hoy me apetecía hablar de una de las enfermedades más comunes de los desarrolladores de software: "la patronitis".

No os molestéis. Este término no aparece en ningún diccionario oficial. Sin embargo, sí puede encontrarse en diversos blogs y libros editados ya hace algunos años. Pero es estos días cuando parece estar más de moda.

En algún blog podemos ver una definición como:
Patronitis: N. fem. Dícese de la enfermedad propia de programadores que consiste en querer aplicar patrones de diseño a todo.

Sin embargo, no considero esta definición del todo exacta. He podido observar esta enfermedad también en analistas, arquitectos, y otras categorías supuestamente más experimentadas.

Normalmente el problema se debe a nuestra naturaleza friki innata, que nos reclama el uso de todo aquello que hemos aprendido, independientemente de su adecuación al caso. ¿Que no aplica? Pues da igual, se mete, aunque sea con calzador. Y así nos van las cosas. ¿Que se pone de moda la arquitectura de 14 capas? Pues se usa. Luego ya iremos eliminando cosas que realmente sobren. Y el problema es que siempre encontramos un uso para algo.

Una vez me enseñaron una regla de oro, de las que no se deberían olvidar nunca: "Un software no está completo cuando ya no se pueden añadir más funcionalidades, sino cuando no se puede eliminar ni una sola más".

Y es que al final, no es la experiencia en el desarrollo de aplicaciones mediante patrones y la aplicación de las diversas tecnologías lo que nos da la experiencia suficiente para saber dónde está el límite en el uso de los patrones. Es al tener que mantener esas aplicaciones, bien desarrolladas por nosotros mismos, o bien por otros, cuando vemos cuán complicadas son las cosas. Un buen artículo (con algunos añitos a sus espaldas ya), está en: http://www.javahispano.org/contenidos/es/el_peligro_de_los_patrones/
Este artículo es bastante conocido por internet, y tiene muchos seguidores y detractores. Allá cada cual.

Finalmente, para los que os gusta visualizar y ejemplizar las cosas, ahí va una perla: (extraída de: http://odetocode.com/Blogs/scott/archive/2005/11/22/2499.aspx):

Design Patterns: A Love Story

Richard tilted his head to watch the waves push flotsam against the boat hull below. Up and down, the flotsam moved. Up and down.
Richard had an idea.
“Virginia, my dear”, he said to the blond woman beside him. “We’ve been singletons on this ship for a long time”.
“I know, Richard”, she replied. “My mean step-mother, the intercepting filter that she is, denies me time with others.”
Richard paused for a moment, to contemplate strategy. Her father, with his pipes and filters, would return soon, and force them to communicate over his message bus. He glanced aft, and saw no one else around. Richard turned his front controller to face Virginia, and looked her in the eyes. She was close now, and Richard could feel his active record rising.
“Virginia”, he whispered. “There is no observer in sight. Let us run below deck. I want to peel away your façade, and tightly couple.”
“Oh yes, Richard”, she blushed, and leaned towards him. “I want you to give me a dependency injection”.

Técnicas ágiles: Principio KISS

2011-06-26T06:29:00.000-07:00

El principio KISS, es uno de esos acrónimos que quedan bien en cualquier presentación. Es una palabra conocida en inglés, y al mismo tiempo, es una frase simple y útil en el desarrollo de software.

"Keep It Simple, Stupid"

Supongo que alguien tuvo que añadir la palabrita final para conseguir doblar la S, y que así tengamos la palabra en inglés.

Básicamente, esta técnica general, se basa en que en cada una de las actividades del desarrollo software, debemos valorar si estamos realmente adoptando la solución más simple o no. Esta técnica ha sido abanderada por las metodologías ágiles, que rápidamente la han adoptado como suya.

Al mismo tiempo, es una afirmación correcta en cualquier desarrollo. No siempre se tiene la entereza de mantener la simplicidad. Más cuando uno es novato en alguna tecnología y quiere demostrar que tiene la suficiente destreza, o bien simplemente quiere utilizar el último patrón o framework de moda.

Hay un término de moda, y es la "deuda técnica". Este término está relacionado con el principio KISS. Si sabemos mantener la simplicidad en cada una de las facetas del desarrollo, estaremos disminuyendo la deuda técnica. Es curioso, pero en Wikipedia encontramos la definición siguiente de deuda técnica: "La deuda técnica es un eufemismo tecnológico que hace referencia a las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware." (http://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica)

Si ahondamos en la definición, veremos que la deuda técnica no siempre estaría originada por un "desarrollo apresurado". Podemos hacer un exhaustivo análisis, diseño técnico, definición arquitectónica, etc. Y sin embargo, eso no asegura que no vaya a existir una deuda técnica en un futuro inmediato. Puede ser una arquitectura demasiado rimbombante, un complejo diseño técnico que no se vea actualizado...o una implementación desviada del diseño...o un uso indiscriminado de patrones ("patronitis", algún día os hablaré de ello).

Y para terminar, un ejemplo que me ha gustado y que he leído en más de un sitio (con ligeras variaciones). Éste en concreto, está extraído de un blog (http://www.gedpro.com/Comunidad/Blogs/tabid/69/EntryId/465/Principio-KISS-en-la-gestion-de-proyectos.aspx) en el que hablan del término KISS para temas de gestión de proyectos. Pero como el mismo autor reconoce, es un término válido para cualquier faceta del desarrollo:

Cuenta la leyenda que cuando la NASA inició el lanzamiento de astronautas, se dieron cuenta enseguida de que los bolígrafos no funcionarían con gravedad cero. Para resolver este problema, la NASA contrató a Accenture (la antigua Andersen Consulting). Una década y 12 millones de dólares después, la NASA disponía de un innovador bolígrafo que escribía con gravedad cero, hacia arriba y hacia abajo, bajo el agua, en prácticamente cualquier superficie, incluido el cristal y en un rango de temperatura desde -30ºC hasta más de 300ºC. Los Rusos utilizaron un Lápiz.