You are currently browsing the category archive for the ‘software development’ category.
IT people is often scared when I say that I don’t like the traditional testing phase in IT projects.
I understand, it’s so relaxing to know that you have a bunch of people to blame when projects go the wrong way: “we did 3 month of testing, we really couldn’t do more to save this project!”.
And if it’s not the testing team, you can always blame the requirements team for gathering them badly. But this is another story, another post :). Let’s get back to testing.
What I generally don’t like about testing is that you do some operations based on … what the system is designed to do. Someone writes a requirement, someone (else) writes one or more test cases to prove it, someone (else) writes some code and finally someone (else) reads the test case and uses the system giving his interpretation of the behavior … giving a GO/NO GO.
Should I explain why I feel uncomfortable? I hope not but let me add an unobvious thing: where is reality in this long chain? Who’s in charge of saying if the system is doing what is needed and not what someone (else) thinks it should be doing?
Scary, isn’t it?
Back in 2001, traditional management had the idea that if everything was documented, things would work out fine.
Three reasons to read this article:
- because in 2012 90% of management DO have the idea that full documentation means “it will work fine“
- because it’s an interesting article about agility and beyond (adding some lean startup concepts too)
- because most of the stuff that you read comes from Kent Beck and you should read everything from Kent. PERIOD.
Tell us what you think
Every time I hear of a big IT projects, with a big RFP, with a big upfront multi-months/years analysis … I think of what happened to my friend Gianmarco some years ago.
When a SW project finish, a Project Manager is a happy, a company can send the bill and … the team moves to another project leaving the code to the lucky maintenance team.
Is the project team deeply motivated to build a product who can last for long? Is the maintenance team skilled (and willing and has the right incentive) to make the system working better and better?
Here is a possible recipe:
Form long-lived teams around applications/products, or sets of features. A team works from a prioritised backlog of work that contains a mix of larger initiatives, minor enhancements, or BAU-style bug fixes and maintenance. Second-level support should be handled by people in the product team. Everyone in the team should work with common process and a clear understanding of technical design and business vision.
What do you think?
I’ve collected some resources about “UX and friends” and I want to share them with you. I hope they can inspire or be helpful!
Usability Design Considerations for Web Forms
The Death of the Wireframe? Towards An Integrated Approach to UX Design
The New Google+ Is More Beautiful Than Facebook
I’ve this tweet in my ‘favorites tweets’ list and I love to read once in a while:
What do you think?
software design problems have a few great answers, many flat out wrong ones, and lots of ways to improve any actual situation – K. Beck
“create a low-fi prototype at the first responsible moment, create the hi-fi product at the last responsible moment” @aslamkhn