La prima de riesgo de un país, es la diferencia del tipo de interés que se paga por prestarle dinero a un estado en comparación con el país referencia que tendrá el tipo de interés más bajo dentro de la Comunidad Europea, o sea, Alemania.

El dinero que presta el estado, se hace mediante subasta. Habréis oido hablar de Letras y Bonos del Tesoro. Pues es esto. Todo el mundo tiene acceso a invertir en estas subastas. Podéis hacerlo incluso por internet en www.tesoro.es (para España).

Entonces, los inversores, cuando prestan su dinero a Alemania, por ejemplo, saben que van a tener poca rentabilidad (ahora un 2,17%) a cambio de que se fían de que Alemania les van a devolver el dinero sin problemas.

En cambio, si se fían menos de otro Estado de otro país, por ejemplo España, exigen que les pague más intereses, si no, no estás dispuestos a arriesgar su dinero. A España se le exige casi un 5,73% para el mismo tipo de inversión: bono a 10 años.

La diferencia del tipo de interés que te da el bono español (5,73%) y el alemán (2,17%) nos da la prima de riesgo: (573-217=357). Los puntos es la unidad mínima en que puede variar el tipo de interés, o sea 0,01%, por eso se miden como 357 puntos, y no 3,57.

Scrum es un proceso ágil que nos permite centrarnos en ofrecer el mayor valor de negocio en el menor tiempo.

Scrum es…

• Simple y minimalista
• Un marco de trabajo para la gestión de proyectos
• Soporta los valores y principios en el Manifiesto Agile
• Un planteamiento eficaz para gestionar la complejidad y el cambio
• Capacidad de adaptación para requisitos cambiantes o poco claros
• “Agile” en la naturaleza y la práctica
• Basado en el sentido común (pragmático)
• Menos documentación (”pocos y valiosos”)
• Liberar el producto pronto y a menudo (maximizar el ROI)
• Evita el caos, balanceando entre adaptación y la anticipación
• Promueve la comunicación frecuente y eficaz de los equipos
• Orientado al compromiso, la confianza y la responsabilidad
• Alienta a la difusión de conocimientos, la comprensión y la innovación
• Visibilidad diaria de los progresos y los obstáculos
• Un cambio de paradigma

¿Por qué usar Scrum?

• Aumento de la productividad
  • Según Rico (2008) con Scrum se aumenta la productividad entre un 14% y un 384% (88% de media).
  • Según Mah (2008) los proyectos Agile son un 16% más productivos.
• Reducción de coste
  • Según Rico (2008) la redución del coste fue desde el 10% al 70% (26% de media), gracias a reducir el re-trabajo.
• Aumenta el nivel de compromiso y la satisfación del empleado
• Reducción de las fechas de salida al mercado
  • Según Mah (2008) los productos de proyectos Agile salen un 37% antes que la media industrial.
• Aumenta el nivel de satisfacción de los interesados (clientes)
• Mayor calidad y mejora continua.

Resumen

• Scrum es un proceso ágil que nos permite centrarnos en ofrecer el mayor valor de negocio en el menor tiempo.
• Scrum nos permite rápida y repetidamente inspeccionar el software en el que se está trabajando actualmente (cada 1-4 semanas)
• El negocio fija las prioridades. Los equipos se auto-organizan para determinar la mejor manera de desarrollar las funcionalidades con más prioridad.
• En intervalos regulares (de 1 semana a 1 mes), cualquiera puede ver el software en el que se está trabajando y decidir entregarlo como está  o continuar para mejorarlo en el siguiente Sprint.

Valores Scrum

• Compromiso
• Foco
• Abierto
• Respeto
• Coraje

Esquema de Scrum

Los elementos

Pila de Producto (Product Backlog)

La pila de producto es el corazón de Scrum. Es donde empieza todo. La pila de producto es, básicamente, una lista priorizada de requisitos, o historias, o funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas usando la terminología del cliente. Llamamos a esto historias, o a veces simplemente elementos de la Pila.

