推翻“敏捷洗脑”论,客观谈谈什么是真正的敏捷

  • 时间:
  • 浏览:0

关于团队气氛,然后一个 多团队里每个成员都在闷头做被委托人的工作,独自面对被委托人的交付压力和技术挑战,成员之间互相帮不上忙,我们歌词 的气氛一定我这样多 太好。而然后人及 通力配合工作在相同的功能上,一齐理解消化业务,一齐处置技术大问題,一齐做技术决策,并分担处置严重不足(BUG)的责任和压力,这样团队的气氛缘何会不好呢?

怎么才能 才能 去做好一个 多团队带头人?应该安排团队成员每天做哪些地方?

我们歌词 的代码真的写了好多测试。

我希望要开一整天的会,我不知道我们歌词 是缘何撑下来的。

感觉跟着我们歌词 一齐做测试驱动开发好像没这样难。

在成功学的洗脑课程中,有一句被强调最多一句话:“失败一定有意味,而成功一定有土办法!”这样,我们歌词 过去回答不了的上端哪些地方地方大问題,也回答不了由它们意味的管理上的大问題,其根本意味又是哪些地方呢?获得管理上成功的土办法又是哪些地方呢?

这段时间里,我让被委托人成为一个 多“警惕的观察者”。不管是主观上的警觉,还是故意在外人背后将被委托人打造成我希望的一个 多形象。生怕在我还这样觉察到的然后就然后被敏捷洗脑了;一齐也希望在我希望的好友背后以尽量理性、中立和客观(理中客)的形象示人。不过,这不妨碍在我们歌词 看来,我然后被洗脑了。

然后我了解到,这如同学习新知识过程“守破离”中“守”的阶段。“守”的过程既是获取新认知的过程,也是与过去的认知做比较和更新的过程。观察大问題——对比质疑——私下学习——拨开疑云,大体我希望我希望的不断重复,在不断了解新实践的过程中,也同步去认识它、理解它。

我希望对于敏捷来说,暂且发生哪些地方洗脑不洗脑的说法。它我希望这个 风格,这个 态度。我希望你运用你这个 思路和风格去让团队合作者者这样好,开发出来的软件质量这样好,那我希望敏捷的。敏捷中典型的具体实践土办法有 Scrum、XP 和 Lean 等。此外,近年被广为谈论的 DevOps,也然后成为了敏捷软件土办法的典型实践。

渐渐地,一系列大问題得以解答,使得我最终接纳了敏捷开发思想,并认为它是适用于现代开发团队中的工作土办法。

江湖上传言说敏捷需要文档,我希望是谬误。敏捷并这样说需要文档,我希望说认为团队成员之间的沟通合作者者比详尽的文档更重要。就说 ,用户故事仍然是会饱含必要的描述内容的。要写清楚为哪些地方要做这项功能以及验收标准等。

但哪些地方地方“不敏捷”的条目,基于团队具体具体情况,然后实际操作起来更可行,就还需要根据目前的阶段去施行,并向着更敏捷的方向去持续改进。这类的还有,敏捷我这样多 说团队一定要开站会,站会一定要在早上开等等……相反,然后要求团队一定要做某件事,并非 它与敏捷思想是背道而弛的。我们歌词 应该遵循敏捷理念去对实践进行改良,以适应团队实际具体情况。

是我不好你你要希望认为。

事实上,“敏捷”一词来源于英语 Agile,你这个 英文词汇也这类于中文中的形容词“敏捷”一词,其适应性相当广泛。我们歌词 往往用它来形容业务的灵活性,思路的开放性等。

在过去我待过的团队中,突然一个 多多无法解答的大问題。那时作为技术经理,我突然被别人问到某些无法用被委托人经验回答的大问題。

这项活动,以及然后的迭代过程中,基于你这个 会议的开发过程解答了我第一个 多大问題。

我希望,我发现开发团队的时间我希望是需要管理的,而管理时间这件事并非 也需要花些心思我这样多 做好。这然后,然后你问我某项功能需要多久做好?我会告诉你,我你要要来拆分一下功能,粗略估计就成为了然后。

1我们歌词

几年然后我还是个野生tcp连接员的然后,对“敏捷”你这个 词是某些抗拒的。那然后,要么是这样想法、懒得去理会,要么我希望主观上拒绝:

我们歌词 一个 多多角色叫BA,会写一个 多个的用户故事来描述需求,一半个月就还需要完成一个 多故事。明确的前提条件和验收标准(从哪里现在开始英文英文英文做,做到哪里为止),让开发工作变得有节奏感,需求不清楚的然后随时就你这个 需求的范围进行讨论。

加入新团队后不久,哪些地方地方大问題就全部得到了解答。

2大问題

逐次代码提交都需要他人审查并批准的管控;

手动部署生产环境;

不你要人修改被委托人编写的代码。

接着开发人员和测试人员对还严重不足详尽的细节提出大问題,讨论获得一致,一齐对各个步骤大致估计所需时间。每个用户故事暂且确定由谁来做,我希望我们歌词 一齐就其中的细节进行讨论,并就所需时间形成一致:有的人说需要 3 天,有的人并非 2 天就够了。我们歌词 会叙述被委托人的想法,并最终达成共识。

估计我希望帮助做计划的这个 土办法,在后续开发过程中,然后发现比当初估计的要复杂化,然后简单的具体情况,需要与 BA、PM 等角色一齐更新你这个 估计值,从而帮助团队及时完善一现在开始英文英文英文制定的迭代计划(然后必要,还需要加入某些、减去某些然后修改某些)。

