アジャイルプラクティス 達人プログラマに学ぶ開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

どんな本なの?

アジャイル開発の方法論や心得を45のプラクティスに分けて解説してます
全部のプラクティスに「バランスが肝心」というコーナーがあって、
盲目的に方法論を実践するのではなく、有効活用できるような心得が書かれているのが特徴
また、本の最後にいろんな立場や環境の人向けに、どのプラクティスから実践していくのがよいか
解説がされていて、実践に向けての敷居が下げられていたのが、特徴的でした
実用的やねー

んで、アジャイルって何ぞ?

重要度の高い事柄に注力し、重要度の低い事柄には労力を裂かないようにする開発方法

アジャイルマニフェスト
我々は、自らソフトウェアを開発し、
かつ他者のソフトウェア開発を援助することを通じて、
よりよいソフトウェア開発方法を解明しようとしている。
この過程において我々は、

 ・プロセスやツールよりも、人と人との交流を
 ・包括的なドキュメントよりも、動作するソフトウェアを
 ・契約上の交渉よりも、顧客との強調を
 ・計画に従う事よりも、変化に適応することを

重視するに至った。
これは、上記各行の左側にある項目の価値を認めながらも、
右側にある項目の価値をより重視するということである

具体的にはどんな感じに開発してくの?

小規模のメンバーでタスクを共有し、
イテーション(反復)という、1〜4週間程度の頻度でリリースを行って、
顧客にデモを行い、フィードバックを得て、機能を実装していく
なので、「設計は指針であって指図ではない」として、詳細な仕様を最初に決めるのではなく、
検証を行いながら、詳細な部分を詰めていくといった感じ


イテレーションの締め切りは厳守として、間に合わないものは取捨選択して、
リリースを遅らせない事で、開発のリズムを保つ事が重要みたい
リズムを保つ事で、停滞を発生させず、とにかく前に進む姿勢を保てるみたい


それで、各種方法論を用いて、短いイテレーション内でストレス無く作業を行うように工夫をする

欠点とかもあるんでしょ?

10人程度の小規模で、全員の意識が高く、同一の場所で作業する場合の方法論なので、
それ以外では、効果はあんまり保障できないです
たとえば、協力会社メンバーを50人タコ部屋に押し込んで…みたいな場所には向かなそう


ただ、本では必要なプラクティスだけ取捨選択すれば良い、と書かれているので、
各自の環境で使えそうなものだけもらうってやり方でもよいのではないかしら?

気になった箇所

3:人ではなくアイディアを批判する
  • 問題点を気づかせるような問いかけをする
    • 「2人のユーザが同時にログインしたらどうなりますか?」
  • 誰かを叩くのではなく、解決策を得るのが目的
11:指針は指針であって指図ではない
  • 設計には「戦略的設計」と「戦術的設計」がある
    • 戦略的設計が、用件定義に近い感じ
    • 戦略的設計を元に、戦術的設計をインクリメンタルに組み立てていく
    • 戦術的設計先に組み立てると…
      • 更新が大変
      • 誤った前提の設計を元に製造が行われる
  • 設計とは「意図」を表したもの。具体的な手順を示すものではない
20:作る前から使う
26:コードで伝える
  • 余計なコメントでお茶を濁さず、コードで挙動がわかるような実装をする
    • コメントが多いと、ソースの修正時に、コメントの修正も必要になって手間だし、
      コメントの修正漏れというリスクが増える
44:コードをレビューする
  • ペアプログラミングは、継続的なコードレビューでもあり、コードレビューの時間を割かなくてもよくなる
  • ピックアップゲーム:実装し、テスト完了後、誰かにレビューしてもらわないとコミットできない仕組み
45:みんなに知らせる
  • 情報発信機という考え
  • 時と共に変化する情報を張り出したポスターのようなもの
  • タスクや進捗だけでなく、マネージャが興味を持ちそうな情報を張る
XPはアジャイルの方法の一つであって、アジャイルならば、必ずXPである必要は無い
  • 勘違いしてました

参考リンク


一日でざっくり読める割に内容は実践的な上濃いので、良本と思いました
そんなかんじー