Es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto.

Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en la pila de producto.

A diferencia de un documento de requisitos del sistema, la pila de producto nunca se da por completo; está en continuo crecimiento y evolución.

Para comenzar el desarrollo se necesita una visión de los objetivos que se quieren conseguir con el producto, comprendida y conocida por todo el equipo, y elementos suficientes en la pila de producto para llevar a cabo el primer sprint.

Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:

• Identificador único de la funcionalidad o trabajo.
• Descripción de la funcionalidad.
• Prioridad.
• Estimación.

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:

• Observaciones
• Criterio de validación
• Persona asignada
• Número de sprint o iteración en el que se realiza
• Módulo del sistema al que pertenece
• Etc.

Sprint (Iteración)

Cada iteración se programa mediante un intervalo de tiempo fijo para realizar una parte del producto (el intervalo) con garantías para que no haya distracciones al equipo de desarrollo y por otra parte que permita flexibilidad para adaptarse a cambios en los requisitos. Es lo que se llama “Sprint”.

El objetivo de un sprint debe ser entregar una parte del producto con ciertas funcionalidades que el cliente puede probar. De esta manera se implica al cliente en el desarrollo del producto, pudiendo este comprobar que lo que se está haciendo es lo que ha pedido además de comprender las dificultades que va teniendo el equipo a lo largo de la vida del proyecto.

Los sprints cortos les gustan a los clientes, porque pueden ir probando funcionalidades que se van acabando y dar su opinión al respecto.

Los sprints largos le gustan al equipo de desarrollo, pues así tiene más autonomía y menos cambios.

Se toma una duración compromiso entre el cliente y el equipo de desarrollo de tal manera que se consiga un equilibrio entre el trabajo realizado y la adaptabilidad al cambio. Suele ser entre 2 y 6 semanas.

Manteniendo la misma duración conseguimos un latido corporativo al que todo el mundo se acostumbra confortablemente.

Pila del Sprint (Sprint Backlog)

La pila del Sprint es la lista de tareas que se van a realizar en una iteración. Es la especificación de los requisitos de software necesarios para dar respuesta a las funcionalidades esperadas por el cliente.

Es la lista que descompone las funcionalidades de la pila de producto en las tareas necesarias para construir un incremento: una parte completa y operativa del producto.

En la pila del sprint se asigna a cada tarea la persona que la va a llevar a cabo, y se indica el tiempo de trabajo que se estima, aún falta para terminarla.

Es útil porque descompone el proyecto en tareas de tamaño adecuado para determinar el avance a diario; e identificar riesgos y problemas sin necesidad de procesos complejos de gestión.

El Incremento

El incremento es la parte de producto producida en una iteración, y tiene como característica que está completamente terminada y operativa: en condiciones de ser entregada al cliente final.

El incremento debe estar terminado y probado. Si el proyecto o el sistema requiere documentación, o procesos de validación y verificación documentados, o con niveles de independencia que implican procesos con terceros, éstos también tienen que estar realizados para considerar que el producto está “terminado”.

Las reuniones

La planificación de la Iteración

La planificación de la iteración es una reunión crítica, probablemente la más importante de Scrum.

Una planificación mal ejecutada puede arruinar por completo toda la iteración.

El propósito de la planificación de la iteración es proporcionar al equipo suficiente información como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas, y para ofrecer al dueño de Producto suficiente confianza como para permitírselo.

En esta reunión, tomando como base las prioridades y necesidades de negocio del cliente, se determinan cuáles y cómo van a ser las funcionalidades que se van a incorporar al producto con la próximo iteración.

En realidad esta reunión consiste en dos: En la primera, que puede tener una duración de una a cuatro horas, se decide qué elementos de la pila de producto se van a desarrollar. En la segunda se desglosan éstos para determinar las tareas necesarias, estimar el esfuerzo que necesita cada una y asignarlas a las personas del equipo.

