Enable Agile tools to play an effective role in agile development

Agile Software Development is no longer a term, but understanding is always biased. The first article in the Agile Manifesto, "individuals and interactions over processes and tools", was misread as "having communication, everything is resolved", and therefore spending a lot of effort to reorganize teamwork, but to belittle the tools (technology). In fact, the meaning of the Declaration is only to emphasize personal and communication more important.

In fact, since it is software development, it is unavoidable to face the choice of tools, and many excellent software practice away from the powerful tools to support all play does not turn. In today's software development world, tools (here is talking about software tools) are endless, so how to choose the right tool?

This article will be based on my more than 10 years of enterprise software development experience to give a little advice, together with you to explore the agile and tools (especially in the enterprise implementation of the tool) this topic.

In order to avoid unnecessary trouble, as far as possible to use open source software as an introduction, but this does not mean that I exclude commercial software, on the contrary, in many cases, only commercial software to provide the functionality you need (of course, most of the time open source software will catch up quickly).

Background: Application life cycle Management

The term "Application Lifecycle Management" (Application Lifecycle Management, ALM) is generally mentioned in the Software development tool, saying the truth, a bit rotten, who all want to put themselves up, who have their own set of statements, Figure 1 is the overall view of ALM in my mind throughout the entire enterprise development project.

The various subsystems in ALM are listed in Figure 1, and the names of the relative tools that I have studied slightly, let's go through the process in a simple way.

Figure 1 Application life cycle management and its tools in development projects

Product development starts with a certain need, there are several levels of demand, from product requirements to project requirements, resulting in a user story, and then the team breaks down the task. Team developers use the IDE (such as Eclipse) to complete the code, and after the unit tests are completed, they are then pushed to the code base (GIT), which is related to software configuration management (software configuration MANAGEMENT,SCM).

The build system will get the latest code from the code base, compile, package, function test and system test, can set up in the quality system to display some relevant information, if all smooth, even directly uploaded to the online system update on the line. In addition, there will be a defect management system in both development and operation.

Bugzilla Everyone should be very familiar with, with redmine less people, the domestic also has more and more companies in the use of Leangoo, very useful for an agile collaboration software, online efficient kanban collaboration. Nexus is a Java software package management tool that needs to be used in conjunction with MAVEN, a quality control tool for a Java project that integrates such things as unit testing, coverage, static quality checks, and so on. Why does the Redmine under task management have a red fork? We'll explain later.

Confined to space, this article will only talk about a subset of these tools. As a reference, you can read the new book "Agile ALM" of Manning Publishing house, which explores the topics of SCM, unit testing, functional testing and so on.

Some tools are required in agile

If you say that agile has been implemented for half a year, but the continuous integration (continuous INTEGRATION,CI) server has not yet been built, I really don't know what you are agile about. Whatever agile you believe in, the automation of all aspects of product development (Automation) and continuous integration are essential. To understand continuous integration, you can look at Martin Fowler's article, a white paper-level classic, with a Chinese translation version.

Use CI will be used to the CI server, there are many options, of which Jenkins is now the most popular one, but also easy to set up. It is inherited from Hudson (since May 2011 Oracle has decided to donate Hudson to the Eclipse organization, the relationship between the two and the future direction of development may also lead to more variables).

In the Jenkins build server, you can define tasks (called Jobs in Jenkins) to complete a number of build steps (such as checkout Code, compilation, various types of tests, packaging, etc.), which are supported by a rich set of plug-in (plugin) resources to integrate the various elements of product software development, It automates everything you need.

Figure 2 Jenkins Project own Jenkins build server

On the first page of the Jenkins build server, each task also has a weather icon indicating its status, which is very intuitive, such as "the Sun" which means everything is normal (at least from the build result). It is a barometer of product development, project status is normal at a glance. Whether you are not aware of Jenkins or want to improve, I highly recommend reading John Ferguson Smart's Jenkins Open Source Book: Jenkins:the Definitive Guide.

For agile, there is no "CI server to or do not" said, it is necessary, must be well implemented. Based on continuous integration, it is continuous delivery (continuous Delivery), which is also a new hotspot for agility, with many new elements (such as automated acceptance testing, continuous deployment, etc.) added.

Don't let the tool take the nose.

Tools are important, but will there be some misunderstanding? Of course, let's take a look at an example I often encounter.

The introduction of agile implementation has always been a reference to the use of the Whiteboard (whiteboard), first to remind you that it is also a "tool" (now can be used Leangoo, online kanban), one of the whiteboard usage is called the task Whiteboard, mainly for the team to use.

Figure 3 Task whiteboard for daily meetings (pictured in the book "Scrum and XP in the Smoke")

Figure 3 is a common task whiteboard, the needs of the team, usually the user story, is placed in the leftmost column "not CHECKED out", as the input of an iteration of the team, and then broken down into tasks (task) posted on the whiteboard with newspaper stickers (commonly known as yellow stickers) "CHECKED Out "that column and sign your name, even if it's a task. When you have finished a task, move it (yellow sticker) to the next column "done! : o) ", the Representative is done, the right side will generally set aside some space to record the progress bar and precautions to remind the team of important things.

If the Jenkins build server is a barometer of product development, then the task whiteboard is a barometer of team development.

