Inicio arrow Blog arrow Gestión de proyectos Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Gestión de proyectos


El proyecto ha sido un éxito, pero ha dejado al cliente hundido.
20.11.2011

preocupadoEsta 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.)


 

 
Gestión ágil y entrega de valor
13.11.2011

entrega de valorEl 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.

 

 
Kanban Boxes: campos de scrum en oficinas multiproyecto
08.04.2010

boxesImplantar 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:

Kanban Box

 

 
Scrum Manager bits: contraindicaciones
18.02.2010

Scrum Manager bits"El producto previsto, en el tiempo planificado y por el presupuesto estimado" Vs. "Valor rápido, y de forma continua, en intervalos breves u regulares".

 

Contraindicaciones

 
Agilidad con varios proyectos a la vez
16.09.2009

piezasImplantar agilidad con un único equipo de 5-7 personas que trabaja en la programación de un único sistema, es un "caso de libro". No hay mas que tomar el libro de Ken Schwaber y aplicarlo. Pero esto  no es lo habitual en las empresas donde la mayoría de nosotros nos movemos, por eso, el que más y el que menos, nos las ingeniamos para aplicar las pautas ágiles en la forma que mejor sabemos y nos permiten las circunstancias.


 
¿Scrum, PMI o Flexibilidad?
15.09.2009

flexibleTener los requisitos cerrados antes de empezar a programar, y trazar con ellos un plan completo ¿es bueno o malo?

La respuesta es distinta si le preguntas a PMI o si le preguntas a la agilidad. Para PMI cada modificación de requisitos es una amenaza para el plan del proyecto, una incidencia que hay que medir y gestionar sus consecuencias.

Para la agilidad cada modificación de requisitos es una nueva aportación que va a hacer más valioso el resultado para el cliente.

Si nos planteamos si será mejor PMI o Scrum ya nos hemos limitado las opciones.

 
Simple Kanban
03.08.2009

simple-kanbanAñado Simple-Kanban al directorio de herramientas libres para gestión ágil. No tiene grandes funcionalidades, pero no se le puede pedir más: se trata de una simple página html: sin php, sin base de datos... nada que instalar, y para según que casos puede ser suficiente.

 

 
Excel para imprimir tarjetas desde la pila del producto (product backlog)
13.04.2009

hojaAunque aún no está terminada la plataforma de e-learning de Scrum Manager; mientras toma forma, con la ayuda de Claudia y Marta, incluyo ya en la lista de herramientas de Navegápolis, esta hoja excel para llevar la pila del producto (product backlog), que incluye una macro con la que generar tarjetas para cada elemento en formato A5.

Es un trabajo para Scrum Manager Open Knowledge, derivado de los anteriores de Stefan Nijenhuis y la posterior modificación de Henrik Kniberg .

Nota: Las historias que hay a modo de ejemplo forman parte del ejercicio del próximo taller sobre product backlog en Scrum Manager OK.

 

 
Combinar recetas
24.03.2009

mezclaUn actor capaz de conseguir el atractivo de Richard Gere, la constitución de Sylvester Stallone y el carácter de Jack Nicholson ¿sería una super-estrella?

Una ciudad con una torre metálica monumental, pirámides y calles "fluviales" con góndolas ¿Tendría más éxito turístico que París, El Cairo o Venecia?.

Es lo que se me ocurre con la idea de juntar "best practices". No sé si la comparación es válida, pero dudo de su resultado. Me convence más "romperlas" para descubrir su razón y fondo de conocimiento, y construir con la síntesis un modelo con personalidad propia, adecuada a mis circunstancias.

 

 
¿Con qué nivel gestiona los proyectos tu empresa?
01.03.2009

nivelesencuesta

0. Ninguno

No se usa ninguna técnica de administración de proyectos y la organización no considera el impacto que supone para el negocio la mala gestión de proyectos.

1.- Inicial

Las técnicas de administración de proyectos dependen sólo de las decisiones particulares de cada gestor de proyecto. La dirección de la empresa no tiene ningún compromiso sobre la propiedad y administración de los proyectos. Ni el cliente ni los usuarios intervienen en las decisiones críticas de la gestión de los proyectos. La empresa no tiene una organización clara para la administración de los proyectos; no hay una definición de roles y responsabilidades, no hay una gestión seria de agendas e hitos, ni seguimiento de fechas y gastos.

 
Coordinación de varios equipos en un mismo proyecto
07.12.2008

