Con kanban, ¿hay que estimar las tareas?, ¿En la reunión diaria hay que poner en la tarjeta kanban el esfuerzo que le queda?
¿Hay reunión diaria en kanban?
¿Puedes hacer scrum y cambiar una historia del backlog por otra a mitad de sprint?
¿Puedes ajustar el flujo con otras variables que no sean el WIP?
¿No estimar las tareas dilata la ejecución o reduce el efecto de la ley de Parkinson?
¿El rol de Scrum Master puede asumirlo lider técnico?
¿Hace falta un Scrum Master en un equipo ágil maduro y experimentado?
¿Hay roles en Kanban?
¿Podemos llevar varias cadencias kanban solapadas?
¿El sprint backlog es en realidad un WIP?
¿Puedo hacer scrum si el equipo no es multidisciplinar?

En definitiva la cuestión es si deberíamos considerar o no a scrum, a kanban o a cualquier otro, como métodos definidos, y por tanto actuar en nuestros proyectos según establezca el que hayamos adoptado.

Pues bien, es normal adoptar métodos definidos para gestionar sistemas de producción relativamente simples o de complejidad conocida y modelable, y sin embargo en la gestión de sistemas complejos resuelve con mayor solvencia el conocimiento tácito de un gestor experimentado. Se trata de la misma diferencia que hay entre la producción industrial y la producción ágil, trasladada a la gerencia: “preferimos las personas a los métodos”.

Con este criterio, hay dos posibles patrones de gestión: uno técnico, basado en la implantación del conocimiento profesional explícito, y otro experto, basado en el conocimiento tácito desarrollado con la experiencia profesional.

Para la gerencia técnica el fin es el método: conocerlo a fondo para implantarlo en la empresa.

Para la gerenica experta un método es un elemento más en su inventario de conocimiento y prácticas que conforman las piezas con las que la persona es capaz de construir la solución de gestión más adecuada a cada realidad.

Un gestor técnico estimará las tareas de los sprints de un proyecto si usa el “método scrum” y no las estimará si usa el “método kanban”.

Un gestor experto conoce ambos métodos, ha adquirido conocimiento de la experiencia en diversos proyectos, con distintos equipos y personas y sabe que según la combinación de tamaño del equipo, talento y motivación, la estimación puede ser contraproducente y favorecer la ley de Parkinson o por el contrario ser una buena práctica para combatir procrastinación o disipación. De igual forma un gestor técnico no contemplará la posibilidad de hacer sprints si usa kanban (y probablemente no comprenderá a quien lo haga).

Frónesis es la característica principal de los nuevos líderes, según afirman los autores que hace 30 años nos enseñaron el concepto de agilidad como avance en campos de scrum: Nonaka y Takeuchi; que comparto y me gusta tanto o más como en su momento me gustó Scrum.

Si en su artículo de entonces "The New New product development game" conceptualizaron los principios de scrum como un ecosistema para trabajo en equipo basado en principios entonces poco académicos, ahora en su artículo "The Wise Leader" presentan también nuevos principios, pero esta vez para los líderes.

Según Nonaka y Takeuchi los nuevos líderes no basan sus decisiones en conocimiento científico y técnico, propio de la formación tradicional de directivos, sino en la sabiduría obtenida de la práctica, que además de la capacidad para encontrar respuesta a un contexto particular incluye "virtud" en la toma de decisiones para que éstas sirvan al bien común.

Los mismos autores que conceptualizaron el marco de trabajo Scrum, las diferencias y relaciones entre conocimiento tático y explícito, y la evolución de éste en forma de espiral dialéctica, argumentan ahora que los líderes tradicionales gestionan con conocimiento explícito. Que a muchos les resulta difícil reinventar sus empresas al ritmo que hoy marca la tecnología, la demografía y el mercado. El liderazgo tradicional es incapaz de desarrollar organizaciones para operar en un escenario global, y sobre todo le resulta difícil transmitir a las personas valores éticos. Los CEO's ya desfasados, según esto, siguen creyendo que la codicia es buena y que el objetivo del negocio es el máximo beneficio.

"Los gerentes suelen basarse en el conocimiento explícito que puede ser medido, codificado y generalizado" dicen Takeuchi y Nonaka. Sin embargo este enfoque "supone un mundo independiente del contexto y busca respuestas universales y predictivas". "Todo el conocimiento explícito del mundo no ha evitado el colapso financiero mundial de hace tres años o la quiebra de Lehman Brothers"

