Cita

Escrito el 13 de Junio de 2008 a las 10:12 

Cada vez que siento que tengo las cosas bajo control, se qué tengo un problema: no estoy en contacto con la realidad”

Xp2008, Katti Vilkki, Nokia Siemens Networks

Categorías: Citas, Gestión de Proyectos
Tags: ,,,,,,
2 comentarios | Compártelo

Just say no

Escrito el 12 de Junio de 2008 a las 12:16 

Es un tema con el que choco recurrentemente en los últimos tiempos, posiblemente porque estamos enfrascados en varios proyectos de implementación de Scrum y es algo que, por lo que he visto a lo largo de mi carrera y como confirma la literatura, ocurre constantemente en todas las industrias y en casi todos los equipos: no saben decir que no.

Típicamente comenzamos a diagnosticarlo cuando los gerentes, jefes de proyecto o dueños de producto encargan algún tipo de iniciativa de mejora. Puede ser la adopción de Scrum o la introducción de cualquier otro tipo de práctica o herramienta. El caso es que en muchas ocasiones, pasado el impulso inicial, se va abandonando la iniciativa. Cuando hacemos exploraciones retrospectivas e intentamos ver por qué se ha abandonado, los equipos se quejan: “los jefes nos marcaron otras prioridades“. Y efectivamente, el equipo está sobrecargado de trabajo y no tiene tiempo para mantener una pila de impedimentos, realizar retrospectivas o planificar sus sprints. Pero entonces suelo preguntar: “¿Os han pedido explícitamente que abandonéis estas prácticas?“. Y los equipos suelen reconocer que no, que no ha sido una petición explícita, pero que cuando te piden que atiendas urgentemente algo y que tienes que hacerlo para mañana no pueden hacer otra cosa que atenderla.

Dependiendo de la tolerancia al interrogatorio y la tortura del equipo :twisted: , prosigo con la exploración: “¿Avisásteis al Jefe que si teníais que atender estas tareas urgentes, debíais dejar de hacer el resto de cosas que os pidieron?“. “No…Pero se sobreendiende“. “No, no hace falta porque ya sabemos lo que nos diría“.

Y así, el equipo tiene su parte de culpa en la prolongación del esquema irreal de la carga de trabajo, lo que en Agile se conoce como “la creencia en la magia” (algo ocurrirá que hará que todo encaje en tiempo y presupuesto), simplemente porque no es capaz de decir que no. En algunos casos, pocos, que me haya encontrado, realmente no se le permite a los equipos decir que no, pero en otros muchos se trata de un problema de habilidad de comunicación, negociación y persuasión por parte de los equipos. Al fin y al cabo, predecible y comprensible: nadie se ha tomado su tiempo en enseñar a un programador a negociar, y de todas maneras muchos de ellos ni siquiera llegan a ver la utilidad de algo que no compile :twisted: . Por supuesto, esto no exime de culpa a los jefes que quieren todo hecho para ayer, ya hablaremos otro día de ellos. De hecho, probablemente ellos no han sabido tampoco decirle que no al cliente, al comercial que ha vendido la moto o a su propio jefe que pide las cosas acostumbrado a la “barra libre”.

Y así logramos lo que en Lean Software Development se conoce como Trashing. Es lo mismo que le ocurre a un ordenador por encima del 100% de carga: pasa más tiempo gestionando el intercambio de tareas que realmente ejecutando las tareas, y al final nada funciona. Solo que en el cerebro humano esto ocurre en cuanto superamos más o menos el 80% de capacidad, algo parecido a lo que ocurre en carreteras y autopistas. Al fin y al cabo, cuando hay un atasco o tráfico lento, en realidad cabrían más coches entre coche y coche, ¿No? Efectivamente, no hay que llegar al 100% para provocar un atasco.

Me he encontrado con empresas que tienen listas de 300 implementaciones o mejoras pendientes, cuando su capacidad de producción es de en torno a 3, 4 o 5 historias al mes, lo que significa que tienen una lista de trabajo de seis o siete años (verídico), y eso sin contar conque la lista sigue creciendo y actualizándose constantemente. Todo por no seguir una simple práctica: decir que no. Para aquellos que quieren conservar las peticiones a título informativo o como recurso de lo que al usuario le gustaría, basta con establecer una lista de “Nunca”, como sugería Mary Poppendieck en un seminario al que asistí esta semana.

