¡Consultor en una empresa que no entiende la tecnología! [cerrado]

Obtuve el trabajo como Consultor en una empresa que tiene otros 3 programadores. Mi trabajo es reescribir todo el sistema antiguo en Java, Spring, etc., pero los programadores del personal solo conocen perl y el gerente no conoce ninguna programación.

Estoy tratando de hacerles entender que tengo 6 proyectos para reescribir aquí, pero nadie tiene documentos de diseño o especificaciones. los programadores del personal nunca tuvieron que escribir ningún documento. Además, no puedo hacer que el gerente comprenda las nuevas cosas de Java Tech. Él sigue pidiendo a algunos miembros del personal opiniones sobre las cosas, pero el personal no lo sabe ni lo entiende.

¿A dónde voy desde aquí para que el gerente entienda que los programadores del personal o alguien tiene que escribir un documento de diseño para que yo sepa qué construir? o si tengo que escribir los documentos, ¿cómo obtengo la información?

Parece un poco extraño que el personal no conozca la plataforma en la que le han pedido que vuelva a escribir su trabajo. ¿Qué sucede después de que se va? ¿Quién apoyará tu trabajo?

Entonces, tiene un sistema complejo que no tiene la documentación adecuada, y debe volver a crear el sistema en una plataforma diferente. Lo que haría, en su posición, es identificar a la persona soltera que debe "cerrar sesión" en el nuevo sistema. A partir de ahí, lea un poco sobre Historias de usuarios para identificar cómo dividir los requisitos en fragmentos de tamaño de bits que se pueden describir en inglés simple. Su formato es algo así como "Como USUARIO, en el SISTEMA X, quiero CUMPLIR LA ACCIÓN para que SE META EL OBJETIVO.

Para explicar más detalladamente una Historia de usuario, agregue 'criterios de éxito' en el formato de "Dado cuando CONDICIÓN y luego RESULTADO" para explicar lo que sucede con diferentes acciones dentro de la Historia de usuario principal. Esta es una forma decente de dividir la funcionalidad en piezas que se pueden entender individualmente, y puede obtener ayuda para escribir diferentes historias de diferentes grupos (solo asegúrese de que la persona de nivel superior que firma el trabajo permanezca igual).

Entonces, vuelva a escribir todas las funcionalidades antiguas del sistema como Historias de usuarios, luego pregúntele al propietario del proyecto si hay alguna funcionalidad NUEVA que deseen en la versión Java. Agregue historias para satisfacer eso, si hay alguna, y luego comience a codificar.

Básicamente, debe poder exponer la inutilidad de los programadores del personal. Haga que el propietario del proyecto requiera que le proporcionen los Criterios de éxito para algunas de las Historias, de modo que si le brindan comentarios insatisfactorios, puede simplemente mantenerlo como sus requisitos oficiales. Cualquier cosa que dejen fuera será su culpa, no la tuya.

He estado involucrado en un proyecto donde todo el sistema fue escrito en Oracle Forms, pero sin ninguna documentación. La tecnología podría haber sido fácilmente Perl. Aquí está el plan de ataque para migrar el sistema a Oracle ADF (pero también podría ser fácilmente cualquier otra plataforma):

1. Cree un conjunto de categorías de código para requisitos empresariales (funcional, errores, validación, interfaz de usuario, etc.).
2. Cree un conjunto de categorías para las pantallas (agrúpelas por una funcionalidad similar).
3. Cree una lista de todas las pantallas para toda la aplicación y enumérelas en una hoja de cálculo.
4. Asigne a cada pantalla una categoría de código y un tipo de código (p. Ej., Regla comercial, requisito del sistema, técnico).
5. Realice ingeniería inversa del código para extraer los requisitos comerciales, elaborando una descripción de una oración de cada requisito.

En este punto, habrá documentado las reglas de negocio para la aplicación. Esto solo será oro para cualquiera que tenga que mantener el sistema. Además, le dará la oportunidad de ver qué partes del sistema se han duplicado. (En mi caso, descubrimos que más del 60% de la base del código estaba duplicada).

Desde aquí, puede ordenar los requisitos comerciales con la administración. Esto podría implicar la elaboración de historias de usuarios, por ejemplo. Esto también revelará una funcionalidad duplicada de alto nivel y presentará oportunidades para simplificar y mejorar el sistema durante la migración. He incluido una captura de pantalla de la hoja de cálculo para mostrar una forma de seguir y documentar los requisitos.

Es posible que tengas que repasar tu Perl. ;-)

Una vez que haya realizado la ingeniería inversa del proyecto, puede emplear un conjunto de herramientas para ayudarlo con el ciclo de vida del desarrollo de software. (Estamos utilizando JIRA , pero hay muchas otras suites de software que funcionarían). Es posible que tenga que luchar, pero una vez que haya reducido los requisitos, querrá pasar a los siguientes entornos:

• Cree un entorno de documentación (por ejemplo, un wiki).
• Crear un entorno de desarrollo (DEV). Servidores web, servidores de bases de datos, repositorio de origen, etc.
• Cree un entorno de prueba (TEST) que refleje el desarrollo.
• Cree un entorno de preproducción (PREPROD) que refleje exactamente la producción y pueda actuar como una conmutación por error para el sistema de producción.
• Crear un entorno de producción (PROD).

Piense en usar un servicio orientado a la comunidad para abordar el requisito de la documentación del usuario final. Un excelente paquete de software similar a la suite StackExchange es OSQA . Deje que los usuarios creen el sistema de ayuda (es una estrategia bastante inteligente).

El SDLC se convierte en:

1. Los desarrolladores realizan y prueban cambios en la aplicación en DEV (usando un repositorio ).
2. Las herramientas del sistema implementan automáticamente compilaciones regulares en TEST.
3. Una vez que los evaluadores están satisfechos con la aplicación, la aplicación se implementa en PREPROD. Esto permite que también se pruebe el proceso de implementación. Se realizan más pruebas en PREPROD.
4. Una vez que los evaluadores están satisfechos con PREPROD, la aplicación finalmente se incluye en PROD.

Considero que este es un enfoque altamente organizado que funciona bien con diferentes metodologías de desarrollo. La primera pasada, que he descrito aquí, debe considerarse como una "pincelada amplia": en este punto, no debe ser demasiado detallado (empantanado) con minucias técnicas. (Los requisitos de la interfaz de usuario, por ejemplo, son capturados por cada pantalla. Mientras tenga las pantallas enumeradas, no necesita iterar cada campo de entrada individual, solo enlace a una captura de pantalla o URL de trabajo).

Por último, para revisar el código fuente, generamos automáticamente una serie de páginas web (una página web por "pantalla" funcional). Esto funcionó bien porque el código PL / SQL podría dividirse en archivos separados y convertirse automáticamente a HTML con resaltado de sintaxis. Con Perl, esto podría no funcionar tan bien para usted. La idea, sin embargo, es que puede crear enlaces de anclaje dentro de la hoja de cálculo que apunten a la sección de código que impone el requisito comercial. (Por otro lado, esto también permitiría que varios desarrolladores realicen ingeniería inversa de los requisitos del sistema en paralelo porque cada desarrollador puede abordar diferentes pantallas simultáneamente).

Un fragmento de código fuente de ejemplo (el + es un enlace de anclaje):

Podría recomendar contratar a un par de gurús de Perl para ayudar con la tarea de análisis.

No creo que sea muy productivo señalar que otras personas están haciendo un "trabajo horrible"; más bien, debería buscar mejorar el producto y dar a las personas la oportunidad de ayudar con este objetivo (y tal vez aprender cómo mejorar sus habilidades en el proceso). Es decir, no sabes lo que saben los otros desarrolladores, ni estabas allí cuando desarrollaron el sistema. Este enfoque hace que todo el proceso sea abierto y altamente visible a través del cual todos puedan contribuir.

Honestamente, los gerentes verán por sí mismos quién es realmente útil y quién quiere mejorar.

No tienen documentación y su código es tan pobre que han contratado a otra persona para que lo reescriba en otro idioma. Comience a reunir los requisitos de la fuente. Encontrará que muchas de las características y funcionalidades ya no se usan o pueden no funcionar correctamente. Es igualmente importante saber qué no construir.

Una vez que haya encontrado lo que los usuarios necesitan, determine qué ya está en la aplicación actual y qué debe construirse desde cero. Las piezas existentes es donde puedes mirar el código y hablar con los desarrolladores.

Cualquiera que proclame que necesita todo nunca se ha molestado en comprobarlo. Existe un argumento para no volver a escribir una aplicación, pero eso supone que todo funciona de la manera que los usuarios lo desean y eso no siempre es cierto. Lo usan porque no hay alternativa. Dales una mejor alternativa.

Comenzaría hablando con su gerente y aceptando la responsabilidad de recopilar los requisitos y definir las especificaciones. Deberá convencerlo de la necesidad de estos documentos y de lo que proporcionarán. Probablemente encontraría un ejemplo en línea. Luego, usted se encarga de ensamblar los requisitos y las especificaciones del sistema. Luego, vuelva a reunirse con su gerente para repasar el documento. Una vez que les haya mostrado el primer documento, es posible que pueda obtener ayuda para crear los otros 5. De lo contrario, si es efectivo, probablemente también será responsable de reunir esos requisitos, pero al menos alguien lo hará.