项目管理

最近，马丁·福勒( Martin Fowler)2018年在澳大利亚敏捷论坛发表主题演讲，其中阐述了2018年的敏捷状态. 提出干净架构的马丁鲍勃大叔发表文章表示赞同，并总结了该演讲的主要观点: 小心敏捷-工业综

Mathias Verraes (@mathiasverraes) 在Qandidate.com 现场进行DDD建模风暴会议图：

技术业务管理（TBM）是由技术业务管理委员会（TBM Council）创建的协作框架。TBM与IT服务管理（

随着规模的扩大，大型企业和初创公司中的团队往往更倾向于项目思维而不是产品思维。产品思维是一种思维方式和过程。什么是产品思维和项目思维？让我们深入探讨一下，因为如果不首先了解这些事情，我们就无法取得很大进展。注意“何时”和“谁”在项目思维中是最重要的，

开发人员的生产力不能使用单一维度或指标来衡量，需要多维框架，这个称为SPACE的框架捕获了开发人员生产力的最重要方面： Satisfaction满意度和幸福感; Pe

现在的情况是一个interface 类 里面有很多的函数。没有注释，也没有文档，只有代码。很多函数看似很类似，而且对接口函数也没有分类。 所以我想问一下，对于接口函数的分类方法是怎么样的？一般怎么来管理这些接口，20个左右的接口。

史蒂夫·乔布斯是一个传说，他凭着坚定的信念改变了我们的生活。现实情况是，苹果的成功很大一部分来自其团队的推动，他们促使乔布斯重新考虑自己的决定。如果乔布斯不是被一群知道如何改变他主意的人所包围，那么他可能就不会改变世界。 询问所有知识以解释事物的工作原理

对现代流程/项目管理解决方案（PPMS）的期望：1.  合适的PPMS基本上应该提供一个协作环境，无论谁负责任何状态的活动都会更新状态并相应地在系统中提供必要的预期数据。这不仅消除了PM肩上不必要的负担，而且还使项目信息保持最新，因为在系统中提供更新和更新项目之间没有时间滞后。

现在有3种流行的软件工程方法：简单的：不能真正解决问题的简单方法 -Scrum复杂的：可任意选择解决方案 -SAFe1＆2的混合：LeSS现在我们正在踏步于SAFe第二阶段，未来可能更需要第三步，第2步的SAFe到底是什

没有一个尺寸的裤子适合所有人穿，没有银弹，没有一个解决方案适合所有场景。本文概述了各种软件方法学。为什么软件方法学都不同？软件方法论主要是为了对付风险而生，因此方法学规定了特定的日常流程或一系列行动，因此他们还规定了管理软件项目风险的特定方法。

在本文中，我将重点介绍如何有效地评估软件开发性能，并举例说明如何在FXStreet上实现它们。多年来，已经进行了许多尝试来衡量软件团队绩效的困难。问题在于大多数模

虽然称为不容忍，但其实有认真的含义，属于偏执狂才能生存的逻辑。 该文认为:无论是软件开发团队的一员还是“软件开发协会”：对质量的最大影响并不是通过达成共识、投票或者容忍他人的观点或编码方式来实现的。对软件质量产生最大的影响的因素正好与前面描述的共识相反：是

“计划只是未来很多可能发生事情中的一种情况，计划不是对将会发生的事情进行预测。” -肯特·贝克 一直成功的计划就是根本就没有计划 计划是我们为了完成目标而预期采取的行动。 计划不是关于我们准备做什么？而是关于可能会发生什么！ 在

对于一个20人左右的软件项目团队，从项目经理的角度出发，哪种项目管理工具比较合适呢，更看重团队中的各成员的操作方便。请路过的前辈们指教。[该贴被shefansxyh于2014-11-13 16:49修改过]

当我们考虑如何以最好的方式做事时，首要考虑的是不要以最糟糕的方式做事并阻止以错误的方式做事，Poka-Yoke（“防错”）——这不仅仅是一个听起来很棒的词，而且是丰田防止用户错误操作的方法的一部分。例如，要启动汽车，你的脚必须踩在刹车上，然后才能启动汽车，这样来防止你做错事。

故事点有两个目的： 1：强迫团队讨论并就工单的范围达成一致 2：让产品经理大致了解完成一组工作需要多少个 sprint，以及每个 sprint 可以完成多少工作。 对于利益相关者，甚至不会向他们提及故事点。他们唯一需要知道的是团队估计完成他们想要完成