Background: Whether encountered in predictive project plans to keep up with rapid change? We could not deliver the product or project to the customer? After delivery due to different customer needs envisaged, leading to frequent changes, team morale, customer confidence overruns!
As a project manager, product manager, technical director of you and I encounter this situation kind of feeling impotent?
Agile appearance, so we see a ray of hope. Agile is a concept or an ideal, is what you and I in the project pursued an ideal environment, is not it?
Now, we chat agility.
In the distant past, the software's pioneers, using waterfall or predictive project management, in the development process, spend a lot of time and effort in collecting information and identifying needs early, and then go to develop, and in the development process not delivered or delivered any small amount of milestone, suffering software delivery day of the team's start.
Finally pioneers in the feedback experienced many "I did not want it", "$ @ #% $", "What is this rubbish, completely wrong, we do not accept," and the like, pioneers that "if there is a new way of programming? based on this way for the progress of software development, quality, customer satisfaction and better! liberation agricultural roots in software development, code, let everyone have more time to do the things they want. "
So in the case in February 2001, the sky snow, a group of pioneers paddled snow, with the exchange. The final "Agile Manifesto" turned an accident.
"Individual and interactive than processes and tools."
"Work / available software than comprehensive documentation"
"Customer collaboration is higher than the contract / business negotiation"
"Responding to Change / change than comply with the specifications / plans."
It can be summarized as follows:
1. People-oriented: respect for each individual, emphasis on cooperation and interaction between individuals
2. Objectives / delivery of the final result is not oriented, final delivery is the software that can be used (and believe me, the available software is the best way to block the customer mouth. Document ...... not waste A4 paper? No waste of disk storage space?)
3. Customer first: understand customer needs, in cooperation with the customer (the balance must always balance, favor the development will cause a lot of customers do not understand the logic operation, tend to customers: we have eaten loss, do not go into details, I write to you, not help a touch of tears, I was too hard.)
4. Embrace change: based on Article III, it is the changing needs of customers, the clear they want, so R & D team to embrace change. (Do not into a dead end, some people argue "whiter than white, black colorful" These stem not discuss)
文档还是需要滴，毕竟可用的软件+规范的文档，会让客户对我们更信任，只是我们应该更关注人、产品模型、写作和迭代。只有随时有成品（原型、功能）交付给客户/项目委员会，才能更好的让项目进行下去，才会将编码工作更好的最大利益化。
讲到这里，笔者不禁要说上几句废话“时间、质量、成本、上级满意度、客户满意度”IE思想不仅仅适用于工厂，同样适用于软件行业，这几条决定我们是否能更好的实现“理想的生活、生活的理想”.......别告诉我，你做软件是为了兴趣等空话，至少笔者目前的觉悟无法达到这种高度。
敏捷原则：
1.我们最重要的目标，是通过持续不断地及早交付有价值的软件是客户满意。
根据GTD四象试图，“紧急的但不重要的、紧急但重要的、重要但不紧急的、不重要不紧急的”这种方式，管理生活、工作，发现会很有用，至少对我来说，收获不错。敏捷中采用迭代事项按照优先级安排、限制WIP、看板、故事卡等方式，为客户尽早提供有价值的功能。同过频繁的刺探和客户的反馈来及时调整研发方向，提高程序的质量，建立客户满意度及客户利益最大化。
敏捷小组关注完成和交付有价值的功能，而不是鼓励的任务。基于“作为【用户类型\需求】，我们希望可以【专业技能/能力】以便实现【业务价值】”的故事方式来分析挖掘需求，原型和文档也会需要编写，也是一种交付，只是更多的工作重点，转到口头交流、看板、迭代工具、每日批斗会（手抖，打错了，每日站会。国内大部分都是批斗会，别问我怎么知道的.....）。
2.即使在研发后期，也欢迎更改需求。敏捷过程利用变化来为客户创造竞争价值。
敏捷者不怕变化，只有通过更改需求，才让我们更好的理解市场，成为独角兽，抢占市场份额。（企业做好了，参与者自然....当一天和尚撞一天钟这种想法地人，实际上在蹉跎光阴，趁早改行，不接受任何反驳。）
3.经常性的交付可以工作的软件，交付周期可以从几周到几个月，交付的时间越短间隔越好。
不予玉璞示人，不适合软件研发行业。加入这个行业，就是加入高度不确定性的工作。迭代是受实践框架限制的，意味着要放弃一些我们认为很有创意的功能也必须按时结束迭代。只要我们可以保证交付的软件会很好的工作，那么交付时间间隔越短，我们和客户的协助、信任度、回头度就会大幅上升，产品质量和市场实用性就会更有益。
“需求、分析、迭代、实施、交付”在敏捷的每个迭代周期都会上演，而不是像预测型的项目，只做一次。
4.在整个项目开发周期，业务人员和开发人员必须天天在一起工作。
软件不可能会依照之前设定的计划原路执行，中间对业务的理解、软件的解决方案肯定会存在偏差，所以客户、需求人员、开发人员以及涉众之间必须进行有意义、频发的交互，这样在早期就可以及时的发现并解决问题。
笔者经历的项目，一般会和客户组件项目委员会，参与者有：业务、对方负责人、实际使用人等组成。避免出现负责人不是使用人，使用人不是负责人这种现象，别问什么。
只有通过不断的刺探、不断的交付、在一起工作，双方理解中的差异会越来越小，软件质量会越来越高，团队士气会越来越好。
5.围绕被激励的个人来构建项目。给他们提供所需要的环境和支持，并信任他们能够完成工作。
看到这里，请大伙回答一个问题“团队里面什么最重要？”答案是：“人”。
SO，码畜、码农都是研发人员自嘲的，企业、客户、团队负责人别真把研发人员当成.....。一群人，一件事，一定赢，要激励、善于消除影响团队士气的因素，个人目标要和团队目标一致，团队也要兼顾个人目标，做到互惠互利，任何偏差都会引起风暴效应。信任、授权、平等的地位、良好的办公环境会提高生产力！
不以人为本，以人民币为本的时代已经过去了，身处信息时代、流动的时代要想办法留住该留的人、淘汰该淘汰的人、沉淀该沉淀文化氛围，才能把利益最大化.....扯远了，回归主题。
6.在团队内部，最具有效果并且富有效率的传递信息的方法，及时面对面的交谈。
笔者每周往返于分部和总部进行沟通，原本一周可以完成的跌打，硬生生拖到两周以上。效率太低了。好在最近要进行集中办公。
说到集中办公，敏捷提倡9人左右的团队集中办公，面对面的交流，效率从经济学角度来说，是相当有回报的。
7.工作的软件是首要进度度量的标准。
用户是否可以使用、用户满意度如何，是首位。笔者在一个长达8年的电商平台项目中，团队贯彻的理念，始终是“功能可用、用户体验度友好”为首要衡量标准。
我见过，也带过前端、后端、DB的小伙伴，我发现有两个极端：1.只管做，不注重结果/质量。2.保质保量。最终给产品带来的市场反馈是完全两个样子。没有测试通过，写在多行代码，在怎么厉害的算法都是无用。质量始终是首位！
8.敏捷过程提倡可持续的开发速度。责任人、开发、用户应该能够保持一个长期的、恒定的开发速度。
什么是可持续性的开发速度？要理解持续这两个字，国内流行风气”996“、加加班辛苦一下、突击一下等等这种观念。
”昨天为什么你不加班，其他同事都加班了“
”咳，老板，加班会影响我心情、影响我心情会影响我的效率“。
不仅让我想到，曾遇到过的一位小伙和BOSS的对话，最终结果，小伙跳槽，薪水客观。老板目前苦苦支撑。
一个项目指望加班、不切实际拍脑袋决定工期，其质量、可用性、团队士气都会大大折扣。笔者提倡”计划-执行-反馈“，日日请，事事清这种工作氛围，才是可持续性、健康的氛围。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
GITHUB、开源项目、敏捷方法等有很多好的技术实践，可以增强产品的敏捷能力和健壮性。很多的原则、模式和实践也可以增强敏捷开发能力。
”实践是检验真理的唯一方法“、”要想知道梨子的味道，你必须咬一口“，多么真挚的感悟。
10.简介文本....极力减少不必要的工作量的艺术。
后期的需求如何变化，我们不得而知。所以不可能一开始就构建一个完美的架构来适应以后的所有变化，事实上也不可能做到。笔者经常给组员灌输“一个中等的实现方法需要30分钟，一个优等的实现方法需要3个小时，那么，要毫不犹疑的选择前者。”
Have seen a guy so they could not deliver the task, asked in detail about that, "I consider the impact of the module on the last module," this practice can not be said to be wrong. But, you ask, the moment the module can not be delivered, it is necessary to consider the impact of this work on later iterations of the way.
Win in the moment, that question is very simple if tomorrow, tomorrow can be solved, SO, it's left up tomorrow. If tomorrow's issues are complex, we also asked them to tomorrow to complete the task today.
11. The best architectures, requirements, design an ad hoc team.
I had an idea "after a day at work, team members ask each other if need assistance, spontaneous processing tasks, flat management mode, no hierarchy," after thinking very fine fear, prone to a crisis of confidence, none of the differences decision-making, no one is responsible for the results.
Although the group as a whole based on agile teams work, but also need some people to assume the role of certain tasks; Product Owner, Architect, UI designers, programmers, demand, testers, documentation writers, etc., also need to a team facilitator, project manager, SCRUM supervisor, project team and other team leaders or agile coach. But so many roles, should always pay attention to servant leadership rather than high above the masses.
12. Each certain time, the team will reflect on how to work more efficiently, and then make the appropriate changes in their behavior.
Many negative factors will always lead to failure of the scheme, such as the members of attrition, the effect of technology applications, user needs change and so will the impact on us will force us to make the appropriate changes.
Agility is not a work based on predefined patterns, it is based on empirical way, the above changes, the constant need to group together "reflection" to adjust to keep the team's agility.
Agile practices commonly used methods are: Scrum, XP Extreme Programming, Crystal, DSDM Dynamic Systems Development, FDD function-driven development, BDD, AUP Agile Unified Process, Lean (IE), billboards, OpenUp, etc., with a quick look at what you species?