If your team is utilizing agile well, then you probably should see some changes in how you work. It's possible that you already developed with a fairly "agile-compatible" mindset, even if your previous work experience was in a more waterfall-style methodology.
Some specific things that I think agile developers ought to be doing (and in a well-run agile team, will naturally find they need to do)
Focus on incremental, complete changes rather than massive architectures - This is a core tenant of agile from the macro planning side, but it's also important to practice even for an individual developer. With a 2 or 3 week iteration, you'll find you simply don't have the time to spend 1 1/2 weeks developing something, and half a week integrating it all together.
Check in early, check in often, and check in working code - Don't do this, and you'll soon find you're that guy famous for breaking the build with a day left before the iteration ends.
Know what's blocking you, and what is likely to block you in the upcoming week or two, and tell people about it - No one in an agile team likes hearing at the last second that a developer working on a critical piece is held up waiting for something to complete his work.
Think about the end of an iteration throughout the iteration - Every line of code you write should be done with the consideration of whether this is realistic to complete before the iteration is over.
Always Be Crunching (hey, I couldn't have a pithy list of advice without a cute, Glengarry Glen Ross ripped off acronym!) You'll learn by your second or third iteration that slacking off for a week followed by some all nighters is going to bite you in the ass.
If you're already following all these - great! They're certainly general best practices rather than being specific to Agile. I think most developers do have a bad habit or two that this list addresses, though (I know I do on occasion.)
In addition to Ryan's great points here are a couple more.
Discuss your ideas with other members of your team. Your fellow developers will quickly point out potential flaws in your thinking and suggest alternatives (be ready to listen and not get offended). I found this works best during planning/story tasking. In a 2-3 week sprint it is painfully obvious when you go down the wrong path. It might even stop you from successfully finishing all you tasks/stories. If others know your plan of attack up front it makes it easier for them to step in and help you out finishing your work if you need it.
Do not hesitate to suggest new ways of doing things. One of the great things about agile is that team processes are not set in stone but evolve from a series of retrospectives. If you have developers who never speak up, the process never changes and things do not get better.
Put your user's hat on. Every application has an end user. Sometimes (especially when you do not have a close contact with your users) you have to step back and question decisions (even if made by a product owner). If you can make a good case, not only your users but the entire team will benefit from it since the product will be better received. Developers do not do this often enough. We want to make things better, faster and leaner in the expense of other, sometimes more important things like delivering on time or adding more features.
The specifics of agile will be different for every person you ask. Yes, you probably want to communicate regularly, but you don't want to take it to extremes that keep you (or your coworkers) from being productive.
But like I said, it will be different for everybody. The only people who know how best to match your team are the people on your team. Just tell them you aren't used to agile and you were wondering how you've been handling it. They're really the only ones who will be able to say for sure.
1) Good pair programming means making an effort to explain things really well and listening carefully. That's a skill in itself. You have to learn how other people tackle things and be patient when other people tackle things differently from you.
2) Being prepared to be flexible and change your mind. The smaller the ego, the easier and less painful it is to handle this.
3) To do agile well, you need to be communicating continuously with everybody in the wider team (i.e. not just devs - sysadmins, managers, customers, network admins, hardware people...) Part of this is feeling comfortable, safe and confident - i.e. there needs to be real trust in the team, not just phoney trust - real trust
4) Be prepared to work outside your specialism and comfort zone. I often have to pair with graphic designers, system admins and DBAs. Saying "that's not my job" isn't part of agile. We're part of a multidisciplinary team and getting the product released in a useful state is the whole team's problem - not just looking after my pet specialism.
5) Try to keep things simple and minimal - no "we'll make it totally generic" or "we'll need it later". Think "you aren't gonna need it." We're shooting for small, simple, concrete steps informed by feedback.
6) Tackle the difficult things and the things that aren't clear first - so that the you get feedback on the problems as early as possible so you if you have to revise estimates or cancel the work the customer gets informed as soon as possible.
7) Try to keep the team dynamics co-operative rather than competitive. Pitting people against each other pulls the team apart - and it gets you well-polished fragments and a broken product rather than a cohesive whole made by people that give-and-take as they find necessary to be successful.
发布评论
评论（5）
如果您的团队很好地利用了敏捷，那么您可能应该看到工作方式发生一些变化。即使您以前的工作经验是采用瀑布式的方法，您也可能已经以相当“敏捷兼容”的心态进行开发。
我认为敏捷开发人员应该做的一些具体事情（在运行良好的敏捷团队中，他们自然会发现他们需要做）
如果您已经关注所有这些 - 太好了！它们当然是通用的最佳实践，而不是特定于敏捷的。不过，我认为大多数开发人员确实有一两个坏习惯，这个列表解决了这个问题（我知道我有时会这样做。）
If your team is utilizing agile well, then you probably should see some changes in how you work. It's possible that you already developed with a fairly "agile-compatible" mindset, even if your previous work experience was in a more waterfall-style methodology.
Some specific things that I think agile developers ought to be doing (and in a well-run agile team, will naturally find they need to do)
If you're already following all these - great! They're certainly general best practices rather than being specific to Agile. I think most developers do have a bad habit or two that this list addresses, though (I know I do on occasion.)
除了 Ryan 的精彩观点之外，这里还有其他几点。
我希望这有帮助。
In addition to Ryan's great points here are a couple more.
I hope this helps.
对于你问的每个人来说，敏捷的具体细节都会有所不同。是的，您可能希望定期沟通，但您不想走极端，以免影响您（或您的同事）的工作效率。
但就像我说的，每个人的情况都会有所不同。唯一知道如何最好地匹配你的团队的人就是你团队中的人。只要告诉他们你不习惯敏捷并且你想知道你是如何处理它的。他们确实是唯一能够肯定地说的人。
The specifics of agile will be different for every person you ask. Yes, you probably want to communicate regularly, but you don't want to take it to extremes that keep you (or your coworkers) from being productive.
But like I said, it will be different for everybody. The only people who know how best to match your team are the people on your team. Just tell them you aren't used to agile and you were wondering how you've been handling it. They're really the only ones who will be able to say for sure.
简短的回答，但对所有问我这个问题的开发人员都非常有用：
有一本名为《敏捷开发人员实践》的书，http://www.pragprog.com/titles/pad/practices-of-an-agile-developer。
本书将专门回答你的问题。我非常喜欢它，因为它不仅仅是过程，还有行为和心理。
Short answer but was very useful to all developers that asked me that question:
There is a book called Practices of an agile developer,http://www.pragprog.com/titles/pad/practices-of-an-agile-developer.
This book will specifically answer to your question. I like it very much because it's not just about the process, but behaviors and psychology.
与态度相关的事情：
1）良好的结对编程意味着努力很好地解释事情并仔细聆听。这本身就是一种技能。你必须学习其他人如何处理事情，并且当其他人处理事情与你不同时要有耐心。
2) 准备灵活并改变主意。自我越小，处理这个问题就越容易、越不痛苦。
3) 要做好敏捷，您需要与更广泛团队中的每个人持续沟通（即不仅仅是开发人员 - 系统管理员、经理、客户、网络管理员、硬件人员...）感到舒适、安全和自信 - 即需要对团队有真正的信任，而不仅仅是虚假的信任 - 真正的信任
4) 准备好在你的专业和舒适区之外工作。我经常需要与图形设计师、系统管理员和 DBA 合作。说“这不是我的工作”不是敏捷的一部分。我们是多学科团队的一部分，让产品以有用的状态发布是整个团队的问题——而不仅仅是照顾我的宠物专业。
5) 尝试让事情变得简单和最小化 - 不要“我们会让它完全通用”或“我们稍后会需要它”。想想“你不会需要它。”我们致力于小型、简单、根据反馈通知具体步骤。
6) 首先解决困难的事情和不清楚的事情 - 这样您就可以尽早得到问题的反馈，以便您在必须修改估算或取消客户的工作时尽快得到通知。
7) 尝试保持团队活力的合作性而不是竞争性。人们之间的相互竞争会导致团队分裂——它只会让你得到精心打磨的碎片和破碎的产品，而不是由那些认为成功所必需的给予和接受的人们所创造的有凝聚力的整体。
Attitude-related things:
1) Good pair programming means making an effort to explain things really well and listening carefully. That's a skill in itself. You have to learn how other people tackle things and be patient when other people tackle things differently from you.
2) Being prepared to be flexible and change your mind. The smaller the ego, the easier and less painful it is to handle this.
3) To do agile well, you need to be communicating continuously with everybody in the wider team (i.e. not just devs - sysadmins, managers, customers, network admins, hardware people...) Part of this is feeling comfortable, safe and confident - i.e. there needs to be real trust in the team, not just phoney trust - real trust
4) Be prepared to work outside your specialism and comfort zone. I often have to pair with graphic designers, system admins and DBAs. Saying "that's not my job" isn't part of agile. We're part of a multidisciplinary team and getting the product released in a useful state is the whole team's problem - not just looking after my pet specialism.
5) Try to keep things simple and minimal - no "we'll make it totally generic" or "we'll need it later". Think "you aren't gonna need it." We're shooting for small, simple, concrete steps informed by feedback.
6) Tackle the difficult things and the things that aren't clear first - so that the you get feedback on the problems as early as possible so you if you have to revise estimates or cancel the work the customer gets informed as soon as possible.
7) Try to keep the team dynamics co-operative rather than competitive. Pitting people against each other pulls the team apart - and it gets you well-polished fragments and a broken product rather than a cohesive whole made by people that give-and-take as they find necessary to be successful.