Estoy convencido de que el marketing de hace una década, no sólo no funciona, sino que no es aconsejable para muchos proyectos TIC, por eso me ha encantado este vídeo de "The Orchestra of Ideas".

En los 80 se nos decía: "Cuanto antes empecéis a programar, más tarde terminaréis. ¿Cómo os ponéis a programar, sin analizar antes el problema, diseñar la solución y planificar el trabajo?. Empezáis sin tener ni una página de requisitos, ni un análisis y una planificación de los trabajos, y sus tiempos. ¿Os imagináis que un arquitecto hiciera lo mismo?".

Aprendimos a hacer requisitos del sistema, especificaciones de requitisos del software, planes de proyecto, gestión de riesgos, matrices de trazabilidad. Y desde entonces nuestros clientes no pueden darnos planes de productos estables y nos piden re-inventar sus productos de forma continua.

Scrum Manager da una visión de scrum amplia y flexible, la original de Nonaka y Takeuchi, que es diferente a la implantación concreta de la Scrum Alliance.

Scrum Manager y Scrum Alliance no son lo mismo. Las características de flexibilidad,  globalidad, y síntesis entre la agilidad y el conocimiento anterior (CMMI, 15504...) así como la difusión abierta, y condicionada a la calidad son aportaciones de Scrum Manager, o cuando menos, otra forma de interpretar los entornos de trabajo que Nonaka y Takeuchi llamaron "campos de scrum⁽¹⁾" hace 25 años, y de compartirlo y difundirlo.

Convencidos de que es un error monopolizar el concepto de campo de scrum. De que se encorseta y se empobrece al trocar los principios básicos⁽²⁾ por prácticas determinadas de sprints, backlogs y reuniones; y de que se podían aportar mejoras sustanciales a lo carísimo del modelo "comercial" de formación scrum, y al criticado certificado scrum master, Claudia y el que suscribre nos decidimos a no sólo hablar de alternativas, sino a construirlas.

