Diferencia entre revisiones de «Kent Beck»

(Fuentes)
 
(No se muestran 9 ediciones intermedias de 6 usuarios)
Línea 3: Línea 3:
 
|nombre completo = Kent Beck Martin Fowler
 
|nombre completo = Kent Beck Martin Fowler
 
|otros nombres =  
 
|otros nombres =  
|imagen =Kent.jpg
+
|imagen =Kent_Beck.jpg
 
|tamaño =  
 
|tamaño =  
 
|descripción =Creador de la Metodología ágil para el desarrollo de software.
 
|descripción =Creador de la Metodología ágil para el desarrollo de software.
Línea 36: Línea 36:
 
}}
 
}}
 
<div align=justify>
 
<div align=justify>
     
 
 
'''Kent Beck.''' Es uno de los creadores de la [[Metodología ágil]] para el [[desarrollo de software]] conocida como [[programación extrema]]. También creó, junto a [[Erich Gamma]] el [[framework]] de pruebas unitarias para [[Java]], [[JUnit]].
 
'''Kent Beck.''' Es uno de los creadores de la [[Metodología ágil]] para el [[desarrollo de software]] conocida como [[programación extrema]]. También creó, junto a [[Erich Gamma]] el [[framework]] de pruebas unitarias para [[Java]], [[JUnit]].
+
 
 
==Bibliografía==
 
==Bibliografía==
 
*[[Smalltalk Best Practice Patterns]] (ISBN 0-13-476904-X)
 
*[[Smalltalk Best Practice Patterns]] (ISBN 0-13-476904-X)
Línea 45: Línea 44:
 
*[[Planning Extreme Programming]] (ISBN 0-201-71091-9), con Martin Fowler
 
*[[Planning Extreme Programming]] (ISBN 0-201-71091-9), con Martin Fowler
  
==Reflexiones==
+
===Reflexiones===
 
{{Sistema:Cita|“El problema (de los proyectos de [[desarrollo de software]]) no es el cambio porque el cambio se va a producir; el problema, más bien, es la incapacidad de afrontar el cambio cuando se produce”.}}
 
{{Sistema:Cita|“El problema (de los proyectos de [[desarrollo de software]]) no es el cambio porque el cambio se va a producir; el problema, más bien, es la incapacidad de afrontar el cambio cuando se produce”.}}
  
Línea 54: Línea 53:
 
El [[software]] se tiene que desarrollar pensando en que va a cambiar y los medios puestos a disposición del sistema de información (o del conjunto de sistemas de información de una organización) deben poder dar respuesta a cuando esos cambios se produzcan, que a veces no sabremos cuando, pero sí sabemos que ocurrirán.
 
El [[software]] se tiene que desarrollar pensando en que va a cambiar y los medios puestos a disposición del sistema de información (o del conjunto de sistemas de información de una organización) deben poder dar respuesta a cuando esos cambios se produzcan, que a veces no sabremos cuando, pero sí sabemos que ocurrirán.
  
==Lineamientos principales ==
+
===Lineamientos principales===
 
+
====Valores====
===Valores===
 
 
Son conceptos universales, idealmente se aplican en todos los ámbitos. Es el camino para conducir el propósito a la práctica.
 
Son conceptos universales, idealmente se aplican en todos los ámbitos. Es el camino para conducir el propósito a la práctica.
  
===Communicación===
+
===Comunicación===
 
 
 
Es un factor importante para crear sentido de equipo y lograr cooperación efectiva. Cuando surgen problemas sorpresivos puede ayudar a resolverlos.
 
Es un factor importante para crear sentido de equipo y lograr cooperación efectiva. Cuando surgen problemas sorpresivos puede ayudar a resolverlos.
 
La mayor parte de los problemas son causados por carencia de conocimiento o por carencia de comunicación.
 
La mayor parte de los problemas son causados por carencia de conocimiento o por carencia de comunicación.
Línea 83: Línea 80:
 
Lograr satisfacción en un esquema de mejoras a cambio de, esperar la perfección al instante, es posible sólo acudiendo al [[Feedback]], que puede producirse de varias formas:
 
Lograr satisfacción en un esquema de mejoras a cambio de, esperar la perfección al instante, es posible sólo acudiendo al [[Feedback]], que puede producirse de varias formas:
  
*Escuchar distintas opiniones sobre una idea.
+
* Escuchar distintas opiniones sobre una idea.
*Como se ve el código una vez implementada la idea,
+
* Como se ve el código una vez implementada la idea,
*Si los tests fueron fáciles de escribir,
+
* Si los tests fueron fáciles de escribir,
*Si los tests ejecutaron,
+
* Si los tests ejecutaron,
*Cómo la idea funciona una vez que se hizo el [[deploy]].
+
* Cómo la idea funciona una vez que se hizo el [[deploy]].
  
 
Un equipo debe esforzarse en generar tanto [[Feedback]] como pueda, tan rápidamente como le sea posible. Tan pronto como se conoce la situación, tan pronto podremos adaptarnos.
 
Un equipo debe esforzarse en generar tanto [[Feedback]] como pueda, tan rápidamente como le sea posible. Tan pronto como se conoce la situación, tan pronto podremos adaptarnos.
  
 
===Coraje===
 
===Coraje===
 
 
Es la acción efectiva de enfrentar el temor.
 
Es la acción efectiva de enfrentar el temor.
  
Línea 99: Línea 95:
  
 
===Respeto===
 
===Respeto===
 
 
Este es el valor que subyace a los otros cuatro. [[XP]] funciona en un marco dónde cada integrante del equipo considera a cada otro y lo que está haciendo. La contribución de cada persona necesita respeto.
 
Este es el valor que subyace a los otros cuatro. [[XP]] funciona en un marco dónde cada integrante del equipo considera a cada otro y lo que está haciendo. La contribución de cada persona necesita respeto.
  
 
===Otros===
 
===Otros===
 +
* Seguridad.
 +
* Predicción.
 +
* Calidad de vida.
  
*Seguridad
+
===Las 4 reglas de Kent Beck para escribir código simple===
*Predicción
+
* Estar bien cubierto y satisfacer las aserciones de una buena batería de [[tests unitarios]].
*Calidad de vida
+
* Expresar las ideas que nosotros como programadores queremos expresar [[código auto-documentado]].
 +
* Decir cada cosa una única vez.
 +
* Evitar tener partes supérfluas: debe ser simple y satisfacer las necesidades actuales, sin pensar en lo que puede pasar en el futuro; y tener el mínimo número de clases y métodos teniendo en cuenta el [[Principio de Responsabilidad Única]].
  
==Las 4 reglas de Kent Beck para escribir código simple==
+
===Véase además===
 
