Program development task allocation method based on dynamic weight and real-time load balancing

Abstract

The application relates to a program development task allocation method based on dynamic weight and real-time load balancing, and the method is as follows: step S1, constructing a multi-dimensional portrait of a developer; step S2, receiving a to-be-allocated R&D work order, and analyzing technical stack requirements, a business module to which the work order belongs, an emergency level and a demand level of the work order; step S3, dynamically generating a weight; step S4, load balancing scoring; step S5, allocation execution: distributing the work order to an employee with the highest comprehensive matching score; and step S6, closed-loop feedback updating: immediately collecting an actual processing duration and a user score of the work order after the work order is processed, and updating historical indexes in the multi-dimensional portrait of the employee by using a moving average algorithm, so that adaptive correction of the portrait is realized. The scheme truly realizes real-time load balancing of R&D resources, and solves the problems of lagging and distortion of portrait data.

Description

Technical Field

[0001] This invention relates to the field of computer information processing technology, specifically to an automatic work order allocation and scheduling technology in a software development task allocation service system. Background Technology

[0002] In existing corporate operations and maintenance management systems (OMS), work orders are typically assigned using the following traditional methods:

[0003] 1. Manual task assignment: Department leaders manually assign tasks to designated personnel. The disadvantages are low efficiency, uneven distribution of tasks, and reliance on the subjective judgment of department leaders.

[0004] 2. Simple Round Robin: Assigns tasks sequentially in turn. The drawback is that it doesn't consider the current workload and skill level of employees, potentially assigning complex problems to novices.

[0005] 3. Random assignment: Randomly assign roles. The disadvantages are the same as above; code quality cannot be guaranteed.

[0006] 4. Based on simple technology stack matching: only determines whether an employee belongs to the Java team or the front-end team. The drawback is that it cannot distinguish the familiarity of employees within the same team with specific business modules, the quality of their code, or their current development schedule.

[0007] Existing technologies lack an intelligent allocation mechanism that can comprehensively consider developers' proficiency in specific technology stacks, current R&D workload (Story Points, number of work orders), historical code quality (Bug rate), and Code Review pass rate, and can dynamically adjust the weights according to the urgency of production incidents, and has the ability to learn and update itself. Summary of the Invention

[0008] The present invention aims to solve the above problems and provide a software development task allocation method based on multiple dynamic weights and real-time load balancing.

[0009] To achieve the above objectives, the technical solution of this invention is as follows: a program development task allocation method based on dynamic weighting and real-time load balancing, comprising the following steps: Step S1: Constructing a multi-dimensional profile of developers, the profile includes static tags (technology stack, business module familiarity) and dynamic indicators, the dynamic indicators including at least the current R&D task load, historical code quality score, historical development efficiency, and online fault response time; Step S2: Receiving R&D work orders to be allocated, parsing the work order's technology stack requirements, business module, urgency level, and requester level; Step S3: Dynamic weight generation: Based on the urgency level, generating weight coefficients for each dimension indicator in real time; when the urgency level is high, automatically increasing the weight coefficients for response time and current load; Step S4: Load balancing scoring: Based on the weight coefficients and the multi-dimensional profile of employees, calculating the comprehensive matching score of candidate employees; wherein, a negatively correlated load scoring factor is introduced, so that the fewer work orders currently in progress an employee has, the higher their calculated comprehensive matching score. Step S5: Assignment and Execution: Assign the work order to the employee with the highest comprehensive matching score; Step S6: Closed-Loop Feedback Update: After the work order is processed, immediately collect the actual processing time and user rating of the work order, and use the moving average algorithm to update the historical indicators in the employee's multi-dimensional profile to achieve adaptive correction of the profile.

[0010] The specific process of step S1 is as follows: Establish a dynamically updated employee profile database. The profile construction includes two sub-processes: initialization and real-time updating.

[0011] 1. Data Acquisition and Configuration:

[0012] Technology / Business Matching ( The degree of matching between employees' technology stacks (e.g., Java, Go) and business modules (e.g., RBAC, MES, BPM) and work order requirements.

[0013] Extract skill tag sets from employee profiles (For example: {Java, python, mes}).

[0014] Parse the work order for its set of requirement tags. (For example: {Java, mes}).

[0015] Calculate the intersection (matching items) of the two sets, divide it by the number of elements in the requirement set (requirement items), and obtain the coverage rate.

[0016] formula:

[0017] If the calculation result is 1.0 (full coverage), full marks are awarded; if it is 0, 0 marks are awarded. This formula is normalized within the interval [0,1].

[0018] 2. Calculation and normalization of dynamic indicators:

[0019] Code quality score ( ): Extract the bug rate (Bugs / KLOC) of the tasks handled by this employee over the past 3 months. Normalize it using a function: ,

[0020] Development efficiency score ( ): Calculates the average actual working hours consumed per Story Point. The lower the value, the higher the efficiency score.

[0021] Current load score ( ): Retrieves the normalized values ​​of the employee's currently unfinished tasks. The fewer the tasks, the higher the score.

[0022] Response speed rating ( ): The average time difference from task assignment to the start of processing in history.

[0023] The system normalizes the raw data to form a standardized feature vector, which is then stored in the database.

[0024] The design of step S1 essentially transforms unstructured human factors (ability, habits, busyness) into structured, computable mathematical vectors. This enables subsequent step S3 (dynamic weights) to make optimal decisions based on this set of objective, real-time, and standardized data, even in complex business scenarios.

[0025] The specific process of step S2 is as follows:

[0026] The business department submits a work order through the OA system.

[0027] During the order approval process, the characteristics of the work order (required technology stack, business module, and order type) are improved.

[0028] Order type:

[0029] Bug: p0, p1, p2, p3, p4, p5

[0030] Priority: Urgent, Medium, Normal

[0031] Development types: core business development, new technology evaluation, architecture upgrade.

[0032] The specific process of step S3 is as follows:

[0033] 1. Build a dynamic weight matrix template.

[0034] 1.1 Response-first model,

[0035] After the system identifies the work order as P0 level, it calls the preset "P0 level fault" evaluation model to construct a 5th order judgment matrix. The values ​​in the matrix represent the relative importance of the two indicators (using the 1-9 scale, where 1 represents equal importance and 9 represents extreme importance).

[0036] The specific data structure of the matrix is ​​as follows:

[0037] The first line (comparing response speed with other metrics): set to [1, 3, 5, 7, 9]. This means that under a P0 failure, "response speed" is 3 times more important than "current load," 5 times more important than "skill matching," 7 times more important than "development efficiency," and 9 times more important than "code quality," reflecting the "speed is everything" strategy.

[0038] The second line (comparing current workload to other metrics): set to [1 / 3, 1, 3, 5, 7]. This means that while "current workload" is not as important as response speed, it is more important than skill, efficiency, and quality, because if employees have too many tasks piling up, they simply cannot respond.

[0039] The third row (comparing skill matching with other metrics): set to [1 / 5, 1 / 3, 1, 3, 5].

[0040] The fourth line (comparison of development efficiency with other metrics): set to [1 / 7, 1 / 5, 1 / 3, 1, 3].

[0041] The fifth line (comparing code quality with other metrics): set to [1 / 9, 1 / 7, 1 / 5, 1 / 3, 1]. Here, code quality is given the lowest priority, which aligns with the principle of emergency stop-loss.

[0042] 1.2 Quality-First Model

[0043] When a work order is identified as a new feature development for core business operations, the system automatically switches to a quality-first model.

[0044] The first line (comparing response speed to other factors): set to [1, 1 / 5, 1 / 7, 1 / 3, 1 / 9], indicates that response speed is the least important factor, its importance being only 1 / 9 of code quality.

[0045] The second line (comparing the current load to others): set to [5, 1, 1 / 3, 3, 1 / 5]. Load is more important than response time, but far less important than skill and quality.

[0046] The third row (skill matching compared to others): set to [7, 3, 1, 5, 1 / 3], where skill is the second most important factor after quality.

[0047] The fourth line (development efficiency compared to others): set to [3, 1 / 3, 1 / 5, 1, 1 / 7], places its efficiency in the lower-middle range.

[0048] The fifth line (code quality compared to other metrics): set to [9, 5, 3, 7, 1], indicates that code quality is absolutely dominant and more important than any other metric.

[0049] 1.3 Efficiency-first model,

[0050] When the system detects that a project is entering its deadline countdown (e.g., less than 3 days until the final draft is completed), it switches to an "efficiency-first" model.

[0051] The first line (comparing response speed to other metrics): set to [1, 1 / 3, 1 / 5, 1 / 7, 1]. Response speed and quality are both low priority.

[0052] The second line (comparing the current load to others): set to [3, 1, 1 / 3, 1 / 5, 3]. Load is more important than response and quality, but must yield to efficiency.

[0053] The third row (skill matching compared to others): set to [5, 3, 1, 1 / 3, 5]. Skills are the basic guarantee.

[0054] The fourth row (development efficiency compared to other metrics): set to [7, 5, 3, 1, 7]. Development efficiency is given the highest priority (9 times that of quality) and is 3 times more important than skills.

[0055] Line 5 (code quality compared to others): Set to [1, 1 / 3, 1 / 5, 1 / 7, 1]. In the critical delivery phase, quality temporarily takes a backseat.

[0056] 1.4 Skills-first model

[0057] When a work order involves "architectural upgrade" or "introduction of new technology stack", the system switches to a "skills-first" model.

[0058] The first line (response speed compared to others): set to [1, 1, 1 / 7, 1 / 5, 1 / 3].

[0059] The second line (comparing the current load to others): set to [1, 1, 1 / 7, 1 / 5, 1 / 3]. For high-difficulty tasks, the load level is not crucial.

[0060] The third row (skill matching compared to others): set to [7, 7, 1, 3, 5]. Skill matching is the core factor; only experts can accept orders.

[0061] The fourth line (development efficiency compared to others): set to [5, 5, 1 / 3, 1, 3].

[0062] Line 5 (code quality compared to others): Set to [3, 3, 1 / 5, 1 / 3, 1].

[0063] Calculate the feature vector and weights based on the characteristics of the work order.

[0064] The bug in the first-weighted work order characteristic is at level P0, which will definitely match the response-first model.

[0065] The second priority for special work orders is urgency, with matching efficiency taking precedence.

[0066] Finally, match based on type.

[0067] 2.1 Column Vector Normalization: Divide each column element of the judgment matrix A by the sum of the elements in that column to obtain the standardized matrix B, as shown in the formula:

[0068] (i,j=1,2,...,n)

[0069] Where n=5 is the number of indicators.

[0070] : Represents the judgment matrix The element in (the first) Okay, number The value of the column), representing the number of columns. The first indicator is relative to the first The importance of each indicator, for example, if the indicator It's a metric called "response speed". It's about "code quality". This may mean that in the current scenario, "response speed" is slightly more important than "code quality" (about 3 times more important).

[0071] : Represents a matrix The Middle The sum of all elements in the column.

[0072] Meaning: This is the denominator in the normalization process, used to proportionalize the values ​​in this column so that the sum of the weights calculated subsequently is 1.

[0073] : Represents the standardized matrix The elements in the table are the original judgment values. The value obtained by dividing by the sum of that column is used to eliminate the influence of different column dimensions and is used to calculate the final weight vector. The necessary preliminary steps

[0074] : Represents the number of metrics (evaluation dimensions), as specified in the document. These correspond to the five core dimensions mentioned in the document:

[0075] Technology / Business Matching ( )

[0076] Code quality score ( )

[0077] Development efficiency score ( )

[0078] Response score ( )

[0079] R&D workload score ( )

[0080] 2.2 Row Summation and Average Eigenvector Approximation: Sum the elements of each row of the standardized matrix B and divide by n to obtain the weight vector. The formula is:

[0081]

[0082] No. The weight coefficients calculated from the final evaluation metrics represent the weight of the first evaluation metric in the current work order scenario (e.g., "P0 level fault" or "new feature development"). The relative importance of each indicator compared to other indicators, all The sum of them is approximately 1.

[0083] Normalized elements, which are the standardized judgment matrix calculated in the previous step. The elements in the matrix eliminate the influence of different column dimensions in the original judgment matrix, allowing the data in each row to be directly added together.

[0084] Row sum, normalizing the matrix In the middle, the first This step sums up all the values ​​in the row, representing the sum of the values ​​in the first row. The relative importance share of each indicator in all comparisons

[0085] Calculate the average and divide by the total number of indicators. The average of the "row sums" is taken to reduce the error that may be caused by a single judgment, thus obtaining a smoother and more accurate weight estimate. ,

[0086] 2.3. Calculate the largest eigenvalue :

[0087]

[0088] This is the judgment matrix. The theoretical largest eigenvalue is the basis for subsequent calculations of the Consistency Index (CI). Judgment criterion: Theoretically, if the judgment matrices are completely logically consistent (e.g., A is twice as important as B, and B is twice as important as C, then A must be four times as important as C), then... It should be exactly equal to .if Compare The larger the value, the more serious the logical contradiction in the matrix.

[0089] The first vector product Components: This is the original judgment matrix. With weight vector After multiplication, the first element in the resulting new vector is... 1 element. Calculation method: matrix. The Rows and weight vectors Performing a "dot product" (multiplying corresponding elements and then adding them together). This represents the product of the matrix... The logical derivation of the first The weighted sum of the indicators.

[0090] For the first The weight of the first indicator: the weight calculated in the previous step. The normalized weight values ​​of each indicator. Used as the denominator to calculate the ratio.

[0091] This is the consistency ratio component, the ratio of the derived value to the calculated value. If the matrices are perfectly consistent, this ratio should be always equal to... (or more accurately) This involves calculating the ratio for each dimension separately.

[0092] 3. Consistency check.

[0093] To ensure that the logic of the judgment matrix does not contain serious self-contradictions, a consistency check must be performed:

[0094] 3.1. Calculate the consistency index:

[0095]

[0096] This is an indicator for measuring the degree of deviation of the judgment matrix from consistency. If : Indicates that the judgment matrix has complete consistency.

[0097] like The larger the value, the more serious the logical contradiction in the matrix (for example, you say A is more important than B, B is more important than C, but conversely you say C is more important than A).

[0098] As a denominator, it is used for normalization.

[0099] 3.2 Calculate the consistency ratio:

[0100]

[0101] This is the final criterion, used to measure whether the logical inconsistency of your constructed judgment matrix is ​​within an acceptable range. This indicates that the judgment matrix has passed the consistency test, and the calculated weights are valid and reliable. This indicates that the logical contradiction is too great, and the judgment matrix needs to be readjusted until the conditions are met.

