sábado, 31 de agosto de 2013

Curso HTML desde 0. Capitulo 5



El capitulo de hoy tratará sobre los iframes.

Los iframes son la manera de introducir información de otra página web en la nuestra. iframes es usado por páginas como youtube (para reproducir los videos) o amazon (para distribuir la publicidad), solo por poner dos ejemplos simples de ver.

La sintaxis es la típica de <iframe></iframe> y sus principales parámetros son:
- src : url de donde sacaremos el contenido
- width y heigt: el número de pixeles o el porcentaje de la pantalla que ocupará el iframe
- align: alineacion
- scrolling: si se puede hacer scroll del iframe o no

Hay más parámetros pero con estos ya podréis empezar a trabajar.

Vamos con un ejemplo:

El código sería este:
<HTML>
<HEAD>
<TITLE> Curso de HTML desde 0. Capitulo 5 </TITLE>
</HEAD>

<BODY>
<iframe width="49%"  height="50%" src="http://lordpakus.blogspot.com.es/p/curso-de-html-desde-cero.html" ></iframe>
<iframe width="49%"  height="50%" src="http://lordpakus.blogspot.com.es/p/metodologias-agiles.html" ></iframe>
</br>
<iframe width="49%"  height="50%" src="http://lordpakus.blogspot.com.es/p/gurus-de-la-programacion.html"></iframe>
<iframe width="49%"  height="50%" src="http://lordpakus.blogspot.com.es/p/algoritmos.html"></iframe>
</br>
<iframe width="49%"  height="50%" src="http://lordpakus.blogspot.com.es/p/tutorial-de-programacion-cc.html"></iframe>
<iframe width="49%"  height="50%" src="http://lordpakus.blogspot.com.es/p/lordpakus-game-engine.html"></iframe>
</br>
</BODY>

</HTML>

Y la visualización sería esta:


Poco a poco ya veréis como se le puede sacar mucho jugo a este tag

Nos vemos

LordPakusBlog

domingo, 25 de agosto de 2013

Curso HTML desde 0. Capitulo 4



Mirando los capítulos anteriores pensareis que poca cosa queda por aprender de lo básico de HTML, pero estáis bastante equivocados. Como mínimo todavía nos quedan las tablas.

Las tablas de HTML no son más que las típicas rejillas de datos (de las hojas de cálculo por ejemplo) que sirven para presentar información de una forma ordenada y clara.

Implementar tablas es bastante sencillo. Toda la tabla estará contenido dentro de los tags <TABLE> </TABLE>. Cada fila que queramos insertar la pondremos mediante <TR> </TR> y los datos de cada celda los pondremos mediante <TD> y </TD>.

Una de las gracias de las tablas de HTML es que dentro de cada celda se puede poner absolutamente lo que se quiera (textos, imágenes, objetos, lo que sea) y además las tablas tienen la particularidad que el borde por defecto no es visible ( se le ha de forzar con un border = "elnumerodepixelesdegrosorquequeramos" dentro del tag TABLE), esto nos permite tanto tener tablas con celdas dibujadas(que es lo que mostraremos abajo) como utilizar tablas para colocar los elementos dentro de nuestra web como queramos. (técnica que se ha usado durante muchos años)

Fácil?? Veamos un ejemplo.

<HTML>
<HEAD>
<TITLE> Curso de HTML desde 0. Capitulo 4 </TITLE>
</HEAD>

<BODY>

<H1> Libros de ciencia ficción </H1>

<TABLE border = "5">
<TR>
<TD>Año</TD>
<TD>Autor</TD>
<TD>Titulo</TD>
<TD>Compralo</TD>
</TR>

<TR>
<TD>1932</TD>
<TD>Aldous Huxley</TD>
<TD>Un mundo feliz</TD>
<TD> <iframe src="http://rcm-eu.amazon-adsystem.com/e/cm?

lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=lord00-21&o=30&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=8497594258" 

style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
</TD>
</TR>

<TR>
<TD>1948</TD>
<TD>George Orwell</TD>
<TD>1984</TD>
<TD> <iframe src="http://rcm-eu.amazon-adsystem.com/e/cm?

lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=lord00-21&o=30&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=3548234100" 

style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
</TD>
</TR>

<TR>
<TD>1985</TD>
<TD>Orson Scott Card</TD>
<TD>El juego de Ender</TD>
<TD> <iframe src="http://rcm-eu.amazon-adsystem.com/e/cm?

lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=lord00-21&o=30&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=8496581578" 

style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
</TD>
</TR>
</TABLE>

</BODY>
</HTML>


Gráficamente se ve tal que así:

Libros de ciencia ficción

Año Autor Titulo Compralo
1932 Aldous Huxley Un mundo feliz
1948 George Orwell 1984
1985 Orson Scott Card El juego de Ender

Espero que os haya gustado. Recordad que si queréis aprender tenéis que ir practicando.

Nos vemos

LordPakusBlog

sábado, 24 de agosto de 2013

Curso HTML desde 0. Capitulo 3



Si ya habéis mirado los capítulos anteriores de este curso ya sabéis lo muy básico de html (poner un texto, una imagen y enlazarle links). Ahora faltaría darle un poco de formato a los textos para se pareciesen más a lo que nosotros queremos:

Encabezados: HTML define 6 tipos diferentes de encabezados de mayor a menor tamaño. Cada uno de los encabezados se definen con el tag <h1>, <h2>, etc...  Ejemplo:

<h1>Encabezado 1</h1>
<h2>Encabezado 2</h2>
<h3>Encabezado 3</h3>
<h4>Encabezado 4</h4>
<h5>Encabezado 5</h5>
<h6>Encabezado 6</h6>

Saltos de linea: HTML define el tag de salto de linea como <br> , aunque también se puede usar el tag <p></p> para definir párrafos... dependerá de lo que queremos hacer. Ejemplo:

Hola
<br>
Adios
<p>
Hola
</p>
<p>
Adios
</p>

Alineación: Si utilizamos la etiqueta <p></p> para definir un párrafo podemos darle valor a un atributo(align) para decirle con que alineamiento queremos el texto de ese párrafo.Ejemplo
<p align = "left">
Hola
</p>

<p align = "center">
Que tal?
</p>

<p align = "right">
Adios
</p>

Lineas horizontales: Hay ocasiones en que nos interesa poner una linea horizonal para separar contenidos dentro de una misma web. Para hacer eso se ha de usar el tag <hr>. Tiene los siguientes parámetros: align, noshade (sin sombra) ,size (grosor en pixeles), width (ancho en porcentaje del tamaño de la pantalla). Por ejemplo:
<hr>
<hr size="20">
<hr size="20" noshade>
<hr align="left" size = "20" width="40%">
<hr align="center" size = "15" width="30%" noshade>
<hr align="right" size = "10" width="40%">


Tipografias: Todos los editores de texto permiten modificar el tamaño, tipo y formato de las fuentes en las que se està escribiendo. HTML permite modificar las características de una fuente mediante los siguientes tags: <B> (negrita), <I> (cursiva), <STRIKE> (texto tachado), <BIG> (tamaño grande), <SMALL> (tamaño pequeño), <SUB> (subindices), <SUP> (superindices), <U> subrayado. Por ejemplo:
<p>
<B> Negrita </B> <br>
<I> Cursiva </I> <br>
<STRIKE> Tachado </STRIKE> <br>
</p>

<p>
Normal
<BiG> Grande <BIG> Más grande <BIG> Más grande todavía </BIG></BIG></BIG>
</p>

<p>
Normal
<SMALL> Pequeño <SMALL> Más pequeño <SMALL> Más pequeño todavía </SMALL></SMALL></SMALL>
</p>

H<SUB>2</SUB>O  <br>

1<SUP>ero</SUP> <br>

<U> Subrayado </U>


Espero que os haya gustado.

Nos vemos



LordPakusBlog

jueves, 22 de agosto de 2013

Curso HTML desde 0. Capitulo 2



Hola a todos,

En el capítulo anterior hablamos de como pintar textos y poner links. El capítulo de hoy trata de poner imágenes y usarlas en nuestras webs.

El código del ejemplo es el siguiente (lo podéis copiar-pegar en un notepad y grabarlo con el nombre que queráis y extensión html)

<HTML>
<HEAD>
<TITLE> Curso de HTML desde 0. Capitulo 2 </TITLE>
</HEAD>

<BODY background="http://upload.wikimedia.org/wikipedia/commons/thumb/d/d4/Puerta_OR_con_transistores.jpg/220px-Puerta_OR_con_transistores.jpg">

<H1> Imagenes</H1>

<H2> Esto es una imagen con un link incorporado. Haz click encima. </H2>

<a href="http://lordpakus.blogspot.com.es/" style="background-color: white;" title="">
    <img alt="LordPakusBlog" height="82" src="http://4.bp.blogspot.com/-               ShU_aT6Eayw/T60usvEVp_I/AAAAAAAAAII/qBk-a7i_-
f4/s1600/BannerLordPakus.jpg" width="320" />

</BODY>
</HTML>

Si lo ejecutáis veréis algo de este estilo:


A nivel de explicación es sencilla:

1. Si dentro del tag de body, le pasáis como parámetro un background con una ruta de gráfico, este gráfico se utilizará para ir pintando el fondo.

2. El tag que se encarga de poner imagenes se llama img : <img></img>

3. Se pueden poner links a imagenes facilmente mediante <a> </a>

4. Esas rutas largas y raras no son más que los gráficos usados para este ejemplo

Espero que os haya gustado

Nos vemos
LordPakusBlog

miércoles, 21 de agosto de 2013

Curso HTML desde 0. Capitulo 1



Hola a todos,

HTML es un lenguaje simple y fácil de usar que nos permite implementar paginas web sencillas.

La primera cosa que tenemos de tener clara es que es un lenguaje interpretado por nuestro navegador (Mozilla, Chrome o el que tengáis), así que no se compila y no es necesario tener ninguna herramienta que no sea un navegador y un editor de textos sencillo (con un notepad tendríamos suficiente para empezar.)

El lenguaje html se basa en una estructura arbórea de llaves basada en tags que va definiendo que es lo que queremos en nuestra página web. El objetivo de este curso no es más que descubriros estos tags para que conozcáis todas las posibilidades que tiene este lenguaje. 

Vamos a empezar con el primer ejemplo:


Si copiáis este código en vuestro bloc de notas y haceís un "Guardar como" web.html (el nombre es indiferente lo importante es que la extensión sea html y no txt) ya tendreis vuestra primera página web creada!!!

Dadle dobleclick encima del icono del archivo que hayáis creado (normalmente el icono dependerá del navegador que uséis) y veréis lo siguiente:


Puntos importantes a tener en cuenta:
1. Todo documento  html ha de estar dentro del tag <html>  </html>
2. El tag <HEAD> nos define que saldrá en la pestaña del navegador
3. El tag <BODY> nos define todo aquello que saldrá en nuestra página
4. H1 significa cabecera. Todo aquello que esté dentro de este tag tendrá unos tamaños predeterminados
5. El tag <a> sirve para hacer links a otras páginas, ya sean locales o externas.
6. Todos los tags se cierran con </el_tag_que_queramos_cerrar>

Por ahora, ya está bien como comienzo. En breve empezaremos a hacer cosas un poco más complicadas.

Nos vemos

LordPakusBlog

sábado, 17 de agosto de 2013

Metodologías ágiles: DSDM (Dynamic Systems Development Method)



Hola a todos,

El DSDM ( Método de Desarrollo para Sistemas Dinámicos ) es una metodología de trabajo ágil muy parecido a SCRUM o XP con la única diferencia importante en la que el tiempo es un requerimiento fijo. Se pueden variar los requerimientos y se pueden renegociar las funcionalidades pero nunca los plazos de entrega.

A fin de poder realizar este tipo de filosofía con un mínimo de garantías, DSDM propone unas cuantas normas estrictamente necesarias:
- El usuario final (cliente) ha de participar de forma activa del desarrollo del proyecto.
- El equipo ha de tener el poder de tomar decisiones sin necesidad de pasar por una cadena burocrática.
- Entregas frecuentes: como el resto de metodologías ágiles, DSDM establece que cuanto más rápido podemos entregar algo hecho al cliente mejor que mejor.
- Desarrollo iterativo guiado por el feedback que nos da el cliente.
- Los cambios han de poder ser reversibles: En cualquier momento se ha poder eliminar cualquier cambio que no haya gustado.
- Los requerimientos han de estar definidos en lenguaje natural, no se ha de pensar en detalles de código en el momento de tomar requerimientos.
- El equipo ha de entender el objetivo economico o comercial del proyecto.
- Testeo continuo
- La colaboración es esencial. No solo entre los miembros del equipo sino entre todas las personas que colaboran en ese proyecto de una manera u otra.
- Regla de Pareto (20%- 80%) . La regla de pareto dice que el 80% del trabajo será desarrollado en el 20% del tiempo Lo que propone DSDM es que este 80% de producto sea lo primero que se tenga para entregar, de forma que si el cliente ve alguna cosa que no le gusta nos lo pueda comunicar cuanto antes mejor.


LordPakusBlog

viernes, 16 de agosto de 2013

Metodologías ágiles: OpenUP (Open Unified Process)



Hola a todos,

El Open Unified Process es una metodología ágil que fue desarrollada por un conjunto de empresas del sector del software que cedieron su creación a la Fundación Eclipse para que lo difundiera.

Este proceso productivo tiene 4 puntos básicos:
- Colaborar: sirve para que todo el equipo esté en la misma onda y los conocimientos fluyan en el equipo.
- Equilibrar prioridades: En caso de crisis los responsables han de decidir a que le dan más prioridad y han de ser coherentes con la decisión. De otra manera la empresa no va a obtener los beneficios que espera obtener.
- Centrarse en la arquitectura: Antes de hacer nada estar seguros que tenemos algo que se aguanta y sobre el que podemos ir añadiendo código.
- Desarrollo evolutivo: Es decir, ciclos cortos y iterativos que permitan la retro-alimentación del equipo y el aprendizaje de los errores.

OpenUP tiene una herramienta de estimación/seguimiento que es la siguiente:

Queda claro que es un proceso ágil debido a que las fases de este proceso están mucho más distribuidas en el tiempo que en el antiguo sistema de gestión en cascada.


LordPakusBlog

Metodologías ágiles: LEAN Software Development



Hola a todos,

El desarrollo de software LEAN es la traducción al mundo de la programación del sistema productivo automovilístico usado en TOYOTA (referente mundial en su campo).

La idea principal que mueve LEAN es eliminar todo aquello que sean "desperdicios" en el proceso de producción. Desperdicio se define como todo aquello que genera costes pero no genera valor para el consumidor.

Un ejemplo sencillo: si tenemos una fabrica de lapices, nos interesa saber que el consumidor quiere comprar un lapiz, sin más. Que sea de madera, que escriba y que se le pueda sacar punta, si además es de su color fávorito mejor que mejor. El consumidor no va a estar dispuesto a pagar más por que el lápiz se haya desplazado 3,5 km dentro de la fábrica en un complejo sistema de cintas transportadoras, ni por el hecho que después se haya embalado y transportado en camión durante 500 km. El consumidor solo quiere un lápiz. Solo estará dispuesto a pagar más si el lápiz dura más, pinta mejor o tiene alguna otra característica que lo hace atractivo.  Lo mismo pasa con el mundo del software. El consumidor no le va a dar ningún valor a que el software haya pasado por un complejo sistema "burrocrático" de aprobaciones o que durante el proceso el proyecto se haya parado por que ha habido un bug muy grande. El solo quiere pagar por la funcionalidad que le da el software, nada más.

