This can helps when there is lot of roles and when they are very complex.
The more roles you have, the more complex it is to satisfy all of them. They have different needs, values, power, etc. Having the picture sounds a bit trivial, but it really helps too.
The reason for using personas is for the team to get a better understanding of the story. It makes it easier for the team (programmers...) to relate to the story on a more personal/emotional level, which I think is good.
If your team has a habit of shipping stories that are not what the customer wanted, then by all means, try the persona approach and see how it works out for you.
Personas can be useful also to make communication between development team and business more clear. When you speak more in non-technical terms business might understand you more clearly.
Instead of the description
The application administrator will maintain the db structure and the application code
you will use persona Frank:
Frank is responsible for technical issues of our application. He understands the database. He does not teach the users how to work with the application but in case of any problems he can solve them.
I still am not sure whether to describe personas with real emotions, e.g. "Frank is not very happy to help the users all the time so the users should not disturb him often".
I can remember reading a Boston Consulting Group white paper on personas in the growing latin american middle class. While interesting, I thought their level of scrutiny was wholly unnecessary. Personally I think personas are a waste of time and should be viewed as an ancillary tool, and not a priority objective. I remember spending a week constructing personas for a social network for entrepreneurs. Big waste! I think it is better to discover your company or website mission. A company mission can help you rationalize how to best service your users, irrespective of their particular personalities. Think Facebook, "We want to allow users to share and connect with their friends " or Foursquare " We are the social utility that connects users to their cities."
"Petr likes to drink lots of beer. Petr only uses his computer when he is drunk. Petr's requirements depend on his blood alcohol level. Petr likes to program his computer. His best code is written after 12 litres of Pilsner, and he doesn't write code unless he has consumed at least 6 litres of Pilsner. "
What producing Personas does is help the analysts really understand what they are writing about. It helps you discover requirements you would normally overlook.
发布评论
评论（5）
当角色很多且非常复杂时，这会很有帮助。
您扮演的角色越多，满足所有这些角色就越复杂。他们有不同的需求、价值观、权力等。拥有图片听起来有点微不足道，但它确实也有帮助。
查看 Jeff Patton 关于该主题的精彩视频：http:// www.infoq.com/presentations/pragmatic-personas
他的网站：http://www.agileproductdesign.com/
This can helps when there is lot of roles and when they are very complex.
The more roles you have, the more complex it is to satisfy all of them. They have different needs, values, power, etc. Having the picture sounds a bit trivial, but it really helps too.
Check this really nice video from Jeff Patton on the subject: http://www.infoq.com/presentations/pragmatic-personas
His website: http://www.agileproductdesign.com/
使用角色的原因是为了让团队更好地理解故事。它使团队（程序员......）更容易在更个人/情感的层面上与故事联系起来，我认为这很好。
如果您的团队习惯于发布客户不想要的故事，那么请务必尝试角色方法，看看它对您有何效果。
像往常一样检查和调整。
The reason for using personas is for the team to get a better understanding of the story. It makes it easier for the team (programmers...) to relate to the story on a more personal/emotional level, which I think is good.
If your team has a habit of shipping stories that are not what the customer wanted, then by all means, try the persona approach and see how it works out for you.
Inspect and adapt, as usual.
角色对于使开发团队和业务之间的沟通更加清晰也很有用。当您更多地使用非技术术语时，企业可能会更清楚地理解您。
而不是描述
应用程序管理员将维护数据库结构和您将使用角色 Frank 的
我仍然不确定是否用真实的情感来描述角色，例如“Frank不太乐意一直帮助用户，所以用户不要经常打扰他”。
Personas can be useful also to make communication between development team and business more clear. When you speak more in non-technical terms business might understand you more clearly.
Instead of the description
you will use persona Frank:
I still am not sure whether to describe personas with real emotions, e.g. "Frank is not very happy to help the users all the time so the users should not disturb him often".
我记得读过波士顿咨询集团关于不断壮大的拉丁美洲中产阶级角色的白皮书。虽然很有趣，但我认为他们的审查程度完全没有必要。我个人认为角色是浪费时间，应该被视为辅助工具，而不是优先目标。我记得花了一周的时间为企业家的社交网络构建角色。大浪费！我认为最好发现您的公司或网站的使命。公司使命可以帮助您合理化如何为用户提供最佳服务，无论他们的特殊个性如何。想想 Facebook，“我们希望允许用户与他们的朋友分享和联系”或 Foursquare，“我们是将用户与他们的城市连接起来的社交实用程序。”
I can remember reading a Boston Consulting Group white paper on personas in the growing latin american middle class. While interesting, I thought their level of scrutiny was wholly unnecessary. Personally I think personas are a waste of time and should be viewed as an ancillary tool, and not a priority objective. I remember spending a week constructing personas for a social network for entrepreneurs. Big waste! I think it is better to discover your company or website mission. A company mission can help you rationalize how to best service your users, irrespective of their particular personalities. Think Facebook, "We want to allow users to share and connect with their friends " or Foursquare " We are the social utility that connects users to their cities."
另一方面，你可以拥有角色“Petr”。
“Petr 喜欢喝大量啤酒。Petr 只在喝醉时才使用电脑。Petr 的要求取决于他血液中的酒精含量。Petr 喜欢对电脑进行编程。他最好的代码是在喝完 12 升比尔森啤酒后编写的，而他不这样做。”除非他喝了至少 6 升比尔森啤酒，否则他不会写代码。”
制作角色的作用是帮助分析师真正理解他们所写的内容。它可以帮助您发现您通常会忽略的需求。
On the other hand, you could have Persona "Petr".
"Petr likes to drink lots of beer. Petr only uses his computer when he is drunk. Petr's requirements depend on his blood alcohol level. Petr likes to program his computer. His best code is written after 12 litres of Pilsner, and he doesn't write code unless he has consumed at least 6 litres of Pilsner. "
What producing Personas does is help the analysts really understand what they are writing about. It helps you discover requirements you would normally overlook.