[0102] Average random consistency index: This is an empirical constant representing the average consistency deviation generated when randomly filling in a matrix of the same order. It serves as the denominator and acts as a reference, using the actual deviation ( Removed by random bias ( ), The value depends only on the order of the matrix. . The setting here is ,

[0103] Conclusion: Due to The matrix is ​​determined to meet the consistency requirement, and the weight calculation is valid.

[0104] The above solution addresses the technical challenge of "multi-objective conflict": software development task allocation is essentially a multi-objective optimization problem. Speed, quality, and efficiency are often mutually exclusive. Traditional linear weighting methods cannot dynamically balance these conflicts in different scenarios.

[0105] By constructing pairwise comparison matrices, the complex "5-dimensional synchronous decision-making" is reduced to "10 simple pairwise comparisons." It not only determines which indicator is more important, but also quantifies "how much more important" it is (whether it is 3 times or 9 times). This non-linear quantification can more accurately capture the extreme requirements of business scenarios (such as when there is a P0-level failure, the weight of response speed shows an exponential overwhelming advantage), thereby obtaining the local optimum solution in the current scenario.

[0106] This ensures the "mathematical consistency" and robustness of the decision-making logic: Logical paradoxes can easily arise when rules are manually set. For example: setting rule A "Only experts can build architectures (skill > workload)," rule B "Busy people should take on fewer jobs (load > efficiency)," and rule C "Efficiency is paramount when meeting deadlines (efficiency > skill)." This creates a logical loop of A>B>C>A, causing the algorithm to fail or oscillate under certain edge conditions.

[0107] The eigenvalue method is introduced to solve for the weight vector, coupled with a consistency check (CI / CR calculation). The hard constraint of CR < 0.1 is equivalent to adding a "logical firewall" at the algorithm level. Before running, the system automatically checks the logical consistency of the matrix. Once a logical conflict is detected (CR is too large), the algorithm will refuse to execute or issue an alarm. This ensures the transitivity and stability of the allocation strategy from a mathematical perspective, preventing the system from making chaotic decisions.

[0108] This achieves "complete decoupling" between the algorithm engine and business strategy: In traditional systems, the allocation logic is usually hard-coded in the Service layer (e.g., numerous `if (isP0) { weight = ...} else if (isDeadline) { ...}`). Once the business strategy changes (e.g., the company decides to "focus on quality this year"), a large amount of code needs to be modified and redeployed.

[0109] This step encapsulates the operators (normalization, eigenvalue calculation) into a general mathematical engine, while extracting the business strategies (matrix values ​​from 1.1 to 1.4) into configurable data templates.

[0110] Scalability: When a new scenario (such as "cost-first mode") is needed, no code modification is required; simply insert a new value into the database. A matrix is ​​sufficient. This data-driven architecture significantly reduces system maintenance costs and iteration risks.

[0111] It provides strong support for "explainable artificial intelligence": Allocation decisions made by neural networks or complex black-box algorithms often cannot explain "why A was chosen instead of B", leading to dissatisfaction among team members and making management difficult to implement.

[0112] intermediate product weight vector A clear audit path is provided. The technical team can clearly see that because it's "P0 mode," therefore... The algorithm automatically calculated it to be 0.51. The value was reduced to 0.04. This white-box computation process makes every task allocation traceable, which not only enhances the transparency of the system but also facilitates subsequent fine-tuning of the model parameters.

[0113] It enhances the "fault tolerance" for outlier data: During vector normalization and averaging, a data smoothing process is actually performed. The effect: Even if the original judgment data for a certain dimension contains minor noise or bias, the feature vector (weights) obtained through overall matrix operations remains relatively stable. This is more flexible and resistant to interference than simply relying on a single-point threshold for judgment.

[0114] The specific process of step S4 is as follows:

[0115] Read the total number of unfinished Story Points currently held by this employee. );

[0116] The rating is negatively correlated with the load, even if the formula is: This means that the fewer tasks you have backlogged, the higher your score will be.

[0117] This score forms the employee's current workload rating. ),

[0118] The system connects to the company's GitLab via API.

