Monday, January 14, 2019

Agile Team Evolution Theory (3 stages toward high responsiveness and fast delivery) - Part I

Why I’m writing this?

If you asked a question "What is Agile Development?” to other people, most of them would give you different answers. And the more you ask, the more confused you get, doesn’t it? When you moved from a company or a team to another, did you feel the difference in doing Agile practices? And why is that?
How you understand Agile Development depends on what Agile practices you have experienced, and what Agile practices you experienced depend on the team you have joined. What practices your team choose are the results of a series of decisions, and the decisions the team made depend on what they care about which is called context. In different Agile teams, the context is different so that the priority of problems or goals are different.
However, there are 3 high-level goals that any team wants to achieve for their product in whatever context, which are quality, responsiveness, velocity. Waterfall Development has done a lot of improvement on quality and velocity but nothing to do with responsiveness. That becomes a huge problem for living in a changeable market which requires value-oriented delivery. That also becomes the original motivation for most organizations to adopt Agile Transformation. But in most cases, while the responsiveness is increasing, the quality and velocity are decreasing. On the other hand, an Agile team is able to deliver value with quality to production in hours with low cost, which means all the goals are achievable. So the question becomes how? If we break down the high-level goals and mixed with the context, we can see a journey from Waterfall Development which is normally in a hierarchical organization with heavy department walls and deliver features in years, to Agile Development which is normally in a flat organization with autonomy environment and deliver features in hours.
I’m very lucky to have the opportunities working with more than 20 teams on the different stages of the journey. Some were just starting, some were in the middle, some were very agile. And because my goal was to help them moving forward, I tried a lot of practices among all these teams. I got a lot of feedback from those experiments. One thing came out, the same practice was working on one team might not be working on another. In the beginning, I thought that is what we call “it depends”, isn’t it? But afterwards, I couldn’t stop thinking. Why it depends? What does it depend on? People? Yes, because everything is done by people. But also no, because people are subjective, is there anything objective to let it happen? I kept finding. I tried the same practices in more teams, and finally, I found some patterns. And these patterns are very good to describe the Agile journey.

In this series of articles, I'll describe the journey as 3 stages. Each stage would have only one goal with different approaches for different scenarios. I'll also explain why the goals have to be achieved in this order and why some practices only benefit teams in one stage but not in another. Before jumping into the first stage, let's talk about why the starting point of the Agile transformation is Waterfall Development.

What is Agile Development?

The definition from Wikipedia is "Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).” However, if you ask the question to people, you will get a lot of different answers. A lot of people say Agile is about delivering value to the customer instead of delivering functionalities which might not have value. That’s right, we serve the customer to solve their problems so we can earn the money from them. A lot of people may also say Agile is about delivering software with better quality. That’s also true. We want to deliver qualified software at any time. And there are also some arguments between responsiveness and speed of delivery. Of course, the best to have both of them.
But why we have so many right answers? To understand Agile Development better, we need to look back to the history.

The history of Agile Development

The first time we have the word “Agile" is in 2001, the well-known Manifesto for Agile Software Development was published in Snowbird by 17 developers. And the popular Agile frameworks are also published around that time such as XP and Scrum in the 1990s. At that time, a lot of organizations were building big ideas into big software and systems with Waterfall Development. Since the popularization of the internet, the market gets increase rapidly, more and more small software products succeeded along with more and more big projects failed, even before the first release. Because of that, more and more people started to seek a way to deliver software with more possibility of success which requires delivering software with quality in a small period of time so the company has more chance to get customers early. And Agile Development was born for this purpose, reducing the lead time of feature delivery and not damaging the quality at a reasonable speed. The shorter the feature gets to the customer, the faster feedback comes back, the better understanding the company have of the market, the more chance they could succeed. So from that point, people start to give up Waterfall Development and transfer to Agile Development.

Stage 0 - Waterfall Development



In Waterfall Development, the delivery of software is split into multiple stages. In high level, they are planning, design, developing, testing, and release. Each stage is taken normally months and done by different people from different departments. Long documents are usually used to pass the information among them. To make sure the quality of each stage, teams need to sign off the documents from the previous stage. This process looks perfect if all the teams can finish their job perfectly. However, this is hard and a lot of companies failed or changed. But some companies in some traditional industries such as banks are still alive and working in this way.

Why they still alive and what they did to improve their process?

  • First, they all have a strong business to support them, obviously. 
  • Second, inside the organization, they have very strong process management and standards which define what everyone should do in which stage.
  • Third, very limited technical stacks (normally very old as well) to make sure all the technical persons having the same required knowledge.

If you think about building a building, the building designer needs to give very detailed information, such as where needs how many rebars in which type. This requires the designer to understand the materials used by the building and the workers also need the same knowledge. Even the quality checking person needs to have the same knowledge. In software development, hiring teams having the same knowledge is not possible for most companies. But it’s possible if you have enough money to define all the standards with limited tools and technologies (normally are expensive and commercial) in design, coding, testing, deployment, and collaboration. You can give professional training to all the new employees to make sure they all have the necessary knowledge.

So see? Waterfall development seams working well except the release cycle is too long and all features releasing together. And this leads to some problems:

  1. Very hard to put hotfixes into production - hotfixes are not possible to wait until next release cycle, and it’s also not possible to deploy the new codes of hotfixes immediately from the current codebase because the codes of new features are already there. One way to solve it is to have a clean release brand, put all the hotfixes into that branch and go throw the release process to push it into production. In most cases it's fine, but sometimes, it’s still too slow. So some companies allow the developer to change the production code directly with the approval of their manager in some very urgent cases. And I don’t think anyone like it because of the risk the action brings. Also, there is another problem which is the double effort. Whatever you have done on the release branch, it needs to be merged into the developing branch and go throw all the test cases, which have been done in the release branch. Another solution I’ve seen is that they write all the code in the developing branch, then use something like cherry-pick to pick the change to testing branch and release branch. However, this is a high-cost solution which requires someone to review each pick and never works well because of the complexity of the job itself. Also, I’ve seen a company allows the developers to use their local machine to make the package and ask the release team to deploy it (the package still needs to be signed off by the manager and the testing team) which is similar to a release branch.
  2. A lot of low-value functionalities were delivered into production - because of the long release cycle. If the business failed to push their idea into production at this release, they have to wait for another very long period. Because the business is not getting feedback from the customers, they can only judge the value by their experience which we know it’s normally wrong in a rapidly changing market. So instead of putting the partial idea into the market to have a test, they prefer to push the whole idea at once. And unfortunately, many parts of the software are never used.

To avoid these problems, we have to make the release cycle much shorter. We can either to make the release cycle in a fixed short period or to release feature once it finished. This is the first step to enable value-oriented delivery. We will talk about how to do it in Stage 1.



