viernes, 4 de diciembre de 2009

Scrum:IGTD (Scrum implementa el interfaz GTD)

Cada día están más en auge las metodologías orientadas a la productividad personal. Todos y cada uno de nosotros gestionamos recursos, al menos nuestro tareas en el tiempo, y es recomendable, por no decir necesario, organizar dichas tareas para ser los más productivos posible.

El ámbito de aplicación GTD no se limita al entorno profesional sino que cubre también los aspectos de organización personales, permitiendo aplicar pautas a todos los aspectos de nuestro comportamiento. Existen en la red toneladas de material al respecto y discutir las bondades de la metodología GTD y las implementaciones de las mismas quedan fuera de la intención de este post. Sin embargo, me gustaría analizar la relación que existe entre dos mundos íntimamente relacionados (aunque no de manera explicita) como son GTD y las metodologías ágiles. Como representante de dichas metodologías estudiaremos Scrum.

Si consideramos GTD como un interfaz o contrato, llamémosle IGTD, sus puntos serian:

  • Recopilar
  • Procesar
  • Organizar
  • Revisar
  • Hacer

Veamos como SCRUM implementa cada uno de los mismos…

  • Recopilar
    El objetivo en GTD se define como “sacar” todo de nuestra mente y recogerlo en alguno de los elementos de almacenamiento para luego procesarlos.

    Scrum define exactamente esta tarea identificando un rol para cubrirla, el responsable de producto o Product Owner. Entre las responsabilidades principales de dicho rol se encuentran la de identificar los puntos que más valor aportan al producto servicio que desarrolla el proyecto. Dicha recolección se realiza escuchando y tratando con los diferentes stakeholders. Este punto común de acceso permite crear una capa de protección y homogenización para el resto del equipo.
    Otra tarea muy importante y a la vez menos visible que recae sobre esta figura, es la de rechazar las propuestas de los stakeholders que no interesa avancen por el flujo puesto que no son interesantes para el producto. Esto permite al equipo centrarse en lo que realmente aporta valor.

  • Procesar
    Por supuesto, el trabajo de un buen Product Owner, no se limita a transcribir todo lo que escucha a los diferentes stakeholders. Debe realizar un proceso de análisis y diseño cuyo resultado se muestra como un conjunto de historias de usuario o Product Backlog. Dichas historias deben mantenerse consensuadas, consistentes y priorizadas puesto que conforman el material sobre las cuales trabajará la “apisonadora” que es el equipo.

    Una buena regla para saber si tienes un buen Product Owner en tu equipo es preguntarse cuanto disminuiría la rentabilidad del producto si lo sustituyes por una regla de redirección de correo…
  • Organizar
    El equipo, liderado por el Scrum Master y contando con la disponibilidad del Responsable de Producto, comienza en el Sprint Planning Meeting a digerir y desmenuzar ese producto Backlog. El resultado de dicho procesamiento son las tareas necesarias para cubrir las historias de usuario que el Product Owner ha recopilado.
  • Revisar
    Scrum da gran importancia al proceso de revisión. En base al grano deseado realiza la tarea de revisión en dos maneras.

    Todo el equipo se reúne una vez al día en el Daily Scrum comenta lo que ha realizado, lo que va a realizar en el día y los impedimentos que se ha encontrado por el camino. La verdad es que no se me ocurre una mejor forma de aplicar el concepto de revisión a grano fino.

    Por otro lado, al finalizar cada sprint se realiza una revisión del mismo, Sprint Retrospective que permite a nivel de todo lo realizado en el Sprint, evaluar los aspectos positivos para potenciarlos y negativos para mejorarlos.

    En GTD también existen dos tipos de revisiones, las diarias y las semanales (por Sprint para Scrum) así que en este punto la cosa encaja como un guante.
  • Hacer
    Una vez que tenemos claro lo que hay que hacer el equipo lo desarrolla, lo mismo que en GTD. Ambas metodologías hacen hincapié en la satisfacción de hacer las cosas y poder marcarlas como hechas, quitándolas de la primera línea de batalla y permitiendo centrarnos en lo que falta por hacer.

La conclusión que podemos obtener de este análisis, es que ambos metodologías son recomendablemente compatibles. Encajan porque se basan en patrones comunes, haciendo hincapié en centrarse en lo importante, reducir el stress, simplificar el día a día.

Además son especialmente cuidadosas con evitar el cambio de contexto y fomentar la concentración, GTD vía controlando las interrupciones internas y externas y Scrum blindando a los equipo de los cambios durante los Sprints.

lunes, 30 de noviembre de 2009

Instanciando objetos en Silverlight: Code VS XAML

Si os pregunto que manera de instanciar los objetos es más rápida, por código o vía el parser de XAML ¿Cual sería vuestra respuesta?
Pues la mayoría de los desarrolladores dirían que por código, pero obviamente la cosa tiene trampa…

En la mayoría de los casos el parser de XAML es más rápido. La razón de esta característica es el resultado de una serie de optimizaciones realizadas en tiempo de ejecución por Silverlight. El parser de XAML no crea los API objects que se emplean para interactuar con los elementos, sino que solo crea una representación interna de los mismos. Cuando desde código comenzamos a interactuar con esos objetos es cuando Silverlight crea los API objects necesarios. Esta característica se hace especialmente patente en inicializaciones de gran cantidad de objetos, aunque hay entra nuestra labor de diseño para evitar crear vistas inmanejables…

Teniendo esta particularidad en mente y valorando las facilidades de integración diseñadores/desarrolladores que nos da escribir UI en XAML es recomendable dejar la creación de objetos por código para los escenarios en los que realmente es necesario.

domingo, 29 de noviembre de 2009

Metodología, motivación y otras hierbas…

No digo nada nuevo al afirmar que las empresas de desarrollo de software cuentan como materia prima para crear sus “productos finales” con la tecnología y conocimiento. Ahora bien, este conocimiento no reside en el aire, sino en las personas.

Los malos modelos directivos valoran los recursos solo en su aspecto cuantitativo sin valorar la calidad de los mismos. He oído a “grandes” gestores del sector de desarrollo de software, sacar pecho al decir que consigue dos “recursos” (por ejemplo programador) al precio de uno. Por supuesto, el cambio implicaba sustituir una persona con diez años de experiencia por dos becarios, pero desde su perspectiva el cambio de 2x1 implicaba el doble de trabajo al mismo coste…

Este mercado avanza, lentamente y en su proceso madura. Podemos decir que el ritmo al que madura el mundo del desarrollo del software es varias veces más lento que el ritmo al que avanza la tecnología, pero aun así, lo hace. Si hiciéramos un paralelismo con algún otro sector de desarrollo más maduro, supongamos la automoción, nadie se plantearía trabajar sin una metodología definida que permita a todos los miembros de los diferentes equipos conocer las reglas del juego. Aún así hay muchas empresas que no emplean ningún tipo de metodología explicita. 

Pensemos un poco sobre como impacta la forma de trabajar en la motivación de los profesionales. Los músicos de una orquesta, por muy buenos que sean, necesitan una partitura compartida para tocar juntos. Es cierto que la partitura ya esta creada por un compositor (en muchas ocasiones genios) y esta no varía. Se repite de idéntica manera miles de veces y no se adapta a las demandas del que la escucha. Nuestra partitura es más compleja. Varía con el tiempo y no es conocida de antemano (aunque las metodologías predictivas se empeñen en decir lo contrario). Al empezar nuestra obra no conocemos la cantidad de violines o tubas que necesitaremos…

Esta complejidad es una razón más para contar con una poderosa herramienta como la metodología que nos guie por el camino. Esta nos aporta:

  • Evitar desgastarnos en definir y redefinir procesos implicados en el día a día.
  • Aplicar cierta “objetividad” a la forma de trabajar y a la valoración del trabajo de los miembros del equipo.
  • Ganar en visibilidad al definir roles y responsabilidades asociadas.
  • Alinear los objetivos de los diferentes miembros del equipo.
  • Tener una base que adaptar y mejorar para los siguientes proyectos.

