¿Debería un desarrollador (junior) tratar de impulsar mejores procesos y prácticas en su equipo de desarrollo / TI?

Soy un desarrollador junior que tiene la capacidad de ayudar a dar forma a los procesos de mi equipo si puedo justificar el cambio y si ayuda al equipo a hacer el trabajo. Esto es nuevo para mí, ya que mis compañías anteriores tenían procesos más o menos rígidamente definidos que provenían de la administración.

Mi equipo es bastante pequeño y algo nuevo (<3 años). Carecen:

• Un marco de desarrollo de software / gestión de trabajo bien definido (como scrum)
• fuerte propiedad del producto
• roles bien definidos (p. ej., el personal de negocios realizará pruebas manuales)
• reuniones regulares de pie
• un proceso consolidado de seguimiento de problemas (tenemos una herramienta, el proceso aún se está desarrollando)
• un conjunto o lista de unidades, sistemas, regresiones o pruebas manuales
• documentación sobre lógica y procesos comerciales
• Una base de conocimiento para documentar consejos internos y orientados al cliente

Y la lista continúa. La administración está abierta a la implementación de mejoras siempre que el valor esté justificado y ayude a realizar el trabajo más importante (es decir, el desarrollo). Sin embargo, la suposición subyacente es que debe asumir la responsabilidad de la implementación, ya que nadie lo hará por usted. Y no hace falta decir que algunos de los proyectos anteriores no son triviales, sin duda requieren mucho tiempo y claramente no son trabajo de desarrollo.

¿Vale la pena el esfuerzo de un desarrollador (junior) para tratar de impulsar lo anterior a medida que pasa el tiempo? ¿O es mejor "mantenerse en su carril" y enfocarse en el desarrollo y dejar la mayor parte de la definición del proceso y la optimización a la gerencia?

Buenas respuestas hasta ahora, pero no cubren todas las bases.

En mi experiencia, muchas personas recién salidas de la universidad tienen un conocimiento teórico fantástico, mucho mejor que yo o muchas otras personas mayores con décadas de desarrollo de software para ganarse la vida.

PERO, y eso es un gran PERO, ese conocimiento no se basa en ningún escenario práctico. En el mundo real, gran parte de esa teoría fracasa, o al menos tiene que tomarse con un grano de sal masivo, ya que en la práctica no funciona tan bien en un escenario del mundo real.

Caso en cuestión: una aplicación en la que trabajé hace mucho tiempo fue diseñada por un brillante teórico de OO, diseñado para seguir los principios y la teoría de OO a la T, con muchos patrones aplicados en todas partes.

Fue una pieza fantástica de diseño de software.

Lamentablemente, esto resultó en una pesadilla de producción y mantenimiento. La base del código era tan grande y compleja que los lugares eran imposibles de cambiar; No porque fuera especialmente frágil, sino porque era tan complejo, nadie se atrevió a tocarlo por miedo a lo que sucedería (el arquitecto / diseñador original había sido un contratista que hacía mucho tiempo que se había ido).

También se desempeñó muy mal, precisamente debido a la estructura de patrones de varias capas y a las bibliotecas de clases que requería el diseño. Por ejemplo, hacer clic en un botón en una pantalla para hacer una sola llamada a la base de datos daría como resultado varios cientos de instancias de objetos y llamadas a métodos, todo en nombre de garantizar un acoplamiento suelto y cosas así.

Este arquitecto había sido profesor universitario con varios libros sobre el tema a su nombre. Nunca había trabajado un día como programador en un proyecto comercial.

Las personas con experiencia práctica en la creación de software se habrían dado cuenta de la monstruosidad a la que el diseño conduciría inevitablemente y habrían adoptado un enfoque más pragmático, lo que llevaría a un sistema que es más fácil de mantener y funciona mejor también.