Someone maybe wants to ask, why not starts the transformation from improving quality or reducing cost?

  • Quality - in the Waterfall process, the responsibility of quality belongs to the testing team. They do a lot of different types of testing on the software multiple times. So normally the quality of software is quite good after all these tests. And even if it was not that good, the company would put the effort into the testing department, not the development department, which would make the flow longer. It’s just an exchange from velocity and responsiveness to the quality. So that's not what we want.
  • Cost -  Many people feel Waterfall Development is expensive. But it is not always true especially when all the resources are well organized. Testers are cheap, devs with just enough coding skills are cheaper than devs with TDD and clean code skills, Architects are shared among teams, release teams are also shared. Plus there are processes to control the budget and manage risks, the cost is normally reasonable. And even if the company wants to reduce the cost, it would try to cut down projects, resources instead of improving the efficiency, which is also not we want.


Reducing the release cycle helps to improve responsiveness but not velocity. Velocity means the values delivered in a period of time with resources (value/cost). Increasing velocity means either to deliver more value with the same cost or the same value with less cost. As I mentioned above, we need a shorter feedback loop to achieve higher value with the same amount of requirement. So before we have better responsiveness, velocity is only able to represent as speed which is functionalities/cost. If the capability of a team was not changed, increasing the workload would lead to impact other hiding factors such as quality and tech debts. And the increasing of tech debts or the decreasing of quality leads to more unplanned time and finally slows down the speed of delivery. So before the team seeks the fast speed, they need to have the responsiveness and be able to deliver qualified software first.

Stage 1 - Start

Goal: Release faster
Key Indicator: Lead Time - From Yeas to Weeks

There are quite a lot of Agile frameworks. The most popular frameworks are Scrum and Kanban. Scrum is to make the delivery period fixed so that force the team to deliver a small batch of requirement. Kanban is to ask the team to focus on one thing at one time so that they can release each feature as early as possible. But because of the complexity of software development, both of them needs to involve a lot of practices. Where should you start?

Planning

A lot of people think the planning is not necessary for Agile Development. The deadline for a requirement is not needed. The team just needs to focus on delivery. They don’t need to tell the business when the job might be finished. And the business needs endless passions and confidence in the delivery team just because they call themselves Agile team. That’s obviously not true.

Why we need to plan before delivery?

Planning is always the first step in doing anything. Everyone is planning all the time. For example, before we have dinner, we always plan what we gonna eat. To make a better plan, we need to have more information such as looking for a restaurant or searching for food from a fridge. You may not plan until the last minute like when you felt hungry or someone invited you. However, in software delivery, those kinds of last-minute plan don’t work. We need to know what the team is going to delivery and when the team can delivery because the company relies on this to plan the limited budget and the business relies on this to plan the events of client interaction. Without a proper plan, the company might encounter a cash flow fracture without warning, the business might lose the change to get customers.

Why planning is hard in Waterfall Development?

Because the planning is so important, we make plans all the time since the first day we develop software. However, in Waterfall Development, most of the plans don’t work. Delaying plan, adding more budget, hiring more developers are so common in software development. And we have the reason that software development is not predictable. So many small unplanned things come out during the development, such as the misunderstanding of the requirement, lack of knowledge of the domain, waiting for a dependency, a bug from a library, learning about technology, etc. Because the development team can’t solve all these problems before planning, they have to leave buffers for uncertainty in the development phase. However, the business and the manager know that and they want to get a plan without buffers. So the communication between the development team and the business will be a negotiation. And in a negotiation, two sides, of course, have different goals. So as we know, the result will be a plan no one satisfied.

How we can make a plan better?

Be clear, it is not possible to get rid of all the problems before planning, a common way is to have an inception stage to remove those problems so that we can have a better plan. However, the number of problems is in direct proportion to the size of the requirement. And in waterfall development, the size normally is huge so the number of problems is also huge. Another thing from software development is complexity. In a large system, codes interact with other codes, functions interact with other functions. It’s not possible to fit all the information into our brain. That’s why a wrong decision normally is found in a very late stage. Design decisions affect each other and it’s hard to realize wrong decisions until we start to write the code. There are tools, principles to reduce those wrong decisions, but there is no silver bullet, so none of them can reduce problems to a reasonable amount.
Sine the number of problems is related to the size of requirement, so the better way to make a plan is to reduce the size of requirement, which leads to deliver less but multiple times. The smaller size of requirement we plan at once, the more amount of problems reduces, the more accurate plan we can get.

The inception

We keep the inception phase but make it shorter (normally from 2 days for a 1 month project to 2 weeks for a 6 months project), change the goal from making a fixed delivery plan for everything to a changeable high-level plan for the project with the detailed delivery plan only for next 1 or 2 iterations. In this case, a professional team are normally able to solve most of the problems during the inception and get ready to start delivery.

Risk management

Like the normal project management, the plan must have a resources plan and a goal with a roadmap which includes the estimated time of each milestone so that we can define risks and make decisions like adding more resources or reducing the scope when there is a risk.
Sometimes, there are uncertain problems which are not possible to make an estimation. In this case, you can say you don’t know when and how to do it, but you have to have a plan to find it out. It can be a spike with a fixed time frame or find help from someone else.

Summary

In Waterfall, because everything is going to release together, so normally everything is mandatory. There is no clear priority among requirements. But now because we want to give a better plan only for the near future, we need to decide what we deliver first. Which means we need a clear prioritized requirement list to help us deliver multiple small versions in desired order instead of a big version. The smaller pieces of requirements, the easier we can prioritize them and deliver them. So how can we make a requirement small as well as deliverable? In agile development, we write the requirement into a Story.

Story based requirement management

In the Waterfall process, business used to put all the requirement of a feature into one document. For example, if they want a bank mobile app, a big feature of account management will be in one document, login will be in another document, money transfers will be in another and so on. The business put all the details into those documents without splitting and prioritization because they will be delivered together. So when a development team starts to ask the business what should deliver first, the answer from business is normally a big feature such as login or account management. However, if we deliver login only to users, there is no value to them. Who wants to use an app which is only able to login? And if you get closer to the business, you will find that some part of a feature is more important than another part. So why we don’t deliver parts of multiple features such as login without signup, displaying existing account information without editing and adding, transferring money only between user’s accounts in the first version, then continuously adding other parts of features in the following versions? That’s what we do in Agile development, to deliver small pieces of value in short periods frequently. So far, we have found out 4 most important elements of a story, the user (Who), the reason the user wants (Why), the behaviour the user wants (What), and the scope (Which part).
In the Waterfall process, the documents of requirements are used by development teams to write code and by testing teams to write test cases. They understand the same documents from different perspectives. And because testing is the next step of development, a lot of misunderstandings, especially for different scenarios and corner cases,  are found in the later stage. To reduce the number of misunderstandings, the developers and the testers need to get agreement on how to check the story is done. So we write down acceptance criteria (AC) on stories.
Also, we noticed the story is just a part of a feature so that it might not be able to be delivered until some other stories were delivered. Or in a complex system, a development team might rely on another team to provide an API or a component. We list these dependencies on a story so that the business and the development team know it can't be planed until all dependencies have been removed. Of course, in an ideal world, we shouldn’t depend on other teams, we should have access to the whole codebase and be able to change all of them on our own. However, that’s not possible in a team who just starts Agile Development.

