Announcing: BarCamp Hong Kong 2008

Posted by Conrad Benham on August 28, 2008

Agile, Ajax, Apple, Artificial Intelligence, Aspect Oriented Programming, Big Visible Charts, Blogging, Business Analysis, C, C#, C++, CSS, Continuous Integration, Databases, Design Patterns, Domain Driven Design, Entrepreneurialism, Expert Systems, HTML, Haskell, Innovation, Iterative Development, Java, Leadership, Linux, Mashups, Mobile Development, Open Source, Pair Programming, Project Management, Retrospectives, Ruby, Scala, Social Software, Stand Ups, Start Ups, Web 2.0, Web Design, Web Services, Windows, XP…

These are just some of the things you might consider presenting at BarCamp Hong Kong 2008 on September 6 2008. With the hordes that are expected this year, the “unconference” promises to be a very lively and fun-filled day in which you will get to share your ideas and hear the ideas of others’ and make new friends. Like last year, the BarCamp will focus on IT related topics. Participation doesn’t mean you have to present as anyone can attend any event, though if you have something you’d like to share, you should certainly consider presenting.

Still not sure? Check out what some people said about last years event:

Want to know more about BarCamp in general?

Don’t forget your laptop and charger, Wifi will be provided and some of the presentation rooms even have projectors for live demonstrations.

For more information check the BarCamp Hong Kong 2008 website.

See you there!

BarCamp Hong Kong 2008 was not organised by Agile Hong Kong.

Control Chaos with Scrum 9

Posted by Conrad Benham on August 17, 2008

On Tuesday, Aaron Farr of JadeTower gave a very entertaining and informative overview of Scrum. Drawing on experience gained from working in Scrum teams at Siemens, Aaron was able to provide a thorough insight into the process.

Aaron opened by discussing how Scrum is a lightweight process that manages the chaos associated with building software. This chaos is controlled by providing guidelines designed to limit the impact. Various roles are necessary to enable this including a Product Owner, Scrum Master and Scrum Team.

Scrum is an iterative style of development where certain pieces of functionality are delivered in a fixed period of time known as Sprints. Aaron introduced the notion of a Product Backlog which is held in user stories and can be estimated and prioritised. The product backlog is defined during the planning meeting that occurs prior to the commencement of a sprint. The sprint runway was also discussed which clearly defines work that is to be complete.

Some interesting questions were raised as to how stories should be estimated. The two concepts are intuitive hours and the somewhat abstract idea of story points. Either way story estimates help determine velocity which can be used to create burndown charts.

Aaron ended the evening with a highly interactive session in which he demonstrated the creation of stories that were subsequently estimated. In this entertaining session he asked for input from people to determine the relative size of each story. That is, the size of each story in comparison to other stories that were estimated. The first story chosen was used as a baseline to estimate the size of subsequent stories.

Aaron has kindly put his slides on Slideshare. He also suggested people refer to the Scrum Checklists on InfoQ for more information in the way of mini-books about Scrum. Aaron also made reference during his presentation to the page You Aren’t Gonna Need It hosted on C2.

Scrum: Agile for Everyone

Posted by Conrad Benham on August 04, 2008

Need an agile, iterative process that still gives you the flexibility to code software in a way that works for you and your team? Scrum may be the answer. Focusing on larger issues of workflow and project management, Scrum provides a framework to tame the chaos of software development. Many other agile (and non-agile) methods can work hand-in-hand with Scrum, making it an excellent first step to transitioning to a more agile workplace.

J Aaron Farr is an experienced scrum practitioner and previously helped assist and train an enterprise development team at Siemens Medical Systems in the ways of agile software development. In this session, Aaron will introduce Scrum and share some practical lessons learned.

When: 7:30pm, Tuesday 12th of August 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
Contact

Practical Builds using Hudson 1

Posted by Conrad Benham on August 04, 2008

Our last Jam was both theoretical and practical. In the theoretical part we looked at what makes a quality build system. The practical part took some of the theoretical concepts and applied them, focusing specifically on continuous integration using Hudson. We also played around with some of the tools typically used in Java projects to aid in the project quality.

In the current context a build system is something that automates the static checking, compilation and running of automated tests (unit, integration and functional) against production code. If the build system has been carefully designed it may also include a process to manage the upgrade of a database and also create deployable artifacts (of course a build system may do more or less of the activities described). A facility to deploy these artifacts to various environments may also be included, though this is increasingly being handled by the continuous integration environments as they mature.

While the choice of tool used to automate the tasks mentioned above does not really matter, there are choices that will make the job easier. Some in the industry argue that the XML approach offered by tools such as Ant is cumbersome and not as powerful as new approaches that are offered by tools such as Rake or the Groovy Ant Task the script is actually written in code. Certainly the thing that must be avoided is starting a project using plugins that are offered by IDE’s to build certain parts of a system. Doing this tends to lock the building of a project into the IDE which makes the task automation impossible (unless of course if the IDE plugin has a scriptable equivalent). Over time it can become increasingly difficult to release the dependency on the IDE plugins. The aim is to create an automated build system that can be invoked by an external agent (a continuous integration tool or a developer) and not require any further intervention.

Simplicity is key! An easy to use build system will not require the definition of properties before it can be executed on a developer machine. For efficiency it should be possible for a developer to check a code base out of a repository and be able to invoke the build system on it (provided the requisite build tool has been installed correctly).

One goal of a build system is to make it fast, so it is painless and easy for a developer to run a  full build prior to checking code changes into the code repository. The pain comes when the build is slow to complete. In such a scenario it is worth optimising the system (code or build system itself) so it executes faster. Sometimes the pain can be transferred to the continuous integration tool. This implies that a different build task or target may actually be invoked by the continuous integration tool. It is common to have a default build that is executed by developers (remember our goal of making it easy for developers to get up and running) which runs a good portion of the build omitting that which is slow. The slow parts can be transferred to the continuous integration version of the build.

We also looked at failing fast. It is important to ensure that those things that run quickly do so early so they can also fail early. For example, static code analysis tools that check for duplicate code should be run first as they are generally quicker to execute than a compiler or automated tests and therefore save time by failing early and fast.

In the practical component of the evening we used Hudson to integrate a solution to the Anagrams problem that we solved in the first Code Jam. That solution was hosted on GoogleCode and can be found here. It is also the same as the solution posted in the first Code Jam. The aim of the practical component was to install and configure Hudson, understanding the capabilities of what it and tools like it can do. We then modified the build file that came with the project to add checks to it. We also looked at a number of tools that are commonly used in Java build systems. All of the tools we looked at are open source:

So how does a build system affect the agility of a project? A quality build system will help verify the quality of a system. Beyond that it aids in the concept of frequent releases (one goal of Agile) by making the artifacts required for deployment easy to create and obtain. Even deploying them in some cases.