X FECHAS

x orden alfabetico

ENLACES

+ vistas

varios

VARIOS


Contador Gratis
relojes para blogger html clock for websites contador de usuarios online
PULSAR   1  de arriba para cerrar pestaña

Scrum

Scrum

Ciclos de desarrollo

Scrum es un proceso de desarrollo de software iterativo e incremental utilizado comúnmente en entornos ágiles de desarrollo de software.

Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.

Contenido

 [ocultar]

Historia [editar]

  • En 1986, Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales:1
    • Ellos comparan esta nueva aproximación holística en la cual las fases se solapan de manera intensa y el proceso completo es realizado por un equipo con funciones transversales, como el rugby, donde el equipo entero "actúa como un solo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro".
    • Los casos de estudio se centran en empresas de las industrias automovilísticas, y de fabricación de máquinas fotográficas, computadoras e impresoras.
  • En 1991, DeGrace y Stahl, en Wicked Problems, Righteous Solutions,2 se refirieron a esta aproximación como Scrum (meleé en inglés), un término rugbístico mencionado en el artículo por Takeuchi y Nonaka.
  • A principio de los 90, Ken Schwaber utilizó una aproximación que llevó a poner en práctica Scrum en su compañía, Advanced Development Methods.
  • Por aquel tiempo, Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla Scrum.3
  • En 1995, Sutherland y Schwaber presentan de manera conjunta una ponencia describiendo Scrum en el OOPSLA '95 en Austin, en su primera aparición pública. Schwaber y Sutherland colaboraron durante los años siguientes para consolidar los escritos anteriores, su experiencia, y las mejores prácticas en la industria, en lo que hoy día se conoce como Scrum.
  • En 2001, Schwaber y Mike Beedle escribieron la metodología en el libro Agile Software Development with SCRUM.

Características de Scrum [editar]

Scrum es un proceso marco que incluye un conjunto de prácticas y roles predefinidos. Los roles principales en Scrum son elScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a losstakeholders (clientes externos o internos), y el Team que incluye a los desarrolladores.

Durante cada sprint, un periodo entre 15 y 30 días (la longitud es definida por el equipo), el equipo crea un incremento de softwarepotencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del product backlog, que es un conjunto de requisitos de alto nivel priorizados que dan forma al trabajo a realizar. Los elementos del backlog que forman parte del sprint se determinan durante la reunión de sprint planning. Durante esta reunión, el Product Owner informa al equipo de los elementos en el product backlog que quiere ver completados. El equipo entonces determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.4 Durante el sprint, nadie puede cambiar el sprint backlog, lo que significa que los requisitos están congelados durante el sprint.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Roles en Scrum [editar]

En Scrum se definen varios roles; estos están divididos en dos grupos; cerdos y gallinas, inspirados en un chiste sobre un cerdo y una gallina.4

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice, "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice, "Buena idea, ¿cómo se llamaría el restaurante?" La gallina piensa un poco y contesta, "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría comprometido pero tu solamente estarías involucrada".

De esta forma, los cerdos están comprometidos a construir software de manera regular y frecuente, mientras que el resto son gallinas: interesados en el proyecto pero realmente irrelevantes porque si este falla no son un cerdo, es decir, no son los que se habían comprometido a sacarlo adelante. Las necesidades, deseos, ideas e influencias de los roles gallina se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum.


Roles "Cerdo" [editar]

Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamón en el plato".

Product Owner
El Product Owner representa la voz del cliente. Ellos se aseguran de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como debe. El ScrumMaster es el que hace que las reglas se cumplan.
Equipo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 o 9 personas con una mezcla de las habilidades necesarias para realizar el trabajo (diseñador, desarrollador, etc).


Roles "Gallina" [editar]

Los roles gallina no son parte del proceso real Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximación Ágil es la práctica de involucrar a usuarios, parte de negocio y otros responsables (stakeholders) como parte del proceso. Es importante que esa gente participe y proporcione su opinión sobre las salidas para la revisión y planificación de cada sprint.