Afectada por el engaño y la codicia, la gente está molesta por la ausencia de valores y ética en los negocios. Las empresas de Wall Street pensaron que podían manejar riegos mayores usando números, datos y fórmulas científicas en lugar de analizar con sabiduría la naturaleza de los préstamos.
Lo mismo ocurre con la industria del automóvil de EE.UU. que se basa en la oferta de incentivos financieros en lugar de comprender las necesidades del cliente. Depender sólo del conocimiento explícito impide conocer las dependencias del contexto y su análisis en el entorno social.

Nonaka y Takeuchi proponen en su artículo la frónesis aristotélica, síntesis del conocimiento científico y técnico, como clave del nuevo liderazgo, y la definen como "el conocimiento tácito adquirido por la experiencia que permite a las personas hacer juicios prudentes y actuar de forma adecuada a cada situación, guiadas por los valores y la moral".

Según los autores son seis los principios de los líderes sabios:

• Los líderes sabios toman decisiones sólo despues de averiguar lo que es bueno para la organización y la sociedad.
• Captan rápidamente la esencia de las situaciones y los problemas, comprendiendo la naturaleza y el significado de las personas, las cosas y los hechos
• Crean contextos de trabajo basados en el diálogo y el consenso
• Saben cómo elaborar metáforas e historias para transformar la esencia de su experiencia en el conocimiento tácito de los individuos y los grupos.
• Tienen la capacidad política de reunir a personas con objetivos en conflicto y estimular a la acción.
• Fomentan el desarrollo de la frónesis en otros.

Entrevista a Takeuchi y Nonaka sobre su artículo The Wise Leader

Al situar las técnicas y los métodos con los que trabajamos en el contexto de evolución del conocimiento profesional, además de "culturilla" adquirimos una perspectiva útil para comprender mejor cuáles son los problemas que solucionan, las diferencias y similitudes con otras técnicas, y las fortalezas o limitaciones en relación con ellas.

Para los que os pueda ser útil, esta es una visión somera, pero quizá suficientre para ver el camino recorrido desde la fabricación artesana a la producción lean, y para situar en perspectiva el concepto de producción lean, o a kanban como una técnica de apoyo.

De la artesanía a la producción lean

División del trabajo

“La riqueza de las naciones” es la obra más célebre de Adam Smith. Fue publicado en 1776 y se considera el primer libro moderno de economía. En él desarrolla la teoría económica sobre la división del trabajo.
Para Smith el principal factor para mejorar la productividad del trabajo es su división, que ilustra en su célebre ejemplo de la manufactura de alfileres, en el que compara la producción que puede alcanzar un herrero que acomete todas las tareas necesarias, con la obtenida en un sistema con división del trabajo entre obreros especializados en cada tipo de tarea (estirado del alambre, cortado, afilado,etc.).
En el ejemplo demuestra que la división del trabajo hace posible que en lugar de producir 50 alfileres diarios por obrero, se produzcan 5.000

Este artículo es una traducción autorizada del post "Why You Shouldn't Hire More Developers" de Ash Moran publicado el 3 de Febrero de 2012 en PatchSpace Blog, y al que desde aquí agradezco el permiso y la disposición para publicarlo en Navegápolis.

La situación latente

Eres el responsable de un equipo de cinco programadores, y estás completamente quemado. Pasáis los días en la oficina desde primera hora de la mañana hasta el final de la tarde, intentando hacer frente a una acumulación continua de trabajo.
De hecho empiezan a ser mejor las noches para trabajar, porque durante el día estáis inundados con interrupciones, emergencias y errores que reclaman atención, por lo que cada vez tenéis menos tiempo para desarrollar funcionalidades nuevas.
Casi no puedes atender a los clientes actuales, y los de comercial acaban de cerrar el acuerdo con un nuevo cliente, que tiene un montón de peticiones. Cada vez pierdes más tiempo en reuniones tratando de mantener la situación bajo control. Probablemente ya te estás tirándo de los pelos, pensando que no tienes tiempo para todo y que tienes que tomar una determinación.

Así que esbozas la situación en una hoja: Cada programador dedica al menos 60 horas a la semana, así que tienes unas 300 horas/programador por semana, de las que estimas que unas 50 se les van en corregir errores, otras 30 en atender la operativa del sistema y 20 en reuniones. En total 100 horas: ¡una tercera parte del tiempo! antes de poder atender las funcionalidades nuevas que están en un backlog que no para de crecer. ¡Y ahora para colmo un nuevo cliente!.

