Este documento discute el enfoque de #NoEstimates para el desarrollo de software, el cual implica realizar proyectos sin ningún proceso formal de estimación. Varios autores argumentan que las estimaciones son inexactas debido a la naturaleza cambiante de los requisitos, y que en su lugar se debe enfocar en la entrega continua de valor mediante iteraciones cortas y colaboración con el cliente. También se comparan los enfoques tradicional, ágil con estimaciones y #NoEstimates en términos de métricas, compromisos y
Un project manager debe luchar por conseguir el personal adecuadoDaniel Piret
De todas las actividades de gestión que debe asumir el Project Manager, la adquisición del personal es sin duda la que marca la diferencia entre el éxito y el fracaso
Un project manager debe luchar por conseguir el personal adecuadoDaniel Piret
De todas las actividades de gestión que debe asumir el Project Manager, la adquisición del personal es sin duda la que marca la diferencia entre el éxito y el fracaso
Creando la práctica de Design Research en una startup. Actividades que tienen sentido para evangelizar y cuando la investigación no se conoce y por lo tanto no se considera estratégica.
Desarrollo e implantacion de un PROYECTODavid Comí
Consultoría y Formación especializada en incrementar el rendimiento, eficacia, proactividad, compromiso y formas óptimas de trabajar de las personas, con el fin de que contribuyan al máximo en los resultados de negocio de la organización.
La experiencia agile de softeng en el desarrollo de Portal BuilderSOFTENG
En esta presentación, el Director General de Softeng explica en la universidad Gimbernat de Barcelona, cómo la filosofía Lean en el desarrollo de software combinado con la metodología Scrum, fueron claves en el éxito de la construcción de Portal Builder. Portal Builder es un potente cms que ayuda a impulsar a las empresas a través de la web. Con Portal Builder, las empresas obtienen mayor autonomía y productividad en la gestión de potentes portales web y rentabilidad, consiguiendo un mayor número de oportunidades de negocio gracias al motor seo y las analíticas de comportamiento de los usuarios. Portal Builder se aloja en la nube, en la plataforma Windows Azure de Microsoft.
Book de Diseño de logotipos y aplicaciones de Identidad Gráfica. Con más frecuencia de la que me gustaría, la mayoría son de "urgen para ayer". Lo más importante es destacar la habilidad para resolver un problema con la mejor calidad posible en el menor tiempo disponible. Si el tiempo fuera el adecuado, muy probablemente el trabajo sería más sofisticado.
Soy el Licenciado en Comunicación Germán Cruz Guzmán. Pueden comunicarse a mi localizador 044 22 22 77 53 85 y a mi e-mail licgermancruz@gmail.com
Aprendiendo a Programar, Primeros pasos.Maria Torres
Slides creados para el Women Techmakers Lima 2014.
Cómo aprender a programar: Sesión orientada a personas sin conocimientos de programación o con pocos conocimientos. Tips y lugares en donde uno puede iniciarse programando y otros datos de interés.
Enjoy!
Consejos y trucos para cualificar una oportunidad DrupalLa Drupalera
David Munárriz, co-Fundador de Emergya y de La Drupalera y Director de Emergya Digital, repasa algunos tips que utliizamos en Emergya/Drupalera para saber si debemos o no entrar en determinados proyectos y cuales son nuestros trucos y filtros más importantes para alinearnos con el cliente a la hora de cualificar una oportunidad Drupal o para detectar si vamos o no llegar a buen puerto. Creo que puede ser interesante para personal de negocio, jefes de proyecto, preventa y cualquier desarrollador.
Universidad Nestlé - Google - Herramientas del futuro hoyCarlos Toxtli
Exploramos algunas de las habilidades consideradas imprescindibles para el aprendizaje en esta nueva era de la información y como con las herramientas de Google podemos beneficiarlos y sacarles el máximo provecho en nuestra aventura educativa.
Creando la práctica de Design Research en una startup. Actividades que tienen sentido para evangelizar y cuando la investigación no se conoce y por lo tanto no se considera estratégica.
Desarrollo e implantacion de un PROYECTODavid Comí
Consultoría y Formación especializada en incrementar el rendimiento, eficacia, proactividad, compromiso y formas óptimas de trabajar de las personas, con el fin de que contribuyan al máximo en los resultados de negocio de la organización.
La experiencia agile de softeng en el desarrollo de Portal BuilderSOFTENG
En esta presentación, el Director General de Softeng explica en la universidad Gimbernat de Barcelona, cómo la filosofía Lean en el desarrollo de software combinado con la metodología Scrum, fueron claves en el éxito de la construcción de Portal Builder. Portal Builder es un potente cms que ayuda a impulsar a las empresas a través de la web. Con Portal Builder, las empresas obtienen mayor autonomía y productividad en la gestión de potentes portales web y rentabilidad, consiguiendo un mayor número de oportunidades de negocio gracias al motor seo y las analíticas de comportamiento de los usuarios. Portal Builder se aloja en la nube, en la plataforma Windows Azure de Microsoft.
Book de Diseño de logotipos y aplicaciones de Identidad Gráfica. Con más frecuencia de la que me gustaría, la mayoría son de "urgen para ayer". Lo más importante es destacar la habilidad para resolver un problema con la mejor calidad posible en el menor tiempo disponible. Si el tiempo fuera el adecuado, muy probablemente el trabajo sería más sofisticado.
Soy el Licenciado en Comunicación Germán Cruz Guzmán. Pueden comunicarse a mi localizador 044 22 22 77 53 85 y a mi e-mail licgermancruz@gmail.com
Aprendiendo a Programar, Primeros pasos.Maria Torres
Slides creados para el Women Techmakers Lima 2014.
Cómo aprender a programar: Sesión orientada a personas sin conocimientos de programación o con pocos conocimientos. Tips y lugares en donde uno puede iniciarse programando y otros datos de interés.
Enjoy!
Consejos y trucos para cualificar una oportunidad DrupalLa Drupalera
David Munárriz, co-Fundador de Emergya y de La Drupalera y Director de Emergya Digital, repasa algunos tips que utliizamos en Emergya/Drupalera para saber si debemos o no entrar en determinados proyectos y cuales son nuestros trucos y filtros más importantes para alinearnos con el cliente a la hora de cualificar una oportunidad Drupal o para detectar si vamos o no llegar a buen puerto. Creo que puede ser interesante para personal de negocio, jefes de proyecto, preventa y cualquier desarrollador.
Universidad Nestlé - Google - Herramientas del futuro hoyCarlos Toxtli
Exploramos algunas de las habilidades consideradas imprescindibles para el aprendizaje en esta nueva era de la información y como con las herramientas de Google podemos beneficiarlos y sacarles el máximo provecho en nuestra aventura educativa.
Como prototipar MAL una aplicación. La importancia del WireframeJorge Galindo Cruces
Buenas! Hace un mes di una charla sobre prototipado en el VIII Betabeers Cádiz y como soy un desastre he tardado en colgar la presentación.
Le di este nombre para recalcar lo mal que se puede llegar a hacer una app sin el uso del prototipado antes del diseño. Empiezo hablando del porqué hacerlo y poco a poco desarrollo el proceso que utilizamos en 47 Degrees.
Por favor, sentidse libre de comentar o preguntar lo que sea!
Enjoy!
Documento que busca ilustrar a los lectores sobre los procesos avanzados que se realizan para crear un proyecto digital de alto valor en la actualidad, sin importar si son agencias de publicidad o empresas de tecnología todos nos debemos comprometer en hacer del internet una herramienta que de verdad complemente y aporte de manera significativa a la vida de los usuarios.
Todo proyecto software está sujeto a 3 grandes verdades. No se puede luchar contra ellas, se debe convivir con ellas. En este artículo intento mostrar esas 3 verdades y algunas soluciones para que no afecten a tu proyecto.
El propósito de todo proyecto, es hacer posible el desarrollo estructurado, planificado e inteligente de una IDEA que suponemos tiene potencial y es estratégica en la organización.
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
3. ¿Cómo podemos estimar
cuando todavía no sabemos o
entendemos la solución?
Neil Killick
http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/
6. para construir software necesitamos sólo una
visión clara y un propósito compartido,
objetivos de alto nivel, y no el detalle de cómo
vamos a lograrlos
7. ¿qué sentido tiene buscar una
estimación precisa y condicionar todo
el proyecto a ella? ¿qué sentido tiene si
sabemos desde el principio que es
inexacta por naturaleza?
13. En casi todos los
proyectos,
comienzan con “-
¿Esto cuánto va a
costar?-“ Pero,
quizá, la pregunta
correcta no debería
ser… “-¿De cuánto
presupuesto
dispones?-“.
14. “- Es que si trabajo con un
presupuesto me van a engañar, ya
que desarrollo va a trabajar más
despacio para intentar alargar el
proyecto -”.
15. Si la empresa de desarrollo
te quiere engañar lo hará en
cascada, en ágil o en
cualquier modelo
16. Pero al no atarte a una
estimación te llevas de
regalo poder cambiar los
requisitos cuando quieras
17. En cualquier caso, recuerda,
“Customer collaboration over contract
negotiation”, si no hay confianza
difícilmente habrá un proyecto de
éxito
19. Sino está claro que hay que
hacer, porque se descubre
según avanza el proyecto,
estará poco claro cuándo se
va a terminar.
20. ¿Te crees que con requisitos
cerrados sabías seguro cuándo
se va a terminar?
21. Y, no obstante, en la
realidad si que vas a
tener una previsión de
finalización, ya que vas
a ir viendo los
requisitos que el
equipo va completando
por periodo de tiempo,
lo que te dará lo que
llamamos la media de
velocidad, que te valdrá
para hacer previsiones
de finalización.
27. 5 - #NoEstimates consiste en buscar la
forma de que si sea viable en el
mundo real no estimar
28. Comparando el enfoque tradicional,
con el ágil con estimaciones y con el
#noEstimates
http://www.javiergarzas.com/2014/12/comparando-el-enfoque-tradicional-con-el-agil-con-estimaciones-y-con-el-noestimates.html
https://docs.google.com/presentation/d/1AinGFFlzOE4gL8Bntp2rJFAdoqhku_iXrKgfJjK-BSw/mobilepresent?pli=1#slide=id.p13
29. Velocidad
(trabajo
completado
por Sprint),
Puntos
Historia. Burn
Down / Up
TRADICIONAL ÁGIL C/ ESTIMACIONES #NOESTIMATES
Métricas típicas de seguimiento de
proyecto
Tiempo Real
vs Tiempo
Estimado.%
de avance
(p.e. El típico
del Gantt)
Valor entregado.
Historias de
Usuario
completadas,
Lead Time, Cycle
Time
30. Compromisos
por Sprint
(semanas)
Acuerdos “cliente” – “proveedor”
La estimación
inicial se
convierte en un
compromiso a
largo plazo
(meses, años),
en tiempo,
precio y
alcance
Entrega continua. Flujo
continuo de entrega de
valor. Los acuerdos
están en la ordenación
por valor de aquello a
realizar y en intentar
reducir los tiempos de
elaboración (el cycle
time, desde que se
empieza a trabajar en
una tarea hasta que se
termina)
TRADICIONAL ÁGIL C/ ESTIMACIONES #NOESTIMATES
31. Ciclo de vida
iterativo e
incremental con
iteraciones
cortas.
Framework tipo
Scrum
Modelo, framework, ciclo de vida
referencia
Ciclo de
vida en
cascada
Kanban
TRADICIONAL ÁGIL C/ ESTIMACIONES #NOESTIMATES
No está muy claro el origen de la idea, pero desde luego, en los últimos tiempos, el movimiento que recomienda y defiende que las estimaciones en el mundo del software no tienen sentido (e incluso son perjudiciales) ha crecido con relativa fuerza en el mundo del desarrollo software y, más concretamente, en el mundo ágil.
Más allá de los orígenes, por si quieres seguir este tema, quienes más están liderando el #NoEstimates son Woody Zuill y Neil Killick.
Hoy en día, este movimiento en contra de las estimaciones software podemos encontrarlo agrupado bajo el nombre #NoEstimates (lo de la # al principio del nombre viene de que éste es un hasghtag de twitter, por si no eres muy tuitero, bajo el que se recopilan opiniones sobre el tema).
Realmente, por la naturaleza del software, es imposible obtener una estimación precisa
Como expone en un artículo Neil Killick, que como te decía es unos de los precursores del movimiento, la base del movimiento #noEstimates está en “¿Cómo podemos estimar cuando todavía no sabemos o entendemos la solución?”
El desarrollo software es, por su propia naturaleza, impredecible y no repetitivo. A diferencia de la producción de, por ejemplo, automóviles (te recomiendo aquí aquel post de Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas), el producto exacto que estamos construyendo es desconocido hasta que lo hemos construido.
Por esta razón, fijar el alcance exacto (en tiempo – esfuerzo) de los proyectos software es imposible. Incluso si lo fuera, no es deseable, ya que un enfoque de este tipo limita el cambio durante el proyecto, limita un diseño emergente, los requisitos cambiantes y la innovación.
Si aceptamos que el alcance de aplicación a desarrollar es siempre la variable… también debemos aceptar que la fecha de entrega puede ser variable.
Obtener una estimación se basa en satisfacer un conjunto fijo de requisitos, si los requisitos no son precisos… las estimaciones no son precisas
Y tener unos requisitos precisos antes de comenzar… ya sabemos, y está muy debatido, que es algo que muy pocos proyectos se pueden permitir, algo que siempre pretendió el ciclo de vida en cascada, algo que generó (genera) proyectos en los que todas las partes acaban inconformes, etc.
No me extiendo en las razones de todo esto, que ya las hemos contado muchas veces, no obstante, si tienes interés léete estos dos post: Contrato cerrado, ¿el peor enemigo del software o mal necesario? Y Diagramas Gantt cómo arma de destrucción masiva de proyectos.
Estimar varias veces durante el proyecto. No basta con estimar al principio, según avanza el proyecto deberíamos reajustar la estimación. Algunos autores señalan que deberíamos estimar al menos en tres puntos: En la etapa de estudio de viabilidad, o inicio del proyecto, en la etapa de requisitos y en la etapa de diseño. Yo incluso creo que en proyectos grandes habría que estimar varias veces según avanza el desarrollo.
El nivel de precisión de la estimación es distinto a medida que avanza el proyecto. Al principio del proyecto, cuando sólo se tienen requisitos, el error con el que se trabaja es mayor que cuando se estima en la fase de diseño. Una figura muy útil para entender esto es el “cono de incertidumbre”, que muestra cómo las estimaciones son más precisas según progresa el proyecto:
Aparte de tamaño y esfuerzo global, hay que estimar fases concretas del ciclo de vida. Si no se tienen históricos, existen fórmulas que dicen cómo se divide en fases el esfuerzo total del proyecto, las más famosas son del ISBSG.
Cada empresa (y muchas veces tipo de proyecto) tiene su método de estimación. No hay un mejor método de estimación… hay uno mejor para cada empresa, y este depende del negocio, del tamaño de la empresa, de su madurez, etc. Por ejemplo, el método de estimación para empresas que desarrollan productos no será seguramente igual que el de empresas que externalizan.
Utilizar varias fuentes y métodos. Complementar siempre el método de estimación con datos de proyectos anteriores (analogía), y realizar comparativas con los mismos. Además, complementar preguntando al equipo de desarrollo.
Usa una unidad de estimación acorde a la fase del proyecto en la que estimas. A la hora de proporcionar una estimación muchas veces es útil valerse de rangos, que se pueden ir ajustando conforme avanza el proyecto. Por ejemplo, “entre la primera y la segunda semana del mes de abril” o “10 meses con más menos quince días de error”. Un error muy frecuente es en la primera estimación decir el día exacto de finalización del proyecto, cuando sabemos que en una estimación tan temprana siempre hay error.
Como argumentan desde el #noEstimates, para construir software necesitamos sólo una visión clara y un propósito compartido, objetivos de alto nivel, y no el detalle de cómo vamos a lograrlos. Entonces… ¿qué sentido tiene buscar una estimación precisa y condicionar todo el proyecto a ella? ¿qué sentido tiene si sabemos desde el principio que es inexacta por naturaleza?
En la verdadera forma iterativa entonces podemos alinear nuestras decisiones justo a tiempo acerca de cómo vamos a mejorar el producto en la siguiente iteración (es decir, lo que vamos a construir al lado, también conocidos como elementos principales en la Pila de Producto) con estas metas.
To build software we need a clear vision and shared purpose of what success looks like. When commencing with a potentially valuable software initiative we need well understood high level goals, not the detail of how we will achieve those goals.
In true iterative fashion we can then align our just-in-time decisions about how we will improve the product in the next iteration (i.e. what we will build next, aka top items in the Product Backlog) with these goals.
Woody Zuill y neil Killick
Zuill didn't claim that estimates are "bad" in all cases; rather, they're not always essential to the software development process.
an estimate is "a length of time it will take to develop software, determined by human judgment and based on experience." There are many ways to do this. You can break the work down into chunks and add it up, you can look at a variety of similar projects to compare, or you can stick your finger in the air and guess. All of those are estimation techniques.
We'll define #NoEstimates as running a software project without any human estimation process. If customers asks, "How long will it take?" that's estimating. If they never have to ask, that's #NoEstimates.
For the purpose of this article, an estimate is "a length of time it will take to develop software, determined by human judgment and based on experience." There are many ways to do this. You can break the work down into chunks and add it up, you can look at a variety of similar projects to compare, or you can stick your finger in the air and guess. All of those are estimation techniques.
Corte, ver como aplicar en la realidad
Entiendo que os estaréis preguntando como hago p llevar esto a la realidad, yo lo puedo decir de manera muy coherente aca pero afuera hay que hacer presupuesto y vender proyectos y lo que quiero deciros es que si se puede y de hecho ya se esta haciendo…
El problema no solo son los requisitos, sino la tecnología cambiante y el cliente también (diferentes)
La incertidumbre no solo está en los requisitos…
En la medida de lo posible En vez de tener proyectos llave en mano hacer acuerdos de colaboración
Es lo típico cuando una empresa que tiene una idea se alía con una consultora tecnológica para llevarlo acabo ..
en este caso no es necesaria la estimacion, porque no vendemos un proyecto cerrado sino que firmamos un acuerdo de colaboración
http://www.slideshare.net/mgbarcomb/fly-weight-agile-stop-making-it-harder-than-it-needs-to-be
En modelos de comercialización cloud se factura por uso el proyecto de desarrollo de software
Hay muchas consultoras grandes que en vez de vender proyectos llave en mano cobran sus servicios por utilización
Imagínate una multinacional con miles de empleados dispersos alrededor del mundo que necesita un proyecto de single signe on (autenticación unica)
En vez de contratarnos un proyecto cerrado con necesidad de estimar p hacer este sw, nos paga por usuario conectado por mes
Consultoras grandes como everis ademas de proyectos cerrados estan tendiendo a vender proyectos por uso
No está muy claro el origen de la idea, pero desde luego, en los últimos tiempos, el movimiento que recomienda y defiende que las estimaciones en el mundo del software no tienen sentido (e incluso son perjudiciales) ha crecido con relativa fuerza en el mundo del desarrollo software y, más concretamente, en el mundo ágil.
Más allá de los orígenes, por si quieres seguir este tema, quienes más están liderando el #NoEstimates son Woody Zuill y Neil Killick.
Hoy en día, este movimiento en contra de las estimaciones software podemos encontrarlo agrupado bajo el nombre #NoEstimates (lo de la # al principio del nombre viene de que éste es un hasghtag de twitter, por si no eres muy tuitero, bajo el que se recopilan opiniones sobre el tema).