preface

Speaking of Agile, I have always wanted to carry out the idea, but the reality is that I have been doing some optimization work of Agile. Due to various current situations and environmental problems, there is no way to fully practice the Agile theory. What I want to do is to find a kind of neutral product between the traditional R&D method and the agile R&D method. The corporate system is not easily changed, the leadership’s thinking is not so easy to change, organizational division and team barriers are not so easy to break down. Gradually, I became less concerned with concepts, practices, processes, etc., and more focused on sticking to the core concepts of Agile and adapting to improve the existing development process, such as: rapid iteration, high priority requirements driven, maximizing the team’s self-motivation, etc.

So I’m not sure if the title fits, is this Agile? In 2019, I also wrote an article about the agile development process, a summary of the development process for the current situation at that time. Today, organizations, functions and teams have all changed. This article is just a few ideas about the current situation, and the scope is within the research and development department. Some unreasonable still exist, but the best is the one that is suitable.

R&D role division

  • Software Architect

    The architect develops the overall business architecture, application architecture and technical architecture for all projects and products to ensure the stability and extensibility of the products. Guide the pre-research and implementation of cutting-edge technologies; Participate in team echelon building, talent training, improve team technical ability; Formulate unified technical standards, tools and procedures.

  • Team Leader

    Responsible for physical team work scope management, work time management, quality management, team management, communication management and corresponding problem solving.

  • Project leader (may overlap with team leader)

    Responsible for the R&D process control of specific projects.

  • Research and development personnel

Research and development process

The basic requirements for the research and development phase are:

  • Teams are leveled.
  • All necessary outputs must be managed in the knowledge base.
  • All personnel must strictly use project management tools (currently MASTERLAB tools in R & D) to keep track of their own task status.
  • The physical team needs to support the project team.
  • All research and development activities must comply with the specifications and standards of each physical team, and the physical team leader verifies the output.

For different demand sources in the research and development stage, our research and development process can be divided into:

  • demand-driven

    It will be the dominant R&D approach, characterized by the initiation, collection and boundary of requirements by the upstream department of R&D (currently the product), and the process boundary of R&D starting from requirements review and finally submitted to the testing department.

  • Business driven

    The nature of the project determines the direct docking of business research and development, which is more common in small scale or enterprise retention systems. The process boundary of development begins with requirements gathering and ends with submission to the testing department.

    For secondary development projects, demand-driven or business-driven projects can be flexibly adopted depending on the size and future planning

  • event-driven

    It is mainly aimed at the occurrence of emergency events such as temporary events, online problems, high priority and small demands. Research and development needs to adopt a special process with high mobility and high response.

demand-driven

Project team composition

Team features include:

  • Cross-functional, including front-end and back-end developers (including testers is recommended).
  • Include the required technical line personnel across the technology stack.
  • It can be built on a project basis or on a demand cycle basis.

  • Role:

    • Product Owner(PO) : Project leader

      The primary responsibility of the project leader is to maximize the ROI (Return on Investment). Specifically, it is necessary to determine product functions, ensure that the requirements are reasonable at the research and development level, and determine the priority of functions; Develop and implement R&D plans; Control the whole R&D process to ensure the project schedule and product quality;

    • Dev Team(DT) : The development Team

      The development team needs to have a certain breadth of technology and stable staff.

    • Scrum Master(SM) : Team mentor/organizer

      The Scrum Master needs to remove all obstacles to the team’s goals and ensure that the team members are as focused as possible on their own work. Facilitate team communication and help others clarify their responsibilities. Be a typical service Leader and direct team operations.

      This can be done by an architect or an experienced team lead.

Flow mode

R&d link

The flow chart of research and development is as follows:

The requirements phase

  • Requirements presentation/validation/analysis/validation

    • Participants: Architect, R&D team leader, requirements analyst, UI, QA

    • Organize requirement presentation meeting, analyze, decompose, propose and solve problems, confirm the details of requirements.

      • Requirement briefings may be repeated until there are no more questions about the requirements.
      • Demand talk is equal, not in the form of command, otherwise it will reduce the effectiveness.
      • Requirements analysts need to have a high level of business understanding and involvement, minimize the scope of the meeting, and avoid the inefficient approach of everyone participating.

    • About the boundaries of the requirements

      • If the demand is large, whether the demand is divided into stages and the demand boundary of each stage must be determined. When the demand cycle exceeds 4 weeks, it must be divided into stages.

      • If the demand is not divided into stages

        • When the cycle exceeds two weeks, the PO has the right to stage the development process, i.e., multiple sprints, to ensure continuous output.

      • If the demand is in stages

        • Each stage of the demand must be clear, if the stage of the demand is not clear, should not be included in this demand analysis. Each requirements phase addresses an Epic in agile development.
        • The following development process will only start with the current requirements phase. The subsequent requirements phase starts the cycle directly from the development process

    Output:

    • All the meeting minutes, archive knowledge base
    • Requirements cycle and requirements boundary
    • Signature of requirements by business department

  • Demand resource preparation

    1. Internal Review of Requirements

      Internal review requirements for R&D architects and team leaders, including:

      • Requirement difficulty
      • The matching degree of personnel required by the requirements
      • Workload estimation
      • staffing

      And through the R&D internal ST meeting decision.

    2. Project Team Building

      • PO and SM need to communicate with DT for the first time to make it clear:

        • What does the team do?
        • When will it be ready?
        • How to do?

    3. Requirements decomposition and presentation

      • The PO uses the MasterLab tool for task decomposition of the requirements
      • For complex requirements, PO writes requirements documents

      Output:

      • The requirements document

        • If the requirements are phased, a requirements document needs to be created for each Epic.
        • The requirements document is a matrix that specifies the list of Epic User Story (User Story, equivalent to the concept of functional modules). It avoids being as long as the traditional requirements document, and only needs to simply describe the functions (in the short cycle of agile, each User story will not be too complex).
      • The PO needs to communicate closely with the team members, communicate the requirements, and ensure that everyone understands what is being done.

The design phase

  • API interface design

    • According to the UI prototype design front and back data interaction interface.
    • If the PO does not have a technical background, the team leader may be required to assist.

  • Data structure design

    • The PO designs the data structure and is reviewed by the R&D Architect and delivered to the development team. (Data structure is more special, should avoid different people to design).

  • Business process/interaction design

    • The PO designs processes and front-end interactions for some of the core, complex business needs based on the requirements document.

  • The system design

    • The system design is carried out by the R&D architect and needs to be considered from the perspective of the entire technology center or the entire self-research

    • Assess the impact of this requirement on existing online systems

      • Whether you need support from other services
      • Whether the existing architecture needs to be changed
      • Whether to cause existing services to need to be extended

    • Design solutions

      • If the involvement is minor, the R&D architect will directly arrange personnel to solve the problem.
      • If it involves a wide range of projects, including other project teams, the architect will coordinate and arrange for the solution.
      • Such additional workload must also be included in the project workload and adjusted through the ST meeting.

  • Efficient communication

    • PO and DT must establish effective communication

      • DT questions about requirements
      • Design purpose of the PO for the requirements
    • The architect or ST team is available to assist and support the team.

Output:

  • API Interface Document
  • System design document (ignore form, brief summary)
  • Data structure files, database upgrade scripts