Cualquiera de estas características son básicas a la hora de motivar a los profesionales, sobre todo a los buenos. He tenido experiencias al respecto y es un autentico fenómeno a estudiar como cambia la aptitud de los miembros de un equipo que trabajan sin ninguna metodología explicita, al implantar una metodología (especialmente las ágiles). Muchos de ellos tienen la sensación de que su trabajo no se valora porque no es visible, lo cual acaba implantando un “comunismo” asesino de la eficiencia.

Podemos decir que los buenos profesionales necesitan visibilidad y que la metodología aporta visibilidad…así que la cosa está clara.

miércoles, 16 de septiembre de 2009

¿Que hace un tecnólogo como tú en una crisis como esta?

Estamos en lo que parece el ecuador de la crisis económica mundial. Los que ya peinamos alguna que otra cana ya hemos pasado por esto antes y probablemente pasaremos por alguna más. Ya conocemos como se comporta el mercado y os apuesto lo que queráis a que, aunque pase la dichosa crisis, el tiempo de reacción de las empresas de tecnología hacia sus currillos (y la de los clientes hacia las empresas) se estirará lo más posible.

Nos guste o no tenemos que mover ficha. De hecho, tenemos que hacer ajustes para corregir un problema que ni hemos creado ni podíamos haber evitado... Con el fin de adecuarnos a la situación, debemos ser especialmente cuidadosos en algunos aspectos de nuestro día a día, sobre todo, con los directamente o indirectamente relacionados con los (escasos) presupuestos que manejamos.

  • Ajusta y maximiza más que nunca los recursos
    Puede ser un momento interesante para transmitir al cuadro directivo la necesidad de introducir/mejorar la metodología a emplear en los desarrollos. Argumentado las ventajas de la misma, las empresas suelen estar más receptivas a las mejoras, sobre todo si estas implican poca (o nula) inversión. Mantener una buena visibilidad es un aspecto clave para que los stakeholders analicen mejor que nunca en que se invierten los recursos.
  • Céntrate en lo importante
    No es nada nuevo, lo deberíamos hacer siempre y las metodologías agiles se cansan de repetirlo. El riesgo de que los proyectos se trunquen a medio camino es más alto en época de inestabilidad. Los presupuestos se aprueban para los diferentes ejercicios y puede ocurrir que un proyecto se paralice o cancele. 
    Priorizar las funcionalidades que más valor aportan, así como evaluar con detalle aspectos de más difícil R.O.I. (Creación de Frameworks, metalenguajes, diseñadores…) siempre es importante, pero ahora se vuelve crítico.
  • Tomate tiempo para apoyar a la fuerza comercial
    Vender siempre es difícil, vender Software o servicios de I.T. siempre es muy difícil, pero es que en épocas duras se convierte en una acción titánica. Los comerciales e ingenieros comerciales involucrados en las acciones de preventa necesitan justificar y explicar más claramente que nunca porque el cliente debe invertir en el servicio que ofrecemos.
    No escatimes en apoyar con argumentos tecnológicos las soluciones ofrecidas, puesto que cada venta es una batalla y todas las justificaciones que tengamos a mano serán muy apreciadas.
  • Valora la posibilidad de emplear soluciones estándar
    Potencia el R.A.D. Intenta recortar los tiempos de desarrollo evitando en la medida de los posible los desarrollos a medida desde cero. Probablemente existan soluciones, bien creadas por Microsoft o terceros, para la mayoría de problemas a solucionar. Esto te permite centrarte en la funcionalidad que realmente aporta valor. Es increíble la cantidad de funcionalidad común que está a mano y no empleamos por no tomarnos el tiempo en evaluarla...
  • Re-evalúa las infraestructuras
    Probablemente el súper C.P.D. diseñado en los momentos de vacas gordas pueda ser sustituido (antes de realizar la inversión a poder ser ;)) por un sistema en Cloud que reduzca el coste total del proyecto de manera significativa. O quizás explicando en detalle el coste que supone cierto grado de disponibilidad de una funcionalidad, esta no le parezca tan importante al cliente…
  • Revisar aquella certificación para la que nunca tenias tiempo
    Si tienes un poco más de tiempo de lo habitual, ten en mente que las crisis no son eternas, pasan y cuando se levante el telón los mejor preparados podrán aprovechar el tirón para reclamar los mejores puestos que vuelva a ofrecer el mercado.

Lo que nunca debemos hacer es caer en el desanimo, estamos en esto porque es nuestra profesión y además porque nos gusta, que se note!

viernes, 11 de septiembre de 2009

La historia del zapatero de Ikea y la perspectiva del proyecto

La historia que os voy a contar está basada en hechos reales. Aprovechando que tengo unos días libres antes de salir de viaje me he dispuesto a acabar con la fila india de zapatos que tengo por casa. Así que ni corto ni perezoso me fui al Ikea y me cogí un zapatero de esos tan apañado que te montas en casa.

Me puse manos a la obra y decidí seguir las instrucciones que tan amablemente incluyen los suecos a modo de ”paso a paso”. Tras una revisión previa combinada con mis nulos conocimientos en bricolaje y ebanistería, me decidí a seguir los pasos indicados al pie de la letra. El resultado, os lo podréis imaginar, un zapatero impresionante con una de las tablas del frontal colocada al revés, es decir, un precioso acabado en madera virgen…

Me ha dado por pensar los motivos de este pequeño desastre y la analogía de los mismos en los proyectos de desarrollo de Software. Podemos decir que yo he sido el programador currillo que he recibido una serie de pequeñas tareas bien definidas. Estas tareas fueron creadas por un gran analista sueco como resultado de un diseño basado en el análisis de la funcionalidad a cubrir.

Por supuesto, no tengo ninguna duda de que el señor analista sueco creó las tareas de manera correcta en su contexto y en su momento. Lamentablemente en el proceso de “codificación” de mi zapatero se han dado algunas circunstancias inesperadas.

  • Errores humanos
    Tras comprobar de nuevo las instrucciones observo que no se especifica explícitamente el lado que debe dar hacia el frontal y cual no. Obviamente mi decisión no fue la correcta.
  • Falta de comunicación
    La verdad es que el analista sueco no me pillaba lo suficientemente a mano para completar las dudas que me surgían sobre el manual mientras avanzaba el desarrollo del proyecto.
  • Falta de perspectiva e interiorización del alcance global del proyecto He depositado mi confianza en el manual, sin llegar a interiorizar los componentes del proyecto. Si lo hubiese comprendido como un conjunto, me hubiera dado cuenta de que ese madero en el frontal dado la vuelta no encaja bien, pero para cuando  comprendí que eso era el frontal ya era demasiado tarde….
  • Falta de revisiones
    Una pequeña revisión al finalizar cada paso o conjunto de pasos podría haber evitado la desviación. Esto me habría limitado la cantidad de pasos a deshacer para recolocar el maldito madero y por lo tanto, el esfuerzo (dinero en proyectos reales) malgastado en problemas que yo mismo me he buscado.

En el mundo del Software tanto las especificaciones como los entregables son más abstractos. Si no comprendemos bien las necesidades del cliente, (las que nos transmite y las que ni él mismo ha identificado aún!) podemos llegar a las oficinas del cliente con un software que le produzca mas enfado que satisfacción. Dichas necesidades en la mayoría de ocasiones nos son totalmente ajenas y desconocidas puesto que no conocemos profundamente el sector del cliente (Al menos en los primeros proyectos tipo!).

Sin trabajar este proceso de interiorización apoyado en la empatía, podemos entregar el zapatero al cliente sin enterarnos de que tenemos el madero al revés aunque lo estemos mirando con todo detalle...

Así que dicho queda, me voy a por la caja de herramientas de nuevo…

domingo, 30 de agosto de 2009

