Grandes expectativas al usuario

-
Una niña abre un regalo de Navidad y empieza a llorar, no era la muñeca barata que la niña estaba esperando. Un equipo del proyecto hace milagros para implementar una fenomenal y complejo aplicación, sólo para que sea rechazado por sus usuarios, ya que no tiene un sistema de ayuda.

En un sentido abstracto, una solicitud tiene éxito si se implementa correctamente sus especificaciones. Es decir, el éxito de un proyecto se mide por lo bien que se cumple con las expectativas de sus usuarios. Un proyecto que cae por debajo de sus expectativas es considerado un fracaso, no importa lo bueno de la realización en términos absolutos.

Los usuarios llegan a usted con una visión de lo que quieren. Puede ser incompleta, inconsistente o técnicamente imposible, pero es de ellos, y, como la niña en Navidad, que hay algo de emoción invertido en ella. Usted no puede simplemente ignorarla.

A medida que su comprensión de sus necesidades se desarrolla, encontrará en áreas donde las expectativas no se pueden cumplir, o cuando sus expectativas quizás son demasiado conservadoras. Parte de su papel es el de comunicarlo. Trabaje con los usuarios de modo que su comprensión de lo que va a entregar es exacta. Y hacer esto en todo el proceso de desarrollo. Nunca pierda de vista los problemas de negocio que su aplicación pretende resolver. Algunos consultores llaman a este proceso "gestión de las expectativas", de forma activa controlan lo que los usuarios deben esperar para obtener de sus sistemas. Nuestro papel no es controlar las esperanzas de nuestros usuarios. Sinó, trabajar con ellos para llegar a una común comprensión del proceso de desarrollo. Si el equipo está en comunicación fluida con el mundo exterior, este proceso es casi automático; todos deben entender lo que se espera y cómo se va a contruir.
Existen algunas técnicas importantes que pueden utilizarse para facilitar este proceso. De estas, balas trazadoras, prototipos y Post-it, son las más importante. Ambos permiten al equipo construir algo que el usuario puede ver. Ambas son formas ideales de la comunicación, comprensión y requerimientos.

Algunas cosas que se pueden añadir con relativa facilidad para lucir bien con el producto:
- Información de herramientas que ayudan.
- shortcuts.
- Una guía de referencia rápida como suplemento del manual de usuario.
- Colorización.
- Analizador de archivo log.
- Instalación automatizada.
- Herramientas para verificar la integridad del sistema.
- Una pantalla de bienvenida personalizado para su organización.

Todas estas cosas son relativamente superficiales, no sobrecargan el sistema y tampoco altera el alcance de los requerimientos

Mi Retrospectva 2009

-
Esto de la retrospectiva será el último post del año. Esto de retrospectiva personal me parece como jugar al #yoconfieso de twitter.

El 1 de Enero este sencillo blog cumple 1 año. Los primeros post (Enero y Frebrero 2009) trataba de código y herramientas que había utilizado años atrás, por esta razón tengo varios posts en los primeros meses.

Me trazé muchas metas como aprender más lenguajes y tener más certificaciones Java, lo cual no pude llegar por varios motivos personales y laborales. Sin embargo, este 2010 los cumpliré. Me siento muy motivado, con la frente en alto y olvidando los malos ratos que pasaron en este 2009. El hecho de cometer algunos errores me han servido como experiencia. Como lo escuché en el taller de Scrum Master: "El error es una inversión".

Este año fue muy complicado para mi ya que tuve que llevar un proyecto largo y difícil que me mantenía muy ocupado, limitado por Jdk 1.4 no pude investigar y aplicar muchas cosas que había leido o escuchado. Y ahora mismo me encuentro finalizando ese proyecto :S

Una de las cosas más importantes que me pasó este año es haber conocido mucha gente hábil y profesional, los cuales han sido fuente de motivación en el trabajo, en el blog y en la vida diaria.
Después de haber escuchado y aprendido más del mundo del software y redes sociales, combinando mis experiencias y de las demás personas, se me presentan varios proyectos que tengo en mente. Bueno... pero eso ya es otra historia.

Lo más rescatable del año es haber aprendido el framework Scrum y empezar a programar en RubyOnRails. XD