Y como, "¿Cuál es la diferencia con Scrum Alliance?" o "¿Qué aporta?",  son preguntas frecuentes, cuando no críticas, :-( estas son, contadas con brevedad y objetividad, las razones de Scrum Manager:

1.- AREA DE MEJORA DETECTADA: El enfoque de Scrum en el área de gestión de proyectos está bien, pero un "campo de scrum" implica también al área de programación o desarrollo de producto y también a la gerencia y dirección de la organización. RESPUESTA: Scrum Manager contempla tres áreas de conocimiento: Proyecto, Producto y Gerencia.

2.- AREA DE MEJORA DETECTADA: El enfoque de la formación de Scrum Master sólo muestra las prácticas scurm de la Scrum Alliance. RESPUESTA: Scrum Manager presenta una síntesis de conocimiento entre procesos y agilidad: un enfoque objetivo mostrando la agilidad como antítesis de los procesos y las posibilidades que la síntesis de los dos conocimientos da a un gestor: como "criterios de gestión" en lugar de "recetas de actuación".

3.- AREA DE MEJORA DETECTADA: La formación de Scrum Alliance tiende a hacer olvidar el concepto original de campo de scrum y monopolizar scrum como las prácticas que ella misma define, empobreciendo las posibilidades de implementación de cada campo de scrum de la forma más adecuada a cada organización. RESPUESTA: Flexibilidad. Es un principio de Scrum Manager: adecuar las prácticas ágiles a la empresa, y no al revés.

4.- AREA DE MEJORA DETECTADA: Los certificados de la Scrum Alliance se obtienen sólo por pagar los 1.000€ o más que vale el curso de 2 días. Puede acudir una persona sin entender inglés a un curso scrum manager dictado en inglés, no entender nada y sin ningún examen ni comprobación lograr la certificación  Scrum Master. RESPUESTA: Un modelo enfocado en la formación, que permita incluso lo contrario: poder aprender y obtener un certificado acreditando que se sabe, de forma gratuita. (http://www.scrummanager.net/ok). Los certificados de Scrum Manager requieren un examen y actualmente un 20% de los presentados los suspenden y no obtienen la certificación.

5.- AREA DE MEJORA DETECTADA: Servicios profesionales presenciales (franquiciados) centrados en el negocio,que exigen una tasa de franquicia para dar formación, generando como consecuencias: a)encarecimiento de los costes normales de un curso presencial, b) formadores más centrados en el negocio que en los resultados de los alumnos. RESPUESTA: modelo partnership de Scrum Manager sin canon de entrada ni cuota de mantenimiento. Concesión otorgada y mantenida por la valoración de calidad de los cursos (http://scrummanager.net/qa). Consecuencia: los formadores tienen como principal interés ofrecer formación de calidad, (la valoración media de los cursos presenciales actualmente es > 8 ) y el modelo garantiza que un formador que no ofrece calidad no puede trabajar con Scrum Manager.

6.- MODELO DE CERTIFICACIÓN "PARCO": Me explico: con dos días de formación, (aun suponiendo que sea de calidad y con examen) ya se es "ágil certificado" (?), sin marcar ningua apreciación de grado. Un profesional puede, además de conocer el "scrum clásico" saber también de gestión de equipos, producto, recursos humanos, cultura ágil, o de prácticas de programación ágiles: integración continua, TDD, etc... Decir que una persona es Scrum Master, no es decir mucho de cuánto sabe de agilidad. RESPUESTA: Modelo de certificación con puntos de autoridad. La certificación Scrum Manager va vinculada a un grado de autoridad, que es proporcional a las áreas de conocimiento acreditadas.

He intentado sintetizar, y escribiendo un poco a vuela pluma. Seguro que me dejo cosas, pero creo que en conjunto este es el mapa general de razones y diferencias entre Scrum Alliance y Scrum Manager.

_{(1) "Moving the Scrum Downfield" - The New New Product Development Game. (Hirotaka Takeuchi and Ikujiro Nonaka. 1986)
(2) Built-in instability - Self-organizing project teams - Overlapping development phases - Multilearning - Subtle control - Organizational transfer or learnig.} 

Robert Johnson, director de software de Facebook, afirma que de los 7 principios clave que han hecho posible al equipo de programación dar respuesta al ritmo de crecimiento del proyecto, 5 tienen que ver con las personas y su cultura de trabajo en equipo.

Estos son los números de Facebook a fecha de hoy:

• 500 millones de usuarios activos.
• 100 mil millones de hits diarios.
• 50 mil millones de fotos.
•  2 trillones de objetos cacheados, con cientos de millones de peticiones por segundo.
• 130 TB de logs diarios.

Presentación de Kanban como una herramienta, para entornos ágiles: definición y explicación de un posible ejemplo de uso: kanban boxes.

 No hacedme mucho caso, cuando juzgo de paletos-digitales, sinvergüenzas y oportunistas a quienes quizá sean, como sin duda ellos mismos se deben considerar, "empresarios" o "emprendedores"

Seguramente no tengo un criterio objetivo por la rabieta de estar varios días tras el nombre del dominio para un proyecto nuevo, y encontrar que todos los tienen acaparados, a lo perro del hortelano, estos personajes cuyo fantástico proyecto consiste en exigir a otros proyectos 100, 1.000 o 100.000 veces el precio que hubieran pagado si no hubiera sido por su "valiosa" mediación para reservarlo y protegerlo de desaprensivos.

Me recuerda un poco a la mafia, pero lo dicho, no hacedme mucho caso, ya se me pasará esta rabieta tonta que me distorsiona el juicio sobre esta buena gente.

Nos gustan mucho los campos de scrum, y para aportar un modelo de formación asequible y una certificación que no se logre sólo por pagar, que pueda conseguirse incluso gratis, pero que realmente acredite el conocimiento, nos pusimos manos a la obra, ahora hace sólo un año: Primer Año de Scrum Manager .

 Gracias a todos por vuestro apoyo. :-)

Para los mejores vendedores, vendan lo que vendan, incluso consultoría, formación, coaching... lo importante no es ofrecer algo bueno, sino que lo percibamos como bueno.

Es la "Ley de la Percepción". La cuarta de las 22 leyes inmutables del marketing que afirma que los buenos vendedores no trabajan sobre lo que venden, sino sobre la percepción que de su producto transmiten a los clientes. ¡Qué peligro!

¿CMMI, Scrum, PMI o Prince2? ¿Estas práctias o aquellas? etc.  La cuestión es que no hay verdades absolutas, cada uno elaboramos la nuestra. Cuando pensamos que tenemos razón y que el otro está equivocado, lo que sentimos en el fondo es que nosotros percibimos (o creemos percibir) mejor la realidad.
La mayoría de las personas creemos ser más espabilados que los demás, que nuestras percepciones son más certeras que las de los vecinos. Realidad y percepción se funden en nuestra mente sin que nos demos cuenta ni nos preocupemos en diferenciar una de otra.

