íneas de Trabajo acumulado a En curso.

CAPITULO 2
Etiquetas más inteligentes,
mejor tarea
tablas

Un panel de tareas es un "transmisor de información" de un vistazo acerca de su

proyectos de software. Es la forma más fácil para que los equipos rompan las
barreras que dividen a las personas que trabajan en un proyecto, potenciando la
comunicación, la eficiencia y un producto de mayor calidad. En este capítulo, vamos
a
explica cómo combinar etiquetas y tuberías personalizadas para crear tu
Panel de proyectos perfecto.
Lo primero es lo primero
Una base de proyecto exitosa comienza con un buen tablero de tareas y una
El buen tablero de tareas comienza con repos, tuberías comprendidas y un sonido
sano.
Sistema de etiquetado.
• El panel de tareas (o "tablero") es la forma en que usted ve, prioriza y administra
la cartera de productos.
• Los repositorios ("repos") son la forma en que se dividen los proyectos en GitHub.
GitHub ahora proporciona repositorios privados ilimitados en planes pagados.
Dado que ZenHub te permite conectar repositorios juntos, no
Sé tímido: divide tus proyectos en un número generoso de repositorios para
Ayuda a que las cosas se mantengan organizadas.
• Las tuberías son columnas en su tablero que organizan sus problemas.
(Tareas). Sus problemas se mueven entre tuberías de izquierda a derecha
A medida que avanzan a través del ciclo de desarrollo. Discutiremos
Personalizar sus tuberías más tarde, pero la estructura predeterminada de ZenHub
Funciona bien como punto de partida.
• Las etiquetas son el sistema de etiquetado utilizado para transmitir más
información.
sobre cada tema. Naturalmente, puedes filtrar tus tablas por etiqueta.
20
Una nota en las etiquetas.
No se conforme con las siete etiquetas predeterminadas de GitHub. Tómese un
minuto para configurar
una guía de estilo de etiqueta que comunica más que el tipo de problema.

Nuestro equipo creó etiquetas personalizadas que comunican el estado,

bloqueadores, complejidad (por ejemplo, marcamos soluciones rápidas con la
etiqueta “Bash Es ”), y otros factores. Juntos, se comunican mucho en una sola.
vistazo. Echa un vistazo a nuestra guía de estilo de ejemplo en la página siguiente.
Nuestra guía de estilo de etiqueta Las etiquetas no solo agregan un toque de color;
Si los usas consistentemente, nunca tendrá que analizar sus problemas en la
pizarra. (Para más ideas sobre el etiquetado de las mejores prácticas, consulte esta
publicación.)
Tu nuevo hogar en el trabajo ¿Sabías que el cerebro procesa la información visual
60,000 veces? más rápido que el texto? Kanban es una metodología que aprovecha
este hecho para crear un Sistema eficiente y orientado a la mejora. Básicamente,
los tableros Kanban crean una imagen del trabajo y los procesos del proyecto. Al
visualizar el trabajo de esta manera, puede crear enfoque, establecer Fluye, y
mejora continuamente. Antes de herramientas como ZenHub, se crearon tableros
de tareas utilizando post-it y pegatinas. ¿La única ventaja que tiene un tablero físico
sobre digital? Visibilidad constante para tenerlo en cuenta. Mantenga su tablero en
un gran monitor en algún lugar obvio y márquelo como 22 su lugar de trabajo ir a
Usando tuberías como un jefe Los tableros ZenHub vienen preestablecidos con seis
líneas: Nuevos problemas, Trabajo pendiente, Tareas pendientes, En curso, Listo y
Cerrado. Repasemos rápidamente cada uno de ellos. Nuevos problemas: los
nuevos problemas aterrizan aquí automáticamente. Ellos deberían ser Arrastrado a
otra tubería tan pronto como sea posible. Backlog: los problemas de backlog no son
un enfoque actual, pero usted actuará en ellos en algun momento Si no tienen un
hito de GitHub, considérelos parte de la cartera de productos. Una vez que agregues
un Hito, son parte de su cartera de sprint. Para hacer: poblado con problemas bien
definidos, este canal es el objetivo de su equipo enfoque actual Los problemas aquí
fluirán en la tubería En curso, por lo que Ordénelos por prioridad y asigne
encargados que usen la función Asignado. En progreso: esta tubería responde a la
pregunta, "¿En qué estás trabajando ahora?". Idealmente, cada miembro del equipo
debería estar trabajando en solo una cosa a la vez Hecho: Dependiendo de la
definición de su equipo de "Hecho", un problema en Aquí puede significar que está
en producción o puesta en escena, o que está listo para la prueba. ¡Asegúrese de
que su equipo esté de acuerdo con lo que significa "Hecho"! Cerrado: Estos son
temas completados. Arrastrar los problemas a esta tubería los cerrará, mientras que
al arrastrarlos los volverá a abrir. 23 Para mantener el orden de ZenHub Boards
libre, puede ocultar este canal a través de La casilla de verificación en la parte
superior del tablero. Cuando la casilla está marcada, la tubería aparece en el
extremo derecho. Haciendo que todo se junte • Las cuestiones deben ser ordenadas
por prioridad, con la más urgente Problemas en la parte superior. Los problemas
obtienen más detalles a medida que avanzan en el tubería. • No es un trabajo de un
(wo) hombre. Un equipo que funciona bien tiene todos sus miembros arrastrando y
soltando problemas a medida que avanzan, y una Un panel de tareas bien
organizado es la clave para hacer esto posible.

