标签:har evel linear none scrum cin weight 时间 roc
第13.2.5节提到“探索式测试是团队管理不佳的一个标志”,我的疑惑是,会存在Bug Trash的效果总是优于单元测试/集成测试的情况吗?以及进行能否通过程序来模拟这种探索性测试?
在第16章里提到了IT行业的创新,提到了要成为领域的专家,才能创新。那作为一名还在还在学校上学、接触项目经理还很少的学生,该怎么进行培养创新意识?我们怎么才能认为一个创新是可实现的创新,因为我有时想出我觉得不错的点子,但总是觉得技术要求太高而觉得遥不可及,因此改怎么去发掘其可能的价值?
关于第8章的需求分析,我觉得需求分析的设计/制定不能太满,即得留出空间给后期开发的时候补充,这样也算给用户一个选择的空间。就像草坪留出道路给人踩出路径再铺石头一样,可能会起到更叫的效果,不知道这样的想法可行吗?
在第三章讲到的关于软件工程师的成长,作为大三学生,如果想未来从事一名软件工程师,目前应当注意培养哪些技能?
两人合作应不应该确定一名leader? 应当是风格相近的还是比较互补的作为两人合作比较合适?
概念 | 提出时间 | 地点 | 提出人 |
---|---|---|---|
软件 | 1953.8 | 兰德公司的研究备忘录 | Richard R. Carhart |
软件工程 | “阿波罗”太空计划期间 | NASA | Margaret Hamilton |
敏捷宣言诞生记
2001年2月11日至13日,在美国犹他州瓦萨奇山雪鸟滑雪胜地,17个人聚到一起,交谈、滑雪、休闲,当然还有聚餐。他们试图找到共识,最终的成果就是《敏捷软件开发宣言》(Manifesto for Agile Software Development)。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。
由全体参会者签署的《敏捷软件开发宣言》(Manifesto for Agile Software Development)成为了重要标志,因为这么大一帮无政府主义者能聚到一起实在是太不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心,他认为多数美国人都不知道“敏捷”这个词如何发音。
Alistair Cockburn和很多参会者一样,最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后,他再次分享了自己的感受。“对我来说,很开心宣言能够最终定稿。而让我感到惊讶的是其他人也同样开心,因此我们的确达成了某种实质性共识。”这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站首页的《敏捷软件开发宣言》,他们称自己为“敏捷联盟”
软件 | 优点 | 缺点 |
---|---|---|
Microsoft TFS | 集成性 | 搭建、维护复杂 |
Git | 分支切换快速 | 操作繁琐,命令有些不一致 |
Mercurial | 操作简单、跨平台 | 分支切换不方便 |
Github | 流行 | 中文支持差,价格高 |
Bitbucket | 对提交大文件友好 | 用户少 |
Trac | 灵活、可扩充 | 功能缺乏 |
Bugzilla | 支持定制 | UI不好看 |
Rationale | 创建争论地图、推理方便 | 中文支持差 |
Apple Xcode | 编译快 | 只面向OSX 语言少 |
主要参考维基百科、百度百科等
标签:har evel linear none scrum cin weight 时间 roc
原文地址:http://www.cnblogs.com/ohazyi/p/7599199.html