Factores Humanos, Desarrollo Agil

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 4

Factores humanos

Los defensores del desarrollo de software ágil enfatizan la importancia de los


“factores personales”. Como dicen Cockburn y Highsmith: el proceso se adapta
a las necesidades de las personas y del equipo.

Listare algunas de las características que deben de tener aquellos miembros


del equipo de software que elaborarán las características aplicadas a la
elaboración del software.

Competencia. La "capacidad" incluye talento innato, habilidades específicas de


software y conocimiento general del proceso que el equipo ha elegido usar. Las
habilidades y el conocimiento de los procesos pueden y deben ser
considerados por todos los miembros de un equipo ágil.

Enfoque común. Los miembros del equipo Agil realizan diferentes tareas y
aportan diferentes habilidades al proyecto, todos deben estar enfocados en el
mismo objetivo: brindar productividad al cliente dentro del marco de tiempo
prometido. Para lograr esto, el equipo también se enfocará en la adaptación
continua para asegurar que el proceso satisfaga las necesidades del equipo.

Colaboración. El desarrollo de software implica la evaluación, el análisis y el


uso de la información proporcionada al equipo de desarrollo; crear información
que ayude a todos los participantes a comprender el trabajo del grupo; y
generar información que aporte valor empresarial a los clientes. Para realizar
estas tareas, los miembros del equipo deben colaborar entre sí y con todos los
participantes.

Habilidad para tomar decisiones. Cualquier buen equipo de desarrollo debe ser
libre de dirigir su propio destino. Esto significa que se otorga autonomía al
equipo: el poder de tomar decisiones sobre cuestiones de ingeniería y diseño.

Capacidad para resolver problemas difusos. Los administradores de software


deben ser conscientes de que los equipos ágiles a menudo se enfrentan a la
incertidumbre y se verán constantemente abrumados por el cambio. En
algunos casos, el equipo tiene que aceptar que el problema que están
resolviendo ahora puede no ser el problema que tendrán que resolver mañana.
Sin embargo, las lecciones aprendidas de los pasos de solución de problemas
serán útiles para el equipo más adelante en el proyecto.

Confianza y respeto mutuos. El equipo ágil debe convertirse en lo que DeMarco


y Lister llaman “pegado”. Un equipo pegado tiene la confianza y respeto que
son necesarios para hacer “su tejido tan fuerte que el todo es más que la suma
de sus partes”.

Organización propia. En el panorama del desarrollo ágil, la autoorganización


tiene tres cosas:

1) un equipo ágil es auto organizado para hacer el trabajo,

2) el equipo organiza el proceso que mejor se adapte a sus condiciones


locales,

3) el equipo organiza el horario de trabajo para que la distribución incremental


se haga de la mejor manera posible

Valores XP.

Un conjunto de cinco valores sustenta todo lo que se hace en XP:


Comunicación, Simplicidad, Retroalimentación, Coraje y Respeto. Cada uno de
estos valores se utiliza como controlador para operaciones, operaciones y
tareas específicas de XP.

Para simplificar las cosas, XP limita a los desarrolladores a diseñar para las
necesidades actuales, no para las necesidades futuras. El objetivo es crear un
diseño simple que se pueda implementar fácilmente en el código. Si el diseño
necesita mejoras, se volverá a hacer más tarde.

La retroalimentación provienen de tres fuentes: software implementado,


clientes y otros miembros del equipo de desarrollo. Al desarrollar e implementar
una estrategia de prueba efectiva, el software (a través de los resultados de la
prueba) proporciona retroalimentación al equipo ágil. XP utiliza pruebas
unitarias como su principal táctica de prueba.
La medida en que el software implementa el resultado, la funcionalidad y el
comportamiento del caso de uso es una forma de retroalimentación.
Finalmente, a medida que surgen nuevos requisitos durante la planificación
iterativa, el equipo proporciona rápidamente comentarios al cliente sobre los
costos y el impacto en la planificación operativa.

La mayoría de los equipos de desarrollo de software ceden ante esto y


argumentan que "diseñar para el mañana" ahorrará tiempo y esfuerzo a largo
plazo. El equipo de Agile XP debe tener la disciplina para diseñar hoy y
comprender que los requisitos futuros pueden cambiar drásticamente, lo que
requiere una iteración significativa del código de diseño e implementación.

El proceso XP.

La programación extrema utiliza un enfoque orientado a objetos como modelo


de programación preferido e incluye un conjunto de principios y prácticas
aplicados en el contexto de cuatro actividades: planificación, diseño,
codificación y prueba. Esta figura muestra el proceso de XP y destaca algunas
de las ideas y tareas clave asociadas con cada operación de la plataforma. Los
siguientes párrafos resumen las principales actividades de XP.

Planeación: La planificación (también conocida como el juego de la


planificación) comienza con la escucha de la recopilación de requisitos, lo que
permite a los miembros del equipo de ingeniería de XP comprender el contexto
comercial del software y comprender los resultados, así como las
características y funciones clave requeridas.

En el proceso, el cliente puede agregar una historia, cambiar el valor de una


historia existente, dividirla o eliminarla. Como resultado, el equipo de XP
analiza los envíos faltantes y ajusta su plan en consecuencia.

Diseño: El diseño de XP se adhiere estrictamente al principio MS (mantenlo


simple). Un diseño simple siempre es mejor que una presentación más
compleja. Además, el proyecto define la realización de la historia en la forma en
que está escrita: nada más, nada menos. No se recomienda diseñar
funcionalidad adicional porque el desarrollador cree que será necesaria más
adelante.
Si se descubre un problema de diseño complejo durante el diseño de la
historia, XP recomienda crear inmediatamente un prototipo funcional de ese
diseño. El prototipo de diseño, conocido como solución final, se implementa y
prueba. El propósito es reducir el riesgo al inicio de la implementación real y
verificar las estimaciones iniciales para el piso que contiene el problema de
diseño.

Rediseño: es el proceso mediante el cual se cambia un sistema de software en


forma tal que no altere el comportamiento externo del código, pero sí mejore la
estructura interna. Es una manera disciplinada de limpiar el código y modificar
o simplificar el diseño interno que minimiza la probabilidad de introducir errores.
En esencia, cuando se rediseña, se mejora el diseño del código después de
haber sido escrito.

Codificación: Una vez que se desarrolla la historia y se completa el diseño


inicial, el equipo no comenzará a codificar, sino que desarrollará una serie de
pruebas unitarias para cada historia que se incluirán en el lanzamiento en curso
(parte ampliada de la historia). Una vez que se crea una prueba unitaria, el
desarrollador puede concentrarse mejor en lo que debe implementarse para
pasar la prueba. No se agregó nada extraño. Tan pronto como el código está
listo, se prueba la unidad de inmediato, lo que brinda retroalimentación
inmediata a los desarrolladores.

Pruebas: Se ha dicho que crear pruebas unitarias antes de codificar es una


parte importante del enfoque de XP. Las pruebas unitarias que cree deben
implementarse utilizando un marco que les permita automatizarse (para que
puedan ejecutarse repetidamente y fácilmente). Esto fomenta una estrategia de
prueba de regresión cada vez que cambia el código (que suele ser el caso
debido a la filosofía de rediseño de XP).

También podría gustarte