どこでもプロジェクト管理バックログ / Redmine.JP / Brabio! : プロジェクト管理,スケジュー...他...全8件
ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの(わたしの)プロジェクトにも導入すべき? その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ~ソフトウエア開発を成功させる2つの鍵のバ
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
今週月曜日に公開した記事「特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐」は、記事に対して数多くのブックマークやツイートが行われ、大きな反響をいただきました。 その萩本氏から「問題提起だけで終わるのではなく、こうあるべきだという提案もしたい」、という依頼をいただいたので、記事にいただいた反響への返答という意味も込めて、萩本氏の提案についても掲載したいと思います。 以下からは萩本氏の文章となります。 これまでのIT業界の慣習を捨て去り、あるべき姿へ 僕が日記(注:記事の元になったFacebookへの書き込み)を書いたのは、二度とこのような案件が出ないよう本質的な問題提起をしようと思ったからです。 それが僕の責任だと思いました。 本質的問題を提起したつもりですが、しかし本当に理解していただいたのかというのが心配でもあり、また理解していただいたとしても、今後何
あるプロジェクトに何カ月もの間(あるいは何年もの間)取り組んでいたら、ある日新しい従業員が入ってきて、これまでの自分の仕事が全部無駄に見えてしまうような素晴らしい方法を提案した、といった経験はあるだろうか?こんなとき、あなたやチームの他のメンバーは、同じことを思い付けなかったことで、自分をバカだと感じるはずだ。 知性や創造性、社会的影響力や記憶力の面で、自分よりも明らかに優れている人には、恐怖を感じてしまいがちだ。たとえ自分が優れた人材だとしても、自分が持っているのとは違う、特別な才能を持つ部下がいるかもしれない。 自分のチームに優秀な人材がいることには良い点もあるが、彼らは必ずしも管理しやすいとは限らない。特定の分野や精神過程で明らかに並外れた能力を持つ人は、型破りであったり、論争を好んだり、寛容でなかったり、融通が利かなかったり、しゃくに障る態度を取ったりして、能力が十分認められなかっ
先週、1月25日と26日に都内で行われたソフトウェアテストに関するシンポジウム「ソフトウェアテストシンポジウム JaSST'12 Tokyo」。会場には、参加者が自分の知っているテストの種類を付箋に書いて、自由に貼ることができるポスターが掲示されていました。 独自のテストの種類を貼っていく ポスターの下地になったのが「テスト技法ポジショニングマップ」です。さまざまなテスト技法が表示されています。 この上に、さらに自由にテスト技法、テスト手法の名前が付箋で貼られました。例えば、右上には「ZERO テスト(テストしない)」、右下の方には「血みどろテスト」、中央下には「書いてあるとおりテスト」、左下には「がまの油いぶり出しテスト」、左上には「カン」(勘ですね)、図のど真ん中には「たぬきの皮算用テスト」などなど。名前だけではどんな内容のテストなのか分かりませんけれど……
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
クライアントとの更新やりとりを10倍楽にする(か... / 【無料配布】Web制作における書類一式、そしてド... / WEBサイト制作前やデザイン制作時に欠かせないヒ...他...全5件
第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基本契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出
特許庁が5年前から進めてきた基幹系システムの刷新プロジェクトを中止する方針を固めたことが、日経コンピュータの取材で分かった。当初は2011年1月の稼働を予定していたが、業務分析の遅れなどから要件定義と設計が難航。稼働を3年遅らせたが、立て直すことができなかった。 政府が策定したレガシーシステムの刷新指針に基づき、特許庁は2004年10月に「業務・システム最適化計画」を策定した。この刷新指針は、特定のITベンダーとシステム保守などを長期契約することによるITコストの高止まりを解消する目的で策定されたものだった。同庁はさらに、入札に分割調達の仕組みを採用して競争原理を働かせることを目指した。 要となるシステム設計とシステム基盤の構築については、東芝ソリューションが入札予定価格の6割以下の99億2500万円で落札した。ところがプロジェクトが始まると、現行の業務やシステムを理解した職員と技術者が足
お疲れ様です。ウェブサービス本部開発2室のスエヒロです。 普段はプログラマとしてサービス開発に携わっておりますが、ライブドアキャプテンブログ(旧ライブドア社長ブログ)の代打執筆や、テキスト系妄想メディア「ワラパッパ」の編集など、プログラマ職以外の活動もさせて頂いております。サッカー以外もオシャレにこなすヒデみたいなポジションを目指したいところです。ヒデと言っても日出郎さんじゃないですよ。どうぞ宜しくお願いします。 さて。 皆様、サービス開発や運用を効率よく進める上で「プロジェクト管理ツール」をお使いでしょうか?新しいサービスの開発進捗の管理、運用フェーズにおけるタスク管理、バグ・不具合解消のためのやりとりなど、様々なフェーズで利用されるプロジェクト管理ツール。実際業務で使われている方も多いかと思います。 livedoorのサービス開発においてもいくつかの管理ツールが利用されています。代表的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く