Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

7 Tips for Effective Agile Software Development : Page 2

Agile software development provides a set of patterns and best practices, they are only half of the equation. These 7 tips will fill in the rest.


advertisement

The Role of Testing in the Sprint Process

At the end of every sprint, there is a requirement to verify that the code written will not introduce bugs into the system. This assurance is usually addressed through various testing approaches. At Zoosk, we employ a number of mechanisms to test our code. This is particularly important because our business logic is very complicated. We have numerous business rules that control the user sign-up process, what content can be uploaded, interactions between users, how many messages they can send and receive, and so on. Rigorous testing of these interactions is the best way to guarantee consistency across sprints.

The first layer of testing that we employ is unit test coverage. Every developer is expected to build unit tests that exercise their code with each feature check-in. We don't try to employ test-driven development, which would require the unit tests to be written first, but do expect a basic set to accompany the code that enables the feature. These unit tests are run against the code in our continuous integration environment, which is controlled by Jenkins. Automated builds with a unit test run are kicked off with each code commit. Jenkins sends an email to all committers for a failed test run.



The second layer of testing is manual testing of a feature. For new features developed in a sprint, the QA engineer assigned to that development team will begin an initial set of functional tests after the feature is generally working. This is followed by product manager demos and acceptance testing. The final layer of testing applies to existing features and business logic that weren't directly touched during the sprint.

To test these functionalities, the QA engineer will run through a battery of manual regression tests at sprint's end. As new features become a part of our permanent product offering over time, other QA engineers will create automated functional tests that run against the code in a controlled test environment. The output of these automated tests is compiled into a summary report that is distributed to and reviewed by the development teams daily.

How to Communicate Requirements Efficiently

The project requirements communication process is a place where many Agile organizations can get hamstrung. Teams should keep the desired outcome in mind: to get the product manager's vision for a feature into working code on the production environment as efficiently as possible. Therefore, whatever tactics serve this end, adjusted for the nuances of each organization's culture and structure, can become the standard practice.

If your development team is co-located, then in-person, high-bandwidth communication is often the most efficient. If a product manager can explain a feature to a single developer in 30 minutes, and then the developer can go and build that feature in the same day, then there is little need for detailed requirements documentation up front. However, as the feature becomes broader, with more developers and even multiple development teams involved, then some amount of written documentation is a more efficient means to communicate the requirements.

At Zoosk, we employ a fairly lightweight documentation process. The product team will generate visual mock-ups of the feature, usually anchored around the UI views. These mock-ups are then annotated with business logic or functional requirements. The documentation is stored in a page on our wiki. Each project's work items are captured as a tree of tickets in our bug tracking system. The parent ticket will have a link to the wiki with the associated requirements documentation. Further clarification of requirements beyond this level of detail is usually accomplished through conversations. On the implementation side, the engineering teams will often create a design document for a large project. This is usually a wiki page as well, that includes data structures and basic class diagrams.

We invest more effort in specifying interfaces between systems, usually at the API layer. Detailing the data contract between the client application and the server-side API is very important and will save a lot of time, as it naturally forces the developers to discuss implementation details. We apply this general approach to requirements communication in varying intensity levels depending on the size or complexity of a particular project. At Zoosk, we generally err on the side of having a conversation versus requiring a written spec.

Keep Teams Lean

Since the Agile process values rapid, in-person communication, we try to keep our teams small. Our Agile teams range from 2-6 developers, plus a product manager and QA engineer. If a team gets larger than that, we start to see incrementally greater overhead in keeping the team informed and coordinated. Each team member is fairly self-directed and we entrust large swaths of feature implementation to individuals. For a larger project, we will appoint a project lead, who gathers status updates and coordinates activities across multiple developers (or even development teams). However, we still try to rely on the daily stand-ups and general Agile process to keep projects organized, versus falling back to a stricter command-and-control structure. Smart people, organized around a common goal with some basic shared practices usually find the most efficient way to collaborate and work through coordination problems.

Use Retrospectives to Tune Your Agile Process

If an Agile team's process is continually evolving, it is the retrospective that provides the input for these process improvements. After every sprint, we conduct a retrospective with the full organization and capture input around two themes: what went well and what should be done differently. Originally, we gathered input on what didn't go well, but changed that into "do differently" to make improvement more actionable. Many of our current Agile practices are "do differently" suggestions that came out of a past retrospective.

Also, after a particularly large project or a challenging production release, we will conduct an ad-hoc retrospective. The key outcome of these retrospectives is to reinforce how our process is working well and to identify new opportunities for improvement. Additionally, I have found that retrospectives have a positive side-effect on team morale, allowing team members to express their appreciation for the efforts of others and to air grievances in an open, non-threatening environment.

About the Author

Peter Offringa is vice president of engineering at Zoosk.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap