En esta oportunidad, Gustavo Andres Brey, Co-Founder de Ingenia y ArqConf realizará una introducción a la metodología de Lean Startup y las consideraciones Arquitecturales que debemos tener a la hora de llevarla adelante para la creación de Startups Tecnológicos. Aportará su experiencia en la utilización de la metodologías no solo en startups sino también en su experiencia como Gerente de Sistemas en corporaciones creando productos digitales en la industria de la salud.
En esta oportunidad, Gustavo Andres Brey, Co-Founder de Ingenia y ArqConf realizará una introducción a la metodología de Lean Startup y las consideraciones Arquitecturales que debemos tener a la hora de llevarla adelante para la creación de Startups Tecnológicos. Aportará su experiencia en la utilización de la metodologías no solo en startups sino también en su experiencia como Gerente de Sistemas en corporaciones creando productos digitales en la industria de la salud.
Proceso de desarrollo de software. metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.
Proceso de desarrollo de software. metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.
Софтуерни инструменти в Амазон, които използвамМихаил Великов
В моят онлайн базиран бизнес използвам няколко софтуерни инструмента. На уебинар, който правих преди време ме попитаха какви са те. Тази презентация минава през основните няколко.
Това са Google Sheets, MercheBee, JungleScout и AMZ Seller Browser.
How To Improve Lead Generation With Prospecting Brian Carroll
In our time-crunched economy, teleprospectors and inside sales are the driving forces behind B2B sales. As a new year kicks off, teleprospectors and inside sales reps are in the hot-seat with expectations to generate the real revenue that will lead their companies out of this economy. How ready are they to take over the controls? Will their old habits keep them from succeeding? Where do they need to pick up speed?
During this webinar, Brian Carroll CEO of InTouch invites Josiane Feigon, founder and CEO of TeleSmart Communications to show you fresh and new ideas that will help catapult marketing and sales efforts in the new year.
In this Webinar, you'll learn tips on:
* Cold Calling
* Email and Voice Mail Trends
* Getting out of the No-Po Zone
* Finding the Power Buyers
* Winning Qualification Criteria
* And much more...
Work para explicar la creación de una App Rails:
* Creando la aplicación Rails
* Utilizando el Scaffold
* Migrando la base de datos
* Agregando validaciones
* Agregando relaciones entre los modelos
* Utilizando Nested Routes
* Utilizando View Helpers
* Agregando AJAX
A complete manual of Perspective from 0 to 6 vanishing points, including the curvilinear perspective. Drawings are step by step, without long descriptions. There is also a 5 languages Dictionary and Terminology page. (Italiano, English, Español, Français, Deutsch). The book is 312 pages in 16 chapters.
drawing perspective, one point perspective, two point perspective, three-point perspective, perspective definition.
prospettiva accidentale, prospettiva centrale, prospettiva 1 punto di fuga, prospettiva 2 punti di fuga, prospettiva 3 punti di fuga, definizione prospettiva, manuale di prospettiva, disegno della prospettiva.
I know perfectly that many people could think: Hey guy, this stuff is only a dream, good for some sci-fi movies.
This general opinion is normal because so far we have seen electronics always opaque but, before show these project, I wanted to be sure they were feasible.
Well, if you read the ebook " A foldable world" - http://www.biodomotica.com/foldable-nanotech.htm - you will find that all this is true.
Most important universities, companies and research centers around the world are working on nanotechnology and on projects that I like: transparent electronics.
You don't need a Ph.D. in Physics to understand articles inside the ebook. At the end of reading you will begin to ask for a new foldable & transparent laptop ;-)
These devices are not yet available but are NOT sci-fi.
Printed electronics and nanotechnology will rules and changes the world before than you think.
Forget what have seen so far about electronic gadgets: printed electronics is coming with new unbelievable features.
This products will be thin, light, without wires, flexible, water-proof, shock resistant, low energy, solar recharge and recyclable.
This technology will be out of laboratory and completely available by a few years, so it’s not too early to think how the nanotechnology will change our life and how interact with invisible electronics.
Transparent and foldable electronic is a part of the coming printed electronics and these forecasts are my personal point of view:
Electronics should be user-friendly and eco-friendly, cheap and standard.
Some products will have only 2 dimensions. If you want 3rd dimension is possible use packaging technology (boxes) or glued printed electronics sheets or print directly on surfaces of 3d objects.
Philosophy of product designer is going to be more near to fashion designers or graphic designers:
products thought as dress, using ribbons and sheets.
Transparent and thin means not only invisible electronics but you can also customize it with your creativity.
Help and tutorial “how use it” are visible on the products’ surface.
With “artificial muscles” inside is possible move, vibrate or open printed sheets.
Using surface’s treatment like gecko's paws is possible shape or attach devices everywhere.
Solar nanocells recharge devices by sun or infrared rays.
Without wires for electric energy is possible use it everywhere.
Neither fall or water can damage our precious electronic friend.
Para nosotros la más importante es para que puedas dedicar ese tiempo a cosas que realmente importan como tu familia, hobbies o simplemente a descansar. Pero son muchas las razones sobretodo por salud, higuiene y recursos porque no todos disponemos de un equipo de profesionales formados con las mejores técnicas de limpieza y con maquinaria especializada.
2-2-17: Today Data & Society is releasing a new report – The Legacy of inBloom – which takes up these questions. Coauthors Monica Bulger, Patrick McCormick, and Mikaela Pitcan engaged in a year-long series of interviews and research to map the story of inBloom and its closure, which ignited a public discussion of student data privacy and has become the legacy any future edtech project will have to contend with.
Los Modelos Prescriptivos de Proceso definen un conjunto distinto de actividades, acciones, tareas, flujo de trabajo, fundamentos y productos de trabajo que se requieren para software de alta calidad.
Sesión 3: Modelos prescriptivos de proceso de softwareLuis Fernández
Los Modelos Prescriptivos de Proceso definen un conjunto distinto de actividades, acciones, tareas, flujo de trabajo, fundamentos y productos de trabajo que se requieren para software de alta calidad.
Docker es una de las tecnologías que más revolucionó el manejo de ambientes y despliegue de aplicaciones a gran escala. Veremos por qué es tan importante conocer esta tecnología para desarrolladores y administradores de infraestructura y cómo facilita aplicar prácticas de devops.
Durante la charla introduciremos la tecnología, como así tambien los casos prácticos sobre clustering, repositorios privados de imágenes y arquitectura productivas.
Gustavo Brey
Gustavo Andres Brey es Ingeniero en Sistemas de Información con más de 15 años de experiencia en la Industria IT. Actualmente es el CIO del Instituto Nacional de Servicios Sociales para Jubilados y Pensionados (INSSJP/PAMI), donde está impulsando un cambio de paradigma innovador en IT para la gestión de la salud pública Argentina. Desde 2004 es fundador y profesor de la materia Arquitectura de Proyectos de IT en la UTN- FRBA. A su vez es Co-Fundador de CONF4IT, una organización sin fines de lucro, que desarrolla conferencias agnósticas para distintas comunidades IT como ARQCONF y KIDSCONF. Participó en importantes conferencias de Tecnologías de la Información, Salud , Innovación, Open Source, Big Data, Arquitectura de Software, Gobierno y Datos Abiertos, así como de Hackathones.
Andrés Calabrese
Ingeniero en Sistema de Información con más de 11 años de experiencia tanto en puestos de liderazgo técnico en grandes empresas, como así también como CTO en varios emprendiendo tecnologicos como socio. Andrés comenzó su carrera en IBM, liderando proyectos complejos en diferentes tecnologías, a su vez promovió encuentros de colaboración técnica. Como CTO definió, planificó e implementó prácticas de Devops que permitieron guiar tecnologicamente a la compañía en términos metodológicos, de desarrollo e infraestructura.
Presentación de Ruby, destacando las características más interesantes del lenguaje desde un punto de vista cualitativo. Poco código en la presentación ya que va a ser usado con live coding con el IRB.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
3Redu: Responsabilidad, Resiliencia y Respetocdraco
¡Hola! Somos 3Redu, conformados por Juan Camilo y Cristian. Entendemos las dificultades que enfrentan muchos estudiantes al tratar de comprender conceptos matemáticos. Nuestro objetivo es brindar una solución inclusiva y accesible para todos.
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
5. Es un proceso de
aprendizaje, que va desde
la adquisición de un
conocimiento a la
representación del mismo.
6. 6
Arquitectura de Proyectos de IT
Características de una metodología
Cascada vs. Iterativo.
– Decision Momentum
Procesos bien definidos vs. aprovechamiento de las
habilidades y las interacciones entre las personas.
– Brain Work vs. No Brain Work
– Procesos definidos vs. Procesos intuitivos o internalizados
Procesos repetibles vs. adaptativos, eficiencia, mejora
continua.
Cuánto y qué tan formalmente documentar.
7. 7
Arquitectura de Proyectos de IT
Metodologías Iterativas - Desripción
El proyecto se divide en “iteraciones”, cuyo entregable es una
versión del sistema.
Todo está sujeto a ser modificado en las iteraciones
posteriores (planificación, análisis, diseño, código, etc).
En lugar de poner el énfasis en la eliminación de los errores,
se procura minimizar su impacto.
Se intenta aprovechar el aprendizaje durante el desarrollo.
Ideales para cuando los requerimientos no están del todo
claros en un comienzo o pueden sufrir modificaciones.
No confundir iterativo e incremental. Lo iterativo no
presupone o incremental, ni viceversa.
8. 8
Arquitectura de Proyectos de IT
Metodologías Iterativas - Motivaciones
En la actualidad, con frecuencia la extracción de
requerimientos es más costosa que la construcción.
Dinamismo o “apuro”. Muchas veces los requerimientos no
están definidos desde el comienzo, cambian durante el
desarrollo, pueden cometerse errores.
La complejidad en muchos sistemas hoy en día pasa más por
las interfaces de usuario que por la lógica de negocio.
No es tan sencillo manejar los requerimientos
independientemente de las posibilidades o restricciones
tecnológicas.
9. 9
Arquitectura de Proyectos de IT
Metodologías Iterativas
Ventajas
Más “realista”
Se adaptan mejor a los cambios
Permiten administrar mejor los riesgos
Mayor visibilidad para el cliente
Mejor feedback para el equipo de desarrollo
Desventajas
Falta de experiencia
Reacción al cambio de enfoque
Requieren de distintos modelos de contrato.
10. 10
Arquitectura de Proyectos de IT
Problemas de las metodologías secuenciales
Relación del costo de un cambio con metodologías secuenciales
11. 11
Arquitectura de Proyectos de IT
Problemas de las metodologías secuenciales
Como aplanar la curva utilizando técnicas ágiles
12. 12
Arquitectura de Proyectos de IT
Problemas de las metodologías secuenciales
Curva según Ken Beck (Creador de la metodologías ágil XP)
14. 14
Arquitectura de Proyectos de IT
Manifiesto agil
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando
a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
Individuos e interacción, por sobre los procesos y herramientas.
Software funcionando, por sobre documentación exhaustiva.
Colaboración con el cliente, por sobrenegociación contractual.
Responder a los cambios, por sobre del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
15. 15
Arquitectura de Proyectos de IT
Principios de las metodologías ágiles
Son iterativas. No intentan minimizar los cambios, sino estar
preparados para aceptarlos.
Son adaptativas en lugar de repetibles.
Incorporan feedback sobre el proceso.
Asegurar la calidad y la excelencia técnica desde el
inicio
Buscan minimizar el overhead metodológico.
16. 16
Arquitectura de Proyectos de IT
Prácticas claves
Requerimientos evolutivos
Planificación iterativa y adaptativa
Priorización por valor de negocio y por riesgo
Diseño y arquitectura emergentes
Deployment incremental
Timeboxing
Empowerment y auto-organización
17. 17
Arquitectura de Proyectos de IT
Prácticas de calidad
Test Driven Development
– Se escribe código productivo una vez que se tiene un test que
Falla
Pair Programming
– Toda línea de código productivo se escribe con dos personas en
una misma máquina => Revisión de código on-the-fly
Diseño simple y refactoring
– Diseñar el sistema tan simple como sea posible en cada
momento, eliminando complejidad innecesaria tan pronto como
sea identificada.
– Reestructurar el sistema sin cambiar su comportamiento para
eliminar duplicaciones, mejorar la legibilidad, la simplicidad y la
flexibilidad del código.
Estándares de codificación
– Reglas que permiten comprender y compartir el código entrelos
desarrolladores
18. 18
Arquitectura de Proyectos de IT
Integración continua
Build automatizado y auto-verificable
– El código incluye un suite de tests automatizados que
buscan detectar bugs
– Los tests pueden ser ejecutados con un simple comando y
verifican automáticamente los resultados
– Si alguno de los tests falla, todo el build falla
Servidor de integración continua:
– Ante cada commit dispara un build auto-verificable
– Permite detectar y eliminar los bugs tan pronto como son
introducidos
19. 19
Arquitectura de Proyectos de IT
Manejo de Riesgos en Metodologías Ágiles
Retrasos y cancelaciones
Altos costos de mantenimiento
Gran cantidad de defectos
Falta de entendimiento del negocio
Cambios en el negocio
Requerimientos “volados”
Arquitectura y diseño “volados”
Inestabilidad de personal
20. 20
Arquitectura de Proyectos de IT
¿Cuándo Elegir las Metodologías Ágiles?
Los requerimientos son poco claros o altamente volátiles.
El cliente entiende el proceso y está involucrado en el
proyecto.
Se cuenta con profesionales capacitados y competentes
Se tienen canales ricos de comunicación
El grupo de trabajo no es demasiado grande (~ 50)
Se desea fomentar la mejora continua del proceso
21. 21
Arquitectura de Proyectos de IT
Rol del Arquitecto en un Proyecto Iterativo
Toma de decisiones en todo momento
Necesidad de construir arquitecturas que
evolucionen
Prácticas de Calidad (TDD, Integración Continua,
etc)
Tiene sus propios pasos en la iteración
Entender/seleccionar los requerimientos
Crear/Actualizar la arquitectura
Comunicarla constantemente
Evaluarla con los stakeholders
Verificar su implementación
23. 23
Arquitectura de Proyectos de IT
Material Complementario
Ejemplos de Metodologías Agiles
– Scum
– eXtreme Programming
24. 24
Arquitectura de Proyectos de IT
Scrum – Fases de un proyecto
Planeamiento
Arquitectura o diseño de alto nivel
Desarrollo (sprints)
– Sprint Planning
– Daily Work
– Sprint Review
Cierre
25. 25
Arquitectura de Proyectos de IT
Scrum – Planeamiento
Definir el backlog del producto.
Determinar los próximos releases (objetivos y
fechas).
Determinar los objetivos y el equipo para el primer
release.
Analizar los riesgos.
Revalidar o ajustar las herramientas e
infraestructura.
Estimar el costo del release.
Verificar la aprobación del management.
26. 26
Arquitectura de Proyectos de IT
Scrum - Arquitectura o diseño de alto nivel
Identificar los cambios necesarios para implementar
el backlog.
Extender o actualizar el modelo de dominio.
Refinar la arquitectura para soportar los nuevos
requerimientos.
Plantear la estrategia para encarar cada item del
backlog.
Revisar cada diseño y reasignar tareas si es
necesario.
27. 27
Arquitectura de Proyectos de IT
Scrum – Desarrollo
Ciclo de desarrollo iterativo
“Concurrent Engineering”
Sprint Planning
En cada sprint se realizan las siguientes tareas:
– Desarrollo (análisis, diseño, programación, testing y
documentación)
– Empaquetado y despliegue
– Revisión
– Ajustes
Sprint Review
28. 28
Arquitectura de Proyectos de IT
Scrum – Cierre
Se cierra el release.
Pruebas de integración
Pruebas de sistema
Documentación para el usuario
Preparación del material de entrenamiento
29. 29
Arquitectura de Proyectos de IT
Scrum – Vista global del proceso
Product Backlog Increment
Sprint Planning Meeting
Daily Scrum
Daily Work
Sprint Goal
Sprint Backlog
Blocks List
Product
Sprint Review Meeting
Sprint:
2 weeks
Product Backlog’
Increment’
30. 30
Arquitectura de Proyectos de IT
Scrum
Roles
Product Owner
Scrum Master
Team
StakeHolders
Artefactos clave
Product Backlog
Sprint Goal
Sprint Backlog
Blocks List
Increment
Reuniones clave
Sprint Planning
Daily Scrum
Sprint Review
31. 31
Arquitectura de Proyectos de IT
Scrum – Reuniones
Sprint Planning
–Seleccionar los items de mayor prioridad en el Product Backlog
–Determinar el Sprint Goal
–El equipo determina el Sprint Backlog
Scrum
–Habla cada desarrollador del equipo:
–¿Qué hiciste ayer?
–¿Qué vas a hacer hoy?
–¿Qué cosas te traban?
–Se actualiza el Sprint Backlog y el Blocks List
Sprint Review
–Demostración y discusión del incremento
Las tres reuniones son manejadas por el ScrumMaster
32. 32
Arquitectura de Proyectos de IT
Scrum – Artefactos
Backlog: Funcionalidades aún no cubiertas en el release actual. Bugs, defectos,
mejoras, etc.
Release: Conjunto de items del backlog que representan un entregable con
fecha.
Packet: Conjunto de componentes u objetos que deben se modificados para
implementar un item del backlog.
Changes: Cambios que deben ocurrir para implementar un item del backlog.
Problems: Problemas técnicos que deben ser resueltos para implementar un
cambio.
Risks.
Solutions: Respuestas a los problemas y riesgos, generalmente resultando en
cambios.
Issues: Cualquier otra cuestión del general al proyecto no descripta en
términos de paquetes, cambios y problemas.
33. 33
Arquitectura de Proyectos de IT
Scrum – Ventajas
Evita estancamientos en el proyecto
Seguimiento del proyecto
Seguimiento del equipo
SW que incrementa su funcionalidad en cada sprint
Mecanismos de control para variables cambiantes con el
entorno
Progreso en el producto con requerimientos inestables
Aumenta comunicación con el equipo
Cliente obtiene feedback frecuente sobre el producto
35. 35
Arquitectura de Proyectos de IT
XP – Estrategia de planificación
Planning Game
– El equipo de desarrollo estima
– El cliente prioriza
Whole Team
– El cliente participa del equipo de desarrollo
– Debe estar disponible siempre
Small Releases
User stories
– El usuario…
– Desea…
– Para así poder…
Metrics
36. 36
Arquitectura de Proyectos de IT
XP – Estrategia de diseño
Principios
– Baja inversión inicial
– Asumir simplicidad
– Crecimiento gradual – pasos pequeños
– No sobrediseñar (“travel light”)
Prácticas
– System Metaphor
– Simple Design
– Refactoring
– Test Driven Development
37. 37
Arquitectura de Proyectos de IT
XP – Otras prácticas
Pair Programming
Collective Code Ownership
Continuous Integration
Coding Standards
Sustainable Pace
39. 39
Arquitectura de Proyectos de IT
XP – Elementos de una iteración
Planning Game – recolección de user stories
Estimación – hecha por el desarrollador en base a
analogía o prototipado
Metáfora – vocabulario común del sistema
Diseño Simple – en XP el código fuente es el diseño
Tests de aceptación
Refactoring
Integración
40. 40
Arquitectura de Proyectos de IT
XP - Críticas
No escalable
Altos riesgos si existen fallas en la arquitectura
Altos riesgos si no hay capacidad/estabilidad en las
personas
La programación de a pares es un intento por
solventar la falta de análisis
Puede caer en el modelo de codificar y probar
Vagas nociones de aseguramiento de la calidad
Fuerte tendencia a no documentar
41. 41
Arquitectura de Proyectos de IT
Bibliografía
[PlanningXP] Kent Beck, Martin Fowler , Planning Extreme
Programming. Addison Wesley, 2000, ISBN 0-201-71091-9.
[XPExplained] Kent Beck, Extreme Programming Explained,
Addison-Wesley, 1999, ISBN 0201616416
[MythicalMM] Fred Brooks, The Mythical Man-Month,
Addison-Wesley, 1995, ISBN 0201835959
[PMMethodolgies] Jason Charvat, Project Management
Methodologies, JOHN WILEY & SONS, INC., 2003, ISBN
0-471-22178-3
[AbySoft]
http://www.agilemodeling.com/essays/costOfChange.htm
Notas del editor
Incremental development is a scheduling and staging strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed. It does not imply, require nor preclude iterative development or waterfall development - both of those are rework strategies. The alternative to incremental development is to develop the entire system with a "big bang" integration.
Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. It does not presuppose incremental development, but works very well with it. A typical difference is that the output from an increment is not necessarily subject to further refinement, and its' testing or user feedback is not used as input for revising the plans or specifications of the successive increments. On the contrary, the output from an iteration is examined for modification, and especially for revising the targets of the successive iterations.
The two terms were merged in practical use in the mid-1990s. The authors of the Unified Process (UP) and the Rational Unified Process(RUP) selected the term "iterative development", and "iterations" to generally mean any combination of incremental and iterative development. Most people saying "iterative" development mean that they do both incremental and iterative development. Some project teams get into trouble by doing only one and not the other without realizing it.
I’ll give you a minute to read the cartoon strips…
We are not using Agile or Lean to get rid of people, that’s not our definition of lean.
We aren’t throwing away all documentation and process.. This is a disciplined agile approach.
We are providing training!
Typical objections, among others:
I don’t know what you mean by “agile”
I’ve seen “agile” used just as an excuse to do anything you want
Agile doesn’t scale
Agile can’t work across sites
Agile techniques will result in lower quality
Agile is unproven
Agile is a huge cultural transformation that doesn’t warrant the investment
Agile approaches are not CMMI compliant
Business management processes prevents me from doing agile
Typical objections, among others:
I don’t know what you mean by “agile”
I’ve seen “agile” used just as an excuse to do anything you want
Agile doesn’t scale
Agile can’t work across sites
Agile techniques will result in lower quality
Agile is unproven
Agile is a huge cultural transformation that doesn’t warrant the investment
Agile approaches are not CMM compliant
Business management processes prevents me from doing agile