La planificación de la iteración no debe durar más de un día.

Seguimiento de la Iteración (Daily Scrum)

Es una breve reunión diaria para dar repaso al avance de cada tarea, y al trabajo previsto para la jornada. Cada miembro del equipo responde a las siguientes preguntas:

1. Trabajo realizado desde la reunión anterior
2. Trabajo que se va a realizar hasta la próxima reunión
3. Impedimentos que se deben solventar para que pueda realizar el trabajo.

Revisión de la Iteración

Permite realizar el análisis y revisión del incremento generado. Esta reunión no debe tomarse como un “acontecimiento especial”, sino como la presentación normal de los resultados.

Los roles

Se destacan tres roles imporantes:

El dueño del producto (Product owner)

En el proyecto hay una persona, y sólo una, conocedora del entorno de negocio del cliente y de la visión del producto. Representa a todos los interesados en el producto final y es el responsable de la pila de producto.

El equipo

Todo el equipo de desarrollo, incluido el propietario del producto conoce la metodología Scrum, y son los auténticos responsables del resultado.

Es un equipo multidisciplinar que cubre todas las habilidades necesarias para generar el resultado.

Se auto-gestiona y auto-organiza, y dispone de atribuciones suficientes en la organización para tomar decisiones sobre cómo realizar su trabajo.

Scrum Master

En él recae la responsabilidad de funcionamiento del modelo.

La organización debe garantizar el funcionamiento de los procesos y metodologías que emplea, y en este aspecto Scrum no es una excepción.

Gráfica Burndown

Gráfica Burndown

Es una herramienta de seguimiento para el equipo, que muestra el avance del sprint día a día y revela de forma temprana posibles desviaciones.

Es un gráfico cartesiano que representa en el eje de abscisas los días laborables del sprint, y en el de coordenadas, la cantidad de esfuerzo estimada. Ver figura 4.

Primero, se traza una recta punteada que parte desde el día 1 del sprint con la cantidad de esfuerzo de todas las tareas estimadas y planificadas para es sprint y llega hasta el última día del sprint con una cantidad de esfuerzo 0. Esta línea es la evolución ideal del estado del proyecto.

Después, en la reunión diaria cada miembro del equipo al referirse al trabajo que realizó ayer, y el que tiene previsto hacer hoy, actualiza en la pila del sprint: si ha terminado alguna de las tareas en las que ha trabajado, o actualiza cuánto esfuerzo estima que le queda en cada una de las tareas que tiene asignadas. Se va trazando día a día la línea del estado del proyecto, según esta información.

De esta forma al final de la reunión la columna del día del sprint, muestra el esfuerzo que según el equipo falta para terminar sus tareas, y el equipo marca en el gráfico el punto que tiene como ordenada ese valor, y como abscisa la fecha del día.

Si la línea de estado del proyecto diverge de la ideal hacia encima, quiere decir que hay problemas y habrá tareas de la pila del sprint que no se podrán realizar. Sin embargo, si la línea diverge de la ideal hacia abajo, quiere decir que el equipo es capaz de desarrollar más trabajo y si no se aumenta la pila del sprint, se quedarán sin trabajo.

DSDM

Es la metodología más veterana de las auto-denominadas ágiles. Surgió en 1994 de los trabajos de Jennifer Stapleton, la actual directora del DSDM Consortium.

DSDM es la metodología ágil más próxima a los métodos formales; de hecho la implantación de un modelo DSDM en una organización le permite alcanzar lo que CMM consideraría un nivel 2 de madurez. Sin embargo los aspectos que DSDM reprocha a CMM son:

• Aunque es cierto que se ha desarrollado con éxito en algunas organizaciones, lo que funciona bien en unos entornos no tiene por qué servir para todos.
• CMM no le da al diseño la importancia que debería tener.
• CMM plantea un foco excesivo en los procesos, olvidando la importancia que en nuestra industria tiene el talento de las personas.
• El tener procesos claramente definidos no es sinónimo de tener buenos procesos.