Lo mismo puede aplicarse a muchas otras cosas que encuentre como recién graduado, o incluso como un nuevo empleado en cualquier empresa. No asuma que debido a que su base teórica le dice que algo está mal o no es óptimo, que no hay una buena razón para hacerlo de esa manera.

Incluso ahora, con más de 20 años de experiencia en el campo, desconfío de criticar la forma en que se hacen las cosas en las empresas con las que trabajo. De paso, mencionaré que noté que las cosas son diferentes a las que, según mi experiencia, son las más óptimas, pero no de manera beligerante. Esto a menudo conduce a conversaciones interesantes sobre por qué esas cosas son como son. Tal vez ocurran cambios y tal vez no, dependiendo de si el valor de cambiar las cosas es menor que el costo.

No tengas miedo de sugerir que las cosas se pueden hacer mejor, pero siempre asegúrate de no parecer un niño con la nariz mocosa, sino un compañero de trabajo que está tratando y dispuesto a no solo aprender, sino también Ayudar a mejorar los procesos para el mejoramiento de la empresa, no solo la corrección teórica.

Sí, pero con mucho cuidado!

Déjame aclarar eso.

Debe esforzarse por mejorar la habitabilidad del software. Si observa el código / equipo / negocio / proyecto / administración y su primera respuesta es darse una ducha, entonces no es habitable. Si su primera respuesta es gritar, ¡sí! ... y luego quejarse cuando está fuera de la oficina, entonces debe hacer que su hogar sea más habitable. Es un sentimiento, y lo sabrás.

Dicho esto, estás trabajando en una complicada síntesis . Es probable que todo lo que hagas salga mal y probablemente empeore las cosas al menos a corto plazo, porque un simple cambio tiene ondas. Así que, en primer lugar, sé humilde, no me refiero a ser un empujón o aceptar que las cosas deben ser malas, me refiero a aceptar el hecho de que tus buenas intenciones te atacarán brutalmente.

El problema

Con la mejor de las intenciones, puede sentir que es necesario un cambio amplio y amplio, y no estoy en desacuerdo con la existencia de estas situaciones, pero tómese un momento para pensarlo. El sistema actual está funcionando, usted y su equipo están produciendo código, quizás sea lento, quizás sea doloroso, pero está funcionando y todos ustedes tienen experiencia en cómo hacerlo. Usted sabe aproximadamente qué esperar, en resumen, son profesionales con experiencia en este sistema.

Después del cambio radical, nadie, excepto quizás el implementador, sabe qué esperar. En resumen, todos se han restablecido a un nivel neófito en esta parte del sistema. Eso no es bueno. Los neófitos tienen que aprender las nuevas reglas que llevan tiempo. En ese tiempo, los neófitos cometen errores porque no se practican. Esos errores se vuelven parte del sistema, con el que ahora tienes que vivir y ahora no es tan brillante.

Un camino a seguir

Hay momentos en que cortar, quemar y reconstruir es, con mucho, lo mejor que puedes hacer. Es particularmente atractivo si no se practica a nadie en el sistema antiguo, porque lo único que se pierde es el conocimiento codificado. Si este conocimiento es completamente incomprensible, entonces ya está perdido, y comenzar de nuevo es la única opción. Por el contrario, si el método de codificación, o cómo se usa es problemático pero funciona, ese conocimiento aún es accesible, y quizás valga la pena mantenerlo, tal vez no lo sea. Simplemente no tome la decisión a la ligera.

La otra opción es trabajar con el sistema para que todos tengan un marco de referencia, pero cambiar pequeñas partes del sistema para que todos en el equipo estén al tanto, o si no están al tanto del cambio, es fácil Aviso y fácil de aprender. Esta es la base de las prácticas llamadas Kaizen . En la presentación Shaving the Golden Yak se presenta una fórmula más orientada al desarrollador. Recomiendo verlo y pensarlo detenidamente.

