1。不拼能行么?
2。努力重要,选择更重要。
3.成为为大家服务和解决问题的人。
4.幸福来的就是这样的突然,有时候往往就是在一个人即将绝望的时候。
5.感觉人都快被掏空了,是时候该充充电了
6.江郎才尽。
7.世上充满无数的选择和努力,但对于成功,选择大于努力 。
8.那三年炼狱般的生活,也是我人生的一笔宝贵财富,不过如果上天再给我一次重新选择的机会,我也许不会选择 X 公司
9.千万不要对一切都失去信心,失去信心才是最可怕的
10.我也没有提出特别系统的和有建设性的解决方案,所以管理层也就没有足够的重视吧
11.有的乘火车,有的乘飞机,有的自驾车,还有人甚至要把几乎所有的交通工具都换个遍才能到家。
12.传统的软件开发流程,比如瀑布流程,就像我画的这张图(如图 3-1所示)一样。从需求、设计,到开发、测试和部署,是一环套一环的,结束一个环节才能开始下一个,中间过程很长,且不允许有变更,等到交付的时候才发现已经与客户的目标相差太远了。这时,要想弥补就要付出巨大的代价,很多工作需要重来,从而产生了巨大的浪费。”
13.春节回家,一般情况下,大家都会在出发前制定一个大概的计划,明确你家所在的城市这一最高目标,然后顺应情况不断调整行程计划。14.疲劳驾驶可是要出车祸的。
15.接着,另一位扮演“员工”角色的同事说:“做员工也很没意思,像个机器人,没有自主权,明明知道怎么走却要等命令才能行事。”
16.这个游戏叫‘命令和控制’。首先,我需要两位参与者,其中一位是老板,另外一位是执行者,也就是员工了。老板可以发出 6 个指令,包括走、停、左、右、快、慢,执行者必须服从老板的指令。老板只能发出指令而不能触碰到执行者。你们的目标就是要使执行者在 2 分钟之内走完 60步。当然,我会在你们的行进途中设置很多障碍。
17.第二个游戏叫‘自我导向’。大家听名字就应该明白是怎么回事了,就是你们所有人都是执行者,需要你自己在障碍物之间用 2 分钟走完 60 步。”
18‘老板’总是耽误时间并拖延项目的那个人
20.敏捷方法欢迎并且随时准备应对变化。
21它们注重调动人的积极性、主动性和创造性,并培养人在工作中的自豪感。
22.据统计,很多软件产品的功能中,客户常用的功能只占 20%左右,其他大部分功能是客户很少使用甚至基本不用的。在这种情况下,采用瀑布方式在详细设计阶段所设计出的功能,其实很多是不必要的,这将浪费很多资源。
23.在敏捷方法中,由于没有经理的管理和约束,团队和项目必然是一团糟,仿佛越是上层越有这种想法 。
24.敏捷开发的理念是信任开发团队,信任每一个人。
26.“当然,敏捷开发的团队也需要管理,但这些管理是非命令式的,很多时候是战略指导和服务性质的。
27.你觉得客户对我们产品的质量满意吗?在产品发布之前,有多少测试和开发工程师需要挑灯夜战?在产品发布以后,又有多少技术支持和服务的工程师还在忙着修补漏洞?你觉得你们团队的每个成员都很愉快吗?他们能做到每天高高兴兴按时上班,高高兴兴按时下班吗?每个成员每天都有进步和成长的感觉吗?
28.敏捷开发也不是银弹,不能指望它解决所有的问题。”29“人的思想转变过程是最痛苦的
30.经理应该相当于足球场上的教练,在场外指导,但是真正踢球的是团队
31.中国老百姓过去几千年都习惯被‘奴役’,不过我们可是优秀的70 后、80 后的代表,崇尚自由,有独立的思想,从小就接受过良好的教育,有团队合作的精神,这样你觉得自我管理行不行?”
32.A very good team player,excellent communication skills, open minded, pro-active, and self-motivated.
very good team player很好的团队合作者。敏捷强调团队,如果只是个人能力强而不懂得合作,这样的人
在敏捷团队里就没法混。
communication skills
优秀的沟通能力。这一点的重要性不言而喻,敏捷里最强调的就是沟通,最有效的沟通方式就是面对面的交流。那种只会埋头干活,不会沟通的不要。
minded, pro-active, and self-motivated
敏捷团队成员必须能够敞开思想,随时接受新事物,积极主动,自我激励。
每个成员不仅有优秀的技术能力、优秀的团队协作和沟通能力,还要具备良好的全局观,而且最好能优势互补。
敏捷开发的核心是人,招到合适的人是所有开发环节中最重要的。
33.只要每个人都自觉地遵守规则,就像今天的道路一样,那该多爽啊!
34.XP 注重的核心在于“沟通、简明、反馈和勇气”,用一句话来概括 XP 的这 4 个核心价值观就是:通过充分的交流和沟通,使产品的设计尽可能简单明了;同时通过客户经常性的反馈,生产出符合客户要求的软件产品,并且有勇气迎接需求的改变。
35.客户计划的制定、小版本发布、隐喻、结对编程、测试驱动开发、重构、稳定的进度、代码共享、编码规范、简单的设计、持续集成、现场客户。
36.每个 Task 的时间最好不要超过 8 小时,就是要保证在 1 个工作日内完成,如果做计划时发现有些 Task 的时间超过了 8 小时,就说明 Task 的划分有问题,需要特别注意。