3.Planificación de Proyecto

7/23/2019 3.Planificacin de Proyecto

1/50

Planificacin de

ProyectoPlanear para el xito


2/50

En serio, mi desarrollo desoftware est tan bien

planeado que llegar a tiempotodos los das para ver el futbol

juntos

Cada pieza del software empieza con un gran plan.Ahora vamos a aprender cmo crear ese plan. Aprenderemos a trabajar con el cliente parapriorizar sus requerimientos. Definiremos las iteraciones que trabajaremos con nuestroequipo y finalmente crearemos un plan de desarrollo alcanzable que, con nuestro equipo,podamos ejecutar y monitorear. Cuando terminemos, sabremos exactamente ir desde los

requerimientos a nuestro primer entregable


3/50

Los clientes quieren su software AHORA!.Los clientes quieren su software cuando lo necesiten y ni un minuto despus. Ya tenemos las ideas delclientes utilizando lluvias de ideas, ya tenemos un conjunto de historias de usuarios que describen todo loque el cliente pueda necesitar para el software, y hasta hemos aumentado un estimado a cada historia deusuario que nos ayud a averiguar cuanto nos tomar entregar todo lo que el cliente desea . El problema es,el desarrollar todo lo que el cliente necesita tomar mucho tiempo...

Nuestro Estimado Lo que el cliente desea

489 Das! 90 Das!El total despus de sumar todos los

estimados de las historias deusuario

Bueno, obviamente nopodemos hacer todo lo que elcliente quiere en 90 das. por

qu no reducimos ypriorizamos


4/50

Planificacin.Orbit an necesita modernizar el sistema de reserva; solamente que no pueden esperarcasi dos aos para que el software este terminado. Tomando y priorizando los msimportantes podramos priorizar las ms importantes


5/50

Estas son lashistorias deusuario que

hemos elegido

Pero eso no es lo que yoquera... Para nada!

Pudimos ingresar estashistorias para llenar los

90 das

El cliente decide las prioridadesParece que el dueo de Orion's Orbits no est contento,y lo podemos culpar? Despus de todo ese trabajo quetuvimos para averiguar lo que necesita, lo hemos ignoradocompletamente cuando decidimos qu historias deusuario son prioritarias en el proyecto.Cuando las historias de usuario se priorizar, necesitamosenfocarnos en el cliente. nicamente el cliente conoce loque se necesita. As que cuando tenemos que decidir loque entra y lo que no, nosotros podremos proveer algo de

ayuda experta, pero al final es una eleccin que el clientetiene que hacer

Nuestro Estimado Total


6/50

Priorizar con el clienteEs el trabajo de tu cliente decidir cual es la prioridad de las historias de usuari, para ayudar a tu cliente atomar la desicin, revuelve las tarjetas Y colcalas en la mesa y dile a tu cliente que las ordene porprioridad (las ms importantes para el primero) y luego selecciona el conjunto de caractersticas quenecesitan ser entregadas en el Milestone 1.0 del software

Qu es el "Milestone 1.0"?El Milestone 1.0 es tu primer lanzamiento principal del software para el cliente. A diferencia de lasiteraciones ms pequeas donde le mostramos el software al cliente para retroalimentacin, el Milestoneser las primera vez que vamos a entregar software de verdad (y recibiremos paga posiblemente) acontinuacin buenas y malas ideas cuando planeamos el Milestone 1.0

Buena

Idea...

Balancear la funcionalidad con la impaciencia del cliente.

Ayudemos al cliente a comprender qu puede cumplirse en el tiempo disponible. Cualquier historia deusuario que no entra en el Milestone 1.0 no sern ignoradas, solo pospuestas para el Milestone 2, o 3...

Mala

Idea...

Planear "seran buenos..."

El Milestone 1.0 trata de entregar lo que se necesita, y eso significa entregar un conjunto de

funcionalidad que cumpla con las necesidades ms importantes del cliente.

Mala

Idea...

Preocuparte por la longitud (al menos no ahora)

En este punto le preguntamos al cliente cuales son las historias de usuario ms importantes. No letomemos importancia a cunto tiempo tardar en lograrse. Estamos tratando de entender lasprioridades del cliente


7/50

Ya sabemos lo que es el Milestone 1.0 (bueno, casi)De todas las historias de usuario desarrolladas a partir de las ideas del cliente, organizadas en orden deprioridad, el cliente selecciona las historias de usuario que desea formen parte del Milestone 1.0 delsoftware


8/50

Prueba de cordura para tu Milestone 1.0Ahora que conocemos las caractersticas que el cliente desea en Milestone 1.0, es hora de averiguar sitenemos una longitud de trabajo razonable del proyecto si desarrollamos y entregamos todas esascaractersticas importantes...

273 DasSuma todoslos estimadosde lashistorias deusuario del

Milestone 1.0


9/50


10/50

Qu diferencia existe entre elMilestone y una Versin?No mucha. De hecho podramos llamar al primer Milestone"Versin 1.0" si as deseas. La gran diferencia entre ambos es que elMilestone marca un punto en el cual entregamos softwaresignificativo y obtenemos paga del cliente, donde la versin no es

ms que un simple trmino descriptivo que es utilizado paraidentificar un lanzamiento especfico del software.

La diferencia es muy sutil, pero la manera ms simple de entenderes que la "Versin" es una etiqueta y no significa nada ms, y elMilestone es entregar funcionalidad y recibir pago.

Puede coincidir que la Versin 1.0 sea la misma que el Milestone1.0, pero de la misma manera puede ser que el Milestone 1.0 seasolo la versin 0.1 o 0.2 o cualquier etiqueta que elijamos


11/50

Cul es la funcionalidad base demi software?Es el conjunto ms pequeo de caractersticas que se necesitatener para que sea til para el cliente y sus usuarios.

Si pensamos en una aplicacin de procesamiento de palabras, su

funcionalidad base sera dejarnos cargar, editar y grabar texto aun archivo. Cualquier otra cosa es ms all de la funcionalidadbase sin importar qu tan til sea la caracteristica. Sin podercargar, editar y grabar un documento con texto en l, unprocesador de palabras no es til.

Esta es la regla principal: si podemos trabajar sin unacaracterstica, entonces esta no es una funcionalidad base, y esprobablemente un buen candidato para retrasarlo a otroMilestone que el primero en el caso de que no nos alcance eltiempo


12/50

Hice los clculos y sin importar cuantas historiaselimine, no puedo entregar lo que mi cliente desea enel tiempo que me dan Qu puedo hacer?

Es hora de confesar, desafortunadamente. Si en verdadno podemos construir el software que se requiere en eltiempo que se necesita, y el cliente simplemente no deja

sacar ms historias, entonces vamos a tener que salirnosde ese proyecto y al menos saber que fuimos honestoscon el cliente.

Otra opcin es intentar incrementar el equipo connuevas personas para intentar realizar ms trabajorpido. Sin embargo, agregar ms personas al equipohar subir los costos considerablemente, y no tendremoslas ventajas necesariamente que nos imaginamos.


13/50

Y no podemos simplemente agregar ms personaspara minimizar los estimados? Agreguemos dos

desarrolladores ms y haremos el trabajo en 1/3 deltiempo verdad?

Despus veremos al grfico defrecuencia Burn-down

Es ms que tiempo de desarrolloAgregar ms personas puede ser muy atractivo al principio, realmente noes tan simple como decir "el doble de personas, mitad de estimacin"Cada nuevo miembro de equipo necesita ponerse al da en el proyecto;necesitan entender el software, las desiciones tcnicas y cmo todo seuna al final; y mientras hacen todo eso no podrn ser 100% productivos.Luego necesitamos que esa nueva persona configure las herramientas

necesarias y equipamiento para trabajar con nuestro equipo de trabajo.Esto puede significar la compra de nuevos muebles, equipos y licencias,pero incluso si solo signifique descargarnos software gratuito u opensource, todo nos tomar tiempo y ese tiempo necesita ser factorizado ennuestrs estimaciones.Finalmente, cada persona que aumenta en nuestro equipo hace msdifcil mantener el rastro de todo. Mantenerlos a todos en la mismadireccin puede ser un trabajo de tiempo completo, y mientras el equipoaumenta de tamao encontraremos que la comunicacin se har ms

complejas puede empezar a afectar la habilidad del mismo equipo paradesarrollar software.De hecho, existe un mximo nmero de personas que nuestro equipospuede contener y aun ser productivo, pero depender mucho delproyecto, del mismo equipo y de la persona que estamos agregando. Lamejor tcnica es monitorear el equipo y si este empieza dar menosresultados o ser menos productivos, a pesar del aumento de personal,entonces es hora de revaluar la cantidad de trabajo que se har o lacantidad de tiempo en que se har.


