ASPIRE

Jira入门

=Start=

缘由：

之前不论是做安全还是做开发其实都是一种单打独斗的情况（国内大部分安全团队其实应该都差不多——因为人数少，没有明确分工，且开发项目比较简单），但随着现在面对的开发项目越来越大、越来越复杂，逐渐认识到专业、规范的重要性（之前没出问题真的属于运气好），所以也在不断学习专业的工具、理解开发测试规范、阅读项目管理书籍，以期不断提升专业能力水平。

这里要介绍的就是最近用的比较多的项目管理工具——Jira。

正文：

参考解答：

Jira是什么？

Jira是澳大利亚Atlassian公司出品的一款Issue跟踪及项目管理软件，是Scrum敏捷开发的杰出代表。

Jira中的一些概念

BackLog

功能范围，需求池。Backlog 主要是用于需求的收集和优先级排序。

Sprint

不是版本的概念。一定周期内的冲刺，一般2-3周工作日时间。如果团队刚刚使用Scrum，建议以三周为一个Sprint：两周开发，第三周用来修复bug和回归测试、做演示、回顾会议、上线、讨论下个迭代需求、确定backlog等。

Story

故事卡，独立的功能点 【可以理解为一个已立项的小项目】.实际开发周期内，由产品负责建立Story。对于开发人员来说，Story是不进行执行周转的。

Task

任务，来源于故事卡的拆分。包括并不局限于对应的开发时间和，发调整，与产品的沟通历史，关键的变更计划等。由实际开发人员创建，每个任务必须最优是关联一个故事卡。测试人员建立BUG时，需要关联到对应的Story和Task。
任务是需要跟踪执行的，有几个主要的状态需要流转，主要是基于新建，开发中，测试，已解决和已关闭。作为量化工作量的最小单位，任务执行者负责登记开发工时，用于 SM（项目管理者）集中统计工时，评估团队领取故事卡的能力。
任务的状态流转可以在项目面板中，以拖拽的方式进行。

使用Jira的好处？

Jira是一个很好的项目管理辅助工具，将所有项目开发、运作过程中的所有Task、Bug、创意、改善意见都可以融汇进入这个系统。可以在第一时间将这些问题指派而责任人进行处理。

Jira的实际使用

# 普通用户
# 管理员
# 自动化开发

瀑布流模型

瀑布流模型将软件开发和交付划分为几个相互独立的阶段：

  1. 需求收集
  2. 设计
  3. 编码
  4. 测试

其中每一步都需要等前一步完成之后才能进行，必须从上向下，也因此得名“瀑布”。

敏捷开发

2001年，十几位很厉害的开发者们聚在一起，经过一翻交流之后，发起了敏捷运动，还撰写了一份宣言——《敏捷宣言》。现在这份敏捷宣言还托管在GitHub Pages上，有兴趣的可以去 http://agilemanifesto.org 看一看。

敏捷宣言的主要内容，翻译一下是：

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，但我们更重视左项的价值。

敏捷开发也存在需求、设计、编码、测试4种职能，不过敏捷开发并不是小型瀑布流，4种职能之间是紧密结合、彼此交融、相互依赖的，不存在瀑布流的“职能筒仓”问题。文档、开发、测试往往是同步进行的。基于敏捷开发的理念，衍生出来精益开发、极限编程、测试驱动开发（TDD）等等具体方法，而Jira所支持的Scrum就是其中的方法之一。

参考链接：

=END=

Docker

, ,
, , , ,

