A cloud platform coordination method and system for elastic resource scheduling

Abstract

The application relates to the technical field of software development management, in particular to a cloud platform collaboration method and system for flexible resource scheduling, which comprises the following steps: dynamically collecting a development data source and a requirement document, determining a developer capability portrait based on the development data source, and determining a task requirement portrait based on the requirement document; inputting the updated developer capability portrait and the task requirement portrait into a preset matching model, and dividing received to-be-processed project tasks into a plurality of group subtask sets based on the updated preset matching model; and determining a developer matching scheme for each subtask in the subtask set by using an updated optimization algorithm. The application upgrades a static skill label into a quantifiable and updatable dynamic portrait, constructs an optimization function by taking multiple targets such as a skill matching degree, load balancing, a project priority and a collaboration cost, and realizes a specific implementation method for solving an optimal developer matching scheme for an atomic task.

Description

Technical Field

[0001] This application relates to the technical field of software development management, and in particular to a cloud platform collaboration method and system for elastic resource scheduling. Background Technology

[0002] With the increasing volatility of software project requirements and the normalization of remote collaboration, existing technologies face a core contradiction: traditional rigid manpower allocation cannot adapt to dynamic project changes, while emerging platforms have significant bottlenecks in intelligent matching and collaboration efficiency. Current software development resource scheduling mainly relies on the experience of human project managers or simple rules (such as filtering by skill tags), lacking the ability to dynamically optimize multiple dimensions such as personnel skill saturation, collaboration costs, and project priorities.

[0003] Currently, crowdsourcing development platforms based on skill tag matching perform initial screening using standardized skill tag libraries (such as Java / front-end / testing) and project requirement keywords, establishing a static association between developers and tasks. While these platforms address the information asymmetry problem, the matching granularity is coarse, making it impossible to quantify and assess collaboration compatibility (such as communication costs and work style fit). They provide online processes for requirement posting, bidding, and contract signing, but task decomposition, progress coordination, and quality control still heavily rely on manual intervention. For example, when collaborating across time zones, they lack automated asynchronous workflow optimization capabilities.

[0004] However, existing solutions are essentially information matching tools rather than intelligent scheduling systems. They cannot track resource load status in real time (such as developer workload), are difficult to dynamically adjust priorities among multiple projects, and lack the ability to predict collaboration risks (such as the probability of delays) through historical data. Summary of the Invention

[0005] In order to track resource load status (such as developer workload) in real time and enable dynamic priority adjustment among multiple projects, this application provides a cloud platform collaboration method for elastic resource scheduling.

[0006] Firstly, this application provides a cloud platform collaboration method for elastic resource scheduling, employing the following technical solution:

[0007] A cloud platform collaboration method for elastic resource scheduling includes the following steps:

[0008] Dynamically collect development data sources and requirements documents, and determine the developer capability profile based on the development data sources, and determine the task requirement profile based on the requirements documents;

[0009] The updated developer capability profile and the task requirement profile are input into the preset matching model, and the received project tasks to be processed are divided into several sets of sub-tasks based on the updated preset matching model.

[0010] The updated optimization algorithm is used to determine the developer matching scheme for each subtask in the subtask set;

[0011] A list of work plans is determined based on the developer matching scheme, and the corresponding sub-tasks are sent to the corresponding developers based on the list of work plans.

[0012] By adopting the above technical solutions, a dynamic capability profile construction method based on multi-source data fusion dynamically quantifies and updates algorithmic models based on multiple sources of data, such as code repositories and project management systems, to dimensions such as developer technical stack proficiency, domain experience, workload saturation, collaboration preferences, and historical delivery quality. This upgrades static skill tags into quantifiable and updatable dynamic profiles. Furthermore, a developer-task intelligent matching algorithm based on multi-objective optimization employs improved Pareto solution set search and other optimization algorithms to construct an optimization function with multiple objectives such as skill matching degree, load balancing, project priority, and collaboration cost. This provides a specific implementation method for solving the optimal developer matching scheme for atomic tasks.

[0013] In one embodiment, after sending the corresponding subtasks to the corresponding developers based on the work plan list, the following steps are also included:

[0014] The actual execution data is acquired in real time and input as feedback data into the model optimizer to update the developer capability profile and the preset matching model.

[0015] By adopting the above technical solution, a closed-loop optimization and evaluation system based on reinforcement learning is established. This system collects actual task execution data (such as progress and quality) and uses this data to optimize the matching model and scheduling strategy through reinforcement learning agent feedback, forming a specific method for a "execution-feedback-optimization" closed loop.

[0016] In one embodiment, the actual execution data is input as feedback data to the model optimizer to update the developer capability profile and the preset matching model, including the following steps:

[0017] The actual execution data is compared with the initial prediction data to obtain the execution deviation, and it is determined whether the execution deviation is within a preset threshold.

[0018] If the execution deviation is within a preset threshold, the corresponding subtask will be sent to the corresponding developer based on the work plan list;

[0019] If the execution deviation is not within the preset threshold, a retraining signal is generated, and the decision model is retrained based on the retraining signal to generate feedback rewards.

[0020] The internal parameters are adjusted based on the feedback rewards to update the developer capability profile and the preset matching model.

[0021] In one embodiment, after dynamically collecting development data sources and requirements documents, the following steps are included:

[0022] Based on the aforementioned development data source and requirement documents, computing nodes are determined according to role type to construct a hierarchical decision-making system, which includes a product requirement layer, a development execution layer, and a testing requirement layer.

[0023] Planning instructions are determined based on the product demand layer, and status signal feedback is determined based on the development execution layer;

[0024] The planning instructions and status signals are fed back into the core collaborative function to determine the work plan list.

[0025] In one embodiment, determining the developer matching scheme for each subtask in the subtask set using an updated optimization algorithm includes the following steps:

[0026] Construct a multi-objective optimization function, and determine the Pareto solution set based on the multi-objective optimization function;

[0027] The developer's capability profile and task requirement profile are compared to dynamically evaluate matching combinations, and a developer matching scheme is determined from the Pareto solution set based on preset weights.

[0028] In one embodiment, constructing a multi-objective optimization function includes the following steps:

[0029] The expression for the multi-objective optimization function is:

[0030] Maximize F(X)=[fskill(X),fbalance(X),-fcost(X)];

[0031] Where X represents a matching scheme, fskill represents the skill matching degree, fbalance represents the team load balancing degree, and fcost represents the estimated collaboration and management cost.

[0032] In one embodiment, determining the developer matching scheme for each subtask in the subtask set using an updated optimization algorithm includes the following steps:

[0033] Multiple scheduling agents are set up, and the scheduling matching strategies of different task developers are learned based on the scheduling agents to obtain the optimal scheduling strategy.

[0034] Based on the actual progress and quality of the project, feedback signals are determined, and the optimal scheduling strategy is learned based on the feedback signals to obtain a developer matching solution.

[0035] In one embodiment, determining the list of work plans based on the developer matching scheme further includes the following steps:

[0036] The type of flexible processing is determined based on the actual progress of the task, and the type of flexible processing includes horizontal scaling and vertical scaling.

[0037] If the elastic processing type is determined to be horizontal scaling, a cross-project scheduling signal is generated, and developers corresponding to low-priority projects are selected in the global projects based on the cross-project scheduling signal to determine the additional developers.

[0038] If the elastic processing type is determined to be vertical scaling, a time adjustment signal is generated, and the proportion of time invested is adjusted in real time according to the actual progress of the task based on the time adjustment signal.