Generally early in the morning at the daily stand-up meeting (Daily standup meet), the whole team will be around the whiteboard, sharing the progress of the task, by the way to move the task to the corresponding status bar, in this way can reduce a lot of unnecessary reporting meetings, And team members can quickly understand the overall situation of development. Believe that if a yellow sticker on the whiteboard for three days without moving, the team will certainly be someone to help. (no?!) Let's start by organizing them in team-work training. ）

Sometimes the team is more dispersed, or some people like the popular Home Office, you may start to use some graphical whiteboard to manage team tasks, everyone on the screen to introduce progress, the effect seems to be good, others (including managers) are also very happy, because they can at any time from the Internet to understand the progress of the team. Slowly, the face time seems to save, as long as the nest in the seat of the mouse, move the electronic yellow paste (if the support of beautiful procrastination is better) is enough.

Is this a good practice for agility?

Do you smell a little strange? It is the wrong tool I want to talk about, the whiteboard will cut down the communication between the team, reduce the transparency of the team, contrary to the principle of agile attention to people and team. If your team members do not regularly update the task time on the whiteboard, you will slowly see less accurate information. Some people may say that we still face the electronic whiteboard to open the daily standing meeting Ah, I hope you have a big screen bar, so that the effect is better.

Then why not say it's wrong, because in some cases it still works. The key is that the team is fully aware of its limitations, so I strongly oppose the use of electronic whiteboard at the beginning of the team, can wait for the team to fully understand the importance of agile human communication and then introduced.

This is also in Figure 1 deliberately with the Red fork reminder do not use Redmine to manage the task (Redmine this whiteboard function of the plug-in is poor, rather than with Leangoo).

So to understand your needs, do not let some tools to lead the nose, to understand the purpose of agile implementation, or if the problem is not in place, desperately want more powerful function, the results into a big misunderstanding.

Some tools can bring unexpected benefits.

The traditional agile writings usually refer to the CI part, but the use of tools is not limited to this, for example, I used in the actual project Gerrit, it is very fit for the purpose of agile, but also brings us unexpected benefits.

Code review is a good agile development practice, which is very frustrating to implement. Large enterprises often develop a lot of relevant specifications and procedures to guide code review. I heard that many companies will print out the code, for the days, it is really tired ah. This kind of way can give people a feeling of distrust, and it should be quite a waste of time.

Pairing programming (pair programming) is also a very good way of code review, it is worth a good study, but I am not too cold, experience is in large enterprises to implement the pair programming difficult, of course, if you can find the right drivers, that still can try.

Let's see how the Open source community solves this problem, and what tools are used? Google's Android system is now a very popular open source project, its code review (including the contributor's code) using Gerrit, very good things, in their own enterprise is also very convenient to set up, I love it.

Gerrit is a web-based code review and project management tool for projects that are based on a git version control system, so if you don't use Git (why not), you won't be able to Gerrit, so let's look at how code reviews are implemented in Gerrit.

First the Developer (contributor) code changes are pushed through the git command (push) to the GIT repository under Gerrit management, and the push commits are converted into one code review task (see Figure 4).

Code reviewers can view audit tasks, code changes through the Web interface, and make decisions through code reviews (Review) or rejections (Reject) through the Web interface.

The tester (which can typically be set as CI server execution) can be tested by access to fetch (FETCH) code changes, and if the test passes, the review task can be set to validate pass (verified).

Finally, code changes that have been audited (Review) and verified (verified) can be merged into the corresponding branch of the repository through the commit action in the Gerrit interface.

Compared to the code, its advantage is that the review action occurs before the skeleton to submit code, can only look at the changes in the part of the very intimate, online and anywhere to review it is also very convenient, which is different from the pair programming benefits.

Anyone can review the submitted code, the entire team's code is at a glance, easier to review, and very consistent with an open, transparent and agile spirit. After use can significantly improve the quality of code, and even after the habit, the code is not reviewed, I feel really embarrassed to submit code to the trunk up.

In Gerrit, code changes for any audit task can be accessed through a specific branch, so it is convenient to look at it or merge it locally.

Gerrit may be a little unaccustomed to the beginning of the implementation, after all, the entire workflow has changed, so the implementation needs to be considered overall.

As above is just a tool I particularly like recently, in fact, there are many similar tools, this is just bucket.

Summarize

Water can carry a boat, but also overturn it, tools and agile relationship is also the case, below I give a few suggestions:

It is important to try and understand these tools in your own software development environment by actively experimenting with new tools, developing tools in today's software development world, keeping pace with the times, learning about the latest trends and using effective tools to assist with agile implementations, and not just looking at instructions or wearing tinted eyes to see them. You should find the choice that best suits you through practice.

People are always the first, to know your team, to understand their needs, and sometimes even for the team, to risk the adoption of new technologies, new tools, so as to improve team cohesion (one of the agile elements). Some of the departments I've been pushing git, that's how they come in, and sometimes it's a waste of time to talk too much about their pros and cons, rather than spend more time trying.

The implementation of agile is also inseparable from the organization's support, particularly large enterprises involved in a lot of people (possibly different levels), when the drivers must use professional means to establish a continuous progressive tool introduction process, which will make implementation easier.

Nagging so much, is actually just some fur, there is a lot of things we need to continue to study.

Source: Programmer

Enable Agile tools to play an effective role in agile development