Desarrollador con calidad vale por dos (o más...)

Las metodologías ágiles nos recomiendan centrar nuestros esfuerzos en aportar valor al cliente. Dicho valor se traslada a través de los entregables que el equipo va liberando en las diferentes iteraciones. En el mundo del desarrollo de aplicaciones informáticas, el más importante de todos los artefactos que entregamos es el Software. Y este software se genera desde el código que generan los miembros del equipo.

Bueno eso este claro. Y que menos se puede pedir al equipo que se aplique al máximo con el código que genera? Como desarrollador de software el código es tu producto final, y este debe ser desarrollado con la máxima calidad que nos sea posible.

Algo que todos (los que entendemos como funciona el negocio del desarrollo de software..) tenemos claro, es que es más rentable asegurar al calidad de nuestros desarrollos desde las primeras etapas del proceso en vez de corregir los errores más tarde. El impacto de los errores crece exponencialmente cuanto más tarde se descubren.

Por lo tanto, como desarrolladores profesionales que somos, debemos poner especial hincapié en mantener presente la calidad en nuestros proyectos. Es fácil de decir, pero como a menudo, no tan fácil de conseguir…

Existen algunos grupos de problemas comunes que podemos identificar como focos problemáticos:

  1. Comunicación pobre y malas interpretaciones
    La capacidad de comunicación del ser humano es uno de los factores que le diferencia del resto de las especies. El grado de abstracción que podemos aplicar a la misma es muy alto. Esta característica, nos permite transmitir mucha información de manera muy efectiva.

    Por ejemplo, si yo te digo, singelton, grano fino, o capa de servicios y ambos tenemos un conocimiento equivalente en la materia, hemos conseguido transmitir una serie de conceptos más o menos complejos de manera optimizada.

    Es una herramienta potente, pero que debemos cuidar para evitar desviaciones igual de potentes. La comunicación debe ser clara y fluida, asegurando que el receptor ha comprendido el mensaje en la misma dimensión que deseamos emitirlo. No se debe escatimar en comunicación funcional, técnica, recabar feedback del equipo y aplicar un poco de psicología (la empatía puede ser la clave). Colaborar en este juego es parte de la tarea de cualquier miembro de un equipo.

  2. Errores de programación
    Las personas  escriben código y las personas comenten errores. Ergo…el código tiene errores (ahora no abusemos del mismo para hacer chapuzas diciendo es intrínseco el error en la persona...)

    Escribir buen código no es fácil. Debemos tener en cuenta aspectos como seguridad, rendimiento, localización, mantenibilidad... y en tiempo record!

    Aunque apoyarnos en el CLR ayuda, siempre existirán bugs que tendremos que corregir y realizar mantenimiento sobre el mismo. Y esto ocurre haciendo las cosas todo lo bien que podemos, esforzándonos al máximo como desarrolladores. Imagínate si no lo hacemos así…

  3. Falta de realimentación de pruebas
    Escribir pruebas unitarias es un trabajo que (casi) no aporta visibilidad. Lleva tiempo y no es código fácil de reutilizar. Aunque los desarrolladores sabemos que debemos escribirlas y esforzarnos y alcanzar la cobertura d código marcada por los parámetros de calidad del proyecto, a menudo nos enfrentamos a desincentivos que tientan a no realizarlas. Pero lo que es seguro, es que sin un buen conjunto de pruebas, (no tiene que ser muchas pero si bien diseñadas) es muy fácil cambiar código y no descubrir los efectos secundarios no deseados hasta demasiado tarde. (vamos creando un coladero…)

  4. Versión distorsionada
    Gracias a la metodología al principio, y a las herramientas de control de código fuente, más adelante no se han producido millones de asesinatos entre los desarrolladores. Aún así existen archivos y configuraciones de puestos que no son propios del código fuente cuyas diferencias producen errores que son difíciles de diagnosticar. Cuantas veces hemos oído eso de "En mi máquina funcionaba!".

  5. Falta de transparencia
    Para desarrollar un proyecto con éxito hace falta todo. Como una de las piezas falle o no se comunique adecuadamente todo el proyecto se puede venir abajo como un castillo de naipes. Tradicionalmente, han sido mundos diferentes (e inconexos!!) aspectos como la infraestructura de desarrollo, el sistema de gestión del proyecto, el trazado de requisitos/errores, métricas...(Intenta sincronizar el s.v.n. con el Visio que se sacó tu gerente de la manga...;))
    En esta situación, el equipo tiene poca visibilidad respecto al estado global del proyecto. (aparte de los odiados y poco fiables informes de estado...)

Cada una de estas cinco categorías son un foco potencial de problemas que afectan directamente a la calidad del código realizado. Esto implica que el mecanismo que el cliente emplea para evaluar el valor aportado, tiene problemas que afectan, directamente, a las sensaciones que transmitimos. La aparición de herramientas que nos permiten gestionar todos los aspectos relacionados con el desarrollo de manera orquestada vienen a facilitarnos la vida, y conocer sus posibilidades es un esfuerzo con seguro retorno de inversión.

Por nosotros que no quede...

martes, 18 de agosto de 2009

¿Es lo mismo arquitectura por capas y N-Tier?

Me parece importante, para optimizar la comunicación entre profesionales, que todos tengamos claros los conceptos y los apliquemos para referirnos exactamente a lo mismo. Esto nos evita malas interpretaciones y errores muy críticos sobre todo en entonos de desarrollo rápido de aplicaciones (RAD). 

Existen dos conceptos arquitectónicos que a veces tendemos a confundir. Estos son la “Layered arquitecture” (arquitectura por capas) y la “N-tier arquitecture” (arquitectura de N-niveles). Me voy a referir a ellas sin traducirlas, puesto que ambos conceptos (“layer” y “tier”) pueden verse traducidas (erróneamente en el caso de “tier”) como “capa” lo cual fomenta aún más la propensión a errores.

Veamos primero que es exactamente “Layered architecture”: 

Se centra en una distribución jerárquica de las roles y responsabilidades proporcionando una separación efectiva de las preocupaciones. (cada cual que se apañe con sus problema…). El rol indica el modo y el tipo de interacción con las otras capas, y la responsabilidad indica la funcionalidad a alcanzar.

Por ejemplo, el diseño de una típica aplicación Web comprende una capa de presentación (funcionalidad relacionada con la U.I.), capa de negocio (procesamiento de reglas de negocio) y capa de datos (funcionalidad relacionada con el accesos a datos.)

El estilo de arquitectura por capas tiene algunas características que  la identifica:

  • Describe una descomposición de servicios de tal manera que las interacciones ocurren normalmente entre capas vecinas. (depende de lo laxos que queramos ser…)
  • Las capas de la aplicación pueden residir en el mismo ordenador fisco o pueden estar distribuidas en separados equipos. El concepto de distribución se aplica siempre que se produzca el mecanismo de marshaling para realizar una comunicación (siempre que no se comparta espacio de memoria…)
  • Los componente de cada capa se comunican con otros componente de otras capas a través de un conjunto de interfaces bien definidos. (sino apañados vamos…)
  • En alguna ocasión ha sido descrito como “pirámide invertida de reutilización” donde cada capa agrega sus propias responsabilidades  y abstracciones a la capas que están por debajo.

Que beneficios conseguimos aplicando esta distribución en capas?

Abstracción, encapsulamiento, capas de funcionalidad muy bien definidas, alta cohesión, reusabilidad (las capas inferiores de la pirámide no tienen dependencias de las superiores por lo que es fácil reutilizarlas) y débil acoplamiento (comunicación basada en abstracciones)

La separación, reduce el riesgo y el impacto de los cambios tecnológicos. Por ejemplo al cambiar el mecanismo de persistencia de la aplicación las capas que lo consumen no tienen porque realizar cambios. Además aumenta el rendimiento (a partir de cierta carga de trabajo) al distribuir las capas sobre múltiples capas físicas. También aumenta la escalabilidad y la tolerancia a fallos.

Este escenario es propicio para implementar una buena política de pruebas, permitiendo conmutar entre diferentes implementaciones de los interfaces (mock, servicios reales…)

Por otro lado tenemos la N-Tier architecture

El estilo de despliegue de esta arquitectura describe la separación de la funcionalidad en diferentes segmentos, de manera similar a la arquitectura por capas. pero cada segmento es un nivel que se encuentra físicamente en un equipo independiente.

Es un estilo que define el despliegue de las capas de la aplicación, se caracteriza por por una descomposición funcional de la aplicación, componentes de servicios y su despliegue distribuido, proveyendo mejoras de escalabilidad, disponibilidad  y utilización de recursos.

Cada capa es completamente independiente del resto, excepto de aquella/s se encuentran inmediatamente por debajo de ella. La capa n sabe como manejar las peticiones a la capa n+1, como trasladar dicha petición a la capa n-1 (si es que existe) y como tratar el resultado de la misma.

Las arquitecturas con “N-Tiers” poseen por lo menos 3 capas lógicas separadas. Cada capa tiene una funcionalidad especifica, de la cual es responsable y están localizadas en diferentes servidores físicos. Una capa (“layer”) se despliega en un nivel (“tier”) si más de un servicio o aplicación es dependiente de la funcionalidad expuestas por la capa.

Veamos los beneficios que nos aporta esta arquitectura:

  • Mantenibilidad
    Cada nivel es independiente de los demás, con lo que se consigue independencia. Se puede actualizar o modificar un nivel sin afectar a la aplicación en su conjunto. 
  • Escalabilidad
    Es razonablemente sencillo escalar puesto que los niveles están basadas en el despliegue de las capas.
  • Flexibilidad
    Cada nivel puede ser gestionado o escalado independientemente, lo cual aumenta la flexibilidad.
  • Disponibilidad
    Las aplicaciones pueden explotar la arquitectura modular empleando componentes fácilmente escalables.

Resumiendo un poco :

Podemos decir que para que una aplicación sea “N-Tier”, es condición necesaria pero no suficiente que mantenga una arquitectura por capas. Esta característica nos permite cumplir los requisitos de despliegue (3 o más capas separadas) que hacen a una aplicación “N-Tier”.

miércoles, 12 de agosto de 2009

Dulce introducción al Kanban!!

Bueno, parece que SCRUM ha puesto la pica en Flandes y se ha convertido en una metodología ampliamente conocida y respetada. Pues ya está, no? ya tenemos metodología ágil para cualquier tipo de proyecto y para siempre…

Muy confiado tienes que ser para creerte eso…

En mi trabajo hemos desarrollado un producto aplicando SCRUM con unos resultados muy satisfactorios. Dicho producto, se ha comenzado a implantar y ahora entra un equipo de soporte a mantener la primera versión del mismo y comienza una nueva rama de desarrollo de la siguiente versión.

Estaba planteándome como organizar el equipo de soporte y no acababa de encajar SCRUM sobre la naturaleza de su trabajo(la verdad que esta y cualquier otra metodología…). Es muy difícil organizarse para planificar incluso un pequeño Sprint, puesto que no se conocen las tareas de antemano. Por lo tanto, llegué a la conclusión de que necesitamos para este tipo de proyectos (que no son pocos) algo todavía más adaptable que SCRUM…

Tomando un café con el gran (aunque javero) Jorge Prieto me comentó algo sobre Kanbas y comencé a tirar del hilo para ver si me podía cuadrar eso que sonaba a pescado crudo…

Así que vamos a aprovechar este post para explicar que es eso de Kanban compararlo con SCRUM e identificar sus conflictos potenciales. Antes que meternos en harina vamos a dejar las cosas claras, haciendo un pequeño resumen de SCRUM y Kanban

SCRUM (en pocas palabras)

  • Divide su organización en pequeños equipos auto-organizados y multidisciplinares.
  • Divide el trabajo en una lista de pequeños elementos muy concretos.
  • Ordenar la lista por orden de prioridad y estimar el esfuerzo relativo de cada elemento.
  • Dividido en iteraciones cortas de longitud fija (normalmente con entrega o demostración después de cada iteración.)
  • Optimizar el plan de liberación y actualizar las prioridades en colaboración con el cliente, sobre la base de conocimientos adquiridos por la inspección de la entrega después de cada iteración.
  • Optimizar el proceso por tener una retrospectiva después de cada iteración.

Resumiendo el resumen:

Pasamos de “Muchas personas haciendo algo muy grande” a “Pocas personas haciendo cosas pequeñas que se integran con regularidad para ver el conjunto.”

Kanbas (en pocas palabras también)

  • Visualizar el flujo de trabajo
    Dividir el trabajo en trozos escribir cada uno de los elementos en una tarjeta y poner en la pared.
    Usar el nombre o columnas para ilustrar en que estado se encuentra cada elemento dentro del flujo de trabajo.
  • Límitar WIP (Work In Progress)
    Asignar límites explícitos obre cuantos elementos pueden estar en cada uno de los estados del flujo de trabajo.
  • Medir el tiempo
    Contar el tiempo promedio para completar un tema, a veces llamado "tiempo de ciclo" y, como es obvio, optimizar el proceso para que el tiempo tan pequeño y previsible como sea posible.

image

Podemos observar que Kanban es todavía menos prescriptivo que SCRUM.

Prescriptivo significa “reglas para seguir”. 100% prescriptivo implica que no tienes que usar el cerebro, ridículo verdad?…) y en este apartado vemos que SCRUM aporta mas reglas “out-of-the-box” como por ejemplo encajar en un tiempo los Sprints cosa que Kanban no hace.

Para hacernos una mejor composición podemos observar la escala de “prescriptividad” (toma ya!) de forma gráfica:

image

Como siempre podemos decir que la mejor opción es no limitarse a un herramienta en concreto. Probablemente la solución nuestros problemas se encuentre en una combinación de varias. Muchos equipo Kanban realizan una reunión diaria a primera hora (típica liturgia de SCRUM). Algunos equipos de SCRUM que he conocido, escriben su Backlog como Casos de Uso (típico de RUP) o limitan el tamaño de las colas (típico de Kanbas).

Así que como siempre “haz las cosas como mejor te funcionen”, ya os contaré el resultado de aplicar esta forma de trabajo con el equipo de soporte.

Para terminar os cito a Miyamoto Musashi que los japoneses algo saben de todo esto:

“No desarrolles ninguna dependencia de arma o escuela de lucha”

Los mejores países para hacer negocio

Si estáis pensando en globalizar vuestras líneas de negocio o cambiar de aires profesionales, os puede resultar interesante saber que el World Bank Group ha publicado su informe anual "Doing Business" que clasifica 181 países sobre lo propicio que es su regulación hacia los empresarios.

El informe proporciona una medida cuantitativa de la normativa, que sirva como soporte a la decisión de abrir un negocio y se aplica a las pequeñas y medianas empresas nacionales. Las economías están clasificadas en base a un índice de facilidad de hacer negocios. (Índice creado por el propio World Bank Group)

Los valores más altos de este índice indican un conjunto de reglamentos más ventajosos para las empresas y el fortalecimiento de la protección de los derechos de propiedad.

Facilidad de hacer negocios:

  1. Singapur.
  2. Nueva Zelanda.
  3. Estados Unidos.
  4. Hong Kong. (es una Región Administrativa Especial…)
  5. Dinamarca.
  6. Reino Unido.
  7. Irlanda.
  8. Canadá.
  9. Australia.
  10. Noruega.

