みなさんこんにちは。@ryuzeeです。 僕がチームやチームメンバーに対して期待したり言いたいことを好き勝手に書いてみたいと思います。 もちろん、僕の感覚に合わない人も多いかもしれませんが、僕個人の考えということでご容赦いただければと思います。 こういうのは言語化することが非常に重要だと思っています。 給料をもらえるのは、自分が会社に所属しているからではなく、その先にお金を払ってくれるお客様がいるからだ、ということを理解しようしたがって、お客様の期待に応えられるようにふるまうことは責任であることを理解しようお金をもらう以上プロなので、プロとしてふるまうようにしようプロとして無理なものは無理と言おう会社は自分の将来の面倒を見てくれるわけではないことを理解しよう他でも通用するスキルを身につけよう。それが自分のためであることを理解しようプロとして自分に投資しよう。勉強は会社のためにやるのではなく
『アジャイルレトロスペクティブズ』読了。献本感謝。 GoF本がデザインパターンの教科書であり、XP本がソフトウェア開発の手法に関する教科書だとすれば、本書はチーム開発における「ふりかえり」の教科書であると言ってよいのではないだろうか。 本書では、「ふりかえり」に関するパターンが50近く紹介されているのだが、一つ一つがとても実用的かつユーモラスにまとめられている。 本書で紹介されている方法はゲーム的で、模倣可能で、隠れてしまっている改善へのヒントを引き出すものとなっている。 以下、おもしろかったものをいくつか、コメントを交えて。 ■ アジャイルレトロスペクティブなチーム まずいきなりインパクトがあるのが、アジャイルレトロスペクティブなチームの会議の例。一見何ともない普通の会議に思えるが、この箇所だけ見ても、明確なゴールと時間の設定、冒頭に全員に発言させる点など、参考になる点がいくつもある。
どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，(1)設計作業を実施する，(2)成果物をレビューして欠陥を洗い出す，(
尾藤正人です。 ウノウではおかげさまで順調にエンジニアの数が増えてきました。エンジニアが増えてくると、共同開発をいかに効率よく行うかが問題になってきます。n人の開発者がいれば開発スピードはn倍にはならず、n倍よりも落ちます。人数が多ければ多いほど、共同開発は難しくなり、ひどい場合には人数が増えたから開発スピードが落ちたということになりかねません。 ウノウでは共同開発を効率よく行うために様々な工夫を用いています。今回はウノウでどのようなステップで開発を行っているか紹介したいと思います。 subversion でソースコードを管理 ソースコード管理ソフトがなくては話になりません。ウノウではソースコードの管理に subversion を使ってます。subversion を使うことで過去の状態に簡単に戻すことができますし、個人の環境を完全に分離することができます。 subversion のコミット
ソフトウェア開発ではこれまで、設計の重要性が繰り返し提言されてきた。良い設計ができれば、仕様を満たして正しく動作するだけでなく、理解や変更がしやすく、さらに再利用しやすいシステムとなる。逆に、そのようなシステムが実現できているのなら、それは良い設計であったといえるだろう。 では、良い設計が実践できているかというと、できていないことの方が多いのではないだろうか。例えば以下のような状況を聞くことは決して少なくない。 良い設計が実践できていない例： 不具合を修正してリリースしたら、その影響によりほかの個所で不具合が発生し収束に時間がかかった ほぼ同じコードが複数個所に大量に存在するため、1つの目的の修正でも数多くの同じ修正が必要となった 修正した場所と本来関係ない個所で問題が発生してしまった 機能アップする場合、修正するより作り直す方が早かった それでは良い設計を実践し、このような状況に陥らない
ソフトウェア開発ではこれまで、できるだけ「シンプル」に設計・開発することの有効性が繰り返し提言されてきた。ソフトウェアをシンプルにすればするほど、設計は見通しが良くなり、開発は容易になり、メンテナンスも楽になる。 では、開発を＜シンプル＞にするというのはどういうことなのか？ 一体どうすれば＜シンプル＞になるのか？ これらの質問にあなたは即答できるだろうか。実際のところ、頭ではシンプルにすることが良いと分かっていても、現実には実践できていなかったりするのではないだろうか。 そこで本稿では、現実の開発現場でシンプルな設計・開発を行うための1つの手段として、その「考え方のコツ」を考察する。もちろんこのコツを身に付けることは、すべてのソフトウェア開発で役立つものだろうが、特にNAgile（エヌ・アジャイルまたはナジャイル）を実践していくうえでは、ぜひ知っておいてほしい（NAgileについての概要は
連載 開発をもっと楽にするNAgileの基本思想 第1回 アジャイル開発ではドキュメントを書かないって本当？ ――より良いコミュニケーションを実践するコツ―― 福井コンピュータ株式会社 小島 富治雄（Microsoft MVP 2006 － Visual C#） 2006/02/22 はじめに 本連載は、人気連載「NAgileで始める実践アジャイル開発」の姉妹版となる別枠の新しい連載である。「NAgileで始める実践アジャイル開発」の連載が基本的にプラクティスを実行する方法やツールにフォーカスしているのに対し、本連載ではアジャイル開発の基本思想を身に付けるためのコツを中心に書いていこうと思う。 どちらの連載もNAgile開発を実践するうえで欠かせない知識となるので、基本版「NAgileで始める実践アジャイル開発」と姉妹版「開発をもっと楽にするNAgileの基本思想」の両連載（NAgileシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
