Si todos los desarrolladores de un equipo tienen la misma función / responsabilidad en la redacción y actualización de documentos de diseño de software

7

Hace unos días hice una pregunta muy similar, pero como presenté demasiado de la situación actual de mi empresa, la mayoría de las respuestas se centraron completamente en algo que no estaba buscando responder. Así que quería volver a intentarlo ...

Teniendo en cuenta a casi cualquier equipo ágil, siempre tiene personas con variados a) conocimiento del producto b) experiencia en la producción de diseños yc) nivel general de competencia.

Entonces, digamos que toma un equipo ágil y usa los factores (a), (b) y (c) que aparecen arriba para obtener un puntaje general para cada ingeniero (solo ejercicio mental). Ahora los ordenamos en orden ascendente y obtenemos un espectro continuo.

Entonces, la pregunta que quería hacer es esta: ¿Se debería dar a cada persona de este espectro la misma responsabilidad en lo que respecta a escribir / actualizar especificaciones de diseño de software?

No estoy hablando de idear un diseño de software, en equipos ágiles que normalmente lo realiza más de una persona en un entorno más colaborativo. Pero al final del día, alguien tiene que volver a su escritorio para abrir su editor de documentos favorito (y aprobado por la empresa / equipo) y escribirlo todo.

La razón por la que hago esta pregunta es porque parece que las personas de alto rango del espectro tienden a producir documentos más legibles y concisos, pero tienen exactamente la información que desearía en una especificación de diseño para que las futuras personas que la lean tengan Mucho más beneficio. Las personas en el lado opuesto del espectro tienden a producir documentos que no son tan útiles o claros y muchas veces, incluso con varias iteraciones de revisiones de diseño, su trabajo no parece ser tan útil (por lo que las especificaciones que producen se convierten en escrituras). solo descargando un terreno que nadie lea o confíe debido a la forma en que están escritos).

No estoy proponiendo que el equipo ágil sea segregado y que solo ciertos individuos tengan ciertos roles que nunca cambiarán. Estoy preguntando... 1) ¿Qué hace en sus equipos con personas que tienen puntuaciones (a) x (b) x (c) muy diferentes? 2) ¿Tiene sentido no dar la misma responsabilidad a todos? En su lugar, asigne solo tareas de actualización más pequeñas (o ninguna) a aquellas en el extremo inferior del espectro. Pero luego trabaje con estas personas identificando (a), (b) y (c) los factores que necesitarían mejorar y, a medida que mejoren, les dará más responsabilidad.

Personalmente, no estoy vendido de una manera u otra, solo tengo curiosidad por cómo otros equipos están lidiando con esto.

    
pregunta DXM 09.10.2011 - 07:40

4 respuestas

4

Permítame responder con una contra-pregunta: si hubiera un componente del sistema que fuera particularmente adecuado para el conjunto de habilidades de un desarrollador, ¿debería ser la preferencia del equipo que ella sea la única que trabaja en eso? En un equipo ágil, casi seguro que no. Uno de los objetivos del "proceso ágil" es compartir y distribuir el conocimiento. Si aquellos que son malos en escribir documentos de diseño no obtienen práctica y comentarios, ¿cómo van a mejorar?

El mantenimiento de compilaciones, la escritura de códigos, la compilación, los documentos de diseño, la depuración y las pruebas forman parte del rol de desarrollador de software en casi todas las organizaciones. Si tienes un interés a largo plazo en invertir en los miembros de tu equipo, deberías considerar mejorar las habilidades más débiles, posiblemente uniéndolos a un mentor con una fortaleza en esa habilidad. Es difícil mejorar sin práctica.

El hecho de que los documentos de diseño sean importantes o no para un equipo ágil no es lo importante. Si un desarrollador no puede comunicar bien un diseño, entonces no puede comunicarse bien. He trabajado en equipos donde los miembros del equipo no podían usar svn. He trabajado en equipos en los que solo una persona sabía cómo formatear un archivo de configuración. Personalmente, creo que Microsoft Word está diseñado intencionalmente para trabajar en oposición directa a la forma en que pienso acerca de escribir documentos. No importa. Si esa es la herramienta que usa mi equipo, entonces tengo que adaptarme a ese entorno para trabajar de manera efectiva en un equipo. (Eso no quiere decir que no haya formas de cambiar el entorno, pero esa es una discusión diferente).

    
respondido por el Steve Jackson 09.10.2011 - 16:43
3

Escribir documentación es una carga compartida como todo lo demás en un equipo ágil.

Comience preguntando a su equipo qué tipo de documentación realmente necesitan, cuánto de ella y con qué frecuencia debe actualizarse. Luego instrúyalos a través de esa discusión teniendo en cuenta los valores ágiles. Eventualmente, deberían estar de acuerdo y comprometerse con algo, y cualquier cosa que se les ocurra es probablemente la respuesta correcta en su caso. No es su lugar decirles cómo deben hacerlo.

A menudo resulta que la documentación no se usa en la práctica y solo existe debido a las políticas de la compañía. Si descubre que no lo necesita todo, la mayor parte del problema con la redacción de la documentación desaparece. Por ejemplo, obtener conocimiento del código mediante comentarios, código limpio y pruebas unitarias, ya que las especificaciones ayudan mucho.

    
respondido por el Martin Wickman 09.10.2011 - 11:17
1

Es bueno que esté considerando documentar especificaciones de diseño. Como usted dijo, si la escritura se deja a los individuos, obtendrá niveles variados de calidad. Una forma de ayudar a elevar la calidad y el valor de este tipo de documentación es diseñar plantillas de lo que se debe documentar y buenos ejemplos de qué incluir y qué no incluir. Luego, haga que 1 persona mayor revise la salida (como una revisión de código pero con un número máximo de iteraciones fijo). Es difícil obtener una salida homogénea sin hacer esto.

Además, tenga en cuenta que algunas personas técnicas no tienen ninguna habilidad para escribir. Asegúrese de no presionar a esas personas para realizar tales tareas. Si tiene un sistema con una gran cantidad de componentes, la mayoría de las personas deben ayudar con la documentación. Hacer tareas solo a unos pocos expertos hará que su producción de desarrollo sufra.

    
respondido por el NoChance 09.10.2011 - 08:35
0

No hay una receta fija para la documentación; Como todo lo demás, depende en gran medida de las personas en un equipo y de sus personalidades y habilidades. Todos pueden hacer su parte, o una sola persona puede encargarse de la tarea. Todo vale, en serio. He tenido buenos resultados con el probador al escribir la mayor parte de la documentación, pero es quizás el mejor cuando un arquitecto / jefe de proyecto hace la documentación. Cada programador que haga su parte también puede funcionar, pero algunos programadores son muy malos en esto.

La pregunta que debe hacerse es cuál es la mejor manera de abordar el problema con su equipo, no cómo debe hacerse en un mundo ideal. Use las fortalezas de las personas o fortalezca las habilidades de las personas si son malas en algo, o incluso mejor, haga ambas cosas cuando pueda.

    
respondido por el Domchi 09.10.2011 - 15:43

Lea otras preguntas en las etiquetas