Friday, September 26, 2008

Official Google Blog: Project 10^100

Official Google Blog: Project 10^100

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

Ajaxian » What if we didn’t lump all “accessibility” requirements together?

Ajaxian » What if we didn’t lump all “accessibility” requirements together?

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.

InfoQ: How to Handle Unfinished Stories?

InfoQ: How to Handle Unfinished Stories?
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


  1. 第一型
  2. 第二型
  3. 第三型
  4. 第四型
  5. 第五型
  6. 第六型
  7. 第七型
  8. 第八型
  9. 第九型


  • 看重自己的表現和成就。
  • 講究效率。
  • 喜歡競爭,避免失敗。
  • 相信愛情來自你能提供甚麼,而不在於你是誰。
  • 只關注事物積極的方面,不理會消極負面的信息。
  • 重視效率、比賽、贏。
  • 難以瞭解個人的感覺。在工作的時候把感情放到了一邊。
  • 為爭取認可而打造有利形象。公眾形象屬於社會高層人物。
  • 在真正自我和工作角色之間會產生困惑。
  • 通過集合思維的方式集中注意力,通過多渠道來尋找問題的答案。
  • 能夠下意識地調整自我形象,以為調整地形象就是個人的真我。