w1100n
This site is best viewed in Google Chrome
wiloon, 5/10/2019 13:14

减少进程的上下文切换 https://www.infoq.cn/article/xYCWYK9*TfmpFNO6RkWt?utm_source=rss&utm_medium=article

wiloon, 5/10/2019 0:13

android,ios: Scrum Poker Cards (Agile) Home

wiloon, 5/8/2019 15:16

https://blog.csdn.net/u014801432/article/details/82558380

wiloon, 5/7/2019 11:18

curl https://ip.cn curl icanhazip.com curl ident.me curl whatismyip.akamai.com curl tnx.nl/ip curl myip.dnsomatic.com curl ifconfig.me https://blog.csdn.net/liu0808/article/details/80769810

wiloon, 5/6/2019 12:27

查看当前使用的shell echo $SHELL 命令行式shell(Command Line Interface shell ,即CLI shell) 也就是通过命令行和计算机交互的shell。 Windows NT 系统下有 cmd.exe(命令提示字符)和近年来微软大力推广的 Windows PowerShell。 Linux下有bash / sh / ksh / csh/zsh等 一般情况下,习惯把命令行shell(CLI shell)直接称做shell,以后,如果没有特别说明,shell就是指 CLI shell,后文也是主要讲Linux下的 CLI shell。 cat /etc/shells 3.1、bash Bourne Again Shell 用来替代Bourne shell,也是目前大多数Linux系统默认的shell。 3.2、sh Bourne Shell … Continue reading

wiloon, 5/5/2019 18:22

故事story是粗略的勾勒的需求,它是信!号!卡!,指向真正的需求或者叫故事详情,怎么说都好。 而需求就是需求。 这里隐含了敏捷的一个要素,就是,延!迟!决!策! 当需求不是被细化的摆放着,而是粗略的STORY的时候,才能更好的表达延迟决策。首先我们并不在一开始就把所有的东西都想清楚,而是仅仅以STORY的方式跟踪记录我们未来要做的事情。当开发前,我们才去细化STORY故事,把他变成需求。或者,开发前,我们扔掉STORY,因为它已经不重要了。see。故事可以帮我们更好的做延迟决策。保证所有的事情是在开发前才定下来的,而且保证我们不会遗漏。所以这里,就是为什么敏捷要用STORY而不是需求去进行需求的管理。 作者:马菲菲 链接:https://www.zhihu.com/question/26996772/answer/35078718 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

wiloon, 5/5/2019 17:04

在敏捷项目的估算或计划时,我们常提到以下几个概念。talent.mypm.net   · Epic Storyservice.mypm.net   · Feature项目经理圈子   · Minimal Marketable Feature (MMF)项目管理者联盟   · Theme项目管理者联盟   · User Story项目管理培训   · Tasktalent.mypm.net   本文将说明这几个概念的意义和他们间的关系。项目管理者联盟   1. FeaturePgMp.mypm.net   Feature是可以为顾客提供价值的东西,它代表一个产品可以做什么,或提供什么服务;是可以满足用户的需求,为客户服务,为用户带来真正的价值的成果物的特性。PgMp.mypm.net   Feature相对复杂,可由一组动宾结构的句子表达,如一个超市的交易可以描述为:blog.mypm.net   · 扫描条形码项目管理者联盟   · 显示单价PgMp.mypm.net   · 计算总价项目管理者联盟   · 计算税额项目管理者联盟   · 打印清单项目管理者联盟文章   因此,一个Feature是很难进行估算的,它需要被分解成一个个更小的单位,这就是下面要讨论的User Story。Feature一般在Release Plan的层次,一个Feature可能需要几次迭代才能完成。项目管理者联盟   由于Feature是满足用户需求的交付物,因此每次交付的对象应该是一个或多个Feature。可以说Feature就是敏捷宣言中的“Working software”。转自项目管理者联盟   2. Minimal … Continue reading

wiloon, 5/5/2019 15:42

https://github.com/cdr/code-server docker run \ -d \ –name vscode-server \ -p 8443:8443 \ -v /etc/localtime:/etc/localtime:ro \ -v vscode-projects:/home/coder/project \ –restart=always \ codercom/code-server \ –allow-http \ –no-auth

wiloon, 5/5/2019 12:30