[0039] By adopting the above technical solutions, a flexible resource scheduling mechanism that supports horizontal and vertical scaling is achieved. In a concurrent multi-project environment, the decision-making logic and execution process of dynamically allocating cross-project resources (horizontal scaling) and dynamically adjusting the task time of individual developers (vertical scaling) are realized.

[0040] In one embodiment, the process of selecting additional developers by filtering developers corresponding to low-priority projects in the global project pool based on the cross-project scheduling signal includes the following steps:

[0041] Based on the development data source and requirements document, multi-dimensional matching scores are calculated. A multi-attribute decision method is used to determine the comprehensive score for each candidate developer. The candidate developer with the highest comprehensive score is selected as the additional developer.

[0042] Secondly, this application provides a cloud platform collaborative system for elastic resource scheduling, which adopts the following technical solution:

[0043] A cloud platform collaboration system for elastic resource scheduling, executing the cloud platform collaboration method for elastic resource scheduling described in the first aspect, includes:

[0044] The resource perception and profiling layer is used to dynamically collect development data sources and requirement documents, and determine the developer capability profile based on the development data sources, and determine the task requirement profile based on the requirement documents.

[0045] The intelligent matching and decision-making layer is used to input the updated developer capability profile and the task requirement profile into the preset matching model, and divide the received project tasks to be processed into several sets of sub-tasks based on the updated preset matching model; and use the updated optimization algorithm to determine the developer matching scheme for each sub-task in the set of sub-tasks.

[0046] The elastic scheduling and execution layer determines a list of work plans based on the developer matching scheme, and sends the corresponding subtasks to the corresponding developers based on the list of work plans.

[0047] In summary, this application includes at least one of the following beneficial technical effects:

[0048] 1. It completely changes the existing technology's reliance on static skill tags for coarse-grained matching. By constructing refined developer capability profiles and task requirement profiles, and employing improved multi-objective optimization algorithms (such as Pareto solution set search) for collaborative decision-making, the system can find the optimal balance among multiple objectives such as skill matching, load balancing, project priority, and collaboration cost. This makes the matching results not only consider "can it be done?", but also optimize "who is more suitable to do it, when is it more efficient to do it, and how to collaborate at a lower cost," thereby raising the accuracy of resource and requirement matching to a new level and reducing project delays and quality risks caused by mismatched personnel skills or poor collaboration from the source.

[0049] 2. Addressing the characteristic of fluctuating software project requirements, this invention achieves true elastic scheduling. The system can monitor developer workload and project progress in real time, supporting dynamic resource allocation across projects ("horizontal scaling") and flexible adjustment of time invested by individual developers ("vertical scaling"). When high-priority tasks are inserted, the system can quickly perform global resource rearrangement to ensure the progress of the critical path. This dynamic adaptability overcomes the slow response of traditional fixed-team models, achieving global optimization and efficient turnover of enterprise-level human resource pools, significantly improving resource utilization and agility in responding to changing requirements.

[0050] 3. A closed-loop learning mechanism of "execution-feedback-optimization" has been introduced, which is not available in existing technology platforms. By continuously collecting data such as actual task completion time, code quality, and communication costs, and using this data feedback to adjust matching model parameters and optimize scheduling strategies, the system possesses the ability to learn and continuously improve itself. This allows the platform to continuously accumulate and solidify excellent project management experience, becoming increasingly intelligent with use. It not only improves the accuracy and predictability of scheduling but also provides data support for enterprise knowledge accumulation and process improvement. Attached Figure Description

[0051] Figure 1 This is a block diagram of a cloud platform collaboration method for elastic resource scheduling provided in an embodiment of this application;

[0052] Figure 2 This is a schematic diagram of a cloud platform collaborative system for elastic resource scheduling provided in an embodiment of this application;

[0053] Figure 3 This is a flowchart of the developer-task multi-objective matching engine workflow provided in the embodiments of this application;

[0054] Figure 4 This is a schematic diagram of the elastic resource scheduling mechanism provided in the embodiments of this application;

[0055] Figure 5 This application provides a flowchart for closed-loop optimization and evaluation. Detailed Implementation

[0056] To better understand the purpose, technical solutions, and advantages of this application, it has been described and illustrated below with reference to the accompanying drawings and embodiments. However, those skilled in the art should understand that this application can be implemented without these details. In some cases, to avoid obscuring various aspects of this application due to unnecessary description, well-known methods, processes, systems, components, and / or circuits already described at a higher level will not be elaborated upon. It will be apparent to those skilled in the art that various modifications can be made to the embodiments disclosed in this application, and the general principles defined in this application can be applied to other embodiments and application scenarios without departing from the principles and scope of this application. Therefore, this application is not limited to the illustrated embodiments, but conforms to the broadest scope consistent with the scope of protection claimed in this application.

[0057] This application discloses a cloud platform collaboration method for elastic resource scheduling. Based on a cloud platform collaboration system for elastic resource scheduling, the system includes a resource perception and profiling layer, an intelligent matching and decision-making layer, an elastic scheduling and execution layer, and a performance feedback and optimization layer. Through a four-layer closed-loop architecture, a collaborative system integrating resource profiling, intelligent matching, elastic scheduling, and closed-loop optimization is built, enabling efficient and dynamic allocation of human resources such as product, development, and testing in software development projects. Simultaneously, through multi-objective intelligent matching algorithms, dynamic elastic scheduling mechanisms, and data-driven closed-loop optimization, it achieves a leap from "simple matching" to "intelligent optimization" of software development human resources, significantly improving resource utilization, project delivery efficiency, and management sophistication. The technical solution will be described in detail below with reference to the accompanying drawings. Example 1

[0058] Reference Figure 1A cloud platform collaboration method for elastic resource scheduling includes the following steps:

[0059] S101 dynamically collects development data sources and requirements documents, and determines the developer capability profile based on the development data sources and the task requirement profile based on the requirements documents.

[0060] The data sources for development include code repositories (such as Git) and project management systems (such as Jira). Developer proficiency profiles include technical stack proficiency (such as Java, Python), domain experience (such as finance, e-commerce), current workload saturation, collaboration preferences (such as asynchronous communication ability), and historical delivery quality (such as code defect rate). Requirements documents include PRDs, and task requirement profiles include the technical requirements, complexity level, priority, dependencies, and estimated workload of the task.

[0061] Specifically, combined Figure 2 The system dynamically collects and constructs two core profiles: resource awareness and profiling. The first is the developer capability profile, which quantifies a developer's technical stack proficiency (e.g., Java, Python), domain experience (e.g., finance, e-commerce), current workload saturation, collaboration preferences (e.g., asynchronous communication ability), and historical delivery quality (e.g., code defect rate) by analyzing data sources such as code repositories (e.g., Git) and project management systems (e.g., Jira). The second is the task requirement profile, which extracts the technical requirements, complexity level, priority, dependencies, and estimated workload of a task by parsing requirement documents (e.g., PRDs) and task breakdowns (e.g., WBS).

[0062] It's important to note here that dynamically collecting development data sources and requirements documents specifically involves using the GitPython library to extract metrics such as commit frequency and code complexity for code repository analysis. Prometheus is used to collect system metrics like CPU / memory usage for real-time load monitoring. The formula for calculating technical stack proficiency is:

[0063] Proficiency = ∑(Project weight × Technology usage time) / Total project time.

