Recientemente comencé a trabajar en un equipo en un nuevo proyecto. Nuestra empresa está intentando ejecutar las cosas de una manera ágil.
El equipo del proyecto consta de 4 desarrolladores, cada uno de diferentes equipos y con diferentes conocimientos de dominio comercial del nuevo proyecto.
Nuestra primera reunión involucró revisar una lista de historias de usuarios y usar el póquer de planificación para intentar dar estimaciones de las historias presentadas. Sin embargo, realmente luché con este proceso.
Aquí para algunas cosas con las que luché.
Un ejemplo de un par de historias de usuarios se veía así:
Como administrador de cuentas / oficina de campo, quiero instalar la aplicación localmente para poder usarla sin conexión.
Como administrador de CRM, quiero poder almacenar los archivos xml de la aplicación en el sistema CRM de la empresa para poder imprimir informes de marca.
A pesar de todo esto, aún hicimos estimaciones utilizando puntos relativos de la historia. El PM entonces iba a irse y aumentar el costo del proyecto y estimarlo en términos de tiempo para poder hacer una cotización para la compañía que requiere el trabajo.
Mis preguntas incluyen:
Si el proyecto es nuevo y no hay experiencia previa, le sugiero que use puntos de historia para estimar las historias de los usuarios .
Muchas de las historias estaban impulsadas por la interfaz de usuario y su complejidad podría depender de la complejidad de la interfaz de usuario de la que no teníamos idea. Por lo tanto, luché para estimar adecuadamente.
Si la complejidad depende de la interfaz de usuario, entonces el uso de puntos de historia es la mejor opción. Las estimaciones relativas no son tan frágiles como las absolutas.
El primer ministro quería que calculáramos todas las historias. Sin embargo, algunas de las historias tenían grandes incógnitas y preguntas que el primer ministro no pudo responder.
Para esas historias , puede pedir aclaraciones o dar estimaciones sin procesar/estimaciones . Es tu decision. Si las historias son realmente enormes y no están claras, le sugiero que le pida a PO que las divida y participe en su reunión de estimación . Estoy seguro de que obtendrá los comentarios más rápidos entonces.
¿Debe estimar todas las historias de usuarios al comienzo de un proyecto?
La acumulación estimada es necesaria para una gestión eficiente de la acumulación de productos por parte del propietario del producto . Es una buena práctica completar y estimar todo el backlog cuando comienza el proyecto para proporcionar una estimación de alto nivel del producto. Es obvio que se agregarán nuevas historias en el futuro de todos modos, pero puede proporcionar un punto de partida.
Dadas nuestras estimaciones, ¿cuál es la mejor manera para que el PM determine las horas por punto para que pueda estimar un costo total? Creo que normalmente usamos el tiempo promedio de un proyecto anterior, sin embargo, este proyecto consta de 4 nuevos desarrolladores.
Sí, se puede utilizar la experiencia de proyectos anteriores. Puede calcular una cantidad promedio de puntos de historia por desarrollador por sprint. De todos modos, es mejor calcular la velocidad real de un equipo después de 2 o 3 sprints ya que "Scrum se basa en la teoría de control de procesos empíricos o empirismo. El empirismo afirma que el conocimiento proviene de la experiencia y la toma de decisiones basadas en lo que se sabe".
¿Deberíamos hacer maquetas de UI y discusiones de diseño durante este proceso para ayudarnos a estimar mejor?
Si el equipo de desarrollo considera que se necesitan maquetas de IU para su desarrollo, entonces no hay razones para evitarlas.
En nuestras estimaciones, no hubo probadores involucrados para agregar su aporte.
Si sigue Scrum/Agile, no hay valor en el incremento sin pruebas, ya que es parte del proceso de desarrollo de software. Cada historia requiere pruebas de aceptación. Después de varios sprints, definirá la velocidad del equipo: cuántos puntos de historia puede terminar su equipo en un sprint.
Estos son solo algunos pensamientos y experiencias sobre proyectos impulsados por la interfaz de usuario.
Hace 3 meses comenzamos un nuevo proyecto para volver a desarrollar completamente la columna vertebral de nuestros productos de automatización industrial de 10 años. Hicimos muchas reuniones de lluvia de ideas para los aspectos de hardware, software, firmware, etc. del proyecto. Entonces decidimos abordar el proyecto de forma multi-equipo.
La parte de software del proyecto incluyó un rediseño completo de toda el área de UX. Entonces, como los desarrolladores aún están desarrollando la base del código, estamos trabajando con un experto independiente en UX que nos coordina con su experiencia. Creamos personas, diseñamos escenarios y casos de uso, diseñamos maquetas y wireframes, y hoy en día estamos comenzando a seleccionar la tecnología adecuada en función de los requisitos que surgieron de todos estos estudios y prototipos. Estamos apenas al comienzo de la parte UX del proyecto. Habrá muchos más pasos en el camino.
Como puede ver y creo que ya sabe, la interfaz de usuario no es un problema de un solo paso/única vez en el ciclo de vida del diseño de un producto, sino que es el principal impulsor de la columna vertebral. Debe advertir a su PM sobre las consecuencias de omitir esta fase del proyecto. La decisión contraria llevaría el proyecto al caos a largo plazo.
Puedo ver varias banderas rojas aquí:
1) Tus historias publicadas no tienen criterios de aceptación. ¿Cómo podrá el cliente/PM saber si algo está completo además de un capricho personal?
2) Tus historias publicadas no tienen comportamiento... hablan sobre los objetivos del sistema, pero no tienen información sobre cómo se comporta en función de lo que está haciendo el usuario.
3) Tampoco hizo mención de "elaboración". No haces una estimación hasta que la historia esté lo suficientemente elaborada como para que puedas hacer una estimación razonable. ¿Sientes que podrías implementar razonablemente estas historias tal como se dan? Si no es así, entonces no está listo para entrar en el backlog y no está listo para ser estimado. Por lo que ha publicado, el PM está tratando el trabajo pendiente como una lista de deseos, no como una cola prioritaria de tareas "listas para ejecutar".
También esto:
Como administrador de cuentas / oficina de campo, quiero instalar la aplicación localmente para poder usarla sin conexión.
Algo me dice que es un arco narrativo o épico, y debe dividirse en varias historias implementables de forma independiente.
Recientemente terminé un proyecto que tuvo un comienzo similar. Ella necesita la cotización, y para construir la cotización, necesita sus estimaciones. Pero para estimar, necesita un nivel de detalle que no siempre es posible en esta fase. ¡Es un círculo vicioso!
Nuestro enfoque fue asociar tantos supuestos como pudiéramos generar al armar la estimación para cada pieza de funcionalidad, y luego asignar un valor de riesgo a esos supuestos. Cuando presenta su cotización, puede decirle al cliente con cierta confianza: aquí está nuestra estimación del rango de costos, que se basa en estos supuestos que estimamos que implican este nivel de riesgo.
Espero que eso ayude un poco, ¡y la mejor de las suertes!
Recientemente tuve una situación similar.
El cliente nos pidió que le brindáramos la planificación con la documentación que consta de
Queríamos dirigir el equipo de manera ágil (Scrum), por lo que primero decidimos encontrar tantas historias de usuarios como pudiéramos; dedicamos varios días a discutir y analizar los requisitos. Luego descubrimos que incluso si estimamos las historias de los usuarios en puntos, no podremos calcularlo en días-hombre, por lo que no lo hicimos. Al tener historias de usuarios, nuestra comprensión del sistema fue mucho mejor, por lo que el trabajo que hicimos no fue innecesario. Eventualmente, comenzamos a analizar los aspectos técnicos del proyecto y a construir la EDT con tareas técnicas. Usamos PERT ( http://pl.wikipedia.org/wiki/PERT ) como técnica de estimación (hay muchas otras pero esta parece ser la más fácil y rápida de implementar).
Gracias a este enfoque preparamos dos ofertas, pesimista y muy probable (del PERT). El cono de incertidumbre se utilizó como uno de los argumentos por los que no podemos estar seguros de los costos y la fecha de entrega. El cliente aceptó eso y no trató de socavarlo.
¿Qué fue lo siguiente? El cliente suspendió el proyecto por otras razones y nos dio otro proyecto más pequeño que nos dio tiempo para introducirlo mejor en el dominio. El equipo tiene mucha experiencia ahora:
Uno de los resúmenes de la retrospectiva sobre la planificación que hicimos es que, felizmente, el cliente no había decidido iniciar este proyecto, porque incluso la versión pesimista estaba equivocada:
Todd A. Jacobs
Dreza
Todd A. Jacobs