En el caso concreto de LEAN para el desarrollo de software se designan algunos puntos adicionales:
- Eliminar desperdicios: Eliminar burocracias, código innecesario, procedimientos que no aportan valor.
- Ampliar aprendizaje: La formación continua del producto permite a los trabajadores realizar menos fallos y entender mejor los requerimientos.
- Decidir lo más tarde posible. Si se retrasa la toma de decisiones menos posibilidades hay que se tiren para atrás en el último momento.
- Reaccionar tan rápido como sea posible: Vendría a ser la idea subyacente de XP, hacer lo mínimo indispensable para cumplir con los requisitos, a fin de tener cuanto antes una versión entregable que se pueda evaluar a fin de poder iniciar la siguiente iteración.
- Potenciar al equipo: Los programadores del equipo han de poder auto-organizarse solos y desarrollar su trabajo en el marco que ellos establezcan a fin de poder trabajar más cómodos y por tanto , eficientes.
- Crear la integridad: Este concepto es el de como se comporta nuestro producto de software como un todo. Si se desarrolla por partes separadas y meramente pegadas con pegamento dificilmente estará todo integrado.  A veces es necesario refactorizar (como en  XP) pero no con el objetivo de reducir la complejidad  sino la de unificar el código y eliminar las duplicidades.
- Ver el conjunto: Esto significa que los programadores, en todo momento, han de tener muy claro que va ha hacer y como tiene que ser el producto de software final (independientemente que la parte que ellos toquen sea una minúscula parte del total) a fin de que todo el conjunto tenga cohesión.


LordPakusBlog

Gurús de la programación: Jim Highsmith



Hola a todos,


James A. Highsmith III, es un programador estadounidense nacido en 1945 que después de décadas de experiencia desarrollando software y gestionando y asesorando equipos elaboró la metodología ágil de trabajo "Adaptative Software Development".  En el 2001 fue uno de los firmantes del "Manifiesto Agil para el desarrollo de software".

Ha recibido numerosos premios como por ejemplo el premio Jolt en el 200 y el premio Stevens en el 2005.

Actualmente es ejecutivo en Touhgworks Inc y dedica los ratos libres a mantener su web y a escribir libros:


LordPakusBlog

Metodologías ágiles: Desarrollo adaptativo de software (ASD)



Hola a todos,

El Adaptative Software Development es una metodología ágil desarrollada por Jim Highsmith y Sam Bayer por allà a finales de los 90 y que se basa en que en el mundo real las cosas no se pueden determinar, medir y predecir con precisión sino que todo lo que hagamos está en un marco de inestabilidad en un entorno cambiante. Es decir, nuestro sistema de desarrollo ha de poder adaptarse día a día a los cambios que el proyecto se vea sometido.

El ciclo de trabajo que promueve el ASD se basa en tres etapas que se repiten de forma iterativa (como con SCRUM, CrystalClear o XP por ejemplo) :

- Especular: En un entorno altamente cambiante hablar de planificar es una falacia. No podemos planificar cuando podemos haber entendido mal los requerimientos, la tecnología puede cambiar o directamente las condiciones del mercado pueden variar. Si seguimos un plan obtendremos el producto que hemos planificado, si especulamos y nos adaptamos obtendremos el producto que necesitamos.

- Colaborar: Si no podemos planificar (que realmente no podemos), no podemos dirigir o controlar los equipos (al menos de la manera tradicional). El gestor del equipo ha de trabajar codo con codo con el equipo y saber como va todo gracias a la colaboración. Esto no significa que el equipo se sumerga en el caos, sino que el equipo se autogestione y la organización del trabajo emerga de los mismos trabajadores.

- Aprender: Si no se aprende no se mejora. Este aprendizaje puede venir de muchos sitios: del mismo equipo que diga que algo no se ha hecho bien y se puede mejorar, del testing durante y después del ciclo de trabajo o de cualquier fuente de información que permita al equipo aprender ha hacer las cosas un poquito mejor.

El ciclo es sencillo de visualizar:


Si os ha gustado esta filosofía de trabajo tal vez os guste el artículo que dió origen a ASD:  link


LordPakusBlog

jueves, 15 de agosto de 2013

Metodologías ágiles: Programación Extrema ( XP)



Hola a todos,

La metodología eXtreme Programming (XP, programación extrema) es una metodología de trabajo para desarrollar software de una manear altamente productiva desarrollada por Kent Beck en 1996.

Tiene muchas detalles en común con SCRUM y Crystal Clear pero se diferencia de ellos por darle una extrema importancia a la calidad del código que se exige como manera de producir de manera sostenible.

XP tiene 5 valores que si no son respetados no se puede decir que se está utilizando esta metodología:
- Comunicación: Tanto interna del equipo como de la empresa/cliente con el equipo.
- Simplicidad: Hacer lo más sencillo y correcto para cumplir con los requisitos actuales.
- Retroalimentación: Tanto el software , como el equipo, como el cliente han de retroalimentarse mutuamente.
- Valentía: Programar para hoy (y solo para hoy) , sabiendo que mañana habrá partes que tal vez se tengan que reescribir (o no), y ser capaz de cuando llegue el momento reescribir todo lo que haga falta.
- Respeto: El equipo ha de estar unido pase lo que pase.

