Para competir hay que ser barato. La productividad se mide en líneas de código o en horas-silla. Personas o departamentos que se "pasan la pelota" de uno a otro lado. Productos o servicios con una calidad muy mejorable. Proyectos que los usuarios no necesitan. Tareas repetitivas. Pocos retos. No puedo hacer las cosas como yo creo que deben hacerse.
física Planificaciones Reuniones diarias Demostraciones Kanban Añadimos artefactos y conceptos al día a día Lean Integración continua Tests Revisiones de código Refactorizaciones Programación por parejas TDD, BDD, … *DD
aplicar metodologías ágiles y aparecen los primeros problemas. No ocurre el milagro que todos esperábamos. Se necesita tiempo y constancia para empezar a ver resultados.
entrega temprana y continua de software con valor. No todos los roles tienen claro qué significa "valor". 2014 University Day Agile: Teoría vs Práctica Prioridades que no están claras. Prioridades que no se respetan Requiere procesos y herramientas lo más automáticos y simples posible.
los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Se piden definiciones titánicas. Hay que mantener el foco en el corto plazo.
funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. Requiere un entorno de desarrollo eficiente y que se utilicen buenas prácticas.
University Day Agile: Teoría vs Práctica Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Las planificaciones, demos y retrospectivas NO son los únicos momentos de comunicación.
avance deben ser fulminados. Los implicados deben participar en la toma de decisiones. El equipo debe tener retos. 2014 University Day Agile: Teoría vs Práctica Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. No definir el "cómo", definir el "qué".
al equipo de desarrollo y entre sus miembros es la conversación cara a cara. 2014 University Day Agile: Teoría vs Práctica Minimizar al máximo debates por mail, chat y "teléfonos escacharrados". Aquellos que necesitan algo y aquellos que aportan una solución deben trabajar directamente.
funcionando es la medida principal de progreso. Las estimaciones no son contratos. Los puntos de historia son relativos. Se necesita tiempo para encontrar la velocidad.
Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. Satisfacer las necesidades presentes sin comprometer las posibilidades futuras.
buen diseño mejora la Agilidad. 2014 University Day Agile: Teoría vs Práctica El equipo tiene que poder y debe incluir mejoras en las técnicas. El equipo debe responsabilizarse de la calidad interna y defenderla a toda costa.
equipo la motivación de lo que se pretende conseguir. Todas las partes deben ceder para simplificar. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
arquitecturas, requisitos y diseños emergen de equipos auto-organizados. Hay que permitir y ayudar al equipo a que se gestione solo. Si hay un director técnico, debe ir cediendo la gestión al equipo.
deben hacerse de manera constructiva y positiva. 2014 University Day Agile: Teoría vs Práctica A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. Para que la mejora continua sea real se necesitan acciones concretas. Pueden convertirse en "el día de la marmota" con facilidad.
alvaromg
kumamotone
tinoue
tokida
ritou
hankehly
ch6noota
stripehideokamoto
isaoshimizu
yfcgpsebp
jjebejj
kazamori
comucal
swwweet
edds
frogandcode
rocio
jonyablonski
tanoku
jonrohan
aarron
malarkey
soudai
dougneiner
mojombo
