流程改进上的3个想法

为什么80%的码农都做不了架构师？>>>   

下面是我对流程改进上的3个想法，请拍砖

1.改进刻录发布方式
当前产品发布给运营部时，使用的是scm刻录光盘给运营部的形式，发布前刻录耽误的时间较多，常有下班前才刻录发布的情况，时间紧迫，而且一但刻录机坏了，还得费力的找其他刻录机，影响发布。
scm希望运营部能从ftp上直接取，之所以需要刻录光盘，从运营部的角度来说，光盘中的东西是只读的，不可能有变化，如果从ftp上去取，难保程序不被人为改变，出问题后难以认定责任。
如何能让运营部确保从ftp上取到后，ftp上的东西绝对不会变化？由此引入md5校验方法，md5校验可以用来检验文件是否被修改过，广泛的应用在软件产品的发布中。
当我们从网上下载一个软件时，怎么才能知道下载来的软件是否就是软件提供商提供的那个呢，用md5校验就可以验证。
MD5的全称是Message-Digest Algorithm 5，Message-Digest泛指字节串(Message)的Hash变换，就是把一个任意长度的字节串变换成一定长的大整数。请注意我使用了“字节串”而不是“字符串”这个词，是因为这种变换只与字节的值有关，与字符集或编码方式无关。
MD5将任意长度的“字节串”变换成一个128bit的大整数，并且它是一个不可逆的字符串变换算法，换句话说就是，即使你看到源程序和算法描述，也无法将一个MD5的值变换回原始的字符串，从数学原理上说，是因为原始的字符串有无穷多个，这有点象不存在反函数的数学函数。
MD5的典型应用是对一段Message(字节串)产生fingerprint(指纹)，以防止被“篡改”。
举个例子，你将一段话写在一个叫readme.txt文件中，并对这个readme.txt产生一个MD5的值并记录在案，然后你可以传播这个文件给别人，别人如果修改了文件中的任何内容，你对这个文件重新计算MD5时就会发现。
联系到我们的产品发布情况，在发布前，scm对ftp上的文件计算出一个md5值，把这个值记录到产品发布表中，运营部根据产品发布表从ftp上获取文件后，重新计算出一个md5值，如果这2个值一样，说明ftp上的文件没有变化。这种校验任何时候都可以重复做。
这就好比光盘的作用，而且免了刻盘的工作程序，可以随时发布，scm签字即代表发布。
不需人工来取光盘，实现电子化发布。
计算一个文件的md5值的方法也很简单，用到一个md5计算工具即可。

2.改进基线发布流程
当前基线发布流程是PM做好“工作成果签字确认表”并打印出来，开完评审会后即在纸件上会签，经QA确认后给scm入基线并发布，scm发布基线后将“工作成果签字确认表”返回给QA留存。

  问题是QA审核时如果有问题，一般是PM直接在纸件上修改，不严谨，重新打印又浪费纸；没有电子版，不便于传递；scm发布后没有副本留存，不严谨；“工作成果签字确认表”没有QA、scm的签名，不严谨。
建议改为，开完评审会后不再立刻会签，PM修改好“工作成果签字确认表”，发mail给QA确认，QA确认后转发给scm入基线，scm入完基线后全部答复mail，QA收到mail后打印“工作成果签字确认表”找相关人会签后留存。
以前是评审会通过后即会签，会签的并不是最终版，这样都可以，那么改为评审会后修改件只需QA简单确认也是可以的，这样确认mail只需在PM、QA、scm之间流转即可，不需发mail给所有评审人确认。
经过mail确认后打印的表是和mail完全一致，不会有关键性修改，mail内容是可靠的。
mail是QA确认的，scm根据mail入基线是可靠的，还有留存，便于事后核查。
最后的纸件会签的过程也就是基线发布的过程，scm不用再发布基线。
mail流转确认，实现电子化流转，手工签字确认只是起存档的作用。
实现电子办公，特别是便于PM、QA、scm三者异地办公时。

3.改进产品发布流程
和基线发布一样，产品发布经发布会后，由PM发mail给QA确认，QA确认后转发给scm，scm这时需要填写发布文件的md5值，最后由pm打印出来会签给运营部留存。
scm需要在发布表单上填写一长串md5值，是纸件手写时难以解决的。
mail流转确认，scm也不用刻盘，实现电子化流转。

  要求所有需要发布的文件都放在ftp上，才便于计算md5值，便于运营部获取，这也是建设产品库的需要和作用。

转载于:https://my.oschina.net/tadcat/blog/149210