Agile development-based project iteration risk real-time early warning and self-adaptive adjustment method

Abstract

This invention relates to the field of software project management technology and discloses a method for real-time early warning and adaptive adjustment of project iteration risks based on agile development. The method includes: collecting multi-dimensional process data of agile projects and preprocessing it; extracting multi-dimensional risk characteristic indicators, performing standardization processing and feature selection; constructing a risk identification model and a risk identification rule base, identifying risk types and levels, setting early warning thresholds and generating push messages; constructing an adjustment strategy library, matching and evaluating candidate strategies from the library, performing constraint checks and optimization selection, and formulating an execution plan; monitoring the comparison of data before and after adjustment, quantitatively evaluating the adjustment effect and analyzing its effectiveness, and updating the risk identification model; establishing a team collaboration mechanism and a risk management knowledge base, and obtaining visualized display and knowledge management results. This invention achieves real-time monitoring, intelligent early warning, and adaptive adjustment of risks in agile projects, improving the predictability and success rate of project delivery.

Description

Technical Field

[0001] This invention relates to the field of software project management technology, and more specifically, to a method for real-time early warning and adaptive adjustment of project iteration risks based on agile development. Background Technology

[0002] Agile development methodologies, emphasizing rapid iteration, continuous delivery, and flexibility in responding to change, have become mainstream practices in the software development field. In agile projects, iteration cycles are typically short, requirements change frequently, and team collaboration is close. While these characteristics improve responsiveness, they also bring unique risk management challenges. Traditional project risk management methods rely primarily on human experience and periodic reviews, making them ill-suited to the fast pace and high variability of agile development.

[0003] Current risk management practices in agile projects mainly suffer from the following problems: risk identification relies on the project manager's personal experience, lacks systematic data support, and is prone to subjective bias and omissions; risk monitoring often lags behind the occurrence of problems, and by the time problems are discovered in retrospective meetings, the room for adjustment is already limited; the selection of risk response measures lacks scientific basis, making it difficult to assess the effectiveness and cost of different strategies; and the risk management experience accumulated by the team is difficult to effectively consolidate and reuse, with each project repeating similar mistakes.

[0004] With the improvement of project management toolchains and data collection capabilities, agile projects generate a large amount of process data, including requirement change records, code commit history, build and test results, defect tracking information, etc. This data contains rich information about the project's operational status and potential risks, but effective analysis and utilization methods are lacking. How to fully explore the value of this multi-dimensional process data, establish a real-time risk warning mechanism, and provide intelligent adjustment suggestions has become a key requirement for improving agile project management. Summary of the Invention

[0005] This invention provides a method for real-time early warning and adaptive adjustment of project iteration risks based on agile development, which solves the technical problems of lack of systematic data support and lack of scientific basis for the selection of risk response measures in related technologies.

[0006] This invention provides a method for real-time early warning and adaptive adjustment of project iteration risks based on agile development, including: Collect multidimensional process data from agile projects and preprocess it to obtain a standardized data stream; Based on standardized data streams, multi-dimensional risk feature indicators are extracted, and standardized processing and feature selection are performed to obtain a multi-dimensional risk feature set. Based on a multidimensional risk feature set, a risk identification model and a risk identification rule base are constructed to identify risk types and levels, set early warning thresholds, and generate early warning information in real time to obtain risk early warning information. Based on risk warning information, candidate strategies are matched and evaluated from the adjustment strategy library. After constraint checks and optimization selection, an execution plan is formulated to obtain a risk response and adjustment solution. Based on the risk response adjustment plan, monitor the comparison of data before and after the adjustment, quantify the adjustment effect and analyze its effectiveness, update the risk identification model, and obtain the adjustment effect evaluation results; Based on standardized data flow, risk warning information, risk response and adjustment plans, and adjustment effect evaluation results, visualization and interactive simulation are performed, a team collaboration mechanism and a risk management knowledge base are established, and visualization and knowledge management results are obtained.

[0007] In a preferred embodiment, the step of obtaining the standardized data stream includes: Establish data connection channels with the requirements management system, version control system, continuous integration platform, defect tracking system, and team collaboration platform; An event-driven data collection strategy is adopted, with real-time collection of state change events triggered by events and periodic collection of cumulative indicators. The collected heterogeneous raw data is cleaned by using a unique identifier deduplication algorithm to remove duplicate records, statistical detection methods to identify and correct outliers, and a completion strategy to process missing data. A standardized data table structure is defined using a unified data model; A sliding time window mechanism is used for data aggregation, and the aggregated metrics within the window are calculated.

[0008] In a preferred embodiment, the extraction of multi-dimensional risk feature indicators includes: Extract the risk characteristics of demand change, calculate the frequency of demand change, the rate of demand change, and the concentration of change time. Use graph analysis algorithm to obtain the propagation depth and breadth of change, and use time series analysis method to obtain the trend characteristics of demand change. Extract schedule deviation risk characteristics, calculate the deviation between task completion rate and ideal completion rate, task delay degree, delayed task ratio, identify critical path task status, and calculate burn-down chart deviation; Extract code quality risk characteristics, count the number of defects and classify them according to severity level, and calculate defect density, code complexity, code duplication rate and code review pass rate; Extract test coverage and quality assurance features, calculate test coverage rate and test case pass rate, statistically analyze test failure frequency and failure mode, and calculate defect repair time and defect re-opening rate; Extract team collaboration and resource load characteristics, calculate team member load distribution and load balance, analyze communication records to count response time, count personnel changes, and identify the number and duration of blocked tasks. Extract external dependency risk characteristics, identify external dependencies and record dependency type, planned delivery time, and actual delivery time, calculate dependency latency rate, count interface call failure rate, and track external dependency change events.

[0009] In a preferred embodiment, the construction of the risk identification model and risk identification rule base, and the identification of risk types and levels, includes: The training dataset is constructed by extracting feature vectors from historical iterations as input samples and using actual risk events as labels. A multi-label classification method is used to identify risk types, an ensemble learning algorithm is used to build a base classifier, and model fusion technology is used to combine the prediction results of multiple base classifiers; a multi-classification or regression method is used to predict risk levels; and cross-validation is used to evaluate model performance. Based on the experience of domain experts and the analysis of historical risk cases, the structure of the rules is defined as a condition part and a conclusion part. The association rule mining method is used to mine rules that meet the preset minimum support and preset minimum confidence. Specialized rule subsets are constructed for different risk types, and priority and confidence are set for the rules.

[0010] In a preferred embodiment, setting the warning threshold and generating warning information in real time includes: Define an early warning level system, and set a threshold range for risk scores for each risk type and each early warning level; A dynamic threshold adjustment mechanism based on time dimension is introduced; an early warning mechanism based on trend judgment is introduced, which triggers an early warning when the risk score continues to rise over multiple consecutive time windows and the cumulative increase exceeds the preset increase threshold. When the risk score exceeds the warning threshold or the trend warning rule is triggered, a warning message is automatically generated. Based on the warning level and risk type, a notification strategy is adopted to determine the recipients and channels of the warning message.

[0011] In a preferred embodiment, the construction of the adjustment strategy library based on risk warning information, which involves matching and evaluating candidate strategies from the adjustment strategy library, includes: Define a structured representation of the adjustment strategy, including strategy identifier, strategy name, risk type, warning level, preconditions, strategy action, expected effect, implementation cost, and constraints; For schedule risks, construct a set of schedule adjustment strategies; for quality risks, construct a set of quality improvement strategies; for requirement change risks, construct a set of requirement control strategies; for resource risks, construct a set of resource allocation strategies; and for external dependency risks, construct a set of dependency management strategies.

[0012] In a preferred embodiment, the step of obtaining the risk response adjustment plan includes: Based on the risk type and warning level in the early warning information, applicable strategies are selected from the adjustment strategy library, the preconditions of the strategies are checked, and the case reasoning method is used to retrieve iterative cases with similar risk characteristics in the historical data warehouse to generate a candidate strategy set. For each candidate strategy, the expected results of strategy implementation are obtained by simulation, and the comprehensive score of each candidate strategy is obtained by multi-objective optimization algorithm, resulting in a list of recommended strategies. Check resource constraints, technical constraints, business constraints, and team constraints. Remove strategies that do not meet the constraints from the recommendation list or mark them as infeasible, and generate the final set of feasible strategies. Present a set of feasible strategies to project decision-makers, and develop an implementation plan for the selected strategies.

[0013] In a preferred embodiment, the step of obtaining the adjustment effect evaluation result includes: Record the current moment as the adjustment baseline time point when the adjustment strategy begins to be executed, and save a complete snapshot at this time; After the adjustment was implemented, data was collected, and the changes in various indicators were obtained using the differential analysis method. Calculate risk mitigation effectiveness indicators, schedule improvement effectiveness indicators, resource utilization efficiency indicators, and adjustment cost indicators; Based on the analysis of key factors for successful adjustment strategies, update the success rate and recommendation priority of the corresponding strategies in the adjustment strategy library; The adjusted cases are used as new training samples to update the parameters of the risk identification model.

[0014] In a preferred embodiment, the visualization and interactive simulation include: Design a dashboard view that uses different colored areas to represent different risk types, uses radar charts to show the overall situation of multi-dimensional risks, and uses a timeline to show warning events; It provides a strategy comparison matrix; provides strategy simulation functionality; and provides multi-strategy combination functionality to evaluate the overall effect and potential conflicts of the combination scheme.

