project-management - pmi - project manager office

¿Cómo lograr que los recién llegados comiencen con un proyecto existente? (16)

P: Cuando está en un proyecto en ejecución, ¿cómo hace que los recién llegados ... conozcan el código y la cultura del proyecto rápidamente para que puedan ponerse al día rápidamente?

Establecemos dos metas para los nuevos empleados.

Construye familiaridad: la gente nueva asiste a 2 revisiones de códigos el primer día. Se reúnen con los desarrolladores, ven el código del proyecto y pueden hacer preguntas. Continúe incluyéndolos en las revisiones de código hasta que decidan detenerse.
Cree respeto por el grupo: si la nueva persona escribe un blog, usa StackOverflow, o contribuye a un proyecto público, enlace a su perfil o trabajo. Si tiene un wiki del proyecto, muéstreles cómo publicar preguntas y cuándo pueden esperar respuestas.

Los primeros tres días, dos personas (típicamente 1 gerente y 1 desarrollador) almuerzan con ellos. Esto les da a las personas salientes acceso a su experiencia y les permite a las personas reservadas absorber algo de cultura sin forzarlas a una conversación de 1 a 1.

P: ¿Cómo, como peón, empiezas un proyecto? ¿Qué puedes hacer para que sea más efectivo?

Si es posible, comienzo a trabajar en el comedor, una sala de conferencias u otra área pública. Puse algo inusual en la mesa para que la gente lo pregunte. La conversación estimula la inclusión, algo difícil de lograr al principio de un nuevo trabajo. La parte técnica se vuelve más fácil una vez que sabes algo sobre la gente.

Cuando estás en un proyecto en ejecución, ¿cómo consigues que los recién llegados comiencen? ¿Cuál es, en su opinión, la forma más rápida de ponerlos en funcionamiento? ¿Cómo lograr que conozcan rápidamente el código y la cultura del proyecto para que puedan ponerse al día rápidamente?

¿Qué haces? ¿Darles defectos para resolver por lo que tienen que sumergirse en el código? ¿Les das documentación para leer (para que se aburran)?

Hace poco empecé con un proyecto y me asignaron defectos como punto de partida. Como siempre, todavía no tengo acceso al SCM (pero tengo las fuentes), todavía no tengo un correo, la gente no tiene mucho tiempo para ayudar, etc. Entonces, aquí está la otra pregunta. :

¿Cómo, como peon, empiezas en un proyecto? ¿Qué puedes hacer para que sea más efectivo?

Ayudándoles a saltar lo más rápido posible. Solo aprendes realmente haciendo algo :-).

Identifique pequeños errores / nuevas funciones con un alcance limitado, y pídales que lo hagan. Posiblemente les asigne un mentor que siempre pueden hacer preguntas.

Dar una charla de introducción formal también es una buena idea, pero sobre todo la información debe suministrarse "a pedido" (de lo contrario, se olvidará rápidamente). Por supuesto, debe responder no solo a la pregunta literal, sino también a algunos contextos.

Creo que lo mejor es asignar errores a nuevas personas, para que las corrijan.

Como nuevo, a menudo haré algunas cosas para ayudarme a entender el nuevo código base. Usaré ingeniería inversa del código en UML utilizando Sparx Enterprise Architect. Lo mismo con la base de datos. En ambos casos, esto me da la posibilidad de buscar el modelo de ingeniería inversa para encontrar cosas como tipos y nombres de columnas. También puedo crear diagramas basados en el modelo de ingeniería inversa. Los diagramas pueden centrarse en un área que me interesa aprender.

También usaré ReSharper para hacer refactorizaciones de prueba de áreas de código. Estos serían refactorizaciones agresivas y reformateos para que me sea más fácil leer el código; ¡No vuelvo a comprobar esto en el control de código fuente!

Después de presentarles la arquitectura y la documentación, bríndeles pequeños proyectos a sus recién llegados. Elija ese proyecto bajo los siguientes temas:

Los proyectos deben ser pequeños y razonables.
Los proyectos deben contribuir al "panorama general".
Los proyectos deben tratar los temas de su proyecto principal.

De esta manera, las personas se ponen en contacto con su proyecto principal y tienen que aprender las bases (por ejemplo, trabajar con el framework XYZ). Los recién llegados obtienen momentos de éxito, lo cual es muy importante. Debido a esto, se motivan en lugar de aburrirse. Los trabajadores motivados son buenos trabajadores ;-)

En TI, siempre es posible que se agreguen nuevas personas a los proyectos en ejecución cuando sea necesario.

Reúna todos los detalles sobre el proyecto de todas las fuentes disponibles.
Haga todo lo posible para que una persona existente le explique los requisitos comerciales. Y tratar de mantenerlo como un mentor.
Ya que tiene el código fuente, puede profundizar en él para encontrar todas las tecnologías que utiliza.
Dedique (extra) tiempo a aprender las tecnologías necesarias (p. Ej., Ajax, jQuery, etc.) que le resulten difíciles.
En lugar de leer todo el código de fuente, inicie rápidamente el módulo en el que se supone que debe trabajar.
Aprende el resto de código cuando los necesites.