Elements on a story


  • User - Tells the team who gets the value. In most cases, it is the end user. In some cases, it can be the business. For example, the payment function. It's the business who wants users to pay, but the users normally want everything for free. So the story can be written in "as a service provider, I want to add a 1% surcharge on each cross-bank transfer so that I can sustain my business”. And for users, they want to see the surcharge so that they can make the decision whether they use the service or not. In rare cases, it can be the development team. Such as setting up a pipeline or build automated deployment. Some people also call them tasks instead of stories. Whatever they called, all of them should help the team to deliver faster.
  • Reason - Tells the team why the users need the functionality from the business perspective. This represents the value of the story. This plus the user are the most important part of a story. First, if a function has no value for anyone, then why we put money on it? Second, by clarifying the goal, it gives the team a chance to find a better solution.
  • Behaviour - Tell the team what the users want. This part is negotiable if the delivery team can give a better solution to achieve the same value. In the Waterfall process, normally the lead developers and the architects are responsible to tell the business the duplicated part of requirements or to remove the duplication and simplify the solution by technical design. But in Agile Development, the delivery team talks to the business directly, so they need to find the duplication and the chance of a better design on their own.
  • Scope - A clear boundary of a story. Stories are normally split from a bigger story which is called feature or epic. It’s very hard to distinguish them by only descriptions. Clarifying boundaries among stories and telling what will be done in other stories help the delivery team focus on the current story and avoid to deliver something unnecessary.
  • Acceptance Criteria(AC) - The common understanding among everyone about how to check whether the story is done from the business perspective. There should not be any check related to implementation, such as saved in a database or a method has been called. There are other conditions of done, such as deployed into production or passing all the regression tests which we will talk about them later.
  • Dependencies - A checklist for starting a story. Make sure remove all the dependencies before picking it up.


Common format of a story

<Card Number> <Title>
As a <user>, I want to <do something>, so that I can <get some value>.

Acceptance Criteria:
1. ...
2. ...

Dependencies
1. This has to be done after <Another Card Number>
2. Rely on <other team> to <do something>
3. ...

Out of scope
1. <some functionalities> will be done by <Another Card Number>

How to check a story

In Agile Development, we normally use the acronym “INVEST” to check the quality of a story.

  • Independent - a good story is able to be delivered independently
  • Negotiable - everything is changeable on a story if you have a better replacement
  • Valuable - be clear about why to deliver the story
  • Estimable - small and clear enough to give an approximation to other stories
  • Small - small enough to fit into an iteration and deliver it quickly
  • Testable - a story is able to be tested based on the output. Which means the person who is testing the story should not care about any implementation.

Beyond INVEST, the priority of stories is also very important. The business needs to be clear to the delivery team what they want first.

Example of a story

BMA-010 Transfer between my accounts
As a bank client,
I want to transfer my money between my own accounts,
so that I can put my spare money into my saving account to get more interests.

Acceptance Criteria:
1. The user has more than 1 accounts, the user is allowed to transfer money under the balance between the accounts
2. There is no limitation of the amount as long as the user has enough balance in the source account.
3. The user is not allowed to transfer money if there is not enough balance.
4. The user is not allowed to transfer money in minus or 0

Dependencies
1. This has to be done after #BMA-001 Login and #BMA-002 list the accounts
2. Rely on back-end team to provide the transfer API

Out of scope
1. Money transfer to others will be done by #BMA-011

Comments: BMA = Bank Mobile App

Story wall

In Waterfall Development, each feature in a document is assigned to a developer with a planned start date and end date. The developer updates the percentage every day to track the progress. The manager tracks the progress of all the features to make sure the project is under control. If any progress is slower than expected, the manager will go to the person and ask why. There are two results of this risk management model.

  1. The developers report the real progress and get asked every day. They push all the reasons of delay to other people, such as waiting for dependencies, requirement changes (actually it’s misunderstanding in most cases), bugs introduced by others in the related components, but no one talks about the original plan (because it was made by their manager), the code quality (because they wrote the code), the inefficient tools the company provided (because all the tools come from the higher managers and cost a lot), the time they spent on fixing defects (because they created those defects). Then the manager collects all the problems and solves these problems by communicating with other managers. In a Waterfall project, a manager can have 5 - 10 developers, if each developer reports 3 problems every day, the manager needs to track and solve 15 to 30 problems every day. So solving problems would become the most time-consuming job for them every day, but no essential problem would have been solved. Finally, the project delayed with all these “unexpected” problems and everyone gets rewarded because of the hard work.
  2. The developers report the fake progress. So they don’t get interrupted every day by their manager. But the developers need to make the fake progress not that fake, so they start each feature on time and build the minimum version of each feature and ignore most corner cases. So once the development team submits the application to the testing team, a huge amount of defects would be found. The testing phase would be much longer than expected so that the project has to be delayed.

