顯示具有 agile 標籤的文章。 顯示所有文章
顯示具有 agile 標籤的文章。 顯示所有文章

9/02/2019

Scrum的缺點 (成為主管的31堂課)



當手上有榔頭,看到任何東西都像釘子 -- Abraham Maslow 1966
------

過去數年來Scrum明顯成為Agile軟體開發裡最常被討論跟使用的方法。

當然也有不少文章討論scrum的缺點(請參考這裡)。然而,Scrum是個在agile development範疇內的方法論,它是個很好的參考軟體開發流程的工具,而這工具有其「特性」,無所謂好與壞,當然就無所謂優點與缺點。

然而,這些特性不可否認,需要對該工具有一定的認知,特別是一些「預設要知道的事情」,以免誤用。舉例來說,當你使用榔頭的時候,大概會知道它是用來釘釘子,而不是拿來釘螺絲。此外,你也會大概猜到,右手拿榔頭左手扶著釘子時,要記得不要敲到自己的手指。

以下Scrum缺點(特性),也是常見的陷阱僅供參考。


(1) 團隊成員對Scrum的了解必須一致,工作能力最好也要差不多。


Scrum的運作中,高度依賴成員的自主性。Scrum Master雖然很重要,但僅在於Scrum本身的運作。對於任務完成的定義以及任務的品質,還是靠所有成員的能力。

換言之,如果有人技術能力特別糟糕,或者技術能力雖好,但對於Scrum的運用與瞭解和大家都不一樣,那麼有可能會有意想不到的長時間磨合期。


(2) Scrum並不會真正加快速度,只是讓速度透明,讓大家專注重要的事情。

許多企業導入scrum的目的是為了加速產出。事實上,Scrum並不會加快「某件事情的速度」。Scrum會讓事情變得透明,同時也讓團隊進行的速度變透明,讓大家更容易專注於正確的事情上。

整體來說,Scrum會減少各種不必要的浪費,讓整個專案效率提升,但就個別事情的速度而言,Scrum並不會提升。換言之,軟體工程師仍然需要有自己的方式來提升個人效率。


(3) Scrum並不會解決工作內容的相依性 


傳統的專案管理方法論,常常會提供類似甘特圖的工具。然而,Scrum方法論專注於某件任務(story)的完成,而隱含著希望每個任務的相依性,會在團隊成員的「成熟考慮」下被處理完成。

換言之,有相依性的工作就是有相依性的工作,軟體開發團隊還是必須要有自己的方式解決相依性。使用scrum並不表示相依性消失,也並不表示當有個寫得很獨立的story產出時,就一定會跟其他工作無關。這些都還是得靠團隊來處理。無論是使用Jira還是agilefant還是任何工具,都應該有自己的處理相依性的方式。


12/09/2017

How to build a self-motivated software developer team


A team which all team members are self-motivated is a dream team where everybody want to join in. But, it is really rare. Well, maybe the 1992 dream team was one of the cases but we didn't see many examples in software developer's world.

Nevertheless, to build a self-motivated team is a major task of a manager. If you are the manager, this should be your priority-zero task, and should be only one zero, if you are going to build a new team.

Self-motivated might be the best way to drive software engineer's performance. Since high productive engineer works high involved in creativities and mental work.  These are hardly be gain or impacted by salary or physical award (reference: 1, 2, 3). Sometimes it could be driven by a noble target: save all poor children in the world, increase average human life to 200 years. But unfortunately, that kind of things normally happens in non-profit organization with a born charismatic leader. 

So how to build a self-motivated software developer team in a common working place?

Three key points: (1) selection (2) intersection (3) automation.

(1) Selection

If a member who is already a self-motivated person, then it will be easy to keep his good attitude. Since it is pretty hard to change a person's mindset, therefore to get a right person is the most easy way.

Do select a person who already has record on self-motivation. DON'T select a person who has good skill-set but has bad records on self-motivation and you believe you can change his/her mindset, I won't say it is possible but you need to understand that you really have much less changes. Since you can't be with the person 7x24 and his mindset is only inside his brain.

The key point of selection is try to understand his past. Do not judge his "self-motivation" by ask future question like: will you be self-motivated in our team? Understand his past working experience by asking the difficult moment. Especially, sometime he might not be in spotlight and what he did on that moment.

Again, identify a person's past is the best way to select right attitude candidates. And a best fitting person can really have positive impact for the team. 


(2) Intersection

There is no way to read team member's mind. People have left-hand-column, even if you already selected best people to join your team and you were very sure they all are honest. But they surly have things which can't tell or won't tell.




Some leaders or managers will try to dig it out, it is fine to do but not that easy. The best way is to admit the existence. And then leaders should focus on the intersection which is the area that covers the target of a single team member, the team and the organization. And that is also the area where creates win-win-win.

A self-motived member could find that area by himself. But if you are leader/manager, you should keep in mind that figure out the area and knowing the area is very different in each individual. To fine tune a bit earlier can largely reduce the risk of un-motivated situation.

For example, "Ken" is always in good performance and deliver pretty good result. And you believe that you knew that his career interesting is pure technical area. Which means he might want to be an architect in the future. However, if you see he is pretty happy to lead junior members to work out teamwork activities, for example : organize a study group, handle company travel, or year end party. That might be a sign of that he is actually want to be a manager in the future. If his actions is toward his goal then it is fine. However, if his actions didn't reflect your assumption, then it is your time to reset yourself or/and make a little changes.

The bottom line is to avoid lose-lose-lose situation. This sounds funny and should not even considered to happen. But there are too many true sad stories existed in the world. An usual/typical sample in software developer's world was: a team (which members are well-pay) worked over-time on an ambiguous project for months, delivered a product which didn't fit PM's expectation, company lose money, members lose life, customer didn't get result: no body wins.

To avoid 3-lose situation, make sure there is an intersection of all. If you were the manager, make sure you can guide your members into his own intersection. But if you really see that there is NO intersection at all, make sure to create one.



(3) Autopilot

Autopilot means a member knows exactly what to do, how to do. And most important thing is if there are tasks out of his current skill set, he will know how to learn. He can even do self-consideration of intersection and selection. Totally worry-free.

Again, if the selection was done good, to let team member become autopilot will be easy. All you need to do is coaching. Coaching is another topic of a few books plus lots of trainings/experience. If you are an experienced leader/manager then you already know how to do, just reminder to keep open your mind. And also please keep in your mind that open-your-mind is never easy.

The bottom line is to avoid micro-management.  Software development is highly brain consuming job. Micro-management never works in software development, it does work in other kind of job but it definitely doesn't work in software development. If you need to talk to your member about when to arrive in office, when to leave, what to update in Slack, how to write email. That means you are NOT trying to build self-motivated team or this specific person won't fit in a self-motivated team.



Sorry, No short-cut

There is no short-cut in for organization theory. However, practically do the right things normally will get the positive result in a few months. Of course, sometimes in a rapid startup environment, it seems no time to wait. But most of us in software developer world are running marathon not a sprint.


Skill sets and performance concerns:


