domingo, 15 de julio de 2012

La obsesión por el éxito

En general, tenemos el problema de que no estamos dispuestos a aplicarnos a nosotros lo que exigimos a los demás.

No es la primera vez que oigo que en un proyecto con metodología ágil, el analista técnico o programador se queja de que el diseño funcional que le entregan no está 100% cerrado al inicio del sprint.

Es decir, ¿sólo usamos el agilismo de cara al cliente o al jefe de turno? ¿No estamos dispuestos a aceptar también los cambios en los documentos de otros compañeros? Hemos de superar el hecho natural de que los demás también se equivocan, aceptar los cambios y gestionarlos como tales, no como un problema al que se asigna un culpable.

Sólo cuando estemos dispuestos a aceptar que el trabajo en equipo tiene estas cosas, podremos realmente llevar adelante proyectos con éxito. Porque el éxito no significa "sin problemas". Significa superarlos, y poner los medios para que no se produzcan, no buscar los culpables para que no nos señalen con el dedo.

Nota: esta entrada está más o menos sacada de un comentario mío en LinkedIn, en respuesta al excelente artículo "El Oportunismo del Agilismo".

sábado, 14 de julio de 2012

El lenguaje de programación X++

Es el lenguaje propio de Microsoft Dynamics AX. Es una herramienta ERP de Microsoft, comprada a Navision,  que a su vez se había fusionado antes con la empresa Damgaard tras abandonar IBM su colaboración con ella.

El desarrollo y modificación del software se realiza mediante su propio entorno de desarrollo integrado, MorphX. El entorno de desarrollo permanece en la misma aplicación del cliente, permitiendo de esta forma tener acceso a dichas herramientas desde la aplicación del cliente. El lenguaje que se emplea (X++) es muy similar a Java o a C++.

El lenguaje X++ está orientado a objetos, e incluye sentencias SQL y características específicas para construir complejos sistemas de gestión contable y de negocio.

El modelo de gestión de memoria es muy simple, los objetos se crean con el operador NEW.

No existen punteros.

Se accede al complejo sistemas de clases de Microsoft Dynamics AX, que proporcionan funcionalidad desde la transferencia de información, entradas y salidas básicas, o la modificación de controles en tiempo de ejecución. La funcionalidad de estas clases es extensible.

X++ proporciona una extensiva comprobación en tiempo de compilación, seguida de una segunda comprobación en tiempo de ejecución. También existe un recolector de basura, que funciona automáticamente en cuanto un objeto deja de estar referenciado.

Para más información, existe una extensiva documentación en el portal de Microsoft:



viernes, 13 de julio de 2012

Kanban para novatos

La meodología Kanban, cada día se presenta más y más como posible sucesora de Scrum en el rol de abanderada del Agilismo.

La metodología de desarrollo Kanban (Kanban Software Development) está basada en la metodología de fabricación industrial del mismo nombre. Para saber de sus orígenes, y ver cómo ha acabado implantándose en el mundo del desarrollo de software, hay muchas fuentes. Una que he encontrado bastante válida es: http://www.monografias.com/trabajos7/elka/elka.shtml

Orientación visual


El sistema Kanban, orientado al desarrollo de software, está fuertemente ligado al uso del tablero o pizarra Kanban. Vamos a ver en qué consiste.

La pizarra Kanban contiene las tareas que tenemos que desarrollar. La pizarra está estructurada por columnas, que identifican cada una a los distintos estados por los que puede pasar (más o menos secuencialmente), la tarea:
  • Solicitada
  • Asignada
  • En desarrollo
  • En pruebas
  • Completada
Se podría pensar en más estados: validada por el usuario, implementada en producción, etc. Lo importante aquí es el aspecto visual, ya que las distintas tarjetas (una por tarea), siguen de izquierda a derecha en la pizarra, los estados. El aspecto de la pizarra sería tal que así:

Limitar el trabajo en curso

