首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >生产力-完成3次请求(最多4次),然后在8小时内对新的支持请求提交代码。

生产力-完成3次请求(最多4次),然后在8小时内对新的支持请求提交代码。
EN

Software Engineering用户
提问于 2021-01-04 12:09:27
回答 2查看 141关注 0票数 1

Situation

现在,我正在意识到,在我目前的位置上,我没有定期完成请求,而是间隔了请求的完成。但是为了接近我真正的能力,我想在一天的过程中尝试,为了我的第一次尝试,在一个工作日(8小时)内推出3次中等大小的提交。

范围

平心而论,我使用的是普通PHP、MySQL和甲骨文,除了jQuery之外没有其他框架。而且目前我花了足够的研究时间,我可以磨练。

定义

一次提交对应于通过电子邮件接收到的支持请求,有些请求尚未完成,但尚未准备好提交。现在,我正在包括未提交的已完成的支持请求,这些请求将首先被推送过去。

I向这里的社区征求关于我的过程在最长2小时内的总体有效性的反馈,并提供了上述信息

提出了13步解决方案(1小时30分钟-最长2小时)

提高工作效率的Proposed解决方案(如果我每一步花费10分钟以上的时间,没有任何进展)请立即通过电子邮件与经理或请求者核对。

Preparatory用于我确定的步骤的处理过程,首先指定的项目点是

在收件箱和电子邮件回传日志中确定4个支持请求以解决,考虑优先级和完成时间。与经理或请求者检查整个过程。

对每一项支助请求

捕获问题并通过电子邮件向请求者验证理解(20分钟)

10分钟 0)读一两次电子邮件,然后用我自己的话写问题。打开目标请求的网页以验证遇到的问题。写下第一步所需的问题和澄清.

5分钟

  1. 创建请求的项目符号点,以捕获当前问题的范围(当我执行this..this操作时),以及我创建的带项目符号的需求点(应该改为.)

5分钟

  1. 收到后,开始制定一个以短语为项目符号的需求列表,分解每个特定的需求,并由请求者询问所述项目符号需求是否包含解决方案的范围。
  2. 邮件请求者与一个简短的电子邮件寻址0),1),2)询问我是否正确和完整地理解问题和解决方案,并等待回应和作出必要的修改才继续。

测试用例公式(10分钟)

5分钟

  1. 为建议的解决方案编写测试用例列表

5分钟

  1. 测试计划坚持每个测试用例(直接由需求驱动)

制定解决方案(20 minutes)

10分钟 6)编写伪代码并绘制流程图(分别为半页、一页)

10分钟 7)写出特定语言的代码行(主要是PHP和SQL),以与步骤5相匹配

实现/测试和验证(40分钟)

30分钟

  1. 为项目符号特性需求点列表执行代码输入,并通过测试用例测试逐步验证插入的代码行到适当的代码区域。

10分钟

  1. 一旦所有案例都通过了所需的功能..。根据所期望的主要功能验证已实现的完整解决方案,以检查一旦验证了已理解和期望的功能是否满足,与请求者或管理人员共享可行的解决方案,独立验证该解决方案的功能。

修改解决方案(10分钟)

  1. 如果没有,则从步骤6开始得到澄清和修改解决方案。

提交# (5分钟)

  1. 如果是,则开始将进程提交到适当的分支。

移到下一个支持请求

  1. 移到下一个支持请求

统一任务的总计划时间(1 HR 45分钟至2 HR)

EN

回答 2

Software Engineering用户

发布于 2021-01-04 13:54:14

创建一个解决问题的标准时间框架似乎是个好主意,直到一个问题不能很好地融入时间框架。我的经验是,你不能预测这类事情。在您建议的工作流中,唯一看起来有风险的是您期望花费的时间。

每个工作要求,无论是增强还是缺陷,都将贯穿每一步。每个步骤和所有步骤总共花费的时间将取决于工作请求的范围和难度。

在讨论这个问题之前,先找出是否有一个Service级别协议()适用于这个应用程序,并以此作为指导。如果不存在这样的协议,那么如果你愿意的话,你就可以定义一个。

真正的问题是,你的用户对他们得到的服务水平不满意吗?

如果他们是快乐的,那么你可以保持这些步骤和时间框架的隐私。设定崇高的目标并努力实现这些目标是没有错的。

如果用户对服务水平不满意,那就联系你的客户。与他们会面,看看他们的期望是什么,以及你是否能满足他们。不要把所有的负担都推到你的肩上,而是看看把代码带到生产中的更广泛的过程。减速可能在你无法控制的范围内发生。你只能写代码和点击按钮如此之快。找出取得进展的其他障碍,并努力解决这些问题。

票数 4
EN

Software Engineering用户

发布于 2021-01-04 16:20:26

处理支持请求的方法似乎是very结构化的(有些人会说是僵化的)。这可能是一个很好的指导,或者至少是一个清单,以确保没有忘记任何东西。但假想的时机从何而来呢?这只是直觉吗?你刚才在一些简单的问题上尝试了你的方法吗?因此,在设定任何时间目标之前,开始收集数据:收集在一组有代表性的支持请求上花费的时间。

如果你对科学管理方法很在行(泰勒在1911年提出了这一建议,并在IT领域引领着瀑布式的方法--同时也知道它只能在非常罕见和特定的情况下起作用),那么你就会把测量的平均值作为一个目标。如果有人有的不幸得到一个真正复杂的请求并成功地解决它,那么您可能会指责他/她不尊重SLA,而不是祝贺他/她所做的出色工作。你要去这里吗?

但是,有了更多的统计知识,您就会发现平均值是没有意义的:一个小的软件错误很容易解决。但是,如果这是一个基于某些特定输入的事件,再加上一些峰值时间网络条件和复杂的计算,可能需要更长的时间才能计算出来!因此,您可以按照复杂度级别(低、中和高)设置请求,为每个类别设置不同的假设时间,而不为高复杂性设置时间(如果您正在准备SLA契约关系,那么您应该预见到需要提供高复杂性的证据)。

最后,不要微观管理。只为较大的块定义时间,以消除每个详细任务的波动。不要忘记,分辨率可能还需要迭代步骤(越复杂,迭代越多)。

票数 3
EN
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://softwareengineering.stackexchange.com/questions/420630

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档