Busca

Login | Crate una cuenta | Bitcoras

Secciones portada amricas e-derechos ciencia debian empleo entrevistas espaa especiales eventos formacin libros ocio pregunta a /. softlibre Barrapunto Sobre /. Contactar FAQ Bitcoras Buscador Alertas Etiquetas Temas Editores Lo ms Rollos viejos Encuestas Enviar

Por qu registrarme? | Ayuda Login Barrapunto Apodo (nick)

Proyectos de informtica: Reacciona antes de estrellarte!

Entrada escrita por faragon y editada por mig21 el Lunes, 18 Julio de 2011, 07:30h desde el dept. autoayuda

El objetivo de este texto es intentar ser til a quienes se hayan topado con alguno de los siguientes problemas: el mantenimiento de lo existente en produccin se come el grueso del tiempo de desarrollo, cualquier cosa compleja o ambiciosa se torna en imposible, puesto que, por ejemplo, la capacidad del equipo equivale al 20% de lo que debera por no estar organizados adecuadamente, la situacin lleva aos estancada, y no se hace nada que pueda cambiar esto en lo sustancial. Siguen en la pgina ampliada los consejos para hacer autocrtica, identificar y prevenir los problemas y tratar de mejor el presente y el futuro. 1. Autocrtica y consciencia de la situacin. El "no hay recursos suficientes" no es excusa: Si produces el 20% que otros con igualdad de recursos, significa que no lo ests haciendo bien. El responsable eres t. No te escudes en la proyeccin psicolgica. 2. Identificar los recursos que dispones Identifica en qu eres competente y en qu no. S realista y honesto contigo mismo: No tapes tus complejos pretendiendo saberlo todo, pues cuando es obvio que no tienes ni idea de algo, genera desconfianza y malestar (por ser una falta de consideracin/respeto y un insulto a la inteligencia). Busca suplir tu incompetencia con la competencia de otros. Busca la excelencia: no actes por orgullo, miedos, o amiguismo. Conoce muy bien a las personas, si no sabes en profundidad cmo trabaja cada uno de los componentes de tu equipo, ests perdido: Para un ignorante dos programadores pueden ser iguales, pero en el mundo real uno puede hundirte la empresa y otro sacarte las castaas del fuego en una fraccin del tiempo. Identificar a quien perjudica ms que aporta, y consciencia de falsas ventajas comparativas: Si alguien tarda en programar algo 2 meses, y luego otro tiene que estar una semana corrigiendo, y este segundo habra hecho esa misma tarea en una semana o en menos, significa que la productividad de la primera persona es 0 -i.e. no hay posibilidad de ventaja comparativa cuando la productividad es menor o igual a 0-. Esto se puede arreglar asignando otras tareas o con "reciclaje" u "orientacin" (i.e. programa como X, y si no, no programas, punto). 3. Prevencin de problemas El proceso de desarrollo tiene que estar definido, ser sencillo, y que no se den "cortijos" (gente que no pide permiso ni sigue regla alguna). Usa gestores de versiones, planifica las releases. Si quieres tener el control sobre todo, has de tener el conocimiento sobre todo. Como eso es imposible, tienes que aprender a: delegar. Si no delegas, sers el rbitro universal, tendrs que resolverlo t todo, hasta para el conflicto ms ridculo, e incluso para cosas en las que no tienes ni idea (si hay alguien experto en X, delega en X las decisiones al respecto: recuerda que como responsable tendrs siempre capacidad de veto). Las obligaciones y responsabilidades han de estar claras. Las bicefalias/tricefalias/etc., junto con las responsabilidades que estn en el aire, producen conflictos y/o desautorizaciones a destiempo (i.e. si alguien es responsable de algo, ha de ser responsable "de verdad", pues si por miedo de delegar el tema se queda a medio gas, acaba siendo un cachondeo). Adecuar el talento y formacin a las tareas: Dejar hacer algo "grande" a un aprendiz o a alguien sin preparacin suficiente puede quebrar a una empresa, por el pifostio que puede montar. Salvo que sea algo experimental y no dependa de ello el negocio, pues es importante dar oportunidades a gente con potencial. Asigna lo complejo a quien tenga ms talento. Si por criterios arbitrarios asignas cosas a quien no puede con ellas o a quien lo podra hacer mejor, tendrs retrasos, problemas,