Los criterios tenidos en cuenta a la hora de confeccionar este ranking son:

  • Facilidad de hacer negocios
    Procedimientos, tiempo, costo y capital social mínimo para abrir un nuevo negocio.
  • Permisos de Construcción
    Procedimientos, tiempo y costo para obtener permisos de construcción, las inspecciones y las conexiones de servicios públicos.
  • Emplear trabajadores
    Índice de dificultad de contratación, índice de rigidez de horas, índice de dificultad de despido, coste de despido.
  • Registro de la Propiedad
    Procedimientos, tiempo y costo para la transferencia de bienes inmuebles comerciales.
  • Obtención de crédito
    Fuerza de los derechos legales, profundidad de crédito.
  • La protección de los inversores
    Fuerza de la protección de los inversores, grado de divulgación, grado de responsabilidad del director y la facilidad de adaptación del accionista.
  • Impuestos
    Número de pagos de impuestos, el tiempo necesario para preparar y presentar declaraciones de impuestos y pagar los impuestos, relación del total de impuestos con el porcentaje del beneficio.
  • Comercio a través de las fronteras
    Documentos, tiempo y el costo para exportar e importar.
  • El cumplimiento de los contratos
    Procedimientos, tiempo y costo para resolver una disputa comercial.
  • Cierre de una empresa
    La tasa de recuperación de la quiebra.

Como podéis comprobar está todo pensado...

Si queréis profundizar más en el tema, pasaros por aquí World Bank - Doing Business

lunes, 10 de agosto de 2009

¿Por que iterar?

Aplicando el patrón C.S.P. (Common Sense Pattern…) en nuestros desarrollos, observamos que debemos cumplir con las necesidades del cliente. Acto seguido, descubrimos, que estas cambian más que los nos gustaría (ouchh!). Por lo tanto, se crea la necesidad de ir ajustando el avance del proyecto a las necesidades reales (y cambiantes) del proyecto.

¿Pero como…?

La respuesta que nos aportan las metodologías agiles es sencilla, iterando. Partiendo el desarrollo de la aplicación en pequeños entregables que el usuario pueda probar e ir enriqueciendo. Suena lógico, pero vamos a hacer un esfuerzo de plasmar negro sobre blanco las principales ventajas que esta forma de trabajar nos ofrece:

  • Gestión de riesgos
    Asumámoslo, el resultado deseado no es concebible por adelantado. Existen riesgos, algunos ya identificados y otros por identificar. Para gestionarlos correctamente debes demostrar o refutar tus requisitos y diseñar las suposiciones implementando incrementalmente elementos que son objetivos del sistema, empezando con los de más alto riesgo.
  • Económicos
    En un ambiente de negocio incierto (casi todos los proyectos lo son !!) es clave optimizar los esfuerzos en las mayores prioridades del proyecto. Debemos manejar cada iteración como un conjunto de fichas de juego a apostar por un conjunto de funcionalidad que se pueda entregar, probar y que funcionen.
  • Enfoque
    Solo podemos mantener una cantidad limitada de elementos en la mente. Trabajando con pequeños lotes de trabajo podemos focalizar nuestros esfuerzos con un conjunto de funcionalidades que comprendemos y somos capaces de encajar y entender.
  • Motivación
    No existe un mecanismo mejor de motivación de acción prolongada (el dinero solo motiva en un espacio reducido de tiempo!!) para un profesional que comprobar como su creación se usa, es efectivo y valorado por los usuarios.
  • Control de la teoría
    Las iteraciones nos permiten controlar mejor las desviaciones, reduciendo el impacto de los errores en las estimaciones y crear un mecanismo de retroalimentación sobre los planes del proyecto.
  • Implicación de los interesados
    Los patrocinadores (clientes, usuarios, dirección…) pueden observar los resultados más rápidamente (cumpliendo así con la visibilidad, requisito fundamental de cualquier desarrollo) y así aportar mayor compromiso, implicación y financiación.
  • Aprendizaje continuo
    Todos los actores del proyecto aprenden en cada iteración. Los miembros del equipo adquieren conocimiento funcional y aportan mejoras desde la prospectiva tecnológica y los funcionales comprenden las implicaciones de automatizar los procesos empresariales. Todos aportan y el proyecto crece rápido y mejora.

Ya tenemos un conjunto de argumentos para convencer a los stakeholders más peleones acerca de las bondades de trabajar en pequeñas iteraciones, ahora el que quiera entender que entienda…

lunes, 3 de agosto de 2009

Aplicaciones multilenguaje ASP.NET MVC

El desarrollo de capa de presentación Web en .NET ha cambiado desde que Microsoft se decidió a realizar una implementación oficial del conocido patrón MVC en la plataforma ASP.NET y la (amplia) comunidad de desarrolladores de ASP.NET lo asumió con todos los cambios que implica.

Y esta implementación ha calado rápido y profundo, (ya se está desarrollando la segunda versión) ha llegado a la gente acostumbrada a Frameworks ligeros de desarrollo web que incluían sus propias implementaciones de MVC. Entre otras ventajas, ha ayudado a estandarizar la organización de los archivos del sitio y refinar las responsabilidades (Controladores -> Procesos de interfaz de usuario, workflow de la aplicación... Vistas –> mostrar la información de manera amigable y recoger los datos, validaciones de formato...).

Si deseamos acogernos a la implementación de Microsoft de dicho patrón deberemos ir encajando los problemas la funcionalidad de toda la vida sobre estas nuevas reglas de juego.

Uno de los requisitos clásicos más general es que nuestra aplicación disponga de características de globalización / localización. La idea general es la de siempre, evitar incluir ninguna referencia explicita a una determinada cultura y jugar con las características de globalización que nos ofrece el .NET Framework. Pero como ya sabemos, en Web todo se complica un poquito más. Al correr sobre un protocolo sin estado como HTTP recae sobre nuestra aplicación recordar la cultura especificada por el usuario entre las distintas peticiones.

Entonces tenemos clara la misión:

Mostrar los elementos de la UI acordes a la cultura que el usuario especifique.

Suena fácil, no? Pues lo es, si somos un poco cuidadosos…

(Por cierto, os dejo al final del post el código de la solución para que os lo podáis descargar y probar.)

1 - Estableciendo las bases, recursos a los ficheros de recursos.

Vamos a ir realizando un ejemplo paso a paso para evitar perdernos:

  1. Creamos un nuevo proyecto ASP.NET MVC Web Application.
  2. Incluimos en el proyecto la carpeta de App_GlobalResources.
  3. Incluimos un par de ficheros de recursos de acuerdo a la configuración de recursos por idioma que deseamos incluir.

    La convención de nomenclatura de los mismos dice que la primera parte del archivo es el nombre base. La segunda especifica la cultura (puede también ser solo el lenguaje que la forma). Esta última parte es opcional, entendiéndose como el juego de recursos predeterminado en caso de no exista.

    Es responsabilidad del .NET Framework enlazar automáticamente (en base a los ficheros de recursos especificados) el fichero adecuado con a la cultura especificada en actual hilo de ejecución.

    Por ejemplo, creamos el fichero predeterminado (en Inglés) y otro para español sin tener en cuenta el país. (MLTest.resx y MLTest.es.resx (para cualquier cultura con lenguaje español))
  4. Incluimos en el conjunto de ficheros de recursos todos los recursos que nuestra aplicación va a necesitar.
    En nuestro caso solo uno con nombre "GREETING".
  5. Incluimos desde una vista ( por ejemplo Views/Home/Index.aspx) la forma de consumir el recurso:

    <%
    =Resources.MLTest.GREETING%>

    Fuertemente tipado, Intellisense, detección de errores en tiempo de compilación...(da gusto verlo!!)

Bueno, pues ya tenernos una aplicación que nos muestra los recursos en base a la cultura del Framework instalado (en el servidor Web en este caso) que se encarga de especificar la cultura del hilo de ejecución.

Ya es algo, pero no es lo que queremos, verdad?

(El que dude que revise la misión que hemos puesto arriba)

2- Estableciendo la cultura del hilo en ejecución

Ya sabemos que debemos establecer la cultura del hilo de ejecución para que el Framework cargue el fichero de recursos adecuado, pero ahora la pregunta es cuando?

