本身精心準備了很長時間,從素材和文章以及一字一句。框架
過程當中感受自信滿滿,後期再去回顧發現其實硬貨還須要再硬一點。
學習
本身在這個社區進行分享的時候,開始本身照着本身的演講稿念,沒多久本身發現根據演講稿年思路不夠連貫。測試
本身扔掉演講稿根據以前本身準備的主體脈絡進行分享,有準備可是仍是以爲臨場發揮思路更加連貫和清晰。blog
一個半小時過去了,個人分享完畢,這種直播的壓力確實是比較大的,由於你要直接面對聽衆,會遇到一些突發事情。開發
期間就發生了2次離線,還有你要關注評論的同時也不能讓評論影響你的節奏,博客
對於一些重要的評論在分享過程當中隨時回覆仍是記錄下來?直播
直播結束後,次日我又從新聽了一下本身的分享,總結一下直播的經驗。產品
過程比結果收穫更大。期間還有一件事讓我非常糾結。社區
我發朋友圈作宣傳,把本身的同事給屏蔽了,由於當時的我沒有自信,怕他們笑話。書籍
心中的那種不自信的感受徹底打敗了一切。本身不是技術最牛的,本身也不是這個管理經驗最豐富的。
我對本身這種糾結懊悔了好久,正常地作本身就行了,又不是作給別人看的。
下次再有機會我會更加自信,即使不是最專業,那也須要一份對本身努力的自信。
沒有一絲防備,咱們直接切換另外一個話題。
上面算是給本身這3個月沒寫博客劃一個句號。咱們來看看最近咱們在敏捷一些什麼?
咱們項目組組織了讀書分享,當時組織這個讀書分享我也是很糾結。
做爲項目經理不是職能經理,本身到底組織一場讀書分享合不合適?
我把個人疑惑和需求說給了咱們項目羣經理,但願從他那裏可以獲得一些經驗。
疑惑:咱們從項目角度出發來組織學習,會不會觸碰了職能經理的職能邊界?
(好比讓你們閱讀《Scrum精髓:敏捷轉型指南》,會不會觸碰產品職能的邊界?)
需求:我但願你們可以系統地認識敏捷和框架。
從中可以學習到一些東西來應用到項目中,其次你們對於這種項目內的分享形式是擁抱的態度
經理的建議是能夠嘗試一下。咱們項目組開了一個會,約定了一下。
在不佔用你們太多的時間,咱們挑選值得閱讀的章節麼一個項目中帶着一次分享,每次分享大約1-2個章節。
咱們實際上是在項目結束後一週內,肯定好閱讀範圍,肯定好分享人,肯定好分享時長兩小時。
流程分爲依次提問和自由提問,分享人能夠拿任何的分享資料分享(doc,表格)都行。
目的就是讓你們內心有必定的概念並對當前最容易實行的一個敏捷方法進行深刻討論。
這是當時分享人的一個分享大綱
第一次分享,你們也在適應遮掩的一種分享狀態。
總體過程很順利也夠味,若是可以再放鬆一些那就更好了,你們說着說着就說成了項目總結會~
從有了開這種分享會的想法到實行,總結下來就是若是你們都抱有期待而且準備充足那就先試試。有想法就嘗試。
一些以前的想去執行的想法,當下就會執行嘗試。
終於到了標題中的這一部分。以前讀敏捷相關的書籍時,不少會提到站會上須要一個像權力交接棒的實際物品來標識你的權力~
之前咱們開站會,時間和習慣都不錯,到時間我提醒你們開會,你們湊一堆開始開會。
可是,總以爲缺乏一些什麼讓整個會議顯得有點太過於形式。
我想起了開始的那句話:有一個實際的權力物品來作交接。
看吧,就是這隻小鴨子
天天的站會,不一樣的主持人,主持人的象徵就是擁有這隻小鴨子~
就是誰拿到這隻小鴨子,誰就是站會的負責人和支持人。
8:40 他會在羣裏喊,而後會議上主持,結束後流動到另外一位組織者手裏~
你們對站會接受度更高了,對這個項目也有了一些感情,團隊的人的默契和氛圍會默默提升不少。
這種感受是潛移默化的,也是須要咱們隨時提醒和創建的。
再回過頭來講那次敏捷分享的效果,咱們以前是開發,而後測試,最後上線。
咱們雖然是分階段提測可是沒有執行分階段測試。
因此此次新版本中咱們「打成」一致嘗試分階段提測後分階段測試。就是 開發-測試交替進行。
有沒有難度呢?有,就是你們的時間和專一度會受到衝擊。
對於實踐這個開發、測試交替進行咱們認可一些東西也相信一些東西。
咱們組內也認可起初實踐起來確定會比以前的模式有必定的不適應,可是咱們依然信心。
但願能夠踊躍暴漏問題不論是我的仍是團隊不論是心情仍是問題,都暴露出來。
咱們組內達成了一致默默嘗試了一下,咱們重視了組內的衝刺總結會,其實從總結會上咱們收穫仍是不少的。
一些開發和溝通問題,組內他們可以自組織去主動解決,根據目前組內的主動性,我以爲我不須要關心。
我重點解決了一下時間和專一度衝突的問題。
開發正在開發下一個階段,測試正在測試你上一個階段,忽然一個bug給你你煩不煩?開不開心?
--你是立刻斷開思路去改正?仍是抱着忐忑的心情繼續開發?
開發修復完bug,立刻回給測試,測試此時正在測試下一個階段,
--你是斷開思路立刻去迴歸?仍是思索着會不會影響後面的功能的心情測試下去?
咱們就問題討論,最終達成一致
固然咱們還依然堅信,剛開始實踐期間確定會有不適應和一些問題。
可是咱們還堅持要解決問題並把問題的根因找出來,想辦法解決。這是毋庸置疑的。
分階段提測,你們達成一致是由於每一次提交的功能不是不少,測試測試以前能夠先在羣裏發出通知。
開發就一些工做進行微調,便於後面的bug修改。
測試發通知--3:00統一提bug--開發4:00開始修復--測試最晚命題談進行迴歸
還有一點就是,對於流程和嚴重bug,隨時支持,沒有理由。這個你們也是承認的。
其實這一段時間對於我到其餘社區進行了一次敏捷分享;
對於項目組,咱們使用權力交接棒--小黃鴨,進行你們主人翁意識的交接培養。
對於項目,咱們實踐衝刺,咱們開始重視每一次的衝刺總結會,
咱們但願團隊中任何一我的均可以發現問題並本身發起會議(固然也是集中遇到問題或者集中解決問題)
咱們實踐開發-測試交替進行的模式,爲何呢?
這個緣由咱們的測試總結得很好,縮短期其次,重要的是測試能夠提早參與,提早發現問題,而不是最後採起發現問題。
我理解的是經過測試的力量在過程當中來保駕護航,而不是在項目最後去修修補補。
最近感觸很大,當一些行動得到你們承認的時候,你們互相能理解,你們也都互相提建議。
爲了讓項目更好,讓咱們更加自主,你好,我好,項目好。你提升,我提升,項目也提升。
當前的應屆生的學習能力和融合能力確實很強。
做爲項目經理除了要保證項目交付這個基本目標之外,也是但願你們從項目中可以得到一些東西。我更但願是自驅的動力~
若是能夠,能夠把項目中的好的實踐帶到其餘項目中去,去默默影響他人。
堅持本身,堅持本身的那些原則。得到好的優秀的經驗,慢慢影響他人。