level of abstraction 越高，越讓人能了解 whole picture，越能定義整件事情。對團隊來說 know how 才能累積。這也是為什麼程度較佳的團隊會要求自己的工程師：先寫文件再開發，注意/定義介面。BTW，如何寫好文件又是 another story 了。寫好文件不容易，暫不討論。

有沒有以上觀念差別在哪？

1. 開發好的東西是否能累積，是否能維護。小則讓同一工程師在一個月後還知道自己當初在開發什麼，大則核心人員要離職時不至於造成災難。
2. 讓管理者和團隊有東西可以依據。
3. 我提過，讓 process 提供 driving force, 而不是個人意志力。
4. 讓研發團隊知道自己在做什麼，而不是日復一日做一些 minor 或未經過設計的更動。
5. 藉由介面的定義改善程式品質，程式品質會直接反映在軟體品質。

但技術底子強的工程師面對變動時馬上會想到：

1. 為什麼要改？或是為什麼要在這時間點改？
2. 改了之後程式碼的代價是？風險是？
3. 改了之後可以維護嗎？有要維護嗎？

軟體工程的概念不能馬上給你一個超炫的新功能，或是馬上解決眼前的 bug。但卻有機會把軟體的體質改善，獲得長期根本上的健康。

優：

1. 窗口單一，以上層來說好管理。
2. task不用拆太細，sub-task 間沒有相依性 (都是由同一人負責)

缺：

1. 從頭到尾由同一人負責，不會去考慮模組間介面的問題，影響軟體品質。
2. 該負責員工不是神，也許可以做完，但很可能每個區塊都不優。
3. 重工的問題 (員工A 研究、實作完的東西，員工B 又要重複一次)

水平分工

優：

1. by 功能區分，可以培養出該 domain expert，當然該模組也會較優。
2. 要考慮 / 協議模組間或上下層介面的問題，對軟體品質有益。

缺：

1. 分派任務，或分派誰解 bug 時較難。
2. 專案進行時 task 間會有相依性。

以 design pattern 來說，Inversion of Control 真正的精神是 template method. 在 GoF 的 <Design Patterns> 中，template method 主要以繼承來達成。但是如果真正理解的話，用 composition 的方式一樣可以達成 template method.

很多文章會把 Dependency Injection 與 Inversion of Control 擺在一起討論 (如上面 link)。主要是因為雖然兩者用意不同 (Dependency Injection 的目的是解除相依性，Inversion of Control 的目的是製造框架)，但常常產出的程式碼會相近，尤其是當 Dependency Injection 被大量使用的時候。

需注意的是，即使是少量的 Dependency Injection, 一樣會伴隨小規模的 Inversion of Control. 所以雖然兩者目的不同，但實為一體之兩面。

• OgreMain
  • Extract the overlays from OgreMain and transform it into a own overlay component
  • Progressive Mesh improvements and new Mesh LOD sample.
  • Loads of documentation updates
  • Added Mesh::mergeAdjacentTexcoords to collapse two adjacent texcoords into one (i.e. float2 texcoord0 & float2 texcoord1 become float4 texcoord0)
  • According to the documentation, the default SceneManager ambient light should be black, which is wasn't though.
  • SceneManager: updateSceneGraph should happen BEFORE prepareShadowTextures.
  • AtomicScalar operators should be returning their value. Only affects using GCC or Clang.
  • New class ProgressiveMeshGenerator to degenerate mesh detail at runtime.
  • Bug fix for Sphere::merge. Inaccurate results can occur if one sphere does not fully encompass the other.
  • New LOD strategies ‘distance_box’ and ‘screen_ratio_pixel_count’. Details, see Ogre Manual.
  • SharedPtr moved to use atomics (related API change see below in the porting notes).
  • SubMesh has a new method: clone(const String& newName, Mesh *parentMesh) to perform deep copies of SubMesh objects. The second parameter is optional and can be used to reparent a SubMesh.
  • Removed Configfile::load(const String& filename, const String& resourceGroup, const String& separators, bool trimWhitespace) because it can easily be ambiguous. If you wish to load from a resource group, use the existing function loadFromResourceSystem. The arguments are identical to the removed function. See OGRE-175.
• New Volume Rendering component with LOD. See GSoC 2012 Volume Rendering
• Many Terrain improvements.See GSoC 2012 Terrain Improvements
• RTSS
  • Changed error handling of RTSS sub-render state parameter creation. Sub-render state now throws exception on errors
  • Added 2 new demo samples: multiple lights and textured fog
• CgProgramManager
  • Added support for high-level output profiles glslv/glslf/glslg and hlslv/hlslf (glslg not fully working yet)  

