You CAN Develop with Loosely Defined Requirements, Sort Of.
We just opened up a beta site at www.plantcollections.org.
I'm the Business Analyst on the project. Wonderful idea, connect all the Plant Kingdom databases into a single repository and let anyone who wants it, access the data.
The initial requirements were, essentially, let me export the data I want based on any field in any view and allow me to download it in an Excel spreadsheet where I'll manipulate it to get what I really want. And I need this yesterday.
Continue reading »
Topics: Add new tag, Agile Development, Ruby on Rails
Agile Development and Testing: Unit or Montecarlo?
I've had a running debate with my colleague John McCaffrey on the question of testing. He is a big fan of unit testing and testing in general that examines the smallest possible units to be tested, then assembles them in every larger integration tests. The idea is that if you get the small stuff right, then the larger stuff has a greater chance of being right too.
Come to think of it, I'm a big fan of this approach too. But there are some times that this sort of strict constructionism is insufficient. There are a few instances that a comprehensive system test is necessary. Some instances that come to mind are:
Topics: Agile Development, Testing
Upcoming Talk at RIApalooza: Fast. Smart. Agile. User Experience Driven Agile Development
![[image]](http://mowser.com/img?url=http%3A%2F%2Fblogs.pathf.com%2Fagileajax%2Ffinal-riapalooza-logo.png){kind=logo}
Look Ma, no Powerpoint! My colleague Matt Nolker will be giving a talk entitled Fast. Smart. Agile. User Experience Driven Agile Development at the upcoming RIApalooza to be held at the Illinois Technology Association (ITA), 200 S. Wacker Dirve, 15th Floor, Chicago, on Saturday, May 31st.
The event has an interesting restriction: no Powerpoint. So no snooze fest sales presentations with endless bullet points. Since UXD (User Experience Design) has some visual aspect to it (you can only wave your hands and speak to a point for so long), we will be making due with "more primitive visual aids" as Tom Lehrer put it.
See you at the networking even on Friday.
800 on Your Math SAT, Software Development and Bugs
![[image]](http://mowser.com/img?url=http%3A%2F%2Ffarm3.static.flickr.com%2F2387%2F2433158044_d12543342f.jpg)
Why don't more people get a perfect score on the math portion of the SAT? I mean its dead simple -- just simple arithmetic. And there are plenty of bright young things that understand the problems cold.
I can understand stubbing your toe on the verbal; after all, there may be a word in the test that you just don't know or remember. But the math? There aren't more than a half dozen problems, and though the numbers may change, the concepts don't. So why don't more people get a perfect 800 on their math portion?
I ask this question every time someone asks me why there are bugs in software.
Topics: Agile Development, Best Practices
Whitepaper - Ajax Roadmap: How to tranform your website without starting from scratch
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.pathf.com%2Fpage_attachments%2F0000%2F0143%2FAjaxRoadmapsmall.jpg)
My colleague Brian Dillard has written a rather decent whitepaper entitled Ajax Roadmap: How to tranform your website without starting from scratch, that lays out an approach to transforming your website or application without having to reengineer the whole darned thing. It offers a number of case studies, rationals and justifications for launching Ajax projects, pitfalls, quick wins -- in short, everything you need to start an Ajax transformation in your own company.
We're quite pleased with it. Come on by and have a look.
Topics: Agile Development, Ajax Development
Agile Business, Microsoft and the Threat of Cloud Computing
Competition is the keen cutting edge of business, always shaving away at costs.
-- Henry Ford
![[image]](http://mowser.com/img?url=http%3A%2F%2Ffarm3.static.flickr.com%2F2252%2F2410316947_6433a1d65e.jpg)
I've been working with Java and Microsoft technologies -- .NET most recently -- in one form or another for quite some time. My company, now headquartered in Chicago with an office in NYC, was actually founded in Seattle by a group of four developers that had met around developing an Exchange-based bulk email system to replace the sendmail-based ones that Microsoft was using at the time. In that span, despite all of the food fights about total cost of ownership (TCO), etc., I haven't seen any evidence that Linux, Windows, Mac, Java, .NET, etc., puts you at a significant business advantage one way or the other. Until now.
Topics: Agile Development, Analysis, Editorial, Open Source
My talk at Web 2.0 Expo this Friday
I have arrived in San Francisco for Web 2.0 Expo. Over the next couple of days, I'll post about my favorite sessions and all that jazz. But here's the obligatory plug for my session, which takes place at 3.50 p.m. Friday in room 2003. I posted about my talk when I was first accepted, and I'm really pleased with the way it's come together. I did a dry run of it with my peers at Pathfinder on Monday and got a lot of excellent feedback.
As previously reported, my session is called Do Try This at Home: Ajax Bookmarking, Cross-site Scripting, and Other Web 2.0 Browser Hacks. In it, I'll examine the various draft WC3 specs that are already coming alive in the latest crop of browsers - and how you, the everyday developer, can help road-test the future of the web by employing the new tools sooner rather than later.
I'm part of the development track, but given that I'm speaking in the last session on the last day, I'm going to mix the technical details with a lot of strategy and DIY cheerleading. The best thing about my R&D job here at Pathfinder is the chance it affords me to play with all the latest toys. I want to encourage other developers to do the same, even if they can't find a way to work such forays into their day-to-day projects.
Hope to see you there!
Topics: Agile Development
BDD: Book Driven Development
Jay Fields, who has been posting a very nice sequence of nuts-and-bolts Ruby and Rails guidelines, pauses to talk about creating examples. It's a topic I've wanted to write about here for a while, and this is as good a lead-in as any. Plus, I'm generally interested in how principles of software development apply or don't apply in odd cases, and software being developed specifically for example purposes certainly qualifies as an odd case.
For Professional Ruby On Rails, I knew that I wanted to run a single example application through the book. I had some grand visions of it being a "real" application or at least a real example of coding best practices. For best practices, I think it's pretty good on a method-by-method bases, but has some weaknesses as an entire app, for reasons that I think will become clear.
Topics: Agile Development, Ruby on Rails
“Do Try This at Home: Ajax Bookmarking, Cross-Site Scripting and Other Web 2.0 Browser Hacks” - my talk at Web Expo 2.0 in April
O'Reilly has booked me to speak at Web 2.0 Expo, which runs April 22-25, 2008 at San Francisco's Moscone West convention center. I'm in the process of changing the session title, so ignore what it says on the website. The new title will be something along the lines of Do Try This at Home: Ajax Bookmarking, Cross-Site Scripting and Other Web 2.0 Browser Hacks.
Regardless of the slug, my talk will focus on how to push the latest and greatest browsers to their limits by peering under the hood and finding the quirks, bugs, hidden APIs and partially implemented draft specs you can use and abuse in your Ajax apps. My thesis is that instead of waiting for the Dojo or Prototype or Moo folks to exploit all the hidden goodies in today's browsers, you can go on a hunting expedition yourself if you have the right tools. With Firefox 3 and IE8 on the horizon, now's the time to start hacking.
Ajax history management will, of course, inform much of my talk, thanks to my stewardship of Really Simple History. But I'll also delve into cross-site-scripting hacks, offline storage and other on-the-bubble technologies.
My talk is scheduled for the final time slot on the final day of the conference: 04/25/2008 at 3:50 p.m. (conference schedule here). Any Agile Ajax readers who are attending the conference and plan to stick around till the bitter end should come and check me out.
Topics: Agile Development, Browsers, Javascript
Gmail, agile development and user experience design
Ionut Alex Chitu of Google Operating System posted yesterday about Gmail's evolution from internal beta to public beta to today's constantly-evolving-but-still-beta version. Gmail's Humble Beginning never uses the phrases "agile software development" or "user experience design." (Nor, for that matter, does the original post, by Gmailer-turned-FriendFeeder Paul Buchheit, from which Chitu liberally quotes.) Regardless, the evolution of Gmail provides a case study in the combination of agility and UxD.
Sample quote from Chitu's post:
Gmail got a delete button after many months of requests from users, even if Gmail's philosophy was "archive, don't delete". Gmail will also add some functionality from folders to its labels, most likely drag and drop.
The key step is to build a product that's interesting enough to a attract an audience and learn from people who use the product. "The sooner you can start testing your ideas, the sooner you can start fixing them," explains Paul.
Topics: Agile Development, Google, User Experience
Agile Development: Pipelining
Sometimes you can roll into an iteration or sprint with a handful of high-level user stories and refine as you go. But if you have a very complex system with lots of interdependencies, or are trying to incorporate a high level of user experience design, or your domain experts aren't readily available to you on a daily basis, then your requirements have to be a little more refined up front.
The answer isn't to go to a waterfall process and bang everything out months in advance. The answer, rather, is to pipeline requirements and development. In practice, the functional team -- made up of Business Analysts and Interaction Designers -- focuses on the requirements for sprint n+1 during sprint n, while the development team focuses on developing the features for sprint n. You can, and should, extend this further: the QA testing team should work on building the automated tests for the features developed during sprint n-1 in sprint n. Anther way of saying this is that the development team is looking at now, the function team is looking one sprint ahead, and the testing team is looking one sprint behind.
While the feedback isn't as tight as if you were to do all of this in one sprint, it's still pretty far away from waterfall. One thing worth pointing out is that this doesn't mean that you do no testing or requirements gathering for sprint n in sprint n, just that the bulk of it happens in the sprint preceding and following the current one. Also, the development team will be involved in the requirements gathering somewhat, but they won't be forced to context switch between what they are working on now and what they will be working on in the next sprint. And they'll definitely get to ask all of their questions in the next sprint planning meeting.
Anyhow, if you find yourself wrestling with trying to jam requirements, development and testing all into one sprint, give pipelining a try.
Technorati Tags: agile, sprint, pipelining
Topics: Agile Development, Best Practices
Agile planning tools.. paper or ‘plastic’?
How often have you heard, "Yeah it's not great, but it's the best thing out there", or maybe "We spent two months investigating this tools and there's no turning back. End of discussion. We're not going to switch again!" Does anyone ever hear anything like that when your only tools are whiteboards, paper, pencil and a wiki? What's there to change? The color of paper? Illegible handwriting? How long the walk is from the kitchen to your story wall? These are cheap to fix, and anyone can affect such change more easily when the materials you have to work with don't require logins, passwords, user permissions, mouse clicks, overhead projectors, VGA cables, and a fully charged laptop in a meeting room.
I have used many kinds of planning/tracking tools throughout the years. A recurring belief that crops up all the time is one that suggests that the biggest factor preventing a team from being more agile is the absence of a "proper" agile planning or tracking tool that will satisfy everybody's desire to (you guessed it) be more agile. I find this strange to say the least.
Ron Jeffries said it very well here:
When you're working with a tool, someone
owns the keyboard, and everyone else is an observer. It's easy to
develop the habit of "check the database" instead of "talk with each
other". It's easy for a manager to think that he's managing the group
when he's really looking at his screen.
Might a team need a tool like these? Well, yes, they might. But to a
team just learning XP or Agile, I'm very concerned that the tool will
get in a way.
And now, a few words of advice...
Topics: Agile Development
Ideal team size for your next Facebook project
I recently worked on a Facebook application for one of our clients. This turned out to be our first collective experience building for Facebook, and it involved a mixture of re-using existing web services and building new ones for use by the same infrastructure. All in all, a challenging thing to build and deliver given a relatively short deadline.
While there were many architectural considerations at hand, one of the interesting aspects of the project for me dealt with how we structured our team and went about tackling the problem. As a result, I have a bit of advice on team size for those of you considering similar projects with an existing team at your company. But first, a little history...
Topics: Agile Development, Facebook
Agile User Experience: If you have a silo, knock it down
In many development processes, team members are organized by functional group. A project might have a team of developers building the code, and then down the hall or across the globe, a separate team of designers working on the visual and usability aspects of the application. The two sub-teams are walled off in their own silos, and communication between the two sides is minimal.
This structure is not compatible with an Agile software process -- it's too hard to get rapid feedback between the teams that make a process truly Agile. Worse, if the two teams are separated, the odds that they will have a common conception of the project, or even a common set of terms for discussing the project.
The most important step in tearing down the silos in your project is just switching your mindset from function-based teams to project-based teams. Continuous integration spreads from being just something the developers do to a way of making sure that all aspects of the project are in synch.
At the most basic logistical point, the designers and developers should share a common code repository. There's a certain amount of overlap in the tools used for web applications on both sides. If designers can see the latest version of the application when making CSS or HTML changes, then developers can see those changes and work with the most current design as quickly as possible.
In order for this structure to work well, each side needs to move out of its silo and toward the other. Developers need to have an awareness of usability and design issues, and be able to discuss potential problems with the designers. Developers also need to be willing to do any rework that will be needed as the design changes.
Designers need to be willing to work at least some of the time in the developer toolkit, working with source control, able to make CSS or HTML changes directly in the code files (even better if the designers and developers can make it easy to make tweaks at the JSP or ERB level). Not everything that a designer does can be captured this way, but using common tools and files where available increases the team's ability to work together. Sharing knowledge makes the team more able to notice potential problems, and makes teams more stable over time.
Last week, I wrote about how a user proxy can help integrate Agile and User Experience Design.
Once again, let me mention the upcoming book Professional Ruby on Rails. Available mid-February.
Topics: Agile Development, Ruby on Rails, User Experience
Agile Development, Documentation and Bringing Projects back from the Dead
One of the things that comes up quite frequently when talking about Agile development with newcomers to the topic, is the subject of documentation. They hear about "just enough" documentation, "low ceremony" process, and Wikis. To many it seems like "not enough" documentation.
When pressed on what they mean by documentation, they usually respond that what they want is a document that represents all of the specifications and decisions about specifications, the architecture, the design, and the tests that completely describe the system being developed. That may seem like a reasonable request, and I think that a typical agile project, with it's User Stories and various other Wiki artifacts that are produced in each sprint, constitute just such a record.
Topics: Agile Development
