¿Tiene un arquitecto de software un papel en agile, esp. Scrum? [cerrado]

Mi rol como arquitecto en Scrum incluye lo siguiente.

1. Picos técnicos proof pruebas de concepto how cómo lo haremos. ("Sería más simple si simplemente usaras la biblioteca SMTP directamente, ya envuelve las bibliotecas SMTP existentes; escribir tu propio wrapper alrededor de nuestro wrapper no ayuda mucho. Podemos agregar el método que desee.")

2. Coordinación entre los desarrolladores para adaptarse a la arquitectura prevista. ("Ummm... ¿por qué estás usando tus propias propiedades? archivo?"

3. Trabajar con los usuarios para priorizar el backlog apropiadamente. ("Estos tres están relacionados, si hacemos uno, obtenemos los otros dos a casi cero costo adicional.")

4. Trabajar con gerentes para costear el backlog. (No, un gerente de proyecto no puede hacer esto; no tienen la profundidad técnica. No, los programadores no pueden hacer esto, no tienen la visión general.)

5. Articulando por qué los nombres de los paquetes son de esa manera, y por qué el modelo de datos tiene esos función.

6. Encontrar las cosas que nos faltan y reordenar las prioridades del backlog por motivos técnicos ("Vamos a necesitar este sprint adicional para integrar [X], actualizar [Y] y reemplazar [Z] o nunca conseguiremos hacer esos sprints.")

El desarrollo ágil no significa desarrollo anarquista, todavía necesita ser coordonado para mantenerse mantenible en el tiempo.

Pero... Tal vez la mayor diferencia entre waterfall methodologis y agile methodologis, es que donde encontrarás una PERSONA de software achitect en la cascada, probablemente tendrás HABILIDADES de software achitect en desarrollos ágiles. Quiero decir, a medida que la gente está trabajando más ordenadamente para saber, hay una alta probabilidad de que las habilidades se vuelvan con el tiempo más compartidas el equipo del hoyo, lo cual es bueno.

Por supuesto, el arquitecto de software "líder" será el que mantenga el panorama general en su lugar y se asegure de que todos los bloques de construcción sean consistentes, pero no será el único que se refiera a lo largo del tiempo, ya que su conocimiento se enseñará a los demás.

Absolutamente sí, especialmente en proyectos medianos y grandes. Un arquitecto proporciona dirección técnica al tener una vista panorámica del proyecto y es responsable de evaluar y mitigar el riesgo técnico. Los desarrolladores tienden a tener un enfoque más estrecho y están menos expuestos a preocupaciones de alto nivel.

Totalmente.

El proceso de desarrollo/proyecto que ha mencionado es para construir las cosas que el arquitecto diseñó.

Así que la analogía de uso frecuente, el arquitecto diseña y planifica la ciudad, las carreteras, los edificios.

Los promotores construyen la ciudad, las carreteras, los edificios.

Los desarrolladores pueden utilizar cualquier sistema de gestión de proyectos que necesiten para conseguir la construcción, los coches en la carretera y el funcionamiento de la ciudad.

Al igual que la construcción los arquitectos están a la mano para supervisar el edificio con los ingenieros, así también debe el arquitecto de software estar a la mano para supervisar el proceso de desarrollo.

Ambos roles Arquitecto y Desarrollador están relacionados, pero pueden seguir un proceso diferente para lograr su propio programa de trabajo.

Absolutamente - un arquitecto es deseado y requerido en un equipo de scrum. Tal vez no escuchará eso de scrum / evangelistas ágiles, entrenadores, etc. pero cualquier dueño de producto experimentado le dirá eso. El papel de un arquitecto en scrum es muy importante.

Yo diría que ciertamente lo hay. A pesar de que el enfoque en agile es que los desarrolladores sean libres de dignificar su propio código, todavía hay una necesidad de un diseño general del programa a un nivel más alto que el que un desarrollador individual estaría trabajando.

Creo que esto es más una cuestión de habilidades que una cuestión de enfoque. Así que sí, puede tener un papel incluso si tiene ese título.

Sin embargo... Agile es mejor para proyectos pequeños, y los arquitectos especializados normalmente son más útiles en proyectos grandes.

La forma en que creo que con funcionaría bien, es si el Arquitecto establece la hoja de ruta general y define los módulos necesarios junto con los líderes del equipo de una manera Scrum. Sin embargo, entonces los líderes de equipo y sus equipos de Scrum hacen el desarrollo real.

Una especie de Scrum de dos etapas.

Incluso en una metodología Ágil, que puede no tener una jerarquía estricta, los programadores no van a ser iguales. Tendrá activistas experimentados, principiantes, aquellos que conocen el código base y el dominio del problema al revés y combinaciones de lo anterior.

Creo que aunque puede que no haya arquitectura "formal" en un proyecto realmente ágil, siempre hay preocupaciones arquitectónicas que deben abordarse y generalmente son los miembros del equipo más experimentados los que tendrán la conocimiento para abordar algunas de estas cosas.

Y también tenga en cuenta que el método de proyecto interno puede estar separado de la categoría de pago, por lo que un título puede ignorarse en gran medida "en el trabajo", por así decirlo.

+1 en la respuesta de S. Lott. El papel del arquitecto es importante, pero un enfoque ágil pide que el arquitecto baje de la torre de marfil y se ensucie las manos con el equipo. Esto puede ser difícil, ya que las torres de marfil a menudo conducen a la desconexión con el arte de crear el software.

Hemos estado practicando Scrum con éxito durante 1 año y lo que hemos experimentado es que hay dos cosas que deben equilibrarse: - La arquitectura del sistema es un "contrapeso" importante en un entorno de desarrollo puramente basado en características. La planificación estratégica y a medio plazo a nivel técnico tiene que ser hecho explícitamente como propietarios de productos se centran en las siguientes características que quieren ser implementadas (que por supuesto está bien por su parte) -Por otro lado ser realmente ágil significa que -Sistema Los arquitectos no deben sentarse en torres de marfil (como se mencionó en varios posts anteriores) y diseñar cosas que funcionan solo en teoría - El conocimiento debe ser distribuido para que cada equipo tenga suficientes habilidades arquitectónicas

Nuestra solución fue la siguiente (estamos trabajando en un entorno multi-equipo): Creamos un equipo virtual dirigido por el Arquitecto Principal (que no forma parte de un equipo Scrum). Cada equipo decide para cada tema que tiene que ser discutido ¿qué miembros quieren participar en el discusión. El equipo toma una decisión común. Si se necesita trabajo adicional, esto se realiza a través de una nueva historia de usuario o si es pequeño fuera de Scrum. Los miembros del equipo que se comprometieron a la decisión son responsables de comunicar la decisión y controlar su ejecución dentro de sus equipos.

Absolutamente. No hay razón por la que la arquitectura tenga que hacerse todo por adelantado de todos modos.

Sí, mucho

'Arquitecto' fue un término que software robó a la industria de la construcción con la intención de describir a alguien que supervisó el proyecto en su conjunto. Un arquitecto en la industria de la construcción es alguien que consulta a Ingenieros Estructurales sobre la apariencia y la "interfaz humana" del proyecto. Se puede trazar un paralelo más estrecho entre el "arquitecto" de la construcción y el "diseñador de UX" de un proyecto de software. El término que creo que describe más de cerca lo que un Software Arquitecto hace, es Ingeniero de Sistemas.'

Entonces, ¿cuál es el papel de la arquitectura de software en el desarrollo ágil? Para entender esto, es importante entender los principios del desarrollo de software ágil. Estos principios se pueden encontrar en el Manifiesto para el Desarrollo Ágil de Software aquí http://agilemanifesto.org

• Individuos e interacciones sobre procesos y herramientas

• Software de trabajo completo documentación

• Colaboración con los clientes en la negociación de contratos

• Responder a los cambios posteriores a un plan

Más información aquí: http://carlospliego.com/2016/10/08/agileSoftwareDevelopmentAndArchitecture/

En primer lugar: el equipo Scrum es auto-organizado. Eso significa que los roles de gestión técnica no se expresan tanto. Sí, el equipo puede elegir / invitar a un miembro para un rol. Pero en este rol de contratación también debería estar delegando al equipo. Yeah..it no lo es realmente.Además de la actividad del equipo son más fuertes en las partes de reunión y sprint, principalmente.La arquitectura técnica proporciona soluciones del nivel de epics y, al menos, requiere construir una hoja de ruta, aprobar tecnologías, retroalimentar a las partes interesadas y otros las operaciones específicas son nuestro ámbito temático. Además, los arquitectos técnicos actúan en los intereses de desarrollo corporativo de la empresa, especialmente para mantener SECO y otros principios de reutilización de soluciones,calidad y así sucesivamente.De sprints gruesos pueden ser y deben estar interrelacionados en la empresa multi equipo, que requiere también disposición a nivel de liderazgo. En estos aspectos, el arquitecto está en nombre de los grupos de interés, y, además, un elementos técnicos, limitaciones, patrón, tecnologías, que son el objeto de implementación, son una sección correcta en la historia del usuario. Básicamente, cuando es necesario, las latas de arquitecto escriben código en un sprint frames si es en interés de los negocios (esto depende en gran medida del código de liderazgo en una empresa concreta, no veo aquí nada que esté fuera de rango). Sin embargo, el papel definido del arquitecto es soluciones técnicas en nombre de las partes interesadas para llevar a cabo negocios para la traducción de definiciones técnicas y el control de directrices técnicas

No creo que exista la necesidad ya que la guía SCRUM escrita por los formantes originales de SCRUM Dr Jeff Sutherland y Ken Schwaber no menciona la necesidad de uno.