[0015] In a preferred embodiment, the establishment of the team collaboration mechanism and risk management knowledge base includes: Create a dedicated risk management channel or space in the team collaboration platform to automatically push early warning messages, adjustment plans, and execution progress; Provides structured risk discussion templates; supports online meeting integration, automatically initiating risk response meeting invitations when an alert is triggered; establishes a risk response responsibility matrix; Establish a risk management knowledge base to structurally store all risk events, early warning records, adjustment cases, and effectiveness evaluations; The system tags and categorizes cases in the risk management knowledge base; supports case retrieval based on similarity; and extracts best practices and lessons learned in risk management.

[0016] The beneficial effects of this invention are as follows: Through real-time collection and standardized processing of multi-dimensional process data, a risk characteristic system covering multiple dimensions such as requirement changes, schedule deviations, code quality, test coverage, team collaboration, and external dependencies was established. A risk identification mechanism integrating machine learning models and expert rules was adopted, enabling accurate identification and severity assessment of different types of risks, thus improving the timeliness and accuracy of risk warnings.

[0017] By constructing an adjustment strategy library and combining it with a multi-objective optimization evaluation method, this invention can automatically match and recommend optimal response strategies for identified risks, supporting interactive simulations and decision support, enabling project teams to quickly formulate and implement effective adjustment plans. The quantitative evaluation of adjustment effects and the incremental model update mechanism form a closed loop of continuous improvement, allowing the system's risk management capabilities to continuously improve with the accumulation of project experience. Visualization and knowledge management functions promote team collaboration and experience transfer, transforming individual experience into organizational knowledge assets. This invention effectively reduces the risk of iteration failure in agile projects, improves the predictability and success rate of project delivery, and provides an intelligent decision support tool for agile project management. Attached Figure Description

[0018] Figure 1 This is the main flowchart of the present invention; Figure 2 This is a detailed flowchart of the present invention. Detailed Implementation

[0019] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0020] At least one embodiment of the present invention discloses a method for real-time early warning and adaptive adjustment of project iteration risks based on agile development, such as... Figures 1 to 2 As shown, it includes: Step 1: Collect multidimensional process data from the agile project and preprocess it to obtain a standardized data stream; Specifically, the following steps are included: Step 1.1, Data source access and acquisition configuration; Based on the toolchain used in agile projects, methods such as API calls, database connections, and message queue subscriptions are employed to establish data connection channels with the requirements management system, version control system, continuous integration platform, defect tracking system, and team collaboration platform.

[0021] The requirements management system uses JIRA or similar tools to obtain information such as user story creation time, status change history, estimated work hours, actual work hours, priority changes, and relationships via REST API. The version control system uses Git to obtain information such as code commit records, committer information, modified file list, changes in lines of code, and branch merging status via Git API or hook mechanism. The continuous integration platform uses Jenkins or GitLab CI to obtain information such as build trigger time, build status, test execution results, code coverage, and static analysis reports via Webhook or API. The defect tracking system obtains information such as defect creation time, severity, status transition, fix time, and number of restarts. The team collaboration platform uses Slack or WeChat Work to obtain information such as communication frequency, response time, and discussion topics.

[0022] Based on the real-time requirements of data acquisition, an event-driven acquisition strategy is adopted, resulting in an acquisition mechanism that combines real-time data streams triggered by events with periodic data snapshots collected at fixed time intervals. For state change events, such as task status changes, code commits, and build completions, real-time acquisition is performed using event triggering. For cumulative metrics such as team load, technical debt, and dependencies, periodic acquisition is conducted hourly or daily.

[0023] Step 1.2, Data cleaning and format standardization; Based on the collected heterogeneous raw data, a data cleaning process was adopted to obtain a standardized dataset that removes duplicate records, corrects erroneous data, and fills in missing values.

[0024] For handling duplicate data, a unique identifier deduplication algorithm is used to obtain deduplicated data based on unique identifiers such as task ID, submission hash value, and defect number. For outliers, statistical detection methods are used to identify values ​​that exceed reasonable ranges, such as a single code submission exceeding 10,000 lines, or task time estimates being 0 or negative. Outliers are marked and corrected or removed based on context information.

[0025] For handling missing data, multiple completion strategies are employed. When task estimated work hours are missing, the historical average value of similar tasks is used for filling in the gaps. When code committer information is missing, it is completed by tracing back through Git logs. When test coverage data is missing, the most recent valid value is used for forward filling. If critical fields are consistently missing and cannot be reasonably completed, the record is marked as unavailable.

[0026] Based on the cleaned data, a unified data schema is defined to obtain a standardized data table structure. The task data table is defined, including fields such as task identifier, task type, creation time, planned start time, actual start time, planned completion time, actual completion time, estimated working hours, actual working hours, status, priority, responsible person, and list of dependent tasks; the code commit data table is defined, including fields such as commit hash, commit time, committer, branch name, number of modified files, number of new lines, number of deleted lines, and commit message; the build test data table is defined, including fields such as build number, trigger time, completion time, build status, total number of test cases, number of passed cases, number of failed cases, number of skipped cases, and code coverage; the defect data table is defined, including fields such as defect number, creation time, discovery stage, severity level, status, assigned to, repair time, and associated task.

[0027] Step 1.3, Time window segmentation and data aggregation; Based on the standardized data table structure and iteration cycle characteristics, a sliding time window mechanism is used to obtain a data view aggregated by time period.

[0028] With an iteration cycle of 2 weeks, a multi-granularity time window segmentation strategy is adopted. For indicators that require high-frequency monitoring, an hourly time window is used, generating aggregated data once per hour; for daily monitoring indicators, a daily time window is used, generating aggregated data once per day; and for trend analysis indicators, a 3-day or 1-week time window is used to capture medium-term trends.

[0029] Based on a time window, aggregate functions are used to calculate statistical characteristics within the window, resulting in aggregate metrics such as counts, sums, averages, maximums, minimums, standard deviations, and rates of change. For example, within a daily window, count metrics such as the number of tasks completed that day, the number of new defects, the number of code commits, and the number of build failures are calculated; the task completion rate is calculated as the number of completed tasks divided by the planned number of tasks; the average task latency is calculated as the average of the actual completion time minus the planned completion time; and the rate of change in code commit frequency is calculated as the ratio of the number of commits in the current window to the number of commits in the previous window.

[0030] Step 1.4, cross-iteration historical data management; Based on real-time data from the current iteration and archived data from historical iterations, data warehouse technology is used to obtain a unified data storage that supports cross-iteration querying and analysis.

[0031] Establish a historical iteration data warehouse to store complete data snapshots of all past iterations. For each completed iteration, save metadata such as iteration identifier, start date, end date, planned task list, actual completion status, risk events that occurred, adjustments taken, and final delivery quality. Save detailed data during the iteration, including daily task status snapshots, code commit records, build and test results, and defect flow history.

[0032] Based on historical data, data mining methods are used to extract risk patterns, revealing typical characteristics and evolutionary patterns of different risk types. Cases of historical iteration delays are analyzed to identify common characteristics preceding the delays, such as consistently low task completion rates, frequent requirement changes, and blocked critical dependency tasks. Cases of historical quality issues are also analyzed to identify early warning signs of quality risks, such as declining test coverage, increased defect density, and lower code review pass rates. These historical patterns serve as an important source for the risk identification rule base.

[0033] This step outputs a standardized data stream, including multi-source real-time data streams, statistical indicators aggregated by time windows, a historical iterative data warehouse, and a risk pattern knowledge base.

[0034] Step 2: Based on the standardized data stream, extract multi-dimensional risk feature indicators, perform standardization processing and feature selection to obtain a multi-dimensional risk feature set; Specifically, the following steps are included: Step 2.1, Extraction of risk characteristics for requirement changes; Based on data from the demand management system, change tracking analysis is used to obtain characteristic indicators that reflect demand stability.

[0035] Calculate the frequency of requirement changes during the iteration, including the number of new requirements, deleted requirements, number of requirement scope modifications, and number of priority adjustments. Based on these statistics, calculate the requirement change rate, which is the total number of changes divided by the total number of planned tasks for the iteration. Calculate the temporal distribution characteristics of requirement changes, statistically analyzing the proportion of changes occurring in the early, middle, and late stages of the iteration to obtain a change time concentration index. Requirement changes in the later stages of the iteration are assigned a higher risk weight.

[0036] Calculate the impact scope of requirement changes, and analyze the number of tasks, code modules, and test cases affected by each change. Based on the dependency graph, use graph analysis algorithms to obtain the propagation depth and breadth metrics of the change. Propagation depth represents the maximum number of layers that can be reached from the change point through the dependency relationships, and propagation breadth represents the total number of affected nodes.

[0037] Based on historical statistics of demand changes, time series analysis is used to obtain the trend characteristics of demand changes. The change frequency of the most recent 3 days, 1 week, and the entire iteration is calculated, and the changes in change frequency across different time windows are compared to determine whether the changes are accelerating, decelerating, or stable. If the change frequency continues to rise, it indicates that the demand is unstable and the risk level is increased.

[0038] Step 2.2, Extraction of schedule deviation risk features; Based on task management data and time information, progress tracking analysis is used to obtain characteristic indicators reflecting the health of the iteration progress.

