jira敏捷項目管理
jira敏捷項目管理

本文目錄一覽:
JIRA 優點有哪些?
定制、問題跟蹤。
JIRA的svn?hook可以在svn?commit之后將信息跟某個case綁定,只需要在commit?comment里面寫上jira?id與confluence整合:在confluence中輸入jira?id,就能自動生成一個包含case?title的鏈接,很有用,tempo插件用來跟蹤每個員工在什么case上花費了時間。
JIRA自定義配置中主要有-?IssueType-?Workflow-?Screen-?Custom?Fields由這四項可自由通過Scheme定義出任意的組合以滿足工作中不是的Issue流程處理。從設計的角度它的可變性,擴展性很高。
JIRA的插件利用JIRA這方面設計開發出豐富第三插件。如果你去看JIRA的源碼的話。JIRA本身的功能也都是利用Plugin實現的。JIRA Agile通過JIRA的可定制問題和靈活的工作流提供了一種適應團隊發展的敏捷項目管理工具。
在JIRA中定制與敏捷開發相關的問題類型、字段和工作流,快速適應組織中流程的變化。在一個JIRA Agile看板中可以顯示多個JIRA項目的開發狀態。比如你可以首先從一個Scrum面板開始,然后通過添加列約束從而與看板方法實踐相結合。
敏捷開發項目的管理流程
導語:對于敏捷開發項目的管理流程,相關人員要清楚。下面是我收集整理的敏捷開發項目管理流程,供各位閱讀和參考。
前段時間給大家整理了敏捷開發的流程,最近在整理敏捷開發項目的流程和管理制度,其整理的項目管理規程如下,這份規程也不完全算是敏捷專屬的項目管理規程,主要是在結合我們公司實際的情況下編寫出來的,大家在實際嵌入到公司的過程中可以參考下,不能照搬。
1. 目的
規范互聯網軟件產品開發項目管理過程,指導開展項目研發、管理等活動。
2. 適用范圍
本章程的作用范圍為互聯網軟件產品開發立項至結項管理過程。
1.對項目經理開展產品規劃及設計活動以及項目管理手段和應遵循的開發流程提供了指導;
2.對項目團隊的日常管理活動及內容進行了指導;
3. 角色及職責定義
項目經理:
進行產品開發過程中的業務目標、進度、成本、質量控制。
挑選項目團隊并進行團隊建設,激發、鼓舞和改進團隊的生產效率。
識別項目干系人,定期向干系人匯報,并作為團隊和外部的接口,屏蔽外界對團隊的干擾。
確保項目中流程被遵循,組織、監督、培訓項目各實踐活動。
產品策劃
確定產品的功能,拆分用戶故事。
需求功能確定優先級。
接受或拒絕開發團隊的工作成果。
參與產品開發過程中的有關會議。
UI
根據用戶故事,負責產品的功能交互及界面設計
組織開展人機交互及用戶體驗,不斷跟蹤改進,提高產品表現力。
參與產品開發過程中的有關會議。
開發
根據用戶故事,負責產品的技術架構設計及功能開發
評估、設計及維護產品相應模塊,確保模塊的穩定性、易用性、高效性。
參加產品開發過程中的有關會議。
測試
根據用戶故事,設計產品測試標準,確保產品品質滿足市場需求。
合理分配測試資源,組織產品測試并優化測試流程及測試標準,提高測試效率。
編寫產品測試用例,提交測試問題,編寫測試總結報告,以測試角度來確定產品版本是否發布。
4. 項目管理過程
按照互聯網軟件產品項目開發過程,可將整個項目管理過程分為立項過程、規劃過程、執行與監控過程、結項過程。下面分別闡述在每個階段過程中該如何進行項目管理。
4.1 立項過程
互聯網軟件產品開發項目的立項過程,通常是指從準備項目啟動會到召開會議這個階段,在立項過程中,需要完成項目目標,需求范圍的初步確認,項目團隊成員,其他資源的安排。
確定項目的初步目標并達成共識
對于項目目標,需要和干系人在以下幾點上達成共識:
項目的背景、目標用戶、核心人員及產品定位是什么
項目的資源投入預算是多少
項目的資源投入是多少
各人員在項目中扮演的角色和對項目的作用是什么
準備啟動會議文檔
文檔內容包括:
用戶畫像
產品定位
市場策略
業務目標
技術可行性
研發成本預算
路標規劃
召開項目啟動會
參加人員包括:
管理層代表
項目經理及項目團隊
其他干系人代表
主要議題包括:
申明項目目標范圍及對組織目標的貢獻。
管理層正式任命PM,設定期望,統一思想
文檔內容的宣講。
與PM小組確定項目管理要求
項目啟動會完成后,需要與PM小組成員確定項目立項機制以及公司項目管理要求。
4.2 規劃階段
在規劃階段,團隊需要共同完成產品的版本規劃,迭代計劃
版本規劃
從產品的關鍵特性列表中按照優先級規劃產品每個版本需要完成哪些特性,在規劃完成后需要在項目干系人內達成共識。具體可參考《版本規劃樣例》
迭代如何劃分
迭代劃分是指將特性列表拆分形成用戶故事列表,并將其對應的主要任務劃分到各個迭代中去,形成粗粒度的項目迭代計劃。這個過程主要考慮以下幾個因素:
有些任務間是有依賴關系,某個任務的開始或結束是以另一個任務的開始或結束為前提,在劃分時必須考慮這種前后依賴關系。
在安排每個迭代的任務時,需要對各種因素進行綜合考慮,如平衡每個迭代中任務的技術難度和價值差異。
除了進行初步的迭代任務劃分,還需要確定項目過程中迭代任務調整的規則,如迭代任務未完成時是將剩余任務延至下一迭代還是延長迭代周期。
確定人員分工
項目經理需要根據每個人員的能力和特點,初步擬定大致分工。在進行任務分工時需考慮以下因素:
任務難度與人員能力相匹配,對于明顯超出能力范圍或過于簡單的任務容易造成負面影響。
耦合度高的盡量分配給同一個人,避免不必要的溝通消耗。
鼓勵團隊內部“任務認領”,提高人員的工作積極性和主動性。
確定迭代運行模式
如一周迭代、兩周迭代,每個迭代包含的工作內容等。
具體的迭代計劃可參考《迭代計劃樣例》
制定其他輔助計劃
制定溝通計劃、風險計劃和質量計劃是必要的,溝通計劃主要包含以下幾個方面:溝通對象、溝通方式、溝通頻率即可,如:
風險計劃包括風險項、負責人、重要性、應對措施,如下:
質量計劃包括:bug分布滿足何種條件可以發布,有幾個致命bug必須停止開發新特性等。。
搭建基礎技術架構
如果是一個全新的項目,需要重新開發系統框架,則這個工作應該在迭代0完成,否則會影響后期的工作開展。系統框架的每次改動必然會導致大量的重復工作量,從而給穩定的團隊節奏帶來很大的毛刺。
4.3 項目執行和監控過程
迭代N的執行
A、迭代N的需求細化
考慮每個迭代需要完成的用戶故事;
用戶故事需包含幾個部分,工作量評估、功能性需求、非功能性需求。具體的可參考《用戶故事模板及樣例及拆分說明》
用戶故事編寫完成后需要在團隊內部進行需求評審,一方面是為了向團隊成員解讀該需求,另一方面團隊成員也可在評審時給出指導性意見。
B、測試用例評審
測試人員根據用戶故事要求編寫對應的測試用例,并組織項目團隊進行測試用例評審。根據評審意見修改測試用例
C、開發
將用戶故事的'需求開發的過程。
D、開發自測
在開發過程中,每完成一個功能點,都需要及時的進行開發自測并通知產品策劃人員進行驗收體驗。
E、驗收
開發完成后,產品策劃需要對開發完成的成果進行驗收,驗證其是否符合用戶故事的要求,驗證通過后方可流到測試環節,否則需與開發詳細討論其不符合性,其驗收的checklist可以參考《產品驗收checklist及模板》
F、測試和回歸
提交測試時,必須要有正確的版本。測試人員根據測試用例進行測試,在IT平臺中提交測試bug,并根據測試的角度給出產品是否發布的意見,輸出《測試報告》
G、bug修改
在IT平臺中獲取分配給自己的bug進行修改。
H、showCase
階段性必須有可體驗版本進行showCase.需要
確定showCase時間:某個迭代開發、自測完成,準備提交測試前
會議前1-2天發出體驗版給到參與人員
會議期間,由項目經理組織大家體驗、反饋問題、記錄問題。
項目經理根據問題情況,與開發或產品確定問題的解決時間并發出會議紀要。
I、灰度發布
迭代一定版本后,由項目經理與團隊共同決定是否需要進行灰度發布。
監控方式
每日站立會
主持人輪流擔任,負責控制節奏,記錄問題,以備會后跟蹤。
每人講自己昨天做了什么,有什么問題,今天的計劃是什么;
其他人了解別人的工作情況,并發現指出可能存在的問題。
對于發現的問題,鼓勵認領,其余由項目經理指定責任人。
時間通常控制在15分鐘內。
會議期間,更新任務墻,任務墻樣式如下:
周報
反饋項目計劃的執行情況,強調本周工作要達成的目標
暴露出項目的問題,特別是需要領導或其他團隊需要協助的問題。
周報可在IT平臺中輸出。
月報
反饋項目當月的執行情況,包括進度、人力及質量。
反映項目存在的問題和風險。
迭代回顧
每人講述本次迭代做的好的地方和不好的地方
回顧上個迭代不好的地方,看看改進情況。
讓每個人發言。
每次迭代回顧會議完成后,可更新燃盡圖
4.4 結項階段
項目經理指導產品策劃收集總結項目的產品運營數據,同時指導團隊成員從自身角色進行總結,包括測試、開發、UI等。
項目經理與項目團隊成員給出項目總結報告,內容可參考《項目經驗教訓總結-項目團隊》,《項目經驗教訓總結-項目經理》
召開結項會議,各成員進行結項匯報。
PM小組將過程文檔和經驗教訓總結進行歸檔。
jira是什么工具
是項目與事務跟蹤工具。
JIRA是Atlassian公司出品的項目與事務跟蹤工具,被廣泛應用于缺陷跟蹤、客戶服務、需求收集、流程審批、任務跟蹤、項目跟蹤和敏捷管理等工作領域。
JIRA中配置靈活、功能全面、部署簡單、擴展豐富,其超過150項特性得到了全球115個國家超過19,000家客戶的認可。
jira和ones哪個好?
Jira 和ONES我們團隊都使用過,那么究竟 Jira 和 ONES 哪個更好呢?我在研發團隊內部做了小調研,大家都覺得,整體來說 ONES 體驗感比 Jira 好,更加符合我們的期待。
先簡單介紹一下我們團隊的背景和需求:
公司做網文行業,團隊規模400+,研發團隊占據一半。由于該行業需要快速迭代出受眾喜歡的功能,我們主要采用敏捷的研發方式,比較看重項目管理軟件的穩定性、功能的全面性和費用性價比這幾個方面。
Jira 的功能的確很強大。但由于它是一家西方基因的公司,產品的設計對國人不是很友好,學習成本高。
我最開始上手 ONES 只用了一兩天,很好操作也很方便,覆蓋了需求、開發、測試、部署、交付整個研發流程的管理。
最重要的是,它支持一鍵導入Jira數據,用戶、用戶組、項目配置等都可以實現完整的遷移,這對我們團隊來說是很便利的。而且,我好像聽說 ONES 公司去年融資了1個億,整體發展勢頭還是很足的。
Jira和 ONES 的相同點還是很多的:
(1)它們都是項目管理工具且都適用于敏捷團隊
(2)都適用于項目進度追蹤、缺陷管理、缺陷追蹤等場景
(3)都支持SaaS、私有部署和高可用版本
他們的差異也不少,ONES 的優勢更加明顯,這也是我近半年(目測未來的多年內)使用 ONES 的原因。且來聽聽我的分析吧,我將從產品能力、擴展能力、穩定性、使用感和服務能力幾個方面評估。
這是 ONES 幾款產品能力的流程圖:
產品能力
Jira僅支持Scrum模型的基礎功能,如果需要其他擴展性功能(例如內容管理、流程強化,工時統計)要另購買插件,價格不菲;ONES 支持敏捷、瀑布、DevOps等多種模式,有強大的產品組裝能力,價格也便宜很多(這對于小公司來說太重要了)
2. 擴展能力
Jira支持郵件和釘的機器人提醒,默認可與用戶系統打通,且必須是LADP或者AD服務。ONES 提供 API 接口,支持從國內主流辦公系統進行賬號同步組織架構。
3. 穩定性
Jira的境外云服務難以保證數據的安全。ONES 是支持私有部署的,數據與外網隔離,更加安全可控。
4. 使用感
Jira的界面包括整體思維模式都不太符合國人,更加偏向西方,且不適用于新手。ONES 使用感好一點,更加了解大家的痛點及訴求,上手簡單。這也是我們團隊成員最開始用 ONES 時第一感受。
5. 服務能力
Jira無原廠服務,主要通過代理商為中國企業服務。ONES 提供完整的解決方案,24小時遠程都有客服,且售前售后提供的咨詢服務都是免費的。
總的來說,Jira 和 ONES 對比下來,ONES 更加出彩,產品矩陣也更加專業。主要的優勢在于:
(1)高度靈活,自定義程度高,可以適配很多場景
(2)更加了解國人的痛點,界面簡潔,使用感好
(3)ONES 成本真的很低!Jira的插件很貴,企業負擔較大
(4)服務不錯,24小時遠程解決客戶問題
【敏捷實用工具】JIRA介紹以及使用方法
正文共2254字,閱讀時間:6分鐘
敏捷開發并不是由敏捷工具來推動的。
但是沒有敏捷工具的支持,就很難進行各種軟件工程的相關事件,工具的作用是約束和流程,正確使用敏捷工具可以事半功倍,實踐敏捷。
近幾年來敏捷開發催生大量敏捷工具的產生,在敏捷工具上多了很多種選擇,每個團隊需求不一樣,就會使用到不同的敏捷工具。
不同的組織使用JIRA追蹤不同的問題。
JIRA的項目是根據你的企業組織需要定制的,是問題的集合。 例如, 一個JIRA項目可以是:
一個軟件研發項目
一項市場推廣活動
一個技術服務/幫助臺系統
一個需求管理系統
一個網站需求調查系統
一個項目模塊是這個項目中問題的邏輯分類集合。每個項目都可以根據你企業組織的要求設置多個模塊 (也可以不設置模塊)。
例如:一個軟件研發項目可以設置“文檔”,“郵件系統”、“用戶界面”等模塊。一個網頁設計項目可以設置“產品”“聯系我們”“專業服務等模塊。
對于一些項目類型來說, 特別是軟件研發項目, 為問題關聯產品的 版本 是非常有用的 (例如 1.0 beta, 1.0, 1.2, 2.0)。
一個問題可以設置兩種類型的版本信息:
影響版本 — 可以清晰地反映出這個問題在哪個版本中出現錯誤。
例如, 一個軟件的缺陷可能影響了產品的 1.1 和 1.2版。
修復版本 — 可以反映出報告的問題將在哪個版本,或已經在哪個版本中修復了。
例如, 軟件缺陷影響了產品的 1.1 和 1.2版,這個缺陷已經在2.0版中修復了。 注意沒有修復版本的問題會被歸類到“未規劃”,就像上面截圖顯示的一樣。
版本可以有3個狀態: 已發布,未發布或已歸檔。
版本可以設置發布日期,而JIRA會自動將到期而還沒有發布的版本高亮顯示出來,并標注上'超期'標志。
Jira是Atlassian公司出品的一款事務管理軟件。
無論是“需求”,還是“BUG”,或是“任務”,都是“事務”的一種,所以Jira可以勝任非常多的角色:需求管理、缺陷跟蹤、任務管理等。
因為Jira提供了專門的Scrum視圖和Kanban視圖,所以特別適合敏捷開發團隊使用。大型互聯網公司如LinkedIn、Facebook、eBay等內部都在使用Jira。
Jira在國內的銷售價格相當貴,而且沒有永久授權,只能年付,CSDN的報價最低18000元(25用戶)。推薦直接去官網購買,10人以下團隊的永久授權只要$10。這個價格,別說小團隊正式使用,就是個人玩票性質的買一個正版,也是完全可以了。
- 創建問題
1.點擊頁面頂部的“創建問題”鏈接;
2.會顯示“選擇項目和問題類型”彈出框,選擇相關項目和問題“創建”按鈕。
這里值得注意的是:
如果默認的項目或問題類型不會顯示這個彈出框,例如:只有一個項目,并且這個項目只有一個問題類型。
如果你在瀏覽項目時點擊 ‘創建問題’鏈接,而且瀏覽的項目只有一個問題類型。
如果你在瀏覽項目時點擊 '創建' 圖標, 例如:
3.“輸入問題詳細信息”頁面會顯示出來。輸入問題主題并完成所有標有帶星號的斜體字體的必填字段。
為問題上傳附件或者截圖
1.打開你需要上傳附件的JIRA問題。
2.在-更多操作-菜單中,選擇“上傳附件”或者“上傳截圖”。
(更多菜單)
(上傳附件)
(上傳截圖)
在不同的操作系統截取屏幕的方法也不同,比如:
在Windows中截取屏幕
截取新的屏幕 — 要截取屏幕并保存到剪貼板,使用下面任一種方法:
-按 ALT-PRINTSCREEN 鍵截取當前的窗口
-按 CTRL-ALT-PRINTSCREEN 截取整個桌面
已經存在的圖像 — 使用你熟悉的圖像瀏覽應用程序,并打開已存在的圖像文件然后復制圖像到剪貼板。
在Mac OSX中截圖屏幕
截取新的屏幕 — 要截取屏幕并保存到剪貼板,使用下面任一種方法:
-按 CTRL-APPLE-SHIFT-4 鍵截取當前的窗口
-按 CTRL-APPLE-SHIFT-3 截取整個桌面
已經存在的圖像 — 使用你熟悉的圖像瀏覽應用程序,并打開已存在的圖像文件然后復制圖像到剪貼板。
在為問題登記工作日志之前,你需要為問題設定初始預估時間 (即 預估完全解決這個問題所需要耗費的時間)。
當第一次為問題登記了工作日志, JIRA自動地以初始預估時間減去耗費時間 (實際工作時間) 計算出 剩余預估時間。 當再次登記新的工作日志后,JIRA再從 剩余預估時間 中減去 此次工作所 耗費的時間,作為解決這個問題的 剩余預估時間。
當然,在問題的解決周期內,你可以手動編輯 初始預估時間 或者 剩余預估時間:
定位并查看一個問題, 點擊頁面頂部的 '編輯' 按鈕。
或
在頁面右上角,點擊 '創建問題' 發起一個新的問題,并填寫所有必要的字段
編輯時間跟蹤字段:
初始預估時間 — 解決這個問題預估需要多少時間。 通常, 可以在創建問題或第一次登記工作日志之前設置這個時間值。
剩余預估時間 — 解決這個問題還需要多少時間。
在 初始預估時間 或 剩余預估時間 字段中輸入具體的時間。 使用 'w', 'd', 'h' 和 'm' 時間單位來表示周,日,小時或分鐘。例如, 要設置 '6小時' , 輸入 '6h'。
(消息) 如果這兩個字段都是必填項 (標注了紅色星號), 你可以只輸入其中一個字段值,而其他字段可以留空。當你提交這個表單, 你在其中一個字段中填寫的值,會被復制到留空的字段。
點擊頁面底部的 '更新' 按鈕。
END
閱
敏捷項目管理的基本定義是什么?
敏捷項目管理是規劃和指導項目流程的迭代方法。
與敏捷軟件開發一樣,敏捷項目是在叫做迭代的小型部門中完成的。每個迭代都由項目團隊審查和評判;從迭代的評判中獲得的信息用于決定項目的下一個步驟。每個項目迭代通常是安排在兩周內完成。
APM是這個領域的新概念。它的歷史能夠追溯到多年前。在2001年,敏捷軟件開發第一次通過由Mar tinFowler和Jim Highsmith推出的“敏捷宣言”形成規范。敏捷宣言是所有APM模型的指導原則。多數APM模型源于軟件開發,因此對軟件開發實踐的針對性很強。
原型和適應性項目框架是APM模型中僅有的適用于所有類型的項目的模型。由于開發周期短,對需求管理恰當,敏捷項目管理正在從軟件研發行業延伸到已經采取項目化管理的大部分行業中 。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。