feat: post sobre pair programing #17
Open
+78
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MaximilianoGarciaRoe
added
the
A Revisar
rovcode
reviewed
Jun 24, 2024
rovcode
reviewed
Jun 24, 2024
MaximilianoGarciaRoe
force-pushed
the
feat/pair-programing-flujo-completo
branch
from
f36ee2c to
13b32e7
Compare
MaximilianoGarciaRoe
force-pushed
the
feat/pair-programing-flujo-completo
branch
from
13b32e7 to
389c910
Compare
panchocorderos
approved these changes
Jul 1, 2024
|
|
||
| ## ¿Qué es el Pair Programming? | ||
|
|
||
| Primero, es importante explicar qué es el Pair Programming. Es una metodología de programación en la que dos programadores trabajan juntos en una misma tarjeta y en un mismo ordenador (o con videollamada usando la extensión de VScode [Live Share](https://code.visualstudio.com/learn/collaboration/live-share)). Uno de los programadores es el piloto, quien escribe el código, y el otro es el copiloto, quien revisa el código y piensa en la solución del problema. Ambos programadores intercambian roles constantemente. |
There was a problem hiding this comment.
Suggested change
| Primero, es importante explicar qué es el Pair Programming. Es una metodología de programación en la que dos programadores trabajan juntos en una misma tarjeta y en un mismo ordenador (o con videollamada usando la extensión de VScode [Live Share](https://code.visualstudio.com/learn/collaboration/live-share)). Uno de los programadores es el piloto, quien escribe el código, y el otro es el copiloto, quien revisa el código y piensa en la solución del problema. Ambos programadores intercambian roles constantemente. | |
| Primero, es importante explicar qué es el Pair Programming. Es una metodología de programación en la que dos programadores trabajan juntos en una misma tarea y en un mismo ordenador (o con videollamada usando la extensión de VScode [Live Share](https://code.visualstudio.com/learn/collaboration/live-share)). Uno de los programadores es el piloto, quien escribe el código, y el otro es el copiloto, quien revisa el código y piensa en la solución del problema. Ambos programadores intercambian roles constantemente. |
|
|
||
| ## ¿Cómo lo implementamos en Buk? | ||
|
|
||
| Como explicamos en un post anterior [Agilidad + Onboarding = Hold My Beer!](/2022/04/01/agilidad-onboarding-hold-my-beer.html), en Buk trabajamos con épicas, ahora llamadas misiones (suena más cool 😎). Estas misiones son un conjunto de tarjetas que tienen un objetivo en común, sacar una nuevo feature. Por ejemplo, una misión puede ser "Mejorar la velocidad de carga de la página de inicio", y esta misión tiene tarjetas como "Optimizar las imágenes de la página de inicio", "Optimizar el código de la página de inicio", etc. |
There was a problem hiding this comment.
``
Suggested change
| Como explicamos en un post anterior [Agilidad + Onboarding = Hold My Beer!](/2022/04/01/agilidad-onboarding-hold-my-beer.html), en Buk trabajamos con épicas, ahora llamadas misiones (suena más cool 😎). Estas misiones son un conjunto de tarjetas que tienen un objetivo en común, sacar una nuevo feature. Por ejemplo, una misión puede ser "Mejorar la velocidad de carga de la página de inicio", y esta misión tiene tarjetas como "Optimizar las imágenes de la página de inicio", "Optimizar el código de la página de inicio", etc. | |
| Como explicamos en un post anterior [Agilidad + Onboarding = Hold My Beer!](/2022/04/01/agilidad-onboarding-hold-my-beer.html), en Buk trabajamos con épicas, ahora llamadas misiones (suena más cool 😎). Estas misiones son un conjunto de tarjetas que tienen un objetivo en común, sacar un nuevo feature. Por ejemplo, una misión puede ser "Mejorar la velocidad de carga de la página de inicio", y esta misión tiene tarjetas como "Optimizar las imágenes de la página de inicio", "Optimizar el código de la página de inicio", etc. |
|
|
||
| Como dijimos, uno de los roles del champion es encargarse de la gestión a nivel técnico de toda la misión. Esto implica muchas responsabilidades y dificultades, porque no es fácil encargarse de la gestión de la misión por completo, además de pensar en cada tarjeta, cada criterio de aceptación, sus casos de prueba, etc. Esto resultaba muy agotador para el champion, generando incluso a veces la sensación de _burnout_ en él. | ||
|
|
||
| Esta forma en un principio nos funcionaba "bien", pero el champion perdía mucho tiempo en esto ademas no le daba tiempo para desarrollar alguna tarjeta de la mision que esta liderando. También, era solo una persona a cargo de resolver el problema en su totalidad (aunque había ayuda, en general, era solo uno), lo que aumentaba la probabilidad de cometer algún error. |
There was a problem hiding this comment.
Suggested change
| Esta forma en un principio nos funcionaba "bien", pero el champion perdía mucho tiempo en esto ademas no le daba tiempo para desarrollar alguna tarjeta de la mision que esta liderando. También, era solo una persona a cargo de resolver el problema en su totalidad (aunque había ayuda, en general, era solo uno), lo que aumentaba la probabilidad de cometer algún error. | |
| Esta forma en un principio nos funcionaba "bien", pero el champion perdía mucho tiempo en esto. Además, no le daba tiempo para desarrollar alguna tarjeta de la misión que estaba liderando. FInalmente, era solo una persona a cargo de resolver el problema en su totalidad (aunque había ayuda, en general, era solo uno), lo que aumentaba la probabilidad de cometer algún error. |
| Esta forma de hacer pair programming trae muchos beneficios: | ||
|
|
||
| - Se reduce el tiempo de entendimiento de la tarjeta, incluso de la misión completa, ya que la pareja que la va a desarrollar era la que la había creado. | ||
| - Mayor entendimiento del equipo de la misión, además de hacerlos mucho más parte de la solución del problema. |
There was a problem hiding this comment.
Suggested change
| - Mayor entendimiento del equipo de la misión, además de hacerlos mucho más parte de la solución del problema. | |
| - Mayor entendimiento del equipo de la misión, pues se hacen mucho más parte de la solución del problema. |
| - Se reduce el tiempo de desarrollo de la tarjeta, ya que al hacer la tarjeta por ellos mismos, ya vienen con una idea clarar de como desarrollarla . | ||
| - Se reduce el tiempo de revisión de la tarjeta, ya que al tener más contexto del problema, es más probable que tenga menos errores. | ||
| - El champion tenía más tiempo también para desarrollar en la misión, además de que tenía más tiempo para pensar en cómo resolver el problema de manera más macro, incluso teniendo tiempo de hacer algún pair con un compañero. | ||
| - Involucras a mas personas en la solución de una misión, porque antes el champion pensaba la solución solo, y con esta metodología hay más personas pensando en la solución. |
There was a problem hiding this comment.
Suggested change
| - Involucras a mas personas en la solución de una misión, porque antes el champion pensaba la solución solo, y con esta metodología hay más personas pensando en la solución. | |
| - Más personas se involucran en la solución de una misión, porque antes el champion pensaba la solución solo, y con esta metodología hay más personas pensando en la solución. |
|
|
||
| ## Bueno... ¿y esto funciona? | ||
|
|
||
| Como dije en un principio, todas estas prácticas siempre se tienen que adaptar para cada realidad de trabajo o equipo. Pero para ver que funciona hay que medirlas y nosotros las medimos y funcionó. A continuación, les muestro un gráfico de [Cycle Time](https://en.wikipedia.org/wiki/Cycle_time_(software)) de una disitintas tarjetas que se desarrollaron en pair programing con esta metodologia. |
There was a problem hiding this comment.
Suggested change
| Como dije en un principio, todas estas prácticas siempre se tienen que adaptar para cada realidad de trabajo o equipo. Pero para ver que funciona hay que medirlas y nosotros las medimos y funcionó. A continuación, les muestro un gráfico de [Cycle Time](https://en.wikipedia.org/wiki/Cycle_time_(software)) de una disitintas tarjetas que se desarrollaron en pair programing con esta metodologia. | |
| Como dije en un principio, todas estas prácticas siempre se tienen que adaptar para cada realidad de trabajo o equipo. Pero para ver que funciona hay que medirlas, y nosotros las medimos y funcionó. A continuación, les muestro un gráfico de [Cycle Time](https://en.wikipedia.org/wiki/Cycle_time_(software)) de disitintas tarjetas que se desarrollaron en pair programing con esta metodologia. |
|
|
||
| ## Conclusión | ||
|
|
||
| El pair programming es una gran práctica que se puede adaptar a cualquier realidad de trabajo. En este caso, lo adaptamos a un flujo completo de trabajo y nos dio muy buenos resultados. Siempre es importante probar nuevas formas de trabajo y adaptarlas a nuestras realidades, porque si uno no las prueba, nunca sabrá si le van a funcionar o no. Por otro lado uno siempre pueden mejorar los tiempos de entrega y la calidad del trabajo, pero para lograrlo hay que hacer cambios a la forma de trabajar. Es importante destacar que esta es una de las tantas formas que usamos en Buk para hacer un trabajo más ágil, eficiente y de excelencia, los resultados que mostramos no solo son por esta practica tambine son por muchas otras prácticas que tenemos en Buk, pero eso es tema para otro artículo 😏. |
There was a problem hiding this comment.
Suggested change
| El pair programming es una gran práctica que se puede adaptar a cualquier realidad de trabajo. En este caso, lo adaptamos a un flujo completo de trabajo y nos dio muy buenos resultados. Siempre es importante probar nuevas formas de trabajo y adaptarlas a nuestras realidades, porque si uno no las prueba, nunca sabrá si le van a funcionar o no. Por otro lado uno siempre pueden mejorar los tiempos de entrega y la calidad del trabajo, pero para lograrlo hay que hacer cambios a la forma de trabajar. Es importante destacar que esta es una de las tantas formas que usamos en Buk para hacer un trabajo más ágil, eficiente y de excelencia, los resultados que mostramos no solo son por esta practica tambine son por muchas otras prácticas que tenemos en Buk, pero eso es tema para otro artículo 😏. | |
| El pair programming es una gran práctica que se puede adaptar a cualquier realidad de trabajo. En este caso, lo adaptamos a un flujo completo de trabajo y nos dio muy buenos resultados. Siempre es importante probar nuevas formas de trabajo y adaptarlas a nuestras realidades, porque si uno no las prueba, nunca sabrá si le van a funcionar o no. Por otro lado uno siempre pueden mejorar los tiempos de entrega y la calidad del trabajo, pero para lograrlo hay que hacer cambios a la forma de trabajar. Es importante destacar que esta es una de las tantas formas que usamos en Buk para hacer un trabajo más ágil, eficiente y de excelencia. Los resultados que mostramos no solo son por esta práctica, también son por muchas otras prácticas que tenemos en Buk, pero eso es tema para otro artículo 😏. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://buk.atlassian.net/browse/TECHBLOG-4