敏捷就是“团队快乐”

团结一致确保目标统一是敏捷的特点

结一致

抱成一团还是一盘散沙,这是个很简单的选择。但工作中,一个传统职能组织中的每个人都能够团结一致,相互帮助、相互补位又是一种很难达到的状态。

对于传统职能桶式的组织而言,虽然成员的岗位归属在一个组织中,但各自有各自的职能目标。比如产品要出需求,技术要写码,测试要进行测试。各职能之间与其说相互配合,不如说相互打架,各自都觉得自己没责任,同时都觉得上游不负责,下游事儿太多,苦活累活都自己干了还不讨着好。 继续阅读

再次推荐《用户体验草图设计》

推荐产品必读用户体验草图设计

每当审核项目设计进展时,我总是会对那些复杂但很专业的Axure原型一筹莫展。在“确定做这个”与“展示原型呈现”之间,我们总缺乏足够的勇气去经历充分的沟通,虽然我一直强调用户故事,强调敏捷,强调拿起铅笔先确定草图,我们的团队也能适应敏捷流程的要求,但仿佛直接出原型已经成为了大家习惯,而那些流程方法都不过是形式而已。

我很痛恨这种感觉,真的。没有人是神,虽然经验能够帮助我发现很多Axure原型中的问题,但这些问题本应该在更早的阶段被解决,设计师可以用5分钟画出那些天才的创意,然后来沟通一下,而不是用5个小时做一个完美的交互原型,然后体现自己很牛逼很专业,我想骂也要很温柔的先鼓励一番,毕竟人家花了5个小时做了个漂亮而专业的Axure原型是不? 继续阅读

供应链式项目管理

最近我们重新规划和设计敏捷项目总体流程,对需求伊始直至项目上线的目标、指标、时间节点和责任人都做了定义。但当我们制定更详细的计划时,发现一个严重的问题:这是一个“梦幻日程计划”。在项目生命周期管理的探索与实践上,我们经历过瀑布式、迭代式、增量式以及混合的Scrum敏捷式,如果只针对项目管理而言,我相信在一个Sprint周期内,做到“一切尽在掌握”是可行的,但放眼至一个季度甚至半年的最终目标上,梦幻计划的完美主义的思想又成为了另一个极端。 继续阅读