A few thoughts on agile development processes

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

About Agile Development

What is Agile

At the core of Agile is iteration:

Our r&d process uses the Scrum method of agile development, 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 driven

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

Here are the values of Agile development:

  • The subjective initiative of programmers, and the interaction between programmers, is superior to established processes and tools.
  • Software works better than detailed documentation.
  • Close collaboration with clients is better than contract and negotiation.
  • Able to respond to change, better than following a plan.

Here are the twelve principles of Agile development:

  1. Customer satisfaction is achieved through early and consistent delivery of valuable software.
  2. Welcome changing requirements, even late in project development. Be adept at taking advantage of changing requirements to help customers gain competitive advantage.
  3. Deliver usable software over time, usually a few weeks, the shorter the better.
  4. Business people and developers must work together during a project.
  5. Projects must be built around individuals who are intrinsically motivated and should be trusted.
  6. Talking face to face is the best way to communicate.
  7. Availability is the primary measure of progress.
  8. Promote 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 essential and minimizes unnecessary work.
  11. The best architectures, requirements, and designs come from spontaneous awareness within the team.
  12. The team periodically reflects on how to be more effective and adjusts accordingly.

Agile development requirements

  • High level of code quality and people 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 teams and agile teams:

  • Physical team: UI team, Android team, IOS team, FE team, Java team, QA team, product team
    • Have a team leader
    • Code libraries, configuration libraries, knowledge bases, and so on follow the physical team
    • People belong to the physics 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) : Development Team

Research and development process

The basic requirements for the r&d phase are:

  • The team is horizontal.
  • All necessary outputs must go into knowledge base management.
  • All personnel must strictly use the project management tool JIRA to continuously track the status of their own tasks.
  • When the PO is not good at a certain stage, it needs to be supported by the head of the physics department.
  • The physics team needs to support the project team.
  • All research and development activities must comply with the specifications of each physics team, and the physics team leader verifies the output.

demand

When you determine what needs to be done, enter the requirements stage, which is divided into the following steps:

  1. Requirements gathering

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

  2. Demand analysis

    • Participants: PO, requirements analyst (currently basically physical team leader), UI, QA, product
    • Brainstorming: PO organized demand analysis meetings, analyzed and decomposed requirements, raised and solved problems, and confirmed all details of requirements.
      • Requirements analysis can be done several times until there are no more questions about requirements.
      • Requirements analysis will be equal, not in the form of commands, which would limit the effectiveness of brainstorming.
      • The requirements analyst needs to have a high level of business understanding and engagement, minimize the scope of meetings, and avoid an inefficient approach in which everyone participates.
    • About the boundaries of requirements
      • If the demand is large, whether the demand is carried out in stages and the demand boundary of each stage must be determined. When the demand cycle exceeds 4 weeks, the demand must be carried out in stages.
      • If there is no stage of demand
        • When cycles exceed two weeks, the PO has the right to stage the development process into multiple sprints to ensure continuous production.
      • If the demand is phased
        • The requirements of each stage must be clear. If any stage requirements are not clear, they should not be included in this demand analysis. Each requirements phase addresses an Epic in Agile development.
        • The rest of the r&d process only starts with the current requirements phase. Subsequent requirements phases start the cycle directly from the development process.

    Output:

    • Meeting minutes, archiving knowledge base
    • Demand cycles and demand boundaries

  3. Needs to be finalised

    • Jira and Confluence initialization projects
    • PO writing requirements documentation
    • UI Design prototype

    Output:

    • The requirements document
      • If the demand is phased
        • Requirements documentation needs to be established for each Epic
      • The requirements document is a matrix of Epic User stories (the concept of functional modules), avoiding the traditional way of lengthy requirements documents and simply describing the functionality (in the short agile cycle, each User story is not too complex).
    • UI Design prototype
      • UI design current Epic prototype
      • If the requirements are staged and the requirements are clear, the UI must submit the Epic prototype before the next stage of development.

  4. Internal requirements review

    • Participants: PO, requirements analyst (currently basically physical team leader), UI, QA, product
    • Verify that requirements meet expectations based on requirements documents and UI design prototypes. Adjust in time if requirements change or are not as expected.

  5. External validation of requirements

    • Identify requirements with business units
    • Business department signature

  6. Decomposition of demand

    • The PO needs to decompose the requirements as follows:

      • Epic
      • User Story
      • Task (Task)
      • Sub-Task

      To break down the requirements at the level of the DT team, ensuring that the development task is already very detailed.

    • PO needs to be added to the Backlog in Jira.

    • If the PO has no technical background, it can be assisted by the physics team leader.

  7. Build DT team

    • PO needs to communicate with physics team leader and coordinate personnel.

    • The physical team leader needs to make a judgment and reasonable arrangement based on the priority of requirements, the ability of team members, the existing workload, and the matching degree of requirements.

    • PO needs to communicate with DT for the first time to clarify:

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

      The physics team leader also needs to communicate, assist and advise.

