Make Text BiggerMake Text SmallerReset Text Size

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

Ir a navegapolis.com

¿Es suficiente un tablero kanban?
Blog - Agilidad
06.04.2011

tablero kanban A un equipo ágil le basta con un tablero kanban, pero a menudo se usa junto con alguna herramienta de seguimiento de tareas  por alguna de estas razones: Para elaborar informes, porque no trabaja todo el equipo en el mismo sitio, porque no trabajan en un entorno ágil, por razones administrativas o de documentación, por colaboración con otros equipos (scrum de scrums).

Esta es al menos la conclusión de la tesis de grado presentada el mes pasado por Mascha Kurpicz en la Universidad de Berna: Tool Support for Scrum en la que compara la utilidad y funcionalidaes entre herramientas de seguimiento de tareas y  tableros visuales)

 

Comparación entre Tableros Kanban y Herramientas de gestión

Issue Tracker vs Kanban Board

 


Issue Tracker vs. Kanban Board
 
 
 


Al final de la tesis Mascha Kurpickz propone un prototipo para sincronizar la imagen de un tablero kanban con una hoja de cálculo: Scrum Detector.

 
Scrumbrl: Tablero Kanban virtual en tiempo real
Herramientas -
25.03.2011

scrumbrlScrumbrl es una herramienta muy simple, hecha y liberada por Ali Asaria que puede ser muy útil para trazar y compartir la evolución del trabajo entre personas o equipos distantes. Se puede usar libremente en scrumblr.ca También lo podéis montar en vuestro propio servidor, porque el código es libre y se encuentra aquí . Está desarrollado con Node.js, socket.io y JQuery.

 
 

 
 
Excipientes y principios activos de la agilidad
Blog - Agilidad
16.03.2011

medicinasExcipientes de la agilidad

Tableros kanban, etiquetas adhesivas, reuniones de pie, gráficos burndown, estimación de póker, product backlog, sprint backlog, gráficos burnup, formatos de historias de usuario, etc.

Principios activos

  • Visión: El proyecto tiene un objetivo definido, conocido y asumido por todos los miembros.
  • Priorización: El criterio de prioridad del cliente define en cada momento los trabajos inmediatos para avanzar hacia el objetivo.
  • Visibilidad: No hay información oculta y en las decisiones se tienen en cuenta las consideraciones y aportaciones del todo el equipo.
  • Competencia: Todos los miembros tienen la competencia profesional necesaria para aportar un trabajo valioso.
  • Respeto: Todos los miembros dan y reciben respeto y valoración.
  • Compromiso: Las personas no anteponen sus intereses propios a los del equipo.
  • Confianza: Todo el equipo tiene confianza real en el desempeño, valor y compromiso de los demás.
  • Coraje: Todos los miembros y el equipo en su conjunto hace frente con decisión y solvencia a las situaciones adversas.
  • Responsabilidad: Cada persona tiene el margen de acutación y decisión necesario para su aportación al proyecto y es responsable de sus decisiones, acciones y omisiones.
  • Ritmo: El desarrollo se realiza con una cadencia de avance objetivo continuo y sostenible.
  • Retroalimentación: De forma periódica el equipo analiza su forma de trabajo y toma decisiones de mejora.


 
Retos culturales para equipos scrum distribuidos
Blog - Agilidad
07.03.2011

comunicación interculturalHay dos patrones culturales relativos a la comunicación entre individuos: de "bajo contexto" y de "alto contexto". En las culturas de alto contexto los mensajes dependen de variables del entorno  sin las cuales la comunicación pierde información relevante, porque en la cultura que comparten los interlocutores se interpretan de forma común. Por el contrario en las culturas de bajo contexto los mensajes explícitos incluyen la información significativa y objetiva para su correcta interpretación.

"Una comunicación o mensaje de alto contexto es aquel que supone gran parte de la información implícita en la persona, y se necesita muy poca información explícita en el mensaje verbal. Una comunicación de bajo contexto es justo lo contrario (Hall E.T., Beyond Culture 1989)

Culturas de alto contexto son, por ejemplo, la japonesa, china o coreana; mientras que en el extremo opuesto o de bajo contexto estarían la alemana, suiza o escandinava.

La comunicación en las culturas asiáticas es a menudo indirecta e implícita, e interpretan correctamente los mensajes porque comparten el mismo fondo cultural; sin embargo en las culturas occidentales la comunicación tiende a ser más directa y explícita. Las culturas de alto contexto prefieren los estilos indirectos, y pueden interpretar como conflictiva una comunicación muy directa.

Algo parecido sucede con la valoración del tiempo. Hay culturas (monocrónicas) que lo valoran de forma cuantificable y objetiva como si fuera dinero. Otras (policrónicas) lo entienden como un fluir continuo e interminable desde el pasado hacia el futuro. Estas últimas estructuran menos el tiempo y la planificación de las actividades, al revés de lo que suelen considerar correcto las culturas monocrónicas, que prefieren planificaciones y focos de trabajo definidos.

La impuntualidad, las interrupciones, la gestión simultánea de varias tareas, las pausas en las comunicaciones por correo, etc. se consideran de forma diferente en cada cultura.

Estos factores pueden suponer retos a la comunicación de equipos ágiles distribuidos y multiculturales, y como cada vez hay más organizaciones que combinan la operativa ágil, basada en la comunicación directa de las personas, con la deslocalización de equipos, me ha parecido curioso el informe de  Hasit D. Yaggahavita: "Challenges in Applying Scrum Methodology on Culturally Distributed Teams" donde analiza estas variables, desde su experiencia como ingeniero en una software factory en Sri Lanka (Eurocenter)

Retos equipos distribuidos

 

 

 
Los cambios de requisitos son bienvenidos con Scrum, pero ¿a qué precio?
Blog - Agilidad
16.02.2011

comparandoLa gestión de proyectos predictiva afirma que la forma más eficiente de hacer un trabajo es hacerlo bien a la primera. ¿Es más eficiente la gestión de proyectos predictiva que la gesitón de proyectos ágil?.

La ingeniería de software tradicional necesita requisitos detallados y estables.
Para la gestión de requisitos tradicional, (una de las cinco áreas de conocimiento de la ingeniería de requisitos según SWEBOK) cada modificación de requisitos es una "incidencia". Un torpedo contra el éxito del proyecto que requiere un estudio de impacto y medidas de reparación.

Sin embargo , los requisitos genéricos y los cambios durante el desarrollo son las premisas del desarrollo ágil, que afirma cosas como "Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente".

La clave de esta aparente contradicción está en los ciclos de vida empleados por unos y por otros: El desarrollo secuencial o en cascada necesita requisitos detallados y estables, algo que no sucede si se usan modelos iterativos.

requisitos: secuencial vs ágil
Requirements Management in an Agile-Scrum


Pero... todo tiene su precio. La agilidad se adapta al cambio y da más valor a la visión del producto, en cada modificación que va descubriendo mientras lo construye... pero claro, los cambios de requisitos repercuten en la eficiencia del equipo y en la calidad entregada.
 Porque es evidente que "La forma más eficiente de hacer un trabajo es hacerlo bien a la primera".
¿Sí?.
¿Alguien lo ha comprobado, o simplemente se da por supuesto porque parece obvio?.

Esto es lo que se plantearon los profesores de la Universidad de San Marcos en Texas Elizabeth Oyeyipo y Carl Mueller, y para comprobarlo han realizado un estudio con 33 alumnos de Ingeniería de Software, formando 8 equipos de 4 ó 5 programadores y cuyos resultados publica la Universidad en el reciente informe "Requirements Management in an Agile Scrum "

Los 8 equipos construyeron el mismo sistema con el mismo product backlog y trabajando con el mismo propietario de producto: un programa de gestión de agendas.

Siete equipos trabajaron con Scrum, admitiendo al propietario de producto realizar cambios en el backlog de requisitos durante la ejecución del proyecto.
Un equipo se empleó como referencia para contrastar los datos, de forma que usó un ciclo de desarrollo iterativo (4 iteraciones en lugar de los 4 sprints)  pero sin modificar los requisitos, para analizar las diferencias de eficiencia y calidad.
Las métricas empleadas en el estudio han sido 29, agrupadas en 4 categorías: Esfuerzo del equipo, Funcionalidad producida, Impacto de los cambios de requisitos y calidad entregada.


resultados esfuerzo
(El grupo I trabajaba con Scrum y el II no)

El estudio concluye que los grupos trabajando con Scrum permitiendo cambios en el backlog entregaron más calidad, más funcionalidades e invirtieron menos horas que los que trabajaron con iteraciones sin permitir cambios.

 
Scrum: opiniones de los directivos y cambios en sus funciones
Blog - Agilidad
10.02.2011

leaderLa función de los directivos y gestores en una organización con Scrum es un tema muy interesante del que no hay casi ningún estudio. El documento "Virtual Reality Meets Scrum. How a Senior Team Moved from Management to Leadership" analiza los cambios en las funciones de gestión y los comportamientos en el personal de empresa finlandesa de juegos sociales Sulake, que comenzó a trabajar con Scrum en 2006, y lo institucionalizó a los 6 meses.

El estudio se ha realizado en 2009 con las respuestas de 19 directivos y 36 técnicos.

Los mayores desafíos para los gestores en organizaciones con Scrum consiste en dar autonomía al equipo, y no practicar la micro-gestión.

 

Preguntas sobre Scrum

 

 
Conocer metodologías acelera el aprendizaje, pero luego la conformidad lo detiene.
Blog - gestion
27.01.2011

disconformidad1998: "No termino de ver por qué tenemos que trabajar con ISO 9000 en el departamento de programación, pero lo recomiendan todos los expertos en calidad, y lo hacen las mejores empresas. Mejor no desentonar, porque soy novato en dirigir equipos de programación, así que vamos a por lo mejor."

2001: "¿Donde vas con una ISO 9000? Para la industria del software lo mejor y lo último es CMM."

2005: "¿Procesos? Los procesos son del siglo pasado." Tienes que usar Scrum. 2007: "¿Scrum o Kanban?...." ¡Eso que tu haces no es así! ¡El proceso tiene que ser así....!

Wikipedia: Conformidad es el grado hasta el cual los miembros de un grupo social cambiarán su comportamiento, opiniones y actitudes para encajar con las opiniones del grupo.

Mecanismos de conformidad: sugestión, imitación, contagio, simpatía, instinto gregario (Psicología de las relaciones de autoridad y poder . 2006. Editorial UOC.)

Los modelos son útiles para dar los primeros pasos, pero después, adoptar mecanismos de conformidad puede bloquear el desarrollo de un criterio profesional propio.

 

 
Los mejores equipos no siguen metodologías
Blog - Agilidad
16.01.2011

 

Artículo migrado a la nueva versión de Navegápolis.

Nueva dirección en Los mejores equipos no siguen metodologías en navegapolis.com

 

 

 
¿Cómo se debe facturar el software?
Blog - gestion
11.01.2011

que cobrarEs una pregunta más ambigua de lo que parece. ¿Vendemos horas de trabajo o sistemas valiosos?. Preguntar cómo se debe facturar el software, es como preguntar cómo se debe facturar la pintura.

 

 

 talento y factura

 

talento y factura

 
Kunagi: herramienta libre para gestión ágil de proyectos
Herramientas -
08.01.2011

kunagiAñado Kunagi a la lista de herramientas libres para la gestión de proyectos ágiles.

Es una herramienta gratuita sobre interfaz web para gestión ágil de proyectos que además de los artefactos más frecuentes (pila de producto, pila de sprint y pizarra de trabajo con representación kanban y gráfico burndown) incluye también aspectos interesantes como registro de requisitos no funcionales, riesgos, impedimentos, versiones, wiki o foro.

1.- herramientas para gestión y seguimiento ágil:

  • Pizarra de trabajo con gráfico de avance o Burndown.
  • Registo de Sprint: Registro y segimiento a nivel de tareas con indicación del estado y tiempo pendiente de cada una que se pueden ver en formato kanban, en el que se agrupan las tareas por historias de usuario, o en formato pila de sprint. En ambos casos con información de tiempos, impedimentos y comentarios.
  • Producto: Registro y seguimiento a nivel de historias de usuario en formato pila de producto, con información de estimación, comentarios del equipo, historias y temas relacionados. En este área también se pueden registrar requisitos genéricos de calidad que afectan a varias historias, Temas y versiones.
  • Proyecto: Registro y seguimiento de parámetros del proyecto: Impedimentos, Riesgos, Diario del proyecto, fechas e histórico de sprints.

Pantalla Kunagi

 

 

 

 
<< Inicio < Anterior 1 2 3 4 5 6 7 8 9 10 Siguiente > Fin >>

Resultados 26 - 35 de 807
Advertisement





Registrado en Safe Creative