标签:
http://www.cnblogs.com/SteelPillar/p/4027877.html
http://www.cnblogs.com/SteelPillar/p/4096145.html
在实践过程中,我最终发现写成文档类的沟通是比较有效的.比如说,我和前端的负责人谈论她所需要的接口,如果少的话,在企鹅上一句两句就可以解释明白,但如果需求多的话,可能就要写一份需求的说明,我会按照前端的要求,一个一个的完成任务,同时把对应的解释写在原来说明对应的位置,内容会写比如返回给前端什么样的数据,格式这些等等,把这些东西回传给他,这样挺有效率,出现问题也很有针对性.
进度这个东西真的很难去说什么,在和队友的合作中,在分工明确了之后,大家基本能成功完成自己的部分.
还是那个任务分配的地方,怎么分配任务既能发挥各人所长,有使工作量合理.
再版本不断地更迭中,有些接口 函数之类的讲被新的代替,或者被搁置一旁不再用了,这些代码是否应该留给后来的维护者(我在看学长代码时候就发现了很多无用代码,甚至是假实现),该怎么处理这类东西.
需求:NABCD需求分析.
设计:估算工程量
实现:敏捷开发 结对编程
测试: 单元测试
发布:寻求用户反馈
维护:通过实际的反馈进行修改
标签:
原文地址:http://www.cnblogs.com/SteelPillar/p/4215903.html