Construyendo tu flujo de trabajo perfecto

Si bien el tablero predeterminado es un excelente punto de partida para cualquier

proyecto,
debería considerar personalizarlo para que se adapte a su equipo único.
La personalización puede ayudarlo a descubrir cuellos de botella más rápido y
proporcionar
Más información para otras partes interesadas en el proyecto.
24
Auditando tu tablero
Hágase estas preguntas:
• ¿Este tablero contiene solo lo que necesitamos y nada más?
¿Podría mi jefe ver esto y entender todo lo que necesita?
¿Sobre el proyecto?
• ¿Todos los grupos están representados aquí? ¿Puede alguien en diseño,
Marketing, o control de calidad, mire este tablero y sepa exactamente dónde está
o su ayuda es necesaria?
• Piensa en cómo tu equipo construye productos. Son recurrentes
"Etapas" se pierden aquí? Se trata de mantener los problemas que fluyen
a través del tablero. Si su sitio web tiene su propio repositorio, por ejemplo,
Es posible que necesite una tubería de "Copyediting".
• ¿Está "Hecho" realmente definido aquí? Y mi equipo sabe y
¿Entiendes nuestra definición? Recuerde: definir "Hecho" es crucial
En cualquier proyecto ágil.
25

CAPÍTULO 3
Tomando GitHub
problemas de la buena
a gran
26

Los problemas son una poderosa llave en el cinturón de herramientas de cualquier

desarrollador. Pero mientras
su estructura simple hace que sea más fácil para otros, los problemas son
Realmente solo tan bueno como los haces.
Sin algún proceso, su repositorio puede volverse difícil de manejar, rebosar de
problemas duplicados, solicitudes de características vagas o confusas
informes de errores. Los encargados de mantener los proyectos pueden sentirse
agobiados por la carga organizativa, y puede ser difícil para los nuevos
contribuyentes
entender dónde están las prioridades. Es un desafío para cualquier equipo, pero se
vuelve especialmente difícil cuando el proyecto es grande o de código abierto.
En este capítulo, aprenderá a tomar los problemas de GitHub de bueno a
genial.
El tema como historia de usuario.
Hablamos con el experto en software Jono Bacon, ex director de comunidad en
GitHub y XPRIZE, autor de The Art of Community, y
Consultor de estrategia.
“Los problemas de alta calidad son la base de ayudar a que un proyecto tenga éxito.
Si bien algunos pueden ver los problemas simplemente como una gran lista de
problemas que tiene
Los problemas atendidos, bien administrados, controlados y etiquetados pueden
proporcionar una visión increíble de su código, su comunidad y dónde se encuentran
los puntos problemáticos ".
Continúa: "En el momento de la presentación de un problema, el usuario
probablemente
Tiene poca paciencia o interés en proporcionar detalles expansivos. Como tal,
Debes hacerlo lo más fácil posible para obtener la información más útil de ellos en
el menor tiempo posible ".

