質とスピード(2022春版、質疑応答用資料付き)
![質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition](https://cdn-ak-scissors.b.st-hatena.com/image/square/6a842e0cdaca4b59b4a7526df7802187f71c023a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F0d45756f147d45229020083eb2dd139c%2Fslide_0.jpg%3F21716780)
質とスピード(2022春版、質疑応答用資料付き)
Henrik Knibergさんのブログで「One day in Kanban land」という記事を見つけました。そこでは、かんばんの使い方のポイントがうまく描かれたマンガが紹介されています。各国語に訳されているので、ヘンリック氏に許可をいただき、日本語訳してみました。 赤い人がプロダクトオーナー(PO)の役割で、青い人たちが開発チーム(DEV。ここでは2名ずつ2チーム)、緑の人がテスターだと思います。テスターチームはデプロイまで担当しているみたいですね。 また、「TODO」「開発」「デプロイ」という各ステージにはWIP(Work in Progress:仕掛り作業)が制限されています。WIP制限とは、各ステージにWIPの数以上のカードを貼ることができないというルールです。
It's a bright day for code review! Still on pull requests? See why organizations upgrade to Review Board: Code review, document review, and image review, all in one place Your code and data stays private, secure, and in your control (Review Board won't mine your data for AI training or other purposes) Works with what you use today (such as Git, Mercurial, Perforce, ClearCase, Cliosoft SOS, or Azur
Pythonで書かれたレビューツールです。VMware社内で利用されていることで有名なツールです。 プレコミットレビューという概念のレビューツールです。つまり、コミット前にレビューをするという事が前提になっているツールです。よって、結果的に差分を重点的に確認していくツールのつくりになっています。 rietveld rietveld – Code Review, hosted on Google App Engine – Google Project Hosting Google社内で使われているコードレビューツールである「Mondrian」のオープンソース版です。基本的にGoogle App Engineで動くことが前提になっています。 GAEの上のコードのデータを置くということがオトナの事情的に難しいかもしれませんが、検討してみてください。 Phabricator Phabricator
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
オブジェクト指向エクササイズ下記のルールで、1000行程度のソフトウェアを書いてください。 1. 1つのメソッドにつきインデントは1段階までにすること 2. else句を使用しないこと 3. すべてのプリミティブ型と文字列型をラップすること 4. 1行につきドットは1つまでにすること 5. 名前を省略しないこと 6. すべてのエンティティを小さくすること 7. 1つのクラスにつきインスタンス変数は2つまでにすること 8. ファーストクラスコレクションを使用すること 9. Getter、Setter、プロパティを使用しないこと というルールが適応できない場合は優先すべきルールを選択し、どのルールを適応するのか判断して欲しいとの旨が記載されています。 9つのうち 7つがデータのカプセル化 1つポリモフィズの適切な利用(else句をつかわない) 1つが明確でわかりやすい命名標準 オブジェクト指向
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい!どの口がアジャイル出来るって言ってるねん!」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを10年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか?」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く