Pregunta:
Disculpas por la publicación larga, pero no estoy seguro de cómo manejar esto.
Antecedentes:
Tenemos un equipo de desarrollo de 3 ubicado en otra ciudad. El desarrollador principal ha existido durante 6 años y los otros desarrolladores se han unido por menos de 6 meses y ambos se graduaron.
El último proyecto dejó a todos agotados debido a la mala comunicación, los requisitos en constante cambio y lo que parecen prácticas/procesos de desarrollo deficientes. Una parte que encontré polémica fue donde los desarrolladores vieron que su trabajo era 'codificar' y que era trabajo de la empresa 'probar'. Esto significaba que el personal de la mesa de ayuda no calificado tenía enormes scripts de prueba y estaba probando a mano la funcionalidad que podría haberse automatizado y las pruebas tomaron el doble de tiempo que la parte de "desarrollo". También insistieron en que se trataba de pruebas de caja negra, por lo que probablemente estábamos probando cosas que ellos ya habían probado. El desarrollador principal dividiría el trabajo en tareas rastreadas en su herramienta de desarrollo, sin embargo, se negó a que nadie supiera cuáles eran las tareas o revelar cómo las estimó.
Guión:
Me contrataron para supervisar el desarrollo de la próxima versión. La gerencia no quiere gastar dinero y nunca se ha encontrado con ningún proceso de desarrollo de software que no sea levantar el teléfono y gritar los requisitos. Quiero pasar a una metodología ágil, pero nadie, incluidos los desarrolladores, ha encontrado algo así antes. Como resultado, he pedido algunos pequeños cambios primero:
Hasta la fecha:
El desarrollador principal ha aceptado: (2) escribir los requisitos y ahora quiere que todo se escriba como una especificación completa. Incluso con esto, los desarrolladores se niegan a realizar pruebas de acuerdo con esta especificación exhaustiva porque "es trabajo del equipo de control de calidad". Siento que estoy siendo rehén ya que la gerencia ha visto el beneficio de esto, sin embargo, no está interesada en hacer más cambios porque involucrarse en la discusión es 'demasiado esfuerzo'. (1) fue rechazado porque se niegan a estimar, para que no se les exija esa estimación. (3) fue rechazado porque su trabajo es 'desarrollar' y el trabajo del equipo de control de calidad es encontrar errores. (4) fue rechazada porque la estimación 'lleva demasiado tiempo' y no quieren que se les exija. Como lo ha denominado el desarrollador principal: es
Ahora tenemos un proceso en el que el tiempo se divide en: x (escribir especificaciones) + x ('desarrollo') + 2x (pruebas): el desarrollo está esperando la mitad de este tiempo.
Resumen:
Disculpas por la publicación larga, pero no estoy muy seguro de qué probar. Me siento como si estuviera siendo rehén, y lo que sentí que eran pequeños cambios, ¿han sido 'demasiado difíciles' para todos los involucrados?
Mi enfoque se centraría en persuadir a su desarrollador principal para que acepte eso:
Creo que todo se reduce a mantener esta disciplina y una persona que lidere este cambio. Antes de traer otros vientos de cambio a través de un proceso, comenzaré con estos cambios 'culturales'.
¿Necesita a alguien que crea en esto y pueda persuadirlo/hacer cumplir los cambios, desarrollador principal? un arquitecto ? o tu ?
¡Bienvenido a PMSE!
En primer lugar, tiendo a preferir un tema claro y reflexivo que cualquier pregunta de dos líneas de personas que ni siquiera saben lo que quieren saber. En cambio, ofreció muchos detalles sobre su situación, lo que podría conducir a respuestas excelentes y precisas que (con suerte) encajarán en su escenario.
Al leer todos los problemas que presentó, concentraría mis esfuerzos en cómo manejar el comportamiento de los 'códigos solo para desarrolladores' . Pensando en Agile, el concepto de personas haciendo solo un rol es ridículo. En Agile, todos usan varios sombreros, especialmente los desarrolladores*.
Entonces, la clave sería entender por qué los desarrolladores tienen esa cultura .
Me pregunto algunas causas :
Esta lista podría ser enorme... pero yo diría que una conversación sincera con sus desarrolladores para entender por qué existe la cultura de 'los desarrolladores son solo programadores (pobres)'.
Los otros problemas, desde mi punto de vista, son colaterales. El problema de raíz es la calidad de los desarrolladores que tienes a mano.
Importante resaltar que también el concepto de QA es erróneo : QA, como su nombre lo dice, es asegurar la calidad del entregable. Un equipo de control de calidad no es un equipo de prueba. Idealmente, el control de calidad no detectaría ningún error, pero generalmente el control de calidad solo encuentra algunos errores. No la mayoría de ellos. Esa es la tarea del desarrollador, seguro.
Importante destacar también que, llegado el momento, quizás prefieras evaluar al equipo en su conjunto .
Recuerde: tratar de pasar a Agile con esta mentalidad de desarrollador será una pérdida de esfuerzos. Una de las bases de Agile es que todos hagan todo. Entonces, olvídate de los 'sprints' por ahora. Diría que una combinación de Agile + Waterfall podría conducir a mejores resultados (y menos desperdicio de recursos, como los desarrolladores jugando juegos de cartas mientras el 'QA' prueba sus códigos).
'* Descargo de responsabilidad: MI conocimiento Agile es muy limitado, así que chicos ágiles, corríjanme si me equivoco.
Creo que su primer paso debe ser un cambio de cultura con sus desarrolladores. De hecho, estoy lidiando con un problema similar, en el que muchos de mis desarrolladores (hasta hace muy poco era un líder de equipo) consideraron, como el suyo, que su trabajo era escribir el código, el trabajo de QA era encontrar los errores y el de ellos corregirlos. .
Estamos, lentamente, tratando de cambiar esa cultura para que sea responsabilidad de los desarrolladores no escribir código, sino producir un producto que cumpla con los requisitos, lo que obviamente incluye que cumpla con los estándares de calidad que tenga.
Una cosa que comenzamos a hacer es instruir a QA que si alguna vez encuentran (por ejemplo) 5 errores en 5 minutos en un proyecto, o un error muy obvio en ese tiempo, dejen de probar y lo envíen de vuelta a desarrollo para tener ellos lo arreglan. Este es un motivador bastante fuerte, porque es vergonzoso que te digan que tu trabajo es tan malo que ni siquiera vale la pena probarlo.
¡Vaya, parece que tienes mucho trabajo aquí, Jeff! Estoy de acuerdo con Tiago, no creo que un cambio generalizado a Agile funcione bien en esta situación, ya que realmente necesita que todo el equipo funcione como una unidad interfuncional tanto como sea posible, y todavía no estás allí. Sin embargo, hay muchas técnicas ágiles y artefactos que puede incorporar con el tiempo que pueden ayudar a mejorar la situación a corto plazo. Parece que el problema principal es la mentalidad del equipo de desarrollo en lugar del proceso en sí (¡aunque también hay algunos problemas!).
Ya ha realizado los pasos iniciales correctos al intentar que el desarrollo asumiera más responsabilidad en el rol de prueba/calidad, pero no tuvo éxito. Me pregunto si podría volver a intentarlo desde el lado de las pruebas unitarias. Quizás el equipo de desarrollo esté más abierto a mejorar la cobertura de las pruebas unitarias (ya que eso realmente debería ser parte del rol de los desarrolladores). Luego, podría usar esto como una forma de hacerlos participar un poco más con el concepto de garantía de calidad como algo que sucede a lo largo del proyecto. Una vez que estén creando de forma más activa buenas pruebas unitarias, podría sugerirles que ayuden con alguna forma de prueba de IU automatizada. Mi equipo acaba de comenzar a crear palabras clave de Selenium para todas las funciones nuevas como parte del desarrollo Definición de Listocriterios. Al principio dudaban, pero ahora están bastante a favor de la idea, ya que ha sido la forma más rápida y productiva de crearlos. Para su equipo, me apegaría a las pruebas automatizadas que involucran algún elemento de escritura de código, ya que será una venta más fácil.
Con respecto a los requisitos documentados, esta es un área en la que Agile puede ayudar. Si usa el formato de historia de usuario e insiste en el hecho de que las historias en sí mismas son solo ayudas de memoria para una conversación adecuada, eso puede ayudar a que el equipo de desarrollo y el negocio se comuniquen más estrechamente. El formato de historia de usuario es un formato fácil de crear para la empresa, y dado que son breves (porque gran parte de los detalles se encuentran en la conversación real), la energía de activación necesaria para persuadir a la empresa para que las cree debe ser baja. Puede extender esto enumerando las Condiciones de Satisfacciónpara cada historia y haga que los desarrolladores los demuestren en una demostración regular. Esto empujará a los desarrolladores a realizar al menos algún nivel de prueba antes de que esté "listo" para el control de calidad. Esto claramente no es perfecto, pero es un pequeño paso hacia el nirvana.
Para las iteraciones y estimaciones de 2 semanas, ¿podría impulsar el uso de puntos de historia como mecanismo de estimación? Estos no se basan en el tiempo, pero brindan una forma de realizar un seguimiento del progreso. No estoy 100% seguro de que esto funcione muy bien sin una buena relación de trabajo entre los equipos de control de calidad y desarrollo, pero podría valer la pena intentarlo. Supongo que la razón por la que los desarrolladores están tan en contra de la estimación es porque históricamente han sido quemados al estar sujetos a estimaciones. Necesitas trabajar duro para asegurarte de que esto no suceda. Los puntos de la historia son una buena manera de probar algo diferente como un puntapié inicial, pero una vez que tenga algunas estimaciones, debe asegurarse de que se usen con cuidado. No querrás perder la confianza de los equipos, ya que parece que será difícil recuperarla.
Entonces, en resumen, sugiero los siguientes pasos:
Buena suerte, parece que tienes unos meses divertidos por delante. Cambiar la mentalidad de las personas no es algo rápido, así que no apresure este proceso. Si solo puedes mejorar un aspecto, no te preocupes al menos has mejorado algo.
No estoy seguro de dónde reside su autoridad en esto, pero no es un problema de metodología lo que tiene, es un problema de responsabilidad/rendición de cuentas. Y hasta que/a menos que la gerencia se involucre, nada cambiará.
El problema es que tienes un grupo de personas que están determinando cuál es su trabajo y qué están dispuestos a hacer, incluso si se les dice lo contrario.
La única forma de corregir o cambiar esto es demostrar "por qué" la gerencia debe involucrarse. Resuma los problemas del último proyecto. Muestre cómo los cambios sugeridos mejorarán las cosas. Muéstreles cuánto les está costando esta actitud (repetición del trabajo, retrasos, corrección de errores, etc.)
Explíquele a la gerencia que tiene un equipo que no está dispuesto a estimar cuánto tiempo llevará algo porque no quieren ayudar con eso. Mgmt está pagando por ese tiempo, entonces, ¿cómo pueden pronosticar algo o rastrear a menos que se les dé algo desde el principio? cualquier cosa menos significa que el equipo de desarrollo tiene un presupuesto abierto para tomarse todo el tiempo que quieran.
En pocas palabras, hasta que pueda encontrar una manera de forzar a mgmt a ver los problemas y actuar, nada cambiará.
Jeff, Implementar un nuevo proceso es una tarea compleja. Demasiado complejo, creo, para describirlo en una respuesta de PMSE. Además, implementar no es el objetivo, el objetivo debe ser sostener el nuevo proceso y hacer que el cambio sea estable .
A corto plazo, puede realizar algunas mejoras y cambios, pero a la larga necesita cambiar la cultura tanto en la administración como en el equipo de desarrollo. Nunca vi un cambio, forzado solo por una gerencia de nivel medio, que tuvo éxito. Eso significa que debe vender el concepto a la gerencia y los desarrolladores, lo que implica política.
Situación que describiste, parafrasearía así:
Tienes un grupo de compañeros de trabajo que la pasaron bien sentados en su zona de confort, empujando su trabajo sobre los hombros de otros o no haciéndolo en absoluto. Por ejemplo, la gerencia no manejó los requisitos cambiantes y los desarrolladores no se preocuparon por la calidad. Ahora puedes hacer que se den cuenta de la situación y ganar el apoyo O decidir si quieres trabajar en un lío...
Mi departamento pasó de "ningún proceso en absoluto" a Agile, así que no dude en ponerse en contacto conmigo en caso de que necesite "soporte en el extranjero". Además, encontrará muchas soluciones a corto plazo en este sitio de PMSE.
Como desarrollador de software, puedo decirle con 100 % de certeza que, independientemente del proceso de desarrollo que esté utilizando (agile/waterfall/RUP/hacking), el trabajo del equipo de software es probar que el software que entregan funciona. Esto no solo incluye pruebas unitarias sino también (como mínimo) pruebas de integración de software. Es muy posible que no sea práctico para el equipo de software realizar pruebas a nivel del sistema debido a los recursos de hardware y/o al proporcionar recursos de hardware dedicados al equipo de software, pero muy bien deberían poder realizar pruebas de aceptación de software que cumplan con TODOS los requisitos de software. .
Desafortunadamente, si no tiene apoyo administrativo, entonces está realmente perdido. Sin embargo, si tiene algún apoyo administrativo (aunque sea un poco), lo único que recomendaría es exigir que el equipo de software pase los procedimientos de prueba de aceptación del software antes de pasar el software al control de calidad. Esto significa que todos los requisitos que se implementan para la versión en particular deben probarse de alguna manera. Si el equipo de software no quiere escribir los procedimientos, está bien, pero después de que su software falla continuamente en las pruebas de aceptación, eventualmente asumirán con gusto esa tarea. Luego, simplemente se convierte en una cuestión de que alguien verifique que sus procedimientos realmente prueban la intención de los requisitos.
Creo que un punto central es que no deberías tratar de persuadir al equipo para que haga algo.
Si tiene una cultura de baja confianza, un equipo recién formado y los desarrolladores lo ven como una extensión de la administración que intenta obligarlos a cambiar sus formas, tendrá dificultades para mejorar el proceso. Sin embargo, si puede 1) hacer que el equipo sugiera sus propias mejoras, y 2) hacer un seguimiento de esto lo mejor que pueda, entonces está generando la confianza necesaria para que el equipo crezca y aprenda.
jmort253