Contrasea
Login

Terminal pblico [ Crear nueva cuenta ] Enlaces relacionados Barrapunto Linux proyeccin psicolgica 1 programar bien es difcil, y que no se aprende en 21 das Jenkins usando generadores de "workspaces", es para alucinar en colores Iron Maiden - Wasted Years Ms sobre Programacin Ms sobre Pasta (Gansa) Ms sobre Especiales Ms sobre Index Tambin de mig21

converted by Web2PDFConvert.com

llegando a perder la salud o tener que cerrar la persiana. Si no hay bastante talento, bscalo, o simplifica el problema hasta que sea abarcable por lo que tengas. Hay que buscar hacer lo complicado sencillo: Si alguien hace complicado lo simple, ah tienes tu aprendiz, ni se te ocurra encargarle tareas de ms de 20 horas. El "cdigo malo" sale carsimo (slo interesa a crnicas y dems parsitos del mantenimiento eterno). Si en tu equipo tienes personas que generan, por el motivo que sea, "cdigo malo" (sean conscientes o no), tenlos identificados, y mucho ojo con lo que se le asigna. Si funciona, no lo toques. (i.e. si slo se trata de que no te gusta a ti) Si no funciona, analiza y evala antes de reescribir. Hay "reescrituras" que son peores que el/los original/es. El dejar de usar algo sin reemplazo, tambin es una opcin. Intenta evitar nueva funcionalidad a una base de cdigo malo: Aade lo nuevo en un contexto "sano", i.e. si tienes componentes defectuosos pero que "funcionan" y no puedes permitirte reprogramarlos, en lugar de aadirles funcionalidades nueva dentro, hazlo en otros componentes nuevos. Contabiliza en qu se te va el presupuesto. Esto, es, si reescribes una misma funcionalidad 20 veces, que conste cunto ha costado, y por qu se ha hecho ese gasto. No puede ser que tras 3 aos te des cuenta que has gastado 1500 horas (correcciones, pruebas, soporte tcnico) en correcciones a un componente que reescribirlo por completo no habra costado ms de 300 horas (desarrollo + pruebas). Tienes que saber dnde se va el tiempo, o el tiempo se escapar un sumidero. 4. Identificacin y gestin de los problemas en curso Partiendo de la base que lo que tenis en uso/produccin es "ms o menos usable/vendible", y que lo queris hacer sobre la marcha (1): Paso 1, localizacin y segmentacin de problemas: A) Dividir entre lo que afecta (A.1) y lo que no afecta (A.2) a la experiencia del usuario. B) Diferenciar lo que no funciona o funciona pero no es escalable (B.1; crashes y problemas que ocasionan "consumo" del personal de soporte tcnico, querys de 5 minutos, etc.), y lo que es horrible a nivel de cdigo "pero funciona bien como caja negra y no hace crash nunca" (B.2). C) Diferenciar lo que funciona pero supone gastos fijos (C.1; e.g. cosas sin automatizar que requieren procesos manuales como pueda ser el despliegue de contenido a N nodos remotos, el no usar gestores de versiones adecuados, no tener backups, etc.), de lo que no tiene coste dejndolo como est (C.2). Tras el primer paso, el problema se reduce a modificar: A.1, B.1, C.1 (si lo queris es vender un buen producto, reduciendo los fallos y el tiempo dedicado a mantenimiento). Paso 2: priorizacin Pasada de priorizacin #1 (sobre A.1,B.1,C.1): Elimina todo lo que veas en A.1, B.1, C.1 que puedas dejar de hacer, por no ser vital para el negocio, de A.1, ya sea simplificando procesos o hacindolo de otra manera (e.g. cambiar Intranet hecha "a mano" por un CMS, sin tunear a medida, algo austero pero que cumpla lo mnimo que necesitis). Tras la limpieza, quedara: A.1', B.1', C.1' Pasada de priorizacin #2 (sobre A.1, B.1): Juntad el 80% de los casos ms graves de A.1' y B.1', que se puedan resolver en el 30% del tiempo sin generar dependencias en los casos restantes (tuneado de la "Regla de Pareto" pero con un 80-30 en lugar del 80-20). Etiquetad esos casos como "AB.1-rpido", el resto, dividirlos entre "AB.1-fcil-pero-lento" y "AB.1-muydifcil" Pasada de priorizacin #3 (sobre C.1): Determinar los gastos fijos que suponen, separando en dos grupos: C.1-pinchazo (hasta el 5% de los costes fijos de la empresa, i.e. la empresa podra ir boyante, pero las chapuzas se comen los beneficios) y C.1-sangra (riesgo de cerrar la empresa). Paso 3, ejecucin: Pre-ejecucin: No asignar a nadie una tarea para la que no est capacitado (la buena voluntad no siempre es suficiente), la pueda hacer en un tiempo razonable, y el resultado sea de calidad. Si esas restricciones no son posibles, volved al paso 1, y simplificar ms todava las tareas hasta que las podis acometer (si es imposible, y depende del cierre de la empresa, pagad a uno o varios figuras un pastn -e.g. pasta por delante y adems, si en 3 aos le va bien a la empresa, te llevas un X como bonus-).
converted by Web2PDFConvert.com

