[閱讀筆記] Peopleware: Productive Projects and Teams (1/6)

    1.      根據研究顯示，專案失敗的常見原因是 politics，包含溝通問題、人員問題、與主管或客戶關係緊張、缺乏做事動機與高流動率等。但是，這類些問題的本質其實是社會學 (sociology) 而非政治學 (politics)

    2.      我們工作上所面臨到的主要問題，本質上與技術沒啥關係，倒是與社會學 (sociology) 習習相關

    3.      大部分的主管都承認，他們對人員 (human) 的憂慮遠高於技術 (technology)，但是實際在管理的時候，優先順序卻是相反，他們常將技術作為主要考量。不過這也不是主管們的錯，因為在學校受教育時，學校僅教導如何將事情做完 (how the job is done)，而非如何將事情做好妥善管理 (how the job is managed)

    4.      專案要能成功，需要仰賴專案成員間良好的人員互動 (good human interactions)；失敗則源自於差勁的人員互動 (poor human interactions)

    5.      明知在專案中，人員比技術重要，但是卻聚焦於技術，並非我們真的認為技術比較重要，而是相較之下，技術問題比較好處理。試想，為什麼 Horace 如此沮喪 (blue funk) ，或者為什麼 Susan 最近幾個月對公司如此不滿，這類的問題會比技術問題好解決嗎？人員互動 (human interactions) 是件複雜且不好處理的事情，但是它卻是工作層面中最重要的事情

    6.      若你發現你自己聚焦於技術 (technology) 而非社會學 (sociology) 時，你就像是個在暗巷遺失鑰匙，卻在鄰近光線較亮的街道找鑰匙的人一樣，只因為這條街光線比較亮

    7.      據我們觀察，大約15%的專案會成為泡影：不是被取消、放棄、“延期”，就是其成品從未被使用。專案規模越大勝算越渺茫。持續二十五個工作年以上的專案，有整整四分之一沒有完成。我們所研究的失敗專案中，絕大部份無法以單一技術問題來解釋其失敗。

    8.      你可以透過斯巴達式的管理來逼底下的人動起來，但是你無法讓他們有創意、有點子且設想周到。此法也只能產生短期的生產力，長期來說並不管用。

    9.      管理者常用製造業的思維來做專案，將專案成員視為是機器的一部分，當零件耗損，你只要再訂購一個一模一樣的零件予以替換即可。許多開發部門的主管常採用這種思維，催眠自己沒有任何人是不可替換的，因為他們恐懼 key person 離開，只好不斷地欺騙自己

 10.      人在時間壓力下不會把工作做得更好，只會做得比較快，結果被迫交出低品質的產品，自尊心降低，最後辭職不幹。

 11.      其實部屬們都明白人生苦短，也很清楚世上還有許多比眼前的蠢工作更重要的事。

 12.      終極的管理罪惡，就是浪費員工的時間，例如儀式性的會議。

 13.      工作時要包含腦力激盪、學習、調查、閱讀等。風險越大時越要做，而不是埋頭猛做

 14.      對大多數腦力工作者而言，偶爾犯錯是工作中既自然又健康的一部份，醞釀不容許出錯的氣氛，只會使人產生防衛心理，不再敢嘗試。但犯錯常常是產生創新的的源頭，為了防止犯錯會讓工作者產生防衛心理，而不敢做決定。

 15.      當風險升高時，多思考的重要性就應大幅增加。遇到真正困難的工作，就必須學習以更少時間做事，以更多時間思考工作。工作越困難，團隊成員學習良好互動與相處融洽就越重要。

 16.      加班就像衝刺 (sprint)。在馬拉松最後幾百碼，用盡最後剩餘的力氣來做最後的衝刺，這是有意義的，如果你是從馬拉松一開始就在衝刺，你是在浪費時間，因為你無法跑到終點線。一位只會叫員工不斷衝刺的主管，只會讓人對他失去尊敬。

 17.      主管設定無法達到的時程 (unreachable deadlines)其實是在傷害產品的品質。但是他們通常都不是這樣想，他們認為設定不合理的時程是讓員工自我挑戰，讓他們更加卓越。在此不合理的情況下，投入更多員工或減少功能通常都不會是選項之一，在時間壓力，員工能做的就是降低品質而已，員工會很憎恨他們所交付的產出，但是他們還有什麼選擇可以選？

 18.      無論是在哪個產業，若公司重視產品品質，員工也會交付高品質的產出物，進而提升員工的工作滿意度、降低員工流動率

 19.       對品質絕不妥協的公司將永遠得到卓越的品質，「品質ー若時間允許的話」的政策將保證產品沒有任何品質。

 20.      1969年，彼得 (Laurence J. Peter) 和霍爾 (Raymond Hull) 合著的《彼得原理》一書提出了一條與帕金森定律一樣，揭露官僚制組織弊端的原理，即“彼得原理 (The Peter Principle) ”。 該書指出，在任何科層體制的各個層次上都能看到一種普遍現象，即許多人不勝任他們目前所擔負的工作。 作者們對彼得原理表述為：“在科層體制 (Bureaucracy) 中，每一名雇員都趨向于晉升到他所不能勝任的等級上”。 同時他們還進而引出了一條推論：“每一個崗位最終往往被一個不適合履行其責任的雇員所占據”。 彼得原理是對工作效率低下、領導軟弱無力的官僚現象所作的一種解釋，按照他們的解釋，這種現象的原因在于等級制的組織不斷地把人們提拔到力不從心的工作崗位上的結果。 他們在低一級的工作崗位上本來工作得很好，但是在出現職位空缺向上晉升時就變得不勝任了。

 21.      一個健康的工作環境，有些人無法把事情做好通常是不適任、缺乏自信、對於專案的其他成員與目標缺乏歸屬感，這些人通常對於產出的品質好壞與否毫不在意。當看到此現象時，通常是一個非常確定的信號，這位同仁無法處理所交付的工作的困難度，繼續施加壓力並無法讓事情改善，他所需要的是重新分配較簡單的工作或是到其他家公司

 22.      帕金森瑣碎定理（英語：Parkinson's Law of Triviality），又譯為帕金森氏凡俗法則，或稱芝麻蒜皮定律、芝麻綠豆定律，由英國歷史學者與政治學者西里爾·諾斯古德·帕金森（Cyril Northcote Parkinson）於1957年所提出，用來說明大型組織會花費大量時間在討論無關緊要的瑣事，但是真正重大的決議反而可以輕鬆過關這種現象。這是由於人對大議題較難有全面性的理解，故怕貿然提出異議，可能會失言；相反地，對於一些簡單瑣碎的小事，有相當的認識，因此意見特別多，造成組織在各事項上討論所花費之時間，通常與事項本身的重要程度呈現反比。

 23.      帕金森定理（英語：Parkinson's law），由英國作家西里爾·諾斯古德·帕金森提出的俗語。這個俚語最早出現在1955年《經濟學人》中的幽默短文，西里爾·諾斯古德·帕金森說：在工作能夠完成的時限內，工作量會一直增加，直到所有可用時間都被填充為止。西里爾·諾斯古德·帕金森在1958年，將這個觀察，擴充為一本書，《帕金森定理：對於進度的追求》（Parkinson's Law: The Pursuit of Progress）。在此書中，帕金森定理被當成一個數學等式，用來描述官僚組織隨著時間而擴大的速率。帕金森觀察到，一個官僚組織中的雇員總數，通常以每年5-7%的速度增加。他認為，有兩股力量造成了這個增長：

              23.1.      一個官員希望他的下屬增加，但不希望解僱造成敵人增加；以及

              23.2.      官員會製造工作給彼此。

 24.      當專案時程完全不合理且不真實時，專案成員會變得憤怒與挫折，團隊士氣會降到谷底，這對團隊成員與管理者是雙輸局面 (no-win situation)。

 25.      軟體專案管理七個錯誤的期待 -