[0064] Project weight is a coefficient that measures the importance or complexity of a project's contribution to an individual's skills. The weight is typically determined by the following factors (which can be selected individually or comprehensively in the specific calculation): project size, technical complexity, business importance, and the individual's role. Project size can be confirmed based on lines of code, number of modules, team size, etc. Technical complexity is mainly confirmed by whether it includes core architecture design, high-performance optimization, or exploration of new technologies. Business importance can be determined by whether the project belongs to a core business system and the amount of online traffic. The individual's role can be confirmed from multiple aspects such as leading development, core development, or auxiliary development. For example, leading development might be weighted at 1.2, core development at 1.0, and participating in some modules at 0.6.

[0065] Assuming Project A involves the restructuring of the company's core system, as a core developer, the weight could be set to 1.2. Project B is the development of internal tools; as an auxiliary developer, the weight could be set to 0.7. Weights are typically assigned by technical managers, based on historical data analysis, or by fixed rules to differentiate the value of experience from different projects when calculating proficiency.

[0066] Technology usage duration refers to the actual length of time a particular technology is used within a project. For example, if Project A lasted 6 months, with Python used for the entire 6 months and Redis used for the last 3 months, then the technology usage duration for Project A is: Python used for 6 months, and Redis used for 3 months.

[0067] Assuming there are only two projects, Project 1 and Project 2, Project 1 has a total duration of 10 months and a weight of 1.2, with 10 months spent using Java and 8 months using MySQL. Project 2 has a total duration of 6 months and a weight of 0.8, with 6 months spent using Java and 2 months using MySQL. Calculations show that the contribution to Java proficiency is 1.05, and the contribution to MySQL proficiency is 0.7. Project weights reflect the difference in contribution to skill growth based on the importance and complexity of the project. Technology usage time reflects the actual time you spent using the technology within that project. Proficiency is the sum of all factors (project weight × time spent using the technology within that project), divided by your total time across all projects, avoiding the problem of simply adding up time and ignoring differences in project quality.

[0068] The formula for calculating load saturation assessment is as follows:

[0069] Saturation = (Current number of tasks + Queued number of tasks) / Maximum concurrency capacity.

[0070] A higher saturation level indicates a heavier load and more strained resources, potentially leading to performance degradation, increased latency, or the need for expansion / increased manpower. The current task count refers to the number of tasks being processed. For the server, this means the number of requests currently being processed (e.g., data queries, API calls). For engineers, it means concurrent work orders, development tasks, meetings, etc. The queued task count refers to the number of tasks that have arrived but not yet been processed. For the server, this means requests waiting in the queue (e.g., requests waiting to be forwarded by Nginx, messages waiting to be consumed in the message queue). For engineers, this means tasks assigned in the to-do list but not yet started.

[0071] Maximum concurrency capacity refers to the maximum number of tasks a system or person can handle simultaneously while ensuring service quality (such as response time and stability). For servers, it refers to the optimal number of concurrent connections or peak QPS obtained through stress testing (not the ultimate crash value, but the performance inflection point). For engineers, it refers to the maximum number of tasks that can be processed simultaneously, estimated based on historical work efficiency (e.g., one person can handle a maximum of 3 tasks at the same time; exceeding this will result in decreased efficiency).

[0072] For example, suppose the web server is currently processing 120 requests and there are 30 queued requests. After stress testing, the maximum concurrency capacity (performance inflection point) is 200 requests. The corresponding saturation is (120+30) / 200=150 / 200=0.75, which is 75% load, with some margin.

[0073] Suppose that the development engineer is currently performing 2 tasks (coding + meeting), and has 4 tasks in the queue (requirement review, bug fixing, documentation, etc., which are scheduled but have not yet started). The engineer's maximum concurrency capacity (empirical value) is 3 tasks (efficiency will drop significantly if this is exceeded). The saturation level is (2+4) / 3=6 / 3=2.0, which is 200% load, which is severely overloaded and requires load reduction or task scheduling adjustment.

[0074] S102, input the updated developer capability profile and task requirement profile into the preset matching model, and divide the received pending project tasks into several sets of sub-tasks based on the updated preset matching model.

[0075] S103, use the updated optimized algorithm to determine the developer matching scheme for each subtask in the subtask set.

[0076] The pre-set matching model refers to a multi-objective optimization matching engine, an algorithmic model that has been pre-trained and encapsulated with matching logic and rules. It receives updated developer capability profiles and task requirement profiles as data sources. Based on these two types of input profiles, it calculates and understands who is suitable for what. Furthermore, the pre-set matching model internally defines a series of rules on how to calculate skill matching degree, how to assess workload, and how to balance different objectives (such as skills vs. cost). The model's structure, objective function (such as maximizing overall matching degree and minimizing collaboration cost), and initial parameters are pre-designed, but its internal knowledge (i.e., judgment criteria) is continuously updated through performance feedback and optimization layers; therefore, it is referred to as the updated pre-set matching model. Pending project tasks refer to newly entered complete projects or large requirements waiting to be assigned and executed.

[0077] A subtask set is a group of logical tasks generated by a pre-defined matching model after intelligently decomposing the tasks in a project. This decomposition is not arbitrary but rather an optimized breakdown based on the current resource profile (developer capabilities). The core idea is to determine how to divide the large task pool into smaller parts within the existing team capability structure to achieve optimal overall allocation. A subtask set may contain multiple highly related atomic tasks suitable for completion by one or a group of developers with specific skills. For example, a front-end subtask set might include UI component development and page interaction logic. A back-end payment interface subtask set might include encryption algorithm implementation and reconciliation logic development.

[0078] The developer matching scheme provides optimal assignment recommendations for each specific subtask in the subtask set, calculated by an optimization algorithm. It not only recommends who should perform the task but also includes scheduling information such as start time and estimated duration. The developer matching scheme's decision-making is multi-objective, comprehensively considering skill matching, load balancing, project priority, and collaboration costs. Skill matching refers to whether the developer's technical stack matches the task requirements; load balancing avoids situations where some developers are overloaded while others are idle; project priority prevents high-priority tasks from being assigned to high-quality or idle resources; and collaboration costs aim to allocate tasks requiring frequent communication to developers with similar time zones and work habits.

[0079] The project tasks received by the intelligent matching and decision-making layer are decomposed into atomic subtasks, which are then processed by a multi-objective optimization matching engine. This engine comprehensively considers multiple objectives such as skill matching, load balancing, project priority, and collaboration costs (e.g., time zone differences), and uses an improved optimization algorithm to calculate the optimal developer matching scheme for each subtask. Through model decomposition and algorithm matching, the system achieves intelligent mapping from a large project to a specific person performing a specific task, and this process dynamically considers the overall capability profile of the current team.

[0080] It's important to note the following calculations: Skill matching degree calculation: Matching degree = (∑(Required skill weight × Developer skill level)) / Total required weight. Load balancing degree assessment: Load balancing degree = 1 - (Standard deviation (Developer load) / Average load). Collaboration cost quantification: Collaboration cost = Communication frequency × Time zone difference coefficient + Number of historical collaboration conflicts × Conflict weight.

[0081] S104: Determine the work plan list based on the developer matching scheme, and send the corresponding sub-tasks to the corresponding developers based on the work plan list.

[0082] The work plan list is a scheduled task list generated based on the developer matching scheme. It is an execution-oriented list that includes specific times and action instructions. It is not just an allocation table of who does what, but an executable plan of who does what, when, in what order, and what.

