working time"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 .

 

scrum distribuidoEl 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 HerranzNoel Mamoghli,  Edgar GonzálezDaniel MatulisVictor RatónMiguel SalasSalvador ArauzoFelipe 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.


 Safe Creative #1106149463894

Este artículo fue publicado originalmente en navegapolis.net el 21 de junio de 2011

 

hippieLa agilidad no es cosa de pegar post-it's en las paredes, o hacer de las estimaciones juegos de adivinanzas o partidas de póquer.

No se trata de convertir a equipos de programación, en grupos de boy-scouts, o en comunas de socialización.

La agilidad no nace de las formas sino del fondo: personas, motivación y cultura; y a diferencia de la producción basada en procesos, es muy sensible a la capacidad de las personas y al entorno de la organización.

Por razones de imagen, ninguna empresa admite en público problemas en su organización, pero este estilo se sostiene en personas con competencias muy altas, y como tan escasos son los buenos programadores como los buenos directivos, los campos de scrum que realmente funcionan son pocos.

Si me das de gestor a Ken Schwaber y de programadores a Kent Beck, Erich Gamma y Ron Jeffries ya verás que bien me sale Scrum, y dará igual que siga al pie de la letra el marco de Scrum técnico, o que empleemos las técnicas ágiles con las qeu nos sintamos más cómodos.

Si me das a un jefe "Pointy-haired" o un gestor "cuadriculado" y de programadores a media docena de aprendices... acabaré cansado de modificar el modelo de trabajo, y culpando a éste y al equipo por los resultados. 

No nos engañemos. Estamos hablando de agilidad. El origen de los problemas no hay que buscarlo en los procesos, los más importantes estarán localizados en alguno de estos elementos: toxicidad de la empresamotivación  o competencia de las personas; pero sea cual sea, ese no es el origen real. El real se encuentra en un nivel más profundo, porque... alguien dirige la empresa, contrata y gestiona a las personas, y está tropezando en las asignaturas pendientes de la gestión ágil:  motivación, organizaciones basadas en equipos y  gestión del talento  (que no de los recursos humanos).

Este artículo fue publicado originalmente el 29 de enero de 2009 en navegapolis.net

 

equipoAl aumentar el tamaño del equipo del proyecto, disminuye la productividad individual. Esta es una percepción recurrente, o al menos a mi me da esa impresión, y por eso me ha llamado la atención este consejo(*)del consultor de EE Times, Jack Ganssle:

Ponga a los mejores en los proyectos pequeños.
Los mejores desarrolladores son seis veces más productivos que el más flojo del equipo, pero sólo cuando se mide a ambos en proyectos pequeños.
A medida que el proyecto crece el mejor y el peor son igual de improductivos. Los grandes proyectos tienen grandes cantidades de ruido, reuniones, informes, e-mail...
Un espabilado atiende en las reuniones a la misma velocidad que un torpe.
 

(*) Este post se publicó originalmente el 4 de septiembre de 2007 en navegapolis.net. El artículo enlazado ya no está disponible. Otra referencia de Jack Ganssle a la misma idea se encuentra en The Embedded Muse 102, - copia local en navegapolis-

 

foto

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 usarmetodologí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."

 

Publicado originalmente en navegapolis.net el 3 de julio de 2011

 

brujula 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? ¿Os imagináis que un arquitecto hiciera lo mismo?"

10 08 01

Aprendimos a redactar antes requisitos del sistema, la especificación de requitisos del software, el plan de proyecto, gestión de riesgos, matrices de trazabilidad... y entonces nuestros clientes no dijeron que no podían definir el producto desde el principio, que empezáramos cuanto antes, aunque no tuviéramos una descripción completa, y que ya nos irían diciendo.

Aprendimos a basar la calidad de nuestros programas en los procesos de nuestra empresa, y al hacerlo descubrimos sus limitaciones frente al talento de las personas.

10 08 02

A falta de una, aprendimos dos formas de abordar los problemas: desde la planificación y la ingeniería de procesos, y desde la agilidad y las personas; y cuando ya sabemos hacer las cosas "blancas" o "negras", descubrimos que los proyectos reales son de tonos grises más o menos claros. 

10 08 05

 

Y en este aprendizaje hemos creado dos bandos: planificación y agilidad, y hemos perdido la cabeza creando y etiquetando metodologías en cada bando: Scrum, XP, Kanban, Lean, Scrumban... 

10 08 03

 

El consejo es huir del "etiquetalismo metodológico, y ser prágmáticos.  Conocer las diferencias de base y enfoque entre planificación y agilidad: las fortalezas y debilidades de cada una y a partir de ahí, los "artefactos" de las diferentes doctrinas son simples prácticas, no "metodologías". Unos útiles para construir planes, otros para mantener requisitos cambiantes. Con sprints podemos iterar el producto en pulsos de tiempo prefijado (sprints),  con técnicas kanban iteraremos el producto en un flujo continuo de crecimiento. 

Cuanto mayor sea el inventario de prácticas que conozcamos, las fortalezas y debilidades de cada una, más recursos tendremos como gestores y más flexible será nuestro trabajo, y nuestra capacidad de adaptarlo a las característcas de cada proyecto. 

 

10 08 06

¿Por qué no se va a usar en un proyecto con gestión predictiva, planificación de póquer para conducir una reunión de estimación por juicio de expertos?, o un tablero de gestión visual Kanban.
¿Por qué no se pueden aplicar criterios de institucionalización de CMMI a las prácticas empleados en una empresa ágil?

10 08 07

Este artículo se publicó originalmente el 22 de agosto de 2010 en navegapolis.net

Vaya usted a saber por qué, pero sí que es frecuente encontrar entre los programadores a personas polarizadas en uno de estos tipos: 

 

  • El pesimista: Programador que siempre está advirtiendo de problemas y fallos. De carácter difícil.
  • El cowboy: Le gusta programar, y sobre todo hacerlo a su manera, y lo que a él le parece importante o necesario, lo haya pedido el cliente o no.
  • El disciplinado: es el carácter preferido de los gestores. Hace lo que le dicen sin cuestionar.
  • El rey de las reuniones: para el que todas las decisiones necesitan una buena reunión.

tipos p

Me ha llamado la atención esta clasificación que planteó Aaron Ruhnow en la exposición de Agile 2007Consciously Evolving an Agile Team, pero no coincido en que impliquen también si técnicamente son buenos o malos.

No necesariamente por ser disciplinado, por ejemplo, se es también "programador experimentado y capaz", como dice Aaron: que una cosa es la personalidad y otra la cualificación técnica.

Desde mi punto de vista los estereotipos puros serían ocho y no cuatro:

estereotipos programadores

 

Y me quedo, y por este orden, con el 2, 4, 6 y 8.

(*) Este artículo se publicó originalmente en navegapolis.net el 29 de agosto de 2007