• Android Port
  • Remove eclipse based android port
  • CMake based build support
  • Create find Ant / NDK packages (currently Ant and the NDK must be in the global path)
  • Generate android make files for the sample browser
  • Use android tool chain to compile OGRE as static lib
  • Cleanup RTSS (Remove OgreStringSerialiser)
  • Improve platform integration
    • Add Android log listener into OgreRoot
    • Disable Filesystem- / Zip- / EmbeddedZip- Archives on android
    • Resource system improvements
    • OgreAPKFileSystemArchive to handle file access inside the APK
    • OgreAPKZipArchive so we can handle zip files inside the APK (APK is also compressed using zip)
  • Improve EGL support
    • Create concrete subclasses of EGL-Support/Window/Context
    • Handle context creation / configs inside OGRE
    • Resource recreation / Handle it like DX device lost / restore
      • Add managed resource class which every resource derive from (only active on Android – handled via macros)
      • Recreation of Texture, Shader, HardwareVertexBuffer
  • ETC1 texture codec
    • PKM support
  • Sample browser
    • Add touch input support
    • Build a APK file via CMake command line
    • Add rotation support
    • Fix / Enable more samples
      • Compositor not working
  • Improve CPU/ vendor detection
  • Add how to build it on Linux / OSX / Win32
  • Provide pre-compiled dependencies
  • Fix our dependencies so the can compile against the android tool chain
• Windows Metro style application (WinRT)
  • Add support as a new platform (named WinRT).
  • Create a WinRT project for the sample browser.
  • Create a how to compile file.
  • Get all existing samples to work with the D3D11 render system.
    • Multi monitordevice support.
• Windows Phone 8 port.
• OS X
  • Add a helper function to get a sandbox friendly temp file name for iOS and OS X.
  • Other fixes to file handling in response to App Store rules.
  • Support for building with libc++ on OS X.
  • Proper example of DisplayLink usage in the SampleBrowser.
  • Plugins and components are now built as frameworks.
  • Add escape key as a shortcut for Cancel. Fix crash when hitting cancel as well.

• DirectX 11
  • Improvements from GSoC project.
  • Add tessellation shaders support.
  • Add tessellation sample.
  • Add dynamic linking support.
• DirectX 9Ex support
• Added OpenGL 3+ RenderSystem. Still marked as experimental and under heavy development.
• OpenGL ES
  • GLES 2 terrain support.
  • OpenGL ES state and uniform caches.
  • Rewrote PVRTC codec, adding cube map, 3D and mipmap support. Only files created with PVRTexTool are supported now, not Apple's texturetool utility.
  • Experimental OpenGL ES 3.0 support.
• GL RenderSystem
  • GLEW updated to 1.9.0.
  • Remove restriction that all GLSL programs have the same matrix order when linking.

Just in Time 與 Kanban 管理系統源自於 Toyota 汽車創辦人 Kiichiro Toyoda 與副總 Taiichi Ohno 的 Toyota Production System (後來適用於軟體開發的 Kanban 已是軟體相關社群調整過的).

與傳統製造業一昧增加產能不同, JIT 強調的是

• 有需求才生產
• 減少浪費 (此一精神就是 Lean 的前身)
• 準時 (過產與落後都不符合標準)

另外因為「減少浪費」的基本精神, 持續 review 是否有浪費的情況下,「持續改進」也是 JIT 相當強調的精神.

http://blog.lyhdev.com/2011/04/lean-startup.html

1991 年的一本大作 “The Machine That Changed the World : The Story of Lean Production”

將 TPS (Toyota Production System) 發揚光大, 並提出 Lean 的概念, 經過 Agile 社群調整後, 即為 Lean Software Production.

另外 2011 年出版了另一本大作 “Lean Startup”, 為創業者提供了不同的思考模式. 須注意的是 Lean Startup 的重點並不是軟體開發流程或慣例等, 粗略的說 Lean Startup 與軟體開發本身毫無關聯.

http://www.kanbanblog.com/explained/

Kanban 則是 JIT 管理的其中一個實作. Kanban 一個非常重要的概念是 Limit work-in-progress (WIP) 來管理整條 pipeline 的 bottleneck 在哪. Limit WIP 才能將任務可管理, 並有高品質產出. 並非傳統直覺越快越好, 產出越多越好.

http://www.slideshare.net/ihower/scrum-kanban-scrum-lean-startup

ihower 的投影片, 個人覺得相當精髓. 其中 Kanban 與 Scrum 相異點

• 沒有 sprint
• 沒有定義的 roles, 團隊沒有要 cross-functional
• 沒有要估算時間 (至少沒有要以小時為單位估算時間)

我很喜歡其中一個重點: 別讓方法論(或是 Scrum)禁錮你的心!

根據以上「價值」, 所以軟體模組化, 撰寫文件, 基本的開發流程, 甚至定期重構程式就不需要了嗎?

完全以 business value 來看, 答案恐怕是 Yes. 但對有經驗或好的 programmer 來說, 以上的事情都不做, 可以想像會是災難一場.

在此我不是在挑戰 Agile 所強調的價值, 該價值就精神上是對的, 團隊千萬不要把力氣放在撰寫超嚴謹的文件, 或過度的重構 (larry 認為沒有明顯差異時, 根本不用重構. 但有沒有明顯差異, 則見仁見智, 尊重該負責員工).

就有規模有歷史的團隊而言, Agile 所強調的價值應建築在團隊現有制度, 文化之上, 做適時適地的做法規劃. 那對於小或新創團隊呢, 則須先建立基本的制度, 才有資格去談論其他東西.

題外話. 以上是 Agile 所強調的價值, 那你/我的價值為何? 你/我的每一動為了什麼? What really drives you forward?