[0083] The Elastic Scheduling and Execution Layer is responsible for executing scheduling decisions, generating specific work plans, and notifying relevant developers via message queues or APIs. This layer receives developer matching schemes (including task-developer pairs) from the decision-making layer, reads the existing work plans of each matched developer (i.e., the tasks they are already working on), and calculates their actual idle time slots. New tasks are globally prioritized based on their project priority and urgency. High-priority tasks may preempt lower-priority tasks, triggering dynamic adjustments (i.e., elastic scheduling). This layer supports elastic scaling; for example, when a high-priority task urgently needs resources, the system can dynamically adjust the resource allocation for lower-priority tasks or initiate cross-project resource borrowing. Finally, it generates a personal to-do list for each developer and a global project Gantt chart or team dashboard for the project manager.

[0084] Step S103 uses the updated optimization algorithm to determine the developer matching scheme for each subtask in the subtask set, including the following steps:

[0085] S105, construct a multi-objective optimization function, and determine the Pareto solution set based on the multi-objective optimization function.

[0086] S106 compares the developer's ability profile with the task requirement profile to dynamically evaluate matching combinations and determine the developer matching scheme from the Pareto solution set based on preset weights.

[0087] Specifically, combined Figure 3 The developer-task multi-objective matching engine is based on an improved Pareto solution set search algorithm, simultaneously optimizing multiple conflicting objectives. The expression for the multi-objective optimization function is:

[0088] Maximize F(X)=[fskill(X),fbalance(X),-fcost(X)].

[0089] Here, X represents a matching scheme, fskill represents the skill matching degree, fbalance represents the team load balancing degree, and fcost represents the estimated collaboration and management cost. The goal is to find the Pareto solution set that simultaneously optimizes these three objectives while satisfying constraints (such as task deadlines and developer availability). The matching engine compares the task requirement profile with the developer capability profile. The improved optimization algorithm dynamically evaluates a large number of possible matching combinations and selects the final best matching scheme from the Pareto solution set based on the weights preset by the project administrator (e.g., emphasizing fskill during critical phases and emphasizing fbalance during stable phases). This method overcomes the limitations of simple rule matching or single-objective optimization.

[0090] It's important to note that the multi-objective optimization engine implementation specifically includes a task decomposition logic tree module and a multi-objective optimization engine module. The goal of the task decomposition logic tree is to transform macro-level requirements into atomic tasks that meet the execution standards of edge nodes. The multi-objective optimization engine module is responsible for dynamically and efficiently allocating atomic tasks to developers at edge nodes. The task decomposition logic tree primarily implements functional dependency analysis and task atomic decomposition. Functional dependency analysis analyzes user stories and requirement documents, identifies completion-start dependencies between tasks, and constructs a directed acyclic graph (DAG). Finally, it determines all possible (or optimal) execution sequences. Task atomic decomposition applies the following standards to each node (coarse-grained task) in the DAG: duration, skill singularity, and verifiability. The duration standard uses methods such as three-point estimation to ensure that the estimated duration of the decomposed subtasks is ≤4 hours. The skill singularity standard ensures that each task requires ≤3 core technologies (e.g., "Java + Spring + MySQL") when splitting subtasks. Verifiability standards define a clear completion definition for each task, such as "API interfaces achieve 80% unit test coverage" or "UI components pass visual regression testing".

[0091] The multi-objective optimization engine module receives a queue of atomic tasks to be scheduled (including priority, skill requirements, and duration). It also receives the current task load and skill vectors of all developers (e.g., {Java:0.9, Python:0.7,...}). Skill matching is then used for filtering; the matching degree is calculated using the following formula:

[0092] Matching degree = (Task-required skill vector · Developer skill vector) / (Task skill vector magnitude). Only developers with a matching degree ≥ 80% are retained to form a "candidate assignment list". If a task has no candidates, it is marked as blocked and returned to the cloud center for replanning or skill upgrade.

[0093] Construct an optimization model, where the decision variable is: X_ij (task i is assigned to developer j, 0 or 1).

[0094] The multi-objective function includes maximizing overall efficiency and maximizing load balancing. Maximizing overall efficiency is Σ(matching degree_ij*X_ij). Maximizing load balancing means minimizing the standard deviation of the load of all developers. Load calculation: New load for developers = Current load + Σ(Task i duration *X_ij). Next, soft constraints are applied, mainly based on the load balancing degree. Specifically, the balancing degree = 1 - (Standard deviation of developer load / Average load). The balancing degree is used as one of the optimization objectives, or it is converted into a penalty term and added to the objective function to guide the system to adjust the load within the ideal range [0.7, 0.9]. Finally, a multi-objective optimization algorithm is used to solve for the Pareto optimal solution set. Multi-objective optimization algorithms include heuristic algorithms and / or rule-based + greedy algorithms. Heuristic algorithms, such as NSGA-II (genetic algorithm), are suitable for scenarios with large task scales and non-extreme real-time requirements. Rule-based + greedy algorithms, in scenarios with strong real-time requirements, select developers with the highest matching degree for each task, whose load does not exceed the limit after allocation, according to priority. Decision-makers or systems can select the solution that best suits their current strategy (such as "keeping the schedule" or "preventing overload") from the solution set.

[0095] After edge nodes execute atomic tasks, they generate actual time consumption data, which is used to revise the task decomposition estimation model. Real-time monitoring of developers' actual workload (psychological load, context switching costs) is used to calibrate the load calculation model of the optimization engine, track tasks blocked due to skill mismatches, and drive management decisions on whether to conduct personnel training (improving skill vectors) or adjust the granularity of task decomposition. Based on historical scheduling results (on-time completion rate, team satisfaction), the weight parameters of the optimization algorithm are automatically adjusted to better align with the organization's actual situation.

[0096] Combination Figure 4 In step S104, determining the work plan list based on the developer matching scheme also includes the following steps:

[0097] S107, determine the flexible processing type based on the actual progress of the task. Flexible processing types include horizontal scaling and vertical scaling.

[0098] S108. If the elastic processing type is determined to be horizontal scaling, a cross-project scheduling signal is generated, and the developers corresponding to low-priority projects are selected in the global projects based on the cross-project scheduling signal to determine the additional developers.

[0099] S109, if the elastic processing type is determined to be vertical scaling, a time adjustment signal is generated, and the proportion of time invested is adjusted in real time according to the actual progress of the task based on the time adjustment signal.

[0100] Appendix Figure 4 This demonstrates the system's dynamic resource allocation capabilities in a multi-project concurrent environment. Horizontal and vertical scaling allow for fine-grained resource adjustments. Vertical scaling refers to dynamically adjusting the proportion of time a single developer dedicates to a task based on its actual progress (e.g., from 50% to 80%). Horizontal scaling refers to intelligently adding developers to a project from the platform's global resource pool based on matching factors when a single project's resources are insufficient. The core innovation of cross-project collaborative scheduling lies in using a distributed constraint optimization algorithm to solve the cross-project resource scheduling model. When multiple projects compete for the same critical resource (e.g., an architect), the system can achieve optimal global resource utilization while ensuring the core progress and data isolation of each project. The diagram visually illustrates this collaborative borrowing relationship using dashed arrows between different project resource pools.

