标签: agile

有许多敏捷软件开发方法.您在实践中使用了哪些成功项目,以及该方法如何为成功做出贡献？

在您的“企业”工作环境中，工程师如何对执行代码检查和单元测试负责？您遵循什么过程（正式方法或自定义过程）来确保软件质量？您是否尝试过为可交付成果实施开发人员“签署”工作表？

提前致谢！

更新：我忘了提到我们正在使用Code Collaborator进行检查。问题在于让人们“得到它”并愿意在一群核心人之外去做。正如跟踪专家在下面指出的那样，这是文化的变化，但是问题就变成了，您如何改变自己的文化以促进诸如审查/单元测试之类的高质量计划？

想象一下,你为一家小型精益软件公司工作.您知道公司未来的竞争力在于拥有良好的可重用代码库.管理公司的再利用政策以确保您今天的交付,同时为未来提供支持,这将是非常重要的.

在我看来,在业务中编写可重用代码有两个原因; 1)在公司内共享以提高未来的速度和效率2)在网络上发布和其他人将有助于改进代码(从某种意义上说是众包).

开发人员应该始终运用常识来重复使用.但是为了从管理角度处理这个问题,我想要一些整体的代码重用指南,以确保我们现在和将来都具有竞争力.这些指南应鼓励开发人员询问"我的代码是否为重用候选人？".这些指导方针应该说什么？

我最初的想法:在最低级别编写可重用的代码是不值得的(例如,我有一些内联代码在字符串的末尾添加了一个"s"),这个代码的代码太多了.甚至筛选,发现有人已经做过了.在最顶层(即应用程序)编写可重用代码也是不值得的,因为您的客户报告应用程序最终会被通用化为SQL客户端 - 对大多数用户来说是无用的.

可重复使用代码的主要障碍:除非您知道它存在,否则不能重复使用它; 信任 - 它已经完成,但你相信吗？使代码通用/可重用(并记录)的初始时间.

目前我们使用Trac来管理我们的所有门票(错误,增强功能和新项目).它缺乏很好的能力来绘制项目,发布和做时间估计.是否有一个良好的Scrum项目管理系统可以与Trac集成以使用我们已经制作的门票？

我一直在研究不同的编程方法:Scrum,瀑布,螺旋,但有人讲述了一个名为面向对象的方法.据我所知,这是一种范式,而不是一种方法论.

如果是一种方法论,有人可以解释它与敏捷或瀑布的区别吗？

在构建实施软件之后,PMBOK是更多的用于向客户提供,而Agile或Scrum更适合用于构建软件吗？只是想了解.

谢谢.

编辑:我主要担心的是PMBOK.他们在我工作的地方使用它很多但不用于开发(他们用它来实现.)它们没有发展很多,所以我没办法问,"嘿,你用什么来开发？" 我必须自己想出最好的计划.我真的不太关心PMP认证,但如果这是使用PMBOK开发软件的最佳方式,我可以证明它是合理的.如果scrum或敏捷是最好的方式,那么我宁愿使用它并且比我的名字有一个pmp更成功.

在Scrum和/或其他敏捷方法中,您如何简单地处理需求版本？我认为有很多组织都是敏捷的,但也需要跟踪需求变化以达到监管目的等等.

您可能在版本1中有一个要求在版本8中有实质性更改.您如何跟踪版本之间的这种更改？

在Scrum或Agile团队中,产品所有者是否建议参与多个产品？拥有企业系统的产品负责人和该系统组件的"子"产品所有者是否合适？也就是说,在零售商中你是否有一个企业系统的PO,可以推动零售,供应链和制造业的"子"PO？

感兴趣的是其他人如何在企业环境中处理Scrum团队,而许多利益相关者都处于功能孤岛中.

在研究软件方法时,我经常看到免责声明"这种方法需要一个成熟的开发团队".

哪些开发方法专门针对不成熟的开发团队？ 我认为这是大多数球队应该开始的地方.

让我们将一个不成熟的团队定义为一个团队,其成员以前没有合作过,在一个未知的环境(即新公司)工作,还没有定义他们的流程和控制.

根据这篇Scrum文章:

故事点是相对值,不会直接转换为特定的小时数.相反,故事点可以帮助团队量化用户故事的总体大小.这些相对估计不太精确,因此它们需要较少的努力来确定,并且随着时间的推移它们会保持更好的状态.通过估算故事点,您的团队现在将提供用户故事的一般大小,并在团队成员即将实施用户故事后,开发更详细的工作小时数估算.

任何人都可以澄清:

1. 故事点的测量尺度应该是多少？它应该是在给定产品积压中分配的10,100或最高故事点吗？
2. (一点偏离主题)"产品积压项目"(检查附加图像)包含项目的所有用户故事,而sprint积压包含产品积压中的故事子集.话说回来; 如果一个产品积压足够,那么为什么TFS允许我们有多个产品积压项？