14/50

Ms personas a veces quiere decir disminucin de valores de

retornoAumentando ms personas al equipo no siempre funciona como se espera. Si una personatoma 273 das en completar el Milestone 1.0, entonces 3 personas no necesariamente setomarn 91 das. De hecho podran tomarse ms tiempo aun! Observemos... El desempeono siempre aumenta con el tamao del equipo?

Desempeo

Personas


15/50

Existe un nmero mximo deintegrantes de equipo que nunca debo

sobrepasar?En realidad no. Dependiendo de la experienciapodras manejar equipos de 20 personas, pero tal vezsea imposible manejar 21. De manera alternativa

podemos encontrarnos con equipos de 3desarrolladores, y si aumentamos ms personaspodramos hacer bajar el desempeo. La mejortcnica es monitorear el desempeo del equipo de

manera muy cercana y realizar ajustes basados en lasobservaciones


16/50

Lleguemos a un Milestones 1.0 razonableCuando tratamos de trabajar con tres desarrolladores en lugar de solamente uno (agregandodos) podra tener un impacto positivo. Veamos como puede funcionar

Primero agregamos dos personas nuevas al equipo...Agregando dos desarrolladores al equipo (es decir tres incluyndote) ayuda, pero noes una solucin mgica. Dos desarrolladores puedes agregar mucho trabajo al

proyecto, pero aun queda mucho ms por hacer.

...y luego volvemos a priorizar con el clienteAhora tenemos una buena manera de averiguar lo que se tiene que remover. Tenemos 189das de trabajo en equipo y 273 das de trabajo. As que necesitamos hablar con el cliente y

remover 84 das de trabajo eliminando y separando algunas historias de usuario delMilestone 1.0

273 dasde trabajo

189 dasDe trabajo

sobrantes

273 das detrabajo Caractersticasremovidas por el cliente

3 desarrolladores

84 das

184 dasSe ve mucho mejor, con unoscuantos das de sobra para darnos

un poco de respiro en el Milestone


17/50

Pero 184 das de trabajo es menor a los 189 dasque nuestro equipo puede producir, nodeberamos sumar caractersticas con el cliente?

El estimado en general no tiene que ser exactamentelos 189 das. Dado que estamos tratando conestimaciones, las cuales no son 100% precisas, y que

tendemos a ser un poco optimistas en nuestrosestimados, entonces 184 das es bastante cercano ala marca de 189 das para estar lo suficientementeconfiado.


18/50

Cmo sacamos los 189 das cuandoagregamos dos desarrolladores?

En este punto este nmero es solo otra estimacin.Lo hemos adivinado asumiendo que al agregar dospersonas para formar un grupo de tres podremos

trabajar 189 das de trabajo en 90 das de calendario.Ms adelante respaldaremos esto con el clculo develocidad del equipo.


19/50

Una vez priorizadas lastarjetas de acuerdo a la

importancia desde elpunto de vista delcliente

Clave de Prioridad

-Ms importante

-Menos importante


20/50

Por qu las prioridades son 10,20, 30, 40, 50?Hacerlo en grupos de 10 hace que el cerebro seconcentre en grupos de caractersticas en lugar deordenar cada caracteristica de manera separada

como por ejemplo 8 o 26 o 42. Estamos tratando queel cliente decida las caractersticas ms importantes yno que se concentre en los nmeros exactos.Tambin, los grupos de 10 nos permiten especificar

ocasionalmente, por ejemplo, un 25 a algunacaracterstica que tal vez queremos insertar si nosqueda tiempo


21/50

Y si es 50, entonces es mejordejarlo fuera, verdad?No, 50 no significa que la historia de usuari escandidata a salir. En este punto estamos trabajandocon las historias de usuario que pertenecen al

Milestone 1.0, o sea que estas historias ya llegaronde un filtro que el cliente seleccion como las msimportantes. El objetivo es priorizar, y no descifrar silas caractersticas son importantes. Entonces 50 nos

dice que podemos desarrollarlas despus, y que noes tan importante para el cliente.


22/50

Qu hago con las tarjetas que noentraron al Milestone 1.0?Asignales una prioridad de 60, para que no semezclen o confundan con la del Milestone 1.0


23/50

Y el cliente tiene que hacer todoeste trabajo?Tu puedes ayudar y dar consejos, y tal vez mencionarlas dependencias entre algunas historias de usuario.Pero la ultima desicin de priorizar es siempre del