La realidad de la que estamos seguros y convencidos cada uno de nosotros es la que vamos formando por nuestra particular experiencia, nuestra interpretación y comprensión de lo que nos rodea. Y cuando alguien nos "vende" una solución, aunque se suponga que somos gestores, o profesionales, el mecanismo es el mismo que en cualquier mancia: Cuanto más inexperto se es y más necesitado de resultados se está, más fácil es creer.

Nota: subtítulos en español disponibles. Vía Ningunterra. 

Las 18 lecciones de liderazgo de Colin Powell son frecuentes en textos de gestión, management(?) o liderazgo. Dejando de lado consideraciones sobre "consejos-receta", si tuviera que elegir las tres que más me gustan, serían, por este orden, y con esta traducción:

1.- Lección 8: La Organización no es la que consigue los logros.  Los planes y las teorías de gestión no sirven de mucho. La gente es la que hace triunfar o fracasar a las empresas. La mayoría de los gerentes afirman que su mejor activo es su gente, pero en realidad ¿cuántos son los que se preocupan por crear ambientes que atraigan y retengan a los más capaces, creativos y productivos, donde se les permita dar rienda suelta a su creatividad e ingenio sin ataduras?. En la economía de hoy lo realmente importante, por encima de modas administrativas o teorías gerenciales es la gente que realiza los proyectos. Sólo los líderes que atraen a los mejores logran los mejores resultados.

2.- Lección 11: No busque los estereotipos. Deje de ir a la caza de las modas de gerencia. No exsiste el modelo o la filosofía administrativa para asegurar el bienestar general de una empresa. Seguir las teorías de gerencia de moda, no sólo es peligroso por los cambios que pueden presentar, sino que produce desconfianza en la dirección y rigideces en la visión y la acción. Los líderes deben ser flexibles, comprender que los modelos de gestión no son lámparas de aladino, sino recursos de cierta utilidad a las que se puede acudir en determinadas situaciones.

3.- Lección 14: Los buenos líderes son casi siempre buenos simplificadores, que pueden atajar debates, dudas y discusiones ofreciendo una solución que todos puedan entender. Tienen respuestas claras, sin ambigüedad, y con firmeza que transmiten al grupo, dando credibilidad e integración en la organización. Los buenos líderes mantienen las cosas sencillas. No se complican.

 Me recuerdan:

1. Preferimos el valor de las personas al de los procesos...

2.- Flexibilidad

3.- Lean Management, KISS...

Haciendo collage con estas 4 citas  de Garry Kasparov ("Cómo la vida imita al ajedrez ") veo la estrategia de un emprendedor ágil. Esto es obsesivo ;-)

LA VISIÓN

"El estratega empieza con un objetivo para un futuro lejano y trabaja retrocediendo hasta el presente."

LA TÁCTICA

"Si jugamos sin objetivos a largo plazo, nuestras decisiones se convierten en exclusivamente reactivas y nos vemos jugando el juego de nuestro oponente, no el nuestro. Mientras saltamos de una cosa nueva a la siguiente, acabamos por perder el rumbo, impelidos por lo que tenemos delante, en lugar de por los logros que necesitamos."

ITERACIONES Y RETROSPECTIVAS ESTRATÉGICAS

"Evalúa cuál será el resultado de su posición y establece una meta. Luego va paso a paso hasta conseguir su propósito."

"Los objetivos intermedios son esenciales, son los ingredientes necesarios para crear condiciones favorables para nuestra estrategia."

NOTA: CAMBIO DE FECHA Organizado por Agile Spain Zaragoza , con la iniciativa de Teresa Oliver , el próximo jueves, 17 de junio de 6 y media a 8 y media de la tarde  Frogtek presentará su forma de trabajar.

¿Donde?. En el edificio del ITA (Instituto Tecnológico de Aragón) en María de Luna, 8, Zaragoza.

Para ir haciendo ganas:

MODIFICACIÓN (15-Junio): Teresa anuncia que se cambia la fecha al lunes 21, también a las 18:30.

Esta semana, buscando información técnica quedé en estado de shock. Aún no me he recuperado. Necesito contarlo:

Viendo la página personal de un programador y buscando cómo contactar con él, descubrí que tenía un widget de "contacta conmigo" que decía "$0,50 el minuto". Bueno, esto me sorprendió, porque aunque es muy famoso el servicio de LIVEPERSON (tiene un índice Alexa de cincomil y pico) yo no lo conocía.
Me sorprendió, digo, pero no es esto a lo que me refiero.

