上月非常规敏捷方法对制造执行系统或制造操作管理项目的成功至关重要。许多人评论LinkedIn博客转贴时请求解释和洞察力, 特别是:“如何用这种方法估计项目?” 和“如何管理各种短程中可能发生的范围变化?
本月首题由我回答下个月我将回答另一个问题。很显然,我并不知道所有答案, 但我提供食物思考和讨论 从我对Autoware的经验
估计软件项目总是复杂任务多理论开发 试图使估计活动 量化算法方法软件开发过程根本上具有创举性,我认为没有任何方法实际显示产生足够正确估计,比经验有效开发项目尤其如此,项目间变化可能极大。
选用敏捷方法管理项目会增加复杂性的另一个因素,因为敏捷方法提供高度弹性与最终结果不确定性匹配如何估计实现不清晰定义和具体说明之事所需的资源?
当我们需要定义开发新项目所需承诺时,我们通过采取这些步骤解决问题:
- 与客户定义近似边界需求并映射宏请求到尽可能多的宏领域这有助于我们至少粗略地识别问题并理解从哪组经验提取信息以试图将请求带回已知事物
- 开发大型技术解决方案参考值,并计及项目复杂性架构提供定义公共元素供日后与客户端交互使用
- 确定需求集有多少可与标准特征或为其他项目开发的组件相仿,以及公司现有经验领域或范围外差异多大
活动计及客户用户需求规范提供的文件最重要的是,这一过程通过与客户直接交互作用发挥作用,帮助我们更好地了解客户的目标和期望超出文件描述范围理解客户中长期愿景也至关重要,这样项目有可能立即从实现最终目标所需方向接近项目-至少从分析时可定义时算起
将宏需求与宏功能相联,使问题分解成小问题或模块,通过这些模块你能够更好地利用从估计和实现中获取的经验。这会大大降低定义必要资源过程的风险,并允许你更清晰地定义每个模块的风险系数以纠正估计值
定义模块后,经验提取和风险因素后,你得到两样东西:
- 定义项目预算值的唯一目的是允许客户判定它是否符合期望、估计或预算
- 精确估计探索公开主题所需承诺的价值,精化分析,以便将每份文件(可能由客户单方制作)带入客户集成团队编译并分享的文件
如果客户决定继续进行项目,则开始深入分析项目范围阶段,导致起草通用规范文件或修改并分享客户制定的内容
这一步骤对创建共同基础至关重要,共同基础可以向所有有关方面提供支持和安全。通用规范文档与团队期望一致,清晰目的并尽可能定义官方项目轮廓该文件拟在项目过程中编辑修改,但在每种情况下都用作指导未来活动的指南
只有在活动完成后才有可能重拟估计预算并提供估计所涉工作所得值将仅受一类修改-项目期间讨论并商定的范围变式-下月详细讨论
LuigideBernardini是首席执行官软件验证控制系统集成器关联成员基地意大利维琴扎欲了解更多Outoware信息,访问软件网站或见公司简介工业自动化交换