Al fin y al cabo, cuando Google ofrece a los empleados un 15% de tiempo para asuntos libres y personales, en realidad hace algo de trampa. En realidad, todos dedicamos en torno a una hora al día a desayunar, ir al baño, mandar correitos chorra, leer un blog, chatear por el messenger con un compañero, revisar la cuenta del banco y demás asuntos personales. Una hora al día representa en torno a un 13% de tiempo. Lo único que Google dice es “esta bien, SABEMOS que hacéis estas cosas en jornada laboral y nos parece bien, siempre que el restante 85% lo dediquéis a esta compañía, y lo hagáis al máximo nivel”.

Otra de las cosas que Google hace, como muchos sabéis, es reservar otro 20% de tiempo para proyectos de innovación. Y este tiempo debe ser respetado. El riesgo de esta política es que los equipos se queden más tiempo del que les toca para atender a una demanda siempre creciente de tareas, incapaces de atenderlas todas en el 65% de tiempo que les queda para el desarrollo. Muchas de estas tareas, por cierto, caerán en ese 60% de funcionalidades que, según Standish y según mi experiencia directa y la de todos los desarrolladores con los que he trabajado hasta ahora, se usan rara vez o nunca. YAGNI. Quemar recursos, dinero y tiempo de la empresa y de las personas.

Así pues, dear teams in the way of Agilehood: Just Say No. No a más trabajo del que razonablemente se puede desarrollar. Y os prometo una cosa: cuando los equipos tienen responsabilidad y se les da cierta holgura en la dedicación, la productividad se dispara. Se escribe mejor código, más limpio, con menos errores que atender y corregir en los próximos meses. Hay tiempo para aprender mejores prácticas y nuevas tecnologías. Hay tiempo para refactorizar, implementar arquitecturas mejores, mejores herramientas… Y esto, junto con un equipo motivado por el avance, es el motor del aumento de la productividad en Agile. Implementar únicamente el scrum diario, un tablón y seguir sobrecargando al equipo no llega siquiera a atisbar las mejoras reales que pueden lograrse en una implementación completa de los principios que operan tras Scrum.

Y por hoy ya vale, que me está saliendo un ladrillo considerable.

Actualización: Ofú, meneado… Mejor voy cerrando los comentarios… :-D :-D :-D

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,,,,,,
13 comentarios | Compártelo

“No podemos hacerlo”

Escrito el 4 de Junio de 2008 a las 19:43 

Como decía Ford, “Tanto si crees que puedes hacerlo como si no…Tienes razón”. Esto es algo que deberían grabarse a fuego algunos de los jefes de proyecto con los que trabajo de vez en cuando. Típicamente estamos en medio de un proyecto de implantación metodológica o de consultoría organizativa, y desde Proyectalis proponemos algún cambio que, a nuestro juicio, proporcionaría una mejora significativa en los equipos y la empresa. Entonces surge el “no, eso no podemos hacerlo”, seguido lógica e indefectiblemente por nuestro perenne “¿por qué?”.

En ese instante suelo observar que nuestro interlocutor eleva los ojos un instante, sígno de que está pensando, construyendo, artículando y argumentando su respuesta, y comienza la lucha: “es que blablabla uno”. Y nosotros, “bueno, pero eso, blablabla solución uno”. “Ya, pero es que además blablabla dos”. “Si, pero blablabla solución dos”. Así ad infitum (o ad nauseam, lo que primero llegue ;-) ).

El caso es que cuesta el mismo trabajo ponerse a pensar las razones por las que no podemos hacer un determinado cambio o esfuerzo que pensar en cómo podría realizarse dicho cambio, o cuáles serían las condiciones en las que dicho cambio sería viable. Posiblemente incluso se detecten los mismos impedimentos que en el enfoque anterior, pero al mirarlos desde la perspectiva de “qué tendriamos que hacer para solucionar esto” los resultados son más constructivos, más positivos y sobre todo existen más posibilidades de que consigamos descubrir una manera de implementar el cambio o incluso definir y trazar el plan de acción.

Pensad además que cada “pero” suele encerrar un paradigma amenazado.

Categorías: Citas, Gestión, Gestión de Proyectos
Tags: ,,,,,,
9 comentarios | Compártelo

Scrumsourcing

Escrito el 22 de Mayo de 2008 a las 15:57 

Me lanza Luís (al que añoro leer más a menudo, pero ando hasta arriba) un guante que recojo encantado esperando que pueda seros de utilidad. Luís describe la típica situación de un cliente que va descubriendo lo que en realidad necesita conforme va avanzando en el proyecto. Es la típica situación que los técnicos describen como “el cliente no sabe lo que quiere” y que los profesionales de Agile, Lean y Scrum describimos como “en un sistema de dimensión compleja, los requisitos son emergentes”. No es culpa del cliente (aunque de todo hay en la viña del Señor): es que no hay otra forma de asegurarse de acertar en el resultado de un proyecto que incrementar los ciclos de feedback cliente-proveedor mediante un desarrollo iterativo e incremental, con entregas de producto funcional y testable al final de cada iteración, algo que va en contra de lo que académicamente se ha postulado durante los últimos treinta años en el mundo de la gestión de proyectos software, que se ha basado típicamente en la aciaga herencia de los desarrollos industriales en cascada.

