日常工作中，我们总是需要对未来的任务，进行工作量的评估，这也是项目启动最重要的先决条件，目前这部分主要是基于WBS估算法来进行的，今天跟大家分享一下自己的相关思路以及具体的流程。
Sprint规划是scrum中用来启动Sprint的事件。迭代规划的目标是定义Sprint可以交付的内容，以及如何完成各项工作。迭代规划需要整个scrum团队合作完成。
我们在软件项目可研、招投标和工作量估算等管理实践的过程中，常常被一个问题所困扰：究竟我们怎么预估或者证明某个项目需要多少人和资源，工作量是如何计算出来的？ 实践中，我们最多使用的是拍脑袋法，根据项目的deadline，结合以往的项目经验，给一个大致合理，或者说，看上去合理的工作量估算。这样做有两个问题： 1）估算量按照deadline倒推，不够准确。 2）由于项目类型，规模，性质，范围的不同，以往的项目经验往往不能匹配目前的项目，造成张冠李戴的错误。 那么，有没有更好的解决方案呢？ 笔者在最近的工作实践中，接触到一种项目估算的专家法，可以提升估算的准确度，为项目决策提供科学的数据。 这个方法的核心思想就是：首先根据公司或者项目建设团队历史的经验，确定一系列的背景数据，如项目难度系数，团队开发效率，团队测试效率，团队文档效率等，再由3至5名有相似经验的专家对建设过程中的各个动作（如需求分析、设计、编码、测试、集成等）进行独立评估，给出工作量预估值，最后汇总所有专家的数据，根据一定的计算规则，算出最终的估算值，作为项目评估的依据。 具体的操作表格见下，表格比较清晰，具有自解释性，不再赘述： 链接：http://pan.baidu.com/s/1o8iITIi 密码：p9xv 虽然这个方法可以提升评估的准确度，但是要注意的是，这个方法仍然基于人的经验评估，所以出现一定的偏差仍然是难以避免的。由于软件项目基于大脑智力活动的特点，对于工作量的预先估计只能无限接近，难以完全到达。这也是大家普遍接受的一种认知。
很多时候，我们感觉什么都没干一天就过去了，但对领导者来说，事情最好已经提前做完了，而且是越快越好。聪明的管理者知道，“时间”是需要花大功夫去把控的限制因素，只有掌握了更多关于时间和工作的数据，我们才能更好地执行计划，在预算范围内按时完成项目。
本文作者：努力为用户解决一些实际问题 @joeyguo 腾讯文档智能表介绍 腾讯文档智能表，是一款新型的数据库电子表格，具备丰富的列类型和多维的视图展示。目前共有 20 种列类型，每一种列类型都对列的内容有严格的限制，保证了行列数据格式规整，使得能够轻易的进行数据分组、筛选、排序、统计，并且还可以转换为各种各样的视图展示，如表格视图、看板视图、画册视图、甘特视图、日历视图等等。 灵活多样的组合方式可以支撑我们轻易搭建出满足自己诉求的业务系统。以下将具体介绍我们通过智能表搭建的项目管理系统与 OKR
每个软件开发人员可能对什么是健康的软件项目都有自己的想法。可能是产生了巨大的商业价值，也可能是解决了某个领域的难题，就我个人而言，如果这个项目可维护、可运营，就可以称之为健康的项目。那么关于可维护、可运营的项目有什么特点呢？下面我列举一些更具体的方面。
软件开发成本估算过程可进一步细分为软件规模估算、工作量估算、成本估算和确定软件开发成本等四个过程。其中成本估算需要对直接人力成本、间接人力成本、间接非人力成本及直接非人力成本分别进行估算。
本文的目标读者是从事软件行业想快速了解软件开发过程工作量评估的人员。软件工作量评估方法很多，如代码行法、类比法、WBS、故事点、用例点、NESMA、FPA、cosmic、COCOMOⅡ等。本文只是选取主流评估方法进行简述，每一种方法在实际操作过程中有若干条计数规则，在此并未阐述，并不能作为评估工作的实施指南。实际使用方法时，需以各方法发布机构发布的官方文档为准。
a、依据工作量估算结果和平均人力成本费率直接计算出直接人力成本和间接成本的总和，加直接非人力成本计算软件开发成本；
确定测试范围一般在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，有助于在早期阶段发现潜在的测试遗漏；
抖音上有很多程序员和产品经理的段子。说产品经理提的需求有多S的，那只是段子而已。现在产品经理也是一种竞争很激烈的行业，如果有，那也做不长久。
软件规模估算是软件估算的基础。软件研发工作量与软件规模密切相关，因而，估算软件规模是进行有效项目范围和成本管理的基础。
通常情况下，规模估算是软件成本估算过程的起点。估算规模是后续计算软件项目的工作量、成本和进度的主要输入，是项目范围管理的关键，因此，在条件允许的情况下，应进行规模估算。在规模估算过程中，需要注意以下情况：
当User Story 无法在规定时间内完成时, 许多人的第一反应便是: User Story 估算的方法不对, 所以, 需找一个可 “准确” 估算人天的方法◦ 1) 首先,我想任何解决问题的方
题目比较特殊，最近过完年工作量和问题爆发的方式增长，DBA的工作量增长只能说明如下的几个问题
程序员要面临的挑战千千万，项目进度评估是有史以来就存在而且到现在也没有完美解决的重量级问题。 项目进度这个坎儿其实又可以拆分为两个： 1.工作量评估 2.项目执行与评估 前一阵圈子里流行一篇文章，题目是“做一个这样的APP要多久”，类似的版本还有“做一个这样的网站要多久”、“做一个这样的APP要多少钱”、“做一个这样的网站要多少钱”…… 多年的软件开发经验给我施了墨刑，在脸上刻了三个字：“程序员”，所以我走到哪里都会被识破身份。嘿嘿，都不用介绍了。这不，上周我去洗车时，就被一个兄弟认出来是搞软件的。然后
近年来，实体零售低迷成为趋势，客流下降、渠道管理混乱、高库存、反应慢、以及落后的供应链问题暴露的更加明显。而随着互联网人口红利逐渐消失，电商步入成熟期，许多企业电子商务的发展也逐渐遇到瓶颈。价格战、关店潮、倒闭潮、裁员潮、资金链断裂、股价暴跌等故事在零售业舞台不断上演。
知晓要如何解决问题，只是真正解决问题的第一步。在工作里，我们更多时候遇到的问题不只是如何解决，而是如何有效落地。
工作量估算 即对开发软件产品所需的人力和时间的估算——人力成本是一个项目的主要成本。
Checkmarx是以色列研发的一款代码审计工具，是.NET开发的，只能在Windows下使用。很多人喜欢把它和fortify进行比较，其实很难说两款工具孰优孰劣，各有秋千吧，两款工具配合起来互补一下更好。Checkmarx和Fortify一样，是商业版的，没有免费版。就我本人实战使用的经验来看，对于有些高危漏洞，有时候Fortify能扫出来，有时候Checkmarx能扫出来，没法评判哪个工具更厉害。Checkmarx的使用教程网上很少，我看了它的说明书，说明书写得有点复杂，我写一个简单的教程方便大家上手吧。
需求确认好之后，每个人都会领到自己的任务。我们首先要做的是评估个人开发时间和项目的上线计划。
这个问题显示了一部分PM对项目管理理解的一个误区，不应该把重点放在出了这种情况怎么处理，应该着重关注如何避免问题中出现的情况，这才是项目经理的职责所在。真出现这样的困境实际上已经晚了，能做的只是一点补救措施。
随着国内金融行业市场化进程持续加快以及互联网金融的兴起，信息技术尤其是软件技术的应用对于金融科技创新至关重要。各大金融机构在持续加大科技创新力度的同时，如何科学、高效地管控应用开发的投入并充分利用现有资源，进一步提升交付质量和IT治理水平变得尤为关键。
经常会有用户在咨询大表 DDL 的进度，预估时间等信息，其实依靠经验来做判断的话，比较容易出现误差，而且也和评估人的实际评估手段有较大的关系。事实上 MySQL 本身就有 DDL 的监控手段吗，只是默认情况没有进行开启。
产品经理和程序员的那些“恩怨情仇” 相信大家读听过“五个程序员杀了两个产品经理”的故事，虽然故事有点夸大，但却反映了程序员和产品经理之间长久以来的“恩怨”。做为开发中的两个关键角色，程序员和产品经理
博客：https://juejin.im/post/5ccecb006fb9a0322758cd22
国标/行业标准所描述的功能点估算规范，既有IFPUG ，也有 NESMA，二者在流程和规则上，大部分是相同的，主要差异是：
当开发的个人能力成长到一定程度时，日常工作不再是缝缝补补、修修 bug、打打下手。
随着公司业务的快速发展，以及业务线的快速扩张，项目不仅多同时也越来越复杂，且还有较多项目涉及到跨团队跨域协作。在此大前提下，技术层定期统一组织业务类立项宣讲筹备会，以便做好资源冲突的规避，同步资源信息和项目信息，确保项目按计划及时完成交付。
SQL查询语句的性能从一定程度上影响整个数据库的性能。很多情况下，数据库性能的低下差不多都是不良SQL语句所引起。而SQL语句的执行 计划则决定了SQL语句将会采用何种方式从数据库提取数据并返回给客户端，本文描述的将是如何通过EXPLAIN PLAN 获取SQL语句执行计划来获 取SQL语句的执行计划。
针对某一类问题的解决，我们可能需要借助算法来实现，实现的手段也可能是各式各样的。虽然最终都解决了问题，但是各个解决手段，也就是算法还是存在优劣之分的。
程序运行过程中，有些错误是不可避免的，而如何使程序在出现错误时代码仍然正常工作就成了程序员的日常工作之一。那么处理错误和代码整洁有什么关系呢？
在通常情况下，移动端主要关注以下性能测试场景： 验证在不同的负载下应用程序的性能是否满足需求 验证当前网络是否支持峰值、均值、最小用户级别的应用程序 验证应用程序客户端/服务端的设置是否能提供所需最佳性能配置 验证应用和基础环境的性能瓶颈，以便进行风险防控 验证应用的响应时间是否满足需求 验证应用或硬件设备是否能支持预估的负荷工作量 验证电池寿命是否能支持应用的预计工作负荷 验证在2G/3G/4G、wifi网络切换过程中，性能的表现情况 验证每个CPU周期是否最优化 验证电池消耗、内存泄露、GPS、相机等资
Google 的 AdMob 全栈工程师 Raymond Farias 在 Quora 发表评论表示：“我的同事最近和我分享了一组调查研究数据，一名高效的工程师每天能写100-150 行代码，我嘲笑了他，并表示这项预估值绝对要比实际值低很多。”
一个项目从立项到交付上线，经历过些许阶段，从销售谈拢，到开发进场，测试与交付，前前后后，要不少时间。比较厉害的项目经理，怼天怼地也在交付之前，交付产品，虽然伤痕累累。
1982年 拜占庭将军问题 Leslie Lamport等人提出拜占庭将军问题（Byzantine Generals Problem），把军中各地军队彼此取得共识、决定是否出兵的过程，延伸至运算领域，设法建立具容错性的分散式系统，即使部分节点失效仍可确保系统正常运行，可让多个基于零信任基础的节点达成共识，并确保资讯传递的一致性，而2008年出现的比特币区块链便解决了此问题。 David Chaum提出密码学网路支付系统 David Chaum提出注重隐私安全的密码学网路支付系统，具有不可追踪的特性，成为
导读： “随着卫生信息化的发展，我们的数据量会越来越大。目前数据量已经足够，但是关键的问题是数据该怎么用，我们最缺少的是对数据的认知方法。”在12月2日财新峰会健康点医疗专场上，海市决策委员会委员、上海市医改办副主任许速分享了他关于上海新医改的经验，他认为，数据越大，医改问题就越聚焦，从分级诊疗到医院日间手术室，再到药品两票制、带量采购，都表明医改中的措施越来越具体。进入大数据时代，医改必须精准化。 社区与医院建立两个标准 上海新医改的最核心的部分是建立了两个标准：一个是基于社区卫生服务中心的标化工作量
美美导读：ETA（预计送达时间预估）是配送调度环节中非常重要的一环，而且涉及的因素特别多。本文阐述了ETA深度学习技术迭代中的一些尝试及效果。
显杰，美团点评技术专家，2018年加入美团，目前主要负责配送算法数据平台深度学习相关的研发工作。
不管我们是做业务开发，还是做基础建设，虽然产品诉求千差万别，但是我们必然需要做好方案设计，然后还需要进行方案设计评审。
在企业微信创建腾讯表格，选中：项目甘特图，即可在公司内部、部门之间进行项目甘特图的整理、收集、记录和共享协作。
代码出结果的速度依赖于代码量、运行硬件等诸多因素，所以程序员在代码出结果（包括中间结果和最后结果）需要的时间也不一样。如果结果需要等几分钟到几小时（且中途没有报错），在这段时间程序员都会选择干什么？
据统计，有差不多 70% 的项目都没能准时完成，你的项目也可能是其中之一。总是 delay 是不是很烦人？你也希望在满足市场需求的同时，还能按时交付项目，对不对？正因如此，软件开发时间的估算，应该是构建研发流程时优先考虑的事项。我们编制了一份清单，列出了为获得贴近实际情况的软件开发时间，你需要做的一些基本动作和步骤。下面我们就来具体谈谈，如何估算开发时间。
最近在分析一个迁移案例的时候，突然多了一些额外的想法，也算是对原有方案的一个补充。 比如存在两个数据库 peak和esales,彼此是独立的业务，所幸两者也没有用户的冲突等，都在10g版本，如果需要把他们整合到11g的环境中，迁移的方案就是一个重中之重。 因为这两个库的数据量不大，都不到200G,所以迁移的时间估算下来在2个小时还是可行的。 初步的想法就是常规的逻辑导出导入，比如使用数据泵来做。按照以往的经验，每个数据库大概会在40分钟左右完成。两个加起来就是80分钟左右。 如
导读：ETA（预计送达时间预估）是配送调度环节中非常重要的一环，而且涉及的因素特别多。本文阐述了ETA深度学习技术迭代中的一些尝试及效果。
今天的标题中的预判，意思就是预先判断。根据设计图，对此项目可能发生的工作量，进行预先判断。一般开新项目之前的会议上，每个人都要报一个预估的工期，这个工期就是根据这个预判来的。 那怎么预判呢？说难也难
原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！ 原文链接地址：程序员在等代码出结果的时候都会干什么？ 代码出结果的速度依赖于代码量、运行硬件等诸多因素，所以程序员在代码出结果（包括中间结果和最后结果）需要的时间也不一样。如果结果需要等几分钟到几小时（且中途没有报错），在这段时间程序员都会选择干什么？ [1240] 牛逼的程序员都是擅长提高自己的生产效率的能手，减少无效idle时间就是其中一个重要的点。如果你可以多线程干活，那么两台机器，一台机器build切换到另外一台机器做另一个事情，这个需要你
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