[0101] It's important to note that the horizontal scaling algorithm primarily evaluates the merits of each allocation scheme, typically considering multiple metrics (such as total completion time, cost, and load balancing). It identifies non-dominated solutions (Pareto optimal solutions) in the current population, which are superior to other solutions on at least one objective and no worse on others. Genetic operations, such as crossover or mutation, are performed on the Pareto front solutions. Crossover combines the characteristics of two solutions, while mutation randomly alters certain parts of the solution. New candidate solutions (offspring) are generated, and superior individuals are selected from both the parent and offspring generations to form the next generation of the population, maintaining a constant population size. Finally, the optimal task allocation scheme found is returned. Vertical scaling control is based on a PID controller that dynamically adjusts resource allocation: Adjustment = Kp × Schedule Deviation + Ki × Cumulative Deviation + Kd × Deviation Change Rate.

[0102] It's important to clarify the consistency of time features and the implementation steps. The system ensures consistency of time features through the following methods: A unified timestamp service is used, with all data collection points employing a distributed clock synchronization protocol to ensure time consistency during cross-timezone collaboration. The time sequence alignment algorithm uses Dynamic Time Warping (DTW) to align multi-source asynchronous data streams, as shown in the formula. The version control mechanism generates a timestamped snapshot for each task state change, supporting backtracking verification.

[0103] Example of specific implementation steps: Taking the "user login function development" task as an example, the steps are as follows: Requirements analysis phase: Identify the time constraint of "completing the login function within 30 minutes" using NLP. Task decomposition phase: Break down the login function into front-end components (15 minutes) + back-end interfaces (15 minutes). Resource matching phase: Dynamically adjust time allocation based on the developer's real-time load. Execution monitoring phase: Collect progress data every 5 minutes to ensure the time target is achieved. Example 2

[0104] refer to Figure 2 Unlike Example 1, after sending the corresponding subtasks to the corresponding developers based on the work plan list, the following steps are also included:

[0105] S201 acquires actual execution data in real time and inputs it as feedback data into the model optimizer to update the developer capability profile and the preset matching model.

[0106] Specifically, the system monitors actual task execution data (such as completion progress, code quality, and communication frequency) and uses this as feedback data to input into the model optimizer. This data is then used to adjust and update the resource profile and matching model, forming a closed loop of continuous learning. The model optimizer is a software module that integrates data analysis, model training, and parameter tuning algorithms. Its core responsibility is to receive real-world feedback data during task execution and use this data to calibrate and improve the accuracy and effectiveness of the system's two core components—the developer capability profile and the pre-set matching model—thereby forming a closed-loop learning system.

[0107] In step S201, the actual execution data is input as feedback data to the model optimizer to update the developer capability profile and the preset matching model, including the following steps:

[0108] S202, perform deviation analysis between the actual execution data and the initial prediction data to obtain the execution deviation, and determine whether the execution deviation is within the preset threshold.

[0109] S203 If the execution deviation is within the preset threshold, the corresponding subtask will be sent to the corresponding developer based on the work plan list.

[0110] S204 If the execution deviation is not within the preset threshold, a retraining signal is generated, and the decision model is retrained based on the retraining signal to generate feedback rewards.

[0111] S205 adjusts internal parameters based on feedback rewards to update developer capability profiles and preset matching models.

[0112] Initial prediction data refers to the system's estimate or expected value based on its existing knowledge (profiles and models) before the task begins (matching and decision-making layers). Execution deviation is the quantitative difference between the actual execution data and the initial prediction data, including time deviation, quality deviation, collaboration deviation, and result deviation. Time deviation = Actual time consumed - Estimated time. Quality deviation = Actual number of defects / rate - Estimated defect level. Collaboration deviation = Actual communication cost - Estimated collaboration cost. Result deviation is obtained based on the difference between the final delivery and the expected outcome. Preset thresholds are acceptable error ranges set by system administrators and / or domain experts; specifically, they act as a buffer filter. Preset thresholds allow for different thresholds for different task types and priorities (e.g., stricter time deviation thresholds for high-priority tasks), and separate thresholds are set for different dimensions such as time and quality. Thresholds reflect the business's requirements for "predictability" and "stability," distinguishing between "normal fluctuations" and "abnormal signals." Deviations within the threshold are considered acceptable real-world noise. Deviations exceeding the threshold are considered significant deviations in system perception, requiring intervention.

[0113] A retraining signal is a trigger event or flag automatically generated by the system when the execution deviation exceeds a preset threshold. The signal includes information such as which task is involved, what type of deviation (e.g., "time deviation exceeds threshold"), and which developers are involved. Depending on the severity of the deviation, the signal may carry different levels of urgency. The retraining signal is a learning instruction issued by the system after self-diagnosis.

[0114] Feedback rewards are a quantitative score used during the retraining process of a decision-making model (especially when using a reinforcement learning framework) to evaluate the quality of historical decisions. They are calculated based on the magnitude and direction of the execution bias. Negative rewards (penalties) occur when the actual result is significantly worse than the prediction (e.g., severe timeouts, quality incidents). The greater the bias, the heavier the penalty. Positive rewards (rewards) occur when the actual result is better than the prediction (e.g., early and high-quality completion). Positive rewards are intended to encourage the system to discover and promote better matching strategies.

[0115] Decision model retraining refers to rerunning the model training algorithm (such as backpropagation in neural networks or policy gradient updates in reinforcement learning) using an augmented dataset containing new feedback (rewards) to generate an updated model. It typically involves fine-tuning the existing model rather than training from scratch to preserve existing knowledge. Targeted training can be performed for specific task types or developer groups that may cause bias. The training process usually runs in the background and does not affect the real-time matching of the online system.

[0116] Internal parameter tuning is the specific mathematical implementation of the retraining process; that is, the model automatically modifies its internal weights and values ​​based on feedback rewards. In a preset matching model, this might involve adjusting the weight coefficients between different optimization objectives (skill matching, load balancing) or adjusting the function parameters used to calculate the matching degree. In a developer competency profile, it involves directly modifying specific values ​​within the profile, for example:

[0117] If a developer repeatedly times out on a certain type of task, their proficiency score for the corresponding technology stack can be lowered, or their personal plan buffer coefficient can be increased. If the complexity of a certain type of task is systematically underestimated, the mapping parameters of the complexity feature in the task profile can be updated.

[0118] Adjusting internal parameters based on feedback rewards to update developer capability profiles and preset matching models enables automation, data-driven approaches, and clear objectives (the objective is to maximize long-term cumulative rewards, i.e., optimal overall performance).

[0119] Specifically, combined Figure 5 The system's continuous self-learning mechanism is described. Scheduling and matching decisions are not the end point. The system tracks the actual execution of tasks for each developer in real time, including progress, quality, and communication costs. This data is compared with the initial predictions. If significant deviations occur (e.g., a certain type of task is completed much more efficiently than expected by developers with specific technical skills), the feedback optimization layer triggers retraining of the decision model. Reinforcement learning agents adjust internal parameters based on feedback rewards (e.g., positive rewards for "early delivery" and negative rewards for "delay"), updating their understanding of developer capabilities and task difficulty. This allows the system to adapt to changes in the technology stack and the growth of team capabilities, becoming increasingly intelligent with use.

[0120] This invention comprises four core mechanisms: a hierarchical closed-loop architecture, intelligent matching based on multi-objective optimization, refined elastic scaling and cross-project collaboration, and data-driven continuous optimization. Together, these mechanisms form an efficient, intelligent, and adaptive software development human resource scheduling solution. Example 3

