敏捷開發(fā)培訓(xùn)(Agile_Development)

1、2022-4-41Agile Development敏捷開發(fā)Jack Ding ()09/28/20102022-4-42Content nAgile Development介紹nRUPnXPnScrum2022-4-43Agile Process - 敏捷的開發(fā)流程敏捷的開發(fā)流程nAgile Process (敏捷的開發(fā)流程) 是一種軟件開發(fā)流程的泛稱，幾項共通的特性 ：客戶與開發(fā)人員形成密切合作的團隊，因為客戶無法于初期定義完整的規(guī)格，而開發(fā)人員于開發(fā)過程中也常常無法知悉外在環(huán)境或業(yè)務(wù)的變動，所以需要兩者密切合作方能開發(fā)適用的軟件。 項目最終的目標(biāo)是可執(zhí)行的程序，因此所有的中間產(chǎn)品必須經(jīng)過

2、審慎評估，確認(rèn)有助于最終目標(biāo)，才需要制作中間產(chǎn)品。 采用 Iterative 與 Incremental 方式分階段進行，密集 review 是否符合需求。 流程可以簡單，但規(guī)劃與執(zhí)行必須嚴(yán)謹(jǐn)。 1.強調(diào)團隊合作，賦予高度的責(zé)任，團隊有自主權(quán)得以因應(yīng)變化做調(diào)整2022-4-44Agile Developmentn敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法 n在敏捷開發(fā)中，項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征 。2022-4-45敏捷開發(fā)核心價值 (Core Value)nIndividuals and interactions over pr

3、ocesses and tools 個人和交流重于過程和工具nWorking software over comprehensive documentation 正在運行的軟件本身重于復(fù)雜的文檔nCustomer collaboration over contract negotiation 與客戶的溝通和交流重于使用合同約束客戶nResponding to change over following a plan對變化的快速響應(yīng)重于跟隨計劃2022-4-46敏捷開發(fā)原則(Principles)最高目標(biāo)是通過快速的和經(jīng)常的發(fā)布軟件滿足客戶的需要提交軟件的周期為幾個星期到幾個月產(chǎn)生正確的軟件是衡

4、量進度的首要標(biāo)準(zhǔn)主動接受需求的改變而不是拒絕商務(wù)人員和開發(fā)人員工作在一起個人必須有動力，要創(chuàng)造環(huán)境支持他們的要求，信任他們最有效的交流方法是面對面的交流最好的結(jié)構(gòu)，需求和設(shè)計來自于自組織的團隊（self-organizing team），允許任何人提出想法和建議持續(xù)改進設(shè)計和編碼鼓勵正常工作，減少長時間加班保持簡單，減少不必要的部分，認(rèn)識到簡單的設(shè)計比復(fù)雜的設(shè)計更難（simple design is harder to produce）定期調(diào)整過程，獲得更高效率2022-4-47敏捷開發(fā)的設(shè)計原則 nSRPn單一職責(zé)原則SRP：Single Responsibility Principle n

5、OCPn開放封閉原則OCP：OpenClose Principle nLSPnLiskov替換原則LSP：Liskov Substitution Principle nDIPn依賴倒置原則DIP：Dependency Invertion Principle nISPn接口隔離原則ISP：Interface Separate Principle 2022-4-48敏捷開發(fā)-迭代計劃最新版本驗收測試發(fā)布計劃迭代計劃開發(fā)項目周期項目周期2022-4-49敏捷開發(fā)-迭代計劃2022-4-410名詞解釋故事故事 是客戶想要系統(tǒng)做的事情，適合在一至兩個迭代內(nèi)完成，并且是可測試的，他不一定是商業(yè)價值的直接體