So none of them gets a good result. We need some better way to track the progress. We have talked about how can we make the plan closer to the reality in Agile Development. The smaller plan with stories. Now I'm going to introduce how the Story Wall can be an effective way to track the state of the plan with visualization.

  1. The real progress - real progress helps us to find the risk ahead and adjust the original plan accordingly. So how can we have real progress? 
    1. Checking the facts instead of reporting - in Waterfall Development, the progress relied on the reports from each developer. In Agile Development, the progress relied on the objective facts. Since we can’t deliver a story without finishing it, the easy way to define the progress is “stories in done” / “stories planned”. For example, you plan to finish 5 stories in 2 weeks, after the first week, you check your progress to be 40% as you finished 2 stories and 1 story in progress. In the old way, it might be 50% which means no risk. But now, you see a small risk based on the number, so you plan to check more frequently in the second week and take actions if it’s necessary. You might realize that there is a gap between the defined progress and real progress. We can reduce the gap by reducing the size of the stories. And we can ignore the effect of the gap once the size of stories is small enough.
    2. Define what is done of a story - the team needs an agreement on what’s the criteria for delivering a story. At the beginning of the journey, it is not necessary to be in production since some organizations have a very heavy release process which is not possible to be replaced or automated immediately. But the story is at least tested in an integration test environment and ready to deploy to further environments.
    3. Define the value stream of a story - if you only want to check the progress, columns backlog -> in progress -> done is enough. This is how Scrum board looks like. However, it’s not enough if you want to find any opportunities to improve the responsiveness. We will talk about it later.
    4. Update the state of stories in time - the ideal situation is to update the Story Wall immediately if any state of stories changed. However, not all the team members do that which I guess because of the cost of the action. So sometimes, having a physical wall or a big touchable electrical wall nearby is helpful.
  2. Identifying hiding problems - problems are also opportunities for improvement. Instead of pushing all the problems outside, being open to the problems inside as well.
    1. Have a clearer view of stories - to be able to find the hiding problems, we need to understand what obstacles to stop a story moving on. And that requires more information, who is working on it for what. So we need to expand “in progress” column into more stages. Here I've listed some high-level stages to production, you can choose a part of them based on your definition of done.
      1. Backlog - a column for the team to get a brief idea of a project
      2. Analysis - a column for BA or UX when a story needs more information to be started for development
      3. Ready for Dev - a column for BA to store the stories in priority, which have enough information and are ready to be picked up
      4. Developing - a column for Dev. Pick a story from Ready for Dev when a Dev is free and put the Dev's name on it.
      5. Dev Done - a column for Dev to store the stories which have finished in coding and ready for test
      6. Testing - a column is for a QA/Tester. Pick a dev-done story into this column when a QA or Tester is free and put the name on it
      7. Ready for Showcase - a column for the team to store the stories which are well tested. Stories in this column are ready to do the demo to the business or the users.
      8. Ready for release - a column for the team to store the stories which have been approved by the business and ready to deploy to production. Notice that this column would not be useful once you got the capability of continuous deployment in stage 2.
      9. In Production (Done) - a column for the team to see what stories are in production
    2. Anti-patterns of a Story Wall - these patterns help the team to find problems and seek opportunities to improve
      1. Cards bouncing between columns - this normally happens between Developing and Testing because of the quality of development. This is an opportunity to shift the responsibility of quality from QA/testers to developers.
      2. Multiple tasks - if you see the same name on more than one story, the person must be holding to more than one stories. There are a lot of reasons. It could be an urgent story/defect coming across,  the developer stops the current work and pick up the urgent one, which means the previous story is not in progress. In this case, the padding story is better to be pushed back and get chance to others to pick. Another reason could be that a story in progress is blocked by some obstacles which are not possible to remove shortly so the developer or QA picks another story. In this case, they could put a warning post on the story and check it regularly.
      3. Unassigned Story in Analysis, Developing or Testing columns - this might happen when a person takes leaves. In this case, it's better to push the story back and wait for others to pick it up
      4. Has not moved for a long time - it’s very easy to find out a story in one column for days if you use the Story Wall. Find out why and try to avoid this situation to happen again.
      5. Too many stories in Ready for Dev or Dev done - this is a change to find the bottleneck of the team. It’s the opportunity to try cross-role team which means anyone can be any role when the team needs.
  3. Visualization - we all want to make our team better. And to do that, the team needs to get a better understanding of themselves first. A Story Wall nearby helps that by allowing them to see the state of themselves anytime they want.

Collaboration based on stories

Requirement document helps the communication between different teams be efficient by setting up the context in Waterfall Development. Any updates of a feature would be recorded into the document and spread to all the related people. The same thing needs to happen on stories.
We can easily use stories to replace the documents to set up the context to make the conversations more efficiently. Any outcome or the important information can also be attached to a story to avoid the same conversation happened again. We can record them as comments of a story if you have an electrical wall, or record them on a post and stick it on the story if you only have a physical wall. With a Story Wall, the information will be spread automatically. And in case someone isn’t noticed, the information can also be mentioned in a Standup (a common practice in Agile Development, I’ll explain later).

The lifecycle of a story

Once a story is delivered, the information on it has been translated into the code. If we kept updating a story while writing other code, we would have the duplicated information with double cost. To avoid this, discard a story when it is done and create new stories for new requirement based on the working software, which is different from the Waterfall Development, updating the existing document for new changes which are based on the document.
So the lifecycle of a story starts from the backlog, goes through each stage of the value stream, ends at done.

Summary

Using stories instead of documents to manage the requirements increases the efficiency of collaboration between different roles. It gets easier to be priorities, easier to be planned, easier to be tracked. It changes the way of describing the requirement from function-oriented to value-oriented. It’s a core stone of Agile Development, which defines what should be delivered.


Delivery

As mentioned above, we need to deliver in small batches with short periods. But it is not possible if we keep all the process of Waterfall Development. Think about how could it be possible to finish a story quickly if it needs a design document before coding and test cases before testing, if all the documents need to be reviewed by leaders, if each move of a story needs to be submitted in a system and signed off by a leader from another department which might take days. It is not so we need a light process instead. However, not all the organizations are able to apply the lightest process at the beginning. So based on the situation of an organization, there are 3 chooses for a good start point.

  1. Build a new feature team and apply Scrum if you are in an open environment which allows you to make mistakes and do some experiments, and the product you are building doesn’t have complicated dependencies which require a lot of integration testing.
  2. Optimize your team to remove the wall between departments and apply Kanban if you are in an open environment but your product has complicated dependencies such as hardware involved development or the different skill set required development.
  3. Add QA/testers into your development team and apply Small Waterfall if your organization is very conservative which doesn’t like a lot of changes at once.


Scrum

Scrum is a well-defined framework of Agile Development. It has one delivery team with a PO and a Scrum Master to deliver in the fixed periods which are called sprints and each sprint has 4 types of meetings (Planning, Standup, Review, Retrospective) with a business showcase.

Practices

  • Sprint - it is a fixed time frame which means it is not allowed to be delayed. It forces the team to adjust the scope instead of the time.
  • Showcase - demo to the PO what value has been delivered for each sprint, which helps the team to get faster feedback from the business and build trust between the business and the delivery team to enable collaboration instead of negotiation.
  • Planning - product backlog is made in product planning which is normally done before the first sprint. Sprint planning happens at the beginning of each sprint which creates a sprint backlog and defines a sprint goal.
  • Standup - is also called as daily scrum. It happens every day to synchronize the progress and obstacles so that the team is able to find the risk as early as possible. A Scrum Master needs to make sure the team doesn’t treat it as a report meeting, instead to spread the responsibility of success to the whole team instead of the project manager in the old way. Each team member is responsible to find the risk and help others.
  • Review - it happens at the end of a sprint to check the key indicators and how they have done in the sprint. All the information should be open to the team includes the result, the way to calculate, and the way to collect data.
  • Retrospective - look back to the sprint and find anything they did well or could be improved, take actions or experiments in the next sprint. Again, the Scrum Master should make sure that everyone in the team has the responsibility to improve the team, not just the manager which is like the old way.
  • Feature team - a team is able to do all the necessary things to push to production. Dev role to write the code, QA/Tester role to test the software, BA role to get all the business information the team needs, Ops role to deploy to all environments. Roles are more about the capability, so it is not necessary to be one role one person, such as a Dev can also be a part-time Ops.


