Consulta sobre el desafió Kanban - 02

¿Como se puede medir correctamente el peso de esta tarea, si el esfuerzo por parte del código que tiene que crear el desarrollador es medio?
mmm sabes estamos en el mismo dilema actualmente y en nuestros registros tenemos la siguiente estrategia:
Bajo el concepto de puntos de historia (XP) el peso es relativo al esfuerzo de actividades experimentadas anteriormente, pregunto entonces… ¿ya tiene tu equipo un registro en puntos de historia de tareas anteriores con los cuales pueda apostar? (claro si utilizas SCRUM), en KANBAN como metodología, el peso se pondera por capacidades productivas dentro del flujo, a diferencia de SCRUM, las capacidades no son estimadas respecto a experiencias anteriores (son reales, actuales y cambian en el tiempo) sino que nos sirven como medida para comprender el proceso productivo o FLOW, dicho esto, en nuestra situación actual (en estos momentos estamos participando en un proyeto de arquitectura empresarial) como comprenderás, nuestro equipo no tiene experiencia en el conocimiento de la organización para poder estimar puntos de historias, no conocemos tampoco la complejidad de las acitividades que tenemos que desarrollar, pues usualmente las más simples se transforman en complejas gracias a la cultura organizacional a la cual deseamos soportar.
Efectivamente, uno de nuestros objetivos es asegurar la data y su calidad para poder construir con esta patrones de información que necesita el negocio para su operatividad normal (soluciones de misión crítica), lo que comprendemos con este problema son 2 cosas:
1) existe un problema real en la organización respecto al manejo de la data, este problema tiene que ser resuelto por toda la organización mediante cultura y políticas de aseguramiento de la data, como sómos ágiles, pensamos en las personas sobre las herramientas y los procesos (incluido políticas y procedimientos) porque el problema real es cultural y no tecnológico.
2) comprendido esto, desde la tecnología, limitamos el alcance de nuestra responsabilidad mediante el aseguramiento de la data que es procesada por todos nuestros sistemas, la data está diseminada en toda la organización, por lo que pensar en desarrollar una única solución implicaría mucho esfuerzo y generaría muchos riesgos asociados, para comprender este dilema utilizamos la noción de “entidades” y les dotamos de capacidades de mensajería mediante la orientación a servicios", una vez que nuestra tarea KANBAN dentro del FLOW ha sido descubierta como compleja, realizamos una retrospectiva urgente e inmediata con todo el equipo y definimos las restricciones que implican el resolver este cuello de botella, las técnicas para ello las compartimos a continuación :o)
¿Como se puede identificar de mejor manera el cuello de botella?, es necesario crear alguna columna de “En Espera por 3ros”
No es cuestión de crear indicadores de flujo (que si son una buena idea) pues todo aquel intento para mejorar el FLOW es bien venido y sólo sabrás si tu idea fue buena o no “experimentando” :o) Ahora bien respondamos por partes tu segunda inquietud…
A) cómo identifico si existe un cuello de botella?
pues mediante indicadores de flujo (tal como lo propones “en espera por terceros”) e inspeccionando el flujo :o)
B) cuando descubres las restricciones de aquella tarea y el impacto en el flujo, tienes que ponderar la actividad de acuerdo a ello, me explico, si esta tarea es vital (y depende de terceros) tengo que parar el FLOW, se convierte en una tarea PRIORITARIA (para nosotros esta escala de problema o FAILFAST la etiquetamos como ERROR) su categoría rompe todo el flujo, una vez parado el FLOW se ubica la tarea en el indicador que hayamos descubierto existe la falla y entramos en acción redistribuyendo el esfuerzo en resolver el problema de forma urgente pues es muy costoso para todos parar el FLOW, para nosotros como responsables de la data y para el negocio como consumidor de información, para anular el desinterés de aquel que no provee el insumo necesario utilizamos técnicas FaceToFace y modelos de costos para que comprenda el impacto en la organización y el porqué paramos la producción, me comprendes?…
Ahora bien, si la tarea no es tan vital pero si posee un impacto considerable en nuestro FLOW, la etiquetamos como WARNING y debido a su condición de “compilación” dentro del FLOW, tiene prioridad de URGENTE o INVESTIGACIÓN (dependiendo como hayas fijado la condición de “compilación” del flujo) si es urgente se descubre en cuál indicador existe la falla y se regresa a ver a la capacidad adoptada para este indicador respecto a las capacidades totales del FLOW con el objetivo de redistribuir esfuerzos del equipo en la resolución de la falla mientras los otros miembros siguen trabajando en las tareas propias del indicador afectado y de todo el FLOW, espero haberme hecho entender:o)
si es de investigación, inmediatamente se destina un equipo apropiado que comprenda la naturaleza de la falla y en consecuencia se redistribuyen las tareas dentro del flow conforme a sus capacidades (pues soportamos por cortos períodos de tiempo una sobrecarga en el flow)
Esperamos haberte ayudado :o)
DSN_XP