BT
rss
人のフォロワー

個人の生産性

作者: Christopher Goldsbury フォローする 0 人のフォロワー , 翻訳者 笹井 崇司 フォローする 0 人のフォロワー   投稿日  2012年1月9日 午後8時44分

Tony Wong氏(プロジェクトマネジメントのブラックベルト)は個人の生産性にとって実践的なポイントをいくつか挙げている。この記事では、これらをいかにソフトウェア開発に適用するかを考え、彼のリストと他のリストを比べる。

人のフォロワー

バリューストリームマッピングはソフトウェア開発でも有効か?

作者: Vikas Hazrati フォローする 0 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー   投稿日  2010年11月5日 午前12時57分

バリューストリームマッピングはリーン(lean)生産技法のひとつであり,製品やサービスを消費者に届けるのに必要な,材料と情報の流れを分析するために使用される。製造業において Toyota が実施に成功したこのプロセスが,ソフトウェア開発においても適用されている。ソフトウェア開発は製造業と同じ道をたどるのだろうか?

人のフォロワー

アジャイルの"ルール"を"ガイドライン"に変えられるか?

作者: Vikas Hazrati フォローする 0 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー   投稿日  2010年2月3日 午後3時2分

一般的にルールとは,ある行動に関して定義された基準のことをいう。ルールには従わねばならない。法律の非公式な呼び方が "ルール" である,と言い換えてもよいだろう。これに対してガイドラインとは,決められた手順に従うことによって,特定のプロセスを合理化する目的のものだ。定義上は,ガイドラインは義務ではない。アジャイルチームはルールを語るべきだろうか,それともガイドラインで十分なのだろうか?

人のフォロワー

ふりかえりについてのふりかえり

作者: Deborah Hartmann Preuss フォローする 0 人のフォロワー , 翻訳者 和智 右桂 フォローする 0 人のフォロワー   投稿日  2009年9月27日 午前1時4分

組織内のどのチームもアジャイルを用いていて、それぞれ局所的な改善を実装するので手一杯だった場合、正式に「IT」ないし「システム開発」と呼ばれるようなより大きな組織では何が起こるのだろうか?これについて巨大なアジャイルプログラムを抱えるコーチが、自分たちの立てた戦略を共有した。これはより大きな組織が全体の動向を把握し、そこから学ぶことで利益を得られるように作られている。Paulo Caroli氏はこれを「ふりかえりについてのふりかえり」と呼んでいる。

人のフォロワー

ビジネス価値を基準に(バックログの)優先順位を付ける

作者: Derek Longmuir フォローする 0 人のフォロワー , 翻訳者 近藤 修平 - (株)永和システムマネジメント フォローする 0 人のフォロワー   投稿日  2008年9月10日 午前12時56分

ビジネス価値を基準に(バックログの)優先順位を付ける。Luke Hohmann氏は、バックログのどの項目から検討を始めるべきかについて定量的な判断を下す方法を述べている。

人のフォロワー

アジャイルの採用に関する感覚的な障害

作者: Mark Levison フォローする 0 人のフォロワー , 翻訳者 木下 史彦 - (株)永和システムマネジメント フォローする 0 人のフォロワー   投稿日  2008年8月20日 午前9時59分

Amr Elssamadisy氏 (『Agile Adoption Patterns: A Roadmap to Organizational Success』の著者) はAgile2008でアジャイルの採用における非技術的な障壁をテーマにセッションを行った。彼は「年を重ねるにつれて、もっともややこしい問題は技術ではなく人の問題であることに気づいたんだ」と言った。

人のフォロワー

アジャイルプロジェクトにおけるトレーサビリティ・マトリックス

作者: Vikas Hazrati フォローする 0 人のフォロワー , 翻訳者 沼田 暁子 フォローする 0 人のフォロワー   投稿日  2008年6月18日 午前12時24分