6、現(xiàn)。迭代迭代 是一個周期在2-4周，能夠完成當(dāng)前團隊所能實現(xiàn)的，最具商業(yè)價值的功能，并可以提供一個可工作的小版本供發(fā)布。Velocity 翻譯為項目周轉(zhuǎn)時間。代表團隊在給定周期內(nèi)能夠完成多少商業(yè)價值，以便用于衡量將來該團隊能夠提供的商業(yè)價值。也即昨天的天氣。2022-4-411名詞解釋優(yōu)先級優(yōu)先級 主要考慮商業(yè)價值，同時兼顧市場風(fēng)險、商業(yè)風(fēng)險、技術(shù)風(fēng)險等因素在內(nèi)的一個衡量數(shù)字，優(yōu)先級越高通常意味著其商業(yè)價值越高風(fēng)險系數(shù)風(fēng)險系數(shù)風(fēng)險系數(shù) 綜合商業(yè)環(huán)境、項目資源、技術(shù)以及項目環(huán)境等等因素在內(nèi)的一個衡量數(shù)字，它是優(yōu)先級的重要衡量指標(biāo)之一。它通常出現(xiàn)在故事中。風(fēng)險系數(shù)較大意味著優(yōu)先級也較大。負(fù)載因子負(fù)

7、載因子負(fù)載因子 是綜合項目成員的技術(shù)能力、技能集、精神狀態(tài)等等因素，對于團隊成員的一個負(fù)載系數(shù)。2022-4-412名詞解釋理想時間理想時間 排除一切可能的外界干擾，同時排除自身的精神狀態(tài)，職業(yè)態(tài)度等等因素，完成某項工作所需要的時間。實際時間實際時間 理想時間乘上負(fù)載因子任務(wù)任務(wù)任務(wù) 分配到項目成員，從故事切分的出來。通常任務(wù)時間不應(yīng)該超過10個實際工作日。2022-4-4131. RUP2. XP3. Scrum2022-4-414RUP- Rational Unify ProcessnRUP 為 IBM Rational 提出的軟件開發(fā)流程n內(nèi)容含蓋 Business modeling,

8、Requirement Modeling, Logical Design, Implementation, Testing, Deployment 等軟件開發(fā)生命周期的直接工作n與 Project Management, Change & Configuration Management，Environment support 等支持性工作。 2022-4-415RUP 的主要精神 項目進行采用 Iterative 程序分階段漸進地完成項目功能；廣泛使用 Visual Modeling 于商業(yè)需求分析、系統(tǒng)分析與系統(tǒng)設(shè)計；強調(diào)架構(gòu)設(shè)計；對每項工作所需要的技術(shù)、工具、做法、模板、檢查項目均有詳細(xì)

9、的定義，架構(gòu)完備且具有可調(diào)整的彈性。2022-4-4161. RUP2. XP3. Scrum2022-4-417XP - eXtreme Programmingn極限編程，最輕量級的開發(fā)流程，其最主要的精神是在客戶有系統(tǒng)需求時，給予及時滿意的可執(zhí)行程序，所以最適合需求快速變動的項目 n強調(diào)客戶所要的是 workable 的執(zhí)行碼，所以把與撰寫程序無關(guān)的工作降至最低，并要求客戶與開發(fā)人員最好以 side-by-side 的方式一起工作 2022-4-418XP強調(diào)4個因素n交流(communication)，XP要求程序員之間以及和用戶之間有大量而迅速的交流n簡單（simplicity），XP

10、要求設(shè)計和實現(xiàn)簡單和干凈n反饋（feedback）通過測試得到反饋，盡快提交軟件并根據(jù)反饋修改n勇氣（courage）。勇敢的面對需求和技術(shù)上的變化2022-4-419XP 開發(fā)流程 n開發(fā)人員隨時可以和客戶進行有效溝通，撰寫 user stories 以確認(rèn)需求。n簡易快速的系統(tǒng)設(shè)計，撰寫?yīng)毩⒌尿炞C程序以解決特殊困難的問題，找出算法即可丟棄驗證程序。n規(guī)劃多次小型階段的項目計劃，以最快速度完成每一階段的程序交付客戶，客戶負(fù)責(zé) Acceptance tests；nCoding 前必須完成 Unit Test 與 Acceptance tests 程序，所有模塊整合前都須經(jīng)過 Unit Test

11、s；n開發(fā)人員必須快速響應(yīng) Bug 與需求變更；n要求二人一組使用一臺計算機設(shè)計程序，當(dāng)一人 coding 時，另一人負(fù)責(zé)思考與設(shè)計；n程序必須符合程序規(guī)范，并常做程序的重構(gòu) (Refactoring)。2022-4-420XP原則和實踐-Planning-user storiesnuser stories nUser stories類似use case， 描述用戶所見的系統(tǒng)功能，但避免使用大量的文檔，user stories由用戶編寫（不僅限于描述用戶界面）。User stories使用用戶的語言編寫，不使用技術(shù)性的語言，每個user stories限于幾句話。User stories用于在