Una estructura consistente puede quitarle una gran carga a tu equipo. Comience
con consistencia Recuerde: las historias de usuario abordan el "quién, qué y por
qué" de una función, como este. “Como <tipo de usuario>, quiero <task> para que
<goal> ". Por ejemplo: "Como <cliente>, quiero <crear una cuenta> para que <puedo
hacer compras> ". Sugerimos pegar esa historia de usuario directamente en el título
del problema. Usted puede configurar plantillas de problemas para mantener las
cosas coherentes.
El punto es hacer que el problema esté bien definido para todos los involucrados:
identifica la audiencia (o usuario), la acción (o tarea) y la salida 28 ven (o meta) lo
más simple posible. No hay necesidad de obsesionarse con esta estructura Se han
propuesto otras alternativas. Siempre y cuando el qué y por qué de una historia son
fáciles de detectar, estás bien!
Cualidades de un buen tema No todos los temas son creados iguales. Un problema
de GitHub bien formado logra Los criterios detallados en The Agile Samurai.
Pregúntate a ti mismo si ... • Es algo de valor para los clientes. • Evita la jerga o
mumbo jumbo. Un no experto debe ser capaz de entiendelo. • "corta el pastel", lo
que significa que va de extremo a extremo para entregar algo de valor. • es
independiente de otros temas si es posible. Cuestiones de dependencia Reducir la
flexibilidad de alcance. • es negociable, lo que significa que generalmente hay varias
maneras de llegar a El objetivo declarado. • es pequeño y puede estimarse
fácilmente en términos de tiempo y recursos requeridos. • es medible; Usted puede
probar los resultados. 29
¿Qué pasa con todo lo demás? Si un problema es difícil de medir o no parece
factible terminar dentro de poco tiempo, todavía puede trabajar con él. Algunas
personas llaman a estos "Restricciones". Por ejemplo, "el producto debe ser rápido"
no se ajusta a la historia Plantilla, pero no es negociable. Pero, ¿qué tan rápido es
rápido? Los requisitos vagos no cumplen con los criterios de un "buen problema",
pero si continúa Defina estos conceptos, por ejemplo, "el producto debe ser rápido"
puede ser "cada página debe cargarse en 0,5 segundos": puede trabajar Con ellos
más fácilmente. Las restricciones pueden verse como métricas internas de éxito, o
un hito para disparar para. Tu equipo debe probar para ellos periódicamente

¿Qué hay dentro de tu problema? En ágil, las historias de usuario suelen incluir
criterios o requisitos de aceptación. En GitHub, debe usar las listas de verificación
(en markdown) para delinear Cualquier sub-tareas que conforman un problema.

Supongamos que estamos creando un problema para la página de inicio de un

nuevo sitio web. Las subtareas para esa tarea pueden parecerse a las anteriores.
Si es necesario, enlace a otros temas para definir mejor una tarea. (GitHub
hace esto realmente fácil.)
Definir las funciones de la forma más granular posible facilita el seguimiento
progreso, prueba de éxito y, finalmente, envía más código valioso
frecuentemente.
Una vez que haya recopilado algunos puntos de datos en forma de problemas,
puede utilizar las API para obtener una visión aún más profunda de sus proyectos.
"La API de GitHub puede ser de gran ayuda aquí para identificar patrones
y tendencias en tus temas ", dice Jono. "Con algo de ciencia de datos creativos
puede identificar puntos problemáticos en su código, detectar miembros activos de
su comunidad y [obtener] otras ideas útiles".
(La API de ZenHub agrega un contexto adicional, que proporciona datos como
estimaciones de problemas,
historial, e información del tablero de tareas.)
Subir a otros a bordo
Una vez que su equipo decide sobre una estructura de problemas, ¿cómo puede
lograr que otros compren? Piense en el archivo ReadMe.md de su representante
como el proyecto de su proyecto.
“Cómo hacerlo”. Debe definir claramente lo que hace su proyecto (idealmente
utilizando
lenguaje de búsqueda) y explique cómo pueden contribuir otros (mediante el envío
de solicitudes, informes de errores, sugerencias o código de contribución)
sí mismo.)

El archivo ReadMe es el lugar perfecto para compartir las pautas de problemas de

GitHub. Si desea que las solicitudes de funciones sigan el formato de la historia del
usuario, comparta ese aquí. Si utiliza una herramienta de seguimiento para
organizar el registro de su producto, considere agregar su distintivo para que otros
sepan cómo acceder a él.
"Plantillas de problemas, etiquetas sensibles, documentación sobre cómo presentar
problemas, y garantizar que sus problemas sean evaluados y respondidos
rápidamente.
Todos son importantes "para su proyecto de código abierto, dice Jono.
Recuerde: no se trata de agregar proceso por el bien del proceso. Algunos
Directrices simples pueden ayudar a otros a descubrir, comprender y sentir.
Cómodo contribuyendo a tu comunidad.
“Concentre sus esfuerzos de crecimiento comunitario no solo en aumentar el
número
32
Programa de programadores, pero también [sobre] personas interesadas en ayudar
con problemas
ser precisos, actualizados y una fuente de conversación activa y resolución de
problemas productiva "

