Desarrollo de software. Kent Beck. El software es así y lo tienen que entender y aceptar todas las partes
El enfoque de planifico todo el proyecto, realizo todo el análisis y después diseño, construyo e implanto está todavía presente en una gran cantidad de personas de nuestra industria.
Muchos desarrolladores recién llegados ven el proceso de desarrollo con ese enfoque, sin embargo el problema no son ellos, tienen todavía mucho tiempo para cambiar, sino personas que se dedican a esto desde hace mucho tiempo y que, como suele pasar en las organizaciones, con el paso de los años han alcanzado responsabilidades directivas.
Quien se ha criado en metodologías clásicas, quien ha trabajado durante muchos años con ellas le resulta muy complicado cambiar sobre todo si se está alejado ya del día a día de los proyectos de desarrollo de software. Con el paso del tiempo todo se idealiza, algo que además si no tiene mucho espíritu crítico te puede llevar a pensar que realmente no fueron tan mal todos esos proyectos en los que trabajaste y que utilizaron enfoques clásicos.
Por otro lado, en el área usuaria o funcional, el enfoque de los proyectos en los que trabajan que serán en su mayoría no software también será, por regla general, de tipo totalista, es decir, contrato un trabajo, lo ejecutas de una vez y adiós.
La aplicación de enfoques ágiles se encuentra con esta resistencia, personas que no terminan de entender por qué aplicas esa estrategia, personas que se sienten más cómodas trabajando sobre una planificación general, independientemente de que la misma nunca se cumpla o que el producto final se parezca bien poco a las expectativas que se tenían sobre el mismo.
Para que proyectos con este enfoque puedan llevarse a cabo es fundamental que todas las partes implicadas en él entiendan, comprendan y compartan que esta forma de entender el desarrollo de software es la que mejor se adapta a su incertidumbre inherente y por tanto, es la que de forma más probable te llevará al cumplimiento de los objetivos.
En general, apliques la metodología que apliques es fundamental que todas las partes remen en la misma dirección, de lo contrario a las resistencias que te vas a encontrar en el propio proceso de desarrollo tendrás que sumarle que estaréis solos tu equipo y tú para poder vencerlas y que las otras partes, por regla general, lo que harán será sumar más resistencia.
Kent Beck, describe todo esto de la siguiente manera: «El software es inherentemente poco fiable y los clientes están condicionados a aceptarlo. Los desarrolladores están condicionados a aceptarlo. Los testers están condicionados a aceptarlo».
Jummp 
El software es inherentemente poco fiable.
No estoy para nada de acuerdo con este hombre. ¿Acaso piensa lo mismo cuando conduce su coche, sube a un avión o se hace una radiografía?
Si la mayoría del software convencional es una basura, es porque se ha hecho a patadas y sin usar ningún tipo de ingeniería. Y por gente mediocre o poco cualificada.