[討論] 如何工作？開發不同系統間交換資料的程式

[scottshai (打字猴)]

最近在軟體開發上遇到一些狀況，
這狀況最後的結局是導致測試及撰寫文件的人要加班把東西弄好。
但細想整個流程，感覺我同事這加班是可以避免的，
所以想Po來詢問大家，如何用最少的時間，做到一樣的事情。

有三個系統 A、X、Y，
角色有 PM-A、PM-X、PG-A(我)、PG-X、輔導，
公司都稱測試及撰寫文件的人叫輔導 (雖然我查網路好像沒特別這樣說)

X 跟 Y 系統兩者之間的功能只有些微不一樣；
A 與 Y 之間資料交換的程式已經上機有好一陣子，
整個傳送的過程也都很順利；
今年8月底的時候客戶要求 A 跟 X 也要有一樣資料交換的程式，
同時因為 X 跟 Y 有些不一樣，來自 X 的資料在 A 前端顯示會有些微不同，
程式要求9月底交付；

PM-A 了解需求後告訴我怎麼做，
因為知道有時間壓力，所以把 A系統 這邊的程式在9月初完成後發測，
結果測試一直出現錯誤，大部分的原因是 X系統 要與 A 交換的程式有缺漏，
使得傳過來給 A系統 的資料不完全， A系統因此一直報錯。
來回幾次之後在今天 PM-X 跟我說 A 前端的顯示
跟當初 PM-A 說有些不一樣，以及今天要將文件完成先交給客戶，
今天下班前 輔導問我說這個要改好要多久，
我想了一下大概要一個小時，由於前端顯示並沒有差很多，
輔導決定用修圖的方式先把文件做出來，
想到我可以明天一早上班就先處理掉，就準時下班了。

過去我劃分職責的方式是照程式是寫在哪個系統上的，
但依照這分法，A 與 X 個系統間的資料交換，程式寫在 X 系統，
所以不是我負責的，
但那隻程式的 domain know-how 比較多是跟 A系統有關。
所以我應該要在開發過程中去主動了解那隻程式的狀況，
來避免我的同事加班嗎？

更進一步的來說，A、X、Y 三個系統都是同一家公司負責的，
所以有問題只要走到彼此辦公位置討論就好，很方便；
但 A 跟 其他公司的系統 I 也有資料交換，如果以後要增加資料交換的功能，
程式開發時間勢必會因為電話及郵件來往間耗掉很多時間。

不知道大家聽到上述狀況，有沒有甚麼想法呢？
是不是有更好的作法，能夠花更少的力氣，做到一樣、甚至更多的事？


--
→ nightfly1984:為追一個女孩認真讀書，最後考上交大，把春青的故事
→ nightfly1984:寫成小說，最後拍成電影，這還不夠熱血嗎?
→ nightfly1984:我不敢說九把刀現在有多成功，但他的確是一步一步在
→ Bonescythe:  賺錢
→ nightfly1984:實現他的熱血，以及他說出來的夢想..
→ Bonescythe:                                      定價250
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.217.118.161
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1506005985.A.7B6.html
※ 編輯: scottshai (49.217.118.161), 09/21/2017 23:03:12
推 Clain66: 不就PG-A跟PG-X在一開始就定義好資料溝通介面，兩邊各自
→ Clain66: 開發這樣嗎？寫程式的人也要負責寫文件給測試人員才對，
→ Clain66: 沒文件也要講清楚流程
推 alog: 我的直覺在於 你們開了一個根本自己做不到的時間
→ alog: 從一開始的時間就是錯的  也就是你們對於自己在做什麼事情
→ alog: 都不太清楚
→ alog: 然後給客戶一個根本做不完的時間
→ alog: 跟承諾
→ alog: 修改維護案每當增加一系列的項目更改或新增功能時
→ alog: 每一項下會動到哪些在準備執行前就會初估時間
→ alog: 等到時間估出來 才會擬新案合約開始執行
→ alog: 你們寫到會發現測試過不了或是有持續性問題 我的感覺就是你
→ alog: 們在評估階段時可能連測試都沒初步測試能不能整合或調整都
→ alog: 不知道就貿然開案
→ alog: 還有連緩衝時間都沒有
→ alog: 客戶越急 你們上面的人就必須要有能力跟對方談
→ alog: 這項悲劇我只能說 你們要自己檢討流程 而不是程式的問題而已
→ alog:  幫不了你們
推 ripple0129: 看來看去都是介面沒先溝通好產生的問題
→ doranako: 兩邊規格書打開一看就知道，沒寫表示一開始沒定好(pm問
→ doranako: 題)，交換資料格式一定要寫在規格書
推 chuegou: 結論是當初A-Y之間的傳遞說明文件亂寫對吧？
→ chuegou: 你照著說明實作 發現有問題對吧？
→ chuegou: 那就無解 若文件不保證正確 那這件案子就一定會撞進去
→ chuegou: 而且是撞進去才有辦法知道錯誤
→ enthos: 系統A,B,C,D,E都有它們自己的export/import成json格式的
推 maxqq: 輔導 xd 為啥不叫 QA or SQA
→ enthos: 界面,只認自己版號的格式.專用的系統Z負責轉換格式。
→ maxqq: 我想有兩個 .. 1. flow chart 2. swagger hub api test
→ maxqq: 你們要加強流程圖與測試工具，而非系統整合後，的完整測試
→ maxqq: 最後，再用 jenkin 的部署，進行上線單元測試即可
→ maxqq: 先把 flow 圖搞定，交給各方人馬資料交換的結構方式
→ maxqq: 再把測試工具/api交給對方，自行驗證
→ maxqq: 基本上除非沒想到的例外狀態，再加入到 flow / api 中即可
→ bobju: 要磨合 沒有絕對答案
推 shietsd: 這個例子應該是你們五個人為一個team的概念去做才對，依
→ shietsd: 照project 組隊就沒什麼問題
→ shietsd: 各自單獨的A，X系統的問題也要處理，所以A,X間的問題優
→ shietsd: 先權就是PM-A/PM-X來決定
推 zased: 沒有API的觀念就是這下場  很新手的問題......