There is one more thing. I didn't discuss skill sets and performance here. But this is actually extremely critical for a software developer's team. Without an excellent skill sets and performance delivery the self-motivated will be useless. However, this "should" be not difficult to identify during interview and resume check.



12/05/2017

Scrum: Feature-boxing of Sprints







In certain scenario, a scrum project could allow different length of Sprints and still satisfies Timeboxing principle. It benefits an involving software product of build MVP, increase integration quality and make members even more focus.



Time-boxing is one of fundamental practices in Scrum methodology. Most of actions in scrum are time-boxed. It makes sure the project keep going and also lets members focus on current task.

Time-boxing is one of the cure of Parkinson's Law of Triviality for all kind of meeting. No matter it is Sprint kick-off or daily standup. I believe it should apply to not only project management but also other area of organization, as long as the timeframe is a consensus of members. 

You can easily find the definition or discussion of how important time-boxing (or timebox) is in google. For example: this one or this one.

Timeboxing in Sprint


A Sprint in scrum also apply to time-boxing. Normally it means when project kick-off, all scrum members will decide how long is a Sprint. The recommended length is 4 weeks in software development. After that all Sprint will be in 4 weeks, no matter how many stories have done or what changes happened between Sprints. That also means if a project is in Sprint-11, 40 weeks was gone. 

A fixed timebox sprint make process happens. But is it necessary to keep the same length of Sprint?

Still timeboxing but flexible in next Sprint



Timeboxing is still critical and should be applied in the moment before event start. Sometimes, we should not fix timeframe in project kick-off and keep for next 40 weeks or more.

In fact, every Sprint kick-off meeting should also discuss a timeframe of this specific Sprint.

Image a sprint-kick-off meeting. Everybody: Product Owner, Scrum Master, Scrum Members were together in this Sprint kick-off meeting, discuss stories and story-points. If PO select 3 stories: P1, P2 and P3 which needs 2 weeks, 1 weeks, 3 weeks. What team should do? The general practice should be keep P1 and P2 in this Sprint and also select a few lower priority task to fill up that one left week. However, there are a few drawbacks in this situation. Firstly, remember Parkinson's Law? members might extends the time for not select lower priority tasks which sometimes is not a bad idea. But secondly, if a scrum team keep doing select a lower priority to fill up time slot, it make the "priority" not "priority" any more. 

If all members have consensus of flexible Sprint length, they can easily setup next Sprint to 3 weeks. And that Sprint will done  P1+P2. Or with Product Owner's agreement, they can setup next Sprint to 6 weeks to complete all P1~P3. 

In some scenario, the most beautiful way should be keep P1 in next sprint only. And this Sprint will be just 2 weeks. 


Make MVP possible

Why do one story at one Sprint is a beautiful way? Well, in some scenario, we need to make MVP(Minimum Viable Product)...and keep make MVP for a while to identify market and make sure minimum waste. Unfortunately, no body can foresee the future. A quick/early delivery is the reason why MVP is useful and also the reason why it is good to stick a single story delivery in a single Sprint. To achieve that, we need flexibility in different Sprint.

The key person of MVP is Product Owner (PO). And to make MVP possible, the bottom line of scrum is to have PO's real participant. In reality, it is very very hard to PO to focus on what he needs to do. A single story delivery forces PO to make a decision of the real priority of backlogs. Since the team will really delivery a things in every Sprint and of course PO should then put the thing in the market. PO can't say: well, it is too early to go for market. Since this is his priority one! Priority one should go for market right away! 


Why Quality improved?


Very simple, each Sprint with only one story has its own QA process and due to the complexity of change is short. we can easily fix integration issue or new defeat much quicker than a sprint with more than one story.

Agile: Feel comfortable to Adopt reality


An agile team should be comfortable to adopt changes and those changes should reflect to reality. But should still keep the critical concept. There is always a way to enjoy both without compromise to an uneasy method. 

To be flexible in Sprint length doesn't mean to break Timeboxing. But it does break some rule from the regular Scrum training. Nevertheless, process is continuously improving is the bottom and spirit of Agile. Scrum master or organization leader should take responsibility to make sure the process could be tailored after retrospective.

Case Study


As developer manager of a enterprise software product, I modify a bit of product release method to make sure PO's backlog is a real priority to reflect market needs. 

The result is since 2016/July to 2017/Mar (8 Month), we delivery 5 releases. The longest Sprint is 8 weeks and the shortest Sprint is 2 weeks. We actually complete 5 major stories and achieve following technical result.

(1) Quality: no side effect in these 5 release. Compare to previous fix Sprint length model much lower technical defeat in beta.

(2) Productivity: averagely, more code conduct per engineer compare to previous fix Sprint length model. However, at the same period of time, we enjoy more team building activity then before and very very very few overtime.

(3) Motivation: engineer could see the result (no matter good or bad) few weeks after delivery. Previous fix Sprint length model needs 3 to 9 months to know if our works really matters.

If you'd like to know more detail, please drop me email.



12/02/2016

Scrum - 回顧。檢討?驗屍!



在Scrum方法中,每個Sprint結束要做事情是(1)實際交付產出 (2) 回顧檢討這個Sprint (3) 決定下個Sprint的開始。

其中,回顧檢討這個Sprint的做法,通常是一個2-4小時的Retrospective Meeting(回顧會議),再加上改善動作。


實務上,回顧檢討是sprint最難做得好的項目。


困難因素在於,人類有天生的認知謬誤。回顧檢討會議既然是人來召開,人來組成,當然很難確切找到此Sprint的需要改善的問題,並對症下藥。偏偏,絕大多數專案Sprint問題和人有關。

說得更直白的:

    - 所有專案團隊的主要關鍵問題,都跟人有絕對的關係。每個sprint檢討會議不去檢討「人」,就等於是兇殺案發生而不去驗屍一樣。

    - 所有未來改善項目,其改善效果和速度,也都和人有絕對關係。


Scrum基本作法


在大部分的Scrum教學材料中(註1),都很輕而易舉地說,團隊要在回顧檢討會議說,瞭解並討論三個項目:

(a) 這個sprint哪些地方團隊做得很好

(b) 這個sprint哪些地方團隊做得不好

(c) 下個sprint 團隊要做哪些事情使其變得更好



許多Scrum教學中,回顧會議都用一些簡單的方式:例如每個人提出3個意見,然後由Scrum Master逐一唸出,並且分類意見,接下來針對分過類型的意見投票,投完票之後再指定人選負責在下一個Sprint中改善。這個方式當然可以消除不少偏見和謬誤,但是容易忽略了「改善是需要針對人的行為而非針對事情」。


舉個某回顧會議中,團隊認為最需要改善的問題:

* 需求在sprint開始時還沒確定

這是個極為常見的sprint回顧問題,也通常是軟體團隊的困難。Scrum方法雖然試圖避免這個困難,但是還是非常容易在回顧會議中被提出來。筆者常看到會議記錄中,天真且單純的紀錄這一條問題....然後?也只是記錄而已。


這個紀錄有什麼問題?  ....有很大的問題!


