一个女生和五个男生的软件工程之旅，你懂的
~~~~~~~~~~~~~~~~华丽丽的分割线~~~~~~~~~~~~~~~~~~~
恩，这的确是一个女生和五个男生的故事，你没看错，我们组的6个同学正好是5男1女，我们一起做软件工程的team project
上周，我们最终完成了软件工程的alpha版本，我们组的同学合作的都非常愉快，大家多非常享受一起完成一件事的过程
所谓无图无真相，先来一张我们组同学的合影吧
根据我们的切身经验来看，一个女生和五个男生确实是一个不错的搭配
下面就来总结一下我们在alpha版本的教训和收获
1. 我们在实际开发过程中削减了一些需求和feature，因为我们发现这些需求不强烈，这样的feature也不值得去做。比如说，对于活动的更新和创建，我们本来写进了task中，但在实际开发的过程中，我们发现，绝大部分用户其实根本不需要在手机上更新创建活动，大家做的最多的还是查看活动。因为删除和更新是“重量级”操作，而用户在手机上的使用场景通常是轻量级的。如果一个用户真的想要创建活动，他必然会在电脑前完成操作，因为他要打好多字，还要传照片，这样复杂的操作几乎不可能在手机上完成。
对于这种类型的feature我们可以通过更加详细的需求分析和前期计划来避免。
2. 我们组的讨论通常是在饭桌上完成的，好处是大家的关系相处的都很nice，坏处是有的时候讨论效率不高，吃完饭还要继续讨论。总之，我们觉得在饭桌上讨论问题还是不错的 ^_^
3. 在任务分配阶段，有些任务pm交代的不清楚，造成了dev的一些误解，虽然没有做很多无用功，但是还要尽量避免。这个问题根本上是沟通的问题，很多事不能只在口头上说，最好落实到书面上，写的清清楚楚，尽量确保大家都明确自己的任务和目标。
4. 很多技术上的问题需要事先调查好，否则做到一半发现做不下去了，就会很浪费时间。比如说，我们本准备提供评论的详细信息页面，后来把页面基本做好之后才发现豆瓣并不提供这样的api，这种状况应该尽量避免，不能想当然。
5. 关于风险管理，前期必须控制好。这一点我们组做的比较好，一方面我们的工作技术上难度不大，相对来说，风险也比较小，另一方面我们在前期做了小demo，完成了认证及post和get的示例，这样我们的后期工作基本就没什么风险了，只要复制黏贴，修改即可。
6. task的分配还有待提高。比如说我们组的每个同学都会涉及到xml的解析和listview的绑定，但是我们并没有安排某个同学去解决这方面的问题，后果就是每个同学都要同时解决这个问题，浪费了生产力。如果我们先分配一个同学搞定这一部分，其他同学直接拿来用就可以了，既提高了效率，还保证了代码的一致性。
7. 至于task所需时间的估计，这一点我们做的不好，主要原因在于大家对于C#和silverlight以及windows phone的api不熟悉，前期的工作耗时较多，上手了之后效率就提高了很多，导致task的时间不好估计。这种问题在beta版本就很容易解决了，到时候大家对于windows phone的开发已经比较熟悉了。
8. 当我们进行功能和页面设计的时候，我们始终是以用户为出发点，并且结合手机的特点来进行设计的。比如说对于书籍，电影，音乐的详细信息页面我们用的是panorama view，它很适合展现一个object的大量attributes，而且也是windows phone的特色。对于豆邮页面，我们使用的是pivot view，它常用来展现并列的几个页面，发件箱和收件箱放好符合。我们在设计的时候参考了iphone和android上的一些客户端，但是我们最终还是要以用户为中心，根据windows phone的特点来进行产品设计。
9. 我们在team project中还用到了pair programming，发现真的很赞！在我们daily scrum的最后一天，我们需要把大家的代码放在一起，互相review并且fix bug，当我们两三个人坐在一起写程序，调试的时候，我们惊奇的发现这个过程真的非常enjoyable，效率非常之高，大家一起见证者我们的app越来越好，真是太棒了！
在beta版本我们还有许多事要做，那就加油吧
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
