Amazon.co.jp: 情シスの定石 ~失敗事例から学ぶシステム企画・開発・保守・運用のポイント: 石黒直樹, 解夏: 本
炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance
最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ！！経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要！やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ！— 代表取締役 岩元仁＠株式会社ロックシステム (@iwa3nen) 2021年8月28日 経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します) 炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。 僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上
ブルックスの法則 - Wikipedia
ブルックスの法則（ブルックスのほうそく）は、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。 これは1975年にフレデリック・ブルックスによって出版された著書『人月の神話』[1]に登場した。 根拠[編集] ブルックスによれば、この法則が成り立つ主な理由は以下の通りである。 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる ソフトウェアプロジェクトは、複雑な作業である。また、新たにプロジェクトに参加した人は、仕事に取りかかる前に、まず開発の現状や設計の詳細などを理解しなければならない。つまり、新たに人員を追加するには、その人員を教育するために、リソースを割かなければならないのである。したがって、人員の増加がチームの生産性に与える効果は、短期的にはマイナスになる
Project delays: why good software estimates are impossible
Christian Maioli M. 🛠 Web development and 🖥 computer programming Rubik’s cube world recordHave you ever tried to solve a Rubik’s cube and been unable to complete it? I once tried several times during a long bus trip and felt pretty bummed after failing every time. Then I learned that there are kids out there that can do it in seconds! How is that even possible? Update: Mia Li was kind enough to
Software versioning - Wikipedia
The two purely numeric forms removes the special logic required to handle the comparison of "alpha < beta < rc < no prefix" as found in semantic versioning, at the cost of clarity. Incrementing sequences[edit] There are two schools of thought regarding how numeric version numbers are incremented. Most free and open-source software packages, including MediaWiki, treat versions as a series of indivi
ソフトウェア開発における多能工の問題 - 勘と経験と読経
ソフトウェア開発の現場では、特定作業に特化した専門家による分業開発から、個々人が幅広い作業をこなす多能工による開発といった方向に変わりつつある。アジャイル開発プロセスそもそも多能工を前提としている。また、全般的なソフトウェア開発プロジェクトが大規模より中小規模・短工期にシフトしていることが、専門家(単能工)による開発を難しくしつつある状況も、開発エンジニアの多能工化を後押ししている。しかし、多能工によるソフトウェア開発はベストプラクティスかというと、そうではないと思う。多能工アプローチの問題点について考察して望まないと、思わぬところから足をすくわれる事がある。 なぜ多能工なのか？専門家(単能工)はなぜだめなのか？ ファクトリー型アプローチは一時期流行し、いまなお一定の価値をもってはいるが、ほとんどのアプリケーション・ソフトウェアの開発には、現在これよりも有効な手法が存在している。 ソフトウ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: ユーザーのためのプロジェクトマネジメント実践講座: KPMGビジネスアシュアランス: 本
Amazon.co.jp: これ以上やさしく書けない プロジェクトマネジメントのトリセツ: 西村克己: 本
Amazon.co.jp: 「プロジェクトマネジメント」実践講座: 伊藤大輔: 本
Amazon.co.jp： プロジェクトマネジメント現場マニュアル[改訂版]: 能登原 伸二, 日経SYSTEMS: 本![Amazon.co.jp： プロジェクトマネジメント現場マニュアル[改訂版]: 能登原 伸二, 日経SYSTEMS: 本](https://cdn-ak-scissors.b.st-hatena.com/image/square/25ed69cbd7cecc73d77ffaa4648350d0b5fc5934/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F41K9aDgDCKL._SL500_.jpg)
試験区分一覧 | 試験情報 | IPA 独立行政法人 情報処理推進機構
)
Dependency (project management) - Wikipedia