This article is not perfect, but more about some ideas and processes for quick execution and some rules summarized in the early stage of the team.

About Agile Development

What is Agile

At the core of Agile is iteration:

Our development process uses the Agile Scrum approach, which is more in line with our current situation than the traditional waterfall model and other Agile methods:

  • Iterative development
  • Incremental delivery
  • Self-organizing team
  • High-priority requirements drive

At the same time, our R&D process is not standardized Scrum, but a set of process that is more in line with our actual situation by combining the characteristics of our own enterprise and the characteristics of our team.

Here are the values of agile development:

  • Programmer initiative, and interaction between programmers, takes precedence over established processes and tools.
  • Software works and is better than detailed documentation.
  • Work closely with customers over contracts and negotiations.
  • Being able to respond to change is better than following a plan.

Here are the twelve principles of agile development:

  1. Achieve customer satisfaction through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even in the late stages of project development. Be good at taking advantage of changing requirements to help customers gain competitive advantage.
  3. Deliver working software over and over again, usually in a matter of weeks, the shorter the better.
  4. During the project, the business people and the developers must work together.
  5. Projects must be built around individuals who are internally motivated and should be trusted.
  6. Face-to-face conversation is the best form of communication.
  7. Usability is the primary measure of progress.
  8. Advocate sustainable development and maintain a steady rate of progress.
  9. Constantly focus on whether the technology is good, whether the design is good.
  10. Simplicity is critical, and minimizes unnecessary work as much as possible.
  11. The best architectures, requirements, and designs come from a spontaneous understanding within the team.
  12. The team must periodically reflect on how to be more effective and adjust accordingly.

Agile Development Requirements

  • High level of code quality and personnel quality
  • High level of automated testing
  • High level of configuration management (code version, application, environment)
  • Continuous integration, continuous delivery, continuous deployment

Team division

Our team is divided into physical team and agile team:

  • Physical team: UI team, Android team, iOS team, FE team, Java team, QA team, Product team

    • Have a team leader
    • The code base, configuration base, knowledge base, and so on follow the physics team
    • People belong to the physical team

  • Agile teams:

    • Cross-functional, including UI, front-end, back-end developers, QA
    • It can be built on a project basis or on a demand cycle basis

    • Role:

      • Power Owner(PO) : Project leader, preferably with technical background
      • Dev Team(DT) : The development Team

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 the project management tool JIRA to keep track of the status of their tasks.
  • When the PO is not very good at a certain stage, it needs to be supported by the physics department leader.
  • 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.

demand

When it is determined that it needs to be done, it enters the demand stage, which is divided into the following steps:

  1. Requirements gathering

    • Confirm the PO.
    • The PO collects the requirements from the source of the requirements, which may be the product or directly the customer

  2. Demand analysis

    • Participants: PO, requirements analysts (currently basically physical team leaders), UI, QA, product

    • Brainstorm: Organize the requirements analysis meeting, analyze the requirements, break down the requirements, propose and solve the problems, confirm the details of the requirements.

      • Requirements analysis can be done several times until there are no more questions about the requirements.
      • Requirements analysis would be in the form of equality, not command, which would limit the effectiveness of brainstorming.
      • 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

  3. Needs to be finalised

    • JIRA and Confluence initialize the project
    • The PO writes the requirements document
    • UI Design Prototype

    Output:

    • The requirements document

      • If the demand is in stages

        • 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).

    • UI Design Prototype

      • UI design for the current Epic prototype
      • If the requirements are phased and the requirements for each phase are clear, the UI must submit the corresponding Epic prototype before the next phase of development.

  4. Internal Review of Requirements

    • Participants: PO, requirements analysts (currently basically physical team leaders), UI, QA, product
    • Confirm that the requirements meet expectations based on the requirements document and the UI design prototype. If there is a change in demand and not expected, timely adjustment.

  5. External validation of requirements

    • Identify requirements with business units
    • Signature of business department

  6. Decomposition of demand

    • The PO needs to decompose the demand as follows:

      • 1. Epic
      • User Story
      • Task 1.
      • Sub-Task

      To break down requirements at the level of DT team members is already a fine development task.

    • The PO needs to be Backlog on the JIRA.
    • If the PO does not have a technical background, it can be assisted by the physics team leader.

  7. Build a DT team

    • The PO needs to communicate with the physics team leader and coordinate personnel.
    • The physical team leader needs to make judgments and appropriate arrangements based on the priority of the requirements, the capabilities of the team members, the existing workload, and the matching degree of the requirements.

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

      • What does the team do?
      • When will it be ready?
      • Who is going to do?

      The physics team leader also needs to be involved in communication, assistance and advice.

