Desarrollador: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
Los '''desarrolladores''' son | {{Meta-bok|min=4}} | ||
Los '''desarrolladores''' son los profesionales del equipo Scrum responsables de construir el [[incremento]] en cada [[sprint]]. A pesar del nombre, no se habla necesariamente de programadores: el término engloba a cualquier persona cuyo trabajo contribuye directamente a construir o desarrollar el incremento, independientemente de su disciplina (diseño, redacción, análisis, programación, QA…). | |||
== Características == | |||
* Es un '''equipo multifuncional''': todos los miembros trabajan de forma solidaria con responsabilidad compartida sobre el incremento. Si el equipo falla, falla el equipo; si tiene éxito, el éxito es del equipo. | |||
==Características== | * Puede haber miembros especialistas en áreas concretas, pero la responsabilidad del incremento recae sobre el conjunto, no sobre personas individuales. | ||
*Es un '''equipo multifuncional''' | * Se recomienda que el equipo tenga entre '''3 y 9 personas'''. Más allá de 9 resulta difícil mantener la comunicación directa y se manifiestan con más intensidad los roces habituales de la dinámica de grupos. | ||
* | * En el cómputo del número de desarrolladores '''no se cuentan''' ni el [[Scrum Master]] ni el [[propietario del producto]], a menos que trabajen activamente en el desarrollo del producto. | ||
*Se recomienda que el equipo | == Grupo de trabajo vs. equipo == | ||
*En el cómputo del número de desarrolladores no se cuentan ni | La diferencia entre un grupo de trabajo y un equipo es central en Scrum: | ||
== | * En un '''grupo de trabajo''', las personas tienen asignaciones específicas de responsabilidad individual y siguen pautas de ejecución. Cada quien responde de forma individual aunque trabajen en la misma organización. | ||
* Un '''equipo''' tiene espíritu de colaboración y un propósito común: conseguir el mayor valor posible para la visión del cliente. Los desarrolladores se autogestionan, se coordinan sin un gestor que asigne y controle el trabajo, participan en la toma de decisiones y comparten el objetivo del sprint y la responsabilidad del logro. | |||
*En un ''' | == El desarrollador en equipos con IA: evolución hacia el ''product builder'' == | ||
*Un ''' | La incorporación de herramientas de IA generativa —asistentes de código, agentes autónomos, generadores de especificaciones— está transformando el perfil del desarrollador. La guía ''Scrum en equipos con IA'' de Scrum Manager describe esta evolución con el término '''product builder''': | ||
* '''El valor se desplaza de implementar a orquestar:''' diseñar arquitecturas, escribir especificaciones que guíen a la IA, revisar y validar lo que genera, asegurar calidad y seguridad. | |||
==Véase también== | * '''Nuevas competencias necesarias:''' prompt engineering, context engineering y spec writing, además de las competencias técnicas tradicionales. | ||
* '''Responsabilidad ampliada:''' el product builder es responsable de que el código generado por IA cumpla la [[Definición de hecho|DoD reforzada]]: análisis estático, no-duplicación, seguridad y revisión cruzada. | |||
El equipo de developers en contextos con IA gestiona tres tipos de tareas: | |||
# '''Tareas automatizadas:''' realizadas por agentes de IA con supervisión humana mínima (generación de tests unitarios a partir de una spec, scaffolding de componentes). | |||
# '''Tareas humanas:''' trabajo que requiere creatividad, juicio o conocimiento contextual que la IA no puede aportar (estrategia de producto, diseño de experiencia de usuario, negociación con stakeholders). | |||
# '''Tareas de revisión e integración (R&I):''' trabajo humano dedicado a revisar, validar e integrar lo que genera la IA. Es el tipo más fácil de subestimar en la planificación y el que genera más cuellos de botella si no se reserva capacidad explícita para ello. | |||
<div class="bok-aviso"> | |||
Si se planifica el sprint solo con la velocidad de generación de la IA y no se reserva capacidad para la revisión humana, el sprint colapsa: todo el código está "generado" pero nadie lo ha podido revisar. Estimar las tareas de revisión e integración de forma explícita es lo que evita este cuello de botella. | |||
</div> | |||
== Error frecuente == | |||
<div class="bok-aviso"> | |||
'''Tratar "desarrollador" como sinónimo de "programador".''' En equipos multidisciplinares que construyen productos digitales, el rol de desarrollador puede incluir diseñadores UX, redactores técnicos, analistas de datos, especialistas en QA o en accesibilidad. Limitar la definición al perfil de programación es una de las causas por las que algunas disciplinas quedan fuera del equipo Scrum y siguen trabajando como departamentos separados, rompiendo la multifuncionalidad que hace eficaz al equipo. | |||
</div> | |||
== Recursos == | |||
<div class="bok-recurso"> | |||
📄 [https://www.scrummanager.com/files/scrum_master.pdf '''Scrum Master v.4.0''']<span class="detalle">Descarga gratuita · Scrum Manager</span> | |||
</div> | |||
== Véase también == | |||
<div class="bok-tags"> | |||
[[Roles]] [[Propietario del producto]] [[Scrum Master]] [[Definición de hecho]] [[Autoorganización]] [[Equipos autogestionados]] [[Agilidad técnica]] | |||
</div> | |||
<div class="bok-ecosistema"> | |||
<div class="texto"> | |||
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span> | |||
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span> | |||
</div> | |||
<div class="botones"> | |||
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div> | |||
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div> | |||
</div> | |||
</div> | |||
[[Category:Glosario de términos]] | [[Category:Glosario de términos]] | ||
[[Category:Scrum]] | [[Category:Scrum]] | ||
[[Category: | [[Category:Scrum_estandar]] | ||
Revision as of 14:52, 14 May 2026
Los desarrolladores son los profesionales del equipo Scrum responsables de construir el incremento en cada sprint. A pesar del nombre, no se habla necesariamente de programadores: el término engloba a cualquier persona cuyo trabajo contribuye directamente a construir o desarrollar el incremento, independientemente de su disciplina (diseño, redacción, análisis, programación, QA…).
Características
- Es un equipo multifuncional: todos los miembros trabajan de forma solidaria con responsabilidad compartida sobre el incremento. Si el equipo falla, falla el equipo; si tiene éxito, el éxito es del equipo.
- Puede haber miembros especialistas en áreas concretas, pero la responsabilidad del incremento recae sobre el conjunto, no sobre personas individuales.
- Se recomienda que el equipo tenga entre 3 y 9 personas. Más allá de 9 resulta difícil mantener la comunicación directa y se manifiestan con más intensidad los roces habituales de la dinámica de grupos.
- En el cómputo del número de desarrolladores no se cuentan ni el Scrum Master ni el propietario del producto, a menos que trabajen activamente en el desarrollo del producto.
Grupo de trabajo vs. equipo
La diferencia entre un grupo de trabajo y un equipo es central en Scrum:
- En un grupo de trabajo, las personas tienen asignaciones específicas de responsabilidad individual y siguen pautas de ejecución. Cada quien responde de forma individual aunque trabajen en la misma organización.
- Un equipo tiene espíritu de colaboración y un propósito común: conseguir el mayor valor posible para la visión del cliente. Los desarrolladores se autogestionan, se coordinan sin un gestor que asigne y controle el trabajo, participan en la toma de decisiones y comparten el objetivo del sprint y la responsabilidad del logro.
El desarrollador en equipos con IA: evolución hacia el product builder
La incorporación de herramientas de IA generativa —asistentes de código, agentes autónomos, generadores de especificaciones— está transformando el perfil del desarrollador. La guía Scrum en equipos con IA de Scrum Manager describe esta evolución con el término product builder:
- El valor se desplaza de implementar a orquestar: diseñar arquitecturas, escribir especificaciones que guíen a la IA, revisar y validar lo que genera, asegurar calidad y seguridad.
- Nuevas competencias necesarias: prompt engineering, context engineering y spec writing, además de las competencias técnicas tradicionales.
- Responsabilidad ampliada: el product builder es responsable de que el código generado por IA cumpla la DoD reforzada: análisis estático, no-duplicación, seguridad y revisión cruzada.
El equipo de developers en contextos con IA gestiona tres tipos de tareas:
- Tareas automatizadas: realizadas por agentes de IA con supervisión humana mínima (generación de tests unitarios a partir de una spec, scaffolding de componentes).
- Tareas humanas: trabajo que requiere creatividad, juicio o conocimiento contextual que la IA no puede aportar (estrategia de producto, diseño de experiencia de usuario, negociación con stakeholders).
- Tareas de revisión e integración (R&I): trabajo humano dedicado a revisar, validar e integrar lo que genera la IA. Es el tipo más fácil de subestimar en la planificación y el que genera más cuellos de botella si no se reserva capacidad explícita para ello.
Si se planifica el sprint solo con la velocidad de generación de la IA y no se reserva capacidad para la revisión humana, el sprint colapsa: todo el código está "generado" pero nadie lo ha podido revisar. Estimar las tareas de revisión e integración de forma explícita es lo que evita este cuello de botella.
Error frecuente
Tratar "desarrollador" como sinónimo de "programador". En equipos multidisciplinares que construyen productos digitales, el rol de desarrollador puede incluir diseñadores UX, redactores técnicos, analistas de datos, especialistas en QA o en accesibilidad. Limitar la definición al perfil de programación es una de las causas por las que algunas disciplinas quedan fuera del equipo Scrum y siguen trabajando como departamentos separados, rompiendo la multifuncionalidad que hace eficaz al equipo.
Recursos
📄 Scrum Master v.4.0Descarga gratuita · Scrum Manager
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.