「ZenHub×GitHub」を軸としたアジャイルプロセスの作り方
他プロジェクト管理ツールとの比較と選定ポイント また、アジャイルプロセスを作っていく上で親和性がある他のプロジェクト管理ツールとしては、アトラシアン製のJIRAとTrelloがあります。 これらの中でZenHubを選定した理由は、「チケット管理」と「リポジトリ管理」の親和性がポイントでした。 例えば、リポジトリ管理にアトラシアンのBitbucketを利用しているならば、JIRAやTelloのほうが親和性が高いですし、さまざまな連携からアジャイルプロセスを作りやすいです。 一方、GitHubを使っているのであれば、ZenHubを使うことをおすすめします。特にチケット（GitHub Issue）からリポジトリに対するコミット履歴やPull Requestが確認できたり、チケットとリポジトリで相互リンクの関係を作れていたりとてもアジャイルプロセスが作りやすいです。また後述しますが、ZenHubは
GitHub - susam/gitpr: Quick reference guide on fork and pull request workflow
Every project has a main development branch where the developers push commits on a day-to-day basis. Usually, the main development branch is master but some projects choose to have develop or trunk or another branch for day-to-day development activities. We refer to this main development branch as the main development branch throughout this document to keep the text general. However in the command
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
プログラマが知るべき 97 のこと - Backnumbers: Steps to Phantasien
「プログラマが知るべき 97 のこと」 日本語版のエクストラとしてちょこっと書かせてもらいました. エッセイ集のような本で, 読切 Blog 記事一気読み, みたいなノリで読めます. ソフトウェアアーキテクトが知るべき(同上) の続編というかんじですが, アーキテクトもプログラマも大差ないので片方読んで面白かったらもう一方も楽しめると思います. (両方に書いてる人もいます...) 一編 2 ページくらいの長さに揃っているので割と読み易い一方, 私のようにぐだぐだ長々と書く傾向の人間が書くと ややあっさりしてしまう気がした. ここで続きをちょっと書きたい. パッチのなやみ 私が書いたのは, "良いコード" と "良いパッチ" はときどき相反することがあるからどうしましょうね, という話だった. 良いコードはさておき良いパッチとはどんなものだろう. という話は本を買っていただきたくおもいますが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
n8n.io - a powerful workflow automation tool
