¿Cómo deberíamos llamar sprints en desarrollo ágil cuando no vendemos consultoría a un cliente?

Me referiría a estos como "Iteraciones". Puede describir su proceso en términos de iteraciones para sus clientes; por ejemplo, trabajamos en iteraciones de dos semanas. Eso significa que, en el primer día, identificamos el trabajo que vamos a hacer en las próximas dos semanas.... etc...

Términos del sector público

Cada industria y sector tiene su propio dialecto . En el sector público, las prácticas ágiles generalmente se denominan "desarrollo modular" y los sprints ofrecen "incrementos" o "segmentos útiles". Consulte la página 7 de la Guía de contratación para apoyar el desarrollo modular para ver un ejemplo.

Términos del sector privado

Para las empresas que entienden las prácticas ágiles, a menudo sigue siendo útil definir los términos tal como pretende usarlos. Para mis clientes, generalmente defino marcos ágiles (por ejemplo, Scrum) como:

Un proceso iterativo (o conjunto de procesos) donde el objetivo de cada iteración es completar un incremento demostrable de funcionalidad visible para el usuario.

Estoy seguro de que otras personas han dicho cosas similares, pero la cita anterior es mía, por lo que no tengo ninguna referencia externa. Simplemente encuentro útil definir mis términos con la gente para que, independientemente de cómo decidamos llamarlo entre nosotros, al menos teóricamente estemos de acuerdo en el objetivo real.

Ver también

• http://www.cio.gov/documents/25-point-implementation-plan-to-reform-federal%20it.pdf
• http://scrum.jeffsutherland.com/2010/01/iterative-vs-incremental-development.html

Desde la perspectiva de Scrum, el Sprint no es solo una iteración. Tiene compromiso (planificación) y responsabilidad (demostración) también .

Si cambia la terminología, no podrá comunicarse con otros profesionales. Si la gerencia no entiende la definición de Sprint y se detiene en la terminología, pueden pensar que Scrum significa que los desarrolladores entrarán en formación y harán esto todas las mañanas:

Mi punto es que no cambie un nombre existente porque es más fácil vender algo . Vender la idea no el nombre. La gente no compra cierto tipo de producto, porque fue hecho por una compañía que lleva el nombre de una fruta. Compran porque tienen la idea de lo que representa : confiabilidad, simbolismo de estatus, etc.

Según mi experiencia, la mayoría de los gerentes son inteligentes y conocen la diferencia y comprenderán el significado de un Sprint .

No creo que realmente tengas que preocuparte por la semántica. "Sprint" es una terminología bastante estándar, y los clientes se preocuparán más por la revisión final del sprint/gráficos de trabajo pendiente, etc. Mientras se haga el trabajo, ¿qué significa un nombre?

Habiendo dicho esto, si realmente debe cambiar el nombre, ¿qué tal timebox? Si usa la terminología ágil de DSDM, puede dividir el proyecto en ciclos iterativos y luego dividir las iteraciones en timeboxes. Esto es lo mismo que 'sprint' pero con un nombre diferente.

¿Qué hay de los "paquetes de trabajo en caja de tiempo"?

¿Cuál es la perspectiva de lo que llamas un sprint para tu cliente? ¿El cliente tiene visibilidad y recibe un entregable que evalúa y necesita aprobar? ¿Proporciona comentarios sobre el producto que considera para futuras versiones? ¿Está el producto definido de forma suficientemente clara y cerrada para terminar el desarrollo? En mi opinión, debe ponerse de pie para nombrar a su cliente de una manera que tenga sentido para él y también ser lo suficientemente claro para que el equipo entienda la perspectiva del cliente. Sin más información, puede llamarlo 'lanzamiento', 'versión' o algo similar. El tema es importante ya que es más probable que describa y ayude a cumplir con las expectativas.