Así que encuentre algo pequeño que se pueda cambiar que mejore su vida y, con suerte, la de algunos otros. Arreglar o mejorar la situación. Esto le dará práctica y experiencia para poner en práctica los cambios. Asegúrese de recibir comentarios: ¿podría haberlo discutido mejor, si fue realmente útil, si molestó a otra parte del sistema? Desarrolle su sensación de lo que se puede hacer y cómo hacerlo.

Ahora han sucedido tres cosas:

• has mejorado el sistema,
• has obtenido experiencia sobre cómo cambiar el sistema
• el equipo te ha visto cambiar con éxito el sistema.

Ahora elija otra cosa para mejorar, a medida que su experiencia crezca y a medida que elimine los problemas bajos comenzará a enfrentar los problemas más difíciles del sistema, pero al menos ahora cuando dice que tenemos que cambiar X:

• Sabes cómo afectará el cambio al sistema
• Usted sabe qué problemas generará (qué reglas necesitan volver a aprender)
• Conoce algunas formas inmediatas de solucionar o mejorar los problemas que introducirá el cambio
• las personas que lo rodean son conscientes de que conoce el sistema y es capaz de cambiarlo con éxito

Sí tu puedes. PERO...

Tienes que tener cuidado.

Al comienzo de mi carrera (hace mucho tiempo) tuve la suerte / mala suerte de entrar en un proyecto de unos meses como "Junior".

Como lo primero que noté, no había (OMG) ningún repositorio de código. Todas las fusiones de código se realizaron manualmente mediante el envío de archivos zip entre sí por correo.

Así que fui a mi (también nuevo) gerente y le sugerí que deberíamos tener un repositorio. La respuesta fue: Ok, organízala ...

Así que organizar un repositorio de código, sin ayuda, era nuevo en la empresa, ahora que fue una experiencia humillante.

Cuando lo configuré todo, (sorpresa) nadie quería usarlo. Así que traté de impulsar las cosas y afortunadamente mi gerente entendió su importancia, así que tuve apoyo.

Pero esto resultó en que no me gustaban mucho y desafortunadamente obtuve un apodo derivado del sistema de control de fuente.

Así que mi opinión sobre esto es, primero sentir a los miembros de su equipo, lo que creen que es importante configurar a continuación.

Quizás también tengan una lista como la tuya. Tal vez lo han pensado todo y querían hacer esa "cosa" en la lista. Tal vez ellos ... (lo que sea) ...

Todo el equipo tiene que estar alineado.

Pero si no lo son, aún puede trabajar profesionalmente. Y encuentre personas con ideas afines y trabajen juntos como creen que debería hacerse. Si esto trae buenos resultados, más personas trabajarán con usted, eventualmente se convertirá en "el" proceso.

Al igual que con el código, lo mismo para los procesos de desarrollo: se necesita una mejora continua.

Entonces, sí, siempre debes tratar de mejorar lo que es posible mejorar.

Pero también recuerde a muchas personas con las que está trabajando, que ya podrían ser profesionales y saben lo que está mal y lo que se necesita.

¿Vale la pena el esfuerzo de un desarrollador (junior) para tratar de impulsar lo anterior a medida que pasa el tiempo?

Sí, siempre vale la pena intentar y mejorar las cosas. Usted sabe mejor qué problemas enfrenta después de todo.

Pero como mencionas, hay muchos problemas que resolver y muchos de esos problemas no son terriblemente valiosos. Y en muchos lugares, habrá barreras insuperables para su éxito u otras personas que estén mucho mejor posicionadas para defenderlos. Por lo tanto, siempre debe intentar mejorar las cosas, incluso si eso significa elegir qué cosas pasa su tiempo tratando de mejorar.

Porque al final, si no eres parte de la solución, eres parte del problema.

Si. Pero el cambio organizacional es difícil incluso para una persona mayor, por lo que si realmente desea marcar la diferencia, hágalo de la manera correcta:

• No durante las primeras semanas: use este tiempo para:

  • Crea una buena primera impresión. Demuestra que encajas en el equipo.
  • Comprender la cultura y la política de su empresa. ¿Es seguro presionar por cambios?
  • Construye una buena relación con tus compañeros de trabajo.
  • Conozca el proceso, las reglas y las necesidades de su equipo.
  • Aprende tu trabajo y hazlo lo mejor que puedas. Seguramente estarás lo suficientemente ocupado.

• Elige tus batallas. Obtenga algunas victorias tempranas : puede llegar con energía para cambiar todo, pero esto no es realista. Concéntrese en algunas frutas bajas y demuestre que sus ideas funcionan. Desea que sean receptivos a mejoras más complejas. Y recuerda que las cosas son más fáciles en los libros.

• Considere la implicación para los demás : hago refactores que afectan muchos archivos. Incluso si mejoran el código, debo ser muy cuidadoso para evitar convertir las fusiones en un fastidio. Trate también de comprender las razones por las que siguen trabajando así. Es posible que no puedan usar Scrum, ya que carecen de pruebas y, comprensiblemente, tienen miedo de impulsar el código no probado a la producción con frecuencia. Escribir una prueba real no es tarea fácil. El código actual podría ser realmente difícil de probar. Además, el equipo no puede usar ni para escribir pruebas o código comprobable. La base de código actual puede ser especialmente difícil de probar y necesita ser refactorizada. Puede llevar años cambiar este problema, pero al menos puede centrarse en la causa raíz.

• No juzgues. No exijas. Pídalo y escuche con atención: este es un momento en que la comunicación es crítica y nosotros, los programadores, generalmente no somos muy buenos con los matices sutiles. Existen técnicas para ayudar . Es fácil seguir presionando por nuestra idea en lugar de centrarnos en la respuesta. Primero asegúrate de que sientan que tienes sus puntos. Comprende que los sentimientos son importantes. ¿Qué les hace sentir este cambio? ¿miedo? insuficiencia? ¿ira? ¿frustración? ¿esperanza? ¿Perezoso? ¿Estúpido? (Nunca hagas que la gente se sienta estúpida). Por supuesto, habrías hecho muchas preguntas antes y esto evitará muchos pasos falsos.

• Lidere con el ejemplo : quejarse es fácil, crear el cambio es difícil. Muestra resultados y la gente te creerá. Si no usan prueba, puede escribir sus pruebas unitarias. Si la gente no documenta, puede compartir algunos documentos de Google con el equipo. Comprenda que "Ok, hágalo" es uno de los mejores escenarios posibles y que luego debe cumplir. En este caso , debe haber pensado qué recursos necesitará . Ejemplo: dame una pequeña instancia de Amazon y dos horas de los administradores para un servidor Jenkins

• Manténgalo pequeño y simple (y barato): no desea esperar una aprobación formal del presupuesto o hacer que sus jefes piensen que está perdiendo un tiempo valioso de los programadores caros. Sería genial tener este software de revisión de código o evaluar varias herramientas de código abierto, pero solo usaremos el repositorio por el momento.

• Obtenga masa crítica: reúna al grupo de personas enfocadas en mejorar la calidad. Incluso puede ir con ellos a conferencias y pedir ayuda o tutoría. Peopleware describe el "despertar del fenómeno gigante" con la base del equipo que se rebela literalmente contra algunas prácticas estúpidas que reducen la productividad. Esto individualmente habría sido realmente peligroso y no lo recomendaría. Pero si todo el grupo está de acuerdo, el cambio es más fácil.

• Dale tiempo. Luego vote con sus pies: es posible que desee probarlo durante unos meses hasta dos años. Pero algunas empresas no tienen soluciones fáciles. Algunos equipos no quieren cambiar y no tienen incentivos. Y algunas bases de código son puro horror. Si siente que es usted contra el mundo, recuerde que hay muchas ofertas en el grupo de trabajo. Desea aprender buenas prácticas y, a la larga, será mejor en un lugar con un salario ligeramente menor pero obteniendo experiencia que lo hará más valioso.

