Atlassian

分散式已是目前的主流架構，當今雲端充斥著許多的平台，在不同的平台上提供著不同的資源，每種資源大都是以分散式的節點組合起來的，若沒有不同的叢集（Cluster- Aware）架構來組織這些資源，那這朵雲會是個什麼樣的混亂，大家可想而知。 •    叢集的规划Cluster •    叢集Cluster类型的介绍 •    叢集存儲Storage •    如下圖顯示 •    高可用High Availability •    负载平衡Load Balancing •    高效能High Performance •    RPO備份 RTO備援 •    RPO 复原时间点目标Recovery Point Object •    RTO 复原时间目标Recovery Time Object •    HA 的模式 no-fencefenceo •    軟件式 None-Fence MODE •    硬件式 Fence MODE 虛擬模式物理模式 •    我們來看一下 Fence-agents 的種類 •   ...

數據由於系統默認導出的數量為1000條，而且後續就不再支持該功能，建議您想要導出超過的數目的方法有幾種分別如下 1.使用插件Enlarge  Your  Excel  Export  for  JIRAhttps://marketplace.atlassian.com/plugins/com.rauliki.ExportAllIssuesExcel.ExportAllIssuesExcel/server/overview 2.使用插件Run CLI Actions in JIRAhttps://marketplace.atlassian.com/plugins/org.swift.jira.acli/server/overview 3.新增或修改參數 jira-config.properties 內容加入底下 jira.search.views.default.max = 10000jira.search.views.max.limit = 10000jira.bulk.edit.limit.issue.count = 10000 置放於Jira Home中重啟，不過該動作會吃內存另外很有可能導致無法啟用，如有這方面的需求,  建議使用插件來解決！...