[0039] Calculate the task completion rate by comparing the number of tasks completed at the current time with the planned number of tasks. Based on the remaining iteration time, calculate the ideal completion rate, which is the time already consumed divided by the total iteration cycle, to obtain the deviation between the actual completion rate and the ideal completion rate. If the actual completion rate is lower than the ideal completion rate by more than a certain threshold (e.g., 10% or 15%), it indicates that the schedule is behind schedule and there is a risk of delay.

[0040] The task delay level is calculated by summing the actual completion time of each completed task against its planned completion time, thus obtaining the task delay distribution. The average delay is calculated by dividing the sum of all task delays by the number of tasks. The maximum delay is calculated as the number of days the most severely delayed task was delayed. The delayed task ratio is calculated by dividing the number of delayed tasks by the total number of completed tasks. A delayed task ratio that is too high, typically exceeding the threshold of 30% to 50%, indicates inaccurate estimation or low execution efficiency, posing a systemic schedule risk.

[0041] Calculate the status of tasks on the critical path, identify the critical path in the project dependency graph, and determine whether tasks on the critical path are progressing as planned. Based on the critical path method, forward and backward calculations are used to obtain the earliest start time, latest start time, and total float for each task. For critical tasks with a total float of 0, if delays or status anomalies occur, their risk weight is higher than that of non-critical tasks.

[0042] Calculate the burn-down chart deviation, plot the ideal burn-down curve and the actual burn-down curve, and calculate the area difference between the two curves as a quantitative indicator of schedule deviation. If the actual curve is consistently higher than the ideal curve and the gap widens, it indicates that the remaining workload is being consumed at a slower rate than expected, posing a risk of not being able to complete the task on schedule.

[0043] Step 2.3, code quality risk feature extraction; Based on data from version control systems and static analysis tools, code metrics analysis is used to obtain characteristic indicators reflecting code health.

[0044] The number of defects detected by static code analysis tools is statistically analyzed and categorized by severity into four levels: blocking, critical, general, and warning. Blocking defects cause system malfunction or core functionality failure; critical defects affect important functions but have temporary solutions; general defects affect minor functions or user experience; and warning defects indicate code style issues or potential risks. Defect density is calculated by dividing the number of defects by the total number of lines of code or modules, yielding the number of defects per thousand lines of code. The current defect density is compared to a historical baseline. A continuously increasing defect density indicates declining code quality and a risk of accumulating technical debt.

[0045] Calculate code complexity metrics, using methods such as cyclomatic complexity and cognitive complexity to assess the complexity of the code. Count the number of functions or classes whose complexity exceeds a threshold, where the cyclomatic complexity threshold is usually set to 10 or 15, and the cognitive complexity threshold is usually set to 15 or 20. Calculate the average complexity and maximum complexity. High-complexity code is difficult to understand and maintain, prone to introducing defects, and increases rework costs later.

[0046] Calculate the code duplication rate by using a code duplication detection tool to identify duplicate code segments in the codebase and calculate the proportion of duplicate lines of code to the total number of lines of code. A high duplication rate indicates poor code reusability, increasing maintenance costs and the probability of errors.

[0047] Calculate the code review pass rate, which shows the percentage of submitted code changes that have been reviewed, and the percentage that pass the review on the first attempt. A decrease in the pass rate or an increase in the number of rework attempts indicates a decline in code quality or excessive pressure on the development team.

[0048] Step 2.4, Test Coverage and Quality Assurance Feature Extraction; Based on data from the continuous integration platform and test management system, test metrics analysis is used to obtain characteristic indicators reflecting the adequacy of testing.

[0049] Calculate test coverage, including multiple dimensions such as statement coverage, branch coverage, and path coverage. Statistically determine the percentage of code covered by automated tests and compare the current coverage rate with the coverage threshold required by the project's quality standards. This threshold is set based on the project's risk level and industry specifications, typically between 60% and 80%. If the coverage rate is below the threshold and shows a downward trend, it indicates insufficient testing and a quality risk.

[0050] Calculate the test case pass rate by analyzing the execution results of test cases in each build and dividing the number of passed tests by the total number of tests. If the pass rate is lower than expected or shows a downward trend, it indicates that the newly developed feature has introduced defects or broken existing functionality, posing a regression risk.

[0051] Calculate test failure frequency and failure modes, and statistically analyze the distribution of test failure frequency and types. Differentiate between occasional and persistent failures, and distinguish between different failure causes such as functional defects, performance issues, and compatibility problems. Persistent failures indicate the existence of unresolved serious issues that require priority attention.

[0052] Calculate defect discovery and repair efficiency, calculate the average time from defect creation to repair, and calculate the defect reopening rate (number of reopened defects divided by number of closed defects). A high reopening rate indicates poor defect repair quality, suggesting misunderstandings or inappropriate repair methods. Calculate the stock and new defects of different severity levels, focusing on the accumulation of blocking and severe defects.

[0053] Step 2.5, Team Collaboration and Resource Load Feature Extraction; Based on team collaboration tools and task allocation data, we use social network analysis and load balancing analysis to obtain characteristic indicators reflecting the health of the team.

[0054] Calculate the load distribution among team members, including the number of tasks and total working hours currently undertaken by each member, and calculate the load variance and load balance. If the load distribution is severely uneven, with some members overloaded while others are underloaded, it indicates unreasonable resource allocation, resulting in efficiency losses and overload risks.

[0055] Calculate team communication efficiency by analyzing communication records on the team collaboration platform, and statistically analyzing message count, response time, and discussion activity. Calculate the average time from when a problem is raised to when a response is received; excessively long response times indicate poor communication or distracted team attention. Analyze the centrality and clustering coefficient of the communication network to identify information silos and communication bottlenecks.

[0056] Calculate team stability metrics and track personnel changes during iterations, including new member additions, departures, and role changes. Personnel turnover leads to knowledge loss and integration costs, increasing project risk. Calculate the average project experience of team members; teams with less experience face higher technical risks.

[0057] Calculate collaboration bottlenecks, identifying the number and duration of tasks blocked while waiting for deliveries from others. Based on task dependencies, employ dependency analysis algorithms to determine the upstream dependencies and causes of blocking tasks. A high blocking rate indicates poor team collaboration or inadequate task planning.

[0058] Step 2.6, Extraction of external dependency risk features; Based on dependency tracking data and external interface connection records, dependency analysis methods are used to obtain characteristic indicators that reflect the health of external dependencies.

[0059] Identify external dependencies, including third-party service interfaces, deliverables from external teams, and infrastructure resources. For each dependency, record the dependency type, provider, planned delivery time, actual delivery time, and delivery quality.

[0060] Calculate the dependency latency rate and count the number and duration of delays in external dependencies. For critical dependencies, such as those on the critical path or core functionality dependencies, calculate the impact of their latency on the overall project schedule. Based on the dependency graph, use impact propagation analysis to obtain the number of downstream task blocks and time losses caused by dependency latency.

[0061] Calculate dependency stability and assess the reliability and responsiveness of external dependencies. Statistical metrics include API call failure rate, response timeout rate, and data error rate. If the dependency's stability is poor, contingency plans should be developed or alternative solutions should be identified.

[0062] Calculate the frequency of dependency changes and track changes such as interface changes, version upgrades, and feature adjustments to external dependencies. Frequent dependency changes increase adaptation costs and compatibility risks, requiring additional effort for integration testing.

[0063] Step 2.7, Risk Feature Vector Generation; Based on the feature indicators extracted from the above dimensions, a feature fusion method is used to obtain a comprehensive feature vector that represents the overall risk status of the iteration.

[0064] For numerical features, standardization is used to eliminate the influence of dimensions, and the Z-score standardization method is used to convert the feature values ​​into a distribution with a mean of 0 and a standard deviation of 1. For categorical features, one-hot encoding or label encoding is used to convert them into numerical representations. For time series features, a sliding window statistical method is used to extract time series features such as trends, periods, and anomalies.

[0065] Based on domain knowledge and correlation analysis, a feature selection method is used to screen the most valuable feature subset for risk prediction. Mutual information and correlation coefficients are used to evaluate the correlation between features and risk labels, retaining features with correlations higher than a set threshold (e.g., correlation coefficient greater than 0.3). Recursive feature elimination and LASSO regularization are used to remove redundant and irrelevant features, ultimately retaining the feature set that contributes most to the model's predictions.

[0066] The filtered features are organized into structured feature vectors by dimension, including feature groups for requirement changes, schedule deviations, code quality, test coverage, team collaboration, and external dependencies. Each feature group contains several specific features, and each feature is labeled with metadata such as its name, type, value range, and statistical time window.

[0067] This step outputs a multidimensional risk feature set, including: multidimensional risk feature vectors, feature metadata descriptions, and a correlation matrix between features and risk types.

[0068] Step 3: Based on the multidimensional risk feature set, construct a risk identification model and a risk identification rule base, identify risk types and levels, set early warning thresholds, and generate early warning information in real time to obtain risk early warning information; Specifically, the following steps are included: Step 3.1, Risk identification model construction; Based on feature vectors and labeled risk events in a historical iterative data warehouse, a risk identification model is constructed using a supervised learning method, resulting in a classification model that can predict the probability of occurrence of different risk types.