12、release plan會議上對開發(fā)時間進行評估，也用于產(chǎn)生驗收測試（acceptance test），必須使用可以自動進行的驗收測試保證軟件的正確性。User stories與傳統(tǒng)的用戶需求的區(qū)別在于詳細(xì)的程度，user stories并不會確定需求的每個細(xì)節(jié)，它只是用來簡單的描述系統(tǒng)功能，供開發(fā)人員進行估計開發(fā)進度，在開發(fā)過程中開發(fā)人員和用戶會不斷的交流以討論細(xì) 節(jié)問題。User story應(yīng)該專注于功能，不應(yīng)該過分注重用戶界面等細(xì)節(jié)。一般一個user storiy在1-3周的時間完成，如果估計超過3周，說明user story太大了，需要細(xì)分 .2022-4-421XP原則和實踐-Pla

13、nning-release plannrelease plan n召開一個 release plan會議，產(chǎn)生release plan。Release plan將用于指定每個iteration的計劃。開發(fā)人員對每個user story估計開發(fā)時間（在不被打斷，無其他工作情況下的開發(fā)時間，包括測試），用戶對user stories給出優(yōu)先級，release plan會議并不制訂每個iteration的計劃。Release plan要用戶，開發(fā)人員和管理者都同意，在完成功能范圍（scope），使用資源（resource）,時間（time）和質(zhì)量(quality)上達 成一致（一般質(zhì)量是不能改變的）

14、 2022-4-422XP原則和實踐-Planning-small releasensmall releasenoften and small release是XP的一個原則，每個release完成一些用戶有意義的功能集合，盡快的提交給用戶以獲得反饋，及時調(diào)整，提交的越晚，調(diào)整越困難。 2022-4-423XP原則和實踐-Planning-project velocitynproject velocity n團隊在開發(fā)過程中要收集數(shù)據(jù)，以便于對自己的開發(fā)速度進行評估，用于以后的releazse plan2022-4-424XP原則和實踐-Planning-iterationniteration

15、 n每個small release的周期稱為iteration，每個iteration約為1-3周，在一個項目中保持每個iteration的時間相等，不要超前制定計 劃，每個iteration的計劃在iteration的開始時制定。這樣能夠更靈活的應(yīng)付變化。不要急于完成本次iteration沒有包括的功能。要 注重每個iteration的時間限制，當(dāng)團隊覺得不能按時完成iteration時，召開一次iteration plan會議，重新評估，減少一些user stories。2022-4-425XP原則和實踐-Planning-iteration planniteration plan n在每

16、個 iteration開始的時候召開會議，從release plan中選擇還沒有實現(xiàn)的用戶最迫切需要的user stories。上一個iteration中沒有通過驗收測試的功能也要在這個iteration中實現(xiàn)?？梢愿鶕?jù)上一個iteration的實踐調(diào)整團 隊速度。User stories和失敗的測試被分解成programming task，task使用技術(shù)語言編寫，作為iteration plan的詳細(xì)描述。程序員主動領(lǐng)取task并估計完成時間，每個task應(yīng)該在1-3天內(nèi)完成，超過3天的task應(yīng)該被細(xì)分。如果整個團隊需要的時間 多于或少于規(guī)定的iteration時間，調(diào)整user sto

17、ries。 2022-4-426XP原則和實踐-Planning-move people aroundnmove people around n不要使每個開發(fā)人員局限于一項工作，不要使某項工作依賴于一個開發(fā)人員，增加知識共享，減少信息孤島，多進行交流和培訓(xùn)。當(dāng)項目中的所有人對所有模塊都了解并可以進行開發(fā)時是效率最高的，鼓勵開發(fā)人員在不同iteration中開發(fā)不同的模塊。 2022-4-427XP原則和實踐-Planning-stand-up meetingnstand-up meeting n每天工作 開始之前，開5-10分鐘的stand-up會議（站立會議），站立的目的是為了強迫節(jié)省時間，

