using data and acceleration techniques to improve essential software development processes for greater automation, fast feedback cycles, and reliable feedback. Developer Productivity Engineering は、自動化、迅速なフィードバックサイク ル、信頼性の高いフィードバックを実現するために、データと加速技術を使用 してソフトウェア開発プロセスを改善するための分野です. THE DEVELOPER PRODUCTTIVITY ENGINEERING HAND BOOK 19
approvals? - 手動による変更承認なしで、変更を実稼働環境にプロモートできますか? 2. Do production changes need to be approved by an external body before deployment or implementation? - 運用上の変更は、展開または実装前に外部機関の承認を受ける必要がありますか? 3. Do you rely on peer review to manage changes? - 変更を管理するためにピアレビューに依存していますか? 4. Do team members have a clear understanding of the process to get changes approved for implementation - チームメンバーは、変更の実装を承認してもらうプロセスを明確に理解していますか? Ex. Streamlining change approval （変更承認の合理化） DevOps capabilities: process Streamlining change approval 31
saying that a project is failed because it is late, or has cost overruns - I would argue that it's the estimate that failed. So the CHAOS report isn't chronicling software project failure, it's chronicling software estimation failure. So what counts as success? If we could measure it the answer has to be Return on Investment. Sadly this is usually next to impossible to measure (see my discussion in CannotMeasureProductivity) In the end it's a fuzzy sense of business satisfaction relative to the cost of the project. 引用: WhatIsFailure（失敗とは）: マーティンファウラー 56
that they usually feel most productive when they make progress on tasks and when they have only a few context switches and interruptions. However, observing developers’ workdays revealed that they constantly switch contexts, often multiple times an hour. For example, developers switched tasks on average 13 times an hour and spent just about 6 minutes on a task before switching to another one. “ “開発者たちは、タスクの進捗を感じる時や、コンテキストの切り替えや中断が少ない時に最も生産的 だと感じることが多いと報告しています。 しかし、開発者の労働日を観察すると彼らは絶えずコンテキストを切り替えており、しばしば1時間に何 度もこれを行っています。例えば、開発者は平均して 1時間に13回タスクを切り替え、約6分間タスクに 集中して別のタスクに移っています” 引用 : Rethinking Productivity in Software Engineering Chapter Developers’ Diverging Perceptions of Productivity
of schedule, which I'll call the manager's schedule and the maker's schedule. The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour. ~ there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.” - タイムボックスが、エンジニアとマネージャーでは違う - マネージャーは、1時間区切りでタスクをこなす - メーカー（エンジニア）は、半日単位でタスクをこなす タイムボックスの違いが大きい 60
i35_267
line_developers_tw
punsiriboo
soudai
grafferhandbook
nasuvitz
minorun365
phayacell
hotekagi
minamikoyasuganka
oracle4engineer
yujirooo
recruitengineers
bluesmoon
cromwellryan
stephaniewalter
sergeychernyshev
gr2m
destraynor
kastner
nonsquared
shlominoach
kneath
addyosmani
swwweet
