在三天内提高我们开发效率的两个技巧

在过去的几年中,我看过一些Scrum团队,总觉得有些不对劲。 从表面上看,它们看起来很不错:他们按照Scrum指南中的描述填补了角色,举行了活动,但最后,它们看起来比传统的开发团队更加透明,可预测和更具生产力。 在日常的讨论中,我并不觉得团队正在突破障碍。 这更像是相互之间的状态报告,而没有实现目标。 我已经在sprint审查演示中首先看到了已实现的功能,但为时已晚,无法进行更改,这并不是我所设想的结果。 我尽了最大努力来更精确地定义愿景,但没有获得更多成功。 请不要误会我。 团队在执行我要求他们做的事情方面做得很好,但是我们的进度仍然比我们需要的慢得多。 他们是了不起的:所有有才能的人,努力工作并热爱我们正在创造的产品。 但是,我们需要找到一种方法来填补这一空白,以使团队变得更有效率。 我无法从这个单冲刺中看出未来。 但是,我发现,两个简单的窍门惊人地改变了团队的思维方式,立即影响了生产力。 他们提供了更多的价值,却没有感到自己必须做更多的工作。 他们接管了我的不耐烦,以查看结果并获得用户的反馈。 我们同意在剩下的15天里保持这一状态,然后团队可能会再写一篇关于他们对新流程的感受的文章 如果您对此有任何意见或反馈,我们希望在下面的评论中听到。 如果您喜欢此博客,请别忘了鼓掌并在您喜欢的社交媒体上分享。 如果您想与Iain联系,请访问他的网站以获取联系信息。

通过这些策略在开发团队中获得最佳性能

衡量开发团队的实际绩效和生产率并非易事。 因此,软件开发团队的经理可能很难挑战其团队成员并帮助他们提高绩效。 在Apriorit,我们发现同时使用团队指标和个人指标都可以帮助我们的经理指导他们的开发团队,从而带来了更高质量的工作和更好的沟通。 衡量团队和个人生产力 因为我们采用敏捷方法,所以速度是衡量团队生产力的重要指标。 我们使用此指标来帮助估计下一个Sprint的范围,但是它是有限的。 恰当的例子:领导者无法比较不同团队的速度; 实际上,他们几乎无法比较同一团队在不同时期的速度,因为这也各不相同-人们加入和离开团队,休假和请病假。 Ivan Selikhovkin在有关Scrum的书中指出,速度几乎不能用来预测最终交货时间表。 可以知道交付时间表,不仅因为团队的速度随时间而变化,还因为团队成员在同一冲刺中完成不同的任务。 分析师为下一个冲刺准备任务。 开发人员实施当前范围,测试人员对上一个冲刺中的任务完成质量保证检查,依此类推。 由于这些变量,冲刺的团队速度将不一致,尤其是在生产率方面。 相反,假设团队绩效和项目环境保持不变,我们将更多地依靠挣值分析技术来了解我们是否将在预算范围内按时交付项目。 但是,我们还使用了一种不属于敏捷方法的方法:个人生产力。 Scrum拒绝单个指标,因为它们与方法论核心的团队精神相矛盾。 但是作为软件开发公司,我们需要衡量开发人员的个人生产力,以便制定个人开发计划,提升员工,提前发现问题等。…