Zeety lineamientos de trabajo

Grupo de Investigación y Desarrollo de
Tecnologías de la Información
Lineamientos de Trabajo

SISTEMA INTEGRADO DE GESTIÓN ID: Ver:
1.0.0.0
Lineamientos Generales de Trabajo Pág 2 de 15
Historial de Cambios
Versión Fecha Descripción cambios Responsable(s)
1.0.0.0 Contenido Coronado, P.
Tabla: Cuadro historial de versiones
Zeety S.A.S
Grupo de Investigación y Desarrollo de Tecnologías de la Información

1.0.0.0
Introducción

Ya son varias décadas desarrollando software. Aunque siempre es una tarea gratificante en lo personal, no
todas las veces se logran los objetivos de los proyectos con éxito. Cronogramas que no se cumplen, fallos
excesivos, requerimientos mal definidos, usuarios no involucrados, entre muchas otras cosas hacen que un
paraíso se convierta en un infierno.
¿Cómo evitar eso?. La respuesta es muy simple: Apeguese a los lineamientos definidos en El Libro Azul
del Modelo de Desarrollo de Software. En este documento se acumula el ser, el saber, el saber hacer y el
no saber hacer de las personas y equipos de trabajo que a lo largo de la historia de la organización han
contribuido al desarrollo de OpenKyOS.
Se pretende tener una lectura amena, a modo de cartilla de normas, recomendaciones y buenas prácticas,
sin profundizar en los detalles para que se pueda convertir en una “referencia de bolsillo”. Son consejos
de múltiples fuentes que a través de estos años nos han demostrado, tanto por las buenas como por las
malas, que en el mundo del software afortunadamente aún se mezclan el arte, la técnica, la ingeniería y la
ciencia produciendo una verdadera revolución basada en la información.
Zeety S.A.S

1.0.0.0
Capítulo
1
En los
procesos de
desarrollo
“Conclusión: El sistema presenta un
comportamiento bastante extraño.”
Cesar Varón
“Se concederá autorización para un
proyecto, únicamente cuando ninguno
de los que lo autorizan pueda ser
culpado si el proyecto fracasa, pero
todos se lo puedan atribuir si resulta un
éxito. “
Regla de Roger
Zeety S.A.S

1.0.0.0
El repositorio es su amigo
Con un repositorio de software se tienen varias ventajas: control de versiones, copias de respaldo,
sincronización de equipos de trabajo, facilidad al desplegar en diferentes ambientes, capacidad de retornar
a estados estables. Para un desarrollador moderno es imprescindible gestionar su código fuente a través de
esta herramienta. Particularmente se recomienda el uso de Git.
Escuchar a los interesados
Y para poder escucharlos tiene que tenerlos claramente identificados. Algunos podrán tener interés en que
el proyecto culmine con éxito, otros quizás no. Un proyecto saludable siempre estará guiado por los
requerimientos de los interesados. Se recomienda desarrollar un adecuado modelo de gestión de
requerimientos basado en casos de uso.
Hacer lo que requieren los interesados
Involucre en todo momento a los interesados. Ellos deben estar atentos a cualquier avance en el sistema
para que puedan retroalimentar rápidamente. El objetivo primordial es que el software satisfaga al usuario
final no que dicho usuario acepte nuestro software.
No mezclar lenguajes en un mismo archivo
Mezclar lenguaje de programación con lenguaje de etiquetado hace que el código sea difícil de entender y
mantener. Sáquele provecho al uso de plantillas.
La arquitectura es su amiga
El código fuente es el rey, la arquitectura es el reino. Debe documentarse claramente tanto la estructura
como la funcionalidad del sistema, así como las decisiones que guían su evolución. Un modelo básico de
representación es el modelo 4+1 al cual se le pueden agregar otras vistas. El conocimiento de la
arquitectura puede ser documentado utilizando diagramas UML.
Respetar los ambientes de desarrollo, pruebas y producción
La separación de ambientes obliga a la revisión cooperativa del producto, reduce la propagación de
errores y fomenta un desarrollo planificado. No deje que los afanes de la salida rápida a producción sean
una excusa para evitar el paso del aplicativo por todos los ambientes y la ejecución de pruebas de calidad
serias. Se recomienda que se tenga como mínimo un modelo de 3 niveles - desarrollo, pruebas,
Zeety S.A.S

