Dos Ideas. - Contribuciones del usuario [es]

Reunion Diaria De Scrum

2008-07-26T21:59:35Z

190.172.86.173: /* Beneficios */

En [[Scrum]], el Scrum Diario es una reunión de 15 minutos máximo, que se realiza todos los días y participan todos los [[Miembros Del Equipo De Scrum]] durante el desarrollo de un [[Sprint]]. Durante esta reunión el equipo sincroniza su trabajo, progreso e informa cualquier impedimiento que tenga o prevea al [[Scrum Master]] (para que éste pueda tratarlos).

==Entradas==
Backlog del sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior.
Información de las tareas realizadas por cada componente del equipo

==Resultados==
Backlog del sprint y gráfico de avance (Burn-down) actualizados.
Identificación de necesidades e impedimentos.

==Beneficios==
Esta reunión es de suma utilidad y tiene los siguientes beneficios:
* Los impedimentos se identifican prontamente, para poder mantener el ritmo de desarrollo.
* Se disminuye la duplicación de esfuerzo.
* Mejor comprensión de la interdependencia entre los [[Miembros Del Equipo De Scrum]].
* Se comparten objetivos y una dirección clara en el equipo.
* Se contruye confianza y motivación durante el Sprint.
* Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.
* Mejora la comunicación del equipo y sus relaciones.

==Reglas==
* Tener la Reunión Diaria de Scrum en el mismo lugar, a la misma hora todos los días. Lo ideal es que la reunión sea lo primero del día, de manera que los miembros del equipo puedan recordar lo que hicieron el día anterior, y planear el día que comienza.
* Se requiere de todos los miembros del equipo en la reunión. Si por cualquier motivo algún miembro no puede asistir, se necesitaría que el ausente participe por teléfono, o que otro miembro reporte el status del ausente.
* Los miembros deben ser puntuales. El [[Scrum Master]] comienza la reunión a la hora indicada, sin importar quién esté presente. Cualqueir miembro que llegue tarde paga una multa que es donada para caridad!
* El [[Scrum Master]] comienza la reunión con la persona que esté a su izquierda y sigue en sentido horario hasta que todos hayan hablado.
* Cada miembro del equipo debe responder a estos preguntas:
** ¿Qué hiciste desde el último Scrum Diario respecto al proyecto?
** ¿Qué harás desde ahora y hasta el próximo Scrum Diario?
** ¿Qué te está impidiendo hacer tu trabajo lo mejor posible?
* Cada miembro informa la cantidad de tiempo que le falta para terminar la tarea que tiene asignada, registrando dicho valor en su tarea. Así, el [[Scrum Master]] podrá luego realizar el [[Seguimiento Del Sprint]].
* Los miembros del equipo no deben divagar fuera de estas preguntas, saltando por ejemplo a temas como diseño, discusiones de problemas, rumores, etc. El [[Scrum Master]] es responsable de mantener el orden y pasar de persona a persona lo más rapidamente posible.
* Los miembros del Equipo deben dirigirse al Equipo al hablar. La reunión no se trata de "Informarle al Scrum Master".
* Durante la reunión sólo una persona habla al mismo tiempo. El resto escucha sin hablar entre ellos.
* Cuando algún miembro del Equipo informa algo de interés para otros miembros del Equipo, o necesita ayuda de otros, cualquier miembro del Equipo puede organizar inmediatamente para juntarse luego de terminado el Scrum Diario.
* Los Pollos (personas fuera del Equipo) son bienvenidos de participar en el Scrum Diario, pero no se les permite hablar, realizar observaciones, hacer gestos o interferir con la reunión de cualquier otra manera.
* Los Pollos se mantiene alejados en la perisferia del Equipo, de manera de no interferir.
* Si muchos Pollos quieren asisten a la reunión, el Scrum Master puede limitar la asistencia de los mismos para mantener el orden.
* Los Pollos o Cerdos que no sigan las reglas pueden ser excluidos de la reunión (en el caso de los Pollos) o quitados del Equipo (Cerdos).

==Al final de la reunión==
* Con las estimaciones de tiempos actualizadas por el equipo, el [[Scrum Master]] actualiza el gráfico de avance del sprint.
* El responsable de la gestión de procesos de la organización (Scrum Manager o [[Scrum Master]]) comienza a gestionar las posibles necesidades e impedimentos identificados.

==Ver también==
* [[Roles De Scrum]]

==Más información==
* [http://scrumfromthetrenches.blogspot.com/2008/05/daily-scrum-mistakes.html Daily Scrum mistakes]

Reunion Diaria De Scrum

2008-07-26T21:58:46Z

190.172.86.173: /* Ver también */

En [[Scrum]], el Scrum Diario es una reunión de 15 minutos máximo, que se realiza todos los días y participan todos los [[Miembros Del Equipo De Scrum]] durante el desarrollo de un [[Sprint]]. Durante esta reunión el equipo sincroniza su trabajo, progreso e informa cualquier impedimiento que tenga o prevea al [[Scrum Master]] (para que éste pueda tratarlos).

==Entradas==
Backlog del sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior.
Información de las tareas realizadas por cada componente del equipo

==Resultados==
Backlog del sprint y gráfico de avance (Burn-down) actualizados.
Identificación de necesidades e impedimentos.

==Beneficios==
Esta reunión es de suma utilidad y tiene los siguientes beneficios:
* Los impedimentos se identifican prontamente, para poder mantener el ritmo de desarrollo.
* Se disminuye la duplicación de esfuerzo.
* Mejor comprensión de la interdependencia entre los [[Miembros Del Equipo]].
* Se comparten objetivos y una dirección clara en el equipo.
* Se contruye confianza y motivación durante el Sprint.
* Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.
* Mejora la comunicación del equipo y sus relaciones.

==Reglas==
* Tener la Reunión Diaria de Scrum en el mismo lugar, a la misma hora todos los días. Lo ideal es que la reunión sea lo primero del día, de manera que los miembros del equipo puedan recordar lo que hicieron el día anterior, y planear el día que comienza.
* Se requiere de todos los miembros del equipo en la reunión. Si por cualquier motivo algún miembro no puede asistir, se necesitaría que el ausente participe por teléfono, o que otro miembro reporte el status del ausente.
* Los miembros deben ser puntuales. El [[Scrum Master]] comienza la reunión a la hora indicada, sin importar quién esté presente. Cualqueir miembro que llegue tarde paga una multa que es donada para caridad!
* El [[Scrum Master]] comienza la reunión con la persona que esté a su izquierda y sigue en sentido horario hasta que todos hayan hablado.
* Cada miembro del equipo debe responder a estos preguntas:
** ¿Qué hiciste desde el último Scrum Diario respecto al proyecto?
** ¿Qué harás desde ahora y hasta el próximo Scrum Diario?
** ¿Qué te está impidiendo hacer tu trabajo lo mejor posible?
* Cada miembro informa la cantidad de tiempo que le falta para terminar la tarea que tiene asignada, registrando dicho valor en su tarea. Así, el [[Scrum Master]] podrá luego realizar el [[Seguimiento Del Sprint]].
* Los miembros del equipo no deben divagar fuera de estas preguntas, saltando por ejemplo a temas como diseño, discusiones de problemas, rumores, etc. El [[Scrum Master]] es responsable de mantener el orden y pasar de persona a persona lo más rapidamente posible.
* Los miembros del Equipo deben dirigirse al Equipo al hablar. La reunión no se trata de "Informarle al Scrum Master".
* Durante la reunión sólo una persona habla al mismo tiempo. El resto escucha sin hablar entre ellos.
* Cuando algún miembro del Equipo informa algo de interés para otros miembros del Equipo, o necesita ayuda de otros, cualquier miembro del Equipo puede organizar inmediatamente para juntarse luego de terminado el Scrum Diario.
* Los Pollos (personas fuera del Equipo) son bienvenidos de participar en el Scrum Diario, pero no se les permite hablar, realizar observaciones, hacer gestos o interferir con la reunión de cualquier otra manera.
* Los Pollos se mantiene alejados en la perisferia del Equipo, de manera de no interferir.
* Si muchos Pollos quieren asisten a la reunión, el Scrum Master puede limitar la asistencia de los mismos para mantener el orden.
* Los Pollos o Cerdos que no sigan las reglas pueden ser excluidos de la reunión (en el caso de los Pollos) o quitados del Equipo (Cerdos).

==Al final de la reunión==
* Con las estimaciones de tiempos actualizadas por el equipo, el [[Scrum Master]] actualiza el gráfico de avance del sprint.
* El responsable de la gestión de procesos de la organización (Scrum Manager o [[Scrum Master]]) comienza a gestionar las posibles necesidades e impedimentos identificados.

==Ver también==
* [[Roles De Scrum]]

==Más información==
* [http://scrumfromthetrenches.blogspot.com/2008/05/daily-scrum-mistakes.html Daily Scrum mistakes]

Reunion Diaria De Scrum

2008-07-26T21:58:28Z

190.172.86.173: /* Ver también */

En [[Scrum]], el Scrum Diario es una reunión de 15 minutos máximo, que se realiza todos los días y participan todos los [[Miembros Del Equipo De Scrum]] durante el desarrollo de un [[Sprint]]. Durante esta reunión el equipo sincroniza su trabajo, progreso e informa cualquier impedimiento que tenga o prevea al [[Scrum Master]] (para que éste pueda tratarlos).

==Entradas==
Backlog del sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior.
Información de las tareas realizadas por cada componente del equipo

==Resultados==
Backlog del sprint y gráfico de avance (Burn-down) actualizados.
Identificación de necesidades e impedimentos.

==Beneficios==
Esta reunión es de suma utilidad y tiene los siguientes beneficios:
* Los impedimentos se identifican prontamente, para poder mantener el ritmo de desarrollo.
* Se disminuye la duplicación de esfuerzo.
* Mejor comprensión de la interdependencia entre los [[Miembros Del Equipo]].
* Se comparten objetivos y una dirección clara en el equipo.
* Se contruye confianza y motivación durante el Sprint.
* Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.
* Mejora la comunicación del equipo y sus relaciones.

==Reglas==
* Tener la Reunión Diaria de Scrum en el mismo lugar, a la misma hora todos los días. Lo ideal es que la reunión sea lo primero del día, de manera que los miembros del equipo puedan recordar lo que hicieron el día anterior, y planear el día que comienza.
* Se requiere de todos los miembros del equipo en la reunión. Si por cualquier motivo algún miembro no puede asistir, se necesitaría que el ausente participe por teléfono, o que otro miembro reporte el status del ausente.
* Los miembros deben ser puntuales. El [[Scrum Master]] comienza la reunión a la hora indicada, sin importar quién esté presente. Cualqueir miembro que llegue tarde paga una multa que es donada para caridad!
* El [[Scrum Master]] comienza la reunión con la persona que esté a su izquierda y sigue en sentido horario hasta que todos hayan hablado.
* Cada miembro del equipo debe responder a estos preguntas:
** ¿Qué hiciste desde el último Scrum Diario respecto al proyecto?
** ¿Qué harás desde ahora y hasta el próximo Scrum Diario?
** ¿Qué te está impidiendo hacer tu trabajo lo mejor posible?
* Cada miembro informa la cantidad de tiempo que le falta para terminar la tarea que tiene asignada, registrando dicho valor en su tarea. Así, el [[Scrum Master]] podrá luego realizar el [[Seguimiento Del Sprint]].
* Los miembros del equipo no deben divagar fuera de estas preguntas, saltando por ejemplo a temas como diseño, discusiones de problemas, rumores, etc. El [[Scrum Master]] es responsable de mantener el orden y pasar de persona a persona lo más rapidamente posible.
* Los miembros del Equipo deben dirigirse al Equipo al hablar. La reunión no se trata de "Informarle al Scrum Master".
* Durante la reunión sólo una persona habla al mismo tiempo. El resto escucha sin hablar entre ellos.
* Cuando algún miembro del Equipo informa algo de interés para otros miembros del Equipo, o necesita ayuda de otros, cualquier miembro del Equipo puede organizar inmediatamente para juntarse luego de terminado el Scrum Diario.
* Los Pollos (personas fuera del Equipo) son bienvenidos de participar en el Scrum Diario, pero no se les permite hablar, realizar observaciones, hacer gestos o interferir con la reunión de cualquier otra manera.
* Los Pollos se mantiene alejados en la perisferia del Equipo, de manera de no interferir.
* Si muchos Pollos quieren asisten a la reunión, el Scrum Master puede limitar la asistencia de los mismos para mantener el orden.
* Los Pollos o Cerdos que no sigan las reglas pueden ser excluidos de la reunión (en el caso de los Pollos) o quitados del Equipo (Cerdos).

==Al final de la reunión==
* Con las estimaciones de tiempos actualizadas por el equipo, el [[Scrum Master]] actualiza el gráfico de avance del sprint.
* El responsable de la gestión de procesos de la organización (Scrum Manager o [[Scrum Master]]) comienza a gestionar las posibles necesidades e impedimentos identificados.

==Ver también==
* Roles De Scrum

==Más información==
* [http://scrumfromthetrenches.blogspot.com/2008/05/daily-scrum-mistakes.html Daily Scrum mistakes]

Reunion Diaria De Scrum

2008-07-26T21:56:34Z

190.172.86.173:

En [[Scrum]], el Scrum Diario es una reunión de 15 minutos máximo, que se realiza todos los días y participan todos los [[Miembros Del Equipo De Scrum]] durante el desarrollo de un [[Sprint]]. Durante esta reunión el equipo sincroniza su trabajo, progreso e informa cualquier impedimiento que tenga o prevea al [[Scrum Master]] (para que éste pueda tratarlos).

==Entradas==
Backlog del sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior.
Información de las tareas realizadas por cada componente del equipo

==Resultados==
Backlog del sprint y gráfico de avance (Burn-down) actualizados.
Identificación de necesidades e impedimentos.

==Beneficios==
Esta reunión es de suma utilidad y tiene los siguientes beneficios:
* Los impedimentos se identifican prontamente, para poder mantener el ritmo de desarrollo.
* Se disminuye la duplicación de esfuerzo.
* Mejor comprensión de la interdependencia entre los [[Miembros Del Equipo]].
* Se comparten objetivos y una dirección clara en el equipo.
* Se contruye confianza y motivación durante el Sprint.
* Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.
* Mejora la comunicación del equipo y sus relaciones.

==Reglas==
* Tener la Reunión Diaria de Scrum en el mismo lugar, a la misma hora todos los días. Lo ideal es que la reunión sea lo primero del día, de manera que los miembros del equipo puedan recordar lo que hicieron el día anterior, y planear el día que comienza.
* Se requiere de todos los miembros del equipo en la reunión. Si por cualquier motivo algún miembro no puede asistir, se necesitaría que el ausente participe por teléfono, o que otro miembro reporte el status del ausente.
* Los miembros deben ser puntuales. El [[Scrum Master]] comienza la reunión a la hora indicada, sin importar quién esté presente. Cualqueir miembro que llegue tarde paga una multa que es donada para caridad!
* El [[Scrum Master]] comienza la reunión con la persona que esté a su izquierda y sigue en sentido horario hasta que todos hayan hablado.
* Cada miembro del equipo debe responder a estos preguntas:
** ¿Qué hiciste desde el último Scrum Diario respecto al proyecto?
** ¿Qué harás desde ahora y hasta el próximo Scrum Diario?
** ¿Qué te está impidiendo hacer tu trabajo lo mejor posible?
* Cada miembro informa la cantidad de tiempo que le falta para terminar la tarea que tiene asignada, registrando dicho valor en su tarea. Así, el [[Scrum Master]] podrá luego realizar el [[Seguimiento Del Sprint]].
* Los miembros del equipo no deben divagar fuera de estas preguntas, saltando por ejemplo a temas como diseño, discusiones de problemas, rumores, etc. El [[Scrum Master]] es responsable de mantener el orden y pasar de persona a persona lo más rapidamente posible.
* Los miembros del Equipo deben dirigirse al Equipo al hablar. La reunión no se trata de "Informarle al Scrum Master".
* Durante la reunión sólo una persona habla al mismo tiempo. El resto escucha sin hablar entre ellos.
* Cuando algún miembro del Equipo informa algo de interés para otros miembros del Equipo, o necesita ayuda de otros, cualquier miembro del Equipo puede organizar inmediatamente para juntarse luego de terminado el Scrum Diario.
* Los Pollos (personas fuera del Equipo) son bienvenidos de participar en el Scrum Diario, pero no se les permite hablar, realizar observaciones, hacer gestos o interferir con la reunión de cualquier otra manera.
* Los Pollos se mantiene alejados en la perisferia del Equipo, de manera de no interferir.
* Si muchos Pollos quieren asisten a la reunión, el Scrum Master puede limitar la asistencia de los mismos para mantener el orden.
* Los Pollos o Cerdos que no sigan las reglas pueden ser excluidos de la reunión (en el caso de los Pollos) o quitados del Equipo (Cerdos).

==Al final de la reunión==
* Con las estimaciones de tiempos actualizadas por el equipo, el [[Scrum Master]] actualiza el gráfico de avance del sprint.
* El responsable de la gestión de procesos de la organización (Scrum Manager o [[Scrum Master]]) comienza a gestionar las posibles necesidades e impedimentos identificados.

==Ver también==
* RolesDeScrum

==Más información==
* [http://scrumfromthetrenches.blogspot.com/2008/05/daily-scrum-mistakes.html Daily Scrum mistakes]

Reunion Diaria De Scrum

2008-07-26T21:56:09Z

190.172.86.173: Página nueva: En Scrum, el Scrum Diario es una reunión de 15 minutos máximo, que se realiza todos los días y participan todos los Miembros Del Equipo De Scrum durante el desarrollo de un...

En [[Scrum]], el Scrum Diario es una reunión de 15 minutos máximo, que se realiza todos los días y participan todos los [[Miembros Del Equipo De Scrum]] durante el desarrollo de un [[[Sprint]]. Durante esta reunión el equipo sincroniza su trabajo, progreso e informa cualquier impedimiento que tenga o prevea al [[Scrum Master]] (para que éste pueda tratarlos).

==Entradas==
Backlog del sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior.
Información de las tareas realizadas por cada componente del equipo

==Resultados==
Backlog del sprint y gráfico de avance (Burn-down) actualizados.
Identificación de necesidades e impedimentos.

==Beneficios==
Esta reunión es de suma utilidad y tiene los siguientes beneficios:
* Los impedimentos se identifican prontamente, para poder mantener el ritmo de desarrollo.
* Se disminuye la duplicación de esfuerzo.
* Mejor comprensión de la interdependencia entre los [[Miembros Del Equipo]].
* Se comparten objetivos y una dirección clara en el equipo.
* Se contruye confianza y motivación durante el Sprint.
* Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.
* Mejora la comunicación del equipo y sus relaciones.

==Reglas==
* Tener la Reunión Diaria de Scrum en el mismo lugar, a la misma hora todos los días. Lo ideal es que la reunión sea lo primero del día, de manera que los miembros del equipo puedan recordar lo que hicieron el día anterior, y planear el día que comienza.
* Se requiere de todos los miembros del equipo en la reunión. Si por cualquier motivo algún miembro no puede asistir, se necesitaría que el ausente participe por teléfono, o que otro miembro reporte el status del ausente.
* Los miembros deben ser puntuales. El [[Scrum Master]] comienza la reunión a la hora indicada, sin importar quién esté presente. Cualqueir miembro que llegue tarde paga una multa que es donada para caridad!
* El [[Scrum Master]] comienza la reunión con la persona que esté a su izquierda y sigue en sentido horario hasta que todos hayan hablado.
* Cada miembro del equipo debe responder a estos preguntas:
** ¿Qué hiciste desde el último Scrum Diario respecto al proyecto?
** ¿Qué harás desde ahora y hasta el próximo Scrum Diario?
** ¿Qué te está impidiendo hacer tu trabajo lo mejor posible?
* Cada miembro informa la cantidad de tiempo que le falta para terminar la tarea que tiene asignada, registrando dicho valor en su tarea. Así, el [[Scrum Master]] podrá luego realizar el [[Seguimiento Del Sprint]].
* Los miembros del equipo no deben divagar fuera de estas preguntas, saltando por ejemplo a temas como diseño, discusiones de problemas, rumores, etc. El [[Scrum Master]] es responsable de mantener el orden y pasar de persona a persona lo más rapidamente posible.
* Los miembros del Equipo deben dirigirse al Equipo al hablar. La reunión no se trata de "Informarle al Scrum Master".
* Durante la reunión sólo una persona habla al mismo tiempo. El resto escucha sin hablar entre ellos.
* Cuando algún miembro del Equipo informa algo de interés para otros miembros del Equipo, o necesita ayuda de otros, cualquier miembro del Equipo puede organizar inmediatamente para juntarse luego de terminado el Scrum Diario.
* Los Pollos (personas fuera del Equipo) son bienvenidos de participar en el Scrum Diario, pero no se les permite hablar, realizar observaciones, hacer gestos o interferir con la reunión de cualquier otra manera.
* Los Pollos se mantiene alejados en la perisferia del Equipo, de manera de no interferir.
* Si muchos Pollos quieren asisten a la reunión, el Scrum Master puede limitar la asistencia de los mismos para mantener el orden.
* Los Pollos o Cerdos que no sigan las reglas pueden ser excluidos de la reunión (en el caso de los Pollos) o quitados del Equipo (Cerdos).

==Al final de la reunión==
* Con las estimaciones de tiempos actualizadas por el equipo, el [[Scrum Master]] actualiza el gráfico de avance del sprint.
* El responsable de la gestión de procesos de la organización (Scrum Manager o [[Scrum Master]]) comienza a gestionar las posibles necesidades e impedimentos identificados.

==Ver también==
* RolesDeScrum

==Más información==
* [http://scrumfromthetrenches.blogspot.com/2008/05/daily-scrum-mistakes.html Daily Scrum mistakes]

Backlog Del Sprint

2008-07-26T21:51:50Z

190.172.86.173: Página nueva: El backlog del Sprint es una lista de tareas que define el trabajo a realizar por los Miembros Del Equipo De Scrum durante un sprint. La lista surge durante la [[Planificacion Del...

El backlog del Sprint es una lista de tareas que define el trabajo a realizar por los [[Miembros Del Equipo De Scrum]] durante un sprint. La lista surge durante la [[Planificacion Del Sprint]]. Las tareas del backlog del sprint son las que el equipo definió como necesarias para convertir a items del [[Backlog Del Producto]] en funcionalidad del sistema. Cada tarea identifica quién es responsable de hacer el trabajo y un estimado de la cantidad de trabajo faltante para la tarea durante cualquier día del Sprint.
Es útil porque descompone el proyecto en tareas de tamaño adecuado para determinar el avance a diario; e identificar riesgos y problemas sin necesidad de procesos complejos de gestión.
Es también una herramienta de soporte para la comunicación directa del equipo.

==Características==
* Contiene tareas para convertir un [[Backlog Del Producto]] en funcionalidad concreta del sistema.
* Las tareas del backlog del sprint deben estar respaldadas por un requerimiento del [[Backlog Del Producto]], el cual fue seleccionado para ser completado durante el Sprint en curso.
* Las tareas se estiman en horas, generalmente entre 1 y 16 horas.
* Las tareas con más de 16 horas se descomponen durante la reunión de [[Planificacion Del Sprint]] o durante el mismo sprint a medida que es tratado.
* Los miembros del equipo eligen las tareas (no son asignadas).
* Cualquier miembro puede añadir, borrar o cambiar las tareas del backlog del spring (las suyas o nuevas).
* Si no está en claro el trabajo, definir el backlog del sprint con una mayor cantidad de tiempo, y luego dividirlo más tarde.
* Actualizar la estimación de trabajo restante a medida que se sepa más sobre las tareas.
* Sólamente el equipo puede agregar items al backlog del sprint.

==Formato y soporte==
Hay tres opciones:

* Hoja de cálculo.
* Pizarra física o pared.
* Herramienta colaborativa o de gestión de proyectos.

Y sobre la que mejor se adecúa a las características del proyecto, oficina y equipo lo apropiado es diseñar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:

* Incluye la información: lista de tareas, persona responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla.
* Sólo incluye la información estrictamente necesaria.
* El medio y modelo elegido es la opción posible que más facilita la consulta y comunicación diaria y directa del equipo.
* Sirve de soporte para registrar en cada reunión diaria del sprint, el tiempo que le queda a cada tarea.

[[Ejemplo De Backlog Del Sprint]]

==Finalización de una tarea del Backlog del Sprint==
Es importante que el Equipo cuente con una definición consistente de cuando se puede considerar a una tarea como "Terminada". Esto es aún más importante cuando el concepto de "Terminado" varia entre los equipos. El objetivo fundamental es tener una vista honesta y clara de los logros que se vayan consiguiendo, y del trabajo restante. Se debe mantener la confianza con los clientes, evitando "ocultar" trabajo no realizado.

Una buena definición de cuando una tarea se encuentra "Terminada" podría ser la siguiente:

PONER NUESTRO CONCEPTO DE TERMINADO

* El código cumple con los estándares
* Todos los tests pasan exitosamente
* El código está subido a un repositorio de versiones
* El código está integrado correctamente en el entorno adecuado

La naturaleza iterativa de los procesos ágiles deberían estar soportadas por buenas prácticas y herramientas con alto grado de automatización, para poder asegurar que las tareas del Sprint tienen la suficiente calidad para poder considerarlas "Terminadas". Cuando no se cuenta con estas herramientas, hay una importante sobrecarga de trabajo manual para poder realizar estas comprobaciones, que incluso no pueden garantizarse.

==Mantenimiento del Backlog del Sprint==
El equipo tiene muy pocas tareas administrativas que se interpongan con su trabajo. Sin embargo si tienen una obligación muy importante: mantener actualizado el Backlog del Sprint. Scrum es un proceso empírico que, por lo tanto, necesita del feedback sobre el progreso para permitir tomar cualquier decisión o acción que sea necesaria lo antes posible. El gráfico de Burndown del Sprint, para el SeguimientoDelSprint, no será útil si no muestra el estado actualizado del progreso del Equipo.

Las nuevas tareas deben agregarse al Backlog del Sprint a medida que surgen, y las horas estimadas restantes del día-a-día para cada tarea deben mantenerse actualizadas. Este estimado es el tiempo total restante para completar la tarea, sin importar la cantidad de personas que realicen el trabajo.

* La estimación de horas restantes de trabajo se actualiza diariamente, en general inmediatamente después de la [[Reunion Diaria De Scrum]].
* No debe confudirse esta práctica con un informe de tiempos, que no forma parte de Scrum. No existen mecanismos en Scrum para el seguimiento de la cantidad de tiempo que un equipo trabaja.
* A los Equipos se los mide por su cumplimiento de objetivos, no por cuántas horas trabajaron para cumplirlo. Scrum es un proceso orientado a los resultados, y no orientado al esfuerzo.

==Ver también==
* [[Backlog Del Producto]]
* [[Seguimiento Del Sprint]]
* [[Patrones]]

Wideband Delphi

2008-07-26T21:44:12Z

190.172.86.173: Página nueva: El método wideband Delphi es una Tecnica De Estimacion estructurada en grupo. Se basa fundamentalmente en que varios expertos, tras crear estimaciones individuales, se reunen par...

El método wideband Delphi es una [[Tecnica De Estimacion]] estructurada en grupo. Se basa fundamentalmente en que varios expertos, tras crear estimaciones individuales, se reunen para ponerse de acuerdo en una estimación.

==Proceso==
# El coordinador presenta a cada experto la especificación y un formulario de estimación.
# Los estimadores trabajan individualmente. (Se puede hacer esto tras el paso 3)
# Se hace una reunión en la que los expertos hablan de los posibles problemas de estimación.
# Los expertos rellenan las estimaciones y se las dan al coordinador de manera anónima.
# El coordinador prepara un resumen de las estimaciones y la reparte a todos los expertos.
# Se reunen tanto el coordinador como los expertos para ver variaciones en las estimaciones.
# Los expertos votan anónimamente si aceptan la estimación media. Si alguien vota que no se vuelve al paso 3.
# La estimación final es una estimación única (single-point estimate). También podría ser un rango creado durante la estimación en la que la single-point es el caso esperado (recordad lo de caso más probable, menos probable y caso esperado).

==Utilidad del método==
En estudios realizados, un 25 grupos en los que ha recogido datos, comparando datos de estimaciones hechas haciendo un promedio de los expertos respecto a usar método Delphi, se obtiene una mejora de alrededor de un 40%.

Muchas veces la estimación correcta (que lógicamente sólo se sabe a posteriori) no está dentro del rango original cubierto por los estimadores, y que sin embargo usando Delphi se llega, 1/3 de las veces, a incluir ese punto.

===¿Cuándo usarlo?===
Fundamentalmente al inicio de los proyectos, cuando todavía hay mucha incertidumbre. En el área inicial del cono de incertidumbre se puede mejorar mucho con Delphi, luego cuando hay más datos será mejor cambiar a otras técnicas.
Pero al principio puede ser útil combiar múltiples informaciones de diferentes expertos.

==Ver también==
* [[Tecnica De Estimacion]]

==Más información==
* [http://en.wikipedia.org/wiki/Wideband_delphi Wideband Delphi en la Wikipedia]

Planificacion De Poker

2008-07-26T21:41:38Z

190.172.86.173: /* Funcionamiento */

La Planificación de Poker (o Planning Poker, en inglés) es una [[Tecnica De Estimacion]] usada en conjunción con [[Wideband Delphi]], para lograr consensuar estimaciones de tamaño de los requisitos de un proyecto de una manera rápida y ágil.
Es una práctica ágil, que resulta útil para conducir las reuniones en las que el equipo estima el esfuerzo y la duración de tareas.
Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ideó este juego de planificación como ayuda para conducir la reunión.

==El proceso==

El Planning Poker es muy sencillo, se presentan los requisitos a estimar uno por uno haciendo una descripción de los mismos. Luego se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas (que estan numeradas según la serie de Fibonacci) la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo.

Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas (esto es así para evitar que las estimaciones de unas personas sesgen las de otras). Si la dispersión entre las estimaciones se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimación.

Generalmente la dispersión en las estimaciones es sintoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos oscuros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito, de tal manera que en la siguiente ronda de estimación, la dispersión de las estimaciones será mucho menor y se podrá llegar facilmente a un consenso.

De esta manera es facil estimar los requisitos de una manera democrática, agil y rápida y que nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos, en definitiva estimaciones que todo el mundo puede asumir como suyas y que todo el mundo respetará.

Uno de los problemas que tiene el Planning Poker es que requiere que todos los implicados en la estimación se encuentren en una misma sala. Esto no siempre es posible cuando los equipos de desarrollo están distribuidos geográficamente.

==Las cartas==

Este método se basa en un juego de cartas que tiene cada persona que estima.
El modelo inicial de James Grening consta de 8 cartas con los números representados mas abajo, porque James lo ideó para las estimaciones de versión en [[Extreme Programming]], con equipos que emplean como unidad de esfuerzo: días de trabajo de cada par de programadores y trabajan con tareas de tamaño máximo de 10 días.

* ½, 1, 2, 3, 5, 6, 7, 8, infinito

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.

Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”

Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.

Lo relevante no es el número de cartas, la unidad de medida empleada, o si el tamaño máximo de tarea debe ser 5, 7 ó 10 días, sino trabajar con el modelo más apropiado al equipo, respetando los principios siguientes:

* No definir tareas demasiado grandes, porque dificulta la precisión de las estimaciones y la identificación de riesgos. Un criterio válido, si el equipo no dispone de experiencia previa, es descomponer en otras menores las que tengan una duración mayor de 7 días ideales de trabajo.
* No definir tareas con duraciones inferiores a medio día ideal de trabajo.
* Utilizar al misma unidad de medida (story points, días, horas…) en todos los gráficos y backlogs.

====Variante: sucesión de Fibonacci====
Basado en el hecho de que al aumentar el tamaño de las tareas, aumenta también el margen de error, se ha desarrollado una variante que consiste en emplear sólo números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:

* El juego de cartas está compuesto por números de la sucesión de Fibonacci.
* La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.

Para estimar tareas puede ser válido un juego de cartas como éste:

* 0, ½, 1, 2, 3, 5, 8, 13, 20, infinito

Si se quiere emplear la planificación de póker para estimar requisitos a nivel de producto o de versión (funcionalidades, temas…) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144…)

Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación.
También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.

====Funcionamiento====

* Cada participante de la reunión tiene un juego de cartas.
* Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
* Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.
* Cada participarte selecciona la carta o cartas que representan su estimación y las separa del resto, boca a bajo.
* Cuando todos han hecho su selección, se muestran boca arriba.
* Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido para estimar, la tarea debe dividirse en sub-tareas de menor tamaño.
* Si las estimaciones resultan muy dispares, el moderador, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar… puede optar por:
** Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo?. Tras escuchar las razones, repetir la estimación.
** Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
** Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
** Tomar la estimación menor, mayor, o la media.

Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y además...
resulta divertido y dinamiza la reunión.

==La unidad de estimación: el día ideal==
Los números que se muestran en las cartas pueden representar distintas unidades. Uno de los enfoques más utilizados es el de "día ideal de trabajo". Esto es, la unidad representa un día ideal y perfecto de trabajo, sin interrupciones, interferencias o distracciones de ningún tipo.

Dicho de otra manera: "si estuviera yo solo encerrado en una habitación, con alimento ilimitado y trabajando 6 horas perfectas, inspirado y totalmente concentrado, ¿cuánto tardaria en desarrollar la funcionalidad X de forma completa y con calidad productiva?".

Por ejemplo, la carta "5" representa que quien estimó podría completar la funcionalidad estimada en 5 días "ideales" de trabajo.

==Cartas para imprimir==
* [http://www.dosideas.com/descargas/cat_view/40-scrum.html Juego de cartas de Planificación de Poker para imprimir]

==Ver también==
* [[Tecnica De Estimacion]]

==Más información==
* [http://en.wikipedia.org/wiki/Planning_poker Planning Poker en la Wikipedia]
* [http://www.navegapolis.net/content/view/525/59/ Planificación de Poquer]

Planificacion De Poker

2008-07-26T21:40:54Z

190.172.86.173: Página nueva: La Planificación de Poker (o Planning Poker, en inglés) es una Tecnica De Estimacion usada en conjunción con Wideband Delphi, para lograr consensuar estimaciones de tamaño...

La Planificación de Poker (o Planning Poker, en inglés) es una [[Tecnica De Estimacion]] usada en conjunción con [[Wideband Delphi]], para lograr consensuar estimaciones de tamaño de los requisitos de un proyecto de una manera rápida y ágil.
Es una práctica ágil, que resulta útil para conducir las reuniones en las que el equipo estima el esfuerzo y la duración de tareas.
Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ideó este juego de planificación como ayuda para conducir la reunión.

==El proceso==

El Planning Poker es muy sencillo, se presentan los requisitos a estimar uno por uno haciendo una descripción de los mismos. Luego se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas (que estan numeradas según la serie de Fibonacci) la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo.

Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas (esto es así para evitar que las estimaciones de unas personas sesgen las de otras). Si la dispersión entre las estimaciones se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimación.

Generalmente la dispersión en las estimaciones es sintoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos oscuros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito, de tal manera que en la siguiente ronda de estimación, la dispersión de las estimaciones será mucho menor y se podrá llegar facilmente a un consenso.

De esta manera es facil estimar los requisitos de una manera democrática, agil y rápida y que nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos, en definitiva estimaciones que todo el mundo puede asumir como suyas y que todo el mundo respetará.

Uno de los problemas que tiene el Planning Poker es que requiere que todos los implicados en la estimación se encuentren en una misma sala. Esto no siempre es posible cuando los equipos de desarrollo están distribuidos geográficamente.

==Las cartas==

Este método se basa en un juego de cartas que tiene cada persona que estima.
El modelo inicial de James Grening consta de 8 cartas con los números representados mas abajo, porque James lo ideó para las estimaciones de versión en [[Extreme Programming]], con equipos que emplean como unidad de esfuerzo: días de trabajo de cada par de programadores y trabajan con tareas de tamaño máximo de 10 días.

* ½, 1, 2, 3, 5, 6, 7, 8, infinito

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.

Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”

Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.

Lo relevante no es el número de cartas, la unidad de medida empleada, o si el tamaño máximo de tarea debe ser 5, 7 ó 10 días, sino trabajar con el modelo más apropiado al equipo, respetando los principios siguientes:

* No definir tareas demasiado grandes, porque dificulta la precisión de las estimaciones y la identificación de riesgos. Un criterio válido, si el equipo no dispone de experiencia previa, es descomponer en otras menores las que tengan una duración mayor de 7 días ideales de trabajo.
* No definir tareas con duraciones inferiores a medio día ideal de trabajo.
* Utilizar al misma unidad de medida (story points, días, horas…) en todos los gráficos y backlogs.

====Variante: sucesión de Fibonacci====
Basado en el hecho de que al aumentar el tamaño de las tareas, aumenta también el margen de error, se ha desarrollado una variante que consiste en emplear sólo números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:

* El juego de cartas está compuesto por números de la sucesión de Fibonacci.
* La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.

Para estimar tareas puede ser válido un juego de cartas como éste:

* 0, ½, 1, 2, 3, 5, 8, 13, 20, infinito

Si se quiere emplear la planificación de póker para estimar requisitos a nivel de producto o de versión (funcionalidades, temas…) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144…)

Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación.
También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.

====Funcionamiento====

* Cada participante de la reunión tiene un juego de cartas.
* Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
* Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.
* Cada participarte selecciona la carta o cartas que representan su estimación y las separa del resto, boca a bajo.
* Cuando todos han hecho su selección, se muestran boca arriba.
* Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido para estimar, la tarea debe dividirse en sub-tareas de menor tamaño.
* Si las estimaciones resultan muy dispares, el moderador, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar… puede optar por:
** Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo?. Tras escuchar las razones, repetir la estimación.
** Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan
quedado pendientes.
** Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de
las funcionalidades resultantes.
** Tomar la estimación menor, mayor, o la media.

Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y además...
resulta divertido y dinamiza la reunión.

==La unidad de estimación: el día ideal==
Los números que se muestran en las cartas pueden representar distintas unidades. Uno de los enfoques más utilizados es el de "día ideal de trabajo". Esto es, la unidad representa un día ideal y perfecto de trabajo, sin interrupciones, interferencias o distracciones de ningún tipo.

Dicho de otra manera: "si estuviera yo solo encerrado en una habitación, con alimento ilimitado y trabajando 6 horas perfectas, inspirado y totalmente concentrado, ¿cuánto tardaria en desarrollar la funcionalidad X de forma completa y con calidad productiva?".

Por ejemplo, la carta "5" representa que quien estimó podría completar la funcionalidad estimada en 5 días "ideales" de trabajo.

==Cartas para imprimir==
* [http://www.dosideas.com/descargas/cat_view/40-scrum.html Juego de cartas de Planificación de Poker para imprimir]

==Ver también==
* [[Tecnica De Estimacion]]

==Más información==
* [http://en.wikipedia.org/wiki/Planning_poker Planning Poker en la Wikipedia]
* [http://www.navegapolis.net/content/view/525/59/ Planificación de Poquer]

Tecnica De Estimacion

2008-07-26T21:37:27Z

190.172.86.173: Página nueva: Uno de los primeros pasos al iniciar un proyecto o iteración es poder calcular el esfuerzo que se necesitará para lograr el objetivo. Existen diversas técnicas para realizar estim...

Uno de los primeros pasos al iniciar un proyecto o iteración es poder calcular el esfuerzo que se necesitará para lograr el objetivo.

Existen diversas técnicas para realizar estimaciones, que apuntan a resolver distintos problemas. Por tratarse de eventos futuros, ninguna técnica de estimación puede ser exacta; sin embargo, existen diversos técnicas para disminuir la incertidumbre y aprender de situaciones pasadas.

==Técnicas==
* [[Planificacion De Poker]]
* [[Wideband Delphi]]
* [[Cocomo]]
* [[Puntos De Funcion]]

Estimacion Del Sprint

2008-07-26T21:35:49Z

190.172.86.173: Página nueva: Scrum requiere en sus etapas la estimación de los items del BacklogDelProducto. Scrum por si mismo no especifica qué Tecnica De Estimacion utilizar, si bien habitualmente se...

[[Scrum]] requiere en sus etapas la estimación de los items del BacklogDelProducto. Scrum por si mismo no especifica qué [[Tecnica De Estimacion]] utilizar, si bien habitualmente se suele aplicar la [[Planificacion De Poker]].

==Estimación de Backlog del Produducto==
En [[Scrum]], en la etapa de [[Planificacion Del Sprint]], se realizan estimaciones sobre los items del [[Backlog Del Producto]]. Se puede utilizar la [[Planificacion De Poker]] como técnica para que los [[Miembros Del Equipo De Scrum]] y el [[Scrum Master]] realicen la estimación.

Si existen esimaciones muy dispares, el [[Scrum Master]] puede tomar los extremos y pedirle a las partes que justifiquen su estimación: es probable que alguna de las partes (o ambas!) hayan comprendido cosas diferentes sobre el item a estimar. Una vez expuestas las justificaciones, el ScrumMaster debe luego pedir otra ronda de estimación.

En caso de variaciones menores, el [[Scrum Master]] puede decidir tomar el promedio de todas, o elegir el número seleccionado por la mayoría.

En última instancia, es el [[Scrum Master]] quien termina decidiendo la estimación en base a las cartas expuestas. Esto es así porque la reunión de [[Planificacion Del Sprint]] tiene una duración acotada y fija.

==Estimación de la velocidad del Equipo==
Utilizando Planificación de Poker, los items del Backlog del Producto se estimacion en "días ideales". Queda entonces calcular cuántos días ideales podrán realizar los [[Miembros Del Equipo De Scrum]] durante el [[Sprint]].

El primer cálculo será simple: multiplicar la cantidad de integrantes por la cantidad de días hábiles del Sprint. Con esto obtendremos la cantidad total de días ideales disponibles para el Sprint.

Por ejemplo, si fuera un Sprint de 15 días hábiles (3 semanas), y un equipo de 4 personas, se obtendría:

15 x 4 = 60 días ideales

===El factor de foco===

Ahora bien, en la vida real que tendrán los miembros del equipo no existen dichos días ideales. Deberemos entonces disminuir este número, por lo que se conoce como '''factor de foco'''. El factor de foco es un coeficiente que ajusta la estimación anterior, para poder acercarla a la realidad (teniendo en cuenta demoras, distracciones, errores, etc.). Al comenzar, el factor de foco suele estar entre 50% - 80%.

===Ajuste al final del Sprint===
Al finalizar el Sprint tendremos ya la velocidad real que tuvo el equipo (sabiendo cuántos items del backlog pudo completar). Así, contaremos con dos valores: la '''velocidad estimada al comienzo del Sprint''' y la '''velocidad real''' al finalizar el Sprint. Esta velocidad real al finalizar el Sprint deberá ser la velocidad estimada para el próximo Sprint.

A su vez, deberá ajustarse el factor de foco para ver su valor real. Este nuevo factor de foco será útil en el caso de que se modifique la cantidad de integrantes del equipo para el siguiente Sprint, para poder recalcular la velocidad del mismo. El nuevo factor de foco será:
Factor de Foco = velocidad_real_fin_de_sprint / velocidad_ideal

==Ejemplo==

Supongamos un proyecto con un Equipo de 4 personas, y una duración del Sprint de 15 días hábiles (3 semanas).

Para calcular la cantidad de días ideales disponibles durante el Sprint haríamos:

4 x 15 = 60 días ideales

Deberemos luego "achicar" este valor, aplicando un factor de foco. Como estamos comenzando el primer Sprint del proyecto, comenzamores con un factor de foco del 0.75

60 x 0.75 = 45 días

Así, tendremos 45 puntos (o días) para poder tomar items del Backlog del Producto a realizar. Esta será la '''velocidad estimada del Sprint'''

Al finalizar el Sprint podremos entonces ver cuál fue la velocidad real del Sprint, en base a la cantidad de items del Backlog del Producto terminados. Por ejemplo:

Velocidad estimada al comienzo del Sprint: 45
Velocidad real al final del Sprint: 40

Con esto, la velocidad estimada del próxima Sprint deberá ajustarse a 40. El nuevo factor de foco será:

60 x FACTOR_DE_FOCO = 40
FACTOR_DE_FOCO = 40 / 60
FACTOR_DE_FOCO = 0.66

==Ver también==
* [[Planificacion De Poker]]

Planificacion Del Sprint

2008-07-26T21:30:22Z

190.172.86.173: Página nueva: El propósito de un Sprint es convertir un set de items del Backlog Del Producto en un incremento de funcionalidad potencialmente productiva. El Dueño Del Producto, el [[...

El propósito de un [[Sprint]] es convertir un set de items del [[Backlog Del Producto]] en un incremento de funcionalidad potencialmente productiva. El [[Dueño Del Producto]], el [[Scrum Master]] y los [[Miembros Del Equipo De Scrum]] se reunen antes de cada Sprint para determinar en qué funcionalidad del producto se seguirá trabajando. El [[Dueño Del Producto]] presenta el [[Backlog Del Producto]] y el equipo selecciona lo que cree puede ser construido durante el Sprint.

La reunión de Planificación del Sprint consiste de dos partes, cada una de las cuales puede durar hasta cuatro horas.

1. '''Selección del backlog''' (Exposición): el [[Dueño Del Producto]] presenta el backlog de mayor prioridad al equipo de desarrollo. Juntos colaboran para acordar cuántos de estos items pueden convertirse en un [[Incremento Del Producto]] potencialmente productivo durante el próximo Sprint. El equipo realiza la [[Estimacion Del Sprint]] y selecciona todo lo que crea pueda realizar.

2. '''Planificación de trabajo del Sprint''' (Resolución): el equipo define la arquitectura y el diseño de la funcionalidad que fue seleccionada, y luego define el trabajo, o tareas que conformarán el [[Backlog Del Sprint]], para construir dicha funcionalidad durante el próximo Sprint.

[[Ejemplo De Exposicion Resolucion]]

El tiempo que dura la Planificación del Sprint debería estar en correspondencia con la duración misma del Sprint (donde, por ejemplo, en un sprint de 2 semanas no se deberían usar más de 4 horas en total para la planificación).

===Pre-condiciones===
* La organización tiene determinados los recursos posibles para llevar a cabo el sprint.
* El propietario del producto tiene preparado el backlog del producto: con su criterio de prioridad para el negocio, y un nº suficiente de elementos para desarrollar en el sprint.
* Siempre que sea posible el propietario del producto debe haber trabajado ya previamente con el equipo. De esta forma su estimación previa de qué cantidad de backlog de producto se puede desarrollar en el sprint será bastante ajustada.
* El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del producto suficiente para realizar estimaciones basadas en "juicio de expertos”, y para comprender los conceptos del negocio que expone el propietario del producto.

===Entradas===
* El backlog del producto
* El producto desarrollado hasta la fecha a través de los sucesivos incrementos (excepto si se trata del primer sprint)
* Circunstancias de las condiciones de negocio del cliente y del escenario tecnológico empleado.

===Resultados===
* Backlog del sprint.
* Duración del sprint y fecha de la reunión de revisión.
* Objetivo del sprint.

===Funciones del rol de Scrum Manager===
El Scrum Manager es responsable y garante de:
# Se realiza esta reunión antes de cada sprint.
# Que antes de la reunión que el propietario del producto disponga de un backlog adecuado y suficiente para realizar el sprint.
# Que el diálogo principal de la reunión se realice entre el propietario del producto y el equipo. Otros asistentes pueden participar, pero su colaboración no puede implicar toma de decisiones ni limitar el diálogo principal.
# Que la reunión sea un trabajo de colaboración activa entre los dos protagonistas: cliente y equipo, y concluyen con un acuerdo sobre el incremento de producto que van a realizar en el sprint.
# Que el equipo comprende la visión y necesidades de negocio del cliente.
# Que el equipo ha realizado una descomposición y estimación del trabajo realistas y ha considerado las posibles tareas necesarias de análisis, investigación o apoyo.
# Que al final de la reunión están objetivamente determinados:

* Los elementos del backlog del producto que se van a ejecutar.
* El objetivo del sprint.
* El backlog del sprint con todas las tareas estimadas.
* La duración del sprint y la fecha de la reunión de revisión.

El Scrum Manager modera la reunión para que no dure más de un día. Debe evitar que el equipo comience a profundizar en trabajos de análisis o arquitectura que son propios del sprint.

===Pizarra de Trabajo===
Es recomendable, que el propietario del producto emplee una hoja de cálculo, alguna herramienta similar, o el soporte de una intranet, para guardar en formato digital la pila del producto.
Pero no es aconsejable emplearla como base para trabajar sobre ella en la reunión proyectándola sobre la pantalla de la sala.
Es mucho mejor trabajar y manipular elementos físicos; y usar una pizarra y fichas removibles (adhesivas, con chinchetas o magnéticas).

===Un ejemplo de pizarra.===
La pizarra es una herramienta para facilitar la comunicación y el trabajo de la reunión.
Al final de la reunión el propietario del producto registrará en la hoja de cálculo, o en la herramienta que emplee, el estado y las modificaciones en el backlog del producto.
El equipo hará lo mismo con backlog del sprint.
Según la distribución y espacio de la oficina de trabajo quizá se reutilice la pizarra o las notas
para el seguimiento del sprint; o quizá no.
Este es un ejemplo, pero la pizarra, y el resto de las formas, son técnicas que ayudan a trabajar de forma ágil; no reglas estrictas.
En cada caso se pueden ajustar o modificar según las características de la organización.
Algunos soportes que se suelen emplear:
* Pizarra blanca y fichas adhesivas tipo “Post-it”
* Pizarra de corcho laminado y chinchetas para sujetar las fichas.
* Pizarra de acero vitrificado y soportes magnéticos para sujetar las fichas.

Se puede conseguir una solución práctica y económica empleando fichas adhesivas (“Post-it”) y usando como pizarra cartón pluma blanco de 5mm. fijado con puntas directamente sobre la pared.
El cartón pluma es un material ligero, de acabado satinado que puede adquirirse en tiendas de materiales para bellas artes y manualidades.

[[Ejemplo De Backlog Del Sprint]]

===Resumen===
* El Dueño del Producto prioriza el backlog del producto
* El Dueño del Producto, el Scrum Master y el Equipo se reunen para dterminar el trabajo a completar durante el próximo Sprint.
* El trabajo lo selecciona el equipo de la lista priorizada.
* El equipo obtiene todo el detalle necesario del Dueño del Producto, de forma que puedan estimar lo que es posible realizar durante el próximo Sprint.
* El Dueño del Producto es responsable por negociar y tomar decisiones sobre cualquier asunto de requerimientos, de forma que el Equipo pueda trabajar sobre un único set de prioridades.
* El Dueño del Producto y el Equipo establecen el objetivo para el Sprint.
* El Equipo debe seleccionar sólamente el trabajo que se puedan comprometer a terminar.
* Los items seleccionados se descomponenen en tareas para el [[Backlog Del Sprint]].
* La estimación del Equipo se informa en base a los sprints anteriores, la capacidad para el próximo sprint y la complejidad relativa de las tareas requeridas para cumplir con el objetivo del Sprint.
* Si en el segundo día del Sprint ya se ve que se necesitará un 20% más de trabajo extra, será necesario planificar mejor. Esto es un tema a resolver durante la [[Retrospectiva Del Sprint]].

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]
* [[Estimacion Del Sprint]]

Backlog Del Producto

2008-07-26T21:24:49Z

190.172.86.173: Página nueva: El backlog del producto en Scrum es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que n...

El backlog del producto en [[Scrum]] es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.

El backlog es un inventario o una lista priorizada de requerimientos funcionales, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones.
Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto. Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el backlog.

Estos son algunos ejemplos de posibles entradas de un backlog:
* Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.
* Reducir el tiempo de instalación del programa.
* Mejorar la escalabilidad del sistema.
* Permitir la consulta de una obra a través de un API web.

A diferencia de un documento de requisitos del sistema, el product backlog nunca se da por completo; está en continuo crecimiento y evolución.
Habitualmente se comienza a elaborar con el resultado de una reunión de "fertilización cruzada" o brainstorming; o un proceso de “Exploración” ([[Extreme Programming]]), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto.
El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc.
Sí que es importante sin embargo disponer de una visión real, comprendida y compartida por todo el equipo.

El product backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.

===Formato===
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El product backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo.
Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:

* Identificador único de la funcionalidad o trabajo.
* Descripción de la funcionalidad.
* Campo o sistema de priorización.
* Estimación

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:

* Observaciones
* Criterio de validación

[[Ejemplo De Product Backlog]]

Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El [[Dueño Del Producto]] es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.

==Ver también==
* [[Scrum]]
* [[BacklogDelSprint]]

Miembros Del Equipo De Scrum

2008-07-26T21:22:06Z

190.172.86.173: /* Responsabilidades */

Los Miembros del Equipo es uno de los [[Roles De Scrum]]. El equipo del proyecto es un grupo multi-funcional de personas con todas las habilidades diferentes que son necesarias para convertir los requerimientos en algo que es un incremento de una funcionalidad potencialmente productiva. Por lo tanto, usualmente consiste en:
* analistas
* diseñadores
* encargados de Calidad (QA)
* desarrolladores
* documentadores
* otras habilidades necesarias para realizar el trabajo

Este es el equipo que se compromete con el [[Dueño Del Producto]] en las tareas a realizar en cada iteración, y luego las hace. Al final de la iteración le muestran al [[Dueño Del Producto]] el resultado, de manera que pueda elegir cómo seguir.

Muchas organizacionse suelen tener un grupo de personas especializadas en distintos temas, como ser usabilidad, administradores de bases de datos, expertos en seguridad y arquitectos de sistemas. Cuando se necesita la participación de alguno de ellos, deberían pasar a formar parte del equipo. Es decir, no son parte de un grupo "externo" de expertos que dan consejos, sino que se convierten en miembros del equipo para aquellas iteraciones en las que es necesario construir una arquitectura, infraestructura o trabajar en la base de datos. Pueden estar trabajando o guiando, monitoreando a los miembros del equipo que hacen el trabajo. La diferencia fundamental es que no son más pollos. Se comprometen al comienzo de la iteración junto al resto del equipo, y siguen con ellos hasta el fin de la iteración. Por lo tanto se convierten en cerdos por un período corto de tiempo.

==Características==
* Multi-funcional.
* Tamaño del equipo de entre 5 y 9 miembros.
* Auto-Administrado, gestionado por los mismos miembros del equipo.

==Responsabilidades==
Las principales responsabilidades, más allá de la auto-organización y uso de tecnologías ágiles, son las que se derivan de la diferencia entre “grupo de trabajo” y “equipo”.

Un grupo de trabajo es un conjunto de personas que realizan un trabajo con una asignación específica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecución.
Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde de su trabajo.

El equipo tiene espíritu de colaboración, y un propósito común: conseguir el mayor valor posible para la visión del cliente.

Un equipo Scrum responde en su conjunto.
Trabajan de forma cohesionada y auto-organizada.
No hay un gestor que delimita, asigna y coordina las tareas. Son los propios miembros del equipo los que realizan estas funciones.

En el equipo:

* Todos los miembros conocen comprenden la visión del propietario del producto.
* Aportan y colaboran con el propietario del producto en el desarrollo de la pila de producto.
* Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro.
* Todos los miembros participan en las decisiones.
* Se respetan las opiniones y aportaciones de todos
* Todos conocen el modelo de trabajo con Scrum.

Entonces las responsabilidades son:
* Selecciona el objetivo de la iteración y determina los resultados del trabajo
* Tiene el derecho para hacer todo lo necesario (dentro de los límites de las guías del proyecto) para alcanzar el objetivo de la iteración
* Se organiza a si mismo y a su trabajo
* Realiza demostraciones del resultado del trabajo ante el [[Dueño Del Producto]] y los stakeholders.

==Ver también==
* [[Roles De Scrum]]

Miembros Del Equipo De Scrum

2008-07-26T21:21:23Z

190.172.86.173: Página nueva: Los Miembros del Equipo es uno de los Roles De Scrum. El equipo del proyecto es un grupo multi-funcional de personas con todas las habilidades diferentes que son necesarias para c...

Los Miembros del Equipo es uno de los [[Roles De Scrum]]. El equipo del proyecto es un grupo multi-funcional de personas con todas las habilidades diferentes que son necesarias para convertir los requerimientos en algo que es un incremento de una funcionalidad potencialmente productiva. Por lo tanto, usualmente consiste en:
* analistas
* diseñadores
* encargados de Calidad (QA)
* desarrolladores
* documentadores
* otras habilidades necesarias para realizar el trabajo

Este es el equipo que se compromete con el [[Dueño Del Producto]] en las tareas a realizar en cada iteración, y luego las hace. Al final de la iteración le muestran al [[Dueño Del Producto]] el resultado, de manera que pueda elegir cómo seguir.

Muchas organizacionse suelen tener un grupo de personas especializadas en distintos temas, como ser usabilidad, administradores de bases de datos, expertos en seguridad y arquitectos de sistemas. Cuando se necesita la participación de alguno de ellos, deberían pasar a formar parte del equipo. Es decir, no son parte de un grupo "externo" de expertos que dan consejos, sino que se convierten en miembros del equipo para aquellas iteraciones en las que es necesario construir una arquitectura, infraestructura o trabajar en la base de datos. Pueden estar trabajando o guiando, monitoreando a los miembros del equipo que hacen el trabajo. La diferencia fundamental es que no son más pollos. Se comprometen al comienzo de la iteración junto al resto del equipo, y siguen con ellos hasta el fin de la iteración. Por lo tanto se convierten en cerdos por un período corto de tiempo.

==Características==
* Multi-funcional.
* Tamaño del equipo de entre 5 y 9 miembros.
* Auto-Administrado, gestionado por los mismos miembros del equipo.

==Responsabilidades==
Las principales responsabilidades, más allá de la auto-organización y uso de tecnologías ágiles, son las que se derivan de la diferencia entre “grupo de trabajo” y “equipo”.

Un grupo de trabajo es un conjunto de personas que realizan un trabajo con una asignación específica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecución.
Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde de su trabajo.

El equipo tiene espíritu de colaboración, y un propósito común: conseguir el mayor valor posible para la visión del cliente.

Un equipo Scrum responde en su conjunto.
Trabajan de forma cohesionada y auto-organizada.
No hay un gestor que delimita, asigna y coordina las tareas. Son los propios miembros del equipo los que realizan estas funciones.

En el equipo:

* Todos los miembros conocen comprenden la visión del propietario del producto.
* Aportan y colaboran con el propietario del producto en el desarrollo de la pila de producto.
* Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro.
* Todos los miembros participan en las decisiones.
* Se respetan las opiniones y aportaciones de todos
* Todos conocen el modelo de trabajo con Scrum.

Entonces las responsabilidades son:
* Selecciona el objetivo de la iteración y determina los resultados del trabajo
* Tiene el derecho para hacer todo lo necesario (dentro de los límites de las guías del proyecto) para alcanzar el objetivo de la iteración
* Se organiza a si mismo y a su trabajo
* Realiza demostraciones del resultado del trabajo ante el DueñoDelProducto y los stakeholders.

==Ver también==
* [[Roles De Scrum]]

Lista De Impedimentos

2008-07-26T21:17:34Z

190.172.86.173: Página nueva: Se considera un Impedimento a cualquier cosa alrededor de un proyecto Scrum que interfiera con la productividad o calidad del mismo. El responsabilidad del Scrum Master elimi...

Se considera un Impedimento a cualquier cosa alrededor de un proyecto [[Scrum]] que interfiera con la productividad o calidad del mismo.

El responsabilidad del [[Scrum Master]] eliminar cualquier impedimento que le impida al equipo producir código de calidad productiva. La Lista de Impedimentos es un grupo de tareas que el [[Scrum Master]] usa para el seguimiento de los impedimientos que necesitan ser resueltos.

Scrum Master

2008-07-26T21:16:41Z

190.172.86.173: /* Ver también */

El Scrum Master es uno de los [[Roles De Scrum]]. Anteriormente solía ser el project manager, ahora es la persona responsable para asegurarse que el proceso de Scrum es utilizado correctamente. Hay distintas maneras de pensar sobre el rol del Scrum Master. Podría ser, por ejemplo, como un padre, ya que cuando se crea un equipo de Scrum, al principio no saben como auto-administrarse, no saben como trabajar entre todos, no saben cómo trabajar con el [[Dueño Del Producto]], o cómo trabajar dentro de timeboxes. Entonces, al igual que un padre, el Scrum Master es el responsable de enseñarles cómo hacer todo esto hasta que aprendan, llevándolos en el proceso de convertirse en un equipo auto-administrado. Además, el Scrum Master es como un coach, responsable de alentar a todo el equipo, ser su líder y guía. El Scrum Master es también un referee que asegura que se sigan las reglas.

El Scrum Master por sobre todas las coasas tiene que asegurar las reglas. Muchos de los procesos que utilizan las organizaciones crean impedimentos para el progreso del trabajo del equipo. A veces puede parecer más simple el abandonar y aceptar que el proceso organizacional no puede cambiar, y así comprometer la eficiencia del equipo. Por lo tanto es vital que, para mantener la alta productividad de Scrum, se sigan las reglas y las mismas se mantengan sin importar el entorno. Haciendo esto, se hace evidente las cosas de la organización que son disfuncionales y se interponen en el proceso de creación de software.

El trabajo del Scrum Master es quitar cualquier impedimento, interno o externo al equipo que le impida alcanzar el objetivo de construir el software que comprometieron al inicio del Sprint.

==Responsabilidades==

Un Scrum Master es entonces un Lider y Facilitador, y es el responsable de:
* Mejorar la vida y productividad de los miembros del equipo, facilitándole la creatividad de cualquier manera posible.
* Asegurar la cooperación de todos los roles, y quitar cualquier barrera que lo impida.
* Proteger al equipo de interferencias externas, y quitar impedimentos.
* Asegurar que se siga el proceso
* Invitar a personas al Scrum diario, y a reuniones de revisión del sprint y planificación
* Seguir la [[Lista De Impedimentos]], quitando las barreras entre el desarrollo y el cliente, de manera que el cliente maneje directamente la funcionalidad desarrollada.
* Enseñarle al cliente cómo maximizar su retorno de inversión y cumplir sus objetivos con Scrum
* Mejorar las prácticas y herramientas usadas, de manera que cada incremento de funcionalidad sea potencialmente productivo.

==Ver también==
* [[Roles De Scrum]]

Scrum Master

2008-07-26T21:16:17Z

190.172.86.173: Página nueva: El Scrum Master es uno de los Roles De Scrum. Anteriormente solía ser el project manager, ahora es la persona responsable para asegurarse que el proceso de Scrum es utilizado cor...

Dueño Del Producto

2008-07-26T21:12:33Z

190.172.86.173: Página nueva: El Dueño del Producto (o Product Owner) es uno de los Roles De Scrum. Es el responsable por el retorno de la inversión del proyecto. Por lo tanto es la persona que representa el...

El Dueño del Producto (o Product Owner) es uno de los [[Roles De Scrum]]. Es el responsable por el retorno de la inversión del proyecto. Por lo tanto es la persona que representa el interés de todos en el proyecto, y responsable que el valor que entregue el proyecto sea mayor a su costo.

El [[Dueño Del Producto]] es generalmente el empleado cliente que encarga el proyecto, y es dueño del entregable en términos de ser responsable post-implementación. En términos de responsabilidad del proyecto, el rol del [[Dueño Del Producto]] es tener un alto conocimiento para poder priorizar los requerimientos funcionales, no funcionales y creativos. El Dueño del Producto es responsable de asegurar que la funcionalidad que está priorizada, desarrollada e implementada cumpla con las necesidades del negocio, y entreguen beneficios particularmente en términos de retorno de la inversión.

==Responsabilidades==
* Define las características del producto, decide fechas de entregables y contenido del mismo
* Consolida las necesidades de los usuarios, stakeholders y otras partes interesadas para crear una visión única y priorizada de los requerimientos del sistema.
* Es responsable de los beneficios del producto (retorno de la inversión)
* Priorizar las características de acuerdo al valor de mercado
* Puede cambiar las características y prioridad cada 30 días
* Acepta o rechaza el resultado del trabajo

===Para ejercer este rol es necesario:===

* Conocer perfectamente el entorno de negocio del cliente, las necesidades y el objetivo que se persigue con el sistema que se va a desarrollar.
* Tener atribuciones suficientes para tomar las decisiones necesarias durante el desarrollo.
* Conocer Scrum para realizar con solvencia las tareas que le corresponden:
* Desarrollo y administración de la pila del producto.
* Presentación y participación en la reunión de planificación de cada sprint.
* Recibir y analizar de forma continua retro-información del negocio (evolución del mercado, competencia, alternativas…) y del proyecto (sugerencias del equipo, alternativas técnicas, pruebas y evaluación de cada incremento…).
* Es recomendable conocer y haber trabajado previamente con el mismo equipo.

==Ver también==
* [[Roles De Scrum]]

Roles De Scrum

2008-07-26T21:09:31Z

190.172.86.173: /* Empresa */

En [[Scrum]], el equipo de personas que son responsables de crear la solución son usualmente conocidos como "Cerdos" (Pigs). Puede sonar un poco ofensivo, pero en realidad hace referencia a un chiste acerca de un cerdo y un pollo caminando por una ruta: el Pollo mira al cerdo y le dice "Hey, por qué no abrímos juntos un restaurante?". El cerdo mira al pollo y dice: "Buena idea, ¿cómo podría llamarse?". El pollo entonces piensa al respecto y finalmente dice: "¿Por qué no lo llamamos 'Jamón y Huevos'?". "Mmmmm, no me parece justo. ", dice el cerdo, "Yo estaría totalmente comprometido, mientras que vos sólo estarías algo involucrado".

Entonces tenemos a los '''Miembros del Equipo''', el '''Scrum Master''' y el '''Dueño del Producto''' (o Product Owner), que están comprometidos a construir software de manera frecuente y regular. Cualquier otro puede estar interesado en el proyecto pero, en realidad, es irrelevante ya que si el proyecto falla no eran cerdos, y por lo tanto no estaban comprometidos en hacerlo. Los "pollos" pueden ser stakeholders, usuarios, arquitectos y demás personas que puedan estar interesadas en el proyecto, y que cuyo interés puedan atentar contra la entrega de software.

Una de las características claves de un proceso ágil es involucrar a los usuarios, negocio y stakeholders y hacerlos parte del proceso. Es esencial que estén involucrados y den su feedback de los incrementos resultantes de los Sprints.

==Empresa==
El grado de éxito de Scrum en una empresa no depende sólo de los roles y las responsabilidades directamente relacionadas con el desarrollo de los proyectos (cliente y equipo).
Las organizaciones son realidades inter-relacionadas, y aunque aquí veremos los roles relacionados con la ejecución directa del proyecto, el área directiva o de management de la organización, así como la de
procesos tienen también responsabilidades que deben gestionar de forma coordinada y alineada en una estrategia que genere el mejor ecosistema para la implantación y evolución de trabajos en “campos de Scrum”.

[[Responsabilidades Roles]]

==Roles de cerdo==
Los cerdos son quienes están realmente comprometidos con el proyecto y el proceso de Scrum.

* [[Dueño Del Producto]] (representa la voz del cliente)
* [[Scrum Master]] (el facilitador de Scrum, asegura y guía en el proceso de Scrum, y quita escollos)
* [[Miembros Del Equipo De Scrum]] (los responsables de crear el producto)

==Roles de pollo==
Los pollos no forman parte del proceso de Scrum, pero se tienen que tener en cuenta.
* Usuarios (quienes utilizarán el software)
* Stakeholders (clientes, vendors; aquellos que permiten que exista el proyecto)
* Gerentes (los administradores de la organización)

Roles De Scrum

2008-07-26T21:09:08Z

190.172.86.173: Página nueva: En Scrum, el equipo de personas que son responsables de crear la solución son usualmente conocidos como "Cerdos" (Pigs). Puede sonar un poco ofensivo, pero en realidad hace refer...

En [[Scrum]], el equipo de personas que son responsables de crear la solución son usualmente conocidos como "Cerdos" (Pigs). Puede sonar un poco ofensivo, pero en realidad hace referencia a un chiste acerca de un cerdo y un pollo caminando por una ruta: el Pollo mira al cerdo y le dice "Hey, por qué no abrímos juntos un restaurante?". El cerdo mira al pollo y dice: "Buena idea, ¿cómo podría llamarse?". El pollo entonces piensa al respecto y finalmente dice: "¿Por qué no lo llamamos 'Jamón y Huevos'?". "Mmmmm, no me parece justo. ", dice el cerdo, "Yo estaría totalmente comprometido, mientras que vos sólo estarías algo involucrado".

Entonces tenemos a los '''Miembros del Equipo''', el '''Scrum Master''' y el '''Dueño del Producto''' (o Product Owner), que están comprometidos a construir software de manera frecuente y regular. Cualquier otro puede estar interesado en el proyecto pero, en realidad, es irrelevante ya que si el proyecto falla no eran cerdos, y por lo tanto no estaban comprometidos en hacerlo. Los "pollos" pueden ser stakeholders, usuarios, arquitectos y demás personas que puedan estar interesadas en el proyecto, y que cuyo interés puedan atentar contra la entrega de software.

Una de las características claves de un proceso ágil es involucrar a los usuarios, negocio y stakeholders y hacerlos parte del proceso. Es esencial que estén involucrados y den su feedback de los incrementos resultantes de los Sprints.

==Empresa==
El grado de éxito de Scrum en una empresa no depende sólo de los roles y las responsabilidades directamente relacionadas con el desarrollo de los proyectos (cliente y equipo).
Las organizaciones son realidades inter-relacionadas, y aunque aquí veremos los roles relacionados con la ejecución directa del proyecto, el área directiva o de management de la organización, así como la de
procesos tienen también responsabilidades que deben gestionar de forma coordinada y alineada en una estrategia que genere el mejor ecosistema para la implantación y evolución de trabajos en “campos de Scrum”.

[Responsabilidades Roles]

==Roles de cerdo==
Los cerdos son quienes están realmente comprometidos con el proyecto y el proceso de Scrum.

* [[Dueño Del Producto]] (representa la voz del cliente)
* [[Scrum Master]] (el facilitador de Scrum, asegura y guía en el proceso de Scrum, y quita escollos)
* [[Miembros Del Equipo De Scrum]] (los responsables de crear el producto)

==Roles de pollo==
Los pollos no forman parte del proceso de Scrum, pero se tienen que tener en cuenta.
* Usuarios (quienes utilizarán el software)
* Stakeholders (clientes, vendors; aquellos que permiten que exista el proyecto)
* Gerentes (los administradores de la organización)

Preparacion De Un Proyecto Scrum

2008-07-26T21:06:06Z

190.172.86.173: /* El caso de negocio */

La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su objetivo es invertir la menor cantidad de tiempo posible para lograr llegar a una posición donde se pueda comenzar con el ciclo iterativo de Scrum.

La fase de "Preparación" contiene algunas tareas que son candidatas a realizar durante la etapa de iniciación de un proyecto. Esta fase de iniciar un proyecto Scrum se conoce a veces como '''Sprint 0'''.

===El caso de negocio===
Todo proyecto debería tener un caso de negocio sin importar la forma en la que se llevará a cabo. Se necesita una clara compresión del valor que el proyecto le va a a agregar a la organización para luego poder tomar decisiones relativas a la prioridad de las características que serán entregadas.

Por lo tanto, es importante comprender y aceptar que las estimaciones realizadas durante esta etapa son de muy alto nivel y, por lo tanto, imprecisas. Es por eso que el [[Backlog Del Producto]] es estimado en días: estimar en cualquier otra unidad de tiempo más chica daría una falsa sensación de exactitud. Por otro lado, lo mismo es cierto sobre la estimación del valor que el proyecto le dará a la empresa, el cual será sin dudas también inexacto. Es decir, no vale la pena invertir mucho tiempo en lograr estimaciones exactas de esfuerzo, a menos que se esté preparado para invertir el mismo tiempo en lograr estimaciones igual de exactas para los beneficios. Todo este tiempo está mejor invertido en crear el producto en si mismo, en lugar de agonizar y discutir sobre la exactitud de las estimaciones.

Por otro lado, debido a la naturaleza iterativa de Scrum, la inexactitud de las estimaciones se hacen evidente muy rápidamente, ni bien comienza a aparecer datos reales sobre qué tan rápido el equipo de desarrollo puede entregar software que funcione. Esto significa que los proyectos Scrum son mucho más efectivos mitigando el riesgo de estimaciones inexactas y, por lo tanto, no necesiten perder tiempo intentando bajar el riesgo de la estimación al principio.

Una de las ventajas más importantes de Scrum, muchas veces ignorada, es que permite ver muy fácilmente si un proyecto es viable. Si un requerimiento de negocio es muy demandante para el equipo y tecnología disponibles, debería resultar evidente tras el primer Sprint que el equipo no podrá entregar la funcionalidad requerida. Esto le permitirá a la empresa cancelar el proyecto luego de unas pocas semanas, en lugar de descubrir esta información tras 6, 12 o 18 meses de arduo trabajo. Scrum permite que el negocio tenga el control del proyecto realmente.

===La visión del proyecto===
Scrum, como otras metodologías ágiles, no fomentan la documentación innecesaria. Sin embargo, es importante que el equipo completo comprenda la esencia del proyecto o producto que están intentando crear. Aquí es donde la Visión del Proyecto entra en juego. Debería ser lo más corta y accesible posible, comunicando la esencia y espíritu del emprendimiento. Comunicar la visión es tan importante cómo tenerla. Un buen ejemplo de éxito sería poder preguntarle a cualquier integrante del equipo que explique correctamente el propósito del proyecto.

La Visión del Proyecto debería ser descompuesta en un set levemente más detallado de Visiones de Entregable, una por entregable. Un pequeño set de slides en una presentación deberían funcionar bien para esto.

===Backlog inicial del proyecto===
A medida que el equipo entra en el primer Sprint, debería tener disponible suficientes ítems en el BacklogDelProducto enumerados y priorizados para permitirles comenzar a trabajar. Estos items del backlog pueden haber surgido durante el trabajo de crear el caso de negocio, transformados de un documento de requerimientos, o creados directamente por el [[Dueño Del Producto]].

===Plan inicial para los entregables===
El [[Backlog Del Producto]] contiene toda la funcionalidad que el producto debería tener. Si toda esta funcionalidad se construye antes de un entregable productivo, se pierde la oportunidad que Scrum brinda de poder ser por adelantado el valor del producto, y obtener feedback de manera temprana. Por estos motivos es una práctica común dividir el backlog en "Entretables" o colección de características útiles del sistema, que tienen sentido ponerlas en producción.

Es importante recordar que lo que al principio puede parecer un set coherente de entregables, puede cambiar con el paso del tiempo, de forma que es necesaria cierta flexibilidad. Algunas razones para cambiar un plan de entregas son:
* cambio en las oportunidades del negocio.
* durante una [[Revision Del Sprint]] el grupo de usuarios puede encontrar que la funcionalidad mostrada podría entregar valor al negocio si fuera puesta en producción.
* demasiadas características para un entregable en el tiempo dado, de forma que se requiera más tiempo o menos características para el entregable.

Cuando se crea un plan de entregas:
* el negocio determina cuando se necesita un entregable, la funcionalidad que debe contener, el nivel de aceptación de la calidad y el costo.
* el equipo de desarrollo determina cuánto se tardara en construir ese entregable
* el equipo de desarrollo crea las estimaciones preliminares
* el equipo de desarrollo refina las estimaciones a medida que se incrementan las prioridades
* el equipo selecciona el backlog del producto a desarrollar, cada Sprint (backlog del Sprint)
* el negocio se centra en el valor entregado por cada entregable

===Constitución del equipo===
Una vez que todos los roles del equipo están identificados, el equipo debería juntarse para una reunión de kick off, en la cual se deberían tratar:
* el alcance del proyecto
* una revisión rápida del backlog
* cualquier discusión técnica
* acuerdos iniciales sobre cómo el equipo trabajará junto (por ejemplo, a qué hora son las reuniones diarias)

===Logística===
Hay ciertas tareas de organización y logística que deben completarse al iniciar un proyecto ágil:
* tener un área o lugar disponible para el equipo
* tener las reuniones de kick off con el equipo
* planificar las reuniones con el usuario por adelantado, y agregarlas a las agendas de las personas
* crear una "pizarra de trabajo" en el área del equipo
* llenar las parades libres en el área del equipo con pizarras
* asegurarse que el equipo tiene lo necesario para comenzar el desarrollo del primer Sprint: notebooks / PCs, un sistema de [[Control De Versiones]], conectividad de red e Internet, entornos de desarrollo y test, etc...
* comprar café y snacks!

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]

Preparacion De Un Proyecto Scrum

2008-07-26T21:05:41Z

190.172.86.173: /* Logística */

La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su objetivo es invertir la menor cantidad de tiempo posible para lograr llegar a una posición donde se pueda comenzar con el ciclo iterativo de Scrum.

La fase de "Preparación" contiene algunas tareas que son candidatas a realizar durante la etapa de iniciación de un proyecto. Esta fase de iniciar un proyecto Scrum se conoce a veces como '''Sprint 0'''.

===El caso de negocio===
Todo proyecto debería tener un caso de negocio sin importar la forma en la que se llevará a cabo. Se necesita una clara compresión del valor que el proyecto le va a a agregar a la organización para luego poder tomar decisiones relativas a la prioridad de las características que serán entregadas.

Por lo tanto, es importante comprender y aceptar que las estimaciones realizadas durante esta etapa son de muy alto nivel y, por lo tanto, imprecisas. Es por eso que el BacklogDelProducto es estimado en días: estimar en cualquier otra unidad de tiempo más chica daría una falsa sensación de exactitud. Por otro lado, lo mismo es cierto sobre la estimación del valor que el proyecto le dará a la empresa, el cual será sin dudas también inexacto. Es decir, no vale la pena invertir mucho tiempo en lograr estimaciones exactas de esfuerzo, a menos que se esté preparado para invertir el mismo tiempo en lograr estimaciones igual de exactas para los beneficios. Todo este tiempo está mejor invertido en crear el producto en si mismo, en lugar de agonizar y discutir sobre la exactitud de las estimaciones.

Por otro lado, debido a la naturaleza iterativa de Scrum, la inexactitud de las estimaciones se hacen evidente muy rápidamente, ni bien comienza a aparecer datos reales sobre qué tan rápido el equipo de desarrollo puede entregar software que funcione. Esto significa que los proyectos Scrum son mucho más efectivos mitigando el riesgo de estimaciones inexactas y, por lo tanto, no necesiten perder tiempo intentando bajar el riesgo de la estimación al principio.

Una de las ventajas más importantes de Scrum, muchas veces ignorada, es que permite ver muy fácilmente si un proyecto es viable. Si un requerimiento de negocio es muy demandante para el equipo y tecnología disponibles, debería resultar evidente tras el primer Sprint que el equipo no podrá entregar la funcionalidad requerida. Esto le permitirá a la empresa cancelar el proyecto luego de unas pocas semanas, en lugar de descubrir esta información tras 6, 12 o 18 meses de arduo trabajo. Scrum permite que el negocio tenga el control del proyecto realmente.

===La visión del proyecto===
Scrum, como otras metodologías ágiles, no fomentan la documentación innecesaria. Sin embargo, es importante que el equipo completo comprenda la esencia del proyecto o producto que están intentando crear. Aquí es donde la Visión del Proyecto entra en juego. Debería ser lo más corta y accesible posible, comunicando la esencia y espíritu del emprendimiento. Comunicar la visión es tan importante cómo tenerla. Un buen ejemplo de éxito sería poder preguntarle a cualquier integrante del equipo que explique correctamente el propósito del proyecto.

La Visión del Proyecto debería ser descompuesta en un set levemente más detallado de Visiones de Entregable, una por entregable. Un pequeño set de slides en una presentación deberían funcionar bien para esto.

===Backlog inicial del proyecto===
A medida que el equipo entra en el primer Sprint, debería tener disponible suficientes ítems en el BacklogDelProducto enumerados y priorizados para permitirles comenzar a trabajar. Estos items del backlog pueden haber surgido durante el trabajo de crear el caso de negocio, transformados de un documento de requerimientos, o creados directamente por el [[Dueño Del Producto]].

===Plan inicial para los entregables===
El [[Backlog Del Producto]] contiene toda la funcionalidad que el producto debería tener. Si toda esta funcionalidad se construye antes de un entregable productivo, se pierde la oportunidad que Scrum brinda de poder ser por adelantado el valor del producto, y obtener feedback de manera temprana. Por estos motivos es una práctica común dividir el backlog en "Entretables" o colección de características útiles del sistema, que tienen sentido ponerlas en producción.

Es importante recordar que lo que al principio puede parecer un set coherente de entregables, puede cambiar con el paso del tiempo, de forma que es necesaria cierta flexibilidad. Algunas razones para cambiar un plan de entregas son:
* cambio en las oportunidades del negocio.
* durante una [[Revision Del Sprint]] el grupo de usuarios puede encontrar que la funcionalidad mostrada podría entregar valor al negocio si fuera puesta en producción.
* demasiadas características para un entregable en el tiempo dado, de forma que se requiera más tiempo o menos características para el entregable.

Cuando se crea un plan de entregas:
* el negocio determina cuando se necesita un entregable, la funcionalidad que debe contener, el nivel de aceptación de la calidad y el costo.
* el equipo de desarrollo determina cuánto se tardara en construir ese entregable
* el equipo de desarrollo crea las estimaciones preliminares
* el equipo de desarrollo refina las estimaciones a medida que se incrementan las prioridades
* el equipo selecciona el backlog del producto a desarrollar, cada Sprint (backlog del Sprint)
* el negocio se centra en el valor entregado por cada entregable

===Constitución del equipo===
Una vez que todos los roles del equipo están identificados, el equipo debería juntarse para una reunión de kick off, en la cual se deberían tratar:
* el alcance del proyecto
* una revisión rápida del backlog
* cualquier discusión técnica
* acuerdos iniciales sobre cómo el equipo trabajará junto (por ejemplo, a qué hora son las reuniones diarias)

===Logística===
Hay ciertas tareas de organización y logística que deben completarse al iniciar un proyecto ágil:
* tener un área o lugar disponible para el equipo
* tener las reuniones de kick off con el equipo
* planificar las reuniones con el usuario por adelantado, y agregarlas a las agendas de las personas
* crear una "pizarra de trabajo" en el área del equipo
* llenar las parades libres en el área del equipo con pizarras
* asegurarse que el equipo tiene lo necesario para comenzar el desarrollo del primer Sprint: notebooks / PCs, un sistema de [[Control De Versiones]], conectividad de red e Internet, entornos de desarrollo y test, etc...
* comprar café y snacks!

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]

Preparacion De Un Proyecto Scrum

2008-07-26T21:04:55Z

190.172.86.173: Página nueva: La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su obj...

La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su objetivo es invertir la menor cantidad de tiempo posible para lograr llegar a una posición donde se pueda comenzar con el ciclo iterativo de Scrum.

La fase de "Preparación" contiene algunas tareas que son candidatas a realizar durante la etapa de iniciación de un proyecto. Esta fase de iniciar un proyecto Scrum se conoce a veces como '''Sprint 0'''.

===El caso de negocio===
Todo proyecto debería tener un caso de negocio sin importar la forma en la que se llevará a cabo. Se necesita una clara compresión del valor que el proyecto le va a a agregar a la organización para luego poder tomar decisiones relativas a la prioridad de las características que serán entregadas.

Por lo tanto, es importante comprender y aceptar que las estimaciones realizadas durante esta etapa son de muy alto nivel y, por lo tanto, imprecisas. Es por eso que el BacklogDelProducto es estimado en días: estimar en cualquier otra unidad de tiempo más chica daría una falsa sensación de exactitud. Por otro lado, lo mismo es cierto sobre la estimación del valor que el proyecto le dará a la empresa, el cual será sin dudas también inexacto. Es decir, no vale la pena invertir mucho tiempo en lograr estimaciones exactas de esfuerzo, a menos que se esté preparado para invertir el mismo tiempo en lograr estimaciones igual de exactas para los beneficios. Todo este tiempo está mejor invertido en crear el producto en si mismo, en lugar de agonizar y discutir sobre la exactitud de las estimaciones.

Por otro lado, debido a la naturaleza iterativa de Scrum, la inexactitud de las estimaciones se hacen evidente muy rápidamente, ni bien comienza a aparecer datos reales sobre qué tan rápido el equipo de desarrollo puede entregar software que funcione. Esto significa que los proyectos Scrum son mucho más efectivos mitigando el riesgo de estimaciones inexactas y, por lo tanto, no necesiten perder tiempo intentando bajar el riesgo de la estimación al principio.

Una de las ventajas más importantes de Scrum, muchas veces ignorada, es que permite ver muy fácilmente si un proyecto es viable. Si un requerimiento de negocio es muy demandante para el equipo y tecnología disponibles, debería resultar evidente tras el primer Sprint que el equipo no podrá entregar la funcionalidad requerida. Esto le permitirá a la empresa cancelar el proyecto luego de unas pocas semanas, en lugar de descubrir esta información tras 6, 12 o 18 meses de arduo trabajo. Scrum permite que el negocio tenga el control del proyecto realmente.

===La visión del proyecto===
Scrum, como otras metodologías ágiles, no fomentan la documentación innecesaria. Sin embargo, es importante que el equipo completo comprenda la esencia del proyecto o producto que están intentando crear. Aquí es donde la Visión del Proyecto entra en juego. Debería ser lo más corta y accesible posible, comunicando la esencia y espíritu del emprendimiento. Comunicar la visión es tan importante cómo tenerla. Un buen ejemplo de éxito sería poder preguntarle a cualquier integrante del equipo que explique correctamente el propósito del proyecto.

La Visión del Proyecto debería ser descompuesta en un set levemente más detallado de Visiones de Entregable, una por entregable. Un pequeño set de slides en una presentación deberían funcionar bien para esto.

===Backlog inicial del proyecto===
A medida que el equipo entra en el primer Sprint, debería tener disponible suficientes ítems en el BacklogDelProducto enumerados y priorizados para permitirles comenzar a trabajar. Estos items del backlog pueden haber surgido durante el trabajo de crear el caso de negocio, transformados de un documento de requerimientos, o creados directamente por el [[Dueño Del Producto]].

===Plan inicial para los entregables===
El [[Backlog Del Producto]] contiene toda la funcionalidad que el producto debería tener. Si toda esta funcionalidad se construye antes de un entregable productivo, se pierde la oportunidad que Scrum brinda de poder ser por adelantado el valor del producto, y obtener feedback de manera temprana. Por estos motivos es una práctica común dividir el backlog en "Entretables" o colección de características útiles del sistema, que tienen sentido ponerlas en producción.

Es importante recordar que lo que al principio puede parecer un set coherente de entregables, puede cambiar con el paso del tiempo, de forma que es necesaria cierta flexibilidad. Algunas razones para cambiar un plan de entregas son:
* cambio en las oportunidades del negocio.
* durante una [[Revision Del Sprint]] el grupo de usuarios puede encontrar que la funcionalidad mostrada podría entregar valor al negocio si fuera puesta en producción.
* demasiadas características para un entregable en el tiempo dado, de forma que se requiera más tiempo o menos características para el entregable.

Cuando se crea un plan de entregas:
* el negocio determina cuando se necesita un entregable, la funcionalidad que debe contener, el nivel de aceptación de la calidad y el costo.
* el equipo de desarrollo determina cuánto se tardara en construir ese entregable
* el equipo de desarrollo crea las estimaciones preliminares
* el equipo de desarrollo refina las estimaciones a medida que se incrementan las prioridades
* el equipo selecciona el backlog del producto a desarrollar, cada Sprint (backlog del Sprint)
* el negocio se centra en el valor entregado por cada entregable

===Constitución del equipo===
Una vez que todos los roles del equipo están identificados, el equipo debería juntarse para una reunión de kick off, en la cual se deberían tratar:
* el alcance del proyecto
* una revisión rápida del backlog
* cualquier discusión técnica
* acuerdos iniciales sobre cómo el equipo trabajará junto (por ejemplo, a qué hora son las reuniones diarias)

===Logística===
Hay ciertas tareas de organización y logística que deben completarse al iniciar un proyecto ágil:
* tener un área o lugar disponible para el equipo
* tener las reuniones de kick off con el equipo
* planificar las reuniones con el usuario por adelantado, y agregarlas a las agendas de las personas
* crear una "pizarra de trabajo" en el área del equipo
* llenar las parades libres en el área del equipo con pizarras
* asegurarse que el equipo tiene lo necesario para comenzar el desarrollo del primer Sprint: notebooks / PCs, un sistema de ControlDeVersiones, conectividad de red e Internet, entornos de desarrollo y test, etc...
* comprar café y snacks!

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]

Proceso De Desarrollo Con Scrum

2008-07-26T21:00:56Z

190.172.86.173: Página nueva: Scrum es un proceso iterativo que se puede usar para el desarrollo de software. Las etapas de este proceso son: # Preparacion De Un Proyecto Scrum ## Presentación de los [[...

[[Scrum]] es un proceso iterativo que se puede usar para el desarrollo de software.

Las etapas de este proceso son:

# [[Preparacion De Un Proyecto Scrum]]
## Presentación de los [[Roles De Scrum]]
## Creación del [[Backlog Del Producto]] inicial
# [[Planificacion Del Sprint]]
## Creación del [[Backlog Del Sprint]]
## Estimación mediante [[Planificacion De Poker]]
# [[Sprint]]
## [[Reunion Diaria De Scrum]]
## Actualización diaria del [[Seguimiento Del Sprint]]
## [[Revision Del Sprint]]
### [[Sprint De Release]]
## [[Retrospectiva Del Sprint]]
# [[Medicion Para Gestion Agil]]

==Resumen del proceso==
El proceso de Scrum se centra en entregar software con calidad productiva cada iteración.

Para comenzar el proceso es necesario realizar la debida [[Preparacion De Un Proyecto Scrum]], también conocida como Sprint 0, en dónde se conforma el equipo, se presenta la visión y la meta del proyecto. En la reunión del Sprint 0 el [[Dueño Del Producto]] puede también presentar la funcionalidad básica que tendrá el producto. También se define el horario para la [[Reunion Diaria De Scrum]] y cualquier otra convención necesaria para el proyecto.

Así, se puede entonces comenzar con le proceso iterativo.

Al principio del [[Sprint]], se comienza con la reunión de [[Planificacion Del Sprint]]. Esta reunión está dividida en dos partes. La primera parte es junto al [[Dueño Del Producto]], quien presenta el [[Backlog Del Producto]] priorizado y actualizado. Esto le permite a los [[Miembros Del Equipo De Scrum]] realizar la estimacion mediante [[Planificacion De Poker]], seleccionar un grupo realizable de items del backlog con la mayor prioridad, de acuerdo a la velocidad del equipo. La segunda parte de la reunión es ya interna al Equipo, en la cual se encargan de dividir los items del backlog seleccionados para el Sprint en tareas, creando así el [[Backlog Del Sprint]]. En esta segunda reunión se comienza a armar el dashboard principal para el [[Seguimiento Del Sprint]].

El equipo luego procede a trabajar en las tareas del [[Backlog Del Sprint]] en forma diaria, sincronizando su actividad durante la [[Reunion Diaria De Scrum]], y actualizando el estado del proyecto para mantener el [[Seguimiento Del Sprint]].

Al finalizar el Sprint el equipo tiene construido un [[Incremento Del Producto]] el cual se lo muestran al [[Dueño Del Producto]], usuarios del negocio y cualquier stakeholder interesado durante la [[Revision Del Sprint]].

El feedback obtenido de la [[Revision Del Sprint]] será añadido al [[Backlog Del Producto]] y priorizado por el [[Dueño Del Producto]]. Antes de comenzar el próximo Sprint el equipo analiza la performance y realiza mejoras en la forma de trabajo durante la [[Retrospectiva Del Sprint]].

El equipo continuará realizando sprints hasta haber desarrollado algo lo suficientemente útil para que pueda ser puesto en producción, momento en el que se inicia un [[Sprint De Release]].

Durante todo el proceso, el Scrum Master y el [[Dueño Del Producto]] deciden cómo gestionar las [[Interrupciones En Scrum]], como ser bugs y soporte a Producción que pudieran afectar al Sprint.

==Ejemplo==
* [[Sesion De Ejemplo De Scrum]]

==Más información==
* [http://www.scrumforteamsystem.com/processguidance/v2/ProcessGuidance.aspx Guía del proceso de Scrum]

Interrupciones En Scrum

2008-07-26T20:53:02Z

190.172.86.173:

El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[Scrum Master]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.

Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su [[Sprint]], tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el [[Dueño Del Producto]]. De hecho, de poco le servirá al [[Dueño Del Producto]] que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.

===Tipos de interrupciones===

Durante el proceso de [[Scrum]] pueden surgir diferentes tipos de interrupciones, que atentan contra la entrega de software para el [[Sprint]] en curso. Estas interrupciones puede ser:
* Soporte técnico que no puede ser resuelto por la primer línea de soporte de la empresa
* Tareas de mantenimiento del sistema.
* Pedidos de investigación de comportamientos extraños en el sistema.
* Pedidos de información del sistema que no se consiguen facilmente, y requieren la dedicación de un desarrollador.
* Problemas en el entorno productivo (por ejemplo, mala performance o caidas) que requieren la atención de desarrolladores.

==Gestión de interrupciones==

Todos estos aspectos (y algunos más) puede ser potencialmente más importantes que completar nuevas historias. Entonces, ¿cómo ma}nejar estas interrupciones en el [[Sprint]]?

Hay varias formas de llevar adelante las interrupciones, y depende de la cultura de la empresa y las características de la propia interrupción.

*'''Usar dos Backlog''': tener un backlog para las características del producto, y otro para temas relacionados al soporte de producción. El [[Dueño Del Producto]] define la cantidad de trabajo que se realiza en cada backlog. En este escenario, se puede llevar un gráfico burn-down para el backlog del producto, y un gráfico burn-up para el soporte a producción.

*'''Bugs como historias''': se ubican las interrupciones como historias dentro del backlog del producto, y se estiman de la misma manera, incluso los problemas productivos. El [[Dueño Del Producto]] luego las prioriza según sus necesidades, y elige acorde.

*'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint.

====Atención de las interrupciones====
Otro tema importante a resolver es quién deberá trabajar en las interrupciones. El soporte de producción puede ser aburrido, y en general nadie del equipo quiere hacerlo. Es por esto que tener un equipo dedicado al soporte no es buena idea. Además, un equipo dedicado a soporte genera una división de las tareas, con la confusión que esto trae.

Una opción es contar con un "rol de soporte" que vaya cambiando de Sprint a Sprint, o semanalmente. Esto ayuda a reforzar el sentido de equipo, y como beneficio adicional aumenta el conocimiento general del sistema.

Otra opción para atender las interrupciones es utilizar el concepto de "Sacrificar una persona". con este concepto, la solución del problema se asigna a una persona que se dedica en forma exclusiva a la interrupción. Si bien esta persona queda "sacrificada", el resto del equipo puede seguir progresando en su actividad principal.

En resumen, cuando llegue el momento de gestionar interrupciones, considerar el ubicarlas en el backlog del producto, y priorizarlas. Esto ayuda a asegurarse de que el equipo siempre esté realizando el trabajo correcto. De todas formas, si la interrupción es una emergencia, entonces ocurrirá un costo para el Sprint, y la decisión dependerá de evaluar este costo versus una resolución inmediata.

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]

==Más información==
* [http://www.infoq.com/news/2008/07/interruption-driven-development Interruption Driver Development]

Interrupciones En Scrum

2008-07-26T20:52:45Z

190.172.86.173: /* Tipos de interrupciones */

El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[ScrumMaster]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.

Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su [[Sprint]], tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el [[Dueño Del Producto]]. De hecho, de poco le servirá al [[Dueño Del Producto]] que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.

===Tipos de interrupciones===

Durante el proceso de [[Scrum]] pueden surgir diferentes tipos de interrupciones, que atentan contra la entrega de software para el [[Sprint]] en curso. Estas interrupciones puede ser:
* Soporte técnico que no puede ser resuelto por la primer línea de soporte de la empresa
* Tareas de mantenimiento del sistema.
* Pedidos de investigación de comportamientos extraños en el sistema.
* Pedidos de información del sistema que no se consiguen facilmente, y requieren la dedicación de un desarrollador.
* Problemas en el entorno productivo (por ejemplo, mala performance o caidas) que requieren la atención de desarrolladores.

==Gestión de interrupciones==

Todos estos aspectos (y algunos más) puede ser potencialmente más importantes que completar nuevas historias. Entonces, ¿cómo ma}nejar estas interrupciones en el [[Sprint]]?

Hay varias formas de llevar adelante las interrupciones, y depende de la cultura de la empresa y las características de la propia interrupción.

*'''Usar dos Backlog''': tener un backlog para las características del producto, y otro para temas relacionados al soporte de producción. El [[Dueño Del Producto]] define la cantidad de trabajo que se realiza en cada backlog. En este escenario, se puede llevar un gráfico burn-down para el backlog del producto, y un gráfico burn-up para el soporte a producción.

*'''Bugs como historias''': se ubican las interrupciones como historias dentro del backlog del producto, y se estiman de la misma manera, incluso los problemas productivos. El [[Dueño Del Producto]] luego las prioriza según sus necesidades, y elige acorde.

*'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint.

====Atención de las interrupciones====
Otro tema importante a resolver es quién deberá trabajar en las interrupciones. El soporte de producción puede ser aburrido, y en general nadie del equipo quiere hacerlo. Es por esto que tener un equipo dedicado al soporte no es buena idea. Además, un equipo dedicado a soporte genera una división de las tareas, con la confusión que esto trae.

Una opción es contar con un "rol de soporte" que vaya cambiando de Sprint a Sprint, o semanalmente. Esto ayuda a reforzar el sentido de equipo, y como beneficio adicional aumenta el conocimiento general del sistema.

Otra opción para atender las interrupciones es utilizar el concepto de "Sacrificar una persona". con este concepto, la solución del problema se asigna a una persona que se dedica en forma exclusiva a la interrupción. Si bien esta persona queda "sacrificada", el resto del equipo puede seguir progresando en su actividad principal.

En resumen, cuando llegue el momento de gestionar interrupciones, considerar el ubicarlas en el backlog del producto, y priorizarlas. Esto ayuda a asegurarse de que el equipo siempre esté realizando el trabajo correcto. De todas formas, si la interrupción es una emergencia, entonces ocurrirá un costo para el Sprint, y la decisión dependerá de evaluar este costo versus una resolución inmediata.

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]

==Más información==
* [http://www.infoq.com/news/2008/07/interruption-driven-development Interruption Driver Development]

Interrupciones En Scrum

2008-07-26T20:51:22Z

190.172.86.173: Página nueva: El proceso de Scrum habla de tener un mínimo de interferencia durante el Sprint, de manera que los Miembros Del Equipo De Scrum puedan abocarse completamente al cumplimie...

El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[ScrumMaster]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.

Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su [[Sprint]], tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el [[Dueño Del Producto]]. De hecho, de poco le servirá al [[Dueño Del Producto]] que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.

===Tipos de interrupciones===

Durante el proceso de [Scrum] pueden surgir diferentes tipos de interrupciones, que atentan contra la entrega de software para el [Sprint] en curso. Estas interrupciones puede ser:
* Soporte técnico que no puede ser resuelto por la primer línea de soporte de la empresa
* Tareas de mantenimiento del sistema.
* Pedidos de investigación de comportamientos extraños en el sistema.
* Pedidos de información del sistema que no se consiguen facilmente, y requieren la dedicación de un desarrollador.
* Problemas en el entorno productivo (por ejemplo, mala performance o caidas) que requieren la atención de desarrolladores.

==Gestión de interrupciones==

Todos estos aspectos (y algunos más) puede ser potencialmente más importantes que completar nuevas historias. Entonces, ¿cómo ma}nejar estas interrupciones en el [[Sprint]]?

Hay varias formas de llevar adelante las interrupciones, y depende de la cultura de la empresa y las características de la propia interrupción.

*'''Usar dos Backlog''': tener un backlog para las características del producto, y otro para temas relacionados al soporte de producción. El [[Dueño Del Producto]] define la cantidad de trabajo que se realiza en cada backlog. En este escenario, se puede llevar un gráfico burn-down para el backlog del producto, y un gráfico burn-up para el soporte a producción.

*'''Bugs como historias''': se ubican las interrupciones como historias dentro del backlog del producto, y se estiman de la misma manera, incluso los problemas productivos. El [[Dueño Del Producto]] luego las prioriza según sus necesidades, y elige acorde.

*'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint.

====Atención de las interrupciones====
Otro tema importante a resolver es quién deberá trabajar en las interrupciones. El soporte de producción puede ser aburrido, y en general nadie del equipo quiere hacerlo. Es por esto que tener un equipo dedicado al soporte no es buena idea. Además, un equipo dedicado a soporte genera una división de las tareas, con la confusión que esto trae.

Una opción es contar con un "rol de soporte" que vaya cambiando de Sprint a Sprint, o semanalmente. Esto ayuda a reforzar el sentido de equipo, y como beneficio adicional aumenta el conocimiento general del sistema.

Otra opción para atender las interrupciones es utilizar el concepto de "Sacrificar una persona". con este concepto, la solución del problema se asigna a una persona que se dedica en forma exclusiva a la interrupción. Si bien esta persona queda "sacrificada", el resto del equipo puede seguir progresando en su actividad principal.

En resumen, cuando llegue el momento de gestionar interrupciones, considerar el ubicarlas en el backlog del producto, y priorizarlas. Esto ayuda a asegurarse de que el equipo siempre esté realizando el trabajo correcto. De todas formas, si la interrupción es una emergencia, entonces ocurrirá un costo para el Sprint, y la decisión dependerá de evaluar este costo versus una resolución inmediata.

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]

==Más información==
* [http://www.infoq.com/news/2008/07/interruption-driven-development Interruption Driver Development]

Scrum

2008-07-26T17:48:01Z

190.172.86.173: Página nueva: Scrum es una metodología para la gestión de proyectos. Es considerada metodología ágil para el DesarrolloAgilDeSoftware, si bien Scrum puede ser aplicado para la administración d...

Scrum es una metodología para la gestión de proyectos. Es considerada metodología ágil para el DesarrolloAgilDeSoftware, si bien Scrum puede ser aplicado para la administración de proyectos de prácticamente cualquier índole.

Scrum es un proceso que incluye un conjunto de practicas y roles predefinidos. Los principales [[Roles De Scrum]] son el [[Scrum Master]] el cual se encarga de mantener los procesos y tareas de manera similar a un Project Manager; El [[Dueño Del Producto]] o Product Owner (tambien llamado "Hombre de Negocios") quien representa a los interesados (stakeholders) y es parte de la compañía que solicita el producto; y los [[Miembros Del Equipo De Scrum]] que incluye a los desarrolladores. Es importante destacar que en la práctica se usan los nombres de origen ingles (Ejemplo: Project Manager, en vez de gerente de proyecto).

Durante cada [[Sprint]] o iteración, un periodo de 2 a 4 semanas decidido por el equipo, el equipo crea un [[Incremento Del Producto]] de un prototipo del software utilizable. Es importante que el prototipo sea funcional, esto quiere decir que compile en primer medida.

El conjunto de características que se suman en cada iteración provienen del [[Backlog Del Producto]] (o simplemente backlog), el cuales un conjunto de requerimientos de alto nivel que tienen que ser realizados ordenados por prioridad. Qué requerimientos se incluyen en el backlog se determina en la reunión de planificación de cada iteración. Durante esta reunión el Dueño del Producto le informa al equipo de los ítems en el backlog que quiere que sean completados.

Durante la iteración, nadie esta habilitado a cambiar el backlog, lo que significa que los requerimientos están congelados para esa iteración. Hay muchas buenas implementaciones de sistemas para asistir a un desarrollo de Scrum. Otros prefieren simplemente una pizarra y anotaciones en un "memo". Una de las principales ventajas del método Scrum es que es muy fácil de aprender y requiere un mínimo esfuerzo para empezar a utilizarlo.

==Valores==
Scrum es una metodología muy simple en su composición, sin embargo sus fundamentos teóricos y los valores en los que se fundamentan tienen implicaciones que van más allá de la simplicidad de sus componentes. Los valores de scrum y del manifiesto ágil son el "pegamento" que une a las personas en las reuniones y a través de los documentos y les permite cumplir con sus compromisos día a día, sprint a sprint hasta el éxito del proyecto.
*'''Compromiso''': Estar dispuesto para comprometerse a una meta. La metodología la da a las personas la autoridad que necesitan para cumplir con sus compromisos.
*'''Enfoque''': Haz tu trabajo. Enfoca todos tus esfuerzos y habilidades para trabajar en lo que te comprometiste a hacer. No te preocupes por nada más. Alguien lo hara por ti.
*'''Apertura / honestidad''': Scrum mantiene todo acerca del proyecto visible a todos.
*'''Respeto''': Los individuos estamos formados por nuestros orígenes y nuestras experiencias. Es importante respetar las diferentes a las personas del equipo y sus formas de pensar.
*'''Coraje''': Tener el coraje para comprometerse, actuar, ser honesto y esperar respeto.

==Scrum para el desarrollo de software==
Scrum nada dice sobre cómo llevar adelante una iteración. Es por esto que Scrum se complementa perfectamente con [[Extreme Programming]] y [[Test Driven Development]], práctias que suelen usarse en conjunto a Scrum para llevar adelante un [[Desarrollo Agil De Software]].

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]
* [[Herramientas Para Planificacion Colaborativa]]
* [[Metodologia Agil En Una Organizacion En Cascada]]
* [[Interrupciones En Scrum]]

==Más información==
* [http://es.wikipedia.org/wiki/Scrum Scrum en la Wikipedia]
* [http://www.navegapolis.net/content/view/694/61/ Flexibilidad con Scrum (libro gratuito)]
* [http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Scrum and XP from the trenches (libro gratuito en inglés)]
* [http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx Explicando Scrum a mi abuela]
* [http://www.chuidiang.com/ood/metodologia/scrum.php Breve explicación de Scrum]

Metodologia Agil En Una Organizacion En Cascada

2008-07-26T17:40:48Z

190.172.86.173: /* 10 consejos para integrar Ágil y Cascada */

Es posible aplicar una metodologia ágil dentro de una organizacion que utiliza Cascada como proceso. Ambos mundos pueden coexistir: es necesario crear un "puente" entre ambos. De hecho, esta es una situación común, y este "puente" suele ser el primer paso para una transformación más profunda.

Es posible entonces, por ejemplo, llevar un proceso ágil de desarrollo por más que los extremos no lo sean. Sin embargo, hay que tener en cuenta algunos obstáculos que puedan ocurrir en el camino, y cómo sortearlos.

==Obstáculos==
===Resistencia===
La resistencia al cambio es normal, y no será una excepción al intentar aplicar una nueva metodología. Es importante que la actitud a tomar deberá ser la de "vender" la metodología ágil, y no transformarse en un actor defensor de la misma (por sentirnos atacados).

====Resistencia del Management====
Lo más más recomendable es no intentar venderle el cambio: de todas formas, no saben lo que se está haciendo ahora tampoco.

Por otro lado, es importante comunicarse en su mundo e idioma: explicar los beneficios de una metodología ágil, el incremento del ROI, entregas más tempranas, mayor calidad, reducción de costos, etc. Evitar términos como Scrum, Sprint, Backlog, XP, etc, que no aportan al objetivo final.

Por último, es bueno recopilar historias de éxito para compartir con el management: esto les puede transmitir experiencias reales, y brindarles más seguridad sobre el cambio que se está llevando adelante.

====Resistencia del negocio====
Es importante involucrar al [[Dueño Del Producto]] y demás participantes desde el principio: tienen que sentirse parte del proceso, y comprender el mismo.

Sirve mucho destacar el bajo riesgo: "Satisfacción garantizada, o le devolvemos el dinero". Es decir, explicar que el Dueño del Producto puede realizar cambios frecuentes (cada 1 Sprint!), revisando qué cosas no le gustó del proceso y ver cómo cambiarlas. Más aún, puede cancelar el proyecto temprananmente si consigue la funcionalidad requerida, o el proyecto deja de tener sentido para el negocio.

Por último, una buena práctica es comenzar a adoptar herramientas y prácticas ágiles al proceso de desarrollo, por más que la metodología todavía no se implemente. Técnicas como [[Integracion Continua]], [[Automatizacion De Pruebas Unitarias]], programación de pares, etc, pueden ir "preparando el terreno" entre las personas.

====Resistencia del Equipo====
No hacerse problema por los integrantes escépticos: de hecho, es su trabajo diario el cuestionar y revisar. Es necesario responder y aclarar todas sus inquietudes, con sinceridad. Si no se sabe una respuesta, o plantean una situación que no se había previsto, integrarlos para hallar juntos una solución.

Es bueno también que el Equipo cuente con un "guía" (un Coach ágil), el cual los pueda asistir y guiar en el proceso de implementar un proceso ágil de desarrollo.

===Administración de recursos===
Muchas veces las empresas necesitan asignar personal por adelantado. Puede ayudar en estos casos presentar un Release Plan, para poder ir calculando qué personas serán necesarias en distintas fechas.

No es un requesito obligatorio que todos los integrantes del equipo se encuentren físicamente ubicados en el mismo lugar (si bien es una condición deseable). En el caso de que los equipos no pueden co-habitar el mismo espacio, será necesario contar con herramientas que faciliten su interacción.

===Vendors y Contrataciones===
Los Vendors proveen al equipo con algún servicio o producto necesario para el proyecto. Si la relación con el Vendor es a corto plazo, no vale la pena intentar explicarles el proceso ágil: simplemente tomar su resultado y seguir avanzando. Por otro lado, en el caso de relaciones a largo plazo (por ejemplo, integrantes tercerizados del equipo) será necesario realizar una capacitación y explicar el proceso de desarrollo ágil.

Cuando el proyecto sea para un cliente que no es ágil, será importante explicarles el proceso, haciendo incapié en los beneficios que se dará. Remarcar que pueden cancelar el proyecto cuando lo deseen, de manera de brindarles seguridad.

===Facilidades y Herramientas===
Todos los equipos y lugares de trabajo son diferentes, por lo que las soluciones van a variar de acuerdo al lugar. Involucrar siempre al equipo para encontrar soluciones al acondicionamiento del lugar: cómo ubicarse, dónde reunirse, qué salas usar, dónde pegar los gráficos, etc.

Es importante destacar que los equipos físicamente separados van a necesitar comunicarse diariamente, comunicar su avance a los stakeholders, poder planificar y colaborar entre ellos, y registrar decisiones que realicen.

Como requerimientos técnicos generales se pueden mencionar la necesidad de automatizar las prueba, integración continua y repositorios de código.

===Costos y Presupuesto===
Cuando sea necesario calcular el costo del proyecto, puede servir acotar el problema y calcular el costo de cada iteración. De hecho, con este dato se puede incluso calcular el costo por cada punto de historia, y el costo por "hacer nada".

En todo caso, conviene evitar la documentación innecesaria: quizás sea posible arreglar el envio de una foto por email del Burndown chart como muestra del avance.

==10 consejos para integrar Ágil y Cascada==
# '''Establecer un ritmo de Inspección y Adaptacion''': Llevar adelante todas las reuniones de [[Revision Del Sprint]] y [[Retrospectiva Del Sprint]], haciendo incapié en aplicar las lecciones aprendidas de experiencias pasadas.
# '''Encontrar un ejecutivo involucrado''': Es siempre deseable contar con un sponsor interesado en la aplicación del proceos ágil.
# '''Socializar, no evangelizar''': Tener buenas relaciones, hablar con todas las personas posibles de la empresa, y explicar los beneficios es mucho más efectivo que transformarse en un evangelizador.
# '''Usar el poder del Backlog''': Agregar problemas de la organización al backlog, para hacerlos evidentes pero también mostrar que se resuelven. Recordar que las tareas del Backlog no tienen que ser exclusivas del producto.
# '''Tirarse a la pileta''': Lo más dificil es comenzar: no hay que esperar al "momento perfecto", simplemente lanzarse y empezar.
# '''Usar el principio de "lo mínimo requerido"''': Ser eficientes y efectivos; no hacer tareas "demás". Recordar preguntarse siempre: ¿qué es lo mínimo que sirve para satisfacer el requerimiento?
# '''Invitar a todos los no-agiles a las reuniones de planificación''': Compatir la reunión de planificación con personas no-ágiles, para que vayan viendo el proceso.
# '''Enviar el feedback "hacia arriba"''': Ir informando el avance y el desarrollo del proyecto ágil "hacia arriba" en la jerarquia de la organización.
# '''Prestar atención al comportamiento''': En momentos de crisis se suele volver a "la forma anterior". Prestar atención si, ante problemas, se tiende a volver a la forma anterior de resolver las situaciones, y corregir.
# '''Invitar a todo el mundo a las Retrospectivas''': En estas reuniones el equipo y todos los interesados pueden opinar sobre cómo mejorar el proceso. Esto es importante ya que no sólo se mejora el proceso del propio equipo, sino su implementación en toda la organización.

==Ver también==
* [[Desarrollo Agil De Software]]
* [[Scrum]]

==Más información==
* [http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger Agile in the Waterfall Enterprise by Michele Sliger (video)]

Metodologia Agil En Una Organizacion En Cascada

2008-07-26T17:38:57Z

190.172.86.173: Página nueva: Es posible aplicar una metodologia ágil dentro de una organizacion que utiliza Cascada como proceso. Ambos mundos pueden coexistir: es necesario crear un "puente" entre ambos. De hec...

Es posible aplicar una metodologia ágil dentro de una organizacion que utiliza Cascada como proceso. Ambos mundos pueden coexistir: es necesario crear un "puente" entre ambos. De hecho, esta es una situación común, y este "puente" suele ser el primer paso para una transformación más profunda.

Es posible entonces, por ejemplo, llevar un proceso ágil de desarrollo por más que los extremos no lo sean. Sin embargo, hay que tener en cuenta algunos obstáculos que puedan ocurrir en el camino, y cómo sortearlos.

==Obstáculos==
===Resistencia===
La resistencia al cambio es normal, y no será una excepción al intentar aplicar una nueva metodología. Es importante que la actitud a tomar deberá ser la de "vender" la metodología ágil, y no transformarse en un actor defensor de la misma (por sentirnos atacados).

====Resistencia del Management====
Lo más más recomendable es no intentar venderle el cambio: de todas formas, no saben lo que se está haciendo ahora tampoco.

Por otro lado, es importante comunicarse en su mundo e idioma: explicar los beneficios de una metodología ágil, el incremento del ROI, entregas más tempranas, mayor calidad, reducción de costos, etc. Evitar términos como Scrum, Sprint, Backlog, XP, etc, que no aportan al objetivo final.

Por último, es bueno recopilar historias de éxito para compartir con el management: esto les puede transmitir experiencias reales, y brindarles más seguridad sobre el cambio que se está llevando adelante.

====Resistencia del negocio====
Es importante involucrar al [[Dueño Del Producto]] y demás participantes desde el principio: tienen que sentirse parte del proceso, y comprender el mismo.

Sirve mucho destacar el bajo riesgo: "Satisfacción garantizada, o le devolvemos el dinero". Es decir, explicar que el Dueño del Producto puede realizar cambios frecuentes (cada 1 Sprint!), revisando qué cosas no le gustó del proceso y ver cómo cambiarlas. Más aún, puede cancelar el proyecto temprananmente si consigue la funcionalidad requerida, o el proyecto deja de tener sentido para el negocio.

Por último, una buena práctica es comenzar a adoptar herramientas y prácticas ágiles al proceso de desarrollo, por más que la metodología todavía no se implemente. Técnicas como [[Integracion Continua]], [[Automatizacion De Pruebas Unitarias]], programación de pares, etc, pueden ir "preparando el terreno" entre las personas.

====Resistencia del Equipo====
No hacerse problema por los integrantes escépticos: de hecho, es su trabajo diario el cuestionar y revisar. Es necesario responder y aclarar todas sus inquietudes, con sinceridad. Si no se sabe una respuesta, o plantean una situación que no se había previsto, integrarlos para hallar juntos una solución.

Es bueno también que el Equipo cuente con un "guía" (un Coach ágil), el cual los pueda asistir y guiar en el proceso de implementar un proceso ágil de desarrollo.

===Administración de recursos===
Muchas veces las empresas necesitan asignar personal por adelantado. Puede ayudar en estos casos presentar un Release Plan, para poder ir calculando qué personas serán necesarias en distintas fechas.

No es un requesito obligatorio que todos los integrantes del equipo se encuentren físicamente ubicados en el mismo lugar (si bien es una condición deseable). En el caso de que los equipos no pueden co-habitar el mismo espacio, será necesario contar con herramientas que faciliten su interacción.

===Vendors y Contrataciones===
Los Vendors proveen al equipo con algún servicio o producto necesario para el proyecto. Si la relación con el Vendor es a corto plazo, no vale la pena intentar explicarles el proceso ágil: simplemente tomar su resultado y seguir avanzando. Por otro lado, en el caso de relaciones a largo plazo (por ejemplo, integrantes tercerizados del equipo) será necesario realizar una capacitación y explicar el proceso de desarrollo ágil.

Cuando el proyecto sea para un cliente que no es ágil, será importante explicarles el proceso, haciendo incapié en los beneficios que se dará. Remarcar que pueden cancelar el proyecto cuando lo deseen, de manera de brindarles seguridad.

===Facilidades y Herramientas===
Todos los equipos y lugares de trabajo son diferentes, por lo que las soluciones van a variar de acuerdo al lugar. Involucrar siempre al equipo para encontrar soluciones al acondicionamiento del lugar: cómo ubicarse, dónde reunirse, qué salas usar, dónde pegar los gráficos, etc.

Es importante destacar que los equipos físicamente separados van a necesitar comunicarse diariamente, comunicar su avance a los stakeholders, poder planificar y colaborar entre ellos, y registrar decisiones que realicen.

Como requerimientos técnicos generales se pueden mencionar la necesidad de automatizar las prueba, integración continua y repositorios de código.

===Costos y Presupuesto===
Cuando sea necesario calcular el costo del proyecto, puede servir acotar el problema y calcular el costo de cada iteración. De hecho, con este dato se puede incluso calcular el costo por cada punto de historia, y el costo por "hacer nada".

En todo caso, conviene evitar la documentación innecesaria: quizás sea posible arreglar el envio de una foto por email del Burndown chart como muestra del avance.

==10 consejos para integrar Ágil y Cascada==
# __Establecer un ritmo de Inspección y Adaptacion__: Llevar adelante todas las reuniones de RevisionDelSprint y RetrospectivaDelSprint, haciendo incapié en aplicar las lecciones aprendidas de experiencias pasadas.
# __Encontrar un ejecutivo involucrado__: Es siempre deseable contar con un sponsor interesado en la aplicación del proceos ágil.
# __Socializar, no evangelizar__: Tener buenas relaciones, hablar con todas las personas posibles de la empresa, y explicar los beneficios es mucho más efectivo que transformarse en un evangelizador.
# __Usar el poder del Backlog__: Agregar problemas de la organización al backlog, para hacerlos evidentes pero también mostrar que se resuelven. Recordar que las tareas del Backlog no tienen que ser exclusivas del producto.
# __Tirarse a la pileta__: Lo más dificil es comenzar: no hay que esperar al "momento perfecto", simplemente lanzarse y empezar.
# __Usar el principio de "lo mínimo requerido"__: Ser eficientes y efectivos; no hacer tareas "demás". Recordar preguntarse siempre: ¿qué es lo mínimo que sirve para satisfacer el requerimiento?
# __Invitar a todos los no-agiles a las reuniones de planificación__: Compatir la reunión de planificación con personas no-ágiles, para que vayan viendo el proceso.
# __Enviar el feedback "hacia arriba"__: Ir informando el avance y el desarrollo del proyecto ágil "hacia arriba" en la jerarquia de la organización.
# __Prestar atención al comportamiento__: En momentos de crisis se suele volver a "la forma anterior". Prestar atención si, ante problemas, se tiende a volver a la forma anterior de resolver las situaciones, y corregir.
# __Invitar a todo el mundo a las Retrospectivas__: En estas reuniones el equipo y todos los interesados pueden opinar sobre cómo mejorar el proceso. Esto es importante ya que no sólo se mejora el proceso del propio equipo, sino su implementación en toda la organización.

==Ver también==
* [[Desarrollo Agil De Software]]
* [[Scrum]]

==Más información==
* [http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger Agile in the Waterfall Enterprise by Michele Sliger (video)]

Sinceridad Como Valor Agil

2008-07-26T17:34:42Z

190.172.86.173: Página nueva: La '''sinceridad''' es un principio fundamental detrás del éxito de un Desarrollo Agil De Software. Los métodos ágiles se basan en que las personas dicen la verdad y atúan c...

La '''sinceridad''' es un principio fundamental detrás del éxito de un [[Desarrollo Agil De Software]].

Los métodos ágiles se basan en que las personas dicen la verdad y atúan con integridad. Es importante no perder esto de vista, ya que en el día-a-día se suele hacer más foco en los aspectos técnicos (como [[Test Driven Development]], refactoring), o en temas relacionados con el liderazgo del equipo.

Por ejemplo, es común que durante el desarrollo de una aplicación alguien piense haber creado un buen diseño, pero luego tenga que luchar para hacerlo funcionar. En estos casos, puede ser que el desarrollador no quiera mostrar que cometió un error. De ser así, podría hacerle creer al resto del equipo que "todo está bien", mientras trabaja horas extra para arreglar la situación.

El orgullo suele ser un mal consejero para cubrir decisiones técnicas incorrectas.

En cambio, un entorno ágil no es fértil para estas acciones: simplemente no se puede sostener en el tiempo. Recordemos que en un desarrollo ágil existe propiedad colectiva de código, reuniones diarias, seguimiento de historias y tareas, y seguimiento general del esfuezo restante. Todo esto hace que el proceso entero sea más transparente. Obviamente, y por todo esto, los métodos ágiles se basan en que las personas cuenten y actúen con sinceridad.

Igualmente, ningún equipo ágil es inmune a estos problemas. Es bueno que cada miembro del equipo se pregunte:
* ¿estás expresando sinceramente tus dudas e inquietudes en la [[Retrospectiva Del Sprint]]?
* Si algo te molesta de algún otro miembro, ¿tratás el tema de manera directa y con respeto para solucionarlo?
* ¿Estás dispuesto a admitir abiertamente cuando alguien tiene una mejor idea o diseño que el tuyo?
* ¿Estás dispuesto a admitir que cometiste un error?
* ¿Decís lo mismo de una persona cuando estás frente a ella, y cuando esa persona no está?

En resumen, la Sinceridad es un valor fundamental para el buen funcionamiento de un Equipo Ágil. En general, todos los Valores son cada vez más importantes en las metodologías ágiles: sin valores, las prácticas individuales de TDD, iteraciones, Definición de Terminado y otras pierden todo su sentido.

==Ver también==
* [[Desarrollo Agil De Software]]
* [[Scrum]]

==Más información==
* [http://www.infoq.com/news/2008/07/truthfulness-agile-value Truthfulness - an Agile value?]

Agil

2008-07-26T17:32:30Z

190.172.86.173: /* Prácticas ágiles */

El Desarrollo ágil de Software a un paradigma de las [[Metodologias De Desarrollo]] basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

El proceso ágil usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incoporando los cambios continuamente.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo.

El software desarrollado en una unidad de tiempo es llamado una '''iteración''', la cual debe durar de una a cuatro semanas. Cada iteraciones del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos Agiles enfatizan las comunicaciones cara a cara a través de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta. La oficina debe incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y directores de proyecto.

==Principios ágiles==
Los principios fundamentales de una metodología ágil se pueden resumir:
* Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
* Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
* Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
* Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
* Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
* La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
* El software que funciona es la principal medida del progreso.
* Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
* La atención continua a la excelencia técnica enaltece la agilidad.
* La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
* Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
* En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

==Características de un desarrollo ágil==

* Proceso iterativo e incremental
* Mitigación del riesgo mediante iteraciones fijas
* Mejora continua
* Calidad desde el primer día
* Priorización de requerimientos de acuerdo a su valor
* Equipos dedicados y auto-gestionados
* Colaboración continua con el cliente
* Incorporar al cambio
* Prácticas de desarrollo modernas

==Metodologías ágiles==
* [[Scrum]]
* [[Extreme Programming]]

====Prácticas ágiles====
* [[Test Driven Development]]
* [[Sinceridad Como Valor Agil]]

==Ver también==
* [[Metodologia Agil En Una Organizacion En Cascada]]

==Más información==
* [http://es.wikipedia.org/wiki/Proceso_%C3%A1gil Desarrollo ágil de software en la Wikipedia]
* [http://www.navegapolis.net/content/view/801/62/ Listado de metodologías ágiles]

Agil

2008-07-26T17:31:44Z

190.172.86.173:

El Desarrollo ágil de Software a un paradigma de las [[Metodologias De Desarrollo]] basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

El proceso ágil usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incoporando los cambios continuamente.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo.

El software desarrollado en una unidad de tiempo es llamado una '''iteración''', la cual debe durar de una a cuatro semanas. Cada iteraciones del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos Agiles enfatizan las comunicaciones cara a cara a través de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta. La oficina debe incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y directores de proyecto.

==Principios ágiles==
Los principios fundamentales de una metodología ágil se pueden resumir:
* Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
* Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
* Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
* Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
* Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
* La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
* El software que funciona es la principal medida del progreso.
* Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
* La atención continua a la excelencia técnica enaltece la agilidad.
* La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
* Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
* En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

==Características de un desarrollo ágil==

* Proceso iterativo e incremental
* Mitigación del riesgo mediante iteraciones fijas
* Mejora continua
* Calidad desde el primer día
* Priorización de requerimientos de acuerdo a su valor
* Equipos dedicados y auto-gestionados
* Colaboración continua con el cliente
* Incorporar al cambio
* Prácticas de desarrollo modernas

==Metodologías ágiles==
* [[Scrum]]
* [[Extreme Programming]]

====Prácticas ágiles====
* [[TestDriven Development]]
* [[Sinceridad Como Valor Agil]]

==Ver también==
* [[Metodologia Agil En Una Organizacion En Cascada]]

==Más información==
* [http://es.wikipedia.org/wiki/Proceso_%C3%A1gil Desarrollo ágil de software en la Wikipedia]
* [http://www.navegapolis.net/content/view/801/62/ Listado de metodologías ágiles]

Extreme Programming

2008-07-26T17:31:01Z

190.172.86.173: /* Características */

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software. Es la más destacada de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

==Características==
Las características fundamentales del método son:
* '''Desarrollo iterativo e incremental''': pequeñas mejoras, unas tras otras.
* '''Pruebas unitarias continuas''', frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación ([[Test Driven Development]]). Se pueden utilizar herramientas para PruebaUnitaria como [JUnit].
* '''Programación en parejas''': se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
* Frecuente '''integración del equipo de programación con el cliente o usuario'''. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
* '''Corrección de todos los errores''' antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
* '''Refactorización del código''', es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
* '''Propiedad del código compartida''': en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
* '''Simplicidad en el código''': es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

==Ver también==
* [[Metodologias De Desarrollo]]
* [[Test Driven Development]]
* [[Integracion Continua]]

==Más información==
* [http://www.extremeprogramming.org Web oficial de XP]
* [http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema XP en la Wikipedia]
* [http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Scrum and XP from the trenches (libro gratuito en inglés)]

Extreme Programming

2008-07-26T17:30:29Z

190.172.86.173:

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software. Es la más destacada de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

==Características==
Las características fundamentales del método son:
* '''Desarrollo iterativo e incremental''': pequeñas mejoras, unas tras otras.
* '''Pruebas unitarias continuas''', frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación (TestDrivenDevelopment). Se pueden utilizar herramientas para PruebaUnitaria como [JUnit].
* '''Programación en parejas''': se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
* Frecuente '''integración del equipo de programación con el cliente o usuario'''. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
* '''Corrección de todos los errores''' antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
* '''Refactorización del código''', es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
* '''Propiedad del código compartida''': en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
* '''Simplicidad en el código''': es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

==Ver también==
* [[Metodologias De Desarrollo]]
* [[Test Driven Development]]
* [[Integracion Continua]]

==Más información==
* [http://www.extremeprogramming.org Web oficial de XP]
* [http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema XP en la Wikipedia]
* [http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Scrum and XP from the trenches (libro gratuito en inglés)]

Extreme Programming

2008-07-26T17:27:08Z

190.172.86.173: Página nueva: La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software. Es la más destacada de los procesos ágiles de desarrollo de software. Al igual que ...

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software. Es la más destacada de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

==Características==
Las características fundamentales del método son:
* __Desarrollo iterativo e incremental__: pequeñas mejoras, unas tras otras.
* __Pruebas unitarias continuas__, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación (TestDrivenDevelopment). Se pueden utilizar herramientas para PruebaUnitaria como [JUnit].
* __Programación en parejas__: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
* Frecuente __integración del equipo de programación con el cliente o usuario__. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
* __Corrección de todos los errores__ antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
* __Refactorización del código__, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
* __Propiedad del código compartida__: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
* __Simplicidad en el código__: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

==Ver también==
* [[Metodologias De Desarrollo]]
* [[Test Driven Development]]
* [[Integracion Continua]]

==Más información==
* [http://www.extremeprogramming.org Web oficial de XP]
* [http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema XP en la Wikipedia]
* [http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Scrum and XP from the trenches (libro gratuito en inglés)]

Agil

2008-07-26T17:24:56Z

190.172.86.173: /* Metodologías ágiles */

El Desarrollo ágil de Software a un paradigma de las [[Metodologias De Desarrollo]] basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

El proceso ágil usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incoporando los cambios continuamente.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo.

El software desarrollado en una unidad de tiempo es llamado una __iteración__, la cual debe durar de una a cuatro semanas. Cada iteraciones del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos Agiles enfatizan las comunicaciones cara a cara a través de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta. La oficina debe incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y directores de proyecto.

==Principios ágiles==
Los principios fundamentales de una metodología ágil se pueden resumir:
* Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
* Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
* Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
* Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
* Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
* La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
* El software que funciona es la principal medida del progreso.
* Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
* La atención continua a la excelencia técnica enaltece la agilidad.
* La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
* Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
* En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

==Características de un desarrollo ágil==

* Proceso iterativo e incremental
* Mitigación del riesgo mediante iteraciones fijas
* Mejora continua
* Calidad desde el primer día
* Priorización de requerimientos de acuerdo a su valor
* Equipos dedicados y auto-gestionados
* Colaboración continua con el cliente
* Incorporar al cambio
* Prácticas de desarrollo modernas

==Metodologías ágiles==
* [[Scrum]]
* [[Extreme Programming]]

====Prácticas ágiles====
* [[TestDriven Development]]
* [[Sinceridad Como Valor Agil]]

==Ver también==
* [[Metodologia Agil En Una Organizacion En Cascada]]

==Más información==
* [http://es.wikipedia.org/wiki/Proceso_%C3%A1gil Desarrollo ágil de software en la Wikipedia]
* [http://www.navegapolis.net/content/view/801/62/ Listado de metodologías ágiles]

Agil

2008-07-26T17:24:24Z

190.172.86.173: Página nueva: El Desarrollo ágil de Software a un paradigma de las Metodologias De Desarrollo basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriorment...

El Desarrollo ágil de Software a un paradigma de las [[Metodologias De Desarrollo]] basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

El proceso ágil usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incoporando los cambios continuamente.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo.

El software desarrollado en una unidad de tiempo es llamado una __iteración__, la cual debe durar de una a cuatro semanas. Cada iteraciones del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos Agiles enfatizan las comunicaciones cara a cara a través de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta. La oficina debe incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y directores de proyecto.

==Principios ágiles==
Los principios fundamentales de una metodología ágil se pueden resumir:
* Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
* Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
* Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
* Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
* Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
* La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
* El software que funciona es la principal medida del progreso.
* Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
* La atención continua a la excelencia técnica enaltece la agilidad.
* La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
* Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
* En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

==Características de un desarrollo ágil==

* Proceso iterativo e incremental
* Mitigación del riesgo mediante iteraciones fijas
* Mejora continua
* Calidad desde el primer día
* Priorización de requerimientos de acuerdo a su valor
* Equipos dedicados y auto-gestionados
* Colaboración continua con el cliente
* Incorporar al cambio
* Prácticas de desarrollo modernas

==Metodologías ágiles==
* [[Scrum]]
* [[ExtremeProgramming]]

====Prácticas ágiles====
* [[TestDrivenDevelopment]]
* [[SinceridadComoValorAgil]]

==Ver también==
* [[Metodologia Agil En Una Organizacion En Cascada]]

==Más información==
* [http://es.wikipedia.org/wiki/Proceso_%C3%A1gil Desarrollo ágil de software en la Wikipedia]
* [http://www.navegapolis.net/content/view/801/62/ Listado de metodologías ágiles]

Metodologias De Desarrollo

2008-07-26T17:17:29Z

190.172.86.173: Página nueva: El desarrollo de software es un proceso que involucra a personas y tecnología para la creación de sistemas informáticos. Las empresas que se destacan en el negocio del software so...

El desarrollo de software es un proceso que involucra a personas y tecnología para la creación de sistemas informáticos.

Las empresas que se destacan en el negocio del software son aquellas que poseen un proceso de creación e innovación de productos ágil y eficaz. El proceso de desarrollo de productos es el mas crítico para la continuidad del éxito, prosperidad y continuidad de las organizaciones.

==Metodologías==
Actualmente se puede realizar una distinción entre dos grandes grupos de metodologías para el desarrollo de software:
* [[Desarrollo Agil De Software]]
* [[Desarrollo Tradicional De Software]] (buscarle mejor nombre?)

==Más información==
* [http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software Desarrollo ágil de software en la wikipedia]

Base De Datos

2008-07-26T17:14:39Z

190.172.86.173:

Explicar el concepto de bases de datos.

==Ver también==
* [[Oracle]]
* [[SqlServer]]

JTDS

2008-07-26T17:14:15Z

190.172.86.173: Página nueva: El proyecto jTDS provee un driver JDBC 3.0 tipo 4 de Software Libre para Microsoft SQL Server (6.5, 7, 2000 y 2005) y Sybase (10, 11, 12, 15). Este driver resulta ser el ...

El proyecto jTDS provee un driver [[JDBC]] 3.0 tipo 4 de [[Software Libre]] para Microsoft SQL Server (6.5, 7, 2000 y 2005) y [[Sybase]] (10, 11, 12, 15).

Este driver resulta ser el más utilizado SQL Server en Java, e incluso varios drivers comerciales están basados en jTDS. Su utilización no requiere de ninguna configuración particular, más que agregar el driver al classpath de la aplicación.

==Ver también==
* [[SqlServer]]

==Más información==
* [http://jtds.sourceforge.net/ Web oficial de jTDS]

SqlServer

2008-07-26T17:12:48Z

190.172.86.173: Página nueva: Microsoft SQL Server es un sistema de gestión de bases de datos relacionales basado en el lenguaje Transact-SQL, y específicamente en Sybase IQ, capaz de poner a disposición de muc...

Microsoft SQL Server es un sistema de gestión de bases de datos relacionales basado en el lenguaje Transact-SQL, y específicamente en Sybase IQ, capaz de poner a disposición de muchos usuarios grandes cantidades de datos de manera simultánea.

Microsoft SQL Server constituye la alternativa de Microsoft a otros potentes sistemas gestores de bases de datos como [[Oracle]].

==Drivers JDBC==
El proyecto [[JTDS]] provee un driver de [[Software Libre]] para SQL Server.

==Ver también==
* [[JTDS]]

==Más información==
* [http://es.wikipedia.org/wiki/Microsoft_SQL_Server SQL Server en la Wikipedia]

Oracle

2008-07-26T17:10:57Z

190.172.86.173:

Oracle es una base de datos relacional comercial.

==Ver también==
* [[Concepto De Rownum]]
* [[Transacciones Autonomas En Oracle]]
* [[Bulk Collect]]
* [[Tablas Externas]]
* [[Primary Key En Tablas Particionadas]]
* [[Oracle Flashback Technology]]

==Más información==
* [http://www.oracle.com Web oficial de Oracle]

QJ-Pro

2008-07-26T16:47:22Z

190.172.86.173:

QJ-Pro is a comprehensive software inspection tool targeted towards the software developer. Read the PDF brochure and concepts for an understanding of what the product does.

Developers can automatically inspect their Java source code and improve their Java programming skills as they write their programs. QJ-Pro provides descriptive Java patterns explaining error prone code constructs and providing solutions for it.

QJ-Pro checks:

* conformance to coding standards,
* misuse of the Java language,
* best practice conformence
* code structure and
* potential bugs at the earliest stages of development.

QJ-Pro default supports over 200 rules some of which can be used to instantiate new customized rules.

==Mas información==
[http://qjpro.sourceforge.net/ Web oficial de QJ-Pro]

QJ-Pro

2008-07-26T16:47:00Z

190.172.86.173:

QJ-Pro

2008-07-26T16:46:21Z

190.172.86.173: Página nueva: QJ-Pro is a comprehensive software inspection tool targeted towards the software developer. Read the PDF brochure and concepts for an understanding of what the product does. Develop...

Performance De Aplicaciones

2008-07-26T16:16:03Z

190.172.86.173: Página nueva: La performance en las aplicaciones es más que importante: no sólo puede mejorar (o perjudicar) la experiencia de un usuario, sino que puede hacer inviable (o inutilizable) a todo un...

La performance en las aplicaciones es más que importante: no sólo puede mejorar (o perjudicar) la experiencia de un usuario, sino que puede hacer inviable (o inutilizable) a todo un desarrollo.

Medir la performance y realizar un análisis de los datos obtenidos no es una tarea trivial.

==Consejos==
===Saber qué esperar de nuestra aplicación===

¿Cómo saber si nuestra aplicación funciona en tiempos aceptables, si los mismos no están definidos? Antes de realizar cualquier análisis de performance, es fundamental tener en claro qué esperar de estos resultados: debemos saber los tiempos esperados para cada una de las operaciones de nuestra aplicación.

El requerimiento debería tener ya indicados los tiempos aceptables para las funciones que tenga nuestro proyecto; si no los tiene, debemos exigirlos antes de avanzar! Hablando de lo cual...

===Encarar la performance desde el principio del proyecto===

Claro, a menos que luego querramos prender fuego todo. La performance requerida puede afectar a la solución planteada. Una solución viable con ciertos tiempos (y volúmenes) puede dejar de serlo con otro entorno. Y hablando de esto...

===Probar performance en entorno de desarrollo no es indicativo de nada===

¿Nuestra aplicación vuela en el entorno de desarrollo? ¿Y estamos contentos? No nos apuremos. El entorno de desarrollo no es en abosluto comparable al entorno productivo. El test final de performance debe realizarse contra un entorno productivo (o lo más parecido posible... y no, los "release" no sirven para esto).

===Mover un gran volumen de datos es invitar al desastre===

Si nuestro super-servicio necesita devolver (o procesar) miles y miles de registros, es una invitación perfecta a que ocurra algún problema. Desde insuficiente memoria hasta quilombos de performance, todo es posible.

Es siempre necesario analizar estos casos detenidamente, viendo la real necesidad de esta suerte de "migración" de datos a través del supuesto servicio.

Y por cierto, paginar millones de resultados tampoco es la solución mágica. Pero de serlo, no olvidar que...

===Paginar por algún índice cuando sea posible===

La paginación que provee Hibernate pagina utilizando el campo rownum de la base de datos. Sin embargo, en algunas consultas, esto puede ser sumamente ineficiente (llevando a que la demora aumente a medida que se piden páginas más alejadas).

Una buena solución es paginar por algún campo que sea índice de la tabla. Por ejemplo, es posible paginar los clientes por su código (id_cliente). Es decir, podría quedar:

Página 0: id_cliente 0 al 1000
Página 1: id_cliente 1001 al 2000
Página 2: id_cliente 2001 al 3000

Evidentemente, si existen "agujeros" en la columna "id_cliente" las páginas tendrán un tamaño variable, y podrán existir páginas sin datos. Sin embargo, la mejora en performance puede ser más que interesante.

==Ver también==
* [[Prueba De Carga]]

Prueba De Carga

2008-07-26T16:14:24Z

190.172.86.173: Página nueva: La prueba de carga implica estresar una aplicación de forma que se pueda medir cómo responde la misma ante distintos niveles de carga. Por ejemplo, en una Aplicacion Web, se po...

La prueba de carga implica estresar una aplicación de forma que se pueda medir cómo responde la misma ante distintos niveles de carga.

Por ejemplo, en una [[Aplicacion Web]], se podría simular el acceso concurrente de distinta cantidad de usuarios, de forma tal de medir los tiempos de respuesta del sistema.

Las pruebas de carga son una herramienta fundamental para evaluar la [[Performance De Aplicaciones]].

==Ver también==
* [[Herramientas Para Prueba De Carga]]
* [[Performance De Aplicaciones]]

LoadRunner

2008-07-26T16:12:53Z

190.172.86.173: Página nueva: LoadRunner es una herramienta comercial de carga y performance de Hewlett-Packard (desde que adquirió Mercury Interactive, empresa que originalmente desarrolló el producto). LoadRun...

LoadRunner es una herramienta comercial de carga y performance de Hewlett-Packard (desde que adquirió Mercury Interactive, empresa que originalmente desarrolló el producto). LoadRunner permite emular cientos o miles de usuarios concurrentes para simular carga sobre aplicaciones, y a la vez recolectar información clave de la infraestructura de componentes (servidores web, bases de datos, etc.).

==Ver también==
* [[Herramientas Para Prueba De Carga]]

==Más información==
* [https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-126-17%5E8_4000_100__ Web oficial de LoadRunner]
* [http://en.wikipedia.org/wiki/LoadRunner LoadRunner en la Wikipedia]