Soy un desarrollador de software que trabaja en una empresa de sistemas integrados. Tenemos un Gerente de Proyecto, que se encarga del cronograma general del proyecto (incluyendo electricidad, calidad, software y fabricación), por lo tanto, su cronograma de software es muy breve.
También tenemos un administrador de software, que es mi jefe. Me hace escribir y mantener el programa de software, los documentos de diseño (diseño de alto y bajo nivel), SRS, gestión de cambios, planes e informes de verificación, gestión de versiones, revisiones y, por supuesto, el software.
Solo tenemos un ingeniero de pruebas para todo el equipo de software (10 miembros), y en un momento dado, hay un par de proyectos en curso.
Paso el 80% de mi tiempo haciendo estos documentos. Mi jefe proviene de un proceso de fondo y cree que lo que necesitamos es una mejor documentación para mejorar el software:
- Considera que el diseño es primordial, la codificación es "solo escribir el diseño", no debería llevar mucho tiempo y "todo el código debe escribirse antes de que el hardware esté listo".
- No entiende la diferencia entre un control de versión central y distribuida, incluso después de que le dijimos que es más fácil colaborar con un modelo distribuido.
- No entiende el código y quiere entender cada error y su solución propuesta.
- Considera que la verificación debe ser realizada por el desarrollador y la validación por el Probador. Sin embargo, nuestra verificación solo verifica si la implementación es correcta (no escribimos pruebas unitarias, nunca se considera en el cronograma), y la validación es una prueba de caja negra, por lo que faltan las pruebas unitarias.
Estoy realmente confundido.
- ¿Soy responsable de mantener todos estos documentos? Me hace sentir que estoy haciendo la gestión de proyectos de software, en esencia. Estoy de acuerdo con la documentación técnica, pero creo que la programación / planificación no debe ser realizada por el desarrollador.
- Realmente no me gusta crear documentos, quiero resolver problemas y escribir código. En mi experiencia, crear documentos de diseño solo ayuda hasta cierto punto, nunca es la solución para un código mejor o más rápido.
- Siento que al jefe realmente no le importa hacer mejores productos, sino solo ser un buen gerente a los ojos de la gerencia.
¿Que puedo hacer? Todo este año he realizado 3 meses de codificación real, el resto solo lo he gastado en hacer documentos y esperar los informes de errores de los clientes.
Respuestas:
Suenas como un ingeniero de software.
Un gerente de proyecto está más enfocado en el estado del proyecto general y en la asignación de recursos de una manera efectiva para garantizar que se cumplan los hitos y en el momento adecuado. También eliminan obstáculos y ayudan a los recursos del proyecto a centrarse en sus funciones laborales específicas.
Escribir y mantener la documentación técnica y de diseño es una parte importante de ser ingeniero de software y es apropiado para su función. Sin embargo, demasiado de algo bueno puede ser malo (ver Análisis de parálisis ).
Si el gerente del proyecto considera que los documentos de diseño son primordiales, entonces espera que los documentos sean entregables en el proceso. No es una pérdida de tiempo de su parte si él siente que son lo suficientemente importantes como para asignarle el 80% de su tiempo.
Esta es una ilusión y una vista de estilo Waterfall bastante anticuada de cómo funciona el desarrollo de software. Invariablemente nunca es tan limpio, no importa cuánto diseño y preparación dedique. Sin embargo, en esa nota, debe tener especificaciones de hardware claras y entornos de prueba adecuados y simulaciones de hardware simuladas para que su código interactúe, pero nuevamente, el mundo real es desordenado.
La gestión de proyectos es increíblemente fácil en un mundo perfecto. Sin embargo, el mundo no es perfecto, sin importar cuánto desee que sea, por lo que la gestión de proyectos reales es increíblemente difícil. Es por eso que se les paga mucho dinero.
¿Por qué debería importarle? ¿Cómo afecta a los hitos? No lo hace.
Su objetivo es trabajar con software y el tuyo también debería serlo. No necesita comprender el código, pero sí debe comprender los problemas que impiden que el software funcione. Una vez que los dos se encuentren cara a cara en este nivel básico, su objetivo común los ayudará a trabajar juntos de manera más efectiva.
¿Qué hay de malo en este sentimiento? Los probadores en el rol de garantía de calidad deben preocuparse por validar las características y requisitos. Los desarrolladores deben hacer todo lo posible para verificar y probar su trabajo antes de que vaya a la prueba.
Si prefieres ser un simple programador, entonces quizás deberías hablar con tu jefe sobre esto y ver si hay un mejor rol para ti en el proyecto. Alguien necesita escribir y mantener la documentación técnica, por lo que quizás uno de los otros desarrolladores pueda ayudarlo con algunas de estas tareas para que no pase el 80% de su tiempo escribiendo documentación.
Esto es principalmente cierto ... pero solo si los diez desarrolladores pasan el 80% de su tiempo escribiendo documentación técnica que nadie leerá nunca. Este es un enorme antipatrón de gestión en el que he vivido antes. Si descubre que está haciendo la mayor parte de la documentación para el equipo, entonces no parece justo que se le niegue el derecho de realizar más trabajo de codificación.
El hecho es que la mejor documentación técnica es el código en sí.
Siento que lo hace la atención porque el producto es su protegida y si los proyectos y características no se han completado y los clientes no están contentos, entonces la alta dirección no cuidar de él mucho. El problema es que su perspectiva sobre las mejoras de calidad necesarias no coincide con la suya y con la alta gerencia, y la percepción de los clientes de lo que sienten es importante.
Intente comprender qué es realmente importante para el producto, porque si bien puede aumentar la eficiencia de un proceso 3 veces, si pasa una semana completa haciendo esto, es a costa de otra característica importante que el cliente exige.
Todos queremos lucir bien a los ojos de nuestro superior. No hay nada de malo en eso, es la naturaleza humana ser egoísta. Este es un hecho de la vida.
fuente
Hasta cierto punto, estoy de acuerdo con su gerente de proyecto. El desarrollo de software va más allá de las funciones de codificación. :-)
Dada su situación, iría a él y le explicaría que sus solicitudes están tomando el 80% de su tiempo, y trataría de entender por qué es importante para él que pase este tiempo manteniendo la documentación en lugar de desarrollarla (lo que va más allá de la codificación).
Para su información, Atlassion , una compañía de software, tiene una proporción de 13 desarrolladores para una persona de control de calidad y la mayoría de las pruebas (planificación y ejecución) son realizadas por los desarrolladores. Aprendí esto durante una de sus presentaciones en Agile 2012 y nuestros equipos que actualmente trato de emular esta práctica.
Sin embargo, también discutiría con su gerente de proyecto si estaría abierto a probar Scrum como metodología para ayudar a avanzar a todo el equipo. Dada su descripción, no creo que esté usando Scrum.
Al igual que usted, estaba extremadamente frustrado por mantener planes que cambiaban constantemente y un enfoque ligero de Scrum me ayudó a superar esta frustración.
fuente
Los equipos con mejor desempeño en mi experiencia fueron aquellos que enfrentaron la menor cantidad de procesos necesarios para hacer su trabajo. En algún momento, un proceso adicional comienza a quitarle calidad al producto. Si el control de calidad comienza a perder errores porque están más preocupados por eliminar el papeleo, y DEV no está codificando características o corrigiendo errores porque están escribiendo documentación, entonces tiene un problema. Sin embargo, descubrir si este es realmente el caso en su empresa es una pregunta altamente localizada que solo las personas de su equipo pueden responder (no nosotros).
Hay una cosa en la que su jefe está muy equivocado, y es el hecho de que tiene tan poco control de calidad y no tiene pruebas unitarias. Un error creado por un desarrollador es, por definición, un descuido de su parte. Esperar que los desarrolladores prueben siempre sus propias características y tener pocas pruebas aparte de eso es un problema de proceso. El control de calidad puede ser reemplazado por pruebas automatizadas dependiendo de su dominio hasta cierto punto, pero si no tiene ninguno, entonces probablemente esté dejando pasar los errores (y eso generalmente termina costando más que encontrarlos antes).
Además, desde una perspectiva comercial estricta, contratar QA es más barato que contratar desarrolladores. Podrá cubrir más terreno para el dinero gastado si los equipos tienen una buena relación QA / DEV.
fuente
QA can be replaced by automated testing depending on your domain-1 No estoy de acuerdo con vehemencia con esto. Ninguna cantidad de pruebas automatizadas es un reemplazo viable para el control de calidad, especialmente cuando se trata de hardware especial.Las implementaciones de CMMI que he visto o de las que he oído hablar directamente han sido pesadas en procesos y documentación; La creencia de su jefe de que la documentación debe ser lo suficientemente detallada como para que la implementación sea trivial implica que su expectativa es similar.
Si está recibiendo una parte desproporcionada de la escritura / mantenimiento de la documentación, es razonable pedir que se distribuya de manera más uniforme. Si los otros desarrolladores tienen documentación similar a las proporciones de codificación y desea pasar la mayor parte de su tiempo escribiendo código; Puede ser hora de considerar encontrar un nuevo empleador.
fuente
Estás hablando de sistemas médicos ... por lo que la seguridad es primordial y, por lo tanto, la documentación (específicamente la trazabilidad) es esencial.
Un probador parece un poco ligero, pero aparte de eso, sí, usted es responsable de garantizar que la documentación esté en su lugar.
Mi experiencia en el mundo médico es limitada, pero en el mundo aeroespacial / de defensa tenemos Do-178B (ahora C) que prescribe un modelo de ciclo de vida que especifica la documentación y el nivel de pruebas necesarias (dependiendo de la importancia de la seguridad [más específicamente, el nivel de garantía de diseño] del software), y en el mundo del automóvil tenemos ISO26262 que hace lo mismo.
Si la documentación no está en su lugar, el producto no se certifica.
Pero lo importante es trabajar con la documentación requerida para mejorar su producto ... no intente aplicar ingeniería inversa a la documentación como una idea posterior porque no sirve para nada en el mundo real.
fuente