Extreme Programming (XP)

Ó programación extrema. Es la metodología ágil más popular, y posiblemente también la más transgresora de la ortodoxia basada en procesos. Su creador fue Kent Beck, impulsor del Manifiesto Ágil.

Extreme Programming (XP) se yergue sobre la suposición de que es posible obtener software de gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asunción es que con un poco de planificación, un poco de codificación y unas pocas pruebas, se puede decidir si se está siguiendo un camino acertado o equivocado, evitando tener que echar marcha atrás demasiado tarde.

Prácticas destacables de este modelo son:

Programación en parejas ó “Pair Programming”: para desarrollos complejos este modelo aconseja que dos desarrolladores se sienten juntos y programen conjuntamente. Cuando dos personas trabajan en lo mismo, se discuten ideas, se corrigen errores y como resultado se obtiene un código más robusto y elegante, con lo que conlleva un aumento de productividad.

Desarrollo Orientado a Pruebas ó “Test Driven Development (TDD)” o: Se trata de programar antes la prueba que la funcionalidad en sí. Con esto, el desarrollador realiza el código de manera que no va a fallar, aumentando la calidad de lo entregado.

Integración continua: cada vez que se realice un cambio hay generar una versión que se pueda probar o incluso entregar. Si hay algo mal, la integración fallará y se podrá corregir al momento.

Scrum

Aunque surgió como modelo en el desarrollo de productos tecnológicos, sus principios son válidos para entornos que trabajan con requisitos inestables, y necesitan agilidad: situaciones frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplicó los principios de los campos de Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 presentó junto con Ken Schwaber, las prácticas que empleaba como válidas para gestionar el desarrollo de software OOPSLA 96 (Schwaber & Sutherland, 1996).

Otros modelos o prácticas ágiles

Además de las mencionadas, destacan otras como:

• Crystal: Adaptative Software Development (ASD) ó Desarrollo de Software Adaptativo.
• Pragmatic Programming (PP) ó Programación pragmatica.
• Agile Modeling (AM) ó Modelado Ágil.
• Feature Driven Development (FDD) ó Desarrollo Orientado a Funcionalidad.
• Etc.

Estas metodologías ágiles no deben considerarse como modelos de procesos completos. Cada metodología ágil surge de la difusión de una o unas “buenas prácticas” diseñada y utilizada con éxito por su autor, y contrastado éste también por los equipos que la van incorporando.

Por eso, en cada caso, son conjuntos de prácticas focalizadas sobre un área de conocimiento, más o menos delimitado, de la Ingeniería del Software. Las prácticas de Agile Modeling cubren básicamente tareas técnicas de diseño, las de Scrum diseñadas por Sutherland y Schwaber se centran en la gestión del desarrollo, Extreme Programming cubre las actividades que desde el plano completo de la ISO 12207 pertenecería al desarrollo, etc.

Por esta razón es frecuente combinar varias de estas prácticas (ej. XP + Scrum + FDD) para dar cobertura ágil a un ámbito más amplio del ciclo de vida.

• Utilice aceite de oliva
• Manténgase hidratado bebiendo agua abundante
• Evite largos períodos en ayunas… haga 5 o 6 comidas diarias
• Consuma 2 ó 3 piezas de fruta al día
• Consuma  legumbres habitualmente
• Consuma pescado regularmente
• Elija carnes blancas en lugar de rojas
• Consuma cereales integrales
• Modere el consumo de sal
• Reduzca el consumo de azúcar y dulces
• Modere el consumo de bebidas alcohólicas o estimulantes
• Huya de alimentos con grasas añadidas (bollería, alimentos precocinados, etc)

Errores más comunes en la dieta:

• No desayunar
• Desayunar poco y desequilibrado
• Sustitución de comidas por “snacks”
• Exceso de de azúcares y productos azucarados
• Abuso de alimentos fritos y salados
• Saltarse alguna comida
• Consumo regular de refrescos
• Intervalo entre comidas de más de 3 horas y media
• Cenar demasiado