大部分團隊,剛組成的時候,其Sprint檢討會議中,會不自由主的「避免」提出直接針對「某些人」的能力,做法,產出的問題。團隊會因為想要「努力團結」而避免針對人的討論。然而,除了超短期專案外,所有軟體專案,幾乎不可能「沒有人的問題」。反過來說,解決重要的人的問題,專案就會執行得更好。

回顧檢討要注重「人的問題」,並非單指某個人的能力不夠,也非某些人難以溝通。而是要透過實際的事物,探究人的行為造成的問題,而非問題的本身。「需求在sprint開始時還沒確定」是個血淋淋的事實。

但是,回顧檢討的重點在於,過去4周內,到底團隊成員知道是「誰做了什麼,或者沒做了什麼造成這個事實」,這才是重點。

正確的回顧檢討事實,可以是:


* 需求在sprint開始時還沒確定,因為Scrum Master沒有邀請Product Owner參加kick-off會議。

也可以是:

*  需求在sprint開始時還沒確定,因為Product Owner在kick-off會議沒講清楚,而團隊當時卻認為自己清楚需求,直到開始做了才發現不清楚,偏偏Product Owner之後就不參加每日例行會議。

也可以是:

*  需求在sprint開始時還沒確定,因為Product Owner在專案中間需求有改變,但是Scrum Master並未注意到大幅變更。


無論哪種回顧,都需要有「人」,「當時做的事情或這沒做的事情」,「產生的結果或沒產生的結果」。這樣的回顧檢討才會有意義。


但是,Scrum的方法論,看起來都是對事不對人。要如何在不交互指責的憤怒會議中,做到針對人的檢討,並能在下個Sprint還能持續團結合作?

如果你是專案經理或者Scrum Master,有三個基本的關鍵作法可供參考。(1) 先個人,再團隊。只內部,無外部。(2)  沒有問題,是最可怕的問題 。(3)實際事實,實際行為優先。



(1) 先個人,再團隊。只內部,無外部。


在會議開始之前幾天,先通知大家,回顧檢討會議的重點:先檢討自己,再檢討團隊,只檢討團隊內,不檢討團隊外。


(a) 先檢討自己的「行為」,再檢討團隊的「行為」。


並非要檢討個人的價值觀。例如,是不是很認真,很願意和其他人溝通...等等。而是自己先看自己過去做的「行為事實」,有什麼可以改善的地方。

例如:完成某功能程式碼之後,沒有先執行整合測試,就在某天每日會議報告已經完成,隔天發現,該功能有很多問題,還得修正進度,並且讓測試人員額外進行rollback。

另一個例子:這次sprint開始的時候,Scrum Master沒有堅持要Product Owner確定所有要完成的項目的需求,就讓Sprint展開。使得Sprint需要額外需求確認時間。

檢討團隊的行為,也和個人一樣。稍微不一樣的是,團隊行為通常是「個人行為」的組合。換言之,以「沒有人」為開頭的陳述就是團隊行為。Scrum Master或者專案經理,或者實際決定事情的主管,要特別注意,絕大部分的「沒有人」開頭的陳述,就要當作「自己」!

例如:沒有人發現在第二週自動測試的伺服器當機,連續好幾天的測試報告都沒有自動email出來,以至於團隊錯失及早修復bug的時間。

另一個例:沒有人提醒Product Owner開會的時間。



(b) 只檢討團隊內,不檢討團隊外


Scrum對於團隊有很嚴格的定義:做事情的人+Scrum Master = 團隊成員。

回顧檢討會議,必須要檢討內部,而不是檢討外部。許多檢討會議看似檢討內部,但其實是在檢討外部。

例如:加強和UX/UI部門溝通

這通常隱含對方不好溝通,我們只好努力跟他溝通。

又例如:公司有臨時交辦事項,團隊得分心處理

這隱含是更高階主管來的非專案任務,需要打斷專案時間。

這兩個例子並非不要改善。而是檢討回顧方式,會大幅「限制」或影響改善方式。與其他部門溝通問題,應該是具體列出過去4週,那些確切事情「被誤解」或者「理解錯誤」。根據實際的錯誤,來改變團隊對應的方法。

以UX/UI而言,釐清理解錯誤,可以用「雙方討論事情的時候,一定要至少要有mock-up」。

而以公司有臨時交辦事項為例。應該是「每個sprint預設的工作時間原本是160小時,下個sprint改為145小時,因為上個sprint臨時交辦非專案任務大約15小時」。這樣是以具體的事實,解決公司有臨時交辦事情的問題。

重點是:解決問題必須在「團隊內部能做的行為」,而非「希望團隊外去做的事情」。

會不會有回顧檢討的問題是「團隊內部解決不了」的事情?的確有可能,但是機率很低。團隊解決不了的事情,早就在sprint kick-off (開始會議)被隱含排除,所有團隊「認知到」的專案問題,幾乎都是團隊內部有方式解決或減少影響的。




(2) 沒有問題,是最可怕的問題。


有為數不少的專案團隊,在回顧檢討會議時,因為很多因素,無話可說。只好拿一些雞毛蒜皮的小事,或者看似重要但是不太重要的事情敷衍一下。

例如:

* 每週固定的下午茶太不健康,看能不能換健康一點的。
* 我們的螢幕太小,寫code很不方便。
* 每天站著會議好累,可不可以坐著
* 能不能有免費可樂
* 昨天code view有說code style要統一但是還沒有
* 我們可以固定一段時間來分享一下大家coding的心得

如果檢討會議的重要事項,全都是這類型的,那有三種可能(註3):

(A) 團隊有如NBA夢幻一隊素質極高,工作合作超級愉快,成果驚人。

(B) 團隊失去對專案的信心和動力,或根本不相信Scrum Master。

(C) 團隊絕大部分的成員經歷太淺,不知如何開始檢討。



--- (A) ---

如果你認為你現在的團隊是A,大概有49.99%的機會你是在欺騙別人。另外有49.99%的機會是你自己騙自己,或被別人騙。


--- (B) ---

如果你認為你所處的團隊是B,而你恰好是Scrum Master,或者是專案經理,或者任何領導階層。那你最最需要做的事情是「檢討改善自己」,而非「檢討改善別人」。一個團隊,大部分的人不願意說真話,最有可能有問題的一定是管理階層。

如果你認為你所處的團隊是B,而你非管理階層,也非Scrum Master。你可以先審視自己專案對社會的重要性。如果你是在核電廠,或者急診室,那你應該盡自己一切的可能,不計代價,不眠不休地改善現況。

然而,如果只是一般的軟體專案,建議你先就自己可以改善的地方檢討自己。確定當你看到不正確的事情時,會先審視自己的能力與做法。但也不需要強出頭,把自己當作革命烈士。畢竟,大部分的軟體專案並不是那麼重要。


--- (C) ---

這種情況似乎也常發生,但是解決方法很簡單。

首先Scrum Master應該在第一時間對於「雞毛蒜皮小事」,做立刻回應。對於每個小事的回應都是:下次不用等到sprint結束,中間任何時候都可以馬上找我講。這樣才會讓團隊成員養成自動自發,並容易判斷哪些事情很不重要。

如:

* 每週固定的下午茶太不健康,看能不能換健康一點的

