カテゴリー別アーカイブ: 技術のこと

エンジニアを目指す人に読んで欲しい、ちょっとだけ古い本

 

3冊の本

 
これからソフトウェアエンジニアを目指す人、またはすでにどこかでエンジニアとしての一歩を踏み出した人すべてのひとに読んでもらいたい本。ちょっと古い書籍ですが技術書というほど内容が濃くないので読みやすい本ばかり。
新しい技術や開発手法が次から次へと出てくるソフトウェア産業でも色あせない内容の本だと思う。ちなみに、仕事仲間には必ず、読んでもらうようにしている本である。

 

Joel on Software

 

最初の本は、「Joel on Software」(Amazon)

米マイクロソフトや米大手ISP(インターネット・サービス・プロバイダ)のJunoでソフトウエアの設計・開発に従事してきた筆者が、分かりやすい言葉で解説する。タイトルと同名の筆者自身のWebサイト(http://www.joelonsoftware.com)」で公開していたものを書籍化した。

ソフトウェア開発を行う上で大切なこと「考え方」「人・チームについて」「コミュニケーション」といったことをジョークを交えて書かれている。各文章もエッセイ形式(下に紹介しますが、Joel on Software というウェブログをまとめた書籍ということでエッセイ形式になっています)のため、技術文書よりも軽く読むことができる。

トレンドや技術については専門書やウェブに大量の情報がありますが、「考え方」のヒントを提供してくれる書籍として良書だと思う。

 

ピープルウエア 第2版 – ヤル気こそプロジェクト成功の鍵

 

次は、「ピープルウエア 第2版 – ヤル気こそプロジェクト成功の鍵

開発プロジェクトで技術よりも何よりも大事なもの——それは「人」。一人一人の人格の尊重、頭を使う人間にふさわしいオフィス、人材の選び方・育て方、結束したチームがもたらす効果、仕事は楽しくあるべきもの、仕事を生み出す組織づくり、という6つの視点から「人」を中心としたプロジェクト開発の大切をユーモラスに語っている。1987年に初版が発行され、多くのソフトウエア・エンジニアの共感を呼んだ名著の改訂第2版。

チームの視点、プログラマの視点、管理者の視点、またそれぞれの役割について「プロジェクトを成功させるためのキーポイント」をわかりやすく説明している。ソフトウェア開発は知的作業であるため、その生産性は人・チーム・環境に大きく影響されてしまう。そのために必要な「ヤル気」を促す職場環境・開発環境が必要と述べている点がもっとも言いたいことであり、この考えに共感する。

 

ハッカーと画家 コンピュータ時代の創造者たち

 

最後は、「ハッカーと画家 コンピュータ時代の創造者たち


本書の著者Paul Grahamは、LISPプログラミングの達人であると同時に、後のYahoo!Storeとなるソフトウェアを作り、ベンチャー創業者として大きな成功を収めたことで知られる。本書でGrahamは、コンピュータが大きな役割を担う時代において、いかに発想を広げ、美しいものを設計し作り上げるかを、さまざまな切り口から大胆に考察している。インターネット上で大きな話題となったエッセイを書籍化。

一人のハッカーの考え方、何かやってみようと思わせる(これは、自分が迷っていることに対して、背中を押してくれる感じが近いのかも)エッセイである。Joel on Software 同様に軽い感じで読みやすいのでオススメ。
これからエンジニアを目指す人は上の2冊とあわせて読んで欲しい書籍。

 

さいごに

 

今回紹介した書籍は、どれも技術文書(プログラミング言語とか、設計の仕方とか)ではない。
私自身、そのようなトレンドや時代の流れとともに変わっていく技術的な内容は、必要なときに必要な技術を学習すればよいと考えている。技術書ではなく、「人」「考え方」という普遍的な題材を扱った本を読むことで、ソフトウェアエンジニア/ビジネスマンとしての基礎体力を付けてもらいたい。その基礎体力が新しい技術やトレンドが変化したときでも、対応できる応用力と技術力にすることが出来ると考える

そのため、「エンジニアを目指す人に読んで欲しい本」として紹介。

IT勉強会に参加してみよう

IT勉強会に参加してみよう

4月は何か新しいことを始めるにはとても良い季節です。

学校は4月始まりですし、社会人になってからも会社の会計年度(4月〜3月)が多く定着しているため新しいことを始めるには最適な季節だと思います。

 

IT勉強会に参加したことはありますか?

ここ数年でIT勉強会に関する情報やイベントが多く開催されており、参加してみようと思われる方も多いのではないでしょうか。

ソフトウェアエンジニアの多くが企業による社内研修やOJT・独学で学んでいると思いますが、それとは違ったメリットがあるのがIT勉強会だと思います。

ネットで有名な人に会いたい・話したい、スキルアップしたい、興味がある技術をもっと知りたい、コミュニティに参加したい、、、など参加するきっかけは様々ですが参加することできっとあなたのエンジニアライフが広がります。

IT勉強会に参加するための情報収集

 

まずはどのような勉強会に参加したいのか、どのような勉強会があるのかを知っておきましょう。
 
一度は聞いたことがあるようなオープンソースソフトウェアや雑誌で特集されるオープンソースなどは大規模なイベントから小規模なものまで様々あります。IT勉強会の形態は様々あり、都内の大規模なイベント会場を使ったイベントから、オフィスの会議室を解放して行われる小規模なイベント、有料・無料など、決まった形は無く主催者や運営するコミュニティによって違います。

 
まずは、イベントのスケジュールを見てどのような勉強会が行われいるのかを見ましょう。

IT勉強会カレンダー

  1. IT勉強会カレンダー
  2. IT勉強会カレンダー(facebook)

 
IT勉強会の定番になっています。GoogleカレンダーをつかったIT勉強会のカレンダーです。
開催されるイベントが一目でわかります。想像以上に多くのイベントが登録されているのが分かります。
ただ、カレンダーを常に見ているわけではないので興味のあるIT勉強会を見つけたら募集終わっていた、、、開催されたばかり、、、が多いです。
 

IT勉強会に使われるイベント管理サービス

 
参加したいIT勉強会を見つけたら、参加申請を行います。IT勉強会ではイベント管理サービスが利用されています。イベント管理サービスはイベントを作成したり、参加費の課金、参加者管理がオンラインで可能です。
よく使われているイベント管理サービスを紹介します。

 

1. eventATND(イベントアテンド)

 
古くからIT勉強会に利用されてきた ATND β版に事前決済機能が付いた新サービスになっています。β版も利用できます。技術系のイベントが多いです。
 

2. Zussar

 

2011年頃にリリースされたイベントプラットフォームサービス。
非公開イベントが開催できるなど機能が豊富です。

 

その他にも

など多くのイベント管理サービスがあります。

IT勉強会に参加してみる

 

情報収集したら実際に参加してみましょう。イベントは講義形式や特定のテーマについて議論する形式があります。

 

初めて参加する場合、自分に合ったイベントが分からないと思いますが多くのIT勉強会は過去のイベントの様子やスライド・動画など公開されている場合が多くそれを見て雰囲気を知ることができます。

 

ビジネス寄りなイベントが苦手な方は、仕事が終わる19時頃から開催されているイベントや土日に開催されているイベントがオススメです。これはあくまで自分が参加したことのあるイベントからの予想ですが….

IT勉強会に自主的に参加する人たちは、目的意識が高く、集まって何かすることが大好きな人たちだと思います。なんとなくですが、教えることがすきでとても親切な人たちが多い印象です。

IT勉強会は仕事以外の出会いの場として大いに刺激を受けます。

そのような意識の高い人、スキルの高い人たちと技術的な濃い話題やソフトウェア開発、開発現場の話をざっくばらんに話ができる親睦会はぜひ参加してもらいたいと思います。
親睦会がメインと思えるくらい濃い話が聞けると思います。

 

IT勉強会に興味を持つ、参加したいと思う方がもっと増えてくれることを期待しています。

Sphinx + blockdiag による非プログラマのための使える図解の紹介

はじめに

こんにちは。Sphinx Advent Calendar 2012 の4日目のエントリです。@tk0miyaより受け取りました。

Sphinx を使い始めてまだ日が浅いですが実際に仕事で使ってみてすばらしいツールだと今更ながら気づき、Sphinx に特化したエントリというよりも Sphinx + blogckdiag を使って仕事に使えるダイアグラムの表現方法についてご紹介します。

非プログラマでも簡単に作成ができ修正も簡単、イライラしないでサクサクと図が書けます。

ソフトウェア開発プロジェクトで作成されるドキュメント(特にマニュアルで利用)は顧客に説明するための図解を多用します。これまでの経験で

  • Word/Excel の描画ツールをつかってがんばって作った図
    調整と編集がとても大変
  • Visio を使ってわかりやすく綺麗に作成されているが、Word/Excel/PowerPoint に貼り付け、画像のため編集が手間
  • 最近増えたと思われる開発環境としての Mac 利用者で使える描画ツールがほしい
    • Mac では OmniGraffle というすばらしいツールがありますが全員分のライセンスは難しい

このような状態でした。Visio や Omnigraffle は愛用しておりすばらしいツールですがもっとお手軽な描画ツールが欲しいとさがした結果、Sphinx + blockdiag という組み合わせが実用的なことに今更ながら気づきました。

基本的な Sphinx / blogckdiag の使い方ではなく、仕事で使える図解例のコードを紹介したいと思います。

図解のためのフォーマット

Sphinx + blockdiagでどのようなことができるでしょうか。
仕事で使えると思うパターンを以下の図をコードとともに紹介します。

  1. 手順…順番に説明するとき、ステップや時系列説明
  2. リスト…グループ毎に分かれた場合の説明
  3. リング/循環…連続したプロセスの説明
  4. 階層…重み付けされたモノの説明
  5. 集合の関連…グループの関連、アイデア、マインドマップ
  6. マトリクス…関連度合いの説明など

1. 手順

ステップや時系列説明に利用するダイアグラムです。

.. blockdiag::

   blockdiag {
     A [label = "ネタを探す"];
     B [label = "記事を書く"];
     C [label = "推敲する"];

     A -> B -> C;

   }

2. リスト

ダイアグラムと対応した説明をつけています。 :desctable: を利用すると説明表を自動生成してくれます。

.. blockdiag::
   :desctable:

   blockdiag {
     A [numbered = 1, label = "オペレーティングシステム", description = "CentOS 6.3"];
     B [numbered = 2, label = "ミドルウェア", description = "Apache 2.4 / Python 2.7.2 / Django 1.4.2"];
     C [numbered = 3, label = "データベース", description = "PostgreSQL 9.2.1"];

     A -- B -- C;

     // 配置
     node_width = 220;
     span_width = 20;
     span_height = 20;
    }

3. リング/循環

連続したプロセスなどの説明に利用するダイアグラムです。

.. blockdiag::

  blockdiag {
    default_shape = roundedbox
    node_width = 160;

    A [label = "タスク準備"];
    B [label = "プランニングミーティング"];
    C [label = "タスク割当"];
    D [label = "デモンストレーション"];
    E [label = "中間ミーティング"];
    F [label = "デイリースクラム"];

    A -> B -> C;
    D <- E <- F;
    C -> F [folded];
    D -> A [folded];
  }

4. 階層

プロジェクトチーム、組織など重み付けがある情報の説明に利用するダイアグラムです。

.. blockdiag::

   blockdiag {
    //縦書きモード
    orientation = portrait

    A [label = "プロジェクトチーム"];
    B [label = "開発チーム"];
    C [label = "斉藤"];
    D [label = "高山"];
    G [label = "品質チーム"];
    H [label = "佐藤"];
    I [label = "田辺"];

    A -> B -> C;
         B -> D;
         A -> G;
         G -> H;
         G -> I;
  }

5. 集合の関連

グループの関連、グループのメンバーなど集合に関するダイアグラムです。

.. blockdiag::

   blockdiag {
     A [label = "スクラムチーム"];
     B [label = "クロダ"];
     C [label = "サカモト"];
     D [label = "タニグチ"];
     E [label = "コンドウ"];
     F [label = "サトウ"];
     G [label = "ナカジマ"];
     H [label = "ソウマ"];
     I [label = "キタダ"];
     J [label = "コジマ"];

     A -- B -- C -- D;
     A -- E -- F -- G;
     A -- H -- I -- J;

     group first_group {
        label = "設計チーム"
        B; C; D;
     }

     group second_group {
        label = "開発チーム";
        color = "#77FF77";
        E; F; G;

     }

     group {
         label = "試験チーム";
         color = "#FF0000";
         H; I; J;
     }
  }

6. マトリクス

ここまで来ると無理矢理感がすごいですが、マトリクスっぽいダイアグラムです。

.. blockdiag::

    blockdiag {
      A -- B [style = none];
      C -- D [style = none];
      B -- D [style = none, folded];
      C -- A [style = none, folded];

      // ブロックのサイズと余白指定
      node_width = 200;
      node_height = 100;
      span_width = 5;
      span_height = 5;

    }

さいごに

いくつか blockdiag でやる必要の無い図がありますが、例ということでご了承ください。

Sphinx + blockdiag でこのような表現が簡単にできます。ブロック図生成ツール blockdiagの属性の説明にはさらに細かい設定が可能で作成したいダイアグラムに合わせた調整ができます。

実際に仕事で使ったときに自分達ルールというか、非プログラマでもドキュメント作成できるような環境のお膳立てをしました。優れている点は

  • テキストエディタで作成可能
    Windows/Mac/Linux 関係なく利用可能
  • 非プログラマでも簡単に習得可能
    ドキュメントに合わせたtoctreeとファイル群を事前に用意。担当にテキスト作成を依頼するだけ。
  • シンプルでさくさく書けること
    仕事で利用する場合雛形を事前に作成、最低限の書式のみというルール。ドキュメント作成者の技術スキルに関係なく文書作成だけに集中してもりもり作成してもらえる。
  • 図の修正が簡単(苦痛がない、これは結構重要)
    Excelの描画ツールではなく、図の描画は専用ツール使おうよ。と思っている。
  • 見た目重視の図、複雑な図ははじめから専用ツール(visio,Omnigraffle)を利用

自分の要求を満たした Sphinx + blockdiag という組み合わせはおすすめです。

次回のエントリは @togakushi です。お楽しみに。

Sphinx + blogckdiagで make html すると”The imagingft C module is not installed”でエラー

Mac OSX 環境でドキュメント作成に Sphinx を使っている。
Sphinx を使ってドキュメント作成するようになってから、使いたいと思っていた blockdiag をインストールしたがライブラリが足りないらしく利用できるまでに試行錯誤したときの設定メモ。

test.rst を作成して make html してみる

test.rst

テストのテスト
=============================
:日付: 2012/11/22

概要
===================
sphinxとblockdiagがちゃんと動くかのテスト。

blockdiagのテスト
===================
月曜日から日曜日、1週間を繰り返す

.. blockdiag::

  diagram {
    月 -> 火 -> 水 -> 木 -> 金 -> 土 -> 日;
    日 -> 月
  }

>make html

writing output... [100%] test
Exception occurred:
File "/Library/Python/2.7/site-packages/PIL-1.1.7-py2.7-macosx-10.8-intel.egg/ImageFont.py", line 34, in __getattr__
raise ImportError("The _imagingft C module is not installed")
ImportError: The _imagingft C module is not installed
The full traceback has been saved in /var/folders/s3/1sdhbw1532lfpqx0c7k4_0n00000gn/T/sphinx-err-NcPB1U.log, if you want to report the issue to the developers.

同様の問題(Mac OS X Lion / homebrew にて python の環境を整える)が起こっているらしく、FREETYPE2 supprt not available が原因らしい。

足りないライブラリをインストール

ライブラリが利用できる状態になっていないため、以下のライブラリを brew からインストールしてやる。
Mac OSX(homebrew)環境ではインストールされる PIL パッケージは blockdiag を利用できず、FREETYPE2 用のパッケージも提供されていないため、スクリプトを作成しインストールする必要がある。

ブログに記載されている内容をもとに freetype2.rb ファイルを作成する。

/user/local/Library/Formula/freetype2.rb ファイルを作成

require 'formula'

class Freetype2 url 'http://sourceforge.net/projects/freetype/files/freetype2/2.4.4/freetype-2.4.4.tar.gz/download'
homepage 'http://freetype.sourceforge.net/index2.html'
md5 '9273efacffb683483e58a9e113efae9f'
version '2.4.4'

# depends_on 'cmake'

def install
system "./configure", "--disable-debug", "--disable-dependency-tracking",
"--prefix=#{prefix}"
# system "cmake . #{std_cmake_parameters}"
system "make install"
end
end

ファイル作成後にターミナルからライブラリをインストール

>sudo brew install freetype2
>sudo brew install libjpeg

libjpegもついでにインストールしておく。

FREETYPE2 をインストールしてからPILをインストール

すでに PIL をインストールしていたので一度アンインストールを実行する。
それから pip を使って PIL を再インストールする。

>sudo pip uninstall PIL
>sudo pip install PIL
--------------------------------------------------------------------
PIL 1.1.7 SETUP SUMMARY
--------------------------------------------------------------------
version 1.1.7
platform darwin 2.7.2 (default, Jun 20 2012, 16:23:33)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available
--------------------------------------------------------------------
To add a missing option, make sure you have the required
library, and set the corresponding ROOT variable in the
setup.py script.

To check the build, run the selftest.py script.
changing mode of build/scripts-2.7/pilconvert.py from 644 to 755
changing mode of build/scripts-2.7/pildriver.py from 644 to 755
changing mode of build/scripts-2.7/pilfile.py from 644 to 755
changing mode of build/scripts-2.7/pilfont.py from 644 to 755
changing mode of build/scripts-2.7/pilprint.py from 644 to 755

changing mode of /usr/local/bin/pilconvert.py to 755
changing mode of /usr/local/bin/pildriver.py to 755
changing mode of /usr/local/bin/pilfile.py to 755
changing mode of /usr/local/bin/pilfont.py to 755
changing mode of /usr/local/bin/pilprint.py to 755

FREETYPE2 support available になったのでうまくいっているようだ。

最後に easy_install コマンドを使って blockdiag をインストールする。

>sudo easy_install blockdiag

これで設定は完了。

参考にしたサイト

開発チームにマイルストーンを導入して、必ずアウトプットを出すチームになる


ソフトウェア開発チームが安定して良い製品を開発し続け、優れたチームとして成果を出し続けるために導入すべき考え方がある。

それは、ソフトウェア開発の進捗管理を支援するための「マイルストーン」と呼ばれる考え方(機能)。

課題管理システム(Bug Tracking System)にもある機能で、製品開発のロードマップとも呼ばれる。
みなさんは「マイルストーン」を活用しているだろうか。

はじめに

マイルストーンとは一里塚や道しるべと訳され、システムやソフトウェアの開発において開発の区切りや工程の区切りを指す言葉として使われる。
進捗管理において、WBSやガントチャートはよく使われているツールだが、私がこれまでよく見たり使ったりしたWBSやガントチャートは管理者がプロジェクト全体の進捗を知るために利用したり、顧客へ報告するために利用している場合が多い。

最終的にWBSに挙げられた作業項目を期限までに終わらせれば良いが、作業項目には前後関係があったり、優先度があったり、期限と合わせ「いつまでに」「だれが」「なにを」をわかりやすく表現し管理できるものがソフトウェア開発では重要でそれがガントチャートにあたる。

ただガントチャートは管理者が管理するためには最適なツールであるが開発者にとってはそうではない場合がある。

このエントリーではガントチャートに代表される管理者のためのスケジュール管理ではなく、開発者視点のスケジュール管理としてマイルストーンを考える。

マイルストーンの効果

あなたがパッケージの開発チームであろうとインターネットサービスの開発チームであろうと明確になっていてほしいことは「いつまでに、何を開発するのか」「いつまでにどのバグを直すのか」ではないだろうか。
(それがまともな計画であるかないかは置いておいて。)
報告者がよく使う言い回しに「A機能の開発進捗が20%になりました。オンスケです。」は開発者にとってあまり重要な報告ではない。この20%が何を持って20%なのかは、プロジェクトやチーム、管理者によって異なる。絶対的な数字ではない進捗率は開発者本人の申請になるため、パーセントでの申告は曖昧にされている場面をよく見る。あくまでも感覚値ということもある。
この進捗率が意味の無い数字というわけではないが(実際、自分が関わっているプロジェクトも進捗率はよく使っている)、少なくとも開発者にとって重要なことは、期限とその実装内容(機能)が間に合うのか、という点である。

自分の少ない開発経験から開発者としての進捗率

ある小さな改修をするために5日間のスケジュールが与えられたとする。コードの量は実質2日間分くらいかもしれないが、実装方法の検討、周辺技術の調査、最適なコーディング方法、よくある実装例などはじめの2日間を調査にあてていた場合、ガントチャートの進捗は2日目まで0%。では管理者も顧客も納得しないため、10%-20%という数字を記載する。

タスクの進捗率については基準を設けるべきであり、その解説はこちら「上手なプロジェクトの進ちょく管理とは? – @IT情報マネジメント」に詳しい。

話を戻して、マイルストーン。

開発チームに焦点を当てたとき、このマイルストーンを利用するととてもよく機能する。
管理者が管理するためや顧客への報告のための道しるべではなく、プロダクトを開発するための道しるべだからである。

うまくいくためのマイルストーンのおすすめ設定がある。
マイルストーンに必要な3つのポイントは

  1. 期限・・・いつまでに完了させるのか
  2. 具体的なタスク・・・できるだけ具体的なタスクに落としたリスト、またはバグリスト
  3. 担当者・・・開発チームの担当者と割り当て(タスクの担当振り分け)

ポイントを個別に見ていくと、

1. 期限:いつまでに完了させるのか

あまりにも長い期間、大きな機能はおすすめしない。例えば「あるECサイト管理システムに在庫管理システムとの連携機能をつける、そのために3ヶ月くらい必要です。」3ヶ月規模の開発を1つのマイルストーンで考えるのは危険である。これはもっと細分化したタスクと分割した複数のマイルストーンを設定すべきである。

スクラム開発ではイテレーションという呼び方で2週間〜4週間くらいの開発サイクルを繰り返す手法をとっているが、理想はその期間と思って欲しい。
長すぎず、短すぎない期限で機能を実現するために必要十分な期間だと思う。

まずはチームメンバーにとって1ヶ月くらいで可能な開発範囲を決める、というやり方から始めるのが良いだろう。
あくまでも全体工程の中の道しるべになる日付と内容を決めることが重要である。

2. 具体的なタスク:できるだけ具体的なタスクに落としたリスト、またはバグリスト

これは比較的分かりやすい。WBSやガントチャートの項目を日々のタスクに落とす作業をすればよいだけとなる。
大きな項目を小さな項目に細分化したことがないならこれを機会にやってみることをおすすめする。開発者にとって作業の工数や見積を予測することはとても重要なことなので。
大きな項目とは、
* インフラ : ステージング環境構築 : 07/31 – 08/10 : 進捗率(10%) : 着手中

を開発者が実際にしなければいけないタスクをリストアップすることである。
まずは、サーバ環境を調査したり、開発環境のソフトウェアのバージョンやミドルウェアのバージョン、ライブラリを調べたり、資料にまとめたり、設定ファイルのこと、DBのこと、データはどうするのか、DB以外のユーザデータの扱い、etc…
ステージング環境を構築するという項目の中には見えないけどたくさんのやらなければいけないことがあることが分かる。プロダクトによっても大きく違う。

これを可能な限り具体的なタスクに落としたリストは、担当者だけでなく、チームの情報共有(彼、彼女は今何しているの?)のためにも有効である。

最後に、

3. 担当者:開発チームの担当者と割り当て

誰が対応するのか、を明確にすべきである。細かいタスクに分割した場合も同様で「だれが」という所在をはっきりさせておくべきである。進捗の状況によっては、担当割り当てが変更される場合もあるが、マイルストーンがスタートする時点ですべてのタスクを割り当てておくことが良い管理につながる。

プロジェクト管理方法、進捗管理方法を変えたり、ウォーターフォールからアジャイル手法に方式をかえるなどの大きくインパクトのある変更はとても難しいけど、開発チームと開発者にとって、自分たちのチームにマイルストーンを導入して効率的に進捗を管理することは大きな効果(ソフトウェアの高い品質)につながりやすいと思う。

小さい規模の開発チームであればあるほど導入はしやすく、すぐに効果が見えると思う。

小さな改善を繰り返すことで、あなたのチームはどこにも負けない良いチームになる。

マイルストーンのためのヒント

  1. チームで、またはリーダーがマイルストーンの期限と範囲を決める
  2. マイルストーンの期限は2週間から長くても4週間にする
  3. 期間で可能な目標を決める
  4. 目標=具体的な機能をチームで共有する場を設ける
  5. 管理者から割り振られた項目を細分化する(2,3日で完了する規模)、タスクに細分化。
  6. 毎朝、マイルストーンからタスクの一覧を確認する
  7. 進捗は小さいタスク単位に行う
  8. 進捗はタスクリスト(バグリスト)を共有して行う


具体的な作業項目は開発者を助け、進捗の正確性を向上させる。マイルストーンを計画するために最初の時間は必要であるがこのスパイラルがうまく機能したとき、チームとしてのアウトプットが大きく向上する。
会社やチームのやり方を変える権限がない場合でも、あなた1人だけが自分だけではじめることができる。小さな一歩であるがよりよいソフトウェアを開発したいという思いがあれば、今日からスタートできる。

マイルストーンは何かのツールや手法に依存したものではないのでどんなチームにも導入できる。