CAPÍTULO 4
Dominar tu
Pila de Producto

Una cartera de productos es una lista de todas las cosas que deben hacerse en
Tu proyecto ágil. Es la culminación de la retroalimentación de múltiples fuentes,
como el equipo de desarrollo, prospectos, administración, marketing.
Y, lo más importante, sus clientes.
Es su trabajo tomar esos comentarios, priorizarlos, gestionarlos y trabajar
En el futuro de su producto. ¿Es fácil? No. Pero al apegarnos a un
pocas mejores prácticas, se vuelve mucho más fácil.
¿Por qué eso importa? Una acumulación (bien administrada) lleva a un trabajo más
productivo y más significativo. El resultado es un mejor producto, y
Una que sus clientes realmente quieren comprar.
¿Necesito un proceso de acumulación de productos?
Sí. No nos pelees en este caso.
Sin uno, su backlog se obstruirá con inactionable
realimentación. Se crea doble trabajo, la visibilidad disminuye y se enfoca
eventualmente perdido todo se suma a una experiencia desmoralizadora.
Pero no te preocupes. Construir un proceso es realmente fácil.
35
Cómo ejecutamos nuestro backlog

Así es como lo hace el equipo ZenHub:

1. Nuevos comentarios e ideas aterrizan automáticamente en los Nuevos Temas
tubería. Nuestro propietario de producto escanea cada problema y decide
rápidamente
si cada tarea es accionable Nota: cuando decimos "propietario del producto", nos
referimos a quien hace la última llamada en cuanto a lo que está construido y
cuando.
2. Si pretendemos completar un problema pero aún no está listo para el desarrollo
(es decir, necesita más detalles o el equipo no tiene capacidad para más recursos).
36
trabajo), el problema se arrastra el Backlog. Los problemas aquí todavía no
tener un hito Agregará uno al comienzo de un sprint.
• Si es un tema valioso pero no tenemos planes de agregarlo a
un hito, lo congelaremos en la caja de hielo. Esto mantiene nuestra
el atraso se atasca.
• Si el problema no se va a resolver, lo cerramos por completo.
No te pongas demasiado valioso al respecto: siempre puedes volver a abrir
eso.
3. ¿Está el tema listo para la acción? En este punto, nuestro equipo ha añadido
detalles (como requisitos de aceptación) y una historia de usuario (la
qué y el por qué.) Nuestros ingenieros han agregado una estimación.
Una vez que un presupuesto y un hito se han adjuntado a un
problema, es formalmente parte de nuestro "Registro de Sprint".
4. Cuando comienza el sprint, simplemente filtramos el tablero por hito. Los
individuos toman lo que está en la parte superior de nuestra cartera y
arrástrelo a En curso para indicar que se está trabajando. Sencillo.

¿Qué hace que un "buen" registro de productos? Enfócate en hacerlo PROFUNDO.

Detallado adecuadamente. Cuanto más cerca esté el problema de la parte superior
de su trabajo acumulado, más detalles debería tener. 37 Estimado. La acumulación
de su producto es más que una lista de tareas pendientes; Es una herramienta de
planificación. Los problemas en la parte superior deben tener estimaciones precisas
(por tiempo, complejidad, o lo que sea que funcione para su equipo), mientras que
las tareas más abajo no Necesitamos ser tan específicos. Emergente. En un retraso,
el tiempo, el presupuesto y la calidad son variables fijas. Alcance no es. Los trabajos
pendientes son emergentes, lo que significa que los problemas se “congelarán” en
el Icebox, cerrado, agregado o editado a medida que aprende más. Priorizado Los
problemas deben organizarse verticalmente de acuerdo con su valor comercial.
¿Cuál es el papel del cliente en una cartera de productos? ¿Conoces la expresión
“el cliente siempre tiene la razón”? Además de ser una fuente de agonía para la
gente que trabaja en trabajos minoristas, la expresión se aplica de manera no
negociable a su cartera de productos. Los comentarios de los clientes deben ser los
más influyentes en lo que se trabaja, y cuando trabajas en ello En el desarrollo ágil,
las necesidades del cliente, deseos, y la retroalimentación informa todos los
requisitos de un proyecto. Su cliente ideal es un experto en su materia. Ellos
deberían ser… • Familiarizado con su negocio • Profundamente invertido en lo que
hace su producto, cómo se ve y 38 cómo funciona. Después de todo, su producto
está resolviendo una necesidad significativa. En su vida. • Comprometido a guiar a
su equipo y responder preguntas pensativamente. Naturalmente, solo su equipo de
desarrollo sabe cómo otros factores, como Deuda técnica potencial, afectará cómo
se debe priorizar esa retroalimentación. Manteniendo su backlog saludable Una
cartera de productos bien mantenida podría ser el mayor regalo. Usted puede dar a
sus usuarios - y su cordura. El punto de "backlog" refinamiento "no es para crear un
proceso innecesario, sino para hacer espacio para un Producto más enfocado.
Piensa en ello como eliminar el smog de los equipos. Estrella del Norte. El
refinamiento del backlog logra algunas cosas: 1. Proporciona priorización, dando
claridad y dirección a todos los involucrados. 2. Asegura que los comentarios de los
clientes sean observados e integrados el producto. 3. Prepara los problemas para
el equipo de desarrollo, dando a cada uno emitir una base clara, concisa y
comprobable para desarrolladores trabajar desde. Nuestro trabajo atrasado mejor
refinado resultó en reuniones de planificación más cortas, un Incremento en la
eficiencia de la planificación, y temas más pequeños, más enfocados. 39 ¿De quién
es el trabajo? Una persona puntual, el propietario del producto, debe estar a cargo
de refinamiento de la cartera. Pueden atraer a desarrolladores, partes interesadas
y clientes según sea necesario durante el proceso de descubrimiento.

