Vi la posibilidad que traten de implementar scrum en el trabajo. Esto sería recomendable pero un poco estúpido.

Yo tuve Scrum funcionando en el área hasta que los cambios del corporativo (24 nov) dejaron fuera esa manera de trabajar. Curiosamente varias comunidades en línea y dos razones sociales que manejo usan la misma fecha pero este no es un evento relacionado.

Lo extraño del caso es que , como dije, Tanto SAEM como XFB y AGB ya estaban usando Scrum con su lista de labores del día, pendiente del día y demás. Todo en basde al procedimiento, sabiendo que era SCRUM pero sin decirlo. Funciona.

Hace unos años empezó este problema en varias consultorías que he visto. Personas que tienen idea de vocabulario, escupen metodologías y no implementan ninguna. En este caso, no solo están regresando al repositorio, sino que supongo se darán cuenta de que ya estaba implementado 5s y CMMI 2, además de los 12 pasos de Joel on Software (entre otras).

No me gusta decir se los dije, pero como se los dije, probablemente usen otra metodología y no Scrum.

Un resumen de Scrum tomado de :
===================================================
http://www.ingenierosoftware.com/equipos/scrum.php

estión de proyectos con SCRUM

Por Joaquin Gracia
4 de Septiembre de 2006

¿Qué es SCRUM? SCRUM es una forma de gestionar proyectos de software. No es una metodología de análisis, ni de diseño, como podría ser RUP, es una metodología de gestión del trabajo.

Una de las características más importantes es que es muy fácil de explicar y de entender, lo que ayuda mucho a su implantación.

Por otra parte SCRUM puede ser aplicado a distintos modelos de calidad (como podría ser CMMI) puesto que estos te dicen qué tienes que hacer, es decir, te dicen que tienes que gestionar el proyecto, pero no te dicen cómo. Ahí es donde entra SCRUM como modelo de gestión del proyecto.

Pero vamos a la materia, los siguientes son los elementos básicos de SCRUM.

Una lista con las funcionalidades de la aplicación ordenadas de mayor a menor importancia. Esta lista se llama «Product Backlog». No hace falta que esta lista contenga todas las funcionalidades inicialmente.

De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y son anotadas en una lista que se llama «Sprint Backlog». Estas tareas serán realizadas en el siguiente mes.

Además de estos elementos tenemos unas cuantas reglas básicas y sencillas que tenemos que cumplir.

Una vez que se pasan las tareas más prioritarias del «Product Backlog» al «Sprint Backlog», estas no se pueden cambiar, esto quiere decir, que el trabajo de un mes queda fijado. Esta es la regla más importante de todas.

Al final del mes, este periodo se le llama «Sprint», se tiene que tener un ejecutable con las funcionalidades del «Sprint Backlog».

Todo el mundo puede añadir funcionalidades al «Product Backlog», pero sólo una persona puede ordenarlo. A esta persona se le denomina «Product Owner». Es el responsable del producto final.

Cada día se hace una reunión de menos de 15 minutos, en la que se reúne todo el equipo: ingenieros y gestor (llamado «Scrum Master») en la que cada miembro del equipo expone sólo los siguientes temas:
¿Qué es lo que se hizo el día anterior?
¿Qué es lo que se va a hacer hoy?
¿Qué impedimentos tengo para realizar mi trabajo?
Sólo se tratan estos temas para que la reunión sea rápida y no malgastemos el tiempo de los demás. Si se tiene que tratar otro tema se hace otra reunión sólo con las personas implicadas. ¿Recordáis la serie de TV «Canción triste de Hill Street» en la que el sargento tenía una reunión matutina con sus agentes y que terminaba con un «Tengan cuidado ahí fuera»? pues viene a ser algo parecido.

Al final del mes, es decir, al final del Sprint, se presenta el producto y se toma del «Product Backlog» ordenado las funcionalidades para cubrir en el siguiente mes.
Básicamente esto es todo. Como podéis observar las reglas son sencillas y claras.