Ataque #1: "C.1-sangra" Ataque #2: "AB.1-rpido" Ataque #3: "AB.1-fcil-pero-lento" Ataque #4: Volver al Paso 1, con slo "AB.1-muy-difcil" y "C.1-pinchazo" 5. Enfocar el presente y el futuro Suponiendo que ya conoces la situacin, eres consciente de tus capacidades y la de quienes estn a tu cargo, puedes prever/evitar problemas, y has reenfocado/solucionado los problemas del "pasado". Ahora qu? Cmo enfocar el camino? 5.1. Visualiza dnde ests y a dnde te diriges Si el desarrollo est estancado, y no cambias nada, dentro de dos aos, suponiendo que puedas mantener el negocio en funcionamiento, seguirs prcticamente igual. Estando en situacin de "detenimiento psicolgico", haciendo las cosas a remolque, anclado en el mantenimiento, es equivalente a estar parado: arrancar no ser fcil. En mi opinin, lo que ms sirve es tener una visin del camino a dnde quieres/puedes ir, e ir hacindolo ms o menos de acuerdo a un programa, susceptible de cambios por los requisitos que puedan llegar de fuera, etc. Si no tienes ni idea de a dnde quieres ir, ni por donde, ni con quien, lo tienes crudo. Si tienes un plan a largo plazo, an cuando este no sea el mejor del mundo, es infinitamente mejor que ir a la deriva, que te llevar a estrellarte tarde o temprano, pues los problemas no se solucionarn solos, sino que irn a peor. 5.2. Multiplica la capacidad de programacin En la industria del software, descontando la parte del espectculo, el hacerse la foto, vender la moto, y dems cuentos, lo que acostumbra a determinar la supervivencia del negocio es el resultado de trabajo enfocado en la parte de desarrollo. Si el desarrollo no funciona adecuadamente, el negocio malvivir de los xitos del pasado o cerrar en el largo plazo, salvo que no tenga competencia, claro est. La parte clave en el desarrollo es el programador, quien marca la diferencia. Por mucho que se haya pretendido, principalmente por parte de consultoras plagadas de gestores mediocres, el programador no es ninguna commodity, desde el momento que un programador excelente puede ser de 5 a 20 veces ms productivo que uno "normal" (y como normal no incluyo a los que son ms perros que un trillo, que como en todas las profesiones, haylos). Hay gente con ms y menos talento, ms y menos formacin, y si bien no puedes convertir a un burro en una eminencia, la mayora de la gente que programa tiene mucho potencial de mejora. Se me ocurren las siguientes claves de la "reprogramacin de programadores" (ejemplos, si alguien tiene ms, que lo comente): Clave 1: Producir cosas sencillas es menos costoso que cosas complejas. Ejemplo: Si alguien necesita 30 threads para algo trivial que se puede hacer con slo uno. Esto, por mi experiencia, puede suponer reducir el coste de implementacin y mantenimiento a la tercera parte. Tambin hay casos de software que no llega a funcionar bien nunca, pues aadir complejidad sobre algo complejo acaba llevando la situacin al esperpento. Clave 2: Evitar la "sobreingeniera". En el caso de software orientado a objetos, el montar un "pifostio" con 10 veces ms clases de las necesarias, slo para demostrar que alguien se ha ledo el libro de "patrones de diseo de turno" tiene un coste brutal. Para hacer mantenimiento implica una curva de aprendizaje importante, dificultando que las correcciones mantengan el "enfoque" original. Clave 3: Buscar de motu proprio la simplificacin de las cosas, como actitud. Hay que aprender a que identificar cosas innecesarias es muy productivo, pues hacer algo que no se necesita es tirar el tiempo/dinero. Clave 4: No se puede ahorrar en la estabilidad del software. Si algo est mal sincronizado, es un bug crtico y hay que corregirlo, punto. El sacar a produccin algo defectuoso puede ocasionar costes brutales de mantenimiento y soporte tcnico, sin contar la mala imagen que proyecta. Clave 5: Identificacin de las limitaciones. En el software, salvo casos excepcionales, los "todologos" (gente que "sabe" y discute de todo) son muy peligrosos. Una solucin objetivable e impepinable para este punto son los hechos: opinin tiene todo el mundo, pero opinin respaldada por hechos, no. Una vez se es consciente de las limitaciones, se puede aprender de quien realmente sabe, con humildad y sin aspavientos. Clave 6: Planificacin y supervisin de los desarrollos por parte de gente de ms talento/conocimientos/experiencia. El que sabe menos tiene que aprender del que sabe ms, con humildad y disciplina (i.e. que no sea "el coo de la ta Bernarda"). Si se ignora esto, jams se sale de la mediocridad. Por mi experiencia, los desarrollos sin supervisin adolecen siempre de un problema u otro: calidad, productividad (e.g. retrasos), falta de visin de conjunto que generarn costes a otros componentes en el futuro, etc. Clave 7: Seguimiento (subconjunto de la supervisin). No puede ser que para una proyecto estimado en 2 meses, lleguen los dos meses, y te enteres de que es un desastre. Esto, por mi experiencia, mejora notablemente con un anlisis de riesgos dentro de la planificacin (sea pblico o no), y acciones a tomar, e.g. comprobaciones en el 30%, 50% y 70% del desarrollo.
converted by Web2PDFConvert.com

