GTD en ABAP

>Aunque este artículo se centra en la programación ABAP, puede ser exportable a cualquier otro lenguaje de programación, con las modificaciones oportunas. Este artículo nace en respuesta a un correo ⚠ <b>Félix Gómez-Cardoso⚠ </b>, que me preguntaba cómo se puede ser más productivo en la programación ABAP y en la consultoría SAP. Yo me voy a centrar en la parte de programación.La programación no escapa de la productividad, igualmente sigue siendo un proceso altamente creativo cuando tienes cuatro pinceladas de lo que quieres hacer o un proceso mecánico si ya te dan el diseño técnico (DT) completamente hecho. Cualquier de los casos, la productividad está presente y para ello, utilizaremos el sistema GTD para hacer de nuestro trabajo, un proceso más sencillo. Recordemos: recopilar, procesar, organizar, hacer y revisar. Nada escapa de estos pasos.!!! Normalmente esto suele llegar por un agente externo, que a modo de correo, documento que cae a plomo sobre la mesa o servilleta con cuatro garabatos, de un diseño más o menos especificado de lo que hay que hacer. Si estamos en nuestro proyecto, el proceso de construcción del diseño técnico lo hacemos nosotros mismo y va directo a nuestra bandeja de entrada. Cuando llega este DT, siempre nos piden una fecha de finalización o nos la marcan, nunca hay que dar esa fecha, sólo prometer que lo metes en la bandeja de entrada y cuando llegue el momento de procesarlo, podrás indicar esa fecha. El agente externo se pondrá nervioso y seguirá preguntando. Ahí es donde hemos de coger valor y como disco rayado volver a decir lo ya dicho.
!!! Llega el momento de coger el DT. Lo primero es saber que es un proyecto y como tal no es accionable, simplemente irá a nuestra lista de proyectos, podemos delegarlo, sólo en el caso de que ya haya pasado por la etapa de organizar. Siguiente acción: organizar.
!!! Lo guardaremos en nuestra carpeta de referencia, apuntando en el proyecto dónde se encuentra.
Toca leerlo y “entenderlo”. Yo soy de esos programadores que no entiende la filosofía de los programas. Para mí, los programas que realizo y que no voy a utilizar son líneas de código que hay que picar, nada más. No me interesa acumular funcionalidades en mi mente, ni entenderlas sabiendo que en un corto/futuro a largo plazo no me van a servir. Así que no quiero entender los flujos de facturación, los procesos de contabilidad, las carreras de los candidatos, el ciclo del almacén, etc. Por lo que exijo que el DT esté lo suficientemente claro como para que lo entienda cualquier persona. La razón es sencilla, tal vez ese trabajo no lo acabe haciendo yo y tenga que delegarlo en otra persona que no tiene por que comprender todo lo que está en la mente del funcional.Entenderlo significa que todo esté claramente definido: ¿Es un programa? ¿Una función? ¿Un webproxy? ¿Una aplicación interactiva? ¿Una sencilla modificación? ¿Un listado? ¿Las pantallas tienen todos los campos con su código? ¿La relación de las tablas es coherente? ¿Hay referencias a antiguos programas? ¿Existe interacción con otros programas? ¿Dónde se va a programar? ¿Hay usuario y password de acceso? ¿Tengo acceso a esa máquina? ¿Tenemos un juego de datos ya preparado para realizar las pruebas de calidad y estrés?Hay que entenderlo no como un programador sumamente experimentado, si no como un junior que acaba de entrar a este mundo de la programación. Con este esfuerzo, con esta lectura, pulimos el DT y mejoras la documentación que muchas veces debe ser entregada al cliente. Esto genera muchas veces un efecto rebote , dónde la documentación debe regresar a quien nos la entregó para que realice los cambios oportunos con todo lo que hemos encontrado. En este momento se genera una delegación y el proyecto pasa de estar activo a en espera. El proceso vuelve a comenzar. Recordemos: recopilar, procesar, organizar, hacer y revisar.Una vez que el DT está completamente terminado y comprendemos todos sus recovecos, hay que dedicar un tiempo a visualizarlo, a ver cómo va a estar construido, esta etapa es la más creativa, podemos ver sus órganos, cuantas funciones necesitamos, que objetos tocaremos, si hay que crear cosas nuevas, como serán las comunicaciones, que tipo de rutinas podremos reutilizar. Lápiz en mano, vamos apuntando todo esto es una lista o un mapa mental. En él, reconoceremos al instante rutinas que ya tenemos en nuestro repositorio o que deberán pasar a él, reconoceremos recursividad, optimizaciones a accesos a tablas, flujos de control, gestión de mensajes, etc.Después de las palomitas, toca reunir al equipo. Juntamos todo lo necesario para iniciar al construcción, principalmente rutinas que ya tenemos guardadas en el repositorio, metemos accesos en el logon, creamos una carpeta específica, buscamos enlaces de referencia, todo lo que sea necesario para modificar.Antes de construir, si no hemos hecho el mapa mental de la aplicación, hay que dedicar unos instantes a realizar un gráfico del funcionamiento, el flujo que tendrá si no viene ya definido. Apuntando cada detalle que necesitemos en sus ramas, nos quitamos de la cabeza el ejercicio de visualización y lo dejamos plasmado, como material de referencia en un papel físico. Es en este momento cuando puedes dar una fecha de estimación real, de lo que vas a tardar en construirlo, a lo que debes sumar, todo el tiempo que has estado organizando y el que estarás, realizando pruebas de calidad y de estrés ;)Mucho de lo que he escrito en este apartado, podría ir perfectamente ubicado en la sección de hacer. Pero entiendo que hacer, es sólo el acto de creación o modificación, el resto es pura planificación y organización, que tiene que estar completamente separado.!!! Finalmente llega el momento de tirar líneas. Este es el momento dónde uno es productivo, tal como entiende la mayoría de gente. Centrado y dedicado exclusivamente a teclear. No hay que hacer el esfuerzo de pensar, sólo picar. Ya hemos pensado antes y no podemos encontrarnos ningún escollo en nuestro trabajo. Si dudamos, si tenemos que buscar, es que hemos fallado en las etapas anteriores, con lo que nos pararemos y tendremos que iniciar el ciclo. Esto hace que los programas se dilaten en el tiempo y que la gente pierda la confianza en nuestros plazos.Entramos en la zona y no queremos salir de ella, ¿a quién le importa si el mundo continúa girando?
!!! Poco que aportar aquí, si los pasos anteriores son correctos, en este punto sólo tendremos que realizar las tareas de seguimiento de la aplicación que hemos realizado. Una aplicación muere, cuando ha subido a productivo, hasta entonces, debe permanecer como una aplicación delegada, en espera de las pruebas y las subidas a los diferentes entornos. Aquí es cuando nacen las acciones de seguimiento, dando presión a quien nos lo ha dado, por saber si ya lo ha verificado, como le ha ido, etc.
Hay que revisar que igualmente hemos metido todo el material nuevo en nuestro repositorio, todas aquellas rutinas que hemos descubierto y que quedan reflejadas en el mapa mental o diagrama de flujo, ese material nos servirá para el futuro.Esto tan idílico pueda parecer que no sirve para el día a día, para los fuegos que existen en productivo, pero si no somos constante en lo que hacemos, si no nos disciplinados, sabremos que los programas volverán a nosotros con modificaciones, con errores, con falta de funcionalidad, por malas previsiones, por ir corriendo, por callar los gritos del cliente.Esto es GTD para ABAP o al menos para mí :) ¿y tú? ¿Ya GTDeas tu programación?
Publicado el 20100812