[0069] A training dataset is constructed, extracting feature vectors from historical iterations as input samples and using actual risk events as labels. For each historical iteration, risk events such as schedule delays, quality issues, resource conflicts, and uncontrolled requirement changes are labeled. For each risk event, attributes such as its occurrence time, severity, and scope of impact are labeled. The feature vectors at different points in time during the iteration are associated with risk events occurring within a certain future time window to construct a mapping relationship between features and risks.

[0070] Based on the characteristics of the training dataset, machine learning algorithms suitable for imbalanced data and multi-classification problems are adopted. For risk type identification, considering that an iteration may face multiple risks simultaneously, a multi-label classification method is used. Ensemble learning algorithms such as random forest, gradient boosting tree, and support vector machine are used to construct basic classifiers, and model fusion techniques are used to combine the prediction results of multiple basic classifiers.

[0071] For risk level prediction, multi-class classification or regression methods are used to output a severity score of the risk. Risk levels are defined as low, medium, and high. Low risk indicates the risk is within a controllable range and requires no special intervention; medium risk indicates the risk requires attention and the development of contingency plans; and high risk indicates a serious threat to the iterative objective that requires immediate action. Alternatively, a continuous risk score between 0 and 1 can be output. A mapping model from features to risk levels is established using methods such as logistic regression and neural networks.

[0072] Based on the risk identification model construction process, cross-validation was used to evaluate the model's performance, obtaining the model's performance in metrics such as accuracy, recall, and F1 score. For risk warning scenarios, recall was prioritized to reduce the risk of missed reports. The ability of the risk identification model to identify high-risk samples was improved by adjusting the classification threshold or using cost-sensitive learning methods.

[0073] Based on feature importance analysis, a model interpretation method is used to obtain the contribution of each dimension of features to risk prediction. The influence of each feature is quantified using methods such as SHAP values ​​and feature weights to identify the features most indicative of a particular type of risk. This information helps to understand the root causes of risk and provides a basis for adjusting strategies.

[0074] Step 3.2, Construction of the risk identification rule base; Based on the experience of domain experts and the analysis of historical risk cases, a rule extraction method is used to obtain an explicit set of risk identification rules.

[0075] The basic structure of a rule definition is in the form of "if condition then conclusion". The condition part is a logical judgment of the feature value, and the conclusion part is an assertion of the risk type and level. For example, the rule "If the task completion rate is less than 0.5, the iteration is more than halfway complete, and the burn-down chart deviation is greater than the threshold, then a high-level progress risk is determined to exist"; the condition of the rule can be a threshold judgment of a single feature, or a logical combination of multiple features.

[0076] From historical risk cases, association rule mining methods are used to obtain the association between frequently co-occurring feature patterns and risk types. The Apriori algorithm or FP-Growth algorithm is used to mine rules that meet the minimum support and minimum confidence requirements. The mined rules are reviewed and adjusted by domain experts to remove unreasonable or overfitting rules, retaining those with business significance and generalization ability.

[0077] For different risk types, specific subsets of rules are constructed. For schedule risks, the rules focus on characteristics such as task completion rate, burn-down chart deviation, and critical path task status; for quality risks, the rules focus on characteristics such as defect density, test coverage, and test pass rate; for requirement change risks, the rules focus on characteristics such as requirement change frequency, change time distribution, and change impact scope.

[0078] Set priority and confidence levels for rules. When multiple rules are triggered simultaneously, the rule with higher confidence or priority will be used first. Set applicable conditions and effective periods for rules. Some rules may only be effective for specific project types or iteration phases.

[0079] Step 3.3, Risk assessment of model and rule fusion; Based on a trained risk identification model and rule base, a fusion reasoning mechanism is used to obtain risk assessment results that comprehensively consider both data-driven and knowledge-driven approaches.

[0080] The real-time feature vector for the current iteration is simultaneously input into the risk identification model and the rule engine for inference. The model outputs the probability of occurrence and risk level score for each risk type, while the rule engine outputs a list of matching rules and corresponding risk assertions.

[0081] Based on the outputs of the model and rules, a weighted fusion strategy is employed to obtain the final risk assessment result. For each risk type, a weighted average of the model's predicted probability and the rule's matching confidence level is calculated as the comprehensive risk score. The weights can be dynamically adjusted based on the performance of the model and rules on historical data, with better-performing methods receiving higher weights.

[0082] For situations where the model and rules conflict, a conflict resolution mechanism is employed. If the model predicts high risk but the rule is not triggered, check for model overfitting or feature anomalies; if the rule triggers high risk but the model predicts a low probability, check whether the rule's applicability conditions are met or whether the rule needs to be updated; an expert review mechanism is introduced, where uncertain risk assessment results are manually judged by the project manager or technical experts.

[0083] Based on the integrated risk assessment results, a structured risk report is generated that includes information such as risk type, risk level, triggering characteristics, confidence level, and prediction basis.

[0084] Step 3.4, setting multi-level early warning thresholds; Based on the risk assessment results and the project's risk tolerance, a threshold setting method was adopted to obtain the criteria for triggering different levels of early warning.

[0085] A warning level system is defined, comprising four levels: Normal State, Attention Level, Warning Level, and Emergency Level. A Normal State indicates that the risk is within an acceptable range and no special intervention is required; an Attention Level warning indicates that risk indicators show abnormal signs and close monitoring is needed; a Warning Level warning indicates that the risk has manifested and countermeasures need to be developed; and an Emergency Level warning indicates that the risk seriously threatens the iterative objectives and immediate action is required.

[0086] For each risk type and each warning level, a threshold range for risk scoring is set. For example, for schedule risk, a score below 0.3 is considered normal, 0.3 to 0.5 is considered a concern, 0.5 to 0.7 is considered a warning, and a score above 0.7 is considered an emergency. The threshold setting comprehensively considers factors such as the score distribution of historical risk events, the project's risk appetite, and industry best practices.

[0087] A time-dimensional threshold dynamic adjustment mechanism is introduced. In the early stages of iteration, due to insufficient data accumulation and a large adjustment space, the warning threshold can be appropriately increased to avoid excessive intervention; in the later stages of iteration, due to limited adjustment margin, the warning threshold should be decreased to increase sensitivity and ensure timely detection and response to risks.

[0088] Introduce a trend-based early warning mechanism. In addition to threshold judgments based on the current risk score, the changing trend of the risk score should also be considered. If the risk score, although not reaching the warning threshold, continues to rise over multiple consecutive time windows, an early warning should still be triggered. Define trend-based early warning rules, such as "If the risk score rises for three consecutive days with a cumulative increase exceeding 0.2, a level-of-concern warning is triggered."

[0089] Step 3.5, Real-time early warning information generation and push; Based on the risk assessment results and early warning thresholds, an early warning generation mechanism is adopted to obtain early warning messages containing risk details and response suggestions.

[0090] When a risk score exceeds the warning threshold or a trend warning rule is triggered, a warning message is automatically generated. The warning message includes the following elements: warning level, risk type, current risk score, score change trend, key characteristics that trigger the warning and their values, a list of affected tasks or modules, historical similar risk cases, suggested countermeasures, and the warning generation time.

[0091] Based on the warning level and risk type, a notification strategy is adopted to determine the recipients and channels of warning messages. For warnings at the "Attention" level, they are pushed to the iteration leader and relevant task leaders through the project management system's message center; for warnings at the "Alert" level, they are sent to key roles such as project managers, product owners, and Scrum Masters via email and instant messaging tools; for warnings at the "Emergency" level, all relevant stakeholders are notified through high-priority channels such as telephone and SMS to ensure that the warning information reaches them in a timely manner.

[0092] The project management dashboard presents alert information visually. Color coding distinguishes different alert levels: red for urgent, yellow for warning, and blue for attention. Charts display the time-series changes in risk scores, marking the trigger points of the alerts. An interactive viewing function is provided for alert details; clicking on an alert expands to view detailed information such as the triggering reason, related characteristics, and recommended measures.

[0093] Establish an early warning response tracking mechanism to record the confirmation status, processing progress, and final result of early warnings. Recipients of early warnings are required to confirm receipt within a specified time and provide feedback on the measures taken and their effects after processing. Early warnings that are not responded to in a timely manner will be automatically escalated to higher-level management.

[0094] This step outputs risk warning information, including: risk identification model, risk identification rule base, warning level determination result, warning message and push record.

[0095] Step 4: Based on the risk warning information, match and evaluate candidate strategies from the adjustment strategy library, perform constraint checks and optimization selection, and then formulate an execution plan to obtain a risk response adjustment scheme; Specifically, the following steps are included: Step 4.1, adjust the strategy library construction; Based on agile project management practices and historical adjustment cases, a knowledge engineering approach was adopted to obtain an adjustment strategy library covering different risk types and corresponding countermeasures.

[0096] Define a structured representation of the adjustment strategy, including attributes such as strategy identifier, strategy name, applicable risk type, applicable warning level, preconditions, strategy actions, expected results, implementation costs, and constraints. Strategy actions describe specific adjustment operations, such as adjusting task priorities, reallocating personnel, increasing resource investment, reducing iteration scope, extending iteration cycles, introducing technical experts, and strengthening communication and coordination.

