原文链接：https://www.jianshu.com/p/b83a03e59561

Below are some points which I think are interesting or important.

Not support jump inside the page currently
# Table of Contents
1. Meet DevOps
2. Do DevOps
3. Be DevOps

Meet DevOps:

• We are required to deliver more complicated products
• Challenges （多，快，好，省）

Remark: they mention that continuous delivery is very important for a team, you can do release/deployment every few weeks, but you need to have the ability to deliver within a short period of time.

IMG_0479.jpg IMG_0480.jpg IMG_0481.jpg IMG_0482.jpg IMG_0483.jpg

---

Do DevOps

• DevOps is raised to resolve the collaboration problem between development team and operation team.

• These problems come from they (i.e. Dev and Ops) have different focus and responsibility given by their roles which are conflicted (i.e. Devs intent to deliver as much as possible while Ops try their best to keep the environment stable)

• The actual point both Dev and Ops team should focus is the customer value

• Now the DevOps' idea can be applied to many areas to resolve conflicts of interests between different parties.

• DevOps: continuous feedback -> continuous improvement

There are iteration retrospective and version retrospective

• Automate everything can automate.
  It may take time to setup but it will bring a huge boost to efficiency.

• Waterfall has its value, it standardized the process of software development. It does resolve most of the pain points in SD. However, development requires creativity, which will be limited by waterfall style.

• Make team flatten. Since team structure defines software structure. As different groups within a team have their own functionality and the same thing will apply to the software implementation, which will make software complicated.

• Two pizza rule, divide the team into cross-function sub-teams (<10 ppls per sub-team) based on the feature/microservices. This will make every team members will usually influence 5 ppl.

• Team's structure can be horizontal or vertical. (Refer to IMG_0493.jpg)Either one has its value. Horizontal (i.e. Cross function teams) will be more recommended in daily work. If facing a difficult problem and need experts to resolve, vertical will be more suitable.

• User does not always know what they really need indeed. Instead, they need us to guide them to dig the real requirements out. We can follow the rule of lean (精益), deliver the MVP to the user and it will lead the user to think about what they really want and what they can compromise.

IMG_0484.jpg IMG_0485.jpg IMG_0486.jpg IMG_0487.jpg IMG_0489.jpg IMG_0490.jpg IMG_0491.jpg IMG_0492.jpg IMG_0493.jpg IMG_0494.jpg IMG_0495.jpg IMG_0496.jpg

---

Be DevOps

• Be DevOps is more important than do DevOps

• User story

  • The template of user story is like "As XXX, I want XXX, because XXX"

  • Initial version of user story is just detailed enough to kickstart. It will gradually be more detailed as we dive deep into the user story (e.g. as shown in IMG_0497.jpg)

  • User story is testable, if a user story cannot be tested, then there will be no idea about when it can be finished.

Remark: testable means the implementation of requirement corresponds to a use case/scenario.

• Continuous integration （可持续化集成）is very important, some activities like user story refinement will take long time to have effect and will bring down the effectiveness in the short term. But CI will make immediate effect once it is setup.

  • Once CI build failed, developers need to drop down all the tasks in hand and try their best to fix it. Fail status cannot stay overnight. This will reduce the cost of defect fix.
  • Huawei DevCloud team have development iteration (per week) and release iteration (1-3 weeks) as shown in IMG_0499.jpg
  • It is like assembly line, through IPM the tasks are put into the iteration backlog awaiting for development team to pick; once development finish, the user story are passed to release iteration for deployment. Every member are like workers in the assembly line, pick the card, implement it, and pass to the next one.
  • It is recommended that the team have the rhythm to do the release. Break the rhythm will make the team hard to adopt it.

• Started from front line or users, via a funnel like （漏斗形）requirement channel, the requirement are filtered and refined repeatedly to reduce the waste and risk.

• We need to prioritize the requirements. The rule are listed in IMG_0501.jpg

• Must have feedback and retrospective. Make retrospective a closed loop (i.e. must have actions to follow up)

• In retrospective, can try AAR method, the details can be found here

IMG_0497.jpg IMG_0498.jpg IMG_0499.jpg IMG_0500.jpg IMG_0501.jpg IMG_0502.jpg IMG_0503.jpg