Después de estar en Madrid, por fin me he dado cuenta por qué era esto.

Un buen paso de cebra:

Paso de cebra correcto

Desde lejos, ya podemos ver a un peatón esperando en el paso de cebra

Si nos acercamos más:

Acercandome a un paso de cebra correcto

Me quedan 10 metros y se perfectamente que debo dejar pasar al peatón.

Detalle

Como vemos, el paso de cebra empieza delante de los coches aparcados.

Además, está señalizado a cada lado.

El peatón es plénamente visible a 10 metros. Paramos para que pase.

El peatón pasa

Ahora veamos ejemplos de pasos de cebra faltamente hechos o diseñados:

Paso de cebra malo

Increíble, ¿no es cierto? Todo está mal:

Paso de cebra malo (detalle)

1. Nos plantan unos buenos contenedores delante del paso de cebra.

2. No hay más señales indicando el paso de cebra.

3. La acera no está adelantada para el que el paso empiece por delante de los contenedores.

Conclusión: parece que han hecho el paso de cebra adrede para atropellar gente y llevarlos al Centro de Salud de enfrente.

Más ejemplos:

Paso de cebra malo

Lo permitir aparcar en esquinas debería estar penado por ley.

Paso de cebra malo

Ahí detrás hay un paso de cebra.

Paso de cebra malo

El stándar del modelo ORM dice que las tablas se mapean a clases, las filas a objetos y las columnas a atributos de los objetos.
Cuando heredamos de la clase ActiveRecord::Base estamos diciendo a la clase que mapea una tabla.

Por defecto Rails asume que el nombre de la tabla es el plural del nombre de la clase y en minúsculas, y si la clase tiene mayúsculas en la palabra, el nombre de la tabla tendrá guiones bajos (”_”).

Order => orders
TaxAgency => tax_agencies
Person => people

Si no queremos seguir estas reglas, podemos indicar el nombre de la tabla con la que trabajará la clase:

class Ship < ActiveRecord::Base
set_table_name “ship_09″
end

Sin tener que definir los atributos explícitamente, se pueden usar. Se usarán los definidos para esa tabla en la base de datos (ficheros Migration).

o = Order.find(1)
puts o.name                     # imprimiría el campo “name” de la tabla “orders”
o.name = “Miguel”          # cambiaría el campo “name” de la tabla “orders” con el nuevo valor

Para que tuviese efecto el cambio del atributo name en la tabla habría que llamar al método “save“.

Claves primarias

Por defecto, una migración de Rails añade una columna con nombre “id” y tipo entero a tu tabla y que es la clave primaria. Pero si tú tienes un campo que será clave primaria, puedes indicarlo:

class Order < ActiveRecord::Base
self.primary_key = “number”
end

Aunque cambies el campo de la clave primaria, el campo “id” siempre indicará la clave primaria. Entonce, en nuestro caso “id” y “number” es lo mismo.

Lo aconsejable es usar un código interno para la clave primaria y no una referencia externa, ya que estas pueden cambiar.

Rails no trabaja con claves primarias compuestas, aunque existen plug-ins que lo facilitan.

Crear, Leer, Actualizar, Borrar (en inglés CRUD)

Crear

Cuando se crean objetos, se crean filas en la tabla asociada a la clase. Con el método “new” se crea el objeto, pero hasta que no se hace “save” no se guarda en la base de datos.

Existe otro método, “create” para crear el objeto y guardarlo en la base de datos directamente.

an_order = Order.create(
:name => “Pepe”
:address => “Calle ancha 1″
:payment => “card”)

Leer

Toda clase modelo tiene el método “find“. Este método puede retornar RecordNotFound si no encuentra ningún objeto, un objeto o una lista de objetos si encuentra uno o varios objetos que cumplan las condiciones de find.

