El libro "Ágil puro. Los fundamentos de la flexibilidad

Hola habrozhiteli! ¡Hemos entregado a la imprenta otra novedad! Han pasado casi veinte años desde que apareció el Manifiesto Ágil. El legendario Robert Martin (tío Bob) se dio cuenta de que era hora de sacudirse el polvo de los principios de Agile y, nuevamente, hablar sobre el enfoque flexible no solo para la nueva generación de programadores, sino también para especialistas de otras industrias. El autor de los libros "Código limpio", "Programador ideal", "Arquitectura limpia", que fue amado por la gente de TI, se originó en Agile. Pure Agile elimina el malentendido y la confusión que, a lo largo de los años de existencia de Agile, han hecho que sea más difícil de usar que el plan original. En esencia, Agile es solo una pequeña selección de métodos y herramientas que ayuda a pequeños equipos de programadores a gestionar pequeños proyectos, ... pero conduce a excelentes resultados,porque cada proyecto importante consiste en una gran cantidad de ladrillos. Cinco décadas de trabajo con proyectos de todos los tipos y tamaños imaginables le permiten al tío Bob mostrar cómo debería funcionar realmente Agile. Si desea comprender los beneficios de Agile, no busque formas fáciles: debe usar Agile correctamente. Pure Agile le dice cómo hacer esto para desarrolladores, probadores, gerentes, gerentes de proyectos y clientes.

Extracto. Lo primero que debes saber

¿Qué es lo primero que necesita saber sobre el proyecto? Antes de averiguar el nombre del proyecto o los requisitos para el mismo, antes de realizar ningún movimiento, necesita obtener más información. Por supuesto, estos son los plazos. Después de seleccionar las fechas, deben corregirse. No tiene sentido discutir los términos, porque se establecen en relación con razones comerciales objetivas. Si se debe septiembre, no es solo eso. Quizás en septiembre se planee algún tipo de exhibición o reunión de accionistas, o quizás los fondos simplemente se agoten. Cualquiera sea la razón, tiene algunos antecedentes importantes. Y la razón no cambiará simplemente porque para algunos de los desarrolladores el volumen de tareas parece abrumador.

Al mismo tiempo, los requisitos pueden cambiar en una secuencia continua que no se puede arreglar.

Y también hay una razón para esto: los clientes a menudo no saben exactamente lo que quieren. Parecen saber qué problema necesitan resolver, pero traducir ese conocimiento en los requisitos del proyecto siempre es difícil. Por lo tanto, hay una constante reevaluación y replanteamiento de los requisitos. Se añaden nuevas funciones.

Algunos viejos desaparecen. La interfaz de usuario cambia rápidamente, en semanas, si no en días.

Así es como se ve el mundo del desarrollo de software. En este mundo, los plazos son fijos y los requisitos cambian constantemente. Y de alguna manera, en el contexto de todo esto, los desarrolladores deben completar con éxito el proyecto.

Colección

El modelo en cascada nos profetizó una forma de evitar esta tarea. Para explicar cuán seductor e ineficaz fue al mismo tiempo, citaré una reunión como ejemplo.

Era el primero de mayo. El gran jefe llamó a los subordinados a la sala de conferencias.

El jefe comenzó: “Tenemos un nuevo proyecto. Es necesario terminarlo antes del primero de noviembre. No tenemos requisitos todavía. Nos serán anunciados en las próximas dos semanas. ¿Cuánto tiempo llevará analizar el proyecto?

Comenzamos a mirarnos inquisitivamente. Todos callaron, temerosos de decir demasiado. Nadie tenía idea de qué responder. Alguien murmuró: "Entonces, no tenemos requisitos, ¿de qué debemos comenzar?"

¡Imagina que lo son! Gritó el jefe. "Sabes cómo funciona todo". ¡Sois expertos! No necesito fechas exactas. Solo necesito completar el horario de alguna manera. Tenga en cuenta que si lleva más de dos meses, puede olvidarse con confianza del proyecto ".

Alguien murmuró inquisitivamente: "¿Dos meses?" El jefe lo tomó de acuerdo con las condiciones: “¡Genial! Justo lo que estaba pensando. ¿Ahora dime cuánto cuesta el diseño?

Y de nuevo todos se quedaron atónitos, la sala se llenó de silencio. Nosotros contamos. Y nos damos cuenta de que hasta el primero de noviembre solo seis meses. La conclusión se sugiere a sí misma. "¿Dos meses?" - usted pregunta.

"¡Así es! - el gran jefe sonrió radiantemente. - Como yo pensaba. Y nos quedan dos meses para la implementación. ¡Gracias a todos, sois libres! "
Muchos lectores probablemente recordaron que algo así ya les sucedió. ¿Quién no tenía esto, bueno, tienes suerte!

Etapa de análisis

Entonces, supongamos que dejamos la sala de conferencias y nos dispersamos por las oficinas. ¿Qué hacer a continuación? Comienza la fase de análisis, lo que significa que debe analizar algo. Pero, ¿qué llamamos exactamente análisis?

Si lee libros sobre el tema de análisis en el desarrollo de software, encontrará que cada autor da su propia definición. No hay consenso sobre qué es el análisis. Puede ser la creación de una descomposición estructural de requisitos. O tal vez: detección y especificación de requisitos. Puede ser la creación de un modelo u objeto de datos fundamentales, y así sucesivamente ... La mejor definición de análisis es esta: eso es lo que hacen los analistas.