Ya sea mediante gestin "tradicional" o tcnicas "agile" (centradas en un seguimiento exhaustivo y divisin de tareas al extremo, an cuando en estos casos tambin se hace fraude "a lo Enron"), si no hay seguimiento y gestin de impedimentos/imprevistos/contingencias, el tema no marchar. Clave 8: Consciencia de que programar bien es difcil, y que no se aprende en 21 das, y que hay gente que necesita 10 aos, otros 20, y otros no aprenden a programar bien nunca (si son conscientes, no es un problema, y conociendo sus limitaciones pueden llegar a grandes logros basados en mltiples elementos sencillos). Clave 9: Consciencia de que, aunque se pueda intentar dentro de lo posible, no siempre se pueden establecer reglas a gusto de todo el mundo, y que, por ejemplo, pueden tener sentido usar procesos que puedan ser antipticos para una parte de los desarrolladores (Windows / Linux / OSX dev wars) si supone reducir el coste de desarrollo de manera sustancial. Clave 10: No hay solucin mgica. Adems de buenos hbitos, talento, conocimientos, y experiencia, hay que trabajar duro. 5.3. Usa las mejores tcnicas y herramientas Obtn el mejor hardware disponible para programar, para todos los miembros del equipo. La productividad que se pierde por usar herramientas no adecuadas es brutal. Adems, con hardware adecuado, i.e. mucha CPU y RAM (e.g. 8-16GB de RAM y 4-8 cores), puedes tener mltiples entornos de desarrollo con diferentes sistemas operativos, etc. Usa un gestor de versiones que reduzca el tiempo de sincronizacin entre desarrolladores. Es estpido usar gestores de versiones poco flexibles o que te hagan tardar media hora para hacer un merge trivial. Planifica las releases. Ya sea por ramas, agrupacin de componentes, o lo que sea, pero que se adece a las capacidades y tenga en cuenta el coste y dependencias. Ten scripts que compilen el cdigo, para todas las plataformas soportadas (e.g. para llamar a todos los makefiles y/o proyectos de Visual Studio). Es inaceptable el no enterarse de que algo se ha roto. Si no lo conoces, chale un ojo a herramientas como Jenkins (antes llamado Hudson). Aade tests en cada desarrollo, an cuando no hagis TDD. Ya sea a nivel de clases, componentes, o lo que consideres oportuno para cada caso. No es un gasto, es inversin: Dedicar un 5-10% del tiempo de desarrollo a cobertura por tests (an cuando estos sean sencillos y no cubran todas las posibilidades), reducir de manera notable el coste de mantenimiento. Si desarrollas para mltiples plataformas, usa un mtodo sencillo (e.g. Makefiles si se ha de soportar un nmero limitado de entornos POSIX e.g. Linux y OSX, automake/autoconf para los casos de soportar el mximo nmero de sistemas POSIX, junto con ficheros de proyecto para Visual Studio). En mi opinin, por ejemplo, para proyectos multiplataforma de C y C++, el mantener proyectos para Eclipse/NetBeans/Xcode es un error, puesto que para muchos proyectos el mantenimiento de estos es brutal (an usando refritos como CMake, pues es un elemento de ruido ms: compatibilidad de versiones determinadas entre diferentes SOs, etc.) Si incluso usando el Make pelado de GNU hay problemas de compatibilidades, usando generadores de "workspaces", es para alucinar en colores, salvo que se traten de pocos proyectos y te lo puedas permitir.