Recordar que cada petición empieza de nuevo y no recuerda las anteriores ( HTTP es stateless). Indagando un poco en la MSDN podemos ver que la clase Controller (de la que derivan nuestros propios controllers) de la implementación del MVC de Microsoft especifica dos métodos virtuales que nos van a resultar muy interesantes:

  • OnActionExecuting
    Se ejecuta antes de la llamada a cualquier Action Method.
  • OnActionExecuted
    Se ejecuta después de la llamada a cualquier Action Method. (obvio, no?)

Como debemos de establecer la cultura cada vez que nos realicen una llamada a cualquier action method de cualquier controlador, lo ideal es crear un controlador base del cual hereden todos los demás y sobrescribir en el método OnActionExecuting el mecanismo para restablecer la cultura. Nuestros controladores harán así transparente al resto de la aplicación las particularidades de trabajar con estado. También podríamos usar un atributo aplicado sobre la clase base y en la implementación del atributo especificar que implementa el interfaz IActionFilter si lo queremos hacer un poco mas AOP que OO.

En la implementación que os dejo utilizo un atributo con el que decoro la clase base (Al gusto!!)

En el ejemplo:

La clase base de los controladores:

[SetCulture]
public class BaseController : Controller
{
...
}

Y en la implementación de la clase del atributo programo como establecer la cultura seleccionada en el hilo activo:



public class SetCultureAttribute : FilterAttribute, IActionFilter
{
public void OnActionExecuting(ActionExecutingContext
actionContext)
{
CultureHelper.SetCulture(GetCurrentCulture
(actionContext), actionContext.
HttpContext.Session)
}
...


Para almacenar la cultura especificada entre las llamadas podemos emplear diferentes mecanismos, en este ejemplo el flujo de trabajo será el siguiente:



  1. Revisar si tiene alguna cookie de nuestro sitio que especifique la cultura.

  2. Comprobar la variable de sessión de la cultura.

  3. En caso de no disponer de ninguna de las dos informaciones anteriores, preguntar por las culturas configurados en el navegador y presentar la interfaz de usuario en base a la primera coincidencia que se produzca.


En la implementación que os dejo del proyecto podéis consultar los métodos que he creado para realizar dichas acciones, son muy sencillos y podéis modificarlos al gusto.

Los principales métodos son:



  • GetCurrentCulture de la implementación del atributo, que consulta la información previamente almacenada en base al flujo que hemos comentado.

  • CultureHelper.SetCulture que recibe la cultura a asignar y el objeto intrínseco Session Object y carga cultura en el hilo actual de ejecución.


Aquí nos aparece otro problema.(Que raro, eh?)

Si el usuario es la primera vez que accede a la Web no tiene cookie ni session establecida.

Para intentar que la aplicación sea lo más “inteligente” posible, recogemos del navegador las culturas que tiene especificadas y las cruzamos con una sección especifica del fichero de configuración creada a tal efecto.

Por ejemplo, si el usuario tiene Chino e italiano necesito determinar si mi aplicación dispone un algún fichero de recursos que da soporte a alguno de los mismos. Para ello me creo una section en el fichero de configuración y un handler que lo soporte que especifique una lista de culturas soportadas y su orden de aplicación. (Así vemos también como poder realizar esta tarea.)

Observar que la tarea no es tan sencilla como coger el idioma y asignarlo al hilo y dejar que el Framework resuelva. (si no lo puede resolver que aplique la predeterminada) puesto que si el usuario tiene, entre todos los lenguajes del navegador, uno que tenemos implementado nos lo estaríamos saltando. (Por ejemplo Chino, Italiano, Español, Ruso)


En el fichero de configuración especificamos:

<
configSections>
...
<section name="EnabledLanguages" type="AndoniArroyo.MLTest.
Controllers.Infrastructure.Configuration.EnabledLanguagesSection,
AndoniArroyo.MLTest"
/>

</
configSections>
...

además incuimos la citada sección:


<!--Especifica el conjunto de culturas con el que trabaja la aplicación. La última es la cultura por defecto-->
<EnabledLanguages>
<Languages>
<add title="Spanish" code="es-ES" />
<add title="English" code="en-GB" />
</Languages>
</EnabledLanguages>


Para que la aplicación pueda manejar esta section debemos implementar el handler que la maneje:


namespace AndoniArroyo.MLTest.Controllers.Infrastructure.
Configuration
{
public sealed class EnabledLanguagesSection : ConfigurationSection
{
[ConfigurationProperty("Languages", IsDefaultCollection = true,
IsRequired = true)]
internal LanguageElementCollection EnabledLanguages
{
get { return (LanguageElementCollection)this["Languages"]; }
}
}
}

Estos lenguajes será los que tendrá en cuenta el método que intenta cargar el lenguaje desde la información recogida del navegador.


Pues ya casi lo tenemos.

Nos queda por ver como el usuario puede explicitamente modificar la cultura con la que desea trabajar en la aplicación. Visto todos lo anterior la cosa es fácil, no? Basta con crear un action method de modificación de la cultura y en la implementación del mismo llamar explícitamente al método de establecer cultura con el parámetro recibido. (CultureHelper.SetCulture pasándole la cultura especificada por el usuario y la referencia al objeto de sesión...)


Recapitulando, hemos visto unas cuantas cosas:



  • Hemos observado los mecanismos de globalización que nos da el .NET Framework y como extenderlos para nuestras necesidades en web.

  • Definido una política de establecer la cultura activa de la aplicación intentando que la aplicación se adapte al usuario.

  • El punto donde cubrir las características de sin estado del HTTP para establecer la cultura especificada por el usuario.

  • Hemos creado secciones personalizadas en el fichero de configuración y hemos visto como manejarlas.


Y como extra lo prometido el ejemplo con todas estas ideas en acción.


martes, 28 de julio de 2009

Fundamentos de la I.A. (Inteligencia Artificiosa??)

Las aplicaciones informáticas (eso si, a golpe de cañon!) van madurando. Ya consiguen, en la mayoria de las ocasiones, hacer lo que dicen que hacen y comienzan a ser realmente útiles y hasta necesarias. Partiendo de esta base, el usuario, como es lógico, desea que la aplicación sea más y más eficiente. Demanda ciertas características asociadas tradicionalmente con lo que denominamos "inteligencia". Que el software no solo responda de manera determinista, sino que sea capaz de ayudarle, de preveer sus necesidades con antelación y responder con reflejos a la realidad del día a día.

De nuevo, la pelota está en nuestro tejado...(la de los desarrolladores de software, no mires hacia arriba!!)

Nuestras aplicaciones, independientemete de la funcionalidad que cubran, deben comenzar a adoptar dichas caracteríaticas puesto que será una cualidad excluyente a plazo medio. Es fácil de decir, pero no tan sencillo de transformar en instrucciones que admita un compilador... Por ello vamos a analizar algunas de las características que debe cumplir un software para poder decir que es "inteligente" y a que problemas comunes se deben enfrentar independientemente del campo en el que se apliquen.

Haciendo un poco de historia, hacia 1950 parecía que la mecanización de la inteligencia estaba a tiro de piedra pero todavía más de 50 años después no hemos conseguido interiorizarla a nivel general. ¿Existirá alguna razón oscura para no poder lograr alcanzar esa misteriosa meta? Realmente no hay quien sepa donde está la raya divisoria entre la conducta inteligente y la no-inteligente (pensar que exista una raya puede ser una error en si mismo) Lo que si sabemos es que existen algunas características que denotan inteligencia:

  • Responder con mucha flexibilidad a las situaciones.
  • Sacar provecho de circunstancias fortuitas.
  • Hallar sentido en mensajes ambiguos o contradictorios.
  • Reconocer la importancia relativa de los diferentes elementos de una situación.
  • Encontrar semejanzas entre varias situaciones, pese a las diferencias que puedan separarlas.
  • Encontrar diferencias entre varias situaciones, pese a las semejanzas que puedan vincularlas.
  • Sintetizar nuevos conceptos sobre la base de conceptos viejos que se toman y reacomodan de nuevas maneras.
  • Tener ideas novedosas.
  • (Ahí queda eso...)

Existe aquí una paradoja, puesto que los ordenadores son por naturaleza máquinas inflexibles y recae sobre el software simular estas características. Los expertos en I.A. crean gran cantidad de reglas inflexibles para conseguir que las máquinas sean flexibles. Dichas reglas deben estar organizadas en diferentes niveles, Tiene que haber reglas "llanas"," metarreglas" con las que modificar las reglas "llanas" y probablemente "meta-metareglas" con las que modificar las "metareglas"...(¿Hasta donde?)

La razón de tantas reglas que operan a tantos niveles distintos es que el ser humano (que asumimos posee inteligencia) se enfrenta cada día a millones de situaciones distintas, de diferentes tipos. En ciertas ocasiones nos servirán las reglas "llanas", en otras ocasiones deberemos aplicar un conjunto de reglas "llanas" modificadas o ajustadas por ciertas "metareglas". En otras ocasiones, sin embargo, deberemos crear nuevas reglas a partir de las existentes enriqueciendo así el conjunto disponible.

En el meollo de la inteligencia hay, sin duda, extraños bucles fundados en reglas que directa o indirectamente se modifican a si mismas.
Aunque la complejidad de nuestro entendimiento parece a veces tan abrumadora que el problema de entender nuestro inteligencia parezca no tener solución. Pero tengamos fé. Se han dado pasos hacia su resolución y sin duda se darán más, es cuestión de trabajo y tiempo!!

miércoles, 6 de mayo de 2009

8 maneras de cargarte la metodología de un plumazo

No es fácil implantar una manera común de desarrollar proyectos de Software. Cada maestrillo tiene su librillo y no siempre nos es fácil adaptarnos al mínimo común necesario para trabajar en equipo de manera orquestada.

Por contra, lo que sí que es realmente fácil , es dinamitar el camino andado. Hace falta muy poco para saltarse alguna que otra regla y echar abajo lo ganado con tanto esfuerzo. Existen algunos puntos claves en los que los equipos somos especialmente propensos a ceder, veamos algunos…

(*Hablando en SCRUM)

  1. No preparar suficiente Product Backlog para que el equipo adquiera prespectiva del proyecto.
    Aunque parezca mentira a los desarrolladores nos gusta saber qué leches estamos programando. De hecho las mejores propuestas de mejora de las aplicaciones surgen, al menos en las primeras fases del proyecto, del propio equipo de desarrollo. Para poder aprovechar toda esa energía/sinergia los desarrolladores deben poder hacerse una idea global del proyecto.
  2. No profundizar lo suficiente el el Sprint Planning Meeting por cansancio o falta de concrección en la exposición del Product Owner.
    La reunión previa en cada sprint permite al equipo hacerse una idea lo más concreta posible de las funcionalidades que más valor aportan al proyecto. Nos permite alinearnos con las necesidades del cliente de tal forma que todos aunemos esfuerzos en la misma dirección. También permite mitigar los riesgos e identificar sorpresar antes de asumir un compromiso. Un buen hábito que no siempre se realiza es el de poner una meta al sprint ( por ejemplo “Disponer del sistema de automatización de informes” ) que identifique la situación ideal al final del mismo y ayude al desarrollador a responder preguntas que le “tienten” por el camino. (¿Es esto importante para la meta del sprint?)
  3. Falta sistemáticamente al Daily Scrum o no respetar sin aviso las pocas liturgias que especifica SCRUM.
    Una de las características que hace a SCRUM “medio” bala de plata tan demandada por los desarrolladores, es las pocas imposiciones que propone. De éstas, una de las más importantes, es la de realizar una pequeña reunión diaria en al que cada miembro del equipo explica que ha hecho el día anterior, que impedimentos se ha encontrado y que pretende hacer en el mismo día de la reunión. Este Daily Scrum es el que da jabón al equipo y permite que todo el mundo este al día del avance, evitar duplicar batallas…
  4. Estancar conocimiento asumiendo un mismo desarrollador todas las Sprint Backlog Item de un Product Backlog Item.
    Es importante que nadie sea imprescindible. Que todos los miembros del equipo desarrollen tareas de todos los Product Backlog Items permite evitar que se creen “Reinos de Taifas” y estandariza el código. Además los equipos de desarrollo con un poco de verguenza torera se igualan por el mejor, lo que permite que se produzca aprendizaje por el camino, mejorando la calidad final del proyecto.
  5. Inventarse tareas sobre la marcha o modificar las existentes bajo demanda.
    Cuando un equipo de SCRUM asume un compromiso con el cliente a través de un sprint, dicho compromiso es inmutable por ambas partes. Es por esto que los sprints son tan cortos, para permitir reorientar el proyecto entre sprints.
  6. Intentar esconder las desviaciones o sufrir el “sindrome del investigador“.
    Si existen desviaciones, lo mejor es saberlo y ser consciente de las causas que las han provocado. En la mayoría de ocasiones dichas desviaciones se pueden justificar y son el argumento principal para mejorar los procesos del equipo. Otro de los aspectos que debe afrontar cualquier metodología es lograr una adecuada visibilidad. Esta característica es la que debe permitir permite que los StakeHolders conocozcan la situación del proyecto. Adoptar una visibilidad adecuada permite detectar las desviacioes de manera temprana así como planificar las acciones orientadas a corregirlas. Como equipo debemos ser capaces de justificarlas y transmitir los motivos a los StakeHolders adecuados, así como las acciones y planes creados. Suele ser un buen hábito, especificar a nivel de Product Backlog Item las condiciones de aceptación, en las cuales se especifican las poscondicones necesarias para que una historia pueda darse por terminada. Por supuesto, deben cumplirse todas para que se pueda dar por finalizada.
  7. No retroalimentar Sprint Backlog Items después de realizarlos.
    Es verdad que siempre vamos con prisa, que existen muchas tareas y todas las excusas que quieras poner, pero para poder decir “Hecho” (y hecho es hecho!!) cada desarrollador debe actualizar como parte de la tarea el estado de los Sprint Backlog Items asociados. Mantener al día dicha información nos permite, analizar las desviaciones y observar la tendencia del sprint y el producto. Colateralmente nos ayuda a ganar y mantener la visibilidad del proyecto manteniendo a los diferentes StakeHolder lo más al día posible.
  8. Evitar las Sprint Retrospective o demostrar falta de compromiso.
    En SCRUM la unión y el compromiso del equipo es clave puesto que todos los miembre del mismo interactuan ampliamente con los demás. El Sprint Retrosprective es la liturgia clave para recibir feedback del mismo y aumentar la unión y sentimiento de grupo. Estas reuniones pueden mejorar mucho los procesos afinando el día a día del equipo, identificando los posibles cuellos de botella y planificando como evitarlos.
    Como siempre, la clave es la constancia, no ceder al desaliento y aplicar las técnicas espartanas de confianza en tus compañeros de equipo. Solo así se puede lograr el “milagro” de echar a andar y mantener una forma de trabajo metodológica.

Como siempre, la clave es la constancia, no ceder al desaliento y aplicar las técnicas espartanas de confianza en tus compañeros de equipo. Solo así se puede lograr el “milagro” de echar a andar y mantener una forma de trabajo metodológica.

Publicado originalmente en Synergos

lunes, 27 de abril de 2009

La metodología (Ágil) va a llegaaaaar…

Como ya predijo el filósofo Arrabál, las cosas están cambiando.

Poco a poco, el sector del desarrollo del software se va haciendo un hombrecito. Desde luego este proceso no se ha postpuesto por falta de esfuerzos. La industria, cual madre concienciada, haciendo palanca a través de la Ingeniería del Software ha intentado estandarizar de muchas maneras el “artístico” proceso de crear software. Algunos de estos intentos han sido más forzados que otras (UML, CMMI, Métricas de calidad… ), pero casi todos han demostrado la misma poca efectividad.

Dichos intentos “encauzadores” de mama industria han quedado a medio camino por la misma razón: contaban con que el terreno sobre el que se apoyaban era firme, cuando realmente lo hacían sobre arenas movedizas. En relación a otras ciencias (y entornos productivo-económicos) el desarrollo de software avanza muy rápido.

Alcanzar esta velocidad de crucero implica que hay mucho que mejorar y obliga al sector a reinventarse contínuamente. La tecnología, los modelos de negocio, el alcance de la funcionalidad de las aplicaciones, la automatización de procesos, la integración y orquestación de unidades de negocio… todo está en expansión. Como todos sabemos, no se puede estandarizar lo que no deja de cambiar, por lo que los intentos realizados se han ido quedando anticuados antes de alcanzar su madurez.

Pero en ese reinventarse ha cambiado la prespectiva…

Un buen día nos damos cuenta de que estamos peleando contra la realidad. Nos liberamos y dejemos de atacar y evitar el cambio como un enemigo. Es una actitud provocada por el convencimiento que surge desde dentro de que no hay otra opción. Debemos asumir (cuanto antes mejor) el cambio como algo que está ahi, nos guste o no, no podemos evitarlo. ¡¡Todo cambia!!

En las metodologías “predictivas” se destinan gran parte de los recursos a ser capaz de predecir lo que se va a desarrollar en los próximos años. Por muy concienzudo que sea dicho estudio, el contexto varía, las necesidades del cliente cambian, surgen nuevas oportunidades y riesgos. El que mayor capacidad de cambio demuestre, contará con una ventaja competitiva significativa.
Por lo tanto, permitir que nuestro cliente marque el siguiente paso (o mejor dicho, pasito) a dar nos permite ajustar el camino a recorrer a las necesidades que sobre la marcha surgan, aportando un mayor valor al software y satisfacción al cliente, que es nuestro objetivo… ¿o no?


Publicado originalmente en Synergos

miércoles, 15 de abril de 2009

.NET Framework 4.0 y C# 4.0 (1 de 5)

Podemos incluir las nuevas caracteristicas que se incluyen en C# 4.0 en cuatro grupos principales:

