欢迎大家赞助一杯啤酒🍺 我们准备了下酒菜:Formal mathematics/Isabelle/ML, Formal verification/Coq/ACL2, C++/F#/Lisp
Agile software development
来自开放百科 - 灰狐
(版本间的差异)
小 (→文档) |
小 (→开发组合) |
||
第23行: | 第23行: | ||
* 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。http://www.pkminfosolutions.com/ | * 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。http://www.pkminfosolutions.com/ | ||
− | == | + | ==项目== |
* [[Ruby]] on [[Rails]] | * [[Ruby]] on [[Rails]] | ||
* [[Python]] on [[Django]] | * [[Python]] on [[Django]] | ||
* [[Groovy]] on [[Grails]] | * [[Groovy]] on [[Grails]] | ||
+ | *[https://github.com/sercxtyf/onboard Onboard] 敏捷软件开发协同工具 | ||
==文档== | ==文档== |
2016年6月13日 (一) 12:51的最后版本
您可以在Wikipedia上了解到此条目的英文信息 Agile software development Thanks, Wikipedia. |
敏捷软件开发模型--Scrum
敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,他们认为:
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
并提出了以下遵循的原则:
- 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
- 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
- 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
- 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
- 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
- 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
- 工作的软件是首要的进度度量标准。
- 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
- 不断地关注优秀的技能和好的设计会增强敏捷能力。
- 简单是最根本的。
- 最好的构架、需求和设计出于自组织团队。
- 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。http://www.pkminfosolutions.com/
目录 |
[编辑] 项目
[编辑] 文档
- Thinking, Fast and Slow, with Software Development
- BDD in Action
- Mastering Security in Agile/Scrum, Case Study
- 敏捷团队的项目质量管理
- 敏捷项目管理在互联网公司中的应用
[编辑] 链接
- http://agilewebdevelopment.com/
- http://agilemanifesto.org/
- http://www.agilealliance.org
- http://www.agileskills.org/
- http://www.xprogramming.com
- 敏捷软件开发资料站
- 将看板应用于软件开发:从敏捷到精益
- 敏捷和模块化的关系
一个实体要“敏捷”,它的结构就需要有高度的模块化。因此,关于敏捷的问题应该从“如何构建敏捷的业务系统?”变成“如何构建高度模块化的业务系统?”
[编辑] 公司组织
分享您的观点