arbolesEl marco de trabajo ágil óptimo es un equipo único de no más de 6 ó 7 personas. La pérdida de eficiencia por el crecimiento de la estructura afecta también a un modelo ágil, y toma mayor dimensión si los equipos están físicamente separados.
Teniendo esto en cuenta, si el proyecto lo requiere, es posible emplear equipos de sincronización para coordinar en el mismo a varios equipos.

Se debe poner como primer elemento en la pila del producto (backlog), la construcción de la línea base de la arquitectura. Lo que Andy Hunt en "The Pragmatic Programmer " denomina como "bala trazadora".

 

 
El gráfico burndown y la ley de Parkinson
20.10.2008

burndownSi monitorizamos el avance del trabajo sobre un plan previo, podemos tener como resultado: que estamos en fechas, o que vamos retrasados, pero nunca adelantados. Y aunque es una herramienta útil para cumplir fechas, también es un freno para reducirlas; de hecho, al seguir el avance de un sprint con un gráfico burn-down, siempre sale o sub-estimado, o bien; pero nunca sobre-estimado.

La gestión predictiva hace planes detallados de duración considerable, y registra el trabajo realizado en cada momento.

La gestión ágil lo hace de forma diferente: trabaja con planes detallados cortos (iteraciones o sprints) y registra, no lo que se ha trabajado, sino lo que falta para terminar. Son los gráficos de avance: burndown.

 

 
Lo que deberían saber los "jefes" de los proyectos de software
06.07.2008

lideresLos programadores tienen alrededor, quizá demasiados "jefes": el director de la compañía, el de márketing, el gestor del proyecto, el scrummaster "cinturón negro", el propietario del producto, el director técnico, el director de calidad...

¿Cuántos son necesarios?, ¿Qué habilidades tienen que tener?, ¿qué es lo que se debe y lo que no se debe hacer?. Este es el tema de esta presentación en vídeo en la que Mary Poppendieck da un repaso a los errores que, aunque son lugares comunes para la gestión de nuestros equipos, siguen siendo repetidos por demasiados "jefes": las reminiscencias majadearas de la aplicación científica del trabajo, los mitos de la motivación, la gestión sin referencias, las culturas orientadas a la tarea, la fe ciega en los procesos, ignorar el origen del comportamiento X o Z, etc.

 
Proyectos funestos
03.07.2008

funesto Edward Yourdon afirma en su libro "Death March" que todos los proyectos que se llevan a cabo con la mitad de la agenda, del equipo o de los recursos necesarios, son marchas fúnebres.

Son funestos todos los proyectos que se llevan a cabo con la mitad de la agenda, del equipo o de los recursos que necesitarían, y los ingredientes que, combinados en mayor o menor proporción, están siempre presentes en estos proyectos son:

  • Politiqueos e intereses innobles
  • La ingenuidad y el optimismo de los jóvenes: "Esto lo hacemos en el fin de semana"
  • La mentalidad empresa "startup"
  • La mentalidad de soldado-héroe: "Los auténticos programadores no necesitan dormir"
  • La intensificación de la competencia por la globalidad y la aparición de nuevas tecnologías
  • La aparición inesperada de alguna crisis durante el proyecto

Funesto (RAE): Aciago, que es origen de pesares o de ruina - Triste y desgraciado.

 

 

 
¿Qué debe tener el mejor modelo de gestión de proyectos de software?
10.01.2008

DianaEl mejor modelo de desarrollo de software debe tener medios de feedback continuo y rápido, y "re-trazar" con la misma rapidez. Tiene que incluir métricas para los factores críticos del desarrollo y gestionar simultáneamente los relativos a la calidad y los relativos al coste. Debe abordar el desarrollo en pequeños incrementos. Aplicar controles de calidad desde las primeras fases. Trabajar con personas motivadas. Incorporar un sistema de retro-información y mejora continua y estar orientado a los resultados finales, sin despistarse en las formas.

 
¿Por qué fallan los proyectos?
18.11.2007

hundidoRecopilando y contrastando las opiniones de autores diferentes, sobre cuáles son las principales causas que hacen fracasar a los proyectos de software, he extraido las más repetidas: tomando de cada uno las 5 razones que considera más importantes, y finalmente del conjunto, las 5 que más se repiten.

Este es el resultado:

 
Ponga a los mejores en los proyectos pequeños
04.09.2007

