Estoy en esta compañía de software, y hasta ahora solo he tenido dos gerentes, pero ambos ven los trabajos de programación como no muy diferentes de poner ladrillos. Siempre enfatizaron que debemos asumir los trabajos de los demás en cualquier momento.
Como resultado, nuestro código tiene "propiedad grupal": nadie es dueño de nada y nadie es responsable de nada tampoco. O, en otras palabras, todos son dueños de todo y todos son responsables de todo. Si algo se rompe, cualquiera puede ser enviado a apagar el fuego, independientemente de quién haya creado el problema. Si abres el código, es bastante caótico, porque diferentes personas tienen diferentes formas de hacer las cosas. Además, arreglar el código de otros sin dedicar mucho tiempo a entenderlo primero rápidamente termina con parches sobre parches sobre parches. Esto nunca molesta a nuestros jefes, porque están orientados a resultados; es decir, nunca se molestan en mirar nada a nivel de código.
Puede que alguien no lo crea, pero es absolutamente cierto, ¡y somos una empresa de software puro!
La justificación que tienen es que cuando todos son responsables de todo, cuando alguien se va de vacaciones, otros pueden/deben simplemente intercambiar y cubrirlo, para que pueda disfrutar de las vacaciones en cualquier momento. Una vez, un chico se había estado preparando para un nuevo módulo durante más de un mes, luego se tomó unas vacaciones y, justo antes de irse, le dijo a nuestro jefe que todos los problemas estaban resueltos y que estaba listo para comenzar a codificar. Entonces, en el scrum del día siguiente, mi jefe me dijo, tenemos que terminar esto la próxima semana, ¿puedes recogerlo, por favor?
Simplemente no podía creer lo que escuché, ese tipo lo preparó durante más de un mes, pero nunca había compartido sus hallazgos con nadie más, y ahora mi jefe quiere que lo recoja, de la nada, sin ningún conocimiento previo. y terminarlo en una semana.
No puedo recordar los detalles, pero tuve la suerte de encontrar algunas razones/excusas logísticas para esquivar la bala letal. No tiene el concepto de que hacerse cargo del trabajo de otros a mitad de camino es lo más doloroso para los programadores.
¿Es esto común para las empresas de software? ¿Cómo me sugerirías darle la mala noticia a estos tipos (despistados), que programar es muy diferente a poner ladrillos, sin que se sientan avergonzados, y también convenciéndolos, porque ambos creen firmemente que todos deben ser responsables de todo?
Les diría que tienen razón, entonces, ¿cómo vamos a lograr ese objetivo en la práctica?
En principio, se trata de un objetivo loable y alcanzable. Veamos los detalles:
Si cada desarrollador trabaja de forma aislada en su pequeña isla con su propio estilo y toma sus propias decisiones de forma independiente, esta es una receta para el desastre. ¿Cómo se integrará su trabajo con el de los demás? ¿Qué pasa si están enfermos o de vacaciones? ¿Qué pasa si, Dios no lo quiera, tienen un accidente y no pueden trabajar o incluso mueren? Si es la única persona que sabe cómo funciona su código y sus compañeros de trabajo necesitan una gran inversión de tiempo para entender el trabajo de esa persona, ¡esto amenaza la continuidad de la empresa! (Esto a veces se conoce como el Factor Bus ).
Al mismo tiempo, cada desarrollador tiene su propio conjunto de habilidades y especializaciones. ¡No todos serán igualmente competentes con todo y eso está bien! Después de todo, es por eso que están trabajando juntos como un equipo hacia un objetivo común.
Entonces, ¿qué se debe hacer para lograr una situación viable?
En primer lugar, el equipo debe sentarse y elegir un conjunto de pautas de codificación para adoptar, o armar su propio conjunto. Esto elimina el factor 'caos' del código: dado que todos harán las cosas de la misma manera, debería ser mucho más fácil para los compañeros programadores entender cómo funcionan las cosas.
En segundo lugar, se debe establecer un sistema que brinde la oportunidad de compartir el conocimiento. Si se espera que dedique todo su tiempo a escribir código, no hay tiempo para compartir conocimientos, por lo que el problema persiste. Los programadores deben tener tiempo para documentar su código o para compartir activamente su conocimiento con otros, o idealmente ambos . También se deben establecer pautas para la documentación del código para evitar posibles problemas que surgirían de una documentación incompleta o insuficiente. Si bien un experto puede comprender una función con unas pocas líneas cortas, alguien que no trabaja con la función regularmente necesitará un poco más de información para ponerse al día. La documentación debe proporcionar suficiente información para el segundo caso.
Idealmente, este intercambio de conocimientos está respaldado por revisiones periódicas del trabajo de cada uno. Esto brinda al revisor la oportunidad de aumentar su conocimiento del código y, al mismo tiempo, ayuda a su equipo a aumentar la calidad general del código, ya que el par de ojos adicional ayudará a detectar posibles errores. También ayuda al equipo a aumentar su comprensión de la calidad general del producto. Si muchas cosas tienen que ser resueltas de una manera 'hacky' entonces obviamente la calidad del producto será mucho más baja que si los mismos problemas pudieran ser resueltos con código agradable y limpio.
Para robar la analogía del barbero, lo ideal es que todos los barberos (codificadores) puedan terminar el trabajo de los demás porque:
todos usan el mismo conjunto de peinados
todos cortan con técnicas y herramientas que son iguales o al menos equivalentes
documentan su progreso en el corte de cabello utilizando un sistema acordado, anotando lo que han hecho, cómo lo han hecho y por qué lo han hecho de esa manera
regularmente se toman un poco de tiempo para revisar el trabajo de los demás, ayudándolos a familiarizarse con él
Para abordar la 'actitud' del OP hacia el problema, es muy posible que en realidad, con el tiempo que tienen los programadores (debido a los plazos y las expectativas sobre cómo se gasta su tiempo) y la naturaleza altamente especializada del trabajo de cada programador, este objetivo es inalcanzable en la práctica. De todos modos, es mucho más fácil ayudar a sus gerentes a ver por sí mismos por qué la meta es inalcanzable, luego afirmar que este es el caso y luego tener que defenderlo. Por lo tanto, si alguien propone algo con lo que usted ve problemas importantes, trate de responder con una actitud constructiva, es decir , "Claro, pero ¿cómo vamos a resolver X, Y y Z?" en lugar de responder con una respuesta negativa, es decir , "¡Eso nunca va a funcionar, debido a X, Y y Z!". Esto ayuda a que la gerencia lo perciba de una manera más positiva y, al final, es probable que genere un ambiente de trabajo mejor y más agradable.
Si lograr la meta A significa gastar mucho tiempo, esfuerzo o dinero en resolver los problemas X, Y y Z, entonces puede que no valga la pena, pero esta es una decisión que debe tomar la gerencia, por lo que es nuestro trabajo como empleados proporcionar con la información necesaria para llegar a una decisión bien informada.
La propiedad colectiva del código es una cosa dentro del desarrollo Agile y generalmente se considera una buena cosa. Pero parece que su(s) jefe(s) simplemente tomaron una cosa que les gusta del manifiesto ágil que les queda bien e ignoraron todas las demás.
Para que esto funcione, debe tener un equipo que trabaje en conjunto y se comunique con frecuencia. La mayoría de las tareas deben resolverse mediante programación en pares, las revisiones de código deben ser comunes y tempranas, debe haber un alto grado de pruebas para inspirar confianza en la calidad, preferiblemente se desarrolla utilizando el desarrollo basado en pruebas, etc., etc.
Que haya un estándar de código común ni siquiera es algo ágil, es solo sentido común.
Creo que el problema es tuyo y no de tus jefes.
diferentes personas tienen diferentes formas de hacer las cosas
Debe detener eso ahora mismo, establecer estándares de codificación, comenzar a trabajar con diseños y convertirse en intercambiables.
Cuando uno de mis compañeros de trabajo se va de vacaciones, obtenemos un documento de lo que está trabajando, cuál es ese progreso y cuáles son los temas pendientes y, lo más importante, dónde está la documentación.
Creo que el meollo del problema es que deberías empezar a trabajar más en equipo.
Y si no puede llegar allí como compañeros de trabajo, es el trabajo de la gerencia hacer que eso suceda, se les paga por eso.
¨I think the heart of the problem is that you should start working more as a team."Mira, eso es un problema de gestión. El corazón de este problema es que, si todo es como se describe, esta bien podría ser una de esas empresas que se deshace de los gerentes, porque estos tipos no están haciendo su trabajo.La propiedad colectiva del código, en la que cada programador puede trabajar igualmente bien en cada parte del software, es un ideal al que se debe aspirar (porque los beneficios son reales), pero se necesita mucho trabajo para alcanzarlo.
El equipo necesita hacer cumplir un estilo de programación para que el código sea inmediatamente reconocible para todos. El equipo debe realizar revisiones estrictas del código para que el conocimiento de una parte del código se comparta tan pronto como se escriba y se garantice el estándar común de calidad. Debe usar una "definición de hecho" que asegure que nada se llame "hecho" hasta que se documente, pruebe y revise. Los nuevos miembros del equipo necesitan tiempo y capacitación para ponerse al día con todas las tecnologías utilizadas.
Si los gerentes exigen los resultados de tal proceso sin invertir primero en implementarlo, están siendo poco realistas.
Creo que debería discutir con sus colegas qué tipo de cambios le gustaría hacer en su flujo de trabajo para que esto sea más posible, como comenzar con revisiones de código o programación en pares, o acordar un estilo de codificación común.
Luego , diríjase a sus gerentes y diga algo como
Sé que le gustaría que todos los programadores fueran intercambiables, para que todos podamos trabajar en cualquier problema que pueda surgir. Sin embargo, aún no hemos llegado a ese punto: todos sabemos manejar solo una parte del código base, y es difícil adaptarse a la forma de trabajar de otras personas. Sin embargo, creemos que es una buena idea, y proponemos implementar X e Y para comenzar a trabajar hacia ese objetivo.
Me parece que los desarrolladores y los gerentes han tomado posiciones totalmente opuestas en el espectro que va desde la propiedad individual del código hasta la responsabilidad conjunta.
Los desarrolladores podrían hacer más para acercarse al ideal de los gerentes:
Es posible que no pueda llegar hasta la flexibilidad extrema que desean los gerentes, pero debería poder ir mucho más allá de que solo haya una persona que pueda trabajar en cada pieza de código. Es posible que a veces necesite decirles "Joe o Nancy podrían hacerlo más rápido" y dejar que ellos decidan si pagan el costo de que otra persona lo recoja.
httpResponseDataen lugar de data, por ejemplo) y pruebas (funcionales y simples) que documentación. Este último es subjetivo y se garantiza que está incompleto (de lo contrario, sería código).Respuesta corta: señala lo ridículo que es.
De hecho, me he encontrado con esto antes, y simplemente dije algo como:
¿Irías a un podólogo si necesitaras una cirugía cerebral? Ambos son médicos, ¿verdad?
O
¿Vas a un sastre para que te corte el pelo, porque los sastres usan tijeras como los peluqueros?
Luego señale que hay conjuntos de habilidades muy diferentes asociados con cada especialización. Dígales que la programación es la misma. Algunos desarrolladores son muy hábiles en un área, pero no tienen ni idea de otra.
No quiere decir que no puedas aprender las otras habilidades, pero tomaría tiempo y la voluntad de querer hacerlo.
Tu escribiste,
nadie es dueño de nada, y nadie es responsable de nada tampoco. O, en otras palabras, todos son dueños de todo y todos son responsables de todo.
Esos son dos extremos (quizás deberías buscar un punto medio entre los dos extremos), y una falsa dicotomía.
¿Es esto común para la compañía de software?
Dependiendo del número de programadores hay varias posibilidades.
Una es asignar un equipo (de varios) a cada componente. Espere que todos los miembros del equipo sean responsables (si es necesario) de (cualquier cosa dentro) de todo el componente. Un equipo puede o no tener un único desarrollador jefe o líder de equipo, que también puede ser o no el punto de contacto oficial del equipo con el mundo exterior (administración y control de calidad).
Un mínimo que recomiendo son las revisiones de código. Cada persona es responsable de su propio desarrollo y tarda días en codificar alguna característica nueva, y luego una o más personas dedican horas a revisar lo que se ha terminado, probado y registrado. Los revisores de código pueden sugerir cambios y pueden razonablemente esperar (por parte de la gerencia) haber entendido lo que revisaron. Por ejemplo, un comentario de revisión (antes de que acepten o 'firmen' el cambio) podría ser: "No entiendo esto, será mejor que lo reelabores un poco y/o lo expliques mejor", o "¿Qué significa esto?" hacer, cuál es la función (por ejemplo, visible en la especificación funcional) que está implementando, dónde está la prueba de regresión funcional automatizada que probará esto").
Después de (si) aprueban un cambio, es razonable que un gerente venga y diga: "Mire, Bob está de vacaciones y/o ha dejado la empresa; creemos que hay un problema con este módulo que revisó y/o desea agregarle una nueva función. ¿Podría echarle un vistazo? Ya está familiarizado con (sin mencionar que es responsable de él), ya que revisó el código cuando se implementó".
Las revisiones de código tienen muchos propósitos, entre ellos:
Una vez, un chico se había estado preparando para un nuevo módulo durante más de un mes, luego se tomó unas vacaciones y, justo antes de irse, le dijo a nuestro jefe que todos los problemas se habían solucionado y que estaba listo para comenzar a codificar. Entonces, en el scrum del día siguiente, mi jefe me dijo, tenemos que terminar esto la próxima semana, ¿puedes recogerlo, por favor?
Ahí tienes a un gerente que se le cayó el cerebro.
Sí, para cada desarrollador debe haber al menos otro con el que esté trabajando íntimamente (programación en pareja y cosas por el estilo) en cada tarea individual (incluida la elaboración del diseño de un nuevo módulo), que debería poder hacerse cargo sin indebidas volver a trabajar en cualquier momento.
Pero eso no es lo mismo que decir que no hay gastos generales para cambiar a la mitad del vuelo:
debería ser aproximadamente el mismo gasto general, o idealmente un poco menos, como si el desarrollador original abandonara esa tarea sin atar cabos sueltos para manejar alguna emergencia, y luego Tuve que volver a subir después de una semana de trabajar en otra cosa.
Ahora, si usted no es con quien trabajó en esa tarea, solo tiene sus notas, y por muy buenas que sean (lo que probablemente no sea estelar, o considerando su descripción más como muy irregular o inexistente), simplemente no puede abarcar todos los detalles que su compañero de trabajo resolvió en ese mes.
Es como ir al hospital y tomarse el tiempo para que un médico evalúe cuidadosamente su condición durante un mes con controles repetidos, muestras de sangre, electrocardiogramas, radiografías y cualquier otra cosa que parezca útil, y luego ir al cirujano para que lo trate de inmediato, nunca dejando que los dos comuniquen algo útil.
Si no es usted con quien trabajó, debe señalar qué compañero de trabajo lo hizo y también advertirle que , aunque a él le resultaría mucho más fácil hacerse cargo que a usted, todavía hay un costo considerable, ya que él no estaba t el que hace la preparación él mismo .
Si no hay nadie más familiarizado íntimamente con esa preparación, debe mencionar que debería haberla y (dependiendo de cómo se documentó la investigación), que podría necesitar entre x% (su mejor estimación en cuanto a la documentación y lo que escuchaste) al tiempo completo de comenzar desde cero.
Al final, parece ser una falla de gestión:
el líder del equipo tiene que reunirse con los otros desarrolladores y elaborar un estándar de codificación, además de comenzar a hacer programación en pares, pruebas unitarias y revisiones de código. y todas las demás actividades para asegurar la calidad y difundir el conocimiento en el equipo.
¿Es común? No mucho. Pero se puede configurar para que funcione.
La idea más allá es evitar a las personas como puntos únicos de falla . Por supuesto, tiene un costo y los programadores pagan el costo. Es por eso que su jefe será difícil de convencer de que es una mala idea. Él tiene todas las ventajas y tú todos los inconvenientes. Aún así, tiene sentido.
Tiene sentido que pases tiempo con otros programadores para intercambiar conocimientos y prácticas. Esto se puede hacer mediante revisiones, programación en pareja o cualquier otra cosa que funcione para usted. He estado en un equipo de 22 donde un consultor (allí desde hace años) pasaba la mayor parte de su tiempo deambulando por los pasillos en lugar de programar. Era el aglutinante del equipo, y al menos 15 personas del equipo podían trabajar en los programas que hice. Puede ser cualquier otra cosa que se adapte a la necesidad, discusiones informales, intercambio de conocimientos en máquinas de café...
Pero tiene un costo. Vale la pena pagar en mi humilde opinión, pero si todos trabajan con la misma tecnología, no será demasiado costoso. El costo es una gran sobrecarga de comunicaciones. Eso es más lo que le comunicarás a tu jefe, ya que su idea no es mala en sí misma. Simplemente, tiene que entender que es una inversión con recompensas no inmediatas.
La justificación que tienen es que, cuando todos son responsables de todo, cuando alguien se va de vacaciones, otros pueden/deben simplemente intercambiar y cubrirlo, para que pueda disfrutar de las vacaciones en cualquier momento.
Conozco una empresa ( Menlo Innovations ) que hace rotar a "todos" en torno a "todos" los proyectos en un horario establecido. Hay una manera de hacer que funcione.
La gerencia se ha fijado esto como meta, pero ha renunciado por completo a la responsabilidad de hacer lo necesario para que funcione. Será necesario contratar a más personas junto con cronogramas de entrega más largos. Pueden justificar esto demostrando resultados a largo plazo y no siendo rehenes de algún gurú que piensa que es la única persona en el planeta capaz de codificar su proyecto en particular.
El verdadero problema con esto es tratar de implementar alguna práctica de forma aislada. Deberían haber considerado prácticas complementarias como: desarrollo de equipos, pruebas, documentación más extensa, reuniones diarias para compartir y poner a todos al tanto de lo que están haciendo los demás.
editenlace está deshabilitado. La empresa es Menlo Innovations y la url es menloinnovations.comCreo que la siguiente es una conclusión bien equilibrada, desafortunadamente a alguien simplemente no le gusta escucharla. He recibido repetidas solicitudes para eliminarlos. En un mundo democrático, todas las voces merecen ser escuchadas. No te gusta escuchar que es una cosa, pero tratar de silenciarme es otra cosa, lo cual no es muy bueno en mi opinión. Así que aquí está de nuevo, mi conclusión, eliminado de mi OP.
Conclusión
Creo que es hora de que detengamos la discusión y pasemos de esto ahora. Después de una revisión cuidadosa, elegí la única "respuesta constructiva que sugiere una solución constructiva" como respuesta. Pero, de hecho, todas las respuestas son muy buenas, me gustaría poder elegir más de una como respuesta.
Por las respuestas me di cuenta que es un tema bastante controvertido, eso me abre los ojos, porque antes pensaba que mis jefes no tienen ni idea. Ahora me doy cuenta de que antes no tenía ni idea.
Como dijo Patricia Shanahan, "los desarrolladores y los gerentes han tomado posiciones muy opuestas en el espectro, desde la propiedad individual del código hasta la responsabilidad conjunta" , y puedo decir claramente qué respuestas/comentarios son de los gerentes:
Antes de llegar a tal conclusión, considere nuevamente el siguiente hecho, ese tipo lo preparó durante más de un mes, pero nunca compartió su hallazgo con nadie más, y ahora mi PM quiere que lo recoja sin ningún conocimiento previo y lo termine. dentro de una semana Y además, el hecho de que, para enviar la solicitud de vacaciones, necesitamos al menos un mes y, con mayor frecuencia, la presentamos dos o tres meses antes de las vacaciones. A partir de esto, creo que todos sabrían dónde está realmente el problema. Estoy totalmente de acuerdo con TripeHound,
Probablemente más importante que "El equipo necesita..." es "La gerencia necesita permitir que el equipo..." y aceptar que habrá un gran impacto en la productividad mientras esto sucede.
Admítalo o no, el problema real ha sido señalado por gazzz0x2z: "Viene con un costo, y los programadores pagan el costo. Es por eso que su jefe será difícil de convencer de que es una mala idea. Él tiene todas las ventajas, y usted todos los inconvenientes" , y personalmente estoy de acuerdo con RemcoGerlich, "si los gerentes exigen los resultados de tal proceso sin invertir primero en implementarlo, están siendo poco realistas" , porque después de todo, como lo expresó no comprende, "se necesita tiempo para volver a comprender incluso el propio código después de no verlo durante un tiempo, por lo que sin duda llevará tiempo comprender el de otra persona.Hay un límite práctico para compartir la responsabilidad del código" ."Sería bueno que todo el equipo directivo pudiera intercambiar puestos de trabajo también" .
Ok, sé que lo he llevado demasiado lejos, y la mayoría de los gerentes aquí podrían no estar de acuerdo conmigo. Entonces, permítanme enfatizar, estos son mis propios puntos de vista personales, y terminemos la discusión y sigamos adelante. Esa es también la razón principal por la que elijo la única "respuesta constructiva que sugiere una solución constructiva" como respuesta: los gerentes y los desarrolladores deben entenderse mejor entre sí y, en la mayoría de los casos, son los gerentes los que necesitan comprender mejor a los desarrolladores. Con tal comprensión y la solución constructiva, estaremos allí, pero no sucederá de la noche a la mañana.
Estoy en esta compañía de software, y lo gracioso es que solo he tenido dos gerentes hasta ahora, pero estos dos gerentes ven los trabajos de programación no muy diferentes a poner ladrillos. Siempre enfatizaron, ustedes deben asumir los trabajos de los demás en cualquier momento.
Esa es una noción completamente ridícula. La programación es un campo altamente especializado y los diferentes aspectos de la programación requieren conjuntos de habilidades muy diferentes. Lo mejor que puedes hacer es señalarles eso. Si bien las analogías con otras profesiones pueden ser puntiagudas y adecuadas (corte de cabello a medida, etc.), es posible que sus jefes no les crean, así que señale algunas de las enormes diferencias en la programación, como cuán diferente es el diseño de la interfaz de usuario de las pruebas de rendimiento, por ejemplo.
Pero sí, definitivamente debería tratar de disipar esa noción de sus gerentes, para que no tengan un despertar muy duro cuando descubran cuán equivocados están.
Puede estandarizar las convenciones de codificación, las herramientas, las carpetas y la forma de hacer las cosas. Pero no puede igualar el conocimiento sobre algunas funciones intrincadas y cómo funcionan algunas partes del código. Eso solo es propiedad de los que pasan horas pensando en eso. Explique a sus jefes que no es poner ladrillos en absoluto, tuve que lidiar con jefes ignorantes como estos, son del campo de la construcción y tratan de usar los mismos estándares en la industria del software, no puedo explicarles que esto conduce a grandes desastres. proyectos fallidos y alta rotación de muy buenos desarrolladores. Explícales eso. Cada pieza tiene su propia forma de trabajar y es específica para los requisitos comerciales. Por ejemplo, tiene un "ladrillo" que puede hacer una operación más, otra operación menos y dividir, algún día un tipo pedirá un cálculo de función derivada o matricial ¿puedes comparar ese "ladrillo" con el anterior? ¿El tipo que programó el nuevo cálculo matricial tiene tiempo para compartir su conocimiento y, al mismo tiempo, permanecer en horario? No me parece.
enderland