David Bock

Presentations

Estimating vs. Guessing - How Agile Teams Estimate Their Work

Estimating is regarded as little little more than 'educating guessing', but so much can hang on the quality of those estimates. With good estimates we can set clear expectations for project delivery, but with bad estimates we can run over schedule and over budget, or worse. We often estimate when we know the least about the work that needs to get done - so how can we make the best of what is potentially a bad situation?

In this session we will look at how successful agile teams estimate the scope of work at the beginning of a project, estimate the amount of work that fits into any one iteration, track the work through the iteration, and the 'burn down' through the end of the project. We will look at 'low ceremony' estimation techniques like planning poker, trim down 'high ceremony' techniques like Wideband Delphi, and look at "FET+", an estimation technique originally developed as a foil for a CMMi effort.

With a little effort, a little planning, a little tracking, open communication, and some good metrics, estimation does not have to be a 'crystal ball' activity.

Hindsight is 20-20 - the Agile Retrospective

Agile development teams should always be looking for ways do develop software better, and the iteration is the perfect tool for doing so. Each iteration we can tweak, tune, adjust, and readjust our practices. So how does an agile team decide what to tweak? This is the purpose of the Agile Retrospective.

On one end of the spectrum we have the 15 minute "what works and what didn't" meeting, and on the other hand we have the "offsite summit" looking at the entire project timeline, from the first handshake with the client to the deployment of maintenance releases. Where do these kinds of meetings fit in the Agile project lifecycle? What kinds of things can we expect to learn? Are there any topics off-limits to the critiquing eye of improvement? How do we keep the focus on the software and not the people? Will we have to manage personnel conflict?

In this session we will learn how to run an agile retrospective while keeping focus on the goal: uncovering better ways of developing software.

Deployment with Capistrano

Capistrano is the de-facto tool used to deploy Rails applications, but it is useful for so much more. In this talk we will publish a real website from scratch, with consideration for real world stuff like safeguarding passwords, turning on and off application monitoring, multiple machine deployments, and general system administration tasks.

In addition to a real deploy in-session, we will look at the real deploy scripts for several real-world, large websites involving multiple machine architectures, minimal (sub second) downtimes, and different server configurations.

Monitoring your Rails application with ExeptionNotifier, Munin and Monit

(including side processes like backgroundrb and ferret)

TBD

Rails Application Tuning and Performance monitoring

Most developers who adopt Rails deploy their first application and see it get rushed under heavy load... thus the rumor that 'Rails doesn't scale'. Well, Rails does, you just have to know a few things

We will touch on a lot of things in this talk - measuring performance tuning your browser experience query tuning caching - built-in and plugins architectural modifications and more

Tools for your Ruby Toolbox - Web Publishing Edition

Rails may be the framework that turned many of us on to Ruby, but if you are using it for all of your server-related Ruby projects, you probably have a hammer and are seeing every problem as a nail. There are a number of smaller, tighter solutions to problem in this space, including GServer (built into the Ruby libraries), StaticMatic and Webby (tools for generating a static site, but with all the templating goodness), Sinatra, a small server with an awesome DSL for restful web services, and Rack, an easy way to get content published as a web service.

We will spend a little bit of time of each of these, seeing how you can use each for a project where you might have previously considered Rails.

Metrics for steering your projects to success

There are a lot of things we can measure about our source code, but what about the "project as a whole" and its overall health? Are there ways of measuring the effectiveness of our processes? Are there things we can measure that would point to project automation wins? Is there a way to measure team 'morale'?

While we can gather a lot of metrics from automated source inspection tools, those can make us focus on the wrong "problems to solve"... There are a lot of personal, team, and project-level things we can measure and tune that can lead to big wins. Using advice from an obsessive-compulsive numbers collector, the Personal Software Process, Scrum, the Pomodoro Time Management Technique, and Personal Kanban, we will discuss ways of effectively measuring aspects of our team and our productivity, and actions we might take based on what we learn.