Catálogo de gestión de desarrollo ágil Gestión de desarrollo
ágil
1. Antecedentes
2. El origen de la gestión de desarrollo ágil
2.1 Los documentos se pueden guardar y usted puede guardar
2.2 La intención original de la gestión
ágil 3. Principios ágiles
4. Desarrollo en cascada y similitudes y diferencias de desarrollo ágil
5. Método ágil
5.1 DevOps
5.1.1 Back-end webApi CI / DI workflow
5.1.2 Front-end CI / DI workflow
5.2 Scrum
6 Proceso ágil implementado por nuestra empresa
6.1 Características: Desarrollo iterativo
6.2 Gestión de tareas
6.2.1 Gestión de la demanda
6.2.1.1 Única vez Gestión de requisitos
6.2.2 Gestión de defectos
6.3 Herramientas de gestión unificadas
6.4 Rol
6.5 Proceso
6.6 Definición final de desarrollo ágil
6.7 Propósito
6.8 Video de capacitación
1. Antecedentes
En el desarrollo de software moderno, un proyecto de software se divide en múltiples subproyectos en la etapa inicial de construcción, cada subproyecto Los resultados del proyecto han sido probados y tienen las características de visualización, integración y uso operativo. En otras palabras, se trata de dividir un proyecto grande en varios proyectos pequeños que están interconectados, pero que también pueden ejecutarse de forma independiente y completarse por separado Durante este proceso, el software siempre está en un estado utilizable. Nació el concepto de gestión ágil del desarrollo.
2. El origen de la gestión ágil del desarrollo
En 2001, un grupo de maestros se reunió en Utah, EE.UU., para intercambiar ideas y crear un manifiesto ágil que establecía 5 valores, como se muestra en la siguiente figura.
2.1 La documentación puede guardar la
descripción de los documentos de atributos de clase y los documentos de descripción de la interfaz (generados automáticamente por swagger). Y algunos documentos valiosos, como documentos de planos de diseño, documentos de sistemas de arquitectura, etc., siguen siendo necesarios.
2.2 La intención original de
Agile La intención original de Agile es sugerir que adoptemos una serie de métodos para hacer que nuestro trabajo de I + D sea más eficiente, flexible y ordenado. Por lo tanto, enfatiza la iniciativa de los miembros del equipo y la cooperación mutua, y presta más atención a responder a los cambios.
3. El principio de ágil
Nuestra principal prioridad es satisfacer a los clientes mediante la entrega de software valioso lo antes posible y de forma continua.
Incluso en las últimas etapas de desarrollo, los cambios en los requisitos son bienvenidos. Los procesos ágiles utilizan el cambio para crear una ventaja competitiva para los clientes.
Entregue software que funcione con regularidad. El intervalo de entrega puede variar desde unas pocas semanas hasta varios meses. Cuanto más corto sea el intervalo de entrega, mejor.
Durante todo el período de desarrollo del proyecto, el personal comercial y los desarrolladores deben trabajar juntos todos los días.
Desarrolle proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo.
Dentro del equipo, la forma más efectiva y eficiente de transmitir información es la conversación cara a cara.
El software de trabajo es la métrica de progreso principal.
Los procesos ágiles promueven la velocidad del desarrollo sostenible. Las personas responsables, los desarrolladores y los usuarios deben poder mantener una velocidad de desarrollo constante a largo plazo.
La atención constante a las excelentes habilidades y al buen diseño mejorará la agilidad.
La simplicidad, el arte de maximizar el trabajo inacabado, es fundamental.
La mejor arquitectura, requisitos y diseño provienen de equipos autoorganizados.
A intervalos regulares, el equipo reflexionará sobre cómo trabajar de manera más eficaz y luego ajustará su comportamiento en consecuencia.
A medida que cambien los tiempos, parte del contenido interno cambiará. Por ejemplo, la división social del trabajo en el punto 4 se está volviendo cada vez más detallada. El requisito es actualizar la plataforma de teambition a través de herramientas a través de la preventa con los clientes (nuestra empresa utiliza la plataforma TeamBition, Tencent TPAD también es una excelente herramienta de plataforma).
El quinto punto no es muy comprensible.
El punto 6 también se logra a través de la plataforma teambition. Nuestra empresa se comunica principalmente con desarrolladores y probadores en Wuhan y Hangzhou. Debido a que Internet nos permite interactuar de forma remota, gracias por esta mejor época.
Otros puntos deben tenerse en cuenta y practicar continuamente.
4. Las similitudes y diferencias entre el desarrollo en cascada y el desarrollo ágil
Desarrollo ágil, segmentación de requisitos, con foco en la gestión del ciclo de vida de cada requisito. Las demandas se plantean en cualquier momento, se retiran en cualquier momento y se modifican en cualquier momento.Cada demanda tiene, análisis, codificación de diseño, pruebas, gestión de defectos. Los gerentes de producto pueden revisar en línea (combinado con DevOps: CI / DI), abrir nuevos requisitos y finalizar requisitos en cualquier momento. El desarrollo de cascada solo puede esperar hasta que la función esté completamente desarrollada para su revisión, como menos iteraciones.
5. Un método ágil
puede denominarse método ágil siempre que sea una metodología que se ajuste a valores y principios ágiles.
5.1 DevOps
Nuestra empresa adopta el método DevOps. Los desarrolladores front-end y back-end a través del código iterativo continuo, la implementación de integración continua CI / DI a través de gitlab, los probadores continúan probando los comentarios y a través de la gestión de ciclo completo de requisitos y defectos de teambton para lograr una rápida finalización de los cambios de demanda Y desarrollo y reparación de defectos, etc.
5.1.1 Flujo de trabajo CI / DI del webApi en segundo plano
5.1.2 Flujo de trabajo CI / DI de front-end
En resumen, integración continua a través de DevOps CI / DI para mejorar la eficiencia del desarrollo ágil. Se puede decir que DevOps CI / DI es el método del Fajia, y el pensamiento ágil es el método del Fajia (reglas, abstracción del pensamiento o taoísmo).
5.2 Scrum
Scrum no es todo ágil, es solo uno de los métodos ágiles.
Scrum es 3355.
¿Qué es 3355?
Los primeros 3 representan 3 roles, a saber, Product Owner (Product Owner), Scrum Master y Team;
El segundo 3 representa 3 artefactos, a saber, Product Backlog (lista de tareas pendientes del producto), Sprint Backlog (lista de tareas pendientes de iteración) e Incremento de producto (incremento de producto);
Los terceros 5 representan 5 eventos, que es lo que todos sienten más profundamente, a saber, Sprint Planning (reunión de planificación de iteraciones), Daily Scrum (reunión diaria de pie), Sprint Review (reunión de revisión de iteraciones), Sprint Retrospective (reunión de revisión de iteraciones) , Refinamiento del Backlog (reunión de clasificación del Backlog del producto);
El cuarto 5 representa 5 valores, a saber, compromiso, concentración, apertura, respeto y coraje;
Nuestra empresa no implementa este método.
6 Proceso ágil implementado por nuestra empresa
6.1 Características: El desarrollo iterativo
debe completar los siguientes cinco pasos en secuencia en cada iteración.
Análisis de requisitos (análisis de requisitos)
diseño (diseño)
codificación (codificación)
pruebas (pruebas)
implementación y evaluación (implementación / evaluación)
6.2 Gestión de tareas
6.2.1 Gestión de la demanda
PO (Product Owner): Dueño del producto, el núcleo es el producto, el demandante puede ser gerente de producto, gerente de proyecto, probador (para nuestra empresa), usuario final, integrador, agente;
Requisitos de modernización: Los requisitos cambian más rápido. Se plantean en la mañana y se cambian en la tarde. Agile es cambiar los requisitos de manera más conveniente. Nuestra empresa es muy adecuada para el desarrollo ágil.
Gestión de la demanda: la clave es anotarlo y escribirlo en la combinación de productos unificada. El proceso de escritura será completo y rastreable. El documento de requisitos, al igual que el código desarrollado, debe tener un registro histórico completo que se pueda rastrear hasta cuándo y quién realizó los cambios, de modo que se puedan contabilizar todos los cambios de requisitos.
6.2.1.1 ¿Cuándo comienza una gestión de demanda específica ?
¿Cuando terminará?
¿Quién está a cargo?
¿A quién se entregará una vez finalizado? @
Ciclo de vida de los requisitos, cobertura de ciclo completo, gestión del estado de los requisitos
¿Qué es el ciclo completo? Es decir, la circulación de todos los estados de demanda y el cese de la circulación.
Definición de estado agregada
6.2.2 Gestión de
defectos Los defectos son errores, que son establecidos por los probadores después de pasar por los casos de prueba y asignados a los desarrolladores correspondientes que completaron las tareas antes. Los desarrolladores están ocupados con su trabajo, retroalimentan la situación real al líder del equipo y luego los asignan a otros por el líder del equipo de software. Desarrollador.
El proceso de asignación es muy importante @tester
es fundamental. La
retroalimentación es muy importante. El
líder del equipo de software debe planificar la
tarea de acuerdo con la prioridad.
La reparación de un defecto se convierte en una iteración.
6.3 Una herramienta de gestión unificada
Nuestra empresa adopta la plataforma TeamBition
Los
requisitos del ciclo completo , el desarrollo, las pruebas, la reparación de defectos, la cobertura completa iterativa, el gráfico de
desarrollo de
tareas eficiente , el estado del proyecto, la división de responsabilidades de los miembros son claros de un vistazo, reducen los costos de comunicación, la
acumulación de
documentos relevantes se archivan con el proyecto, no es fácil de perder, adecuado para que los nuevos colegas intervengan en la
tarea Kanban para
permitir a los líderes de la empresa Las capas, los productos y los equipos visualizan todo el estado y el ciclo de la tarea.
DevOps
combinado con CI / DI, los gerentes de productos y los gerentes de proyectos pueden ver páginas web en cualquier momento, modificar los requisitos en cualquier momento, aumentar el número de iteraciones y reducir los costos de comunicación. Dado el
código de la URL de acceso
, el evaluador establece la URL de gitlab
. Y toda la información de notificación puede ser notificada por la aplicación móvil teambition.
6.4 Rol: el
Product Owner es el
principal responsable de determinar la función del producto y cumplir con los estándares requeridos, y tiene el poder de aceptar o rechazar los resultados del trabajo del equipo de desarrollo.
- El gestor de procesos (Scrum Master)
aclara las necesidades en cada momento, gestiona cada cambio en la demanda, el motivo del cambio e implementa el cambio.
-El equipo de desarrollo (Scrum Team)
organiza las tareas de acuerdo con la prioridad de la tarea
-Después de que los
requisitos del probador estén claros, los documentos de aceptación se pueden escribir para los requisitos. Proceso de prueba, escribir casos de prueba.
6.5 Procesar
la lista de requisitos del producto, que es responsabilidad de la OP;
celebrar reuniones de revisión para eliminar requisitos innecesarios y determinar los requisitos que deben desarrollarse;
tareas de distribución de requisitos simples, prototipos de dibujo de requisitos complejos;
tareas de asignación; la entrega de
pruebas
puede generar un 20% del 80% de beneficios Función;
iteración continua (desarrollo iterativo), entrega continua (entrega incremental);
6.6 la definición final de
desarrollo ágil. El desarrollo ágil toma la evolución de las necesidades del usuario como el núcleo y adopta un enfoque iterativo y gradual para el desarrollo de software.
6.7 Propósito
Gestionar bien los requisitos y mejorar la eficiencia del desarrollo
6.8 Video de
entrenamiento Grabación de video de entrenamiento