design

  • API Interface design
    • Design front and back data interface according to UI prototype.
    • If the PO has no technical background, the physical team leader is required to assist.
  • Data structure design
    • The physics team lead designs the data structure and delivers it to the development team. (Data structure is special, should avoid different people to design).
  • Business process/interaction design
    • PO designs processes and front-end interactions based on requirements documents for core, complex business needs.
    • If the PO has no technical background, the physical team leader is required to assist.
  • The system design
    • The system design is performed by the physics team lead
    • Evaluate the impact of this requirement on existing online systems
      • Whether support from other services is required
      • Whether existing architecture needs to be changed
      • Whether existing services need to be extended
    • Design solutions
      • If the problem is small, the physical team leader will arrange personnel to solve it directly.
      • If communication is involved, including the front and back end, each physics team leader will negotiate the scheme and arrange personnel to solve it.
      • Jira creates a new User story and Task, belonging to the current project requirements.
      • The scheduler is not part of the current project team.
  • Efficient communication
    • Efficient communication must be established between PO and DT
      • DT’s question about requirements
      • PO design purpose for requirements
    • The physics team leader is always available to assist and support the team.

Output:

  • API Interface documentation
  • PDM data structure files and database upgrade scripts

The development of

  • The physical team lead initializes the appropriate code base, configuration base, permissions, and other development preconditions.

  • PO establishes corresponding sprints on Jira and is responsible for overseeing the quality of sprints.

    • PO shall control development progress and adjust personnel tasks according to the actual situation
    • PO and DT need to ensure efficient daily communication
    • The physics team lead needs to review the submitted code

  • Daily station will

    1. What did I do today

    2. What am I going to do tomorrow

    3. What’s wrong with me

  • Internal testing

    • DT members must test their functionality to ensure it is available
    • The PO needs to perform basic functional tests on the daily output

  • Submit to testing department

    • The PO has the right to decide whether to partially test the release on a daily basis or on several completed tasks to adjust the timing of each sprint (e.g. slow development).
    • The physics team lead reviews the code and builds the test version, and prepares the upgrade script (SQL, configuration, and so on). The PO communicates with the test department what the version covers (task number on Jira) and informs the test version number.

    Output:

    • Testable version
    • The upgrade script
    • Deployment instructions (can be resolved with tests)

  • Return to the

    • If partial test, test cycle and development cycle overlap, DT will first modify defects, and then do new tasks.

  • About DT

    • The DT must change the state of his task on Jira in real time.
    • DT must be written in strict accordance with the code specification of the physics department.
    • DT reports its own questions and problems in real time, PO is responsible for business problems, and the technical problems are taken care of by each physics team leader or discussed with other team members.

  • On sprint failure

    • If the sprint time expires and the task is not completed, the sprint will fail.
    • If the sprint fails, continue to complete the task first, PO estimates the remaining completion time, start the new sprint, and pull the unfinished task into the new sprint.
    • The responsibilities of PO and DT will be discussed in detail at the evaluation meeting.