design

  • API interface design

    • According to the UI prototype design front and back data interaction interface.
    • If the PO has no technical background, the physics team leader is required to assist.

  • Data structure design

    • The physical team leader designs the data structure and delivers it 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.
    • If the PO has no technical background, the physics team leader is required to assist.

  • The system design

    • The system design is executed by the physics team leader

    • 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

      • In case of minor involvement, the physics team leader directly arranges personnel to solve the problem.
      • If it involves a wide range of communication, including the front and back, each physics team leader will negotiate the plan and arrange personnel to solve the problem respectively.
      • JIRA creates a new User Story and Task, which are assigned to the current project requirements.
      • The scheduling person is not part of the current project team.

  • Efficient communication

    • PO and DT must establish effective communication

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

Output:

  • API Interface Document
  • PDM data structure file, database upgrade script

The development of

  • The physical team leader initializes the corresponding codebase, repository, permissions, and other development preconditions.

  • The PO establishes the corresponding sprint phase on the JIRA and has the responsibility to monitor 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
    • Submitted code needs to be reviewed by the physics team lead

  • 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 basic functional testing on the daily output

  • Submit to test department

    • The PO has the right to decide whether to adjust the time of a sprint (for example, development is slow) by partially testing the version on a daily basis or on a certain number of completed tasks.
    • The physical team leader reviews the code and builds the test version, preparing the upgrade scripts (SQL, configuration, and so on). The PO communicates with the test department what is covered by the version (task number on JIRA) and tells the test version number.

    Output:

    • Testable version
    • 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

    • The DT must change the state of his task on the JIRA in real time.
    • The DT must be written in strict accordance with the code specifications of the physical department to which it belongs.
    • DT reflects its own questions and problems in real time, PO is responsible for business issues, technical issues are responsible for by each physical team leader or discussed with other team members.

  • 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

  • The links between development and testing are mainly upgraders and regressions, interacting with the JIRA tool through standard test version numbers.

Deployment/Evaluation

  • The deployment of

    • The testing department agrees to go online and stipulates the time of going online
    • The physical team leader sets up the online TAG version in the code base and prepares the deployment instructions and related script configuration requirements

    • online

      • Participant: PO, physics team leader, QA
      • The physics team leader 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
    • The person in charge of the physical department needs to maintain the on-line list, including the estimated on-line time, scope, influence, etc., to facilitate version management and avoid confusion caused by on-line operation and disunity between front and back.

  • assessment

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

      • Physics team leader, 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.

Daily maintenance

  • Online problem

    • This will be solved by the PO and the physics team lead

Fast track

Take the fast track for very high priority, urgent needs or high impact needs.

  • Changes in existing project requirements or new minor requirements

    • The PO negotiates with the physics team leader to arrange personnel.

    • The quick process is as follows:

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

    • Related products are

      • API interface
      • Jira的Task
      • Defect records
      • Deploy the required configuration scripts, available online packages

  • 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

      • R & D leader identifies 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.

Daily management

The day-to-day management is based on the physical team.

Team management

  • Internal team structure

    • The internal divisions of the team are managed and optimized by the physical team leader

    • The team members should be divided into three parts:

      • Core staff

        Undertake the development of core business and modules, and also undertake some pure technical work (technical framework upgrading, new technology learning and research) as well as help and guidance of new staff. The selection of PO is mainly for core staff.

      • The developer

        Undertake the main development work, select good quality, self-motivated, upright character as the core personnel training.

      • Intern Trainer

        Undertake the development of some simple, basic functional modules, aiming to learn deeply and integrate into the team as soon as possible. If not, it needs to be eliminated in time.

  • Personnel training

    • Help and

      • One to one

        New employees or interns will be assisted one on one by key team members or skilled personnel. Mainly in the technical guidance, so that the corresponding personnel as soon as possible to start and integrate.

      • Pair programming

        If staffing conditions permit, decomposed development tasks can be completed in groups of 2 people.

        • One backbone developer + one weaker developer
        • One core person + one intern or new employee

    • Training/Sharing

      • Hold regular communication meeting within the team

        • Conduct training on development specifications and development skills
        • Share good technical solutions, methods and tools within the team, take rotation system.
        • Experience sharing on problem solving

    • share

      • Encourage team members to share their expertise in technology, tools, methods, etc., and upload knowledge base. Incentives can be appropriate according to the results.

    • Stop loss

      • For can’t adapt to the team, do not want to improve themselves, even if the conduct of misconduct personnel eliminated.
      • For the personnel with insufficient potential and weak subjective initiative, but it does not affect the completion of the task, the focus of training should be properly recovered and expectations should be lowered.

  • The team atmosphere

    • The team leader needs to keep the team positive and busy.

Technology system

  • The optimization and upgrading of technical system is a continuous and ecological work.

    • Technical Framework Upgrade
    • The optimization of the implementation scheme
    • Learning and introducing new technology and new concept
  • The technical system is mainly responsible by the team leader and the core personnel

The work in this aspect has a slow effect and low output, but it is the basis for how far the whole team can go. As a technical person, stopping the pace means being eliminated.

Code base/repository management

  • It is managed by the team leader, ensuring security and not revealing the configuration of the production environment.

Please follow my blog