  • Dynamic lookup
    Nos permite escribir métodos, operadores, acceso a propiedades y campos y cualquier invocación a objetos que se salte la comprobación estática de tipos de C# resolviendose en tiempo de ejecución. (¿esto es bueno o malo...? ya hablaremos, pero lo bueno es poder elegir, no? )

  • Parámetros con nombre y opcionales
    A partir de C# 4.0 los parámetros puedrán ser especificados como opcionales, asignandoles un valor por defecto en la declaración de miembro. Por supuesto, cuando el miembro sea invocado, los argumentos opcionales pueden ser omitidos. Los de VB.net que dejen de sacar pecho, porque además cualquier parámetro podrá ser pasado por nombre en lugar de posición. (nada de opcionales al final...)

  • Caracteristicas especificas de Interoperabilidad con COM
    La combinación de las dos mejoras comentadas anteriormente permiten hacer más cómoda la programación contra objetos COM. Además en el framework 4.0 se incluirán otras pequeñas características que mejorarán aún más esta "dura" experiencia.

  • Varianza y Contravarianza
    Quien haya profundizado en la O.O. usando genericos se dará cuanta de lo necesaria que era esta caracteristica. Ahora C# admite "co y contravariance" (por ejemplo Lista de objetos <-> Lista de string). Además los tipos de la B.C.L. son actualizados para que tengan en cuenta esta característica.

Continuaremos profundizando en posteriores posts.

martes, 7 de abril de 2009

.NET Framework 4.0 y C# 4.0 (0 de 5)

Visual Studio 2010 y el .NET Framework 4.0 estarán pronto en beta y con ellos se incluirán nuevas características. Una de ellas, es la nueva versión del lenguaje de programación C# (4.0, que se dice pronto!!). Para ponernos un poco en situación voy a escribir una serie de post en los cuales reflejar las evoluciones más significativas del mismo.

Para hacer las cosas como se deben vamos a hacer un poco de historia:

El equipo C# comienza en 1998 con el objetivo de crear un nuevo lenguaje de programación simple, moderno, orientado a objetos y type-safe (seguridad de tipos) para la plataforma .NET.

Microsoft lanza la plataforma .NET y el lenguaje de programación C# en verano de 2000 con gran éxito puesto que a día de hoy es uno de los más usados.

Uno de los principales éxitos de C# ha sido las buenas fuentes en las que se basa ( C++, Java...) así como el continuo y rápido proceso de evolución que la gente del equipo responsable de Microsoft le aplican.

Con la versión 2.0 del lenguaje se incluye el soporte para genericos, metodos anónimos, iteradores, tipos parciales y tipos nulables.

En la siguiente versión, la 3.0 el lenguaje se centra en habilitar LINQ para lo cual requiere todo lo anterior y una serie de nuevas características:
  • Variables locales de tipo implicito.
  • Métodos de extensión. (se emplea para implementar los proveedores de LINQ de manera debilmente acoplada)
  • Expresiones Lambda. (de esto ya hablaremos en otro post)
  • Inicializadores de objetos y colecciones.
  • Tipos anónimos.
  • Arrays implicitamente tipados.
  • Expresiones de consulta y árboles de expresiones.
Ahora que hemos conseguido un poco de prespectiva comenzaremos a hablar en el siguiente post de las novedades de C# 4.0.

Nota:
El nombre de C# es un guiño a modo siguiente evolución de C++. (C con 4 +)
C =>C++=>C++++

martes, 24 de marzo de 2009

Renombrar un objeto de una base de datos desde el Server Explorer del Visual Studio

Por si alguno no se ha dado cuenta, les comento un pequeño truco muy útil.

Desde la venta del Server Explorer del Visual Studio no se pueden renombrar directamente ciertos objetos de la base datos con la que se está trabajando. 
Por ejemplo, no se puede renombrar una tabla desde esta ventana.

Sin embargo podemos realizar esta tarea de manera muy sencilla a través de un Database Diagram.

Para ello si no tenemos ningún diagrama creamos uno nuevo y editamos las propiedades de los objetos desde la ventana de propiedades del Visual Studio.

Una vez terminadas las modificaciones,  guardamos el diagrama y actualizamos el listado de objetos de la base de datos y listo, los cambios se han realizado.

Espero que les sea de utilidad.

Un saludo.

lunes, 12 de enero de 2009

Incluir UserControl de Windows.Forms en WPF

Hola a todos y Feliz 2009!!



En ocasiones nos puede resultar interesante incluir un control de usuario que ya tenemos desarrollado y funcionando en nuestra aplicación WPF. esta y otras características de integración entre ambos mundo de UI permiten ir adentranos en el mundo de WPF poco a poco realizando las migraciones por pasos puesto que ambas conviven sin problemas.


Pasos para incluir UserControl de Windows.Forms en WPF:


  • Incluir las referencias a:

    -System.Windows.Forms.dll.
    -WindowsFormsIntegration.dll.

    Cae por (..Archivos de programa\Reference Assemblies\Microsoft\Framework\v3.0\)

  • Incluir la referencia al namespace desde el XAML.:

    Integración
    xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"

    Control de usuario
    xmlns:my="clr-namespace:WindowsFormsControlLibrary1;assembly=WFCLTest"

  • Por fin incluir el tag WindowsFormsHost necesario para poder embeber a los controles. Sin este control como wrapped recibiriamos un error de compilación, puesto que el control de usuario de WinForm no es un 'UIElement'




Es posible también, (lo veremos en otro post) inclur un control WPF en un formulario Windows.

Un saludo.