Hay soluciones basadas en Scrum que funcionan en entornos como el que comenta Luís (os lo aseguro), pero el cliente debe estar dispuesto a un modelo más colaborativo. Me ocurre con frecuencia que, cuando comento a un cliente la posibilidad de que contrate a sus proveedores en un modelo de “fixed time-fixed money” con funcionalidad variable (es decir, contrato al equipo por seis meses y a ver cuánto somos capaz de hacer) me dicen que estoy loco, que entonces el proveedor se dedicará a tocarse las narices todo ese tiempo y que no entregará casi nada al final del proyecto. Pero sin embargo cuando se lo comparo con los contratos de outsourcing o bodyshopping comienzan a verlo más claro: el principio es el mismo, y la forma de controlar el progreso es involucrarse en el mismo de forma diaria.

De hecho, los contratos “fixed time, fixed money, fixed functionality”, es decir, contratos basados en un supuesto conocimiento perfecto del futuro y la evolución del producto a lo largo de meses y meses de trabajo, son una aberración en un mundo de productos complejos como el software y los sistemas, de forma que lo que ocurre en realidad es que el cliente trata de trasnferir todo el riesgo tecnológico y de “mutación” al proveedor, y este se blinda metiendo más colchones que pikolin. Así expresado no parece muy colaborativo, ¿Verdad? Pues por eso no funciona. ;-)

Algunas fórmulas intermedias que suelo recomendar incluyen lo que llamo el contrato de “scrumsourcing”, en el que los objetivos se dividen segun MOSCoW (Must, Ought, Could, Wish) y se firma, por ejemplo, hacer un 100% de los Must, un 80% de los Ought y un 50% de los Could en un tiempo determinado por el proveedor. Cualquier funcionalidad o historia en el que no se haya empezado a trabajar puede ser cambiada en cualquier momento por otra de valor / peso similar. Y en caso de que el cliente esté satisfecho con el nivel alcanzado en cualquier punto del proyecto, o al contratio, piense que el proveedor no avanza al ritmo adecuado, puede cancelar el contrato en cualquier momento por un coste equivalente al 20% de lo que quede por hacer. Así, dividimos el riesgo entre todos.

La típica queja que suelen elevar los proveedores es que un enfoque de este tipo les obliga a diseñar el sistema de una forma altamente modular y flexible para soportar los cambios de funcionalidades futuras. Típicamente lo expresan como “no se puede”, pero el caso es que miles de empresas de todo el mundo trabajan así, o sea que se puede, pero requiere un esfuerzo y una disciplina. Y por otra parte, ¿no es más valioso para el cliente contar con una arquitectura modular y flexible que permita incorporar cambios y nuevas funcionalidades en el futuro? ¿No es incluso mejor para el proveedor, de cara a la recurrencia del cliente?

En este tipo de enfoques, lo ideal es comenzar contratando a proveedores para proyectos de bajo riesgo y corta duración, seleccionando a los que mejor funcionan para proyectos a mayor duración y con un impacto mayor en la compañía. Esto tiene dos ventajas: por una parte, como comentaba, podemos seleccionar a los proveedores que funcionan bien con un modelo ágil. Y por otro podemos comenzar a acostumbrarnos al proceso con proyectos de bajo riesgo e ir perfeccionando los mecanismos de control, visibilidad y feedback.

Que por cierto, para este tipo de cosas hay una consultoría que… O:-)

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,,,
8 comentarios | Compártelo

Orcos a las puertas

Escrito el 19 de Abril de 2008 a las 10:52 

Reflexionaba esta semana, junto con los jefes de proyecto de una de las empresas con las que estamos trabajando actualmente, respecto al problema histórico de comunicación entre las áreas de negocio y las áreas técnicas, tantas veces reflejadas, por ejemplo, en los chistes de Dilbert. Es un problema comprensible: las motivaciones muchas veces están enfrentadas (el área de negocio quiere más cosas en menos tiempo, el área de sistemas quiere más tiempo para dedicar a menos cosas) e incluso los lenguajes y el bagaje personal y profesional son tan difererentes que lo raro es que surja una buena comunicación.