Bonificación: si tiene éxito, anótelo para su CV / Entrevistas. Como junior, generalmente tiene muy poco que decir y crear un cambio para mejorar siempre es una gran señal. Desea tener una visión muy clara y realista sobre lo que hizo personalmente y lo que fue el trabajo de otros. Imagine la siguiente pregunta de la entrevista.

• Cuéntame sobre un momento en el que hiciste una diferencia en el equipo.
• Bueno, estaba en un lugar donde tenían prácticas muy anticuadas. Mucha gente no estaba contenta con eso y la productividad tenía un gran margen para mejorar. Así que propuse hacer un experimento rápido con retrospectivas, hicimos X e Y y como resultado obtuvimos este maravilloso resultado medible ".

Si. Pero no las cosas que sugieres.

Fuera de su lista Las pruebas de Unidad / Integración son el único elemento en el que puede avanzar.

Puede comenzar a agregarlos usted mismo con una inversión de tiempo mínima y mostrar un valor instantáneo. Es un problema técnico con beneficios ampliamente aceptados y no afectará las prácticas laborales de otros. Al mismo tiempo que obtiene un gran conocimiento de la base del código, incluso si los resultados no son aceptados. Una venta fácil.

Los otros son generalmente procesos de negocios que involucran a todo el equipo o incluso a otros equipos. Puede sugerir mejoras, pero serán difíciles de cambiar para un empleado junior y el proceso de cambiarlas generalmente no es técnico y probablemente no esté relacionado con su trabajo normal.

También sugeriría cosas como, configurar canalizaciones de CI, implementaciones automatizadas, versiones, empaquetar bibliotecas como cosas buenas para atacar

Depende de:

• cuánto espera obtener de las mejores prácticas
• cuánto esfuerzo tendrás que pasar para llegar allí
• ¿Cuáles son las posibilidades de éxito y los riesgos? desde el simple fracaso de la adopción hasta las nuevas prácticas son realmente terribles, la calidad del código se degrada, las personas clave se van, todos te odian y tienes que encontrar otro trabajo en una ciudad diferente donde nadie sabe tu nombre

Básicamente: está dentro de tus responsabilidades dedicar un tiempo razonable a defender lo que crees que es mejor, pero la decisión debe ser una responsabilidad del equipo o de la gerencia. Tenga en cuenta que alienar a las personas rara vez vale la pena, incluso si termina con mejores prácticas.

No comiences con las cosas más complicadas como Scrum. Comience con los pasos más fáciles posibles.

No mencionó la gestión del código fuente. ¿Tiene algún repositorio de código fuente (git, svn, cvs, ...)? ¿Una estrategia para etiquetar y ramificar? Esos son pasos simples que un principiante puede hacer. Lea qué problemas resuelven estos pasos (intente) y cómo eso ayuda a su empresa a reducir costos (en eso está interesada la gerencia).

El siguiente paso podría ser compilaciones automatizadas, todas las noches o directamente después de cada registro, por ejemplo, con Jenkins. También puede ejecutar pruebas automáticamente. Y agregue algunas herramientas para medir la calidad del código (oh sí: definir algunos estándares de codificación también es un buen paso).

En cuanto a scrum, mejor lea sobre "Programación extrema" (XP). Scrum se basa en muchas ideas de XP y agrega un proceso formal a su alrededor; los conceptos de XP aún se pueden usar sin ese proceso.

Sugiera cosas, brinde información de fondo, intente convencer a otros para que lo prueben, analice los resultados, ... pero no espere mucha cooperación de otros: la mayoría de las personas prefieren seguir con sus viejos malos hábitos. Pero cuando no intentas eso, nada mejorará.