Definition of Done of a story

  • Based on the situation of the organization and make it as close to production as possible.


Key Indicator
From a fixed scope to a fixed period, the habit needs to be changed. In fixed scope, each feature used to get planned in a start date and an end date. The team track both dates because they believe if a feature gets started on time, it has a higher possibility to be finished on time, which is not true because of the cost of multiple tasks. And the real problem is that the plan has too much requirement which is more than the capability of the team. To avoid the delay of delivery, the team needs to make the plan match the capability. That’s why we need to track Finish Rate of each sprint.

  • Finish Rate - the number of stories finished/the number of stories planned. Fixed period means 100% finish rate


Kanban

Sometimes, the software delivery team needs to integrate with a hardware team or other delivery team which has totally different technical stacks, and the integration part takes a lot of time so the lead time of a feature will be very long and not estimable. In this case, we can adopt framework Kanban which is based on Lean Thinking. The basic idea is to reduce the lead time by finding out and visualizing the current value stream then adding a limitation of WIP to each stage to let the team focus on delivering one value instead of many values together.

Practices

  • Value stream - find out the current value stream which from the backlog to production includes all the integration stages across all the teams and departments.
  • Visualization - use the value stream to make a Story Wall
  • Pulling System - add a limitation of WIP to each stage. Allow a story to move to the next stage only when it is not full. If it is full, the person needs to try to help to move the stories in the next stage forward first. If this happens a lot, then you need to think that there might be a bottleneck and find a way to increase the capability for the next stage. 
  • Limited WIP - continuously reduce the limitation of WIP for each stage to find more waste in the delivery and give the team changes to improve
  • One Piece Flow - one feature at a time, which means not picking another feature until the feature has successfully handed over to the next stage. There shouldn’t be a lot of waiting time to move values forward, which requires that recourses for each stage are well balanced and the handing over are smooth.


Definition of Done of a story

  • Deployed into production


Key Indicator

  • WIP - The lower WIP is, the smaller batch is. So how low the WIP is, how successful the team is.


Small Waterfall

To apply the frameworks above from Waterfall Development, both of them need to change to organization structure in either way of merging departments and splitting into feature teams to serve the existing products or creating a new department with maybe a new product to do the experiment. However, in some organizations, they are not able to do these kinds of change. So is it possible to do the transformation in even smaller steps? The answer is yes but with some conditions:

  • Accept longer time of transformation, it can be several years. I have seen some companies were still in Small Waterfall after 2 years doing the transformation and it might take even longer to move to the next stage.
  • Accept much higher cost during the transformation. Because of the department wall, the collaboration is based on the responsibilities and rules instead of trust, so there is a lot of time to be spent on making the new collaborating process and rules and a lot of waste on the duplicated work in the different departments. For example, when the development team started to take the responsibility of quality, they would do a lot of tests which would also be done in the testing team.
  • More people for all the departments. Because the Waterfall process has remained, to reduce the release period, all the departments need to do more work than before such as regression tests, deployment. They also need to learn a lot of new knowledge such as the new way to plan, the new way to write code, the new way to test, etc. All these work needs more people especially in the beginning of the transformation before they become automatic.


To apply Small Waterfall, we need to keep all the existing process from the requirement handing over to sign off of testing and deployment. The first change is to change the planning from a big batch to a small batch as mentioned above. We fit stories into fixed time frames. Running the time frames of design, development, testing parallelly. We also need to deal with the dependencies because of the different priority of different teams.

  • Dependencies - in a big batch, the delivering order of requirement is not that important because they will be released after a very long time and all together. But in a small batch, the outside dependencies become a very big problem. For example, your business owner wanted your team to deliver a feature in the next iteration. But you found that it needs API support from other teams after you finished the design. You submitted a requirement to that team and they told you it needs at least 2 iterations to finish (assume that they had treated it as a high priority already which does not normally happen). Then you had to tell your business about the situation and change your plan. Because of this, a lot of high priority features are not able to deliver as expected. To solve this problem, we need to find out those dependencies early such as in the product planning. We need senior developers and architect to be involved in the early planning stage. Identify the dependencies as many as they can by doing a brief design which requires the knowledge of both the system and business. They need to know what data the team owns and where to get the data they don’t have. After you make a list of stories for those dependencies, you invite those teams with their business owners to make a big plan together. The big planning meeting can be a regular meeting which can happen every 3-6 months. During the meeting, all the teams need to get agreements on the deadline of the requirements and plan their stories before the deadline. It also needs an owner to update the delivering state of those stories which helps to identify the risk as early as possible.


The next change is in the development team.

  • To reduce the unpredictability of the testing and following steps, the development team needs to include a testing phase for each story to increase the quality of the outcome of development, which normally we call it “dev test”. It needs to be done by someone else such as a full-time tester or another developer. However, testing by another developer is normally not ideal because all the developers have their own mission and they wouldn’t treat the test as a high priority. So the testing might not be sufficient because it would happen at the end of an iteration. The better solution is to have more than one full-time testers to test each story after the coding finished so the developers could get faster feedback and the stories would have enough tests. There is some waiting time for devs and testers at the beginning and the end of an iteration. But this is the additional cost we have to pay, otherwise, we would have more waiting time after development stage, more unpredictable unplanned time for all the teams, more possibilities for the delay of releases which might affect several products. Remember, the fixed release cycle is the goal for this stage. 
  • The dev test requires a dev environment to run the software. Because it’s in the developing stage, not all the dependencies are available, so they need to use stub servers to simulate the behaviours of those unavailable dependencies.
  • The dev test needs to be done during the iteration since it’s part of the development stage. The planning needs to include the time of dev test for each story.


At the same time, the deployment team needs to start learning automation.

  • Build a deployment pipeline for the development team to allow them to deploy the code into dev environment by themselves, which helps them to do dev test easily.
  • Build other pipelines for themselves to deploy the code to other environments easily so that they can handle the release more frequently.
  • Automate the database changes by using the database version control.