《 “Jira入门” 》 有 10 条评论

  3. 如果不重视管理会给软件开发带来哪些恶果？
    https://mp.weixin.qq.com/s/Nuf-gQbuSDnyoNHikCH4lg
    `
    有效的软件管理，对于软件开发来说，就如大海航行中的舵手，可以使软件开发的小舟始终保持在正确的航道上，最终驶向胜利的彼岸。相反，如果缺乏有效的管理，会给软件开发带来很多恶果。

    如期交付是妄想
    低能重复为日常
    交付方知已偏离
    合同纠纷太心烦
    状态混乱谁知晓
    棋错一招悔已晚
    质量出事由天定
    意外来临干瞪眼

    缺乏有效的管理，给软件开发带来的后果，远不止上面所述的几种。如果不重视管理，软件的开发过程就是一片混沌，出现什么样的问题都不奇怪。
    `

    回复

  5. 一张图让你看懂敏捷Scrum
    https://mp.weixin.qq.com/s/7TJOjlBA-RHM4nUEGvZ7SA
    `
    敏捷，简单的释义，即灵敏、快捷。

    「合理的任务规划」能让团队的工作即饱和而又能够有良好的应变能力（灵敏），团队需要时刻保持着良好的应变能力，因为我所了解的开发团队一直都面对着一个不确定因素——需求变化快。

    「专注」能够有效提升效率（快捷），当人在多件事情之间来回切换的时候，效率就会显得低下而且心情还很容易变得糟糕。

    接下来将带给你如何使用敏捷的工具之一 Scrum 帮助你完成「合理的任务规划」和如何「专注」。

    Scrum 工具包括：3个角色、3个工件、5个活动和5个价值观。
    01 Product Owner：
    02 Scrum Master：
    03 Team：

    01 Product Backlog：
    02 Sprint Backlog：
    03 Burndown chart：

    01 Sprint：
    02 Sprint planning meeting:
    03 Daily standup meeting:
    04 Sprint review：
    05 Retrospective meeting：

    01 专注：只专注于每个 Sprint 要完成的事情，团队和个人的能力和精力都是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果。
    02 勇气：团队完成任务的过程中肯定都会遇到一些棘手问题的情况，要有勇气去挑战和面对。
    03 公开：Sprint 的进展，遇到的问题，阻碍都应该对所有人可视化，透明的。这样的团队才能彼此了解，彼此尊重，同时也能暴露问题。
    04 承诺：团队在 Sprint 开始的时候做出承诺，并在迭代中全力完成，达成功能交付。
    05 尊重：尊重各个团队以及团队的人员。不要越界（超出了自己的范畴）议论，「产品觉得这么简单的功能还要那么久才能完成」、「开发觉得 UI 怎么设计得这么 Low」、「UI 觉得这么简单的效果你们都做不出来」等，我们要相信他人能够在这个岗位上就有胜任的能力，要相信他的专业能力。

    Scrum 只是一套工具，实施主要还是看人。其中的流程并非一定完全硬套，工具是死的，实施的人是活的，当然是可以根据公司的情况对某些流程进行调整、替换、甚至删除，总结一套适合团队的流程最要紧。最重要的是定下一套流程规则，然后遵守这套规则，循环往复的发现问题和解决问题，完善流程。
    `

    回复

  6. 需求确认的方法和内容，了解一下
    https://mp.weixin.qq.com/s/zcxz5sVsBwYLpnLeC_pxRA
    `
    在GJB5000A标准当中，给出了需求确认的方法：分析、仿真、演示。

    1、分析
    通过对需求规格说明的分析来确认软件需求的方式，通常就是审查或评审。虽然全凭想像，但是有客户和开发人员一起分析，应该可以实现确认的目的。

    2、仿真
    通过使用一种低保真的模型模拟软件的方式来确认需求。由于有了可感知的东西，需求的确认更加可信。

    3、演示
    当具备了初步的软件原型的时候，就可以通过软件原型的演示对需求进行确认。这这种需求确认的方式可信度最高，因为他和将来软件的使用场景非常接近。
    ====
    正确性
    一致性
    完整性
    可行性
    必要性
    可测试性

    总结一下，需求确认就是通过分析、仿真或演示的技术手段，对需求规格说明中描述的需求的正确性、一致性、完整性、可行性、必要性、可测试性进行确认。
    `

    回复

  8. 浅谈项目管理
    https://mp.weixin.qq.com/s/IUjB3izRt38m5idTUsLIdQ
    `
    做技术PM其实是一件出力不讨好的事情，很多时候是责任和委屈撑起来的。
    关于项目我的理解是，在既定的资源和要求的约束条件下，为实现某种目的而相互联系的一次性工作。项目成功的三要素是必胜的信念、正确的信息同步和可靠的人力。经验总结主要如下：

    ● 技术绝对不是炫技，而是贴着业务走，结果为导向的。技术好不好，一定要你的技术的同学使用了，对大家真正有帮助，是大家都能够用技术分析、排查问题且推行到整个应用部才是好技术。
    ● 明确需求很重要。开发以及测试需要对产品功能有一个全面的了解和时间上的风险评估，并且要和产品多讨论，大家一起进步。
    ● 如果有大小项目并行，要排优先级，根据时间四象限，追求短平快、快速迭代。
    ● 项目启动会很重要，一定要拉上相关leader和老板。项目启动会的参加方包括发起人、项目成员、各个依赖方、相关leader和老板，因为在推进项目的过程中我就遇到过老板没拉结果开发就比较“佛系”的情况。
    ● 每天跟进项目，协调冲突。在项目的过程中，由于我的失职，对于一个项目没有按照天跟进项目，结果项目过去四天以后代码分支还没有拉，最后是换人开发解决了问题。项目进行过程中难免出现冲突，依赖于被依赖双方的时间可能存在不吻合情况，或者由于某些事情的插入导致原先时间点出现偏差，这种情况需要项目负责人及时发现问题、协调解决，或者调整排期，或者申请人力，或者调整功能，再或者加个班内部消化。实在有高优项目插入，对本项目造成影响，那就按照正常的需求变更和项目延期流程来合理delay。
    ● 目标同步很重要，也需要既能仰望星空，又能脚踏实地的人。
    ● 首次犯错，给予指导，再次犯错，再批评。作为技术管理者，理应把自己的技术经验传导给员工，而不是变得非常浮躁。
    ● 责任心是需要鼓励的，否则再强的责任心也会被慢慢磨光 。为他人安排任务的时候，会更清晰的规划出每个人的目标且清晰的交代清楚，并且在他实施过程中，多关心多询问，而不是多指责；应该作为一位领路人，别总把大家当机器。
    ● PM的价值，是激发团队热情，促进团队的互信互赖。
    ● 将技术攻关交给感兴趣且有潜力的同学去做，自己做好把关。
    ● 不要为了加班而故意放缓进度而加班，加班应该是有效率的比如可以做下周的事情。快乐、高效是目的，而不是比谁干的活多，谁的工时长。
    ● 明确团队目标非常重要，团队驱动靠的是目标。
    ● 做好项目组组员的教练，为他的结果负责，并且不在公众场合责怪组员。
    `

    回复

  10. Atlassian Confluence
    “`
    — and `uri` like ‘%search%’
    — and `uri` not like ‘%.svg’
    — and `uri` not like ‘%.png’
    — and `uri` not like ‘%.js’

    since 5.2. Instead please use the REST endpoint that is provided by the ‘Confluence QuickNav’ Bundled Plugin. Please use /rest/quicknav/1/search instead. It accepts the exact same arguments and is thus API compatible with this class. You should be able to swap them out directly.

    /rest/quicknav/1/search
    /rest/api/search
    “`

    Atlassian Confluence Quick search
    https://www.alfredforum.com/topic/10234-atlassian-confluence-quick-search/

    Confluence REST API Documentation
    https://docs.atlassian.com/atlassian-confluence/REST/6.6.0/#search-search

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注