La conclusión es obvia: hay demasiado trabajo, y tienes desbordado todo el tiempo disponible, así que necesitas más gente. Si tuvieras dos programadores nuevos se podrían dedicar a la corrección de errores, a las cuestiones operativas e incluso podrían pellizcar algunas de las funcionalidades nuevas. Sólo tendrías que pagar por 40 horas semanales de cada uno, y como siempre, en cuanto asuman la cultura de la empresa acabarán dedicando más. Así que la solución es obvia, y vas a tu jefe para que autorice una selección de personal.

Mal. Lo último que deberías hacer en una situación como esta es contratar nuevos programadores.

Hace tiempo anduve pensando que podría poner un pequeño precio al libro de scrum que regalo, y enviar el dinero a un proyecto solidario; porque no parece lógico que las iniciativas que comparten y regalan desperdicien el posible beneficio que podrían generar, cuando en su mismo mundo hay millones de personas en extrema pobreza.

Me acordaba de aquello que nos decían de pequeños: "Te lo tienes que comer todo. ¿No ves que hay niños que se mueren de hambre?". ?????

Y me produce el mismo sentimiento de impotencia: No me lo como porque no tengo hambre, y lo tengo que tirar porque no se lo puedo dar a los que tienen hambre.

Pero... ¿Qué vas a hacer? ¿Cobrar y explicar que vas a entregar todo o la parte que sea a una ONG? ¿Y cómo se lo cuentas a Hacienda?... Y además a fin de cuentas, sólo sería una gota: unos pocos libros y unos pocos euros. Menudo follón para 4 euros.

Y este es el origen de la idea de PayCommons: una plataforma de pago electrónico que pueda canalizar muchas "gotas" de forma transparente y fácil. Abriría además posibilidades a quienes, con ganas de ayudar, quizá no andan sobrados de medios pero derrochan talento.

No soy el más objetivo para valorar si esta idea tiene sentido o es una quimera, pero lo que no tiene ningún sentido es dejarla en un cajón por no poder atenderla.

Así que para todos a los que pueda interesar fundar un proyecto para darle forma, dirigirlo, participar o invertir... o si sabéis de gente a la que puede interesar y a la que se lo podéis pasar, aquí la he resumido en un "Elevator pitch" en formato PPT (Un "PPT elevator" ? :-)

Elevator pitch - English version .

"A aquellas personas que venden talento cada vez les irá mejor y ganarán mas, a aquellas personas que venden horas cada vez les irá peor.... Si el mileurismo nos parece duro, preparémonos porque lo más probable es que venga el sub-mileurismo"

"En EE.UU. el 65% de los jóvenes se autoemplea, en Europa es un 40% la gente joven que se autoemplea, aquí en España es un 3%.... Si sólo hay un 3% de personas que se autoemplean quiere decir que hay unas creencias detrás que están sustentando todo eso. La creencia básica es "Un trabajo por cuenta ajena me da estabilidad, me da seguridad, me permite pagar la hipoteca etc."

Mucho mejor oirlo directamente de su autor... Sergio Fernández en la entrevista con Beatrice Pieper , directora y fundadora de la revista digital Uakix .

Vía:  vía @EvergreenPM  / @deimer   

Enseñar competencias clave para desarrollar proyectos TIC en un mercado global, con equipos dispersados en distintos países, es el objetivo del proyecto GSD de la Univerisidad de Pace de Nueva York.

Cada año pone en marcha, en colaboración con otras universidades (Tailandia, India, Camboya, Senegal...) el desarrollo de un proyecto de software con equipos distribuidos.

Son proyectos que sirven de aprendizaje para los estudiantes y profesionales que participan, y de material de análisis con el que están construyendo y depurando un fondo de conocimiento específico para desarrollo global de software.

En 2009 decidieron por primera vez emplear un marco ágil (Scrum) para gestionar el desarrollo de una aplicación para dispositivos móviles, con equipos separados  (Universidad de Pace - Universidad de Delhi y Escuela Superior Politécnica de Dakar).

El mes pasado de publicó el informe del proyecto: "Some Management Principles Learned from Scrum Practices within a Global Software Development Project " que incluye las

6 lecciones aprendidas para la gestión de Scrum distribuido:

Lección 1: Se empieza con mucha voluntad...

Pero es dífícil mantener la motivación y el compromiso con los rituales ágiles previstos.
Sugerencia de gestión: Escribir las motivaciones y compromisos individuales para tenerlos presentes y visibles como banderas a lo largo del proyecto.

Lección 2: No caer en el principio de pareto

Trabajar por separado acentúa la tendencia a enfatizar y consumir mucho esfuerzo en tareas de preparación, aplicando esfuerzo ineficiente (80% de esfuerzo en un 20% del resultado).
Sugerencia de gestión: Conocimiento previo de los conceptos de Scrum, y aplicar pautas y artefactos de gestión simples.