...可以,馬上就換。以後一遇到這種問題,不用等到sprint結束,任何時候馬上跟我說或者寫信給我。

* 每天站著會議好累,可不可以坐著

...不行,因為站立會議的目的就是要讓你累。以後想到這類型問題,不用等到sprint結束,任何時候馬上跟我反應。

* 能不能有免費可樂

...可以,你馬上去買,發票給我。以後一遇到這種問題,不用等到sprint結束,任何時候馬上跟我說或者寫信給我。


* 我們可以固定一段時間來分享一下大家coding的心得

...可以,你馬上去發固定會議通知時間。以後一遇到技術分享的事情,只要不影響sprint時間,任何時候就直接去做,不用等到sprint結束。



(3) 實際事實,實際行為優先



Scrum的精神在實況與事實,而檢討的實況和事實在於「行為」而不在於「想法」或者「內心深處的感覺」或者「價值觀」。

這個概念非常重要。缺乏了這個概念,就容易讓檢討回顧會議,變成「互相責怪」會議。

然而,執行也很重要,執行不當,也會讓回顧檢討會議變成「互相責怪」會議。

首先會議一開始Scrum Master一定要強調,接下來的會議以事實優先,而事實當然是根據某人做的事情。在團隊成員互相不熟悉的情況下,要「反覆」的重述事實優先。並且在討論時,嚴守只看事實的承諾。

會議的形式此時就不太重要,不過:點名發表意見是個簡單的好方法。當然Scrum Master應該要自我拋磚引玉一下。

以下舉幾個常見例子:

成員J說:PM常常來叫我們改東改西,為什麼之前不確定好需求

這時候Scrum Master應該列出這個sprint完成的task。追尋到底哪些task的需求被改變,大約影響了多少工作小時。
當然成員可能會說他不記得,就請他大致猜測一下。然後再跟sprint的時間做比對。如果改動所花時間很少,那其實不是問題。如果改動時間比率很高,才是值得關注的問題。值不值得處理,要看比率原則。-- (註4)


成員A說:我覺得我的task太多,都做不完。


這時候Scrum Master應該立刻請成員A把過去一個sprint做完的Task列出,看看是不是有做完,並且完成這些task是否有加班,或者,其實他的task是由別人完成,但是每日站立會議中並沒有說明?總之,現場應該了解事實,而事實也一定能被了解,不能等到「之後」。因為每個Sprint只檢討這個sprint,也就是過去4周左右,不可能需要很長的時間了解事實,也不可能有「我現在忘了要回去找一下」



成員K說:負責前端的人的bug太多,有時候負責後端的人都得幫忙修復bug。


這時候,Scrum Master應該立即根據bug清單,看看前端的bug數量,和負責解決bug的人。假設前端bug數量在過去sprint中有100個,而99個bug是由前端的人解決,有1個是後端的人幫忙解決,而且也只花了1小時。那麼這個問題根本不成立。只是因為後端開發伺服器的人,會特別記得「例外事件」就會有別人bug多太多害我多花時間的印象。這事情比例上多寡,是不是值得處理就要看「實際情況」列出判斷。一旦列出來給團隊成員看,就很容易大家一起判斷。


成員F:我coding速度是沒很快,但是有些速度更慢的人,就完成比較少的task,好像不太公平。


這時候Scrum Master應該根據git或其他版本控制系統,列出團隊成員程式碼數量。配合完成的task數量,bug產生數量(表示code品質不好) 以及bug解決數量(表示解決的問題)大約比對一下,看看團隊的產出是否「差不多」。當然,不同的作業系統,不同的平台,不同的程式語言是不能這樣比較。

不過大部分的情況下,這個問題並不會被提出來。但是,這個問題會存在在壓力比較大的團隊成員中,並且有礙於團隊成長。因此,Scrum Master自己必須要有客觀的衡量產出的方式!即便沒有人提出這個問題。


成員L:我們對所使用的open source工具不太了解,導致於需要學習的時間。

由於這個問題很具體,Scrum Master只需要確定這件事情是否還存在。下個sprint還會不會有不熟悉的工具需要使用。



後續?

 Retrospective檢討回顧會議中,如果找到重要的事項應該要改善。當然就是Scrum Master或者管理階層需要去「執行改善」的時候。前述內容都只有「找到問題」而關於如何有創意的解決問題,還請參閱後續文章。






註1:網路上參考資料非常多,例如:這裡這裡 或者 這裡

註2:專案驗屍(postmortem)在許多人心中另有其定義,可以參考這裡,或這裡

註3:就只有這三種而已啊?確實有可能有別種,但是不太需要討論。例如:在某些軟體專案團隊的前幾個sprint,因為「蜜月期效應」的確真沒有大問題。也有很多軟體專案,本身的目標比較特殊:例如學校的畢業專案,或者政府國科會案,雖然要交付結果,但結果的本身根本不重要,當然也不有大問題。也有某些專案,並不適合採用單純的Scrum,所以無法使用檢討會議針對人進行檢討。

註4:Sprint的中途按照Scrum的精神本來就不能由PM/Owner隨意修改需求規格。但是,在這裡是Sprint的結束。如果Sprint中途真的發生臨時修改的事情,Sprint的結束當然要作為「事實」加以檢討。要注意的是,目的是檢討事實,而不是簡簡單單的說PM/Owner沒遵守「Scrum的規定」。Agile的精神中,團隊的溝通跟改善,遠比「規定」來的重要。由於軟體專案太常出現這類問題,所以後續文章也會有針對這種問題的建議解決方式。




10/20/2016

Scrum - 務實的彈性,千萬不要削足適履




夫所以養而害所養,譬猶削足而適履,殺頭而便冠 ......除小害而致大賊,欲小快而害大利

--- 淮南子說林訓


雖然說Scrum的方式與工具十分簡單,能務實並且彈性運用比照著字面嚴守方式來的重要。不過「務實彈性」和「削足適履」有時候只有一線之隔。


形式主義的削足適履


某些形式主義分子在執行Scrum上,會嚴守大部份framework的要求:每日站立會議,燃盡圖更新,user story和PM確認...等等。達成基本要素,似乎就是必要的事。

但是實際檢視其內容,偶爾會有怪異之處,而這些怪異之處,總是自然生出個理由:「因為我們team比較不一樣,所以有不同作法」。但其實以軟體開發來說,每個team統統都不一樣,而是否能有不同的做法,乃是看有沒有掌握agile的精神而定,而非把不一樣當作理由。

常見的怪異之處有:

* 每日會議除了堅持站著開之外,其他完全不堅持,會議中仍然會試著討論專案問題與技術解答。

* 在幾個sprint之後,仍然無法得知專案團隊的速度,因此仍然常有在sprint快結束時強迫加班的情況

* Scrum Master或者team leader會指定工作項目的完成時間

* 出現一些時間長達3天以上的工作項目,但卻又無法更細分階段或者細項。

* 在sprint結束的檢討會議(Retrospective Meeting)似乎都是在檢討別的單位的合作問題。


這些怪異的狀況都是削足適履的表徵。Scrum的精神在於實況並務實,因為「要Scrum」而做出怪異的行為,還不如乾脆不要使用Scrum作為開發方法論。



