近日，一些评论员提出了是否可将敏捷方法应用于硬件开发项目中的疑问。
Neil Johnson在电子工程专辑中发表了一篇文章：敏捷型硬件开发——荒唐还是很有必要？
他提出了一个问题：
将敏捷方法应用到硬件开发中的做法是否存在争议？那些用来指导敏捷软件开发团队的方法论，在片上系统（SoC，System on Chip）的团队中是否仍旧有着相同的指导意义呢？在这两个截然不同的领域中是否存在很大差异？
接着，他在文章中提到了一段关于敏捷宣言（www.agilemanifesto.org）的讨论，以及其如何使敏捷方法成为软件开发的指导思想。然后引出了他的问题——在硬件开发中敏捷行为是否适用？他提到：
对于那些将硬件研发作为一个创新过程的团队来说，很难否定敏捷的价值观是否直接受用。但仅仅关注价值观层面显然是不够的。从某种意义上来讲，抽象的价值观需要转变为具体的实践。幸运地是，软件开发团队已经积累了丰富的实践经验，这些实践恰好体现了敏捷的价值，同时也可在硬件开发中发挥指导性的作用。
他首先承认了在软件和硬件研发活动中存在的不同有着一定的必然性，然后还鼓励硬件团队要在硬件环境中进行敏捷实践的尝试。
接着，他以软件开发中的持续交付为例：
最有代表性的一项实践，就是为客户提供更早地或持续地部署。对于大多数敏捷型软件团队来讲，持续部署对项目的成功起着决定性的作用。不幸地是，在硬件研发中适用性的缺乏，意图打破敏捷的这个特征。尤其对于专用集成电路（ASIC，Application Specific Integrated Circuit）来说，实施持续交付显然不现实。但是，一个实践的不理想并不意味着将整套实践体系否定。没有哪个敏捷型软件开发团队能将敏捷开发的思想实现的淋漓尽致，对于硬件团队，我们也应该持相同的态度。
在最后的结论中，他向以硬件为主的组织提出了倡议：
在硬件开发中需要有所改变。不管这是从改变规范、人员调整、团队激励还是技术开始，变化都无法避免。那些为了获得更好成绩而放弃现有思想的团队，在敏捷宣言的带领下，将会在硬件开发领域重振旗鼓，并取得更好的突破。相反，那些墨守成规的团队，将会在现代化的硬件开发大潮下，继续从事着徒劳且低效的工作。
Larry Maccherone于今日也以类似的方式写谈论了关于在硬件项目中实施敏捷的 10 个首要问题：
他提供了一个列表，在列表中记录了硬件项目中的相关问题以及他的回复，意在以此来引导敏捷思想的实施：
- 在进行非软件项目时（固件类、电子类、机械类等），敏捷实践的思想和过程是否仍旧有效？
- 要想使 Scrum 过程框架在这些项目中发挥作用，需要做哪些调整？
- 在围绕最小可市场化功能（Minimal Marketable Feature）、紧急设计（Emergent Design）以及保持设计垂直瘦小（thin vertical slices）层面，我们期望有哪些调整？
- 在用户故事层面，我们期望有哪些调整？
- 用户故事如何根据为用户带来价值的不同，来确定优先级？
- 用户故事是我们做需求管理时唯一可以使用的工具吗？
- 用户故事甚至在 Scrum 中都没有被列为官方要求，那我们为什么就不能沿用传统的需求调研管理方法呢？
- 当我们需要将一个电路板（或原型）发送给生产厂商，此时，连一次完整的迭代还未完成，又该如何去做呢？
- 依赖和关键路径分析如何去做？
- 或许我们不必持续地做关键路径的分析，但是我们仍然有专家并非永久致力于团队。这种局面我们如何去面对？
在每个问题之后，他都进行了简要的回答，然后就实际实践中可能遇到的冲突和如何去解决问题进行了讨论。
敏捷实践真的能适用于硬件研发么，要想敏捷的思想发挥作用，还需要做出那些改变呢？
注册/登录 InfoQ 发表评论