cliente


24/50

Iteracin 1

Iteracin 2

Iteracin 3

Total de Das:

Total de Das:

Total de Das:

Dividido para 3desarrolladores:



Qu crees que deberamos hacer al final de la iteracin

Mostrarle al cliente y obtener suretroalimentacin


25/50

Qu pasa si al final de la iteracinno tengo nada que mostrar?

La nica manera que podemos terminar sin nada quemostral al final de la iteracin es si no completamosninguna historia de usuario durante la misma. Si nos

las ingeniamos para lograr esto, entonces tu proyectoest fuera de control y necesitas poner las cosas enorden lo ms pronto posible.


26/50

Mantn tu software

construyndosecontinuamente ysiempre ejecutable

para que podamosobtenerretroalimentacin delcliente al final de laiteracin


27/50

Las iteraciones deben ser cortas y cmodasHasta ahora nos hemos enfocado en iteraciones de 30 das, es decir 3 iteracionesen un proyecto de 90 das. Podemos utilizar iteraciones de distinto tamao, perosiempre asegurarnos de tener los siguientes principios en mente

Mantener las iteraciones cortasEntra ms cortas sean las iteraciones, ms oportunidades tendremosde encontrar y arreglar cualquier cambio o detalle inesperado cuandose presente. Una iteracion corta nos dar retroalimentacin ms

rpido y de esa manera podemos ajustar algn plan, incluso hastacambiar lo que se har en la siguiente iteracion, y antes de lanzar algodefectuoso en Milestone 1.0

Mantener las iteraciones en balanceCada iteracin debera estar balanceada entre manejar los cambios,

agregar nuevas caractersticas, destruir los bugs (errores) ycontabilizar personas trabajand. Si tenemos una iteracin cada mes,realmente no son 30 das de trabajo. Las personas toman fines desemana libres (al menos de vez en cuando), debemos contabilizarvacaciones, los bugs y las cosas que aparezcan en el camino. Unaiteracin de 20 21 das es ms preciso contabilizar como trabajo de

30 das calendario, o iteracin de un mes.


28/50

Iteraciones cortas nosayudan a llevar

empeora el rastro delos cambios y amantener al equipo

motivado y enfocados

d l l lid d


29/50

Comparando nuestro plan con la realidad

Parece que iremos bien con el plan siemprey cuando trabajemos los 5 das a la semana

a tiempo completo

Bob: oh, por cierto, Nick va a venir a las 11 hoy, el tieneuna cita con el mdico...Laura: Qu?Bob: y ya que estamos hablando de eso, los muchachosde TI estn instalando la nueva versin de Oracle en mimaquina esta tarde, as que vayamos anotando esotambin.Laura: Oh genial, alguna otra sorpresa de la cual debaestar al tanto?Bob: bien..., me toca la semana de vacaciones este mesy se viene tambin el da del trabajo...

Laura: Perfecto, cmo podemos crear un plan quefactorice todas estas sobrecargas para cuandotengamos que firmar con el cliente tengamos un plande entrega?


30/50

La velocidad contabiliza las sobrecargas en las

estimacionesEs hora de agregar un poco de realidad a nuestro plan. Necesitamos factorizados todas las sobrecargasmolestosas mirando qu tan rpido nosotros y nuestro equipos desarrollamos software. Aqu es dondeentra la velocidad. La velocidad es un porcentaje dado X nmero de das, cunto de ese tiempo es trabajoproductivo?

Pero cmo puedo conocer larapidez de desempeo de mi

equipo? Recin estamosempezando!

Empecemos con una velocidad de 0.7

En la primera iteracin con un nuevo equipo es justo asumirque el tiempo de trabajo del equipo ser de 70% de sutiempo disponible. Esto significa que nuestro equipo tendruna velocidad de 0.7. En otras palabras. Por cada 10 das detrabajo hora, al rededor de 3 das sern tomados por dasfestivos, instalacin de software, papeleo, llamadas portelfono, emails, y otras tareas diferentes al desarrollo.

Este es un estimado conservativo, y nos daremos cuentaque con el tiempo que la velocidad de nuestro equipo enrealidad es ms alta. Si ese es el caso, entonces, al final denuestra iteracin actual ajustaremos la velocidad yutilizaremos la nueva figura para determinar cuntos dasde trabajo podemos llevar a la siguiente iteracin.