18、會議的目的是交流，提出存在的問題，但不要在會議上解決問 題。開一個所有人員參加的短會比多個個別人員參加的會議要高效。在會議上提出的問題可以由少數(shù)人討論解決，這個少數(shù)人參加的會議如果涉及到代碼，可以在計算機前討論。 2022-4-428XP原則和實踐-Planning-fix XP when it breaksnfix XP when it breaks nXP并不是一成不變的，當(dāng)團隊覺得需要修改的時候，可以根據(jù)自己的情況進行修改，任何修改都要經(jīng)過整個團隊的討論和達成一致 2022-4-429XP原則和實踐-Designing-1nSimplicity n保持簡單的設(shè)計，在完成同樣的功能的情況下

19、，選擇簡單的設(shè)計，不要急于設(shè)計沒有計劃的功能，應(yīng)該認(rèn)識到：keeping a design simple is hard work nSystem metaphor n使用統(tǒng)一的術(shù)語描述系統(tǒng)，在用戶，管理者和開發(fā)人員之間使用統(tǒng)一的術(shù)語。這將使交流清晰。 nCRC card n使用CRC(Class, Responsibilities, and Collaboration) card進行系統(tǒng)設(shè)計，鼓勵更多的人參加設(shè)計。每個CRC卡片表示系統(tǒng)中一個對象，寫上對象的名字，責(zé)任和每個責(zé)任需要交互的其他對象?？梢阅M對象之間 的交互。CRC卡片是易于理解的，但是是非正式的，如果需要正式的文檔，要將卡片轉(zhuǎn)

20、換為相應(yīng)的文檔。nspike solution nnever add function early nrefactoringwhenever and wherever 2022-4-430XP原則和實踐-Designing-2nspike solution n使用spike solution減低風(fēng)險，當(dāng)遇到技術(shù)難題或設(shè)計問題時，使用簡單的程序進行測試，找出問題，在不同的解決方法之間進行評估。在早期進行實驗可以有效的降低風(fēng)險。 nnever add function early n不要過早的設(shè)計沒有計劃的功能，在一個需求經(jīng)常變化的環(huán)境中，過早的設(shè)計經(jīng)常是沒有用的。 nrefactoringwhe

21、never and wherever nXP鼓勵對設(shè)計和代碼經(jīng)常進行重構(gòu)（Refactoring），目的是去除冗余，提高質(zhì)量，保持設(shè)計簡單。重構(gòu)必須以完全測試為檢驗條件2022-4-431XP原則和實踐-Coding-1ncustomer is alaways availablen用戶是項目組的成員之一，用戶的參加貫穿整個開發(fā)過程，用戶與開發(fā)人員之間的交流是重要的 ncoding standard n使用統(tǒng)一的編碼標(biāo)準(zhǔn)，這是保持代碼整潔和共享代碼的基礎(chǔ) ncoding unit test first ntest first是XP的一個特點，在編寫代碼之前先編寫單元測試代碼，單元測試代碼和代碼由

22、同一個程序員完成。先編寫測試代碼可以使程序員更好的理解需求，避免直接編碼造成的理解偏差，對需求的不清晰，可以在編寫測試代碼時就發(fā)現(xiàn)。測試代碼也是檢驗程序是否完成的標(biāo)準(zhǔn)。編碼工作應(yīng)該是以下工作的循環(huán)：1 編寫測試代碼2 運行測試程序，確認(rèn)失敗3 編寫實現(xiàn)這個測試程序要求功能的代碼，不需要實現(xiàn)其他的功能，只需要實現(xiàn)剛剛滿足測試程序的功能4 運行測試程序，確認(rèn)成功實踐證明，test first方式需要的編碼實踐少于先編碼，后寫測試代碼2022-4-432XP原則和實踐-Coding-2nPair Programming nPair programming是XP的特色，它要求兩個程序員在一臺計算機上同

23、時進行編程工作。共用鼠標(biāo)和鍵盤，通常一個人進行戰(zhàn)略上的思考，程序架構(gòu)和函數(shù)， 類之間的關(guān)系，一個人進行輸入和戰(zhàn)術(shù)上的思考，完成函數(shù)和類。兩個人可以經(jīng)常交換角色。 nsequential integration n要保證源代碼庫的狀態(tài)是可標(biāo)識的，同一時間，只允許一個pair的程序進行整和和測試，這樣可以縮小問題產(chǎn)生的范圍。不同的pair可以在自己的機器上隨時進行整和和測試.nintegrate often n只要有可能 就進行代碼整合，周期可以在幾個小時，最好不要超過一天。 2022-4-433XP原則和實踐-Coding-3n共同擁有代碼 n鼓勵每個人對項目中的任何人提 出新的想法，任何開發(fā)人

