我想大多数人都知道“敏捷管理”,它的口号是“敏捷迭代,小步快跑”。那么除了喊口号我们还能做什么呢?或者说,这对项目管理有什么影响呢?
想象一个场景,一家公司目前正在实施“敏捷管理”,并以两周的迭代周期开始。
然后一般情况下就是简单的划分需求的优先级,创建需求文档,审核紧急且重要的原型和需求,最后尽快进行开发,偶尔更新一下开发进度。我们问进展如何了,然后开发完成,测试,并在第二周的周五晚上发布。
这是敏捷吗?
这只是传统的“瀑布模型”到“敏捷模型”的一个应用,仅此而已。
最后发现每两周就有一个版本,所有成员都在加班,几乎冒着生命危险。当我上网时,我发现一切都充满了问题。我还能做什么?回滚.
那么敏捷项目管理到底是如何运作的呢?有什么方法论吗?
我们将从「规划」、「需求」、「拆解」、「跟进」、「回顾」五个方面来讲解如何进行敏捷管理。
敏捷管理的一些概念
项目管理有多种类型,例如预测型和敏捷型,很难说哪一种更好。最好从自己的项目出发,找到最适合自己的路径。因此,必须清楚地认识到敏捷不是神,而只是项目管理的一种。敏捷本身有很多方法论,但我想谈谈Scrum,它有四个主要声明。
个人和交互比流程和工具更重要软件行为比详细文档更重要与客户的协作比合同谈判更重要适应变化比遵循计划更重要这四个陈述是:在某种程度上涵盖了我的内容我要讲的是。当然,我不记得这些声明了。你是否记得并不重要。最重要的不是在方法中找方法,而是从实践中找方法。所以我们开始从传统的瀑布式开发转向敏捷开发,首先要做的就是——计划。
计划
假设您的项目采取小步骤、快速执行的方式,即2 周和1 次迭代,那么最重要的是实际计划。
我认为规划中最重要的有两点。一是团队,二是关键点。
在团队规划中,每个团队的人数应保持在10人以下,因为随着人数的增加,交换的信息变得复杂,不适合“个性和互动”的敏捷宣言。
如果团队超过10人,就需要进行团队划分,并为每个团队任命一名“Scrum Master(团队负责人)”。
一旦你建立了你的团队和他们的具体分工,你就需要开始为关键时刻做好计划。
具体规划的话,你需要在两周内规划好关键时间节点,并且可以逆推找出你的关键节点是什么。
例如上线前需要一定的“在线时间”,上线后需要一定的“测试时间”。测试前我们需要知道某个“开发完成时间”,以后也需要知道某个“开发完成时间”。具体“审核时间”。
这里重要的一点是“特异性”。它以甘特图的形式直接识别每个链接中每个位置的具体关键时间和处理时间。
图片仅供参考,不代表具体情况
然后就可以按照每个版本的规划要点一步步进行,但只有有了路标,项目才能变得清晰。只有规划整个盘子,你才能在盘子里添加一些东西,而不会给你自己和你的团队带来混乱。
需要
3. 目前存在哪些风险?谁需要帮助?
通过站会,我们可以真实地跟进某个开发任务项的完成情况,判断该任务项是否存在风险,如果存在,是应该加班解决,还是应该推迟这个功能?你可以看看它是否不存在。等等?
我们使用看板和每日站立会议这两种工具来实时跟进每个冲刺的细节,以便我们能够了解它并最大限度地降低风险。
如果你是学生,想要项目管理资料合集,请先关注我,然后私信我。
点击“了解更多”了解更多精彩内容。