首页
学习
活动
专区
工具
TVP
发布

PM吃瓜(公众号)

专栏作者
377
文章
467953
阅读量
37
订阅数
项目首先是预算制约 Budget-based,关键知识大爆料
但其实预算才是红线和底线,不管销售阶段范围是怎么规定的,如果预算足够都是可以解决的。
PM吃瓜
2023-03-02
1810
软件开发生命周期的五个阶段
一个软件从定义,开发,运行维护,直到最终要经历一个时期的过程 ,这个时期称为软件的生命周期 系统软件生命周期一般为分析,设计,实现和测试与维护这几个阶段,
PM吃瓜
2023-03-02
9100
前后端分离开发模式
为什么要进行前后端分离 前后端可以身心愉快地专注于各自擅长的领域 避免后端写前端代码(基本上1天时间,20%写后端代码,80%写页面…) 前端配置后端代码运行环境(简直是要疯… 装一堆环境,而且有些开发环境是windows,前端是macos,装环境就要装好几天) 避免前后端打架,推诿,甩锅… 提高开发效率 分离有助于前端大放异彩,后端专注于三高(高并发、高性能、高可用) 太多了…
PM吃瓜
2023-03-02
5770
软件生命周期的几个模型
软件生命周期同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段,一般称为软件生命周期(软件生存周期)。
PM吃瓜
2023-03-02
3660
敏捷过程中的需求分析
瀑布和RUP 强调结构化方法与重型的管理策略,往往在内心中拒绝变更,把变更作为被管理甚至被“管制”的对象;而为了尽可能避免变更,常常要求开发之前的需求获取、分析与定义要完整无误且精确。
PM吃瓜
2023-03-02
5970
项目案例 : Kiran Gems 项目
客户背景情况:Kiran Gems Pvt Ltd(基i兰宝石公司)是印度知名的宝石加工和出口企业,拥有员工超过10000人
PM吃瓜
2023-03-02
6920
敏捷不是小瀑布!
1.持续的设计、开发、集成和测试 设计、开发、集成和测试在sprint中是一个持续的活动,而不像瀑布项目是顺序的过程。下图描述了它们的不同之处: 瀑布项目
PM吃瓜
2023-03-02
2720
敏捷和DevOps你还分的清楚么?
更具体地说,DevOps是补充但不能取代敏捷,是将运维纳入产品开发过程的思维方式,
PM吃瓜
2023-03-02
2330
DevOps 解决什么痛点
其实DevOps在实践中并无统一准确的定义,不断的讨论不断的研究才能深刻理解。在软件工程领域一个非常有效的理念就是“提前把最痛苦的事情频繁得做、反复得做,直到它变成一个不痛苦的事情”。
PM吃瓜
2023-03-02
2950
项目验收该不该严格按照合同来实行?
首先,现阶段国内尚缺乏尊重契约的商业环境;其次软件行业难以标准化,验收的主观因素更重。在大环境不变的情况下,严格按照合同执行验收,你将会四处碰壁,尤其是集团内部项目。 所以不管长期、短期,平衡各方的利益,是项目经理在整个建设过程中,都应重点关注的。
PM吃瓜
2023-03-02
3970
详解IBM的大规模敏捷框架SAFe
常规的敏捷框架适用于中小型项目团队,而且不具有扩展性。基于常规的敏捷框架,SAFe定义了一个可扩展的敏捷框架模型,它适用于大型多个团队的合作开发,可以提高团队之间的协作性,降低团队管理的复杂性。
PM吃瓜
2020-09-08
2.1K0
项目计划有哪些内容?
基本信息 basis project information Process model (采用的项目流程) Project structure (组织结构图) Roles and responsibilities Project contacts (项目内外部联系人) Documentation (如何管理项目数据) 范围管理计划 交付物 方法,工具,技术 时间管理计划 里程碑 路线图 发布计划 成本管理计划 实际对比预算 质量管理计划 设定质量目标:性能,安全,可靠 第
PM吃瓜
2020-08-28
6430
敏捷开发,持续集成/交付(CI/CD)、DevOps
敏捷开发和DevOps都是一种理念。他们的理念相似,都是为了更好更快的发布产品,但又不完全相同。
PM吃瓜
2020-08-17
1.4K0
什么是用户故事(User Story)?
As a <Role>, I want to <Activity>, so that <Business Value>.
PM吃瓜
2020-08-02
2.4K0
活动时间估算
活动时间估算就是估计完成每一项工作可能需要的时间。应由项目团队中最熟悉某一具体工作性质的个人或集体来完成。步骤如下:
PM吃瓜
2020-07-31
6330
详解微服务Micro Service
微服务的概念我们应该大体了解了,那么微服务又是怎么来的?原来将很多功能打包为一个很大的服务单元进行交付的做法不能满足需求吗? 实际上,并非原来“大一统”(Monolith)的服务化实践不能满足要求,也不是不好,只是,它有自己存在的合理场景。 对于 Monolith 服务来说,如果团队不大,软件复杂度不高,那么,使用 Monolith 的形式进行服务化治理是比较合适的,而且,这种方式对运维和各种基础设施的要求也不高。 但是,随着软件系统的复杂度持续飙升,软件交付的效率要求更高,投入的人力以及各项资源越来越多,基于 Monolith 的服务化思路就开始“捉襟见肘”。 在开发阶段,如果我们遵循 Monolith 的服务化理念,通常会将所有功能的实现都统一归到一个开发项目下,但随着功能的膨胀,这些功能一定会分发给不同的研发人员进行开发,造成的后果就是,大家在提交代码的时候频繁冲突并需要解决这些冲突,单一的开发项目成为了开发期间所有人的工作瓶颈。 为了减轻这种苦恼,我们自然会将项目按照要开发的功能拆分为不同的项目,从而负责不同功能的研发人员就可以在自己的代码项目上进行开发,从而解决了大家无法在开发阶段并行开发的苦恼。 到了软件交付阶段,如果我们遵循 Monolith 的服务化理念,那么,我们一定是将所有这些开发阶段并行开发的项目集合到一起进行交付。 这就涉及服务化早期实践中比较有名的“火车模型”,即交付的服务就像一辆火车,而这个服务相关的所有功能对应的项目成果,就是要装上火车车厢的一件件货物,交付的列车只有等到所有项目都开发测试完成后才可以装车出发,完成整个服务的交付。 很显然,只要有一个车厢没有准备好货物(即功能项目未开发测试完成),火车就不能发车,服务就不能交付,这大大降低了服务的交付效率。如果每个功能项目可以各自独立交付,那么就不需要都等同一辆火车,各自出发就可以了。 顺着这个思路,自然而然地,大家逐渐各自独立,每一个功能或者少数相近的功能作为单一项目开发完成后将作为一个独立的服务单元进行交付,从而在服务交付阶段,大家也能够并行不悖,各自演化而不受影响。 所以,随着服务和系统的复杂度逐渐飙升,为了能够在整个软件的交付链路上高效扩展,将独立的功能和服务单元进行拆分,从而形成一个一个的微服务是自然而然发生的事情。
PM吃瓜
2020-07-24
6130
瀑布vs敏捷
一般来说,敏捷开发强调快速迭代,灵活开发,而传统软件工程强调严格周密,步步为营,那两者的具体区别究竟在哪?下面具体分析一下两种软件开发方法的区别。
PM吃瓜
2020-07-23
5350
单独谈一谈敏捷开发
传统软件开发模式开发流程冗长、适应性差的特点使得它根本无法在现代软件开发上被广泛使用,于是,人们又提出了一种强调快速、灵活的敏捷软件开发方法。
PM吃瓜
2020-07-23
4580
软件工程和项目管理
项目管理其实是一个非常宽泛的学科,它不仅仅只适合于软件(或互联网或IT)行业,其实也适合其他行业,例如建筑。
PM吃瓜
2020-07-23
1.1K0
人月神话不是神
用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话,因为它暗示了人员数量和时间是可以相互替换的。(注:人月是用来衡量工作量的,规模是通过功能点或代码行等方式来衡量的,规模除以个体生产率后可以得到人月数据)。
PM吃瓜
2020-07-20
6970
点击加载更多
社区活动
腾讯技术创作狂欢月
“码”上创作 21 天,分 10000 元奖品池!
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档