discovering asian technology
Here a few impression of last weekend’s coding for fun event at Exoweb, unfortunately I didn’t take many pics.
Technologies applied included: Pike, OpenGL, Flash, Chipmunk, Twitter, cURL, Festival, C, Boarduino, Arduino, LED, and many more.
Update: Martin has offered me to add his pics to my flickr account. Thanks, Martin :).
We would like to invite you to a weekend of coding for fun at the Exoweb offices in Beijing on June 28/29. The event is an experiment in which we are trying to bring together developers in an informal way to encourage them to share their projects and coding experience. So, it’s basically like a Hackathon. Everyone brings in their computer and hacks on their own code. People could also give short presentations or demos of their current projects if they want. And if you don’t have anything to hack on you may just look around and watch or join others.
Registration: here
Time: 11am - open end
Date: Saturday and Sunday, June 28/29th, 2008
Location: Exoweb office, Tianshuiyuan Shangwu Zhongxin A-505, 2 - Tianshuiyuan Dongjie, Jintai Lu, Chaoyang District, Beijing
Map: here
In software development, the ticket plays a central role in the development process. In Latour’s terms, the ticket is a non-human actor which carries a message. More generally, it’s a virtual or real object which contains a description of a specific task or a group of tasks. Most tickets are part of a larger project. A project is thus broken down into a number of ideally independent tickets which can then be implemented by the individual developers. In a projects, the final product’s implementation is the sum of all of its tickets.
Many books and papers on agile software development advocate the use of user stories for requirement specification. Wikipedia defines user story as follows:
“A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. […] The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software.
User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them. The intention with the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.
[…] Before a user story is to be implemented, an appropriate acceptance procedure must be written by the customer to ensure by testing or otherwise determine whether the goals of the user story have been fulfilled.”
How are tickets, tasks, and user stories related? As mentioned before, a ticket is just a container for a requirement description. At Exoweb, we use user stories to define the client requirements. The tasks are subsequently defined by the developers as the individual steps that need to be implemented in order to fulfill the customer’s requirements for a user story. There are several things we can learn from Wikipedia’s definition above:
The literature insists that user stories should be written by the customers. Our own experience, however, showed that the quality of the user stories improved considerably when the client was assisted by some members of the development team. Currently, we organise an additional meeting a few days before the sprint meeting, in which the project manager and the team leader are preparing the tickets for the next sprint together with the customer.
User Stories in Detail
In User Stories Applied Mike Cohn presents a formal approach to writing user stories. He suggests the format:
“As a [role] I want [something] so that [benefit]”
For example:
“As a visitor of the website I want to be able to filter search results by additional keywords so that I don’t need to look through a large list of possibly irrelevant results.”
Why should agile teams care about user stories? The main reason is because user stories encourage communication and are written in a language that both, developers and client can understand. A user story should be precise enough for the client to express what he wants and for the developers to estimate it’s complexity. For a more detailed explanation of the difference between user stories and use cases, check out this article.
The Ringier team at Exoweb uses estimation poker for breaking down user stories into tasks. Estimation or planning poker is an excellent way to learn more about the details of a user story. Each developer is asked to estimate the user story and to explain his estimate. This encourages consensus among developers and it allows the team to agree on the necessary technical tasks which need to be implemented for a specific user story. As the client is present during the poker, the team members can ask questions to avoid misunderstandings. When using estimation poker for planning tasks, it is very important to avoid anchoring:
“Who ever starts the estimating conversation with, “I think it’s 50 days” immediately has an impact on the thinking of the other team members; their estimates have been anchored, i.e. they are all now likely to make at least a subconscious reference to the number 50 in their own estimates.”
Defining “Done”
As we have seen in the Wikipedia excerpt above, every user story should be completed with a definition of “Done”. This definition of is ideally a description of the demo the client wants to see at the next sprint meeting. More generally, it’s an agreement between the development team and the client in which the client defines which conditions a ticket has to fulfill in order to be considered “Done”. At Exoweb, we additionally use this definition as a base to define the functional tests for the ticket.
Ticket components
At Ringier team, each of our tickets consists of the following elements:
Ideally the ticket should contain all information a developer needs to start working on a it, and all possible impediments should be solved before a ticket is accepted for a sprint. This allows to minimize the risk of the implementation differing from the client’s expectation. Additionally, it facilitates the developer’s work because he knows exactly what he has to do in order to complete a ticket, and it enables the project manager to decide when to accept a ticket for demo for the next sprint meeting.
Agile software development is a process which requires constant tuning. At Exoweb, we take every sprint as an opportunity to reflect on and improve our performance. In the sprint review meeting, we discuss the last sprint, analyse the velocity and burndown charts, discuss problems and their solutions, and find ways to avoid past errors. For the current sprint, the Ringier team has decided to make the following adaptations to the development process:
The team will be experimenting with these changes during the current sprint and then decide in the next sprint review meeting if the adaptations have actually solved the discussed problems.
The Process
Every ticket which has been committed to the code repository, has to go through two independent review processes: the code review, and the demo review. The code review is done by the other developers in the team, suggesting improvements and tweaks, in order to ensure code quality. The demo review is a process in which the developer demos the ticket features to the project manager and the on-call developer who are then responsible for closing the ticket and preparing the demo for the sprint meeting.
The Changes
For the current sprint, we have decided to adapt the demo review process. We now assign two developers to each ticket: the maintainer and the tester. While the maintainer remains responsible for the actual implementation of the features, the tester will be writing automated tests and demo the ticket in the sprint meeting. The tester will thus replace the on-call developer in the demo review. Additionally, with the automated tests being written by someone else, tester and maintainer have to agree on the ticket design before starting to write their codes. And while writing the code, the maintainer will be able to use the tests as a benchmark.
The Reasons
With every sprint, the complexity of a project grows, and even small changes can produce major damage in the existing code if no precautions are taken. While the importance of automated tests is often underestimated in the beginning of a project, it becomes increasingly important when the project advances, as even seemingly minor changes might have unexpected side-effects.
So far, programmers were responsible for writing tests for their own code. This means design, implementation, and testing was done by a single person. As the team has previously decided that they preferred code reviews over pair programming, design problems were only discovered in the code review. We thus hope that above adaptations will lead to better design decisions, cleaner code, and less bugs which turn will reduce the need for refactoring after code reviews and increase the team’s velocity.
“Free Software is a set of practices for the distributed collaborative creation of software source code that is then made openly and freely available through a clever, unconventional use of copyright law. But it is much more: Free Software exemplifies a considerable reorientation of knowledge and power in contemporary society — a reorientation of power with respect to the creation, dissemination, and authorization of knowledge in the era of the Internet.”
Christopher M. Kelty, Two Bits (2008), page 2.
What happens if we place this definition in an imaginary context in which copyright law doesn’t exist, where people are prosecuted for mentioning “reorientation of knowledge and power”, and where creativity is not considered a positive trait?
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Agile software development has started out with white-boards, story cards, and face-to-face meetings. It’s main goal was to develop software according to the customer’s requirements, to accommodate new requirements during the development process, and to create an environment which encourages self-organisation and team responsibility.
However, the real world is somewhat different. We have to deal with customers, contracts, and project reports. Without tools and processes it is hard to meet these needs:
- How do we write contracts for agile projects?
- How can we record meetings, discussions, and decisions in an efficient way?
- How do we meet the managers’ needs for documentation and project reports?
Negotiating contracts for a software product almost always involves understanding what the customer wants, creating a product backlog, making financial and time-based estimations. But agile is about iterations, about accommodating changing requirements, about constantly rewriting the product backlog, about estimating user stories, not product specifications.
How do we write contracts for agile projects?
In traditional software development, a fixed-price contract is often limited by time and scope. With these two constants, it is possible to make a cost estimate and schedule resources. In an agile project, however, the scope keeps changing, and time requirements need to be renegotiated according to the scope. How can we map the original scope to the new scope to find out which services are not covered by the initial contract? How can we compare dropped features to newly added features to negotiate contract amendments? And how do we decide if a project is done according to the contract?
It seems that with agile methods, it is always difficult to give estimations, and the fairest contract would be based on paying a team to work on a piece of software for a certain amount of time. However, this seems not to be possible in most cases. Hence, we need to constantly keep in mind the product backlog. We need to warn clients when they ask for new features, we have to tell them that adding these means removing other features or allowing for more time with all the related financial consequences.
This means that the product owner cannot simply come into a sprint meeting presenting the next sprint’s features. New features and changes have to be discussed with the respective financial divisions before they are implemented, or at least their consequences have to be transparently communicated to the responsible managers. These aspects make agile planning less flexible, and it means that much more people are involved in the planning of a sprint than the original chicken- and pig metaphor suggests.
Additionally, a client will often require a report of which tasks required more time than expected and why. It is thus important for agile projects to be able to provide a detailed documentation of meetings, discussions, and decisions.
Tools for Agile Projects
The Agile Manifesto values “individuals and interactions over processes and tools”. However, as Liz Barnett, chief editor of the agile journal says in the article on Tools for Agile Projects, “this does not mean that individuals and interactions must replace processes and tools”. Different software tools have been developed in the last couple of years. Tools range from issue trackers like Trac to commercial products like Thoughtworks’ Mingle, Atlassian’s Jira, as well as many others. The goal of all these tools is to provide support for the management of agile projects.
However, the needs of the people involved in agile projects are different. The goal of this post is not to compare these different tools, but rather to identify the expectations:
What the developers want
Developers mainly want a place (ideally a single URL) where they can find all information related to a specific task. When they start woking on a task they want it to be well documented and to include all the information they need. Developers don’t like to be stuck with a task for which some information is missing or pending product owner approval.
What the product owner wants
Product owners want to see a products’ progress. They want to know how long it takes to implement a taks, they need an estimate of when the product will be finished, and they want to know where they can find the latest version of the software.
What the scrum master wants
Scrum masters want an overview of the project. They want to know which tasks are in progress, which are completed, and what remains to be done until the end of the sprint. The scrum master also wants to know where to find the implementation of a specific task, if it has been tested, and who is responsible for it.
What the managers want
The managers want numbers and histories. They want to know which tasks caused a delay and why. They want to know who is responsible for a decision: Is it the team or the client? They want to be able to reproduce all information related to a task, sprint, or product. They want to make statistics, know how long a task took compared to its original estimate.
Yesterday I attended my first Beijing Open Party, a monthly techie unconference event which takes place at the offices of ThoughtWorks here in Beijing. It’s similar to Barcamp, and it’s great fun. This was the first time they were proposing an English track, however, there was only one presentation in English yesterday. Topics ranged from Django over programming in different languages to event-driven architectures and StarDict. About 60-80 (estimation varying depending on who I talked to) people attended the event.
The party started with a stand-up in which everyone introduced themselves, and a presentation on NGO work after the earthquake in Sichuan. After the intro, people were asked to propose their topics, and give a quick talk about what they were going to present. Presentations took place in four different rooms, and there was a total of 12 talks.
I don’t know yet when the next Beijing Open Party will take place, but I will post it here as soon as I find out.