Encontramos reuniones de trabajo atrasadas en todo el equipo que son laboriosas

y en general improductivas. Creemos que los esfuerzos de los desarrolladores se
gastan mejor en realidad en el desarrollo, y que la refinación por parte del comité
puede introducir conflictos,
objetivos mal alineados, y otros posibles tiempos se hunde.
¿Cuándo debe refinar una cartera de productos?
Tratamos de hacerlo un poco todos los días, pero como enfoque, lo refinamos
alrededor
Dos días antes de que comience un Milestone. No hay una respuesta correcta aquí;
su equipo debe desarrollar una cadencia que funcione para usted.

CAPÍTULO 5 Un flujo de trabajo para epopeyas y Hitos

A continuación, le mostraremos cómo crear un flujo de trabajo liviano y poderoso

utilizando Épicas e Hitos. Al aplicar algunos principios ágiles básicos, puede
combinar Epics, temas (como historias de usuario), listas de comprobación de
rebajas (como subtareas) y GitHub Hitos para enviar mejor software con menos
gastos generales. Sigue leyendo para Aprende como lo hacemos. Pero primero…
La diferencia entre epopeyas e hitos. Una de nuestras preguntas más comunes es
cómo interactúan los hitos y las épicas. A veces incluso se confunden el uno con el
otro. Hitos y las epopeyas no son intercambiables; de hecho, funcionan mejor
cuando se usan juntos. Recuerde, un sprint suele ser de dos a cuatro semanas de
trabajo con el Objetivo de envío de código viable para el final. Estos cambios
iterativos Son una piedra angular del desarrollo ágil. Aquí, GitHub Hitos representar
los sprints.

Los hitos se utilizan para realizar un seguimiento del progreso de los problemas y
las solicitudes de extracción. Contienen temas relacionados por tiempo y no
necesariamente relacionados por tema. El alcance del trabajo se fija una vez que
comienza un sprint. Las epopeyas contienen temas relacionados con el tema, y el
alcance es flexible. Mientras que las épicas pueden abarcar múltiples repositorios,
los hitos de GitHub no. Para poder usar epopeyas e hitos de manera efectiva,
necesitamos dar un paso Atrás y mira de qué están compuestos: temas de GitHub.
Volviendo al corazón de la cuestión. Como hemos discutido, sugerimos usar una
historia de usuario como título para sus problemas de GitHub, es decir,
descripciones de funciones de alto nivel que ayudan Definir beneficio desde la
perspectiva de un cliente. Recuerda, una vez que Sprint (Milestone) comienza, su
alcance debe permanecer fijo. Pero, ¿por qué seguimos volviendo al formato de
historia de usuario tradicional? Para obtener más información sobre por qué es
importante, hablamos con el experto en gestión de productos Alexander Cowan,
profesor de la Universidad de Virginia Darden y Director General de Synapse
Partners. "Es importante recordar que las historias de usuario están ahí para
impulsar al equipo discusiones sobre lo que es un resultado valioso para el usuario
", dice. "No son solo otro formato para una especificación; las especificaciones son
acerca de la producción y es por eso que los productos basados en especificaciones
fallan en la marca, por lo que A menudo con el usuario ". Para ilustrar este concepto,
sugiere un ejemplo simplificado de un sitio web que vende algo. En este ejemplo,
una historia relacionada podría ser: Como [persona compradora], quiero [ver mis
artículos finales 43 y cargos] para que pueda [asegurarme de tener lo que tengo
querido, y de acuerdo con los cargos aplicables.] Alex explica: "Ese es un buen
punto de partida para que un equipo diseñe Soluciones para esa parte de la
experiencia de compra. Una especificación basada en enfoque probablemente diría
algo así como 'La página debe mostrar descripciones de artículos, cantidades,
costos, así como impuestos y envío. también parece bien, ¿no? " "Un desarrollador
dada esa especificación probablemente construirá algo Eso hace todas esas cosas.
¿Pero es fácil de entender para el usuario? ¿Juega bien con el resto de la
experiencia? Esos son el tipo de preguntas donde las especificaciones no funcionan
tan bien. Tú habitualmente terminar con algo que no está mal, per se, pero que no
es muy bueno. Y eso ya no es lo suficientemente bueno en el mercado
hipercompetitivo de hoy ".