Los días iniciales serán duros por seguro. Pero las cosas se estabilizarán una vez que empieces.

En algunas compañías (especialmente aquellas que están demasiado ocupadas para darle el tiempo que necesita) es más fácil pedir perdón que pedir permiso.

Lo que quiero decir con esto es lo siguiente: No gaste demasiado tiempo tratando de entender un problema antes de intentar solucionarlo. A menudo funciona probar algo, y luego revisarlo por alguien que sepa lo que debería haber hecho. Si lo entendiste mal, te dirán que, si lo hiciste bien, el rápido tiempo de respuesta te hará lucir bien.

Esto obviamente asume que tus intentos son al menos inteligentes. Tampoco quieres que te califiquen con el equipo. Pero haz las preguntas tontas antes. Cuanto más tiempo los deje, más implacable será el ambiente.

Obviamente, esto no sería un problema si la documentación estuviera a la altura. Trabajé para Accenture hace un par de años, y en realidad estaba productivamente creando un código útil en mi tercer día (los primeros 2 días en los que la inducción es de tipo HR). Sin embargo, también puede haber sido ese único proyecto. Pero nunca antes o después he experimentado lo mismo.

En primer lugar, conozca el entorno, el enfoque de su equipo para las tareas y cómo lo resuelven, eso le dice mucho sobre cómo aplicar ingeniería inversa al código existente para corregir defectos. Tenga el documento como referencia solo cuando esté atascado, o para encontrar el fragmento de código que está buscando, definitivamente le recomendaría conocer las reglas de arquitectura y de negocios antes de comenzar, si tiene una experiencia bastante justa en dev, usted podrá saber el código y corregir los defectos más rápido si sabe lo que está haciendo.

espero que esto ayude.

Saludos,

En realidad estás haciendo dos preguntas diferentes aquí: "¿Qué puede hacer el equipo para ayudar al nuevo miembro?" y "¿Qué puede hacer el nuevo miembro para ayudar al equipo?"

En respuesta a lo primero, hacemos programación en parejas. Desde el principio, el nuevo individuo está trabajando en los mismos proyectos que todos los demás (bueno, está bien, los proyectos seleccionados , pero aún así funciona como una iteración real), pero está trabajando con un miembro experimentado del equipo. Y tampoco la misma persona todo el tiempo; Intentamos intercambiar pares con frecuencia.

Ralentiza al desarrollador experimentado por un tiempo (tener que dar antecedentes, dibujar diagramas, dejar que el nuevo individuo tenga el teclado y cometer errores), pero no hay una manera más rápida de poner al nuevo individuo al día como miembro de pleno derecho. del equipo, capaz de chips en cualquier lugar que sean necesarios.

La forma más rápida de aprender cómo se hace algo es ver cómo sucede.

Emparejaría al recién llegado con alguien que haya trabajado en el proyecto por un tiempo. Pronto, nuestro recién llegado sabrá dónde buscar soluciones, y así podrá resolver las cosas por su cuenta.

Dado que usted es el recién llegado en este caso, creo que los defectos son un buen punto de partida :). Solo sigue haciendo preguntas a tus compañeros de equipo con experiencia.

Me gusta echar un vistazo rápido a los documentos de diseño y hojearlos. He encontrado que la mejor manera de conocer el código base es jugar con él agregando nuevas funciones o corrigiendo errores.

Ayuda si hay alguien a quien puedas hacer preguntas.

Me han echado al fondo una o dos veces, me han dicho que creo que hay un problema de seguridad de Thread en algún lugar allí. Puedes ver si puedes encontrarlo, sin siquiera saber qué se supone que debe hacer el código. Eso no fue tan útil.

Descubrí que, al poner a otras personas al día con un proyecto, pasar una hora o dos de mi tiempo mostrándoles las cuerdas y diciéndoles qué hacen los diferentes componentes y qué herramienta externa utilizamos ahorra tiempo en las preguntas posteriores. Así es como lidiamos con la duplicación del número de desarrolladores en nuestro equipo de 4 de la noche a la mañana, creo que me ayudó muchísimo.

Otros han mencionado que el nuevo chico (o gal) se fije en corregir errores. Creo que esto podría ser contraproducente, ya que podría implicar un conocimiento detallado del producto tanto para encontrar como para solucionar el problema de forma segura. También podría desmotivar a alguien.

En el lado de la codificación, un subproyecto pequeño y autónomo es probablemente el mejor. Le dará al nuevo iniciador un camino hacia el resto del proyecto y producirá algo útil.

Desde el punto de vista de la administración, asegúrese de que estén incluidos en todas las reuniones relevantes y de que se los trate como un miembro completo del equipo desde el día 1. Asigne un mentor y también programe algunos tutoriales sobre el proyecto y su historia. Saber de dónde proviene el proyecto es importante cuando se trata de entender las decisiones de diseño.

Realmente depende de la experiencia del nuevo comentarista en software, la experiencia en el dominio (industria) / tecnología que aborda el proyecto.