La curiosidad me llevó a querer saber más de estas consultas que yo podía dirigir a expertos pagando...

Aún está bastante tierno esto de cribar la red con criterio semántico, pero empieza a tener su gracia. Si le preguntas a Google Squared por prácticas ágiles, la respuesta en el momento de escribir este post es:

• Integración continua
  
• TDD
• Scrum
• Refactorización
• XP
• RUP
• Flirting
• Programación en parejas
• Testing
• Historias de usuario

Nota: No darle más valor del que tiene como curiosidad. A mi por ejemplo RUP me chirria un poco como ágil, y con Flirting no se está enterando muy bien. Allá cada uno :-) 

¡Lo he probado, y no funciona!.

Esta es la razón por la que el director de proyectos de una empresa argentina, afirmaba que prefería CMMI, porque Scrum, simplemente no funciona. Comentándolo con Claudia, nos recordaba este vídeo de formación de Scrum Manager, y lo comparábamos con alguien que acostrumbrado a tocar con pianola, sentenciara: Mucho mejor las pianolas.   Yo he probado también con pianos... y no funcionan. :-)

Lamentablemente Claudia Ruata no podrá impartir el próximo curso de Scrum en Madrid, y tengo la difícil responsabilidad de sustituirla. Espero estar a la altura, y para los que queráis, será un gusto compartir lo mejor pueda y sepa, y allí nos vemos!

P.D. Sinceramente con mucho pesar, por trabajo e impartir también este curso (algo que hago encantado), no creo que pueda alargar la estancia en Madrid para ir también a la Conferencia de Agile Spain. Lo voy a intentar. Voy a hacer lo imposible, pero desde ya disculpas y los mejores deseos para el evento.

Chade-Meng Tan, además de uno de los empleados más veteranos de Google (2000) es jefe de crecimiento personal , responsable de la cultura de gestión de recursos humanos del talento en su empresita; y a la pregunta de cómo se hace crecer la innovación en la empresa, responde: ¿cómo crecen las plantas?:

Crecen ellas solas... si están en el entorno adecuado. 

Ha sido una semana intensa, de reuniones repartidas de San Francisco a San José. Con Attributor (próximas novedades en Safe Creative), Creative Commons, Scribd, PicScout... Hasta he podido conocer de primera mano ideas y principios de la gestión del talento y la creatividad en Google con Chade-Meng. Disculpad por eso, que Navegápolis esté un poco en modo standby, pero también será alimento para próximos posts. ;-)

Preveo que también durante los próximos días tocaré poca chufa por aquí, pero para los pamploneses que el martes (11 de mayo)  podáis acudir, estaré en el seminario "Agilidad Empresarial" a las 9:00 de la mañana, en el salón de actos del Centro de Excelencia del Software de CEIN en Noáin.

Si estás buscando inversores para tu proyecto, andas liado con el powerpoint, el "elevator pitch (discurso de ascensor )", o un  "executive summary" ... y estás escribiendo cosas como:

"Nuestras previsiones son conservadoras"... "Gartner prevé que éste va a ser un mercado de 50.000 millones de dólares en 2005" ... "Somos los únicos que estamos haciendo esto" o "Somos los únicos que sabemos hacer esto" ... "Oracle es demasiado lento / pesado para ser una amenaza" ... "Todo lo que tenemos que hacer es alcanzar el 1% del mercado"

Ten cuidado. Guy Kawasaki, Director General de la firma californiana de capital riesgo para proyectos TIC "Garage, Technology Ventures" afirma que son las mentiras más típicas y habituales de los emprendedores.

Y si recibes respuestas del tipo:
"Podemos tomar una decisión rápida"... "Me gusta tu empresa, pero a mis socios no", "Muéstranos que tiene tirón, e invertimos"... "Tenemos fondos de reserva de sobras"... "Estos son los términos de un acuerdo de inversión habitual y estándar"... "Podemos abrir las puertas de grandes clientes para tu proyecto"...

No te lo creas mucho. Guy dice que son las mentiras más habituales de los inversores.

• The TopTen Lies of Entrepreneurs: Artículo - Presentación.
• The Top Ten Lies of Ventura Capitalists: Artículo - Presentación.
  

El espíritu de los modelos como los Campos de Scrum o Lean es maximizar  el valor para el cliente, y reducir al mínimo el "rozamiento": documentación, gestión burocrática, residuos...

