¡Hola habitantes! Cualquier empresa quiere lograr una mayor eficiencia en el desarrollo de software, porque esto afecta directamente las ganancias. Gran parte de la literatura ágil está dirigida a empresas grandes y de alto crecimiento, pero ¿qué pasa si su empresa no está a la vanguardia de TI? La buena noticia es que todas las organizaciones pueden mejorar el rendimiento, y este libro lo ayudará a encontrar rutas y soluciones específicas para aprovechar Agile al máximo. “No soy un evangelista ágil. Soy partidario de lo que funciona y oponente de lo que promete mucho pero no da resultados. En este libro, la metodología Agile se presenta no como un movimiento que requiere una mayor conciencia, sino como un conjunto de métodos técnicos y de gestión especiales, cuyo efecto e interacción son comprensibles para cualquier empresario o especialista en TI.Los entusiastas de Agile pueden criticar este libro por no promover las mejores prácticas de Agile. Pero este es el punto: un énfasis en métodos prácticos que han demostrado su eficacia. La historia de Agile está llena de ideas que han sido implementadas con éxito por un par de entusiastas en algunas organizaciones, pero que no pueden ser utilizadas por todos los demás ”, dice Steve McConnell. El nuevo libro de Steve McConnell, autor de los legendarios libros Code Complete y Software Estimation, reúne la experiencia de la vida real de cientos de empresas. Utilice una guía sencilla y directa de las prácticas ágiles modernas y más eficaces.que han sido implementadas con éxito por un par de entusiastas en algunas organizaciones, pero que no son utilizadas por todos los demás ”, dice Steve McConnell. El nuevo libro de Steve McConnell, autor de los legendarios libros Code Complete y Software Estimation, reúne la experiencia de la vida real de cientos de empresas. Utilice una guía sencilla y directa de las prácticas ágiles modernas y más eficaces.que han sido implementadas con éxito por un par de entusiastas en algunas organizaciones, pero que no son utilizadas por todos los demás ”, dice Steve McConnell. El nuevo libro de Steve McConnell, autor de los legendarios libros Code Complete y Software Estimation, reúne la experiencia de la vida real de cientos de empresas. Utilice una guía sencilla y directa de las prácticas ágiles modernas y más eficaces.
Ejecución de proyectos aún más eficiente
En el capítulo anterior, analizamos cómo organizar y apoyar a los desarrolladores cuando trabajan en Agile. Este capítulo analiza cómo organizar y mantener correctamente el proceso de desarrollo cuando se trabaja en Agile.
La mayor parte del desarrollo de software se organiza en proyectos. Las organizaciones utilizan una amplia variedad de términos para describir conceptos relacionados con un proyecto, incluidos producto, programa, lanzamiento, ciclo de lanzamiento, función, flujo de valor, flujo de trabajo y más. ...
La terminología varía considerablemente. Algunas empresas creen que la liberación es sinónimo de proyecto. Otros piensan que la liberación se refiere al desarrollo progresivo, por lo que dejaron de usarla. Otros más definen el concepto de "función" como la cantidad de trabajo diseñada para 3 a 9 personas y 1 a 2 años. En este capítulo, con la palabra "proyecto" me referiré a cualquiera de los tipos de trabajo enumerados, es decir, el trabajo de un cierto número de empleados durante mucho tiempo.
Principio clave: proyectos pequeños
Durante los últimos 20 años, los casos más famosos de aplicación exitosa de Agile en pequeños proyectos. Durante los primeros 10 años de su existencia, Agile prestó gran atención a mantener los proyectos pequeños, es decir, de 5 a 10 personas en un equipo (por ejemplo, de 3 a 9 desarrolladores, un propietario de producto y un scrum master). El énfasis en el tamaño de los proyectos pequeños es muy importante porque los proyectos pequeños son más fáciles de manejar que los grandes, como se muestra en la Fig. 9.1.
Capers Jones ha postulado durante 20 años que los proyectos pequeños tienen más éxito que los grandes [Jones, 1991; 2012]. He resumido la mayor parte de la investigación sobre el éxito del proyecto frente al tamaño en mis libros Code Perfect [McConnell, 2004; SPb.: Peter, 2007] y Estimación de software: Desmitificando el arte negro [McConnell, 2006].
Los proyectos más pequeños son más seguros por varias razones. Los grandes proyectos requieren la participación de más especialistas, y el número de relaciones entre personas en equipos y entre los propios equipos aumenta en una progresión no lineal. Y cuanto más compleja se vuelve la relación, más errores se cometen en la interacción. Los errores de interoperabilidad conducen a errores en los requisitos, el diseño, la codificación; en general, otros errores.
En consecuencia, cuanto más grande se vuelve el proyecto, más errores se cometen (Figura 9.2). Esto significa no solo que el número total de errores está creciendo, ¡sino que hay inconmensurablemente más errores en proyectos grandes!
Cuanto mayor sea la tasa de error, menor será la efectividad de las estrategias de detección de fallas. Esto significa que el número de defectos en el producto terminado aumenta de manera desproporcionada.
También se necesita más esfuerzo para eliminar errores. Por lo tanto, como se muestra en la Fig. 9.3, los proyectos más pequeños tienen una mayor productividad por persona, pero cuanto mayor es el tamaño del proyecto, más cae la productividad. Este fenómeno se conoce como costo de escala.
Esta relación inversa entre tamaño y rendimiento se ha investigado y probado exhaustivamente durante más de 40 años. Fred Brooks discutió el costo de la escala en el desarrollo de software en la primera edición de su libro The Mythical Man-Month [Brooks, 1975; SPb.: Peter, 2021]. El trabajo de Larry Putnam sobre la estimación de los costos de desarrollo de software confirmó las observaciones de Brooks [Putnam, 1992]. La investigación sobre el modelo de costos de desarrollo (Cocomo) ha confirmado empíricamente la existencia de costos de escala dos veces, en un estudio de fines de la década de 1970 y en un estudio actualizado de fines de la década de 1990 [Boehm, 1981; 2000].
La conclusión es que para maximizar la probabilidad de un proyecto ágil exitoso, intente mantener el proyecto (y el equipo) pequeño.
Por supuesto, es imposible hacer que cada proyecto sea pequeño. El Capítulo 10, “Ejecución de proyectos grandes de manera aún más eficaz”, describe los enfoques para proyectos grandes, incluidas sugerencias sobre cómo reducirlos.
Principio clave: Sprints cortos
La conclusión natural de que los proyectos pequeños son preferibles es que los sprints no deberían durar mucho. Podría pensar que un pequeño proyecto ya es una receta para el éxito. Pero los sprints cortos de 1 a 3 semanas contribuyen al éxito de la gestión de proyectos. Esto se describe en las siguientes secciones.
Los sprints cortos reducen la cantidad de requisitos intermedios y mejoran la capacidad de respuesta a los nuevos requisitos
En Scrum, se pueden agregar nuevos requisitos entre sprints. Pero una vez que ha comenzado el sprint, no puede agregar requisitos hasta el próximo sprint. Esto tiene sentido si el sprint dura de 1 a 3 semanas.
Si los ciclos de desarrollo toman más tiempo, las partes interesadas piden cada vez con más insistencia que se agreguen requisitos a lo largo del camino, por lo que las solicitudes para posponer la adición de requisitos ya no están tan justificadas. Si el ciclo con un modelo de desarrollo secuencial dura seis meses, pedirle a la parte interesada que posponga la implementación del nuevo requisito hasta el siguiente ciclo significa que el trabajo en el requisito comenzará solo en el siguiente ciclo, es decir, al comienzo del ciclo, este requisito solo se agregará, y luego deberá esperar la entrega del producto al final de este. ciclo. En promedio, se necesitan 1,5 ciclos, es decir, 9 meses.
Por el contrario, los sprints de Scrum normales duran dos semanas. Esto significa que un interesado que desee agregar un nuevo requisito tendrá que esperar un promedio de tres semanas.
Pedirle a una parte interesada que espere 9 meses para que se implemente un requisito suele ser inapropiado. Y tres semanas casi siempre es apropiado. Esto significa que el equipo Scrum trabaja silenciosamente, sin temor a nuevos requisitos en medio del sprint.
Los sprints cortos brindan una mayor capacidad de respuesta cuando se trabaja con clientes y partes interesadas
Cada sprint presenta una nueva oportunidad para mostrar el software en funcionamiento, validar los requisitos y generar comentarios de las partes interesadas. ¡Con sprints estándar de dos semanas, los equipos se dan la oportunidad de ser más rápidos 26 veces al año! Con un ciclo de desarrollo de tres meses, esta oportunidad se presenta solo cuatro veces al año. Hace quince años, un proyecto de tres meses se consideraba corto. Hoy en día, tal programa significa que no podrá responder rápidamente a los comentarios de las partes interesadas, los clientes y el mercado.
Los sprints más cortos generan confianza en las partes interesadas
A medida que los equipos obtienen resultados con mayor frecuencia, el progreso se vuelve más transparente, por lo que el progreso es visible para las partes interesadas, lo que genera confianza entre ellos y el equipo.
Los sprints cortos ayudan a acelerar el desarrollo a través de ciclos de aprendizaje y adaptación.
Cuanto mayor sea la tasa de iteración, más oportunidades tendrá el equipo para reflexionar sobre las lecciones aprendidas, sacar conclusiones y aplicar los resultados a métodos prácticos de trabajo. El fundamento de esta área es el mismo que el de la capacidad de respuesta del cliente: ¿es mejor dejar que sus equipos aprendan y se adapten 26 veces al año, o solo cuatro? Los sprints cortos ayudan a su equipo a mejorar más rápido.
Los sprints cortos ayudan a reducir el tiempo de experimentación
En el contexto de Tangled Issues de Cynefin, los problemas primero deben investigarse antes de que se pueda comprender el alcance completo del trabajo. Dicha investigación debe caracterizarse de la siguiente manera: "Para obtener una respuesta a esta o aquella pregunta, haga la menor cantidad de trabajo necesario". Desafortunadamente, la Ley de Parkinson dice que el trabajo ocupa todo el tiempo disponible. Y hasta que el equipo desarrolle una disciplina férrea, la solución del problema, si se le asigna un mes, tomará exactamente un mes. Pero si solo hay dos semanas, la solución del problema suele tardar dos semanas.
Los sprints cortos permiten la detección oportuna de costos y riesgos
Los sprints cortos te permiten realizar un seguimiento del progreso con más frecuencia. Después de unos pocos sprints, al trabajar en una nueva tarea, se determinará la "velocidad" del equipo o el ritmo de progreso. La capacidad de monitorear el progreso del trabajo hace que sea más fácil predecir el momento del lanzamiento del producto. Si el trabajo está demorando más de lo planeado originalmente, esto será muy claro en unas pocas semanas. Los sprints cortos son una herramienta poderosa para mantenerse informado. El capítulo 20, "Previsibilidad aún mejor", trata con más detalles sobre esto.
Los sprints cortos promueven la responsabilidad del equipo
Si un equipo es responsable de entregar la funcionalidad de trabajo cada dos semanas, no tienen la oportunidad de trabajar en la oscuridad por mucho tiempo. Ella muestra los resultados de su trabajo en reuniones de revisión de sprint e informa a las partes interesadas cada dos semanas.
El propietario del producto ve los frutos del trabajo con más frecuencia.
El propietario del producto acepta o rechaza el trabajo, el progreso del trabajo es claramente visible. Por lo tanto, los equipos son más responsables de su trabajo.
Los sprints cortos promueven la responsabilidad
Durante generaciones, los equipos de desarrollo sufrieron de "estrellas" encerradas en una habitación oscura durante meses, y no estaba completamente claro si el trabajo estaba progresando. En el caso de Scrum, este problema ya no existe. Todo el mundo trabaja en apoyo de los objetivos del equipo en el sprint, además, es necesario venir a las paradas todos los días y hablar sobre el trabajo que se hizo ayer; ya no podrás encerrarte más. O el desarrollador comienza a cooperar, lo que resuelve el problema de una manera, o no puede soportar las condiciones y deja el equipo, que aún resuelve el problema, aunque de una manera diferente. Por mi propia experiencia puedo decir que cualquiera de los resultados es más favorable que en el caso de que alguien trabaje sin informes durante semanas o meses, y al final resulta que realmente no se ha hecho nada.
Los sprints cortos promueven la automatización
Debido a que los equipos a menudo realizan la reconciliación, los sprints cortos pueden automatizar tareas que de otro modo serían repetitivas y consumirían mucho tiempo. La automatización está muy extendida en el ensamblaje, la integración, las pruebas y el análisis de código estático.
Es más probable que los sprints más cortos brinden una sensación de satisfacción. Un
equipo que entrega software funcional cada dos semanas tiene más probabilidades de estar satisfecho con su trabajo y también de tener la oportunidad de celebrar sus logros. Esto contribuye a un sentido de profesionalismo que fomenta la motivación.
Sprints cortos. Resumen
En general, los beneficios de los sprints cortos se pueden resumir de la siguiente manera: "La velocidad de entrega en todos los aspectos ayuda a hacer frente al volumen de trabajo". La entrega de funcionalidad en lotes pequeños y cadencias cortas aporta una gran cantidad de ventajas sobre la entrega de funcionalidad en lotes grandes y cadencias largas.
Planifica en función de la velocidad de las tareas
Las unidades de dificultad de la historia son una medida del tamaño y la complejidad de una tarea. La velocidad es una medida del progreso basada en la frecuencia con la que se completan las tareas y se mide en unidades de dificultad de la historia. La programación basada en la velocidad es la planificación y el seguimiento del trabajo en función de las unidades de dificultad del historial y la velocidad del trabajo.
La programación y el seguimiento de la velocidad no son parte del tutorial de Scrum, pero en mi experiencia creo que sería una buena idea incluirlos. A continuación, hablaré sobre cómo se aplican las unidades de dificultad de la historia y las estimaciones de velocidad.
Estimación del tamaño de la cartera de productos
La puntuación de dificultad se utiliza para determinar el tamaño de la acumulación de productos. Los tamaños de los problemas en la acumulación de productos generalmente se estiman en términos de las unidades de dificultad de las historias, y luego se agregan las unidades de complejidad de las historias para calcular el tamaño total de la acumulación de productos. Esto debe hacerse al comienzo del ciclo de lanzamiento y a medida que se agrega o elimina trabajo del trabajo pendiente. Esto se hace en la medida en que el equipo necesita ser predecible. Más sobre esto en el Capítulo 20, "Aún mejor previsibilidad".
Cálculo de velocidad
La cantidad de trabajo completado por el equipo en cada sprint se calcula en unidades de dificultad de la historia. El número de Unidades de Dificultad de Historia logradas en cada Sprint representa la velocidad del equipo. La velocidad se calcula en función de los resultados de cada sprint calculando el promedio.
Planificación de Sprint
El equipo planifica el alcance del trabajo por sprint, también medido en unidades de dificultad de la historia, basándose en observaciones de la velocidad del equipo.
Si el equipo completó 20 unidades de dificultad de historia por sprint en promedio, y en el siguiente sprint se fijó el objetivo de completar 40 unidades de historia, entonces deben cortar sus planes. Si un miembro del equipo se va de vacaciones o varios miembros del equipo están asistiendo a eventos de entrenamiento, el equipo debe planificar menos Dificultades de Historia por sprint que en promedio. Si el equipo logró completar 20 unidades de dificultad de las historias gracias a las noches de insomnio y al trabajo los fines de semana, la barra también debería bajarse. Si su equipo logra los objetivos de sprint de manera constante y sin esfuerzo, intente programar más dificultad de historia que el promedio. En cualquier caso, el equipo está planificando en función de su velocidad real.
Seguimiento de lanzamientos
En función de la velocidad promedio, puede calcular o predecir la cantidad de tiempo que llevará completar las tareas en la cartera de productos. Si la acumulación de productos tiene 200 unidades de dificultad de historia y la velocidad promedio del equipo es de 20 unidades de dificultad de historia por sprint, entonces el equipo necesitará 10 sprints para completar todas las tareas de la acumulación. Explicaré más sobre cómo funciona esto en el Capítulo 20, "Previsibilidad aún mejor".
Tener en cuenta el impacto de los cambios en el proceso, la composición del equipo y otros cambios
Según la velocidad, puede realizar un seguimiento del impacto de los cambios en el proceso, la composición del equipo y otros cambios. Los detalles de esto se discuten en el Capítulo 19, Mejorar el proceso aún mejor.
Principio clave: entrega del producto en cortes verticales
Para que los sprints sean efectivos, el equipo debe desarrollar la capacidad de entregar pequeños lotes de funcionalidad funcional con frecuencia. El enfoque de diseño que facilita esto se denomina "usar cortes verticales", lo que significa realizar cambios en cada capa arquitectónica para obtener un incremento o valor.
El segmento vertical representa la funcionalidad completa de la pila, como agregar un campo a un extracto bancario o hacer que la confirmación de la transacción de un usuario sea un segundo más rápido. Cada uno de estos ejemplos generalmente requiere que se ejecute toda la pila de tecnología, como se muestra en la Figura 1. 9.4.
Los cortes verticales tienden a ayudar a las partes interesadas no técnicas a comprender, observar y medir mejor el valor comercial. Le dan al equipo la capacidad de lanzar lanzamientos más rápido y darse cuenta del valor real del producto para la empresa, y obtener comentarios reales de los usuarios.
Los equipos que utilizan cortes horizontales corren el riesgo de sumergirse en la jungla durante varios sprints seguidos, trabajando en historias que reflejan algún progreso, pero que no aportan un valor comercial visible.
Los equipos a veces se muestran reacios a utilizar cortes verticales, generalmente debido a su menor eficiencia. Argumentarán, por ejemplo, que es más eficiente hacer más trabajo en la capa de lógica empresarial y luego pasar a la capa de interfaz. Este enfoque se denomina uso de cortes horizontales.
En algunos casos, desde un punto de vista técnico, puede ser más eficiente trabajar en capas horizontales, pero dicha eficiencia técnica, por regla general, conduce a la optimización de partes individuales del producto, lo que no es tan importante como obtener una funcionalidad valiosa. Contrariamente a las afirmaciones de que el uso de cortes horizontales conduce a una mayor eficiencia, nuestra empresa ha descubierto que cuando se utilizan cortes horizontales, muchos equipos se enfrentan a la necesidad de realizar correcciones significativas.
Los sectores verticales proporcionan una respuesta más precisa
Los sectores verticales le permiten ofrecer rápidamente funcionalidad a los usuarios empresariales, lo que le ayuda a obtener comentarios rápidos sobre cómo funciona correctamente la funcionalidad.
Debido a que las secciones verticales requieren un desarrollo de extremo a extremo, los miembros del equipo se ven obligados a trabajar juntos en el diseño y la implementación, lo que proporciona comentarios técnicos útiles a todo el equipo.
El uso de cortes verticales también promueve las pruebas de extremo a extremo, lo que ayuda a garantizar una respuesta precisa.
Los sectores verticales proporcionan un mayor valor empresarial
Los sectores verticales son mejor entendidos por las partes interesadas que no son técnicas, y esto conduce a mejores decisiones que la empresa toma sobre la prioridad y el orden de implementación de la funcionalidad nueva y revisada.
Dado que las secciones verticales proporcionan un incremento funcional completo, a menudo brindan la oportunidad de presentar la funcionalidad del trabajo a los usuarios, lo que aumenta el valor comercial.
El uso de cortes horizontales lleva al hecho de que los desarrolladores comienzan a percibir la arquitectura como un producto. Y esto puede conducir a actividades gratificantes que son completamente innecesarias para la entrega de funcionalidad y a otros métodos que conducen a una disminución del valor.
Lo que necesita un equipo para usar cortes verticales
Ofrecer funcionalidad con cortes verticales puede ser difícil. Depende de la composición del equipo, su negocio, desarrollo y capacidades de prueba, que incluyen habilidades en toda la pila de tecnología.
Los equipos también pueden necesitar cambiar su pensamiento de diseño e implementación para trabajar con cortes verticales, que serán diferentes de trabajar por componentes o capas horizontales. Algunos equipos carecen de habilidades de diseño para hacer esto y necesitarán desarrollar (y mantener el desarrollo) habilidades para enfrentarlo.
Por último, los equipos deben realizar su trabajo en cortes verticales. El propietario del producto y el equipo de desarrollo deben encontrar un enfoque para refinar el trabajo pendiente de modo que el resultado sean cortes verticales.
Principio clave: administrar la deuda tecnológica
La "deuda tecnológica" se refiere a la acumulación de trabajo de mala calidad en el pasado que ralentiza el ritmo del trabajo en el presente. El ejemplo clásico es una base de código frágil donde cada intento de corregir un error genera uno o más nuevos. Incluso corregir un error simple requiere mucho tiempo y corregir errores adicionales.
La deuda técnica puede incluir código de baja calidad, diseño de baja calidad, un conjunto de pruebas débil, un enfoque de diseño difícil, un entorno de construcción engorroso, procesos manuales lentos y otras formas en que un equipo sacrifica el rendimiento a largo plazo en favor de ganancias a corto plazo.
Consecuencias de la deuda técnica
La deuda suele acumularse como resultado de la presión para priorizar las liberaciones a corto plazo sobre la calidad. Una visión holística de los recursos invertidos y los rendimientos obtenidos incluye la contabilización del impacto de la deuda técnica a lo largo del tiempo.
Los equipos técnicos y comerciales pueden tener razones de peso para acumular esta deuda. Algunos lanzamientos son lo suficientemente sensibles al tiempo como para justificar un trabajo adicional más adelante debido al deseo de hacer el trabajo más rápido en el presente.
Sin embargo, un modelo que permita que la deuda técnica se acumule a lo largo del tiempo sin un plan para resolver esa deuda finalmente reducirá la velocidad del equipo. El equipo debe desarrollar un plan de gestión de la deuda para mantener o aumentar su velocidad.
Kruchten, Nord y Ozkaya han desarrollado un diagrama excelente de cómo surge la deuda técnica, qué valor comercial (probable) tiene y cómo, en última instancia, se convierte más en un pasivo que en un activo (Figura 9.5).
Cuando se trabaja desde cero, los equipos pueden evitar acumular deudas técnicas en primer lugar. Al realizar un trabajo que ya ha comenzado, los equipos a menudo no tienen más remedio que trabajar con la deuda técnica ya acumulada. En todo tipo de trabajo, si al equipo no le va bien con la deuda técnica, la velocidad disminuirá con el tiempo.
Pago de la deuda técnica Los
diferentes equipos tienen diferentes enfoques para cancelar la deuda técnica . Algunos equipos, para saldar la deuda, la distribuyen en acciones para cada ciclo de desarrollo (sprint o release). Otros equipos agregan deudas a la lista de retrasos o deficiencias del producto y priorizan la deuda y el resto del trabajo. En cualquier caso, la característica clave es que la deuda técnica se gestiona abiertamente.
Tipos de deuda y cómo lidiar con ella
No todas las deudas técnicas son iguales y existen diferentes clasificaciones. Encuentro estas categorías útiles:
- Deuda intencional (a corto plazo). Deuda derivada de consideraciones tácticas o estratégicas, como publicar un comunicado urgente a tiempo.
- Deuda intencional (largo plazo). Deuda derivada de consideraciones estratégicas, como el soporte inicial de una única plataforma en lugar de ser compatible con varias plataformas.
- Deuda no intencionada (mala fe). Deuda que surge por casualidad debido a métodos de desarrollo de mala calidad. Este tipo de deuda ralentiza el trabajo tanto en el presente como en el futuro, por lo que conviene evitarlo.
- Deuda no intencionada (buena fe). Deuda que surge por accidente debido a errores naturales en el desarrollo de software (“Nuestro enfoque de diseño no funcionó tan bien como planeamos” o “La nueva versión de la plataforma mostró serios defectos de diseño”).
- Deuda heredada. Deuda heredada por el nuevo equipo de la antigua base de código.
El cuadro 9.1 muestra qué enfoques se recomiendan para responder a este tipo de deuda.
Beneficios de discutir la deuda técnica
En mi experiencia, la metáfora "deuda técnica" ha sido útil para facilitar las discusiones entre los profesionales de la tecnología y los negocios. Los profesionales de negocios generalmente no saben cuáles son los costos de pagar la deuda técnica y los técnicos generalmente no conocen los intereses comerciales. En algunos casos, puede ser una buena idea permitir deliberadamente que se acumule la deuda técnica, y en otros no. La deuda facilita el intercambio de opiniones sobre consideraciones técnicas y comerciales, haciéndola más significativa, lo que mejora la calidad de las decisiones sobre cuándo y por qué contraer una deuda y cuándo y cómo reembolsarla.
Construye tu estructura de trabajo para evitar el agotamiento
La visión purista de Agile asume la misma duración de sprint (conocida como "cadencia compartida"). Si el equipo tolera bien la cadencia general, no tiene sentido hacer cambios. Las cadencias compartidas facilitan el cálculo de la velocidad y otros factores al planificar un sprint.
Una queja común al implementar Scrum es que una secuencia interminable de sprints conduce a la fatiga y la sensación de correr en el volante. Con un desarrollo constante, hay fallas naturales en el desempeño, especialmente entre disciplinas, así como también el equilibrio durante períodos de alta intensidad.
Los sprints constantes no dejan tiempo para descansar si cada sprint realmente se ejecuta a un ritmo de sprint.
Uno de los antídotos para la fatiga después de los sprints es cambiar la duración de los sprints según sea necesario. Una forma sistemática de hacer esto es usar un patrón 6x2x1, seis sprints de dos semanas más un sprint que dure una semana, para un total de 13 semanas, que es exactamente un cuarto.
Una alternativa sería utilizar sprints más cortos después de los lanzamientos importantes, en vacaciones y en otros momentos en los que la velocidad del equipo aún no será estable. Durante un sprint de una semana, un equipo puede estar trabajando en infraestructura o herramientas, asistiendo a eventos de preparación o en equipo, hackatones, trabajando en la deuda técnica, trabajando en mejoras que son demasiado grandes para ser completadas en un sprint, o algo más.
La longitud variable de la cadencia de sprint es consistente con el concepto de ritmo sostenido utilizado en Agile. Gran parte de la investigación ágil equipara un ritmo constante con la falta de noches y fines de semana libres. Pero creo que esta es una simplificación excesiva molesta que ignora las diferencias en las preferencias por las condiciones laborales de diferentes personas. Algunos sugieren que una semana laboral de 40 horas es un ritmo constante, pero para otros es un camino hacia el aburrimiento. Personalmente, hice la mayor parte de mi mejor trabajo en modo explosivo: 55 horas durante dos semanas y luego 30 horas durante las siguientes dos semanas. En promedio, puede trabajar unas 40 horas de trabajo por semana, pero los diferentes equipos no siempre tienen 40 horas de trabajo. La comprensión de un ritmo constante es diferente para todos.
Otras Consideraciones
Desarrollo de software fuera del diseño
No todo el desarrollo de software está organizado en proyectos, incluso con las muchas definiciones al principio de este capítulo. A veces, hay situaciones en las que suele trabajar una persona, por ejemplo, es común en el manejo de llamadas de soporte técnico, resolución de problemas de versiones, creación de parches, etc.
Este trabajo, por supuesto, está relacionado con el desarrollo de software y también se presta a prácticas ágiles. Se pueden llevar a cabo de manera más eficiente, cualitativa y metódica mediante la implementación de métodos ágiles prácticos como Lean Manufacturing y Kanban. Pero en mi experiencia, las empresas tienden a tener muchos menos problemas con este tipo de trabajo que con el desarrollo de software en todo el proyecto, por lo que este libro se centra en trabajar en proyectos más que en trabajos ad-hoc.
Estudio de recomendaciones :
- Revise el historial de totales del proyecto. ¿La experiencia de su empresa es coherente con el consenso general de que los proyectos pequeños tienen más probabilidades de éxito que los grandes?
- Explore su cartera de proyectos. ¿Cuál de sus grandes proyectos se puede dividir en varios más pequeños?
- , . ? ?
- , .
- , .
- . ?
- .
- , , .
- .
- [ , 1975]. -. , , .
- [ , 2019]. Understanding Software Projects Lecture Series. Construx OnDemand. (2019 ). ondemand.construx.com. .
- [ , 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. , .
- [ ., 2019]. Managing Technical Debt. .
»Se pueden encontrar más detalles sobre el libro en el sitio web de la editorial
» Tabla de contenido
» Extracto
para los habitantes un 25% de descuento en el cupón - Agile
Tras el pago de la versión impresa del libro, se envía un libro electrónico al correo electrónico.