IT项目管理中的假设约束依赖和承诺


原文: http://blog.sina.com.cn/u/493a8455010003ko
来源: 人月神话的BLOG

项目中的假设约束依赖和承诺是制定项目计划的时候要确定的内容。
项目假设是我们先说严格意义的和非严格意义的:严格意义是在当前时间点根据当前拥有的各种工具无法确定的事物或事件,而且这些事件会对你的项目 造成影响。你的项目是在假设条件成立的情况下进行了。由于假设是不确定因素,所有项目的所有假设都是项目的风险,只是风险的严重程度不同而已,对于关键的 风险应该转化为项目的风险,在后续进行风险的分析和跟踪。比如项目现状是没有测试人员,你可以假设项目在进入测试阶段的时候,能够招聘到两名技能符合要求 的测试人员。同时可以将该条假设转化为风险,即可能存在无法招聘到测试人员,而影响测试和整体进度的风险。
另外还想说的是非严格意思的假设,比如我们经常和别人讨论问题时候爱说假设你的说法是正确的,这个应该说是一种非严格意思的假设,因为在当时这 个点究竟他的说法是否正确是可以通过其它评估方法或工具进行判断的,是一个确认的事情,而不是远期未确认的一个预测性的事情。所以说对于根据自身或组织级 的现有条件无法来评估的现在的某一个事物或事件。这也可以做为假设。在项目开始时候,我们可能并没有一套很体系化的评估和测评工具能够来测评我们每个项目 成员的技能是否达到要求,所以可以做个假设,假设项目中的每个成员都达到了组织或项目要求的技能要求。
而约束,是指所有对你项目有制约性的内部或外部因素都可以做为约束。约束有技术方面的约束如系统的开发必须采用分布式技术,约束也可能是非技术 性的,如项目的资源或成本方面的约束。约束应该是一个在项目过程中不会发生变化的客观因素,因此比如项目中有新员工技能不能满足要求这就不应该做为项目的 约束,因为这个约束是动态变化的,在项目的进行过程中由于新员工技能的提高,这个约束可能就不会成立了。另外约束也可以转化为风险进行跟踪,如项目可能存 在某项约束不能满足的风险。
项目的依赖和承诺都分为项目内部的项目外部的。依赖和承诺密切不可分。下游工序依赖于上游工序的产出物,而上游工序需要做出承诺在哪个时间点给 下游工序交出工件。项目内部的依赖可以体现到进度计划的甘特图上面,我们在对任务进行排序并分析了任务的依赖关系后就可以根据网络图得出项目的关键工序以 便安排项目资源。项目外部的依赖主要是项目中的某项任务需要外界提供相关的产出作为支持,如开发阶段任务需要一个其它项目提供的公用组件。由于外部依赖没 有体现到项目进度计划中,而且外部依赖很多时候项目自身无法控制,所以外部依赖更应该通过专门的跟踪表进行跟踪,要提前多做相关的沟通和确认工作。
项目内的承诺是项目进度跟踪的一个重要内容,项目经理下达给项目成员的任务,项目成员接受了项目任务就默认的承诺能够在相关时间点完成该任务, 项目经理就需要去跟踪和确认任务能否按时完成。而项目对外部的承诺则可能很多,如项目承诺在某个时间点给其它项目一个公用的接口,项目承诺在哪一天能够正 式发布版本等。不管是项目对内或对外的承诺,最好都能够转化成Project具体的任务,这样方面项目进行跟踪和控制。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结