网站模型怎么做,wordpress mc,wordpress安装ssl,东莞工厂一.设想和目标二.计划三.资源四.变更管理五.设计/实现六.测试/发布总结一.设想和目标 1. 我们的软件要解决什么问题#xff1f;是否定义得很清楚#xff1f;是否对典型用户和典型场景有清晰的描述#xff1f; 我们的软件要帮助低头族控制使用手机时间。功能很明确#xff0…一.设想和目标二.计划三.资源四.变更管理五.设计/实现六.测试/发布总结一.设想和目标 1. 我们的软件要解决什么问题是否定义得很清楚是否对典型用户和典型场景有清晰的描述 我们的软件要帮助低头族控制使用手机时间。功能很明确对典型用户和典型场景有清晰的描述在需求规格说明书中。2. 是否有充足的时间来做计划? 有但是因为对开发不熟悉计划是一步一步摸索出来的。3. 团队在计划阶段是如何解决成员对于计划的不同意见的 成员脾气好商讨接纳合理的意见。 有什么经验教训? 如果历史重来一遍, 我们会做什么改进? 首先应明确整个开发过程大体要做哪些事将较大的模块落实到个人负责如文档由某成员专门负责。 二.计划 1. 你原计划的工作是否最后都做完了? 如果有没做完的为什么? 没有大部分做完了我们原本想将数据备份到数据库后来因为申请的原因、我们的APP在Alpha阶段实现功能可以不需要服务器、安卓方面功能较多、服务器方面不熟悉所以程序重心放在安卓2. 有没有发现你做了一些事后看来没必要或没多大价值的事? 基本没有。美工有时候越用心会适得其反走到极端。3. 是否每一项任务都有清楚定义和衡量的交付件? 没有每项代码提交是明显的可衡量交付件。但是成员在学习过程中没有设定交付件导致学习效率不高。4. 是否项目的整个过程都按照计划进行项目出了什么意外有什么风险是当时没有估计到的为什么没有估计到? 没有完全按原计划计划在整个过程中有变动项目有计划地进行。初始计划我们是想将程序方面分为安卓和后台主要是程序方面的工作。我们对项目的认识是模糊的。经过alpha阶段前2天的摸索基本上知道整个完成这个APP要做什么。将程序重心放在安卓后来意识到界面的重要以及原本负责服务器后台的人员会PS所以我们在界面设计方面加入了自己制作的符合我们APP主题的图标 博客的内容有助于每个成员把握自己的时间清楚整个项目把握到整个项目的过程以及记录每个人在这一阶段的成长困难、总结所以博客内容的收集、整理是很重要我们有2个人可以负责文档。一开始对博客的内容提纲不清楚摸清提纲后一个人负责就可以了另一个人可以负责其他事务。5. 在计划中有没有留下缓冲区缓冲区有作用么? 有考虑到缓冲区缓冲区有作用可以应付紧急情况如bug修复。6. 将来的计划会做什么修改 会留出更多缓冲区不将时间按事务排满。 我们学到了什么? 如果历史重来一遍, 我们会做什么改进? 应该明确整个项目的事务清楚定义每个任务包括学习任务设定衡量的交付件提高学习效率。写出代码框架大家坐在一起打代码。 三.资源 1. 我们有足够的资源来完成各项任务么? 有资源但没有足够的资源我们最好的资源是有一位开发安卓经验的组长他写了整个代码的结构拥有PS技能的人员文档编写人员缺少的资源是测试经验、界面设计知识但我们有学习资源却没有安排好学习任务以及学习衡量交付件。2. 各项任务所需的时间和其他资源是如何估计的精度如何? 我们将任务切分基本是一天完成几个任务没有具体到小时精度不高。3. 测试的时间人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? 测试是薄弱的一块我们是手动测试用例测试测试方面花的时间少。对于美工设计和文案我们有重视也认识到美工是一大重点以及弱项。4. 你有没有感到你做的事情可以让别人来做更有效率? 有我们有2个人可以写文档后来让一个人做另一个人做其他事充分利用人力提高效率。 有什么经验教训? 如果历史重来一遍, 我们会做什么改进? 我们会多面对面交流坐在一起学习制定学习验收计划提高效率。 四.变更管理 1. 每个相关的成员都及时知道了变更的消息? 知道通过博客的任务安排知道。2. 我们采用了什么办法决定“推迟”和“必须实现”的功能? 主体功能实现如将服务器推迟到下个版本计时以及记录、结束时强制手动停止必须实现。3. 项目的出口条件Exit Criteria – 什么叫“做好了”有清晰的定义么? 有组长很注重细节结合用户场景来考量项目是否做好了。4. 对于可能的变更是否能制定应急计划? 项目变更可能性小没有考虑到变更如果有变更都是积极地想办法解决。5. 成员是否能够有效地处理意料之外的任务请求 能。有时候临时出现新的事物如界面整合需要修改大家都积极配合。 我们学到了什么? 如果历史重来一遍, 我们会做什么改进? 原本对项目的认识不够所以出现了变更。组长都是根据每个人意愿让大家自主选择大家不知道自己想做什么具体角色是做什么如果重来一次让组长明确每个角色要做什么再结合成员志愿及组长考量将角色及责任落实到个人。 五.设计/实现 1. 设计工作在什么时候由谁来完成的是合适的时间合适的人么 项目的整体结构则由李坤隆先僧完成李先僧之前有参与过开发相比其他成员更熟悉开发的套路所以由他来完成项目的架构是合适的。2. 设计工作有没有碰到模棱两可的情况团队是如何解决的 因为其他小组成员刚开始学习开发不懂套路所以代码结构的设计是由李先僧一人完成的。小组项目最终采用mvp模式根据李先僧的描述这也是他第一次使用这个模式对这个模式并不熟悉和其他成员一样也是摸着石头过河。一开始对代码的分包是像传统的‘activities’‘adapter’这样根据每个文件的所属类别分包还是像google官方的mvp例子那样根据模块分包犹豫不决。最终看了一篇博文按照应用功能来封装而非所属类别决定按模块分包。只是把文件按模块分了下包实际分工的时候是按m-v-p来分的并不是某个人把某个功能模块的mvp三层全包了。mvp三层间依赖于接口而非具体的实现类只要接口在一开始的时候商定好三个层之间完全可以异步并行开发不是很懂栋哥评测那天说的“伪按层分工”是什么意思3. 团队是否运用单元测试unit test测试驱动的开发TDD、UML, 或者其他工具来帮助设计和实现这些工具有效么 团队没有单元测试由于项目开始的比较晚预留的时间比较少大家都不懂得测试代码怎么写。有尝试着学习怎么写android的单元测试但是由于最终时间太紧没有完成测试这是个教训以后要预留好足够的时间在做中学有使用uml工具画项目的用例图和类图。4. 什么功能产生的Bug最多为什么在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况? 暂时没发现产生很多bug的功能在发布前发现多用户登入的情况下还是保有之前用户的数据发布后发现如果在零点的时候使用计时功能可能会导致每日计时统计结果又偏差。都是逻辑上的错误5. 代码复审Code Review是如何进行的是否严格执行了代码规范 李先僧没有让大家重写代码而是自己把代码修改了一下命名并没有改:(我认为这是不利于初学者成长的如果李先僧个大家指出不规范的地方并说明该怎么写这样学习效果会更好 我们学到了什么? 如果历史重来一遍, 我们会做什么改进? 如果重来一次让李先僧更多地给其他组员加油打气写代码指出代码不规范的地方并说明该怎么写。一开始就重视测试工作就像对界面一样。六.测试/发布 1. 团队是否有一个测试计划为什么没有 有测试计划2. 是否进行了正式的验收测试 是的针对各项功能都进行了测试3. 团队是否有测试工具来帮助测试 没有用到测试工具因为第一次进行测试所以就先采用了人工测试4. 团队是如何测量并跟踪软件的效能的从软件实际运行的结果来看这些测试工作有用么应该有哪些改进 在alpha版本完成后将各个模块的测试进行分配每个组员进行用例测试。最后的运行结果证明了测试工作还是有用的发现了很多之前没发现的潜在问题下次要再细心点5. 在发布的过程中发现了哪些意外问题 意外问题倒是没有和原本设想的差不了太多 我们学到了什么? 如果历史重来一遍, 我们会做什么改进? 人工测试可能还是会有些缺陷用测试工具测试可运行更多、更繁琐的测试且快速高效可执行一些人工测试执行相当困难或者做不到的测试如大量的用户并发、更好的利用资源具有一致性和可重复性的特点。所以下次可能更倾向于工具和人工结合。 总结: 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次? 二级 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段? 萌芽还要多学习每个成员都要增强实力。 你觉得目前最需要改进的一个方面是什么? 回首总结了整个过程发现有许多bug这些bug从另一个角度看是别样的收获如果能修复了这些bug、漏洞收获更多。最需要改进的地方团队应多面对面交流提高效率不拖延。转载于:https://www.cnblogs.com/linjin/p/6098937.html