Practices

  • Iterations - it is a fixed time frame which means it is not allowed to be delayed. It forces the team to adjust the scope instead of the time. The testing iteration follows the development iteration. All the related deployment teams should have the same time frame.
  • Collaboration - understand the impact of your job brings. Help other people finish their work more easily by finishing your job in high quality. Beware of the unreadable codes could slow down other’s coding speed, the defects could increase the risk of delivery, the delay of a dependent story could delay a group of features delivered by other teams. To avoid affecting others to get the job done on time, everyone needs to keep communicating and updating the state to the related person for the related job, and solving the risk as early as possible.
  • Cross-Team Planning - teams working on different components need to plan together regularly to align the deadline of the dependent stories. Then reduce the number of dependent stories by expanding the ability of teams, refactoring existing components, and building new products with better design.
  • Dev Test - induce a testing step in the development stage for each story. The stories are not allowed to submit to the next stage without passing the dev test.
  • Auto Deployment - the ops team needs to make deployments automatically so that they can support the increase of deployments.
  • Resources Support - make sure each team gets enough support in training, learning, and people. Reduce the scope instead of pushing the deadline to the team. Accept the real capability and help the team increase it continuously.
  • Release Train - the fixed date to release a group of products and components so that all the dependent stories can be deployed together. The length of time between two releases should be the same as the iteration so that the stories of each iteration can be released to production.


Definition of Done of a story

  • For design teams, done means dependencies found, data designed, mockup provided, INVEST matched
  • For development teams, done means the dev test finished
  • For testing teams, done means passing all the test cases
  • For other related teams, their work isn’t tracked in a story level, so no meaning for them
However, the development team still needs to track which story is in which environment by putting stories into versions and track versions as waterfall process.


Key Indicator
Just like Scrum, use finish rate to make sure the plan matches the real capabilities of teams so that teams can achieve delivering small batches instead of a big batch.

  • Finish Rate - the number of stories finished/the number of stories planned. Fixed period means 100% finish rate

Since the different stages include different teams, we can track the finish rate separately for each team.

Defects

Defects are found in 2 ways, before delivery and after delivery. As the team just started in the new delivery process, they can keep the way they have for the defects found after delivery. For the defects found before the delivery, which means at least one of the AC of a story hasn’t fulfilled, developers could pull the story back and finish it as soon as possible.
If a “defect” is not related to any AC of stories, it’s either a missing story or a missing scenario of a story. In this case, if you can deliver without the new scenario, create a new story into backlog and plan it for later sprints/iterations. If you have to deliver it in this sprint/iteration, change the existing story to add the new scenario, then recheck your workload and remove one or more stories in low priority if it is necessary.

Tools


  • The company provides the options of tools and let the team make the choice.


Summary

Start the Agile journey by changing a big batch to small batches, focusing on releasing early and reducing the lead time of requirement. Teams can get better planning with a better understanding of their capabilities by changing the working process. However, the software delivery is not just about the management, it also needs technical capabilities to support the team to make better quality so they can reduce more unplanned time and deliver faster.


Friday, February 5, 2016

三件事开启你的敏捷转型之旅

开启敏捷之旅的三个实践:持续集成(Continuous Integration, 以下简称CI),自动化测试,每日Code Review



为什么是这三件事?

抗拒变化,效果不佳,扎根不实,缺乏学习氛围等因素,往往是传统团队在敏捷转型中失败的重要的原因。
比如有些团队采用Scrum,引入迭代,计划会议,站会,回顾等实践,尝试两周上一次线,结果上线后产品质量很差,引来各方投诉,同时下个迭代有一半的时间在修bug,严重影响了产品进度,开发开始叫没时间,产品经理吹促着快点完成功能,于是,各种实践开始延期或取消,项目经理决定延长迭代周期,慢慢地团队回到了几个月上一次线的老路。
还有些团队,站会变成团队成员的汇报会,引入了BA却缺乏与其他成员的沟通,团队成员都不愿意暴露弱点,抗拒新知识等。这些团队的管理者,高估了成员走出舒适区和适应变化的能力,很容易导致团队转型的失败。

团队要能成功转型敏捷,必须要一步一步走,一步一个脚印,让团队每个人都能看到进步,感受到好处,并且能让这种获得的进步能在团队中长期保存,形成文化,让新来的人也能继承这些做事方式。

图:团队能成功变革的三要素


我们来看这三个实践是如何相互配合,做到以小的变化,得到大的效果,最终在团队中形成文化的。
  • CI可以在任何形式的团队中引入,帮助团队成员减少手工重复劳动,提高效率,比如打包和部署,回归测试等。同时CI不需要改变团队现有开发流程,对工作习惯的改变较小,且易于理解,容易被团队接受。
  • 自动化测试配合CI一起实施,能尽早的发现问题,尽早的修复问题,有效的提升产品质量。高质量不仅能帮助产品成功,还能减少团队的计划外工作,给团队带来更好的预估。
  • 每日Code Review,通过增加团队面对面交流,使知识得以传播,在团队中建立文化。虽然我们认为结对编程是更好的实践,可以更快速的传播知识,但对于刚刚开始敏捷转型的团队来说,实践难度太大,团队很难接受这种思想,也很难放弃现有习惯去工作,所以每日Code Review就是一种较好的折中。每天的相互反馈,可以帮团队尽早发现和修复问题,使每个人都能向相同的方向前进,同时可以有效传播好的工程实践文化,使新人快速了解团队的做事方式,帮助新人融入团队。

综上所诉,团队能以最小的变化引入持续集成,减少浪费,加上自动化测试使之更有效,再以每日Code Review在团队中建立文化,从而为成功敏捷转型打下基础。


应该怎么做?

CI

CI是一种软件开发实践。在持续集成中,团队成员频繁集成他们的工作成果,一般每人每天至少集成一次。每次集成会经过自动构建的验证,以尽快发现和修复集成错误。

在实施CI的过程中,要有独立的CI服务器,并在服务器上自动化以下事项:
  • 持续检查:静态代码扫描,关注代码质量
  • 持续打包:自动编译和打包,为部署做准备
  • 持续部署:能使同一个包,对各环境做自动或一键部署
  • 持续验证:自动运行所有测试脚本,验证产品功能
  • 持续基础设施:自动创建所需要的环境,并且将代码纳入源代码版本管理
  • 持续报告:建立CI状态墙,所有人实时关注;展示和发送每次运行的结果报告给相关人员
每完成一项自动化工作,都意味着团度效率的提升。

另外,所有人都要参与:
  • 开发人员
    • 提升提交代码的频率,每天至少一次
    • 编写单元测试和集成测试
    • 在代码提交前通过所有的本地测试
    • 第一时间修复CI上失败的Build
  • 测试人员
    • 尽早参与到整个产品的交付流程中,站在用户角度理解需求
    • 自己或和开发一起编写自动化验收测试
  • 运维人员
    • 搭建CI服务器和CI状态墙,优化CI速度和稳定性
    • 帮助产品团队建立CI流程
    • 做好环境和数据库的版本管理
  • 管理人员
    • 做好各种支持,如激励员工,提供资金购买服务器,大电视机等

