Friday, September 26, 2008
I few hours ago, I posted an idea to Google's project 10^100.
It's a simple idea but I think it's hard to turn to reality:
1. build a web community
2. people can come to this community and write down what they like and what's their style.
3. Match via following ways
a. System match the people together via their style and their preferences.
b. People can write down their style and where they will show up in which day
4. System can give them some symbols to those people who might meet together(in the subway or shopping mall, etc)
5. People takes photos or leave messages for their meets.
Source of idea: more and more people feel alone in the modern cities, we found a way for them to meet similar people and make friends each other, or each just for funs.
100 cars will meet together in a weekend 3 PM at Wangfujing Street, and they wear the same color clothes or wear same brand hats.
Give people a chance to know you, give people a chance to talk to new face friends. And then keep in touch in a community.
I think this will solve many social or mentality problems of people.
Hope project 1-^100 can find more funny ideas from people.
Monday, September 22, 2008
This is the similar question with my last post.
What if we didn't have all "accessibility, usability and availability, etc" requirements?
Using prototypes to demostrate your design is okay, but it may need more involvement of user.
It's easy to demo or create a new page, but it's hard to define the BEST.
80/20 policy is used here. And we need user's agreement on the requirements defined.
This is the key.
In Chris Sims' post, he summarized the experiences of David Starr of dealing with unfinished Stories.
One way to track progress is to give 80% of the point value of the story to the team for the current sprint. At first blush, this approach seems to accurately reflect the state of things, and may help keep the team's recorded velocity from varying up and down, sprint to sprint. It also has a certain amount 'feel good' value for the team. However, this approach has significant risk. The story is not verifiably done and the amount of time and effort that will be needed to get to 'done' isn't really known.
A second possibility is to split the story into smaller stories and take credit for the ones that can be considered done. To the extent that some of the smaller stories are truly 'done', this can reduce the risk associated with the 'partial credit' approach. It also allows the product owner to make some decisions about the relative importance of the unfinished stories.
In our projects, we seldom met the same issue. Most of the time, we can finish the stories on time, but sometimes we will also find that we were getting trouble on a certain user story. Most of the time, the issue is, the user story is developed, but it's not the same as expected of user. It's a common issue that user doesn't really aware of what they need. But in a formal development team, we must count our efforts so that we can really know our TRUE velocity in a certain cycle. In this case, usually we will adopt the second approach of David. We will split the user story into smaller user stories, and keep higher priority for unfinished user story in the next iteration.
But here comes my question, if the user story is finished, but we found it's not perfect enough for user, what should we do?
To satisfy user is one of the most important thing we should be aware of in an agile project. But most of the time, user only say "I need something but I don't know what it exactly looks like, I need your help". You can not exactly define what's the final quality requirement of user. So, you will get the feedback like "Yes, it works, but I think there are something we can improve, but I don't know where they are...".
How you deal with this in your experiences?
Friday, September 19, 2008