Por supuesto, hay cosas obvias. Necesitamos evaluar el tamaño del proyecto, para pronosticar indicadores de los principales recursos técnicos, económicos y humanos. Debe asegurarse de que el horario de trabajo sea factible. Este es el más pequeño que la compañía esperará de nosotros. Como se llame análisis, esto es exactamente lo que íbamos a hacer en los próximos dos meses.

Esta es una especie de fase favorable del proyecto. Todos navegan tranquilamente por Internet, realizan pequeñas transacciones, se reúnen con clientes y usuarios, dibujan hermosos gráficos, simplemente, se divierten.

Luego, el primero de julio sucede un milagro. El análisis está completo.

¿Por qué pensamos eso? Porque ya es el primero de julio. Si, de acuerdo con el cronograma, la etapa de análisis debe completarse el primero de julio, entonces esta etapa se completa el primero de julio. No llegamos tarde, ¿verdad? Por lo tanto, organizaremos una pequeña fiesta con globos y discursos ardientes, celebraremos nuestra transición de la etapa de análisis a la etapa de diseño.

Fase de diseño

¿Qué hacer ahora? Por supuesto, diseñaremos. ¿Pero qué es el diseño ?

Sabemos un poco más sobre la fase de diseño de software. En esta etapa, dividimos el proyecto en módulos separados y diseñamos las interfaces entre estos módulos. En esta etapa, también asumimos cuántos equipos necesitaremos y cómo estos equipos estarán interconectados. En general, es necesario aclarar el cronograma de trabajo para elaborar un plan de implementación factible y plausible.

Por supuesto, en esta etapa, algo cambia inesperadamente. Se añaden nuevas funciones. Las viejas funciones desaparecen o se ajustan. Y sería bueno mirar hacia atrás y analizar los cambios nuevamente, pero el tiempo es dinero. Por lo tanto, estamos intentando de todas las formas posibles realizar cambios en el diseño.

Y luego ocurre un nuevo milagro. El primero de septiembre de repente completamos el diseño. ¿Y por qué? Sí porque. El primero de septiembre. Según el horario de trabajo, ya deberíamos haber terminado. No hay necesidad de dudar.

Entonces una fiesta más. Globos y discursos. Y avanzamos a la siguiente etapa: implementación.

Sería genial poner en marcha tal esquema una vez más. ¡Oh, si de la misma manera fuera posible completar la fase de implementación! Pero no funcionará de esa manera. Porque al finalizar la implementación, se requiere completar todo el proyecto. El análisis y el diseño no dan fruto en forma binaria. No tienen criterios inequívocos de integridad.

No hay forma objetiva de saber si se mantienen en la realidad. Por lo tanto, resultó completar estas etapas a tiempo.

Fase de implementación

Pero la implementación solo tiene criterios distintos para la integridad. Aquí ya no es posible perder el tiempo con precisión, dando el resultado imaginario como válido.
En la etapa de implementación, la ambigüedad de las tareas está completamente ausente. Solo escribimos el código. Y tenemos que escribir el código rápidamente, sacando la lengua, porque cuatro meses simplemente fueron arrojados al viento.

Mientras tanto, los requisitos del proyecto continúan cambiando. Se añaden nuevas funciones. Las viejas funciones desaparecen o se ajustan. Tendríamos que regresar, realizar un nuevo análisis y hacer cambios en el diseño, pero ... solo quedan dos semanas. Y a un ritmo acelerado, llevamos todos estos cambios al código.

Cuando miramos el código y lo comparamos con el resultado del diseño, nos damos cuenta de que debemos haber estado fuera de lugar en la etapa de diseño, porque el código en sí tiene poco que ver con lo que originalmente se representaba en los maravillosos gráficos. Pero no hay tiempo para pensar, porque el tiempo corre y las horas extras se vuelven cada vez más.

Alrededor del 15 de octubre, alguien dice: "Oye, ¿cuál es la fecha de hoy?" ¿Cuándo tomarlo? Y aquí entendemos que solo quedan dos semanas y para el primero de noviembre nunca terminaremos. Y de repente, por primera vez, nuestros clientes descubren que hay algunos problemas con el proyecto.

Imagina su indignación. “¿Y en la etapa de análisis era imposible decir sobre esto? ¿No era entonces que debería haber estimado el tamaño del proyecto y haber calculado cuidadosamente el horario de trabajo? ¿Y por qué no dijeron en la etapa de diseño? ¿No era necesario dividir el proyecto en módulos, distribuir el trabajo en todo el equipo y calcular el recurso humano? ¿Por qué descubrimos todo dos semanas antes de la fecha límite?

Y tienen razón, ¿no es así?

Maratón de supervivencia

Y comienza el maratón de supervivencia. Los clientes están enojados. Las partes interesadas han llegado al extremo. La presión está aumentando. Trabajamos horas extras. Alguien deja el proyecto. Solo el infierno!

Y ya alrededor de marzo, nos afligimos por la mitad con el resultado de que solo la mitad cumple con los requisitos de los clientes. Todos están molestos. Todos se rinden. Y nos juramos a nosotros mismos que la próxima vez esto no sucederá. La próxima vez haremos todo sabiamente. La próxima vez, el análisis y el diseño se realizarán de buena fe.

Lo llamo el proceso de hinchazón fuera de control. Vamos a trabajar aún mejor la próxima vez usando un método que no funciona.

»Puede realizar un pedido por adelantado en el sitio web del editor.

Tras el pago de la versión impresa del libro, se envía el pdf por correo electrónico.con las primeras 105 páginas del libro.