Las características que modelan XP son las siguientes:
- Desarrollo iterativo: Como con SCRUM o con Crystal Clear, entregas pequeñas funcionales e incrementales.
- Pruebas unitarias continuas y automatizadas : Como en Crystal Clear, interesa que el código este probado hasta la saciedad. Si no está probado, no está acabado.
- Programación en parejas: Esto es de lo más arriesgado que propone XP, que dos programadores se pongan en el mismo sitio a trabajar. Esto genera una bajada de rendimiento aparente inicial, pero al poco el rendimiento aumenta rápidamente, debido a que dos cabezas piensan mejor que una y se acaba generando un código mejor, más limpio y legible, más estable, con menos errores y por lo tanto, más barato de mantener.
- Corrección de todos los errores antes de incluir nada nuevo: Sino lo nuevo que construimos está sobre cimientos arenosos.
- Refactorizar el código frecuentemente: Es decir, reescribir ciertas partes del código a fin de conseguir que sea más legible o mantenible.
- Propiedad del código compartida: Todo el código es de todo el mundo, no existe la posibilidad que el proyecto se quede parado por que el "encargado de tal cosa" esté de baja. Todo el mundo sabe de todo, peor o mejor.
- Simplicidad del código. Lo más recomendable es seguir la filosofía KISS. Si algo se ha de complicar, ya se complicará y se intentará hacer más complejo si llega el caso.
- Semanas de 40 horas: Todo el mundo entiende que se puedan pedir sobreesfuerzos puntuales, pero cuando estos sobreesfuerzos se transforman en norma la productividad y la calidad del código baja drásticamente. Si se quiere un código de alta calidad ( y por lo tanto más barato de mantener) interesa tener a los programadores frescos. Es lo mismo que decir que se quiere tener un ritmo sostenible.
- Estándar de códificación: Todos los miembros del equipo se han de poner de acuerdo en picar código en una misma dirección, sino el galimatías que acaba resultando es inmantenible.
- El cliente debería estar dentro del mismo equipo para poder dar feedback en tiempo real.

Las ventajas que otorga XP es que la satisfacción del programador por el trabajo bien hecho es alta y la tasa de errores del producto es muy muy baja , el problema es que no es una metodología recomendada para proyectos de largo plazo.

A fin de poder comparar el efecto de los cambios en los requisitos con  XP respecto con los sistemas tradicionales de producción o con SCRUM hay la siguiente gráfica que lo explica bastante bien:
Se observa claramente que al ser ciclos tan cortos los cambios en los requisitos apenas molestan al correcto desarrollo del proyecto.



LordPakusBlog

Metodologías ágiles: Crystal Clear



Hola a todos,

Ya habéis visto SCRUM y KANBAN que realmente son dos metodologías ágiles no centradas en el software (se podrían usar en servicios de atención al cliente o en la construcción, por ejemplo, sin ningún tipo de problemas), ahora toca aprender la familia de metodologías Crystal creadas por Alistair CockBurn que están mucho más centradas en el negocio del software.

El sr Alistair después de mucho investigar en el rendimiento de diferentes equipos de IBM vió que lo más importante eran las personas que trabajan en ese equipo y como se auto-organizaban. Dependiendo de cúan grandes fuesen los equipos y de que responsabilidades tuviese el proyecto el equipo necesitaría más o menos "accesorios" para poder tirar adelante. Así fue como creó la familía de metodologías Crystal. Los proyectos se dividen en 16 tipos diferentes con metodologías ligeramente diferentes de una a otra en función de la peligrosidad y el tamaño del equipo:

NOTA:
L : Riesgo de perder vidas humanas si hay un fallo
E: Riesgo de perder dinero que no es nuestro, si hay un fallo podemos tener graves problemas económicos
D: Riesgo de perder dinero nuestro y no "vital". Si hay un fallo la empresa registrará menos ganancias pero seguirá viviendo.
C: Riesgo de perder la comodidad. Si hay un fallo el equipo tendrá que trabajar más horas e ir fines de semana a acabarlo pero no pasará nada más.
Número: Máximo de personas en el equipo

Así pues estas metodologías tanto sirven para equipos pequeños y proyectos no vitales como para grandes equipos con altas responsabilidades.

Yo me centraré en explicar el Cristal Clear (C6) debido a que es el más sencillo (y es al 90% igual que al resto) y el que al final más se usa (la gran mayoría de proyectos acostumbran a ser pequeños tanto en riesgos como en personal).

Las bases del Crystal Clear son muy parecidas a las de la mayoría de metodologías de desarrollo ágil:
    - Personas por encima de herramientas
    - Reducción de "artefactos" intermedios (documentación, hojas de control, logs, etc..)
    - Reducción en la toma de decisiones
    - Agilidad frente al cambio

Todo esto en la práctica se puede observar como un conjunto de propiedades:
     - Entrega frecuente (como con SCRUM)
     - Comunicación íntima (todos los trabajadores han de estar en la misma habitación y enterarse de las cosas casi sin querer , por ósmosis )
     - Mejora reflexiva (se ha de pensar que es lo que va bien y va mal, para poder mejorar)
     - Autoconfianza de los trabajadores.
     - Acceso fácil a los usuarios especialistas.
     - Foco (que nadie tenga más de dos cosas en la cabeza cuando está desarrollando)
     - Pruebas automatizadas. (como con TDD )
     - Integración frecuente (por ejemplo usando un servidor de integración que gestione también el control de versiones y la documentación)

 Las estrategias que más se recomiendan dentro de Crystal Clear son:
    - Obtener victorias en poco tiempo (es decir, intentar tener poco código pero validado cuanto antes mejor, así se evitan grandes cantidades de código mal enfiocado que no cumple con lo que quiere el cliente)
    - Intentar tener cuanto antes un esqueleto que más o menos funcione, para luego ir añadiendo todas las funcionalidades que se piden.
    - Asumir que en más de una ocasión se tendrá que reescribir una parte del código.
    - Programación por parejas: Ya lo explicaremos con más detalle más adelante, por ahora quedaos en que dos programadores trabajan en el mismo PC y obtienen más rendimiento que estando separados.
    - Reuniones diarias a pie. (como con SCRUM)

LordPakusBlog



Gurús de la programación: Alistair Cockburn


Hola a todos,