Generar más valor con menos recursos, y planificar a corto. Como suelo decir: no alumbrar el futuro con largas, o luces altas, sino con cortas; o luces bajas. Avanzar paso a paso en iteraciones cortas, con el objetivo de mejorar continua y rápidamente el valor del producto.

Los Campos de Scrum, nacieron en empresas como Honda, 3M, Canon, Fuji, Xerox o hp; y la producción Lean en Toyota. El desarrollo de software lleva ya algunos años adoptando sus principios.

Aplicar sus principios en la estrategia de startups, de nuevas empresas de tecnología, es más reciente,  y hasta hace poco, presentar un proyecto sin un plan de negocio detallado, dibujando sólo con precisión 3 o 6 meses, y afirmando que esta sería la pauta continua, por ser la visión de un proyecto ágil, parecía cosa de indocumentados.

Al presentar el plan de una startup en formato de backlog ágil, la sensación de desconcierto y desconfianza de los inversores tradicionales, así como las dudas que empiezas a generar sobre tu cordura se llegan a palpar.
Por eso, tras algunos años de complejo, reconforta descubrir sitios como "Lessons Learned" de Eric Ries, uno de los fundadores de imvu, y la presentación que hizo el año pasado en Web 2.0 que no me resisto a resumir:

Si estás pensando en crear una empresa, per aún no has dado el primer paso.
Si quieres empezar ya, e ir iterando deprisa.
Si quieres crear las condiciones para tener innovación ágil dentro de una gran empresa... Esta es la historia de dos empresas:

La primera comenzó con una convincente visión a largo plazo. Con todo el capital necesario. Contrató a los mejores y más brillantes junto a un equipo de gestión con toneladas de experiencia en startups. Se centró en la calidad: desarrolló una plataforma tecnológica brutal y se promocionó en la prensa y la blogosfera.

Tras cinco años de dolor y 40 millones de dólares logró un fracaso completo, tirando el trabajo y llevando al descrédito a profesionales muy cualificados por seguir estos mitos y falsas premisas:

• Sabemos lo que quieren los clientes.
• Podemos predecir el futuro con precisión.
• Avanzar en el plan es progresar.

La segunda empresa (imvu ) lanzó el producto en 2004, tras 6 meses de desarrollo: una beta horrible, y basó la calidad en la iteración rápida del producto, y prácticas de programación ágil (pudiendo realizar hasta 5 despliegues del sistema en un día ).En 2007 obtenía un resultado de 10 millones de dólares.

Las StartUp ágiles tienen más velocidad porque: 

• Emplean tecnología contrastada y básica, con un elevado grado de apalancamiento (free / open source).
• Implican a los usuarios en la evolución del producto.
• Emplean prácticas ágiles para el desarrollo del sistema de software.
  

The Lean Startup at Web 2.0 Expo

View more presentations from Venture Hacks .

"El auge de los denominados sistemas de Business Intelligence (BI o sistemas de inteligencia de negocio), está haciendo que en los últimos años se estén dando muchos proyectos de implantación de dichos sistemas BI. La gran mayoría de dichos proyectos (85%) han fracasado en conseguir sus objetivos...

...Por otra parte y de forma paralela, las metodologías ágiles de desarrollo de software están teniendo un gran auge y están dando buenos resultados en ámbitos en los que otras metodologías más convencionales habían mostrado limitaciones en su aplicación.
Así pues, si juntamos la inmadurez de la disciplina de BI con la orientación práctica de los enfoques ágiles, podríamos obtener un resultado final más satisfactorio....

...Sin embargo, todas las herramientas de IT Governance actuales siguen centrándose en las estructuras y los procesos. Es necesario que, además existan mecanismos eficaces que fomenten la relación, comunicación y colaboración entre las personas de la organización, en contexto pautado de las estructuras y los procesos..."

Citas del artículo "Agile Business Intelligence Governance: Su justificación y presentación", de J. Fernández, E. Mayor y J.A. Pastor", que analiza la relación entre los 6 factores considerados clave para el éxito de una implantación de un sistema BI, y los principios ágiles. Bueno, hay cosas en las que seguro, cada uno estamos más o menos de acuerdo, pero qué duda cabe que las organizaciones son sistemas realacionados y que la síntesis entre los procesos y la agilidad está servida en todas las áreas.

Más información:

Enlaces relacionados:

• Artículo Agile Business Intelligence Governance: Su justificación y presentación.
• Diapositivas de la presentación en la Universidad Juan Carlos III en 2008
• Vídeo de la presentación .
  

 Sobre agilidad en todas las áreas de la empresa:

•  Agilidad en toda la empresa: ScrumManager
• Adopción flexibile de la agilidad, que implica a toda la organización.

Implantar un campo de Scrum para un único equipo de 4 a 8 personas, que trabaja en el desarrollo de un único sistema es un "caso de libro". No hay más que "copiar y pegar" las prácticas tradicionales de scrum de Ken Schwaber y Jeff Sutherland.

Pero en las empresas en las que nos movemos son bastante habituales los entornos multiproyecto, y "equipos" mínimos de tres, dos, o incluso una persona, y como flexibilidad consiste adaptar las prácticas a nuestra circunstancia y no al revés, os comento una práctica, de invención propia, que me está funcionando razonablemente bien, y que me ha dado por llamar "cajas kanban" o "kanban boxes", que parece que inglés siempre mola más ;-)

Mantiene los principios de "time boxing ", Seguimiento diario del avance, comunicación directa y visual, pero no hace dependiente el avance iterativo de ciclos temporales o "sprints" sino simplemente de nuevas funcionalidades, y es válida para entornos multi-proyecto, y también más aconsejable que el ciclo Scrum clásico para equipos muy pequeños (3 personas o menos)

¿Qué es una caja Kanban o una Kanban Box?

La descomposición y estimación de una funcionalidad o historia de usuario en las tareas que la componen, con un formato visual y simple (Kanban) y un indicador de avance diario ágil:

Con el permiso, y agradecimiento a Mario López de Ávila , comparto aquí una de las diapositivas y texto que emplea, adaptado de "Re-Work" (Fried & Heinemeier, founders of 377 Signals) en uno de sus seminarios de formación.

 
^{cc by nc sa Kaptain Kobokd}

Abracemos la idea de tener menos carga.  Ahora mismo eres lo más pequeño, en forma y rápido que nunca llegarás a ser.  De aquí en adelante, comenzarás a acumular masa.  Y cuanto más masivo es un objeto, más energía requiere para cambiar su dirección.  Esto es tan cierto en el mundo de los negocios como en el mundo físico.
La “masa” aumenta con…

• Contratos a largo plazo
• Exceso de plantilla
• Decisiones irreversibles
• Reuniones
• Procesos “pesados”
• Inventario [físico o mental]
• Dependencias tecnológicas, de software, hardware, etc.
• Planes a largo plazo
• Política de pasillos

Pregunta para directivos de empresas de software: ¿Qué es CMMI?, ¿En qué consiste?. Seguramente se podría escribir una "antología del disparate" con las respuestas. Así lo veía esta semana Scott Adams.

 Fuente: Dilbert 2010-03-13

En Safe Creative acabamos de publicar una herramienta con la que ya no es un dolor de incomodidad y trámites el registro de la propiedad intelectual del software.
La herramienta se llama ART (Automatic Registering Tool). Basta vincular una carpeta de vuestro equipo, o de un servidor de ficheros, con un perfil de registro en Safe Creative, y cada vez que cerréis una versión, al dejarla en esa carpeta, se registrará automáticamente a través del API de Safe Creative.

Según sea el caso de programador o empresa, basta con crear el perfil de registro adecuado, indicando en él los derechos que se están registrando:

- Autoría: para registrar como programador de la aplicación los derechos morales de autoría y reconocimiento
- Autoría y derechos: registrando así también los derechos patrimoniales
- Derechos: como empresa que desarrolla, comercializa, opera o distribuye el software.

Página de descarga

• Instrucciones.
• Más información. 
• Preguntas frecuentes.
• Rigor y garantía del registro.
  

Uno de cada tres programadores, o gestores que trabajan directamente en proyectos de programación usan metodologías ágiles, y las han incorporado por propia iniciativa, no por instrucciones "corporativas". La implementación se produce "motu proprio" en equipos que trabajan en la misma planta o en el mismo edificio.  La metodología más empleada, con mucho, es Scrum; y la mayoría de los que las emplean hablan bien de ellas, y creen que han mejorado la comunicación en el equipo, la velocidad en el cierre de versiones y la flexibilidad en el diseño.

Estas son las principales conclusiones de uno de los pocos estudios realizados sobre una muestra de técnicos, significativa (492 encuestas anónimas). Lo realizó Microsoft hace 2 años entre su personal de EE.UU, Europa y Asia, para analizar el grado de "contagio" de agilidad que estaba teniendo la empresa, la opinión de los técnicos y los resultados.

•  Estudio: Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study .