Usuarios
¡El software es construido para alguien! Si el software no es usado - como la adivinanza sobre si un árbol que cae en el bosque cuando no hay nadie cerca hace ruido - ¿fue alguna vez escrito?.

Reuniones en Scrum [editar]

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama un scrum o la "daily standup". El scrum tiene unas guías específicas:

  • La reunión comienza puntualmente a su hora. A menudo hay castigos -decididos por el equipo- para quién llega tarde (por ejemplo: dinero, push-ups, llevar colgando una gallina de plástico del cuello)
  • Todos son bienvenidos, pero solo los "cerdos" pueden hablar
  • La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
  • Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
  • La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:4

  • ¿Qué has hecho desde ayer?
  • ¿Qué es lo que estás planeando hacer mañana?
  • ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rapidamente y responder a requisitos emergentes.

Documentos [editar]

Product backlog [editar]

El product backlog es un documento de alto nivel para todo el proyecto. Contiene amplias descripciones de todas las características requeridas, funcionalidades en la wish-list, etcétera. Es el "qué" va a ser construido. Es abierto y editable por todo el mundo. Contienen estimaciones burdas, normalmente en días. Esta estimación ayuda al Product Owner a ajustar la línea temporal y, de manera limitada, la prioridad (por ejemplo, si "añadir corrector ortográfico" está estimada en 3 días vs 3 meses, eso podría afectar el deseo del Product Owner.


Sprint backlog [editar]

El sprint backlog es un documento con gran detalle donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se rompen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.


Burn down [editar]

La burn down chart es una gráfica mostrada públicamente en la que aparecen el número de tareas restantes para el sprint actual, o el número de items en el sprint backlog. No debería ser confundido con una tabla de valor añadido. Una burn down chart podría ser plana durante la mayor parte del periodo cubierto en el sprint, y el proyecto podría seguir sobre lo planificado.



Scrum aplicado al desarrollo de software [editar]

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.

Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.

Ficha sinóptica

La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:

  • Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
  • Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.
  • Reuniones:

Planificación del sprint, Revisión diaria, Revisión del sprint.



  • Sprint


Véase también [editar]

Enlaces externos [editar]

Referencias [editar]

  1. ↑ Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan-Feb 1986)
  2. ↑ Peter DeGrace, Leslie Hulet Stahl, Wicked problems, righteous solutions, 1990, ISBN 0-13-590126-X
  3. ↑ Jeff Sutherland, AGILE DEVELOPMENT: LESSONS LEARNED FROM THE FIRST SCRUM, 2004
  4. ↑ a b c Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X
Leer más...

¿Eres el Problema o la Solución?

¿Eres el Problema o la Solución?

de Optima Infinito de jmbolivar@optimainfinito.com (Jose Miguel Bolivar)

soluciones, cortesía de Rafa Zubiria
Básicamente hay dos tipos de personas: las que buscan problemas y las que encuentran soluciones.

Los buscadores de problemas son el grupo más numeroso, supongo que porque resulta más fácil detectar un problema que solucionarlo.

El grupo de los que encuentran soluciones es, imagino que por la misma razón que acabo de comentar, mucho más reducido y sin duda mucho más apreciado y valorado por todos, tanto en el ámbito personal como en el profesional.

Ser un buscador de problemas es una vocación temprana y me atrevería a decir que casi una tendencia innata.

Ya de críos comenzamos a decir no a las propuestas paternas, casi como un acto reflejo, pero rara vez somos capaces de proponer alternativas concretas.

En otras palabras, decimos fácilmente lo que no nos gusta o lo que no queremos pero nos cuesta expresar con claridad lo que sí nos gusta o lo que sí queremos.

El problema es que si no corregimos estos hábitos tempranos acabaremos convirtiéndonos en buscadores crónicos de problemas, lo cual no sólo es bastante aburrido y limitante para el que lo padece sino que además no nos va a resultar de mucha ayuda ni en lo personal ni en lo profesional, más bien lo contrario.

Lo curioso es que pasar de buscar problemas a encontrar soluciones es un paso relativamente sencillo. Como solemos comentar a menudo en este blog lo único que require es uncambio de paradigma.

Las personas que buscan problemas se caracterizan fundamentalmente por dos aspectos: saben lo que no quieren y observan constantemente la realidad buscando el fallo, lo que no funciona e incluso lo que podría no funcionar.

Quienes encuentran soluciones, por el contrario, saben lo que quieren y operan en un paradigma en el que siempre existe una solución para cada problema.

Esta forma distinta de percibir la realidad hace que la reacción de aquellos que buscan problemas sea por lo general inmediata y poco o nada razonada. Tan pronto detectan algo que no les gusta o que no funciona lo dicen sin más.

Sin embargo los que encuentran soluciones no se paran ante el problema o el error sino que lo utilizan como punto de partida para comenzar la búsqueda de la solución, porque saben, sin dudar, que existe. Y lo mejor de todo es que, como no saben que en ocasiones la solución es imposible, siempre la encuentran.

Más allá de los beneficios que este cambio de paradigma te pueda aportar en tu vida profesional, considera también lo que puedes ganar a nivel personal si en lugar de ver sólo problemas comienzas también a ver oportunidades.

Al final todo se reduce a que te hagas esta pregunta: ¿de qué quiero ser parte, del problema o de la solución?

La decisión es sólo tuya.
Leer más...

Metáfora zen del Bambú Japonés

Metáfora zen del Bambú Japonés

No hay que ser agricultor para saber que una buena cosecha requiere de buena semilla, buen abono y riego constante. También es obvio que quien cultiva la tierra no se impacienta frente a la semilla sembrada, hablándole con el riesgo de echarla a perder, gritándole con todas sus fuerzas: ¡Crece, por favor!

Hay algo muy curioso que sucede con el bambú japonés y que lo transforma en no apto para impacientes: siembras la semilla, la abonas, y te ocupas de regarla constantemente.

Durante los primeros meses no sucede nada apreciable. En realidad, no pasa nada con la semilla durante los primeros siete años, a tal punto que, un cultivador inexperto estaría convencido de haber comprado semillas infértiles.

Sin embargo, durante el séptimo año, en un período de sólo seis semanas la planta de bambú crece ¡más de 30 metros! 
¿Tardó sólo seis semanas crecer? 
No, la verdad es que se tomó siete años y seis semanas en desarrollarse.

Durante los primeros siete años de aparente inactividad, este bambú estaba generando un complejo sistema de raíces que le permitirían sostener el crecimiento, que iba a tener después de siete años.

Sin embargo, en la vida cotidiana, muchas veces queremos encontrar soluciones rápidas y triunfos apresurados, sin entender que el éxito es simplemente resultado del crecimiento interno y que éste requiere tiempo.

De igual manera, es necesario entender que en muchas ocasiones estaremos frente a situaciones en las que creemos que nada está sucediendo.
---------------------

Nota de VRedondof.
Tambien se puede aplicar a la planificacion , habia un "cuento" que decia que los Japoneses dedicaban 7 meses para PLANIFICAR un proyecto y luego 7 dias para su desarrollo , en cambio los Españoles siete dias para PLANIFICAR un proyecto y 7 MESES para desarrollarlo , con los fallos y sus costes añadidos que ello conllevaba. 
Leer más...

las 13 CUALIDADES de un emprendedor.

Emprender

Leo que para ser un emprendedor comme il faut hace falta tener todas estas capacidades:

Motivación

Creatividad

Liderazgo

Iniciativa

Intuición

Adaptabilidad

Energía

Entusiasmo

Compromiso

Determinación

Persistencia

Centrarse en una oportunidad

Asuncion de riesgos calculados

De ser cierto, y personalmente no lo veo nada descabellado, parece lógico el alto índice de fracaso entre las empresas de nueva creación....
Leer más...

GTD o cómo ser altamente productivo

Articulo publicado por 
Andrea 
en Saiku


GTD o cómo ser altamente productivo

Septiembre 17, 2008 –

Llevo varias semanas pensando en publicar un post acerca de GTD, el sistema “Getting things done” de David Allen. En innumerables páginas se habla del mismo con la devoción dedicada a un culto, mientras que otras las tachan de elogios inmerecidos.

