阅读Martin Fowler的The New Methodology的心得体会---乌托邦式的开发
1.敏捷方法是适应性的而不是预知性的(adaptive rather than predictive),是面向人的而不是面向过程的(people-oriented rather than process-oriented)
2.代码就是设计文档(source code is a design document)
对于传统的工程学,设计与构建是可以分离的.但是对于软件工程来说,所有的工作都是设计性的.
3.需求是不可预知的和不断变化的,尝试去预测不可预知的需要是危险的
一些软件公司先把需求写好,让用户签字确认.然后以该需求文档为中心进行开发,其间只允许极小的需 求变化.不过这是不可行的或者说是不负责任的做法.
需求变化是很令人头痛的.当你在做一个商业软件时,即使客户不想改变需求,他所处的市场环境也迫使 他改变,所谓商场如战场.曾经做过一个该类型的软件.结果是软件一直在做,需求一直在改,当时感觉是 这个项目好像永远做不完那样.
4.以人为本!开发人员不是拿来就兼容的编程单元
5.开发人员应该更积极的参与到项目中去,自己制订工作计划
开发人员应该与管理人员和用户保持紧密联系.的确,由于软件是做出来供人使用的,所以开发中应该掺杂更多人的因素.这就促使了软件开发涉众要紧密联系.开发人员应该积极主动的参与到项目的管理中去,与管理人员地位相同,并且应该由开发人员决定如何开展项目---这个观点与传统的管理学理论的观点存在矛盾.
6.应该怎样开始尝试敏捷开发?
应该找一个项目规模在比较容易管理的范围之内的项目开始尝试敏捷开发.该项目最好不要是一些毫无重要性的项目.
7.敏捷开发应用范围不单单是较小的项目.
8.不能强迫不愿意使用敏捷方法的开发团队去使用该方法.对于不愿遵循敏捷方法的客户,要尽量使他们参与到项目中来.
2.代码就是设计文档(source code is a design document)
对于传统的工程学,设计与构建是可以分离的.但是对于软件工程来说,所有的工作都是设计性的.
3.需求是不可预知的和不断变化的,尝试去预测不可预知的需要是危险的
一些软件公司先把需求写好,让用户签字确认.然后以该需求文档为中心进行开发,其间只允许极小的需 求变化.不过这是不可行的或者说是不负责任的做法.
需求变化是很令人头痛的.当你在做一个商业软件时,即使客户不想改变需求,他所处的市场环境也迫使 他改变,所谓商场如战场.曾经做过一个该类型的软件.结果是软件一直在做,需求一直在改,当时感觉是 这个项目好像永远做不完那样.
4.以人为本!开发人员不是拿来就兼容的编程单元
5.开发人员应该更积极的参与到项目中去,自己制订工作计划
开发人员应该与管理人员和用户保持紧密联系.的确,由于软件是做出来供人使用的,所以开发中应该掺杂更多人的因素.这就促使了软件开发涉众要紧密联系.开发人员应该积极主动的参与到项目的管理中去,与管理人员地位相同,并且应该由开发人员决定如何开展项目---这个观点与传统的管理学理论的观点存在矛盾.
6.应该怎样开始尝试敏捷开发?
应该找一个项目规模在比较容易管理的范围之内的项目开始尝试敏捷开发.该项目最好不要是一些毫无重要性的项目.
7.敏捷开发应用范围不单单是较小的项目.
8.不能强迫不愿意使用敏捷方法的开发团队去使用该方法.对于不愿遵循敏捷方法的客户,要尽量使他们参与到项目中来.
