バグが起きてもいつ、どこで、なぜ起こったのかすぐには分からない それは仕様がきちんと固まっていなかったから? そもそもバージョン管理もissue管理もタスク管理もやってなかった
バージョン管理→Git タスク管理→カンバン + チーム全員で見積り
ペアプロでTDDという言葉を知らなくてもテストから書いたほうが 書きやすいと思える
自ら動きそのときに出来る小さなことから始めることがたいせつである。
-小さくコミットすること -バージョン管理をすること -細かく見積ること -スモールステプでテストを書くこと
謎発注、技術に触れることは殆どない
どうするか
周囲にアジャイルの魅力を伝え、変革を促す 社内でアジャイルなところに移る 会社をやめる
社内でアジャイルを導入しても、会社をやめても、 いきなりアジャイルをやるのは難しい
ケントベックのテスト駆動開発入門を読んで、実践する GitHubにコードを公開する 実際に活動した結果が公開されれば、それが信用につながるし、 だれかに自分を見つけてもらえれば非常に楽になる
ただし無理をしすぎないこと
今動いている開発手法を捨てて新しい方法を導入するのは難しい →エッセンスを取り入れることで開発者の作業、納期の遵守を考える
これらの方法はプロジェクト全体でかかわっている事が多いため、 すぐに導入することは難しい
故にまずはカンバンから始める
自分が受け持っているタスクを一気に分解し、一定のサイズに分け、 それを以下のステータスに分類する
こうすることで、自分の作業が見える化するし、他の人に作業を振りやすい
たとえばデイリースタンダップミーティングとかは導入しやすい カンバンは、一人で完結するぶんにはいいけど、張り出すための ホワイトボードや壁を用意するのは容易じゃなかったりする。
でも、見えるようにすることで、他の人にも目につきやすいし、 他の人たちも「やってみようかな」という気になるかもしれない。
とはいうものの、スタンダップミーティングが出来たからって カンバンもバーンダウンチャートも…という風にはならないので、 「アジャイルってもしかしていいかも?」って思う味方を増やす。 あと失敗して当たり前なので、定期的ふりかえりを行いフィードバックを受けるべし
実を言うと、某所でスタンダップミーティングをやってましたが、 某居酒屋の某朝礼みたいなテンションで執り行われたため、 僕のテンションはガタ落ちでした。
作るものの価値を高めていたわけではなく、 意を汲み、要件をまとめ、困らないタイミングで困らない程度の出力を出せていたという話に過ぎなくて、人間関係を滑らかにするほうが重要だったりしてた
どうにかしたい
で、まずはデブサミに参加し、それをきっかけに色々なイベントに参加する。 そこに参加しているエンジニアは本当に楽しそうだった
いろいろとわしわしmax
よくないことを見逃さずに正すこと
これは勇気と覚悟が必要だが、見てみぬふりをせず一歩踏み込むことが肝要です。