Se le puede decir al método find que busque el primero (:first) o todos los objetos (:all), pasando estos símbolos como argumentos al método. En Rails 3 directamente existen los métodos “first” y “all” para hacer esto.

SQL y ActiveRecord

Para meter código SQL podemos utilizar el parámetros “:conditions“:

pos = Feature.find(:all, :conditions => “name = ‘New GUI’ and priority=’High’”)

Y si queremos meter variables en el parámetro “:conditios” debemos usar una forma que el ActiveRecord nos facilita para que no exista posibilidad de un ataque de inyección SQL, pasándole una lista, donde el primer elemento contiene el formato de la sentencia SQL indicando las posiciones donde irán las variables, y el resto de elementos las variables:

pos = Feature.find(:all, :conditions => ["name = ? and priority= ?", name, priority])

ó

pos = Feature.find(:all, :conditions => ["name = :name and priority= :priority", {:priority => priority, :name => name}])

Para el uso de “like“:

pos = Feature.find(:all, :conditions => ["name like ?", params[:name]+”%”])

Si queremos que aparezca el resultado en un orden específico debemos indicarlo con el parámetro” rder“.

Si queremos limitar el número de filas de la consulta, lo haremos con el parámetro “:limit“.

pos = Feature.find(:all, :conditions => ["name = 'New GUI'",
rder => "priority",
:limit => 10)

Para seguir viendo resultados que han sido limitados con el parámetro ":limit" se usa el parámetro " ffset" que indica a partir de que posición se desea el resultado.

Cuando no queremos todos los campos sino sólo algunos, utilizamos el parámetro ":select".

El parámetro ":group" añade la sentencia SQL "group by":

pos = Feature.find(:all, :select =>"sku, sum(pages) as num",
:group => "sku")

...

[artículo sin terminar]

El pasado 20 de septiembre se presentó en Nueva York, entre otras novedades de HP, la nueva impresora Designjet T2300 eMFP. La nueva impresora multifuncional conectada a la Web de gran formato.

Esta impresora está dirigida a un público técnico. Los clientes son arquitectos, ingenieros, diseñadores, etc.

Las novedades con las que cuenta esta impresora son:

- pantálla táctil y color, que permite un uso mucho más sencillo, previsulización, etc.

- USB para leer directamente pendrives

- Scanner incorporado, con lo que podremos escanear y copiar.

- Conexión a la Web, con la que podremos enviar y recibir nuestros documentos hacia o desde la Web.

Por lo tanto, por ejemplo, una empresa de arquitectura que tiene su sede en Inglaterra, los ingenieros de estructura en Alemania, y la obra en Singapur, pueden compartir los planos simultanemamente gracias a esta impresora, ya que se pueden hacer anotaciones sobre un plano, escanearlo, enviarlo a otro lugar y allí volver a imprimirlo con las correccines realizadas por sus colegas del otro lado del mundo.

En definitiva, una nueva manera de trabajar.

Nueva Impresora técnica multifuncional de HP

En principio, un sitio idílico para vivir, pero el afán de enriquecer las arcas ciega a los necios.

Los suelos se vendieron muy caros, y lo más asombroso: ni una sola promoción de vivienda protegida. ¿esto es legal? ¿por qué la Junta ó Europa (ya no incluyo al Gobierno, K.O. hace mucho) lo permite?

Bueno, siguiendo para alante, llega la crisis… parón urbanísitco. Muchas constructoras involucradas no inician la construcción, a otras le cuesta un montón vender, porque no quieren comprometer su margen de ganancia. Eso no me importa, si antes han ganado mucho margen, que hubiern ahorrado un poco para ahora poder aguantar las pérdidas. La solución es vender más barato, que por un año que pierdan, no pasa nada, casi todas las empresas tienen pérdidas en los comienzos y en los tiempos de crisis, una empresa no se hace en función de unos resultados de un año. La culpa de que no se vendan los pisos, en parte es porque no rebajan el precio… ¡más pierden!

Pero bueno, sigamos, además del dinero, ¿por qué la gente no se anima? Cuando preguntas a la gente sobre La Lastra, dicen… “buf, está muy lejos”, “allí no hay nada”, etc. Casi todo rebatible. ¿lejos? ¿está más cerca Eras? ¿y la zona del Espacio León?… ¡no!. Medir con un plano tomando el centro la plaza de Santo Domingo y lo veréis.

¿Vive poca gente? más o menos. No hay muchos edificios habitados, por lo menos en mayoría, pero en cifras sí es bastante gente. El problema es que al ser un barrio muy grande, los edificios están dispersos, y hay una sensación desocupación. ¿no hay nada?, bueno, no mucho, pero es que teniendo en cuenta que andando se puede ir al Carrefour, Mercadona, Árbol, carnecerías, el Corte Inglés,  etc., todavía hay que esperar a que haya más densidad de población para que un empresario se lance… el primero tendrá ventaja.

La sensación de abandono de este magnífico barrio viene dada por culpa del Ayuntamiento… sí. ¿por qué? Mayormente por dos razones:

La primera, ya mencionada antes. No hizo ninguna promoción pública, las cuales se venden antes, y con un mínimo de par de edificios que hubiera de estas características, ya habría 100 vecinos fijos, más o menos 250 habitantes. Esto ayudaría a atraer a más gente que ve ahora deshabitado el barrio.

La segunda, porque tiene abandonado el barrio: no mantiene los jardines, que tanto anunciaron a bombo y platillo. Las pruebas:

Malas hierbas y basura detrás del INTECO

Bosque detras del INTECO

Malas hierbas en el centro de LA LASTRA

Crecen las hierbas en el empedrado

Estan para un premio

bosque o selva

Selva de LA LASTRA

Que clase de animales habra ahi

Alguno se puede quedar atrapado al salir del coche

La unica planta que se riega en LA LASTRA

Basura y mas hierbas

¿Dónde están los impuestos de los pobres vecinos de La Lastra? ¿ó acaso no pagan?

Y para rematar, gracias al corte a los turismos de un pequeño tramo de la calle Fernández Ladreda, todo el tráfico de una de las principales vias de León pasa por una pequeña calle de La Lastra, originando pequeños y grandes accidentes en el cruce de esta pequeña calle con la prolongación de José Aguado, cruce que no está dimensionado para este nuevo volumen de tráfico… ah que no lo habían pensado… pues cuando haya desgracias mayores, ¿sobre qué conciencias caerán?… ah que nuestros políticos no tienen de eso. Ya.

Objetivos:

• Esbozar valores y principios que permitan a los desarrolladores desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
• Ser alternativa a procesos de desarrollo tradicionales.

Se creó “The Agile Alliance”: organización sin ánimo de lucro dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos.

Principios del Manifiesto Ágil

1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.
2. Dar la bienvenida a los cambios. se capturan los cambios para que el cliente tenga una ventaja competitiva. 3.
3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.
4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.
7. El software que funciona es la medida principal de progreso.
8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
10. La simplicidad es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.
12. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según ésto ajusta su comportamiento.

Según el Manifiesto se valora:

• Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.
• Desarrollar software que funciona más que conseguir una buena documentación. La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.
• Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc) determina también éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Desarrollo tradicional vs Desarrollo ágil