形式ばったトレーサビリティ・マトリックスは、しばしばアジャイルコミュニティから強い反応を引き起こしている。Agile Testingグループでの激しい議論の中で、Jorge Argus氏はアジャイルプロジェクトにおけるトレーサビリティ・マトリックスの必要性に関する興味深いスレッドを立てた。

人のフォロワー

Article: AgileEVM: 製品ライフサイクル全体で費用対効果を計測する

作者: 長部 広太 フォローする 0 人のフォロワー 投稿日  2008年4月5日 午前6時25分

AgileEVMは、出来高管理の指標を使用した基準計画と比較し、コスト、スケジュール及びスコープの実際の値を計測する伝統的なプロジェクト管理手法を適応したプロジェクト管理手法です。

人のフォロワー

よく組織されたチーム:単に生き残るのではなく、成功へと導く支援

作者: Mark Levison フォローする 0 人のフォロワー , 翻訳者 編集部 フォローする 0 人のフォロワー   投稿日  2008年3月28日 午前12時8分

業績の良いチームを編成するには何が必要なのか?Doug Shimp氏およびSamall Hazziez氏によると「よく組織されたチーム」は以下の特徴があるらしい。AgileおよびLeanの原則に従う、フィードバックループがある適応システムを使用、ビジネスの展望にフォーカス、そして熱意があり非常に生産的である。

人のフォロワー

デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー

作者: Vikas Hazrati フォローする 0 人のフォロワー , 翻訳者 八角研究所 フォローする 0 人のフォロワー   投稿日  2008年3月24日 午前12時16分

デザインとコードレビューに関する興味深い記事でKirk Knoernschild氏は、レビューを行うということは、ソフトウェアの品質を改善することを約束し、基準の順守を保証し、そして価値ある開発者の教育ツールとなると述べている。しかしながら、レビューの実施方法にその効果は左右される。レビューは、ある組織ではソフトウェア開発工程で本当に意味のあるものであるかもしれないが、その一方で別の組織では形式的なお役所仕事の一部となってしまっているかも知れない。

人のフォロワー

Article: 3つのM - リーンの3要素

作者: 沼田 暁子 フォローする 0 人のフォロワー 投稿日  2008年3月23日 午後6時40分

リーン主義をソフトウェア開発に適用することについての議論では、主にムダ(無駄:Muda)なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ(無理:Muri)とムラ(ばらつき:Mura)を削除することも目指しています。

人のフォロワー

成功するコラボレーションには偶然などない

作者: Deborah Hartmann Preuss フォローする 0 人のフォロワー , 翻訳者 編集部 フォローする 0 人のフォロワー   投稿日  2008年1月18日 午前6時4分

パートナーシップコーチのMichael Spayd氏は契約社員と正社員は両方ともプロジェクトに取り掛かる際にコンサルタントとしての役割を果たすことができ、またクライアントとコンサルティング系統の契約を発展させていくという提案を記した記事をInfoQに提供した。これは通常の”契約”という用語とは異なる意味を持っている。サービスプロバイダとクライアント間の法的な決まりごとである。彼の"Designed Partnership Contract"は金銭の交換に関するものではなく、”コンサルタント”がコミュニケートし、自身達の価値観と嗜好を大切にするのを可能にする一方、より良いクライアントとのコラボレーションを成すために使用されるものである。

人のフォロワー

私は自信がない。あなたの聞いたことが、私が言ったと思っていることかどうか。

作者: Joe Rainsberger フォローする 0 人のフォロワー , 翻訳者 白石 俊平 フォローする 0 人のフォロワー   投稿日  2008年1月13日 午前12時25分

コミュニケーションそれ自身は難しくも何ともない、と言わんばかりに、私たちの職場は専門用語であふれている - ビジネスドメイン用語、製品用語、開発者用語など。そのため私たちはそこにコミュニケーションがある、と言われても驚きはしない - しかし私たちは、目をぐるぐる回したりマーフィーの法則を引用したりする代わりに、それを捉え、対処することができているのだろうか?

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT