Make Text BiggerMake Text SmallerReset Text Size

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

Ir a navegapolis.com

Mouseland
Blog - cajon de sastre
18.05.2011

mouselandLo acabo de descubrir: el discurso de Tommy Douglas  "Mouseland", y ahora que estamos a menos de una semana para pasar por las urnas aquí en España.... da que pensar :-)

 

 


 
scrumrf: nueva herramienta para gestión ágil de proyectos
Herramientas -
04.05.2011

scrumrfEstá aún un pelín beta, pero tiene un aspecto fantástico y apunta muy buenas maneras. Se trata de Scrumrf, una herramienta para gestión ágil bien conceptualizada.

Lo han han puesto en marcha con formato SaaS hace escasamente un mes Dany y Ricardo (TonkaLabs ), y merece la pena echarle un vistazo, aunque aún esté algo beta con alguna "arista" que pulir y algúna idea que replantear, porque desde la pestaña de  "feedback" podemos participar como "implicados" enviando nuestras propias sugerencias, que nos piden "con los brazos abiertos"   :-)

En breve: Se agradece el interfaz simple y limpio, con las funcionalidades necesarias y bien estructuradas: Proyectos que se componen de historias y éstas de tareas. Estimación y priorización. Definición de sprints. Gráficos de seguimiento de sprint y de proyecto (burn-down y burn-up). Comentarios de los usuarios a nivel de proyecto, historia y tarea. Muro del sprint con formato Kanban, etc.

pantalla scrumrf

Hay algunas cosas que "chirrian" un poco y que posiblemente necesitan un par de pasos de "feedback-beta". Quizá sería mejor no asignar roles a nivel de usuario, sino de proyecto, o emplear la misma métrica a nivel de historia y de tareas... o que lo pudiera configurar el usuario.

La versión gratuita permite la creación de 2 proyectos con un equipo de 5 miembros. 

 

 
Sé feliz
Blog - cajon de sastre
01.05.2011

felicidad"Be Happy " de Monica Sheehan Con música de Yael Naim, me encanta y no me resisto a compartirlo con vosotros, amigos. (vi@ Rafael Hernampérez )

 

 


 

 

 
Cómo levantar capital y crear una startup
Blog - gestion
12.04.2011

QuéLos proyectos estrella nacen al combinar dos ingredientes poco frecuentes: genialidad y suerte. La suerte es cuestión de probabilidad, que se puede tentar con actitud y trabajo; y la genialidad... ¡vaya usted a saber lo que es!

Un inventario de conocimientos, cursos o coaching puede también ayudar o despistar, pero en ningún caso es imprescindible.

De hecho entre los proyectos-estrella lo habitual son fundadores que "componen tocando de oído": Facebook, Twitter, Youtube, Microsoft, Apple...  Son entusiastas obsesionados por los "QUÉs", que van resolviendo los "CÓMOs" por intuición y criterio propio,  y normalmente "saltándose reglas".

Su éxito atrae la curiosidad de "entrenadores para el emprendimiento" (entrepreneurship coaching ?). Metodólogos que analizan las reglas que se han saltado los "triunfadores", para definir cuáles son las nuevas reglas que ahora llevan al tiunfo, y explican, con puestas en escena adecuadas y travistiéndolos como procesos,  lo que los emprendedores abordan por intuición y criterio propio.

Algunos "emprendedores" terminan despistados, cambiando el norte de su esfuerzo: del QUÉ al CÓMO: cómo crear una startup, cómo levantar capital...

 

 
Tele-kanban: tormenta de ideas
Blog - cajon de sastre
07.04.2011

ideaUn tablero kanban sobre una mesa y una cámara para reconocer la información de cada tarjeta y su posición.

Esta foto es el prototipo de un concepto alternativo al de "Scrum Detector " que aparece en el post anterior. Es la propuesta de Alejandro Rivero como idea semilla para compartir y comentar con las sugerencias que se os ocurran. ¿Le véis posibilidades?. ¿Es un punto de partida válido para un hipotético sistema de "tele-kanban" que permita a equipos distantes compartir un tablero de información visual? ¿Se os ocurren enfoques diferentes?... 

 prototipo tele-kanban

 Lo podéis comentar a continuación, o directamente con Alejandro @arivero

 

 
¿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.

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

Resultados 21 - 30 de 807
Advertisement





Registrado en Safe Creative