Courage to start work on small stories with insufficient detail
Courage to talk to customers to elaborate said stories
Courage to constructively critique team members code
Courage to review your mistakes (in public) and learn from them
Courage to release "unfinished but good and shippable" code when it already delivers value.
Courage to stick to the agreed team processes when management has a bright idea
Courage to amend agreed processes in team when a better way is found
Courage to deliver high quality code using test driven development and continuous integration.
...
Note: The unfinished part does not mean "low quality", it means satisfying the customer, cleanly implemented, tested, ship-ready. However falling short of the developers idea of perfection, i.e. spring configuration is a bit clunky, some refactoring can be made, some auto configuration, some speed improvement, some corner cases... I found that some developers take the "user story hostage" and keep it unshippable till it is perfect. If it is good, you should let go, better is for the next sprint.
What should be my first step in Agile programming?
Read the 12 principles of the Agile Manifesto over here. Understand and try to make sense out of each one and implement them as simply as they are stated.
Although agile principles can be adopted individually, it should be adopted on an organisation level or at least project level IMO. Urge your Team and your project to use SDLC methodologies which are more agile like Scrum for e.g. If you adopt Scrum properly you will automatically be agile.
As for Agile programming - Pair program, configure a Continuous Integration and Build system, use Test Driven Development, pay continuous attention to code quality and design best practices by doing Code Reviews, design discussions and have high unit testing code coverage.
Code, test, and deliver the most important thing on the list; resist being interrupted while you're doing that: if someone tries to interrupt, explain that you're busy doing the most important thing, and that because you're concentrating on only doing that one thing it won't take long and they they'll be able ask you to do something else soon (this phase is called the "sprint").
Once you've delivered, ask for the next most important thing to be done, and then do that, etc.
Doing this all by yourself is going to be very difficult. If you take the principles on the agilemanifesto site you'll see that at least 6 of the items deal with groups of people and teams. You're going to need some buy-in from your co-workers and boss.
I'd start with your pair partner. Ask for a turn occasionally. You could try something like so, "lets see if I undersdand this, can I try to add the next feature point."
There are also tonsofbooks that will be very helpful to someone getting started. There's probably someone at your site who would like to mentor you. If you show you're interested in continuing to learn someone would likely be able to help you. Talk to your boss too. If he wants something from you he should be able to at least point you in the direction of someone who could help.
发布评论
评论（6）
关键词是勇气。
勇于评估和讨论您的工作
勇于开始研究细节不足的小故事
勇于与客户交谈以详细阐述所述故事
勇于建设性地批评团队成员的代码
勇于（公开）审查您的错误并从中吸取教训
勇于发布“未完成但良好且可交付的”代码，当它已经交付价值时。
当管理层有一个好主意时，有勇气坚持商定的团队流程
；当找到更好的方法时，有勇气修改团队中商定的流程；
有勇气使用测试驱动开发和持续集成来交付高质量的代码。
...
注意：未完成的部分并不意味着“低质量”，它意味着让客户满意、干净地实施、测试、准备好发货。然而达不到开发者完美的想法，即spring配置有点笨拙，可以进行一些重构，一些自动配置，一些速度改进，一些极端情况......我发现一些开发者拿“用户故事作为人质”并使其无法发货，直到完美为止。如果好的就应该放手，更好的是为了下一个冲刺。
The keyword is Courage.
Courage to estimate and discuss your work
Courage to start work on small stories with insufficient detail
Courage to talk to customers to elaborate said stories
Courage to constructively critique team members code
Courage to review your mistakes (in public) and learn from them
Courage to release "unfinished but good and shippable" code when it already delivers value.
Courage to stick to the agreed team processes when management has a bright idea
Courage to amend agreed processes in team when a better way is found
Courage to deliver high quality code using test driven development and continuous integration.
...
Note: The unfinished part does not mean "low quality", it means satisfying the customer, cleanly implemented, tested, ship-ready. However falling short of the developers idea of perfection, i.e. spring configuration is a bit clunky, some refactoring can be made, some auto configuration, some speed improvement, some corner cases... I found that some developers take the "user story hostage" and keep it unshippable till it is perfect. If it is good, you should let go, better is for the next sprint.
在我的组织中，你所要做的就是声明自己是一名敏捷程序员。神奇的是，对计划和文档的需求消失了。
In my organization, all you have to do is declare yourself to be an Agile Programmer. Magically, the need for planning and documentation disappears.
请在此处阅读敏捷宣言的 12 条原则。理解并尝试理解每一项，并按照它们的说明简单地实施它们。
尽管敏捷原则可以单独采用，但在我看来，它应该在组织级别或至少项目级别采用。敦促您的团队和您的项目使用更敏捷的 SDLC 方法，例如 Scrum，例如，如果您正确采用 Scrum，您将自动变得敏捷。
对于敏捷编程 - 结对编程，配置持续集成和构建系统，使用测试驱动开发，通过代码审查、设计讨论持续关注代码质量和设计最佳实践，并具有较高的单元测试代码覆盖率。< /p>
Read the 12 principles of the Agile Manifesto over here. Understand and try to make sense out of each one and implement them as simply as they are stated.
Although agile principles can be adopted individually, it should be adopted on an organisation level or at least project level IMO. Urge your Team and your project to use SDLC methodologies which are more agile like Scrum for e.g. If you adopt Scrum properly you will automatically be agile.
As for Agile programming - Pair program, configure a Continuous Integration and Build system, use Test Driven Development, pay continuous attention to code quality and design best practices by doing Code Reviews, design discussions and have high unit testing code coverage.
根据我的理解，可以提出敏捷开发过程（正如 ChrisW 和 Peter 已经告诉过的:-)），类似于：
在指定时间内交付的工作应该具有敏捷性/移动/进展。
你需要：
1）自己选择/由老板分配一个有可接受时间段的任务
线。
2) 准备好正确估计要处理的工作的时间并获得
就此达成协议
3) 每天在冲刺/会议中与您的团队进行讨论（仅限：10-15 分钟）
老板/团队并解释你当天的目标/计划。
4）最好的做法是不要偏离你的任务，直到它完成为止。
成功完成，否则可能会扰乱您的时间安排。
5) 在一天结束时，发送工作状态的状态。
6）任务完成后，主动通知老板并接受下一个任务。
6) 更重要的是，你尽量习惯按时间线交付，不要失败。
As per my understanding Agile development process can be put forward ( as already told by ChrisW & Peter :-) ), something like :
There should be agility/movement/progress in the work being delivered in the specified time.
You need to be :
1) Choose yourself/ get allocated by your boss, a task with an accepted period of time
line.
2) Ready with a correct estimation of time for the bit of work to be handled and get
an agreement on that
3) Every day have a discussion in the sprint/meeting(just for : 10-15 min.) with your
boss/team and explain your goals/plans for that day.
4) It will be a best practice to not to get deviated from your bit of task until it is
finished successfully otherwise it can disturb your time lines.
5) At the end-of-the-day, send a status across, of the state of work.
6) Once your task has completed, inform and get your next task pro-actively from your boss.
6) More important is, you try to accustom to the time-line based delivery without fail.
独自完成这一切将会非常困难。如果您遵循agilemanifesto网站上的原则，您会发现至少有6个项目涉及人群和团队。你需要得到同事和老板的支持。
我将从你的搭档开始。偶尔要求转一转。您可以尝试这样的操作，“让我们看看我是否理解这一点，我可以尝试添加下一个特征点吗？”
话虽这么说，甘地有一句很好的名言：“成为你想在世界上看到的改变。”您可以自己采取很多行动来提高游戏水平。编写测试，让持续构建工作，设定可实现的目标有一些过去经验的基础，重构。
还有吨 书籍对初学者非常有帮助。您的网站上可能有人愿意指导您。如果您表现出有兴趣继续学习，有人可能会帮助您。也和你的老板谈谈。如果他想从你这里得到什么，他至少应该能够为你指出可以提供帮助的人。
Doing this all by yourself is going to be very difficult. If you take the principles on the agilemanifesto site you'll see that at least 6 of the items deal with groups of people and teams. You're going to need some buy-in from your co-workers and boss.
I'd start with your pair partner. Ask for a turn occasionally. You could try something like so, "lets see if I undersdand this, can I try to add the next feature point."
That being said, there's a good Ghandi quote, "Be the change you want to see in the world." There are a lot of actions you can take by yourself to raise the level of your game. Writing tests, getting a continuous build working, set achievable goals that have some basis in past experience, refactoring.
There are also tons of books that will be very helpful to someone getting started. There's probably someone at your site who would like to mentor you. If you show you're interested in continuing to learn someone would likely be able to help you. Talk to your boss too. If he wants something from you he should be able to at least point you in the direction of someone who could help.