務實彈性的例子:以功能為sprint


sprint的基本精神在於每個sprint之後,都會產生可「交付」的結果。一般情況而言,專案的每個sprint時間長度是固定的,以符合Scrum的time-boxed精神。

但如果一個軟體產品已經是5.0版,功能趨於穩定,未來的挑戰,其實在於更快速正確的回應市場變化,則其實可以將time-boxed改為feature-boxed。




上圖取自:http://comsysto.files.wordpress.com/2010/06/scrum_cycle.png

簡單的說,每個sprint的開始,由產品擁有者(PO或PM)選定一個「最最最高優先」的user story。只能有一個,不多也不少。接下來的流程,和一般的Scrum相同,break down開發細項之後,由專案成員評估時間。

略有不同的地方在於,評估確切完成時間之後,就是這個sprint需要的時間。因此,可能是2週,也可能是4週8週。完成的定義當然是變成「可以交付的產品」。因此可能是5.0.1版。

假設sprint plan會議完成,決定是5週,之後就和一般Scrum一樣,在5週之後準時交付產品給產品擁有者。而產品擁有者應該會「立刻」將產品放到市場,看看這個「最最最高優先」項目有沒有達到預期的市場反應。下一個Sprint當然也是選擇一個「最最最高優先項目」,可能會花2週,也可能會耗時8週。

對於已經成熟軟體產品,這樣調整的最大好處是,快速取得市場反應,而非等9-12個月之後產生一個6.0的大改版。

產品擁有者(或者PM)自然會對自已的判斷有完整的責任歸屬,畢竟,如果幾個sprint都交付了產品經理認定的最最最高優先項目,而是市場反應卻不怎麼好,那麼產品擁有者當然要負起責任,花更多的精神來瞭解市場,並且將市場需求轉化為適當的user story。


每一種務實的調整,都有其優點和缺點。

「以功能為sprint」的例子中,最大的缺點在於,稍微控制不當,就會變成傳統瀑布開發模型。而時間估算稍有不當,就會容易延長專案難以收拾。因此每一次務實的彈性調整,都應該在sprint之後的檢討會議上,確實檢討改善。


參考:Scrum的缺點




10/10/2016

軟體專案的現實:解決人的問題




無論是否採用agile的開發方式,所有軟體專案,最大問題的來源都是人。

人的問題,通常會極現實的影響專案的進行。然而,妥善運用agile的精神和Scrum的方法,有機會讓人的問題降到某個程度。

某個朋友,姑且稱為K,在專案扮演專案經理的角色,遇到以下狀況:

我最近有遇到一個問題,不知道怎麼辦,下面的人一直做不到我的要求,或者動作很慢,即便壓日期給他,他還是沒辦法達到,但實際上它任務並不多,只是開test case,我不太知道怎樣push他,我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說,解決方式似乎也很簡單。首先專注於優先項目,接下來根據事實檢視工作,最後才考慮能力問題。


一:專注於優先項目


每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保,在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說,要確保團隊成員專注於目前任務上的方式很簡單:就是腳踏實地的「問」。在該成員一來辦公室的時候,就坐到他座位旁,親切的詢問他昨天早上在做哪些事情,昨天下午在做哪些,並實際上「看」到做的結果。就可以確定他是否專注,而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實,而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」,一起坐著看實際上的狀況。


二:工作檢視

以Scrum而言,每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成,沒有完成即便是已經達到99%也一樣是沒有完成。當然,前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum,則應該盡可能在團隊開始時,就先定義何謂「完成」。

以開test case為例,完成是指把要做的功能的test case詳述在某個測試文件管理系統上?還是只要先用excel或者wiki列出來即可?test case完成後是否要先讓團隊成員審閱,看看有沒有問題?要不要先估計每個test case執行會花的時間?test case的前置作業 - 例如建立測試資料等等,是不是也要涵蓋在其中?

當有完整的工作完成定義之後,要讓負責進行工作的人「決定時間」,而非「被決定時間」。

以軟體專案而言,任何超過2天的工作項目(task),都應該分階段完成。畢竟,就事實而言,一個人不可能「連續工作2天」,每天一定會停住工作,下班回家。而這些階段應該要有階段產出。以test case而言,假設有10個新的user story需要建立test case,則今天完成了4個,表示還有60%尚未完成。


三:能力分配

如果團隊成員的確很專注於工作,而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩,牽涉範圍廣。以軟體專案而言,能力並非只是撰寫程式,測試程式,理解規格等等。能否和其他人合作,也是能力的一環。

一個規模中等的軟體開發團隊(4-7人),如果有一個人的能力「極端」的差,確實會造成專案很大的問題。

在Scrum的情況下,這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多,但未來的sprint的進度,是以團隊能力來考量,因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下,可以先找到該成員的相對優勢。排定一些學習項目,來提昇該成員在這個專案中的相對優勢,並且在未來安排相對優勢的工作。值得一提的是,根據經濟學的「比較利益法則」,每個人一定會有所謂相對優勢:請參考這裡,和這裡

關於軟體開發團隊的個別能力,還需要注意以下幾點:


1. 每個人都會成長,但是....


每個人都會成長學習新知識和能力。但是!在中短期專案裡,必須先考慮個別能力與優勢。

換言之,團隊領導要像下象棋一樣,找到每個人的「專長」,能妥善組合專案,就是個好的領導者。

而差強人意的領導者,則是常常試圖規避個別成員的「缺點」,這樣比較不會出大問題,但也容易產生差強人意的結果。而最糟糕的領導者,則會把人當做圍棋,看到人非黑即白,見到專案漏洞時,看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質),但在軟體開發專案鐵定行不通。


2. 能力是綜合考量...


能力必須綜合考量「全方面」:例如是否好溝通,是否能處理複雜的設計問題,能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外,如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者,應該先思考自己是不是「問題的來源」,甚至要思考自己是不是根本不適合作為團隊領導。


3. 讓不適任的成員離開...


讓不適任的成員離開,某些時候是個可行的解決方案。特別是某些企業管理派別認為,投入時間在不適任的人身上,他有可能變得適任,也有可能不會改變,然而投入時間太多,會造成專案延誤。

以Scrum的角度來說,這個情況不太會發生,因為2-3個sprint之後團隊速度已經確立,無論適不適任,專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言,讓破壞性的不適任者離開,當然是解決方式,但不見得要「找另一個人進來」。






相關文章:人才管理心智圖為自己工作...



11/16/2015

創新公司軟體專案時程管理 (三個基本概念)




絕大部份創新公司,其實在衡量任何事情的時候,其所消耗的標準,並不是真正的金錢,而是創業夥伴們的時間。

每個人一天只有24小時,雖然今年是2015了,但是你還是不可能有時光車讓你爭取更多的時間。因此,專案的時程管理變得很重要。

時間管理的技巧方法很多,如果沒有概念可以先參考這裡。但最好先建立一些基本的觀念:

(1) 觀念一:每個人的時間效率有天壤之別


特別是技術類型公司,單指寫程式的效率來說,最好的程式設計師,和最差的有很大的差距。有些研究說是10倍,有些說是上百倍。

