REST-Based service design
Series [ REST-based Service Design ] Tags [ REST API ]
Just wanted to walk through a quick REST-style API design exercise. Let’s suppose I want a service that lets folks maintain a list of favorite foods. Just as a quick strawman design, let’s walk through some URIs and supported operations: http://host:port/path/{userid}/favorites GET on this URI returns a list of the current user’s favorites. List might be empty. PUT on this URI overwrites an existing list of favorites. DELETE on this URI sets the list of favorites to the empty list.Code Artisan's New Year's Resolutions
Tags [ Cobertura, design patterns, estimation, Javadoc, resolution, TDD, unit test ]
Well, it’s a new year, so time to sit down and draw up a list of development resolutions. Without further ado: I will create unit tests for all my classes. There’s no excuse not to have at least some kind of unit test for each class that gets created; this at the very least provides a stratum on which other people can flesh out the tests to cover things that come up.Who designed this stuff, anyway?
Tags [ architecture, Scrum ]
Many development organizations have an “architect” role, meant to provide technical direction over an entire engineering process [As far as I can tell, “architect” really seems to be shorthand for “someone with deep and broad technical understanding and experience”]. How does this mesh with scrum-based, grass-roots development by empowered teams? Or perhaps, the real question is: if I have folks that would traditionally fill an architect role, what’s the best way to utilize them in a scrum setting?What's the APR on your technical debt?
Tags [ Cobertura, Javadoc, Ken Schwaber, Maven, PMD, Sashimi, Scrum, technical debt ]
Today we’re going to discuss technical debt–what it is, what its impact is, and what to do about it. One of the key tenets of scrum and other agile development methodologies is the idea of producing production-ready increments of work at the end of each iteration. Ken Schwaber calls this “sashimi” in the scrum framework–a slice of product. You may have also heard scrum practioners talk about the definition of “done”, i.Scrum thoughts: Improving individual estimation
Series [ Scrum Thoughts ] Tags [ estimation, evidence-based scheduling, monte carlo simulation, Scrum ]
In my last post, I described that our team routinely overestimates the amount of work it can finish in a sprint. The amount of this overestimation is quite high at times - sometimes we only finish two-thirds of what we initially plan. So how can we get our estimation better? I think there are two sources of estimation error: one is how many hours per day you actually have to apply to sprint tasks; the other is how many hours it will take you to actually finish something.Scrum thoughts: Fixed feature set vs. fixed time
Series [ Scrum Thoughts ] Tags [ backlog, estimation, iteration length, product owner, release management, Scrum, timeboxing ]
I think we’re going to enter into an interesting discussion with our product owners where they would like to propose moving away from a fixed-length (in time) iteration model to a fixed feature set model. The claim is that it is too hard to maintain a release roadmap when the set of features that comes out of a sprint is fluid. [Sidebar: our sprint teams routinely overestimate how much we can accomplish, so items are always falling off the end of our sprints.Scrum thoughts: staggering sprint teams
Series [ Scrum Thoughts ] Tags [ prototype, Scrum, sprint, waterfall ]
When you have two or more sprint teams dedicated to a product, I think there’s an opportunity to stagger their efforts in the following way. Let’s track a user story through two sprints. In the first sprint, the prototyping sprint, design, UX, and development cooperate to put together a working proposal for a user story. At the sprint review, if possible, the whole user story will be complete, where design, UX, and implementation are all consistent.Scrum thoughts: scrum-of-scrums and daily scrums
Series [ Scrum Thoughts ] Tags [ burndown, confidence, Scrum, scrum-of-scrums ]
After planning, we dive right in to having daily scrums. We’ve gotten these to be pretty efficient (today we had a 10-person scrum finish in around 8 minutes). One key thing is starting on time–we charge people $1 if they are late to the scrum, and no one (not even the scrum master) is exempt. When we get enough saved up, we make a donation to charity (there was a thought that this should go to buy donuts for the team, but that felt a little like rewarding ourselves for being late).Scrum thoughts: sprint planning
Series [ Scrum Thoughts ] Tags [ availability, confidence, Scrum, Scrum master, sprint planning, tasks, Trac ]
If you’ll recall from my earlier post about pre-planning, we enter into our sprint planning meetings with a stack of user stories written on large index cards. The first thing we ask everyone to compute is the number of hours they have available for the sprint, starting with number of working days, subtracting out holidays/vacation, and then using a general availability of hours per day of productivity. We’ve tended to use 6 hours per day per developer, although not everyone uses that rate, particularly tech leads and team members doing double-duty as scrum masters.Scrum thoughts: cross-functional teams
Series [ Scrum Thoughts ] Tags [ cross-functional, teams, Scrum ]
For a little while we experimented with truly cross-functional teams, where we had copywriters, graphic designers, UX architects, frontend developers, backend developers, and QA folks all on the same team. I thought this was great, and our planning meeting was very interactive, as everyone had things to work on for new features. There was constant collaboration throughout the sprint: design/frontend, frontend/backend, product owner/QA/UX, etc. As a developer, this was great. We had instant access to team members from the other disciplines, able to brainstorm about how a feature should work and getting questions answered quickly.