Lo mejor de todo, podemos aplicar velocidad a la cantidad

de trabajo, y obtener estimados realistas de cuanto tiempoese trabajo nos tomar en realidad

Otra razn mspara tener

iteraciones deduracin corta,

podemos ajustar lavelocidad demanera ms

frecuente


31/50

VelocidadDas requeridos parahacer el trabajo

Los programadores piensan en das utpicos


32/50

Los programadores piensan en das utpicos...Preguntemos a un programador cuanto tiempo se tomar en hacer algo, como escribir una interfaz en PHPo una base de datos MySQL o hasta dibujar una captura de pantalla con lpiz. Ellos nos van a dar unestimado muy optimista

Esto es lo que un programador dice...

Seguro, no hay problema,puedo hacerlo en dos das.

Me tomar un RedBull cuando vaya a casa,programare hasta las 3 A.M., tomar un descansojugando Halo, luego trabajar toda la maana ydormir un poco, llamar a los muchachos paraque trabajen conmigo y terminar a la medianoche. Mientras todo salga bien y mi mam no

quiera que pase comprando la cena

pero en realidad est pensando


33/50

Los programadores piensan en das del mundo realPara ser un desarrollador de software, debemos tratar con la realidad. Probablemente tengamos un equipode programadores, y un cliente que no nos pagar si nos retrasamos. Encima de todo eso, tal vez tengamosa otras personas que dependen de nosotros, as que nuestros estimados deben ser ms conservativos ytambin deben tomar en cuenta el mundo real


34/50

Cundo la iteracin es muy larga?Supongamos que tenemos tres desarrolladores en el equipo que trabajan a velocidad de 0,7. esto significaque para calcular cuanto tiempo se tardar el equipo en esa iteracin, necesitamos aplicar nuestra velocidadal estimado de iteracin


35/50

Entonces si tenemos 3 desarrolladores, cada uno deellos tiene que trabajar 79 das en 3 meses perosolo hay 60 das de trabajo

Ni siquiera con tres personaspodemos entregar el

Milestone 1.0 a tiempo!


36/50

Solucionar la velocidad antes de las iteracionesTodo este problema pudo haber sido evitado si hubiramos aplicado velocidad desde el principio delproyecto. Aplicando velocidad desde el principio, podamos calcular cuantos das de trabajo podamosproducir con nuestro equipo en cada iteracin. De esa manera sabramos exactamente lo que podramosentregar para el Milestone 1.0.

Primero, aplicamos la velocidad del equipo en cada iteracinTomando el nmero de personas en nuestro equipo, multiplicado por el nmero real de das detrabajo en nuestra iteracin, multiplicado finalmente por la velocidad del equipo, podemos calcularcuantos das de trabajo real nuestro equipo puede producir en una iteracin

Suma las iteraciones para obtener el total del Milestone 1.0Ahora deberamos estimar el nmero de iteraciones que necesitamos para el Milestone 1.0.Multiplicando los das de trabajo por el nmero de iteraciones, y obtendremos el nmero de das de

trabajo que podemos dedicarle a las historias de usuario para nuestro Milestone 1.0

Q d i ! i


37/50

Qu desgracia! nicamente tengo14 das de trabajo productivo por

iteracin si mi velocidad es de 0.7?0.7 es una estimacin conservativa para cuandotengamos nuevos miembros en el equipo queintentan ponerse al da, entre otras sobrecargas.

Mientras t y tu equipo vayan completando otrasiteraciones, revisarn esa velocidad y la actualizaranpara reflejar cun productivos realmente son.


38/50

Con la velocidad, mi Milestone 1.0 me tomarahora 79 das de trabajo, lo que significa 114 dasde calendario. No es eso demasiado tiempo?

S, Orion necesita su Milestone en 90 das decalendario, y aplicando velocidad ahora tenemosdemasiado trabajo que hacer para llegar a esa meta.

Debes volver a analizar tu plan para ver lo que enrealidad puedes lograr con el tiempo y el equipo quetienes.


39/50


40/50

Que mal! O sea que tupuedes hacer todo excepto

esta caracterstica?... hmmdjame pensarlo

Dar las malas noticias al clienteEs hora de hacer lo que todo desarrollador de software teme. Planeamos la iteracin,factorizamos la velocidad del equipo, pero an no podemos hacer todo lo que el cliente

quiere para esa fecha. No hay nada ms que hacer que ser honestos.


41/50

Manejar a los clientes enojados