Lección 3: Asignatura difícil: Gestión individual del tiempo

El trabajo distribuido reduce la visibilidad de problemas en miembros del equipo por una mala autogestión del tiempo. Los miembros de equipos separados deben conocer y aplicar de forma disciplinada los principios para la buena gestión del tiempo. Las prácticas de Scrum  para priorizar y estimar las tareas y seguir su evolución de forma cercana y con compromiso de equipo, son especialmente útiles, pero más difíciles de poner en práctica entre personas geográficamente dispersas.
Prácticas aconsejadas:
1.- Periodo de práctica y aprendizaje previo para poner a prueba las habilidades de gestión del tiempo, realizando prácticas de estimación y ejecución de tareas.
2.- Asesoramiento en el análisis y priorización de las tareas pendientes.
3.- Mostrar a los "perfeccionistas" que la perfección es imposible e innecesaria.
4.- Recordar que el tiempo es un recurso valioso.

Lección 4: Ser impasible... ¡mantener un ritmo de trabajo constante!

No olvidar el principio ágil de mantener una velocidad equilibrada, sin fluctuaciones. Sin momentos de estres que queman y desmotivan, ni periodos de procrastinación.

Lección 5: El fin justifica los medios.

El foco del trabajo no es la eficacia o la estética de la codificación. Son puntos técnicos que no deben consumir más foco que el necesario para garantizar el objetivo real: entregar una aplicación operativa.

Lección 6: La capacidad del barril depende de su tabla más corta.

Cada miembro tiene sus debilidades, o tablas más cortas, y sus fortalezas, o tablas largas. La organización del equipo debe conseguir la distribución del trabajo y el resultado combinando y sumando las fortalezas, no las debilidades.


Otros informes del proyecto GSD.

GSD 2007 GSD 2008 GSD 2009 GSD 2010

¡Feliz Navidad amigos, y los mejores deseos para 2012!

El 24% de los usuarios de redes sociales en España se consideran saturados mientras que el 30% dice que le sabe a poco y que quiere participar más; y el 20% afirma que se dio de alta alta por seguir la moda o probar la novedad pero no se ha "enganchado".

A Facebook la prefieren más ellas que ellos (81% frente a 75%) mientras pasa lo contrario con Twitter (11% frente a 17%).

Estos datos y otros más serios ;-)  están en el estudio sobre conocimiento y uso de las redes sociales , que acaba de publicar el Obserbatorio Nacional de las Telecomunicaciones (red.es). 173 páginas con mucho grano y poca paja para los interesados en las redes sociales, acompañadas además de una presentación-resumen.

• Página de información y descarga del esutio y la presentación.

Esta presentación muestra un ejemplo de la teoría del post anterior, con el que comparto mi experiencia en dos proyectos reales y los patrones de entrega de valor al cliente de cada uno: uno desarrollado en 2000 cuando dirigía el área de proyectos y programación de iA Soft: la versión 1.0 de espublico.com  (gestión tradicional) y el otro, el que dirijo actualmente (gestión ágil): Safe Creative, comenzado en 2007.

Para un gestor de proyectos tradicional, espublico fué un éxito: se entregó al cliente todo lo que pidió con una calidad técnica intachable, en las fechas previstas y por el presupuesto estimado.

Para el cliente fue necesario especificar el 100% de los requisitos desde el principio y esperar un año a tener todo el producto completo. Cuando se le entregó muchas funcionalidades ya no tenían sentido.

Desde el punto de vista de la gestión de proyectos tradicional "la operción fué un éxito". Desde la perspectiva del cliente: "el paciente casi se muere".  Tuvo exactamente lo que pidió, aunque no era lo que realmente necesitaba, y en un 80% no le servía, pero no se pudo dar cuenta hasta que no estuvo todo terminado, ni pudo cambiar de estrategia a mitad de desarrollo. (Afortunadamente, tras pasar el bache de la "operación exitosa" el cliente se repuso y hoy espublico es el líder de su sector.)

El objetivo de la gestión predictiva es construir el producto planificado en el tiempo y con los costes previstos. El de la gestión ágil, entregar el mayor valor posible en el menor tiempo, e incrementarlo de forma continua.

Pasar de desarrollo secuencial y planificación global con requisitos cerrados, a un marco iterativo e incremental con requisitos abiertos no es agilidad. Agilidad también supone preferir la pericia y el criterio de las personas al conocimiento estuchado en los procesos y la tecnología.

Trabajar sin procesos ni gestión predictiva, pero sin conocer tampoco ni principios ni prácticas prácticas ágiles tampoco es agilidad.