Scrum, como sabéis, establece un artefacto (la pila de producto) que permite a la gente de negocio (Dueños de Producto) manejar a la gente técnica (Scrum Master y equipo). Sin embargo, uno de los problemas típicos que nos encontramos en las implantaciones de Scrum en las que trabajamos es el de involucrar a la gente de negocio en el proceso. La implantación de Scrum suele surgir por iniciativa de los técnicos, cosa rara si pensamos que la gente de negocio debería tener una formación y un foco más “humanista” y deberían haber sido los primeros que planteasen formas de colaborar y comunicarse con las áreas de producción (notese el matiz respecto a “áreas productivas”, que esas deberían ser todas, negocio y sistemas).

Al surgir desde el área técnica, las áreas de negocio tienden a veces a considerarlo “cosas de frikis” y pasar muy mucho del tema. Por eso nuestro enfoque de implantación conlleva muchas acciones dirigidas a las áreas de negocio. El objetivo final es que las áreas de negocio nombren un determinado número de Dueños de Producto que sean los que canalizacen y prioricen las peticiones de todos los interesados, clarificando al equipo lo que deben hacer en cada momento. Con eso evitamos también el bombardeo de peticiones “no oficiales” a las que típicamente se ven sometidos los equipos de desarrollo, peticiones cuya prioridad no está clara y que la mayor parte de las veces ni cuentan con una justificación de negocio sólida ni computan luego en la productividad del equipo, ya que se hacen “de tapadillo”.

Lamentablemente, el enfoque de envagelización y colaboración no siempre funciona, y los equipos de desarrollo se enfrentan a peticiones y negociaciones que les llueven por todas partes. Es como enfrentarse a un enemigo muy superior en número y recursos. ¿Y qué podemos hacer en una situación así?

Reflexionabamos sobre esto, como os decía, y tratando de explicar el enfoque que nosotros proponemos como siguiente nivel de presión hacia el cambio corporativo se me ocurrió la metáfora de los “orcos a las puertas”: La batalla del abismo de Helm.

Abismo de Helm

En la batalla del abismo de helm, los humanos se parapetan en un fortaleza que cuenta con un único punto de acceso: un estrecho puente que obliga a los miles de orcos que los asedian a formar casi de uno en uno, con lo que en las puertas de la fortaleza se monta lo que los KODT llaman una “conga de la muerte”, una estrategia perfecta para lidiar con un enemigo muy superior en número y que ya fue utilizada por los 300 espartanos en el paso de las termópilas.

¿En qué consistiría la estrategia “orcos a las puertas”? En primer lugar, en blindar el área de sistemas. Kniberg lo describe muy bien en su libro. Esto se puede hacer a un nivel organizativo o discilplinario, aleccionando a todo el mundo para que no atiendan peticiones de ningún tipo que no vengan del Dueño de Producto de Sistemas, o incluso físicamente, co-alocando a todo el equipo y dejando pocas vías por las que los extraños puedan acceder y pulular. Incluso sentar al Dueño de Producto de Sistemas al lado de la puerta para que actue como guardián del área.

El segundo paso es precisamente ese: nombrar a un Dueño de Producto de Sistemas encargado de lidiar con los orc…Digooo…Con la gente de negocio. Nada fácil, os lo aseguro. En la mayoría de los casos una estraegia pasivo-agresiva como esta suele acabar en el despacho del CEO, pero a veces es precisamente esto lo que hace falta. Por eso es también muy importante preparar documentación sobre todos los intentos previos que se hayan hecho para que el área de negocio asuma la responsabilidad y la competencia que le toca sobre la definición y priorización de los proyectos. Eso nos permitirá justificar el movimiento defensivo.

A veces lo que ocurre es que el área de negocio está encantada con tener un interlocutor único en sistemas, y la estrategia “orcos a las puertas” se convierte en una mejor práctica corporativa. Pues estupendo. De hecho, no se vive tan mal en el abismo de Helm, siempre que uno tenga un puesto calentito, dos buenas pantallas TFT y unas cuantas herramientas de desarrollo… ;-)

Categorías: Gestión de Proyectos
Tags: ,,,,,,,,
2 comentarios | Compártelo

Cosas curiosas que llevar en la mochila (The Agile Coach Toolkit)

Escrito el 15 de Abril de 2008 a las 20:12 

Podéis considerarlo un meme si queréis, me encantaría cotillear en vuestras mochilas ;-)

Ah, sí… Y el portatil con su cargador, claro… ¿Que si pesa? Como un palet de ladrillos, la condenada… :-D

Categorías: Gestión de Proyectos
Tags: ,,,,,
7 comentarios | Compártelo

Ni chapa

Escrito el 24 de Marzo de 2008 a las 13:31 