不只是程式設計,其他工作類型也一樣。更有甚者,品質的產出也被證實和速度沒有很大的關係。換言之,又快又好是絕對有可能的。

(2) 觀念二:每個人時間的比較利益不同,因此可以分工


那麼,這樣來說我們雇用三個強人不就搞定一切事情了?首先你不可能有機會在一開始找到三個強人,因為強人早就已經有非常好的工作。就算你運氣好到不行,真的雇用了三個強人,有趣的工作可能只有一個,也不可能三個人做同一件事情。

所以分工變得很重要。比較利益法則(參見wiki)解釋了為什麼多人合作有可能1+1>2。只要大家負責的部份,是相對其他人比較專長的部份。

不過分工是否得當,會有相當大的差距。在超大型組織裡面,以現代科技發展的程度而言,分工會自然發現,即便沒有效率也會發生,例如,任何開發中國家,經濟發展的時候,投入初級產業(農林漁牧)的人自然就會慢慢變少,換言之,只要少數人的努力就可以提供食物給其他人,而其他人就可以去做更多讓生活更愉快的事情。

但是在小型組織,例如只有5個人的startup,就必須要時常檢視這樣的分工是否合理,能否達到綜效。


(3) 觀念三:中短期的專案,其完成時間早就已經固定

一個為期1-5個月的專案,當目標和資源已經定義出來的時候,其實完成的時間早就已經被上帝決定好了。問題在於,創業夥伴們,能不能事先看出來。如果一開始對時間的估計有誤,接下來新的專案就要把失誤考慮進去。

對,沒錯這就是Agile/Scrum的基本要素,無論什麼理由,當你打算完成的事情決定好產出的目標之後,時間早就已經被決定,你能夠做的就只是盡自己的能力,縮短預測的失誤,而經過幾次中短期專案,理論上,創業夥伴們的能力和資源調配方式,已經讓大家可以準確預測完成的時間。



越是能了解時間的控制,就越不被時間控制。



沉思:


考慮以下說明:時間基本觀念很重要,因為創新公司,事情完成度是以時間來衡量,而不是以事情的進展來衡量。為什麼呢?


10/27/2015

委外(outsourcing)軟體開發的三個要點



委外開發outsourcing行之有年,它只是另一種形式的分工方式。

然而,委外的軟體開發,卻是困難異常。即便是簡單的網站設計,不複雜的智慧手機程式(app),在缺乏正確的溝通認知情況下,還是有可能以意想不到的結果。如果你的專案經理,或者是負責與外包商溝通的人,以下是你最少需要知道的要點。對於不了解的事情,有些時候可以用嘗試的方式學習經驗,但很多時候最好還是參考一下過來人的經驗。

這三個要點,是在已經透過正確的方法選到正確的廠商的前提下。如果還不知道怎麼選擇正確廠商,可參見這裡。


(1) 知道這次外包想要的結果是要什麼


作為專案負責人,你需要知道期待的外包的結果。

假設所有的軟體開發,都是外包商進行,那表示你必須期待外包商有負責管理整件事情

所謂的整件事情,是從設計,細部設計,定義管理的方法(例如Scrum, agile),程式碼版本管理(例如github),測試,檢查驗收。換言之,雖然你不負責整件事情,但是你卻要比外包商更了解,這整件事情要怎麼處理。這樣你才能有效控制外包結果。

當然如果外包的範圍很小,例如繪製android logo,那麼你只要確定外包廠商知道android logo有哪些尺寸與標準,約定好時間,就可以等著看結果。

如果外包的範圍中等,例如處理前端網頁javascript以及html部分,但是需要存取後端的API,而後端API是核心任務,因此是內部自行開發。那麼就要界定清楚範圍,你需要能完整提供API文件,不然至少要有API簡單的訓練課程,以及範例程式。由於開發活動必須有一致性,因此還得提供廠商版本控制系統的權限(例如gitbucket),另外還需要控制開發週期,以及哪些使用者功能(user story)需要先完成,哪些後完成。換言之,如果外包範圍是軟體開發的一部分,那有可能關鍵的結果在於某段程式的正確產出。

(2) 清楚說明規格


在台灣對規格書(spec)其實不那麼重視。尤其是所謂的系統整合商的IT專案。因為有太多情況,規格和最後實際的結果已經截然不同,而規格書很有可能是一邊開發,一邊才跟著寫。根本不切實際,最後都淪為最菜的SA所負責最無聊的工作。

清楚說明規格並不代表要有250頁這麼厚的規格書。而是要有在做重要的事情上,有不可否定的結果。舉例來說,google.com的搜尋畫面,其實也有很多功能,但是必有一個規格是:一個讓人輸入資訊的欄位,並且按下enter之後會直接進行搜尋。某些SA/PM在撰寫規格時會無窮盡的增列細節,例如欄位是要多寬,最多輸入多少字元,反斜線要不要處理,諸如此類。當然重要的規格細節要詳述,但是不能無止盡的窮數之。

對於規格書沒有基本認知的話,可以先參考這裏

已經有很多撰寫規格書的經驗,但自覺從來沒寫對的話,可以參考這裏。這個spec只有短短20頁,去頭去尾真正的spec可能只有17頁,他沒有很多細節,也沒有用很複雜的UML圖。而且spec徹底與實作方式無關。

(3) 確定對方理解什麼


這點聽起來很不可思議。但是在現實,實在常常發生。那就是即便語言上沒有問題,在溝通認知上,還是有極大的差距。有些幫助有效會議的技巧,通常會提到,會議結束的時候,請最重要的幾個人,用很短的時間,簡單說明會議之後他要去做的事情。如果在一個常常進行無聊會議的組織裡面,可能會有很戲劇性,很荒謬的效果。(請參見"開會開到死")

對委外開發而言,很多時候不是面對面的會議,再加上語言的不同,更容易產生誤會。執行者(就是外包商負責人)必須要有創意的使用結構性合理的方式,來讓彼此理解工作內容。

首先,使用文件是最合理的。尤其是對跨國廠商而言。而文件的長短與格式並不是重點,重點在於有沒有表達你要傳達的資訊。

更有甚者,文件常常有先後次序,你需要知道外包商到底有沒有看那份最重要的文件。

一個簡單的作法是:在最重要的文件(例如規格書Spec)的莫約3/4處,夾一段文字,說如果你看到這份文字,要立即email給某人,並且夾帶一段簡單的"口令",因為這可以證明他有認真看過,如果在X月X日前,沒有回覆給某人,你會假設他無法完成第一個milestone。

這個作法不管在第一次有沒有達到目的,接下來外包商自然就自動被訓練為,你的重要文件,他一定會看。

管理委外廠商有很多創意的作法。可惜的是,這些作法必須根據靠經驗和實際情況而改變與適應。很難光是用教學的方式就體會。





參考:

* 虛擬助理




10/26/2015

務實專案管理(FLA)的三個重點...(從team leader的角度)

軟體工程與專案管理的方法論以及參考書籍非常多,無論是最傳統的PMP,到近幾年強調的Agile, Extreme programming,以及創新公司最常用的Scrum,這些方法都不外乎希望能盡可能圓滿達成專案目標。