+
* [http://www.exa.unicen.edu.ar/cursosposg/docs/MetodosAgiles.pdf exa.unicen.edu.ar]
*Estar bien cubierto y satisfacer las aserciones de una buena batería de [[tests unitarios]].
 
*Expresar las ideas que nosotros como programadores queremos expresar [[código auto-documentado]].
 
*Decir cada cosa una única vez.
 
*Evitar tener partes supérfluas: debe ser simple y satisfacer las necesidades actuales, sin pensar en lo que puede pasar en el futuro; y tener el mínimo número de clases y métodos teniendo en cuenta el [[Principio de Responsabilidad Única]].
 
 
 
==Véase además==
 
http://www.exa.unicen.edu.ar/cursosposg/docs/MetodosAgiles.pdf
 
  
 
==Fuentes==
 
==Fuentes==
 
+
* [http://www.extremeprogramming.org/ Programación]. Disponible en "www.extremeprogramming.org". Consultado el 8 de noviembre del 2011.
*[http://www.extremeprogramming.org/ Programación]. Disponible en "www.extremeprogramming.org". Consultado el 8 de noviembre del 2011.
+
* [http://alonsogarciapablo.com/blog/las-4-reglas-de-kent-beck-para-escribir-codigo-simple/ Las 4 Reglas de Kent beck]. Disponible en "alonsogarciapablo.com". Consultado el 8 de noviembre del 2011.
 
+
* [http://booksforgeeks.com/author/kent-beck Libros de Kent beck]. Disponible en "booksforgeeks.com". Consultado el 8 de noviembre del 2011.
*[http://alonsogarciapablo.com/blog/las-4-reglas-de-kent-beck-para-escribir-codigo-simple/ Las 4 Reglas de Kent beck]. Disponible en "alonsogarciapablo.com". Consultado el 8 de noviembre del 2011.
+
* [http://www.google.com.cu/search?tbm=isch&hl=es&source=hp&biw=1024&bih=576&q=Kent+beck&btnG=Buscar+im%C3%A1genes&gbv=2&oq=Kent+beck&aq=f&aqi=&aql=&gs_sm=s&gs_upl=0l0l0l946l0l0l0l0l0l0l0l0ll0l0 Imagen Kent beck].  Disponible en "www.google.com.cu". Consultado el 8 de noviembre del 2011.
 
+
[[Categoría:Científicos de Estados Unidos]][[Categoría:Ingenieros de Estados Unidos]][[Categoría:Informáticos de Estados Unidos]][[Categoría:Programadores de Estados Unidos]][[Categoría:Investigadores de Estados Unidos]]
*[http://booksforgeeks.com/author/kent-beck Libros de Kent beck]. Disponible en "booksforgeeks.com". Consultado el 8 de noviembre del 2011.
 
 
 
*[http://www.google.com.cu/search?tbm=isch&hl=es&source=hp&biw=1024&bih=576&q=Kent+beck&btnG=Buscar+im%C3%A1genes&gbv=2&oq=Kent+beck&aq=f&aqi=&aql=&gs_sm=s&gs_upl=0l0l0l946l0l0l0l0l0l0l0l0ll0l0 Imagen Kent beck].  Disponible en "www.google.com.cu". Consultado el 8 de noviembre del 2011.
 
[[Category:Personalidades]][[Category:Programador]][[Category:Informático]]
 

última versión al 10:11 17 nov 2017

Kent Beck
Información sobre la plantilla
Kent Beck.jpg
Creador de la Metodología ágil para el desarrollo de software.
NombreKent Beck Martin Fowler
NacimientoBandera de los Estados Unidos de América Estados Unidos
NacionalidadEstadounidense
OcupaciónProgramador

Kent Beck. Es uno de los creadores de la Metodología ágil para el desarrollo de software conocida como programación extrema. También creó, junto a Erich Gamma el framework de pruebas unitarias para Java, JUnit.

Bibliografía

Reflexiones

“El problema (de los proyectos de desarrollo de software) no es el cambio porque el cambio se va a producir; el problema, más bien, es la incapacidad de afrontar el cambio cuando se produce”.

Ahí, se encuentra uno de los grandes problemas de los proyectos de desarrollo de software y es el hecho de no enfocarse desde el punto de vista de que las especificaciones iniciales van a cambiar, ya sea porque el usuario no ha trasladado adecuadamente lo que quiere, porque el equipo de proyecto no ha interpretado correctamente lo que se le ha pedido o porque los requisitos y/o las prioridades han cambiado.

No es realista afrontar un proyecto de esa manera y sin embargo está a la orden del día encontrarnos con desarrollos que no tienen previsto un mantenimiento y eso es un error tanto aplicando metodologías ágiles como, sobre todo, aplicando metodologías clásicas.

El software se tiene que desarrollar pensando en que va a cambiar y los medios puestos a disposición del sistema de información (o del conjunto de sistemas de información de una organización) deben poder dar respuesta a cuando esos cambios se produzcan, que a veces no sabremos cuando, pero sí sabemos que ocurrirán.

Lineamientos principales

Valores

Son conceptos universales, idealmente se aplican en todos los ámbitos. Es el camino para conducir el propósito a la práctica.

Comunicación

Es un factor importante para crear sentido de equipo y lograr cooperación efectiva. Cuando surgen problemas sorpresivos puede ayudar a resolverlos. La mayor parte de los problemas son causados por carencia de conocimiento o por carencia de comunicación.

Si el problema tiene origen en la falta de conocimiento, no hay nada que pueda hacerse de antemano. Cuando encontremos un problema, preguntémonos si puede ser causado por una carencia de comunicación. Si es así, se debe analzar:

  • ¿Qué tipo de comunicación necesitamos para abordar el problema?
  • ¿Qué comunicación necesitamos para mantenernos fuera de esta situación en el futuro?

Simplicidad

Es el valor más intensamente intelectual. Se trata de pensar las cosas de forma de eliminar toda complejidad innecesaria.

Retroalimentación

Los cambios son inevitables y crean la necesidad del Feedback. Personalmente entiendo que es común el escenario en el cual la coyuntura nos condiciona a implementar funcionalidad de forma imperfecta en uno o varios aspectos. Esta situación crea una fuerte necesidad de Feedback, de otra forma se asume el riesgo de perpetuar esa imperfección y quizá ya nadie recuerde su existencia.

Existen fundamentalmente tres motivos que dificultan hacer las cosas bien al primer intento:

  • Al resolver un problema por primera vez, puede haber más de una solución que funcione o que la solución no sea totalmente clara.
  • Lo que es bueno hoy puede no serlo mañana.
  • Hacer algo con absoluta corrección podría insumir tanto tiempo que las circunstancias cambiantes futuras invaliden la solución de hoy, antes que se finalice.

Lograr satisfacción en un esquema de mejoras a cambio de, esperar la perfección al instante, es posible sólo acudiendo al Feedback, que puede producirse de varias formas:

  • Escuchar distintas opiniones sobre una idea.
  • Como se ve el código una vez implementada la idea,
  • Si los tests fueron fáciles de escribir,
  • Si los tests ejecutaron,
  • Cómo la idea funciona una vez que se hizo el deploy.

Un equipo debe esforzarse en generar tanto Feedback como pueda, tan rápidamente como le sea posible. Tan pronto como se conoce la situación, tan pronto podremos adaptarnos.

Coraje

Es la acción efectiva de enfrentar el temor.

A veces el coraje se manifiesta en forma de paciencia. Cuando uno sabe que existe un problema pero no lo conoce, se requiere coraje para esperar que se manifieste distintivamente. Hay que tener en cuenta que el coraje como valor principal, sin valores que contrabalanceen, puede ser peligroso, incluso puede jugar contra el espíritu del equipo. Pero cuando el coraje juega en confluencia con los otros valores es una herramienta poderosa.

Respeto

Este es el valor que subyace a los otros cuatro. XP funciona en un marco dónde cada integrante del equipo considera a cada otro y lo que está haciendo. La contribución de cada persona necesita respeto.

Otros

  • Seguridad.
  • Predicción.
  • Calidad de vida.

Las 4 reglas de Kent Beck para escribir código simple

  • Estar bien cubierto y satisfacer las aserciones de una buena batería de tests unitarios.
  • Expresar las ideas que nosotros como programadores queremos expresar código auto-documentado.
  • Decir cada cosa una única vez.
  • Evitar tener partes supérfluas: debe ser simple y satisfacer las necesidades actuales, sin pensar en lo que puede pasar en el futuro; y tener el mínimo número de clases y métodos teniendo en cuenta el Principio de Responsabilidad Única.

Véase además

Fuentes

  • Programación. Disponible en "www.extremeprogramming.org". Consultado el 8 de noviembre del 2011.
  • Las 4 Reglas de Kent beck. Disponible en "alonsogarciapablo.com". Consultado el 8 de noviembre del 2011.
  • Libros de Kent beck. Disponible en "booksforgeeks.com". Consultado el 8 de noviembre del 2011.
  • Imagen Kent beck. Disponible en "www.google.com.cu". Consultado el 8 de noviembre del 2011.