Lean Software Development - Revision history

Mberne: /* 2.Construir con calidad */

2023-12-19T09:56:56Z

2.Construir con calidad

← Older revision		Revision as of 11:56, 19 December 2023
Line 22:		Line 22:

	Algunos ejemplos de prácticas que se deben contemplar al hacer software:		Algunos ejemplos de prácticas que se deben contemplar al hacer software:
	*Técnicas como [[TDD]] (Test Driven Development) permiten que usuarios (clientes), programadores y tester definan claramente los requerimientos y confeccionen pruebas de aceptación antes de escribir el código. Ayuda a la comprensión de los programadores y mejora el entendimiento de los requerimientos.		*Técnicas como [[TDD]] (''Test Driven Development'') permiten que usuarios (clientes), programadores y tester definan claramente los requerimientos y confeccionen pruebas de aceptación antes de escribir el código. Ayuda a la comprensión de los programadores y mejora el entendimiento de los requerimientos.
	*El programador es responsable de su propio desarrollo. No debe esperar a que las pruebas o los procedimientos de aseguramiento de calidad descubran los errores.		*El programador es responsable de su propio desarrollo. No debe esperar a que las pruebas o los procedimientos de aseguramiento de calidad descubran los errores.
	*Fomentar el desarrollo de pruebas automatizadas.		*Fomentar el desarrollo de pruebas automatizadas.
	*Refactorización del código, para lograr simplicidad y eliminar duplicidades.		*Refactorización del código, para lograr simplicidad y eliminar duplicidades.

	===3.Compartir conocimiento===		===3.Compartir conocimiento===
	Conocer lo que necesita el cliente requiere dedicación y esfuerzo, y debe convertirse en el aspecto principal, porque desarrollar un producto que no es útil, es el mayor desperdicio.		Conocer lo que necesita el cliente requiere dedicación y esfuerzo, y debe convertirse en el aspecto principal, porque desarrollar un producto que no es útil, es el mayor desperdicio.

Mberne: /* Véase también */

2023-12-19T09:56:32Z

Véase también

← Older revision		Revision as of 11:56, 19 December 2023
Line 45:		Line 45:
	==Véase también==		==Véase también==
	*[[Lean]].		*[[Lean]].
	*[[Manufactura ~~Lean~~]].		*[[Manufactura lean]].
	*[[Lean inception]].		*[[Lean inception]].
	*[[Kanban: origen y definición]].		*[[Kanban: origen y definición]].

Mberne: /* Véase también */

2023-12-19T09:56:25Z

Véase también

← Older revision		Revision as of 11:56, 19 December 2023
Line 45:		Line 45:
	==Véase también==		==Véase también==
	*[[Lean]].		*[[Lean]].
			*[[Manufactura Lean]].
	*[[Lean inception]].		*[[Lean inception]].
	*[[Kanban: origen y definición]].		*[[Kanban: origen y definición]].

Mberne: /* Véase también */

2023-12-19T09:55:04Z

Véase también

← Older revision		Revision as of 11:55, 19 December 2023
Line 45:		Line 45:
	==Véase también==		==Véase también==
	*[[Lean]].		*[[Lean]].
	*[[Lean ~~Inception~~]].		*[[Lean inception]].
	*[[Kanban: origen y definición]].		*[[Kanban: origen y definición]].

	==Referencias==		==Referencias==
	*<sup>1</sup>Poppendieck, M.; Poppendieck, T. (2003) ''Lean Software Development: An Agile Toolkit for Software Development Managers'', Addison Wesley.		*<sup>1</sup>Poppendieck, M.; Poppendieck, T. (2003) ''Lean Software Development: An Agile Toolkit for Software Development Managers'', Addison Wesley.

Mberne at 09:54, 19 December 2023

2023-12-19T09:54:45Z

← Older revision		Revision as of 11:54, 19 December 2023
Line 1:		Line 1:
	__NOTOC__		__NOTOC__

	~~Este término~~ se refiere a la aplicación de los principios la [[manufactura lean]] o [[producción lean]] en el desarrollo del software. Mary y Tom Poppendieck<sup>1</sup> fueron quienes lo acuñaron. Gracias a sus aportes y los de la comunidad ágil, Lean Software Development está desarrollando un inventario de prácticas útiles para el desarrollo ágil de software.		'''''Lean Software Development''''' se refiere a la aplicación de los principios la [[manufactura lean]] o [[producción lean]] en el desarrollo del software.
			==Origen==
			Mary y Tom Poppendieck<sup>1</sup> fueron quienes lo acuñaron. Gracias a sus aportes y los de la comunidad ágil, ''Lean Software Development'' está desarrollando un inventario de prácticas útiles para el desarrollo ágil de software.
			==Principios==
	Se basa en 7 principios:		Se basa en 7 principios:
			===1.Eliminar el desperdicio===
			Las actividades que no crean valor no sirven y deben ser eliminadas.

			Algunos '''ejemplos''':
	~~====1.Eliminar el desperdicio====~~
	~~Las actividades que no crean valor no sirven y deben ser eliminadas.~~ Algunos ejemplos:
	*Tareas que no fueron solicitadas por el cliente.		*Tareas que no fueron solicitadas por el cliente.
	*Sobre-documentación del proyecto.		*Sobre-documentación del proyecto.
