(這是 Three Years of Scrum at Socialtext 這篇文章的中譯，接續上集的內容。)
彼此支援的互助方式，意味著開發人員不需要等開會，就能即時解決自己工作中的阻礙。
這樣一來，當我們每次在 Standup 集會上要列出自己遇到的阻礙時，實際上… 根本沒有任何阻礙。
此外，儘早消除阻礙還有另一個好處：我們通常都能完成每天的工作承諾。因此，“我昨天做了什麼”以及“上次 Standup 上我說過要做的事情”的實際內容是相同的，因此第二個狀態的更新也顯得多餘。
最後的結果是：原本每天要討論的三件事，最終被減少到一件。
突然之間，我們的開會時間大幅縮短，通常只需要 8-12 分鐘，有時候甚至更快。
為了加速集會進行，我們會在各自的微博上提前記錄內容，再由系統自動集中到共筆頁面上。在 Standup 集會裡，我們會直接將頁面進行畫面共享。當大家都習慣這樣的工作方式後，大部份人的狀態彙報通常只有一句：“就是各位看到的這樣”，或“沒什麼新內容，搞定”。
精通 Scrum 的專家看到這裡，可能會認為我們不太對勁：整個團隊似乎根本沒有溝通。但我認為實際情況正好相反：團隊的溝通非常順暢，只不過溝通都是在 Standup 之外進行的。我們每天的工作都列在看板系統上：這塊看板實際上就是一個自動產生的共筆頁面，其中列出我們目前流程中需要執行的每項工作，例如這樣：
（Socialtext 的看板內容節錄。此處的 WIP 是指“開發中的工作”。同一頁裡還包括“準備中”、“品管中”，以及“等待核可”等未顯示的部份。）
通過看板了解狀態，並隨時消除阻礙，這些做法使得 Standup 程序變得沒那麼重要。它像是解決早期問題的古老機制，已經不再適用於團隊的現況。
事實上，情況正是如此。當年 Schwaber 和 Sutherland 兩人在 EasleCorp 公司創建 Scrum 方法時，他們需要解決的具體問題是這樣的：各項需求之間彼此衝突和影響的程度如此之高，以至於技術人員根本無法開展工作 — 他們甚至無法發佈任何一項產品。
因此，您可以將 Scrum 模型裡的“衝刺周期”理解為改變過程中的喘息時間，或者直接想成是“請給我們一個月時間做出實際工作，然後再來修改計劃。”
最近一年多來，這樣的問題已經再也沒有在 Socialtext 出現過。於是我們繼續改善工作流程。
從 2007 年起，我們嚴格執行為期兩周的“衝刺周期”。這個模式運作了兩年多，直到 2010 年初為止。在這段時間裡，我們共進行了 52 次為期兩周的“衝刺”，其中 48 次準時發佈為新版的產品。（如果您想知道細節的話，有兩次失敗的衝刺是因為聖誕節和新年的延誤，一次是由於品質問題導致延期發佈，還有兩次是因為功能未臻完善，不適合發佈。）
這兩年間，我們也遇到了各種挑戰 — 有五六次升級造成運作上的瑕疵，需要開發人員提供支持。但產品的整體素質依然很高，同時幾乎沒有顧客抱怨功能上的問題。
在將我們的工作拆分為小塊的過程中，我們自己的技能也得以提高，同時對於功能可以正式完成的時間估計也更加精確。結果我們發現，如果將工作拆分為幾乎相同規模的小塊，通常根本不需要估算工作量，就能測量出預計的完成時間。
一旦所有工作項目都高度一致，團隊的流程就可以從“只要以高品質成功完成，我們可以每兩周發佈一次”，變成“只要這塊工作完成，我們就可以發佈” — 與此同時，管理層對於專案準時完工依然可以保持充足的信心。
如此一來，我們逐漸從傳統的 Scrum 模型轉變成“塊狀工作”法，也可以稱做“看板法”。
在這段時間裡，我們也對每天舉行的 Scrum 集會進行改進，首先在周三添加了“工程話題”環節，之後則將集會改為每天進行，但並不要求必須全員參加。（“工程話題”包括傳統員工會議裡常見的活動：宣布人員招募訊息、公司策略討論、層出不窮的員工意見建議、測試人員發現的潛在問題等。）
幸虧有了看板，會議的焦點不再是“我目前正在做什麼”，因為大家都可以一目了然地看到每個人正在做什麼。現在我們討論的是接下來需要做什麼，何時以及如何調整優先順序，以滿足每天的需求。如此一來，我們不再需要討論如何完成目標和任務，以及我們被什麼卡住，而是轉為討論團隊正在面臨哪些挑戰，以及我們可以採取的措施。
雖然沒有任何一種流程是完美的，但我必須說，我喜歡這種方式的發展方向。
請不要誤會本文的意圖。我並不是說傳統的每日 Scrum 方法不好，我也並不是要推廣說我們的方法更好。準確來說，我只是想提供某種類型的最佳實踐紀錄。
筆者認為，要形成良好的流程，需要不斷地反省、調整，再做出改變。成長過程中可能會承受痛苦，但決不要放棄追求改善：沒有最好，只有更好。您肯定也明白這一點。
變得“更好”，並不意味著原來的方法就是錯誤的。 Scrum 方法並非一成不變，而是一種不斷持續改進的流程。就像煮一碗湯，您可以品嘗它、改進它，讓它每次的味道都變得更好。
一旦走上這條道路，您就不僅是在開發軟體，更是在創造文化。
創造文化的過程或許艱難，也許會充滿挑戰與辛酸。
不過，最終還是值得的。
我們接下來研究的一個例子，是在共享的試算表裡進行多人即時協同編輯。
這乍看之下也許有點複雜，但是感謝 SocialCalc 的模組化設計，我們只需讓每位使用者將自己的指令傳播給其他參與者執行即可。
為了對本地指令與遠端指令作出區分，我們為 ScheduleSheetCommands 方法增加了 isRemote 參數：
SocialCalc.ScheduleSheetCommands =
function(sheet, cmdstr, saveundo, isRemote) {
if (SocialCalc.Callbacks.broadcast && !isRemote) {
SocialCalc.Callbacks.broadcast('execute', {
cmdstr: cmdstr,
saveundo: saveundo
});
}
// ...original ScheduleSheetCommands code here...
};
現在只需定義一個合適的 SocialCalc.Callbacks.broadcast 回喚函數，即可讓所有連入此試算表的客戶端執行相同的指令。
當 SEETA Sugar Labs 於 2009 年在 OLPC 上首次實作這項功能時，broadcast 函式是用 XPCOM 框架寫成，並在 OLPC/Sugar 的標準傳輸層 D-Bus/Telepathy 網路上運行：
這樣的運行方式，讓 Sugar 網路裡的 XO 電腦能對共同的 SocialCalc 試算表進行協作，但也只能在 Mozilla/XPCOM 瀏覽器平台與 D-Bus/Telepathy 訊息平台上適用。
為了達成跨瀏覽器、跨作業系統的目標，我們使用 Web::Hippie 框架，作為 JSON 在 WebSocket 上傳輸的抽象層。它提供方便的 jQuery 綁定，並且當 WebSocket 不適用時，也能利用 MXHR (multipart XMLHttpRequest) 作為備用傳輸機制.
對於安裝了 Adobe Flash 插件但沒有原生 WebSocket 支持的瀏覽器，我們使用 web_socket.js 專案的 Flash WebSocket 模擬器，這通常比 MXHR 更快也更可靠。
運作流程看上去是這樣的:
客戶端的 SocialCalc.Callbacks.broadcast 函式定義如下:
var hpipe = new Hippie.Pipe();
SocialCalc.Callbacks.broadcast = function(type, data) {
hpipe.send({ type: type, data: data });
};
$(hpipe).bind("message.execute", function (e, d) {
var ss = SocialCalc.CurrentSpreadsheetControlObject;
ss.context.sheetobj.ScheduleSheetCommands(
d.data.cmdstr,
d.data.saveundo,
true // isRemote = true
);
break;
});
儘管這已經能順利運行，我們仍然有兩個問題需要解決。
第一個就是為了執行指令而產生的爭用狀態：如果使用者 A 與 B 同時執行某個影響相同儲存格的操作，之後才接收到與對方傳播出來的指令，那麼雙方將會停在不同的狀態：
我們可以通過 SocialCalc 內置的還原/重作機制來解決這個問題，如下圖所示：
盡管爭用狀態已經得到解決，但「偶爾會覆蓋掉其他使用者正在編輯的儲存格」這樣的不理想情形還是存在。我們可以更進一步，將每位使用者的游標位置傳播給其他使用者，讓每個人都能看到有哪些儲存格正在編輯。
為了實做這一想法，我們為 MoveECellCallback 事件添加了另一個 broadcast 處理程序:
editor.MoveECellCallback.broadcast = function(e) {
hpipe.send({
type: 'ecell',
data: e.ecell.coord
});
};
$(hpipe).bind("message.ecell", function (e, d) {
var cr = SocialCalc.coordToCr(d.data);
var cell = SocialCalc.GetEditorCellElement(
editor, cr.row, cr.col
);
// ...decorate cell with styles specific
// to the remote user(s) on it...
});
在試算表中標記儲存格焦點時，通常會使用帶有顏色的邊框。但是，該儲存格也許已經有自己的 border 屬性了。而由於 border 為單一顏色，因此在相同的儲存格只能表現一個游標。
因此，在支援 CSS3 的瀏覽器上，我們使用 box-shadow 功能來表現多個游標:
/* Two cursors on the same cell */
box-shadow: inset 0 0 0 4px red, inset 0 0 0 2px green;
如此一來，當四人編輯同一個試算表時，螢幕看起來會像這樣:
(未完，待續。)
我們對 SocialCalc 所做的第一項改進，是讓文字儲存格能夠使用共筆語法，以及直接在表格編輯器中實現的豐富文本繪製：
在 1.0 版發布之後不久，為了回應用戶希望通過統一語法插入圖片、鏈接，以及文字標記的需求，我們幫 SocialCalc 加上了這項功能。由於 Socialtext 提供自己的開源共筆平台，因此自然會希望能在試算表中直接使用相同的語法。
為了實現此功能，我們需要將預設的文字儲存格格式（即 textvalueformat 屬性）設為 text-wiki，並為它提供自定的繪製器。
至於 textvalueformat 屬性是什麼呢？請見下文。
在 SocialCalc 中，每個儲存格都有一個 datatype 及一個 valuetype 屬性。包含文字/數字資料的儲存格分別對應到文字/數字值類型，而具備 datatype="f" 的公式儲存格則可能會生成數字或文字值。
在前一節介紹的繪製步驟中，Sheet 物件會為每個儲存格生成 HTML。為此，它會檢查每個儲存格的 valuetype：如果以 t 開頭，則該儲存格的textvalueformat 屬性會決定如何進行生成。如果以 n 開頭，則使用 nontextvalueformat 屬性進行判斷。
如果該儲存格的 textvalueformat 或 nontextvalueformat 屬性沒有定義，則會通過其 valuetype 屬性查詢預設格式，如下圖所示：
對 text-wiki 值格式的支援，寫在 SocialCalc.format_text_for_display 中：
if (SocialCalc.Callbacks.expand_wiki
&& /^text-wiki/.test(valueformat)
) {
// do general wiki markup
displayvalue = SocialCalc.Callbacks.expand_wiki(
displayvalue, sheetobj, linkstyle, valueformat
);
}
此處我們並非將「共筆文字轉 HTML」的轉換器嵌入到 format_text_for_display 裡，而是在 SocialCalc.Callbacks 裡定義一個新的掛鉤。這是 SocialCalc 代碼裡推薦的方法：這種模組化的設計，讓應用程式可以支援各種不同共筆文字的語法。如果應用程式用不到 text-wiki 格式，也可以直接忽略 expand_wiki 掛鉤。
隨後，我們使用了 Wikiwyg，這是一個 JavaScript 程式庫，可在共筆文字和 HTML 之間提供雙向轉換。
我們定義下列 expand_wiki 函式，將儲存格的值透過 Wikiwyg 的 Wikitext 解析器和 HTML 產生器轉換成 HTML：
var parser = new Document.Parser.Wikitext();
var emitter = new Document.Emitter.HTML();
SocialCalc.Callbacks.expand_wiki = function(val) {
// Convert val from Wikitext to HTML
return parser.parse(val, emitter);
}
最後一個步驟則需要在試算表初始化完畢後，將 set sheet defaulttextvalueformat text-wiki 加入命令佇列：
// Assume there's a <div id="tableeditor"/> in DOM
var spreadsheet = new SocialCalc.SpreadsheetControl();
spreadsheet.InitializeSpreadsheetControl(
"tableeditor", 0, 0, 0
);
spreadsheet.ExecuteCommand(
'set sheet defaulttextvalueformat text-wiki'
);
將上述部份搭配起來後，繪製步驟的工作流程將類似這樣：
大功告成！改進後的 SocialCalc 能夠支持豐富的共筆標記語法：
*bold* _italic_ `monospace` {{unformatted}}
> indented text
* unordered list
# ordered list
"Hyperlink with label"<http://softwaregarden.com/>
{image: http://www.socialtext.com/images/logo.png}
請嘗試在 A1 中輸入 *bold* _italic_ `monospace`，隨後即可看到繪製後的豐富文本內容：
(未完，待續。)
這是 SocialCalc 在運行過程中的畫面：
底下則是它的類型圖：
相較於 WikiCalc，伺服器的角色已大幅減輕。現在伺服器只需要負責回應 HTTP GET 請求，提供整份表格內容的序列化字串即可。瀏覽器在收到資料後，所有計算、變動追蹤，以及使用者的互動都是通過 JavaScript 達成的。
JavaScript 元件在設計上使用了層次式 MVC（模型/視圖/控制器）樣式，每個類型都只專注於某部分的功能：
模型中包含從座標指向 Cell 物件的字典，每個物件代表一個儲存格。空儲存格所在的座標不需要有對映的物件，因此完全不占用記憶體。
下面列出的是一些常見的 Cell 物件屬性：
datatype t
datavalue 1Q84
color black
bgcolor white
font italic bold 12pt Ubuntu
comment Ichi-Kyu-Hachi-Yon
RenderContext 用於實現視圖，需要負責將表格繪製為相應的 DOM 物件。
在接收到視圖事件，例如滾動和調整大小後，就會對相關 RenderContext 物件進行更新。
如果收到應用於試算表內容的更新事件，則會在試算表的指令佇列中加入新的指令。
SpreadSheetControl 負責繪制頂層界面，包括工具欄、狀態欄、對話框，以及顏色選擇器。
我們採用了基於類型的輕量級物件系統，僅使用了簡單的組成/委派機制，完全沒有使用繼承或物件原型。所有符號都位於 SocialCalc.* 名稱空間裡，以避免命名衝突。
對試算表的全部更新都需要通過 ScheduleSheetCommands 方法進行，因此需要通過指令字串來代表編輯操作。常用的指令如下：
set sheet defaultcolor blue
set A width 100
set A1 value n 42
set A2 text t Hello
set A3 formula A1*2
set A4 empty
set A5 bgcolor green
merge A1:B2
unmerge A1
erase A2
cut A3
paste A4
copy A5
sort A1:B9 A up B down
name define Foo A1:A5
name desc Foo Used in formulas like SUM(Foo)
name delete Foo
startcmdextension UserDefined args
嵌入 SocialCalc 的應用程序可以自行定義額外的指令，只需要將命名的回調函數添加到 SocialCalc.SheetCommandInfo.CmdExtensionCallbacks 物件，即可使用 startcmdextension 指令進行呼叫。
為改善回應速度，SocialCalc 會在背景執行全部的重算和 DOM 更新，因此在使用者對多個儲存格進行修改時，試算表引擎會同時在指令佇列裡處理先前的改動。
在運行指令時，TableEditor 物件會將其 busy 屬性設為 true；後續指令則需加入到 deferredCommands 佇列，以確保指令能循序執行。事件循環看起來像這樣：
如上圖所示，Sheet 物件會持續發送 StatusCallback 事件，以提醒使用者當前的指令執行狀態，這一過程都可以分為下列四個步驟：
啟動時發送 cmdstart，執行完成後則發送 cmdend。
如果指令間接更改了某儲存格的值，則進入重算步驟。
否則，如果指令更改了一個或多個已在螢幕上顯示的儲存格的視覺外觀，則進入繪製步驟。
如果上述情況都不符合（例如在使用copy指令時），則跳到位置計算步驟。
啟動時發送 calcstart，在檢查儲存格的依存鏈時每隔 100ms 發送 calcorder，完成檢查時則發送 calccheckdone，並在所有受影響儲存格獲得重算後的值後發送 calcfinished。
這一步驟之後總是需要執行繪製步驟。
啟動時發送 schedrender，如果使用格式化後的儲存格更新了 <table> DOM 物件，則發送 renderdone。
這一步驟之後總是需要執行位置計算步驟。
啟動時發送 schedposcalc，並在更新了滾動條、目前儲存格游標，以及 TableEditor 的其他視覺組件後發送 doneposcalc。
因為所有指令在執行後即被保存，因此等於對所有操作都可獲得執行紀錄。為實現稽核追蹤，Sheet.CreateAuditString 方法會傳回以換行隔開的字符串，每行內容對應到一個指令的相關記錄。
ExecuteSheetCommand 還可為執行的每個指令創建還原指令。舉例來說，如果儲存格 A1 包含 Foo，而使用者執行了 set A1 text Bar，則還原指令set A1 text Foo 會被推送到 UndoStack 裡。如果使用者進行還原操作，則會通過執行還原指令來讓 A1 的內容回到原先的值。
接著一起來看看 TableEditor 層。該層可計算 RenderContext 的螢幕顯示內容，並通過兩個 TableControl 實例來管理水平/垂直捲動軸。
視圖層主要由 RenderContext 類型負責。與 WikiCalc 的設計不同的是，我們並非將每個儲存格對映到一個 <td> 元素，而是直接創建固定大小的 <table>，使它充分填滿瀏覽器的可視區域，並為其預先填充 <td> 元素。
當使用者通過自定義的滾動條拖動試算表後，可以動態更新預先繪制的 <td> 元素的 innerHTML。這意味著在很多常見情況下，我們並不需要創建/刪除任何 <tr> 或 <td> 元素，因此大幅提升了回應速度。
因為 RenderContext 只繪製可視區域，所以無論試算表多大，執行效能也不受影響。
TableEditor 還包含一個 CellHandles 物件，可用於處理附加到目前儲存格（即ECell）右下角的圓盤形填充/移動/滑動選單指令：
輸入框則由兩個類型負責管理：InputBox 和 InputEcho。前者主要管理網格上的編輯行，後者主要用於在輸入內容時提供及時更新的預覽層，並覆蓋ECell的內容。
通常，SocialCalc 引擎只有在打開試算表並進行編輯時，以及將內容保存回伺服器時才需要與伺服器通訊。因此，Sheet.ParseSheetSave 方法可在Sheet 物件中解析儲存格式字串，而 Sheet.CreateSheetSave 方法可將 Sheet 物件序列化為儲存格式。
通過使用 URL，公式可引用任何遠端試算表中的值。recalc 指令會重新抓取被引用的外部電子試算表，並使用 Sheet.ParseSheetSave 對其進行解析，然後將其存儲在暫存區中，這樣使用者即可在不重新抓取內容的情況下，直接引用相同遠端表格中其他儲存格的內容。
儲存格式是一種標準的 MIME multipart/mixed 格式，主要由四個 text/plain; charset=UTF-8 部件組成，每部件包含以換行隔開的文字，並用冒號劃分資料欄位。這些部件包括：
meta 部件列出其他部件的型別。sheet 部件列出每個儲存格的格式和功能、每個列的寬度（如果不是預設寬度）、表格的預設格式，以及該試算表中用到的字體、顏色，及邊框列表。edit 部件可保存 TableEditor 的編輯狀態，包括 ECell 的最後一個位置，以及行/列窗格的固定大小。audit 部件包含上一次編輯會話中執行過的指令歷史記錄。舉例來說，下面是一個包含三個儲存格的試算表，A1 作為 ECell，其內容為 1874，A2 中是公式 2^2*43，A3 中的公式 SUM(Foo) 則顯示為粗體字，代表命名範圍從 Foo 到 A1:A2：
這份試算表經過序列化後，儲存格式會像這樣：
socialcalc:version:1.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=SocialCalcSpreadsheetControlSave
--SocialCalcSpreadsheetControlSave
Content-type: text/plain; charset=UTF-8
# SocialCalc Spreadsheet Control Save
version:1.0
part:sheet
part:edit
part:audit
--SocialCalcSpreadsheetControlSave
Content-type: text/plain; charset=UTF-8
version:1.5
cell:A1:v:1874
cell:A2:vtf:n:172:2^2*43
cell:A3:vtf:n:2046:SUM(Foo):f:1
sheet:c:1:r:3
font:1:normal bold * *
name:FOO::A1\cA2
--SocialCalcSpreadsheetControlSave
Content-type: text/plain; charset=UTF-8
version:1.0
rowpane:0:1:14
colpane:0:1:16
ecell:A1
--SocialCalcSpreadsheetControlSave
Content-type: text/plain; charset=UTF-8
set A1 value n 1874
set A2 formula 2^2*43
name define Foo A1:A2
set A3 formula SUM(Foo)
--SocialCalcSpreadsheetControlSave--
上述格式在設計上可讓人直接讀取，並且也很容易通過程式生成。因此，Drupal 項目的 Sheetnode 插件即可使用 PHP 在此格式以及其他流行的試算表格式，例如 Excel (.xls) 及 OpenDocument (.ods) 之間進行轉換。
至此，我們已經簡要介紹了 SocialCalc 各個元件和組成方式。接下來，讓我們透過兩個實際的範例，一起來看看如何擴展 SocialCalc 的功能。
(未完，待續。)
WikiCalc 一問世就帶來許多獨特的功能，是同時期的試算表所沒有的：
從幾個小型試算表組建一個主試算表的能力，是 WikiCalc 的一大強項。舉例來說，每位銷售員可以把營業額放在自己的試算表頁面裡；然後銷售經理可以綜合這些資料到該區的試算表中，之後銷售副總再綜合各區域的數字，構成主試算表。
每次有試算表更新時，所有綜合它的試算表都會即時反映出這次更新。如果主試算表的讀者想要瞭解更多細節，只需要點擊鏈結，即可查看試算表後面的試算表。這項功能讓使用者不再需要在多個地方更新數字，從而減少了多餘而容易出錯的操作，並確保所有資訊的視圖總在最新狀態。
為了即時重新計算的需求，WikiCalc 採用了輕客戶端的設計，將所有要顯示的資訊都放在伺服器端。每個試算表在瀏覽器上以 <table> 元素呈現；編輯儲存格時，瀏覽器會發送一個 ajaxsetcell 指令到伺服器，然後伺服器告訴瀏覽器哪個儲存格需要更新。
當然，這項設計依賴於瀏覽器與伺服器之間的快速連接。當網路出現延遲的時候，使用者在更新儲存格和看到它的新內容之間，會看到 Loading... 訊息頻繁出現；這問題對於需要即時調整、預覽公式結果的使用者特別嚴重。
此外，因為 <table> 元素與試算表有著相同大小，一個 100x100 試算表會在 DOM 裡創建上萬個 <td> 元素，大量消耗瀏覽器的記憶資源，進一步限制頁面的大小。
由於這些缺點，雖然 WikiCalc 作為在本地主機運行的獨立伺服器時尚稱實用，但要當作網頁內容管理系統的一部分，卻超出了它的能力。
在 2006 年，Dan Bricklin 與 Socialtext 團隊開始開發 SocialCalc 專案，用 JavaScript 語言對 WikiCalc 原本的 Perl 源碼作出改寫，目標是能支援大型試算表、分散式協作流程，以及與桌面應用程式一樣的操作界面。
這裡是 SocialCalc 的一些設計目標：
經過三年的開發和發佈許多次測試版之後，Socialtext 在 2009 年釋出 SocialCalc 1.0，成功實現了設計目標。現在，讓我們來看看 SocialCalc 的系統架構。
(未完，待續。)
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
Recent Comments