Algunos equipos de desarrollo en mi empresa están cambiando a prácticas de desarrollo ágiles y el trabajo de sus desarrolladores parece estar disminuyendo para discutir y programar minucias sobre características triviales del software debido a ciclos de iteración de dos semanas. Y también debido a la mentalidad de "cualquier desarrollador puede solucionar cualquier error". Recientemente me uní a uno de esos equipos, transfiriéndome de otro equipo en la misma compañía ...
Creo firmemente que los desarrolladores deberían ser dueños de sus características de software desde el inicio (diseño) hasta el final (implementación y pruebas unitarias). Agile parece ir en contra de este pensamiento. ¿Hay algo de verdad en mi percepción o solo estoy viviendo una mala implementación de Agile?
Durante nuestras iteraciones de dos semanas, a las personas se les asignan arbitrariamente nuevas características y correcciones de errores, dependiendo de su carga de trabajo durante ese ciclo. Nadie parece ser el responsable de las principales características del software. Pasamos una cantidad estúpida de veces en cosas triviales, como agregar un solo botón a un diálogo durante una iteración de dos semanas, completo con una historia, scrums diarios, revisión de código, etc.
Entonces, en proyectos ágiles, ¿cómo se manejan las funciones más grandes? ¿Quién es el responsable: los desarrolladores individuales o todo el equipo? ¿Cómo se extrae de las minucias y se enfoca en objetivos a más largo plazo? Cualquier comentario sería valioso.
Respuestas:
Si cree que ayudaría a los esfuerzos del equipo, no debe dudar en suavizar la mentalidad de "cualquier desarrollador puede solucionar cualquier error" que considera que crea problemas.
La práctica de
Collective Code Ownership, a veces también llamadaShared Code, es un principio fundamental en muchos sabores del desarrollo ágil, y es probablemente lo que estás experimentando:Desde extremeprogramming.org :
Desde c2.com :
Hay algunos beneficios definitivos para
Collective Code Ownership. Sin embargo, usted no es la primera persona en notar deficiencias en ese enfoque . Nada menos que Martin Fowler describe un enfoque que se encuentra entre los extremos deStrong Code Ownership(donde los individuos "poseen" sus módulos) yCollective Code Ownership. Él describe esto como propiedad de código débil :En el mismo artículo, continúa diciendo:
La conclusión es que para adherirse verdaderamente a los principios ágiles, el equipo debe hacer lo que conduzca a un código de trabajo de buena calidad. Si eso significa aflojar el agarre
Collective Code Ownership, entonces no hay nada de malo (o anti-ágil) en eso.fuente
Para responder a su pregunta, intentaré dar una descripción de cómo manejamos las situaciones mencionadas en su pregunta:
Usamos el marco de Scrum en Agile. La planificación de Sprint y las sesiones de preparación del trabajo atrasado ayudan a nuestro equipo a desglosar historias relativamente bien definidas.
En general, un equipo en su conjunto es responsable del resultado de los compromisos para un sprint (todas las historias). Tienen éxito o fracasan como equipo. Por lo tanto, el equipo en su conjunto influiría en cómo se debe gestionar el trabajo para hacer el trabajo en el sprint.
Las cartas de historia tomadas por un desarrollador (en los standups) se convierten en la responsabilidad de ese desarrollador de hacerla y cerrarla, lista para su lanzamiento al final del sprint. Sin embargo, el equipo debe usar las paradas diarias para ver si alguien parece estar luchando con su historia y luego proceder a ayudar al desarrollador a completar sus tareas pendientes.
En nuestro caso, con Scrum, si se nos da algo que no formaba parte del compromiso de sprint original, lo agregamos como 'trabajo no planificado' y nuestros propietarios de productos saben que el esfuerzo no planificado agregado puede resultar en que nuestros compromisos originales no se cumplan. También tenemos una estructura plana en el equipo, por lo que ninguna persona debe desempeñar un papel directivo y todos están motivados para no dejar que el equipo falle, ya que todos son igualmente responsables del trabajo.
fuente
El propietario del producto posee la parte de qué . Está a cargo de decidir qué elementos de la cartera de pedidos de productos son más antes que otros elementos, y es responsable de entregar el producto en función de los recursos disponibles a tiempo .
El equipo de Scrum (incluido el propietario del producto y el maestro de scrum) son responsables de la parte. Deben decidir cómo administrar el equipo, compartir conocimientos, autoorganizarse, reunirse diariamente (stand-up diario), revisarse a sí mismos (reunión retrospectiva), tener recursos multifuncionales, etc.
Esta idea está lejos de ser propietaria de una función, ya que las partes interesadas poseen esas funciones, no tú y yo, hermano.
fuente
La forma en que lo hago, con un bajo nivel de dolor, es hacer que cada desarrollador sea responsable de una tarjeta en el tablero, desde que se recoge de la lista TODO hasta que se mueve a HECHO. El propietario de la función, en cuanto a qué funcionalidad entra en la función, es Team Lead, SME y BA. Cada equipo tiene un jefe de equipo (el experto técnico y defensor), un experto en la materia y un analista de negocios.
Normalmente, el BA es el chico / chica que responde las preguntas del desarrollador que actualmente trabaja en una tarjeta. Todos trabajamos en la misma sala, por lo que si el Líder del equipo (yo), el BA o la PYME escuchamos algo con lo que no estamos de acuerdo, saltamos y llevamos al desarrollador a una sala de reuniones para discutir más a fondo. Por lo general, los tres llevaremos a los miembros de los otros tres si creemos que pueden ser valiosos para la discusión.
Es cierto que a veces lleva a perder algo de tiempo mientras discutimos un problema, pero generalmente llegamos a una buena solución rápidamente.
En última instancia, es el líder del equipo el que firma los elementos de la cartera de pedidos como listos para el desarrollo y es el líder del equipo el que tiene la última palabra cuando es necesario tomar decisiones y es responsable si la implementación es "incorrecta". (No preguntes sobre el juego de culpa "equivocado": /).
Se alienta a cualquier otro desarrollador que escuche la conversación a que ofrezca su opinión y todos los miembros del equipo tienen su opinión durante la presentación al final del sprint, cuando se muestran nuevas características.
tl; dr (para nosotros): el responsable del equipo posee las características y un desarrollador individual trabaja en una tarjeta de características (o error, mejora, deuda técnica, etc.) desde el inicio hasta la aceptación por parte del equipo de prueba).
fuente
El primer problema que veo es que el proceso de estimación se está ampliando un poco. Sí, los desarrolladores deberían poder opinar sobre la cantidad de trabajo que se espera que asuman. No, eso no significa que agregar un solo botón a un formulario web ahora sea una historia de dos semanas de desarrollador (sin importar muchos puntos que se igualen en el proceso de estimación de su negocio). Si ese es el estado actual de las cosas, entonces usted, como gerente del proyecto, debería estar haciendo algunas conjeturas.
En segundo lugar, escucho "desde el principio (diseño) hasta el final (implementación y pruebas unitarias)" y el primer pensamiento que me viene a la mente es "lo estás haciendo mal". Las pruebas unitarias son parte de su trabajo de diseño como equipo de desarrollo / desarrollo, y deben ocurrir primero; usted toma los requisitos básicos, los destila en una simple "lista de verificación" de "If ... When ... Then ..." - escriba oraciones, y luego convierta esas oraciones en una serie de pruebas básicas que afirman que el programa cumple con esos afirmaciones y por lo tanto los requisitos. Eso sucede antes de escribir una línea del código de producción que cumpla con las afirmaciones de las pruebas. Si sus pruebas unitarias son las últimas, después de que ya haya implementado el software, perderá varios aspectos clave de las pruebas unitarias; en general, sus desarrolladores no pueden "programar en verde",
En cuanto a que los desarrolladores "poseen" sus características, hay un sí y un no. En primer lugar, una sacudida bastante común de los "equipos autoorganizados" es la tendencia de los desarrolladores a partir en parejas o en tres y trabajar en las cosas que mejor conocen. Suponiendo que tiene un buen conjunto de experiencia de desarrollador de tal manera que el equipo puede cubrir todo el trabajo a realizar en cada iteración de esta manera, simplemente puede dejar que esto suceda; es bueno para la velocidad, ya que los desarrolladores se mantienen enfocados y familiarizados con las áreas de la base de código en las que han estado trabajando de iteración en iteración.
Sin embargo, un desarrollador que posee una característica de por vida es una mentalidad peligrosa, ya que reduce el "número de camión" de su equipo (definido muy francamente como "cuántas personas podrían ser golpeadas por un camión antes de que el equipo no pudiera funcionar, dado el el peor de los casos de personas específicas golpeadas y el conocimiento resultante perdido). Si el tipo al que le ha asignado la función "Importar archivos" de su software y que lo ha poseído durante 2 años se va de vacaciones durante tres semanas, toma un permiso extendido de FMLA, cambia puestos de trabajo, o en el extremo, realmente es atropellado por un camión y muere, ahora no tienes a nadie más que conozca esa característica porque esa área de la base de código ha sido el ámbito exclusivo de ese tipo durante años. Mientras que otra persona se familiariza con esta pieza particular de la base de código,va a perder una velocidad significativa, y también se abrirá a problemas adicionales con defectos, ya que el nuevo tipo que apenas está familiarizado con el funcionamiento de la base de código ahora puede permanecer lamentablemente ignorante de las cosas que puede y no puede cambiar dentro de él. .
En cambio, debe buscar cultivar una división del trabajo que mantenga el número de su camión al menos 2 o más, y en un equipo más grande (una docena o más) más cerca de 3 o 4. De esa manera, si un tipo no puede hacer el trabajo , por cualquier motivo, hay varias otras personas que pueden participar. A veces, los equipos simplemente se sacuden de esta manera, especialmente si incorporan algunas técnicas XP como programación en pareja o estilo dojo (un tipo escribe en una nueva afirmación basada en sobre los requisitos que el código no cumple; el siguiente individuo luego codifica para pasar esa prueba, luego agrega otra afirmación de requisito que falla y la pasa). Por definición, en estas situaciones, tiene múltiples ojos mirando el código, desarrollándolo y familiarizándose con él.
En general, la idea de Agile es promover el desarrollo "ligero". Su equipo parece estar empantanado en minucias de procesos y documentación, cuando el enfoque principal, según el Manifiesto Ágil, debe estar en los miembros del equipo y sus interacciones, y por supuesto en el código funcional y funcional. Los procesos inherentes a Agile son un medio para un fin, y no hay una sola forma de seguir a Agile; incluso los marcos de trabajo ágiles primarios como SCRUM son maleables en función de sus necesidades como empresa, equipo e incluso día a día (solo asegúrese de tener en mente las ideas básicas de los valores proporcionados por estos procesos al realizar tales cambios).
fuente
El proceso ágil lo define el equipo para el equipo siguiendo las pautas y puede diferir de un equipo a otro. En la mayoría de los casos, no he visto dos equipos diferentes que reflejen el mismo proceso en mi experiencia profesional. Básicamente, la idea es tener el desarrollo más eficiente, lo que en algunos casos significa que diferentes personas trabajan en funciones en la misma base de código y en otros casos una persona es el propietario de la función desde el principio hasta que se completa.
Básicamente, las características más grandes (llamémoslas historias de usuario) se pueden desglosar en historias de usuario más pequeñas y aún así una misma persona puede ser la propietaria de la función que difunde esas historias de usuario en varios sprints. Además, en consecuencia, la persona puede ser propietaria de una función y no hacer todo el trabajo para la función. P.ej
Guión:
El equipo es técnicamente el propietario de la función, pero un desarrollador puede actuar como tal.
En este escenario, hay al menos 3 personas (es posible que tengamos más de un QE en servicio) responsables de la entrega de la función, pero el desarrollador es el propietario y, en cierto sentido, dirige la función. Esto, por supuesto, requiere más dedicación a esta característica específica por parte del desarrollador, pero no está fuera del alcance de Agile y, al mismo tiempo, tenemos un único propietario de la característica.
fuente