Dijiste que el equipo es bastante nuevo (3 años), así que si no puedes introducir algunos buenos principios ahora, será más difícil hacerlo 10 años después. Algunas de las cosas que mencionó, como el sistema de prueba y control de versiones, se encuentran entre las que ya podría sugerir, pero no arroje la sugerencia así sin enfatizar sus beneficios obvios y elegir las herramientas que requiere su paquete de desarrollo.

Al principio, haz preguntas

Al leer su lista, sugeriría las siguientes preguntas (consulte su lista para ver cómo encajan):

• ¿Cómo veo qué trabajo solicitan los dueños de negocios?
• ¿Has probado [Scrum]?
• ¿Quién es el dueño del producto para esto?
• ¿Qué roles hay?
• ¿Qué hace [este papel]?
• ¿Qué papel es responsable de [esta actividad]?
• ¿Has probado un standup diario?
• ¿Cómo comunico mis impedimentos al resto del equipo?
• ¿Cómo averiguo qué otros miembros del equipo están trabajando?
• ¿Deberíamos poner [esto] en la herramienta de seguimiento de problemas?
• ¿Cómo deberíamos escribir [esto] en la herramienta de seguimiento de problemas?
• Cuando [esto] sucede, ¿deberíamos ponerlo en la herramienta de seguimiento de problemas como [eso]?
• ¿Cómo lo probamos?
• ¿Cómo registramos nuestras pruebas para que otros las reutilicen?
• ¿Has probado [JUnit]?
• ¿Dónde está documentado [esto]?
• ¿Has probado [MediaWiki]?

Reemplace las cosas entre [corchetes] según corresponda para que las preguntas tengan sentido o se ajusten a sus prioridades. Considere volver a redactar si mi redacción no coincide con su estilo.

Es posible que ya haya comenzado a hacer eso. Favorezca las conversaciones uno a uno sobre las conversaciones grupales. Porque uno a uno, puede obtener una mejor lectura de lo que piensa la otra persona. ¿Es esa persona para este cambio? ¿En contra? ¿Enclenque? ¿Rabiosamente?

Cuando eres nuevo, hacer preguntas es prácticamente gratis. La gente debería esperar que hagas preguntas. Incluso si sus preguntas defienden implícitamente una posición a la que se oponen, no deberían enojarse. Deberían explicar por qué se oponen a esa posición. Recomiendo no discutir con ellos. Discutir tiende a endurecer las posiciones más de lo que convence. Tenga en cuenta quién tiene qué posición y seguir adelante.

Más tarde, toma medidas

Busque maneras en que usted y posiblemente otros (es decir, aquellos que notó que estaban de acuerdo con usted anteriormente) pueden comenzar los cambios que desea. ¿No todos quieren un standup? Por qué no? Quizás aquellos de ustedes que quieran uno puedan tener su propio standup. No es tan efectivo como con todo el equipo, pero más de lo que tienes ahora.

Cuando tenga un impedimento (y suponiendo que no pueda compartir una batalla), envíe un correo electrónico al equipo para pedir ayuda.

Identifique cuáles deberían ser los roles, posiblemente con el apoyo de otros que estén de acuerdo con usted. Comience a acudir constantemente a las personas cuando el trabajo involucra el rol que usted (posiblemente un grupo que) cree que deberían tener. Si retroceden, pídales que identifiquen quién debe ser el propietario de ese rol.

Solicite a los propietarios de los productos (que identificó) que escriban descripciones de cómo creen que su producto debería funcionar ahora y en el futuro.

Instale un marco de prueba (si otros lo prefieren, tome una decisión conjunta sobre qué marco) y úselo para sus proyectos. Cuando esté arreglando errores, escriba pruebas. Documente esto en el informe de errores en el rastreador de problemas (prueba escrita que demuestra el error, almacenada en [ubicación]). Anime a otros a ejecutar las pruebas cuando realicen cambios. Si no lo hacen, ejecute las pruebas usted mismo y envíe los problemas al rastreador según sea necesario.