Desarrollo tradicional:

• Inspirados en las ingenierías clásicas
• Predictivos y optimizables
• Orientados a:
  • La planificación
  • La documentación del proceso y el producto
• Todas las fases tienen elementos de proceso definidos
• Los equipos de desarrollo se comportan según las actividades del proceso

Desarrollo ágil:

• Procesos adaptativos
  • Pensados para contextos cambiantes (requisitos inestables, cambios tecnológicos, etc)
  • Basados en reglas generativas
  • Minimizar la documentación
• Asumen que:
  • Los requisitos cambian
  • Los planes cambian
  • El diseño es una actividad creativa
  • La construcción de sw (programación) es una actividad poco costosa
• Al ser orientados a personas:
• Es necesaria una alta participación y compromiso
  • Las personas participan en el proceso de decisión
  • Ciclos de vida iterativo o incremental iterativo

Hay seis etapas en el pipeline del núcleo SPARC:

1. Búsqueda – Etapa F
2. Selección de hilo – Etapa S
3. De-codificación - Etapa D
4. Ejecución – Etapa E
5. Memoria – Etapa M
6. Contestación – Etapa W

El acceso de la caché de Instrucción y el acceso ITLB tienen lugar en la etapa F. La selección del hilo (hardware) se realiza en la etapa S. La decodificación de la instrucción y el acceso a los registros suceden en la etapa D. La evaluación de la rama se hace en la etapa E. El acceso a memoria y la respuesta se realiza en las etapas M y W. La figura siguiente ilustra el pipeline y las estructuras involucradas.

