排课系统pope需求交流时遗漏的问题III

总结

• + - 业务方提供需求文档，没有做code或test的核对存在的漏洞
  
  • 这个问题一直存在，但是自己一直吧问题归结为需求的时间不够，是这样吗？如果没有对问题的深入我们就不会知道自己想要什么.但深入在这里让自己一把通到coding和testing去了，合适吗？这个尺度是否要求太高了？
    这里的需求文档完全是用瀑布方式思考的，如果是用迭代方式，是否对需求，开发，设计的压力都会小一些呢？但是这种迭代式的思想是否应该是统一认识的情况下一起开始的，如果不是那么先看到先做，中间随时修改增加，这些与迭代式应该是有区别的吧？界线在哪里？我现在可以想到的就是迭代开发在每一轮开始之前对要做的还是有统一认识的和明确目标的，不是吗？现在就可以想到这里了。这是个一直有，并会一直思考下去的问题，自己在写觋祉的功能时，应该好好体会一下了。
     
  业务数据的统计使用问题
  
  • 这个是自己一直想做的，但是这次也没有做，借口是时间紧，好吧！自己写写这个功能的tool，为以后使用。还是感觉自己有借口的嫌疑。：）
    
  
  这个项目到现在暂时停止了，停到算法了。
      近几日重读 Weinberg 的《质量 软件 管理 第一卷》中提到从模式2向模式3转变的一个内部动力就是要完成功能本身的复杂性引起的，现在感觉这个项目stop其实可以看成是这个模式转换中2-3无法完成，加上用户动力不足，所以搁浅了。
  
      有时在想是自己太谨慎了吗？从开始就感觉不对，过程中一直feel问题，现在发生了，自己就说看我当时就说了，【但是说实话，为测试算法自己也尝试用python开发了一个测试用的算法部分，其实反而feel不是不可以完成的，仔细分析和尝试是可以的做的。好吧，这个自己写python code时的feel，没有验证就可能是错觉。这个要回头整理完源码才可以再评论算法本身的问题。】这个要说的是自验证逻辑的问题，最近总结crm的问题同时在想，如果当初自己跟着crm的需求做下来，在开始一定就会冲着老塞普去了，然后提出一堆的问题，自验证性会不会也成为crm的开发阻力呢？
       也是说，从另一个角度我在自己恐吓自己。每个软件都有其天生的复杂度问题，但在不同的要求客户环境中没有你要求的那么高，问题的原动力你看的真的清楚吗？这个应该是个要求长期思考的问题，本质上和最近在思考项目和产品的质量要求区别有相似的地方吧！再想想吧！
  
  好了，到了这里基本就总结完了，至少feel部分完成了，下面是算法的test部分的doing的总结，这个由于涉及到语言和设计归为另外的分支吧！
  这里要下面做的[next]
  1.从大量原始数据中统计要求内容的tool
  2.思考迭代式与现在工作模式的不同之处，现在这种是吗？
  3.思考需求的自验证性问题（结合项目和产品质量要求差别问题）