Si puede obtener soporte de administración, instale un software wiki o similar y comience a documentar sus cosas. Si las personas le hacen preguntas que muestran que no leyeron la documentación, apúntelas a las páginas relevantes. Aliéntelos a hacer más preguntas si no entienden la documentación. Si continúan haciendo preguntas cubiertas en la documentación, cite la documentación al responder. Considere animarlos a actualizar la wiki si cree que el problema fue estructural en lugar de que no leyeran.

Sugeriría concentrarse solo en una tarea a la vez. Y ciertamente solo presionar uno a la vez. No presiones mucho. Vea este ejemplo de presionar más fuerte de lo que el grupo quería. Concéntrese más en cambiar su comportamiento que el de ellos. Si su camino es el correcto, eso debería ser obvio para las personas que lo observan. Las acciones hablan más que las palabras. Intenta no repetirte con la misma persona cuando empujes. Una vez que hayas llevado al caballo al agua, deja la elección de cuándo o si beber al otro.

Eventualmente, serás mayor

Con el tiempo, su equipo contratará nuevas personas. Dejará de ser el nuevo empleado y podrá defender sus puestos con nuevas personas. Trabaja con ellos para hacer cambios. Y es posible que también esté progresando con sus compañeros de equipo existentes. O si eso no funciona, busque un nuevo trabajo donde tengan mejores prácticas. No hay prisa real. Tienes un trabajo. Puede esperar un tiempo para tener un mejor trabajo, ya sea mejorando ese o encontrando uno mejor.

Respuesta corta : No, por todas las razones descritas en las otras respuestas. Incluso cuando se trata de un desarrollador intermedio o superior, generalmente es mejor buscar primero entender cuando se une a un nuevo equipo.

Una solución propuesta :

1) cuando veas algo que sientes que debería mejorarse, ¡toma nota de ello! (en un cuaderno, en una nota digital ...)

2) Después de 6 meses, vuelva a sus notas y verifíquelas. ¿Cuántas ideas ahora se sienten sin sentido e inadecuadas? Lo más probable es que te hayas ahorrado algo de vergüenza. Si algunas ideas aún se mantienen, ahora sería un buen momento para presentarlas, si es posible probándolas usted mismo primero.

Respuesta tardía, y acuerde mucho buen contenido en las otras respuestas.

Creo que es necesario mencionar que una cuestión clave aquí no son las prácticas específicas, sino la cultura general del equipo.

• Crear un cambio cultural es difícil .
• Más aún si lo ves como "junior"

Todo lo demás puede seguir si hay un medio para lograr una mejora continua .

Mi enfoque para lograr eso es:

• Procesos y procedimientos documentados.
• Retrospectivas con el equipo cuyas acciones son cambios en la documentación del proceso.

Supongo que si no tienes sprints aún no tienes retros regulares. Todo lo que necesitas es una conversación con el equipo, y luego actuar.

Puede comenzar fácilmente a documentar procesos. "Soy el chico nuevo, ¿he entendido bien? Déjame escribir eso". Es importante seguir el proceso usted mismo o intentar llamar a nuestro sitio donde se interrumpe.

Tal vez comiences con tales conversaciones siendo ad hoc y luego sugieras rituales regulares.

Tomar este enfoque permite un enfoque incremental, suave y suave. Puede evitar aparecer como un joven que sabe todo y tratar de ser un facilitador para el equipo que está haciendo el cambio.

Algunas consideraciones

• Algunos equipos tienen un proceso pobre pero en realidad ya lo saben. Quieren cambiar y solo necesitan algo para catalizar eso. Otros equipos realmente se atascaron en sus caminos y fueron mucho más difíciles de cambiar.
• Lo mismo vale para las personas.
• Debe ser sensible a eso y descubrir quién en el equipo está abierto a cambiar y quién no. Entender porqué.
• Encuentra victorias fáciles.
• Haga que los cambios sean bienvenidos para el equipo: encuentre sus puntos de dolor individuales e intente ayudar a solucionarlos.