[0097] To address schedule risks, a set of schedule adjustment strategies is developed. These strategies include: prioritizing tasks on the critical path to ensure critical tasks receive resources first; postponing or removing non-critical tasks from the current iteration to reduce the overall workload; increasing personnel allocation to delayed tasks to accelerate progress through parallel work; breaking down complex tasks into multiple sub-tasks to reduce the risk and uncertainty of individual tasks; and appropriately extending the iteration cycle to provide the team with more buffer time without affecting the overall project plan.

[0098] To address quality risks, a set of quality improvement strategies should be developed. These strategies include: increasing the frequency and rigor of code reviews to ensure new code meets quality standards; dedicating specific time to paying off technical debt and refactoring modules with high complexity or high defect density; increasing automated test cases to improve test coverage; introducing dedicated security audits or performance tests to address specific quality issues; and suspending new feature development to focus on fixing existing defects.

[0099] To address the risk of requirement changes, a set of requirement management strategies should be developed. These strategies include: freezing the scope of requirements for the current iteration, prohibiting or strictly controlling new requirement changes; assessing the impact of necessary changes and adjusting the priority or scope of other tasks accordingly; postponing change requests to the next iteration to maintain the stability of the current iteration plan; strengthening communication with product owners and business stakeholders to clarify requirement priorities and necessity; and establishing a change approval process, with the change control committee assessing the value and cost of each change.

[0100] To address resource risks, a set of resource allocation strategies should be developed. These strategies include: reallocating tasks within the team, transferring tasks from overloaded members to less overloaded members; temporarily borrowing personnel from other teams to supplement key skills or increase manpower; arranging overtime or extending working hours to increase output in the short term; outsourcing some non-core tasks to free up internal resources to focus on core work; and postponing or canceling unnecessary meetings and activities to reduce time commitment.

[0101] To address external dependency risks, a dependency management strategy suite should be developed. Strategies include: strengthening communication with dependent parties to urge them to deliver on time and provide necessary support; developing contingency plans, such as using simulated data or alternative technical solutions, to reduce reliance on specific dependencies; adjusting task execution order, prioritizing tasks that do not depend on external parties to allow more buffer time for dependent tasks; and escalating dependency issues to higher management levels to seek organizational coordination and support.

[0102] Each strategy is annotated with its historical usage and effectiveness evaluation, including the number of times the strategy was adopted, its success rate, average risk mitigation, and average implementation cost. This information serves as an important reference for strategy selection.

[0103] Step 4.2, Strategy matching and candidate set generation; Based on the current early warning information, a strategy retrieval algorithm is used to match applicable candidate strategies from the adjustment strategy library to obtain a preliminary strategy candidate set.

[0104] Based on the risk type in the warning information, filter and adjust all strategies in the strategy library that are applicable to that risk type. For example, for a schedule risk warning, retrieve all strategies in the schedule adjustment strategy set.

[0105] Based on the warning level, further select strategies suitable for the current severity of risk. For warnings at the "Attention" level, prioritize lightweight adjustment strategies, such as enhanced monitoring and advance communication; for warnings at the "Alert" level, select moderate-intensity adjustment strategies, such as task rescheduling and local resource adjustments; for warnings at the "Emergency" level, select strong intervention strategies, such as reducing the scope, increasing resource investment, and extending the time.

[0106] Check if the preconditions for the strategy are met. Preconditions may include constraints such as resource availability, team size, project stage, and technical feasibility. For example, the precondition for the "borrowing personnel from other teams" strategy is that other teams have suitable personnel available and are willing to provide support. If the preconditions are not met, the strategy should be excluded from the candidate set.

[0107] Based on historical experience with similar scenarios, a case-based reasoning approach is used to derive preferred strategies. Iterative cases with similar risk characteristics are retrieved from the historical data warehouse to examine which strategies were employed and their effectiveness. Strategies with higher historical success rates are then prioritized in the candidate set.

[0108] Generate a candidate set containing several candidate strategies, with each candidate strategy accompanied by information such as its applicability score, historical success rate, estimated effect, and estimated cost.

[0109] Step 4.3, strategy evaluation for multi-objective optimization; Based on the policy candidate set and the detailed state of the current iteration, a multi-objective optimization evaluation method is adopted to obtain a policy score that comprehensively considers the risk mitigation effect and implementation cost.

[0110] Define the objective function for strategy evaluation, including multiple dimensions such as risk mitigation effectiveness, implementation cost, impact on other tasks, and team acceptance. Risk mitigation effectiveness measures the expected decrease in risk score after strategy implementation, determined based on historical data and expert estimates; implementation cost includes required additional work hours, capital investment, opportunity cost, etc.; impact on other tasks assesses whether the strategy will cause delays or resource conflicts in other tasks; team acceptance measures the degree of team members' acceptance and cooperation with the strategy; unreasonable or overly aggressive strategies may encounter resistance.

[0111] For each candidate strategy, simulation methods are used based on the current iteration data to obtain the expected results of strategy implementation. For example, for the strategy of "removing 3 non-critical tasks from the current iteration", the workload and schedule after removing these tasks are simulated, and the expected task completion rate and burn-down chart trend are calculated. For the strategy of "adding 2 developers to critical tasks", the reduction in task completion time is estimated based on personnel skills and task characteristics, while also considering the additional overhead of communication and coordination.

[0112] Based on the simulation results, a quantitative score is calculated for each target dimension. A normalization method is used to transform indicators with different dimensions to a uniform scale, such as between 0 and 1. For risk mitigation effectiveness, if the expected risk score decreases from 0.75 to 0.45, the effectiveness score is 0.3 divided by 0.75, which equals 0.4. For implementation costs, a cost cap is set based on the budget and available resources; the closer the cost is to the cap, the lower the score.

[0113] A multi-objective optimization algorithm is employed to obtain a comprehensive score for each candidate strategy. A weighted summation method is used to assign weights to each objective dimension and calculate a weighted comprehensive score. The weights reflect the current priority of the project; if the project faces severe schedule pressure, the weight of risk mitigation should be higher than the weight of implementation cost. Alternatively, the Pareto optimality method can be used to identify strategies that are not strictly dominated by other strategies across multiple objectives, forming a Pareto front from which decision-makers can select the best strategy.

[0114] Candidate strategies are sorted by their overall score to obtain a recommended strategy list. The strategies ranked highest in the list are the adjustment schemes with the best overall performance.

[0115] Step 4.4, Constraint Check and Feasibility Verification; Based on the recommended strategy list, a constraint checking method is used to obtain a set of feasible strategies that meet the actual constraints of the project.

[0116] Examine resource constraints and verify whether the manpower, time, and financial resources required for the strategy are within available limits. If the strategy requires additional personnel but the team has no redundant manpower, or requires an extension but the project delivery date is invariable, then the strategy is not feasible.

[0117] Examine the technical constraints and verify the feasibility of the technical solutions involved in the strategy. If the strategy recommends adopting a new technology or tool, the team's technical reserves and learning costs need to be assessed. If the strategy recommends refactoring a module, the technical risks of the refactoring and the guarantee of test coverage need to be evaluated.

[0118] Examine business constraints and verify that the strategy aligns with business objectives and customer expectations. If the strategy recommends removing certain features, confirm whether these features are core customer needs. If the strategy recommends delaying delivery, assess the impact on customer commitments and market window.

[0119] Examine team constraints and verify whether the strategy aligns with the team's work style and culture. Overly aggressive strategies may trigger team backlash, and too frequent adjustments may disrupt the team's rhythm. Factors such as team fatigue levels, morale, and historical adaptability need to be considered.

[0120] Strategies that do not meet the constraints are removed from the recommendation list or marked as infeasible. Strategies that partially meet the constraints can be adjusted and optimized, such as reducing resource input intensity or narrowing the adjustment range, to make them meet the constraints.

[0121] Generate a final set of feasible strategies, each strategy accompanied by a detailed implementation plan, expected results, risk warnings, and other information.

[0122] Step 4.5, Strategy Selection and Implementation Plan Development; Based on the set of feasible strategies and the actual situation of the project, a decision support approach is used to obtain the final selected adjustment strategy and a detailed implementation plan.

[0123] Present a set of feasible strategies to project decision-makers, including key roles such as project managers, product owners, and Scrum Masters. Provide a visual comparison view of strategies, showing the performance of each strategy across different evaluation dimensions, to help decision-makers quickly understand the differences between strategies.

[0124] The system supports decision-makers in adjusting strategy choices based on the latest information and their subjective judgment. While the system provides a default recommended optimal strategy, decision-makers can adjust it based on factors not captured by the system, such as team sentiment, customer relationships, and strategic considerations. Decision-makers can choose a single strategy or combine multiple strategies to form a comprehensive solution.

[0125] For the selected strategy, develop a detailed execution plan. Break down the strategy into specific operational steps, clearly defining the person in charge, start time, completion time, required resources, and prerequisites for each step. For example, for the "reassign tasks" strategy, the execution plan includes: identifying the task list that needs adjustment, determining the target personnel to receive the tasks, conducting task handover and knowledge transfer, updating the task assignments in the project management system, notifying relevant team members, and monitoring the progress of the adjusted tasks.

[0126] Based on the execution plan, task orders and notification messages are generated, and adjustments are automatically synchronized to relevant systems and personnel. Task status and assignments are updated in the project management tool, adjustment announcements are published in the team collaboration platform, and relevant meetings and milestones are scheduled in the calendar system.