equipoAl aumentar el tamaño del equipo del proyecto, disminuye la productividad personal. ¿Es porque en los equipos grandes los programadores son peores? ¿Porque la gestión los entorpece?.

 
¿Malos proyectos, o malas prácticas de gestión?
19.08.2007

humor1.- Ningún gran proyecto infomático se ha realizado jamás en los plazos y sin desbordar el presupuesto; ni con el mismo personal que lo comenzó; ni termina haciendo lo que se proyectó...
Es bastante improbable que el suyo sea el primero.

 
Calcular la fecha de fin de proyecto
11.04.2007

barquitoAlgunos procedimientos para calcular la fecha de llegada a puerto:

1.- Comparar los días transcurridos con los planificados.  (Método del directivo)

Si el viaje tiene una duración prevista de 30 días y llevamos 20 de navegación, se puede responder que faltan 10 días.

2.- Comparar las horas de trabajo realizadas con las planificadas.  (Método del consultor)

No estaría de más comprobar que los motores no están parados, y trabajan al ritmo previsto usando una métrica del tipo: ¿Cuantos litros de combustible habíamos previsto gastar?, ¿Cuántos hemos gastado?.

 
Gestión de personas tóxicas en proyectos Open Source
18.02.2007

PortadaEn los proyectos "open source" pueden aparecer personas tóxicas que por sus actitudes no colaborativas, intolerantes o dogmáticas pueden intoxicar la atmósfera deseable para la comunidad de desarrollo.

Ben Collins-Sussman y Brian W. Fitzpatrick son ingenieros de software que trabajan en Google para promocionar el desarrollo open-source dentro y fuera de la compañía.
Han trabajado en la creación y desarrollo de Subversion y el mes pasado grabaron para las Googel Tech Talks la sesión que presentaron en la convención OSCON 2006 "How Open Source Projects Survive Poisonous People (And You Can Too)".

Los consejos que dan para identificar y gestionar a las personas y actitudes tóxicas son muy útiles como complemento a las pautas de desarrollo de proyectos open source del libro (también con versión free) "Producing Open Source Software".

 
El escenario TIC necesita otro modelo de gestión de proyectos
20.07.2006

evolucion ipodEn los años 50, 60 y 70, cuando se desarrollaban las bases de una gestión de proyectos basada en la planificación, los productos tardaban años en quedar obsoletos. Las empresas los concebían y diseñaban en un entorno relativamente estable, y luego se dedicaban a producirlos de forma constante durante años, introduciendo quizá algunas variaciones mínimas.

Apple ha desarrollado 6 generaciones de su popular iPod, en sólo 6 años.

 
Scrum Reality
29.05.2006
videoScrum es una metodología ágil basada en desarrollo incremental e iterativo, bla, bla... pero ¿Qué es Scrum para los que lo viven?, ¿para los que lo usan como modelo de prácticas en su trabajo?.
Este vídeo es la respuesta que da el equipo de High Moon Studios, una empresa de programación de videojuegos que adoptó Scrum hace algo más de un año; y cuyo producto más conocido es precisamente el primer trabajo que realizaron con Scrum: Darkwatch.
 
Nueva revisión de dotProject
25.04.2006

dotprojectEstá disponible la revisión 2.0.2 de dotProject, que da respuesta a 714 peticiones de usuarios, y en la que se han resuelto 337 bugs. dotProject es, posiblemente, la herramienta de código libre y gratuito más completa para gestión de proyectos y entorno de desarrollo.

Tags: , , .

 
Guías de procesos para VSTS
21.03.2006
Visual Studio Team SystemYa están disponibles para descargar nuevas versiones de guías de procesos para Visual Studio 2005 Team System; una para trabajar con patrones de desarrollo ágil, y otra para hacerlo con el modelo CMMI.

Actualización 30/03/2006:

Está disponible para descarga Visual Studio 2005 Team Foundation Server Trial Edition. (fichero ISO del CD, 447 MB, S.O.: Windows 2003 Server, con Service Pack 1).

Tags: , , .
 
Entrevista a S. Somasegar
08.02.2006
entrevistaInfoWorld publica una entrevista a S. Somasegar (blog), vicepresidente corporativo de la división de desarrolladores de Microsoft, en la que habla sobre los nuevos productos Team System y Team Foundation Server, con los que Microsoft entra en el campo de las herramientas ALM (Application Lifecycle Management).

A modo de resumen:

 
<< Inicio < Anterior 1 2 Siguiente > Fin >>

Resultados 1 - 25 de 42
Advertisement





Artículos relacionados

Registrado en Safe Creative