一、    導入前狀況Y公司內的研發中心規模不大，涵蓋產品團隊、開發團隊、測試團隊、運維團隊。公司內部的每個團隊各自都有屬於自己團隊的流程，初期運作上沒有問題，但面臨到公司內部規模變大，跨團隊的合作上如果沒有固化流程，往往單一團隊運作上都還行，但是一遇到跨團隊的合作，就面臨到需要規範。例如，過去發生沒有經過上線流程，團隊自行上線幾天後才通報；測試延宕許久，但卻不清楚延遲的原因究竟是開發團隊的缺陷修正的問題還是測試團隊測試的時間過長；另外外部需求沒有進行系統化的管理，往往一個需求過來後，就直接到了產品經理這裡開始進行，一些不重要的需求往往重提也無法清楚究竟是誰提出的，需求的管理上比較混亂。因此希望透過一套成熟的流程和系統將流程固化和記錄，另外希望將所有的會議記錄、測試報告、測試用例、驗收報告、驗受單……等等，都能夠透過系統記錄。內部嘗試使用JIRA、Confluence作為內部的流程固化和文檔管理的工具，但卻遇到了內部想法眾多，無法達成共識。 二、    過程改善其實內部都有流程，但是面臨到需要流程整合，另外也需要將外部及內部的需求管理起來。每個團隊中都有人曾經使用過Confluence或是JIRA，但是往往是以前公司的使用經驗，所以導致內部溝通上挺困難的，雖然內部自行導入JIRA，運維人員知道怎麼配置工作流、Issue Type但是卻怎麼樣都無法謝著達成共識。需要有經驗的規劃和設計流程，所以初期一直希望能夠瞭解更多大公司實際使用上的流程，希望可以直接套進來使用，另外也好去說服領導和其他團隊。當初找我過去的時候合同是個JIRA管理員和敏捷培訓單，但一到現場，培訓個半天後，客戶就說需要的不是培訓而是實施導入，希望在三天內可以導入同時說服所有領導。一瞬間我頭髮都快白了，因為實施導入要在短短三天內可以做到相當多的事，除了我每天得加班外，也要快速的溝通及進行系統實施，因為系統實施不僅僅是流程，還有許可權、角色、介面、欄位等等的設計都不是我一個人說了算就行的，更別說這個是由下到上去說服領導的過程，三天之內說實話雖然我還算經驗豐富可以順利完工系統部分，但是這些流程能否順利說服領導說服內部團隊，最後進行修正是否合乎期待，三天對我來說實在是職涯上的一大挑戰。立馬打電話給商務，商務往往都會造一個美好的夢給客戶，本來是培訓和諮詢的單，變成僅三天內必須實施成功的單，天數壓縮，內容不同，還得天天加班的情況，頭髮變白事小，三天導入失敗可是會傷害到我們專業的形象及客戶的信賴，這種商譽的傷害才是最大的，在商務的請求幫忙下，人也都到了客戶這裡，客戶也看起來挺有壓力的情況下，在愛心和責任心的催逼下，我沒有選擇離開，而是留在這裡把所有過去的經驗應用在此，中午連飯都吃不下，客戶還問老師怎麼都不吃飯是不是不合胃口，我是憂心啊兄弟！立馬在中午休息時間，將過去所有的流程全部都一個一個開展開來，努力思考究竟客戶是希望解決什麼樣的問題，就這樣開展了我覺得有可能使用到的20多個開發流程。下午就告知客戶所有團隊我們簽的合同是培訓單，不是實施單，這麼短的時間內做到實施成功，需要各位一起協助，就這樣一個又一個的流程過，想不到意外的是，不打算做敏捷的客戶，居然看上了一個全面敏捷流程、一個標準研發流程、一個快遞業的設計方式，就這樣結合起來成為後續我們的應用流程如下： 溝透過程才發現，最重要的是希望將需求給管理起來，從需求提出、產品端判斷分給所屬開發專案、開發和測試UI團隊進行設計開發測試、運維團隊的上線流程、驗收等等流程進行系統化的管理和控制，我們設立一個獨立的需求專案及其他開發專案，透過需求專案收集所有內外不需求，另外需求確認後由產品經理統一分派到所屬的開發專案，同時透過子任務的設計，將獨立的UI設計任務、測試用例撰寫、測試任務、開發任務、上線任務，進行分派給所屬的團隊進行處理。 另外Confluence由於內部已經使用起來，所以直接透過彈框中將所屬的會議記錄、測試報告的URL記錄在JIRA上，把整個JIRA上可以妥善清楚流程， 另外由於測試主管、開發主管、運維主管都希望能夠知道各個專案所屬的團隊究竟參與了多少，所以在JIRA面板中採用了二維篩檢程式，將每位測試、開發、運維參與在那些專案中的情況，還有每個人參與的任務情況清楚展開來。 這樣這些領導們就可以清楚他們的資源和參與的情況，能夠有效快速的管理，由於天期不是太多，所以沒法一個一個團隊都進行溝通瞭解實際使用的報表，不過就一個初期e化的團隊，應該暫時可以夠他們使用一段時間，待後續的流程固化後，在進行二期、三期的實施調整優化，最後設計完成後，在內部進行2天所有用戶的教育訓練及試運行打單操作，就這樣頭髮白了幾根的情況下，完成了這些任務，大領導後來也大力支持推動JIRA的實施和導入，就這樣Y公司的夥伴們也開始進入了JIRA的世界。 三、    未來發展建議說真的這中間有太多的故事和溝通的過程，只要是實施就少不了跨團隊”強力”的溝透過程，一些許可權還有工作流太細節的部份太過繁瑣就不在此分享，但是能夠推動起來真的是相當不易啊，由於Y公司使用JIRA還在較初期的階段，也還沒有推動起內部的敏捷實施，所以目前僅使用基礎的JIRA和Confluence功能，一些報表外掛程式還有看板、Scrum板的應用就待下回二期實施的時候，再繼續應用下去，畢竟內部文化的轉化，還是得漸進式逐步推廣才是，期待下回了。 A Section Subtitle* Write one or two paragraphs describing your product, services or a specific feature. To be successful your content needs to be useful to your readers. Start with the customer – find out what they want and...

Jira Core Jira Software Jira Service Desk 專案 *V * *V * *V * *流程* *V * *V * *V * *收尋* *V* *V * *V * *面板* *V * *V * *V * *報告* *V * *V * *V * *敏捷看板 * * * *V * * * *Backlog計劃*...