Una de las muchas y alarmantes constantes que me encuentro en los cursos y demás actividades que hacemos relacionadas con la gestión de equipos y proyectos es que siempre hay alguien que pregunta algo así como “Todo esto de la motivación está muy bien, pero ¿qué hacemos si un empleado se pasa el día sin dar un palo al agua?“. 8O

He de confesar que las primeras veces que me enfrenté a este tipo de cuestiones no me lo podía ni creer. Mi reacción fue la ya conocida por estas páginas como “conejo alumbrado por faros de camión“: no sabía si saltar a la derecha, saltar a la izquierda o encomendarme al Sagrado Monstruo Volador de Espagueti (alabado sea su tallarinesco apéndice). Vamos, que me pensaba que me estaban filmando con cámara oculta. Pero meditándolo posteriormente me di cuenta de que también ha sido una constante en mi devenir laboral la existencia de algún que otro (a veces multitud de ellos) elemento nichapante. El típico tío que no se suele meter con nadie, pero que nadie sabe muy bien a qué dedica su día ni cuáles son sus funciones, y que en cuanto se le intenta sorprender con un passing-brown despliega un envidiable arsenal de excusas y justificaciones para, en última instancia, seguir haciendo nichaping.

Ahora en serio, en mi humilde opinión este tipo de personajes son como un cancer para la empresa. Y digo cancer porque los jodíos metastatizan. Se extienden. Mucha gente se harta de partirse el lomo luchando por la empresa para ver como a final de mes el vago de turno se lo lleva igual de calentito que ellos (a veces más), e incluso en multitud de casos que conozco, les toca la misma cantidad de bonos o incentivos que al resto. La única explicación que se me ocurre para esto último, y es algo en lo que abundaré en un par de párrafos, es que los jefes huyen del enfrentamiento o la confrontación y piensan que “café para todos” es la política más democrática, pacifista y buenrrollista. Error. Craso error. Postdata para mi mismo: hablar un día del buenrrollismo como estrategia de gestión :-D

Así pues, hecha la desagradable metáfora, ¿cómo enfocamos un cancer en la empresa? Bien, de nuevo en mi humilde opinión, habría que empezar por una serie de sesiones de radioterapia y quimioterapia. A veces ocurre que el compañero nichapante o conflictivo manifiesta los síntomas de una falta de confianza, un exceso de perspectivas al respecto de su rendimiento, falta de preparación o la falta de compromiso con el equipo, el proyecto o la compañía. A veces se trata simplemente de que la persona no sabe lo que esperan de ella. En estos casos se pueden diseñar tratamientos: definición correcta de las responsabilidades, objetivos y expectativas del cargo, formación de la persona para que alcance el rendimiento esperado, coaching, team-building… No se puede empezar con las medidas de presión si primero no hemos agotado las vías constructivas. Es de cajón.

Pero a veces ocurre que si quieres arroz Catalina. Que no. Que nasti. Que no hay manera. Y en estos casos, sorpréndome, todavía la gente se pregunta “¿qué hacemos?”. Bien, la siguiente fase del proceso oncológico es la extirpación quirurgica. Esto no siempre quiere decir a la puñetera calle. A veces basta con reasignar esta persona a otro departamento, grupo de trabajo o proyecto en el que se sienta más a gusto. En este tipo de movimientos es necesaria una elevada dosis de comunicación con la persona para que entienda que no se trata de un castigo o una penalización, pero que también entienda que es el primer toque de clarines. Si con todo esto seguimos mal… Pues señores, ¿a qué estamos esperando?

La empresa es un ente que funciona en un mercado determinado. Y los mercados son, por definición, eficientes. La propia empresa es de hecho un mercado y debería ser tan eficiente como fuera posible. Las personas trabajan para la empresa, en vez de dedicarse a la contemplación de la naturaleza y a hablar con Diox, porque les pagan por ello. Si no reciben la suficiente cantidad de dinero por su trabajo, rendimiento y talento, probablemente acaben encontrando otras empresas que sí les paguen lo suficiente, y así se van creando los niveles salariales en función de la disponibilidad del perfil y el rendimiento de la persona. Ahora bien: ¿Qué pasa si el empleado no aporta la cantidad de trabajo esperada por el salario ofrecido y sin embargo la empresa no prescinde de él? Pues señores, es de libro: se produce una pérdida de eficiencia que, en última instancia, paga la empresa, o sea todos los demás, que son los que van a tener que cargar con el hueco de trabajo no generado o, en el peor de los casos, con el cierre de la empresa por poco competitiva.

