在敏捷的工作环境中,我的工作方式应该如何改变?[关闭]

Agile 它实际上是一组基于迭代开发的软件开发方法,其中需求和解决方案通过自组织跨功能团队之间的协作而演化。一个人很难做到。

• 小件工作。 你想把你的任务分解成能在合理时间内完成的部分。(我工作过的团队通常以半天为单位进行测量。因此,您一天可以完成2个单位的工作,一周可以完成10个单位的工作。)
• 编写单元测试。 你的团队正在为代码编写单元测试,对吗?如果没有,那就从现在开始。编写单元测试将迫使您构建可测试的代码,这也将迫使您改进实现和设计。它还将检测回归错误,通过检查以前在有人做出更改时工作的所有内容。
• 任何时候你需要修复一个bug,首先写一个单元测试,它会导致你的代码以与bug相同的方式失败。然后修复你的代码。如果修复是好的,那么您的单元测试现在应该通过了——并且您的所有其他单元测试都应该继续通过。
• 构建新代码时,应该按照规范进行构建。确保规范良好的最佳方法之一是使用规范为代码编写单元测试。一旦有足够的测试来验证要编写的代码,就开始工作,根据测试测试代码。一旦代码通过测试,就可以提交到团队存储库。
• 使用持续集成。 这是团队本身应该做的事情,但是如果你能使用一台额外的PC(它不一定要快,只要有足够的内存和磁盘空间来构建你的工具和软件)。加载 CruiseControl.net 或 Hudson
• 在使用持续集成之前,您需要能够在没有人为干预的情况下重复构建软件。如果您使用的是visualstudio,请学习如何使用MSBuild或Nant生成。如果您正在使用Java,请学习如何使用Ant或Maven进行构建。通过自动生成,可以避免与手动步骤相关的生成和发布问题。(我曾经将一个项目的构建过程从一个每周需要两名专业人员才能完成的笔记本缩减为一组大约需要一个小时才能运行的脚本——你最好相信这样可以提高发布的质量。)

这听起来像是每天开会的瀑布。实施敏捷是一个很大的不同,你不能自己从瀑布式转变为敏捷式,你需要其他人跟随它工作。

我认为最大的改变将是停止在“项目”范围内思考,而开始以非常小的增量来思考工作。例如,当项目“createwebsitexx”出现时,您需要将其逐页分解。确定需要做什么,如何准确地获取、存储、更新和显示数据。需要多长时间来编写完成这项工作所需的不同代码段?一旦计划好了(根据我的经验,敏捷中涉及到更多的计划),你就可以开始说“到星期三,我将向你们展示我可以保存在第X页上的数据,我将在第Y页上显示数据”。

通常有一个“计划”会议。这可能需要一个小时,也可能需要6个小时,这取决于你的标准传达得有多好,团队中有多少成员,以及你的冲刺时间有多长。每个人都选择自己要做的工作,并对其进行评估。在你的sprint(大多数人建议是一到两周)之后,会有另一个会议。理想情况下,在这个会议上,每个人都将演示他们在过去一周所做的事情,并且它将完美地工作。后来有一些反思,什么效果好?我们是不是估计错了什么?

这是一个“周期”,这样做~50次,网站X是完整的!:)

首先,世上没有 这个 敏捷方法论”,敏捷是一个总括性的术语,描述了几种敏捷方法论,如果你的工作场所所做的只是站出来,我已经可以告诉你,这并不能使工作场所变得敏捷。

第二,虽然您可以在个人级别采用一些“敏捷实践”(尤其是工程实践),但这永远不足以使您变得敏捷:1。在我看来,敏捷更多的是关于驱动产品开发的方法,而不是工程实践2。敏捷是一种集体的团队游戏。

所以,我的建议是深入研究 Scrum and XP from the Trenches 为你的同事、老板或潜在的赞助者准备一些副本。

恭喜你站起来。这是一个很好的第一次改变。

你的要求表明你或团队希望在这方面做得更好。在这种情况下,您可以选择以下两种方式之一:

• 增量改进

如果你决定你想要一个巨大的改变,你可能需要一些书籍,培训,也许一个教练或有经验的从业者在身边。如果组织高层也投入到变革中,这通常是成功的。

如果你决定要渐进式地改进,那么围绕敏捷进行阅读就有必要获得一些想法。我推荐“XP解释”。外面也有很多博客,这里也有帖子。你需要做的两件事是:

• 试着交付一些软件,或者至少从涉众那里得到反馈

我们通常用展示来做第一件事,用回顾来做第二件事。我建议至少每两周进行一次回顾,即使展示工作代码非常困难。

• 团队不在同一地点(“团队”包括BAs和QAs)
• 环境不适合
• 对正在进行的工作或总体目标缺乏可见性
• 太多的工作在进行中-事情开始了,但没有完成
• 没有人真正关心的正在进行的项目
• 项目进展很明显,这是不值得做的
• 责备文化阻碍合作。

祝你好运!

1. 将现有项目任务/点/待办事项转换为用户情景
3. 使用测试驱动开发。争取100%覆盖!
4. 使用一周的迭代。重复就是学习!
5. 在每次迭代中向客户交付有价值的软件。

即使整个团队没有以敏捷的方式工作,作为开发人员也很少有可以采用的实践。您可以从CI、TDD和automated deploy开始。作为一个团队,你可以尝试回顾会议。