[0121] Unlike Example 1, this solution draws on the layered concepts of "edge-to-device (edge) collaboration" and "edge-to-cloud collaboration" in space-ground integrated networks, mapping them to the software development resource scheduling scenario. The "product-development-testing" roles can be viewed as different computing nodes, constructing a layered decision-making system. After dynamically collecting development data sources and requirement documents, the following steps are included:

[0122] S301 determines the computing nodes according to role type based on the development data source and requirements document to build a hierarchical decision-making system, which includes the product requirements layer, the development execution layer, and the testing requirements layer.

[0123] S302 determines planning instructions based on the product requirement layer and status signal feedback based on the development execution layer.

[0124] S303 inputs planning instructions and status signal feedback to the core collaborative function to determine the work plan list.

[0125] In this context, computing nodes, analogous to computing units in distributed computing, refer to work units with different roles in software development resource scheduling scenarios. Each node possesses specific computing (processing) capabilities and states. Computing nodes include product role nodes, development role nodes, and testing role nodes. Product role nodes are responsible for requirements analysis, value judgment, and priority calculation. Development role nodes are responsible for code implementation, technical solution design, and task execution. Testing role nodes are responsible for quality verification, test case design, and defect identification.

[0126] Planning instructions refer to the output instructions of the product demand layer (cloud center). Planning instructions include strategic instructions, tactical plans, and constraints. Strategic instructions refer to business objectives, investment directions, and value prioritization. Tactical plans refer to Epic decomposition, priority queues, and delivery milestones. Constraints refer to time windows, resource budgets, and quality baselines.

[0127] Status signal feedback specifically refers to the real-time status of the development execution layer and the testing requirement layer. Status signal feedback includes progress signals, quality signals, resource signals, and risk signals. Progress signals specifically refer to task completion rate, burn-down chart data, and code commit frequency. Quality signals include defect density, test pass rate, and code coverage. Resource signals include developer workload, skill gaps, and collaboration costs. Risk signals include bottlenecks, technical debt, and dependency delays.

[0128] For example, macro-level task planning and prioritization can be carried out at the product requirement level (similar to a "cloud center"), while agile self-scheduling within small teams can be achieved at the development execution level (similar to "edge nodes"), and global resource coordination can be carried out through "collaboration functions". The advantage of this approach is that it has a clear structure, conforms to the existing organizational structure of most software companies, and has less resistance to implementation. However, its globality and efficiency in scheduling optimization may not be as good as the unified optimization model of this invention. Example 4

[0129] Unlike Example 1, the core of this approach is to replace the multi-objective optimization algorithm used in this invention with a reinforcement learning algorithm (such as an improved deep Q-network). The updated optimization algorithm is used to determine the developer matching scheme for each subtask in the subtask set, including the following steps:

[0130] S401 sets up multiple scheduling agents and learns the scheduling matching strategies of different task developers based on the scheduling agents in order to obtain the optimal scheduling strategy.

[0131] S402 determines feedback signals based on the actual progress and quality of the project, and learns the optimal scheduling strategy based on the feedback signals to obtain a matching solution for developers.

[0132] In a reinforcement learning framework, a scheduling agent is an autonomous program entity capable of perceiving the state of the environment, making decisions (scheduling actions), and learning from environmental feedback to achieve long-term goals. Each agent can be designed as a scheduling expert responsible for a specific type of resource or task. For example, a task-type agent might learn how to schedule urgent front-end tasks, while another learns how to schedule back-end data tasks. A developer group agent learns how to assign tasks to senior Java developers. Project / team agents exist for each project or team, learning the optimal scheduling logic within that project. Each agent has its own observation space, action space, and policy network, allowing for independent learning and decision-making. Multiple agents coexist in the same environment (the entire R&D organization). Their goals may align (improving overall efficiency) or they may compete for resources (competing for top developers). The system needs mechanisms (such as collaborative learning and credit allocation) to enable them to cooperate. Decomposing the complex global scheduling problem into multiple parallel, more targeted sub-problems avoids the curse of dimensionality when a single agent faces an extremely large state space.

[0133] It should be noted that the formation process of each agent uses different data for training depending on its function. The specific formation process of the agent uses existing technology, which will not be elaborated on here.

[0134] The scheduling matching strategy is the core decision-making logic within a single scheduling agent, a function that maps "state" to "action." It determines the scheduling choice the agent makes after observing the current situation. The snapshot of the environment observed by the agent may include: the queue of pending subtasks, the current state and capability profiles of relevant developers, the overall team load, project priorities, etc. The specific scheduling suggestions made by the agent are, for example, "assign task T to developer D" or "promote the priority of task T." This can be a simple rule table (if-then) or a complex deep neural network (commonly used). In reinforcement learning, the policy is usually represented by π(a|s), which is the probability distribution of choosing action a in state s. Learning different tasks means that the system trains different agents, each focusing on learning the specific policies of its responsible domain. For example, the agent responsible for the "technical debt" task will tend to assign the task to developers with refactoring experience and less current development pressure. The optimal scheduling strategy is the scheduling matching strategy that maximizes long-term global benefits under a given optimization objective.

[0135] Global optimality is not a local or short-sighted decision; the optimal strategy considers the long-term impact of a task allocation on subsequent tasks, other projects, and team morale. It seeks the optimal balance of total output, quality, and efficiency for the entire organization over a period of time (such as a quarter). Multi-dimensional goal fusion means that the optimal strategy implicitly balances multiple goals such as skill matching, load balancing, project prioritization, collaboration costs, and knowledge transfer. These goals are integrated into the design of the reward function in reinforcement learning. The optimal strategy is not static; it evolves as team capabilities change and business priorities shift. Therefore, the optimal scheduling strategy learned based on feedback signals, as described in S402, is a continuous approximation process, not a one-time endpoint.

[0136] In reinforcement learning, feedback signals are scalar numerical evaluations returned by the environment to the agent after it performs an action (scheduling decision). Feedback signals include positive signals (rewards), negative signals (penalties), and neutral or minor rewards / penalties. A positive signal (reward) indicates that the task is completed ahead of schedule / on time (progress) + a defect rate below standard (quality) → high reward. A negative signal (penalty) indicates that the task is severely delayed (progress) + an online incident occurs (quality) → high penalty. Neutral or minor rewards / penalties are adjustments for slight deviations.

[0137] The design of feedback signals is the soul of a system's success. It must accurately translate the highest business objective (such as rapidly delivering high-quality software) into a mathematical form that the agent can understand and optimize. The quality of a scheduling decision may not be known until long after the task is completed (delayed feedback). The system needs mechanisms (such as temporal difference learning) to correctly attribute the final success or failure (assigning credit) to a series of early scheduling decisions.

[0138] The developer matching scheme is the final output of the entire multi-agent system working together; it is an executable matching decision applied to the specific task to be processed.

[0139] When a new task arrives, the relevant scheduling agents, based on the current environment state and using their learned optimal or exploratory strategies, each propose a matching suggestion. These suggestions are then aggregated, arbitrated, or voted on through a higher-level coordinator or inter-agent communication mechanism, ultimately forming a consistent, globally optimal, or suboptimal developer matching scheme.