Alistair Cockburn es un programador y gestor de equipos que en los 90 fue contratado por IBM para desarrollar una nueva metodología de trabajo. Se dedicó a entrevistarse con los equipos que más rendimiento tenian y se sorprendió al ver que todos ellos "pedian perdón" por no seguir una metodología formal, no obstante eso equipos obtenían un alto rendimiento. Llegó a la conclusión que los equipos que mejor funcionaban eran aquellos que se comunicaban cara a cara y que hacían entregas en ciclos cortos, cosa que acabó calando años después en el "Manifiesto Agil para el desarrollo de software" del cual fue firmante en el 2001.

De toda esta experiéncia surgió las "Crystal Methodologies" (Crystal Clear, Cristal Orange, Crystal Shapire, etc..) cuyo color indica solamente el tamaño del equipo y la necesidad de una metodología más establecida.

Su obra escrita es importante y siempre se ha basado en la defensa de las metodologías ágiles:

LordPakusBlog

Metodologías ágiles: KANBAN



Hola a todos,

En el último artículo os explique en que se basaba la metodología SCRUM y como algunos ya os habréis imaginado, hay situaciones en que, por buena que sea esta metodología, no va a funcionar de ninguna manera, por ejemplo en un equipo que se dedique a dar servicio de mantenimiento en que la respuesta no se puede alargar 2 semanas, sino como mucho horas. Además es muy normal que haya situaciones en que la carga de trabajo entre los diferentes miembros del equipo o de la cadena de producción no esté balanceado y por lo tanto se produzcan retrasos en la entrega del producto solamente por que una de las fases del desarrollo está demasiado cargada de trabajo. Todo esto SCRUM es incapaz de solucionarlo.

Para estas situaciones nació KANBAN (en japonés "tablero visual") , una forma de trabajar nacida en TOYOTA (de hecho apareció bastante antes que SCRUM) y pensada para producir coches más rápido y barato, pero que se puede aplicar a cualquier proyecto. Aparte de ser una metodología ágil se la conoce como uno de los troncos de la filosofía JIT (Just In Time). No explicaré aquí el KANBAN tradicional usado en la industria automovilística debido a que tiene poco que ver con la industria del software, pero si la parte más aceptada dentro de nuestro negocio.

La idea es sencilla, cada persona,departamento o elemento de la cadena de producción puede hacer un máximo de cosas a la vez en función de sus capacidades y recursos, lo que se le llama WIP (Work In Progress)  Darle menos trabajo implica la posibilidad de perder dinero por que hay gente que no está haciendo nada o que en poco tiempo se va a quedar sin trabajo, darle más trabajo del que puede absorber no va ha hacer que ese eslabón de la cadena produzca más, sino más bien al contrario, se estresará, intentará ir más rápido y por lo tanto, hará el trabajo de menos calidad (y luego vendrán bugs que encarecerán el coste final del producto).

La solución entonces es obvia, cada fase del desarrollo no tiene que dar más trabajo a la siguiente fase que el que ésta pueda absorber, pero... que hacemos con el trabajo que hemos acabado y no hemos podido entregar a la siguiente fase? En principio lo tendremos que "guardar". Si es un periodo corto de tiempo no hay problema, estas cosas pasan, podemos seguir trabajando en otras cosas , pero si de mientras que tenemos "guardado" un producto para la siguiente fase ya hemos acabado otro parte del trabajo tenemos un problema gordo y hemos de parar immediatamente de producir. El siguiente eslabón va hasta los topes de trabajo y a la que acabe lo que está haciendo ya le están esperando como mínimo dos tareas más. Tenemos un problema en la producción bastante serio y que se ha de solucionar.

Como solucionar este problema? Hay varias maneras dependiendo de la situación. Una posible solución (si es un problema continuado) es asignar más trabajadores a la fase  conflictiva a fin que pueda absorber más trabajo. Otra solución es intentar mejorar el proceso productivo de esa fase (replantearse tareas que aporten poco valor al producto, automatizar , mejorar en general los tiempos de respuesta ).

Si esta saturación es una cosa que pasa de vez en cuando y de manera más o menos aleatoria, tal vez la inclusión de nuevos trabajadores es innecesaria gran parte del tiempo y la mejora del proceso productivo (aunque siempre necesaria) es insuficiente para estos casos más o menos puntuales. La mejor solución en estos casos es que los elementos de la cadena que se queden sin trabajo por culpa de esta saturación (es decir, principalmente el que le da trabajo a la fase conflictiva y el que absorbe el trabajo de ésta) se pongan a ayudar en lo que puedan en la zona conflictiva. Ayudar significa ayudar en su máxima extensión, desde traer un café , aportar ideas, desarrollar software interno para automatizar tareas o realizar betatesting por ejemplo, cada uno en función de sus capacidades. Cada fase tiene una cierta especialización y se comprende que la ayuda que se pueda aportar no será como la de tener X personas especialistas trabajando en esa fase, pero todo ayuda.

La gracia de KANBAN no es que se gestione mejor o peor la producción de software que con otros métodos sino que los cuellos de botella emergen en toda su esplendor pidiendo a gritos que alguien los arregle. Si se es capaz de arreglar los cuellos de botella el ritmo de producción aumenta considerablemente , pero además se consigue que los trabajadores vivan mejor sabiendo que el trabajo nunca les faltará ni se les acumulará y por lo tanto rendirán más y mejor.

En el mundo del software el tablero típico de KANBAN vendría a ser algo así:



LordPakusBlog

miércoles, 14 de agosto de 2013

Metodologías ágiles: SCRUM



