best practice讨论/交流

gzrain.

其实有这个想法很久了，做IT的，局限与自己的公司/projects，很多时候都是在做相近的东西， 和外界industry流行趋势接触比较少。希望接这个机会交流一下， best practice，或者tips and tricks。我相信每个人的经验和做法都有值得学习的地方。
简单介绍下自己，半路转行的dev，现在在做RubyOnRails， Sydney
1. Development Cycle
直到我现在工作的公司，之前的公司，可以说完全没有release cycle， 想到那做到那，做到那deploy到那。印象最深的一间公司，号称 ”Customer Oriented“  ， 客户一个电话过来，我们这边就要drop everything and fix it (and deploy) right away. 最大的问题是project没有write test code。那时候我到公司不久，还在熟悉中，跟经理说了无数遍 I can make this fix now but I have no idea whether it will break other places in the system.  经理： customer are shouting at me in the telephone, just do it!
结果真是nightmare， we keep introducing more bugs while trying to fix them, without test code. 这个project可想而知， 很长一段时间都在痛苦挣扎中。
后来到了现在的公司，有了相对正规的开发流程，感觉流程对开发质量的确有很大帮助，at some point you have to say NO to customer, 你有新需求，你发现了bug，可以，我们会记录下来，会根据priority在下个release添加。下面简单介绍我们公司的release cycle。 先声明，这只是一家的做法，希望抛砖引玉，也希望听听其他公司是怎么操作的。
release cycle : every 3 weeks (15 working days)
pre-release cycle:  BA and Support team gather issue and bug reports and writing tickets
Day 1: Team Lead and business Team has planning meeting. discuss tickets details
Day 2 - 13: Devs take over, develop tickets base on the priority, for those tickets finished, marked as 'ready' and deploy to staging server so that business team and customer can test them.
Day 14 - 15 EVERYONE in the company do the finial testing and deploy.
So far the company has been using this cycle for over 3 years and it works.
我也很想听听别的公司都是怎么做的呢？

虞宅与美丽.

支持楼主。高个亮让更多人看到参与。

joerkky.

每个公司的资源，所在的环境，项目的特性，大家对开发认识的差异，都会导致practice的不同，没有silver bullet这么一说
比如说，web based startup可以做MVP（minimal viable product），政府项目就很难，所以practice可以有很多，是不是best就具体情况具体分析了
我先抛砖引玉，把我们的practice列一下
Release cycle: 没有release cycle, continuous delivery，每个check in都会自动trigger automation, 测试通过之后就可以merge到master，然后release。未完成的feature在production用feature toggle关闭。
Inception: stakeholder, PM, BA, Architect, Dev, QA开会（会程一天到一周），同意所要做的内容，写user story, 如果需要steering，会邀请steering committee参加
SDLC:
BDD style，每个user story开始的时候，BA，Dev，QA，product owner会碰头，一起写feature file, 然后Dev写代码，QA写automation，完成(code review, stakeholder review)之后大家再碰头确认feature complete
Product指导思想：MVP
Agile methodology: Kanban +Lean

gzrain.

joerkky 发表于 2014-5-23 08:52

每个公司的资源，所在的环境，项目的特性，大家对开发认识的差异，都会导致practice的不同，没有silver bul ...
感谢joerkky的分享，写得比我详细多了。
感觉你的流程很正规啊， 各种role的责任都很分工明确； 我在一间小公司，没有那么多资源，很多时候责任流程比较模糊，不过在过去1年Team lead花了很大的功夫慢慢完善流程和各种工具的运用。另外小公司有个特点，说得好听就是灵活，不好听就是容易受影响，客户和政策的变化可以直接影响开发priority，不过好处也是反应快，希望大家继续分享。

gzrain.

2. repository control
这个相对简单点，估计现在很多开发公司都在用了，基本就是GIT/Pull Request的模式， 流程：
1. developer create and work under correspondent working GIT branch of each ticket
2. developer commit changes and create Pull Request
3. team member review Pull Request,  give feedback or accept the request.
4. changes merged into master branch and remote working branch is deleted
公司因为政策的原因，不能使用github，而是使用自己server hosting的Gitlab，功能大同小异。
我听说有些consultant公司对commit message格式也有严格要求，Pull Request必须有2个以上team member review后才能accept。
在这套流程普及以前，有个叫git flow的git plugin，本质上和这个流程也是一样的.
这套流程我觉得最有用的就是引入了code review，group the commit by working branch bases. 另外我现在通常的习惯是在Pull Request前rebase一下最新的master，这样conflict会比较容易处理些， github/gitlab也能直接accept request。

mengqing.

LZ现在在哪家公司做rails?
我在公司的流程是
因为是one man team，所以直接master branch，除非做feature
要写testing老板说没空 然后直接deploy

rogerkong.

没在澳洲大公司做过，感觉这里的流程比较乱，职责界定模糊不清，不过可能只是我在的这家公司

无翅之徒.

要取决于项目的大小和性质 不是所有的项目都是适合AGILE的。
AGILE 很重要的一点是你要有 DEDICATED CUSTOMERS, 但是 REALITY是CUSTOMER 不给你添乱就不错了

无翅之徒.

rogerkong 发表于 2014-5-28 10:16

没在澳洲大公司做过，感觉这里的流程比较乱，职责界定模糊不清，不过可能只是我在的这家公司 ...
大公司有更多的 POLITICAL GAMES 影响流程 影响进度 基本上影响EVERYTHING 但是你永远也摆脱不了

muyir.

基本上去学习一下agile怎么做，或多或少的的把其中的一些practice用到自己项目中，就可以事半功倍
比如：
planning meeting
retrospective meeting
daily scrum
continue integration
...