rer*_*run 9 agile development-process
我们有一个大型企业应用程序,其中项目的范围设计,最后使用正式的瀑布流程进行编码.我经常为非相关计划进行代码更改,因为它们位于相同的代码段中.所有举措必须同时进行.开发团队对范围或交付时间线也几乎没有发言权.我们无法与用户交谈,我们必须通过一组不了解业务的需求收集人员.
是否有人就如何在这样一个根深蒂固的环境中实施最小的敏捷技术提出任何建议.
至少你可以开始编写单元测试,甚至 - 尽管情况允许 - 自己测试驱动开发(也可能在你的同事共同开发者之间传播这些想法).你可以在没有管理的情况下改变很多甚至注意到任何事情;-)
当然,在平均或更好的地方,管理层的人并不是完全愚蠢的.随着时间的推移,当您设法在开发团队中提高对这些问题的认识时,您(作为团队,集体)也可以与高层管理人员交谈,并说服他们采取措施朝着正确的方向发展.从小规模开始,获得具体结果,并以此为基础 - 通过在开发团队中寻找盟友并在管理层和用户之间尽可能地寻找盟友来建立杠杆.
通常只遵循某些过程,因为"我们总是习惯这样做".如果你能向人们展示有更好的方法 - 并用令人信服的论据来证明 - 你很有可能取得成功.请注意,管理和用户需要与开发人员完全不同的参数.您可以尝试进行粗略的成本效益计算(或谷歌 - 我很确定网上有很多关于这些的东西).我还记得Kent Beck的第一本XP书中有关于此的很好的材料.您还可以收集错误统计信息,随着时间的推移(希望)显示以敏捷方式开发的功能在以后(集成测试或生产)阶段明显减少缺陷.(为此你需要一个缺陷跟踪系统,如果你还没有.)
另一个有用的工具是提问.如果你的东西 - 文件,做事的方式 - 你不明白,敢于提出问题:
通常人们只是把事情视为"给定",但当你开始询问原因时,你可能会发现许多有趣的事情......以及改进的想法.
一个非常有用的敏捷工具是回顾.在每次迭代之后(无论在实际过程中调用它),团队聚集在一起并进行头脑风暴
这可能很容易被管理层接受,并且是开始积极变化的好方法.最重要的是唤醒和激活人 - 让每个人都意识到项目的成功或失败(至少在某种程度上)在他们自己手中,他们可以做些什么来改善这种状况.