https://www.cnblogs.com/cnxkey/articles/7815434.html hyper -v 如何实现端口映射 如果你是想由虚拟机来提供相应的服务,比如虚拟机里安装web服务,将物理主机的web端口映射到虚拟机,可以使用如下命令进行设置即可,我已经成功了。 一、查询端口映射情况 netsh interface portproxy show v4tov4 查询这个IP所有的端口映射。 netsh interface portproxy show v4tov4|find “192.168.1.1” 二、增加一个端口映射 netsh interface portproxy add v4tov4 listenport=外网端口 listenaddress=主IP connectaddress=私网IP connectport=私网IP端口 例如: netsh interface portproxy add v4tov4 listenport=8888 listenaddress=118.123.13.180 connectaddress=192.168.1.10 connectport=2222 三、删除一个端口映射 netsh … Continue reading

wiloon, 5/1/2019 12:22

Product Backlog由所有的功能特性,包括业务功能,非业务功能(技术、架构和工程实践相关),提升点以及缺陷的修复等组成。这些内容也是将来产品版本发布的主要内容。 一个完整的Backlog是一个蓝图,可以根据它来把产品改造成为我们期望的样子。 但是在Scrum中,Backlog是根据产品和产品使用环境的演化而不断演化的。所以Backlog是动态的,我们会持续的改变它去确保我们的产品是最合理的,最有竞争力的,最有价值的。 当我们去看产品的Backlog的时候,优先级是一个重要的视角,优先级越高的Backlog需要越清晰,越详细。对于优先级低的Backlog,详细程度会越低,直到几乎我们不能认为它是一个Backlog项(非常低的优先级,只相当于一个占位符,来用做提醒)。 评算(Esitimate) 对每个backlog项做估算(包括成本,复杂度,风险,功能点)。优先级越高的Backlog估算要越精确,在估算的过程中可能会导致backlog的优先顺序有可能随之发生变化(对于那些很重要,并且可以快速解决的问题可以先做)。 我们要经常做估算。 创建者(Creater) Backlog内容的来源是多样化的. 产品营销部门会分析产生产品的特性和功能点,销售也会有很多反馈可以使产品更具有竞争力或者取悦某些特殊的客户。产品的架构师或者设计人员也会提出一些技术架构方面或者工程实践方面的需求使得产品更加灵活,更具扩展性,可复用性,开发更高效等等。产品实施或者技术支持部门也会有许多产品缺陷的反馈被放入Backlog。 重要程度(Importance) 每个Backlog项都有优先级,这些backlog项按照优先次序排行队列放在Backlog列表中。在评估的过程中 我需要在“什么样的产品特性,技术架构,缺陷的修复才会给产品公司和它的客户带来带来最大的收益? ” 和”什么样的技术架构,工程方法使我们可以更快,更高质量的交付版本”之间做出抉择。不论是对内部技术环境或者外部市场,我们都需要不断筛选和评估什么是最重要的。 版本发布(Release) 规划接下来的几个版本,包括版本的目标,及可能包含的内容。(我们可能需要在发布内容,开发成本及发布周期之间做出抉择)。 产品Backlog要按照Release分组,要让开发团队的所有成员都全部的了解总体开发目标,并且确保所有的技术问题都做了充分的考虑并且放入了产品Backlog. 负责人(Product Owner) 我们需要指定一个负责人来管理Backlog。这个人的职责是管理和控制Backlog列表,对于商业产品的开发, Backlog的负责人也许会是产品经理,对于内部项目的开发Backlog的负责人有可能是项目经理或者它指派的人。这个负责人的职责是调整产品Backlog的优先级和工作量估算,同时决定哪些内容包括在Sprint中。这是一个各个相关的组织协作的过程。 优先级(Priority) 只有一个人来进行排序的工作,这个人的职责是确保达成产品的愿景,提高产品投资回报率。这个人的职位一般是产品经理或者产品营销经理。如果任何人需要改变优先级,他们必须说服这个负责人去改变。 可视化(Visualization) 产品的Backlog需要能够让开发团队,利益相关者等相关的人能够很容易的看到它的内容,状态,进展等等。 以下是引用《硝烟中的Scrum和XP-我们如何实施Scrum(Henrik Kniberg著)》 中讲述他们如何编写Product Backlog: Product Backlog是Scrum的核心,也是一切的起源。从根本上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序。它里面包含的是客户想要的东西,并用客户的术语加以描述。我们叫它故事(Story),有时候也叫做Backlog条目。 我们的故事包括这样一些字段: ID——统一标识符,就是个自增长的数字而已。以防重命名故事以后找不到它们。 Name(名称)——简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确,这样开发人员和产品负责人才能大致明白我们说的是什么东西,跟其他故事区分开。它一般由2到10个字组成。 Importance(重要性)——产品负责人评出一个数值,指示这个故事有多重要。例如10或150。分数越高越重要。 o 我一直都想避免“优先级”这个说法,因为一般说来优先级1都表示“最高”优先级,如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢?优先级0?优先级-1? Initial … Continue reading

previous page
辽ICP备14012896