Definiendo ágil en GitHub.

Para revisar, así es como asignamos conceptos ágiles a GitHub / ZenHub:

Nota: Sin ZenHub, sus problemas de GitHub son simplemente una lista sin
Indicación de dependencias. Las epopeyas de ZenHub agregan esta capa crucial
de jerarquía
Trabajando con epopeyas en GitHub
Si una historia de usuario es la unidad de trabajo más pequeña, una Epic es
esencialmente una "gran"
historia del usuario. Si "como cliente, quiero poder crear una cuenta" es
Una historia de usuario, toda la función de administración de cuentas puede ser una
Epic.
En ZenHub y GitHub, las epopeyas son un tema de trabajo que contiene problemas
(historias) necesarias para completar ese objetivo más grande. Mantienen el
producto
Retrasos coherentes y organizados al tiempo que proporcionan un mayor control.
De extremo a extremo sobre el proceso de lanzamiento.
Como puede ver, ahora tenemos tres tres capas jerárquicas: épica,
problema y subtarea (que puede vincularse a sus propios problemas si es
necesario).
Entonces: ¿Problema, o épico? Al decidir si un problema debe convertirse en una
Epopeya (o viceversa), tenga en cuenta el tiempo y la complejidad. Los problemas
deben completarse en el menor tiempo posible. Si un problema demora semanas o
meses en completarse, probablemente debería ser una epica Del mismo modo, si
un problema se vuelve demasiado complejo, si hay varias tareas requeridas para
completarlo - probablemente sea mejor como un Épico. La división de estas tareas
en partes de trabajo fáciles de completar ayuda reduzca la deuda técnica y le
asegura que puede enviar cambios impactantes más frecuentemente. Un flujo de
trabajo de muestra utilizando épicas e hitos. Aquí hay un ejemplo de cómo
interactúan hitos y epopeyas. Digamos 46 Estamos rehaciendo el sitio web de
ZenHub como parte de un esfuerzo de cambio de marca. Una Epic podría llamarse
"rediseño de sitio web". Dentro de esa Epic, creo Un problema para cada página en
ese sitio web:
A medida que agrego problemas a mi Epic, también crearé listas de comprobación
de rebajas de
Tareas necesarias para completar esa página.
Al comienzo de un sprint, mi equipo creará un Hito (es decir, “Sprint 3”.) Habiendo
estimado ya la complejidad de los problemas en nuestro backlog, decidiremos como
equipo qué temas deben incluirse en nuestro hito. Utilizamos tablas de reducción,
que nos dan un buen resultado. idea de cuántos puntos de historia podemos abordar
en un sprint determinado.

