自己精心準備了很長時間，從素材和文章以及一字一句。

自己在這個社區進行分享的時候，開始自己照着自己的演講稿念，沒多久自己發現根據演講稿年思路不夠連貫。

自己扔掉演講稿根據之前自己準備的主體脈絡進行分享，有準備但是還是覺得臨場發揮思路更加連貫和清晰。

一個半小時過去了，我的分享完畢，這種直播的壓力確實是比較大的，因為你要直接面對聽眾，會遇到一些突發事情。

期間就發生了2次離線，還有你要關注評論的同時也不能讓評論影響你的節奏，

對於一些重要的評論在分享過程中隨時回復還是記錄下來？

直播結束后，第二天我又重新聽了一下自己的分享，總結一下直播的經驗。

過程比結果收穫更大。期間還有一件事讓我很是糾結。

我發朋友圈做宣傳，把自己的同事給屏蔽了，因為當時的我沒有自信，怕他們笑話。

心中的那種不自信的感覺完全戰勝了一切。自己不是技術最牛的，自己也不是這個管理經驗最豐富的。

我對自己這種糾結懊悔了很久，正常地做自己就好了，又不是做給別人看的。

下次再有機會我會更加自信，即便不是最專業，那也需要一份對自己努力的自信。

沒有一絲防備，我們直接切換另一個話題。

上面算是給自己這3個月沒寫博客劃一個句號。我們來看看最近我們在敏捷一些什麼？

我們項目組組織了讀書分享，當時組織這個讀書分享我也是很糾結。

作為項目經理不是職能經理，自己到底組織一場讀書分享合不合適？

我把我的疑惑和需求說給了我們項目群經理，希望從他那裡能夠得到一些經驗。

疑惑：我們從項目角度出發來組織學習，會不會觸碰了職能經理的職能邊界？

（比如讓大家閱讀《Scrum精髓：敏捷轉型指南》，會不會觸碰產品職能的邊界？）

需求：我希望大家能夠系統地認識敏捷和框架。
從中能夠學習到一些東西來應用到項目中，其次大家對於這種項目內的分享形式是擁抱的態度

經理的建議是可以嘗試一下。我們項目組開了一個會，約定了一下。

在不佔用大家太多的時間，我們挑選值得閱讀的章節么一個項目中帶着一次分享，每次分享大約1-2個章節。

我們其實是在項目結束后一周內，確定好閱讀範圍，確定好分享人，確定好分享時長兩小時。

流程分為依次提問和自由提問，分享人可以拿任何的分享資料分享（doc,表格）都行。

目的就是讓大家心裏有一定的概念並對當前最容易實行的一個敏捷方法進行深入討論。

這是當時分享人的一個分享大綱

第一次分享，大家也在適應遮掩的一種分享狀態。

整體過程很順利也夠味，如果能夠再放鬆一些那就更好了，大家說著說著就說成了項目總結會~

從有了開這種分享會的想法到實行，總結下來就是如果大家都抱有期待並且準備充足那就先試試。有想法就嘗試。

一些之前的想去執行的想法，當下就會執行嘗試。

終於到了標題中的這一部分。之前讀敏捷相關的書籍時，很多會提到站會上需要一個像權力交接棒的實際物品來標識你的權力~

以前我們開站會，時間和習慣都不錯，到時間我提醒大家開會，大家湊一堆開始開會。

但是，總覺得缺少一些什麼讓整個會議顯得有點太過於形式。

我想起了開始的那句話：有一個實際的權力物品來做交接。

看吧，就是這隻小鴨子

每天的站會，不同的主持人，主持人的象徵就是擁有這隻小鴨子~

就是誰拿到這隻小鴨子，誰就是站會的負責人和支持人。

8：40 他會在群里喊，然後會議上主持，結束后流動到另一位組織者手裡~

大家對站會接受度更高了，對這個項目也有了一些感情，團隊的人的默契和氛圍會默默提高很多。

這種感覺是潛移默化的，也是需要我們隨時提醒和建立的。

再回過頭來說那次敏捷分享的效果，我們之前是開發，然後測試，最後上線。

我們雖然是分階段提測但是沒有執行分階段測試。

所以這次新版本中我們“打成”一致嘗試分階段提測後分階段測試。就是 開發-測試交替進行。

有沒有難度呢？有，就是大家的時間和專註度會受到衝擊。

對於實踐這個開發、測試交替進行我們承認一些東西也相信一些東西。

我們組內也承認起初實踐起來肯定會比之前的模式有一定的不適應，但是我們依然信心。

希望可以踴躍暴漏問題不管是個人還是團隊不管是心情還是問題，都暴露出來。

我們組內達成了一致默默嘗試了一下，我們重視了組內的衝刺總結會，其實從總結會上我們收穫還是很多的。

一些開發和溝通問題，組內他們能夠自組織去主動解決，根據目前組內的主動性，我覺得我不需要關心。

我重點解決了一下時間和專註度衝突的問題。

開發正在開發下一個階段，測試正在測試你上一個階段，突然一個bug給你你煩不煩？開不開心？

–你是馬上斷開思路去改正？還是抱着忐忑的心情繼續開發？

開發修復完bug，馬上回給測試，測試此時正在測試下一個階段，

–你是斷開思路馬上去回歸？還是思索着會不會影響後面的功能的心情測試下去？

我們就問題討論，最終達成一致

當然我們還依然堅信，剛開始實踐期間肯定會有不適應和一些問題。

但是我們還堅持要解決問題並把問題的根因找出來，想辦法解決。這是毋庸置疑的。

分階段提測，大家達成一致是因為每一次提交的功能不是很多，測試測試之前可以先在群里發出通知。

開發就一些工作進行微調，便於後面的bug修改。

測試發通知–3：00統一提bug–開發4：00開始修復–測試最晚命題談進行回歸

還有一點就是，對於流程和嚴重bug，隨時支持，沒有理由。這個大家也是認可的。

其實這一段時間對於我到其他社區進行了一次敏捷分享；

對於項目組，我們使用權力交接棒–小黃鴨，進行大家主人翁意識的交接培養。

對於項目，我們實踐衝刺，我們開始重視每一次的衝刺總結會，

我們希望團隊中任何一個人都可以發現問題並自己發起會議（當然也是集中遇到問題或者集中解決問題）

我們實踐開發-測試交替進行的模式，為什麼呢？

這個原因我們的測試總結得很好，縮短時間其次，重要的是測試可以提前參与，提前發現問題，而不是最後採取發現問題。

我理解的是通過測試的力量在過程中來保駕護航，而不是在項目最後去修修補補。

最近感觸很大，當一些行動獲得大家認可的時候，大家互相能理解，大家也都互相提建議。

為了讓項目更好，讓我們更加自主，你好，我好，項目好。你提高，我提高，項目也提高。

當前的應屆生的學習能力和融合能力確實很強。

作為項目經理除了要保證項目交付這個基本目標以外，也是希望大家從項目中能夠獲得一些東西。我更希望是自驅的動力~

如果可以，可以把項目中的好的實踐帶到其他項目中去，去默默影響他人。

堅持自己，堅持自己的那些原則。獲得好的優秀的經驗，慢慢影響他人。