Tag: outside-in
Saturday, 26 September 2009
Outside, in
Posted by Simon Baker
We create software by working inwards from the user experience. Maintaining focus on the users' perception of the system, we do just enough to satisfy the needs of the user rather than what we think is necessary or cool. On a regular basis, we come up for air to check context and avoid getting lost in the weeds. We decide which direction to go next based on where our client sees value and consider how we're going to demonstrate what we've created so far. We don't jump into unit land because trying to connect all the pieces at the end doesn't produce a good solution.
Comments: 1
Wednesday, 2 September 2009
We don't need no stinkin' process
Posted by Simon Baker
We're enjoying ourselves so much I'm wondering if it's illegal. We're working in a 4-man team with a new client (who consult for the Lean Enterprise Academy) and we're experimenting with some new techniques. Our goal is to create a product that is very kind to its users, so we're trying to stay as close as possible to the users' conceptual model and stop thinking like programmers all the bloody time. When we catch one another 'flipping' to techie mode we quickly 'flop' them back to user mode.
Read more...
Sunday, 4 May 2008
Testers in our agile team
Posted by Simon Baker
In our team, developers create the vast majority of the automated tests, whether they are acceptance tests, integration tests, or unit tests. They do this because they are story test-driven. They develop stories from the outside in, starting with the user interface and are guided by the acceptance criteria. The developers profile their code and create automated performance and load tests as they go because code has to be production-ready at the end of every 1-week iteration. Testers in our team do exploratory testing and they're free to pair-up with anyone, another tester or more likely a developer, to create any automated tests they feel are missing. The testers, however, add value to the team that goes way beyond testing. Working closely with the Product Owner they facilitate connection and collaboration with the customer, helping the team to empathize with users, understand their needs and appreciate value from their perspective. Working with the facilitator they help the team develop a conscience that is focused on the delivery of value and quality, while their continuous interactions within the team keep collaboration high.
Read more...
Comments: 2
Friday, 18 August 2006
Build quality in
Posted by Simon Baker
It's worth being test-driven and working from the outside-in, starting with automated acceptance tests. And it's worth getting done in the iteration, which means performing any supplementary testing, e.g. adhoc testing on a per user-story basis in the iteration. This means that testing responsibilities and skills are an intrinsic part of the team and are colocated.
Read more...