En el desarrollo ágil, ¿quién es el propietario de las "características" del software y cómo gestionar el desarrollo?

8

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.

Kavka
fuente
Si desea salir de las minucias, no se preocupe por hacer una asignación de por vida de una función a un desarrollador específico.
JeffO
"A las personas se les asignan arbitrariamente nuevas características pequeñas" parece un problema, no es ágil. Los procesos Agile típicos deberían permitirle seleccionar su propio trabajo. Trate de leer un libro sobre Agile. Recomiendo successingwithagile.com para todos.
Dave Hillier

Respuestas:

12

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 llamada Shared Code, es un principio fundamental en muchos sabores del desarrollo ágil, y es probablemente lo que estás experimentando:

Desde extremeprogramming.org :

La propiedad colectiva alienta a todos a aportar nuevas ideas a todos los segmentos del proyecto. Cualquier desarrollador puede cambiar cualquier línea de código para agregar funcionalidad, corregir errores, mejorar diseños o refactorizar. Ninguna persona se convierte en un cuello de botella para los cambios.

Desde c2.com :

ExtremeProgramming considera que el código pertenece al proyecto, no a un ingeniero individual. A medida que los ingenieros desarrollan la funcionalidad requerida, pueden explorar y modificar cualquier clase. Son responsables de mantener en funcionamiento todos los UnitTests (y escribir otros nuevos para una nueva funcionalidad). Asumen los mismos deberes de preservación de integridad que el propietario de la clase en una situación de CodeOwnership.

Trabajar en este modo permite que un equipo responsable se mueva rápidamente para agregar nueva funcionalidad mientras mantiene la responsabilidad en los objetos correctos. CodeOwnership crea dependencias y cuellos de botella al implementar UserStories. Evitamos la propiedad del código porque entra en conflicto con el compromiso de PlanningGame. ("¡El código no es nada, las historias lo son todo!")

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 de Strong Code Ownership(donde los individuos "poseen" sus módulos) y Collective Code Ownership. Él describe esto como propiedad de código débil :

La propiedad de código débil es similar [a Propiedad de código fuerte] en que los módulos se asignan a los propietarios, pero diferente en que los desarrolladores pueden cambiar los módulos propiedad de otras personas. Se espera que los propietarios de módulos asuman la responsabilidad de los módulos que poseen y estén atentos a los cambios realizados por otras personas. Si desea realizar un cambio sustancial en el módulo de otra persona, es cortés hablarlo primero con el propietario del módulo.

En el mismo artículo, continúa diciendo:

La elección entre propiedad débil y colectiva tiene más que ver con la dinámica social del equipo. Ambos parecen funcionar, y fallan, igualmente bien. Personalmente, prefiero la dinámica de un equipo de propiedad de código colectivo, particularmente en el contexto de la Programación Extrema.

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.

Eric King
fuente
Gran respuesta y buenas citas! Diría que en un mundo perfecto con el equipo perfecto, Strong Code Ownership tiene mucho sentido. Sin embargo, muchas empresas tienen desarrolladores de peso muerto y cuando se les otorga la propiedad de una tarea, todos sufren y, como resultado, la calidad del software se reduce al nivel más bajo posible. La programación extrema y la propiedad colectiva son mejores en este caso porque los desarrolladores ineficaces pueden evitarse.
maple_shaft
3
@maple_shaft: Diría que en un mundo perfecto con el equipo perfecto, la propiedad del código colectivo tiene mucho sentido. Todos los desarrolladores comprenderían completamente todo el código y serían competentes para realizar cambios en cualquier lugar. Cualquier desarrollador podría hacer todo el trabajo necesario para cualquier historia de usuario. No habría cuellos de botella ya que uno u otro propietario se sobrecargó.
Kevin Cline
@kevincline Buen punto y una perspectiva que no consideré
maple_shaft
Gran respuesta. Creo que lo que me incomoda con Agile es la gran diferencia entre las prácticas de mi equipo anterior y el nuevo. En mi antiguo equipo, todos tenían títulos de maestría y doctorado en un campo de ingeniería. Primero fueron expertos en un área que luego implementarían código especializado en su dominio de experiencia. Por lo tanto, la propiedad del código compartido sería prácticamente imposible. Mientras que en mi equipo actual, todo el mundo es esencialmente un experto en informática con antecedentes y experiencia similares, lo que parece hacer que la propiedad compartida sea más factible.
Kavka
@Kavka: Supongo que su antiguo equipo confiaba en la experiencia del dominio como un sustituto de los requisitos explícitos de nivel de unidad (es decir, pruebas de unidad). Se necesita experiencia en el dominio para definir los requisitos. No es necesario implementar requisitos una vez definidos. En mi experiencia, el código escrito por expertos en dominios tiende a ser difícil de mantener porque los expertos en dominios rara vez son también programadores expertos.
Kevin Cline
4

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.

David 'el jengibre calvo'
fuente
3

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.

Saeed Neamati
fuente
1

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

Rob Gray
fuente
0

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

KeithS
fuente
0

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:

  • Característica grande que dura 6 semanas (3 sprints).
  • La función se divide en varias historias de usuarios, cada una de las cuales demora hasta dos días.
  • Las historias de usuario incluyen desarrollo de características, pruebas unitarias, pruebas de interacción, integración (con otras características) y pruebas de integración.

El equipo es técnicamente el propietario de la función, pero un desarrollador puede actuar como tal.

  • El desarrollador escribe la funcionalidad
  • El desarrollador escribe las pruebas unitarias.
  • Un ingeniero de calidad escribe la automatización.
  • Otro desarrollador asegura la integración

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.

Konstantin Dinev
fuente