Y si esto está tan claro, ¿Por qué los gerente sistemáticamente se enfrentan a la duda sobre qué hacer con estas personas? Típicamente, por miedo o aversión a la muy desagradable tarea de echarse a una persona a la cara y decirle que está en la calle. Que lo entiendo. Que a nadie le gusta a menos que sea un sociópata (que los hay, oiga, yo los he visto :-D ). Pero que alguien tiene que hacerlo, y no puede uno aceptar la carga de la dirección pero limpiándole las partes que no gustan. Yo mandar sí, y cobrar también, pero responsabilidades desgradable no, mirusté. Pues magnífico.

En otros casos ocurre que el gerente en cuestión se enfrenta a la tarea de rellenar el hueco que dejaría esta persona, y se le antoja una tarea imposible o suficientemente dura como para preferir el “mal menor” de aguantar con el elemento nichapante (también conocido en el argot de un buen amigo como “saco terrero” :-D ). Pues error. El “mal menor” es aguantar dos o tres meses sin esta persona y echarle horas al proceso de selección. O incluso apechugar con una persona menos y repartir su salrio en forma de bonos e incentivos entre el resto del equipo. El mal mayor es que esta persona siga minando la productividad de la empresa y la moral de sus compañeros, estableciendo además un mensaje muy claro para todos los trabajadores: “no passsa nada si no das ni chapa, aquí no echamos a nadie”.

Más razones: el buenrrollismo. Que no se estrese la gente pensando que la pueden echar. Vease el argumento anterior.

Otra razón más: la estrategia aerostático-maquiavélica. En estos casos (pocos los que he visto, pero notables todos ellos) uno se carga de una cierta cantidad de lastre para que, cuando lleguen los periodos de vacas flacas (que en ciertos sectores son cíclicos), poder desprenderse de los mencionados sacos terreros justificando por un lado el recorte de personal pero sin perder por el otro productividad y capacidad.

Y otra más: “no depende de mí”, estrategia reactiva, también conocida como lloriqueo vulgar. El gerente en cuestión no tiene autoridad para despedir al elemento nichapante. Esta es fácil: comuníqueselo a quien sí tenga la responsabilidad. Si no reacciona, comience a disminuir sus previsiones de producción, justificándose en la influencia negativa de esta persona. Si aun así no passsa nada, búsquese otra empresa, esa no le conviene.

Por último, una salvedad: if you pay penauts, you’ll only get monkeys. O lo que es lo mismo: si pagas por debajo del mercado, obtendrás perfiles por debajo del mercado. Pero tener a gente a precio de mercado y produciendo por debajo…Pues mire usted, no.

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,,,
30 comentarios | Compártelo

Testing

Escrito el 18 de Marzo de 2008 a las 13:40 


MWAA-HAHAHA!! ROTFLASTC!! :-D :-D :-D :-D

Vía Sebastian Bergmann, encontrado en Flickr buscando “Agile Software Development”.

Categorías: Gestión de Proyectos
Tags: ,,,,,,,
Deja un comentario | Compártelo

Scrum y XP desde las trincheras

Escrito el 26 de Febrero de 2008 a las 19:51 

Uno de los libros que más recomendamos para la gente que quiere aprender más sobre Scrum y, especialmente, cómo implementarlo de forma efectiva es el magnífico “Scrum&XP from the trenches” de Henrik Kniberg. En este libro Henrik no se dedica a profundizar en los conceptos teóricos de Scrum, su procedencia y su relación con las metodologías ágiles o las ventajas de este tipo de metodologías frente a los enfoques más tradicionales o pesados. En su lugar, Henrik pasa directamente al meollo de la implementación de Scrum con un enfoque eminentemente práctico y holístico: qué hemos probado, qué fue mal, que hicimos en su lugar, por qué nos funciona mejor…

El libro está disponible de forma gratuita en InfoQ, un magnífico recurso para los interesados en las metodologías ágiles y el desarrollo de software en general. Dada su naturaleza abierta, hace unos meses contactamos con Henrik y le contamos que utilizábamos gran parte de su libro en la preparación de nuestros cursos o en los proyectos de consultoría e implantación de Scrum en empresas, y como agradecimiento nos ofrecimos a traducirlo al castellano. Henrik nos ofreció su colaboración y visto bueno desde el principio, y fruto de dicho ofrecimiento queremos poner a vuestra disposición el primer borrador de Scrum y Xp desde las trincheras en castellano.

La URL por si queréis incluirla en vuestros blogs sería http://www.proyectalis.com/scrum-y-xp-desde-las-trincheras. Espero sinceramente que lo disfrutéis tanto como yo. ;-)

Categorías: Gestión de Proyectos
Tags: ,,,,,
3 comentarios | Compártelo

Certificación Scrum Master en Febrero - Madrid

Escrito el 30 de Enero de 2008 a las 19:37 

