敏捷开发的好与坏做法-快速回顾

因此,您知道什么是敏捷开发,作为方法论遵循的规则以及可以预期的结果。 但是,如果您已经使用该方法已有一段时间,但还没有完全看到它的好处,那么也许是有一些漏洞正在发生?
要快速重新评估您的团队在工作中是否采用了敏捷开发实践,请查看以下内容:

从文化开始,而不是工具和细节。

与其使用一个新的工具集而不是全神贯注,值得为团队建立合适的环境而工作,而不用打扰他们(例如电话,会议和其他信息噪音),这会影响生产力。 换句话说,请记住从敏捷心态开始。

从头开始计划。

考虑大规模计划,然后设计迭代以实现这些目标,而不是反过来。 这样,您不仅可以实现主要计划,而且可以使团队始终参与其中。 旨在更好地了解过程并提高生产率。

在计划时,请计划实际项目,而不是想法。

尝试成为您的客户。 客户与产品开发团队之间的人员应尽可能少。 这样,构建的产品最接近所需的产品。 请记住,一个想法经历过的每个人,无论是否愿意,都会对其添加自己的想法。 人们根本不会以完全相同的方式看到事物,因此,与其在产品说明中添加2万多个单词,不如将其集中在按照需要的方式进行构建上。

团队沟通。

许多人会争论,这是使敏捷工作的关键要素。 如果目标是快速做出反应并迅速适应变化,那么开发有效沟通需求和障碍的好的方法确实至关重要。 尝试使用可视化工具,这将使事情变得轻而易举。

团队定位和识别。

无论您的团队是坐在一个房间里还是遍布多个城市,州或大洲,每个团队成员都必须知道该向谁寻求特定信息。 换句话说,人们需要知道而不是猜测谁在项目的哪个部分。 很多时间要保存在这里。

迭代。

将工作分成可行的批次,最好是固定的,可重复的长度,然后让团队专注于此。 因此-进行迭代,分配工作,等待将做工作并期望结果的人员的估计。 然后重复。

优先事项!

听起来似乎很容易,但许多团队没有能够很好地确定优先级,同时这也是使任何流程变得敏捷和响应迅速的关键部分,不是吗?

责任。

团队成员需要知道哪些工作属于谁的责任范围。 否则,对工作项目承担的共同责任将落到每个人身上,这实际上意味着它实际上落在了一个人身上。

微观管理。

分配工作后,就可以完成工作,而无需站在团队中。 对流程的每个阶段进行微管理都不是敏捷开发的一部分。 同时,不要以为团队不需要任何形式的监督。 尽管一般的领导通常就足够了,但是领导和利益相关者都应该可以获取过程阶段的最新信息,并且应该能够在遇到任何问题或阻碍时参与进来。

团队变更太频繁。

通过每月增加新的团队成员,成功的机会就会下降,因为原始人员需要调整并评估新人的适应情况。如果需要新人,最好将他们作为首先是一个独立的,新的跨职能团队。 不久之后,新老团队会变得更加熟悉,然后就会更加开放。

不遵守在制品限制。

在制品限制的目的是帮助您,而不是对您不利。 尝试遵守曾经设定的限制,好事就会发生。 尽管对团队来说,覆盖或忽略它们是很典型的做法,但让团队中的所有人真正注意到这一点将是有益的。

将所有错误留给调试。

由于有足够的时间在发布前修复它们,因此很容易将它们保留。 这往往会导致草率的开发实践,并且从长远来看会产生拖延的趋势。 并不是您在敏捷环境中所需要的。

将坏消息隐藏太久。

人们可能会认为这是一件好事,因为他们没有散布压力很大的新闻,但实际上,在为时已晚尝试减少灾难时留下坏消息只会使情况变得更糟。

每次冲刺都遵循相同的障碍。

如果此冲刺中存在障碍,则团队将围绕它们进行工作。 如果下一个冲刺发生相同的障碍-这是一个信号,即使强制将其作为下一个冲刺的工作,也值得完全清除该障碍。 从长远来看,这将是值得的。

不关心团队的幸福。

各个团队成员对工作场所或公司的快乐程度直接转移到他们的工作方式中。 很容易看到如何。 根本不考虑这一点,并留下任何最初的不满情绪成长并可能传播到整个团队是很危险的。 是公司的创建者和工作的人-注意他们的感觉至关重要。

定期评估您的团队的工作方式以及可以做些什么来帮助他们变得更好,更有效率和对工作更满意,这将是非常有意义的。 绝对不会对他们或企业造成任何伤害。

首先发布在 看板工具上 博客