Otro aspecto fundamental del Kanban es mantener acotado dentro de unos límites, el trabajo "en curso". La pizarra ayuda mediante su gestión visual. Además, hay dos conceptos importantes:
  • No podemos comenzar una nueva tarea hasta que la anterior la hayamos terminado.
  • El número máximo de trabajo en curso tiene un límite, que es nuestra capacidad por ciclo o iteración.

Métricas Kanban

Me ha parecido interesante esta mención que hace Javier Garzas en su blog, y es que hay que medir, aunque seamos ágiles y usemos Kanban. En este caso, al menos, recogeremos por cada tarea:
  • Fecha y hora de inicio
  • Fecha y hora de fin
  • Tiempo real invertido
Como además, tendremos la estimación inicial para la tarea, con los datos anteriores ya tenemos la desviación respecto a lo estimado.

El tiempo promedio para completar una tarea, es también importante y a veces conocido como "tiempo de ciclo", ya que es el ciclo medio que nos cuesta pasar una tarea de izquierda a derecha de la pizarra hasta que cogemos una nueva.

Y nada más, que si os animáis, podéis usar esta metodología. Como podéis ver, es muy simple, y tiene muy pocas reglas o normas a seguir.

jueves, 12 de julio de 2012

50 enlaces para aprender inglés

Esto no tiene mucho que ver con lo que suelo publicar aquí...pero qué narices...es tremendamente útil.

Así que venga, animaros los que aún sois reticentes y lográis poner una y otra vez las mismas excusas, ya podéis aprender inglés por vuestra cuenta.

http://cadizempleo.blogspot.com.es/2012/07/50-enlaces-para-aprender-ingles.html

Por cierto, gracias a la autora (Carmen Campanario) por publicar estas cosas tan interesantes en su blog

martes, 10 de julio de 2012

Nueva Norma UNE 16114

Bueno, vamos a tomar un respiro con tanto AOS2012, y tanto agilismo. Hablemos por un día de otras cosas.

Recientemente me ha surgido la necesidad de tratar con esta nueva norma UNE-EN 16114. Esta norma todavía no es una ISO, aunque está previsto que lo acabe siendo en algún futuro cercano. Actualmente es una norma europea, adoptada como 16114, y en España UNE la ha adoptado también.

¿Otra norma? ¿Para qué?

¿Como si no tuviéramos ya pocas normas, verdad? La Norma UNE-EN 16114:2012, fue publicada por AENOR en marzo del 2012 con el objeto de cubrir la necesidad de regular la eficiencia en la prestación de servicios de consultoría de gestión. La Norma UNE-EN 16114:2012 se presenta como una colección de directrices voluntarias aplicable a cualquier tipo de trabajo y cliente.


¿En qué consiste esta norma?

 Proporciona recomendaciones para la realización de servicios de consultoría de gestión incluyendo:
  1. cuestiones legales y éticas;
  2. gestión, comunicación y evaluación;
  3. las relaciones con el cliente;
  4. la oferta y el acuerdo;
  5. la planificación y la ejecución;
  6. el cierre del servicio.
La Norma UNE-EN 16114:2012 no es certificable por terceras partes ya que no establece requisitos que puedan evaluarse para demostrar su conformidad con la norma. Así mismo, la norma no está diseñada para un uso regulatorio o contractual y ni es apropiada como base de ninguna cualificación ni individual ni de organizaciones.

Es decir, que NO podemos obtener un certificado en esta norma, ni para la empresa, ni a nivel personal.

Recientemente adoptada a nivel europeo, todavía no es un estándar Global ISO.
 
Fuentes:

lunes, 9 de julio de 2012

AOS2012 - Agile Inception (2 de 2)

Pues nada, he aquí la segunda parte de la descripción de este método.
Antes de seguir, recordar la principal bibliografía, que es el magnífico libro "The Agile Samurai" de Jonathan Rasmusson, de donde además son algunas imágenes.

Nos habíamos quedado en el anterior post repasando las 5 primeras actividades o juegos. Pasemos a los 5 siguientes. Recordad que podéis encontrar un resumen del AOS 2012 y un indice de las ponencias a que asistí en este enlace.

6.Mostrar la solución 


  • Presentar una solución técnica
  • Revisar riesgos
  • Establecer dimensiones
  • Establecer resultados del producto
  • Establecer claramente lo que va a costar
  • Utilizar lenguaje visual
  • Establecer expectativas de las áreas con más riesgo
  • Obtener compromiso con la solución técnica planteada

7.Despierto por la noche


  • Determinar los riesgos del proyecto
  • ¿Qué nos quita el sueño?
  • Hablar de los riesgos es bueno
  • Debe participar el equipo: compartir los riesgos es aún mejor
  • Clasificar los riesgos en dos categorías: Los que merece la pena preocuparse por ellos (probables o graves), y el resto
  • Llegado el caso, antes de perder la calma, echar mano de la oración de la serenidad:


8.Medir el tamaño 


  • Se trata de dar una estimación de orden de magnitud: un mes, dos, seis meses o un año
  • Utilizar técnicas de estimación ágiles
  • Presentar al cliente la estimación y una planificación a muy alto nivel. No se establecen compromisos en cuanto a plazos.
  • Pensar en pequeño
  • Dar expectativas de tamaño

