Envié este correo hace unos años en otra empresa al tomar posesión de mi puesto de jefe de desarrollo. Tiene varias ideas, que es justo lo que falta aquí aunque no funciona en los ambientes empresariales viciados.

Notese que permite scrum y continuidad de negocio.
=======================================
Para poder comunicarme de manera rápida con las personas de desarrollo,
elaboré un mecanismo que me permite fijartes tareas diarias, y que reporten tener terminadas las tareas, además de concentrar informacion util y clasificarla.

Despues de pensarlo un poco, encontré que la mejor manera de llevar a la
vez un control de documentos / control de versiones / knowledge Base, era
implementar un Repositorio mediante un foro gratuito, que usuarios externos no pueden ver.

Ya se esta parametrizando la información, y necesitaba hacer esto como paso previo para poder poner en la knwoledge base la documentación tecnica del proyecto. Los niveles de visibilidad no estan funcionando todavia ( voy en proceso ), pero la idea basica es usar un subforo como si fuera un gabinete y asi las intrucciones especificas a programadores se guardan en su propio gabinete. Ademas no tienen derecho a editar, por lo cual la implementación es segura y podemos funcionar inclusive en caso de incendio, robo o algo que nos deje sin equipos de computo. La continuidad del proyecto estaría asegurada.

De manera temporal he implementado el repositorio en base a usuarios que
son las INICIALES de cada persona, y solo los usuarios pueden ver el contenido.

Le he reservado la clave de usuario:
admin
password *************

http://*********/foros/

Creo que sería conveniente darlo de alta a usted como usuario ( igual con
iniciales y le ponemos nivel de administrador), por si quiere añadir o
consultar datos de las labores que se estan desempeñando. El alta de usuario se maneja en http://*************

Me tomé la libertad de añadir a **** al repositorio, y así ella misma
podrá ver el cumplimiento de obejtivos, el trabajo realizado diariamente e
información en general que pueda serle util.

aclaraciones:

1 ) Este es un trabajo en formación:
2 ) Estoy en proceso de realizar la documentación tecnica sobre alcances.
3 ) Instalaré Skype mañana jueves.

En espera de sus comentarios y sugerencias.
Gracias.

Vi la posibilidad que traten de implementar scrum en el trabajo. Esto sería recomendable pero un poco estúpido.

Yo tuve Scrum funcionando en el área hasta que los cambios del corporativo (24 nov) dejaron fuera esa manera de trabajar. Curiosamente varias comunidades en línea y dos razones sociales que manejo usan la misma fecha pero este no es un evento relacionado.

Lo extraño del caso es que , como dije, Tanto SAEM como XFB y AGB ya estaban usando Scrum con su lista de labores del día, pendiente del día y demás. Todo en basde al procedimiento, sabiendo que era SCRUM pero sin decirlo. Funciona.

Hace unos años empezó este problema en varias consultorías que he visto. Personas que tienen idea de vocabulario, escupen metodologías y no implementan ninguna. En este caso, no solo están regresando al repositorio, sino que supongo se darán cuenta de que ya estaba implementado 5s y CMMI 2, además de los 12 pasos de Joel on Software (entre otras).

No me gusta decir se los dije, pero como se los dije, probablemente usen otra metodología y no Scrum.

Un resumen de Scrum tomado de :
===================================================
http://www.ingenierosoftware.com/equipos/scrum.php

estión de proyectos con SCRUM

Por Joaquin Gracia
4 de Septiembre de 2006

¿Qué es SCRUM? SCRUM es una forma de gestionar proyectos de software. No es una metodología de análisis, ni de diseño, como podría ser RUP, es una metodología de gestión del trabajo.

Una de las características más importantes es que es muy fácil de explicar y de entender, lo que ayuda mucho a su implantación.

Por otra parte SCRUM puede ser aplicado a distintos modelos de calidad (como podría ser CMMI) puesto que estos te dicen qué tienes que hacer, es decir, te dicen que tienes que gestionar el proyecto, pero no te dicen cómo. Ahí es donde entra SCRUM como modelo de gestión del proyecto.

Pero vamos a la materia, los siguientes son los elementos básicos de SCRUM.