24、員對項目中的任何代碼都可以進行增加功能，改正錯誤和重構(gòu)。 n優(yōu)化工作放在最后 n先使系統(tǒng)能夠正常工作，不要猜測系統(tǒng)的瓶頸，要實際測量 nNO overtime n不要長時間的加班，大多數(shù)加班并不能挽回已有的延遲，連續(xù)超過兩個星期的加班說明有問題存在。向一個已經(jīng)延遲的項目填加人員也不是一個好的選擇。 2022-4-434XP原則和實踐-Testing-1n所有的代碼都有單元測試 n單元測試是XP的基 石，XP中的單元測試應(yīng)該是可以自動進行的，所以可以很快的進行所有的單元測試，單元測試應(yīng)該在編碼之前創(chuàng)建。單元測試的代碼和代碼一起release， 沒有單元測試的代碼不能夠release。使用自動單元

25、測試可以系統(tǒng)整合時節(jié)省大量的發(fā)現(xiàn)錯誤和改正的時間。單元測試越完善，節(jié)省的時間越多。 n代碼在release前必須通過所有的單元測試 n發(fā)現(xiàn)bug后，首先增加測試 n在實際運行中發(fā)現(xiàn)bug,首先增加acceptance test，然后增加unit test，在增加完測試后在查找和修改代碼，增加的測試保證同樣的錯誤不會再出現(xiàn) nacceptance test nacceptance test根據(jù)user stories在iteration plan會議上創(chuàng)建，它也應(yīng)該可以自動運行以便可以經(jīng)常運行。 2022-4-4351. RUP2. XP3. Scrum2022-4-436ScrumScrum

26、2022-4-437Scrum特點n自我管理的團隊n以“sprint”為周期迭代的產(chǎn)品開發(fā)n以一系列“產(chǎn)品 Backlog”記錄了產(chǎn)品需求n沒有特定的工程實踐慣例n在以生成規(guī)則創(chuàng)造的敏捷開發(fā)環(huán)境交付產(chǎn)品n是其中一種“敏捷方法”2022-4-438SCRUM 開發(fā)流程開發(fā)流程 nSCRUM 開發(fā)流程是 Agile Process 的一種，以英式橄欖球爭球隊形 (Scrum) 為名，基本假設(shè)是開發(fā)軟件就像開發(fā)新產(chǎn)品，無法一開始就能定義 Final Product 的規(guī)程，過程中需要研發(fā)、創(chuàng)意、嘗試錯誤，所以沒有一種固定的流程可以保證項目成功。 nScrum 將軟件開發(fā)團隊比擬成橄欖球隊，有明確的最

27、高目標(biāo)，熟悉開發(fā)流程中所需具備的最佳典范與技術(shù)，具有高度自主權(quán)，緊密地溝通合作，以高度彈性解決各種挑戰(zhàn)，碓保每天、每個階段都朝向目標(biāo)有明確的推進，因此 SCRUM 非常適用于產(chǎn)品開發(fā)項目。 2022-4-439SCRUM 開發(fā)流程開發(fā)流程(cont.)nSCRUM 開發(fā)流程通常以 30 天為一個迭代周期，每個迭代周期叫做一個Sprint，由客戶提供新產(chǎn)品的需求規(guī)格開始，開發(fā)團隊與客戶于每一個階段開始時挑選該完成的規(guī)格部份，開發(fā)團隊必須盡力于 30 天后交付成果，團隊每天用 15 分鐘開會檢視每個成員的進度與計劃，了解所遭遇的困難并設(shè)法排除，決定第二天的任務(wù)安排 .nSCRUM較為有特色的，是它