9.¿Cuál va a ser el resultado?


 En este punto, hay que establecer prioridades entre las principales restricciones del proyecto:
  • Alcance
  • Presupuesto
  • Tiempo
  • Calidad
  • Otros
 Recordar dos reglas fundamentales:
  • No pueden ser todas prioritarias (no todas son #1)
  • No puede haber dos al mismo nivel de prioridad

10.¿Cuál va a ser el coste?


  •  Llegados a este punto, mediante los juegos anteriores tenemos la visión y el plan
  • Debemos finalmente mostrar el coste y esfuerzo necesarios, recursos, etc.
  • Detallar nuestro equipo (roles, responsabilidades, nombres, etc.)
  • Aclarar quién va a ser la voz del cliente, el responsable de filtrar y focalizar las peticiones de los stakeholders.
  • El resultado será algo como:

El resultado final

El resultado de esta actividad participativa será un documento o material en el que habrán quedado identificados:
  • Qué se va a construir y porqué
  • Qué amenaza al proyecto: riesgos y retos principales a afrontar
  • Cuáles son los obstáculos a resolver
  • Quiénes van a ser nuestros “vecinos”
  • Qué aspecto tiene nuestra solución
  • Tamaño que va a tener
  • Dónde estamos dispuestos a ser flexibles y adaptables
  • Duración y coste aproximados

Conclusión

Esta actividad, que explicada así puede parecer un poco "de juguete", en realidad consigue de una forma dinámica y participativa, que se encuentren y se pongan en común posturas normalmente opuestas como son las del equipo técnico/funcional, y el cliente. El hecho de ser participativa, y enfocarse en pequeñas actividades, aligera el proceso y permite que algo tan complejo y tedioso como identificar las necesidades del cliente y establecer una visión global del producto a construir, es ameno y en cierto modo, hasta divertido.

Por lo demás, recomendar el libro "Agile Samurai", que aunque en algunos momentos puede parecer "más de lo mismo" en el mundo ágl, tiene algunas perlas que lo salvan de cualquier quema.

domingo, 8 de julio de 2012

AOS2012 - Agile Inception (1 de 2)

Y he aquí como descubrí el método de Inception: en el AOS (Agile Open Space) que tuvo lugar en Zaragoza el pasado mes de Junio de 2012. Si quieres ver mi reseña de otras  charlas del AOS 2012, tienes un índice aquí.

¿Qué es Agile Inception?

Es una colección de ejercicios prácticos, que realizados en una o varias sesiones con el cliente, pretende establecer una visión clara y suficientemente detallada del producto a construir. Los ejercicios son:
  • ¿Porqué estamos aquí?
  • Charla de ascensor
  • Caja de producto
  • La NO lista
  • Conoce a los vecinos
  • Mostrar la solución
  • Despierto por la noche
  • Medir el tamaño
  • ¿Cuál va a ser el resultado?
  • ¿Cuál va a ser el coste?

1. ¿Porqué estamos aquí?

Se trata de conocer el verdadero motivo de construir el producto software. Una vez conocido el por qué, seremos capaces de:
  • Tomar mejores decisiones
  • Gestionar mejor las restricciones
  • Presentar mejores soluciones a los problemas
Técnica 1: Ves y mira tú mismo
Tratar de conocer de primera mano la problemática y necesidad que lleva a construir el producto.
Mediante empatía, cuestionarios, trabajo con el cliente, etc.
Técnica 2: Descubre la intención del responsable
  • Es una frase concisa y simple que resume la intención del responsable (cliente) y que resume el propósito del proyecto
  • El propósito del ejercicio es que el grupo hable de lo que piensan que es el motivo que les ha llevado ahí.

2. Charla de ascensor

El objetivo es condensar en unas pocas frases, la esencia de la idea del producto.
El nombre “Elevator pitch” viene de: ¿cómo venderías tu producto a la persona que puede financiártelo, si te la encontraras en el ascensor?
El enfoque es que sólo se dispone del tiempo que tarda el ascensor en recorrer los pisos.
¿Qué aporta?
  • Claridad
  • Fuerza al equipo a pensar en el cliente
  • Va al grano 

3. Caja de producto

Este ejercicio consiste en crear una caja para el producto, como si éste fuera a ser vendido en una estantería de una tienda.
Pasos:
  • Paso 1: Brainstorming de los beneficios del producto
  • Paso 2: Crear un Slogan
  • Paso 3: Diseñar la caja

4. La NO lista

Al definir un producto, es tan importante decir qué estará en el alcance, como qué no estará dentro del alcance. Es una lista visual

5. Conoce a los vecinos

Objetivo: identificar los distintos roles con los que se va a interactuar durante el proyecto.
Actividades:
  • Paso 1: Brainstorming. El grupo trata de identificar todas aquellos grupos o roles con los que creemos que vamos a interactuar antes de la puesta en producción del producto.
  • Paso 2: Contactos. Crear una lista de contactos para poner caras a los grupos o roles anteriores.
  • Paso 3: Comunidades. Identificar, de los anteriores, los contactos con los que más nos vamos a relacionar. Éstos formarán la comunidad principal de vecinos. El resto, irán en un grupo aparte.

Para ver la segunda parte de este post, haz clic aquí.

miércoles, 4 de julio de 2012

AOS2012 - Más referencias

AOS2012 sigue coleando. Me pasa mi compañero José Antonio Herrero un nuevo link del excelente blog de Ujue Agudo.

Me ha encantado confirmar que allí sigue estando EL MAESTRO Alan Cooper entre los grandes. (Si aún no has leído "The Inmates are running the Asylum", no sé a qué esperas):

Alan Cooper (@MrAlanCooper)
cooper.com
Un histórico referente para los UX (autor del libro “Presos de la tecnología”) aplicando agile.

martes, 3 de julio de 2012

Buenas prácticas de desarrollo en Sharepoint

Microsoft acaba de publicar un excelente conjunto de buenas prácticas en Sharepoint, en una de sus TechNet Wikis.
http://social.technet.microsoft.com/wiki/contents/articles/8666.sharepoint-2010-best-practices-en-us.aspx

Un enlace imprescindible para los que trabajan con Microsoft Sharepoint, o que simplemente desean conocer lo que difícilmente se encuentra en los libros. Además, como toda Wiki, se actualiza diariamente con nuevos contenidos.

Fuente: El excelente blog de Jersson en Geeks.ms