Line 13:		Line 16:
	*Los errores, bugs y fallos del software son verdadero desperdicio que se debe reducir.		*Los errores, bugs y fallos del software son verdadero desperdicio que se debe reducir.

	====2.Construir con calidad====		===2.Construir con calidad===
	Incluir en el procedimiento prácticas para mejora de la calidad en el producto (traslación de prácticas “poka-yoke” y “andon” al desarrollo de software).		Incluir en el procedimiento prácticas para mejora de la calidad en el producto (traslación de prácticas “poka-yoke” y “andon” al desarrollo de software).

	Un procedimiento que respeta la calidad es aquel que es conocido, entendido y mejorado por los propios participantes. Para lograrlo es necesario compromiso y respeto.		Un procedimiento que respeta la calidad es aquel que es conocido, entendido y mejorado por los propios participantes. Para lograrlo es necesario compromiso y respeto.

	Algunos ejemplos de prácticas que se deben contemplar al hacer software.		Algunos ejemplos de prácticas que se deben contemplar al hacer software:
	*Técnicas como [[TDD]] (Test Driven Development) permiten que usuarios (clientes), programadores y tester definan claramente los requerimientos y confeccionen pruebas de aceptación antes de escribir el código. Ayuda a la comprensión de los programadores y mejora el entendimiento de los requerimientos.		*Técnicas como [[TDD]] (Test Driven Development) permiten que usuarios (clientes), programadores y tester definan claramente los requerimientos y confeccionen pruebas de aceptación antes de escribir el código. Ayuda a la comprensión de los programadores y mejora el entendimiento de los requerimientos.
	*El programador es responsable de su propio desarrollo. No debe esperar a que las pruebas o los procedimientos de aseguramiento de calidad descubran los errores.		*El programador es responsable de su propio desarrollo. No debe esperar a que las pruebas o los procedimientos de aseguramiento de calidad descubran los errores.
	*Fomentar el desarrollo de pruebas automatizadas.		*Fomentar el desarrollo de pruebas automatizadas.
	*Refactorización del código, para lograr simplicidad y eliminar duplicidades.		*Refactorización del código, para lograr simplicidad y eliminar duplicidades.
			===3.Compartir conocimiento===
	====3.Compartir conocimiento====
	Conocer lo que necesita el cliente requiere dedicación y esfuerzo, y debe convertirse en el aspecto principal, porque desarrollar un producto que no es útil, es el mayor desperdicio.		Conocer lo que necesita el cliente requiere dedicación y esfuerzo, y debe convertirse en el aspecto principal, porque desarrollar un producto que no es útil, es el mayor desperdicio.
	Hacer software implica un proceso de aprendizaje: entender qué es lo que el cliente quiere y cómo entregar la mejor solución posible. El desarrollo incremental proporciona cuantiosa y frecuente retroinformación.		Hacer software implica un proceso de aprendizaje: entender qué es lo que el cliente quiere y cómo entregar la mejor solución posible. El desarrollo incremental proporciona cuantiosa y frecuente retroinformación.

	====4.Diferir el compromiso====		===4.Diferir el compromiso===
	En los proyectos ágiles que parten con una visión que evoluciona con el desarrollo, el compromiso con el cliente se asienta y evoluciona en la misma medida que se van concretando y comprometiendo los incrementos del producto.		En los proyectos ágiles que parten con una visión que evoluciona con el desarrollo, el compromiso con el cliente se asienta y evoluciona en la misma medida que se van concretando y comprometiendo los incrementos del producto.

	====5.Entregar rápido====		===5.Entregar rápido===
	La gestión evolutiva realiza entregas rápidas a los clientes, que se encuentran con código operativo desde etapas tempranas. Dicho código debe ser desarrollado con calidad ya que no se puede mantener una velocidad importante de entrega si no se cuenta con calidad y un equipo disciplinado, comprometido y confiable.		La gestión evolutiva realiza entregas rápidas a los clientes, que se encuentran con código operativo desde etapas tempranas. Dicho código debe ser desarrollado con calidad ya que no se puede mantener una velocidad importante de entrega si no se cuenta con calidad y un equipo disciplinado, comprometido y confiable.

	====6.Respetar a las personas====		===6.Respetar a las personas===
	Lean se basa en el respecto por las personas que son el elemento único y diferenciador de cada organización.		Lean se basa en el respecto por las personas que son el elemento único y diferenciador de cada organización.

	Deben estar suficientemente capacitadas y ser responsables de los procesos en los que intervienen, de modo que cuando resultan necesarios cambios y mejoras, cada persona colabora en su desarrollo.		Deben estar suficientemente capacitadas y ser responsables de los procesos en los que intervienen, de modo que cuando resultan necesarios cambios y mejoras, cada persona colabora en su desarrollo.

	====7.Optimizar el todo====		===7.Optimizar el todo===
	Lean invita a contemplar el proceso completo, es decir todo el flujo de valor, en lugar de hacerlo en cada etapa. El problema de optimizar cada fase por separado es que genera inventarios grandes en los puntos de transición. En el mundo del software, estos "inventarios" representan al trabajo parcialmente terminado (por ejemplo, requisitos completos, pero sin diseñar, codificar o probar). Lean demostró que un flujo de "una pieza" (por ejemplo, enfocarse en construir un ítem de manera completa) es un proceso más eficiente que concentrarse en construir las partes separadas de forma rápida.		Lean invita a contemplar el proceso completo, es decir todo el flujo de valor, en lugar de hacerlo en cada etapa. El problema de optimizar cada fase por separado es que genera inventarios grandes en los puntos de transición. En el mundo del software, estos "inventarios" representan al trabajo parcialmente terminado (por ejemplo, requisitos completos, pero sin diseñar, codificar o probar). Lean demostró que un flujo de "una pieza" (por ejemplo, enfocarse en construir un ítem de manera completa) es un proceso más eficiente que concentrarse en construir las partes separadas de forma rápida.
			==Véase también==
			*[[Lean]].
			*[[Lean Inception]].
			*[[Kanban: origen y definición]].
	==Referencias==		==Referencias==
	*<sup>1</sup>Poppendieck, M.; Poppendieck, T. (2003) ''Lean Software Development: An Agile Toolkit for Software Development Managers'', Addison Wesley.		*<sup>1</sup>Poppendieck, M.; Poppendieck, T. (2003) ''Lean Software Development: An Agile Toolkit for Software Development Managers'', Addison Wesley.