Los clientes generalmente no estarn felices cuando les digas que no puedes tener todohecho en el tiempo que ellos quieren. Se honesto, siempre y cuando lo hagas con un plan

para el Milestone 1.0 que s puedes lograr, no con un plan que diga lo que el cliente quieraescuchar.

Entonces qu podemos hacer cuando eso suceda?

Es casi inevitable que en algn momento no puedas hacerlo todo, as que ayudara estarpreparado con algunas opciones cuando le digas las malas noticias al cliente

1. Agregar una iteracin a Milestone 1.0

Expliquemos que el trabajo extra puede ser realizado si aadimos unaiteracin ms al plan (alargar fecha). Esto significa un itinerario dedesarrollo ms largo ( junto con los costos), pero el cliente obtendrlo que el quiere en Milestone 1.0


42/50

2. Explicar que el trabajo sobrante no est perdido, solo pospuesto

A veces ayuda el sealar que las historias que no llegaron a Milestone1.0 no se van a perder; solamente estn puestas en espera hasta un

siguiente Mileston

3. Ser transparente en cmo sacaste los nmeros

Suena extrao, pero el cliente solo ha escuchado nuestra palabracuando dijimos que no entregaramos todo lo que ellos desean dentrode la fecha que ellos nos dieron. A veces ayuda explicar de dondevienen, y si puedes mustrales los clculos que respaldan nuestravelocidad y cmo esto repercute en sus necesidades. Digmosletambin que queremos entregar software que funcione, y que poreso tenemos que sacrificar algunas caractersticas para darnos un plan

con el cual estemos en confianza de entregar algo al final

Si d i


43/50

Si voy muy cerca de misestimaciones, puedo tratar de meter

algo con el tiempo sobrante?No se recomienda eso. Recuerda, las estimacionesson solo suposiciones educadas en este punto, y esms probable que se toman ms tiempo de lo

pensado que lo contrario.Es una mejor idea dejar un espacio de respiro en lasestimaciones para estar verdaderamente confiado deque hemos planeado un conjunto de iteraciones

exitoso

0 7 d i d ti


44/50

0.7 parece demasiado tiempoperdido. Qu tipo de actividades

pueden tomar tanto tiempo?0.7 es una velocidad segura, un ejemplo es cuandoinstalamos software nuevo, como un IDE o una basede datos (sin hablar de una marca especfica, claroest). En casos como este, dos horas de instalacinpueden transformarse hasta en CUATRO horas hastaque el desarrollador entre en la zona y puedadesarrollar productivamente.

Tambin vale la pena mencionar que la velocidad es

recalculada al final de cada iteracin. As que si 0.7 esmuy bajo para nuestro equipo en este momento,podremos corregirlo tan pronto tengamosevidencias.


45/50

Est bien! Hagmoslo, vamosa terminar el Milestone 1.0sin aquellas caractersticas

para as poder avanzar con elproyecto rpidamente


46/50

El tablero en la pared

Una vez que sepamos exactamente lo que vamos a construir, eshora de configurar el tablero de control de desarrollo para laiteracin 1. nuestro tablero es realmente solo una pizarra grandeen la pared de la oficina que sirve para llevar rastros de lostrabajos en espera, en progreso y lo que ya se ha completado


47/50

Historias de usuario


48/50

Das restantes

Burn Down

Siguiente

Completado

Trabajorestante


49/50

Cmo arruinar la vida personal de tu equipo

Es fcil mirar todos los itinerarios, estimaciones crecientes y ciclos de iteracin

disminuyendo y pensar El equipo puede trabajar semanas ms largas!. Silogramos que el equipo est de acuerdo con eso, entonces lo ms probable serque nos meteremos en problemas.

Las vidas personales importan

Las largas horas eventualmente van a afectar nuestra vida personal y la vida

personal de nuestros desarrolladores. Eso podra ser trivial pero un equipo felizes un equipo ms productivo

La fatiga afecta la productividad

Desarrolladores agotados no son productivos. Muchos estudios sugieren que losdesarrolladores son ms productivos por cerca de tres horas al da. El resto delda no est perdido, pero entre ms cansados estn, menos probables ser que

lleguen incluso a esas tres horas productivas


50/50

Ten confianza entu planificacin

aplicandovelocidad y no

haciendotrabajar de msni a ti ni a tu

equipo

3.Planificación de Proyecto

Documents

Transcript of 3.Planificación de Proyecto