而越後面產生的方法論,似乎都盡量想要化繁為簡,貼近事實,以便彈性的因應改變。例如Scrum就是將需求變更控制在sprint開始或結束,並且讓每個短暫的sprint(3-5週)可以專心於現在的計劃,改變於是乎就受到控制。

專案經理的角色和技術領導相輔相成,只是目的截然不同。專案經理最終的目的其實是”管理利害關係人的期望” (Manage stakeholder expectations)。實務上,這個目的甚至比專案在時間成本內達成來的重要。

技術領導雖然不是專案經理,但實務上,技術領導的小團隊是專案執行的最適切單位,因而技術團隊領導者也是反映真實狀況的適切人選。

技術領導當然不見得一定需要知道專案管理的細節,然而在軟體專案的執行中,技術領導者瞭解得越多,越能讓專案有機會成功。瞭解得越少,越容易受困於專案管理的本身。

(參考案例一)

專案經理(PM)在專案一開始就召集所有分析師(兼為小組長)進行傳統的WBS製作,完成了一份洋洋灑灑專案管理文件。在缺乏專案管理的知識下,三個月後在專案中期,某小組長發現有很多事情其實未列在WBS中,他就很掙扎要照常繼續回報列出來的項目?還是要重新修改WBS?

(1) 萬事起頭難:起初,專案計劃


作計劃這件事很重要,相關的名言也很多:
  • 廟算者勝,得算多也;未戰而廟算不勝者,得算少也;多算勝,少算不勝,而況於無算乎。
  • A goal without a plan is just a wish
  • Fail to plan, plan to fail
  • Plans are of little importance, but planning is essential.
  • You can't predict the future, but you can plan for it
  • The general who loses a battle makes but few calculations beforehand
  • Planning is everything. Plans are nothing!


任何專案管理方法論都會涵蓋”做計畫”(planning)這件事情,原因也很簡單因為這實在太重要。可是也太容易被忽略誤解或輕視

無論任務範圍大小,多寡,範圍,一個適切的”文字化計劃”對於軟體專案絕對重要!特別是有任務是整個團隊曾經執行過類似的,”原則上”只要根據以前的經驗”照著作”就可以達成,這種特別容易被資深員工忽略的任務特別容易出錯,更何況”照著作”等於是打算重覆過去的經驗,而不是打一開始就意圖要精進。

忽略:"現在時間很急迫,不趕快做來不急,就不先搞計劃了"

越是急迫的事情越不能出錯,減少出錯的最基本方式就是先行計劃。更重要的是簡單的思考整件事情,並且寫下來,適事情大小,不但不花太多時間,而且最能降低的風險以及未來避免浪費時間來修正錯誤。

誤解:"作計劃要花很多時間"

一個複雜的任務絕對需要花時間計劃。但是一個簡單的任務,可能只需要花15分鐘把心裡想做的事情簡單地寫下來。這個過程就可能會讓團隊避免發生前述案例中無聊的錯誤和不必要的問題。

輕視:"作計劃是給老闆看的,反正事情都不是照計劃進行,計劃對我們沒有用"

這種想法跟不打算作計劃完全一樣。等同於靠運氣跟個人當時心情來決定最後任務的好壞。

做計畫並非僵化,計劃的本身形式也不拘,一個簡單的心智圖(mindmap)就可以整理思緒 揭露許多未來的可能性。

下圖是本文撰寫的第一個計畫,可以和最後的結果比較看看,雖然粗糙,而且之後順序以及結構也有很大的改變,但是計劃的本身卻是很簡單可以引領思考。


 

(參考案例二):

有個售前支援團隊,與各國業務長久一起合作習慣了,常常四處進行軟體產品展示任務。有一天得到通知要去東南亞某國家進行安裝測試,大家都以為當地業務會大致把前置作業搞定,因此就迅速訂機票出發。到現場才發現,客戶負責的技術人員當天根本就沒來上班!整個作業只好延宕一天。



任務分配

團隊合作必然涵蓋工作分配。在資訊科技領域中,分配的方式也有很多種。而對於一個團隊的技術領導者而言。當已經對自己以及團隊的能力有基礎認知之後,有效的工作分配是一開始就要先計劃的事情之一。

技術領導者必然是已經瞭解自己也大致瞭解團隊能力,同時也瞭解任務內容之後,才能進行計畫任務分配。任務分配可以是團隊所有人一起討論,也可以技術領導者自行決定,但無論如何一定要先考慮團隊成員能力彼此之間的比較利益。

比較利益法則最早出現在經濟學鼻祖大作國富論的第一章(亞當斯密,1776)。衍生的,基本概念很簡單,只要有效分配,任何情況下都可以達到1+1>2的效果,即便專案成員某些人明顯地比其他人能力還差。

(2) 專案專案執行中面臨的問題

專案執行面臨的問題 - 人的偏誤


人類判斷事情會先採用快速直覺,這乃是上百萬年來的演化,無論是視覺上還是意識上皆是如此。以下簡單列出常見的人類認知偏誤:


歸因謬誤(Attribution Biases): 

解釋別人的事情時,會傾向別人的內在因素,解釋自己的事情時,會傾向外在因素。例如:會議有別人遲到,心裡會想這是這個人紀律問題,沒志力起床。自己遲到,會解釋是因為交通問題,昨天事情太多太晚睡。


錨定效應(Anchoring):

有參考點或第一次接受的訊息時,會過度偏重參考點。例如某地區最近賣出的房價是一坪100萬,則臨近的房子無論好壞,預售價格為一坪50萬時就會被認為"很便宜",即便一坪50萬對絕大部分的受薪階級來說還是貴得要命。


沈沒成本(Sunk Cost):

過去已經付出去的,不管未來的選項如何,其成本都不會變。也就是說不同的選項無關過去的成本,只關係未來。例如當已經花錢買了張電影票,但是臨時聽說同一時間有某明星簽名活動。這時候有兩個選項,一個是繼續看電影,另一個是去參加喜歡的明星的簽名活動。無論是哪個選項,其該電影院票價成本都是存在,因為錢已經花下去。換言之,要考慮的只是,現在看這個電影是不是比得到喜歡明星的簽名重要,而不是考慮如果去參加簽名活動會損失電影票的錢。


過度自信(Over confidence):

人類對於評估自己的能力時都會過度自信。例如,在一個50個人班級裡面,所有人自我評估考試成績的"名次平均"在技術上說應該是25,但是通常自評估的平均值都會遠小於25。也就是大部分的人都會高估自己的能力。


羊群效應(Herding Effect):

在團體中,個別成員會不自覺跟著團體中心行動。例如,股票市場中,市場最常發生一直買或者一直賣的情況。而如果是在競爭市場,有特別突出的公司時,其他公司會學習特別突出的公司的行動。




專案執行面臨的問題 - 進度(時間進程 vs 距離進程)

在專案或者任務執行之中,技術領導者多少需要有效評估跟瞭解現況。而目前進度是最重要的"現況"。在比較嚴謹的專案管理領域裡面,有許多評量進展的指標,例如已投入成本和預計完成所需的成本比例(一般PMP常用方式)然而,在資訊科技領域中,比較適當的衡量應該還是以時間進度能準確反應事實。