Mberne at 09:52, 19 December 2023

2023-12-19T09:52:35Z

← Older revision		Revision as of 11:52, 19 December 2023
Line 1:		Line 1:
	__NOTOC__		__NOTOC__

	Este término se refiere a la aplicación de los principios la [[manufactura lean]] o [[producción lean]] en el desarrollo del software. Mary y Tom Poppendieck ~~[[Poppendieck & Poppendieck, 2003]]~~ fueron quienes lo acuñaron. Gracias a sus aportes y los de la comunidad ágil, Lean Software Development está desarrollando un inventario de prácticas útiles para el desarrollo ágil de software.		Este término se refiere a la aplicación de los principios la [[manufactura lean]] o [[producción lean]] en el desarrollo del software. Mary y Tom Poppendieck<sup>1</sup> fueron quienes lo acuñaron. Gracias a sus aportes y los de la comunidad ágil, Lean Software Development está desarrollando un inventario de prácticas útiles para el desarrollo ágil de software.
	Se basa en 7 principios:		Se basa en 7 principios:

Line 41:		Line 41:
	Lean invita a contemplar el proceso completo, es decir todo el flujo de valor, en lugar de hacerlo en cada etapa. El problema de optimizar cada fase por separado es que genera inventarios grandes en los puntos de transición. En el mundo del software, estos "inventarios" representan al trabajo parcialmente terminado (por ejemplo, requisitos completos, pero sin diseñar, codificar o probar). Lean demostró que un flujo de "una pieza" (por ejemplo, enfocarse en construir un ítem de manera completa) es un proceso más eficiente que concentrarse en construir las partes separadas de forma rápida.		Lean invita a contemplar el proceso completo, es decir todo el flujo de valor, en lugar de hacerlo en cada etapa. El problema de optimizar cada fase por separado es que genera inventarios grandes en los puntos de transición. En el mundo del software, estos "inventarios" representan al trabajo parcialmente terminado (por ejemplo, requisitos completos, pero sin diseñar, codificar o probar). Lean demostró que un flujo de "una pieza" (por ejemplo, enfocarse en construir un ítem de manera completa) es un proceso más eficiente que concentrarse en construir las partes separadas de forma rápida.

			==Referencias==
			*<sup>1</sup>Poppendieck, M.; Poppendieck, T. (2003) ''Lean Software Development: An Agile Toolkit for Software Development Managers'', Addison Wesley.

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:Metodologías ágiles]]		[[Category:Metodologías ágiles]]

Smanager at 10:12, 26 April 2021

2021-04-26T10:12:53Z

