回首“结队编程”项目，我们觉得这些问题刀刀见红，回味无穷，甚至相见恨晚。是的，当我们各种熬夜、纠结、彷徨、争论的时候，也许真的需要这么23个问题来指引我们前行。。所以，与其各种自我解脱的总结，还不如直面这些问题的拷问更有收获~~~
好吧，就请允许我来代表我们组的总结讨论结果，来撰写这份饱含各种思绪的项目报告吧！
设想和目标方面：
第一问.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答:按照最初的预想，我们的软件iteam希望能解决学生小组合作时的时间管理问题。定义虽然清楚但是有所局限，无法完整表达软件在具体功能上的特点。在对典型用户和典型场景的描述方面，我们进行充分的研究和梳理，尤其是撰写了让软件工程专业学生有切身体会的应用场景，使大家最初对我们的项目抱有很高的期待。
第二问：是否有充足的时间来做计划? 项目原来预计有多少用户，实际有多少用户? 为什么有如此落差?
答：我们在需求探讨和原型设计上其实画了不少时间，但在编程阶段却因为种种原因出现了脱节。项目最初预计大约有100-200用户，有统计可寻的BETA版用户为91人（CSDN下载21次，校内bbs下载70次），另外还有通过其他方式如现场安装、QQ传送、无统计的朋友网页下载等20次左右，总体达到了最低预计。但与上限值存在一定落差，原因为ALPHA版问题过多，导致BETA版发布时间过晚，此外CSDN管理员的误删除也导致了第一次BETA版发布的下载量被清空。
第3问：团队在计划阶段如何解决同事们对于计划的不同意见的？
答：我们在计划阶段，主要是方式为充分讨论。我们花费了大量的时间进行讨论，划分功能优先级。一般由PM进行提案，之后大家发表自己的意见，最后由PM总结。
计划方面
第4问：你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：原定工作计划中75%没有达到预定设想或被最终取消，主要包括用户体验改善、数据存储、加密、复杂日历推送、提醒等部分。没有做完的原因很复杂，比较大的因素是项目冲刺阶段时，包括PM在内的2名组员因被公派出国而缺席长达3周，致使其它4名组员只剩2名开发人员。通过在国外期间由于网络不顺畅导致开发时大幅偏离了原有设计概念。此外，这一软件设计的难度也很大，涉及多个领域的技术，解决起来困难重重。
第5问：有没有发现你做了一些事后看来没必要，没多大价值的事?
答：有，比如发现软件偏离原定设计之后，我们讨论决定重改软件架构，但撰写一段时间后又发现时间不足、同学课程考试严重冲突，最后被迫取消，重新回到偏离设计时的软件架构上来。。。。
第6问：每一项任务都有清楚定义的和衡量的交付件?
答：很抱歉，坦率的说，没有。
第7问：在项目的整个过程都按照计划进行?
答：很抱歉，还是没有。现在我们发现，项目过程缺少文档，导致后续工作十分被动。
第8问：在计划中有没有留下缓冲区，缓冲区有作用么?
答：我们事先对软件功能和开发周期上都留有缓冲：功能缓冲上，我们制定了优先级，对部分功能设定为独立的子模块，使他们具有画龙点睛但又可以根据开发进展有所取舍。时间缓冲上，我们确定了绝对不能拖至考试周的时间表，并计划将考试周前后确定为项目最终测试和发布推广的阶段，以使我们在遇到问题的情况下可以利用这段时间进行补充。
第9问：将来的计划会怎么修改？ (例如： 缓冲区的定义，加班)?
答：如同第8问所述，我们确定了功能模块缓冲区和开发周期缓冲区，因为计划修改时对缓冲区的利用是被迫的，因为确实出现了2名组员临时公派出国的事件。最后我们利用缓冲区进行了期末加班和功能删减等。
资源
第10问：我们有足够的资源来完成各项任务么?
答：现在来看，作为PM，我不得不承认，其实是没有足够的资源。从组员能力上说，是有的，举例来说，小组6个人中，有4人拿到过全国大型主机竞赛冠军等奖励（均是利用4个月时间新学习的大机技术而非专业方向），3人是北大研究生院新版网站的主力开发成员（总7人），4人拿到北大乃至北京市挑战杯学术或创业竞赛的各级奖励等等。无论从学业成绩、学术水平、实习经验还是竞赛及项目经验，都是非常好的。但是问题出现在时间资源上，几乎所有人都被各种导师实验室项目所束缚，小组成员不断被出差和被出国。其次，我们没有选择将之前多个获奖项目用于在该门课程的进行改进或微软技术化，而决定选择一个从来没有接触过的桌面软件领域，从技术积累上来看，小组成员们在网站开发、游戏开发、移动平台开发和主机平台开发上具有经验和优势，而完成这个难度较大的日历软件的时候，缺乏技术积累，尤其是微软人机交互领域的技术积累，导致软件界面设计上存在较大困难。总结之，我们在时间资源和技术资源上，其实不具备在4个月的时间内在这个选题内制作一个高水平软件的根基。
第11问：各项任务所需的时间和其他资源是如何估计的，精度如何?
答：我们对时间及资源的估算在初期还是具有一定可信度的，我们根据组员们的课程及实验室项目时间，留足了学习相关开发技术和进行编码的时间，并更多的提前进行设计。最初时间精度为周，我们计划在编码阶段开始量化到每天时间安排，并模拟这一软件的具体运行方式在管理我们开发时间。但是突入其来的出国事件严重打乱了各项安排，我作为PM对此负有全部责任，我应该在行前做好相关安排，以确保项目执行时不至于阻滞。
第12问：用户测试的时间，人力和软件/硬件资源是否足够?
答：非常遗憾，这又是一个痛心疾首的问题。开发的延迟，导致测试被压迫在最后的时间进行，组员中负责测试的吴洋同学的电脑主板坏了，王祖坤的电脑被实验室征用。。。。当然最后大家一起努力边测试边改进，但仍然出现多次的发布软件又被迫因为BUG问题撤下的惨剧。。。。
第13问：你有没有感到你做的事情可以让别人来做（更有效率）?
答：很早以前就感到了，但不是在这次的项目中。总体来说，这次的项目是一个萝卜一个坑，大家还是很负责很努力的来收拾残局了。。。在这样的条件下，效率已然很高了。。这里我们全组尤其在BLOG上表扬组员中负责开发的林凯童鞋，独立完成了超过60%的代码量。。。
变更管理
第14问：每个相关的员工都及时知道了变更的消息?
答：大家都知道了。消息传达方面，我们做的还是很好的。因为大家都很重视这个项目，看项目进度的拖延也都着急。另外我们还建了个QQ群，很抱歉不是MSN。。。
第15问：我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：最初采取了充分讨论的办法。后程由于有各位老师的指导与点评，尤其是郁老师多次单独指导，使我们的功能模块在优先级和变更上更加一致。我们觉得既然是课程项目，首先让老师满意最重要。。。
第16问：项目的出口条件 （Exit Criteria）是否得到清晰的定义? 到底什么叫 ”做好了”?
答：我们定义了，但是最后因为时间原因，被迫没有得到贯彻实行。我们期待做好的软件是“无错、易用、可用的”。但是很遗憾，我们最后只是达到了“能用”。。。。
第17问：对于可能的变更是否能制定应急计划?
答：有应急计划，那就是大家一起熬夜不许睡觉集中起来工作。。
第18问：员工是否能够有效地处理意料之外的工作请求？
答：是的，最后几天紧张工作的日子很难忘，大家都很配合，熬成猫眼终不悔，努力编码人憔悴。。。要知道，由于有女生，要通宵只能征用实验室的会议厅，那里的蚊子多死了，每晚每人都要拍死N只。。。。
设计/实现
第19问：设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：最开始，有PM来提出可选项目，当时提出了8个，最后大家一致决定使用“协作历”，因为我们都觉得自己也需要这个软件。最后PM稍微完善了项目计划后，提案给大家加以讨论并果断进行了模块详细化合分级，之后PM还做了界面设计和产品原型设计。当时大家信心和干劲都很足，所以现在看起来是属于时间合适和人选合适，话说，PM不做设计讨论稿，还有谁做呢？。。。
第20问：设计工作有没有碰到模棱两可的情况，团队如何解决的？
答：有，在界面交互设计的时候，我们发现很多功能都有多种实现方法，但是最优的实现需要很高经验值的人才能完成。于是团队解决方案就是，林凯来学习WPF，杨珂来找一些资源和做初步实验，PM勇成来继续完善设计和去买WPF的书，这个解决方案得到了一致拥护并落实。。。。
第21问：团队是否运用单元测试(unit test), 测试驱动的开发（TDD）, UML, 或者其他工具来帮助设计和实现？这些工具有效么？
答： UNIT TEST有做。日历类软件本身就有各种边界条件，所以这一测试方法是十分有效的。UML也用了。其他的测试工具没用，主要是时间确实不够了。。。桑心中。
第22问：什么功能产生的bug 最多，为什么？
答：软件中的团队视图功能BUG最多，因为涉及到网络通讯、增删改查时的推送与同步、与个人视图的同步、组员信息加入与采集、界面交互等等等等。。。果真是功能越多BUG越多啊。。。后来我们发现，做好这一软件真的是需要一个庞大的开发与测试组。
第23问：代码复审 （Code Review）是如何进行的，是否严格执行了代码规范？
答：木有代码复审。能做出来就谢天谢地了。。。。
测试/发布
第24问：团队是否有一个测试计划？为什么没有？
答：最开始有，后来的情况是，由于课业等因素，原来的开发人员吴洋和思文被改为测试人员，他们全权负责这一部分。后来开发延期，测试时间又和考试时间冲突，所以只好进行了较小规模的测试。思文完成了较多部分的测试，吴洋电脑坏了，所以更多的提供了团队心理建设支持。
第25问：是否进行了正式的验收测试？
答：进行了，我们边测试验收边赶时间发布，多次反复。。。。。
第26问:团队是否有测试工具来帮助测试？
答：到结尾的时候，真的基本上以黑盒人肉测试为主了。。。
第27问：团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：在软件占用系统资源的跟踪上，我们学习了微软的一些测量工具的使用。在软件实习运行效果上，我们采用人盯人战术，在多个QQ群上进行了宣传和跟踪获得反馈，一有问题立刻解决。
第28问：在发布的过程中发现了哪些意外问题？
答：简直是往事不堪回首月明中。。。。。先是打包不可用，数据库不可用，然后是CSDN重复上传导致资源被删除，再接着是同学们发现了种种隐蔽BUG和提出功能不足的反馈后决定收回再改，再再接着是学院网络断网。。。。。总之谢天谢地，经过此番折腾，我果断决定以后自己买个外网空间。
附加(自我提问的2问)
第29（28+1）问：这门课程+项目的收获?
答：在拿到种种奖项和项目成功经验后，在这门课上所经历的失意也是我们的最大收获与财富。项目设计的不讨巧、协作进展的焦着缓慢，挑战难度的决心有余气力不足、最后加班加点时的发现落差后的种种追悔。所幸，我们都没有放弃，并最终完成了这个软件。虽然距离我们之前的设计相差甚远，但是作为大家一起开发的WIN桌面软件，我们为此感到十分的幸福。最重要的是，我们经历了全套的微软项目流程，认知了商业软件的开发，好的软件，决非一夕之功，一己之力。需要我们通力合作、百分专注与持之不懈。我们很幸运有机会挑战一个我们喜欢的创意，我们认为，“协作历”背后所蕴含的理念绝对有其用户基础和商业价值，这个BETA版虽然不足以让大家注意到这个软件，但它总是一粒成长为参天大树种子，我们也决心以后会继续开发下去。
第30（28+2）问：这门课上最后想说的话？
答：这是我们小组全体同学在北大的最后一门课程。作为我，马上就要去台湾交换一个学期了。我们首先想感谢老师们的辛苦，微软的苦心。我们制作了一个有用但不有趣的软件，虽然不知道能得多少分，但这个过程的艰辛其次促进了我们在未来的人生规划，正如温总访问北大时所说的那样：“仰望星空，脚踏实地”。最后，我们祝福微软的软件越卖越火，微软中国的创新充满生机，作为微软的用户和FANS，我们期待着更多的好用的软件走进我们的WIN平台中，我们也将为之努力。
原贴地址： http://iteamwork.spaces.live.com/blog/cns!C59777B5C6A2F0F!206.entry?wa=wsignin1.0&sa=676760372
扫一扫
6011
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