En cualquier caso, ¡yo soy de las admiradoras del método!, por lo que os traigo un resumen acerca de este sistema ampliamente extendido para elevar los índices de productividad de cualquier persona que se proponga seguirlo.

Sus bases conceptuales están constituidas por:

  • Especificar acciones y transformarlas en objetivos y “pasos siguientes” concretos y definidos.
  • Organizar recordatorios y notificaciones, así como clasificar las información en base a cómo y cuándo la necesitarás.
  • Mantener constantemente en tu punto de mira los seis horizontes de tus obligaciones (propósito, vision, objetivos, áreas de enfoque, proyectos y acciones)

¿Cuáles deberían de ser tus primeros pasos para iniciarte?

  • Organiza todos los documentos que haya sobre tu escritorio hasta que este vacío y ordenado.
  • Procesa tu correo electrónico y bandeja de entrada hasta vaciarla.
  • Realiza un brainstorming de tareas e ideas en un cuaderno o dispositivo móvil.
  • Establece un sistema clasificatorio sencillo.
  • Crea listas conceptuales de todas tus acciones, así como una lista de proyectos, una lista de “en espera” y otra de “Algún día/quizás”
  • Utiliza un calendario o un sistema de archivos para recordar futuras tareas o compromisos que han de realizarse “imprescindiblemente” ese día.
  • Haz una revisión semanal para mantener el método en orden y redefinir tus prioridades.

Es posible que en este preciso instante, tras la avalancha de tareas pendiente que probablemente hayas descubierto decidas dejar este artículo, pero ¡espera!, te contaré algo: No tienes por qué implementar todo el sistema GTD de la noche a la mañana para incrementar notablemente tu productividad.

De hecho, la idea principal es adaptar aquellas partes del mismo que puedan optimizar tu rutina de trabajo.

Algunos de los pasos esenciales para apreciar una mejora en tu rendimiento serían:

  • Comienza especificando en una hoja de papel absolutamente todo aquello relacionado con tareas o compromisos pendientes. Si quieres ir un poco más lejos, puedes realizar listas contextuales (“siguientes acciones” clasificadas, por ejemplo, por contextos en los que serán realizadas: trabajo, casa, etc.. de modo que sepas exactamente qué es lo más urgente que deberías hacer en estos momentos)
  • Limpia tu escritorio/bandeja de entrada. El siguiente paso sería procesar todos los papeles, juntándolos en primer lugar en una única pila y clasificándolos uno a uno a medida que vas avanzando.
  • Clasifica. Sin duda esta es la parte más tediosa, pero con un sencillo sistema de archivadores (en caso de papel corriente) o un sistema de carpetas en tu ordenador tu productividad y rapidez trabajando con tus documentos aumentará considerablemente.

Recuerda que un primer acercamiento al método debería incluir un cuaderno, lápiz o bolígrafo, un archivador con clasificadores y etiquetas. De cualquier modo, existen múltiples programas y utilidades que podrás emplear tales como:

  • dispositivos móviles (PDA)
  • etiquetador electrónico
  • calendario
  • software informático (para listas de tareas, brainstorming, mindmapping, etc)

Este diagrama muestra de forma absolutamente clarificadora la estrategia que deberemos seguir al poner en práctica GTD:
gtd

Por último, un par de observaciones al respecto:

Un aspecto clave en el sistema GTD es la definición de un concepto clave: el de “siguiente acción”, de esta forma elaboraremos un método dirigido para la realización  de cualquier proyecto. Un proyecto no es una “siguiente acción”, por tanto, sino que para la realización de un proyecto llevaremos a cabo múltiples acciones estando éstas ordenadas temporalmente en función de su dificultad y urgencia, entre otros muchos factores.

Aquellos compromisos o tareas fundamentales en un día determinado deberían desplazarse directamente al calendario, mientras que aquellas que una vez definidas ocupen un espacio temporal de más de dos minutos deberán ser postergadas o delegadas.

Si buscas software específico para GTD, en las páginas siguientes encontrarás una relación de diferentes programas:
Leer más...