[0140] In a single-model system, the matching scheme is calculated by a central model. In a multi-agent system, the matching scheme is the result of "collective wisdom" generated by multiple distributed experts through interaction and collaboration based on their respective expertise. This approach is more robust (one agent's mistake does not affect the overall system) and flexible.

[0141] It should be noted that the implementation steps of the distributed constraint optimization algorithm are as follows: the first step is problem modeling, where each project is modeled as an intelligent agent and resource conflicts are modeled as constraints.

[0142] Priority quantification methods establish a priority scoring model: Priority Score = α × Business Value + β × Urgency + γ × Strategic Importance. Where α + β + γ = 1, and the weights are dynamically adjusted according to the company's strategy. In multi-objective optimization, higher-priority tasks receive higher weights in the objective function: f_priority(x) = Priority Score × Task Importance Coefficient. Priority thresholds are set in Pareto's multi-solution screening.

[0143] Specifically, the system models the resource scheduling environment as a Markov decision process. The agent (scheduling system) learns the optimal scheduling strategy by continuously trying different task-developer matching strategies and based on feedback signals (rewards) such as actual project progress and quality. The advantage of this approach lies in its powerful online learning and adaptability to dynamically changing environments, making it particularly suitable for agile development scenarios with frequent changes in requirements and high uncertainty. However, its challenge lies in the need for a large amount of exploratory data in the early stages of training, and the fact that the model's decision-making process may not be as intuitive and interpretable as optimization algorithms. Example 5

[0144] Unlike Example 1, this scheme focuses on optimizing the matching process itself, and can introduce concepts such as "task latency matching degree" and "task balance matching degree". Determining the work plan list based on the developer matching scheme also includes the following steps:

[0145] S501 determines the flexible processing type based on the actual progress of the task. Flexible processing types include horizontal scaling and vertical scaling.

[0146] S502, if the elastic processing type is determined to be horizontal scaling, a cross-project scheduling signal is generated, and the developers corresponding to low-priority projects are selected in the global projects based on the cross-project scheduling signal to determine the additional developers.

[0147] S503 If the elastic processing type is determined to be vertical scaling, a time adjustment signal is generated, and the proportion of time invested is adjusted in real time according to the actual progress of the task based on the time adjustment signal.

[0148] Among them, elastic processing types include horizontal scaling and vertical scaling, borrowing a clever analogy from the concept of elastic scaling in cloud computing to the field of human resource scheduling.

[0149] Horizontal scaling essentially involves increasing or decreasing the number of parallel processing units. In a human resources context, this means increasing or decreasing the number of people involved in the same task. This is useful when a task is significantly behind schedule and it's determined that adding more people can speed things up. For example, when a web service experiences a surge in traffic, more server instances are automatically launched to distribute the load. Vertical scaling, on the other hand, involves adjusting the resource allocation intensity or priority of individual processing units. In a human resources context, this means adjusting the proportion of time and focus that existing developers dedicate to the task. This is useful when a task is slightly off schedule, or when the nature of the task is unsuitable for multi-person collaboration (such as developing highly coupled core modules), or when a temporary sprint is needed. For example, dynamically adjusting the CPU / memory allocation of the same server based on demand.

[0150] Based on the deviation between the actual progress and the plan, the parallelizability of the task, the current team structure, and the project stage, the system automatically determines the appropriate intervention type using a rule engine or classification model. For example, a front-end module that is severely behind schedule from the outset and can be developed independently might trigger horizontal scaling. Conversely, a core back-end service that has entered the final integration testing phase is more likely to trigger vertical scaling.

[0151] Cross-project scheduling signals are instructions that authorize and initiate cross-project resource allocation, marking the system's transition from intra-project resource optimization mode to global resource pool optimization mode. These signals include information such as the task ID requiring reinforcement, the required skill set, the required workload, and the maximum acceptable priority sacrifice.

[0152] Time adjustment signals are instructions to adjust the time allocation of a specific developer, directly affecting the developer's schedule. For example, an instruction could be: "Increase the time developer A spends on task T from 4 hours per day to 6 hours per day for the next 3 days," and automatically reduce the time allocated to other low-priority tasks accordingly.

[0153] In one embodiment, the process of selecting additional developers involves filtering developers for low-priority projects across the global project pool based on cross-project scheduling signals, including the following steps:

[0154] S504 calculates multi-dimensional matching scores based on development data sources and requirements documents, determines a comprehensive score for each candidate developer based on a multi-attribute decision method, and selects the candidate developer with the highest comprehensive score as the additional developer.

[0155] The mechanism for selecting additional developers is a cross-project, globally optimal secondary matching process. Its steps are explained as follows: First, it receives a global pool of developer capability profiles and a profile of the task requirements for urgent reinforcement. Second, it calculates multi-dimensional matching scores, including core skill matching, domain experience relevance, current workload and availability, collaboration cost, and relocation cost. Core skill matching refers to the degree of alignment with the technology stack required for the task. Domain experience relevance refers to experience in similar businesses (e.g., finance, e-commerce). Current workload and availability refer to whether tasks in the current low-priority projects can be smoothly transferred or suspended. Collaboration cost refers to the familiarity with the current task team, time zone, and work habits. Relocation cost refers to the estimated loss of context switching. Each dimension calculates a sub-score, and a comprehensive score is determined based on a multi-attribute decision method, such as MADM methods: weighted summation (WSM), analytic hierarchy process (AHP), TOPSIS, etc.

[0156] The system or administrator assigns different weights to each matching dimension. For example, in an emergency rescue scenario, "core skill matching" and "current availability" might have the highest weights, while "mobilization cost" might have a lower weight. Then, a mathematical model aggregates the sub-scores from multiple dimensions into a comprehensive score. This transforms the complex problem of "finding a suitable developer" into a quantifiable optimization problem that comprehensively considers multiple factors. The system ranks all eligible candidate developers and selects the one with the highest comprehensive score as an additional developer.

[0157] Specifically, a matching score across multiple dimensions (such as skill fit, current workload, and historical collaboration synergy) can be calculated for a task and a developer. Then, a multi-attribute decision-making method (such as TOPSIS or weighted scoring) is used to calculate a comprehensive score for each candidate developer, ultimately selecting the one with the highest score. This approach is logically intuitive, computationally lightweight, and easy to understand and implement, making it particularly suitable for rapid application in scenarios where resource scale is not extremely large and real-time requirements are not extremely high. However, its ability to find the globally optimal solution under ultra-large-scale, multi-project concurrency may be limited.

[0158] This application also discloses a cloud platform collaborative system for elastic resource scheduling.

[0159] like Figure 2As shown, the cloud platform collaborative system for elastic resource scheduling includes a resource awareness and profiling layer, an intelligent matching and decision-making layer, an elastic scheduling and execution layer, and a performance feedback and optimization layer. The resource awareness and profiling layer dynamically collects development data sources and requirement documents, determining developer capability profiles based on the development data sources and task requirement profiles based on the requirement documents. The intelligent matching and decision-making layer inputs the updated developer capability profiles and task requirement profiles into a preset matching model, and divides the received pending project tasks into several sub-task sets based on the updated preset matching model. It then uses an updated optimization algorithm to determine the developer matching scheme for each sub-task in the sub-task set. The elastic scheduling and execution layer determines a work plan list based on the developer matching scheme and sends the corresponding sub-tasks to the corresponding developers based on the work plan list.

[0160] The resource awareness and profiling layer dynamically collects and constructs two core profiles. The first is the developer capability profile, which quantifies a developer's technical stack proficiency (e.g., Java, Python), domain experience (e.g., finance, e-commerce), current workload saturation, collaboration preferences (e.g., asynchronous communication ability), and historical delivery quality (e.g., code defect rate) by analyzing data sources such as code repositories (e.g., Git) and project management systems (e.g., Jira). The second is the task requirement profile, which extracts the technical requirements, complexity level, priority, dependencies, and estimated workload of tasks by parsing requirement documents (e.g., PRDs) and task breakdowns (e.g., WBS). The intelligent matching and decision-making layer is the core of the system. Received project tasks are decomposed into atomic subtasks, which are then processed by a multi-objective optimization matching engine. This engine comprehensively considers multiple objectives such as skill matching, load balancing, project priority, and collaboration costs (e.g., time zone differences), and uses improved optimization algorithms (e.g., the Pareto solution set search algorithm or reinforcement learning, discussed later) to calculate the optimal developer matching scheme for each subtask.

[0161] The elastic scheduling and execution layer is responsible for executing scheduling decisions, generating specific work plans, and notifying relevant developers via message queues or APIs. This layer supports elastic scaling; for example, when high-priority tasks urgently need resources, the system can dynamically adjust resource allocation for low-priority tasks or initiate cross-project resource borrowing. The performance feedback and optimization layer monitors actual task execution data (such as completion progress, code quality, and communication frequency) and inputs it as feedback data into the optimization layer to adjust and update resource profiles and matching models, forming a closed loop of continuous learning.

[0162] The implementation principle is as follows:

[0163] By constructing refined developer capability profiles and task requirement profiles, and employing improved multi-objective optimization algorithms (such as Pareto solution set search) for collaborative decision-making, the system can find the optimal balance among multiple objectives, including skill matching, load balancing, project priority, and collaboration costs. This allows the matching results to consider not only feasibility but also who is more suitable, when to do it more efficiently, and how to collaborate at the lowest cost. This elevates the accuracy of resource-requirement matching to a new level, fundamentally reducing project delays and quality risks caused by mismatched personnel skills or poor collaboration.

[0164] The other functions performed in the above-mentioned resource perception and profiling layer, resource perception and profiling layer, intelligent matching and decision-making layer, elastic scheduling and execution layer, and performance feedback and optimization layer, as well as the technical details of each function, are the same or similar to the corresponding features in the cloud platform collaborative method for elastic resource scheduling described above, so they will not be repeated here.

[0165] It should be understood that although the steps in the flowcharts in the accompanying drawings are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise expressly stated herein, there is no strict order in which these steps are performed, and they may be performed in other orders.

[0166] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A cloud platform collaboration method for elastic resource scheduling, characterized in that, Includes the following steps: Dynamically collect development data sources and requirements documents, and determine the developer capability profile based on the development data sources, and determine the task requirement profile based on the requirements documents; The updated developer capability profile and the task requirement profile are input into the preset matching model, and the received project tasks to be processed are divided into several sets of sub-tasks based on the updated preset matching model. The updated optimization algorithm is used to determine the developer matching scheme for each subtask in the subtask set; A list of work plans is determined based on the developer matching scheme, and the corresponding sub-tasks are sent to the corresponding developers based on the list of work plans. Determining the developer matching scheme for each subtask in the subtask set using the updated optimization algorithm includes the following steps: Multiple scheduling agents are set up, and the scheduling matching strategies of different task developers are learned based on the scheduling agents to obtain the optimal scheduling strategy. The scheduling agents include task type agents, developer group agents and project / team agents. The project / team agents represent that each project or team has its own agent and learns the optimal scheduling logic within the project. Based on the actual progress and quality of the project, feedback signals are determined, and the optimal scheduling strategy is learned based on the feedback signals to obtain a developer matching solution. Determining the developer matching scheme for each subtask in the subtask set using the updated optimization algorithm includes the following steps: Construct a multi-objective optimization function, and determine the Pareto solution set based on the multi-objective optimization function; The developer's capability profile and task requirement profile are compared to dynamically evaluate the matching combination, and the developer matching scheme is determined from the Pareto solution set based on preset weights. Constructing a multi-objective optimization function includes the following steps: The expression for the multi-objective optimization function is: MaximizeF(X)=[fskill(X),fbalance(X),fcost(X)]; Where X represents a matching scheme, fskill represents skill matching degree, and fbalance represents team load balancing degree. fcost represents the estimated collaboration and management costs; Determining the work plan list based on the developer matching scheme also includes the following steps: The type of flexible processing is determined based on the actual progress of the task, and the type of flexible processing includes horizontal scaling and vertical scaling. If the elastic processing type is determined to be horizontal scaling, a cross-project scheduling signal is generated, and developers corresponding to low-priority projects are selected in the global projects based on the cross-project scheduling signal to determine the additional developers. If the elastic processing type is determined to be vertical scaling, a time adjustment signal is generated, and the proportion of time invested is adjusted in real time according to the actual progress of the task based on the time adjustment signal. Based on the development data source and requirements document, multi-dimensional matching scores are calculated. A comprehensive score is determined for each candidate developer based on a multi-attribute decision method. The candidate developer with the highest comprehensive score is selected as the additional developer. The multi-dimensional matching scores include core skill matching degree, domain experience relevance, current workload and release capability, collaboration cost, and transfer cost.

2. The cloud platform collaboration method for elastic resource scheduling according to claim 1, characterized in that, After sending the corresponding subtasks to the corresponding developers based on the work plan list, the following steps are also included: The actual execution data is acquired in real time and input as feedback data into the model optimizer to update the developer capability profile and the preset matching model.

3. The cloud platform collaboration method for elastic resource scheduling according to claim 2, characterized in that, The real Actual execution data is input as feedback data to the model optimizer to update the developer capability profile and the preset matching model, including the following steps: The actual execution data is compared with the initial prediction data to obtain the execution deviation, and the execution deviation is then determined. Is the row deviation within the preset threshold? If the execution deviation is within a preset threshold, then the corresponding subtask will be sent to the corresponding [target] based on the work plan list. The developers; If the execution deviation is not within a preset threshold, a retraining signal is generated, and a decision is triggered based on the retraining signal. The policy model is retrained to generate feedback rewards; The internal parameters are adjusted based on the feedback rewards to update the developer capability profile and the preset matching model.

4. The cloud platform collaboration method for elastic resource scheduling according to claim 1, characterized in that, In dynamic sampling After gathering the development data source and requirements documents, the following steps are included: Based on the aforementioned development data sources and requirements documents, computing nodes are determined according to role types to construct a hierarchical decision-making system. The hierarchical decision-making system includes a product requirement layer, a development execution layer, and a testing requirement layer. Planning instructions are determined based on the product demand layer, and status signal feedback is determined based on the development execution layer; The planning instructions and status signals are fed back into the core collaborative function to determine the work plan list.

5. A cloud platform collaborative system for elastic resource scheduling, characterized in that, Perform any of claims 1-4 A cloud platform collaboration method for elastic resource scheduling, as described in one of the claims, includes: The resource awareness and profiling layer is used to dynamically collect development data sources and requirement documents. The developer capability profile is determined based on the development data source, and the task requirement profile is determined based on the requirement document. The intelligent matching and decision-making layer is used to match the updated developer capability profile with the... The task requirement profile is input into the preset matching model, and the received project tasks to be processed are divided into several sets of sub-tasks based on the updated preset matching model; and the updated optimization algorithm is used to determine the developer matching scheme for each sub-task in the sub-task set. The elastic scheduling and execution layer determines the work plan columns based on the developer matching scheme. The table is used to send the corresponding subtasks to the corresponding developers based on the work plan list.

Images