工具:Go CD, Jenkins, Bamboo, travis-ci, TeamCity ...

自动化测试

根据测试金字塔原则,为不同的测试目的写不同的自动化测试脚本。

图:测试金字塔


单元测试,最容易编写,同时可以实现高覆盖:
推荐的单元测试编写方法是TDD。通过TDD帮助我们理清需求,想清设计,从而编写更高质量的代码。
测试因该关注需求,每个测试都应该通过“我要实现什么业务”的方式思考。我见过很多人在讨论单元测试的时候,都纠结于是给所有公共方法写单元测试,还是只给部分写,是覆盖所有分支,还是覆盖重要分支。而事实上这种讨论没有什么意义,测试要保障的是价值的实现,只有关注需求而不是关注代码,才能写出有价值的测试。
单元测试应该隔离依赖,可以反复且快速运行,并且只有一个失败的原因,一旦失败能快速定位问题,帮助开发人员快速修复。

中间层集成测试,编写难度适中,实现组件级重要场景覆盖:
在产品开发中,无论是传统的横向根据技术分层,还是现在的纵向根据业务分块,都免不了出现大量组件,以及组件之间的互相依赖。比如持久层要访问数据库,资源组件要访问网络等等。
集成测试就是把一个或多个组件,当成一个整体来进行独立的功能测试。这种测试通常不包含前端UI界面,这样可以避免处理UI所带来的复杂性。
集成测试有时需要通过一些手段,自建依赖,比如自己创建像H2这样的内存数据库,或者用mountebank之类的工具自建API服务,以便能在独立的环境中重复运行。

上层功能测试,最难编写,重点覆盖完整的业务流程:
功能测试也就是应用测试,是对产品整体的验证。功能测试只关心用户能接触到的内容,模拟用户使用产品,验证产品是否能解决用户问题,符合场景预期等。
一般功能测试会通过Selenium等自动化框架,来模拟实际用户对UI界面的操作,再通过验证界面上返回的信息来验证功能。
功能测试往往会有比较长的操作步骤,因此运行一个测试也会有比较长的耗时。同时功能测试会涉及多个页面和组件,所以运行失败后的问题定位往往会比较困难。这就要求一旦找到问题后,必须要补单元测试来对问题进行覆盖。

总之,根据测试金字塔,为不同目的编写不同单元测试。对于传统团队或遗留系统,可以从单元测试和功能测试入手,让开发写单元测试,测试人员写功能测试,在一段时间之后再引入集成测试。

每日Code Review

在团队转型初期,我见过一些团队会在Code Review中关注注释,代码执行细节,盲目听从一些老员工的建议。这样做不仅不能帮助团队成员得到有效的反馈,提高产品质量,也无法促进知识传播,建立团队文化。

因此,要让这个实践真正有效,我们要更多关注以下左项:
  1. 业务需求理解 > 代码执行细节
  2. 代码业务逻辑 > 代码风格规范
  3. 是否测试覆盖 > 人为逻辑判断
  4. 知识传递 > 听从权威
同时,关注别人代码中的亮点,指出来。

团队可以在每天下班前或站会后,半小时左右,团队中每个人通过介绍实现的需求、代码设计、读代码实现,使团队其他成员理解自己的代码,让大家提出反馈。

总结

敏捷转型没有捷径,通过踏踏实实提高产品质量,以较小的改变带来较大的收益,建立起持续反馈和改进的文化,这样才能慢慢提升团队适应变化的能力,使团队习惯变化、拥抱变化,真正开启通向敏捷的大门。




Tuesday, February 2, 2016

Code Review的正确姿态

正确的做Code Review可以帮我们解决两个问题:
  1. 减少Bug
  2. 使修改别人的代码变得容易


那么怎么样才是正确Code Review的姿态呢?


我们先从bug说起


bug的形态可以分为以下几类:
  • 逻辑不全 - 如缺少输入检查、缺少逻辑判断、少存一个字段等
  • 逻辑错误 - 如字段错位、与或搞错了等
  • 业务理解偏差 - 这个容易理解,就不解释了
  • 集成错误 - 如组件与组件之间接口不匹配等

要让别人鉴别出这些问题,首要任务就是让别人通过理解业务需求来理解你在做什么,对应的需求有没有相应测试覆盖,有没有被遗忘的角落或理解上的偏差。其次再将需求对应到功能代码上,讨论你实现的合理性,是否有更好的实现,是否有已存在的技术,可以简化现在的设计等。
因此这里我们得到了三个关注点:
  • 业务需求的理解
  • 相应的测试覆盖
  • 可读性高的代码

然后我们说说代码共享


容易被修改的代码通常具有以下几个特征:
  • 意图明显 - 让阅读者很容易理解作者为什么要写它
  • 容易阅读 - 有良好的层次,业务逻辑清晰
  • 反应当前业务 - 可以通过阅读代码了解系统现状,从而很容易找到修改点
所以这里要关注的依然是:可读性高的代码,也就是说同样的功能,能越快读懂的代码越好。关于更可读的代码,请参考《Clean Code》。

Code Review在这里能起到避免误读的问题,所以我们还是应该像上面提到的一样,先理解需求,随后看一下代码和需求是否一致。

另外,我们经常看到一些团队,在做Code Review的时候会有一些低价值的讨论,比如:
  • 用if还是switch
  • 注释应该怎么写
  • 大括号前要不要换行
  • 代码在什么情况下会被执行
  • 把Tech Lead的话当圣旨
虽然以上讨论能形成一些代码规范,但这些规范只能非常有限的帮助减少bug和代码共享。

因此,我们从要解决的问题中,找到了Code Review的正确姿态,总结如下:
  1. 业务需求理解 > 代码执行细节
  2. 代码业务逻辑 > 代码风格规范
  3. 是否测试覆盖 > 人为逻辑判断
  4. 知识传递 > 听从权威
同时,关注别人代码中的亮点,指出来。

那么下一个问题,Code Review的频率应该是怎么样的?


通常,大家都希望反馈的周期越短越好,只有得到足够快速的反馈,我们才能尽早的避免引入问题,保持始终往正确的方向前进。
所以基于期望得到最快速的反馈,最好的实践是结对编程。
但是结对编程对于刚刚开始敏捷转型的团队来说,实践难度太大,团队很难接受这种思想,也很难放弃现有习惯去工作。所以比较折中的方式就是进行每日Code Review,也就是团队每天找一个时间,大约半小时左右,在一起互相Review代码。这个时间可以在下班前,也可以在每日站会后,由团队根据自身情况而定。