4就说 ,我被洗脑什么然后?

肯定又是些无所事事的人弄出来的无聊概念,帮我们歌词 被委托人刷发生感的东西

敏捷,我希望哪些地方地方咨询公司弄出来给别人洗脑的,理念太空,根本无法落地

哪些地方地方一大堆概念都在些哪些地方鬼?条条框框这样来越多了,运作起来太麻烦了

我这样多 敏捷,我们歌词 现在不也挺好的吗?敏捷跟我哪些地方地方关系?

敏捷都在哪些地方宗教,它我希望这个 生产软件的思路,这个 倡议。它倡议,通过加强团队成员间的交流合作者者,尽快交付高质量、有价值的软件,让团队以良好的响应性来拥抱软件的变化。为了符合你这个 思路,它一般又会有某些典型的实践土办法。我们歌词 还需要说哪些地方实践是由敏捷土办法所推荐的,我希望是“敏捷的”;而哪些地方实践是不推荐的,我希望是“严重不足敏捷的”。但我这样多 说哪种是好的,哪种是不好的。

典型的业务功能团队以及然后跳出的微服务团队,都很好的诠释了团队价值形式和规模大问題。一个 多多论述产品设计和组织价值形式关系的康威定律,值得我们歌词 深入思考。团队带头人?我突然反应过来,一定要有你这个 角色么?然后我们歌词 都能很好地运作了,那并非 你这个 所谓带头人的作用是很淡化的,这也我希望所谓的自组织团队了。然后一定要一个 多带头人,那他的职责一定是确保我希望这个 自组织的机制在团队中持续地运作下去。

自主提交代码,尽早集成;

自动化一切,包括环境初始化;

代码由团队共享,随时重构和优化。

原文发布时间为:2018-07-21

本文作者:陈计节

本文来自云栖社区合作者者伙伴“DBAplus社群”,了解相关信息还需要关注“DBAplus社群”。

做完你这个 功能,你估计需要几次时间?

为哪些地方我们歌词 在办公室显得很安静、气氛很糙压抑?

最后一个 多大问題,关于团队。

不敏捷的:

但然后我却确定加入了 ThoughtWorks,你这个 传说中的敏捷大本营,一方面然后就说 出名的书都在 ThoughtWorks 的人出的,被委托人面也想亲入虎穴一探究竟。而如今,历经敏捷项目的洗礼,我然后成为专职的一线咨询师,为众多大型企业提供敏捷转型过程中的技术指导。

我带着这个 个 多大问題离开了然后深度图参与的创业项目。与我们歌词 分享了要探索新征程的想法然后,他真诚地邀请我加入他的创意,并希望由我来带领团队一齐续写新的故事。我猛然间发现,并非 并非 然后在团队里担任所谓技术经理的职位,但我真正给团队带来的帮助似乎更多的我希望一个 多有经验的工程师给新手的指导。那然后,第一个 多大问題产生了:

3答疑

目标:发出问卷链接,并将数据取消来。

范围:确定模板、发送链接、取消数据、发送提醒邮件

步骤:

管理员在内部内部结构系统中创建好模板(需要开发)

用户可在 XX 页面中使用选项来确定问卷模板(系统自动将内部内部结构系统中的模板名字同步到本地系统)

用户可在 YY 页面中使用链接发送调查表单,客户收到饱含链接的邮件

系统自动将内部内部结构系统中收到的数据同步到本地系统中以供使用

然后没收到提交数据,系统自动在5天 后自动发出提醒邮件,客户再收到一封饱含链接的邮件

比如,敏捷的:

相比于拿别的产品做个演示,甩一句“就照你这个 做”,我希望就天天催进度、做出来然后又说不对劲的产品经理,一个 多多专门负责业务、随时还需要叫过来讨论的BA让开发人员感到倍感轻松。

而上端的其它大问題也更快得到了解答。

我现在是接受了敏捷思想的,其中还有某些工具和土办法,我还在持续学习过程中。不过,“洗脑”你这个 词这个 并非 具有一定的预设立场,它是哪些地方地方质疑者的说法。

在某些我们歌词 看来,我自从换了工作,就现在开始英文英文英文在群里转发某些敏捷相关的文章,发表某些感言。在转发哪些地方地方内容的然后,我突然用到的叙事口吻是“我们歌词 ”:

团队里我们歌词 的角色是怎么才能 才能 分配的,规模又应该多大?团队之间应该怎么才能 才能 配合?这就太难回答了。

第一个 多要实现的需求我希望一个 多“明星”功能,集成第三方系统的调查问卷。团队更快组织了需求计划会议,并细致地过了一遍第一期要完成的目标、实现你这个 目标要饱含的业务范围、具体又饱含哪些地方步骤(用户故事)。

团队一齐估计时间的过程,不光还需要消除特定人估计时的无助感,更重要的是它让人及 都了解用户故事的细节,在后续开发中谁都还需要参与开发。

把所有故事的估计时间相加,即为整个功能所需最少 的时间。

这样,重新回到大问題这个 。敏捷是哪些地方呢?它会将我们歌词 洗脑吗?

哪些地方地方大问題不得到解答,你要如同掉下井底的青蛙,并非 能听见外面世界的声音,却这样都看井口大小的世界。

相对较小的用户故事,估计起来要比一整个功能(比如对整个调查问卷功能进行估计)估计起来靠谱得多。即使有特定的用户故事估计不准确,其影响范围也是可控的。