[0127] Establish a tracking mechanism for implementation adjustments and set checkpoints to monitor progress. Require responsible personnel to regularly report on implementation status, recording any problems encountered and deviations. If the strategy's effectiveness falls short of expectations or new problems arise during implementation, promptly initiate emergency response or strategy adjustments.

[0128] This step outputs a risk response and adjustment plan, including: an adjustment strategy library, a set of strategy candidates, strategy evaluation results, selected adjustment strategies, and a detailed implementation plan.

[0129] Step 5: Based on the risk response adjustment plan, monitor the data comparison before and after the adjustment, quantify the adjustment effect and analyze its effectiveness, update the risk identification model, and obtain the adjustment effect evaluation results; Specifically, the following steps are included: Step 5.1, Adjusted real-time data tracking; Based on the selected implementation time points in the adjustment strategy, a comparative monitoring method is used to obtain data on changes in risk characteristics before and after the adjustment.

[0130] When the adjustment strategy begins to be implemented, the current moment is recorded as the adjustment baseline time point, and a complete snapshot of all risk characteristic values, task status, resource allocation, progress status, etc. at this time is saved.

[0131] Within the duration window following the adjustment, high-frequency data collection is employed to obtain a dense sequence of monitoring data. For key indicators such as task completion rate, risk score, and progress of critical tasks, the collection frequency is increased to hourly or per status change. Tasks and modules directly affected by the adjustment are subject to focused monitoring and in-depth data collection.

[0132] Based on a comparison of data before and after the adjustment, differential analysis was used to obtain the magnitude and trend of changes in various indicators. The increase in task completion rate, the decrease in risk score, and the reduction in the number of days of delay for critical tasks were calculated. Time series comparison charts of the indicators before and after the adjustment were plotted to visually demonstrate the impact of the adjustment.

[0133] Identify the direct and indirect effects of the adjustment. Direct effects are the improvements the adjustment directly affects in the task or module it impacts, while indirect effects are changes that propagate through dependencies to other parts of the process. For example, prioritizing a blocked task directly speeds up its completion, while indirectly allowing downstream tasks that depend on it to begin execution.

[0134] Step 5.2, adjust the quantitative evaluation of the effect; Based on the adjusted monitoring data and expected goals, a quantitative evaluation method is used to obtain the effectiveness score of the adjustment strategy.

[0135] Calculate the risk mitigation effectiveness index and compare the changes in risk scores before and after adjustment. If a certain risk score was 0.75 before adjustment and dropped to 0.50 after adjustment, the risk mitigation magnitude is 0.25, and the mitigation rate is 33%. Calculate the length of time the adjusted risk score remains below the warning threshold as a measure of risk control stability.

[0136] Calculate progress improvement indicators by comparing progress metrics such as task completion rate, burn-down chart trend, and critical task delays before and after the adjustment. If the task completion rate was 45% before the adjustment, lagging behind the ideal completion rate of 60%, and the task completion rate improved to 58% after the adjustment, approaching the ideal completion rate, then the progress improvement is significant.

[0137] Calculate resource utilization efficiency indicators to assess whether the adjusted resource allocation is more reasonable. Calculate changes in team workload variance; a decrease in variance indicates a more balanced workload. Calculate changes in per capita output; an increase in the number of tasks completed or the value delivered per person indicates improved resource utilization efficiency.

[0138] Calculate adjustment cost indicators, and statistically analyze the actual labor hours, capital, opportunity costs, etc., consumed in the adjustment. Compare the actual costs with the estimated costs in the strategy evaluation phase to analyze the reasons for cost deviations; calculate the cost-benefit ratio, that is, the ratio of risk mitigation effect to adjustment costs, and evaluate the input-output efficiency of the adjustment.

[0139] Based on multiple evaluation dimensions, a comprehensive scoring method was used to obtain the overall effectiveness rating of the adjustment strategy. The effectiveness rating was defined as four levels: excellent, good, average, and poor. Excellent indicates that the expected goals were achieved or exceeded and the costs were controllable; good indicates that the expected goals were basically achieved; average indicates that the expected goals were partially achieved but there were shortcomings; and poor indicates that the expected goals were not achieved or that negative impacts were generated.

[0140] Step 5.3, Adjust strategy effectiveness analysis; Based on the results of the effectiveness evaluation and the implementation process records, the root cause analysis method was used to identify the key factors affecting the effectiveness of the adjustment and directions for improvement.

[0141] For effective adjustment strategies, analyze the key factors for success. Identify which preconditions, execution details, team collaboration, and other factors contributed to the success. Extract successful experiences to form best practices for future reference in similar scenarios. Update the success rate and recommendation priority of the corresponding strategies in the adjustment strategy library.

[0142] For adjustment strategies that fail to produce good results, analyze the root causes of the failure. Examine whether the failure was due to factors such as inappropriate strategy selection, execution deviations, changes in the external environment, or prediction errors. If the problem lies with the strategy itself, the applicable conditions or parameters need to be modified. If the problem is with execution, the formulation and monitoring mechanisms of the execution plan need to be improved.

[0143] Identify unintended impacts that arise during adjustments. Some adjustments may introduce new risks or problems while mitigating target risks. For example, moving a task out of the current iteration may relieve schedule pressure but could affect customer satisfaction or workload in the next iteration. Document these unintended impacts and take them into account in future strategy evaluations.

[0144] By comparing the effectiveness of different strategies in similar scenarios, the most effective strategy type can be identified. Average mitigation effect, success rate, cost, and other metrics for each strategy are statistically analyzed to establish a strategy performance ranking. This provides data support for strategy recommendation algorithms.

[0145] Step 5.4, incremental update of the risk identification model; Based on the complete data before and after adjustment and the actual risk evolution process, an optimized risk identification model is obtained by using an incremental learning method.

[0146] Adjusted cases are added to the training set as new training samples. These samples include the feature vectors before adjustment, risk assessment results, the adjustment strategies adopted, feature changes after adjustment, and whether the final risk was controlled. Special attention is paid to cases where the model predicted low risk but a problem actually occurred, or cases where the model predicted high risk but everything went smoothly.

[0147] Based on the new samples, the parameters of the risk identification model are updated using online learning or incremental training algorithms. For neural network models, several rounds of backpropagation training are performed using the new samples to adjust the network weights; for tree models, new decision rules are added or node splitting thresholds are adjusted; for ensemble models, new base learners can be trained to join the ensemble, or the voting weights of each base learner can be adjusted.

[0148] Based on changes in feature importance, feature selection methods are used to adjust the feature set. If some features show stronger predictive power on new data, their weights are increased or relevant features are added. If the predictive power of some features decreases or introduces noise, their weights are reduced or they are removed from the feature set.

[0149] Use a validation set to evaluate the performance of the updated risk identification model, ensuring that the model's performance on the new data improves rather than overfits. Compare the accuracy, recall, F1 score, and other metrics of the risk identification model before and after the update on historical and new data. If the model's performance improves significantly, deploy the updated risk identification model to the production environment; if the performance improvement is not significant or even declines, retain the original risk identification model and analyze the reasons.

[0150] Step 5.5: Iterative optimization of the rule base and adjustment strategy base; Based on the implementation experience and feedback of the adjustment strategy, an optimized risk identification rule base and adjustment strategy base were obtained by adopting a knowledge update method.

[0151] For the risk identification rule base, the thresholds and conditions of the rules are adjusted based on false positives and false negatives. If a rule is frequently triggered but no actual risk occurs afterward, it indicates that the rule is too sensitive and the threshold needs to be increased or constraints added. If some risks are not captured by the rules, their characteristic patterns need to be analyzed and corresponding rules added.

[0152] For the adjustment strategy library, update the strategy attributes based on the strategy implementation results. Update the strategy records with actual risk mitigation effects, implementation costs, success rates, and other data, replacing or supplementing the original historical data. Newly discovered effective adjustment methods are added to the adjustment strategy library as new strategies. Strategies that repeatedly fail are marked as not recommended or removed from the adjustment strategy library.

[0153] Establish a strategy variation management mechanism to record the effects of the same type of strategy under different parameter configurations. For example, for the "increase personnel input" strategy, record the differences in effects when inputting 1, 2, and 3 people in different scenarios, providing a basis for fine-tuning the strategy parameters.

[0154] Update the applicable conditions and preconditions of the strategy to make the strategy matching more accurate. Based on implementation experience, identify which project characteristics, team features, and risk scenarios make a particular strategy more effective. Avoid recommending the wrong strategy in unsuitable scenarios.

[0155] This step outputs the adjustment effect evaluation results, including: before and after adjustment comparison data, effect evaluation report, strategy effectiveness analysis, updated risk identification model, optimized rule base and adjustment strategy base.

[0156] Step 6: Based on standardized data flow, risk warning information, risk response adjustment plan and adjustment effect evaluation results, conduct visualization and interactive simulation, establish team collaboration mechanism and risk management knowledge base, and obtain visualization and knowledge management results; Specifically, the following steps are included: Step 6.1, Risk Situation Visualization Dashboard; Based on real-time risk monitoring data and early warning information, data visualization technology is used to create a management dashboard that intuitively displays the project's risk status.