← Older revision		Revision as of 12:12, 26 April 2021
Line 44:		Line 44:

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:~~Información complementaria: agilidad~~]]		[[Category:Metodologías ágiles]]

Smanager at 14:51, 18 October 2016

2016-10-18T14:51:28Z

← Older revision		Revision as of 16:51, 18 October 2016
Line 44:		Line 44:

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:~~Scrum II~~]]		[[Category:Información complementaria: agilidad]]

Smanager at 05:29, 16 June 2014

2014-06-16T05:29:47Z

Smanager: /* 1.Eliminar el desperdicio */

2014-06-16T05:28:23Z

1.Eliminar el desperdicio

← Older revision		Revision as of 07:28, 16 June 2014
Line 7:		Line 7:
	====1.Eliminar el desperdicio====		====1.Eliminar el desperdicio====
	Las actividades que no crean valor no sirven y deben ser eliminadas. Algunos ejemplos:		Las actividades que no crean valor no sirven y deben ser eliminadas. Algunos ejemplos:
	**Tareas que no fueron solicitadas por el cliente.		*Tareas que no fueron solicitadas por el cliente.
	**Sobre-documentación del proyecto.		*Sobre-documentación del proyecto.
	**Procesos de desarrollo que se ejecutan sin analizar su nivel de eficiencia o vigencia.		*Procesos de desarrollo que se ejecutan sin analizar su nivel de eficiencia o vigencia.
	**Un mayor número de líneas de código no siempre es mejor, y además requiere mayor esfuerzo de testeo y de mantenimiento.		*Un mayor número de líneas de código no siempre es mejor, y además requiere mayor esfuerzo de testeo y de mantenimiento.
	**Los errores, bugs y fallos del software son verdadero desperdicio que se debe reducir.		*Los errores, bugs y fallos del software son verdadero desperdicio que se debe reducir.


	====2.Construir con calidad====		====2.Construir con calidad====

← Older revision		Revision as of 07:29, 16 June 2014
Line 19:		Line 19:

	Algunos ejemplos de prácticas que se deben contemplar al hacer software.		Algunos ejemplos de prácticas que se deben contemplar al hacer software.
	*Técnicas como TDD (Test Driven Development) permiten que usuarios (clientes), programadores y tester definan claramente los requerimientos y confeccionen pruebas de aceptación antes de escribir el código. Ayuda a la comprensión de los programadores y mejora el entendimiento de los requerimientos.		*Técnicas como [[TDD]] (Test Driven Development) permiten que usuarios (clientes), programadores y tester definan claramente los requerimientos y confeccionen pruebas de aceptación antes de escribir el código. Ayuda a la comprensión de los programadores y mejora el entendimiento de los requerimientos.
	*El programador es responsable de su propio desarrollo. No debe esperar a que las pruebas o los procedimientos de aseguramiento de calidad descubran los errores.		*El programador es responsable de su propio desarrollo. No debe esperar a que las pruebas o los procedimientos de aseguramiento de calidad descubran los errores.
	*Fomentar el desarrollo de pruebas automatizadas.		*Fomentar el desarrollo de pruebas automatizadas.
	*Refactorización del código, para lograr simplicidad y eliminar duplicidades.		*Refactorización del código, para lograr simplicidad y eliminar duplicidades.



	====3.Compartir conocimiento====		====3.Compartir conocimiento====
	Conocer lo que necesita el cliente requiere dedicación y esfuerzo, y debe convertirse en el aspecto principal, porque desarrollar un producto que no es útil, es el mayor desperdicio.		Conocer lo que necesita el cliente requiere dedicación y esfuerzo, y debe convertirse en el aspecto principal, porque desarrollar un producto que no es útil, es el mayor desperdicio.
	Hacer software implica un proceso de aprendizaje: entender qué es lo que el cliente quiere y cómo entregar la mejor solución posible. El desarrollo incremental proporciona cuantiosa y frecuente retroinformación.		Hacer software implica un proceso de aprendizaje: entender qué es lo que el cliente quiere y cómo entregar la mejor solución posible. El desarrollo incremental proporciona cuantiosa y frecuente retroinformación.


	====4.Diferir el compromiso====		====4.Diferir el compromiso====
Line 40:		Line 37:
	Lean se basa en el respecto por las personas que son el elemento único y diferenciador de cada organización.		Lean se basa en el respecto por las personas que son el elemento único y diferenciador de cada organización.
	Deben estar suficientemente capacitadas y ser responsables de los procesos en los que intervienen, de modo que cuando resultan necesarios cambios y mejoras, cada persona colabora en su desarrollo.		Deben estar suficientemente capacitadas y ser responsables de los procesos en los que intervienen, de modo que cuando resultan necesarios cambios y mejoras, cada persona colabora en su desarrollo.


	====7.Optimizar el todo====		====7.Optimizar el todo====