28、特別強調(diào)開發(fā)隊伍和管理層的交流協(xié)作。每天，開發(fā)隊伍都會向管理層匯報進度，如果有問題，也會向管理層要求幫助解決。 2022-4-440Scrum總體骨架總體骨架迭代迭代每30天Daily SCRUM每24小時高優(yōu)先級可運行的軟件可運行的軟件工作項分解產(chǎn)品訂單產(chǎn)品訂單Product Backlog迭代訂單迭代訂單Sprint Backlog新的功能新的功能增量增量迭代規(guī)劃會議迭代規(guī)劃會議Sprint Plan一般不超過8小時。前4個小時：產(chǎn)品負(fù)責(zé)人向團隊展示最高優(yōu)先級的產(chǎn)品，團隊則向他詢問產(chǎn)品Backlog的內(nèi)容、目的、含義及意圖。后4小時：團隊計劃本Sprint的安排迭代復(fù)審會議迭代復(fù)審會議Sp

29、rint Review 一般4個小時，由團隊成員向產(chǎn)品負(fù)責(zé)人額其他利益相關(guān)人展示Sprint周期內(nèi)的產(chǎn)品開發(fā)情況迭代回顧會議迭代回顧會議Sprint Retrospective一般3個小時， ScrumMaster將鼓勵團隊在SCRUM過程框架和實踐范圍內(nèi)，對開發(fā)過程做出修改，使它在下一個Sprint周期中更加有效和令人愉快每日站立會議每日站立會議Daily Scrum Meeting在簡會上，每個成員主要回答三個問題;自上次SCRUM簡會后的一天了（昨天），你做了什么?從現(xiàn)在到下次SCRUM簡會的一天里（今天），你要做什么?在實現(xiàn)SCRUM及項目目標(biāo)的工作中，你遇到哪些困難嗎? 產(chǎn)品負(fù)責(zé)人產(chǎn)

30、品負(fù)責(zé)人Scrum主管主管開發(fā)團隊開發(fā)團隊2022-4-441順序 vs. 重疊開發(fā)過程Scrum并非以一段時間集中完成一個過程.而是將所有過程中必須的每一部分集中在這段時間內(nèi)完成需求設(shè)計代碼測試2022-4-442Scrum 結(jié)構(gòu)框架產(chǎn)品所有者ScrumMaster團隊職能迭代計劃迭代驗收迭代回顧每天召開的 scrum 會議儀式產(chǎn)品backlog迭代 backlog進度曲線圖產(chǎn)出2022-4-443Scrum Teamn自組織的團隊n 跨功能團隊沒有角色區(qū)分n 最少2個,最多7個n 對工作交付負(fù)責(zé)n只要交付工作需求,授權(quán)做任何事情.2022-4-444Scrum角色及職責(zé)角色及職責(zé)火腿雞蛋！

31、三思過后我決定不和你開餐館了。因為我全身心投入，而你只牽涉入內(nèi)！2022-4-445Chickens & PigsnPigs: Scrum Team 成員: 他們承諾對迭代目標(biāo)交付負(fù)責(zé)nChickens : 項目組有關(guān)的成員,但并不專注于項目n以觀察者的形式參加Scrum meeting2022-4-446Product OwnernBacklog優(yōu)先級制定開發(fā)的版本規(guī)劃n必須確保驅(qū)動開發(fā)的需求只有一份n受管理層,客戶等影響但僅PO有權(quán)調(diào)整Backlogn與相關(guān)成員協(xié)同工作來確定Product Backlog的itemsn消除關(guān)于Backlog的疑惑,確保理解一致,消除干擾2022-4-447

32、Scrum MasternScrum Master 職責(zé)n確保SCRUM的成功n 實施 SCRUM 實踐和規(guī)定, 保護團隊以免受干擾n 項目管理的代表2022-4-448Sprintn交付產(chǎn)品的固定的時間箱.建議2-3周n迭代包括design, coding, testing, and documentationn一旦迭代開始,僅 Scrum Team 能增加或者刪除Sprint backlog中的itemsn當(dāng)?shù)哪繕?biāo)變的沒有意義的時候,才能終止迭代開發(fā)n對于Product Backlog,不允許迭代內(nèi)的需求變更：需求優(yōu)先級調(diào)整僅存在于迭代之間2022-4-449如何定義Sprintn團隊自己從產(chǎn)品的backlog中選擇一些他們能夠完成的任務(wù)作為迭代的backlogn迭代backlog被創(chuàng)建n任務(wù)被確認(rèn)并且每一任務(wù)估計工作量應(yīng)該在1-16小時左右n迭代的b