Me comentan que todavía hay algunas plazas disponibles para el seminario de certificación Scrum Master que se celebrará los próximos días 14 y 15 de Febrero en Madrid. Creo que es una buena oportunidad para aquellos que estén empezando con Scrum o quieran perfeccionar sus habilidades como Scrum Master e intercambiar experiencias con otros profesionales. Razón aquí.

Por lo demás, si las fechas no os cuadran, Madrid os pilla mal o el inglés os supone una barrera, ya sabéis que en Proyectalis organizamos cursos similares para empresas en castellano y con una duración de dos días o tres tardes intensivas (fin de la cuña publicitaria ;-) ).

Para saber más sobre el CSM, mirad aquí o aquí.

Categorías: Formación, Gestión de Proyectos
Tags: ,,,,
Deja un comentario | Compártelo

Experiencias reales con Scrum

Escrito el 21 de Enero de 2008 a las 12:40 

Como sabéis, el pasado mes de Noviembre estuve realizando un curso de Scrum para la empresa Peopleware. Es para mi una gozada leer hoy cosas como esta:

Scrum y Teletrabajo

Ya hemos terminado el primer apretón y estamos en el segundo, así que hay algunas conclusiones al respecto de trabajar con una metodología como Scrum, pero antes de nada, en líneas generales, el perfil del equipo de Osmius:

* Somos un equipo pequeño y no queremos crecer a más de 7 u 8. Preferimos dividir y tener otros equipos.
* Hay confianza: Tú sabrás cómo te organizas y cómo cumples tus compromisos con el resto.
* El dueño de producto es interno. No hay un cliente claro presionado aunque abrimos los requisitos además del código.
* En media nos conocemos y hemos trabajado juntos hace… unos diez años.
* Nos gusta un montón el proyecto. Pero tampoco nos importaría empezar otro en unos meses.
* En general preferimos tiempo libre a dinero.
* El equipo es partícipe de los beneficios del proyecto.
* Todos bailamos o cantamos fenomenal

Bien, pues resulta que además de meternos con Scrum hemos empezado con el teletrabajo, y algunas conclusiones han sido:

* Scrum nos ha metido presión. Sensación de ¡vamos, vamos, vamos!
* Somos más efectivos que antes. Cerramos más tareas y cuando lo ves no te lo crees.
* El teletrabajo es un lujo. Ahorro de tiempos, buenas sensaciones…
* Hay que tener contacto diario. El Scrum diario con Skype y las horas en la hoja de cálculo Google han sido fenomenales.
* Toda la semana en casa no mola. Nosotros quedamos en la ofi lunes y jueves. Menos es desagradable.
* Cada uno es responsable de sus tareas para bien y para mal, y los problemas son de todos… o nos vamos a la mierda.
* Hacemos demo en cada apretón y cada dos o tres apretones sacamos versión. Nos da sensación de avance.

Esta es la gráfica del Apretón de la alpha de Osmius 8.01. Según pasan los días vamos quitando trabajo siendo la idea estar con la línea roja por debajo de la línea azul de pendiente constante. En otra ocasión podemos comentar algunas obviedades según sean las panzas y el aspecto de la curva ¿no?

Por cierto el jueves 7 de febrero a las 20:30 hacemos demo en Peopleware. Pasaos sin más o si preferís escribidme a joseluis [puntito] marina [arrobita] peopleware [puntaco] es.

Así que ya sabéis: si queréis avanzar en vuestro camino hacia la productividad, la motivación y una vida personal y profesional más satisfactoria, Scrum puede ayudaros, y nosotros estamos a vuestra disposición.

Categorías: Gestión de Proyectos
Tags: ,,,,
Deja un comentario | Compártelo

Cita

Escrito el 17 de Enero de 2008 a las 23:52 

There are (software development) organizations
that are more productive than others. ‘Luck’ is not the
whole story; you need to look for ways to improve.”

Myers, 1998, vía una presentación de Jeff Sutherland.

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,
3 comentarios | Compártelo

Manda webs…

Escrito el 19 de Diciembre de 2007 a las 10:58 

Hace un par de semanas puse una oferta de empleo en Infojobs. Buscamos gestores de proyectos en el ámbito de las telecomunicaciones y las tecnologías de la información, con al menos tres años de experiencia y manejo del inglés con soltura, aunque las principales características que evaluamos son unas excelentes habilidades interpersonales, una alta capacidad de análisis y síntesis de los problemas y oportunidades observados en el desempeño de sus funciones, un conocimiento tecnológico adecuado a los proyectos en los que vaya a participar y algo de formación específica en las técnicas, metodologías y herramientas de gestión de proyectos. Se trata de un puesto orientado a trabajar en proyectos de nuestros clientes más que a engrosar la estructura interna de la empresa, eso sí, y buscamos titulados en Ingeniería Superior de Telecomunicaciones, Informáticas o con formación/experiencia equivalente. En el fondo, en realidad, lo que buscamos es gente con pasión y con talento, pero claro, eso es dificil de cuantificar en primera instancia.