Si falta alguna de estas piezas el ecosistema para un Campo de Scrum estará cojo. Cuando más evidente es más rozamiento produce, e incluso lo puede hacer inviable.

Cambalache: Trueque, considerado con desprecio, jactancia, satisfacción, pesar u otro movimiento del ánimo que se expresa por el tono y el contexto. Trueque hecho con afán de ganancia. (RAE)

Que el mundo fue y sera una porqueria, ya lo sé,
en el quinientos seis y en el dos mil también;
que siempre ha habido chorros,
maquiavelos y estafaos,
contentos y amargaos, valores y dublé.
Pero que el siglo veinte es un despliegue
de maldá insolente ya no hay quien lo niegue,
vivimos revolcaos en un merengue
y en el mismo lodo todos manoseaos.

Hoy resulta que es lo mismo ser derecho que traidor,
ignorante, sabio, chorro, generoso, estafador.
¡Todo es igual, nada es mejor,
lo mismo un burro que un gran profesor!
No hay aplazaos ni escalafón,
los inmorales nos han igualao...
Si uno vive en la impostura
y otro roba en su ambición,
da lo mismo que sea cura,
colchonero, rey de bastos,
caradura o polizón.

¡Qué falta de respeto, qué atropello a la razón!
¡Cualquiera es un señor, cualquiera es un ladrón!
Mezclaos con Stavisky van don Bosco y la Mignon,
don Chicho y Napoleón, Carnera y San Martin.
Igual que en la vidriera irrespetuosa
de los cambalaches se ha mezclao la vida,
y herida por un sable sin remache
ves llorar la Biblia contra un calefón.

Siglo veinte, cambalache, problemático y febril,
el que no llora no mama y el que no afana es un gil.
¡Dale nomas, dale que va,
que alla en el horno te vamo a encontrar!
¡No pienses mas, tirate a un lao,
que a nadie importa si naciste honrao!
Si es lo mismo el que labura
noche y dia como un buey
que el que vive de las minas,
que el que mata o el que cura
o esta fuera de la ley.

vía  @Mavalvanera

No es fácil trabajar en un marco de Scrum con un equipo distribuido y es precisamente el tema que analiza Sergio Yazyi en su trabajo de Fin de Master en las TIC en Educación de la Universidad de Salamanca "Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido ".

El trabajo emplea para su análisis el taller de Open Knowledge Scrum de Scrum Manager en el que participó el año pasado, que fué dirigido por Claudia Ruata.

El documento compone una visión general y análisis, objetivo y riguroso tanto del aprendizaje basado en proyectos como de los retos del trabajo con equipos distribuidos.

"El aprendizaje basado en proyectos se presenta en varias disciplinas como una estrategia pedagógica óptima para ejercitar conocimientos a la vez que desarrollar habilidades, afrontando situaciones similares a las del mundo real no sólo en términos individuales sino también en la acción coordinada, al mismo tiempo que ofrece un escenario para facilitar la incorporación transparente de la tecnología dentro del proceso de trabajo, por sus virtudes para alcanzar el logro de los objetivos."

"En contextos donde los requisitos son estables, esto ha funcionado bien. Sin embargo, con la aceleración en el ritmo de evolución tecnológica de las últimas décadas, la aplicación de este enfoque en escenarios donde los cambios frecuentes no sólo son inevitables sino incluso deseables, y donde la capacidad de predecir el resultado y el momento es menos importante que garantizar la producción de valor genuino en el
proceso, el modelo tradicional en cascada, predictivo, se ha revelado insuficiente. En particular, en la industria del software se ha vuelto evidente que cuando las definiciones de los requisitos son más dinámicas, inciertas o inestables, este modo de desarrollar produce sistemáticamente  retrasos, altos costos para los proyectos e insatisfacción en el cliente"

Entre las conclusiones del trabajo una particularmente interesante, que apunta una nueva dimensión de Scrum: en la formación.

"Se podría incluso considerar Scrum dentro del aprendizaje basado en proyectos como un verdadero patrón pedagógico, que sintetiza en un conjunto de reglas simples, los principios y buenas prácticas para permitir a un grupo de trabajo transformarse en un verdadero equipo de alto rendimiento, en contextos de incertidumbre e interdisciplinariedad."

... continúa en: "Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido" 

• Página de información del trabajo.
• Enlace de descarga.

La agilidad es lo fácil y la ingeniería de procesos (ISO 12207, ISO 15504, CMMI...) lo difícil.

El marco de trabajo Scrum se explica en media docena de páginas y para conocer las veintitantas áreas de procesos, objetivos y prácticas, específicas y genéricas de un modelo como CMMI,  hacen falta cientos.

Hace unos años, cuando CMMI hablaba sin miedo a perder mercado por la competencia de la agilidad, una implantación para un nivel 2 de madurez, entre pitos y flautas se te iba a más de un año de trabajo y bastantes miles de euros en formación al grupo de evaluación y en minutas de expertos consultores encorbatados. Aparecieron entonces unos chicos que tras años intentando hacer software con esos procesos los habían mandado a la porra, y descubierto otras formas que funcionaban mejor; y tras ellos otros que andaban buscando en qué podían decir que eran expertos, y esto parecía fácil.

Así que teniamos lo difícil y caro: CMMI y lo fácil y barato: Agilidad.... ¿o no?

CMMI es complejo, pero no es difícil. La Agilidad es simple, pero no es fácil.

Para tornear figuras con un torno de control numérico hay que conocer y aplicar sin cambiar una coma el manual de operación, y al final las piezas salen perfectas. Puede ser complejo, pero no difícil. Quien lo hace es un operador.

Podría parecer que es más fácil tallarlas porque sólo hace falta un martillo y un cincel, y además asesorar de cuáles son los mejores martillos, y cinceles. Los mejores materiales, técnicas para coger el cincel... y es que cuando se trata de agilidad y confias el resultado no a los procesos y la tecnología, sino a las personas, como dice mi amigo Luis, la cuestión no son las flechas, sino los indios ;-)

Vaya por delante que no soy abogado, que hablo desde el sentido común, basándome simplemente en lógica, no en teoría jurídica, y con la intención de contrastar el siguiente razonamiento, como hipótesis para reforzar o debilitar con vuestras opiniones. Los que queráis, disparad sin compasión, pero mejor a la idea que a mí...  que ríase usted de las filias y fobias sobre CMMI, Scrum y demás temas habituales de este blog, comparadas con las que se gastan en el mundo copyright-copyleft :-)

Yendo al grano: ¿Cómo lo veis vosotros?, porque aplicando lógica proposicional a los datos que conozco aparecen conclusiones que pueden tener su miga. El silogismo que planteo sería más o menos:

Premisas:

a) Los programas informáticos son obras con derechos de autor.

En el ámbito europeo y latinoamericano (no en el americano / anglo-sajón) el software tiene derechos de autor. Le corresponde la protección por derecho de autor y no por propiedad industrial. En Europa no se patenta el software, se registra.

b) Los derechos de autor y sus derechos conexos se pueden gestionar de forma colectiva.

Para el uso de obras con derechos de autor a través de canales abiertos (radio, televisión, musica ambiental, internet...) como afirma la OMPI (1) se recomienda, emplear un modelo de gestión colectiva "es evidente que resulta prácticamente imposible llevar a cabo una gestión individual de los derechos. Los autores no tienen posibilidad de controlar todos los usos que se hacen de sus obras".

Conclusión: Es posible la gestión colectiva de los derechos de autor y derechos conexos del software.

Para el uso de "obras de software" a través de canales abiertos, se puede emplear un esquema de gestión colectiva de los derechos de autor y sus derechos conexos que haga posible la remuneración a los autores y a la industria de explotación que ofrecen estas obras en los canales abiertos.