一定有什麼方法可以讓生產力大幅提升	事實上，沒有什麼神奇的方法。你該做的，應該是讓你的專案成員保持身心健康，生產力自然就會提升
可以透過神奇的工具獲得 100%, 200% 或更多效益	大部分神奇的工具向你兜售的都是聚焦於軟體開發生命週期中的開發與測試的部分。就算你省下了開發與測試的時間，別忘了 life cyle 裡面還有分析、協調、撰寫規格、教育訓練、驗收測試、系統轉換與導入等等，還有一堆工作要做
科技快速變遷，你快要追趕不上了	沒錯，科技的確快速變遷，但是你做的工作大部分都不是高科技的工作。當機器大幅改變時，軟體開發這一行幾乎沒什麼改變，時間大部份仍花在需求與規格上，也就是我們的工作屬於低科技部份。
更換程式語言可以獲得巨大效益	程式語言會影響你思考問題的方式，但是他只會對你的開發工作有影響。很多新的程式語言會誇大其所帶來的好處，除非過去幾十年的轉捩時刻你都在昏睡，否則更換程式語言對你不會有太大幫助，頂多只有 5% 的效益，不會更多了。
由於代辦事項 (backlog) 太多，你必須馬上提升產能	我們都知道軟體專案成本，預估與最後實際計算出來都差距頗大。對於今年無法開工還躺在 backlog 的專案（因為負荷不了），其成本樂觀地假設為實際成本的一半，甚至更少。請看清事實：這是賠本生意。這不該列為待執行專案，而是丟進垃圾桶，如果這個專案真的很重要，它就會被放在首位，而非 backlog。
即然一切都自動化了，你的軟體開發人員也該自動化	這又是高科技幻覺 (high-tech illusion)，以為軟體開發人員的工作都可以很簡單的自動。它們的主要工作是人際溝通，將使用者的需求說明統整成正式的程序，這個工作是必須且不太容易自動化的
如果你多施加壓力，你的專案成員會做得更好	不會的，你只是在澆熄他們的工作樂趣

 26.      如果施加更多的壓力無法提升人員的生產力，使用最新的科技也辦不到

 27.      管理者的工作並不是叫人去工作，而是創造讓人想去工作的情境。

 28.      浪費一個工作天的辦法有千萬種，卻沒有任何一個辦法可以重拾一個工作天。

 29.       每個人的工作日總是充滿著挫折與中斷，常常是一整天都浪費了，無法去做該做的、重要的事。如果你發現為什麼你每件事情都延遲，這就是主因

 30.      你會發現：

              30.1.      若你早一點到公司，因為不受干擾，故可以很快地完成手邊的工作

              30.2.      6:00 PM 以前，你根本無法完成什麼事情 (太多會打亂你的人事物)

              30.3.      當大家都下班、夜深人靜時，你一個晚上完成的工作量可能是兩到三個白天的工作量