[0157] The dashboard features a multi-layered view, including an overview view, detailed views, and historical trend views. The overview view displays the overall risk status of the current iteration on a single page, using components such as dashboards, heatmaps, and status indicators. The detailed view provides in-depth data analysis and drill-down capabilities for each risk dimension. The historical trend view shows the risk evolution and improvement trajectory across iterations.

[0158] In the overview view, different colored areas represent different risk types, and the size of the area reflects the scope or severity of the risk's impact. A radar chart is used to display the overall situation of multi-dimensional risks, with the values ​​for each dimension reflecting the risk score for that dimension. A timeline is used to display the occurrence time and level of warning events, and to indicate the adjustment measures already taken.

[0159] The detailed view provides a table of characteristic indicators for each risk type, showing the current value, threshold, degree of deviation, and trend of each indicator. It also provides task-level risk analysis, listing high-risk tasks and their underlying causes. Furthermore, it offers workload and performance analysis for team members, identifying overload or inefficiency.

[0160] It supports interactive operations, allowing users to explore data through clicking, filtering, and sorting. Clicking on a risk area allows viewing detailed information and historical records of that risk. Users can filter for specific time ranges or task types to view corresponding risk data. It supports customizable dashboard layouts and monitored metrics to meet the needs of different roles.

[0161] Step 6.2, interactive simulation of the adjusted plan; Based on the generated set of adjustment strategy candidates, interactive simulation technology is used to obtain a simulation tool that supports decision-makers in exploring the effects of different options.

[0162] It provides a strategy comparison matrix, listing candidate strategies horizontally and evaluation dimensions vertically. Matrix cells display the scores of each strategy in each dimension. It supports sorting by different dimensions, helping decision-makers quickly identify the optimal strategy.

[0163] It provides a strategy simulation function, allowing decision-makers to select a strategy and simulate the project state after its implementation. The simulation displays changes in task allocation, schedule forecasting, resource utilization, and risk score after the strategy is implemented. Key indicators before and after strategy implementation are compared graphically, such as burn-down charts, risk score curves, and team load distribution.

[0164] It supports adjusting strategy parameters, allowing decision-makers to modify specific strategy parameters and view changes in effects in real time. For example, for the "increase personnel" strategy, the number of people added and the allocation method can be adjusted, and the system calculates and displays the expected effects and costs under different configurations in real time.

[0165] It provides multi-strategy combination capabilities, allowing decision-makers to select multiple strategies to form a combined solution, and systematically evaluate the overall effect and potential conflicts of the combined solution. It identifies the synergistic effects and mutual constraints between strategies and provides suggestions for combined optimization.

[0166] Record the decision-maker's reasoning process and final choice, including which strategies were reviewed, which parameters were modified, and the basis for the choice. These decision trajectories serve as valuable empirical data to understand the decision-making patterns of human experts and improve system recommendation algorithms.

[0167] Step 6.3, Team Collaboration and Communication Support; Based on early warning information and adjustment plans, a support mechanism is established by integrating collaborative tools to promote efficient team communication and collaborative response.

[0168] Create a dedicated risk management channel or space within the team collaboration platform to automatically push alerts, adjusted plans, and implementation progress information. Team members can discuss risk response measures, provide feedback on implementation status, and propose improvement suggestions in this space.

[0169] Provides a structured risk discussion template to guide the team in effective risk analysis and decision-making. The template includes elements such as risk description, impact analysis, root causes, response plans, responsibility allocation, and timeline. Team members fill in the information according to the template to ensure that the discussion is comprehensive and verifiable.

[0170] It supports online meeting integration, automatically initiating risk response meeting invitations when an alert is triggered, and inviting relevant stakeholders to participate. During the meeting, risk dashboards and adjustment plan simulation results can be shared, enabling real-time discussion and decision-making. Meeting resolutions are automatically recorded and converted into execution tasks.

[0171] Establish a risk response responsibility matrix, clearly defining the responsible person, collaborator, and informed party for each risk type and adjustment task. When an alert or adjustment task is issued, the system automatically notifies the relevant roles and tracks their response status. For tasks that fail to respond within the specified timeframe, the system automatically escalates or issues a reminder.

[0172] Provide a team feedback collection mechanism, inviting team members to provide feedback during and after the strategy implementation process. Feedback should include evaluations of the strategy's rationale, difficulties encountered during implementation, and suggestions for improvement. Summarize team feedback to generate collective wisdom for strategy optimization.

[0173] Step 6.4, cross-iteration knowledge management and experience transfer; Based on data, models, strategies, and cases accumulated over multiple iteration cycles, knowledge management methods are employed to obtain organizational knowledge assets that can be sustainably accumulated and reused.

[0174] Establish a risk management knowledge base to structurally store all risk events, early warning records, adjustment cases, and effect evaluations. For each case, record complete background information, handling process, and result feedback to form a closed-loop case story.

[0175] The case studies in the risk management knowledge base are tagged and categorized, and indexed by dimensions such as risk type, project characteristics, team size, and technology stack. It supports case retrieval based on similarity, allowing for quick searching of similar historical cases for reference when new risks emerge.

[0176] Extract best practices and lessons learned in risk management to create a methodological document that can guide future projects. Summarize frequently occurring risk patterns and effective response strategies to compile a risk response manual. Identify common risk management pitfalls and failure cases, and provide warnings and guidance on avoiding these pitfalls.

[0177] It supports cross-project knowledge transfer and reuse, allowing models trained in one project and accumulated rules to be applied to new projects. It also adapts to the characteristics of new projects, accelerating the establishment of risk management systems for those projects.

[0178] Establish incentive mechanisms for knowledge contribution and use to encourage team members to share experiences and feedback. Recognize and reward members who contribute valuable case studies and improvement suggestions. Regularly organize knowledge-sharing sessions where experienced members can share risk management skills.

[0179] Step 6.5: Continuous system improvement and evolution; Based on long-term system operation data and user feedback, a continuous improvement plan is derived using a continuous improvement approach.

[0180] Establish a system performance monitoring mechanism to track key indicators such as the accuracy of risk identification, the timeliness of early warnings, and the effectiveness of adjustment strategies. Set performance baselines and improvement targets, and regularly evaluate system performance.

[0181] Collect user feedback and suggestions to understand the pain points and areas for improvement in practical applications. Obtain feedback through methods such as questionnaires, user interviews, and usage log analysis. Prioritize resolving issues frequently raised by users and develop features that are highly requested by users.

[0182] Track the latest research and technological advancements in agile development practices and risk management, and promptly introduce new methods and tools. For example, employ more advanced deep learning models to improve the accuracy of risk prediction, and introduce natural language processing technology to analyze team communication content to identify potential risks.

[0183] Establish a system version management and canary release mechanism. New features and model updates should be piloted on a small scale first, and then rolled out nationwide after the effects are verified. Retain historical system versions so that a quick rollback can be made if problems arise with a new version.

[0184] Organize regular system review meetings, with the participation of the project team, system developers, and domain experts, to comprehensively assess the system's value and problems, and plan the direction for improvement in the next phase.

[0185] This step outputs visual presentations and knowledge management results, including: a risk situation visualization dashboard, simulation tools, support mechanisms to promote efficient team communication and collaborative responses, a risk management knowledge base, and a system continuous improvement plan.

[0186] In one embodiment of the present invention, a specific example is provided: The mobile payment system development team of an internet finance company uses the Scrum methodology with a two-week iteration cycle. The team consists of 30 people, including 2 product managers, 20 development engineers, 6 test engineers, and 2 UI designers. The current iteration goal is to optimize the payment process and add QR code payment functionality, with a planned delivery of 12 user stories.

[0187] A four-week (two full iterations) field test was conducted in the team's development environment. During the test, the risk warning and adaptive adjustment system of this invention was deployed and integrated with the JIRA requirements management system, GitLab version control system, Jenkins continuous integration platform, Bugzilla defect tracking system, and WeChat Work collaboration platform. The system collected data hourly to monitor the project's risk status in real time, covering all development activities of the 30 team members.

[0188] The key data collected on day 5 of the iteration are shown in Table 1: Table 1: Key data collected on day 5 of the iteration;

[0189] Based on the data collected in Table 1, multidimensional risk features were extracted and input into the risk identification model. The risk identification model output a schedule risk score of 0.68, exceeding the warning level threshold of 0.5. The rule engine matched the rule "critical path task delayed and task completion rate more than 10% lower than the ideal completion rate," and determined it to be a warning level schedule risk.

[0190] Generate an alert message and push it to the Scrum Master and project manager, listing three delayed critical tasks and the reasons for their delays, and matching five candidate strategies from the tuning strategy library: Strategy A: Move two non-critical tasks to the next iteration, with an expected risk reduction of 0.15 and a cost of the value loss due to delayed delivery.

[0191] Strategy B: Allocate 3 developers from other modules to support critical tasks, with an expected risk reduction of 0.25, and costs of slowing down the progress of other modules and communication and coordination expenses.

[0192] Strategy C: Break down critical tasks into smaller, parallel development steps, with an expected risk reduction of 0.20, and the cost being the design time and integration complexity of the breakdown.

[0193] Strategy D: Extend the iteration cycle by 3 days, expected risk mitigation 0.30, cost is delayed delivery and downstream dependence impact.

[0194] Strategy E: Increase the frequency of daily stand-up meetings and strengthen progress monitoring. The expected risk reduction is 0.10, and the cost is the time occupied by the meetings.

