1. El formato: creo que XML es lo mejor. Me parece la mejor manera de intercambiar y leer/escribir datos. El caso es que tampoco veo que haya por ahí muchos lectores (a poder ser multiplataforma y software libre) de facturas electrónicas en XML.
2. El algoritmo de firma: por lo que he visto en Facturae hay algún generador en Java, etc… pero la verdad es que lo que me gustaría es escribir a mí el algoritmo en PHP o en el lenguaje que yo quiera (o sé si estoy diciendo una burrada).

En fin: ¿alguien que me pueda ayudar? ¿Qué experiencias tenéis con la facturación electrónica? ¿formatos? ¿algoritmos? ¿ideas varias?

¡Gracias adelantadas!

Esto ocurre porque la gestión de riesgos en metodologías como SCRUM no se hace explícitamente, se hace de manera integrada en el propio proceso y, por lo tanto, de manera continua.

Quizá, la parte más explícita de la gestión de riesgos sea el Impediment Backlog. Un Impediment Backlog es una lista de incidencias que tienen que ser resueltas por el equipo y que el Scrum Master debe gestionar y asignar al alguien para que trabaje en ellas, y que será revisada en la reunión SCRUM diaria, tras la pregunta: ¿Qué está bloqueando el progreso del proyecto?

Creo que no vale la pena que explique nada más aquí porque, curiosamente, he encontrado el mejor artículo sobre el tema en castellano. Se trata de un análisis exhaustivo sobre los riesgos clásicos del desarrollo de software y cómo los afronta SCRUM. Contentísimo de que la blogosfera de habla hispana de artículos de ésta calidad, oiga.

• ¿Quién utilizó, qué tecnología, cuándo?
• ¿Quién ha desarrollado qué producto y, por tanto, conoce su Lógica de Negocio?
• ¿Qué pasa si el programador X se marcha de la empresa? ¿se lleva todo su conocimiento? ¿Quién más lo tiene?
• ¿Todo el mundo debe tener los mismos conocimientos? ¿Tenemos diferentes perfiles?
• ¿Cuál va a ser la estrategia para que un recien salido de la facultad llegue a tener los mismos conocimiento que un Senior de su perfil?

Lo más triste es que pienso que la mayoría de estas cosas se podrían solucionar teniendo a una persona que se encargara de pensar un poco en ello. No sé si el problema es que la existencia o no de esa persona depende exclusivamente de que alguien, de manera proactiva, decida dedicarle algo de tiempo, o que algunas empresas tienen en la dirección cabezas que sólo piensan de manera financiera (beneficios = presupuesto – (coste del programador * número de programadores))…

Dejó aquí un artículo interesante y las técnicas básicas que propone:

• Pair Programming: ayuda a revisar el código, tomar decisiones de diseño, y trasvasar conocimiento entre programadores.
  Wiki: es una manera ágil y rápida de compartir documentación, modificarla, y mantenerla totalmente actualizada (sabiendo quién hizo qué cambios).
  Coding Standards Document: si todo el mundo escribe código igual, el mantenimiento es mucho más sencillo y evita que un código solo sea mantenible por quien lo programó.
  Mailing List: o montarte “un twitter” para el proyecto (con Prologue o con lo que sea) ayuda a preguntar y responder dudas sobre el proyecto rápidamente.
  Hacer saber a la gente que has arreglado un problema: esto se refiere a que una persona pueda entra en el código programado por otra y modificarlo para solucionar un problema, comentádoselo luego a los demás, y depende de la manera en que gestiones el código.

Además, describe cómo ir adoptando las prácticas ágiles de manera paulatina, en forma de iteraciones. Una lectura realmente interesante para todos aquellos que pretendemos ir introduciendo las prácticas ágiles en nuestro proceso de desarrollo.

Además, en la parte final de libro, agrupa las prácticas ágiles por Technical Clusters, esto es, conjuntos de prácticas analizadas en los capítulos anteriores.

Lectura fácil y clarificadora. ¡ya os la estáis bajando!

class GreaterThan {
	private $limit;
	public function __construct($limit) { $this->limit = $limit; }
	public function __invoke($number) { return $number > $this->limit; }
}
function filterGreaterThan($array, $limit) {
	$array = array_filter($array, new GreaterThan($limit));
}

Como vemos, GreatherThan es una clase con un método __invoke que array_filter utilizará para elegir aquellos miembros del array que sean mayores que $limit. Me ha parecido una solución útil e interesante.

Una de las claves a la hora de poner manejar cómodamente las user stories, elegir en qué iteración desarrollarlas y poder estimar cuanto tiempo tardaremos o si estamos cumpliendo el plan previsto, es hacer que sean del mismo tamaño (o, al menos, de un tamaño similar). Esto no siempre será posible, pero hay que intentar dividir una user story en varias, o juntarlas, para conseguir la mayor homogeneidad posible.