1.0.0.0
producción; y en la medida de lo posible propender por un modelo de 4 niveles - desarrollo, pruebas,
aceptación, producción.
No tocar el ambiente de producción
El ambiente de producción solo debe ser accedido por personal autorizado para realizar las
sincronizaciones de código que agregan funcionalidad o corrigen errores y que han surtido todo el proceso
de desarrollo, pruebas, verificación de calidad y solicitud de paso de componentes. Bajo ninguna
circunstancia un programador debe tener credenciales de acceso al ambiente de producción en ninguna
capa (p.e. persistencia, lógica, de presentación)
Todo debe gestionarse como un proyecto
El software no debe crecer de manera anárquica ni furtiva. Todo desarrollo debe ser gestionado como un
proyecto y todas a las actividades deben ser de conocimiento del equipo de trabajo. No obstante, los
procesos de gestión deben ser adaptados de acuerdo a la naturaleza del proyecto teniendo como base el
proceso de desarrollo definido.
Reutilizar código y utilizar bibliotecas
El objetivo es entregar un producto de calidad de manera eficiente. Se debe desarrollar pensando que el
componente pueda ser reutilizado en múltiples proyectos. Como parte de la fase de inicio es necesario
verificar las capacidades de reutilización y uso de bibliotecas que ofrezca el proyecto.
Generar el perfil del código pero evite optimización
prematura
El perfilado es necesario para garantizar una óptima utilización de recursos, evitar cuellos de botella,
reducir la complejidad del programa y buscar puntos de mejora. Esto debe hacerse sin olvidar la premisa
de “evitar optimización prematura”.
Verificar la calidad del código
Sin importar el grado de experticia, se debe verificar de manera automática ciertos atributos de calidad del
código fuente. Aspectos como complejidad, duplicidad, reglas de codificación, entre otros; deben ser
analizados por parte del programador antes de solicitar el paso a otros ambientes. En particular se
recomienda el uso de herramientas tales como SonarQube o RISP.
Zeety S.A.S

1.0.0.0
Escribir código simple, fácil de entender
No se escribe código para uno, se escribe para los demás. Escriba el código como le gustaría encontrarlo,
si usted es demasiado informal entonces escriba código considerando que el que lo va a mantener es un
sicópata que sabe la dirección de su casa.

Zeety S.A.S

1.0.0.0
Capítulo
2
En el soporte
a Usuario
“El cliente siempre tiene la razón .”

Zeety S.A.S

1.0.0.0
Escuchar atentamente al usuario
Se debe escuchar detenidamente al usuario para que pueda expresar la causa raíz del problema y pueda
describir el contexto en el que se presentó el error. No se debe intentar cortar el reporte pues se podría
estar perdiendo la oportunidad de recabar información valiosa para la resolución del problema.
No discuta con el usuario
Cuando un usuario llama al Centro de Servicios es porque tiene un problema. Usualmente ese problema le
está afectando el buen desempeño laboral y por ende tendrá estrés.
Sistematice las experiencias
Todo problema debe ser gestionado para garantizar que se responden las preguntas: ¿qué pasó?, ¿cuándo
paso?, ¿dónde pasó?, ¿por qué pasó?, ¿cómo se solucionó?,¿qué afectó?. Con esto se logra crear una base
de conocimiento que permitirá mejorar la gestión de problemas e incidentes.
Utilice formatos de atención por categorías
Una vez el usuario haya descrito la situación es necesario que se tengan preguntas específicas que puedan
dar más luces sobre el problema. Se debe crear cuestionarios predefinidos para cada categoría de
problema.
Fomente múltiples canales de comunicación
La atención asíncrona es una buena estrategia para que los usuarios puedan describir con mayor detalle
los problemas. En lugar de estar repitiendo una y otra vez un discurso por teléfono, se debe tener
plantillas de asistencia en la solución e identificación de problemas. Con esto se logra descongestionar las
líneas telefónicas y se garantiza una mayor calidad en la recepción de casos.
Haga seguimiento exhaustivo a cada caso
Todo requerimiento debe ser seguido hasta su completa resolución. La responsabilidad de resolución no
se transfiere, se comparte.
Realice visitas in situ
Se debe realizar visitas periódicas a los usuarios para levantar reportes de fallos.
Zeety S.A.S

1.0.0.0
Capítulo
3
En las
reuniones
“Cualquier problema sencillo se puede
convertir en irresoluble si se celebran
suficientes reuniones para discutirlo.”
Ley de Mitchell

Zeety S.A.S

1.0.0.0
Determine el tipo de reunión
Antes de convocar o asistir a una reunión defina claramente el objetivo que se quiere lograr. Una reunión
sin un objetivo claro no tiene razón de ser.
Haga lo que se requiere según el tipo de reunión
Evite realizar actividades que no estén relacionadas con lograr el objetivo de la reunión. Si no puede
dedicar el 100% de atención expréselo con anterioridad y no asista.
No repita, complemente
En una reunión de trabajo no es necesario que todos demuestren estar de acuerdo con una posición. Las
posiciones contradictorias o complementarias son mucho más enriquecedoras.
Todos son importantes, inicie a tiempo con los que estén
El respeto hacia el tiempo de los demás es tan importante como el respeto hacia el propio tiempo. A
menos que se tenga que tomar decisiones trascendentales, inicie con el personal que se encuentra en la
sala. Si falta personal clave aún puede iniciar definiendo estrategias para minimizar el impacto de lo que
está ocurriendo.
Grabe la reunión
En la actualidad los mecanismos multimediales deben ser explotados al máximo. Hay que grabar todo de
tal manera que se fomente la transparencia en el accionar.
El acta de compromiso es su amiga
Complementario a la grabación, es necesario tener un documento en donde se exprese claramente y sin
ambigüedades los compromisos, indicando productos concretos, fechas de entrega (parciales y finales) y
responsables.
Una hora es suficiente
Una reunión no es una jornada de trabajo. Debe tener una agenda que no supere los 60 minutos y los
asistentes deben tener intervenciones que no superen los 3 minutos. En ocasiones se pueden programar
varias reuniones del mismo tema en el mismo día, asegurándose que exista al menos una diferencia de
una hora entre las mismas. Esto permite que los argumentos se concreten y las ideas maduren al menos un
poco.
Zeety S.A.S

1.0.0.0
Capítulo
4
En la gestión de
infraestructura
“Multiplique las especificaciones de
rendimiento por 0,5 respecto a lo que
dice el fabricante y por 0,25 respecto a lo
que dice el vendedor” Ley de Elcaro

Zeety S.A.S

1.0.0.0
Tenga un Plan de Contingencia
Se debe saber claramente qué hacer cuando exista un problema de no disponibilidad de algún elemento de
la infraestructura. Ese plan debe ser conocido por toda el área y ser revisado regularmente.
Haga copias de respaldo constantemente
Tenga un Plan de Copia de Respaldos. Los bancos de datos deben ser respaldados con una regularidad
que permita su recuperación óptima, con la menor pérdida de datos transaccionales.
Desarrolle un Plan de Recuperación de Desastres
Los problemas que comprometen el funcionamiento de la infraestructura pueden ser catastróficos. Se
debe diseñar, proponer, implementar, probar y mejorar un Plan de Recuperación de Desastres que permita
el rápido retorno de la operación.
Tenga un inventario de repuestos
Conozca en los boletines del fabricante o los usuarios, las fallas más comunes de los elementos que hacen
parte de la infraestructura y tenga los repuestos adecuados para subsanar posibles fallos.
Haga seguimiento automático a la infraestructura
Utilice herramientas automatizadas (escáner, agentes) para verificar el estado de la infraestructura. El
trabajo manual es lento, consumidor de tiempo e inocuo frente a los problemas.
Reduzca las vulnerabilidades
Conozca, analice y reduzca las vulnerabilidades de la infraestructura. Verifique constantemente el estado
frente a los problemas más conocidos que se encuentran registrados en las bases de datos públicas
Crea que lo están atacando
Siempre debe estar a la defensiva. Los ataques a la infraestructura son indiscriminados y pueden ocurrir
en cualquier momento, ya sea por causa incidental o deliberada. Se debe tener un Plan de Gestión de
Incidentes de Seguridad.
Zeety S.A.S

1.0.0.0
Licencia
Grupo de Investigación y Desarrollo de
Tecnologías de la Información
Los contenidos originales de Zeety S.A.S en esta obra, se distribuyen bajo una Licencia Creative
Commons Atribución-Compartir Igual 3.0 Unported.
Atribución – Compartir igual.
De conformidad a esta licencia:
Usted es libre para:
● Compartir — copiar y redistribuir el material en cualquier medio o formato
● Adaptar — remezclar, transformar y crear a partir del material
Para cualquier propósito, incluso comercialmente
Bajo los siguientes términos:
● Atribución — Usted debe darle crédito a esta obra de manera adecuada: si se
suministran, usted debe dar el nombre del creador y de las partes atribuidas, un aviso de
derechos de autor, una nota de licencia, un aviso legal, y un enlace al material; e
indicando si se han realizado cambios. Puede hacerlo en cualquier forma razonable,
pero no de forma tal que sugiera que usted o su uso tienen el apoyo del licenciante
● Compartir igual — Si usted mezcla, transforma o crea nuevo material a partir de esta
obra, usted podrá distribuir su contribución siempre que utilice la misma licencia que la
obra original..
Las marcas, nombres de productos y empresas, logos, figuras, citas, contenidos no originales de
Zeety S.A.S y otras referencias; son propiedad de sus respectivos dueños y no están cubiertos
por esta licencia.
Zeety S.A.S

1.0.0.0
Zeety S.A.S

Zeety lineamientos de trabajo

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Similar a Zeety lineamientos de trabajo

Similar a Zeety lineamientos de trabajo (20)

Más de grupozeety

Más de grupozeety (20)

Último

Último (6)

Zeety lineamientos de trabajo