-
Dilbert’s Estimation The Purpose of Planning
Before talking about the Cone of Uncertainty and estimation lets clarify some things about planning. I constantly tell my friends and co-workers that ideas are not the same as planning. Remember the last time you started something that, for several reasons, you never ended, or that time you said my “plans” are …, but in reality, you never took real actions to execute those “plans” or you just keep putting them off. The main difference between ideas and plans is basically that ideas are vague, aspirational, and desirable; while true planning takes ideas further and establishes goals along with preconceived steps to take that eventually help to estimate, make decisions, and even refine or change the plan.
In the same way that it happens in life, in the software and IT industry in general, estimations and planning are of the utmost importance for the success of any project. The plans are a guide that tells us where to invest our time, money, and effort. If we estimate that project will take us a month to complete and in return, it will generate a million dollars, then we may decide to carry out that project. However, if the same project generates that million dollars in 15 years, then perhaps it is better to reject it. Plans help us to think ahead and know if we are progressing as expected among other things. Without plans, we are exposed to any number of problems.
In my experience as a developer, scrum master, project manager, etc., teams tend to two extremes: They don’t make any plans at all or they try so hard on a plan that they convince themselves that the plan is actually correct. Those who do not plan simply cannot answer the most basic questions, like, when do they finish? or, will it be ready before the end of the year? Those who plan too much, invest so much time in their plan that they fall into assumptions that they cannot confirm, their insecurity grows more and they begin to believe that even by planning more they will achieve more accurate estimations although this does not actually happen. If you feel identified with any of the previous scenarios, in your favor I can say that planning is not easy.
But that plans fail and planning is complicated is not news. At the beginning of a project, many things can be unknown, such as the specific details of the requirements, the nature of the technology, details of the solution, the project plan itself, team members, business context among many other things. But then, how do we deal with these riddles? How do we deal with uncertainty?
The Cone
These questions represent a problem that is already quite old. In 1981, Barry Boehm drew what Steve McConnell later called the Cone of Uncertainty in 1998. The cone shows that in a sequential or “cascade” project that is in the feasibility stage, we will normally give an estimate that is far from reality, in a range of between 25% and 400%. This is for example, that a 40-week project will take between 10 and 160 weeks. By the time we finish obtaining requirements, our estimate will still be between 33% and 50% out of date. At this point, our 40-week project will take between 27 and 60 weeks. Imagine what happens with those projects that are never clear about their requirements.
How to deal with the Cone of Uncertainty?
Buffering (margin of error)
This is to use a percentage of time and/or resources to cushion the effect of materializing risks. You have to be careful, a common reaction is to put double or triple the time to estimate a project, this is NOT buffering, this is “padding” which IS NOT a good practice. Giving a too large number will cause sponsors or clients to resist and not approve your project. Give them a too low number and you will take the risk of running out of time and money. This becomes doubly risky when you are using fixed contracts for your proposal, where there is even more pressure to keep costs down.
It is important that you make use of historical data to compare your current project with other completed projects and obtain reasonable and justifiable numbers in order to get a margin of error or buffering. Include postmortem processes or lessons learned at the end of each project to support your buffering figures in the future.
Estimate in ranges
Something I like about agile approaches for project management is being honest from the beginning and never use closed figures, but be transparent and always use ranges, especially in projects that seek to innovate and try new things where there is a lot of uncertainty. This is for example:
Look. We don’t know how long this is going to take, however, the following is our best bet based on the information we have so far. But if we can do a couple of iterations, we can develop something, evaluate how long it takes, and then have a much better idea of how big this is.
Also, present the best estimate at the moment as a range. This can help project sponsors to decide how much risk they are willing to accept.
Relative estimation
There have been various investigations on how to make estimates of effort and it has been discovered that people are good at estimating the size of something comparing it with a reference (Software Development_Effort Estimation). For example, someone cannot tell you how high the building you live in is, but they can tell you that it is approximately twice the height of the other. You can apply this principle to projects too.
Note. Agile approaches use interesting concepts like Story Points and Ideal Days to make relative estimates.
This is not a foolproof measure, you can still misjudge. But it is certainly good to get initial funding that allows the team to build something and see how long it takes to complete this progress, while simultaneously they learn more about what needs to be achieved, in such a way that this experience is used to reduce the variance of that estimated starting number.
Why is all this happening?
There is no doubt that there is always pressure from the financial sector of organizations to make estimates for an entire project or for a whole year, although these practices ultimately backfire 😀
The best thing to do is to permeate this knowledge in your organization, and constantly remind and communicate that the goal of estimating is not to guess the future, but to determine whether the project goals are realistic or even possible.
Some interesting links:
Part of the list of topics for this post and the idea of the graphic with the little sun 🙂 were partially based on articles from agilenutshell.com
These are some recommended books to know more:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured / Scrum
Size matters?
This is a very old question, but in this blog, we only will answer that question from the project management point of view (disappointed people please go to another kind of blogs). This time we will see what are and what is the purpose of the famous User Stories and how they differ from traditional requirements in a project.
When I was a kid I spent a lot of time playing on the beach with my cousins, and in some of those games, I found myself digging, transporting and piling sand from one point to another (my tools were a shovel and a plastic bucket) after about 10 minutes my youngest cousin asked me how long it had taken me to gather all that sand, to which I replied: “about 30 laps”. After that, both my cousin and I assumed that with his own bucket he could double the amount of sand, doubled in another 30 laps. It wasn’t like that, it took a lot longer for my little cousin because we both failed to evaluate the capacity of his bucket and appreciating that Gabriel (my cousin) being very young (maybe 6 years old) he still had to strain to load a bucket of different size completely filled and finish in only 30 laps.
As simple and obvious as this anecdote may seem, the reality is surprising, since many work teams responsible for projects of all sizes continue to fall into this same error. They are not yet fully aware of their capacity or speed, nor are they clear about the difference between size and distance in a project, and therefore, they fail from the beginning in their estimates.
Not taking care of trying to measure the size of what you are going to do is an error, therefore the size does matter, and before measuring times and distances you should know the answer to questions like, what is the size of your bucket and shovel? How many buckets and shovels do you have? Are there enough people for each shovel and bucket?
What are the User Stories?
For ease, the concept is often oversimplified, saying that User Stories are the requirements of a system or a product, but they have serious differences with other common approaches such as use cases, IEEE 830 software requirements specifications, and design and interaction scenarios.
User stories are short, simple descriptions of a feature told from the perspective of the person who wants the new functionality, usually a user or customer of the product that they want to create. In general, they follow a simple template:
As <user type>, I want <some goal> so that <some reason>.
User stories are often written on chips or sticky notes, stored in a box and organized on walls, boards or tables to facilitate planning and discussion. As such, they strongly change the approach of writing about characteristics, to discussing them. In fact, these discussions are more important than any text that is written.
This is a simple definition about what a User Story is, but believe me, there is much more behind, writing good User Stories can be a challenge, and to create good stories you have to understand more about their purpose.
Assign Value (points) to User Stories
Eventually, when I became involved in project management and later Agile, I discovered that one way to estimate the size of what is needed is to use the User Stories. To explain what they are I will continue using the analogies.
When was the last time you went to a restaurant and ordered a soup or a drink in milliliters? … That’s right, we usually don’t do that, we usually order a soup or a drink with a relative measure like “small, medium or large”. User stories are also relative, they are used to express size, they don’t have a standardized value, but the values must be relative to each other, that is, a User Story that has value 2 is twice the size of one User Story that it’s worth 1.
To assign values or points to different sizes there are those who use shirt sizes, dog breeds, Fibonacci values (my favorite values) or other representations, no matter what you prefer, you should eventually use relative values. Take the following table as an example, with a possible assignment of points:
Tamaño Camisa Puntos XS 1 S 2 M 3 L 5 XL 8 XLL 12 In an Agile project, it is not uncommon to start an iteration with requirements that are NOT fully specified, the details will be discovered later during the iteration. However, we must associate an estimate with each story that we can see at the moment, even those that are not completely defined.
And where are the details?
Those used to the detail added in advance into traditional requirements will immediately come up with this question. The detail can be added to User Stories in two ways:
- Dividing a User Story into multiple User Stories and smaller ones.
- Adding “conditions of satisfaction”.
When a relatively large story is divided into Agile and multiple User Stories, it’s normal to assume that details have been added. After all, more has been written.
Conditions of Satisfaction are simply high-level acceptance tests that must be met after the User Story is completed. Consider the following as another example of an Agile User Story:
As a marketing director, I want to select a period of time so that I can review the past performance of advertising campaigns in that period.
The detail could be added to this User Story example by adding the following satisfaction conditions:
- Make sure it works with the data of the main retailers: Oxxo, Seven Eleven, Extra.
- It must support the data for the last three years.
- The periods are chosen in intervals of months (not days, nor weeks).
Who writes User Stories?
Anyone can write User Stories. However, it is the responsibility of the product owner to ensure that there is an accumulated backlog of Agile User Story products, but that does not necessarily mean that the owner of the product is the one who writes them. In the course of a good Agile project, you must have examples of User Story written by each member of the team.
Also, keep in mind that who writes a User Story is much less important than who is involved in the discussions of it.
When are User Stories written?
The User Stories are written throughout an Agile project. Overall, a story writing workshop is held near the start of the Agile project, each release and/or at the beginning of each iteration (I personally take some of the first options, depending on the length of the project, and I only do refinement in each iteration). Everyone on the team participates with the goal of creating an “order list” or Product Backlog that fully describes the functionality that will be added during the course of the project, or in a release cycle of three to six months.
Some of these Agile User Stories will undoubtedly be Epics (are not called Epics because they are dramatic…well sometimes 😄). Epics are very large stories that by their size will later decompose into smaller stories that fit more easily into a single iteration. In addition, new stories can be written and added to the “order list” of the product at any time and by anyone.
Velocity
I will not delve too much into this topic because it gives to write another post dedicated entirely to it, but to understand how estimation can work with Story Points that we assign in the table we showed above, it’s necessary to introduce a new concept: Velocity. Velocity is a measure of a team’s progress rate. It’s calculated by adding the number of Story Points assigned to each User Story that the team completed during the iteration.
If the team completes three stories, each estimated at five story points, its velocity is fifteen. If the team completes two stories of five points, its velocity is ten.
If a team completed ten points of work the last iteration, our best calculation is that this iteration will complete ten points. Because the story points are estimates of relative size, this will be true whether they work on two five-point stories or five two-point stories.
As can you see, in order to make estimations, and after knowing the sizes It’s very important to calculate an estimate for the end of the project, or for a release (the distance).
Do User Stories replace a requirements document?
Agile projects, especially Scrum projects, use a product backlog, which is a prioritized list of functionalities that will be developed in a product or service. Although product backlog items may be what the team wants, User Stories have emerged as the best and most popular form of product backlog items.
While a product backlog can be considered as a replacement for the requirements document of a traditional project and perhaps even a WBS, it’s important to remember that the written part of an Agile User Story (“As a user, I want …” ) is incomplete until the discussions about that story take place.
It’s often better to think of the written part as an indicator of the actual requirement. User Stories can point to a diagram that represents a workflow, a spreadsheet that shows how to perform a calculation or any other artifact that the Product Owner or team wants.
Until here I leave the User Stories topic, for now, let me know if you want to know more 😉.
Links of interest:
Without users (User Proxies)
The Agile Team Approach
What Scrum Master Certification to Choose?These are some recommended books to learn more:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Probablemente usted o su organización ya tienen muy claro la Meta y los Objetivos que desea para su proyecto, si es así déjeme felicitarlo porque no siempre es fácil, si por el contrario aún no ha dedicado tiempo a esa tarea o sigue luchando para definir sus metas y objetivos quizá quiere echar un vistazo a nuestro video anterior Definiendo Metas y Objetivos.
Ahora bien, suponiendo que sus metas y objetivos están establecidos, es probable que usted tenga algunas ideas para poder cumplirlos, aquí es donde la participación de los miembros del equipo con el cual usted trabaja se vuelve importante, ya que las perspectivas de diferentes integrantes llega a la creación, fusión o discriminacón de ideas. Todas esta interacción que puede ser impulsado por prácticas de design thinking provoca una lluvia de ideas que se convertirán eventualmente en estrategias de ejecución.
Cuando obtenga muchas ideas y/o estrategias el siguiente paso consistirá en evaluar cuales respaldan de mejor manera a sus objetivos, en el video de este post, llamado Eligiendo Una Estrategia, puede obtner una referancia rápida de como evaluar el grado de cumplimiento de sus ideas y estrategias a los objetivos que persigue:
- Lluvia de ideas
- Matriz de evaluación
- ¿La estrategia satisface los objetivos?
- ¿La estrategia es factible?
- ¿Los riesgos de la estrategia son aceptables?
- ¿La estrategia es compatible con la cultura de la organización?
Recuerde que este video es parte del segundo capítulos del curso en videos de Introducción a la Administración de Proyectos, si desea puede ver los videos anteriores para comprender mejor el tema tratado.
Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden.
También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Video Eligiendo Una Estrategia:
Eligiendo Una EstrategiaAlgunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Puede pensar que la principal responsabilidad de alguien a cargo de un proyecto es entregarlo a tiempo y dentro del presupuesto, de hecho, es una manera muy común de pensar de organizacione, pero estan equivocados. Como parte de un cuerpo estratégico de alto nivel o como un independiente, los responsables de la administración de proyectos, en primer lugar, ayudan a impulsar, guiar y ejecutar acciones para lograr los objetivos de valor agregado identificados de cualquier organización.
Cuando las organizaciones maduran eventualmente crean cosas como las oficinas de gestión de proyectos (PMO) y las buenas prácticas de gestión de proyectos tienen más probabilidades de ser bien recibidas por los ejecutivos y partes interesadas de la organización como elementos tácticos indispensables una vez que reconocen su verdadero valor estratégico.
Muchas organizaciones hoy ya saben que contratado y capacitado a los pensadores estratégicos, aumenta la probabilidad de ejecutar proyectos de alto impacto. Este alto impacto, entre otras cosas, se logra identificando metas y objetivos de largo, mediano y corto plazo con el que los posteriores esfuerzos se deben alinear. Cada involucrado en un proyecto debe poder tener una comprensión clara de la línea directa desde las tareas de un proyecto hasta la visión estratégica de alto nivel.
En el video de este post, llamado Definiendo Metas Y Objetivos, puede aprender las bases para poder crear metas y objetivos apropiados para sus proyectos. En este video se hablamos de :
- Definición de una meta
- Definición de objetivo
- Tipos de objetivos
- Elementos a tomar en cuenta para crear y redactar objetivos
Recuerde que este video es parte del segundo capítulos del curso en videos de Introducción a la Administración de Proyectos, si desea puede ver los videos anteriores para comprender mejor el tema tratado.
Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden.
También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Video Definiendo Metas Y Objetivos:
Definiendo Metas Y ObjetivosAlgunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured¿El tamaño importa?
Esta es una pregunta muy vieja, pero en este blog solo contestaremos a esa interrogante desde el punto de vista de la administración de proyectos (descepcionad@s dirigirse a blogs de otro tipo). En esta ocasión veremos que son y cuál es el propósito de las famosas historias de usario o user stories y en que se diferencían con los requerimientos tradicionales en un proyecto.
Cuando era niño pasé mucho tiempo jugando en la playa con mis primas y primos, y en algunos de esos juegos, me encontré escarbando, transportando y apilando arena de un punto a otro (mis herramientas eran una pala y una cubeta de plástico) después de unos 10 minutos mi primo más pequeño me preguntó cuanto me había tardado en juntar toda esa arena, a lo cual contesté: “como unas 30 vueltas”. Después de eso tanto mi primo y como yo supusimos que con su propia cubeta podría duplicar la cantidad de arena en otras 30 vueltas. No fue así, mi primo pequeño todavía, se tardó bastante más debido a ambos fallamos en evaluar la capacidad de su cubeta y en apreciar que Gabriel (mi primo) al ser muy pequeñito (quizá 6 años) aún tenía que esforzarse para cargar una cubeta de diferente tamaño completamente llena y terminar en sólo 30 vueltas.
Por simple y obvia que parezca esta anécdota, la realidad sorprende, ya que muchos equipos de trabajo encargados de proyectos de todos tamaños siguen cayendo en este mismo error. Aún no están completamente al tanto de su capacidad o su velocidad, tampoco tienen claro la diferencia entre tamaño y distancia en un proyecto, y por lo tanto, fallan desde el principio en sus estimaciones.
No ocuparse de tratar de medir el tamaño de lo que se va a hacer es un error, por lo tanto el tamaño, SÍ importa, y antes de medir tiempos y distancias usted debe saber la respuesta a preguntas como ¿cuál es el tamaño de su cubeta y su pala? ¿cuántas cubetas y palas tiene? ¿existe la cantidad de personas suficiente para cada pala y cubeta?
¿Que son las historias de usuario?
Por facilidad muchas veces se sobre simplifica, diciendo que las historias de usuario o user stories son los requerimientos de un sistema o un producto, pero tienen serias diferencias con otras aproximaciones comunes como son los casos de uso, especificaciones de requisitos de software IEEE 830 y escenarios de diseño e interacción.
Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva funcionalidad, generalmente un usuario o cliente del producto que se desea crear. Por lo general, siguen una plantilla simple:
Como <tipo de usuario>, quiero <algún objetivo> para que <algún motivo>.
Las historias de usuario a menudo se escriben en fichas o notas adhesivas, se almacenan en una caja y se organizan en paredes, pizarrones o mesas para facilitar la planificación y el debate. Como tales, cambian fuertemente el enfoque de escribir sobre las características, a discutirlas. De hecho, estas discusiones son más importantes que cualquier texto que se escriba.
Esta es una definición simple de que es una historia de usuario, pero créame, hay mucho más detrás, redactar buenas historias de usuario puede ser un reto, y para lograr hacer buenas historias hay que entender más acerca de su propósito.
Asigna Valor (puntos) a las historias de usuario
Eventualmente, cuando me involucré en la gestión de proyectos y más tarde Agile, descubrí que una manera de estimar el tamaño de lo que se necesita es utilizar las historias de usuario. Para explicar lo que son seguiré echando mano de las analogías.
¿Cuándo fue la última vez que fue a un restaurante y pidió una sopa o una bebida en mililitros?…..así es, normalmente no hacemos eso, solemos pedir una sopa o una bebida con una medida relativa como “chica, mediana o grande”. Las historias de usuario son relativas también, se usan para expresar tamaño, no cuentan con un valor estandarizado, pero los valores deben ser relativos uno de otro, es decir, una historia de usuario que tenga valor 2 es del doble de tamaña de una que vale 1.
Para asignar valores o puntos a diferentes tamaños hay quienes usan tallas de camisa, razas de perros, valores Fibonacci (mis valores favoritos) u otras representaciones, no importa que prefiera, eventualmente debe usar valores relativos. Tome como ejemplo la siguiente tabla, con una posible asignación de puntos:
Tamaño Camisa Puntos XS 1 S 2 M 3 L 5 XL 8 XLL 12 En un proyecto Agile no es raro comenzar una iteración con requisitos que NO son completamente especificados, los detalles se descubrirán más tarde durante la iteración. Sin embargo, debemos asociar un estimado con cada historia que podamos visualizar en el momento, incluso a aquellas que no están completamente definidas.
¿Y en dónde están los detalles?
Aquellos acostumbrado a el detalle que se agrega de antemano a los requerimientos tradicionales, de inmediato les surgirá esta pregunta. El detalle se puede agregar a las historias de usuario de dos maneras:
- Dividiendo una historia de usuario en múltiples historias de usuarios y más pequeñas.
- Agregando “condiciones de satisfacción”.
Cuando una historia relativamente grande se divide en historias de usuarios ágiles y múltiples, es natural suponer que se han agregado detalles. Después de todo, se ha escrito más.
Las condiciones de satisfacción son simplemente pruebas de aceptación de alto nivel que deberán cumplirse después de que se complete la historia del usuario. Considere lo siguiente como otro ejemplo de historia de usuario ágil:
Como director de marketing, quiero seleccionar un periodo de tiempo para que yo pueda revisar el rendimiento pasado de campañas publicitarias en ese periodo.
El detalle podría agregarse a este ejemplo de historia de usuario al agregar las siguientes condiciones de satisfacción:
- Asegúrese de que funcione con los datos de los principales minoristas: Oxxo, Seven Eleven, Extra.
- Debe soportar los datos de los últimos tres años.
- Los periodos se eligen en intervalos de meses (no días, ni semanas).
¿Quién escribe historias de usuarios?
Cualquiera puede escribir historias de usuario. Sin embargo, es responsabilidad del propietario del producto o product owner asegurarse de que exista un retraso acumulado de productos de historias de usuario ágiles, pero eso no significa necesariamente que el propietario del producto es quien los escribe. En el transcurso de un buen proyecto Agile, debe contar con ejemplos de historia de usuario escritos por cada miembro del equipo.
Además, tenga en cuenta que quién escribe una historia de usuario es mucho menos importante que quién está involucrado en las discusiones de la misma.
¿Cuándo se escriben las historias de los usuarios?
Las historias de usuario se escriben a lo largo de un proyecto ágil. Por lo general, se lleva a cabo un taller de redacción de historias cerca del inicio del proyecto ágil, de cada relese y/o al inicio de cada iteración (personalmente tomo algunas de las primeras opciones, según la longitud del proyecto, y solo hago grooming en cada iteración). Todos en el equipo participan con el objetivo de crear una “lista de pedidos” o Product Backlog que describa por completo la funcionalidad que se agregará durante el transcurso del proyecto o en un ciclo de lanzamiento o release de tres a seis meses.
Algunas de estas historias de usuarios ágiles serán, sin duda, épicas o epics (no se llaman épicas por que se dramáticas 😄). Las épicas son historias muy grandes que por su tamaño se descompondrán más tarde en historias más pequeñas que quepan más fácilmente en una sola iteración. Además, las historias nuevas se pueden escribir y agregar a la “lista de pedidos” del producto en cualquier momento y por cualquier persona.
Velocidad (Velocity)
No profundizaré tanto en este tema porque da para escribir otra entrada dedicada por completo a ello, pero para comprender cómo puede funcionar la estimación con puntos de historia que asignamos en la tabla que mostramos anteriormente, es necesario introducir un nuevo concepto: Velocidad o Velocity. La velocidad es una medida de la tasa de progreso de un equipo. Se calcula sumando la cantidad de puntos de historia asignados a cada historia de usuario que el equipo completó durante la iteración.
Si el equipo completa tres historias, cada una estimada en cinco puntos de historia, su velocidad es de quince. Si el equipo completa dos historias de cinco puntos, su velocidad es diez.
Si un equipo completó diez puntos de trabajo la última iteración, nuestro mejor cálculo es que completarán diez puntos esta iteración. Debido a que los puntos de la historia son estimaciones del tamaño relativo, esto será cierto ya sea que trabajen en dos historias de cinco puntos o cinco historias de dos puntos.
Cómo puede ver esto es muy importante para hacer una estimacion y despúes de conocer el tamaño, para después proceder a calcular una estimación para el final del proyecto o de un release (la distancia).
¿Las historias de usuario reemplazan un documento de requisitos?
Los proyectos ágiles, especialmente los de Scrum, usan un product backlog, que es una lista priorizada de las funcionalidades que se desarrollarán en un producto o servicio. Aunque los product backlog items pueden ser lo que el equipo desee, las historias de usuario han surgido como la mejor y más popular forma de product backlog items.
Si bien un product backlog, puede considerarse como un reemplazo de el documento de requisitos de un proyecto tradicional e incluso quizá de un WBS, es importante recordar que la parte escrita de una historia de usuario ágil (“Como usuario, quiero …”) está incompleta hasta que las discusiones sobre esa historia tienen lugar.
A menudo es mejor pensar en la parte escrita como un indicador del requisito real. Las historias de usuario pueden apuntar a un diagrama que representa un flujo de trabajo, una hoja de cálculo que muestra cómo realizar un cálculo o cualquier otro artefacto que el propietario del producto o equipo deseen.
Hasta aquí dejo las user stories, déjeme saber si quiere saber más 😉.
Enlaces de interés:
El Enfoque Agile De La Planeacion
Planeación, Cono de Incertidumbre y Estimaciones en IT
Introduction to User StoriesEstos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
¿Cuántos proyectos que se alejan de su objetivo? ¿cuántos malos entendidos sobre lo debe hacer su sistema ha tenido? ¿cómo comenzar a priorizar sus tareas? Saber definir el problema que estamos resolviendo con suficiente claridad desde el principio puede ser un factor muy importante.
Continuando con el curso en videos de Introducción a la Administración de Proyectos, Internet80.com y @ManuGekko han comenzado con el segundo capítulo de este curso, el cual estará dedicado el grupo de procesos de Inicio en un proyecto. Es aquí donde comenzaremos a aprender cómo establecer la visión inicial de proyecto y a obtener buy-in de los involucrados en el mismo.
Este segundo capítulo comienza con un video de introducción en dónde hablamos del Inicio de un Proyecto como proceso esto abarca de manera introductoria los conceptos de:
- Grupo de procesos de inicio
- Acta de constitución del proyecto
Enseguida tenemos el siguiente video donde se aborda el tema de la definición del Enunciado de Problema, por qué es importante y como crearlo, para ellos se cubren los temas:
- Concepto de enunciado de problema
- Diferencia con una solución
- La importancia de preguntar por qué
Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Video Iniciando un Proyecto:
Iniciando Un ProyectoEnunciado De Problema:
Enunciado De ProblemaAlgunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Finalmente este es el último video del primer capítulo Explorando La Administracion De Proyectos que forma parte del curso gratuito en video de Introducción a la Administración de Proyectos, así que ahora tocó el turno de hablar de algunas de las opciones que están diponibles en el mercado de software que le pueden ayudar en su labor como responsable de un proyecto.
Siguiendo la tradición del curso, los videos abordan el tema de manera breve, pero buscando siempre ponerlo a usted en la pista correcta para averigüe más y llegue a sus propias conclusiones. En este video se aborda las características esenciales de:
- Software especializado en gestión de proyectos
- Procesadores documentos
- Hojas de cálculo
- Software para presentaciones
- Consideraciones generales
Todos los videos previos están disponibles en YouTube o si prefiere, en los siguientes enlaces:
- Definición de Proyecto
- Definición de Gestión de Proyectos
- Lo Necesario Para Ser Un Administrador de Proyectos
- Los Cinco Procesos De La Administración de Proyectos
- Cascada VS Agile
Estos videos forman parte del primer capítulo del curso Explorando La Administracion De Proyectos. La estructura del curso puede verla aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Con usted el último video de este capítulo Opciones Software Para La Administración de Proyectos:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Cursos / CoursesEste es un video que no pensé incluir cuando estaba diseñando el curso gratuito en video de Introducción a la Administración de Proyectos, pero recordé que hay muchas personas que aun siguen discutiendo y enfrentado los modelos ágiles y los modelos tradicionales de gestión de proyectos, cual si fueran personajes de Street Fighter. Me imagino las pantallas arcade de mi infancia mostrando Cascada Vs Agile, RUP VS Scrum, PSP VS XP, cuando en realidad se trata comprender el contexto de su proyecto para aplicar el enfoque más adecuado.
Finalmente he creado para usted el quinto video de este curso en donde se explica en que situaciones en las cuales debería de aplicar estas aproximaciones de administración de proyectos y cual es su relación con los cinco grupos de procesos del Project Manament Institute o PMI independientemente de pasiones mal ubicadas por marcos de trabajo o técnicas específcas. En este video encontrará:
- Modelo de Cascada, Tradicional o Waterfall
- Modelo Ágil o Agile
- Su relación con los grupos de procesos
Todos los videos previos están disponibles en YouTube o si prefiere, en los siguientes enlaces:
- Definición de Proyecto
- Definición de Gestión de Proyectos
- Lo Necesario Para Ser Un Administrador de Proyectos
- Los Cinco Procesos De La Administración de Proyectos
Estos videos forman parte del primer capítulo del curso Explorando La Administracion De Proyectos. La estructura del curso puede verla aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Sin más el quinto video Cascada VS Agile del curso de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Revelación
Hacer la estimación y la planeación del desarrollo de un producto puede ser una tarea desalentadora que se hace más complicada por nuestra ignorancia o mala interpretación acerca de los proyectos, como concepto y en proyectos específicos. Hace tiempo leí (enlaces al final) que un proyecto no debía ser visto sólo como una secuencia de pasos, sino que también debía ser visto como un flujo rápido que genera nuevas capacidades y nuevo conocimiento. Las nuevas capacidades se entregan como parte del nuevo producto y el nuevo conocimiento se utiliza para hacer un mejor producto (Cohn 2006). Esto es la base para el enfoque de la Planificación Agile sobre la planeación.
Al comenzar a leer sobre administración de proyectos, trabajaba como desarrollador, y esa frase (del párrafo anterior) fué una de mis primeras revelaciones serias acerca de porque trabajaba tan duro codificando para funcionalidades que al final no se utilizaban o bien en proyectos que no lograban sus objetivos plenamente. Parte de las fallas de esos proyectos fueron desde luego, a veces no planear en lo absoluto, pero también tratar de planear todo desde el principio.
Plan En un proyecto Agile utilizamos las nuevas capacidades y el nuevo conocimiento obtenido como guía para el trabajo mismo que se está realizando. El conocimiento obtenido puede ser acerca del producto o del mismo proyecto en general, lo importante es que este nuevo conocimiento nos da mejor idea de cómo debería ser el producto en el cual trabajamos o bien se convierte en mejor entendimiento sobre una tecnología, sobre el equipo, sobre los riesgos, etc.
Cuando pretendemos planear todo desde el principio (ni hablar cuando no planeamos) estamos fallando en integrar nuevo conocimiento al plan, y por lo tanto eso nos lleva a caer en suposiciones erróneas, como creer que estamos incluyendo TODO lo necesario en nuestro plan (lo que en el mundo del software rara vez sucede).
Mis amigos desarrolladores son mayormente gordos y feos (pero aún así los quiero 😃) y no les gusta correr (ejercitarse, hacer cardio, etc.) , pero a mí sí, por lo que utilizaré la siguiente analogía: Una aproximación tradicional a un proyecto puede ser como una carrera de 10km donde usted sabe exactamente dónde está la meta y trata de alcanzarla tan rápido como sea posible. Un proyecto Agile es como cuando usted se toma el tiempo y ve que tan lejos puede llegar en 60 minutos. Un equipo Agile sabe cuándo termina, pero no exactamente que entregará al final. Por lo tanto, planear se convierte en proceso en donde crean y revisan objetivos periódicamente que eventualmente llevan a una meta de más largo término.
Niveles de planificación Agile
Cuando estamos preparando los objetivos de un plan es importante reconocer que no podemos ver más allá de cierto horizonte y que la exactitud de nuestro horizonte será cada vez menor entre más lejos queramos ver. En mis cursos menciono los primeros capítulos de una serie de TV llamada Vikings en donde plantean someramente el uso regular de un compás solar, un piedra solar y cuervos para poder corregir el rumbo periódicamente y mantener un curso correcto; de esta misma manera nosotros debemos revisar el estado de nuestro proyecto y ajustar nuestro plan de acuerdo a ello. Desde este punto ya estamos hablando de la elaboración de una planeación estratégica con el enfoque Agile.
Como ya expresé, el riesgo de un plan se incrementa de acuerdo a que tan lejos en el futuro queramos planear, por ello cada cierto tiempo debemos levantar nuestra vista para ver el nuevo horizonte y ajustar el plan. Los equipos Agile hacen esto planeando en por lo menos 3 distintos horizontes (podrían ser más dependiendo de la aproximación de su organización, pero en esta entrada solo explicare estos). Los 3 horizontes son el Release (Liberación), Iteración y Diaria (actual). Puede tomar como referencia el siguiente diagrama (este no es un estándar, puede encontrar diferentes diagramas similares, pero los 3 horizontes principales no cambian):
Niveles de la Planificación Agile Planificación del Release (Liberación).
Aquí determinamos respuestas a preguntas que se relacionan con el alcance, el calendario y los recursos del proyecto. Este plan debe ser actualizado a lo largo del proyecto, usualmente al inicio de cada iteración para reflejar las expectativas actuales que serán incluidas en el Release.
Planificación de la Iteración.
Esta se lleva a cabo al inicio de cada iteración y basada en el trabajo que se hizo en la iteración anterior (si no es la primera desde luego). El cliente o sus representantes (el Product Owner) deben identificar los elementos de mayor prioridad en los cuales el equipo concentrará sus esfuerzos en la nueva iteración. Esto porque estamos en un horizonte más cercano que el del Release. En este horizonte se establecen las tareas requeridas para obtener una parte funcional y probada de nuestro producto.
Planificación Diaria.
Puede sonar muy excesivo (y quizá lo es) llamar planificación a este horizonte, esto no son más que reuniones diarias e informales (que usualmente se hacen de pie ya que solo deben durar unos minutos) en donde se sincronizan los esfuerzos diarios individualmente. Esto es, que cada miembro del equipo comparte que ha hecho el día anterior, que piensa hacer hoy y comunica los obstáculos que afronta.
Con estos tres horizontes (Release, Iteración y Diaria) los equipos ágiles se concentran sólo en lo que es visible e importante en el plan que han creado. De esta manera han adoptado el enfoque de la planificación Agile.
Condiciones de Satisfacción.
En una futura entrada dedicaré más detalle a esto (lo merece) pero no quiero dejar de mencionar el tema en esta misma entrada, por lo menos de manera breve. Todo proyecto debe comenzar con una meta, quizá de esta se deriven varios objetivos relacionados con fechas, presupuesto, recursos humanos, etc., pero típicamente solo habrá una meta. No dé por hecho que usted debe crear el mejor auto del mundo, la mejor puerta del mundo, el mejor ERP del mundo; los objetivos sólo deben alinearse con las condiciones de satisfacción del Producto Owner (la voz del cliente); esto es, los criterios que serán utilizados para evaluar y determinar el éxito del proyecto.
Lo pondré de otra forma, hace mucho tiempo, cuando estaba en la secundaria era común que a la clase entera nos asignaran escribir un artículo sobre un libro, y de inmediato aparecía la pregunta obligada al profesor, la cual era qué tan largo debía ser artículo. El respondía algo así como “cinco páginas”, entonces conociamos su primera Condición de Satisfacción. Hubo, por supuesto, una serie de condiciones adicionales de satisfacción no escritas, como que el documento estubiera bien escrito, que fuera mi propio trabajo (no plagios), sin faltas de ortografía, etc.
Al comienzo de la planificación Agile del Release o lanzamiento, el equipo y el propietario del producto exploran en colaboración las condiciones de satisfacción del propietario del producto. Estos incluyen los elementos habituales (alcance, calendario, presupuesto y calidad), aunque los equipos ágiles suelen prefieren tratar la calidad como no negociable. El equipo y el propietario del producto buscan formas de cumplir con todas las condiciones de satisfacción. El propietario del producto puede, por ejemplo, estar igualmente satisfecho con un Release en cinco meses que incluya un conjunto de historias de usuarios, que con un sólo lanzamiento de un mes que incluya historias de usuarios adicionales.
A veces, sin embargo, no se pueden cumplir todas las condiciones de satisfacción del propietario del producto. El equipo puede construir el mejor procesador de textos del mundo, pero no pueden construirlo para el próximo mes. Cuando no se puede encontrar una solución factible, las condiciones de satisfacción deben cambiar. Debido a esto, la planificación del lanzamiento y la exploración de las condiciones de satisfacción del propietario del producto son altamente iterativas
Conclusión
Los proyectos deben considerarse como una generación rápida y confiable de un flujo de nuevas capacidades útiles y nuevos conocimientos, en lugar de solo la ejecución de una serie de pasos. Los proyectos generan dos tipos de conocimiento nuevo: conocimiento sobre el producto o servicio y conocimiento sobre el proyecto. Este conocimiento debe ser validado para evitar trabajo infructuoso (waste).
La siguiente imagen muestra como la planifiación Agile existe dentro de una dinámica que busca adaptar conocimiento de manera pronta y altamente iterativa (como ya se mencionó). Hemos basado esta ilustración en la propuesta del buen @sdelbecque quien toma en cuenta la filosofía de Lean, con la cual la agilidad es altamente compatible:
Lean Agile Enlaces relacionados:
El Origen Y Los Valores De Agile
Planeación, Cono de Incertidumbre y Estimaciones en IT
Estos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
El propósito de Planear
Constantemente les digo a mis amigos y compañeros de trabajo que las ideas no son lo mismo que la planeación. Recuerde la última vez que comenzó algo que, por diversas razones, nunca terminó, o aquella ocasión que dijo mis “planes” son…, pero en la realidad nunca realizó verdaderas acciones para concretar esos “planes” o bien simplemente sigue posponiéndolos. La principal diferencia entre ideas y planes radica básicamente en que las ideas son algo vago, aspiracional y deseable; mientras que la verdadera planificación lleva más allá las ideas y establece objetivos junto con pasos previstos a seguir que finalmente ayudan a elaborar estimaciones, tomar decisiones e incluso perfeccionar o cambiar el plan.
De la misma forma que sucede en la vida, en la industria del software y de las IT en general, las estimaciones y las planificaciones son de suma importancia para lograr el éxito de cualquier proyecto. Los planes son una guía que nos indica en donde invertir nuestro tiempo, dinero y esfuerzo. Si estimamos que un proyecto nos tomará un mes en realizar y a cambio nos generará un millón de dólares, entonces quizá decidamos realizar ese proyecto. Sin embargo si el mismo proyecto nos genera ese millón de dólares en 15 años, entonces quizá sea mejor rechazarlo. Los planes nos ayudan a pensar por adelantado y a saber si estamos progresando como esperamos entre otras cosas. Sin planes estamos expuestos a cualquier cantidad de problemas.
En mi experiencia como desarrollador y project manager los equipos tienden a dos extremos: No hacen ningún plan en lo absoluto o se esfuerzan tanto en un plan que se convences a si mismos de que ese plan es correcto siempre. Los que no planean simplemente no pueden contestar a la preguntas más elementales, como ¿y cuando terminan? o ¿estará listo antes del fin de año?. Los que planean demasiado invierten tanto tiempo en su plan que caen en supuestos que no pueden confirmar, su inseguridad crece más y comienzan a creer que incluso planeando más lograrán estimaciones más precisas aunque esto en realidad no ocurra. Si usted se siente identificado con alguno de los escenario anteriores, a su favor puedo decir que planear no es fácil.
Pero que los planes fallan y que planear es complicado no es noticia. Al inicio de un proyecto muchas cosas pueden ser desconocidas, como por ejemplo los detalles específicos de los requerimientos, la naturaleza de la tecnología, detalles de la solución, el plan mismo del proyecto, miembros del equipo, contexto del negocio entre muchas otras cosas. Pero entonces ¿cómo lidiamos con estas adivinanzas? ¿cómo lidiamos con la incertidumbre?.
El Cono
Estas preguntas representan un problema que ya es bastante viejo. En 1981, Barry Boehm dibujó lo que más tarde en 1998 Steve McConnell llamó el Cono de Incertidumbre. El cono muestra que en un proyecto secuencial o en “cascada” que está en etapa de factibilidad normalmente daremos una estimación que está lejos de la realidad, en un rango de entre un 25% y un 400%. Esto es por ejemplo, que un proyecto de 40 semanas tomará entre 10 y 160 semanas. Para cuando se termine de obtener requerimientos nuestra estimación aun estará desfasada entre un -33% y un 50% . Para este punto nuestro proyecto de 40 semanas tomará entre 27 y 60 semanas. Imagine que pasa con esos proyectos que nunca tienen claros sus requerimientos.
¿Cómo lidiar con el Cono?
Buffering (margen de error)
Esto es utilizar un un porcentaje de tiempo y/o recursos para amortiguar el efecto de riesgos que se materializan. Hay que tener cuidado, una reacción común es meter el doble o el triple de tiempo a la estimación de un proyecto, esto NO es buffering, esto es hacer padding (acolchonar) lo cual NO ES una buena práctica. Dar un número demasiado grande, hará que los patrocinadores o clientes se resistan y no aprueban su proyecto. Deles un número demasiado bajo y usted correrá el riesgo de quedarse sin tiempo y dinero. Esto se vuelve doblemente arriesgado cuando usted está utilizando contratos fijos para su propuesta, donde hay aún más presión para mantener los costos bajos.
Es importante que haga uso de datos históricos para comparar su proyecto actual con otros proyecto concluidos y obtenga números razonables y justificables para margen de error o buffering. Incluya procesos de postmortem o lecciones aprendidas al terminar cada proyecto, para así sustentar sus cifras de buffering en le futuro.
Enlarge
Thanks to agilenutshell.com
Estimar en rangos
Algo que me gusta de los enfoques ágiles para gestión de proyectos es ser honesto desde el principio y nunca utilizar cifras cerradas, sino ser transparentes y siempre usar rangos, sobre todo en proyectos que buscan innovar e intentar cosas nuevas donde existe mucha incertidumbre. Esto es por ejemplo:
Mira. No sabemos cuánto tiempo se va llevar esto, sin embargo la siguiente es nuestra mejor apuesta basados en la información que tenemos hasta ahora. Pero si podemos llevar a cabo un par de iteraciones, podemos desarrollar algo, evaluar cuanto nos lleva y entonces tener una mucho mejor ideas de que tan grande es esto.
Además presente la mejor estimación al momento como un rango. Esto puede ayudar a los patrocinadores del proyecto a decidir cual es el monto de riesgo que están dispuestos a aceptar.
Estimación relativa
Han existido diversas investigaciones acerca de como hacer estimaciones de esfuerzo y se ha descubierto que las personas somos buenas estimando el tamaño de algo comparándolo con un referente (Software Development_Effort Estimation) . Por ejemplo, Alguien no puede decirle cuantos metros de alto mide el edificio en el que vive, pero sí puede decirle que es aproximadamente el doble de aquel otro. Usted puede aplicar este principio a los proyectos también
Nota. Las aproximaciones ágiles utilizan interesante conceptos como Story Points e Ideal Days para hacer estimaciones relativas.
Recursos incrementales
Esta práctica se debería aplicar más a menudo o por lo menos más inteligentemente, esto es asignar recursos de manera periódica de tal manera que no se tenga que pedir una gran bolsa de dinero al inicio del proyecto.
No es raro encontrar proyectos donde los patrocinadores proporcionan pagos por fases, sin embargo, aveces se cae en crear fases demasiado grandes o que no son periódicas. El objetivo es financiar regularmente en periodos cortos de tiempo que llamamos iteraciones y con ello hacer revisión del progreso. Al final de cada iteración ese el momento donde tenemos la oportunidad para revaluar si vamos por el camino correcto y reportar números más precisos para la actualización de estimaciones con base en el conocimiento adquirido durante el tiempo transcurrido.
Esto no es una medida infalible, aún puede estimar mal. Pero sin duda es bueno obtener un financiamiento inicial que permite construir algo al equipo y ver cuánto tiempo tarda completando este avance, mientras que simultánemente aprende más acerca de lo que hay que lograr, de tal manera que se aprovecha esta experiencia para reducir la varianza de ese número inicial estimado.
¿Por qué sucede todo esto?
Es indudable que siempre hay presión del sector financiero de las organizaciones para hacer estimaciones para todo un proyecto o para todo un año, aunque estas prácticas al final salgan contraproducentes 😀
Lo mejor que puede hacer es permear este conocimiento en su organización, y recordar y comunicar constantemente que el objetivo de estimar no es adivinar el futuro, sino determinar si los objetivos del proyecto son realistas o incluso posibles.
Algunos enlaces de interés:
El Enfoque Agile De La Planeacion
Parte de la lista de temas para este post y la idea del gráfico con el solecito 🙂 fueron parcialmente basadas en artículos de agilenutshell.com
Estos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
