だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
なぜ糞システムができあがるか
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
上流工程の失敗カタログ - 勘と経験と読経
他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。 「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF) (2019/4/19 リンク切れを修正) 「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む 「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。 本来あるはずのレアケース、例外に関する要求が出てこない 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手
Maka-Veli.com / 作業工数を見積る、という事。
たまには企業ディレクターっぽい記事を書いてみようかと・・・見積作業がたぶん一番多いです。失敗すれば、お客さんにも会社にもデザイナーにも迷惑がかかってしまう重要なタスク。お金に関する問題なので、全工程を把握し、リスクヘッジも含みつつボッタクリなんて思われないようにし、きちんと作業工数分ご請求させて頂く為にミスのないよう心がけています。今回はそんな御見積時に関する、僕が気をつけている点。ディレクターってなんだよ、何してんの偉そうに、って疑問視される方も、少しは身近に感じてもらえるでしょうか？※画像のネコさんは内容と全く関係無いです、申し訳ございません。 個人的に重要だと思うポイントは以下です。 作業の終わりはどこかを決める 「見えない工数」が見えていないと、終わりが無いです。 ラインはきっちり引きましょう。 なぜかというと、 もちろんこちら側の作業が終わらないのを防ぐ理由も大きいです
システム開発の王道を極める
| トップ扉 | 思考支援 . ネット革 . ＵＩ考房 . 設計技術 . シス開発 . 道具活用 | 自己紹介 | | 最近更新 | 思考方法 . 議論手法 . 説明技術 . 知能教育 . □□□□ . □□□□ | 著作更新 | | 総合目次 | 社会進歩 . 市民運動 . ジャナ革 . 未来社会 . 一流仕事 . 組織構築 | 独り言？ | | 補助索引 | 心の階段 . □□□□ . 芸術奥覗 . 残り物達 . リンク集 . 脳ぐちゃ | 推奨用語 | ソフトウェアを中心としたシステム開発では、規模が大きくて複雑なほど、いろいろな技術が必要となる。高度な設計技術はもちろん、分析技術や管理技術などもだ。これらの技術を活用できれば、難易度の高い開発でも成功の可能性が高まる。本格的なシステム開発に役立つ技術を、活用ノウハウも含めて紹介する。 ・システム開発には様々な技術が必要 ・力ずくから
要求仕様戦争（その1）
■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100％はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ（しかも部分的だ）。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
システム・エンジニアの基礎知識