Está en la página 1de 6

Estudiante: Diego Barrientos J.

Estimacin y Planificacin gil

Una parte muy importante a la hora de desarrollar software es la estimacin y la planificacin, y aunque no se quiera siempre se hace, ya sea porque la empresa necesita de fechas para poder hacer anuncios del nuevo producto o para hacer un contrato. Pero lo cierto que es muy necesaria porque nos da un camino a seguir y tambin nos muestra qu tan bien est el proceso de desarrollo, si vamos a lograr cumplir con la fecha y el presupuesto. Estimar y planificar no es nada fcil pero se sabe que, con el paso del tiempo, la estimacin y planificacin se hacen ms certeras, esto quiere decir que conforme se va conociendo el proyecto se sabe ms de l y en consecuencia se logra una aproximacin ms cercana con la realidad. Una buena estimacin y planeacin es tal si reduce los riesgos, si da a conocer cmo es que se lleg a ella y no proporciona cifras exactas, si ofrece confianza y si es capaz de someterse a cambios. A la hora de planificar y estimar, hay muchas cosas que hay que tomar en cuenta: a veces es mejor centrarse en el personal que en las caractersticas que debera tener el proyecto, puede que una persona muy importante sea necesaria o crucial en el desarrollo, pero sta est ocupada con otro proyecto dentro de la empresa, entonces es mejor prescindir de ella, quitar esa caracterstica pero asegurar la entrega del producto en el tiempo acordado, logrando as tambin confianza con los clientes. O por ejemplo, podramos contratar a slo una persona para que desarrollo todo el proyecto, pero esto demorara demasiado, en cambio es mejor contratar un equipo, costara ms pero el trabajo sera hecho en menos tiempo (aunque no siempre es cierto eso de que ms desarrolladores es igual a menos tiempo, hay ocasiones en las que, digamos en una fase avanzada del trabajo, si contratamos ms programadores, el resultado ms bien sera contraproducente, porque a los

nuevos habra que introducirlos a lo que es el proyecto, lo que llevara tiempo). Planificacin gil se refiere a un tipo de planificacin con caractersticas de los mtodos giles: es fcil de cambiar; no todo sale como se planea, siempre pasa algo que nos hace cambiar de planes, por ese motivo la planificacin se modifica y se hace durante todo el proyecto y no solo al principio. Y esto da buenos resultados porque no es necesario modificar las fechas, se podran cambiar otras cosas, como decidir si una caracterstica del producto entra o no en el lanzamiento, hay estudios que dicen que hay un gran porcentaje de caractersticas que no son usadas, o sea que no afectara en nada pero se cumplira con los clientes. Con respecto a las cosas que hacen que las estimaciones y planificaciones tradicionales no cumplan hay varios factores: que las estimaciones estn basadas en las actividades y no en las caractersticas, que no haya prioridad en cuanto a las caractersticas, que se hagan mltiples tareas y que se hagan compromisos sobre estimaciones. Est en la naturaleza humana acabar el trabajo en el tiempo planificado, habindolo terminado an antes para evitar reclamos por haberlo hecho antes o por temor a ser presionado y tener que cumplir rpidamente tambin con los prximos trabajos, lo que hace que siempre exista un retraso el cual no se puede compensar porque nunca van a haber trabajos terminados antes. Hay tambin una realidad desafortunada que hace al proyecto retrasarse, las muchas actividades que hay tienen dependencias con otras y, por lo tanto, no pueden siquiera comenzar hasta que otra finalice. Otro punto en contra es que a veces se quiere trabajar con mltiples miniproyectos a la vez, en principio es bueno esto (cuando se trabajan solo con dos, puesto que cuando haya un bloqueo en uno se trabaje en el otro y viceversa) pero con muchos al mismo tiempo, lo que se va lograr es retrasar mucho el proyecto de la estimacin original, ya que es muy raro que hayan bloqueos en ms de un miniproyecto y adems el estar cambiando entre ellos consume tiempo. Finalmente, aunque son necesarios, no se deberan hacer contratos ni compromisos con estimados porque no son

reales al 100%, en vez de eso se debera optar por colaborar con el cliente para demostrar compromiso. Para evitar estos problemas se ha propuesto el enfoque gil de desarrollo de software, cuyos fundamentos se encuentran en el Manifiesto gil: Software corriendo sobre documentacin extensa. Colaboracin con el cliente sobre contratos. Adaptabilidad al cambio sobre planes. Las personas sobre las herramientas y procesos.

El primer punto se refiere a que dado que el desarrollo es iterativo e incremental, es posible en cada iteracin obtener un incremento con software que puede ser mostrado a usuarios, de modo que se tendr una clara visin de cmo le est yendo al producto y al proceso que estamos siguiendo. En vez de documentacin que si bien es importante, no tiene valor alguno para el usuario. El segundo punto nos dice que los desarrolladores y los clientes deben de apoyarse ya que se tiene un objetivo en comn que es el de resolver un problema y qu mejor que hacerlo de manera conjunta en vez de ser presionados unos por otros. En vez de verse como competidores o enemigos, desarrolladores y clientes deben mirarse como aliados, como un equipo. El tercer punto dice que la mejor forma de desarrollar el mejor producto posible es conseguir las mejores caractersticas y stas se obtienen no siempre al inicio del proyecto, se le pueden ocurrir al cliente en medio del proceso o casi al final y el equipo tiene que ser capaz y estar dispuesto a realizar ese cambio. Los planes son importantes pero no tienen la ltima palabra, son solo una visin. El ltimo punto se refiere a que el software se hace con talento y por ello son las personas las que dan lugar a grandes productos de software mas no las herramientas o los procesos que se podran utilizar. Por eso con un gran equipo pero con malas herramientas o malos procesos se puede llegar a

