Bootstrap
你是做敏捷与DevOps的,还是做掉敏捷与DevOps的?

近年来,由于敏捷与DevOps是软件交付行业的大势所趋,几乎每家公司都有专职做敏捷与DevOps的。这么大力的金钱和人力投入,效果如何呢?

多团队如何评估故事点(译) ——来自Mike Cohn的建议

多团队评估故事点的时候有没有让你头疼?看看大神Mike Cohn给了什么建议。

速度(Velocity)不背这个锅

估算是为了更好的计划,不能把估算当做一种承诺;速度是可变化的,可以用来修正计划的误差。

速度(Velocity)不背这个锅

估算是为了更好的计划,不能把估算当做一种承诺;速度是可变化的,可以用来修正计划的误差。

今天谈谈用户故事地图,不是用户故事

摘要:用户故事地图其实并非是将描述好的用户故事汇总在地图上。而是通过分析、梳理,将用户故事展现出来,进而汇成了一副用户故事地图。

如何组织一场用户故事地图工作坊

用户故事地图通过对话,让不同的角色之间彼此对齐需求认知,发现Gap,增强协作,达成一致的目标。在产品开始动工前,可以说是成本最低的一种假设推研的方式,能够更早地发现不合理或者遗漏点。这也是为什么用户故事地图成为Product Owner工具箱中必备的工具。

一次用户故事地图之旅

一次用户故事地图实战,一些个人真实感受。用户故事地图绝对是PO的好工具。希望我的分享能给您带来一些不同。

敏捷中的威胁建模

软件安全一直被视为一项神秘而又高级的领域,其中的软件安全开发和安全测试更是很多普通的开发者和测试人员难以企及的工作。但是对于常规的安全开发和安全测试,普通的开发人员和测试人员是可以担任的。而且通过这些常规的安全开发和安全测试,可以预防绝大部

实用威胁建模指南(二)

上篇文章我们介绍了威胁建模的发展历史, 解决的问题, 以及对于威胁建模的三条建议, 这篇文章开始我们就具体来看一下到底如何在实际开发中落地威胁建模.

实用威胁建模指南(一)

你写的Code安全吗? 如果有人问你这个问题, 你的答案是什么? “安全的, 因为我用xxx框架, 他可以抵御xxx攻击. ” “安全的, 因为我用了xxx云的xxx安全服务”. OK, 这些答案都不错, 但是如果我们仔细想想, 这些答案是不是又有些虚? 或者说, 安全是安全工程师要

【经验分享】遵循10步法,应用系统发布效率大不同!

本文结合了我们的工作经验和思考,谈谈如何通过“十步法”实现应用系统的高效率发布,同时做到“事前审批、事中控制和事后审计”。

Scrum Master的职责——《Scrum指南》重读有感(5)

今天聊聊Scrum Master这个Role。在Scrum过程中他的职责是什么?他的工作有哪些内容?他的价值是什么?在和实际Scrum团队一起工作中,我发现很多对Scrum Master的误解,有时候会导致人们对这个Role的预期不一致,从而导致领导甚至Scrum Master自己的失望和迷茫

Thinking Agile 2021,Being Agile 2022

将"假设"应用到自身,我们自己就是一个可以不断迭代演进的产品。拥抱变化、获得反馈、学到知识。

<精益创业>读后感

精益创业是一种思维方式,甚至可以是一种生活方式。创业不仅仅发生在新创企业中,也可以发生在大企业甚至是传统企业中,只要你想有所突破,寻找创新之路,那里就创新的血液。

从一个乙方视角聊聊敏捷项目

敏捷开发是否适合项目形态?还是只能在产品研发中发挥作用?让我从一个乙方的视角聊聊感受,他们之间确实有不同的地方,但也有相似的方面。

我们需要软件工艺

软件开发并不是一项简单机械的活动,将其看作一种工程学实践是不恰当的。因此,我们需要给软件开发一个更好的隐喻:软件工艺。 

Scrum模式之估算点模式读后感

估算一直都是软件开发中一个无法绕过的难点之一。项目预算和风险把控需要有一个估算,产品发布时间预测需要估算作为参考。而人类最不擅长的就是估算,毕竟这个是还没有发生的事。我在平时工作中也经常面临要对产品Release或者投标的标书进行估算的场景。最近

重学Scrum三大支柱 《Scrum指南》重读有感(1)