[0119] The system scans Git commit logs using regular expressions (Fix #ID) to associate code changes with bug tickets in the company's OMS (Operation Management System). If a commit is associated with a bug ticket and marked as a bug ticket, the author of that commit is identified as the person responsible for introducing the bug. The system then calculates the employee's bug rate (Bugs / KLOC) over the past three months using the following formula: Normalization via function: For adjustment coefficients,

[0120] This score forms the employee's current code quality rating. ),

[0121] Based on the calculated dynamic weights Based on employee profiles, a comprehensive employee matching score is calculated.

[0122] Calculation formula:

[0123] .

[0124] in, For technology / business matching,

[0125] Rate the code quality.

[0126] Rate development efficiency.

[0127] Current load score

[0128] The response speed is scored.

[0129] As a skill weight,

[0130] For quality weight,

[0131] For efficiency weighting,

[0132] In response to weights,

[0133] This is the load weight.

[0134] Technology / Business Matching ( Based on employee characteristics, assign individual skill and module tags to each employee. For example, employee A is proficient in Java and Python and has developed core modules such as RBAC, MES, and BPM.

[0135] Code quality score ( ): Extract the bug rate (Bugs / KLOC) of the tasks handled by this employee over the past 3 months. Normalize it using a function: .

[0136] Development efficiency score ( ): Calculates the average actual working hours consumed per Story Point. The lower the value, the higher the efficiency score.

[0137] Current load score ( ): Retrieves the normalized value of the employee's currently unfinished tasks; fewer tasks result in a higher score. Response speed score ( The system calculates the average time difference between task assignment and the start of processing in historical data. It then normalizes the raw data to create a standardized feature vector.

[0138] (Skill Weight): Corresponds to the technical / business matching degree, representing "whether it can be done". If the work order requires a high level of technical stack (such as low-level Java language optimization), this weight will be very high to prevent it from being assigned to someone who does not have the skills.

[0139] (Quality Weight): Corresponds to code quality / rating, representing "how well it's done". For the development of new features for core business modules, this weight will be increased, prioritizing the hiring of people with low code bug rates.

[0140] (Efficiency Weight): Corresponds to the development efficiency score, representing "how fast or slow it is done". This weight will increase for tasks with tight deadlines.

[0141] (Response Weight): Corresponds to the response score, representing "how fast the response is". For the highest level of online faults, this weight will become the largest (e.g., 0.5 or even higher). As long as the response is fast, the order will be dispatched first even if other conditions are mediocre.

[0142] (Load Weight): Corresponds to the R&D load score, representing "whether there is currently free time". For ordinary tasks, in order to prevent someone from being overworked, this weight plays a balancing role, prioritizing assignment to the person with the fewest Story Points currently available.

[0143] Normalization calculation for multidimensional vector synthesis has been implemented: future GitLab dimensional data (such as bug rate as a decimal, StoryPoint as an integer, and response time as minutes) will be uniformly mapped to dimensionless scalars in the interval [0, 1].

[0144] and The use of this type of nonlinear transformation function cleverly addresses the long-tail distribution problem of data. It prevents certain large indicators (such as a load factor as high as 50) from masking smaller indicators (such as a bug rate of only 0.01). It avoids the score from suddenly soaring to an uncontrollable range due to an anomaly in a single indicator (such as a load factor of 0 when someone has just returned from vacation), thus ensuring the numerical stability of the system.

[0145] A flexible scoring engine with dynamic weight injection was constructed: the strategy and data are decoupled; S4 is only responsible for performing mathematical operations and is completely uninvolved in business logic. Changes in business logic (such as adjusting P0-level fault weights) only change the input vector. No modification to the scoring algorithm code is required. Real-time optimization is supported; administrators can intervene in the system's allocation bias in real time by adjusting coefficients or weight matrices in the backend (e.g., globally increasing allocation during peak sales periods). Efficiency weighting), without requiring downtime for deployment.

[0146] Data-driven automatic load balancing was implemented: load scoring was introduced as a mandatory element, and... It shows a negative correlation. Automatic peak shaving and valley filling occurs when an employee... After receiving the order, Increase decline decline The probability of dispatching an order next time is reduced. This ensures at the algorithm level that traffic will automatically flow to idle nodes, preventing single-point overload and achieving an effect similar to a microservice gateway.

[0147] It provides precise error attribution tracking capabilities: by matching Git Commit with Fix #ID regular expressions, a strong correlation is established between code-level changes and business work orders. The calculations are not based on vague "feelings," but on verifiable code commit records. The data lineage is clear; the system can precisely trace back to which commit, which line of code, and who wrote each bug. This is not only used for scoring but also provides data support for subsequent automated CI / CD pipeline interception (e.g., code submissions from individuals with scores below 0.6 must undergo two code reviews). Preventing buck-passing: Based on objective Bugs / KLOC metrics, human bias is eliminated, giving the assessment results irrefutable technical credibility.

[0148] 5. Enhanced system scene adaptability: through Dynamic changes, the same employee When faced with different work orders, P0 faults, and new features, its It's completely different. It breaks the vicious cycle of "the capable do more," where traditional systems often assign tasks only to the highest-rated person. This system, however, believes there are no inherently bad employees, only employees misplaced. The algorithm automatically identifies each person's strengths in specific scenarios, achieving global maximization of human resource utilization.

[0149] The specific process of step S5 is as follows:

[0150] Rank employees by score in reverse order, and assign the employee with the highest score to a work order.

[0151] The specific process of step S6 is as follows:

[0152] Update the development efficiency score ( ):

[0153] Extract the actual working hours and corresponding story points of the employee's completed tasks from OMS.

[0154] The formula for calculating the time taken per story point is: ,

[0155] To eliminate differences in task difficulty, only the average value of tasks with similar technology stacks is calculated.

[0156] The lower the value, the higher the efficiency; therefore, reciprocal normalization is used. (where k is the decay constant), ensuring that the score is between 0 and 1 and negatively correlated with the time consumed.

[0157] Re-updating response speed rating ( ):

[0158] By tracing the lifecycle of this employee's historical work orders, two key time points can be extracted: (Assignment time) and (Start processing time)

[0159] calculate It also automatically excludes non-working hours (such as weekends and nights).

[0160] Calculate the average response time of the employee's most recent 30 high-priority work orders. ,

[0161] ,in The baseline response time is 30 minutes. The faster the response, the closer the score is to 1.

[0162] The system performs Min-Max normalization on the raw data to form a standardized feature vector, which is then stored in the vector database.

[0163] Compared with the prior art, the advantages of the present invention are as follows:

[0164] This solution addresses the persistent problem of uneven workloads by introducing... (Real-time load scoring) allows the system to query each developer's Story Points in real time. This avoids forcibly assigning new tasks to core employees who are already at full capacity, effectively preventing staff overwork and project delays, and truly achieving real-time load balancing of R&D resources;

[0165] This system achieves dynamic intelligent scheduling with a "one scenario, one strategy" approach. It abandons the traditional rigid fixed allocation logic and constructs multiple evaluation models. Whether it's a "P0-level fault" requiring speed as the only solution or a "new feature development" prioritizing quality, the system can adaptively switch weights to ensure that each dispatch is a locally optimal solution for the current scenario.

[0166] The closed-loop feedback enables self-evolution, establishing a closed-loop data flow from "order dispatch" to "order completion." The actual time spent on each task and the number of bugs will feed back into updating the employee profile. This means that as the system is used over time, it will increasingly understand the true capabilities of each employee, solving the problems of outdated and distorted profile data. Attached Figure Description

[0167] Figure 1 This is the overall system flowchart. Detailed Implementation

[0168] To enhance understanding of the present invention, the following detailed description of the solution is provided in conjunction with embodiments.

[0169] Example: See Figure 1 The method for allocating program development tasks based on dynamic weights and real-time load balancing includes the following steps: Step S1: Construct a multi-dimensional profile of developers, which includes static tags (technology stack, familiarity with business modules) and dynamic indicators. Dynamic indicators include at least the current R&D task load, historical code quality score, historical development efficiency, and online fault response time; Step S2: Receive R&D work orders to be assigned, and parse the work order's technology stack requirements, the business module it belongs to, its urgency level, and the requester's level; Step S3: Dynamic weight generation: Based on the urgency level, generate the weight coefficients of each dimension indicator in real time; when the urgency level is high, automatically... Step S4: Load Balancing Scoring: Based on the weighting coefficients and the multi-dimensional profile of employees, calculate the comprehensive matching score of candidate employees; among them, a negatively correlated load scoring factor is introduced, so that the employee with fewer work orders in progress will have a higher comprehensive matching score; Step S5: Allocation and Execution: Assign the work order to the employee with the highest comprehensive matching score; Step S6: Closed-Loop Feedback Update: After the work order is processed, immediately collect the actual processing time and user rating of the work order, and use the moving average algorithm to update the historical indicators in the multi-dimensional profile of the employee to achieve adaptive correction of the profile.

[0170] The specific process of step S1 is as follows: Establish a dynamically updated employee profile database. The profile construction includes two sub-processes: initialization and real-time updating.

[0171] 1. Data Acquisition and Configuration:

[0172] Technology / Business Matching ( The degree of matching between employees' technology stacks (e.g., Java, Go) and business modules (e.g., RBAC, MES, BPM) and work order requirements.

[0173] Extract skill tag sets from employee profiles (For example: {Java, python, mes}).

[0174] Parse the work order for its set of requirement tags. (For example: {Java, mes}).

[0175] Calculate the intersection (matching items) of the two sets, divide it by the number of elements in the requirement set (requirement items), and obtain the coverage rate.

[0176] formula:

[0177] If the calculation result is 1.0 (full coverage), full marks are awarded; if it is 0, 0 marks are awarded. This formula is normalized within the interval [0,1].

[0178] 2. Calculation and normalization of dynamic indicators:

[0179] Code quality score ( ): Extract the bug rate (Bugs / KLOC) of the tasks handled by this employee over the past 3 months. Normalize it using a function: ,

[0180] Development efficiency score ( ): Calculates the average actual working hours consumed per Story Point. The lower the value, the higher the efficiency score.

[0181] Current load score ( ): Retrieves the normalized values ​​of the employee's currently unfinished tasks. The fewer the tasks, the higher the score.

[0182] Response speed rating ( ): The average time difference from task assignment to the start of processing in history.

[0183] The system normalizes the raw data to form a standardized feature vector, which is then stored in the database.

[0184] The specific process of step S2 is as follows:

[0185] The business department submits a work order through the OA system.

[0186] During the order approval process, the characteristics of the work order (required technology stack, business module, and order type) are improved.

[0187] Order type:

[0188] Bug: p0, p1, p2, p3, p4, p5

[0189] Priority: Urgent, Medium, Normal

[0190] Development types: core business development, new technology evaluation, architecture upgrade.

[0191] The specific process of step S3 is as follows:

[0192] 2. Build a dynamic weight matrix template.

[0193] 1.1 Response-first model,

[0194] After the system identifies the work order as P0 level, it calls the preset "P0 level fault" evaluation model to construct a 5th order judgment matrix. The values ​​in the matrix represent the relative importance of the two indicators (using the 1-9 scale, where 1 represents equal importance and 9 represents extreme importance).

[0195] The specific data structure of the matrix is ​​as follows:

[0196] The first line (comparing response speed with other metrics): set to [1, 3, 5, 7, 9]. This means that under a P0 failure, "response speed" is 3 times more important than "current load," 5 times more important than "skill matching," 7 times more important than "development efficiency," and 9 times more important than "code quality," reflecting the "speed is everything" strategy.

[0197] The second line (comparing current workload to other metrics): set to [1 / 3, 1, 3, 5, 7]. This means that while "current workload" is not as important as response speed, it is more important than skill, efficiency, and quality, because if employees have too many tasks piling up, they simply cannot respond.

[0198] The third row (comparing skill matching with other metrics): set to [1 / 5, 1 / 3, 1, 3, 5].

[0199] The fourth line (comparison of development efficiency with other metrics): set to [1 / 7, 1 / 5, 1 / 3, 1, 3].

[0200] The fifth line (comparing code quality with other metrics): set to [1 / 9, 1 / 7, 1 / 5, 1 / 3, 1]. Here, code quality is given the lowest priority, which aligns with the principle of emergency stop-loss.

[0201] 1.2 Quality-First Model

[0202] When a work order is identified as a new feature development for core business operations, the system automatically switches to a quality-first model.

[0203] The first line (comparing response speed to other factors): set to [1, 1 / 5, 1 / 7, 1 / 3, 1 / 9], indicates that response speed is the least important factor, its importance being only 1 / 9 of code quality.

[0204] The second line (comparing the current load to others): set to [5, 1, 1 / 3, 3, 1 / 5]. Load is more important than response time, but far less important than skill and quality.

[0205] The third row (skill matching compared to others): set to [7, 3, 1, 5, 1 / 3], where skill is the second most important factor after quality.

[0206] The fourth line (development efficiency compared to others): set to [3, 1 / 3, 1 / 5, 1, 1 / 7], places its efficiency in the lower-middle range.

[0207] The fifth line (code quality compared to other metrics): set to [9, 5, 3, 7, 1], indicates that code quality is absolutely dominant and more important than any other metric.

[0208] 1.3 Efficiency-first model,

[0209] When the system detects that a project is entering its deadline countdown (e.g., less than 3 days until the final draft is completed), it switches to an "efficiency-first" model.

[0210] The first line (comparing response speed to other metrics): set to [1, 1 / 3, 1 / 5, 1 / 7, 1]. Response speed and quality are both low priority.

[0211] The second line (comparing the current load to others): set to [3, 1, 1 / 3, 1 / 5, 3]. Load is more important than response and quality, but must yield to efficiency.

[0212] The third row (skill matching compared to others): set to [5, 3, 1, 1 / 3, 5]. Skills are the basic guarantee.

[0213] The fourth row (development efficiency compared to other metrics): set to [7, 5, 3, 1, 7]. Development efficiency is given the highest priority (9 times that of quality) and is 3 times more important than skills.

[0214] Line 5 (code quality compared to others): Set to [1, 1 / 3, 1 / 5, 1 / 7, 1]. In the critical delivery phase, quality temporarily takes a backseat.

[0215] 1.4 Skills-first model

[0216] When a work order involves "architectural upgrade" or "introduction of new technology stack", the system switches to a "skills-first" model.

[0217] The first line (response speed compared to others): set to [1, 1, 1 / 7, 1 / 5, 1 / 3].

[0218] The second line (comparing the current load to others): set to [1, 1, 1 / 7, 1 / 5, 1 / 3]. For high-difficulty tasks, the load level is not crucial.

[0219] The third row (skill matching compared to others): set to [7, 7, 1, 3, 5]. Skill matching is the core factor; only experts can accept orders.

[0220] The fourth line (development efficiency compared to others): set to [5, 5, 1 / 3, 1, 3].

[0221] Line 5 (code quality compared to others): Set to [3, 3, 1 / 5, 1 / 3, 1].

[0222] 3. Calculate the feature vector and weights based on the characteristics of the work order.

[0223] The bug in the first-weighted work order characteristic is at level P0, which will definitely match the response-first model.

[0224] The second priority for special work orders is urgency, with matching efficiency taking precedence.

[0225] Finally, match based on type.

[0226] 2.1 Column Vector Normalization: Divide each column element of the judgment matrix A by the sum of the elements in that column to obtain the standardized matrix B, as shown in the formula:

[0227] (i,j=1,2,...,n)

[0228] Where n=5 is the number of indicators.

[0229] 2.2 Row Summation and Averaging (Eigenvector Approximation): Sum the elements of each row of the standardized matrix B and divide by n to obtain the weight vector. The formula is:

[0230]

[0231] 2.3. Calculate the largest eigenvalue :

[0232]

[0233] in Representing vectors The i-th component,

[0234] 3. Consistency check.

[0235] To ensure that the logic of the judgment matrix does not contain serious self-contradictions, a consistency check must be performed:

[0236] 3.1. Calculate the consistency index:

[0237]

[0238] 3.2 Calculate the consistency ratio:

[0239]

[0240] Where RI is the average random consistency index.

[0241] Conclusion: Due to The matrix is ​​determined to meet the consistency requirement, and the weight calculation is valid.

[0242] The specific process of step S4 is as follows:

[0243] Read the total number of unfinished Story Points currently held by this employee. );

[0244] The rating is negatively correlated with the load, even if the formula is: This means that the fewer tasks you have backlogged, the higher your score will be.

[0245] This score forms the employee's current workload rating. ),

[0246] The system connects to the company's GitLab via API.

[0247] The system scans Git commit logs using regular expressions (Fix #ID) to associate code changes with bug tickets in the company's OMS (Operation Management System). If a commit is associated with a bug ticket and marked as a bug ticket, the author of that commit is identified as the person responsible for introducing the bug. The system then calculates the employee's bug rate (Bugs / KLOC) over the past three months using the following formula: Normalization via function: For adjustment coefficients,

[0248] This score forms the employee's current code quality rating. ),

[0249] Based on the calculated dynamic weights Based on employee profiles, a comprehensive employee matching score is calculated.

[0250] Calculation formula:

[0251] .

[0252] in, For technology / business matching,

[0253] Rate the code quality.

[0254] Rate development efficiency.

[0255] Current load score

[0256] The response speed is scored.

[0257] As a skill weight,

[0258] For quality weight,

[0259] For efficiency weighting,

[0260] In response to weights,

[0261] This is the load weight.

[0262] Technology / Business Matching ( Based on employee characteristics, assign individual skill and module tags to each employee. For example, employee A is proficient in Java and Python and has developed core modules such as RBAC, MES, and BPM.

[0263] Code quality score ( ): Extract the bug rate (Bugs / KLOC) of the tasks handled by this employee over the past 3 months. Normalize it using a function: .

[0264] Development efficiency score ( ): Calculates the average actual working hours consumed per Story Point. The lower the value, the higher the efficiency score.

[0265] Current load score ( ): Reads the normalized values ​​of the employee's currently unfinished tasks. The fewer the tasks, the higher the score.

[0266] Response speed rating ( ): The average time difference between task assignment and the start of processing in history.

[0267] The system normalizes the raw data to form a standardized feature vector.

[0268] (Skill Weight): Corresponds to the technical / business matching degree, representing "whether it can be done". If the work order requires a high level of technical stack (such as low-level Java language optimization), this weight will be very high to prevent it from being assigned to someone who does not have the skills.

[0269] (Quality Weight): Corresponds to code quality / rating, representing "how well it's done". For the development of new features for core business modules, this weight will be increased, prioritizing the hiring of people with low code bug rates.

[0270] (Efficiency Weight): Corresponds to the development efficiency score, representing "how fast or slow it is done". This weight will increase for tasks with tight deadlines.

[0271] (Response Weight): Corresponds to the response score, representing "how fast the response is". For the highest level of online faults, this weight will become the largest (e.g., 0.5 or even higher). As long as the response is fast, the order will be dispatched first even if other conditions are mediocre.

[0272] (Load Weight): Corresponds to the R&D load score, representing "whether there is currently free time". For ordinary tasks, in order to prevent someone from being overworked, this weight plays a balancing role, prioritizing assignment to the person with the fewest Story Points currently available.

[0273] The specific process of step S5 is as follows:

[0274] Rank employees by score in reverse order, and assign the employee with the highest score to a work order.

[0275] The specific process of step S6 is as follows:

[0276] Update the development efficiency score ( ):

[0277] Extract the actual working hours and corresponding story points of the employee's completed tasks from OMS.

[0278] The formula for calculating the time taken per story point is: ,

[0279] To eliminate differences in task difficulty, only the average value of tasks with similar technology stacks is calculated.

[0280] The lower the value, the higher the efficiency; therefore, reciprocal normalization is used. (where k is the decay constant), ensuring that the score is between 0 and 1 and negatively correlated with the time consumed.

[0281] Re-updating response speed rating ( ):

[0282] By tracing the lifecycle of this employee's historical work orders, two key time points can be extracted: (Assignment time) and (Start processing time)

[0283] calculate It also automatically excludes non-working hours (such as weekends and nights).

[0284] Calculate the average response time of the employee's most recent 30 high-priority work orders. ,

[0285] ,in The baseline response time is 30 minutes. The faster the response, the closer the score is to 1.

[0286] The system performs Min-Max normalization on the raw data to form a standardized feature vector, which is then stored in the vector database.

[0287] The core innovations of this invention lie in the following three aspects:

[0288] Real-time workload balancing: Introduce "current task count" or "current remaining development hours" as real-time variables to prevent core developers from being overwhelmed by demand.

[0289] Dynamic weight adjustment: The system automatically adjusts the weights for "urgent production bugs" and "regular feature requests." Urgent production bugs are prioritized for the person who resolves them the fastest, while new features are prioritized for the person with the highest code quality.

[0290] Closed-loop feedback mechanism: The developer profile will be revised based on the bug rate, code review rejections, and test pass time after the task goes live.

[0291] To achieve the most scientific and objective weight allocation, this system does not use a rigid lookup table method, but instead constructs a judgment matrix for dynamic calculation. Based on the current scenario (e.g., a P0-level online fault), the system automatically generates the following 5x5 pairwise comparison matrix: Matrix example: The judgment in a P0-level fault scenario follows a response-first model.

[0292] *(Note: A value of 5 indicates that it is much more important, and 1 / 5 indicates that it is not important.)

[0293]

[0294] Calculation Steps: 1. Matrix Construction: The system reads the urgency of the work order and calls the preset "P0-level Fault - Judgment Matrix Template". 2. Eigenvector Calculation: Calculate the eigenvector corresponding to the largest eigenvalue of the matrix. 3. Consistency Check: Calculate CR = CI / RI. If CR < 0.1, it is considered logically consistent. 4. Normalization: Normalize the eigenvectors to obtain the final weight vector W. Example of Calculation Results: = 0.51, = 0.26,....... Result: Mathematical calculations have proven that in emergency situations, response speed does indeed play an absolutely dominant role, rather than being arbitrarily set by humans.

[0295] The core innovation lies in the fact that the weights of the five work orders are not fixed, but dynamically adjusted based on dimensions such as the "urgency" and "business importance" of the work order. This dynamic rule is continuously optimized based on actual results.

[0296] Developer profiles are not static. After each task is accepted or deployed, the system collects the number of test bugs, code review rounds, and actual development time for that task, and updates the developer's profile accordingly.

[0297] System module architecture:

[0298] It mainly consists of four modules:

[0299] 1. Data Collection and Profile Building Module: Extracts employee IDs and work order records from the historical database, calculates various basic indicators, and generates initial data.

[0300] 2. Work Order Parsing Module: Receives new work orders, extracts the work order type and urgency based on rules, and determines the required skill tags.

[0301] 3. Intelligent Matching Engine (Core):

[0302] Initial screening: Filter out frontline employees whose current status is "busy / on leave" or who do not have the relevant skills at all.

[0303] Scoring: Each employee in the candidate list is scored using the formula described above.

[0304] Decision: Select the employee with the highest score as the primary processor.

[0305] 4. Dynamic Update Module: Monitors work order status change events. When a work order changes to "archived", it reads the order details and updates the employee's profile database.

[0306] Implementation Process Example

[0307] Scenario 1: A bug (highest level) has appeared in the online payment module that causes an overflow in the amount calculation, which urgently needs to be fixed.

[0308] 1. Work order analysis: Type = Bug Fix, Module = Mes, Technology stack = Java, Urgency = Urgent.

[0309] 2. Weight Generation: Due to the highest-level online fault, the weights are adjusted as follows: .

[0310] 3. Candidate Scoring:

[0311] Developer A: Mes module expert, but currently working on a major closed version development project with an extremely full workload. Low).

[0312] Developer B: Familiar with the Mes module, although less experienced than A, but just finished the previous project and is currently free. high).

[0313] 4. Allocation: The system determines that B can be immediately put into repair to avoid the fault from escalating, so it is allocated to B.

[0314] 5. Feedback: After the fix was implemented, there were no regression errors, and the system improved B's "payment module familiarity" and "quality score".

[0315] Scenario 2: Development of Core New Features (Quality-First Case)

[0316] Suppose the work order task is: "Develop the core module of the next-generation billing engine, requiring high reliability."

[0317] 1. Ticket Analysis: Type = Feature, Module = Crm, Technology Stack = Java / Spring, Urgency = Medium

[0318] 2. Weight Generation: Based on the quality-oriented matrix, weights are generated as follows: , , .

[0319] 3. Comparison of candidates:

[0320] Developer C (Senior Architect): Has extremely high code quality (bug rate <1%), but works slowly (low efficiency score) and is quite busy.

[0321] Developer D (Kuaishou King): Writes code very fast, but doesn't like writing unit tests, resulting in a moderate bug rate.

[0322] 4. Allocation: Although D can finish writing faster, in this scenario, "quality" has a dominant weight (51%), and C wins with its superior quality score.

[0323] 5. Intention: It is better to be slower than to make the core modules error-free.

[0324] Scenario 3: Targeted Campaign on Activity Pages (Efficiency-First Case Study)

[0325] Suppose the work order task is: "Urgently develop a temporary marketing H5 page, to be launched tomorrow, and discarded after use."

[0326] 1. Ticket Analysis: Type = Marketing, Module = Solartown, Technology Stack = Vue, Urgency = Urgent.

[0327] 2. Weight Generation: Based on the efficiency-oriented matrix, weights are generated as follows: , .

[0328] 3. Comparison of candidates:

[0329] Developer E (Perfectionist): The code is written as neatly as poetry, but it will take 3 days to complete.

[0330] Developer F (Intern / Kuaishou): His coding style is messy, but he has no work to do and promises to finish it in one day.

[0331] 4. Allocation Decision: The system identifies the development time of E ( Option F cannot meet the requirements, while option F, although having a low quality score, scores extremely high in efficiency and load. The system decisively assigns option F.

[0332] 5. Intent: Everything is for timely release; code quality can be compromised.

[0333] Scenario 4: Legacy System Architecture Restructuring (Skills-First Case Study)

[0334] Suppose the work order task is: "Break the monolithic payment system into microservices, involving underlying database sharding and table partitioning."

[0335] 1. Work order analysis: Type = Refactor, Module = Platform core code, Difficulty = Extremely high.

[0336] 2. Weight Generation: Based on the skill-oriented matrix, weights are generated as follows: .

[0337] 3. Comparison of candidates:

[0338] Developer G (Chief Expert): He's the only one in the entire company who fully understands this old system, but he's extremely busy. Extremely low).

[0339] Developer H (Senior Developer): Knows a little, has relatively free time.

[0340] 4. Allocation Decision: Although G is very busy, the skill matching rate ( The weight of (G) overrides everything else. The system forcibly assigns the order to G, and may trigger an "overflow alarm" to notify the supervisor for coordination.

[0341] 5. Intent: This is a highly difficult task that requires expertise; there's no other way but to do it if you're busy.

[0342] It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention. Equivalent transformations or substitutions made based on the above technical solutions all fall within the scope of protection of the claims of the present invention.

Claims

1. A method for allocating program development tasks based on dynamic weighting and real-time load balancing, characterized in that, Includes the following steps: Step S1: Construct a multi-dimensional profile of developers, including static tags and dynamic indicators. Dynamic indicators include at least current R&D task load, historical code quality scores, historical development efficiency, and online fault response time. S2: Receive R&D work orders to be assigned, and parse the work order's technical stack requirements, business module, urgency level, and requester level. S3: Dynamic weight generation: Generate weight coefficients for each dimension indicator in real time based on the urgency level. When the urgency level is high, automatically increase the weight coefficients for response time and current load. S4: Load balancing scoring: Calculate the comprehensive matching score of candidate employees based on the weight coefficients and the multi-dimensional employee profile. A negatively correlated load scoring factor is introduced, so that employees with fewer ongoing work orders have higher comprehensive matching scores. S5: Assignment and execution: Assign the work order to the employee with the highest comprehensive matching score. S6: Closed-loop feedback update: Immediately after the work order is processed, collect the actual processing time and user rating, and use a moving average algorithm to update the historical indicators in the employee's multi-dimensional profile, achieving adaptive correction of the profile.

2. The program development task allocation method based on dynamic weighting and real-time load balancing according to claim 1, characterized in that, Step S1 is as follows: Establish a dynamically updated employee profile database. The profile construction includes two sub-processes: initialization and real-time updating.

1. Data Acquisition and Configuration: Technology / Business Matching The degree to which employees' technical skills and business modules match the requirements of work orders. Extract skill tag sets from employee profiles , Parse the work order for its set of requirement tags. , Calculate the intersection of the two sets, divide by the number of elements in the demand set, and obtain the coverage ratio. official: If the calculation result is 1.0, it represents full coverage, and full marks are awarded; if it is 0, 0 marks are awarded. The formula is normalized within the interval [0, 1].

2. Dynamic indicator calculation and normalization: Code quality rating Extract the Bugs / KLOC ratio from the 1,000 lines of code the employee was responsible for in the past 3 months, and normalize it using a function: , Development efficiency score Calculate the average actual working hours consumed per Story Point; the lower the value, the higher the efficiency score. Current load score : Read the normalized values ​​of the employee's currently unfinished tasks; the fewer the tasks, the higher the score. Response speed rating : Statistically analyze the average time difference from task assignment to the start of processing in history. The system normalizes the raw data to form a standardized feature vector, which is then stored in the database.

3. The program development task allocation method based on dynamic weighting and real-time load balancing according to claim 2, characterized in that, Step S2 is as follows: The business department submits a work order in the OA system. During the order approval process, the characteristics of the work order are refined, including the required technology stack, the relevant business module, and the order type. Order type: Bug: p0, p1, p2, p3, p4, p5 Priority: Urgent, Medium, General Development types: core business development, new technology evaluation, architecture upgrade.

4. The program development task allocation method based on dynamic weighting and real-time load balancing according to claim 3, characterized in that, The specific process of step S3 is as follows: 1) Build a dynamic weight matrix template. 1.1 Response-first model, After the system identifies a work order as P0 level, it calls the preset "P0 level fault" evaluation model to construct a 5th order judgment matrix. The values ​​in the matrix represent the relative importance of two indicators, using a 1-9 scale, where 1 represents equal importance and 9 represents extreme importance. The specific data structure of the matrix is ​​as follows: The first line compares response speed with other metrics: set to [1, 3, 5, 7, 9]. This means that under a P0 failure, "response speed" is 3 times more important than "current load," 5 times more important than "skill matching," 7 times more important than "development efficiency," and 9 times more important than "code quality." The second line compares current workload with other metrics: set to [1 / 3, 1, 3, 5, 7]. This means that while "current workload" is not as important as response speed, it is more important than skill, efficiency, and quality, because if employees have too many tasks piling up, they simply cannot respond. The third row compares skill matching with other metrics: set to [1 / 5, 1 / 3, 1, 3, 5]. The fourth line compares development efficiency with other metrics: set as [1 / 7, 1 / 5, 1 / 3, 1, 3]. The quality of the fifth line of code is compared with other metrics: set as [1 / 9, 1 / 7, 1 / 5, 1 / 3, 1]. Here, code quality is given the lowest priority, which conforms to the principle of emergency stop-loss. 1.2 Quality-First Model When a work order is identified as a new feature development for core business operations, the system automatically switches to a quality-first model. The first line's response speed is compared to the others: set as [1, 1 / 5, 1 / 7, 1 / 3, 1 / 9], indicating that response speed is the least important, its importance being only 1 / 9 of code quality. The second line compares the current load with others: set to [5, 1, 1 / 3, 3, 1 / 5]. Load is more important than response time, but far less important than skill and quality. The third row's skill matching is compared to others: set to [7, 3, 1, 5, 1 / 3]. Skill is the core element second only to quality. The development efficiency of the fourth line is compared with others: set to [3, 1 / 3, 1 / 5, 1, 1 / 7], the efficiency is in the lower middle range. The quality of the fifth line of code compared to others: set to [9, 5, 3, 7, 1], the code quality is absolutely dominant, more important than any other metric. 1.3 Efficiency-first model, When the system detects that a project is entering its deadline countdown, it switches to an "efficiency-first" mode. The first line compares response speed with others: set to [1, 1 / 3, 1 / 5, 1 / 7, 1]. Response speed and quality are both low priority. The second line compares the current load with others: set to [3, 1, 1 / 3, 1 / 5, 3]. Load is more important than response and quality, but must yield to efficiency. The third row of skill matching is compared with others: set to [5, 3, 1, 1 / 3, 5]. Skills are the basic guarantee. The fourth line compares development efficiency with other metrics: set to [7, 5, 3, 1, 7]. Development efficiency is given the highest priority (9 times that of quality) and is 3 times more important than skills. The quality of the fifth line of code is compared with others: set as [1, 1 / 3, 1 / 5, 1 / 7, 1]. In the critical delivery period, quality temporarily takes a backseat. 1.4 Skills-first model When a work order involves "architectural upgrade" or "introduction of new technology stack", the system switches to a "skills-first" model. The response speed of the first line is compared with others: set to [1, 1, 1 / 7, 1 / 5, 1 / 3]. The second line compares the current load with others: set it to [1, 1, 1 / 7, 1 / 5, 1 / 3]. For high-difficulty tasks, the level of workload is not crucial. The third row, skill matching compared to others: set to [7, 7, 1, 3, 5], emphasizes skill matching; only experts can accept orders. The development efficiency of the fourth line is compared with others: set to [5, 5, 1 / 3, 1, 3]. The quality of the fifth line of code is compared with others: set as [3, 3, 1 / 5, 1 / 3, 1]. 2) Calculate the feature vector and weights based on the characteristics of the work order. The bug in the first-weighted work order characteristic is at level P0, which will definitely match the response-first model. The second priority for special work orders is urgency, with matching efficiency taking precedence. Finally, match based on type. 2.1 Column Vector Normalization: Divide each column element of the judgment matrix A by the sum of the elements in that column to obtain the standardized matrix B, as shown in the formula: (i,j=1,2,...,n) Where n=5 is the number of indicators. : Represents the judgment matrix The element in (the first) Okay, number The value of the column), representing the number of columns. The first indicator is relative to the first The importance of each indicator : Represents a matrix The Middle The sum of all elements in the column. Meaning: This is the denominator in the normalization process, used to proportionalize the values ​​in this column so that the sum of the weights calculated subsequently is 1. : Represents the standardized matrix The elements in the table are the original judgment values. Dividing by the sum of the columns is a step to eliminate the influence of different column dimensions and is used to calculate the final weight vector. The necessary preliminary steps : Represents the number of metrics (evaluation dimensions), as specified in the document. These correspond to the five core dimensions mentioned in the document: Technology / Business Matching Degree ) Code quality score ( ) Development efficiency score ( ) Response score ( ) R&D workload score ( ) 2.2 Row Summation and Average Eigenvector Approximation: Sum the elements of each row of the standardized matrix B and divide by n to obtain the weight vector. The formula is: For the first The final weight coefficient calculated for each evaluation indicator represents the weight of the current work order in the given scenario. The relative importance of each indicator compared to other indicators, all The sum of them is approximately 1. These are the normalized elements, which are the standardized judgment matrix calculated in the previous step. The elements in the matrix eliminate the influence of different column dimensions in the original judgment matrix, allowing the data in each row to be directly added together. Row sum, normalizing the matrix In the middle, the first This step sums up all the values ​​in the row, representing the sum of the values ​​in the first row. The relative importance share of each indicator in all comparisons Calculate the average and divide by the total number of indicators. By averaging the "row sums", a smoother and more accurate weight estimate can be obtained. , 2.

