本文通过案例分析，展示了如何通过引入新的工作习惯来挽救陷入困境的项目。团队成员对项目目标的理解不一致导致了延误和问题，通过实施“站会”习惯，团队达成了共识，提升了效率和产品质量。在另一个案例中，面对进度滞后和沟通问题，建议从引入敏捷习惯和编码规范着手，逐步稳定项目状态。关键在于逐步引入改变，避免一次性实施所有新习惯，以确保项目的稳定性和团队的接纳度。
一灯能除千年暗，一智能灭万年愚。 —— 慧能
无论经验是否丰富，不管过去有什么样的成功，遇到过什么样的挑战，只要进行一个新的实践，就可以让人头脑清醒，并让你的工作与生活从此发生改变。
使用这些实践的子集，能够救濒临失败的项目于水火，也可以使得从此往后的项目变得完全不同。
1. 只要一个新的习惯
1.1 问题是什么？
- 软件发布总在延期
- Bug不断增加，失去控制
1.2 发现问题的过程
活动：访谈
主题：了解程序员的工作是怎么展开的，有哪些进展顺利，哪些构成了障碍
参加人员：Andy和注重实效的程序员们
第一位成员：他们在开发一个C/S应用，客户端非常瘦，所有的业务逻辑和数据库访问都放在服务器一端
最后一个成员：系统的构成包含一个全部GUI和业务逻辑的胖客户端，以及一个简单数据库的服务器
结论：每个人对项目的方向和目标的了解有所偏差
原因：团队从来没有坐在一起讨论过项目。实际上，每位成员仅仅与坐在旁边的人有过讨论。就像传话游戏，信息在人与人之间传递时出现了偏差，也偏离了本意。
对策：开始“站会”
结果：很快解决了架构的问题；团队变得有凝聚力；bug产生率降低，产品稳定；交付日期可控
1.3 决定对策的过程
医学上的比喻：
症状：胸部疼痛
解决措施：最小剂量（必要的）药物和治疗过程
长远解决措施：别赖在床上了，爬起来开始在跑步机上运动吧。
同样的
如果一个习惯可以产生好的效果，那么采纳所有的习惯，就应该产生更好的影响，是吗？
最终一定是这样的，但是不能一下子全部上马——特别是一个已经处于困境的项目。突然改变某个项目的全部开发习惯，是让项目突然死亡的最佳方式。
不要试图一下子解决全部问题。
案例2
我们首先应该引入一系列习惯来稳定目前的状况，来看另外一个案例。
遇到的问题：
耗费了一半的时间，还有90%的功能没有交付。
管理层对开发人员的进度不满意，开发人员对管理层的进度威逼不满意。
Q1. 剩下的时间，不知道是开发新功能，还是修补bug
Q2. 不管危机发展到什么程度，团队希望成功，不知道该怎么办？
Q3. 所作的事情，每件都让他们更落后，他们感受到了威胁，不愿再做任何决策
-
- 先稳定病人的情况，从促进沟通和协作的敏捷习惯开始
-
- 引入一些与发布相关的习惯
-
- 引入一些与编码的习惯
如果事态没有那么糟，我们都有一些针对性的建议。
引入敏捷：管理者指南
- 作为项目带头人，有责任让大家知道接下来要发生什么
- 从沟通开始
- 准备好基本的开发环境
- 如何将项目和团队带入到一个稳定的节奏
- 迭代结束后，举办项目回顾会议
- 哪些做得好
- 哪些做的不好，需要调整
- 哪些不起作用
引入敏捷：程序员指南
You can lead a horse to water, but you cannot make him drink.
要看到益处，别人才会跟你走。
- 从自己的单元测试开始
- 提升代码质量
- 减少错误，健壮性提高
- 所有的任务可以按时完成
- 可以提前下班回家
- 编码习惯
- 持续构建服务器
- 项目开发节奏
文中斜体部分为引用原文
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