Scrum 将 4 个正式事件组合在一起以在一个容器型事件 Sprint 中进行检视和适应。这些事件之所以起作用,是因为它们实现了基于经验主义的 Scrum 的三个支柱:透明(Transparency)、检视(Inspection)和适应(Adaptation)。

一个Product Owner的假设引发的思考

一次有趣的对话引发的思考。Product Owner应该如何对待假设?

如何进行用户故事估算——Ethan分享观后感

敏捷估算一直是一个无法绕开又非常令人头疼的话题。无法绕开是因为无论是产品还是项目都离不开估算。令人头疼是因为估算结果一般都很难令人满意。

Sprint Review != Demo——《Scrum指南》重读有感(4)

Sprint Review 的目的是检视 Sprint 的成果并确定未来的适应性。Scrum Team 向关键利益攸关者展示他们的工作结果,并讨论 Product Goal 的进展情况。

梳理会在Scrum中是活动还是事件?——《Scrum指南》重读有感(6)

到底梳理会是事件还是活动呢?到底Scrum中什么是事件(Event)?什么是活动(Activity)?今天想聊聊这个话题。

你以为的你以为未必是你以为的

团队高效决策,有什么方法吗?可以试试两顶“帽子”。

SM和PO如何参与Daily Scrum——《Scrum指南》重读有感(3)

Daily Scrum 是一个属于 Scrum Team 的 Developers 的 15 分钟的事件。为了降低复杂性,它在Sprint 的每个工作日都在同一时间同一地点举行。如果 Product Owner 或 Scrum Master 正在积极处理 Sprint Backlog 条目,那么他们将作为 Developers 参与其中。

Scrum Team不等于Development Team——《Scrum指南》重读有感(2)

今天继续这个系列,聊聊Scrum Team。先看看Scrum Guide中的一段描述:

固定价格项目能否敏捷?

固定价格、范围和日期的项目是可以敏捷的吗? 答案是:可以的。让我们尝试在约束的条件下寻找解决方案空间。

用户故事信息过多或过少带来的问题

用户故事信息过多或过少对团队来说都不合适。Just Enough & Just In Time。

JAVA稳定底层,快速开发首选,XJR智能化客户关系管理

如今,CRM(Customer Relationship Management,客户关系管理)已经成为帮助企业信息化运作的重要工具。

对于CRM之于现代化企业的影响以及作用的分析

客户资源管理(Customer Relationship Management)是当代企业软件应用系统的重要组成部分,经过多年来的发展与普及,目前已经成为各领域企业的核心应用。有重复证据表明,CRM对企业拓展业务、开辟市场、提高业绩起着巨大大帮助作用。

很不幸,自动化测试永远只能是必要非充分条件

“ 对自动化测试的合理预期非常重要。”

高效程序员的45个习惯:敏捷开发修炼之道(8)

什么是轮换制?在研发中,轮换制是指在工作中,经常让同事相互之间去迭代对方的代码。在研发中,很多时候开发组长都倾向于让熟悉的人去做熟悉的功能,因为这样效率高。但如果一直这样未来就会出现这个功能只有他能维护,其他人根本维护不了的情况。

学习型组织的修炼之道

时代已经不是一个线性的时代,如果你不会用非线性的思维方式去带领一个团队,去思考一个问题,你的团队很快就会像温水煮青蛙一样不知道会在哪一刻瞬间被淘汰。

敏捷(组织)转型的6个准备条件

敏捷转型非常复杂。成功有巨大的好处,但不能保证成功。客户所钟爱的生产力,创新和更高品质的产品或服务的提升,可以使转型组织的挑战变得非常值得。

如何通过 Jira Service Management 打造员工自助服务工具实现高效分布式工作

2020 年,随着 TEAM Anywhere 的发布,Atlassian 致力于采用一种新的工作方式:我们的大多数团队成员——其中许多人在大流行之前都在办公室工作——现在可以选择在任何地方工作。

全球案例 | 霍尼韦尔:Atlassian 帮助我们在疫情期间拯救生命

Atlassian 支持霍尼韦尔数千名远程工作人员完成复杂任务,同时又在83个国家/地区分发笔记本电脑,从而提高了企业的灵活性。通过采用敏捷、跨职能的框架,霍尼韦尔能够在不到六周的时间内完成过渡。该公司预计每月生产超过 2000 万个 N95 口罩

其他标签