Sintona de hoy: Iron Maiden - Wasted Years

IBM dona el cdigo de Symphony a la Apache Software Foundation | Cmo fomentar entre los universitarios la emprendedura?

Venda joyas de Silpada

Gana dinero extra y joyas gratis. Organiza una Fiesta Silpada hoy!
www.Silpada.com

converted by Web2PDFConvert.com

Historias relacionadas
Pregunta a /.: Como pagar la "deuda tcnica"? 77 comentarios
Proyectos de informtica: Reacciona antes de estrellarte! | Log in/Crear cuenta | Top | 22 comentarios | Buscar hilo

Umbral: 1: 12 comentarios

Hilos

Primero lo ms viejo

Cambiar

Comentar

Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

Gracias por los consejos pero... (Puntos:2)

por pringao (40703) el Sbado, 16 Julio de 2011, 15:12h (#1285010) ( http://noalprestamodepago.org/ | ltima bitcora: Domingo, 12 Junio de 2011, 22:29h )

En qu pas dices que es aplicable esto? :-) Salvando las diferencias, me recuerda un poco a las actividades de "coaching" que ltimamente se han puesto tan de moda. Todo es positivo, hermoso, maravilloso, solucionable... pero parece que los "coach" no han trabajado en una empresa espaola en su vida.
[ Responder ]

Re:Gracias por los consejos pero... de faragon (Puntos:1) Sbado, 16 Julio de 2011, 15:34h Re:Gracias por los consejos pero... de pringao (Puntos:2) Sbado, 16 Julio de 2011, 16:04h Re:Gracias por los consejos pero... de faragon (Puntos:1) Sbado, 16 Julio de 2011, 16:15h 1 respuesta por debajo de tu umbral de lectura actual. Muy buen texto (Puntos:1)
por sammael (16347) el Domingo, 17 Julio de 2011, 01:58h (#1285050) ( http://barrapunto.com/ | ltima bitcora: Viernes, 08 Abril de 2011, 12:00h )

Muchas gracias por escribirlo. Has pensado en ponerle un titulo estupido, rellenarlo de paja y venderselo a managers? Tu te harias de oro y quizas entonces nos dejen a los tecnicos hacer nuestro trabajo (aunque si no lo consiguio Fred Brooks con su mythical man-month, dudo que te hagan caso). --

Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
[ Responder ]

Re:Muy buen texto de faragon (Puntos:2) Domingo, 17 Julio de 2011, 07:03h dudas (Puntos:2)
por kkman (19047) el Domingo, 17 Julio de 2011, 08:26h (#1285061) ( ltima bitcora: Martes, 07 Diciembre de 2010, 18:45h )

Gracias por esta entrada. Mientras iba leyendo he ido identificando mentalmente cada parte con el caso real donde trabajo. En la metodologa para reducir la deuda tecnolgica que describes, indicas que hay que diferenciar en el punto B, lo que no funciona bien porque hace "crash" (B1), y lo que es horrible a nivel de cdigo aunque funciona bien como caja negra (B2)

La dudas que tengo son: duda 1) que se hace luego con las partes detectadas de B2? duda 2) y si se da el caso llammosle "B3": "que funciona bien pero no es una caja negra"?

Un ejemplo: tenemos un "monstruo" de aplicacin web que data del ao 2000 y que no ha evolucionado en cuanto a tecnologa. Es horrible a nivel de cdigo: - sin diseo Modelo Vista-Controlador. Toda la lgica de la aplicacin esta metida en las pginas jsp, que son gigantescas. Los jsps son un caos en los que va todo: desde la lgica con scriptlets, llamadas a la base de datos con sql, hasta cdigo java que en ultima instancia sirve para pintar los elementos en pantalla - utiliza libreras no estandar de las que no existe documentacin, por ejemplo: en lugar de usar jdbc, toda la aplicacin utiliza para el acceso a datos una librera que se coloca por encima del api jdbc. Tambien utiliza una especie de seudolibrera para la presentacin que hace la funcin de pintar elementos html. El no usar tecnologa estandar hace que los desarrolladores necesiten formacin extra de la que no disponemos. - No hay cdigo de pruebas

La aplicacin funciona "bien", pero adolece de una interfaz de usuario amigable. Adems es practicamente imposible meterle mano, por lo que cuando hay que corregir algo o cambian los requisitos, el monstruo crece otro poco. Mediante la refactorizacin se podra ir corrigiendo poco a poco, pero cuesta mucho menos hacer la aplicacin entera de nuevo. (Reflexin personal)... posiblemente el llamado "B3" en este caso es intratable. Habra que tratar la aplicacin entera como un "B2" y no
converted by Web2PDFConvert.com

tocarla. En nuestro caso lo nico que podra aprovecharse de la aplicacin es el modelo de datos. He pensado que una posiblidad sera plantear una arquitectura-infraestructura MVC con tecnologa estandar nueva (JPA, JSF, spring) partiendo de ingeniera inversa, integrarlo en paralelo con el cdigo existente y a partir de ese momento toda modificacin-correccin o nueva funcionalidad realizarla en el cdigo bueno.
[ Responder ]

Re:dudas de faragon (Puntos:1) Domingo, 17 Julio de 2011, 08:47h Re:Caso prctico (Puntos:3, Inspirado)
por polikuijyhdfg (13127) el Sbado, 16 Julio de 2011, 18:14h (#1285024) ( http://barrapunto.com/~polikuijyhdfg/bitacora | ltima bitcora: Sbado, 21 Mayo de 2011, 15:46h )

si se va de tu empresa os desharis de un trabajador que no aporta nada, no lo veo malo. si se cree menospreciado y no se da cuenta que es mediocre, debera de hacrselo mirar -PP PSOE - No les votes [nolesvotes.org]
[ Responder | Padre ]

Re:Caso prctico de faragon (Puntos:1) Sbado, 16 Julio de 2011, 21:02h Re:Caso prctico de pringao (Puntos:2) Domingo, 17 Julio de 2011, 12:38h 1 respuesta por debajo de tu umbral de lectura actual. Re:Caso prctico de faragon (Puntos:2) Sbado, 16 Julio de 2011, 21:25h 1 respuesta por debajo de tu umbral de lectura actual. 4 respuestas por debajo de tu umbral de lectura actual.
Multitarea, posibilidad de que dos bugs ocurran simultneamente. Busca

Buscador interno

Barrapunto 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5 Aviso legal

principal enviar historia rollos viejos encuestas faq editores

converted by Web2PDFConvert.com