La duración del Sprint se puede modificar. Hay gente que prefiere Sprints más largos al comienzo, mes y medio o dos meses, ya que al principio cuesta más obtener un ejecutable y al final Sprints más cortos, una semana o dos, cuando se está en la fase final de refinamiento. Pero básicamente el proceso es el mismo de principio a fin.

Para gestionar el proyecto sólo necesitamos dos listas, el «Product Backlog» y el «Sprint Backlog». Podemos usar Excel para manejarlas.

Las 2 conexiones de Internet del trabajo están fallando. Ya se verificó que del servidor de dns al internet se cae la conexión. Mi propia PC me muestra una pérdida de 14%, lo que equiviale a que se caiga internet seis veces por minuto, y po lo mismo me cierre las comunicaciones via SSH y parte de las ftp.

En resumen: Será poco posible trabajar con esta latencia. No es problema de interferencia, así que será lo mismo que de costumbre. Es extraño que en unas oficinas como las anteriores el problema fuera al revés, que ni mi BAM ni celulares funcionaban. Aquí no he visto de celulares (no me gustan), pero tampoco he visto a nadie hablar por celular desde aqui recientemente.

Sea lo que sea, probar con BAM es casi obligatorio.

Uno de los problemas actuales del área de desarrollo de la empresa en que estoy por nómina, es el que los dos programadores jovenes no tienen idea de como usar una librería, ni de sus ventajas. Desde los ajustes de noviembre, uno de ellos se ha dedicado a la implementación y el otro a los formatos PDF, pero falta verificar las desviaciones al estándar.

La mayoría de los documentadores GPL y no GPL que he visto tienen el problema de ser «verbose», es decir, dan información inútil. Una vez en el año 2000, recuerdo que me quisieron dar en un lugar un archivo de 600 páginas generado con Data Architect de Sybase, y yo me NEGUE a recibirlo. Mi argumento fue simple: Generaste esa documentación con Data Architect, así que si me das la impresión del esquema entidad relación, Se entiende mucho mas rápido. El archivo que me das en este momento es inútil.

Mas adelante En otra empresa una persona que no era técnica (teóricamente si pero en realidad hacía powerpoints) me dio tres esquemas de datos para integrarlo a mi reporteador al mismo tiempo. Uno era powerpoint, otro excel y un tercero word… con estructura de campos diferentes.

En esa ocasión ya había avisado a mi superior inmediato, que si manejaba esquemas identidad relación. El asunto estuvo bastante ridículo, porque todo el mundo menos la powerpointera estuvo de acuerdo que debía ella darme un solo esquema, y preferentemente en un sistema entidad relación. Como dato al margem se acabó ignorando completamente su trabajo e hice un reporteador autoconfigurable.

La premisa básica de la documentación es:

La documentación se debe enfocar a quien va dirigida.

Necesitamos un reporte simple de dependencias, duplicados, contenido, porcentaje de documentación, duplicados e información relevante sobre código fuente para uso de los programadores y líderes de proyecto.

¿Cual es el problema en este momento?

Hay código que no sabemos de que depende, ni a que llama. Ya Tenemos especificaciones funcionales que hice yo, que documentan los límites, pero lo que necesitamos en este momento es un analizador de código que verifique por requires e includes que llama a qué , así como si hay funciones repetidas, etc.

¿De donde sale y Cual es la idea general?

En el año 95 hice un sistema de código Turbo Pascal que revisaba archivos *.pas y reemplazaba llamadas de Tp3 a Tp4, además de varias correcciones y quitar espacios sobrantes. Lo que busco es hacer algo similar, además de dar un reporte simple que me indique funciones documentadas, jerarquía de archivos, relevancia y analizador de archivos sobrantes.

¿Bajo que licencia?

GPL 2.0. Básicamente por que la versión GPL3 sigue en borrador y la gpl3 identifica de manera clara «Unless specifically stated, the Program has not been tested for use in safety critical systems.», lo cual causa bastantes quebradores de cabeza adicionales y subidas en fianzas para sistemas que deben cumplir con HIPAA, http://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act