Research and development phase

  • The PO initializes the corresponding development preconditions, such as codebases, repositories, permissions, etc.

  • PO establishes the corresponding sprint stage on MASTERLAB and is responsible for monitoring the quality of the sprint.

    • The PO should control the development progress and adjust the personnel tasks according to the actual situation
    • PO and DT need to ensure efficient daily communication
    • SM needs to guide the team to function correctly and remove obstacles

  • Daily station will

    1. What did I do today
    2. What am I going to do tomorrow
    3. What’s the problem I’m having

  • Internal testing

    • After a DT member completes a function of his or her own, he or she must be tested to ensure that the function is usable
    • The PO needs to do a basic audit of daily output

  • Submit to test department

    • The PO has the right to decide whether to partially upgrade the test version on a daily basis or on a certain number of completed tasks to ensure sprint time (e.g., delays due to force majeure factors, requirements changes).
    • The PO reviews the code and builds the test version, preparing the upgrade scripts (SQL, configuration, etc.). Communicate with the testing department about the content covered by the version, inform the test version number, and submit the testable image.

    Output:

    • Testable version image
    • The upgrade script
    • Deployment instructions (can be resolved by communicating with the test)

  • Return to the

    • If part of the test, test cycle and development cycle overlap, DT priority to modify defects, and then do new tasks.

  • About DT

    • DT must change the state of his task on Masterlab in real time.
    • DT must be written in strict accordance with uniform technical standards and code specifications.
    • DT reports their questions and problems in real time, PO is responsible for business problems, and SM is responsible for coordinating and solving other problems.

  • On Sprint Failure

    • If the sprint time ends and the task is not completed, the sprint fails.
    • When the sprint fails, priority is given to continuing to complete the task. The PO estimates the remaining time to complete the task, starts a new sprint, and pulls the unfinished task into the new sprint.
    • The responsibilities of PO and DT will be discussed in detail at the evaluation meeting.

Test/Regression

The link between development and testing is primarily upgradation and regression, interacting with relevant regression tools through standard test version numbers. During this period, some problems and disputes shall be communicated and coordinated by the product and SM.

Release and close

  • release

    • The testing department agrees to go online and stipulates the time of going online
    • The PO set up the online TAG version in the code base, and prepared the necessary conditions such as deployment instructions and relevant script configuration

    • online

      • Participants: PO, Architect, Product, QA
      • The Release Manager is responsible for going online
      • Be prepared to launch a failed rollback
      • QA conducted online testing after the launch and confirmed that there were no problems. The launch was successful

  • assessment

    • The PO needs to organize the team to do a sprint review after successful launch

      • Architect, SM, QA are required to attend
      • Analyze the good part and the bad part of the sprint and sum up the experience
      • If the sprint fails, discuss why.

    • The PO needs to write the Sprint Review document

      • Record the details of the review meeting.
      • Summarize and evaluate DT team members. Points shall be deducted for those with poor code quality and large number of defects, points shall be added for those with good code quality. The standards for project incentive payment shall be combined with workload and performance, etc.
      • If the sprint is a failure, need to analyze the reason, if external causes, also need to explain.

Business driven

The business-driven R&D process is on the whole the same as the demand-driven R&D process, but the difference is that there will be direct business docking R&D in the demand collection process:

Correspondingly, the process in the subsequent research and development stage will be reduced or adjusted according to the specific situation.

event-driven

Follow event-driven processes for very high priority, urgent needs. The event-driven process is equivalent to the rapid response process within the research and development. There are no strict requirements on the process specifications and standards, so as to achieve the purpose of rapid response.

  • Changes in existing project requirements or new minor requirements

    • PO, SM to negotiate the plan, the plan needs to pass the ST resolution.

    • The quick process is as follows:

      • design
      • The development of
      • Iterative testing
      • The deployment of

    • Related products are

      • API interface
      • Task breakdown details
      • Defect records
      • Deploy the required configuration scripts and live images

  • New demands are pressing for large chunks of demand

    • Go through the R & D process when there are enough people

      • Iterative testing with partial test was adopted for testing.

    • In the case of insufficient personnel

      • ST meeting to identify requirements priorities
      • Freeze ongoing sprints with lower priority
      • Determine the requirement PO and directly enter the requirement phase.
      • If the number of people is not enough, try not to freeze more sprints in progress, draw people into demand, draw people into the sprint delay.
      • Iterative testing with partial test was adopted for testing.

  • Online problem

    The PO is fully responsible for responding and coordinating relevant resources and personnel, with problem solving as the first priority.

Please follow my blog