Agile is really a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. It's hard to do by yourself.
That said, there are things you can do that will make you more agile, and that your teammates may choose to emulate once they see the advantages:
Work in small pieces. You want to break your tasks down into pieces that can be completed in a reasonable amount of time. (The teams I've worked on usually measured things in half-day units. Thus you could complete 2 units of work a day, and 10 units in a week.)
Commit functioning code. When you're working, you want to commit your code frequently, but only when the code compiles, and works without breaking your unit tests. You do not want to be the person who commits code that breaks a build.
Write Unit Tests. Your team IS writing unit tests for its code, right? If not, then start now. Writing unit tests will force you to structure your code to be testable, which will also force you to improve your implementation and design. It will also detect regression errors, by checking everything that used to work when someone makes a change.
Unit Tests for all bugs. Any time you need to fix a bug, first write a unit test that causes your code to fail in the same manner as the bug. Then fix your code. If the fix is good, your unit test should now pass -- and all of the rest of your unit tests should continue to pass.
Unit Tests for all new code. When you're building new code, you should be building to a spec. One of the best ways to ensure that the spec is good, is to use the spec to write unit tests for your code. Once you've got enough tests to validate the code you intend to write, go to work, testing your code against your tests. Once your code passes the tests, you can commit to the team repository.
Use Continuous Integration. This is something that the team itself should be doing, but if you can get the use of an extra PC (it doesn't have to be fast, just have enough memory and disk space to build your tools and build your software). Load CruiseControl.net or Hudson on it, point it at your repository, and configure it to wait for new commits, checkout your workspace, build your software, and run your unit tests. Why? Because it will catch when someone has neglected to commit all of the pieces of their change, before the change propagates to the whole team.
Automate your builds. Before you can use Continuous Integration you need to be able to build your software repeatedly without human intervention. If you're using Visual Studio, learn how to build using MSBuild or Nant. If you're doing Java, learn how to build with Ant or Maven. By building automatically, you avoid build and release problems associated with manual steps. (I once reduced the build process for a project from a notebook that took 2 professionals a week to complete, to a set of scripts that would take about an hour to run -- you better believe that improved the quality of releases.)
我认为最大的变化将是停止在“项目”范围内思考，并开始以非常小的工作增量进行思考。例如，当项目“创建网站 X”出现时，您需要逐页分解该项目。确定需要做什么，我们到底如何获取、存储、更新、显示数据。编写执行此操作所需的不同代码需要多长时间？一旦安排好（根据我的经验，敏捷涉及更多的计划），然后你可以开始说“到星期三，我将能够向你们展示我可以在第 X 页上保存，并且我将显示Y 页上的数据”。
That sounds like waterfall with daily meetings. Implementing agile is quite a vast difference and you can't just change from waterfall to agile yourself, you need others to follow suit for it to work.
I think the largest change will be to stop thinking in "project" scope, and start thinking in very small increments of work. For example, when the project "Create website X" comes up, you'll need to break that down on a page by page basis. Determine what needs to be done, how exactly are we fetching, storing, updating, displaying the data. How long will it take to write the different pieces of code required to do that? Once that is laid out (there is much more planning involved in agile, from my experience) then you can start saying "By Wednesday, I'll be able to show you guys that I can save on page X and I'll display the data on page Y".
Usually there is a "planning" meeting. This can take an hour or it can take 6, this depends on how well your criteria is conveyed, how many members are on the team, and how long of a sprint you're working with. Everyone selects work that they will do, and puts estimates on it. After your sprint (which most people recommend to be one or two weeks) there is another meeting. Ideally in this meeting everyone will demo what they have been doing the past week(s), and it will work perfectly. Afterward there is some reflection, what worked well? Did we mis-estimate something terribly?
That is one "cycle", do that ~50 times and website X is complete! :)
To start with, there is no such thing like "the agile methodology", agile is an umbrella term that describes several agile methodologies and if all your workplace is doing is standups, I can already tell you that this doesn't make a workplace agile.
Second, while you can adopt some "agile practices" (especially engineering practices) at an individual level, this will never be enough to make you agile: 1. agile is in my opinion more about the way to drive product development than engineering practices 2. agile is a collective team game.
So, my recommendation would be to dive into for example Scrum and XP from the Trenches and to grab some copies for your coworkers, your boss or potential sponsors.
Congratulations on doing stand-ups. It's a good first change.
That you're asking suggests that you or the team would like to be better at this. In that case, you can go one of two ways:
Huge change, or
Incremental improvement
If you decide you'd like a huge change, you'll probably need some books, training and maybe a coach or experienced practitioner around. This is often successful if people higher up in the organisation are invested in the change too.
If you decide you'd like to improve incrementally, it's worth reading around Agile just to get some ideas. I recommend "XP Explained". There are a lot of blogs out there, too, as well as posts here. The two things you'll need to do are:
Try to deliver some software, or at least get feedback from the stakeholders
Work out why that was hard and what you can do to make it easier.
We normally do the first with showcases and the second with retrospectives. I recommend having retrospectives at least every two weeks, even if it's really hard to showcase working code.
Things I often see flagged up quickly as problems include:
Team not co-located ("Team" includes BAs and QAs)
Environment not suited
Lack of visibility of work in progress or overall goals
Too much work in progress - things started but not finished
Projects in progress that nobody really cares about
Project progress makes it obvious that it's not worth doing
Codebase is really hard to change
Blame culture discourages collaboration.
Whatever you find out, you won't be the first.
Note that Agile is a transparent methodology, whichever version you use. A lot of people get scared by transparency. This is normal. Sometimes managers higher up have a vested interest in not allowing things to be transparent. This is also common, and at that point you might need external help. Delivering working software can be very persuasive, though.
If you want do to this from the ground up, then all you need is the agile manifesto and recurring retrospectives each week. But I guess that is not enough, so here is my start-up-list:
Convert your existing project tasks/points/todos into User Stories
Pair program on everything. Switch pairs often!
Use Test Driven Development. Strive for 100% coverage!
Use one week iterations. Repetition is learning!
Deliver valuable software to the customer in each iteration.
Even if entire team doesn't work in an agile way there are few practices that you can adopt as Developer. You can begin with CI, TDD, automated deploy. As a team you can try out retrospective session.
发布评论
评论（6）
敏捷实际上是一组基于迭代开发的软件开发方法，其中需求和解决方案通过迭代不断发展自组织跨职能团队之间的协作。自己很难做到。
也就是说，您可以做一些事情来让自己更加敏捷，并且您的队友在看到这些优势后可能会选择效仿：
Agile is really a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. It's hard to do by yourself.
That said, there are things you can do that will make you more agile, and that your teammates may choose to emulate once they see the advantages:
这听起来就像每日会议的瀑布。实施敏捷是一个巨大的差异，你不能自己从瀑布式转变为敏捷，你需要其他人效仿才能使其发挥作用。
我认为最大的变化将是停止在“项目”范围内思考，并开始以非常小的工作增量进行思考。例如，当项目“创建网站 X”出现时，您需要逐页分解该项目。确定需要做什么，我们到底如何获取、存储、更新、显示数据。编写执行此操作所需的不同代码需要多长时间？一旦安排好（根据我的经验，敏捷涉及更多的计划），然后你可以开始说“到星期三，我将能够向你们展示我可以在第 X 页上保存，并且我将显示Y 页上的数据”。
通常有一个“计划”会议。这可能需要一个小时，也可能需要 6 个小时，这取决于您的标准传达得如何、团队中有多少成员以及您正在处理的冲刺时间有多长。每个人都选择他们将要做的工作，并对其进行估计。在冲刺（大多数人建议一到两周）之后，还有另一次会议。理想情况下，在这次会议中，每个人都将演示他们过去几周所做的事情，并且它将完美地发挥作用。后来反思一下，什么效果好？我们是否严重错误地估计了某些事情？
这是一个“循环”，重复大约 50 次，网站 X 就完成了！ :)
That sounds like waterfall with daily meetings. Implementing agile is quite a vast difference and you can't just change from waterfall to agile yourself, you need others to follow suit for it to work.
I think the largest change will be to stop thinking in "project" scope, and start thinking in very small increments of work. For example, when the project "Create website X" comes up, you'll need to break that down on a page by page basis. Determine what needs to be done, how exactly are we fetching, storing, updating, displaying the data. How long will it take to write the different pieces of code required to do that? Once that is laid out (there is much more planning involved in agile, from my experience) then you can start saying "By Wednesday, I'll be able to show you guys that I can save on page X and I'll display the data on page Y".
Usually there is a "planning" meeting. This can take an hour or it can take 6, this depends on how well your criteria is conveyed, how many members are on the team, and how long of a sprint you're working with. Everyone selects work that they will do, and puts estimates on it. After your sprint (which most people recommend to be one or two weeks) there is another meeting. Ideally in this meeting everyone will demo what they have been doing the past week(s), and it will work perfectly. Afterward there is some reflection, what worked well? Did we mis-estimate something terribly?
That is one "cycle", do that ~50 times and website X is complete! :)
首先，不存在“敏捷方法论”之类的东西，敏捷是一个涵盖性术语，描述了几种敏捷方法论，如果您的工作场所所做的只是站立会议，我已经可以告诉你，这并不能让工作场所变得敏捷。
其次，虽然您可以在个人层面采用一些“敏捷实践”（尤其是工程实践），但这永远不足以让您变得敏捷： 1. 在我看来，敏捷更多的是关于驱动产品开发的方式，而不是工程实践 2敏捷是一种集体团队游戏。
因此，我的建议是深入研究 Scrum 和 XP from the Trenches 并抓住给你的同事、老板或潜在赞助商一些副本。
To start with, there is no such thing like "the agile methodology", agile is an umbrella term that describes several agile methodologies and if all your workplace is doing is standups, I can already tell you that this doesn't make a workplace agile.
Second, while you can adopt some "agile practices" (especially engineering practices) at an individual level, this will never be enough to make you agile: 1. agile is in my opinion more about the way to drive product development than engineering practices 2. agile is a collective team game.
So, my recommendation would be to dive into for example Scrum and XP from the Trenches and to grab some copies for your coworkers, your boss or potential sponsors.
恭喜你完成了站立表演。这是一个很好的第一个改变。
您所问的问题表明您或团队希望在这方面做得更好。在这种情况下，你可以采取以下两种方式之一：
如果你决定你想要一个巨大的改变，你可能需要一些书籍、培训，也许还需要一个教练或经验丰富的从业者。如果组织中的高层人员也投资于变革，那么这通常会成功。
如果您决定要逐步改进，那么值得阅读有关敏捷的内容，以获得一些想法。我推荐《XP 解释》。那里也有很多博客，以及这里的帖子。您需要做的两件事是：
我们通常会进行第一次展示，第二次进行回顾。我建议至少每两周进行一次回顾，即使很难展示工作代码。
我经常看到的事情很快就会被标记为问题，包括：
无论你发现什么，你都不会是第一个。
请注意，无论您使用哪个版本，敏捷都是一种透明的方法。很多人对透明度感到害怕。这是正常的。有时，高层管理者出于既得利益而不愿意让事情变得透明。这也很常见，此时您可能需要外部帮助。不过，提供可用的软件可能非常有说服力。
祝你好运！
Congratulations on doing stand-ups. It's a good first change.
That you're asking suggests that you or the team would like to be better at this. In that case, you can go one of two ways:
If you decide you'd like a huge change, you'll probably need some books, training and maybe a coach or experienced practitioner around. This is often successful if people higher up in the organisation are invested in the change too.
If you decide you'd like to improve incrementally, it's worth reading around Agile just to get some ideas. I recommend "XP Explained". There are a lot of blogs out there, too, as well as posts here. The two things you'll need to do are:
We normally do the first with showcases and the second with retrospectives. I recommend having retrospectives at least every two weeks, even if it's really hard to showcase working code.
Things I often see flagged up quickly as problems include:
Whatever you find out, you won't be the first.
Note that Agile is a transparent methodology, whichever version you use. A lot of people get scared by transparency. This is normal. Sometimes managers higher up have a vested interest in not allowing things to be transparent. This is also common, and at that point you might need external help. Delivering working software can be very persuasive, though.
Good luck!
如果您想从头开始做到这一点，那么您所需要的只是敏捷宣言和每周定期回顾。但我想这还不够，所以这是我的启动列表：
If you want do to this from the ground up, then all you need is the agile manifesto and recurring retrospectives each week. But I guess that is not enough, so here is my start-up-list:
即使整个团队没有以敏捷的方式工作，作为开发人员可以采用的实践也很少。您可以从 CI、TDD、自动化部署开始。作为一个团队，你可以尝试回顾会议。
Even if entire team doesn't work in an agile way there are few practices that you can adopt as Developer. You can begin with CI, TDD, automated deploy. As a team you can try out retrospective session.