移动开发敏捷实践

1,603 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,603
On SlideShare
0
From Embeds
0
Number of Embeds
109
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 介绍我们正在做的iphone到Android的移植项目克服这些困难需要技术上,流程上,团队上各个方面的配合。由于对新技术掌握有一个过程,项目当中容易积累技术负债。互动:大家在移动平台的项目中遇到哪些挑战?
  • 互动:有多少心动?有多少行动?没有包治百病的膏药,但有可借鉴的例子
  • 正如前4点列出的挑战,团队在技术上和敏捷实践上和要求的还有一定差距,如何在短时间内缩短这些差距?结对编程对流程和技术都能起到培训作用正式代码评审在这样的团队当中并没有效率自组织减少了管理的需要,并能提高总体产出清晰定义的DoD使团队对要完成的东西有明确的概念
  • 我每次被指派这样的角色与职责我都浑身不舒服,你只要尽力去做对项目对团队最有贡献的事不就完了。
  • 如果你是一支新组建球队的教练,你怎么预先指定谁踢哪个位置?那会是最好的方式吗?
  • 团队成员根据自己的能力,兴趣与性格等因素进行磨合
  • Done Done级别的DoD
  • 开发人员编写所有测试
  • Dalvik VM运行非常慢和消耗CPU单元测试可以在1分钟内完成
  • 录像
  • 需要30分钟运行完所有测试
  • 通过自底向上设计,提高代码的表达能力,减少了代码行数和复杂度
  • Domain Object框架
  • 项目初期开发能力“过剩”,设计能力不足DoD已经保证的代码覆盖率,降低了重构的风险从而打破先设计还是先交付的困境开发人员的到参考实现后可以提高今后的代码质量
  • 需要设置Maven项目的版本号
  • 需要使用Emma,把Sonar内置的coverage库手工删掉
  • 主要找到的重复是超过1个方法的接口实现
  • 问题更快的到修复对自己的代码更有责任感
  • 初期:由于对新技术不熟悉,代码质量不高,但开发效率也不高,并不能产生太多负债中期:对技术开始熟悉,但认识还不到位,代码质量也不高,一味强调开发效率会产生大量负债持续高产出:高质量,高产出,低缺陷率,低复杂度。我们做的一切都是为了尽快到达并保持在右上角的sweet spot。
  • 代码产出并没有明显提高,但由于自底向上的设计,完成相同的功能所需要的代码减少了。Complexity/method = 1.7
  • 开发效率在Sprint 5开始提高客户很开心
  • 移动开发敏捷实践

    1. 1. 移动开发敏捷实践<br />麦宇安<br />Perficient<br />
    2. 2. 麦宇安,Perficient架构师<br />
    3. 3.
    4. 4. Android移植项目开发的挑战<br />新员工对敏捷实践尚未熟悉<br />只有Java开发经验(Android速成?)<br />团队总体开发经验不足<br />开发人员的能力不全面<br />如何进行单元测试?<br />如何进行自动化验收测试?<br />在没有成型的架构的前提下如何保持开发效率?<br />如何测量代码质量,和应对技术负债?<br />
    5. 5. 要不要做vs怎么做<br />我假设大家已经接受敏捷的价值<br />听课是一会事,问题是如何在一个实际的项目中去实施?<br />怎么解决敏捷实践上和技术上的难题?<br />
    6. 6. 如何让团队有效协作<br />前两周结对编程<br />持续代码评审<br />取消正式代码评审,重大设计改变通过会议进行讲解<br />让团队自我组织<br />Done Done的定义<br />
    7. 7. 预先定义的角色与职责<br />
    8. 8. 预先定义的组织结构<br />
    9. 9. 团队自组织<br />角色与职责的“重构”与“浮现”<br />
    10. 10. “浮现”出来的职责<br />Mr. Y<br />Build Master<br />“提醒”谁把Build搞坏了<br />“提醒”谁没按流程做<br />提升验收测试的速度<br />Mr. W<br />大部分界面的工作<br />Mr. X<br />项目打杂(服务型领导)<br />PO<br />Mr. M<br />重构已经完成的故事<br />避免团队成员在某个技术问题上卡住<br />
    11. 11. DoD<br />完成测试用例<br />测试用例通过PO评审<br />完成自动化验收测试<br />单元测试85%以上覆盖率<br />Sonar:没有Major或以上的问题,没有重复代码<br />产品和测试代码通过高级工程师代码评审<br />PO验收<br />
    12. 12. 任务拆分例子<br />登录测试用例<br />登录UI<br />登录Activity<br />登录DAO<br />登录SQL<br />登录验收测试<br />
    13. 13. 持续的Burn down<br />
    14. 14. 单元测试:Roboletric<br />在JVM运行Android单元测试<br />无需等待Dalvik VM漫长的启动<br />无需Mocking<br />不依赖于网络和数据库<br />获得所有JVM的好处,如:<br />计算代码覆盖率<br />Debugging<br />
    15. 15. 例子<br />
    16. 16. Roboletric的Shadow机制<br />
    17. 17. Roboleric的问题<br />并非所有类和函数都是实现了shadow<br />使用已经实现的API<br />或自己去实现shadow(需要架设Maven Repository Server)<br />
    18. 18. Robotium自动化验收测试<br />Android版的Selenium<br />黑盒测试<br />
    19. 19. 例子<br />
    20. 20. Robotium演示<br />
    21. 21. Robotium的问题<br />DalvikVM经常死机<br />运行非常消耗时间<br />连接到Android手机上运行?<br />在Hudson上,产品项目和测试项目不能同时运行(Maven)<br />Robotium计算坐标的算法有问题<br />使用HVGA<br />有时无法滚动屏幕<br />message<br />
    22. 22. Android项目的技术挑战<br />在没有成型的架构的前提下如何保持开发效率?<br />Spike?<br />先设计?<br />先开发?<br />如何测量代码质量,和应对技术负债?<br />
    23. 23. 自顶向下设计<br />
    24. 24. 自底向上设计<br />用浮现设计获得的设计<br />控件显示隐藏DSL<br />Domain Object框架<br />View和Model的双向绑定<br />“表单”验证<br />派生字段,如全名<br />Lookup字段,如省份<br />
    25. 25. 控件显示隐藏DSL<br />showIf(getModel().isMembershipVerified(),<br /> not(membershipAd), <br /> not(noneMemberLayout), <br />showMyMemberCardButton);<br />showIf(items.size() == 0,<br /> not(itemListView),<br /> background(findViewById(R.id.item_button),<br />R.drawable.selector, R.drawable.selector2));<br />
    26. 26.
    27. 27. 健康的技术债务<br />小组:满足DoD但设计欠佳的用户故事<br />↓<br />最有经验的成员:一天的重构<br />↓<br />小组:参考实现<br />
    28. 28. SonarDashboard<br />
    29. 29. Violations drilldown<br />
    30. 30. 时间机器<br />
    31. 31. 警告制定<br />
    32. 32. Sonar插件<br />
    33. 33. 重复代码检测<br />
    34. 34. SCM Activity配置<br />
    35. 35. Sonar “Blame”<br />
    36. 36. 效率假象<br />代码质量<br />代码生产率<br />
    37. 37. 持续的产出<br />
    38. 38. Project Burn down<br />
    39. 39. 总结<br />新员工对敏捷实践尚未熟悉<br />只有Java开发经验<br />团队总体开发经验不足<br />开发人员的能力不全面<br />如何进行单元测试?<br />如何进行自动化验收测试?<br />在没有成型的架构的前提下如何保持开发效率?<br />如何测量代码质量,和应对技术负债?<br />结对编程,持续代码评审<br />设计交流会议<br />自组织<br />Done Done<br />Roboletric<br />Robotium<br />自底向上设计,浮现设计<br />健康的债务<br />Sonar<br />
    40. 40. Credit<br />http://en.wikipedia.org/wiki/Unified_Modeling_Language<br />http://pivotal.github.com/robolectric/quick-start.html<br />http://docs.codehaus.org/display/SONAR/SCM+Activity+Plugin<br />http://img2.zol.com.cn/product/30_450x337/602/ceGx2IS9vB2A.jpg<br />http://renmai.aliqq.cn/space-15538-do-blog-id-3685.html<br />

    ×