Agradezco a muchas personas que me estuvieron apoyando en el transcurso del año entre ellas, los profesionales: @joedayz y @ccastillop

No muy conforme con los posts del blog (ya que no recibí muchos comentarios). En este 2010 me esforzaré mucho más.

Nos leemos... Feliz año nuevo!

Resolviendo rompecabezas imposibles

-

Gordius, el rey de Frigia, una vez hizo un nudo que nadie podía desatar. Se dijo que el que resuelve el enigma del nudo gordiano podría dominar toda Asia. Así es como viene Alejandro Magno y partió el nudo en pedazos con su espada.

Muchas veces el secreto para resolver el rompecabezas es identificar las reales (no imaginadas) limitaciones, y encontrar una solución en las mismas. Algunas restricciones son absolutas, otras son simplemente nociones preconcebidas.


La frase popular "pensar fuera de la caja" nos anima a reconocer las limitaciones que podrían no ser aplicables y hacer caso omiso de ellos.
Pero esta frase no es del todo exacto. Si la "caja" es el límite de las limitaciones y condiciones, el truco es encontrar la caja, que puede ser considerablemente mayor de lo que crees.
La clave para resolver los rompecabezas es reconocer las limitaciones impuestas y reconocer los grados de libertad que tienen.

Por ejemplo, ¿se pueden conectar todos los puntos siguientes y volver al punto de partida con sólo tres líneas rectas, sin levantar la pluma del papel o volver sobre sus pasos?



No piense si está dentro de la caja o fuera de la caja. El problema consiste en encontrar la caja, la identificación de las limitaciones reales.

Cuando se enfrenta con un problema que crea imposible, enumere todos las posibles caminos que se tienen. No descarte nada, no importa cómo inutilizables o estúpido suenen. Ahora vea a través de la lista y explique por qué un cierto camino no puede ser tomado. ¿Estás seguro? ¿Puedes probarlo?

Considere el caballo de Troya, una solución a un problema de difícil solución. ¿Cómo sacar a las tropas en una ciudad amurallada sin ser descubierto? Usted puede apostar: "a través de la puerta de entrada", fue descartado inicialmente como suicidio.

Categorizar y priorizar sus limitaciones. Cuando los carpinteros inician un proyecto, cortan las piezas más largas en primer lugar, a continuación, cortan las piezas más pequeñas de la madera restante. De la misma manera, queremos identificar las limitaciones más restrictivas en primer lugar, y luego las restricciones que siguen dentro de ellas.

Siempre hay un camino más fácil!!!!

Puede ser el caso donde se llega tarde al desarrollo de un programa o incluso la desesperación de tener el sistema trabajando y vemos que el problema en particular es "imposible".

Ahí es cuando hay que dar un paso atrás y hágacerse estas preguntas:

• • ¿Existe una manera más fácil?
• • ¿Estás tratando de resolver el problema correcto?
• • ¿Por qué es esto un problema?
• • ¿Qué es lo que está haciendo tan difícil de resolver?
• • ¿Tiene que hacerse de esta manera?
• • ¿Tiene que hacerse en todos?

Muchas veces una revelación sorprendente vendrá al tratar de responder una de estas preguntas. Muchas veces, una re-interpretación de los requerimientos de puede hacer desaparecer a un conjunto de problemas al igual que el nudo gordiano.
Todo lo que necesitas son las limitaciones reales, las limitaciones engañosas, y la sabiduría para reconocer la diferencia.

Ahh.. aquí está la solución de los puntos:



Fuente : The Pragmatic Programmer : From Journeyman to Master

Ejerciciós básicos de Refactorización

-
Ejercicio 1

El siguiente código, evidentemente, ha sido actualizado varias veces a lo largo de los años, pero los cambios no han mejorado su estructura. Refactorizar!

if (state == TEXAS) {
 rate = TX_RATE;
 amt = base * TX_RATE;
 calc = 2*basis(amt) + extra(amt)*1.05;
}
else if ((state == OHIO) || (state == MAINE)) {
 rate = (state == OHIO) ? OH_RATE : MN_RATE;
 amt = base * rate;
 calc = 2*basis(amt) + extra(amt)*1.05;
 if (state == OHIO)
  points = 2;
 }
 else {
  rate = 1;
  amt = base;
  calc = 2*basis(amt) + extra(amt)*1.05;
}