3. Calculate the largest eigenvalue : This is the judgment matrix. The theoretical largest eigenvalue, The first vector product One component: For the first The weight of each indicator, For consistency ratio components, 3) Consistency check, To ensure that the logic of the judgment matrix does not contain serious self-contradictions, a consistency check must be performed: 3.

1. Calculate the consistency index: This is an indicator for measuring the degree of deviation of the judgment matrix from consistency. If : Indicates that the judgment matrix has complete consistency. like The larger the value, the more serious the logical contradiction in the matrix. As a denominator, it is used for normalization. 3.2 Calculate the consistency ratio: This is the final criterion, used to measure whether the logical disorder of the judgment matrix you constructed is within an acceptable range. This indicates that the judgment matrix has passed the consistency test, and the calculated weights are valid and reliable. This indicates that the logical contradiction is too great, and the judgment matrix needs to be readjusted until the conditions are met. Average random consistency index: This is an empirical constant representing the average consistency deviation generated when randomly filling in a matrix of the same order. It serves as the denominator and acts as a reference, using the actual deviation ( Removed by random bias ( ), The value depends only on the order of the matrix. , The setting here is , Conclusion: Due to The matrix is ​​determined to meet the consistency requirement, and the weight calculation is valid.

5. The program development task allocation method based on dynamic weighting and real-time load balancing according to claim 2, characterized in that, The specific process of step S4 is as follows: Read the total number of unfinished Story Points currently held by this employee. ; The rating is negatively correlated with the load, even if the formula is: This means that the fewer tasks you have backlogged, the higher your score in this category. This score forms the employee's current workload rating. , The system connects to the company's GitLab via API. The system scans Git commit logs using regular expressions, linking code changes to bug tickets in the company's OMS (Operation Management System). If a commit is associated with a bug ticket and marked as a bug ticket, the author of that commit is identified as the person responsible for introducing the bug, and the system extracts the bug rate per thousand lines of code for that employee over the past three months. The calculation formula is: Normalization via function: For adjustment coefficients, This score forms the employee's current code quality rating. ), Based on the calculated dynamic weights Based on employee profiles, a comprehensive employee matching score is calculated. Calculation formula: , in, For technology / business matching, Rate the code quality. Rate development efficiency. Current load score The response speed is scored. As a skill weight, For quality weight, For efficiency weighting, In response to weights, This is the load weight.