Hola a todos,

Una cosa que pasa bastante durante el desarrollo de un proyecto de software (ya sea grande o pequeño) es que cambien los requerimientos antes de acabarse el proyecto: un cambio en el mercado, una acción inesperada de la competencia o sencillamente haber encontrado un enfoque mejor al problema original.

En las metodologías "tradicionales" esto es devastador. Se pueden perder meses de trabajo de planificación, el código empeora drásticamente a nivel de calidad y normalmente los equipos acaban pagando las consecuencias debido a que tienen que hacer un sobreesfuerzo realizando trabajo en horas no "normales" o incluso en fines de semana.

SCRUM es una metodología ágil de las más usadas actualmente (y desde hace años). Fue desarrollado por Ken Schwaber y Jeff Sutherland y presentado en público en 1995 y se basa en entregar partes del producto acabado en ciclos cortos de tiempo, así que si hay un cambio en los requirimientos en el peor de los casos se pierden unos pocos días o semanas y no meses o años de trabajo.

En SCRUM se definen 3 roles principales:
- Product Owner ( P.O ): Es el que se encarga de encapsular toda la información que le llegue al equipo. Es decir, es el que hablará con los accionistas,el cliente, dirección o quien sea que defina que se quiere para ese producto y se lo transmitirá al equipo. De la misma manera es el que definirá que se quiere, para cuando se quiere y que quiere decir que algo está acabado. Calculará costes, retornos de inversión y decidirá si el proyecto es viable o no. Todo lo que el equipo haga lo tendrá que validar el PO antes de ser entregado al cliente. Vendría a ser la figura de jefe de equipo en otras metodologías antiguas.(pero solo a nivel de producto, el equipo no es de su "propiedad")

- Scrum Master (S.M) : También se le llama facilitador, es el que se encarga que el equipo pueda producir a su máximo nivel. Organizará todas las reuniones , detectará impedimentos (y luchará por solucionarlos) e intentará que el equipo vaya mejorando poco a poco. Vendría a ser el jefe del equipo en cuanto a que una de sus funciones principales es la de proteger el equipo de interferencias externas, pero no tiene decisión sobre el producto como tal (eso es potestad del PO). Para poder conseguir esto necesita hacer cumplir las normas de SCRUM.

- Miembro de equipo : Toda aquella persona que junto con otras, produce un bien o servicio. Puede ser programador, artista, músico, tester, etc...Debe comunicarle  al SM cualquier impedimento en su trabajo y al PO cualquier duda que tenga sobre el producto. Los que forman parte de un equipo no tienen "jefe" como tal sino que son células auto-organizadas, SM y PO tienen unas funciones muy delimitadas que en ningún punto  pueden interferir en la gestión interna del equipo.

SCRUM divide el trabajo temporalmente en forma de sprints. Un sprint es una cantidad de tiempo que siempre ha de ser la misma (aunque en cada equipo se puede escoger una u otra) que suele variar entre las 2 semanas y el mes.

El PO tiene que dar al equipo los requirimientos y tiene que priorizarlos en función de que es lo que quiere que sea lo primero en ser entregado. A partir de ahí el equipo debe "pesar" cada una de las tareas y asignarle cierta cantidad de puntos en función de cuan complicada cree el equipo que es. Cuando el equipo ya tiene experiencia trabajando juntos, el SM puede extraer, más o menos, cual es la velocidad media del equipo, es decir, cuantos puntos pueden asumir por sprint, y por lo tanto se le puede decir al PO (con un margen de error bastante bajo) que se le va a entregar al finalizar el sprint.

Al acabar el sprint el equipo ha de poder entregar trabajo al cual se ha comprometido acabado, es decir, que funcione y que cumpla con todos los requisitos que el PO ha especificado. En el supuesto que el equipo vea que no llegará a la entrega deberá avisar cuanto antes mejor al PO.

Con este proceso iterativo (un proyecto se puede hacer en 1 sprint o en 30 por decir algo) se va consiguiendo por un lado tener cosas "definitivas" que se puedan enseñar al cliente para que nos de feedback sobre si vamos bien encaminados o no y por otro lado una gran flexibilidad en cuanto a cambios de requirimientos.

Para realizar todo este proceso SCRUM define un mínimo de cuatro tipos de reuniones imprescindibles a realizar en los equipos:

- Daily Scrum: Es una reunión que se hace de pie, de un máximo de 10-15 minutos, normalmente al inicio de la mañana en la que todos los miembros del equipo deben responder a tres preguntas muy sencillas:
     ¿Qué has hecho desde ayer?
     ¿Qué es lo que harás hasta la reunión de mañana?
     ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?
Esta reunión le sirve al SM para detectar impedimientos o interferencias en el equipo e intentar solucionarlos cuanto antes. Además permite a los miembros del equipo sincronizarse y entender lo que está haciendo el resto del equipo.

- Planificación de Sprint: Es una reunión que se hace al incio de cada sprint en el que se decidirá que trabajo se realizará durante ese sprint en base a las tareas que ha pedido el PO (priorizadas), su peso (dado por el equipo), y la velocidad del equipo (analizado por el SM)

- Revisión de sprint ( demo ): Es una reunión en la que se revisa el trabajo completado y no completado y se enseñan el trabajo completado al PO para que de su aceptación.

- Retrospectiva: Es una reunión que se hace al finalizar todo el sprint en la que todo el mundo tiene libertad para comentar que le ha parecido ese sprint y en que se puede mejorar. Es la base para que el SM pueda intentar realizar mejora continua dentro del equipo.