Claramente, no podemos completar todo el sitio web en dos semanas, pero terminar
la página de inicio parece razonable. Agregaremos el problema de la página de
inicio a nuestro hito, y quizás a un par de correcciones técnicas no relacionadas.
Juntos, estos problemas forman una parte de trabajo que, en función de la velocidad
proyectada de nuestro equipo, creemos que podemos Terminar, probar y enviar en
las próximas dos semanas. Los hitos y las épicas no son intercambiables, pero son
complementarios. Los beneficios de emparejar epopeyas e hitos Una vez que
entiendas las diferencias entre épicas e hitos, estás listo para usar ambos de
manera efectiva. 48 Las epopeyas tienen la intención de darle una amplia
comprensión de grandes iniciativas Cuando se combina con Hitos, puedes trabajar
para alcanzar Estos objetivos más grandes en iteraciones manejables. Esto significa
que entregas Más valor de negocio (código realizable) con más frecuencia. Si usas
Épicas sin Hitos, puedes quedar atascado en Detalles a medida que persigues
grandes trozos de trabajo mal definido. Si usa Milestones sin epopeyas, es difícil
planificar o perseguir objetivos más grandes. También es más difícil visualizar cómo
los trozos grandes de trabajo están progresando junto con todas sus otras tareas.
La falta de La dirección podría llevar a prioridades poco claras. Sin embargo,
emparejando Hitos con Épicas te da una forma granular. para planificar y lograr su
cartera de productos. Aclara tanto el gran Imagen y los detalles minuciosos que la
conforman, aportando todo. Es necesario enviar mejores proyectos más rápido. Una
vez que hagas eso, estarás Listo para sumar estimaciones y salir corriendo.

.
CAPÍTULO 6
Software
Estimacion:
El arte de
adivinando mal

¿Cuándo se hará? La mayoría de los desarrolladores sueñan con un mundo en el

que puedan contarle a su jefe, “La función se hará cuando la terminemos”. No es
que sean una mofa (bueno, puede que lo estén, pero no es toda la historia). Es
porque los desarrolladores son inteligentes. Esa respuesta es la única correcta.
responder. Cualquier otro es una conjetura. Pero en el mundo real, la respuesta
correcta no siempre es la más útil uno.

Estimación de software - Su conjetura es tan malo como el mio

En algún momento alrededor de finales de 1500, comenzamos a usar una palabra
que
Suena mejor que conjeturas: estimaciones.
Cuanto más grande sea un proyecto, menos precisa será la estimación. Cuanto más
lejos esté el plazo o la entrega de esa función, menos precisa será
51
Su estimación será.
Y sin embargo, esas son las situaciones de negocios y clientes.
preocuparse más por Nadie quiere trazar su curso sin una
mapa.
Al comienzo de un proyecto, las estimaciones son, en el mejor de los casos, malas
conjeturas. En contraste con el desarrollo de cascada de carga frontal, la mayoría
Los equipos ahora agregan detalles sobre las tareas a medida que descubren más
sobre
Las tareas y el proyecto. Esto significa que no sabremos mucho
De cualquier cosa al comienzo de un proyecto, lo cual está bien.
Entonces, ¿por qué molestarse en estimar las tareas de desarrollo?
Estimar una tarea es útil para armar tu carrera
reserva. Dada una cantidad de tiempo establecida, por ejemplo, dos semanas, y un
establecer un presupuesto, ¿cómo puede saber qué problemas de GitHub debe
abordar si
no para las estimaciones?
Cuando se combina con datos históricos en forma de quema o
gráficos de velocidad, su equipo puede ver qué tan rápido está realmente
52
En marcha, que es una herramienta de planificación inestimable.
Hay una gran diferencia entre trazar el rumbo de un satélite al de Jupiter
Orbitar y estimar una línea de tiempo para tareas de desarrollo de software. El
primero requiere docenas de personas con puntajes de CI de nivel MENSA y miles
de millones de
dolares en financiacion; Este último requiere algo más parecido a un hecho en casa.
Brújula y un mapa de la estación de gas. Solo necesitas tener una idea general de
a dónde vas y la ruta que vas a tomar para llegar allí. Las estimaciones son cómo
se hace eso.
¿Cómo debes estimar?
Hay dos tipos principales de estimaciones: punto de la historia y tiempo.
Estimación de puntos de historia
Las personas son mediocres al adivinar qué tan grande es algo en términos
absolutos,
Como horas o días. Pero somos sorprendentemente buenos para evaluar algo en
Relación con otra cosa.
53
Por ejemplo, si le da a una persona dos pilas de frijoles, probablemente no
Poder decirle cuántos frijoles hay en cada pila. Sin embargo, deberían
poder decir que una pila es aproximadamente el doble del tamaño de la otra pila.
Esa es la base de los puntos de la historia. Es una escala de medida sin unidades
en la que
Las "unidades" se dimensionan una en relación con la otra. A diferencia de las horas
o días, que son
Mediciones específicas basadas en valores consistentes - se basan en arbitrarias
Mediciones que no tienen otro propósito que comparar el tamaño de una tarea.
con el tamaño de tus otras tareas.
La estimación ágil utiliza un sistema basado en puntos porque es rápido y no se
Necesito enfatizar acerca de cómo se comparan sus datos reales con sus
estimaciones. Punto
las estimaciones también nos recuerdan que las estimaciones no son una fecha
límite, sino
adivinar.
Tus prioridades a la hora de estimar.
Cualquiera que sea su método de estimación, debe priorizar dos cosas.
El equipo.
Nunca estimar en un vacío. Aprovecha la sabiduría de la multitud en tus
estimaciones. Tus estimaciones serán mejores y tu equipo te agradará más.
Velocidad.
No te dejes atrapar por los detalles, porque aún estás adivinando.
54
Tres formas de estimar el software.
Hay algunas formas principales en las que puede abordar el desafío de la
estimación:
Planeando poker
Todos en el equipo obtienen un juego de cartas con estimaciones puntuales.
Cuando se lee un problema, cada ingeniero sostiene una tarjeta de estimación que
consideran apropiada. El beneficio de este método es la discusión, no el
compromiso: si Sarah y
Tim sostuvo uno y siete respectivamente, no le dé a la tarea una estimación de
cuatro Hablar sobre por qué sus estimaciones son tan diferentes puede revelar
problemas de comunicación sobre el alcance, lo que es útil.