Entre las cosas que ofrecemos están (cito) “la flexibilidad de horarios, el compromiso de formación interna y externa, las facilidades para el Teletrabajo, una filosofía OpenBusiness y la oportunidad de participar en un proyecto jóven con gran proyección de futuro“. Además de una banda salarial de entre 24.000 y 36.000 euros. Que digo yo que no está nada mal.

A la oferta han respondido 61 candidatos, de los cuales unos diez cumplían muy bien con las expectativas que tengo al respecto (al resto, gracias por el interés, y a los 21 que se han descartado por estar absolutamente fuera de nuestro área de interés…En serio, replanteaos la estrategia de apuntaros a todo lo que se mueva, que quema mucho, a vosotros y a nosotros). A los finalistas se les ha mandado un correo explicando mejor el proceso, el timing que estamos manejando, algunas características del puesto y pidiendo algo más de información sobre su situación actual, lo que les ha gustado de la oferta y de la empresa… No he mandado un correo similar a los 30 restantes más por falta de tiempo y de una utilidad en Infojobs que permita mandar un mensaje-tipo a una selección de perfiles (tendría que ir abriendo uno por uno y cogiendo las direcciones de correo…Señores de Infojobs, tomen nota, que esto es consultoría gratis). De todas maneras nos quedamos con estos perfiles para posibles necesidades en el futuro, ya que en general son interesantes.

Bueno, pues de los seleccionados y contactados el 75% ni siquiera me ha contestado al correo, y de eso hace ya una semana. Dicen algunos amiguetes que Infojobs tiene herramientas que te apuntan automáticamente a las ofertas en función del campo de conocimiento, salario, ubicación… Yo creo recordar que Infojobs te avisa de estas ofertas, pero dudo que te pueda suscribir directamente sin tu aprobación específica, y si es así me parece muy mal, sinceramente.

Volvemos a mis preguntas de siempre:

PD: El proceso sigue abierto, por si algún lector se siente cualificado y con ganas… Hay otro puesto más estructural, peor pagado pero con mayor apego y responsabilidad en la empresa. Lamentablemente para vosotros, ese tiene novia hoy por hoy… ;-)

Categorías: Gestión de Proyectos, Negocios y empresas
Tags: ,,,,,,
29 comentarios | Compártelo

Calendario compacto 2008

Escrito el 6 de Diciembre de 2007 a las 13:52 

Micropost: calendario compacto 2008 ya disponible. Razón aquí.

PD: Ya que váis de mi parte, portaos bien y no dejéis de visitar las 37 utilidades para GTD, productividad y gestión del tiempo. Alucinante.

Categorías: Gestión de Proyectos, Gestión del Tiempo
Tags: ,,,,
2 comentarios | Compártelo

Un comentario del blog

Escrito el 30 de Noviembre de 2007 a las 19:59 

El scrum lo descubrí hace unos dos meses, a través de tu blog y me documenté un poco.

Hace un mes, en mi empresa ganamos dos proyectos idénticos que duraban 20 días. Yo lideré uno de ellos, y decidí aplicar un poquito de Scrum, sólo las reuniones matinales repasando qué hice ayer, qué voy a hacer hoy y qué necesito.

Situación inicial, un gerente liderando cada proyecto con una dedicación de 15 horas para los 20 días. Dos equipos idénticos con un jefe de proyecto cada uno, un analista funcional y dos analistas técnicos. Los resultados: el jueves de la semana pasada liberé un analista técnico, el viernes otro, el martes al funcional, y el miércoles al jefe de proyecto, cumpliendo exactamente los 20 días que habíamos planificado con reiteradas felicitaciones del cliente. Ni siquiera he llegado a dedicar las 15 horas.

El otro proyecto aún no ha terminado, terminará el miércoles de la semana que viene y sigue manteniendo todo el equipo.”

Sólo de pensar que hay gente que está encontrando formas mejores de hacer las cosas gracias a este blog, y que eso les está permitiendo llegar a lo que llamo el subidón de “puñeta, somos buenos“… En fin. Que me he emocionado, vaya.

Gracias, Ricard. Gracias de verdad. ;-)

Categorías: Blogs, Gestión de Proyectos
Tags: ,
1 comentario | Compártelo

Más antiguos →

Buscar:

Suscriptores:

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter


Fotos

www.flickr.com
angel.medinilla fotos Más fotos de angel.medinilla