test

  • The link between development and testing is mainly test and regression, interacting with the Jira tool through standard test release numbers.

Deployment/evaluation

  • The deployment of
    • The testing department agreed to go online and agreed on the online time
    • The physical team lead establishes the live tag version in the code base and prepares the deployment instructions and associated script configurations
    • online
      • Participants: PO, physics team leader, QA
      • The physics team leader is responsible for going online
      • Prepare a rollback solution for online failures
      • After the launch, QA conducted an online test to confirm that there was no problem and the launch was successful
    • The physical department manager needs to maintain a list of online services, including the expected online time, scope, and impact, to facilitate version management and avoid online services confusion and background inconsistency.
  • assessment
    • The PO needs to organize the team to do a sprint review after the launch is successful
      • Physics team lead, QA will be required to attend
      • Analyze what went well and what went wrong in the sprint and summarize the experience
      • If the sprint fails, discuss why it failed.
    • The PO needs to write a sprint review document
      • Record the details of the retrospective meeting.
      • Summarize and evaluate DT team members. Those with poor code quality and large number of defects need to be deducted points, while those with good code quality need to be given extra points. Take workload and performance as the criteria for project incentive issuance.
      • If the sprint failed, analyze the cause. If the sprint failed, explain the external cause.

Daily maintenance

  • Online problem
    • Solved by PO and physics team leader

Fast track

Fast-track requirements that are of high priority, urgent, or high impact.

  • Existing project requirements change or add small requirements
    • PO negotiates with the physics team leader to arrange personnel.
    • The rapid process is as follows:
      • design
      • The development of
      • Iterative testing
      • The deployment of
    • Related products are
      • API interface
      • Jira的Task
      • Defect records
      • Deploy required configuration scripts and on-line packages
  • The new demand is urgent big demand
    • Follow the r&d process normally when there are enough personnel
      • The test adopts partial iteration test.
    • When there are not enough people
      • The r&d leader confirms the priority of requirements
      • Freeze ongoing lower-priority sprints
      • Determine the requirements PO and enter the requirements stage directly.
      • If the number of people is not enough, try not to freeze more sprints in progress, pull people into demand, and delay the sprint of the pulled people.
      • The test adopts partial iteration test.

Daily management

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

Team management

  • Internal Team Architecture

    • The division within the team is managed and optimized by the physics team leader

    • Team members should be divided into three parts:

      • Core staff

        To undertake the development of core business and modules, I also need to undertake some pure technical work (upgrading of technical framework, learning and research of new technology) and help 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.

      • Trainee trainee

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

  • Personnel training

    • Help and

      • One to one

        New employees or interns will be guided one to one by core team members or skilled staff. Mainly in technical guidance, so that the corresponding personnel as soon as possible to get started and integrated.

      • Pair programming

        Broken down development tasks can be done in teams of two, as personnel conditions permit.

        • One core developer + one weak developer
        • One core employee + one intern or new employee

    • Training/Sharing

      • Hold regular communication meetings within the team
        • Conduct training on development specifications and development skills
        • Share good technical solutions, methods and tools within the team and take turns.
        • Share experience on problem solving

    • share

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

    • Stop loss

      • For those who can’t adapt to the team, don’t want to improve themselves and misbehave, even if eliminated.
      • For the lack of potential, subjective initiative is not strong, but it does not affect the completion of the task of personnel, appropriate withdrawal of training focus, lower expectations.

  • The team atmosphere

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

Technology system

  • The optimization and upgrading of technical system is a continuous and ecological work.
    • Technical framework upgrade
    • Realize the optimization of the scheme
    • Study and introduce new technology and new concept
  • The technical system is mainly responsible by the team leader and core personnel

This aspect of work is slow to take effect and low output, but it is the foundation of how far the whole team can go. As a technical person, stopping means being eliminated.

Code base/repository management

  • The team leader is responsible for management, to ensure security, do not leak the configuration of the production environment.

Welcome to my blog