Solución

Podríamos sugerir una reestructuración bastante suave aquí: asegúrese de que cada prueba se realiza sólo una vez, y hacer todos los cálculos comunes. Si la expresión 2 * base (...) * 1.05 aparece en otros lugares en el programa, se debe, probablemente hacer una función. En este caso no es necesario.

Hemos añadido un arreglo rate_lookup, inicializado para que las entradas distintos de Texas, Ohio y Maine tengan un valor de 1. Este enfoque hace que sea fácil de agregar los valores de otros estados a futuro.

rate = rate_lookup[state];
amt = base * rate;
calc = 2*basis(amt) + extra(amt)*1.05;
if (state == OHIO)
points = 2;

Ejercicio 2

Las siguientes clases Java necesitan soportar más "shapes". Refactorize la clase.

public class Shape {
 public static final int SQUARE = 1;
 public static final int CIRCLE = 2;
 public static final int RIGHT_TRIANGLE = 3;
    
 private int shapeType;
 private double size;
 public Shape(int shapeType, double size) {
 this.shapeType = shapeType;
 this.size = size;
}
// ... other methods ...
public double area() {
 switch (shapeType) {
 case SQUARE:     return size*size;
 case CIRCLE:     return Math.PI*size*size/4.0;
 case RIGHT_TRIANGLE: return size*size/2.0;
}
return 0;
}
}

Solución

Cuando usted ve a alguien usando los tipos enumerados (o sus equivalente en Java) para distinguir entre las variantes de un tipo, a menudo se puede mejorar el código por medio de subclases:

public class Shape {
 private double size;
 public Shape(double size) {
 this.size = size;
}
public double getSize() { return size; }
}
public class Square extends Shape {
 public Square(double size) {
 super(size);
}
public double area() {
 double size = getSize() ;
 return size*size;
}
}
public class Circle extends Shape {
public Circle(double size) {
 super(size);
}
public double area() {
 double size = getSize();
 return Math.PI*size*size/4.0;
}
}
// etc...

Ejercicio 3

Este código de Java es parte de un framework que se utilizará a través de su proyecto. Refactorizar para ser más general y más fácil de ampliar en el futuro.

public class Window {
public Window(int width, int height) { ... }
public void setSize(int width, int height) { ... }
public boolean overlaps(Window w) { ... }
public int getArea() { . . . }
}

Solución

Este caso es interesante. A primera vista, parece razonable que un "window" (ventana) deba tener una anchura y una altura. Sin embargo, tenga en cuenta el futuro. Imaginemos que queremos apoyar de manera arbitraria las formas de las ventanas. (que será difícil, si sabe que la clase window conoce todo acerca de los rectángulos y sus propiedades).

Sugerimos abstraer la forma de la ventanas de la Clase window.

public abstract class Shape {
// ...
public abstract boolean overlaps(Shape s);
public abstract int getArea();
}
public class Window {
 private Shape shape;
 public Window(Shape shape) {
   this.shape = shape;
...
}
public void setShape(Shape shape) {
 this.shape = shape;
...
}
public boolean overlaps(Window w) {
 return shape.overlaps(w.shape);
}
public int getArea() {
 return shape.getArea();
}
}

También se podría haber extendido este ejemplo mediante la introducción de una interface Java, que especifica los métodos de una clase de apoyo que debe ser compatible con las funciones de shape.

Fuente : ThePragmatic Programmer: From Journeyman to Master

CSM done!

-
Como lo estaba anunciando, asistí el sábado 12 y domingo 13 al primer curso de Certified Scrum Master (CSM) en Lima.

En esa jornada de 2 días puedo decir que el curso a mi parecer fue excelente se realizaron buenas dinámicas, buenos ejemplos, me gustó mucho la metodología de eneseñanza utilizada por Alan Cyment.

De los asistentes conocía a mucho por twitter, fue un agrado para mí el poder conocerlos personalmente. Todos los asistentes que fueron 24, trabajan en sistemas.