Core Pipeline

La Cola de Llenado de Instrucción (IFQ) alimenta la caché de instrucción. La Lista de Instrucciones perdidas (MIL) guarda las direcciones que fallaron la caché de instrucción (I-Cache) y la ITLB,  y la MIL alimenta la Unidad de Almacén de Carga (LSU) para futuros procesamientos. El búfer de instrucción es de dos niveles de profundidad, e incluye la Unidad de Instrucción de Hilo (TIR) y la de Próxima Instrucción (NIR). La Selección del Hilo y el Planificador (etapa S) resuelve el arbitraje entre el TIR, el NIR, el PC de la rama, el PC de interrupciones para coger un hilo y mandarlo a la etapa de decodificación (D). La siguiente figura muestra la porción del pipeline del hilo:

2. Búsqueda de Instrucción

La Unidad de Búsqueda de Instrucción (IFU) mantiene los contadores de programa (PC) y los próximos contadores de programa (NPC) de todas las instrucciones vivas ejecutadas en el procesador. Por cada ciclo de reloj del núcleo, dos instrucciones son buscadas por cada instrucción usada. Esta relación de dos búsquedas por cada uso tiene la intención de reducir el acceso a la I-Cache para llenar la I-Cache de forma oportunista. A cada hilo le está permitido tener un fallo de I-Cache pendiente, y el núcleo SPARC permite un total de cuatro fallos de I-cache. Fallos duplicados de I-cache no inducen la carga redundante al nivel 2 de caché (L2-caché).

3. Registros de instrucción y registros de Contador de Programa

En el búfer de instrucción, hay dos registros de instrucción por hilo: el registro de instrucción del hilo (TIR) y el registro de próxima instrucción del hilo (NIR). El TIR contiene el la instrucción actual del hilo el la etapa de selección del hilo (etapa S), y el NIR contiene la siguiente instrucción. Un fallo en la carga de la I-cache, evita la I-cache y escribe directamente a la TIR, pero nunca escribe en la NIR.

El planificador de hilos selecciona una instrucción válida del TIR. Después de la selección de un instrucción válida, ésta será movida del NIR al TIR. Si no hay una instrucción válida en el TIR, una istrucción de No Operación (NOP) es insertada.

Hay un registro de contador de programa (PC) por hilo. El contador de próximo programa (NPC) puede venir de una de las siguientes fuentes:

1. Rama

2.  PC de interrupción

3. NPC de interrupción

4. Rollback (un hilo revertido debido a un fallo de carga)

5. PC + 4

La IFU rastrea  el PC y el NPC a través de la etapa W. El último PC retirado es guardado in la unidad lógica de interrupción (TLU), y si ocurre una interrupción, también sera guardada en la pila de la interrupción.

4. La caché de instrucción de nivel 1

La caché de instrucción es nombrada comunmente como caché de instrucción de nivel 1 (L1I).

[Artículo sin terminar]