Para poder estimar el tiempo que nos llevará una user story, tenemos varias técnicas:

• por analogía: “si un item me costó 3 horas, y éste es del mismo tamaño, éste también me costará 3 horas.” Cuidado con ésta manera de estimar porque si te equivocas en tu primera estimación, propagarás el error al resto de estimaciones…
• descomposición: si no soy capaz de estimar cuanto me costará un story point, quizá pueda subdividirlo en una serie de story points más fáciles de estimar. Nunca llevar esto demasiado lejos, podemos perder mucho tiempo descomponiendo más y más y más…
• WideBand Delphi: para cuestiones realmente difíciles de estimar. Se trata de un proces en el que se implica a varios programadores y se busca el consens a base de rondas iterativas. Para ver exactamente cómo se haría: aquí.
• … y juegos típicos de SCRUM como el Planning Poker.

Una vez que tengamos nuestra estimación para los items más prioritarios, podremos ver cuantas horas y cuantos programadores serán necesarios para llevar a uen puerto la iteración en el tiempo estimado. Ésta es nuestra primera métrica: Iteration velocity, esto es, el número de horas (o de story points) resultos multiplicado por el número de programadores que participarán.

Si la Iteration Velocity de cierta iteración que va a durar tres semanas se ha planificado en 45 user stories, y pasada una semana sólo se han resuleto 3 user stories, se puede ver claramente que el equipo se está retrasando. Esto se suele representar mediante un gráfico BurnDown.

Diariamente el programador introducirá las horas reales que le están suponiendo los story points. Las horas reales, son una métrica muy evidente. Si estamos por debajo de lo estimado, habrá que añadir story points a la iteración, y si estamos por encima, habrá que ver por qué, y en caso de no haber remedio, disminuir el número de story points de la iteración para poder llevarla a buen puerto.

Si la iteración va mal, y no nos va a dar tiempo a completarla como lo planificamos habrá que ver por qué. A eso nos ayudarán un par de métricas:

• unplanned items: esto es, el número de items que hemos descubierto que había que hacer para poder realizar las funcionalidades desarrolladas. Esto puede darse por varios motivos. El primero es no haber detectado una dependencia (para poder hacer el item x, debería hacer primero el Y), y el segundo es un mala fase de análisis y diseño, que nos haga ahora descubrir cosas sobre nuetro software que ya deberíamos saber.
• defects: si el mismo equipo que se dedica al desarrollo se dedica a la solución de defectos encontrados en las iteraciones anteriores, y el número de defectos encontrados es alto, puede ser que nuestro equipo se esté dedicando a solucionar defectos en vez de desarrollar nuevas funcionalidades, y que esto lo esté retrasando.

Y, por último, dejo aquí un interesante artículo sobre preguntas que podemos hacernos a la hora de controlar el desarrollo de un proyecto, y cómo obtener las respuestas en un entorno SCRUM.

Twitter una sencilla red social donde se pueden escribir mensajes de 140 caracteres, la gente puede seguirte y tu puedes seguir a gente. La formas de comunicarte son:

1. publicar esos mensajes en tu status que verán todos tus seguidores
2. escribir mensajes directos a una persona en concreto
3. mensajes @, que son aquellos que se publican en tu status pero que contestan a un tweet concreto de otro usuario.
4. Que un seguidor haga un “retweet” de un mensaje publicado por tí, de tal manera que no sólo lo vean tus seguidores, sino sus seguidores también.

Además, Twitter permite potentes búsquedas entre lo que la gente está twitteando, que además te permiten descubrir nueva gente interesante y suscribirte a ella. La gente que más exito está teniendo en Twitter, es aquella que está publicando contenido interesante.

Además, Twitter tiene una API que permite postear automáticamente contenido que venga de una aplicación que estés programando o de una fuente RSS por ejemplo. Así que si tienes un blog, puedes ganar en seguidores (y en tráfico) vinculando tu cuenta twitter a tu blog. También se puede utilizar el API para publicar incidencias en un servidor, por ejemplo, y que la gente relacionada con ese servidor pueda seguirlo (las aplicaciones del API de Twitter son infinitas).

Pese a que se habla de Twitter como el SMS-Killer (el día que todos los móviles tengan 3G, twitter te permitirá comunicarte de forma sencilla en mensajes cortos ), Twitter a día de hoy todavía es usado por gente bastante tekki (aunque esto va cambiando poco a poco). El tipo de audiencia que tendremos, comparando con Facebook, es una audiencia más tecnológica.

En definitiva, integrar una web o blog con Twitter es tan sencillo y el potencial aumento de tráfico puede ser tan grande que vale la pena hacerlo…

Presentación sobre seguridad en Zend Framework [PDF]

Artículo original: devzone.