For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
大部分的软件开发项目都是由一个或者多个软件开发团队共同完成的,每个软件开发项目都有一个管理人员,下面我们就通过案例分析来了解一下,软件开发管理工作职责分析。
管理人员,先明白,研发有其自身遵循的客观规律。所谓给技术以时间,凡事总有个测试,优化的过程,如果总是随意拍脑袋,削减研发评估的研发周期,那么,因为功能是显而易见,一定要交付的,所以先被压缩的一定就是质量。例如一个系统计划开发一个月,测试一个月,领导一拍脑袋,开发测试压缩成一个月,那实际上,可能就开发3三个周,测试一个周,中间的各类评审也都被扔的七七八八,开发设计怎么方便怎么来,测试就走走主要功能能用就行。这样质量就不要苛责了,相当于把测试交给终用户,对于长期迭代的项目,也会累积不菲的重构债务。
建立评审,复盘机制,是高级管理人员的职责。重要的评审公司多小也应该具备,如需求评审,开发设计评审,测试方案/用例评审。同样复盘,如结项复盘,或以时间为周期的月复盘,季度复盘。
基层管理人员,参与组织评审时,应保证评审不流于形式。如需求评审,就是降低需求BUG的重要环节,系统大了,需求人员自身的能力,也很难考虑的面面俱到,需要开发,测试共同,帮忙考虑,新需求对已有系统各处的影响。评审过程也是一个传达质量价值观的好机会,在“好改,工作量小”和“规范,长远可维护”中尽量选择,规范的需求设计,开发设计方案。要倡导细心和减少Bug是有非常有技术含量和挑战的事情,而不是一件麻烦的事情,让开发多花精力在一次作对上。
复盘是一个重要的回溯机制,质量问题应该都能追溯到个人,谁提的需求,谁写的,谁测的。到不一定要跟绩效挂钩,但责任到人的方式,确实可以推动大家,建立质量意识,遵守质量规范。用例通过率低的模块的原因?需求Bug的数量较多,提示我们要重视需求编写,评审,提高需求编写人员能力,未自测bug多,提示开发人员责任心不强,生产的Bug数多,要分析,是否为常见问题,测试是否应该覆盖,如果是用户的日常操作,而回归流程却没有纳入,要考虑测试与用户多沟通,了解用户使用习惯。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。