软硬件通包的产品级敏捷团队

2015.6.4，在武汉。和比自己聪明的人。一起做产品。永远是种最大的幸福。

“软硬件通包的产品级敏捷团队”……

团队不同角色的协作。建立起软硬件的核心信息，经由软硬件的核心信息，软硬件通包的产品级敏捷团队便能马上……

  • 分析出在新的硬件规格下，新增的业务场景为何?

  • 在新增硬件的规格下，为提升用户的惬意度。分析出所需的架构的 Qualityof Service
    为何? 架构上所需的新的技术验证点为何?
  • 识别在新增硬件现行的进度状态下，可马上投入开发的场景为何?
    架构为何?

    測试场景为何?

“软件通包的产品级敏捷团队，经由协作，建立起软硬件的核心信息，而能在最短的时间内。在产品的架构上作出最正确的决策。更重要的是。能与硬件的进度隔离；软件研发团队，可持续的冲刺着软件开发的进度。全然避免了等待，避免了浪费。”

时间： 2024-10-02 20:47:52

软硬件通包的产品级敏捷团队的相关文章

2015.7.3, 杭州……产品级敏捷案例研究

永远珍藏的一张照片:产品级敏捷团队的骨干人员. 这一路走来,大伙探讨的不仅仅是如何经由可视化,轻量级,团队协作的方式,完成产品的开发计划,挖掘场景,架构设计,测试用例设计,开发与测试人员的协作与分工 --等等. 更重要的是,大伙更深度的探讨该如何与 Stakeholders 们建立起彼此的信任及正向的互动关系,而能和 Stakeholders 们一同挖掘出有价值的需求,使得每一轮 PI (Program Increment),都能以最少的产出,却能对客户产生最大的影响. 产品级敏捷主要是期望,能

产品级敏捷的核心在 "决策"

2015.6.2 在武汉-- 这是一支谦卑且认真学习,又实实在在做产品的 "产品级敏捷团队". "产品级敏捷团队"--在产品版本开发的生命周期中,均能共同高效的协作,构建出产品版本中的 "核心信息". 根据 "核心信息",产品级敏捷团队能-- ①针对版本中的需求项做出 "减法" 的决策:绝不浪费任何的时间.资源,在那些对客户完全没有任何价值的需求项上. ②根据需求的复杂度与变化的方式,在软件架构的设计上,做

“产品级敏捷” 的这条路; 逐步的形成一高效的产品开发生态系统

2015. 7.1, 我在杭州-. 这一路走来真的相当的不容易; 这一周多来, 大夥跟著一个 "疯子顾问", 经历了不停的交流,辩论, 实践, 验证, 深度思考? 终于, 踏上了产品级敏捷的这条路-.. 以外部客户的视角, 制订出可使客户对产品有信心的版本节奏; PI (Program Increment) ? 拉通产品的特性负责人, 开发骨干与测试经理, 经由可视化的需求看板与 "加法, 减法" 的协作模式, 识别每一轮 PI 所需完成的开发与集成测试的特性场景?

敏捷价值流开发 (产品级敏捷)

许多今天还是明星的科技公司, 却往往因所生产的产品, 对客户不再产生任何的 "影响力", 而面临即将黯然关门, 倒闭的命运? 在这不可预期且淘汰迅速的大环境下, 是否可藉由精益敏捷开发, 而使产品的研发团队, 可以 "以最少的产出, 却对外部的用户, 产生最大的影响与效益" ? 答案是 "肯定的" ! 敏捷价值流开发 (产品级敏捷), 便是以精益敏捷开发的思维, 从外部使用者的视角, 指导著产品的研发团队, 从建构产品级的特性到各版本的研发, 如

产品级敏捷开发关键的第一步: 制订版本发布的节奏

前言: 产品级敏捷开发主要的目的是要达到: 以最少的产出, 却能对客户产生最大的正面影响? PI(Program Increment) 则是制定版本发布的节奏, 以使团队能在最短的版本开发周期内, 产出对客户最有价值的产品特性或功能? 所以, 产品级敏捷开发关键的第一步便是: 依照产品质量与团队人员能力的现况, 制订出合理且能满足外部客户要求的PI (Program Increment)? 本文: 制订出合理且能满足外部客户要求的PI (Program Increment), 便需综合产品质量的

《大产品，小团队——携程敏捷技术与管理转型实战》读后感

作为曾经携程的一员,看到一起奋斗过的小伙伴们宣传此书立刻就买了,非常开心拿到了作者团队的亲笔签名版.读完颇为感慨与惭愧,有种虽然身在此山中,竟不识庐山真面目的感受.当时身处携程俩大核心业务之一,却只知一味地吐槽糟糕的流程和无止尽的加班,即没有推动改进的勇气与执行力,也不知背地里整个公司为优化流程,提倡创新所作出的努力,以及已经取得的成果. 诚如书名<大产品,小团队——携程敏捷技术与管理转型实战>,此书着重于在敏捷开发与管理转型期碰到的问题与解决方案,所以建议小伙伴们在学过了ACP,或者敏捷项目

成熟的敏捷团队该如何看待产品（系统）的缺陷？

何不乐观的看待产品(系统)缺陷? 藉由演算法, 电脑现在可以作曲, 人脸识别, 看病, 预测某人在某个议题上的决策--等等. 所以, 可不可能开发个软件, 经由该软件中的演算法, 会自动的找出产品(系统)中的所有缺陷? 答案是--否定的, 不可能的. 因为, 要能有个软件, 能找出产品(系统)的所有的缺陷, 那就必需先要有个"无缺陷的软件". 当然, 这是永远不可能的. 所以, 缺陷永远找不完, 缺陷也就永远不可被避免.那我们应如何看待缺陷? "任何的产品(系统)上的缺陷,

敏捷团队转型

敏捷团队转型背景 故事一: 以前在一个很有激情的团队中一起干一番事业.每一个人各自发挥各自的特长,将每一期项目在不加班的情况下准时上线. 后来公司在年后財务原因倒闭.团队解散后每一个人到了不同的公司.工作后都发现原来非常多公司.包含某些大公司.没有使用敏捷开发导致公司存在非常多问题,加不必要的班.效率低,代码质量不高.团队之间协调能力差,团队内部没有热情.甚至沮丧.悲观. 年后又一次在一家算比較成熟的.知名的某视频互联网公司入职后,发现公司内部问题也非常大,甚至一个迭代完毕后没有总结会议. 代码

多个敏捷团队之间的版本控制

http://www.infoq.com/cn/articles/agile-version-control/ 多个敏捷团队之间的版本控制 如果我们有多个敏捷团队在同一个代码库上工作时,如何将彼此之间代码互相冲突的风险最小化?如何确保每个迭代结束时拥有一个干净的.可发布的软件版本?本文讲述了关于如何在敏捷的环境中与多个团队共同进行版本控制工作的实例——这正是我们在<Scrum and XP from the Trenches>中描述的公司所采纳的方式. 本文并非专为版本控制专家所写,实际上这样