AngryTask - 基于伪 scrum 的我的项目开发产品

关于

去年年底的时候同事分享了一下 scrum 工做模型, 之后公司按照这种方式来执行产品开发.
联想本身在阿里的两年的工做方式和大学课程讲述的项目协同敏捷开发的一些知识.
因此本文想就开发工做流模型作一个简单的探讨, 并将 scrum 模型应用到 我的项目开发中的作一个尝试性产品 AngryTask 的讨论.

谁优谁劣是伪命题，解决问题才是王道

当在进行这种讨论的时候, 总会陷入讨论孰优孰劣的结局, 大学里边的课程给人的结论就是敏捷开发碾压瀑布流, 但到实际工做的时候发现其实忽略了上下文条件.

什么样的公司

1. 技术外包公司

2. 传统IT企业

3. 互联网公司

4. 创业公司

5. 我的开发者

不一样公司对产品开发模式和对产品的需求相差很大, 所谓有人的地方就有江湖, 真实环境的开发实质是围绕不一样的利益在讨论.

• 技术外包的公司目的是知足客户需求, 因此对客户必须以瀑布的方式, 需求就是合同

• 传统 IT 企业, 老板才是开发的客户, 不错出能知足需求的产品才是核心价值

• 对互联网公司和创业公司来讲要求的就是快速迭代

• 我的开发者须要钱, 须要实现理想, 须要完成一些工具也差别很大

什么样的团队

1. 技术人员占比大团队

2. 产品人员占比大团队

3. 我的开发

不一样人员结构的团队致使不一样的协做方式, 有可能老板主导, 产品主导, 设计主导, 开发主导. 工做协做方式也会由于主导的人发生变化.

什么样的产品

1. 视觉为主

2. 销售为主

3. 后台程序

4. 2B 产品

5. 2C 产品

开发核心价值是

1. 时间为主

2. 质量为主

3. 须要用户参与反馈的迭代开发

没有哪一种开发模型可以知足这些条件, 因此不谈场景只谈模式都是扯淡, 在真实开发环境中生产高质量高效率的产品必须找到适合本身的 pattern .

scrum 工做模型

scrum wiki

严格上的 scrum 是比较严肃的, 设计人限定了不少规则, 如:

1. product backlog 的每一个需求都是一个基于用户场景的用例或者用户故事

2. 角色设定, 强调自我组织, 分为 "猪"组(产品负责人, scrum 主管, 5-9名全栈开发人员), "鸡"组(用户, 利益相关者, 经理)

3. 每日站立会议

对于团队来讲, 大可能是应用伪 scrum 到团队中, 没有严格的遵循标准 scrum 的规则.

说说做为我的开发者的问题

几乎每一个 coder 的某个文件夹里边都放着一些本身的我的项目, 可是大多数项目烂尾而终止, 缘由不少如:

1. 有新的更棒的 idea , 兴趣转移

2. 工做上加班变多, 无力分心来开发我的项目

3. 情绪左右着项目的投入时间, 每月总有那么几天

4. 被某一个问题卡死, 陷入细节, 太复制
   ....

能成功的完成的项目而且推向终端用户的产品是极少数的, 这些我的开发者要么是极度有经验, 要么是颇有毅力, 要么是小团队做战.

因此可否也将我的项目像团队项目同样标准化, 经过某种工做模式让我的项目可以持续的投入并最终产出推向市场?

不要太聪明, 像猪同样笨的执行

我的项目没能完成每每不是由于开发者技术能力作不到, 不够聪明, 也不是由于项目 idea 不够好, 最主要的缘由是由于开发者太"聪明", 对于公司的项目咱们可以即使不加班的状况, 即使讨厌的状况, 也可以顺利完成, 由于有人要求咱们去执行并完成上线. 因此总的来讲就是我的约束没作到位

下面这张图是我根据 PPT 里边 scrum 的介绍画的

若是我的开发者也以这种工做方式来开展的话, 是否是就能解决问题了呢?

AngryTask - 为我的项目开发而生的任务管理工具

这也是我为何要作如今的这个项目, 并用它来约束自身开发, 我取了一个不太好听的名字 叫 AngryTask

先上个正面图

固然如今正在开发中, 尚未正式推出来, 先把话放在这里, 我会用上面的工做方式应用到这个产品的开发中, 并将这种开发模式整合到产品中 .....

转载自个人博客： http://6174.github.io/articles/scrum.html