干货:关于软件开发需要掌握的10个常识( 七 )

正如吉恩·斯帕福德(GeneSpafford)的一句名言:”唯一真正安全的系统 , 是一个关了电、浇铸在混凝土里、由全副武装的警卫把守在绝缘房间里的系统——即便如此 , 我还是心存疑虑 。 “

遵守NISTCSF(国家标准与技术网络安全框架学会)、PCIDSS(支付卡行业数据安全标准)和SOC2(服务组织控制报告)等安全标准可以量化风险 , 如果做得合适 , 还可以降低风险 。 这些标准并不能保证绝对安全 , 绝对安全是不存在的 。 更重要的是 , 它们为如何负责任地应对和报告不可避免的安全漏洞提供了指导 。 诚实、直率、公开是良好的建议 。

软件 , 如果不管它 , 就像面包一样变得陈旧 。 我们的工作是平衡安全妄想与现实 , 并适当预算时间和资源 。

feature大小(用户感知到的)与创建feature所需的时间完全无关 。 小feature可能需要几天或几年的时间 , 大feature(用户感知到的)也可能需要几天或几年的时间 。

我们的工作是创建并支持一个软件开发过程 , 该过程接受这个事实 , 并且不是拍脑袋评估工程量 。 工作量评估本身可能需要令人惊讶的很长时间 。

鼓励通过沟通来解决工作量评估的问题 。 工程师可能会给出一个令人惊讶的很长时间的工作估算 , 但是也会提出对需求进行更改 , 从而大大缩短时间 。 记住工作量评估要包括测试、培训、部署和意外的假期(例如病假) 。

在没有与工程部门协商工作量的情况下 , 永远不要承诺某个feature 。 这并不是我们在公司的权力标志 , 这需要的是一个专业流程 , 在这个流程中 , 开发人员的请求得到认真对待 , 评估工作量 , 并按时交付(或出于诚实的原因延期) 。

伟大来自于在很长一段时间内所做的成千上万 , 也许是数百万的小进步(变更) 。 如果变更的效果都被测量是负面的 , 那么变更将被回滚 。


推荐阅读