Finalmente se definen unas herramientas para realizar todo este proceso que llamaremos backlogs (la traducción sería algo así como "mochila donde almaceno papeles con información"). Estos backlogs normalmente están hechos con papeles adhesivos de notas y pizarras, pero cada uno se lo puede montar como quiera. La idea es que hay dos backlogs principales:
- Backlog de producto: Todo aquello que el PO ha pedido para poder dar por acabado el producto.
- Sprint Backlog: Todo aquello que el equipo se ha comprometido a realizar durante ese sprint.


Aparte de estos backlogs existe otra herramienta llamada gráfico de burndown que muestra de forma bastante sencilla si el equipo está yendo a la velocidad adecuada o no.


Gráficamente todo este proceso se puede ver de la siguiente manera:




LordPakusBlog



¿Que són las metodologías ágiles? Agile Manifesto



Hola a todos,

Las metodologías ágiles de desarrollo de software son  un conjunto de métodos, maneras de producir, organizar y planificar que afectan desde el programador junior recién llegado hasta el máximo directivo de la empresa y que sirven para aumentar la productividad de los equipos y aumentar la calidad del código que producimos.

Estas metodologías ágiles se explican en un manifiesto hecho público en 2001 firmado por 15 de los gurús de la programación y la organización de equipos de software más importantes del momento. Podéis encontrar el manifiesto original aqui

Los firmantes de este manifiesto fueron los siguientes :
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

Traducido y explicado este manifiesto vendría a decir:

Para conseguir unos desarrollos de software mejores se ha de tener en cuenta  que:
 - Son más importantes las personas y las relaciones entre ellas que no los procesos y las herramientas.
 - Es más importante tener software funcionando haciendo lo que tiene que hacer que no la documentación.
 - Es más importante la colaboración del cliente que no los contratos firmados.
 - Es más importante responder a los cambios que no seguir un plan.

Esto no quiere decir que no sea importante los procesos, las herramientas, la documentación, los contratos o las planificaciones, solamente que hay cosas más importantes si queremos producir de una manera óptima.

Aparte de este manifiesto existen 12 principios que son los que marcan todas las metodologías asociadas a el:
- La mayor prioridad es satisfacer al clientes entregándole de forma continua y lo más pronto posible software con valor.
- Los cambios en los requirimientos son bienvenidos, aunque el desarrollo ya se haya iniciado, debido a que un cambio en los requirimientos bien gestionado es una oportunidad de negocio para el cliente.
- Entregar software que funciona frecuentemente (del orden de semanas o como mucho cada mes o dos), siempre que se pueda lo antes posible.
- La gente de negocios y los desarrolladores deben de trabajar juntos diariamente a lo largo del proyecto.
-Los proyectos se han de construir sobre los cimientos de trabajadores bien motivados.
- La forma más efectiva y eficiente de transimitir información al equipo es hablando cara a cara con el.
- El software que funciona es la primera medida de progreso
- Se ha de promover el desarrollo sostenible, es decir, que todas las partes implicadas (desarrolladores, consumidores,etc) puedan mantener el mismo ritmo de forma sostenible.
- La agilidad solo se consigue si se hace continua atención a la excelencia técnica y al buen diseño.
- La simplicidad es esencial
- Las mejoras arquitecturas, requerimienos y diseño emergen de equipos auto-organizados
- A intervalos regulares el equipo ha de pensar en como ser más efectivo para ir ajustando poco a poco la manera de trabajar a fin de ir mejorando de forma continua.





LordPakusBlog

Gurús de la programación: John Carmack

Hola a todos,


Nacido en Kansas, en 1970, John D. Carmack II es uno de los programadores que más méritos ha hecho para ganarse el título de mejor programador de la historia.

Comenzó la carrera de informática y la dejó al cabo de poco para ponerse a trabajar de programador de videojuegos para Softdisk, por allá los 90, donde conoció a John Romero. Poco después fundó con Romero la empresa de videojuegos "id Software".

Los títulos más conocidos en que Carmack ha sido el lead programmer son: Commander Keen, Wolfenstein 3D, Doom, Quake, Rage y secuelas. Por si esto fuera poco para darle un pedestal en la sala de los gurús a Carmack se le atribuyen diversos algoritmos que han revolucionado el mundo de los videojuegos: adaptative tile refresh, raycasting, partición binaria del espacio(BSP), surface caching, Carmack's reverse y la tecnología MegaTexture.

Os dejo una la lista de juegos de Id Software en que Carmack ha colaborado (y sus secuelas) y que todavía se pueden conseguir por internet:


Si quereis saber más de la vida de este crack de la programación os dejo unos pocos libros que hablan sobre los grandes desarrolladores de software:

LordPakusBlog

martes, 13 de agosto de 2013

Gurús de la programación: Ken Schwaber


Hola a todos,


Ken Schwaber es un programador y consultor tecnológico nacido en 1945 cuyo gran mérito es desarrollar SCRUM junto con Jeff Sutherland.  En el 2001 fue uno de los miembros firmantes del "Manifiesto Agil para el desarrollo de software". Es el responsable de la Agile Alliance y es el creador del "Certificado para Scrum Masters".

Actualmente es un "profeta" de SCRUM y se gana la vida mediante la formación de metodologías agiles y la gestión de varias organizaciones que se encargan de estos cometidos.

Sus libros son parecidos a los de Jeff (su compañero de creación de SCRUM), pero ligeramente más enfocados a la programación:





LordPakusBlog

Entradas populares