Ayer noté una lentitud tremenda en el server original que acabo de mover dominios. Lo primero que noté fue un problema en el tamaño del log de messages. Tenía mas de 90 mil líneas en dos dias. Al abrirlo, noté intentos de dns poisoning .

Este es el código simple que hice para verificar incidencias de dns poisoning en el log de messages bajo var/log/

Requisitos: Primero alteré el nombre de messages a messages.txt
Proceso lógico y ampliaciones para estadística en pseudocódigo
inicia bucle fin archivo
esperado=»NO»;
$cadena=lee linea;
avisa que linea estoy leyendo
si encuentra dominio sube contador uno
si «view internal: received notify for zone» {suma contador propio; esperado=»SI»;}
si «view external: query (cache)» suma contador propio
si «sending notifies»
si «host pure-ftpd:»
si «host kernel: Firewall: *TCP_IN Blocked*»»
si «internal: loaded serial»
si esperado==»NO» {contadoresperado+1; mostrar cadena}
termina bucle

El código implementado me mostró problemas de 50% de incidencias en el messages.

Cofigo PHP:

http://alfonsoorozcoaguilar.com/codigo/dnspoisoning.txt

Ayer volvieron a implementar el repositorio de tareas que hice hace unos meses, porque no les quedó otro remedio. Soy previsor.

Ayer, antes de salir al boliche para lo que se había hablado en el corporativo, le comenté a Angel del problema que se veia en el panel de patcheo de las nuevas oficinas: No se ve numeración de nodos.

Hoy en la mañana, le comenté a uno de los socios y al «director» del corporativo la necesidad de poner extinguidores y hacer un programa de simulacros, de manera que idealmente cada semana tengamos un simulacro de ahogamiento, infarto, incendio y evacuación. Como baja las primas de seguro no es mala idea.

Diez minutos despues, se bautizó con sangre la oficina.

El mismo socio al que le comenté, se abrió la cabeza con material del panel de patcheo, lo malo es que el en el pasado fue voluntario de la cruz rojam, y por lo mismo nuestro «experto» en el tema.

Es cuestión de esperar a las medidas de seguridad de incendios.

Para los que no ubican que es un panel de patcheo:

http://esp.hyperlinesystems.com/catalog/patch-panels/

Había quedado de escribir ciertas cosas hoy, pero lo tendré que hacer mañana. En la oficina nueva del trabajo tenemos un internet lentísimo y no podré hacer las pruebas necesarias.

Noto dos o tres cosas, que comentaré después.

Ayer me autorizaron a que el sistema para documentar lo que han hecho SAEM y ABG, se maneje por GPL. Mañana doy los datos del proyecto de documentador de código PHP.

Consideraciones:

EL sistema en cuestión es la base de un sistema SAAS, el problema principal son los escenarios cambiantes.

Para que una solución de antipcopia en PHP funcione, debe considerar factores que estan fuera de nuestro control:

1 ) La pc virtual debe tener salida a internet con latencia normal.
2 ) Por lo general los clientes usan configuraciones inseguras.
3 ) Si el cliente tiene el software instalado, deberia tener lso datos en su servidor pero este no es el caso. Parte de NUESTROS servicios son alojar sus datos. En la practica las soluciones simples son:

1 ) EN SAAS solo tener la instalación de nuestro servidor operativo.
2 ) Usar un hardcoded los datos del calificador.
3 ) En lo posible usar encoders para las licencias y archivos importantes
4 ) Hacer soluciones simples con factor de supervivencia.
5 ) Si usamos soluciones del cliente, hostearlo en nuestro propio server. Un server es tan bueno como su admin, y la mayoría de clientes o no tienen admin de servers o estan perdidos en el espacio.

El principal problema que veo en toda este ejemplo, es el escenario. En la práctica la licencia podría derivar de un numero de serie / macaddress, y en la practica no muchos clientes tienen pc virtuales.