[0195] After multi-objective optimization evaluation and constraint checks, the project manager selected a combination of strategies C and E. The blocked "payment interface integration" task was split into two sub-tasks: "interface debugging" and "exception handling," which were assigned to two developers for parallel development. Daily stand-up meetings were increased from once in the morning to twice a day, focusing on synchronizing the progress of key tasks.

[0196] Three days after the adjustment was implemented, system monitoring data showed that: the task completion rate increased to 48%, approaching the ideal completion rate of 50%; the delay of critical tasks was shortened to 0.5 days; and the progress risk score dropped to 0.42, below the warning level threshold. The adjustment effect was evaluated as good, and the success rate and recommended priority of Strategy C were correspondingly improved in the adjustment strategy library.

[0197] The key data collected on the 10th day of the iteration are shown in Table 2: Table 2: Key data collected on day 10 of the iteration;

[0198] Based on the data collected in Table 2, the system detected that the defect density increased from 3.2 defects / thousand rows to 5.8 defects / thousand rows, and the test pass rate decreased from 95% to 88%. Two critical defects remained unrepaired for more than two days. The risk identification model output a quality risk score of 0.71, reaching the warning level.

[0199] The system recommended strategy: suspend new feature development and concentrate resources on fixing existing defects; increase code review coverage; introduce a dedicated quality audit. The team adopted the suggestions, suspended new feature development for one day, and organized a dedicated code quality improvement campaign. After the adjustment, the defect density dropped to 4.1 defects per thousand lines, the test pass rate recovered to 92%, and both critical defects were fixed.

[0200] At the end of the iteration, 11 of the 12 planned user stories were completed, with one delayed due to a dependency on an external interface upgrade. Delivery quality was good, with no serious defects remaining. The team's risk warning system helped identify and address two major risks in a timely manner, preventing the iteration goals from failing.

[0201] The system adds the complete data from this iteration to the training set and updates the parameters of the risk identification model. Two new successful adjustment cases are added to the risk management knowledge base for reference in subsequent iterations. This application example demonstrates a complete closed-loop process of risk monitoring, early warning, adjustment, and assessment, verifying the practicality and effectiveness of the method of this invention.

[0202] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A method for real-time early warning and adaptive adjustment of project iteration risks based on agile development, characterized in that, Includes the following steps: Collect multidimensional process data from agile projects and preprocess it to obtain a standardized data stream; Based on standardized data streams, multi-dimensional risk feature indicators are extracted, and standardized processing and feature selection are performed to obtain a multi-dimensional risk feature set. Based on a multidimensional risk feature set, a risk identification model and a risk identification rule base are constructed to identify risk types and levels, set early warning thresholds, and generate early warning information in real time to obtain risk early warning information. Based on risk warning information, candidate strategies are matched and evaluated from the adjustment strategy library. After constraint checks and optimization selection, an execution plan is formulated to obtain a risk response and adjustment solution. Based on the risk response adjustment plan, monitor the comparison of data before and after the adjustment, quantify the adjustment effect and analyze its effectiveness, update the risk identification model, and obtain the adjustment effect evaluation results; Based on standardized data flow, risk warning information, risk response and adjustment plans, and adjustment effect evaluation results, visualization and interactive simulation are performed, a team collaboration mechanism and a risk management knowledge base are established, and visualization and knowledge management results are obtained.

2. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The steps for obtaining the standardized data stream include: Establish data connection channels with the requirements management system, version control system, continuous integration platform, defect tracking system, and team collaboration platform; An event-driven data collection strategy is adopted, with real-time collection of state change events triggered by events and periodic collection of cumulative indicators. Data cleaning is performed on the collected heterogeneous raw data. A unique identifier deduplication algorithm is used to remove duplicate records, statistical detection methods are used to identify and correct outliers, and a completion strategy is used to process missing data. A standardized data table structure is defined using a unified data model; A sliding time window mechanism is used for data aggregation, and the aggregated metrics within the window are calculated.

3. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The extracted multi-dimensional risk feature indicators include: Extract the risk characteristics of demand change, calculate the frequency of demand change, the rate of demand change, and the concentration of change time. Use graph analysis algorithm to obtain the propagation depth and breadth of change, and use time series analysis method to obtain the trend characteristics of demand change. Extract schedule deviation risk characteristics, calculate the deviation between task completion rate and ideal completion rate, task delay degree, delayed task ratio, identify critical path task status, and calculate burn-down chart deviation; Extract code quality risk characteristics, count the number of defects and classify them according to severity level, and calculate defect density, code complexity, code duplication rate and code review pass rate; Extract test coverage and quality assurance features, calculate test coverage rate and test case pass rate, statistically analyze test failure frequency and failure mode, and calculate defect repair time and defect re-opening rate; Extract team collaboration and resource load characteristics, calculate team member load distribution and load balance, analyze communication records to count response time, count personnel changes, and identify the number and duration of blocked tasks. Extract external dependency risk characteristics, identify external dependencies and record dependency type, planned delivery time, and actual delivery time, calculate dependency latency rate, count interface call failure rate, and track external dependency change events.

4. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The construction of the risk identification model and risk identification rule base, and the identification of risk types and levels, include: The training dataset is constructed by extracting feature vectors from historical iterations as input samples and using actual risk events as labels. A multi-label classification method is used to identify risk types, an ensemble learning algorithm is used to build a base classifier, and model fusion technology is used to combine the prediction results of multiple base classifiers; a multi-classification or regression method is used to predict risk levels; and cross-validation is used to evaluate model performance. Based on the experience of domain experts and the analysis of historical risk cases, the structure of the rules is defined as a condition part and a conclusion part. The association rule mining method is used to discover rules that meet the preset minimum support and preset minimum confidence. Specialized rule subsets are constructed for different risk types, and priority and confidence are set for the rules.

5. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The setting of early warning thresholds and the real-time generation of early warning information include: Define an early warning level system, and set a threshold range for risk scores for each risk type and each early warning level; A dynamic threshold adjustment mechanism based on time dimension is introduced; an early warning mechanism based on trend judgment is introduced, which triggers an early warning when the risk score continues to rise over multiple consecutive time windows and the cumulative increase exceeds the preset increase threshold. When the risk score exceeds the warning threshold or the trend warning rule is triggered, a warning message is automatically generated. Based on the warning level and risk type, a notification strategy is adopted to determine the recipients and channels of the warning message.

6. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The construction of the adjustment strategy library, which involves matching and evaluating candidate strategies based on risk warning information, includes: Define a structured representation of the adjustment strategy, including strategy identifier, strategy name, risk type, warning level, preconditions, strategy action, expected effect, implementation cost, and constraints; For schedule risks, construct a set of schedule adjustment strategies; for quality risks, construct a set of quality improvement strategies; for requirement change risks, construct a set of requirement control strategies; for resource risks, construct a set of resource allocation strategies; and for external dependency risks, construct a set of dependency management strategies.

7. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The steps to obtain a risk response and adjustment plan include: Based on the risk type and warning level in the early warning information, applicable strategies are selected from the adjustment strategy library, the preconditions of the strategies are checked, and the case reasoning method is used to retrieve iterative cases with similar risk characteristics in the historical data warehouse to generate a candidate strategy set. For each candidate strategy, the expected results of strategy implementation are obtained by simulation, and the comprehensive score of each candidate strategy is obtained by multi-objective optimization algorithm, resulting in a list of recommended strategies. Check resource constraints, technical constraints, business constraints, and team constraints. Remove strategies that do not meet the constraints from the recommendation list or mark them as infeasible, and generate the final set of feasible strategies. Present a set of feasible strategies to project decision-makers, and develop an implementation plan for the selected strategies.

8. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The steps for obtaining the adjustment effect evaluation results include: Record the current moment as the adjustment baseline time point when the adjustment strategy begins to be executed, and save a complete snapshot at this time; After the adjustment was implemented, data was collected, and the changes in various indicators were obtained using the differential analysis method. Calculate risk mitigation effectiveness indicators, schedule improvement effectiveness indicators, resource utilization efficiency indicators, and adjustment cost indicators; Based on the analysis of key factors for successful adjustment strategies, update the success rate and recommendation priority of the corresponding strategies in the adjustment strategy library; The adjusted cases are used as new training samples to update the parameters of the risk identification model.

9. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The visualization and interactive simulation include: Design a dashboard view that uses different colored areas to represent different risk types, uses radar charts to show the overall situation of multi-dimensional risks, and uses a timeline to show warning events; It provides a strategy comparison matrix; provides strategy simulation functionality; and provides multi-strategy combination functionality to evaluate the overall effect and potential conflicts of the combination scheme.

10. The method for real-time early warning and adaptive adjustment of project iteration risks based on agile development according to claim 1, characterized in that, The establishment of the team collaboration mechanism and risk management knowledge base includes: Create a dedicated risk management channel or space in the team collaboration platform to automatically push early warning messages, adjustment plans, and execution progress; Provides structured risk discussion templates; supports online meeting integration, automatically initiating risk response meeting invitations when an alert is triggered; establishes a risk response responsibility matrix; Establish a risk management knowledge base to structurally store all risk events, early warning records, adjustment cases, and effectiveness evaluations; It tags and categorizes cases in the risk management knowledge base; supports case retrieval based on similarity; and extracts best practices and lessons learned in risk management.

Images