8个面向敏捷开发团队的 敏捷开发工具推荐
创新互联公司提供网站设计制作、网站建设、网页设计，品牌网站制作，一元广告等致力于企业网站建设与公司网站制作，十余年的网站开发和建站经验,助力企业信息化建设，成功案例突破上千,是您实现网站建设的好选择.
AGILE DEVELOPMENT TOOLS INTRODUCE
在这篇开源项目管理工具的综述中让我们来了解一下支持 Scrum、 看板(Kanban) 等敏捷开发模式的软件。
1、 MyCollab
敏捷开源项目管理工具之①
MyCollab 是一套针对中小型企业的三个协作模块套件：项目管理、客户关系管理（CRM）和文档创建和编辑软件。有两个许可证选项：一个商业的“终极”版本，它更快，可以在内部或云中运行；另一个开源的“社区版本”，这个正是我们感兴趣的版本。
由于没有使用查询缓存，社区版本没有云方式，并且速度较慢，但是提供了基本的项目管理特性，包括任务、问题管理、活动流、路线图视图和敏捷团队看板。虽然它没有单独的移动应用程序，但它也适用于移动设备，包括 Windows、Mac OS、Linux 和 UNIX 计算机。
2、 Odoo
敏捷开源项目管理工具之②
Odoo 不仅仅是项目管理软件；它是一个完整的集成商业应用套件，包括会计、人力资源、网站和电子商务、库存、制造、销售管理（CRM）和其它工具。
与付费企业套件相比，免费的开源社区版具有有限的 特性 。它的项目管理应用程序包括敏捷团队的看板式任务跟踪视图，在最新版本 Odoo 11.0 中更新了该视图，以包括用于跟踪项目状态的进度条和动画。项目管理工具还包括甘特图、任务、问题、图表等等。Odoo 有一个繁荣的社区，并提供 用户指南 及其他培训资源。
3、 OpenProject
敏捷开源项目管理工具之③
OpenProject 是一个强大的开源项目管理工具，以其易用性和丰富的项目管理和团队协作特性而著称。
它的模块支持项目计划、调度、路线图和发布计划、时间跟踪、成本报告、预算、bug 跟踪以及敏捷和 Scrum。它的敏捷特性，包括创建 Story、确定 sprint 的优先级以及跟踪任务，都与 OpenProject 的其他模块集成在一起。
4、 OrangeScrum
敏捷开源项目管理工具之④
正如从其名称中猜到的，OrangeScrum 支持敏捷方法，特别是使用 Scrum 任务板和看板式工作流视图。它面向较小的组织自由职业者、中介机构和中小型企业。
开源版本提供了 OrangeScrum 付费版本中的许多 特性，包括移动应用程序、资源利用率和进度跟踪。其他特性，包括甘特图、时间日志、发票和客户端管理，可以作为付费附加组件提供，付费版本包括云选项，而社区版本不提供。
5、 ]project-open[
敏捷开源项目管理工具之⑤
]project-open[ 是一个双许可证的企业项目管理工具，这意味着其核心是开源的，并且在商业许可的模块中可以使用一些附加特性。根据该项目的社区和企业版本的 比较，开源核心为中小型组织提供了许多特性。
]project-open[ 支持带有 Scrum 和看板功能的 敏捷 项目，以及经典的甘特/瀑布项目和混合或混合项目。
6、 Taiga
敏捷开源项目管理工具之⑥
Taiga 是一个开源项目管理平台，它专注于 Scrum 和敏捷开发，其特征包括看板、任务、sprints、问题、backlog 和 epics。其他功能包括凭证管理、多项目支持、Wiki 页面和第三方集成。
它还为 iOS、Android 和 Windows 设备提供免费的移动应用程序，并提供导入工具，使从其他流行的项目管理应用程序迁移变得容易。
Taiga 对于公共项目是免费的，对项目数量或用户数量没有限制。对于私有项目，在“免费增值”模式下，有很多 付费计划 可用，但是值得注意的是，无论您属于哪种类型，软件的功能特性都是一样的。
7、 Tuleap
敏捷开源项目管理工具之⑦
Tuleap 是一个应用程序生命周期管理（ALM）平台，旨在为每种类型的团队管理项目——小型、中型、大型、瀑布、敏捷或混合型——但是它对敏捷团队的支持是显著的。值得注意的是，它为 Scrum、看板、sprints、任务、报告、持续集成、backlogs 等提供支持。
其他的 特性 包括问题跟踪、文档跟踪、协作工具，以及与 Git、SVN 和 Jenkins 的集成，所有这些都使它成为开放源码软件开发项目的吸引人的选择。
以下是我学习iOS时的学习步骤：
1、开发环境及工具。首先一定要配置好开发环境及开发工具，才能做后续的学习。
2、开发语言。这是学习iOS的重点，以后你的应用就需要使用这种语言来开发App。重要性不言而喻。这个学习的过程就是多看书，多练习。
3、iPhone/iPad 开发基础。在这一阶段你需要了解iPhone/iPad开发中常用的控件，多做Demo，下一些别人的code，多参考研究
4、代码的优化及复用。这一阶段就需要你有更高的追求，不只是要完成功能，还有让自己写的代码更优化，复用性更强
08年的7月11号，当苹果发布iPhone3G并推出AppStore和iOS开发SDK之后，iOS开发正式出现了。随着iPhone的热卖，App作为移动互联网的入口凸现了它的巨大价值，无数创业团队开始纷纷开发自己的App，iOS开发的身价也是水涨船高。由于苹果提供了完善的开发工具和健全的App市场，App的设计与开发只能按照苹果的标准来，所以 320X480 的尺寸成了设计师们设计App的标准尺寸。
这个标准到2012年发布iPhone5之前一直是金科玉律，设计师无须关心什么是px(pixel)，什么是pt(point)，原因是早期的iPhone中，像素和点是对等的；后来虽然有点小插曲出了retina屏幕，设计师设计时也只需要把原来的尺寸放大一倍即可，开发人员会默认缩小一倍做开发。可以说苹果当时是非常照顾开发和设计人员的，即使升级了retina屏幕，开发和设计之间的默契马上会自动达成。但这也给之后埋下了隐患。
iPhone4s是乔布斯的遗作，但它也可以看作是小团队开发iOS应用浪潮中泡沫的分水岭。
之后问题开始慢慢暴露了。首先是iPhone5变长了，当时我们都挺惊讶的，连忙去确认了尺寸，发现屏幕从{320,480}变成了{320,568}。有经验的iOS开发通过动态计算屏幕高度马上解决了这个问题。然后，开发同学和设计同学沟通好，把效果图和标注图的尺寸改成了{640,1136}。这次苹果的改动其实并没有影响原来开发的方式和设计的原则，所以可是说是虚惊一场。
但是好景不长，iPhone6和iPhone6 Plus出现了，苹果第一次在一场发布会上发布2款不同尺寸的手机。这时候，iOS攻城狮心中是一群草泥马在万马奔腾。从那时起，开发和设计之间的问题就彻底暴露了。
当然，苹果也给了一个万金油的方案，如果我们什么都不改，App会在iPhone6和iPhone6 Plus等大屏手机上自动等比放大展示。作为企业级的App，怎么能容忍放大版的App在iPhone6 Plus上显示呢（因为它真的很大）。然后，我们给不同尺寸的机型补上了不一样的启动图(示意图如下)。
验证完所有需要支持的iPhone机型，我们得到了4种不同的屏幕尺寸，分别是{320,480}，{320,568}，{375，667}，{414,736}(示意图如下)。
开发同学一看到需要给App开发4种尺寸时，一开始的心态是闷逼的。设计人员也纳闷到底拿哪个尺寸做效果图呢。因为都没有经验，一开始我们继续让设计师用{640,1136}做标注图，这样我们结合屏幕的宽度和高度，可以很快的调整好不同尺寸下的布局。
随着iPhone6和iPhone6 Plus的大量普及以及高端Android手机市场份额的提升，之前{640,1136}做的效果图在真机上展示很不理想，于是设计师们把效果图的设计尺寸改成了{750,1334}，而且还考虑用{1080,1920}做效果图。一般设计师们都是在效果图上直接做标注，由于效果图尺寸变成了{750,1334}，我们iOS开发拿到标注图的尺寸也变成了{750,1334}。然后，开发拿着px做各种换算，碰到了各种奇怪的问题，做出来的页面和效果图的差距总是很大。我列举下几个常见的问题：
其实，当设计师用小屏幕的规范去设计大屏幕时，设计稿已经出问题了。比如在小屏幕的时候，定义了最小字号为9号，9号字在PS上{750,1334}的设计图起来还可以，但在真机retina屏幕上看起来就很小，视觉落差特别大。设计师一看效果不对，就让开发加大字号；字号变大后，小屏幕的字体就感觉特别大，然后让开发分屏幕对待，小屏幕不变，大屏幕加大字号；开发拿着{750,1334}尺寸的px标注图，总感觉之前除以2后的宽高在小屏幕上显示不对，于是又用(屏幕宽度/320)搞了个比例系数，而且将错就错的在所有的宽高上乘以该系数。
然后在敏捷开发的团队里，设计师和工程师都开始怀疑人生了。设计师总感觉设计稿和真机效果差别很大，工程师总感觉实现的跟标注图不一致。最后只能通过海量的微调来达到看起来差不多的效果。
说到现在，我们差不多明白问题出在哪里了。
首先是设计师的设计规范需要修订了，之前用在小屏幕上的设计规范不能生搬硬套在大屏幕上，需要重新修订设计规范，兼顾小屏和大屏。
然后是工程师需要更加深入的了解iPhone的渲染机制了，否则px和pt会搞得傻傻分不清。有朋友会说，px和pt怎么会搞不清楚呢，1pt在iPhone6(包括iPhone6s)之前都是2px，在iPhone6 Plus和iPhone6s Plus上是3px。但是当你做出来的效果总是跟设计师的标注图不一样时，你是不是会怀疑自己实现错了。当你觉得设计师标注有问题时，你又怎么说明缘由然后告诉设计师一个误差较少的方案呢？你要明白设计师现在以不再是单独为iOS开发做设计了，还要兼顾Android和H5页面。
所以，我们需要静下来好好研究下iPhone现在是怎么渲染的，然后找到一个靠谱的方案让设计师对标注图做调整。
在iOS开发中，point是抽象单位，它只在iOS系统给我们抽象出来的数字坐标系中有意义，与pixel没有直接的关系。之前我们常说1pt等于2px，1pt等于3px，这些等式之所以成立是因为我们无意识中都给等式加了一个附加条件，那就是在某种机型下。所以之后的机型说不定就有1pt等于4px，1pt等于5px的情况。
当我们在数字坐标系中绘制完界面后，iOS系统就开始在内存中渲染适合当前手机屏幕的页面尺寸，这个时候，渲染的单位就是pixel了。用基于点的图形使用像素进行渲染，这个过程叫做光栅化。像素坐标系是通过点坐标系乘以一个比例因子来获得的。比例因子越大，屏幕的像素密度越大，现实效果就越好。而我们常说的1倍、2倍、3倍就是比例因子。
但是在iPhone6Plus中，屏幕的物理像素只有{1080,1920}，而内存渲染的像素却是3倍的点坐标系{1242,2208}。为了正常显示，iPhone6Plus在显示的时候做了一个 缩减像素采样 (downsampling)的操作。现在我们明白iPhone6Plus的屏幕分辨率为什么不是3倍了。
为了证明iPhone各种机型上渲染的像素是不同的，我们来比较下1个点宽度的线是怎么渲染的。下面是示意图：
这个缩放比率是 1920 / 2208 = 1080 / 1242 = 20 / 23。这意味着iPhone原始渲染的过程中，每23个渲染像素必须映射到20个物理像素上。换句话说，图片被缩放到了大约只有原始大小的87%。
下面，我们从宏观的角度来看看不同的iPhone机型是怎么适配的。请看下图：
搞清楚iPhone的渲染机制后，我们也知道了如何让设计师调整标注图了。之前，设计师为了兼顾Android和H5页面的效果图，把效果图大小调整为{750, 1334}；考虑到工作量，设计师会在效果图上直接出标注，按照之前的约定默认的单位就px。对于开发人员，拿着{750, 1334}单位是px的标注图，他的第一反应是这是iPhone6的标注，iPhone6 plus和小屏的标注只能自己算了。下面我们拿左边距15px做例子：
这么算下来，感觉pt总是算不对。问题出在 不同手机屏幕上相等的视觉长度它们的像素是不同的 ，所以渲染15px的左边距，不同手机上的视觉边距都不一样。如果想在不同手机屏幕上让左边距看起来都一样，我们必须使用pt为单位，原因我们在上面介绍iPhone渲染机制中已作了说明，这里不再赘述。
其实，设计师关注的点也就是标注的内容在不同手机屏幕上显示的效果一样，比如左边距。对于特殊的适配情况，设计师自然会给不同分辨率下的标注。而之前的原因出在我们开发人员没有向设计师解释清楚 不同屏幕上渲染相等的视觉长度，像素是不一样的，但渲染的point是一样的 。后来，我们换成了pt作单位，绝大多数实现不准确的问题都被解决了，对于定高定宽的情况，标注时也做了特殊说明，而且也都换成了相对布局的方式进行标注；最后，拿一张我们最近的标注图做示例。
终于写完了，感觉自己文笔有限，语句多不通顺，但你要明白一点， 不同手机屏幕上渲染相等的视觉长度，pixel是不一样的，但渲染的point是一样的 。希望这篇iOS标注解惑能让你了解pixel和point本质的区别。最后欢迎大家积极回复留言，交流心得。
有。垫付的行为是诈骗，不要相信垫付这件事。
1、iOS企业开发者账号，或者苹果企业开发者账号，是苹果公司推出用来进行敏捷开发，加快团队开发和测试而使用的，还可以用在MDM移动设备管理上。2、年费299$，使用该证书不能把app上传到appstore。仅能用于公司内部测试，或者内部使用的app，如办公软件等。该证书的申请需要公司才可以申请，关于他的申请以及如何获得大家可以咨询。
重庆分公司
重庆分公司