Tallas de camiseta
Se trata de simplicidad. El uso de tallas de camiseta (XS, S, M, L, XL) te garantiza
no analizará demasiado las cosas, y son otro recordatorio de que sus estimaciones
no se pueden equiparar a las medidas del tiempo. Haz que tu equipo venga con
un rango de puntos de historia que es igual a un XS, S, L, etc. Si algo es un
XL, considera dividirlo en varias tareas más pequeñas.
Triangulación
Triangulación es solo una palabra elegante para "emparejar como con".
Tome sus problemas y elija uno que sea definitivo. Toma otra que sea
una estimación de diez. Y otra que está en algún lugar cerca del medio. Ahora
Usted tiene una base sobre la cual puede estimar el resto de sus problemas
comparativamente. Haga coincidir el resto de sus tareas en relación con estas
estimaciones de referencia: ¿Es esto?
problema más grande o más pequeño que mi "uno"? Continúa hasta que todos tus
problemas sean
estimado relativamente
55
¿Qué pasa con las estimaciones de tiempo, entonces?
De vuelta a esa conversación con tu jefe. "¿Cuándo lanzaremos esta función?"
Pregunta ella.
"Bueno", respondes, "es un pequeño extra".
No has resuelto exactamente su problema, ¿verdad?
Las estimaciones de tiempo son útiles solo cuando tiene suficiente información, que
es decir que debe usarlos cuando su equipo de desarrollo haya reunido algunos
detalles y haya realizado un trabajo de descubrimiento.
En contraste con las estimaciones puntuales, las estimaciones de tiempo se refieren
a la productividad real de las personas reales. Lo que le lleva a Sarah tres horas
podría llevarle a Sam dos
dias. Es por eso que nadie, excepto la gente que codifica, debería estar estimando
el tiempo.
Si está agregando estimaciones de tiempo, considere el alcance del problema como
fijo.

¿Cuándo y cómo deberías estimar?

Algunas personas usan estimaciones de tiempo; otros usan puntos de historia.

Después de probar un
56
dos métodos, aquí es en lo que hemos aterrizado.
Primero, no pasamos tiempo estimando tareas hasta que hayamos hecho un trabajo
de descubrimiento. Para mantener los gastos generales lo más bajos posible, los
problemas que se encuentran en nuestro Icebox nunca se estiman.
En este punto, nuestros problemas se han dividido en consecutivamente más
pequeños
trozos a medida que aprendemos más sobre ellos. Esto probablemente significa
que están sentados
en nuestra cartera de productos (la cartera de trabajos pendientes sin Milestone
adjunto)
Al agregar estimaciones en esta etapa, podremos construir nuestros
backlog de sprint (es decir, qué problemas agregar a nuestro próximo hito de
GitHub).
Los problemas que se estiman y Milestoned aparecen automáticamente en nuestros
gráficos de Burndown. Cuando se cierra un problema, aparecerá un nuevo punto de
datos en la
gráfico. Como resultado, podemos ver cómo se compara nuestra velocidad de
trabajo proyectada
con nuestra realidad.
Las estimaciones de software siempre han sido consideradas un desafío, pero con
un
poca práctica, algo de experimentación y algunos datos históricos, su equipo
será recompensado con más previsibilidad y mayor confianza en su
proceso de desarrollo. ¿Vale la pena hacer estimaciones? Lo adivinaríamos.