Un desarrollo lento afecta a todos los implicados en el proceso de desarrollo de software, incluidos clientes, desarrolladores, usuarios finales y directivos. Todos los equipos de desarrollo de software quieren resolver este gran problema: cómo aumentar la velocidad de desarrollo y, al mismo tiempo, tener bajo control los apretados calendarios de desarrollo. En Desarrollo rápido, escrito por Steve McConnell, el autor hace hincapié en las ideas de desarrollo eficaz examinando las estrategias de desarrollo rápido y estudiando los errores clásicos en la circunstancia de los fundamentos del desarrollo de software y la gestión de riesgos. Desmenuza las cuestiones fundamentales del desarrollo rápido, la planificación del ciclo de vida, la estimación y la programación.
¿CÓMO NOS HA AYUDADO ESTE LIBRO?
El Desarrollo Rápido nos mostró cómo aumentar la velocidad de desarrollo del software y describió los límites de velocidad de desarrollo para ayudarnos a tener una base firme para distinguir entre programas de mejora realistas y fantasías ilusorias.
EL LIBRO EXPLICADO EN MENOS DE 60 SEGUNDOS
El camino trazado en este libro es el menos transitado en la industria actual. Este libro analiza cómo los equipos de desarrollo de software pueden aumentar la velocidad del desarrollo de software, permitiéndole entregar software más rápidamente. El desarrollo rápido también destaca las prácticas que hacen visible el progreso, permitiéndole disipar la apariencia de un desarrollo lento.
LAS TRES MEJORES CITAS
«Elija sus batallas. Si el desarrollo rápido es una prioridad máxima, no encadene a sus desarrolladores insistiendo en demasiadas prioridades simultáneamente.»
«Incluso si hace algunas cosas bien, como hacer un uso elevado de las prácticas de programación modernas, puede cometer un error que anule sus ganancias de productividad».
«Un estudio tras otro ha demostrado que la motivación tiene probablemente un mayor efecto sobre la productividad y la calidad que cualquier otro factor».
RESÚMENES Y PUNTOS DESTACADOS DEL LIBRO
PARTE I: DESARROLLO EFICAZ
Capítulo 1 Bienvenido al desarrollo rápido
Qué es el desarrollo rápido
Para algunos, el desarrollo rápido implica aplicar una única herramienta o método favorito. Los hackers se refieren a esto como escribir código durante 36 horas seguidas. Para un ingeniero informático, RAD combina una implicación exhaustiva del usuario, herramientas CASE y plazos ajustados. Todos estos métodos y herramientas son ideales y pueden contribuir plenamente a aumentar la velocidad de desarrollo. Según el libro, Desarrollo rápido es una frase descriptiva que significa desarrollar software más rápido que con los enfoques habituales. Un proyecto de desarrollo rápido es cualquier proyecto que necesite poner su énfasis en la velocidad de desarrollo. En la actualidad, muchos proyectos entran dentro de esa descripción.
Lograr un desarrollo rápido
Para conseguir un desarrollo rápido, debe tener en cuenta estos dos aspectos: la selección de prácticas eficaces frente a las ineficaces y la selección de técnicas orientadas a objetivos. La velocidad de desarrollo suele depender de las prácticas de desarrollo establecidas. La rapidez con la que diseñe un producto concreto vendrá determinada por la medida en que seleccione técnicas eficaces y orientadas a la programación. Existen tres prácticas orientadas al cronograma: Prácticas orientadas a la velocidad, Prácticas orientadas al riesgo del cronograma y Prácticas orientadas a la visibilidad. Sus inquietudes sobre la velocidad de desarrollo determinan el tipo de prácticas orientadas a la programación que elija. Si cree que debe aumentar su velocidad de desarrollo, céntrese en las prácticas orientadas a la velocidad. Si prevé que su velocidad está bien, pero que el problema es la percepción de su ritmo por parte del cliente, entonces oriente su atención hacia las prácticas orientadas a la visibilidad.
Capítulo 2: Estrategia de desarrollo rápido
Estrategia general de desarrollo rápido
El desarrollo rápido puede lograrse siguiendo una estrategia de cuatro partes. Las cuatro partes son: evitar los errores clásicos, aplicar los fundamentos del desarrollo, gestionar los riesgos para evitar contratiempos catastróficos y aplicar prácticas orientadas al calendario. Disponga de todos los pilares y hágalos lo más sólidos posible. Los tres primeros pilares determinan en gran medida su potencial para lograr el mejor calendario. Los tres primeros pilares proporcionan el apoyo necesario para lograr el mejor calendario posible. No el apoyo ideal, quizá, pero sí la mayor parte de lo necesario. Es posible que pueda lograr un horario óptimo sin prácticas orientadas al horario.
Cuatro dimensiones de la velocidad de desarrollo
Tanto si trabaja despacio para evitar errores como si se mueve a gran velocidad con las mejores prácticas orientadas a la programación. Su proyecto de software funciona con la ayuda de cuatro dimensiones esenciales: proceso, personas, producto y tecnología. En primer lugar, las personas son el factor que más influye en el desarrollo, la productividad y la calidad del software. Está claro que cualquier empresa que quiera mejorar la productividad debe considerar en primer lugar las cuestiones relacionadas con las personas. En segundo lugar, el proceso de desarrollo de software incluye metodologías tanto técnicas como de gestión. Centrarse en los procesos aumenta la garantía de calidad, ayuda en la gestión de riesgos y permite evitar la reelaboración. Producto: es la dimensión más tangible. Centrarse en el tamaño y las características del producto presenta enormes oportunidades de reducción de plazos. Si puede reducir el conjunto de características de un producto, podrá reducir su calendario. Por último, la tecnología: cuando cambie sus herramientas tecnológicas, lo más probable es que mejore su velocidad de desarrollo. Puede cambiar de medios menos eficaces a herramientas más productivas.
Capítulo 3: ¿Qué dimensión importa más?
Analice su proyecto para determinar cuáles de las cuatro dimensiones son limitadas y cuáles puede aprovechar al máximo. A continuación, extienda cada una de ellas al máximo. Esa es, en pocas palabras, la clave del éxito del desarrollo rápido.
Cita favorita de la parte: «La primera conclusión es que ahora sabemos con certeza que las cuestiones relacionadas con las personas tienen más impacto en la productividad y la calidad del software que cualquier otro factor».
PARTE II: DESARROLLO RÁPIDO
Capítulo uno: ¿Una talla única para todos?
Diferentes proyectos tienen diferentes requisitos de desarrollo rápido, incluso cuando todos necesitan desarrollarse «lo más rápido posible». Por lo general, los productos que se distribuyen ampliamente deben diseñarse con más cuidado que los productos que se distribuyen poco. Los productos con una fiabilidad crítica deben desarrollarse con más cuidado que los productos cuya fiabilidad es secundaria. Esto implica que debe personalizar una solución que se adapte a su situación.
¿Qué tipo de desarrollo rápido necesita?
La esencia del desarrollo rápido gira en torno a determinar qué tipo de enfoque de desarrollo rápido desea. ¿Se trata de una ligera ventaja en velocidad, una mejor visibilidad del progreso, un coste más bajo o una mayor previsibilidad? Mucha gente cree que necesita un desarrollo rápido, pero en realidad lo que necesita son precios más bajos y más previsibilidad o un enfoque que evite un fracaso trágico. Para determinar qué tipo de desarrollo rápido necesita, hágase estas preguntas;
- ¿Cómo de fuerte es la restricción de calendario del producto?
- ¿El énfasis del proyecto en el calendario se debe a que se trata de un parecido común al desarrollo rápido?
- ¿Está el proyecto limitado por algún punto débil que impida un rápido éxito de desarrollo?
Los productos que tienen que centrarse en la velocidad de desarrollo más que en el coste o la previsibilidad tienen un valor temporal diferente en comparación con los productos típicos. A medida que pasa el tiempo, el valor de los productos específicos suele reducirse gradualmente. Pero para los productos con sólidas limitaciones de calendario, hay un punto en el que disminuyen precipitadamente.
Antes de orientar su proyecto hacia el calendario más corto en lugar de hacia el menor coste, el mínimo riesgo o el mejor rendimiento, descubra qué es lo que se necesita. Los parecidos al desarrollo rápido exigen una velocidad de desarrollo sin límites, pero exigen algo más.
Capítulo 2: Planificación del ciclo de vida
Un modelo de ciclo de vida es un modelo prescriptivo de lo que ocurre entre el primer destello y el último suspiro. Todo esfuerzo de desarrollo de software pasa por un ciclo de vida que comprende todas las actividades entre el principio y el final. El modelo de ciclo de vida más familiar es el conocido modelo de ciclo de vida en cascada, que tiene algunas
debilidades igualmente notables. Existen otros modelos de ciclo de vida y, en muchos casos, son mejores opciones para el desarrollo rápido que el modelo en cascada.
Cascada pura
El modelo de cascada es la base de otros modelos de ciclo de vida eficaces, ya que está asociado a muchos problemas. En el modelo de cascada, un proyecto avanza en un curso ordenado de pasos desde el concepto inicial del software hasta la prueba del sistema. Al final de cada fase, se revisa el proyecto para determinar si está en condiciones de avanzar al siguiente paso, desde el análisis de requisitos hasta el diseño arquitectónico. Si la revisión esboza que el proyecto no está preparado para pasar a la siguiente fase, permanece en el paso actual hasta que esté listo.
Code-and-Fix
El modelo de código y reparación es estándar pero podría ser más útil. Si no ha seleccionado otro modelo de ciclo de vida, deberá utilizar código-y-fijación por defecto. Utilizar el modelo de código y corrección significa empezar con una idea general de lo que quiere crear. Puede tener una especificación formal o no. A continuación, utilice a su conveniencia cualquier combinación de metodologías informales de diseño, código, depuración y prueba hasta que tenga un producto listo para su lanzamiento. Este modelo no tiene sobrecarga, lo que significa que no dedicará tiempo a la planificación, la garantía de calidad o la documentación aparte de la codificación. También requiere poca experiencia. Cualquiera que esté familiarizado con los programas informáticos puede utilizar el modelo de «codificar y corregir».
Espiral
Este modelo descompone un proyecto de software en miniproyectos y está muy orientado a los riesgos. Cada miniproyecto aborda riesgos significativos hasta que no queda ningún riesgo que gestionar. El riesgo en este contexto se refiere a requisitos incompetentes, problemas de rendimiento, arquitectura mal entendida y muchos más. En cuanto se han gestionado los riesgos, el modelo en espiral termina como el modelo en cascada. En el modelo en espiral, se empieza a pequeña escala en el centro de la espina dorsal, se identifican e inspeccionan todos los riesgos, se formula un plan para controlar los riesgos y, por último, se compromete un enfoque para la siguiente iteración. El modelo en espiral proporciona al menos tanto control de gestión como el modelo tradicional en cascada. Dispone de puntos de control al final de cada iteración. Como el modelo está orientado al riesgo, proporciona indicaciones tempranas de cualquier riesgo insuperable.
Capítulo 3: Estimación
La estimación de software es bastante compleja. Los altos y bajos directivos, los clientes y algunos desarrolladores no entienden por qué la estimación es tan difícil. La historia básica de la estimación de software es que el desarrollo de software es un proceso de refinamiento gradual. Se empieza con una imagen borrosa de lo que se quiere construir y luego se pasa el resto del proyecto intentando aclarar esa imagen. Dado que la imagen del software que intenta desarrollar es borrosa, la estimación del tiempo y el esfuerzo necesarios para construirlo también lo es. La previsión sólo puede enfocarse junto con el propio software, lo que significa que la estimación del proyecto de software es también un proceso de refinamiento gradual.
Capítulo 4: Programación
Programación excesivamente optimista
Los calendarios de programación excesivamente optimistas son una tradición desvaída en el desarrollo de software. Todas las cuestiones esenciales de programación son urgencias y muchos proyectos de software necesitan más tiempo de calendario. La presión excesiva del calendario es la influencia más destructiva en el software. La mayoría de los proyectos establecen sus calendarios antes de que se fijen los requisitos y no los establecen sin tiempo de sobra. Las causas de los calendarios excesivamente optimistas son profundas e incluyen; Los directores o los clientes se niegan a aceptar una serie de estimaciones y hacen
planes basados en una única estimación del «mejor de los casos». Los directivos y promotores subestiman deliberadamente el proyecto porque quieren un reto o les gusta trabajar bajo presión. La dirección o los comerciales subestiman deliberadamente el proyecto para presentar una oferta ganadora.
Vencer la presión del calendario
La presión de los plazos es endémica en el desarrollo de software y ha generado un pensamiento negativo a corto plazo. Uno, ha fomentado la toma de atajos en determinados proyectos, lo que ha dado lugar a una entrega deficiente. Dos, ha impulsado una mentalidad de apagafuegos sobre la propia presión de los calendarios. No podemos resolver el problema del desarrollo rápido hasta que resolvamos el problema de la presión del calendario.
Cita favorita del capítulo: «Todo esfuerzo de desarrollo de software pasa por un «ciclo de vida», que consiste en todas las actividades entre el momento en que la versión 1.0 de un sistema comienza su vida como un brillo en los ojos de alguien y el momento en que la versión 6.74b finalmente da su último suspiro en la máquina del último cliente.»
TERCERA PARTE: MEJORES PRÁCTICAS
Capítulo uno: Junta del cambio
Este enfoque controla los cambios realizados en un proyecto de software. Una junta de cambios integra a representantes de desarrollo, documentación de usuario, control de calidad, atención al cliente, gestión y marketing, otorgándoles autoridad suprema para aceptar y rechazar los cambios sugeridos. Este enfoque contribuye a un desarrollo rápido al minimizar el número de cambios incontrolados en el producto y aumentar la visibilidad de la fluencia de características. Los tableros de cambios pueden ponerse en juego en cualquier tipo de entorno.
Capítulo 2: Construcción diaria y prueba de humo
Mediante el proceso Daily Build and Smoke Test, un producto de software se construye cada día y se prueba varias veces para verificar sus operaciones primarias. Este proceso puede instituirse cuando el proyecto ya ha comenzado. Este proceso minimiza los riesgos de retraso, la escasa visibilidad del progreso y la integración fallida. El proceso proporciona un control crítico para los proyectos en modo de recuperación. Su éxito depende de que los desarrolladores se tomen en serio el enfoque y de que se realicen pruebas de humo bien diseñadas. La construcción diaria y las pruebas de humo pueden utilizarse eficazmente en proyectos de prácticamente cualquier tamaño y complejidad. La idea que subyace en el proceso de construcción diaria y prueba de humo es sencilla: construya el producto y pruébelo a diario.
Capítulo 3: Diseñar para el cambio
Diseñar para el cambio es una aplicación exhaustiva que engloba numerosas prácticas de diseño orientadas al cambio. Para que estas prácticas sean eficaces, deben aplicarse durante las primeras fases del ciclo de vida del software. El éxito de este enfoque depende de que se identifiquen los cambios adecuados, se desarrolle un plan de cambios y se oculten las decisiones de diseño para que los cambios no se propaguen por el programa. Algunas de las prácticas de diseño orientado al cambio son más complejas de lo que la gente prevé. Cuando se aplican correctamente, estas prácticas sientan las bases de programas longevos y de una flexibilidad que minimiza los efectos en el calendario de las solicitudes de cambio de última hora. Diseñar para el cambio» no se refiere a una única metodología de diseño, sino a una panoplia de prácticas de diseño que contribuyen a lograr diseños de software flexibles.
Capítulo 4: Entrega evolutiva
La entrega evolutiva es un modelo de ciclo de vida que equilibra el control de la entrega por etapas y la flexibilidad de los prototipos evolutivos. Proporciona su ventaja de desarrollo rápido al entregar partes seleccionadas del software antes de lo posible, pero no entrega necesariamente el producto final más rápido. Ofrece cierta capacidad para cambiar la dirección del producto a mitad de camino en respuesta a las peticiones de los clientes. La entrega evolutiva se ha utilizado con éxito en software empresarial interno y en software retractilado. Si se utiliza con cuidado, puede conducir a una mejora de la calidad del producto, una reducción del tamaño del código y una distribución más uniforme de los recursos de desarrollo y pruebas. Al igual que otros modelos de ciclo de vida, la Entrega Evolutiva es una práctica de todo el proyecto: si quiere utilizarla, debe empezar a planificar su uso en las primeras fases del proyecto.
Cita favorita del capítulo: «Demasiadas horas extraordinarias y la presión del calendario pueden dañar un desarrollo
horario, pero un poco de horas extra puede aumentar la cantidad de trabajo realizado cada semana y mejorar la motivación».
CÓMO PUEDE AYUDAR ESTE LIBRO A LOS DESARROLLADORES DE SOFTWARE
«Desarrollo rápido», de Steve McConnell, es una completa guía para desarrolladores de software que ofrece consejos prácticos y técnicas para aumentar la velocidad y la eficacia del proceso de desarrollo de software. El libro abarca diversos temas como la planificación del proyecto, la recopilación de requisitos, el diseño, la codificación, las pruebas y la gestión del proyecto. El libro también analiza las mejores prácticas y estrategias para gestionar el riesgo, reducir los errores, mejorar la comunicación y aumentar la calidad general de los proyectos de desarrollo de software. McConnell se basa en su amplia experiencia en este campo y proporciona numerosos ejemplos del mundo real para ilustrar sus puntos. En conjunto, «Desarrollo rápido» es un valioso recurso para los desarrolladores que deseen mejorar su productividad y la calidad de su trabajo. El libro ofrece consejos prácticos y procesables para ayudar a los desarrolladores de todos los niveles a ser más eficaces y eficientes.
