一个交付故事
我们与A记之间故事的明线是团队结构的不断变化,然而背后的暗线,却是技术趋势以及所带来的影响。在采用新技术的同时,调整团队结构,给予团队更大的自治,从而释放生产力,这是高效交付的秘诀。
我们与A记之间故事的明线是团队结构的不断变化,然而背后的暗线,却是技术趋势以及所带来的影响。在采用新技术的同时,调整团队结构,给予团队更大的自治,从而释放生产力,这是高效交付的秘诀。
这里有四种离岸交付合作模式:Team Extension Model,Hybrid Collaboration Model,E2E Collaboration Model和Onshore/Offshore Collaboration Model。每种模式都有其优势和挑战,需要根据组织自身情况选择合适的模式。其中E2E Collaboration Model是一种全面的离岸交付模式,适用于团队成熟度较高、业务模块相对独立的情况。
在Thoughtworks,我们通过对最佳实践(Sensible Default Practices)、能力和度量的持续治理和改进,在保障交付正确的客户价值和减少浪费的基础上,使交付质量更好,速度更快,反馈更及时,从而达到追求工程卓越和形成发展工程师文化的目的,最终产生客户影响力。
大部分客户其实并不在乎你做的什么敏捷,他在乎的其实是你能不能在规定的时间内交付应该交付的软件。你告诉他我们用的是故事点估算,他会告诉你我不懂你们的故事点,你就告诉我这个功能几天做完。
根据Go 泛型提案的描述,Go不支持泛型方法:No parameterized methods。主要原因Go泛型的处理是在编译的时候实现的,泛型方法在编译的时候,如果没有上下文的分析推断,很难判断泛型方案该如何实例化,甚至判断不了,导致目前(Go 1.18)Go实现中不支持泛型方案。
不过,泛型方法的缺失,多多少少给程序员带来一丝丝的忧伤的情绪,在一些场景之下,使用起来特别不方便。我最近看到了几个因为缺乏泛型方法导致的问题,在本文中总结一下,和大家探讨。
我认同故事卡里非常详细的描述可以带来价值,但我也相信“简练的表述 + 充分的沟通”可以更高效、更灵活;我认同故事卡不是契约或合同,但我也相信完整、准确的表述可以显著降低各角色间的沟通成本。
持续集成和交付流水线是软件开发过程中避免浪费的一种实践,展现了从代码提交、构建、部署、测试到发布的整个过程,为团队提供可视化和及时反馈。
持续集成和交付流水线是软件开发过程中避免浪费的一种实践,展现了从代码提交、构建、部署、测试到发布的整个过程,为团队提供可视化和及时反馈。
在精益思想的指导下,团队寻找开发流程中的阻碍点,并从各个层面做出调整策略。在业务侧,分析哪些需求可以做到按需发布,哪些需求无法做到,设定适合团队的按需发布标准,并调整迭代工作量。在开发侧,考虑数据的兼容性,部署方式,以及高频率部署所带来的环境准备问题。在测试侧,提高自动化测试的运行速度和主流程的覆盖范围,并利用平台自身的自动化测试覆盖率统计功能,查缺补漏。
抛开中美关系和情绪喜好问题,谁也不可否认乔布斯改变了整个科技世界,他对产品的执着要求完美和跨时代的创新,影响了全世界。