所謂時間進度指的是,還有多少時間可以達到目的。舉例來說假設某人要去日本玩,從家裡到機場需要一小時,而飛行時間為兩小時,抵達機場之後到旅館需要一小時。因此當我們詢問他的進度時,當他的飛機抵達日本的當下,他會回報進度完成75%,尚有25%未完成。

然而,如果是距離進程,也就是以還有多少距離可抵達就有很大的不同。舉例來說,家裡到機場僅有50km,飛機實際飛行距離為1000km,機場到旅館假設有50km,所以當他的飛機抵達日本的當下,他會回報進度完成96%!只有2%未完成。





單以事實來看,這兩者都是事實,可是呈現於資訊科技控制進度與瞭解現況來說,恐怕是以時間進度比較能夠掌握。畢竟,當一個團隊成員說有件事情只剩5%完成,而且你知道他在這事情上做了3小時的時候,在沒特別問清楚的情況下,你大概直覺上認為只需要幾分鐘完成,而非剩下的5%距離,需要在1小時完成。


不過專案進程的事實搜集,有太多太多慘痛的例子是在混用時間進程和距離進程的估計。事實上,由於人類天生的偏誤,在距離很短的時候,會不自覺採用距離進程來回報狀態。這時候技術領導有意識的取得"時間事實"才最重要。

專案執行面臨的問題 - 技術問題

技術問題層出不窮,不過大部份專案的技術問題,通常可以解決。然而,技術問題通常也很難概化討論之,他和專案的特性以及屬性有關。

不過就軟體專案而言,有個兩個看似有些衝突的基本概念一定要知道:


(1) 每個人的技術能力與技術方面的產出差距可以達到10倍以上。而每個組織的能力與技術產出,也有近十倍以上的差距 


(2) Scrum的方法論裡面,假定短時間每個人的績效不會成長,也不會改變

我們以後會再來討論這兩點。不過建議先對agile, scrum有初步研究。


(3) 專案的結束:好的結尾比好的開始更難

第三個重點,專案的結束。很多大公司,無疾而終的專案很多,軟體專案通常無論如何都還是會結束,只是結束的方式好不好而已。

礙於篇幅,我們在日後的文章再來討論專案的結束


沈思:

* 為什麼這次有些項目會在日後再討論,沒辦法先提示一些重點嗎?

* 對於務實的專案管理方式的諮詢服務,請與我們聯繫


10/19/2015

精實創業之 三個精華(MVP POC Scrum)



Lean Startup 精實創業是近年常見資訊時代創業方式。他著
重於確實以及快速。確實達到目標,以及快速反應變化。參見wiki https://en.wikipedia.org/wiki/Lean_startup


當然Lean強調速度也有些反面的意見

以下是三個精實創業的精華:

(1):POC實證觀念:


精實創業最精華的地方在於POC: Proof of Concept:實證觀念。唯有你的創業想法能夠被証實可行,而且在市場上獲得證實,你的主意才有意義,缺乏實證的就把想法大幅推廣只能靠運氣。這裏,會介紹做出MVP的最務實方式。

而在Lean Startup 作法上一般分成幾個層面:
(1) MVP: 最小可用產品
(2) 持續部署
(3) 測試產品(A/B test)
(4) 調整方向(Pivot)
(5) 做-衡量-學習

(2):MVP能達到POC:

在這些層面之中,最重要的還是做出MVP並且在市場測試。MVP講起來簡單,但做起來不容易。特別是在新創公司,大部份的工程師都會傾向做出完整的優良產品,MVP有時候是要做出最小功能的產品,這可能與工程師的天性互相違背。在Lean Start up 原創者Eric Ries的書裡面,描述了一個網路賣鞋的概念,去實現此概念不見得一定要做出有完整購物車以及金流的網站(強烈推薦看一下此書)。

當你靈光一閃的時候,如果沒有去實踐,終究也只是一閃。然而實踐要付出很多代價,最務實的方式會是用Scrum來做出MVP,由MVP進行測試產品,然後再由市場來決定這樣的靈光一閃是不是真的好主意。

(3):用Scrum限制成本達到MVP

Scrum是Agile的方法之一。Scrum可以用在很多地方,但MVP是Scrum能發揮的最佳之處。作法如下:


1. 定義功能
2. 排序
3. 限定時間以及成本
4. 刪除
5. 設計與實作
6. 投入市場
7. 收集反應資料

然而精實創業也常被人詬病為產品不完整,因此一開始有效定義MVP,之後以Scrum來實踐是比較實務的作法。


細節案例請參考如下節。


用以沉思的務實細節:


1. (定義功能)根據靈光一閃出現的絕妙好主意,定義出想要的東西的功能。舉例來說,你想要做一個具有特殊演算法用來計算一起用餐分帳的手機APP。列出的功能如下:

 * 能夠快速紀錄帳款
 * 特別紀錄和朋友一起用餐的分帳方法
 * 顯示欠款,被借款資料,以及目前帳不是平的
 * 一起用餐的餐廳資訊
 * 一起用餐的人數
 * 能夠登入,登出,帳號基本管理
 * 後端能未來做分析

2. (排序)根據你心裡的重要順序 把功能排序,結果可能如下:

 1. 採用特別分帳方法來均分帳款
 2. 能夠紀錄和朋友之間用餐的帳款
 3. 能夠登入,登出,帳號基本管理
 4. 後端能未來做分析
 5. 顯示欠款,被借款資料,以及目前帳不是平的
 6. 一起用餐的餐廳資訊
 7. 一起用餐的人數

3.(限定時間以及成本)這也就是MVP有意義的重點,任何事情都可以無限上綱地做到不可置信的完美,但是時間成本永遠是有限的。假設我們限定一個月,分成4個sprint,並且是2000美金。

4. (刪除)每個Scrum只能做有限成本的功能,剩下應該移入backlog。在這裡粗估每個sprint能完成一個功能,因此只留下四個其餘刪除。可能留下的結果如下:

 1. 採用特別分帳方法來均分帳款
 2. 能夠紀錄和朋友之間用餐的帳款
 3. 能夠登入,登出,帳號基本管理
 4. 後端能未來做分析

5. (設計與實作)根據留下的功能在每個Sprint進行設計以及決定實作:

 這一點牽涉比較多軟體開發知識,在此暫時省略。不過,如果已經固定了成本,可以考慮能實踐你的好主意的企業,例如TALENT-SERVICE

6. (投入市場)對於APP來說,投入市場當然就是上架。但要注意的是,上架本身牽涉到許多行銷以及相關知識。缺乏這種知識與行動的話可能會很慘。


7. (收集反應資料)對於APP來說,設計與實作的好,可以讓資料收集以及市場反應變得很容易。當然這個也牽涉到一些專業知識。簡單的說,盡可能利用已經存在的平台:例如google adsense, AWS, facebook等等來幫助你搜集資料。

Lean startup, MVP, Scrum是三個互相輔助的概念。透過Lean startup的精神,利用Scrum來做出"很多個MVP"才是成功的最簡單方式。參考這裡