6. The program development task allocation method based on dynamic weighting and real-time load balancing according to claim 2, characterized in that, Step S5 is as follows: sort employees by score in reverse order, select the employee with the highest score, and assign an entry order to them.

7. The program development task allocation method based on dynamic weighting and real-time load balancing according to claim 2, characterized in that, The specific process of step S6 is as follows: Update development efficiency rating : Extract the actual working hours and corresponding story points of the employee's completed tasks from OMS. The formula for calculating the time taken per story point is: , To eliminate differences in task difficulty, only the average value of tasks with similar technology stacks is calculated. The lower the value, the higher the efficiency; therefore, reciprocal normalization is used. Where k is a decay constant, ensuring that the score is between 0 and 1 and is negatively correlated with the time consumed. Re-updated response speed rating : By tracing the lifecycle of this employee's historical work orders, two key time points can be extracted: Assignment Time Start processing time, calculate It automatically excludes non-working hours and calculates the average response time of the employee's most recent 30 high-priority work orders. , ,in The baseline response time is 30 minutes. The faster the response, the closer the score is to 1. The system performs Min-Max normalization on the raw data to form a standardized feature vector, which is then stored in the vector database.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the program development task allocation method based on dynamic weight and real-time load balancing as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the computer instruction is executed by the processor, it implements the program development task allocation method based on dynamic weight and real-time load balancing as described in any one of claims 1-7.

Images