hacer buenas cosas, en cambio con un mal equipo pero con las mejores herramientas y un buen proceso de desarrollo, el producto sera psimo. As, el modo de trabajo de los equipos giles es el siguiente: se tiene que trabajar de manera muy comunicativa e interactiva, se debe trabajar en iteraciones que proporcionen incrementos y se debe enfocar en el problema del negocio, ya no en las dependencias propias del proceso utilizado. Todos colaboran con todos, se ayudan entre s, ya no hay eso de que yo he hecho mi trabajo, te lo paso y ya no me importa, los miembros de un equipo gil deben ser proactivos y adems deben tener una gran responsabilidad sobre s mismos y con los dems. En cada incremento de su respectiva iteracin se deben aadir nuevas caractersticas del producto, as se ir armando todo el producto. El equipo se enfoca en el negocio cuando hace una lista de las caractersticas del producto por prioridad y para poder hacer esto las caractersticas deben estar con el menor nmero posible de dependencias ya que es imposible priorizar cuando las dependencias son muy fuertes o marcadas. Tambin se enfoca en el negocio cuando entrega caractersticas valiosas para el usuario y para poder llegar a esto se recurre a las Historias de Usuario, que son descripciones de funcionalidades del sistema, una forma de conseguir los requerimientos del software, en la que los usuarios escriben ellos mismos lo que esperan del software y hasta pueden hacer dibujos, aunque hay una plantilla muy til para poder hacerlas:

Yo como ________________ Requiero ________________ Tal que ________________

Es una forma de evitar escribir extensas descripciones de funcionalidades y para poder conseguir requerimientos justo a tiempo. Las historias de usuario son parecidas a los casos de uso en el sentido que nos proporcionan requerimientos, pero en las historias de usuario colaboramos directamente con los futuros usuarios del producto, en cambio en los casos de uso, son los mismos desarrolladores los que describen stas funcionalidades. Aunque son slo el inicio, porque despus se deben entablar conversaciones entre los desarrolladores y el dueo del producto, (persona que se asegura que todos los miembros del equipo tengan la misma visin, estableciendo prioridades para que siempre se trabaje sobre la funcionalidad ms valiosa) las veces que sean necesarias. Hablando del plan, ste casi nunca se va a cumplir. Ocurrirn varias cosas que lo van a invalidar: puede ser que se vayan o ingresen personas al proyecto, existe la posibilidad que las tecnologas usadas trabajen peor o mejor de lo que se haba previsto, etc. An as, se tienen que ver estos imprevistos como una oportunidad de ajustar el proyecto a la realidad. En cada nueva iteracin se debe aadir el conocimiento adquirido en la iteracin previa, de esta forma podemos mejorar el trabajo puesto que ya hemos visto cmo son las cosas realmente y no slo estamos suponiendo, tambin el dueo del producto habr visto que caractersticas son convenientes para ser desarrolladas primero y cules son mejor ponerlas a un segundo plano. Algo que no se debe hacer es planear todo como si conociramos exactamente lo que va a pasar, por eso lo correcto sera planear una parte, ver qu es lo que ocurre y con esta informacin seguir trazando la ruta que vamos a seguir. Por eso los equipos giles usan tres distintos horizontes de planificacin: el da, la iteracin y el lanzamiento. En la planificacin del lanzamiento se ven las historias de usuario que van a ser desarrolladas, los recursos que van a ser utilizados. sta debe ser actualizada con cada iteracin. En la planificacin de la iteracin el dueo del producto establece las nuevas prioridades en base a la iteracin recin finalizada. Se habla sobre lo que se

va a hacer para que las caractersticas se conviertan en software funcionando. En la planificacin del da se coordina el trabajo, se revisan los planes y se define qu es lo que se va a ser slo ese da. Un proyecto comienza con objetivos, por ejemplo hacer un reproductor de msica capaz de recordar las canciones preferidas del usuario, pero siempre vienen acompaados de otros que no nos damos cuenta que estn presentes: son los objetivos respecto a la calidad, respecto al presupuesto. A stos se los llama condiciones de satisfaccin del dueo del producto, condiciones clave para el xito del producto. Desde el inicio del proyecto el equipo y el dueo del producto colaboran mutuamente a encontrar todas estas condiciones, el dueo de producto por ejemplo podra decir que aceptara un lanzamiento con cierta cantidad de historias de usuario o que le parece bien que tarde ms pero que tenga tambin ms historias. En el caso de la historia de usuario yo como estudiante requiero tomar materias tal que slo yo pueda hacerlo, algunas condiciones de satisfaccin seran: Dependiendo del promedio se pueden tomar ms materias. Se pueden tomar materias tanto normales como de mesa. Es posible cambiar grupo de materia.