Una lista con las funcionalidades de la aplicación ordenadas de mayor a menor importancia. Esta lista se llama «Product Backlog». No hace falta que esta lista contenga todas las funcionalidades inicialmente.

De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y son anotadas en una lista que se llama «Sprint Backlog». Estas tareas serán realizadas en el siguiente mes.

Además de estos elementos tenemos unas cuantas reglas básicas y sencillas que tenemos que cumplir.

Una vez que se pasan las tareas más prioritarias del «Product Backlog» al «Sprint Backlog», estas no se pueden cambiar, esto quiere decir, que el trabajo de un mes queda fijado. Esta es la regla más importante de todas.

Al final del mes, este periodo se le llama «Sprint», se tiene que tener un ejecutable con las funcionalidades del «Sprint Backlog».

Todo el mundo puede añadir funcionalidades al «Product Backlog», pero sólo una persona puede ordenarlo. A esta persona se le denomina «Product Owner». Es el responsable del producto final.

Cada día se hace una reunión de menos de 15 minutos, en la que se reúne todo el equipo: ingenieros y gestor (llamado «Scrum Master») en la que cada miembro del equipo expone sólo los siguientes temas:
¿Qué es lo que se hizo el día anterior?
¿Qué es lo que se va a hacer hoy?
¿Qué impedimentos tengo para realizar mi trabajo?
Sólo se tratan estos temas para que la reunión sea rápida y no malgastemos el tiempo de los demás. Si se tiene que tratar otro tema se hace otra reunión sólo con las personas implicadas. ¿Recordáis la serie de TV «Canción triste de Hill Street» en la que el sargento tenía una reunión matutina con sus agentes y que terminaba con un «Tengan cuidado ahí fuera»? pues viene a ser algo parecido.

Al final del mes, es decir, al final del Sprint, se presenta el producto y se toma del «Product Backlog» ordenado las funcionalidades para cubrir en el siguiente mes.
Básicamente esto es todo. Como podéis observar las reglas son sencillas y claras.

La duración del Sprint se puede modificar. Hay gente que prefiere Sprints más largos al comienzo, mes y medio o dos meses, ya que al principio cuesta más obtener un ejecutable y al final Sprints más cortos, una semana o dos, cuando se está en la fase final de refinamiento. Pero básicamente el proceso es el mismo de principio a fin.

Para gestionar el proyecto sólo necesitamos dos listas, el «Product Backlog» y el «Sprint Backlog». Podemos usar Excel para manejarlas.

Es curioso que SCRUM esté convirtiéndose en una tomada de pelo monumental, donde se trata de transferir a una persona el logro de un equipo Agile. Si bien me ha tocado tener que correr a programadores ineficientes, la regla que he usado en equipos Agile es sacar aquien no puede resolver el trabajo. Y esto tiene que ver con lo del puesto que comentaba ayer.

Hubo un comentario en https://gist.github.com/710960 muy interesante:



Well, this is what’s bound to happen when you start to name things.

«Agile» is doomed too… it’s been since when the name «Agile» started to pop up in conferences and on resumès. When you invent a label it comes with a cost: everyone can use it. And guess who likes labels a lot? Usually someone who has poor knowledge of the subject but needs some handles because he has to make decisions about it (hint: management).

If you can code, you’re a programmer. If you’re the best coder in your team, you’re the team leader. It’s really as simple as this. Nobody who actually is a team leader needs labels – the only ones who can give you real authority are your teammates… the ones who (when the time comes) will have to trust you and submit to your authority.


El ultimo pàrrafo es brutal.

Si puedes programar, eres un programador. Si eres el mejor desarrollador, eres el líder del equipo. Tan simple como eso. Nadie que sea actualmente un líder de equipo de desarrollo necesita etiquetas, lo único que te dará la autoridad en el equipo son los otros miembrosdel equipo, aquellos que cuando el tiempo llega, deben confiar en ti y aceptar tu autoridad.

Claro està que ganar más, y hacer exámen al contratarlos tambièn te da autoridad. Ser el que paga tambièn. Y en comunidades es algo similar. El que hace que las cosas funcionen es lo que cuenta.