Es posible concebir una asociación para la gestión colectiva de los derechos de los autores y de los titulares de sus derechos conexos de las obras de software que ofrecen su uso a través de Internet (hay miles, desde las "grandes producciones" como gmail o google docs, videojuegos (Drankensang B. Galactiva, etc.), y la enorme lista de autores y proyectos de software de alcance más modesto.

Entre los posibles modelos de negocio para hacer viable la creación y explotación de estas obras es posible contemplar la inclusión de las mismas en el repertorio de obras gestionadas por dicha sociedad de gestión y percibir la correspondiente regalía (recaudada través de las perciepciones por canon de los usuarios a medios y redes digitales).

¿Tiene lógica? ¿Porque los sufridos creadores de software en Internet van locos buscando modelos de negocio, mientras que todas las demás áreas de creatividad con derechos de autor disponen de la vía de la gestión colectiva?

Quizá la Propiedad Intelectual se está metiendo en un jardín al aplicar hoy las soluciones a los problemas de ayer, pero si es así... ¿por qué dejar al software fuera?

(1) "Gestión Colectiva del Derecho de Autor y los Derechos Conexos " - Organización Mundial de la Propiedad Intelectual.

Internet no nos enseña lo que queremos ver, sino lo que tenemos que ver. Si continúa el desarrollo de "filtros de personalización" cada vez va a ser más difícil que veamos o consumamos algo que ho haya sido hecho a medida para nosotros.

Como afirma Eli Pariser en esta charla, Internet puede estar cambiando el filtro de los redactores de los medios tradicionales por los "filtros algorítmicos", con la diferencia de que el filtro humano incluye una ética profesional periodística.

"El tiempo es el más precioso precioso de los bienes; su pérdida la mayor de las prodigalidades" (Benjamin Franklin)

¡Qué frecuentes las afirmaciones de este tipo! pero a ver si van a ser otra falacia de nuestra cultura, y como afirmaba Shirley MacLaine sólo sirven para producirnos estrés y agotamiento corporal y emocional?.

 ¡¡ Felices vacaciones !!

Este es el comentario reciente de una empresa argentina a su proveedor de software, y con el que hace un rato comentaba lo que se le podía responder.
Como este prejuicio es bastante frecuente, comparto en abierto lo que le hubiera dicho, por si os puede interesar como un argumento más para el inventario personal, o como opinión con la que contrastar, los que penséis lo mismo.

Se me ocurre que la cuestión principal, el comentario: "No me gusta Scrum poruqe estas metodologías no permiten estimar la duración total de un proyecto" no es cierta.
Lo cierto es que "estas metodologías" permiten que el plan del proyecto se enriquezca (o no, según quiera el cliente) a cada paso que se va construyendo, porque con ellas no va a estar a ciegas desde el día que lo encarga hasta el día que lo recibe.
El cliente lo va a ir viendo crecer (lo tiene que ir viendo crecer) y puede introducir modificaciones: "Lo que era así mejor hacerlo asá..."

"Estas metodologías" cambian el concepto de proyecto rígido y de construcción opaca para el cliente, de: "esto es lo que hay que hacer y no se cambia nada hasta que esté todo hecho, y lo verá hecho cuando lo terminemos y se lo entreguemos" a proyecto transparente y flexible: va a verlo crecer paso a paso y si al hacerlo descubre algo que sería mejor de otra forma, o algo en lo que no cayó en la cuenta de que le hacía falta, lo puede cambiar y lo tendrá en el siguiente paso.

Por eso no es cierto que no sea posible planificar el proyecto. "Estas metodologías" permiten hacerlo (ver gráfico burn-up como plan de proyecto). Le permiten además que ese plan de proyecto, en forma de pila de producto no sea rígido y pueda alterarlo durante el desarrollo.
No es cierto por tanto que "estas metodologías" no sean capaces de planificar, lo que no son capaces es de adivinar lo que usted cambiará :-)

Hace ya algún tiempo empecé a no tirar a la papelera las etiquetas con las historias de usuario que retirábamos de la pizarra al cerrar cada sprint.

Todo empezó el día que al limpiar la pizarra tenía en la mano una carpeta de las que empleamos para encartar folletos de publicidad. Son de cartón grueso y de acabado satinado... y surgió de forma instintiva. Fui pegando dentro las etiquetas adhesivas que quitaba de la pizarra.

Cuando volví al despacho, la cerré... me la quedé mirando y le puse en la solapa derecha una etiqueta con el número dle sprint, la fecha de cierre del sprint y la de despliegue en producción de las historias programadas. la dejé en la estantería.... Mmmm... que interesante.

Acababa de archivar la información de un sprint.

De una forma algo burda diría alguno (me consta que en el equipo hay quien preferiría algo más "tech", y me mira raro porque esto le resulta un poco vergonzante :-)

Bueno. Va como idea. A mi más que burdo me parece simple, y suficiente. ¿Cuántas veces voy a necesitar consultar esta información? y sólo "por si acaso alguna vez", y por las características de seguimiento admisnistrativo que le aplico a este proyecto... no me merece la pena invertir en esta burocracia más de 1 minuto. Por eso lo encuentro  completamente "lean", y os la comento por si a alguno os puede servir directamente o como idea base para hacer algo mejor.

A la vista de que ya el número de carpetas va creciendo se me ocurria que sería posible un "artefacto" como el de la foto para tener un sistema de registro "ágil". ¿Tendría sentido algo así?. (La foto es sólo un prototipo).

En casi todas las oficinas hay una encuadernadora. Encuadernando páginas de gramaje algo recio, y mejor si es satinado, se puede tener algo así como un "álbum kanban", un sistema ágil para registrar la información.

Las páginas de este "álbum de sprints" pueden llevar impresa la cabecera que a cada equipo le encaje mejor con su forma de trabajar para anotar: "Nº de sprint", "fecha", "velocidad",  "Versión", "Valor"... etc (para gustos colores y para riñas... talibanismos) :-)

