Trabajo en una startup donde soy el único diseñador (UI/UX/Visual), sin embargo, no tenemos un desarrollador front-end real, por lo que la mayor parte del desarrollo de HTML/CSS también recae en mí, ya que soy medio decente en eso también. Tenemos una aplicación web que yo y el desarrollo mantenemos, pero también tenemos un sitio web de marketing del que básicamente soy el único mantenedor y también hago otros trabajos de diseño para marketing.
Tenemos un propietario de producto que ayuda a priorizar nuestra cartera de pedidos, pero lamentablemente actualmente no tenemos un maestro de scrum, por lo que estamos tratando de seguir una ruta más de "administrador de programa" hasta que podamos contratar uno.
Actualmente practicamos scrum para nuestro equipo de desarrollo, pero nos encontramos con problemas al tratar de descubrir cómo proyectar la velocidad, ya que técnicamente soy parte de 3 equipos diferentes: desarrollo, diseño y marketing.
¿Cómo contabilizas a alguien que forma parte de varios equipos? Me doy cuenta de que Scrum por el libro dice que esto realmente no debería suceder, pero cuando una empresa no tiene suficientes recursos, entonces una persona será compartida en varios equipos.
He visto respuestas que dicen que básicamente debes agrupar a personas con un determinado conjunto de habilidades (como diseñadores o arquitectos de sistemas) y hacer que formen un equipo completamente diferente que tenga su propio sprint donde muchas de sus tareas cubrirán el trabajo para diferentes equipos Como solo soy una persona, parece un poco exagerado, pero no puedo pensar en ninguna otra solución posible.
El mayor problema que tengo es tratar de hacer que mi proceso de diseño sea realmente ágil, ya que calificar un diseño puede volverse extremadamente problemático. A veces, un diseño se aprobará la primera vez, pero otras veces tomará 5 iteraciones. El único pensamiento que tuve fue tal vez volver a puntuar cada vez que tengo que hacer una iteración y llevarla a la cima de mi sprint, ya que técnicamente sigue siendo mi prioridad. De cualquier manera, hace que el diseño de pronóstico sea realmente difícil y si no puedo tener puntos de historia semiprecisos para el diseño, se vuelve imposible decir cuántos puntos se pueden asignar haciendo historias de desarrollo front-end para el proyecto del equipo de desarrollo si un la historia del diseño termina tardando una eternidad debido a las múltiples iteraciones.
Escuché soluciones antes que dicen dedicar "X por ciento" a este equipo y el resto al otro, pero el problema principal con eso es que mi tiempo cambia drásticamente de ser pesado en diseño una semana a pesado en código la siguiente. Así que la idea de tratar de asignar una cierta cantidad de tiempo a cada equipo prácticamente no funciona.
Diría que el trabajo que hago no debería afectar al equipo de desarrollo, pero actualmente sí afecta su carga de trabajo, ya que ellos son los que revisan el código y prueban cada ticket, ya que solo soy un equipo de uno y no puedo revisar mi propio trabajo. Así que no sé qué hacer aquí, ya que actualmente he estado saltando del diseño a la codificación principalmente en función de lo que considero más importante en este momento, lo cual no es exactamente lo ideal.
Pregunta relacionada: ¿Es posible que alguien sea miembro de dos equipos Scrum y cómo se puede hacer que eso funcione de manera más efectiva?
En su pregunta bastante larga, esta combinación de problemas se destacó como la esencia de lo que realmente está preguntando:
A veces, un diseño se aprobará la primera vez, pero otras veces tomará 5 iteraciones. El único pensamiento que tuve fue tal vez volver a puntuar cada vez que tengo que hacer una iteración y llevarla a la cima de mi sprint, ya que técnicamente sigue siendo mi prioridad. De cualquier manera, hace que el diseño de pronóstico sea realmente difícil y si no puedo tener puntos de historia semiprecisos para el diseño, se vuelve imposible decir cuántos puntos se pueden asignar haciendo historias de desarrollo front-end para el proyecto del equipo de desarrollo si un la historia del diseño termina tardando una eternidad debido a las múltiples iteraciones.
Cuando analizo esto, un par de cosas saltan a la vista:
El problema es solo tangencialmente que estás dividido en múltiples equipos; el problema real es que no hay rigor en el proceso iterativo de su organización o en el ciclo de inspección y adaptación.
Una historia debe poder completarse en una sola iteración. Cualquier historia que no se puede completar dentro de una iteración generalmente es:
Estas historias se deben marcar como incompletas, no se les deben asignar puntos hacia la velocidad o el agotamiento, y se deben volver a colocar en el Product Backlog para su discusión durante la Retrospectiva del Sprint, la repriorización por parte del Product Owner y la descomposición o análisis adicional durante alguna reunión futura de Planificación del Sprint. cuando la historia está de vuelta en el expediente.
Cualquier historia que no esté completa está "no terminada". Vuelve al Product Backlog, donde el Product Owner puede o no encontrarlo relevante para el Sprint Goal de tu próximo sprint.
Incluso si sigue siendo una prioridad máxima, el trabajo probablemente no debería llevarse a cabo tal como está. Si no se completó dentro del sprint, debe revisarse cuidadosamente para determinar:
Ciertamente, hay otras cosas que uno puede revisar sobre el trabajo incompleto como parte del ciclo de inspección y adaptación, pero la breve lista anterior generalmente ha abordado la gran mayoría de los casos del mundo real con los que me he encontrado. Siéntete libre de adaptar o inventar tu propio estilo de introspección; solo asegúrese de que usted y su organización se tomen el tiempo para analizar la causa raíz del trabajo incompleto y el costo para el proyecto de dejar sin resolver cualquier problema descubierto.
La velocidad debe reflejar la capacidad de un equipo . Si está trabajando en varios equipos, esto sin duda afectará la capacidad de los tres equipos y debería reflejarse como un costo visible para los proyectos en los que está involucrado. La mayoría de las veces, este costo se hace visible a través de una reducción en la velocidad real a lo largo del tiempo, un cambio en la pendiente de la quema del proyecto o a través de la cantidad de pisos incompletos que quedan al final de cada iteración. Tal visibilidad es una Cosa Muy Buena™.
Por lo general, es mejor calcular la velocidad como un promedio final de varios sprints. Personalmente, me gusta usar la media estadística de las iteraciones de los últimos tres meses, pero puede usar cualquier cuadro de tiempo deslizante que tenga sentido para usted. Si su velocidad se desvía más de dos desviaciones estándar de la media, probablemente necesite revisar su proceso de planificación y estimación, además de descubrir cualquier obstáculo oculto que pueda existir.
El valor de utilidad de la velocidad de seguimiento es que le brinda una medida de confianza en las estimaciones futuras. Si sabe que su velocidad varía de 5 a 20 puntos por iteración, entonces esperar que se completen 20 puntos de historias en cada iteración simplemente no es una expectativa realista de su proceso actual, pero probablemente podría estar seguro de entregar 5 puntos en cada sprint. .
Cuando usted o su organización comienzan a usar la velocidad como meta, en lugar de un control de detección para determinar si su proceso está fuera de control o una herramienta de planificación para determinar cuántas iteraciones se necesitarán para completar el trabajo pendiente actual, entonces están usando el método incorrecto. herramienta para el trabajo equivocado. La velocidad es simplemente datos estadísticos; no es una herramienta para desarrollar cronogramas de alcance fijo o fechas de entrega.
Utilice su velocidad real para determinar cuántas iteraciones es probable que necesite para completar un conjunto determinado de historias. Su Product Owner puede entonces ajustar el alcance del proyecto para cambiar el número de iteraciones estimadas requeridas para cumplir con los objetivos de gestión, pero no puede generar velocidad (pronunciado incorrectamente "productividad") jugando con los números.
¡Ningún trabajo invisible, nunca!
— Ley de transparencia de CodeGnome
Cuando dice que a veces se necesitan cinco iteraciones para que se apruebe algún elemento de diseño, eso no es intrínsecamente malo. El desarrollo iterativo a menudo significa que las cosas se refinan o se rehacen varias veces. Sin embargo, si los diseños no se completan durante una sola iteración, a menudo significa que hay un problema en el proceso, como la falta de habilidades del equipo multifuncional o un ciclo de retroalimentación mal diseñado en el proceso de diseño.
Si las iteraciones múltiples para refinar un diseño son buenas o malas es una cuestión de juicio para la organización. En cualquier caso, representan un costo para el proyecto, y este costo siempre debe ser visible. Si es simplemente el costo de hacer negocios en su organización para hacer múltiples rediseños, entonces esto debe verse como un costo aceptable, y no hay razón para esconderlo debajo de la alfombra. Si se considera subóptimo, entonces la organización debe mantener ese costo visible como un recordatorio constante de que los procesos relevantes deben inspeccionarse y adaptarse hasta que el costo sea aceptable.
Los costos visibles son la grasa que mantiene las ágiles ruedas girando suavemente. Los costos que son más altos de lo esperado son un llamado a la acción, y su existencia significa que su proceso está detectando adecuadamente esos costos más altos de lo esperado. Esto no es una falla del proceso , sino una oportunidad del proceso . Trátelo como tal.
Sin embargo, si lo hace, haga que su Product Owner priorice las historias y que su Scrum Master reciba y administre todas las solicitudes de su tiempo. Su equipo (y usted) debe centrarse en una historia de máxima prioridad (según lo decida su propietario del producto) a la vez y llevarla al estado "terminado". Ahora para responder a sus preguntas específicas:
¿Cómo explicas a alguien que es parte de 2 equipos diferentes?
Un equipo de scrum debería poder entregar un "incremento potencialmente entregable". Entonces, no, no es buena idea tener un equipo de diseño y otro de desarrollo.
hace que pronosticar el diseño sea realmente difícil y si no puedo tener estimaciones de tiempo para el diseño, se vuelve imposible decir cuánto tiempo puedo dedicar al desarrollo front-end para el proyecto del equipo de desarrollo.
No intente estimar en horas, haga la estimación en puntos de la historia. Todo el trabajo de software tiene algo de incertidumbre incorporada. No puedes eliminar esa incertidumbre. En el mejor de los casos, su equipo puede intentar mejorar su estimación en función de lo que ha aprendido de estimaciones anteriores. Trabaje primero en el trabajo de mayor prioridad (según lo decida su Product Owner). Una vez hecho esto, pasa a la siguiente historia en prioridad. Y discuta el proceso de aprobación del diseño en la retrospectiva y vea si hay alguna forma de mejorarlo.
el problema principal con eso es que mi tiempo cambia drásticamente de ser pesado en diseño una semana a pesado en código la siguiente.
¿Qué hay de malo con eso? El objetivo de su equipo debe ser ofrecer las funciones priorizadas por el propietario del producto, no mantenerlo alimentado con el trabajo de diseño y codificación de manera muy uniforme.
Actualmente he estado saltando del diseño a la codificación principalmente en función de lo que considero más importante en este momento.
Eso es exactamente lo que Scrum está diseñado para evitar. El cambio de contexto acaba con la productividad y aumenta la frustración. Refiera a cualquiera que quiera su tiempo al Scrum Master.
¿Es posible que alguien sea miembro de dos equipos Scrum, y cómo se puede hacer que eso funcione de manera más efectiva?
Trabajé con un desarrollador de bases de datos que era miembro de más de un equipo Scrum. La contención de recursos y la prioridad entre varios equipos de scrum se pueden resolver en una reunión de Scrum de Scrums entre los Scrum Masters y los Product Owners de los dos equipos. Te enfocas en hacer el trabajo priorizado disponible. También actualiza las horas restantes para completar las tareas abiertas diariamente.
GaTechThomas