产品领域是电信硬件和软件，其中关键是cross connect board(某种PCB电路板)，包含电源、FPGA–现场可编程门阵列(其中一些最终融入到ASIC–专用集成电路中)、设备驱动等。
一个架构要点是，容错是非常重要的；一块PCB电路板经常具备另一块“B计划即故障切换(failover)板子（想象该cross connect board”方案具有A板和B板），即使在单块板子上也会有容错处理（例如:从外接电源切换到电池）
作为一个例子，一个特性团队应该包含具备不同技能的人，如电路板设计、热能分析和调整（降温和耗散设计）、电源、FPGA（Verilog编程语言）、Linux设备驱动（C和C++语言)、其他（此外，有个人现在能用FPGA的Verilog语言做TDD，采用了一个有趣和有用的工具叫SVUnit。如果想学习更多硬件研发和增量分拆的话，我推荐大家接受FPGA Verilog TDD辅导）
- 带有主备电源的单个板子，以及主备AC/* DC转换器，能够启动并提供丰富的服务水平信息，并且可以处理“复位”和“进入省电模式”等操作
=== 注意硬件组件团队的局部优化认知偏见 ===
(Below is the origin text from email by Craig Larman)
just answered a question on the SA TCC board, that realized might be of interest here too, and others here will have interesting contributions
Q: examples of increments & slicing in HW dev?
here’s an example of HW product increments from a group based in nuremberg (DE) that was starting a LeSS adoption maybe 5 years ago.
domain is telecomm hw & sw. in this product, key element is a “cross connect board” (a kind of PCB), which includes power, FPGAs (some ultimately baked into ASICs), device drivers, etc.
one noteworthy arch point to understand this is that fault tolerance is a strong force; so a PCB often has a “plan B” failover board (so one thinks of the “cross connect board” solution has having an A and B board), and even within 1 PCB there can be fault tolerance (e.g. working from supplied power versus from battery)
as an example, a feature team may include diff people with primary skills in board layout, thermal analysis & refinement (one has to design for heat reduction and dissipation), power, FPGA (verilog), linux device drivers (C and C++), and more
(aside, one can now to TDD with system verilog for FPGAs, with SVUnit, which is fun & useful. i recommend folks here get into FPGA verilog TDD coaching if they want to learn more about HW dev & slicing/increments)
so an obvious huge splitting into (still huge) smaller increments was:
only 1 board; no integration of A and B boards; no failover support
(versus its major complement): integrated A and B boards with failover support
for 1 board, it included power supply failover with primary & secondary (battery) support. note that the team can create in increment which is just a board with only primary power… and nothing else on it. a board with only primary power versus with failover to secondary. this led to the first concrete increments in this example:
a board with primary (externally supplied) power (no other chips/features)
a board with secondary (battery supplied) power (no other chips/features)
a board with primary and secondary power (and failover from primary to secondary)
next, this is DC land (not AC land), and the board needs an AC/DC convertor. and this one has 2 (for fault tolerance). so…
a board with primary and secondary power, and primary AC/DC convertor
a board with primary and secondary power, and secondary AC/DC convertor
a board with primary and secondary power, and primary & secondary AC/DC convertors (and failover)
boards can and should provide info, via sw probes/queries. so…
a board with primary and secondary power, and primary & secondary AC/DC convertors, and can bootstrap to providing “null” service level info
a board with primary and secondary power, and primary & secondary AC/DC convertors, and can bootstrap to providing simple service level info
a board with primary and secondary power, and primary & secondary AC/DC convertors, and can bootstrap to providing rich service level info
boards can and should offer config/control. so…
a board with primary and secondary power, and primary & secondary AC/DC convertors, and can bootstrap to providing rich service level info, and can handle operation “reset”
a board with primary and secondary power, and primary & secondary AC/DC convertors, and can bootstrap to providing rich service level info, and can handle operation “reset” & “enter power save mode”
perhaps that’s enough to get a sense of this hw splitting and increments?
and not surprisingly, the services of the board can be sliced vertically relatively easily using FPGA incremental dev (which is plain old sw feature splitting, really). if the group wants to eventually go down the ASIC path, then if possible we’ll start with FPGAs only and nail that and then later transform to ASICs.
=== watch out for the local optimization cognitive bias of hw component teams ===
btw, reminds me: afaik common introductory advice for apparently “agile” or “scrum” HW dev is to “define separate hw components with clearly defined interfaces and then have separate component teams”. this is no different than the model of pure sw component teams, and leads to the same system dynamics, sub-optimizations, lack of agility, lack of working on highest value, and wastes in hw dev as in sw dev. versus cross-HW-component feature teams. it’s true that sometimes a HW component boundary can’t be bridged by a true feature team due to “hard knowledge” limitations (e.g. at xerox where used to coach, the (1) optical engine, versus the (2) paper feed mechanism, which involves for (1) mostly laser optics knowledge, and for (2) mech eng knowledge, and was too hard to bridge in 1 team). but on average, in LeSS we suggest experimenting with more cross-HW-component feature teams (e.g. 1 team includes diff people with primary skill in mech eng, thermal analysis, FPGA, power, etc). and we ack that sometimes that’s too hard to bridge, but it’s worth experimenting rather than falling into the default thinking trap of local optimization bias in HW components & dev.
recent case: angela johnson is working with a hw/sw product group (doing a LeSS adoption) that has switched to true cross-HW-component feature teams (versus prior “hw component teams with interfaces”), with very positive consequences