总结


总之,通过每天在Code Review中关注业务、自动化测试和代码可读性,每个成员分享和传递知识,从而增进团队成员之间的相互了解,共同实现更高质量的产品,进而帮助团队在走向敏捷的过程中迈出重要的一步。 

Monday, February 1, 2016

自动化测试简介

为什么要做自动化测试?

自动化测试可以做到人类无法做到的快速验证和反馈,从而提高软件质量和降低修复成本。
想象一下如果不写脚本去做压力测试,会是什么情形?

测试总类繁多,包括但不限于:

通过几十年的技术积累,上面所诉的90%都有相应的技术做自动化支持。由此可见业界对于测试自动化的推崇。


根据测试金字塔原理:


图:测试金字塔

金字塔越下层,说明运行速度越快,编写成本越低,应该在所有测试中占比最多。
金字塔越上层,说明运行速度越慢,编写成本越高,应该在所有测试中占比最少。

由此引出保障软件产品质量的三个基本测试:单元测试、集成测试和功能测试。

底层单元测试:

我们推荐的单元测试编写方法是TDD。通过TDD帮助我们理清需求,想清设计,从而编写更高质量的代码。你得到高覆盖率的单元测试仅仅是额外的奖励。
Java中我们用到的测试框架通常是JunitMockito
Scala我们会用Specs2

测试的编写应该从需求出发,每个测试都表达一个功能点,而不是从代码的角度去讨论单元测试,这点同时应该在方法名中体现。比如在猜数字的练习中,我们的测试描述应该写成 "should_tell_how_much_numbers_are_matched_when_I_guess",而不是"test_method_guess"。

另外为什么先写测试?
试着回答两个问题:先有需求还是先有代码?如何验证代码的正确性?
答案显而易见:先有需求,“实现了的需求”是检验代码正确性的唯一标准。
因此,我们应该根据需求编写相应的测试,并通过所有测试,以此来证明我们写的代码是可靠的。

具体写法,请参考示例

中间层集成测试:

在Restful应用中,集成测试通常是测试服务API。这种测试可以对某个服务进行端到端的测试,同时又避免了处理UI的复杂性。
API的测试,基于Java最常用的就是RestAssured,再加上Spring Test内存数据库等技术,使API测试能独立、可重复的运行。


上层功能测试:

功能测试也就是应用测试,是对产品整体的验证。功能测试只关心用户能接触到的内容,模拟用户使用产品,验证产品是否能解决用户问题,符合场景预期等。
最常见的就是UI测试,通过Selenium来模拟实际页面操作来验证产品功能。



所有测试都应遵照以下流程:

  1. 准备测试环境和被测对象
  2. 给定输入
  3. 验证输出

所有测试都应该符合以下标准:

  • 独立性:测试应能够清楚的表明一个功能或场景
  • 可重复性:测试应可重复运行,且都以同样的形式成功或失败
  • 自我验证:测试要无歧义的表达成功或失败
  • 完整性:测试应该不需要人为参与做类似于调整数据的操作

最后,要学会如何写自动化测试,重点是多练。可以从基础的题目开始练起,用自己擅长的语言。重点训练自己的测试思维,即我们是在验证用户价值,这样才能使测试真正有效。


Resources:
Kata练习题:http://codingdojo.org/

Books:
程序员的职业素养:http://book.douban.com/subject/11614538/

Wednesday, September 2, 2015

为什么应该在团队内完成整个开发生命周期

经常听到有人说,数据库很重要,所以应该有一个经验丰富的团队来把关。架构很重要,所以应该由一些架构师来统筹。

先不说这些高级团队到底能做到多大改善。但这种组织架构会带来致命的问题——组织的开发速度上限受限于这些高级团队,甚至是效率最低的那个。




如图,首先问题是,这些团队会在整个开发流程中成为瓶颈,我们无法通过横向扩展团队来提升组织的开发速度。这对软件产生价值的组织来说是致命的。

第二个问题是,开发中的沟通成本大量增加,团队间的沟通成本会远远大于团队内的沟通成本。如果功能开发团队依赖于大量其他团队,就会使整个开发成本变高,价值流速度降低。

第三个问题是,核心团队成员需要长时间培养,人员流动往往会造成致命的打击,就好像组织中有一根软肋,如果竞争花钱把某一个核心团队成员全部挖走,该组织可能会立刻消失。

由此可见,为了保持某些看起来很重要的东西(比如数据库,架构)运行良好,就让专业团队去做的想法有很多致命问题。

那怎么样才是好的实践呢?



特性团队 + 微服务

团队自己负责所有事务,从一开始就避免大型数据库和大型架构的设计,每个功能根据自己的需求,完成相应的服务设计、开发、测试、部署和上线。如果需要修改其他服务,也由该团队自己完成。通过自动化测试去保障质量,而不是由某个高级团队。

如果遇到遗留系统怎么办?

因为遗留系统可能没有足够的自动化测试去保障质量,所以首选的一定不是去修改它。把遗留系统API化,给遗留系统补测试,把一部分功能拆出来另外实现,都是我们常用的方法。
当然,我们还是避免不了去修改它,这种时候,修改还是由团队自己来完成,因为没有人能代替你去理解业务,没有人能代替你提供实现方案。只是团队需要自己足够谨慎,通过增加对遗留系统的了解以及找曾经在系统上工作过的人沟通,从而具备修改它的能力。



总之,指望把当前团队解决不了的问题扔给另一个团队去解决是不靠谱的,我们应该提升团队能力,使该团队具备解决问题的能力,而不是把希望寄托在别的团队上。

Thursday, July 16, 2015

Never register a domain on oray.com

Oray has a terrible service.

First, they require me to upload a photo within a personal ID by email and mention that the DNS would be affected if I don't upload the photo.

Second, I tried to transfer my domain out but there is on way to do that by myself. They don't provide the service in their web site. And they still require my to send a mail which include a hard copy of my personal ID and an additional paper form to their office. And they won't pay the fee of the mail.

Third, I made a phone call to their service centre. They told me the only way to transfer my domain out is to fill the additional paper form and send it to them with a hard copy of my ID. They had nothing to do.

Last thing is they never mentioned these above until I tried to transfer my domain out. Which means I was informed 5 years later after my first payment for my domain.

So at last, I try to get my auth-code through ICANN. The address of complaint page is below:

Hope this could help anyone who has the similar trouble with me.

Be away from these terrible registrars.


Wednesday, May 20, 2015

Surprise by the new html5 and css3 technologies

Recently I joined a course about how to do a UI design.

Here's the showcase.
https://heaton.github.io/week3/ (not available for IE and old Browsers)

These pages are all made by pure css 3 and html 5 with a little jQuery code for click events and touch events.