1704234450
1704234451
承认自己的无知，也是互联网行业很重要的一个特点，它来自“求援”思维。我们经常向专家求援，甚至向用户求援，力争把对方的智慧、能力榨取出来，为产品做贡献。就像经常听到的一个词UGC——用户生产内容，就是很典型的向用户求援的一个例子。事实上，很多内容属性强的产品，里面绝大多数精彩的内容都是用户贡献的。团队配合时也需要每个人能保持谦逊，大家都是各自领域的专家，通力合作才能达成目标。
1704234452
1704234453
再来复习一下敏捷宣言：
1704234454
1704234455
一、人与人的交互，重于过程和工具。
1704234456
1704234457
二、可用的软件，重于详细的文档。
1704234458
1704234459
三、与客户协作，重于合同谈判。
1704234460
1704234461
四、随时应对变化，重于循规蹈矩。
1704234462
1704234463
敏捷的整体思想非常目标导向、结果导向，也非常接地气，以上四条也都很容易理解。我想多说两句的是第三条，它告诉我们要用敏捷的方式做项目，客户方与实施方之间千万不要搞成“甲方”和“乙方”的关系，而要像一个团队一样彼此协作。因为市场变化很快，采取甲方派任务、乙方实施的接力棒模式，响应速度一定跟不上。
1704234464
1704234465
最后看看更具体的敏捷十二条原则：
1704234466
1704234467
一、对于我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
1704234468
1704234469
二、拥抱变化，欢迎需求的变化，即使在开发后期。
1704234470
1704234471
三、敏捷过程能够驾驭变化，保持客户的竞争优势。
1704234472
1704234473
四、经常交付可以工作的软件，从几个星期到几个月，时间尺度越短越好。
1704234474
1704234475
五、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
1704234476
1704234477
六、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
1704234478
1704234479
先聊聊对前六条的想法。
1704234480
1704234481
敏捷对团队的要求非常高，它要求团队里每一个人都是独当一面的高手，在能力上非常专业，在态度上非常职业。这样的团队，人均产出很高，因而能保持团队规模足够小，员工福利足够高。我们经常对硅谷某些公司的免费餐饮羡慕不已，但团队整体效能上的差距，才是更显而易见的。
1704234482
1704234483
能力不足、新手太多的团队没有办法照搬敏捷的各种做法。比如，没法让新人“认领任务”，只能自上而下地指派任务，因为新人对工作量的评估常常不准；再比如，过于木讷的工程师无法和客户顺畅沟通，只能通过产品经理来传递信息。
1704234484
1704234485
职业精神不强会造成更大的问题。典型例子是，绝大多数国内运动员能理解“第二天要比赛，前一天晚上不应该去泡吧”的合理性和科学性，但有的运动员则必须真有这么一个规定来约束自己。我也碰到过一些职业素养不高的互联网企业开发人员，承诺交付日期后屡屡拖延。
1704234486
1704234487
所以，敏捷在具体操作层面上，要根据团队情况做一些调整，接着看后六条敏捷原则。
1704234488
1704234489
七、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
1704234490
1704234491
八、可以工作的软件是进度的主要度量标准[4] 。
1704234492
1704234493
九、敏捷过程提倡可持续开发。
1704234494
1704234495
十、对卓越技术与良好设计的不断追求将有助于提高敏捷性。
1704234496
1704234497
十一、简单——尽可能减少工作量的艺术至关重要，最好的架构、需求和设计都源自自我组织的团队。
1704234498
1704234499
十二、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
[
上一页 ]
[ :1.70423445e+09 ]
[
下一页 ]