La de arena

las afirmaciones de Alistarir Maughan (Asesor jurídico para la Administración Pública británica de Morrison Foerster):

Estoy dispuesto a aceptar que si todo va bien la agilidad puede reducir el riesgo de fracaso del proyecto. Pero la agilidad simplemente no funciona en el mundo real de proyectos TIC para la Administración. Necesitamos un Richard Dawkins para reventar el mito del evangelio ágil.

Hay razones claras por las que la agilidad no puede funcionar en la contratación con la Administración:

- En el marco ágil se paga por un esfuerzo, pero no por un resultado concreto. Esto no puede funcionar en la Administración.
- Los departamentos se gestionan con presupuestos aprobados y cerrados para obtener resultados concretos.
- La Administración está obligada por ley a seguir reglas de contratación abierta, lo que significa comparar diferentes licitadores sobre una base de igual a igual y decidir la mejor relación calidad-precio. La agilidad no da por adelanteado ni una descripción detallada del resultado, ni un precio cerrado. ¿Cómo cumplir con el requisito legal de que los contratos públicos son justos y abiertos?.
- La administración opera con un modelo de toma de decisiones centralizado hacia arriba, mientras que la agilildad se basa en la autonomía y la delegación de decisiones hacia abajo. Esta es la clave para que pequeños equipos descentralizados puedan reaccionar con rapidez y adaptarse a nuevos escenarios.

Las decisiones en los proyectos ágiles se basan en la confianza mutua, por tanto son muy adecuados para proyectos internos y al mismo tiempo resultan inadecuados para contrataciones externas.

La de cal

El departamento de trabajo y pensiones brítánico (DWP) ha modificado los contratos que rigen el suministro  del sistema de crédito universal, por dos mil millones de libras añadiendo cláusulas para alentar a los proveedores a usar metodologías ágiles en su desarrollo.
Estas modificaciones intentan asegurar que los proveedores abandonan los métodos convencionales de desarrollo de sistemas, acusados del fracaso de los grandes proyectos TIC.

Las cláusulas incentivan a los integradores de grandes sistemas a adoptar metodologías ágiles con lo que el DWP espera garantizar el buen fin del proyecto en la fecha comprometida de 2013.

vía: ComputerWeekly.com

¿Cuál es tu opinión?

¿Estás de acuerdo con la afirmación de  Alistarir Maughan: "Las decisiones en los proyectos ágiles se basan en la confianza mutua, por tanto son muy adecuados para proyectos internos y al mismo tiempo resultan inadecuados para contrataciones externas."

AgileBox es una plataforma de desarrollo ágil completa integrada por herramientas de código abierto, lista para para montar en un servidor virtual VirtualBox montada y compartida por Juan Antonio García Lebrijo.

Una vez descargada basta con importarla desde VirtualBox para disponer de un servidor con: Subversion, Nexus, Jenkis, Sonar, Redmine, Tomcat y MySQL .

• Descarga
  
• Configuración

El documento "Scrum Distribuido" es el resultado del primer taller de investigación (beta) de Open Knowledge Scrum. 

El estudio ha estado dirigido por José Miguel Vera y Sergio Yazyi, en el que han colaborado como autores junto a  Raúl Herranz, Noel Mamoghli,  Edgar González, Daniel Matulis, Victor Ratón, Miguel Salas, Salvador Arauzo, Felipe Muñoz y Luis Farias .

 El objetivo del documento es ofrrecer una primera información de las implicaciones de Scrum en un contexto distribuido. Para ello parte de las definiciones base, e identifica los retos más relevantes para un equipo distribuido, recopilandoy analizando la información para cada uno, con la propia experiencia profesional,  así como la del trabajo  realizado para la ejecución del estudio, que es precisamente el trabajo de un equipo distribuido.

• Descarga de Scrum Distribuido.

El juego "Project Risk" de Successful Projects, dispone ya de versión en español, dirigida por Ángel Águeda. Es un juego de formación que muestra los procesos de gestión de riesgos en proyectos, la técnica de valor ganado y práctica de trabajo en equipo.

Se puede jugar de varias formas, aunque posiblemente la más divertida sea compitiendo varios equipos, cada uno con su tablero.

El objetivo es alcanzar la meta en menos de 12 periodos,  con el mayor número de miembros del equipo y la mayor cantidad de dinero posible (fichas).

En el transcurso del juego se deben gestionar oportunidades (riesgos positivos) y amenazas (negativos) e incluso negociar con otros equipos para evitar la bancarrota.

• Más información: Project Risk.
• Vídeo del juego.