Es posible el modelo actual, y es sostenible. Sin embargo, mi sugerencia sería POR RENDIMIENTO tener tanto la palabra viva, como las pc virtuales bloqueadas, en el calificador. Es mucho mas rapido leer:

function palabraviva($numcliente){
if ($numcliente==1) return «silla»;
if ($numcliente==2) return «mesa»;
if ($numcliente==3) return «cuaderno»;
} // palabra viva

A la larga, el problema final es la tendencia de las empresas a matar moscas a cañonazos.

En un caso de seguridad mayor, como el exigido en lo relacionado con la vida humana (software para hospitales), pondría incluso una funcion que enviara correo al administrador por calificadores erroneos. En el caso de un sistema de alto rendimiento, quizá haría un cachè en variables de sesión.

Es un principio, y funcional.

AHora nos encontramos con los problemas del calificador. El calificador es el archivo que estará en el servidor, y que es llamado por el validador del ejempl oanterior, en la dirección https. Este archivo debe ir en el servidor.

Basicamente podemos complicar la cosa creando una tabla de PC virtuales. En este ejemplo banneo las virtuales 80 y 666, se supone que no son muchas las que se van a bannear y automatizar el proceso sería confuso para los fines de ejemplo.

Los mensajes de error no corresponden a una descripción detallada, para que un «cracker» de código no sepa que le salió mal. Sin embargo el hecho que las maquinas virtuales usen redes locales, impide usar una ip anti proxyes como la función que puse.

http://www.alfonsoorozcoaguilar.com/codigo/calificador.txt

Lo siguiente es el Solicitador de Licencia.

Este archivo debe ir en la pc cliente.

Idealmente el archivo deberia ir encriptado.

Estamos obligados a pasar por parametro la direccion ip del cliente porque quizá esta en un proxy o een una red local tipo
192.*
127.*
10.*

Asi que el antiproxie no funciona si validamos de manera compleja.

http://alfonsoorozcoaguilar.com/codigo/validadorcliente.txt

Añado un ejemplo de licencia a la que altere para no dar datos validos propios:
http://alfonsoorozcoaguilar.com/codigo/Licencia_11_17.txt

El proceso de validación del password necesita varias etapas. Por simplicidad los manejaré en estos blogs como archivo aparte. La parte generador de licencia necesita usar headers, asi que se complica el ponerlo dentro de un script mayor. Por eso, lo pongo en archivo aparte, por simplicidad en la explicación.

Entonces, necesitamos tres archivos:

1 ) Generador de licencia, que genera el .php verificando primero enlazandose a la tabla de datos de clientes y que estemos conectados a un script global. Actualiza la palabra viva en servidor.

2 ) Solicitador de Licencia , que irá en la PC virtual. Si la ip no cuadra, o el resultado es diferente, impide el acceso al aplicativo.

3 ) Calificador de Licencia. Archivo que va en el servidor, y que idealmente debe guardar ip fecha y hora de quien solicita la validación. Por simplicidad no guardo bitácora en el ejemplo.

Requisitos entonces:

1 ) Tanto PC Virtual como servidor, deben tener habilitado curl
2 ) Preferentemente el servidor debe tener HTTPS para reducir riesgo de DNS poisoning
3 ) Enlace con internet de parte del cliente, para validar que el sistema tenga palabra viva.

Se asume por obvio:
1 ) Debe adaptarse el script para enlace a base de datos.
2 ) La variable de sesion variable, en el generador debe ser valids en el proyecto general. Si se omite no hay problema pero es inseguro.
3 ) Debe modificarse la tabla de clientes para añadir un campo llamado Palabra Viva
4 ) Debe definirse en PC virtual el numero de maquina virtual por un define
5 ) Debe llamarse al validador desde el aplicativo de la pc virtual.
6 ) Los paths absolutos deben modificarse. El dominio example.com es un ejemplo.
7 ) El archivo debe tener extension php-
==============================================
Al terminar la serie comentaré las posibles mejoras que pueden hacerse.

Puedes descargar aqui el generador de licencia.
http://www.alfonsoorozcoaguilar.com/codigo/generador.txt