Lo primero que hago es asignar un coacher a esa persona, para que se encargue de la incorporación:

explicarle el proyecto (cosas generales)
Establecer una bibliografía de la documentación relacionada con el proyecto.
Cosas de la arquitectura actual.

Luego, dependiendo de la experiencia, podría hacer que la persona resuelva nuevas características, de forma independiente (no las críticas, pero algunas con menor importancia), o ponerla en un modo de programación en pareja con su acompañante al principio, luego involucrarlo En tareas "productivas".

Por lo general, no uso la corrección de errores para obtener información práctica sobre el proyecto, porque el riesgo de introducir efectos secundarios al corregir un error es significativamente mayor que para las otras personas que ya están en el proyecto. Si no tengo otra opción, le dejo que haga las correcciones, pero antes de cometerlo, primero debe revisar sus cambios.

También empecé un nuevo trabajo y me incorporé a un nuevo proyecto. Lo que más me ayuda es que me den tareas fructíferas. Estos son el tipo de cosas que alguien familiarizado con el sistema podría hacer en tan solo unos minutos. No son difíciles de programar, pero me obligan a familiarizarme más con el sistema. Las buenas ideas son cualquier cosa que se relacione con la estructura del proyecto, como automatizar un proceso o importar datos.

Una reunión rápida con uno de los desarrolladores existentes, preferiblemente uno tan "senior" como sea posible, es útil. Es bueno escuchar a alguien realmente hablar sobre el proyecto, ya que te da muchas pistas sobre qué partes son interesantes, qué están haciendo, qué interfaces se conectan con qué, y así sucesivamente.

Obtener "el panorama general" de un nuevo sistema puede llevar mucho tiempo, y aunque no creo que sea posible hacer trampa y obtenerlo de inmediato, al menos es posible acelerar el proceso.

Tal reunión no tiene que ser muy larga (¿una hora, quizás?), Y también creo que puede ser bastante divertida / interesante para los desarrolladores existentes, ya que hablar de cosas que sabe bien suele ser.

Lo primero para que alguien comience un proyecto, sugiero, mantenga un proyecto bien documentado. La documentación, aunque aburrida si es larga, debe mantenerse tan concisa y en cuanto al punto, podría ser

Tengo un fondo de python, java, C. Y sobre todo prefiero python. Así que déjame poner mis ejemplos en python

Mi documentación de python es de tal formato. Elija un estilo que se sigue estrictamente en su proyecto.

""" This program does so and so, a single line explanation arg1 does so and so. arg2 acts on so and so. It returns a list of something Detailed explanation of exceptions, process etc. >>> code.samples expected result >>> code.samples.failed traceback ... SomeError """

Cualquiera con interés comenzaría a leer algunos códigos de muestra, por lo que este será un buen punto para comenzar, lo que explica qué hace una función, clase o método.

Siguiente

Mantener un wiki, hay n número de motores de wiki por ahí. Para python, puedes usar moin-moin.

En tercer lugar

Para un novato, es difícil dejarlo en paz, definitivamente se aburrirá, en lugar de aburridas capacitaciones y todo, simplemente puede meterlo en la programación de parejas con uno de los expertos. Esta es una fórmula bien probada en programación extrema. vea wiki http://en.wikipedia.org/wiki/Pair_programming Cualquier novato aprenderá más rápido, si se le explican algunos conceptos en persona, en lugar de que lea cosas de otras fuentes escritas.

Por último ,

Ponga a un novato algún trabajo que hacer, él puede comenzar a construir pruebas para un programa, puede compilar los programas si está usando un lenguaje compilado (C / C ++ / Java). Deje que él trabaje en cambiar una función mientras se adhiere a las pruebas de unidad.

Estos serían mis dos centavos para conseguir un novato. No solo lo ponga en cursos y capacitaciones, déjelo trabajar en el proyecto, incluso si tiende a romper cosas, déjelo trabajar en su propia copia.

Nuevamente, observa que el novato está realmente interesado en la programación, de lo contrario, todo esto no funcionará para él. He visto a algunos tipos que simplemente se involucran en proyectos, solo para satisfacer su agenda personal y, a veces, solo ponen en peligro el proyecto. Evite tales personas.

La mayor parte de lo que dije, se refiere a proyectos de código abierto o proyectos mantenidos por la comunidad, puede que no solo sea cierto para los proyectos empresariales o corporativos, que se atienen a sus propias reglas. Siempre siga las reglas.

Empieza a familiarizarte con la estructura de archivos del proyecto
Leer documentos de desarrollador (si hay alguno)
Tenga un problema básico asignado a usted, explorelo, arregle, enjuague, repita;)
Encuentre una persona amigable (por desgracia, no todos los desarrolladores son amigables) para referirse con preguntas
En el camino, comience a inspeccionar el esquema de la base de datos (si hay un backend de base de datos)
A medida que avanzas, intenta resolver problemas más complicados.
Comienza a participar en discusiones públicas, expresa tus ideas.