\ 他提出了乙個問題：
\
\\將敏捷方法應用到硬體開發中的做法是否存在爭議？那些用來指導敏捷軟體開發團隊的方**，在片上系統（soc，system on chip）的團隊中是否仍舊有著相同的指導意義呢？在這兩個截然不同的領域中是否存在很大差異？
\
接著，他在文章中提到了一段關於敏捷宣言（www.agilemanifesto.org）的討論，以及其如何使敏捷方法成為軟體開發的指導思想。然後引出了他的問題——在硬體開發中敏捷行為是否適用？他提到：
\
\\對於那些將硬體研發作為乙個創新過程的團隊來說，很難否定敏捷的價值觀是否直接受用。但僅僅關注價值觀層面顯然是不夠的。從某種意義上來講，抽象的價值觀需要轉變為具體的實踐。幸運地是，軟體開發團隊已經積累了豐富的實踐經驗，這些實踐恰好體現了敏捷的價值，同時也可在硬體開發中發揮指導性的作用。
\
他首先承認了在軟體和硬體研發活動中存在的不同有著一定的必然性，然後還鼓勵硬體團隊要在硬體環境中進行敏捷實踐的嘗試。
\ 接著，他以軟體開發中的持續交付為例：
\
\\
在最後的結論中，他向以硬體為主的組織提出了倡議：
\
\\在硬體開發中需要有所改變。不管這是從改變規範、人員調整、團隊激勵還是技術開始，變化都無法避免。那些為了獲得更好成績而放棄現有思想的團隊，在敏捷宣言的帶領下，將會在硬體開發領域重振旗鼓，並取得更好的突破。相反，那些墨守成規的團隊，將會在現代化的硬體開發大潮下，繼續從事著徒勞且低效的工作。
\
larry maccherone於今日也以類似的方式寫談論了關於在硬體專案中實施敏捷的10個首要問題：
\ 在進行非軟體專案時（韌體類、電子類、機械類等），敏捷實踐的思想和過程是否仍舊有效？\
要想使scrum過程框架在這些專案中發揮作用，需要做哪些調整？\
在圍繞最小可市場化功能（minimal marketable feature）、緊急設計（emergent design）以及保持設計垂直瘦小（thin vertical slices）層面，我們期望有哪些調整？\
在使用者故事層面，我們期望有哪些調整？\
使用者故事如何根據為使用者帶來價值的不同，來確定優先順序？\
使用者故事是我們做需求管理時唯一可以使用的工具嗎？\
使用者故事甚至在scrum中都沒有被列為官方要求，那我們為什麼就不能沿用傳統的需求調研管理方法呢？\
當我們需要將乙個電路板（或原型）傳送給生產廠商，此時，連一次完整的迭代還未完成，又該如何去做呢？\
依賴和關鍵路徑分析如何去做？\
或許我們不必持續地做關鍵路徑的分析，但是我們仍然有專家並非永久致力於團隊。這種局面我們如何去面對？\
在每個問題之後，他都進行了簡要的回答，然後就實際實踐中可能遇到的衝突和如何去解決問題進行了討論。
\ 敏捷實踐真的能適用於硬體研發麼，要想敏捷的思想發揮作用，還需要做出那些改變呢？
\檢視英文原文：can agile development work in hardware projects?
在專案中敏捷開發方法Scrum
公司在上cmmi 雖然很多人都覺得那是那是形象工程。公司的同事說，上cmmi可以忽悠一下 可以，最怕的就是領導把上cmcmi還真當回事了。在專案裡面試用了幾個月沒感覺到很大起色,曾經有人說中國根本就不適合去追求印度式的那種軟體開發過程，印度人太死板，適合做這些沒有創造力的活兒。中國國情不同，中國的開...
gradle在專案中的應用
compilesdkversion 代表是使用的sdk版本buildtoolsversion 代表構建工具的版本,一般都是sdk相配套的。在專案建立的時候就會自動生成signingconfigs 簽名配置,主要有 develop,release develop 開發時候的配置keyalias apk...
Kibana在專案中的應用
雖然本文主要闡釋kibana 在專案中的應用 但是我們需要了解乙個常識，那就是一般情況下elk都是組合應用的，在我們的專案中我們也是一起使用的，但是由於對kibana 的頗具熱情，所以本文是對kibana的初始 先說下專案背景，我是datawarehouse 的 免不了會對些個datastage j...