Principios ágiles

Los principios fundamentales de una metodología ágil se pueden resumir:

Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
El software que funciona es la principal medida del progreso.
Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica enaltece la agilidad.
La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

(copy paste con el fin de difundir)
Fuente: http://www.dosideas.com/wiki/Desarrollo_Agil_De_Software

Una manera de identificar y retirar riesgos

Continúando con mi lectura del libro de Ing. de software una perspectiva orientada a objetos de Braude, me encontré con otra tabla que complemente la entrada anterior. dicha tabla nos indica la manera de identificar y retirar riesgos.

*1. Cada integrante del equipo pasa 10 minutos explorando sus temoreas mas grandes para el éxito del proyecto.
*2. Cada integrante especifica estos riesgos en un lenguaje concreto , los pondera, escribe planes de retiro y envía un correo al líder del equipo.
*3. El líder del equipo integra y asigna prioridades a los resultados.
+4. El grupo dedica 10 minutos a buscar otros riesgos.
+5. El equipo dedica 10 minutos a finalizar la tabla de riesgos.
                *Designa ingenieros responsables del retiro de riesgos.
**6. Los ingenieros responsables hacen el trabajo de retiro de riesgos.
+7. El equipo revisa los riesgos durante 10 minutos en las reuniones semanales.
  *El equipo discute los nuevos riesgos percibidos y los agrega.

*antes de la primera reunión.
+en la reunión.
**entre reuniones.

Como podemos observar, el papel del líder de proyecto se vuelve crucial a la hora de retirar riesgo, llamemos retirar riesgo al hecho de erradicar un riesgo, el líder de proyecto debe de tener el big picture de la situación y tener en cuenta todos los riesgos y retirar los mas importantes y sustentar un plan de emergencia para solventar los demás y que no se vuelvan críticos al proyecto y terminen siendo un impedimento de cumplimento en la entrega con el cliente.

Fuentes.

Ingeniería de software. Una perspectiva orientada a objetos

Capitulo 2 Administración de proyectos.

Braude.

Fuentes de riesgo en orden de importancia

Leyendo el libro de ingeniería de software de Braude me tope con una lista de riesgos ordenados en orden de importancia. Sin duda se me hizo muy interesante y lo comparto.

1. Falta de compromiso de la alta administración.

2. Falla al obtener el compromiso del usuario.

3. Error al entender los requerimientos.

4. Participación inadecuada del usuario.

5. Falla al manejar las expectativas del usuario final.

6. Cambio de alcance y/o de objetivos.

7. Falta de conocimientos o aptitudes requeridas del personal.

Podemos notar que el riesgo mas grande esta en la alta administración, como la negligencia de los jefes puede ocasionar que el proyecto se desmorone.

También nos damos cuenta que si el usuario no tiene el compromiso de participar adecuadamente y jugar su rol como le corresponde puede ocasionar que el proyecto no cumpla con los objetivos.

Sin duda si no entendemos los requerimientos estamos fritos ya que todo el trabajo y esfuerzo por parte del equipo de desarrollo se convierte a nulo si no comprendimos los requerimientos.

El cambio de objetivos y/o requerimientos en una fecha avanzada del proyecto puede ser catastrófico ya que le puede pegar al núcleo del sistema.

Sin duda todos estos riesgos son importantes, ya que incluso con un equipo de desarrollo no preparado ante las tecnologías del proyecto, se puede volver un riesgo potencial.

Fuentes.

Ingeniería de software. Una perspectiva orientada a objetos

Capitulo 2 Administración de proyectos.

Braude.