[Travel] 貓纜、樟湖步道

[Travel] 201903 雲端山城 太平雲梯、老街

[Spring boot] A simple spring-retry example

Scenario

How-To
Add spring-retry in your pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>test</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>test</name>
    <description>Demo project for Spring Boot</description>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.0.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.retry</groupId>
            <artifactId>spring-retry</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>

    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

Create email service

package com.example.service;

import com.example.rest.EmailResource;
import lombok.extern.slf4j.Slf4j;
import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.Recover;
import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Service;

@Slf4j
@Service
public class EmailService {

    private int counter = 0;

    /**
     * 最多 retry 5 次，每次 retry 間隔 5 秒鐘
     *
     * @param param
     */
    @Retryable(maxAttempts = 5, backoff = @Backoff(delay = 5000))
    public void sendMailWithRetry(EmailResource.EmailParam param) {
        counter++;
        log.debug("Failed to send mail. Retried " + counter + " times");
        throw new IllegalArgumentException("some error happened");
    }

    /**
     * 當 retry 5 次全部失敗，則到 recover method，印出錯誤訊息
     *
     * @param throwable
     * @param param
     */
    @Recover
    public void recover(Throwable throwable, EmailResource.EmailParam param) {
        String errorMsg = "fail to retry 5 times, param = %s, error message : %s";
        throw new IllegalArgumentException(String.format(errorMsg, param, throwable.getMessage()));
    }

}

Create email resource class

package com.example.rest;

import com.example.service.EmailService;
import lombok.Data;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@Slf4j
@RestController
@RequestMapping(value = "/email")
public class EmailResource {

    @Autowired
    private EmailService emailService;


    @PostMapping(value = "/send")
    public void sendMail(@RequestBody EmailParam param) {
        emailService.sendMailWithRetry(param);
    }

    @Data
    public static class EmailParam {
        private String to;
        private String subject;
        private String content;
    }

}

Enable spring retry function

package com.example.test;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.retry.annotation.EnableRetry;

// add @EnableRetry annotation to enable spring retry function
@EnableRetry
@SpringBootApplication
@ComponentScan(basePackages = "com.example")
public class TestApplication {

    public static void main(String[] args) {
        SpringApplication.run(TestApplication.class, args);
    }

}

Do test and check result

2018-11-28 09:55:32.135 DEBUG 9804 --- [nio-8080-exec-1] com.example.service.EmailService         : Failed to send mail. Retried 1 times
2018-11-28 09:55:37.136 DEBUG 9804 --- [nio-8080-exec-1] com.example.service.EmailService         : Failed to send mail. Retried 2 times
2018-11-28 09:55:42.138 DEBUG 9804 --- [nio-8080-exec-1] com.example.service.EmailService         : Failed to send mail. Retried 3 times
2018-11-28 09:55:47.138 DEBUG 9804 --- [nio-8080-exec-1] com.example.service.EmailService         : Failed to send mail. Retried 4 times
2018-11-28 09:55:52.139 DEBUG 9804 --- [nio-8080-exec-1] com.example.service.EmailService         : Failed to send mail. Retried 5 times
2018-11-28 09:55:52.215 ERROR 9804 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.IllegalArgumentException: fail to retry 5 times, param = EmailResource.EmailParam(to=junyuo@gmail.com, subject=email subject, content=email content), error message : some error happened] with root cause

java.lang.IllegalArgumentException: fail to retry 5 times, param = EmailResource.EmailParam(to=junyuo@gmail.com, subject=email subject, content=email content), error message : some error happened
 at com.example.service.EmailService.recover(EmailService.java:37) ~[classes/:na]
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]