Llevo trabajando un año con SCRUM ya que mis jefes conocen el concepto. Sin embargo, siempre me quedaban dudas en los procesos, roles y herramientas. Gracias a este curso despejé estas dudas y me encuentro con la motivación de aplicarlo en el trabajo y en la vida diaria.

Este curso me a motivado mucho en seguir la corriente ágil, empezaré a asistir a las reuniones que realiza el grupo "Agile - Perú"

Foto con Alan Cyment (@acyment)



Foto del grupo del curso

Netbeans 6.8 y GlassFish V3

-
Hace unos días me bajé la versión 6.8 de Netbeans para empezar a probarlo ya que tuve un poco de problemas con la versión 6.5 cuando programaba en Ruby y no aparecía bien el guión abajo ("_") ahora ya se ve en esta nueva versión

Netbeans 6.8 ya viene integrado el servidor GlassFish V3 por defecto


Al correr mi aplicación me apareció un error de informando de que no se pudo iniciar GlassFish, esto era porque el puerto 8080 ya estaba siendo utilizado por otro servidor de aplicaciones (tomcat).


SEVERE: Shutting down v3 due to startup exception : Address already in use: 8080=com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler


Cambiar de Puerto

Para saber la ruta del archivo que hay que modificar para cambiar el puerto , entramos a la pestaña de Services, elegimos Server > GlassFish V3 Domain (ese es el nombre que le coloqué).



Entramos a esa ruta "Domain Folder", buscamos el "Domain Name" en mi caso es la carpeta "domain1", entramos a la carpeta config y finalmente al archivo "domain.xml". En este archivo modificamos el puerto 8080.



Guardamos el archivo y al reiniciar el servidor GlassFish debería levantar la aplicación.

Cómo refactorizar (tips)

-
Si procede a arrancar grandes cantidades de código con desenfreno, usted puede encontrarse en una situación peor que cuando comenzó.

Claramente, la refactorización es una actividad que debe llevarse a cabo lentamente, deliberadamente, y con cuidado. Martin Fowler ofrece los siguientes tips sencillos sobre la forma de refactorizar sin hacer más daño que bien:

1. No trate de refactorizar y añadir funcionalidad al mismo tiempo.

2. Asegúrese de que tenga buenas pruebas antes de comenzar la refactorización. Correr las pruebas con la mayor frecuencia posible. De esta forma usted sabrá rápidamente si sus cambios no han roto nada.

3. Tomar pasos cortos y deliberados: mover un campo de una clase a otro, fusione 2 métodos similares en una superclase. Refactorizando a menudo implica hacer muchos cambios que resultan un cambio a gran escala. Si guardas tus pequeños pasos, y pruebas después cada paso, evitarás una depuración prolongada.

Fuente: The Pragmatic Programmer: From Journeyman to Master

Primer CSM en Lima

-


Viendo otras alternativas al desarrollo de software me inscribí al curso de Certificación Scrum Master.

Gracias a Open Edge Technologies este fin de semana se llevará a cabo el primer curso de Certificación Scrum Master en Lima.

Será este sábado 12 y domingo 13 de diciembre.

[De la página de Open Edge: ]

¿Qué es un ScrumMaster?

Es un gestor (manager) de un proyecto ágil el cual pone el énfasis en la facilitación, liderazgo y comunicación por sobre las actividades tradicionales de dirigir y controlar. Para el framework Scrum, este rol es denominado “ScrumMaster” como un recordatorio constante de las diferencias entre la gestión de proyectos ágil y la tradicional. El rol del ScrumMaster implica maximizar los esfuerzos del equipo para alcanzar sus objetivos removiendo aquellos impedimentos que se encuentran en su camino.

El curso CSM cubrirá los siguientes conceptos (entre otros) a través de los dos días de ejercicios interactivos, clases y discusión:

- Introducción a Scrum

- Roles y Responsibilidades en Scrum

- Análisis de Requerimientos Ágil

- Estimación y Priorización del Product Backlog

- Planificación del Sprint, Ejecución, Revisión, y Retrospectiva

- Qué significa “Hecho”?

- Deuda Técnica y otros Errores

- Planificación del Release basada en Mediciones Empiricas

- Scrum en Organizaciones con Multiples equipos

- Q & A

Instructor

Alan Cyment

Más información aquí